Re: xz backdoor
On Sun, 31 Mar 2024 at 13:55, Christopher Klooz wrote:
[..]
BTW all that scandal with xz backdoor.
Looks like if fedora spec file would be using not
Source0:
https://github.com/tukaani-project/%{name}/releases/download/v%{version}/%{name}-%{version}.tar.gz
but
Source0:
https://github.com/tukaani-project/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz
It would be no issue.
kloczek
--
___
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 - Book Smugglers edition
On Sat, 16 Mar 2024 at 10:03, Miroslav Suchý wrote: > Hot news: > The last phase has been announce > https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will > proceed when approved with FESCO. > I think that generally you are wasting your man/hours posting such statistics. The same time could be used better by going with a few grep. sort, sed oneliers to co update and align all packages License: fields and commit all those changes across all per packages repos in a few minutes. Some of the proven packagers with RW access to all packages repos can apply necessary changes in a few tenths of minutes. Subject of SPDX migrations are already IIRC active since July 2022 (soon it will be two years anniversary). All those changes should not be applied relying on each package maintainers because that change is from Trival™️ class. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- ___ 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: libcap-ng upcoming change
On Mon, 18 Dec 2023 at 18:18, Steve Grubb wrote: > Hello, > > I wanted to ask about the right tactic to make a change in Fedora 40. > Libcap- > ng is ready for a new release. I want to remove a Fedora only patch that > allows an errant call to capng_apply to succeed. BTW libcap-ng. Is there any plan to get rid of libcap?樂 kloczek -- Tomasz Kłoczko | inkedIn: http://lnkd.in/FXPWxH -- ___ 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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks
On Mon, 27 Nov 2023 at 17:17, Frederic Berat wrote: > ERROR: Error in gtkdoc helper script: > > ERROR: ['/usr/bin/gtkdoc-mkhtml', > '--path=/builddir/build/BUILD/cinnamon-5.8.4/docs/reference/cinnamon:/builddir/build/BUILD/cinnamon-5.8.4/redhat-linux-build/docs/reference/cinnamon', > 'cinnamon', '../cinnamon-docs.sgml'] failed with status 6 > warning: failed to load external entity "../xml/cinnamon-recorder.xml" > ../recorder.xml:10: element include: XInclude error : could not load > ../xml/cinnamon-recorder.xml, and no fallback was found > > BTW repositories management: createrepo-c needs libxml 2.12.x adjustment as well. It is already integrated in createrepo-c git repo. API has changed slightly not only because has been removed but in the same cases it needs some minor adjustments because of some const declarations (look on libvirt-glib today commited changes by maintainer). Nevertheless, just FTR: ABI has not changed. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH -- ___ 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
https://releases.pagure.org/ is down
Hi, Is it possible to do something about this?樂 kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* -- ___ 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 squeeze coreutils-9.4 into Fedora 39?
On Wed, 30 Aug 2023 at 20:45, Adam Williamson wrote: [..] BTW it would be good to push as many coreutils patches to upstream. Especially the selinux patch. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Broken gcc 13.0.1-0.15.fc39 (missing )
Hi, Looks like with latest gcc 31.0.1-0.15.fc39 many packages builds are failing with: /usr/lib/gcc/x86_64-redhat-linux/13/include/immintrin.h:135:10: fatal error: amxcomplexintrin.h: No such file or directory 135 | #include | ^~~~ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109600 kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* ___ 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
Latest gcc changes causes new [-fpermissive] errors?
Looks like some recent changes introduced after last mass rebuild are causing now some new errors https://github.com/dankamongmen/notcurses/issues/2673 https://bugzilla.redhat.com/show_bug.cgi?id=2116050 Generally speaking, after introducing such changes someone should try to rebuild all packages which depend on gcc-g++ to assess what it caused and informa here to focus other people's attention on fixing new issues. Kind of an explanation and/or shors instruction in which direction should be going, some necessary fixes would be welcome as well. Without that all that kind of issues would be hidden issues .. until the next mass rebuild after which not to many people would be able to correlate the cause with results. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* ___ 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: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)
On Wed, 29 Dec 2021 at 19:00, Gordon Messmer wrote: [..] > > To me this is like saying 'move everything into /usr but because its > > volitile move it back into /var but in a sub-directory from where it > > was so you can keep an image running.' In this case, this doesn't > > sound like any savings and more of a headache of why did it corrupt > > this time. > > But this doesn't. Why would you need to move the rpmdb? Users probably > aren't installing rpm packages in containers at run time (particularly > if /usr is read-only); installation typically happens when building the > container image, at which point /usr isn't read-only. > This is all because none of the file systems available on Linux invented volumes properties. +15 years ago on ZFS introduction on Solaris people had exactly the same problems and all those issues have been resolved by introduction of the volume property marking that exact volume needs to be snapshotted and cloned on making new boot env (global or non-global zone as well). That issue is not limited only to rpm database content or generally /var content. In case scenario when new boot env is created and on that new tree would be upgraded majost upgrade of the database engine which on first execution will change format of the database files you want to have some "backup solution" that in case if anything would go wrong you want to be able quickly be able back to original state. In such cases new upgraded database engine binaries will be on /usr and let's say that database data on /srv/database. To create new boot env in which not only / and /usr will be mounted from from exact clones all what needs to be done in case Solaris or Linux with ZFS would be mark volume mounted in /var that it needs to be snapshotted and cloned during created new instance of the bootable filesystems tree. In other words trying to solve the multiple volumes mount problem by moving more and more to a single volume (because that is the easiest case) is pointless because it will solve only the rpm database problem but it will not solve issues of mounting multiple volumes. Solving that kind of problems on top of all possible to use on Linux like systems is as well pointless because to solve such thing in civilised way it is necessary to have snapshotable FS which in case of linux for now is only btrfs (optionally zfs as well). Volulumes properties stored in volume metadata inside storage pools solves much more use cases than only /, /usr and /var separation. From that point of view I really do not understand why btrfs developers resist to implement well known ZFS functionality. In other words when btrfs will have possibility to possibility to describe a set of volumes which will be necessary to snapshot and clone on making new boot env volumes set SuSE will be rolling back move rpm database back to the /var where it should be. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: [Test-Announce] 2021-09-13 @ 16:00 UTC - Fedora 35 Blocker Review Meeting
On Sun, 12 Sept 2021 at 00:02, Geoffrey Marr wrote: > # F35 Blocker Review meeting > # Date: 2021-09-13 > # Time: 16:00 UTC > # Location: #fedora-blocker-review on irc.libera.chat > > Hello testers! > > There are currently 6 proposed freeze exceptions to be looked at during > the meeting. We will also spend some time looking over the existing 6 > accepted blockers and 6 accepted freeze exceptions. > After recent gcc changes it seems like some packages may no longer compile. First example from the edge a2ps make[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/a2ps-4.14/lib' /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFFILE=\"/etc/a2ps.cfg\" -I. -I.. -I.. -I../intl -I.-O2 -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 -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c -o fonts.lo fonts.c libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFFILE=\"/etc/a2ps.cfg\" -I. -I.. -I.. -I../intl -I. -O2 -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 -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c fonts.c -o fonts.o fonts.c:1700:16: warning: ‘input’ defined but not used [-Wunused-function] 1700 | #else |^ fonts.c:1653:17: warning: ‘yyunput’ defined but not used [-Wunused-function] 1653 | | ^ /bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFFILE=\"/etc/a2ps.cfg\" -I. -I.. -I.. -I../intl -I.-O2 -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 -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c -o path-concat.lo path-concat.c libtool: compile: /usr/bin/gcc -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -DSYSCONFFILE=\"/etc/a2ps.cfg\" -I. -I.. -I.. -I../intl -I. -O2 -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 -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c path-concat.c -o path-concat.o path-concat.c:25:29: error: expected identifier or ‘(’ before ‘void’ 25 | # define mempcpy(D, S, N) ((void *) ((char *) memcpy (D, S, N) + (N))) | ^~~~ path-concat.c:25:37: error: expected ‘)’ before ‘(’ token 25 | # define mempcpy(D, S, N) ((void *) ((char *) memcpy (D, S, N) + (N))) | ^ In file included from /usr/include/features.h:488, from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdio.h:27, from path-concat.c:28: path-concat.c:25:29: error: expected identifier or ‘(’ before ‘void’ 25 | # define mempcpy(D, S, N) ((void *) ((char *) memcpy (D, S, N) + (N))) | ^~~~ path-concat.c:25:37: error: expected ‘)’ before ‘(’ token 25 | # define mempcpy(D, S, N) ((void *) ((char *) memcpy (D, S, N) + (N))) | ^ make[3]: *** [Makefile:763: path-concat.lo] Error 1 Last time this package was rebuilt ~2 months ago and probably many more like this one are still not exposed. https://koji.fedoraproject.org/koji/packageinfo?packageID=180 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: What do we think about always autoreconfing? (was: Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal))
On Tue, 13 Apr 2021 at 11:27, Richard W.M. Jones wrote: > Hijacking this thread originally about > https://fedoraproject.org/wiki/Changes/Autoconf_271 > > What is the current thinking in Fedora about always running > "autoreconf -i" during builds that use autotools? > 1) "autoreconf -i" is not enough. It needs to be executed "autoreconf -fi" and to have proper visibility reconfigure issues should be executed "autoreconf -fiv" 2) Looks like still no one performed experiment of rebuilding all existing packages with %configure macro in spec by execute: $ for i in *.src.rpm; do rpmbuild --rebuild -D "_configure 'autoreconf -fiv; configure'" $i; done To check which Fedora packages are failing in the build environment with autoconf 2.71. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Thu, 11 Mar 2021 at 12:04, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: [..] > I really do not understand why so many upstreams are still using autotools. Because ItWorks(tm) A build system that fails so badly at backwards compatibility (This is not > the first time autoconf has changed incompatibly!) is just a pain for > everybody. "Even in perfect language it is possible to write bad/buggy code". Here is my latest example (only few days old) that proves that this theorem/statement still holds against all odds ;) https://github.com/ofiwg/libfabric/issues/6614 Issue is that sometimes people really don't want (first) to understand how to use the exact tool (it starts from something like "I'm not going to read anything because I want to just use it!!") or look at some already working examples (those cases are even worse :)). Those people prefer to discover how to use it without reading even a single line of necessary documentation. I know that .. because I'm one of those and here probably you can find much more such people :P That behaviour happens all the time and is older than our technical civilisation :) Better .. thanks to those "brave" people, some of them are able to invent something completely new (because of the "traumatic" experience of using something without learning it). Funny (and scarry) thing is that sometimes those new tools are better than old one :o) (most of the time are even worse like scon or waf) In other words it is hard to blame for that anyone here because from exact angle even something so bad objectively is not 100% bad because time to time *that pushes forward The Progress* :P There are alternatives (such as CMake) that handle backwards > compatibility in a much more graceful way. (In fact, the most incompatible > CMake-related change so far was actually a change in the %cmake RPM macros > and not in upstream CMake.) But autoconf still releases breaking updates. > IMO cmake is one tf he worst recent build tooling because it does not introduce good standards of some well known operations and only that opens widely all gates for sometimes freakishly implementations of doing NormalThings(tm). Working on sometimes a few hundreds packages each month most of the problems on which I'm able accidentally stump are related to cmake than probably equally to ac/am/lt and meson. And yes .. some people already started inventing OwnWays(tm) using meson 8-) And not only the new autoconf breaks updates of other packages. That is an immanent feature of all new versions of all software which interact with other software :P Nevertheless above part is completely off-topic from the subject introduction of the ac 2.71 in Fedora. I can only repeat that instead of conserving current state and swiping some issues under the carpet by introduction of compat-autoconf-2.69 to deal with only a handful of packages with some ac 2.71 issues it would be better to form a list of those packages. Because the new f35 cycle just started now is the best moment to expose and sort out all those issues. Again: IMO in a few days it is possible to properly identify all those problematic packages by performing test builds with redefined over command line single macro on all packages with "%configure" used in the spec file. In this case we are talking about testing ~3.7k packages of all ~21.7k Fedora packages. After fixing all those issues it will be possible to close the coffin with autoconf-2.69 and at least in f35 will have one package less .. And at the end I would like only gently recall that still it is yet another (sub)subject of even older autoconf still used by firefox & co :P Who wants to grind that? :P kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Wed, 10 Mar 2021 at 09:28, Ondrej Dubaj wrote: > Hello, > > Thank you for your suggestions, but as you might understand, I do not have > the capacity to resolve problems of dependent packages when building with > autoconf-2.71. > As I wrote so far I found only two packages which are not ac 2.71 compliant which I've not been able to fix by adding a simple patch. IMO fixing found issues before f35 dev cycle is doable and can be finished without strain on anyone's capacity. In most of the cases people are not solving some issues because they don't know that actually it is some issue. In other words only pointing to/encircling the issues sometimes (IMO) it is +95% of success that issue will be solved quickly. it is another issue with Fedora that detecting such issues on massive scale could be a bit tricky because for some reasons instead fixing libtool and automake with explicit calling "autoreconf -fiv" before %configure JFDI/JFDIN approach has been chosen to fiddle in some ac/am/lt files. You can see that JFDI on https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_191 However by building all fedora packages only to check is package X still building or not by executing something like "rpmbuild -bc -D "_configure `autoreconf -fiv; configure' .spec" should be possible to probe probably +~98% cases when autoconf 2.71 may fail. .. ~+98% because in some cases %configure macro is used in spec file and in reality autoconf is not used in the exact source tree or because in some spec files %_configure macro is redefined and above commandline redefinition may collide with that. Such experiments can be done on copr builders. Probably similar experiments on the scale of all fedora packages are already done probably more than one time each month. So as you may already see *diagnosing *which Fedora packages are not ac 2.71 compliant it is *not *beyond anyone capacity .. because checking the whole distro against ac 2.71 effectively can be done by executing a single oneliner. At least after such a diag test build the exact list of problematic packages can be formed. Such list published will put enough/gentle pressure on exact source trees maintainer to fix such issues ASAP :P Those two packages which I've mention (gettext and openldap) I found by testing so far below number of packages: [tkloczko@barrel SPECS]$ grep "^autoreconf -fiv" *spec | wc -l 862 Initially there were more than two failing packages however only those two (gettext and openldap) did not end up with submitting MR/PR (in a few cases in the meantime new versions with merged fixes have been released). And yet another side comment. Necessary fix for ac 2.71 only if correctly done definitely will not break using source tree with ac 2.69. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
On Tue, 9 Mar 2021 at 06:57, Ondrej Dubaj wrote: > If any concerns about the autoconf2.69-2.69 compat package ? If needed it > can be implemented as non-parallelly instalable, > Really .. instead wasting time on packaging stuff which is ~7 years old it would be better to use that time to fix one of those handful packages which are still not ac 2.71 compliant (like openldap https://bugs.openldap.org/show_bug.cgi?id=9485). Listing all those failing packages + posting URL from where is possible to upload ac 2.71 package would allow more people to work on those few remaining packages which still needs to be cleaned/updated. Otherwise some stuff will end up like the firefox, mozjs, nss, nspr packages which still are using even older autoconf :/ (which is in own sense ridiculous that one of the most actively maintained source trees still is using so old build tooling) Some time ago gcc, binutils IIRC received an update for ac 2.71 so at least those two should be by now off-the-table (Am I right?). In many cases executing "autoupdate", adding patch out of the changes generated by that command to spec and submitting PR/MR against the original source tree is all what needs to be done. This is not rocket science .. So .. anyone knows any other packages dist sources trees on which something like "autoreconf -fiv" fails? So far I found only two like that: openldap and gettext (in that case most of the issues are caused by using gnulib which is another swampy area). It is still plenty of time before the f35 cycle needs to be finished, and still it can be done RightWay(tm) .. no rush. For now posting ~óne time a week with updates about progress on wiping out ac 2.69 should allow IMO final upgrade autoconf to 2.71 relatively soon. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
glibc redefines SIGSTKSZ and MINSTKSZ (Re: pagure pushed to stress-ng (rawhide). "Fix build with glibc 2.34 (..more)")
On Thu, 25 Feb 2021 at 10:52, wrote: > Notification time stamped 2021-02-25 10:17:40 UTC > > From a9bc8b5947d10f13996e6e5d7280e5860473bbd4 Mon Sep 17 00:00:00 2001 > From: Yaakov Selkowitz > Date: Feb 25 2021 03:05:37 + > Subject: Fix build with glibc 2.34 > > > https://github.com/ColinIanKing/stress-ng/issues/107 > > --- > > diff --git a/stress-ng-0.12.03-sigstksz.patch > b/stress-ng-0.12.03-sigstksz.patch > new file mode 100644 > index 000..b05c935 > --- /dev/null > +++ b/stress-ng-0.12.03-sigstksz.patch > @@ -0,0 +1,661 @@ > +From 7c4f74761089177127c2cfe6685b7886aa231885 Mon Sep 17 00:00:00 2001 > +From: Colin Ian King > +Date: Thu, 25 Feb 2021 00:33:17 + > +Subject: [PATCH] stack handling: use _SC_SIGSTKSZ and _SC_MINSIGSTKSZ > + > +New versions of glibc will define SIGSTKSZ and MINSTKSZ > +on the sysconf values for _SC_SIGSTKSZ and _SC_MINSIGSTKSZ > +respectively. Define two helper functions to determine the > +stack sizes by trying to use cached sysconf values, fetching > +and caching the sysconf values or falling back to the > +traditional SIGSTKSZ or MINSTKSZ defined values, or hard > +coded 8K limits if all else fails. > + > +Define STRESS_SIGSTKSZ and STRESS_MINSTKSZ that call the > +helper functions and hide the details. Since these sizes > +are dynamic, replace all statically allocated and stack > +allocated alternative stacks with mmap'd versions and add > +in allocation failure error handling. > + > +Finally remove the MLOCKED_DATA macros now that the mlocked > +alt stacks are no longer used. > + > +Signed-off-by: Colin Ian King > +--- > + core-helper.c | 85 +-- > + stress-bad-altstack.c | 39 ++-- > + stress-context.c | 19 +++--- > + stress-ng.c | 3 -- > + stress-ng.h | 10 - > + stress-rlimit.c | 15 +++- > + stress-stack.c| 18 - > + stress-stackmmap.c| 70 --- > + stress-vforkmany.c| 14 +-- > + 9 files changed, 180 insertions(+), 93 deletions(-) > Hmm .. looks like there will probably be mny packages affected by this issue because of the recent glibc changes. The same is with ocaml https://github.com/ocaml/ocaml/issues/10250 Is it not kind of a mistake in case of glibc to introduce such changes? (just asking to only have confirmation that it was not actual mistake and not to start another flame) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Paralel dependencyj (Re: kalev pushed to gnome-shell (master). "Add missing pipewire-gstreamer dependency for screen recorder (..more)")
On Wed, 9 Sep 2020 at 19:47, wrote:
> @@ -90,6 +90,8 @@ Requires: gnome-desktop3%{?_isa} >=
> %{gnome_desktop_version}
> Requires: glib2%{?_isa} >= %{glib2_version}
> Requires: gsettings-desktop-schemas%{?_isa} >=
> %{gsettings_desktop_schemas_version}
> Requires: gstreamer1%{?_isa} >= %{gstreamer_version}
> +# needed for screen recorder
> +Requires: pipewire-gstreamer%{?_isa}
> # needed for schemas
> Requires: at-spi2-atk%{?_isa}
> # needed for on-screen keyboard
> @@ -212,6 +214,9 @@ desktop-file-validate
> %{buildroot}%{_datadir}/applications/evolution-calendar.de
> %{_mandir}/man1/gnome-shell.1*
>
> %changelog
> +* Wed Sep 09 2020 Kalev Lember - 3.37.92-4
> +- Add missing pipewire-gstreamer dependency for screen recorder
> +
> * Sun Sep 06 2020 Florian Müllner - 3.37.92-1
> - Update to 3.37.92
>
What is the point to add yet another fixed dependency in gnome-shell
instead *just .. *remove separation between piperwite and
piperwire-gstreamer? Isn't it?
That separation in piiperwire seems now to be causing only some other
ripples of the manually added dependencies like that one樂
KISS .. please
I'm almost sure that I saw at least a few more similar connections in the
last couple of years. Someone should start looking for that kind of
duplicated dependency by just analysing the network/graph of those
dependencies. All that needs to be processed are only those added by
static/fixed *Requires* token.
Probably it would be even possible to use some (already existing) software
to perform such analysis automatically.
The first similar package which comes to my mind with that kind of ODS
("oversubpackaking disorder syndrome") is udisk2 but there are much more
like udisk2 one in Fedora.
(Probably it would be better to name/classify that kind of dependency as
"parallel dependency")
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Fri, 24 Jul 2020 at 21:31, Igor Raits wrote: [..] > Well, I tell what I see :) > > Compiling kitty with settings below produces this big > /usr/lib64/kitty/kitty/fast_data_types.so: > > * Without any LTO-related flags: 4.52 MB > * With -flto: 4.30 MB > * With -flto -ffat-lto-objects: 4.79 MB > > Well, I did not run compilation multiple times but don't think it will > change much. > Comparing the size of the executable files does not make any sense. You should use the "size" command. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ 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: LTO and F33
On Tue, 18 Aug 2020 at 16:12, Jeff Law wrote: [..] > My focus is now turning to the packages with LTO opt-outs. I'll be > extracting > bug reports for upstream (primarily GCC), trying simple workarounds for > old style > symbol versioning, identifying backports from upstream GCC that allow us to > remove LTO opt-outs and the like. So there should be a trickle of opt-outs > removed, but otherwise should largely be invisible to the F33 release > process. > Do you have a current list of packages which are failing because of LTO? (My question is not about those packages which have already applied LTO disable) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default status updates, 2020-07-26
On Tue, 28 Jul 2020 at 13:22, Lennart Poettering wrote: [..] > > Looks like all other pseudo filesystems are mounted over .mount units > with > > probably one exception .. binfmt_misc. > > Probably .. because as I've pointed there are two units for that fs. > > Only binfmt_misc is typically a kernel module of its own. For stuff > that is built-in it's pointless trying to avoid module loading. > https://www.investopedia.com/terms/d/death-1000-cuts.asp Alternatively it is possible to use here KISS or Okhan Razor. If in case of things like full scale distribution you don't care about details sooner or later bad things will start. I'm not talking about modularisation of the binfmt_misc (which IIRC is possible to compile as the module). I'm talking about currently compiled into the kernel autofs support (and building it as the loadable module). In this case it looks like already mounting binfmt_misc over the existing (dist) .mount unit is in place. And going back to the original question. Why not provide the kernel with all possible to use file systems which are possible to use as root fs as modules? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default status updates, 2020-07-26
On Tue, 28 Jul 2020 at 11:11, Lennart Poettering wrote: [..] > > Why is it still automonter hardcoded into the kernel even if it is > > completely useless on a typical single workstation? > > binfmt_misc is mounted with that by default. > > And systemd will mount the ESP and the boot loader partition with the > automounter by default, so that it's only mounted on access and > quickly unmounted again afterwards, to ensure it stays in a clean > state whenever possible. (This logic is turned off if these mounts are > explicitly listed in fstab tough, unfortunately fedora does that). > So .. someone knows why it cannot be mounted on "mount -a" when entry for binfmt_misc would be in fstab or even over .mount unit? $ rpm -ql systemd | grep proc-sys; echo; systemctl status proc-sys-fs-binfmt_misc.mount proc-sys-fs-binfmt_misc.mount/usr/lib/systemd/system/proc-sys-fs-binfmt_misc.automount /usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount /usr/lib/systemd/system/sysinit.target.wants/proc-sys-fs-binfmt_misc.automount ● proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System Loaded: loaded (/proc/self/mountinfo; disabled; vendor preset: disabled) Active: active (mounted) since Thu 2020-07-23 18:36:17 BST; 4 days ago TriggeredBy: ● proc-sys-fs-binfmt_misc.automount Where: /proc/sys/fs/binfmt_misc What: binfmt_misc Docs: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Tasks: 0 (limit: 154244) Memory: 188.0K CPU: 12ms CGroup: /system.slice/proc-sys-fs-binfmt_misc.mount ● proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System Loaded: loaded (/proc/self/mountinfo; disabled; vendor preset: disabled) Active: active (mounted) since Thu 2020-07-23 18:36:17 BST; 4 days ago TriggeredBy: ● proc-sys-fs-binfmt_misc.automount Where: /proc/sys/fs/binfmt_misc What: binfmt_misc Docs: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Tasks: 0 (limit: 154244) Memory: 188.0K CPU: 12ms CGroup: /system.slice/proc-sys-fs-binfmt_misc.mount Probably .. because as you see there are two units for binfmt_misc. One is just a static/regular .mount unit and the second one which is using autofs. IMO using automounter to mount sysfs, procfs and binfmt_misc is really OVERKILL. If the regular unit works flawlessly it looks like systemd could be compiled without autofs. For example mqueue is mounted over .mount unit $ cat /usr/lib/systemd/system/dev-mqueue.mount | grep -v \# [Unit] Description=POSIX Message Queue File System Documentation=man:mq_overview(7) Documentation= https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems DefaultDependencies=no Before=sysinit.target ConditionPathExists=/proc/sys/fs/mqueue ConditionCapability=CAP_SYS_ADMIN [Mount] What=mqueue Where=/dev/mqueue Type=mqueue Options=nosuid,nodev,noexec Looks like all other pseudo filesystems are mounted over .mount units with probably one exception .. binfmt_misc. Probably .. because as I've pointed there are two units for that fs. $ rpm -ql systemd | grep \\.mount$ /usr/lib/systemd/system/dev-hugepages.mount /usr/lib/systemd/system/dev-mqueue.mount /usr/lib/systemd/system/local-fs.target.wants/tmp.mount /usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount /usr/lib/systemd/system/sys-fs-fuse-connections.mount /usr/lib/systemd/system/sys-kernel-config.mount /usr/lib/systemd/system/sys-kernel-debug.mount /usr/lib/systemd/system/sys-kernel-tracing.mount /usr/lib/systemd/system/sysinit.target.wants/dev-hugepages.mount /usr/lib/systemd/system/sysinit.target.wants/dev-mqueue.mount /usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount /usr/lib/systemd/system/sysinit.target.wants/sys-kernel-config.mount /usr/lib/systemd/system/sysinit.target.wants/sys-kernel-debug.mount /usr/lib/systemd/system/sysinit.target.wants/sys-kernel-tracing.mount /usr/lib/systemd/system/tmp.mount kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
systemd autofs support (Was: Re: Btrfs by default status updates, 2020-07-26)
On Mon, 27 Jul 2020 at 20:05, Zbigniew Jędrzejewski-Szmek wrote: [..] > > So (a bit off-topic) what was wrong with autofs as a separate small > process > > started only when it was necessary? Do you remember that? > > Having automount support directly in pid1 allows automounts to be part > of the unit graph — with dependencies and triggering and failure actions. > The code to talk to the kernel interface is rather simple. The part > to tie into the rest of the unit framework is bigger. Having a separate > daemon would only make that bigger part even more complicated. > Still it does not explain why automonting cannot be just a regular unit with a separated process. That way it still can be part of the "the unit graph", and both systemd units and SMF services are using dependencies. As communication with kennel space is done over /de/autofs and just checked and autofs and systemd are using that interface almost the same way. At the moment it seems that the autofs bit is used only to mout per logged user tmpfs which looks like it could be mounted/umounted using the user systemd unit WITHOUT automounter. Am I right? If yes, using the automonter is kind of overkill because all that could be done without autofs. Instead have in kernel autofs and in userspace communication over /dev/autofs thi could be done with a top 0.5KB systemd unit yext file which will execute mount/umount commands with some exact params. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default status updates, 2020-07-26
On Mon, 27 Jul 2020 at 18:35, Zbigniew Jędrzejewski-Szmek wrote: [..] > > Why the heck dist kernel cannot be without ANY fs support? I've been > using > > such a kernel (sic!) 15y ago !!! > > Tomasz, > take a step back... This is just a kernel config change, no reason to > get angry. > > > Why is it still automonter hardcoded into the kernel even if it is > > completely useless on a typical single workstation? > It is used by systemd for various less-frequently used mount points > and automount entries can be configured in /etc/fstab. > Really? (my jaw is on the floor crashed into the pieces) I must honestly confess that in the meantime systemd swallowed autofs as well! So (a bit off-topic) what was wrong with autofs as a separate small process started only when it was necessary? Do you remember that? Because with some bits of the autofs user space process in systemd when someone would be using automonter maps loaded over LDAP (going over glibc NSS layer) it will be some redundancy between those parts. PS. I think that now I have the proper impuls/reason to port SMF to Linux. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default status updates, 2020-07-26
On Mon, 27 Jul 2020 at 18:00, Chris Murphy wrote: [..] > + btrfs driver is now built-in to the kernel, rather than as a module > Classic .. from frying pan to open fire. Why the heck dist kernel cannot be without ANY fs support? I've been using such a kernel (sic!) 15y ago !!! Why is it still automonter hardcoded into the kernel even if it is completely useless on a typical single workstation? (which is still probably most of the cases when Fedora is used now). Currently dracut can generate initrd with loading correct root fs module and even block layer (nvme/sata) or network layer network card module if boot is done with loading by grub kernel and initrd over network on using NFS on root fs. Why do people who choose other FSess like xfs or ext4 or even f2fs for some embedded systems are forced to have wasted available small memory footprint by things which can be loaded as modules on demand? Only because with such a kernel it could not be possible to say that Fedora is supporting btrfs as default fs? (and buy this it would make all those talks about default fs obsolete?). Why Fedora cannot have only btrfs as default *proposed by anaconda/kickstart* FS? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, 26 Jun 2020 at 23:21, Alex Thomas wrote: > Once question, are we looking at using a layout like openSUSE is > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or > are we looking at something like > > /boot/efi > EFI (FAT32) > / > btrfs > BTW that layout. Anaconda still does not allow installing something like that because it does not allow /boot on btrfs (technically there is no any reasons to demand that and /boot can be just subvolume on the root btrfs pool). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants
On Fri, 26 Jun 2020 at 16:05, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: [..] > I'm strongly against this proposal. BTRFS is the most unstable file > system I ever seen. I would be really interested how you came to that conclusion (how did you measure that?). Do you have any metrics data which shows Linux filesystems stability? Does anyone know any source of some data which could be used to put all Linux filesystems on some stability ruler? Maybe some FS crash statistics taken from systems working on the same/similar HW in some DCs? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros
On Fri, 19 Jun 2020 at 22:20, Ben Cotton wrote: [..] > The %make_build macro enables parallel make builds using the -j option. > In case a package does not build correctly with parallel make, then > parallel make will be disabled for that package by redefining the > %_smp_mflags macro like this: > > %global _smp_mflags -j1 > Sometimes only %build or %install or %check is failing. Any -j1 tweaks should be *only temporary* so IMO formalising this kind of changes is pointless. All parallel build issues should be treated *as critical bugs* which should be *ASAP fixed*. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past
On Tue, 16 Jun 2020 at 14:09, Zdenek Dohnal wrote: > Hi all, > > I'm HPLIP maintainer in Fedora and I would like to ask *the users which > have HP printers which needed their HP plugin to test the scratch build* > of new hplip. > > HPLIP released a new version 3.20.6, where most models, which previously > required HP plugin, were set to do not require plugin anymore. > > Although requirement of HP plugin was questionable with some printer > models, other models may really needed it and they will not work without it. > > Please try the following scratch builds: > > Rawhide: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790790 > > F32: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790902 > > F31: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=45790908 > > And if the update breaks printing or scanning for you, please let the > upstream know here: > > https://bugs.launchpad.net/hplip > Zdenek have kind of question: why there are so many patches in the hplip package? Is it any problem with accepting Fedora patches by source tree maintainer? Is there any git or other VCS repo with source tree? (I don't see it on launchpad) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The price of FHS
On Fri, 22 May 2020 at 21:07, Paul Dufresne via devel < devel@lists.fedoraproject.org> wrote: [..] > The main disadvantage of it, is making hard to have multiple active > versions of a package, because the likelihood of the multiple versions, > to have the same preferred place in the hierarchy for some files. > That has nothing to do with FHS. Only thing which needs to be prepared for that is using not overlapping locations between version by package themeselve. Working example on which you can peak: gtk2, gtk3 and gtk4. On other way of seeing this disadvantage, is the fact that in a system > using FHS, new versions of packages often break other programs... > because using FHS force you to erase the old package to put a new one in > it's place... so that programs that were dependent on the old version > cannot use the old version because it is not there anymore. > FHS has nothing to do with checking or guarantee consistency of the isntralled resources. That kind of duties are on the package management software shoulde. ++mistake > The other problem I had with NixOS, was the strange Nix syntax of > packages. "Strange" is term of "fuzzy logic". Exact values given by that type of logic on processed objects strictly depends on "reference point(s)/context". Many people (like me) do't see anything "strange" here because we are using FHS within context with which seems you are not fasmiliar :) ++mistake kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, 22 May 2020 at 12:07, Jonathan Wakely
wrote:
[..]
> Maybe you should make a proper change proposal to do this, instead of
> just being sarcastic about the work other people are doing?
>
I'm not 100% sure am I understand you correctly because I'm not sure is it
still something not clear or you are trying to push me on some exact rails
:P
1st ver of the answer:
Sorry I'm engineer not bureaucrat.
If someone do not understand what just has been written this is not my
problem (maybe it is brutal claim but it is only truth).
Yes, I'm not native English speaker and my English still is a bit clunky.
2nd:
I understand that Fedora has own bureaucracy and it (en)forces some
technical decisions by policies but all that decision should be strict
technical decision and whole bureaucracy should be done post factum after
discussion -> POC -> discussion of the POC results.
Writing policies is generally to cut off any misunderstanding on scaling
that decisions on other non-initial areas or to provide
clear justification on all not obvious "why that way?" question, and of
course keep entropy of everything on lowest possible level.
Nevertheless now we are not on any of those stages.
Simple I don't like when strict technical decisions are done because they
have been (en)forced by unproven political/strategical decisions. and what
IMO cracks in case of python says me that currently used policies at least
needs some remake.
Someone made the decision about python methodologies and because in the
past that person or people had the best set of facts in own brains they
should speak first to at least confirm that some cracks are not only
imaginary. With agreement that currently used methodologies something is
wrong ("errare humanum est perseverare diabolicum") only IMO is possible to
start new games on some rules/policies.
In cases like this it is really possible to do a lot only discussing
current state and some new possible states (by discussion I understand
conversation in which sides are using facts .. only).
If it is not obvious .. I'm already assuming that what I've described could
be wrong/bollocks/BS because some already tested (in combat) cases on areas
which I don't know/I'm not aware.
Despite that entry/top assumption what just sparked in my head looks
consistent and sound.
I'm not trying as well to challenge personally anyone.
No this is purely technical conversation and even if some wordings looks
harsh it is not absolutely the case.
kloczek
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, 22 May 2020 at 12:02, Miro Hrončok wrote: > On 22. 05. 20 12:43, Tomasz Kłoczko wrote: > > [mode=serious] > > On making transition from 3.8.x to 3.9.x all what would be necessary to > do would > > be just create compat-python3.8 package -> upgrade python.spec to 3.9 -> > monitor > > number of packages still dependent on compat-python3.8 to focus what > still needs > > to be ported/rebuild. ...snip > > This doesn't work. As long as you rebuild setuptools and other essential > packages with 3.9, the entire 3.8 stack would be useless. You would need > compat > packages for hundreds of packages to make this work. > Is that not *the* target/goal? .. make whole old stack useless/obsolete ASAP? And no you would not need that because as long as you will not remove from repository all python---.f22 packages all dependencies will be fulfilled. Remember that each package is not rebuild on entire system but on very limited one with (theoretically) necessary dependencies. With that it is possible to rebuild all packages one by one and move everything in one batch. To make that whole transition easier all what will be necessary to do is clone current repository to something like fedora-transition-python and add keep all rebuild packages in that repo and merge all that packages in one go when all will be finished. No stress or time pressure. such transition can take weeks if not months and decision about merge could be done instantly basing on only one metric which is number of packages still dependent on compat-python3.8. Than if at the and will be still some remains hard quickly to port it should be made decision about create some limited number of packages like compat-python3.8- and/or to put some of those packages on obsoletes list. With single metric decision about actual transition will be no longer in hands of anyone (as single person or comity). It will be strict technical decision based on quite well defined set of conditions hanging on that metric. If we are talking about using that methodology not only for python in some simple enough cases such decision could be done .. automatically! Basing on my already +25y exp on building rpm packages I can even bet that after some cleanups in all python related stuff it should be possible to make python major release upgrade *automatically.* Whoever would want to help on that transition will be asked to add that fedora-transition-python repository to own build systems or own personal system. Initial set of rebuilds made automatically should provide enough set of new dependencies allowing fixing one by one each package which will need manual intervention in form of some patches. Above and what I wrote in my prev email could be general methodology on making any future transition of bigger groups of packages from one major version to another one (not only python specific). All this is just like git branching but on packages with packages repositories as well. It is yet another consequence of what I've sketched. With that it would be possible to remove all python packages bootstrap bconds: [tkloczko@barrel SPECS.fedora]$ grep bootstrap python* | grep bcond python3.spec:%bcond_with bootstrap python-BTrees.spec:%bcond_with bootstrap python-dask.spec:%bcond_without bootstrap python-fsspec.spec:%bcond_without bootstrap python-pbr.spec:%bcond_with bootstrap python-setuptools.spec:%bcond_with bootstrap python-setuptools.spec:# Warning, different bootstrap meaning here, has nothing to do with our bcond python-sphinx_rtd_theme.spec:%bcond_with bootstrap python-stestr.spec:%bcond_without bootstrap python-wheel.spec:%bcond_with bootstrap python-zbase32.spec:%bcond_with bootstrap Of course to that picture needs to be added yet another small bit which is stop (the h*ll) using versioned symlinks in case tools like pytest, sphins and few other to use them *only* in compat-* packages. kloczek ___ 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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, 22 May 2020 at 10:42, Miro Hrončok wrote:
[..]
> It is just the component name. The user installable package is still
> python3.
>
I call it thing-which-should-not-exist or thing-which-shall-not-pass.
That way it is easier to pronounce
> Reasoning:
>
> Build python3, python3-libs etc. from python39 SRPM on F33+:
>
>
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/5QUN7FWI6AV7BTMQGF257BEVMEA4QFOG/
>
>
> Renaming pythonXY packages to pythonX.Y (e.g. python39 to python3.9):
>
>
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/message/VIUS7WMQMDX6H2WEIH7TVTMBB6SUHY7E/
A .. yeah 臘♂️
You are right I forgot that Fedora on making new major release instead
branching all packages stored in git still provides on master full support
for all last three version of the distribution, three EPL/RHEL and
sometimes even few version of SuSE
I must apologise: sorry looks like it is my mistake .. (mea culpa, mea
culpa, .. mea maxima culpa)
[mode=serious]
On making transition from 3.8.x to 3.9.x all what would be necessary to do
would be just create compat-python3.8 package -> upgrade python.spec to 3.9
-> monitor number of packages still dependent on compat-python3.8 to focus
what still needs to be ported/rebuild.
Because other factors the best moment to start such transition would be few
days after f32 official release and tag all git resources and just right
before first MR.
Because rawhide just after that will have in %{dist} "f33" it will be not
even necessary to do what started today (bumping all python packages
releases and committing those changes) because
-.f32 will be always lower than
-.f33.
To make all above possible all only what would be is to stop using python
packages names in Requires and BuildRequires and start using
%pythondist( similar to what is now with pkgconfig() dependencies
(nice clean and not even one new macro needs to be introduced/split on some
exact package major version release).
With above total entropy cost would be *ONLY*:
- one additional compat-python3.8 package
- redefine %pythondist macro to provide python versioned dependencies
(probably by change only version in the macro which should hold python
major version).
On top of such scheme it will be possible go back to old simpler
maintenance of the long term used systems by combing only all installed
compat-* packages .. nice, easy and clean.
pkgconfig proved that this is actually and already/perfectly working (only
adaptation still is sloppy), and I don't see literally even single reasons
why it should not work for python or gt4/kde4 vs. qt4/kde5 as well.
Isn't it?
[/mode]
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, 22 May 2020 at 10:27, Peter Pentchev wrote: [..] > > Originally was python package. Than was python python2 and python3. Now > it > > is python3.9. > > Why not is used still and just python and to provide necessary > dependencies > > during transition python3.8? > > That way as well is casing that with each python major version upgrade > all > > macros needs to be multiplied. > > Are you asking why python3.8 and python3.9 are separate packages? > No I'm not. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: [HEADS UP] Fedora 33 Python 3.9 rebuilds have started in a side tag
On Fri, 22 May 2020 at 02:17, Miro Hrončok wrote: > Hello, in order to deliver Python 3.9, we are running a coordinated > rebuild in a > side tag. > > https://fedoraproject.org/wiki/Changes/Python3.9 > [..] I'm only curious why to make transition to python 3.9 was chosen "debianised way"? Originally was python package. Than was python python2 and python3. Now it is python3.9. Why not is used still and just python and to provide necessary dependencies during transition python3.8? That way as well is casing that with each python major version upgrade all macros needs to be multiplied. All that was possible to avoid bu just unversioned packages names and unversioned python macros hiding major version transitions in macros. All that is causing that for each that many packages will needs to be specially modified to produce proper results on new python version as well instead just retesting new standard macros definition on new python and/or do couple of tweaks only ion those macros definitions and nothing more). All that it is nothing more than creating huge amount of work which needs to be done on each major version upgrade on mny packages. "Making some mistakes is not the problem but repeating them again and again really is". >From that point of view with 3rd iteration should be enough to learn some lessons because now (again) looks like it will be necessary to add many modifications across many packages with python modules .. pointless!!! Generalised build procedure with macros suppose to hide some details like versions and other. For some reasons looks like that completely stopped in case of only python IMO because some people saw how some things has been done on Debian (successfully but with way to big overhead). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Two flaws in upcoming Gnome 3.36
On Sun, 8 Mar 2020 at 14:00, Ernestas Kulik wrote:
[..]
> Are you involved with GNOME l10n? There is no need to do any of that
> with the way Damned Lies works.
No I'm not. Again this is not strict Gnome issue. This is why tooling
needs to be slightly adjusted/redesigned.
Did you ever try to check what I wrote? Seems not ..
You can do this by add in any spec file with meson build based
procedure by add in %build after "%meson_build" another line with
"%meson_build %{name}-update-po".
In case am/ac/lt based build procedures after "%make_build" you can
try to add line "%make_build -C po update-po".
In all those cases if after building package you will be able to see
that produced package size is different it will mean that distributed
.po files have *not been updated* before actual release.
Don't be surprised if you will find in few cases that final package
wit updating .po files will be slightly bigger (however in most of the
cases especially with enough long development history is possible to
see package size reductionist).
Less important is fact is will be enlargement or reduction. As long as
output after update is *different* it means that some additional work
on updating translations should be done.
Only small patches of all packages land like mate desktop packages are
with updated pot files and by this updated updating .po files does
not change final package size (but this is because mate developers
careers about that part of the development)
Nevertheless one more time: this issue is related more to tooling and
used currently methodologies so it stretches far beyond Gnome per se.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Two flaws in upcoming Gnome 3.36
On Sat, 7 Mar 2020 at 22:55, Leigh Scott wrote: [..] > > Just checked that patch and looks like still something is wrong because > > test suite is partially failing. > > > I get the same in f31 without the patch Please repeat that test running "xvfb-run -a make check" (test suite needs $DISPLAY) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Two flaws in upcoming Gnome 3.36
On Sat, 7 Mar 2020 at 21:10, Leigh Scott wrote: [..] > > Still some long term cogl nad clutter solution needs to be applied. > > > As I wrote it is now separated (staticly linked) cogl and cutter copy in > > mutter > > It isn't statically linked, they are renamed private libs. > > ldd /usr/bin/cinnamon |grep -e cogl -e clutter > libmuffin-clutter-0.so => /usr/lib64/muffin/libmuffin-clutter-0.so > (0x7f45dbcb1000) > libmuffin-cogl-pango-0.so => > /usr/lib64/muffin/libmuffin-cogl-pango-0.so (0x7f45db12) > libmuffin-cogl-path-0.so => > /usr/lib64/muffin/libmuffin-cogl-path-0.so (0x7f45daf89000) > libmuffin-cogl-0.so => /usr/lib64/muffin/libmuffin-cogl-0.so > (0x7f45dacac000) Hmm .. this potentially makes this even worse because: - it is probably 3rd copy of the cogl (standalone cogl, mutter and - mutter developer told that cogl copy is only cut to be used in mutter. If I'm right it means that private code is used by mutter over library jump table making that code slower than it could be. In all those cases looks like private copies of those libraries are used as DSOs. Just checked and looks like mutter cogl DSOs are used by gnome-shell. [tkloczko@barrel SPECS]$ objdump -x /usr/lib64/libmutter-6.so.0 | grep NEED | grep cogl NEEDED libmutter-cogl-6.so.0 [tkloczko@barrel SPECS]$ objdump -x /usr/bin/gnome-shell | grep NEED | grep cogl NEEDED libmutter-cogl-pango-6.so.0 [tkloczko@barrel SPECS]$ objdump -x /usr/bin/mutter | grep NEED | grep cogl [tkloczko@barrel SPECS]$ [tkloczko@barrel SPECS]$ rpm -qal | grep lib64/ | grep cogl | grep -v pkgconfig /usr/lib64/libcogl-pango.so.20 /usr/lib64/libcogl-pango.so.20.4.2 /usr/lib64/libcogl-path.so.20 /usr/lib64/libcogl-path.so.20.4.2 /usr/lib64/libcogl.so.20 /usr/lib64/libcogl.so.20.4.2 /usr/lib64/libcogl-pango.so /usr/lib64/libcogl-path.so /usr/lib64/libcogl.so /usr/lib64/mutter-6/libmutter-cogl-6.so /usr/lib64/mutter-6/libmutter-cogl-6.so.0 /usr/lib64/mutter-6/libmutter-cogl-6.so.0.0.0 /usr/lib64/mutter-6/libmutter-cogl-pango-6.so /usr/lib64/mutter-6/libmutter-cogl-pango-6.so.0 /usr/lib64/mutter-6/libmutter-cogl-pango-6.so.0.0.0 /usr/lib64/mutter-6/libmutter-cogl-path-6.so /usr/lib64/mutter-6/libmutter-cogl-path-6.so.0 /usr/lib64/mutter-6/libmutter-cogl-path-6.so.0.0.0 So looks like cinamon is using 3rd copy :) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Two flaws in upcoming Gnome 3.36
ok ok ok ok test_color_hsl: ok FAIL ok ok ok test_fence: ok ok ok ok ok test_texture_no_allocate: ok ok ok FAIL ok test_texture_rg: FAIL ok ok ok ok make[4]: *** [Makefile:1943: test] Error 139 ``` kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Two flaws in upcoming Gnome 3.36
On Sat, 7 Mar 2020 at 18:35, Leigh Scott wrote: > Fixed https://bodhi.fedoraproject.org/updates/FEDORA-2020-bcd6554797 Thx. However as I wrote that is only short term solution. Still some long term cogl nad clutter solution needs to be applied. As I wrote it is now separated (staticly linked) cogl and cutter copy in mutter and looks like those two components development is not well coordinated. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Two flaws in upcoming Gnome 3.36
Hi,
*Disclaimer*:
The main propose of this email is only to flag some issues or to form some
vectors/conclusions /necessary actions.
*1) cogl does not build*
https://koji.fedoraproject.org/koji/buildinfo?buildID=1434712
Looks like cogl library is more or less dead or at least kind of dead end.
https://gitlab.gnome.org/GNOME/cogl/
cogl is used by at least by clutter, clutter-gst, libchamplain which are
used by cheese, gnome-maps, libchamplain which are then used by
gnome-contacts, gnome-control-center, gnome-initial-setup and so on ..
I've been trying to flag this in
https://gitlab.gnome.org/GNOME/cogl/issues/11
In that ticket, it is possible to find some links to other gnome components
tickets maintainers of which I've been trying to ask about the current
situation/find a workable solution.
So far .. no useful results.
Gnome mutter has own cogl and clutter copies but seems it has been bend not
to be useful outside of the mutter.
I think that it would be good to invest some time to at least bring cogl to
cleanly building state than some desktop developers should discuss on how
to approach to cogl/clutter code from long term perspective.
*2) Almost all gnome translations are not-up-to-date.*
As long as cogl issue is related to only a few gnome components, I just
realised that this issue stretches wy beyond the gnome.
Despite huge effort of all translators around the world almost all gnome
packages have not updated/properly maintained translations :(
All because one small issue that most of the source code maintainers
literally *never* executed "make -C update-po" or in case of meson using
projects "meson -update-po" then commit all changes generated
changes to source tree to inform translators that they have something to
update.
The same is in case of gnome help files ("meson help--update-po"
target).
All this happens because all frameworks helping maintain translations are
basing only on .po files, and all translations updates are maintained
*outside* original source tree.
To update .po files new .pot file needs to be generated (which contains
generated list of untranslated strings to translate) then combining .po and
.pot file new/updated .po file is generated adding new strings or
commenting out all those entries which need to be updated.
More or less current result of above is that almost all projects which have
.mo files after call during build *update-po targets are .. **SMALLER**!!
All this because i most of the cases many strings which are no longer used
in current code version are still in .po files, and they are populated to
end packages .mo files.
When I found the above I've been thinking for a quite long time was only:
**How to solve this class of issue with minimum effort?**
(Because this issue is affecting now thousands of projects .. not only
gnome one).
After many months have yellow post-it card note on the back of my skull I
think that that I have kind of idea what to change/heal this not-so-good
situation instantly with that minimum effort.
That is about "what?" or identification of the issue.
So now next question is only "how?".
*** I think that meson, gettext and cmake need to be changed. ***
*Explanation:*
Part of the execution of the meson "dist" or in case automake "dist" or/and
"distcheck" targets should be IMO calling meson "*-update-po" and automake
"make -C po update-po" bits.
With that whoever will be doing code release will have in VCS trees
modified file which should be committed.
Similar changes it would be good to apply as well for cmake i18n support.
In case of automake/autoconf all files which needs to be updated art part
of the gettext.
With that relatively smalll set changes, I think that chances to have 100%
up-to-date translations in any projects will grow dramatically.
When I've been working on shadow source tree usually few days before actual
release, I've been commuting all .po files updates and sending kind of
broadcast message to all translators to have a look on all current .po
files and send me updates.
I think that something like this should be part of the open-source
development cycle methodology/habits.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
On Sat, 21 Dec 2019 at 00:37, Neal Gompa wrote: [..] > I believe it's also used by the %cmake and %meson macros. Yep. Look on the output of the “rpm -E %cmake” and you will find that to switch to other C and C++ compilers all what you need to do is redefine %__cc and %__cxx macros, The same is with %configure and %meson, In other words you can switch NOW from non-root account to other compiler without execution update-alternatives from root. In other words this proposal is pointless. kloczek -- -- Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* ___ 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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
On Tue, 8 Oct 2019 at 17:15, Nikola Forró wrote: > On Tue, 2019-10-08 at 12:22 +0200, Jindrich Novy wrote: > > Nikola, is it intended that aspell doesn't depend on any dictionary? > > E.g. aspell-en? Please see the email bellow. > > Hi, > > it seems it is intentional [1], this is probably the reason [2]. > I suppose aspell could recommend aspell-en, to prevent circular > dependency (assuming weak dependencies actually do prevent it). > > Thanks, > Nikola > > [1] > https://src.fedoraproject.org/rpms/aspell/c/405c4df7ef4bcd93103c57e3e910e2f82a045c24 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=485210 It is very easy to fix this by merge build of the aspell and aspell-en. Build processes should not be affecting how final packages should be used and in this case it is like this. Someone choose that clean build is more important than dependencies between those packages. To be honest IMO separating aspell dictionaries is a bit illogical because on distribution layer language dependent resources should be described by %lang() and chosen on install stage by %_install_langs. Ergo: all "langpack" (like aspell-* of Libreoffice- or firefox-* etc) packages should disappear. As long as rpm packages exist only in form of solid archives it is not possible precisely choose to download only resources which does not depends on any %lang() + those which depends on set of languages listed in %_install_langs. This is why IPS has concept of facets and because package exist only as set of files with attributes in IPS repository, by this repository can stream to client (where packages will be installed) *only* that files which have been requested but not on boundaries of the packages existing on build stage. This is one of the biggest weakness of the rpm or more precisely any PM software which uses packages as archives. Nevertheless problem still is not correctly described. To be more precise aspell does not need aspell-en but any dictionary which is needed by current local settings (system one or user one or even user session one). *If I'll be using for example locale pl_PL and will have installed aspell-en mcedit still will be barking that about missing dictionary!!!* In other words .. aspell should not require aspel-en but at least one/some dictionary package. Nevertheless in current state of the rpm adding dependencies which depends on *current locale settings* is unsolvable by definition. All what is possible to do is provide GoodEnouhg(tm) solution. IMO above shows clearly that adding "aspell-en" in mc or aspell dependencies does not solve issue .. at all. Kind of mitigation of that problem should be IMO change aspell error message (by add Fedora/any rpm based distro patch) informing that system has missing aspell- package. Workaround 1: add in aspell "%bcond_with bootstrap" and when package will be build "--with boostrap" disable "Requires: aspell-en". aspell used as only as aspell-devel will not break any other packages builds. Workaround 2: add in each aspell- "Provides: aspell-dictionary" and in aspell "Requires: aspell-dictionary". With that aspell-en can be build as long will have stored any aspell- package. Conclusion: for me still it is clear that mc should stay untouched and any other steps should be done outside of the mc package. PS. BTW anaconda/kickstart still does not setup /etc/rpm/macro file with %_install_langs with list of choose languages support. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: psutter pushed to iproute (master). "iproute-5.3.0-2 (..more)"
Hi,
On Tue, 8 Oct 2019 at 12:58, wrote:
> Notification time stamped 2019-10-08 11:54:56 UTC
>
> From 26d638db91fa316f706ea947ab076bce216ec8cc Mon Sep 17 00:00:00 2001
> From: Phil Sutter
> Date: Oct 08 2019 11:51:27 +
> Subject: iproute-5.3.0-2
>
>
> - ifcfg script uses killall, therefore requires psmisc package
>
IMO that fix is fundamentally wrong.
Instead using killall it should be used systemd to reload service
("systenctrl reload rdisc").
Why? In case of using LXC or other containerisation ifcfg which will be
using killal and used from global zone/namespace will cause to reload
all rdisc (those running in containers as well).
Next is that rdisc is part of the iputils which is not listed in list of
iproure dependencies (I'm not sure is it correct to add that dependency but
seems it is legit).
Other thing is that ifcfg script is bash dependent because
$ grep -w local /usr/sbin/ifcfg
local sbase fwd
local class;
Those two lines can be removed without harming anything to make that script
full POSIX sh compliant (and still working correctly with bash as
/usr/bin/sh).
BTW. Looks like no one in Fedora have been looking on all cases like above
to have proper separation between zones/container/namespaces.
kloczek
___
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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
On Mon, 7 Oct 2019 at 15:30, Jindrich Novy wrote:
[..]
> BTW mc.
>> Also I do not understand why FC31 release comity ignored my objection to
>> push mc 4.8.23 to fc31 since it core dumps sometimes few times per hour of
>> active use.
>>
>
> You commented on the F29 update (not F31) here:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3e2bc7747 and failed
> to reply to my comment.
>
I did not receive any notification about that comment.
> > now we have pollution of the mc static dependencies by add aspell-en.
> > mc does not need aspell-en but aspell does because aspell to work
> properly needs at least
> > some dictionary.
>
> Adding Requires of aspell-en fixes this:
>
> https://antonishapsas.wordpress.com/2019/01/18/midnight-commander-no-word-lists-can-be-found-for-the-language-en/
>
Again .. where never aspell is used without installed dictionary it will
fail (not only in mc).
This is not mc bu aspell issue.
Please d knot try to fix the issue (real issue) in wrong package.
[tkloczko@domek ~]$ rpm -q --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags}
%{REQUIREVERSION}\n]" aspell
/usr/bin/sh
libaspell.so.15()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libm.so.6(GLIBC_2.29)(64bit)
libncursesw.so.6()(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(CXXABI_1.3.9)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libtinfo.so.6()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
rtld(GNU_HASH)
As you see current aspell does not requires installing any dictionaries and
this is causing that mc barks about missing dictionary.
kloczek
___
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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
On Mon, 7 Oct 2019 at 13:28, Jindrich Novy wrote:
> Hi Tomasz,
>
> > On top of removing perl-generators which add for mc proper perl modules
> dependencies for
> > patchfs
>
> Can you please elaborate on the above? patchfs works for me despite
> missing perl-generators? This is not raised by me but the following request
> from an user:
> -
> Hi Jindrich,
>
> I did a minimal install of CentOS 8 with mc and saw that it pulls in perl
> due to (I guess) BuildRequires: perl-generators in the spec file. I
> looked at mc upstream and they do not list perl as a requirement:
> https://github.com/MidnightCommander/mc/blob/master/doc/INSTALL
>
> Did I miss something or is perl no more needed? I'd be happy to file a
> BZ, just let me know.
>
$ rpm -q --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags}
%{REQUIREVERSION}\n]" mc | grep perl
/usr/bin/perl
perl(File::Basename)
perl(File::Temp)
perl(POSIX)
perl(bytes)
perl(strict)
For generating those perl dependencies is responsible per-generators
package which you've removed from BRs.
$ grep ^use /usr/libexec/mc/extfs.d/*
/usr/libexec/mc/extfs.d/mailfs:use bytes;
/usr/libexec/mc/extfs.d/patchfs:use bytes;
/usr/libexec/mc/extfs.d/patchfs:use strict;
/usr/libexec/mc/extfs.d/patchfs:use POSIX;
/usr/libexec/mc/extfs.d/patchfs:use File::Temp 'tempfile';
/usr/libexec/mc/extfs.d/uzip:use POSIX;
/usr/libexec/mc/extfs.d/uzip:use File::Basename;
/usr/libexec/mc/extfs.d/uzip:use strict;
$ rpm -q --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags}
%{REQUIREVERSION}\n]" mc | grep perl | xargs rpm -q --whatprovides
perl-interpreter-5.30.0-446.fc32.x86_64
perl-interpreter-5.30.0-446.fc32.x86_64
perl-File-Temp-0.230.900-439.fc31.noarch
perl-interpreter-5.30.0-446.fc32.x86_64
perl-interpreter-5.30.0-446.fc32.x86_64
perl-libs-5.30.0-446.fc32.x86_64
Without installed perl(File::Temp) perl module when someone will enter into
patch to use patchfs it will be be not working.
If you want to fix that you should try to rewrite patchfs perl backend
script in POSIX sh.
I'm almost sure that using perl in patchfs or zipfs is obverkill.
As well rpmfs is written is perl (many years ago when I've rewrote rpmfs
scrip it was using only POSIX sh with rpm as only external command ..
however in meantime someone made here some "progress").
Next time instead using you proven packager privileges at least please try
to contact someone who actively is maintaining some package.
You last two commits should be rolled back.
BTW mc.
Also I do not understand why FC31 release comity ignored my objection to
push mc 4.8.23 to fc31 since it core dumps sometimes few times per hour of
active use.
>From end user point of view difference between mc 4.8.22 and 4.8.23 are
negligible.
I have opened ticket with that issue
http://midnight-commander.org/ticket/4023
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: jnovy pushed to mc (master). "- just keep perl-interpreter BR because of man2hlp, (..more)"
On Mon, 7 Oct 2019 at 12:04, wrote:
> Notification time stamped 2019-10-07 11:04:36 UTC
>
> From c0792d465daa3db808d63086a1524e786b213fe2 Mon Sep 17 00:00:00 2001
> From: Jindrich Novy
> Date: Oct 07 2019 11:04:05 +
> Subject: - just keep perl-interpreter BR because of man2hlp,
>
> it is a perl script required by build
> - require aspell-en, otherwise an annoying error prompt
> is displayed while editing any file
>
> ---
>
> diff --git a/mc.spec b/mc.spec
> index a800397..40dada6 100644
> --- a/mc.spec
> +++ b/mc.spec
> @@ -4,7 +4,7 @@ Summary:User-friendly text console file manager
> and visual shell
> Name: mc
> Epoch: 1
> Version: 4.8.23
> -Release: 4%{?dist}
> +Release: 5%{?dist}
> License: GPLv3+
> URL: http://www.midnight-commander.org/
> Source0:
> http://www.midnight-commander.org/downloads/mc-%{version}.tar.xz
> @@ -22,6 +22,8 @@ BuildRequires:groff-base
> BuildRequires: libssh2-devel >= 1.2.5
> BuildRequires: %{?with_slang:slang-devel}%{!?with_slang:ncurses-devel}
> BuildRequires: pkgconfig
> +BuildRequires: perl-interpreter
> +Requires: aspell-en
> Suggests: mc-python
>
On top of removing perl-generators which add for mc proper perl modules
dependencies for patchfs now we have pollution of the mc static
dependencies by add aspell-en.
mc does not need aspell-en but aspell does because aspell to work properly
needs at least some dictionary.
Jindrich please rollback your last two commits.
kloczek
___
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 builds failing with "GenericError: Build already in progress (task …)"
On Sun, 29 Sep 2019 at 14:11, Zbigniew Jędrzejewski-Szmek wrote: > I have seen this a few times lately. When a build is started for > rawhide, and in succession builds for other branches, they fail. > > Example: > https://koji.fedoraproject.org/koji/taskinfo?taskID=37938969 (build > target: rawhide) > https://koji.fedoraproject.org/koji/taskinfo?taskID=37938975 (build > target: f31-candidate, > fails with GenericError: Build already in progress (task 37938969)) > > Trying the rebuild again succeeds. > > Known issue? > Yesterday I've hit the same issue trying to repeat the build mc without bumping release after small cleanup in git. All what you need to do is execute "fedpkg build --scratch". kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: systemd-243-rc1
On Wed, 31 Jul 2019 at 13:25, Lennart Poettering wrote: > On Mi, 31.07.19 12:57, Tomasz Kłoczko (kloczko.tom...@gmail.com) wrote: > > > As usually that type of versioning convention is rubbish and it only adds > > more work on packaging layer. > > Why you guys did not released that as v243.99 ? > > I like my bikesheds blue. > Yes. Today is a bit sunny in London. Thanks for asking .. and ignoring that rc versioning convention adds some overhead on packaging layer. Your bikeshed argument is really powerful so I can only give up. > Other thing is that looks like systemd devel cycle elongated and it cased > > that some stabilisation fixes are only committed in master branch with > all > > other changes. > > > > Proposal for next systemd devel cycle: > > - create devel branch and commit all devel changes in that branch only + > > stable fixes > > - commit in master branch only stable fixes and release more ofthen > v244.1, > > v244.2 and so on (one time a month or even more often depends on > importance > > of the fixes) > > - release candidates starting from v244.99 > > - when everything in devel will be ready just merge devel branch to > master > > and tag it as new major release. > > Are you volunteering to do the work for this? Or do you just expect us > upstream to maintain twice the amount of releases? > > We don't want to be consumed in just doing release mangament. It's > hard enough, and we definitely prefer if developers focus on one > master, not many, and stop developing new stuff while we are in release > mode. This means, doing parallel branches for upstream development is > not in the cards, sorry. Either everyone stabilizes or everyone works > on new stuff. > > Note that there's a "stable" backport tree maintained outside of the > main repo: > > https://github.com/systemd/systemd-stable In other words you asking me voluntary do the job which is already done. Nice. OK, I'll take that job. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: systemd-243-rc1
On Tue, 30 Jul 2019 at 21:19, Zbigniew Jędrzejewski-Szmek wrote: > Hello everyone, > > a new pre-release of systemd was tagged today, and it's building in > rawhide now. See https://github.com/systemd/systemd/blob/v243-rc1/NEWS As usually that type of versioning convention is rubbish and it only adds more work on packaging layer. Why you guys did not released that as v243.99 ? Other thing is that looks like systemd devel cycle elongated and it cased that some stabilisation fixes are only committed in master branch with all other changes. Proposal for next systemd devel cycle: - create devel branch and commit all devel changes in that branch only + stable fixes - commit in master branch only stable fixes and release more ofthen v244.1, v244.2 and so on (one time a month or even more often depends on importance of the fixes) - release candidates starting from v244.99 - when everything in devel will be ready just merge devel branch to master and tag it as new major release. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Replacing glibc langpacks
On Mon, 27 May 2019 at 20:13, Florian Weimer wrote: [.,] > > In other words your proposition is *not* about not any kind of > > reduction size but increase size of installed resources because those > > binary files which needs to be present will be increased by source of > > those binary files. Other thing is that generating those files on > > install-time elongates install time. > > 2.9 MiB (compiled en_US.utf8 locale) plus 3.4 MiB (compressed locale > sources without charmaps) is 6.3 MiB, which is less than 6.7 MiB > (current installed glibc-langpack-en size). It should be possible to minimise this size by use proper %lang(en_US) tagging. Only this and nothing more. Nevertheless Fedora is not using rpm as it is designed .. shame but that is only cause of what is seen as the issue in this context. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Replacing glibc langpacks
On Mon, 27 May 2019 at 10:41, Florian Weimer wrote: > I'm investigating whether it makes sense to switch to a scheme where the > glibc locale data is built from source, during package installation, > based on the langpack configuration system. This is similar to what > Debian does. > > The reason is that the compressed locale source code (without the > charmaps, which are not strictly needed once we patch localedef) is > smaller than the subset of locales of a langpack package which people > actually. For example, glibc-langpack-en on Fedora 29 is 6.7 MiB when > installed, but en_US.utf8 is 2.9 MiB, and the locale sources are > 3.4 MiB, so even the common case realizes a small saving. > > For the installer, the savings might be much larger. If we can teach > anaconda to generate the appropriate locale only after the user has > selected the language, then we no longer need the full locale archive in > the installation image (and in RAM). In other words your proposition is *not* about not any kind of reduction size but increase size of installed resources because those binary files which needs to be present will be increased by source of those binary files. Other thing is that generating those files on install-time elongates install time. Remember that dpkg does not have any kind equivalent of rpm %lang() tagging in packages descriptions. In that exactly context Fedora still does not properly setups /etc/rpm/macros::%_install_langs macro and instead setting that macro during install-time provides langpack packages (which IMO is at least engendering/design mistake/misunderstanding). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 12:44, Nicolas Mailhot wrote: [..] > > Point taken. Can you shortly describe other use cases? > > You use apps in one of those languages that static build by default. > There is a security alert in one code component. You want to know which > packages in your repo/mirror have been build using the broken piece of > source code OK. Some time ago I've successfully removed all static libraries on my all build systems. Good to know that I will never have such dilemmas :o) Do you have maybe other examples of the use cases? :p kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel wrote: [..] > You're assuming the only use is roolback. It's not Point taken. Can you shortly describe other use cases? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Thu, 2 May 2019 at 20:29, Nicolas Mailhot via devel wrote: [..] > > IMO maintainer in this case is 100% right because all properties of > > the build env already can be described in with enough precision. > > Providing more details about build env will be duplicating current > > build dependencies. > > You're confusing constrains (build dependencies) with actual build env > composition (exact constrains resolution, which has been known to > change even with the same package set, just by switching dependency > resolution engines from yum to dnf to whatever). > > Build env composition information is generally useful for audits, > reproducibility, and debugging. It's useful enough to have been > reimplemented over the years in multiple places (elfutils spec, koji, > whatever). It's even more useful with the recent tendency to static > build. > > What is missing is a mecanism to record in in a generic way package- > side, so one does not have to rely on build farm logs (that may or may > not be retained over time) to access this basic info. > > Computing this info is trivial. It’s just a rpm -qa at the end of > buildrequires resolution. Accessing this info reliably, however, it not > trivial today, because the storage part has not been streamlined. As I wrote problem only is that without possibility really rollback to the full state described in set of exact N-E:V-Rs packages recorded data such auditing data in case if something starts going wrong such data could be used only as kind of murky vector where possible cause really is. It is nothing wrong with keeping only latest versions of the packages but with that assumption to have enough effectiveness of catching errors/issues needs to be added more test units fired straight after package build is done or during that process. Just look on some numbers below: [tkloczko@domek SPECS.fedora]$ grep ^%check *| wc -l; ls -1| wc -l 11692 21300 and the same stats on results of my own work: [tkloczko@domek SPECS.g2v]$ grep ^%check *| wc -l; ls -1| wc -l 426 498 Do you see where my thoughts are heading? With that only in last 3-4 months I've been able to catch maybe even few tenths of new issues just right on build packages (you can check stat of my accounts on gitlab and github to be able spot that part of my activity). I fully understand why Fedora keeps only latest versions of the packages and it is nothing wrong with that. Problems only is that if that small bit must be kind of assumption other parts around needs to be readjusted to create kind of strategy catching and dealing with new issues. And again .. with assumption that during packages development process never would be possible to fully rollback to the same N-E:V-Rs state storing build time metadata is kind of pointless (IMO). In other words reproducibility of those N-E:V-Rs metadata in case of Fedora are very close to *null*. BTW: storing all N-E:V-Rs of the *packages* could be easily solved by move away from rpm to IPS and I know that in case of the Fedora that kind of change is unrealistic. Adapting rpm to use packages repository like it is in case of IPS is unrealistic as well .. because to many things around needs to be changed (not only on packaging and distribution layer). You can observe this kind of effect on for example Sol 11.4 packages http://pkg.oracle.com/solaris/release/en/ The same web interface which immanent part of the IPS provides very long list of all version of the packages if you would be able to observe all Solaris SRUs (Service Recommended Updates) data. On Solaris 10 with IPS is possible even rollback to the state ~10 years old. Full rollback to the system state of all packages from the past is sometimes really important and this is why in OL repositories are never deleted older packages (yum/dnf repo allows keep multiple E:VRs of the same package in single repository). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Fri, 3 May 2019 at 09:46, Tomasz Kłoczko wrote: [..] > http://pkg.oracle.com/solaris/release/en/ URL correction: http://pkg.oracle.com/solaris/release/ kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Wed, 1 May 2019 at 09:04, Nicolas Mailhot wrote: [..] > > One of those specs is elfutils.spec in which is: > > > > %check > > # Record some build root versions in build.log > > uname -r; rpm -q glibc > > Funny; that’s pretty much > https://github.com/rpm-software-management/rpm/issues/607 > > that upstream does not want to acknowledge. > IMO maintainer in this case is 100% right because all properties of the build env already can be described in with enough precision. Providing more details about build env will be duplicating current build dependencies. Discussion about such cases should start from analyse of some case(s) when such details could help with some class of issues. Then someone should go to root cause that some exact failed/produced broken packages, and then (maybe) at the end some solution can be provided. All those context details are missing in that issue ticket so (IMO) rpm maintainer had no even chance understand what caused that someone started thinking about storing such metadata in src.rpm. BTW elfutils and glibc package EVR. This detail is already part of the koji root.log. https://kojipkgs.fedoraproject.org//packages/elfutils/0.176/2.fc31/data/logs/x86_64/root.log contains line: DEBUG util.py:556: glibc x86_64 2.29.9000-17.fc31 build 3.9 M Nevertheless some people forgets sometimes that spec syntax provides not only BuildRequire but BuildConflict token as well. With those two is possible with 100% accuracy describe build env properties. That is all what rpmbuild needs to provide (IMO). [tkloczko@domek SPECS.fedora]$ grep ^BuildConflict * | wc -l 38 Some packages source code build automation implements sometimes strange things. For example gawk is using libsigsegv only if autoconf is able to find it, and it is not possible to disable using it by provide configure parameter. However there is only handful of such cases and it is easier to fix those packages source code build automation than designing rpm extensions to handle such cases straight on packaging layer. Uniformity below packaging layer should be our real goal .. this why when I see that in git repos someone is using some strange tagging convention like replace dots by underscores or putting build automation deep below project root directory (examples: recently introduced meson and cmake files in lz4 and zstd) I'm always trying gently ask maintainers to change this to implement and use those bits in kind of StandardWay(tm). All because it makes packaging easier with virtually no costs on layer below. Other issue is that as Fedora keeps only last versions/releases of all packages and even if someone would be storing full list of all installed packages in build env in koji gut it will have very limited abilities to help with something as it is not possible quickly reassembly from scratch exactly the same build env out of the available packages. So question which only left from this branch of the discussion is: What was the exact initial impulse which pushed someone to idea of storing full build env properties in src.rpm? IMO someone have been only thinking that this could solve something (that someone had only incorrect impression that it would help with something). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Wed, 1 May 2019 at 03:24, Neal Gompa wrote: [..] > Second, do you not even know that Mock passes --nodeps to rpmbuild > because the rpmdb in the chroot isn't necessarily compatible with rpm > in the chroot? We currently don't allow rpmbuild to evaluate > dependencies at all. We may change this if Koji switches to producing > bootstrap chroots before producing the build chroot. So right now, > that lookup is not even happening. > Calling rpmbuild with --nodeps to be able to resolve build dependencies from outside chroot and duplicating resolution of those dependencies by adding more code in yum/dnf to handle situation when rpm database in chroot is in different version is really .. "interesting". Just checked all Fedora spec files to find few of them which are using straight rpm command in %build or %check. One of those specs is elfutils.spec in which is: %check # Record some build root versions in build.log uname -r; rpm -q glibc In https://kojipkgs.fedoraproject.org//packages/elfutils/0.176/2.fc31/data/logs/x86_64/build.log is possible to find: Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.F4TimI + umask 022 + cd /builddir/build/BUILD + cd elfutils-0.176 + uname -r 5.0.6-200.fc29.x86_64 + rpm -q glibc glibc-2.29.9000-17.fc31.x86_64 I'm really happy that rpm database still is available inside mock chroot (ufff). During +25 years of using rpm it was at least two times situation when rpm was in kind of transition and in all those cases to build packages using my own automation I was always able to use just chroot command, and to be honest I would never even think about use "that way". If not using simplest "BuildRequires: pkgconfig" may be (somehow) affected by above (which I'm 100% sure that it is still not the case because still above isn't by any way kind of counterargument against "BuildRequires: pkgconfig") .. I think that I'll give up. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Tue, 30 Apr 2019 at 21:04, Neal Gompa wrote:
> > And what is wrong with just "BuildRequires: pkgconfig"?
>
> That is no guarantee that '/usr/bin/pkg-config' will be provided,
> which is required by the dep generator and various tools.
>
You just put in my hand +1 to not use paths in BuildRequires.
+1 for me. Thx.
If you will look across /usr/lib/macros and files in /usr/lib/rpm/macros.d
you will find hundreds of other commands used with full path and only
occasionally some of them are used in BRs in form "BuildRequires:
/some/path/command".
Are going to request/propose to change whole distribution pattern of BRs?
Really?
FYI: We call that thing which you are refusing to use .. abstraction.
> > Don't you see that this forces dependencies resolution to use packages
> files list?
>
> This is free already, as that data is always part of the solver cache.
>
> Besides, there is no ban on paths that are provided by primary.xml
> (*/bin, */sbin, */lib(64|exec), /etc). The ban is basically pointless,
> but that's what it is.
>
rpmbuild is not using dnf xml files :-/
> IIRC Fedora already had policy to not use paths in BRs.
>
> Outside of paths already provided in primary.xml, packagers SHOULD NOT,
> yes.
>
You are again talking about *install package time dependencies resolution*.
Command rpmbuild which is processing spec files is using *rpm database*.
We are talking about packages *build time dependencies resolution*.
Please do me a favourite and execute on your system from root "rpm
--rebuilddb; ls -l /var/lib/rpm/{Basenames,Providename}" and answer on the
question: query to which one rpm table has chance to be shorter?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: dropping autogenerated dependency on pkg-config
On Tue, 30 Apr 2019 at 18:19, Neal Gompa wrote: [..] > If we're going to go down this road, it should be > > BuildRequires: /usr/bin/pkg-config > > That's what's required for the dep generator to work, too. > And what is wrong with just "BuildRequires: pkgconfig"? Don't you see that this forces dependencies resolution to use packages files list? IIRC Fedora already had policy to not use paths in BRs. [tkloczko@domek SPECS]$ rpm -qf /usr/bin/pkg-config pkgconf-pkg-config-1.6.1-1.fc31.x86_64 [tkloczko@domek SPECS]$ rpm -q --whatprovides pkgconfig pkgconf-pkg-config-1.6.1-1.fc31.x86_64 kloczek -- Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH ___ 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: dropping autogenerated dependency on pkg-config
On Tue, 30 Apr 2019 at 14:59, Neal Gompa wrote:
[,,]
> > Bollocks .. just sed/perl oneliner which will add BuildRequires:
> pkgconfig if in package is used any "BuildRequires: pkgconfig() and
> remove from rpmdependencies autogenerator add "Requires: pkgconfig" if
> package has any on the list any pkgconfig file -> rebuild all affected
> packages.
> > It should take ~1h for someone with proven packager priviledges.
>
> Note that removing /usr/bin/pkg-config from the build environment also
> stops pkgconfig() Provides/Requires from being generated.
>
> And while I am a provenpackager and capable of making these kinds of
> changes, I won't if I think they're not a good idea (like this one).
>
So that is your problem that you don't see that serving any .pc file should
not automatically cause "Requires: pkgconfig()", and that such
generator should not relay on availability of pkgconfig command in build
env isn't correct solution as well.
If you still have some king of doubts that this is correct solution just
please try to describe scenario when this may not work or will produce
misleading results. Can you do this .. please?
Just in case if anyone woulds be asking did I tested this.
I'm using above solution since I've first time opened issue ticket against
rpm to drop adding pkgconfig (~two years ago). So far ItWorks(tm).
Please find in attachment patch patch which I'm using.
If you will have look closer you can find that this patch effectively
removes only one line and everything else makes that generator shorter and
depends only on POSIX sh (because it does not uses any bash specific
extensions).
And on the bottom line
If that problem would be solved we can start discussing dropping adding
Requires.Private as automatic devel dependencies. And filter off
Libs.Priovarte as only handful pf Fedora packages provides static libraries.
This issue is as well related to meson messy behaviour. Coincidence but
today I'v opened issue ticket against meson related to propagating
Requires.Provate when meson is used to build only shared ABI.
https://github.com/mesonbuild/meson/issues/5334
PS. No offence but when it comes to engineering usually when someone cannot
prove/disprove something in technical context and to refuse something they
are using only what they like/dislike usually I'm stoop listening.
If you do not understand simple fact that you can only use your taste when
you have two Correct(tm) solutions .. just change job.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
--- rpm-4.14.2.1/scripts/pkgconfigdeps.sh~ 2017-10-05 12:04:57.587602034 +0200
+++ rpm-4.14.2.1/scripts/pkgconfigdeps.sh 2018-12-31 08:33:37.433158137 +0100
@@ -1,19 +1,19 @@
-#!/bin/bash
+#!/bin/sh
pkgconfig=/usr/bin/pkg-config
test -x $pkgconfig || {
-cat > /dev/null
-exit 0
+ cat > /dev/null
+ exit 0
}
[ $# -ge 1 ] || {
-cat > /dev/null
-exit 0
+ cat > /dev/null
+ exit 0
}
$pkgconfig --atleast-pkgconfig-version="0.24" || {
-cat > /dev/null
-exit 0
+ cat > /dev/null
+ exit 0
}
# Under pkgconf, disables dependency resolver
@@ -44,7 +44,6 @@
case "${filename}" in
*.pc)
i="`expr $i + 1`"
- [ $i -eq 1 ] && echo "$pkgconfig"
DIR="`dirname ${filename}`"
export PKG_CONFIG_PATH="$DIR:$DIR/../../share/pkgconfig"
$pkgconfig --print-requires --print-requires-private "$filename" 2> /dev/null | while read n r v ; do
___
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: dropping autogenerated dependency on pkg-config
On Mon, 29 Apr 2019 at 20:09, Rex Dieter wrote: [..] > The work required to fix packages affected by this disadvantage > (potentially) far outweighs any advantage > Bollocks .. just sed/perl oneliner which will add BuildRequires: pkgconfig if in package is used any "BuildRequires: pkgconfig() and remove from rpm dependencies autogenerator add "Requires: pkgconfig" if package has any on the list any pkgconfig file -> rebuild all affected packages. It should take ~1h for someone with proven packager priviledges. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora 31 Self-Contained Change proposal: Minimal GDB in buildroot
On Fri, 26 Apr 2019 at 22:59, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Minimal_GDB_in_buildroot
>
> == Summary ==
> Create gdb-minimal package (without XML support, Python
> support, Syntax Highlight and such) and switch to it in buildroot.
>
> == Owner ==
> * Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:sergiodj|Sergio
> Durigan Junior]]
> * Email: ignatenkobr...@fedoraproject.org, sergi...@sergiodj.net
>
> == Detailed Description ==
> Create subpackage in gdb source package called
> gdb-minimal that will contain 2 files:
> * /usr/libexec/gdb-minimal — GDB executable built without
> optional unneeded features
> * /usr/bin/gdb-add-index — Executable script shared with
> gdb-headless package (modified to fallback to gdb-minimal if exists)
>
Hi Ben,
AFAIK that part of the gdb is used only to separate debuginfo in
%post_install.
Some times ago IIRC for exactly the same operation was used eu-strip used
-o to save stripped part in debuginfo files.
Even if eu-strip is not doing stripping correctly better would be better to
fix it or modify binutils strip to implement -o option from elfutils strip.
Using gdb for saving debuginfo looks like overkill and elfutils is +10
smaller and depends only on glibc.
$ rpm -q --qf "%{NAME}\t%{SIZE}\n" gdb-headless elfutils
gdb-headless 18123356
elfutils 1245125
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Fedora 32 System-Wide Change proposal: Retire Python 2
On Thu, 25 Apr 2019 at 08:34, Miroslav Suchý wrote:
> Dne 24. 04. 19 v 23:04 Ben Cotton napsal(a):
> > Removed packages that would block the upgrades to Fedora 32 will be
> > obsoleted from {{package|fedora-obsolete-packages}}.
>
> Which effectively means all python2-* packages. Right?
>
And gimp or at least gimp python plugin .. as seem no one now at the moment
is working to port that plugin to python 3.x
https://gitlab.gnome.org/GNOME/gimp/commits/master?utf8=%E2%9C%93=python
https://gitlab.gnome.org/GNOME/gimp/branches/all?utf8=%E2%9C%93=python
BTW: someone knows how often that python plugin is used?
Someone here is using it or knows someone who uses it?
(personally I think that it will be hard to find such person and packaging
it is just kind of waste of effort)
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Using %verify and %ghost and other issues for mass cleanups
On Wed, 24 Apr 2019 at 12:49, Pavel Valena wrote: [..] > Hello, > I'm not a provenpackager, but I want to help a bit. > Commands inline should do the trick. I've tested them, so it should be > smooth. > Thank you Pavel. Good job :) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Bigger packages (Was: Re: Fedora rawhide compose report: 20190417.n.0 changes)
On Wed, 17 Apr 2019 at 17:00, Fedora Rawhide Report < rawh...@fedoraproject.org> wrote: [..] > Package: at-spi2-core-2.32.1-2.fc31 > Old package: at-spi2-core-2.32.1-1.fc30 > Summary: Protocol definitions and daemon for D-Bus at-spi > RPMs: at-spi2-core at-spi2-core-devel > Size: 1.77 MiB > Size change: 42.01 KiB > Changelog: > * Tue Apr 16 2019 Adam Williamson - 2.32.1-2 > - Rebuild with Meson fix for #1699099 > > > Package: atomix-3.32.1-2.fc31 > Old package: atomix-3.32.1-1.fc30 > Summary: Puzzle game: Build molecules out of isolated atoms > RPMs: atomix > Size: 2.85 MiB > Size change: 20.33 KiB > Changelog: > * Tue Apr 16 2019 Adam Williamson - 3.32.1-2 > - Rebuild with Meson fix for #1699099 > I'm not sure did anyone noticed that but despite fact that fixing #1699099 should introduce relatively small change each rebuild recently introduces bigger packages. I'm still investigating this but looks like that change (ELF files length increase) is not related to the meson or #1699099 but to binutils. Tomasz -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: [PSA] %meson contains -Db_ndebug=true
On Tue, 9 Apr 2019 at 13:54, Igor Gnatenko wrote: > At this moment, > > * %meson doesn't pass -Db_ndebug at all, we use project-specific options > * If project doesn't specify it, b_ndebug=false is default in meson > * In case of mesa, it specifies b_ndebug=if-release which works correctly > now with backported patch > IMO discussed here issue is more related to Fedora macros. As current definition of the %meson uses --buildtype=plain instead --buildtype=release and that build type is fixed and does not provide any other way to redefine build type than just just pass another --buildtype= fiddling anything around plain build profile straight in meson source code may introduce more harm than good thing. IMO whole rpm macro suite should proved something like %build_type macro which should be used transparently by %configure, %cmake and %meson. Effectively for now Fedora IMO needs only as %build_type something like "release" and "debug". Any other type of the build should have some strict definition of the propose. IMO it would be even good to have in whole rawhide development cycle something like build all packages with build type "debug" and use "release" type only after branching all packages and rebuild everything with build type "release". This would as well guarantee that whatever will be offered in new stable release will be building with all other packages (which up to now still is not the case). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Using %verify and %ghost and other issues for mass cleanups
le openocd ORBit parted psacct pwmd
python2-docs ratpoison teseq tinc wdiff wol
*3) (over)use %doc in case of man pages entries in %files*
[tkloczko@domek SPECS.fedora]$ grep "^%doc %{_mandir}" * -l | wc -l
192
Man pages are by definition %doc because:
$ rpm -E %__docdir_path
/usr/share/doc:/usr/share/man:/usr/share/info:/usr/share/gtk-doc/html::/usr/share/man:/usr/share/info:/usr/share/javadoc:/usr/doc:/usr/man:/usr/info:/usr/X11R6/man
BTW: currently it is possible to shorten that list of paths because it has
duplicates and no longer used by any fedora package directories.
And list of affected packages:
[tkloczko@domek SPECS.fedora]$ grep "^%doc %{_mandir}" * -l | awk -F.
'{print $1}' | xargs
adcli annobin ansible argtable asciidoc augeas auto-destdir bcrypt boom-boot
boxes brltty castxml cdargs c-graph CGSI-gSOAP cherokee cinnamon-session
cloud-utils cockpit collectd criu cstream ctpl dbus-java dbxtool dietlibc
diffoscope dnssec-system-tray dracut e2tools ebtables eot-utils fbida fdupes
fedora-upgrade fetch-crl firefox freeradius freeze freight fwknop-gui
fwupdate gajim gcc-python-plugin gdcm geany general-purpose-preprocessor
gitstats globus-authz-callout-error globus-authz globus-callout
globus-common globus-ftp-client globus-ftp-control globus-gass-cache
globus-gass-copy globus-gass-transfer globus-gatekeeper globus-gram-audit
globus-gram-client globus-gram-client-tools
globus-gram-job-manager-callout-error globus-gram-job-manager-fork
globus-gram-job-manager-scripts globus-gram-job-manager globus-gram-protocol
globus-gridftp-server globus-gridmap-callout-error globus-gsi-callback
globus-gsi-cert-utils globus-gsi-credential globus-gsi-openssl-error
globus-gsi-proxy-core globus-gsi-proxy-ssl globus-gsi-sysconfig
globus-gssapi-error globus-gssapi-gsi globus-gss-assist globus-net-manager
globus-openssl-module globus-proxy-utils globus-rsl
globus-scheduler-event-generator globus-simple-ca globus-xio-gridftp-driver
globus-xio-gsi-driver globus-xio gnome-desktop gnome-screensaver
gnome-session gnome-system-log gnugo gofer grig gsm-ussd
gst-editing-services gst-entrans gstreamer1 gtick hash-slinger hunt icemon
igraph ipset iucode-tool jwm lbdb lcdtest lcgdm lde libcsv librabbitmq
librecad libreswan libxslt liquibase lookup loopabull lsyncd mod_mono
mousetweaks mpg123 mpich munin ndisc6 nethogs NLopt nml nodejs nomarch
nordugrid-arc nss numad nut obs-signd ocaml-tplib OpenCoarrays pacemaker
pam_shield papi parfait pass perl-App-PFT perl-PFT planarity pngcrush
python-behave python-bitmath python-clint python-ethtool
python-networkmanager qpid-cpp rear retrace-server rktime rssh
rubygem-bundler rubygem-chake rubygem-clockwork rubygem-mustache
rubygem-rake rubygem-sdoc rubygem-shotgun rubygem-tilt rubygem-treetop salt
sbd scap-workbench scapy scponly sepolicy_analysis serd snake socat
squeezelite sslh star stow subscription-manager tcpreplay tito
transmission twinkle txt2tags udns ursa-major whowatch xlockmore xwax ytree
yuicompressor
4) Above issues should be cached by rpmlint so it is yet another small
point on TODO list.
Who will take care at least those 3 first points?
Volunteers?
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
___
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: Loopy rpm subpackages dependencies
On Thu, 28 Mar 2019 at 11:47, Neal Gompa wrote: [..] > No. The rpm plugins are runtime activated things, that's why they are > split out. > Exactly. Just checked and in python code those modules initialisation looks like below: -- # try to import build bits but dont require it try: from rpm._rpmb import * except ImportError: pass # try to import signing bits but dont require it try: from rpm._rpms import * except ImportError: pass -- So technically those rpmb and rpms pythoon DSOs can be separated. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Loopy rpm subpackages dependencies
On Thu, 28 Mar 2019 at 20:57, Neal Gompa wrote: [..] > > Other things related to the rpm. > > Why in main rpm package is possible to find whole /usr/lib/rpm/platform? > That directory contains ONLY resources used during build!!! Why main rpm > package includes documentation about building packages? =:-# > > > > They can be used at runtime as well, especially if you use > runtime-evaluated macros in scriptlets. > Hopefully it is still only theory .. 1) Exactly those macros long time ago have been separated as build stage dependent set. (Just in case if it is not obvious) in platform/ are all archs files because that allows use rpm to do cross arch builds. 2) Theoretically someone may do any possible s*d thing in such scriptlets and still it does not mean that those macros should be used :) 3) I don't know anything about such cases like you mention in any Fedora spec files uses that (just done I've done few greps and still potential list is empty) and it is already some non-empty set of such specs that should be corrected ASAP because using something like this potentially could be like opening Pandora box. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Loopy rpm subpackages dependencies
On Thu, 28 Mar 2019 at 16:37, Miroslav Suchý wrote: > Dne 28. 03. 19 v 13:57 Tomasz Kłoczko napsal(a): > > dnf does not provide any signing functions and I was not even aware that > someone implemented in base dnf building > > functionalities (someone is using that?) > > No, DNF likely does not user rpmb and rpms. > Both libraries has 21K + 15K. It is really worth the work? Note that the > split will affect ~ 16 other packages in > Fedora. And likely some outside of Fedora. They need to be notified of the > split, reconsider their dependencies. For > saving 36K? > Yes, I care about every possible (even smallest) cut on the elephant skin which will die if thousand small cuts on his skin will be done :P If that does't matter why the rpm package build produces generates so many subpackages?? If on typical system most of those packages are not optional why make so many subpackages? To make Packages table in rpm database longer only? Not mentioning about fact that even usability of current grouping of the rpm files has zero usability in case of multilib scenarios (which could be some logical reason for thatcase but isn't) Just for fun/Because we can(tm)? If may I point on one cardinal argument which is .. KISS!!! There is no any other single package which during build may require signing library (only). Not keeping sign library in rpm-sign is purely artificial. In other words probability that this package would be required in some multilib scenarios is ZERO! Other things related to the rpm. Why in main rpm package is possible to find whole /usr/lib/rpm/platform? That directory contains ONLY resources used during build!!! Why main rpm package includes documentation about building packages? =:-# kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Loopy rpm subpackages dependencies
On Thu, 28 Mar 2019 at 12:47, M A Young wrote: [..] > > python3-rpm is required by dnf so it is really hard to have manageable > > system without that part (however in extreme cases it is still possible > to > > drop completely dnf). > > You could always use microdnf instead. > If it is really possible why it is not used that way by default? dnf does not provide any signing functions and I was not even aware that someone implemented in base dnf building functionalities (someone is using that?) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Loopy rpm subpackages dependencies
Hi,
Just found that on some minimal system it is not possible to remove some
rpm subpackages.
* Current state
# rpm -qa | grep rpm
rpm-libs-4.14.2.1-4.fc30.1.x86_64
rpm-4.14.2.1-4.fc30.1.x86_64
python3-rpm-4.14.2.1-4.fc30.1.x86_64
rpm-build-libs-4.14.2.1-4.fc30.1.x86_64
rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64
python3-rpm is required by dnf so it is really hard to have manageable
system without that part (however in extreme cases it is still possible to
drop completely dnf).
Problem is that on minimal system rpm-sign-libs and rpm-build-libs
theoretically should be not needed, however because python module in
current form combines in single package all its three DSOs:
# rpm -ql python3-rpm | grep so$
/usr/lib64/python3.7/site-packages/rpm/_rpm.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpmb.cpython-37m-x86_64-linux-gnu.so
/usr/lib64/python3.7/site-packages/rpm/_rpms.cpython-37m-x86_64-linux-gnu.so
it causes that it is not possible to use only core rpm package management
on minimal system.
I think that it would be good to split python3-rpm into python3-rpm{,b,s}.
* Proposal
In current form keeping separated rpm-plugin-selinux is a bit pointless so
that part IMO should be joined with rpm-build.
As well probably rpm-plugin-ima could be merged with rpm-sign.
With that changes total number of generated packages will be the same and
will make IMO much more sense in case of non-devel/build systems and
systems which are used for signing packages.
Comments?
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Wed, 27 Mar 2019 at 21:27, Jonathan Wakely wrote: > On 26/03/19 11:40 +0000, Tomasz Kłoczko wrote: > >On Tue, 26 Mar 2019 at 08:57, Jonathan Wakely > >wrote: > >[..] > > > >> >What does this 42 means in this case? It means that during whole gcc > build > >> >are repeated 42 times some subset of *autoconf tests*. How it was > possible > >> >to loose that?!? 樂 > >> >gcc is quite monolithic and it should have only one configure.ac. Yes, > >> > >> Why? > >> > > > >Really? > >Really do you want me to answer on the question "why there is no any sense > >repeat 42 times some tests on the source code configuration stage?" ?? > > Yes, because you repeatedly make the mistake of assuming that one > dimension of a problem is the only one that matters, and that all > other considerations are irrelevant. > Just to be clear .. So you want to say that I'm making mistake because I'm assuming that speed/performance matters? Could you please confirm that is is what you are thinking reading what I wrote? Could you please as well crush my assumption using logical arguments and facts? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Tue, 26 Mar 2019 at 16:44, Tomasz Kłoczko
wrote:
[..]
> If above is correct IMO collecting such files (it those files are really
> needed and used) should be done outside of the scope of regular "rpmbuild
> -ba".
> Collecting and preserving some build logs always should be part of the
> build automation.
>
One more thing (and sorry again related do gcc.spec)
(again *Warning*: wear welder mask before start reading that file!)
I just realised that in gcc.spec at end of the %check is possible to find
few funny lines which I'll quote here:
mkdir testlogs-%{_target_platform}-%{version}-%{release}
for i in `find . -name \*.log | grep -F testsuite/ | grep -v
'config.log\|acats.*/tests/'`; do
ln $i testlogs-%{_target_platform}-%{version}-%{release}/ ||:
done
tar cf - testlogs-%{_target_platform}-%{version}-%{release} | xz -9e \
| uuencode testlogs-%{_target_platform}.tar.xz ||:
rm -rf testlogs-%{_target_platform}-%{version}-%{release}
if it is hard to see about what this part is this is about archiving some
files in build logs :o)
Just tar | uunecode and output to stdout. Pure JFDIN :)
That uuencoded part lands in gcc build logs. Funny old school .. but is it
really necessary/useful?
Quick check:
[tkloczko@barrel SPECS.fedora]$ grep uuencode * -l
binutils.spec
gcc.spec
gdb.spec
ghc-dataenc.spec
nacl-arm-binutils.spec
nacl-binutils.spec
perl-Convert-UU.spec
sharutils.spec
uudeview.spec
>From that list it is possible to remove last three specs.
I think that all those uuencode use cases have been done by the same person
-> kind of exception.
What above says?
That probably there are some needs to preserve some files beyond regular
build process and some people already started taking care of that without
thinking to much.
Question only is: are those needs are really real (real-real) or only
imaginary?
If yes I can propose simpler solution like create .post_build_preserve.lst
file in source build root and whatever will be added to that file should be
archived in some --.tar.xz file to be accessible
over koji web interface.
If such file will be created during manually executed "rpmbuild -ba" it
will not leave any garbage behind or will be no flooding stdout during
build.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Tue, 26 Mar 2019 at 15:42, Dridi Boukelmoune
wrote:
[..]
> > Japheth Cleaver explained why in response to me a couple of days ago:
> > apparently changing it would also change the shell used for some
> > scriptlets...
>
> He also posted this link:
> http://web.archive.org/web/20150821020837/http://rpm.org/ticket/877
Just FTR: Fedora macros are already polluted by bashisms;
$ rpm --showrc | egrep -e "popd|pushd"
pushd %{buildsubdir}
popd
$ egrep -e "popd|pushd" /usr/lib/rpm/macros.d/*
/usr/lib/rpm/macros.d/macros.perl:pushd %{buildsubdir} \
/usr/lib/rpm/macros.d/macros.perl:popd \
So here it is whole macro which is using pushd/popd:
%__perl_check_pre %{expand: \
%{?__spec_check_pre} \
pushd %{buildsubdir} \
%define perl_br_testdir %{buildroot}%{perl_testdir}/%{cpan_dist_name} \
%{__mkdir_p} %{perl_br_testdir} \
%{__tar} -cf - %{__perl_test_dirs} | ( cd %{perl_br_testdir} && %{__tar}
-xf - ) \
find . -maxdepth 1 -type f -name '*META*' -exec %{__cp} -vp {}
%{perl_br_testdir} ';' \
find %{perl_br_testdir} -type f -exec %{__chmod} -c -x {} ';' \
T_FILES=`find %{perl_br_testdir} -type f -name '*.t'` \
%fix_shbang_line $T_FILES \
%{__chmod} +x $T_FILES \
%{_fixperms} %{perl_br_testdir} \
popd \
}
and:
%perl_testdir %{_libexecdir}/perl5-tests
That %check_pre extension looks like it is about archiving some post %build
files (what???).
Just checked:
[tkloczko@domek SPECS.fedora]$ grep perl5-tests *
perl.spec:%global perl5_testdir %{_libexecdir}/perl5-tests
I could be wrong so please correct me if I'm wrong.
Looks like someone to add something in *single perl package* build process
one additional macro has been added to global rpm macros.
If above is correct IMO collecting such files (it those files are really
needed and used) should be done outside of the scope of regular "rpmbuild
-ba".
Collecting and preserving some build logs always should be part of the
build automation.
Conclusion: whole macro should be removed and there is nothing to fix about
fixing some bashisms here.
If that macro is needed in perl build process it should be moved to the
perl.spec (I would even verify that part carefully as well).
It would be good if someone else as well will carefully review whole
content of the macros.perl. I would be not surprised it that file contains
more such .
That is result of abandoning strict controlling macros used during rpm
build process.
I've been telling here something like +2y ago that spreading macros across
many packages will blow up.
Nevertheless .. cuts_counter--
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Tue, 26 Mar 2019 at 12:32, Nicolas Mailhot wrote: [..] > Packager time is not cheap, it's not inexhaustible, it runs out. Wasting > it on bashisms is not smart. > I like that conclusion because it is way better than all what I wrote. Thanks Nicolas for those two final sentences :) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Tue, 26 Mar 2019 at 08:57, Jonathan Wakely wrote: [..] > >What does this 42 means in this case? It means that during whole gcc build > >are repeated 42 times some subset of *autoconf tests*. How it was possible > >to loose that?!? 樂 > >gcc is quite monolithic and it should have only one configure.ac. Yes, > > Why? > Really? Really do you want me to answer on the question "why there is no any sense repeat 42 times some tests on the source code configuration stage?" ?? > The GCC tree contains lots of quite separate subsystems, which are > maintained semi-independently by different groups of people. It makes > sense for me to maintain libstdc++-v3/configure.ac and > libstdc++-v3/acinclude.m4 without worrying how my changes affect the > rest of the tree. > Decades ago on the begging of the gcc development it was only handful developers around which been able to build gcc because compiler it is still not easy piece of the code to build. To help in that process and to minimise those less skilled people mistakes decision about inclusion of the other projects code into gcc tree has been made. It was really long time ago an in mean time many tools around gcc has been developed to guarantee that exact libraries or tools would be present in for example gcc build environment. Best example: pkgconfig. However gcc is like some time capsule and preserved that initial state quite well straight in the code. Seems like you do not understand the impact of the fact that some parts of the gcc code are older than some people reading this list today. As same as not keeping in po/ directories .pot files is not helping translators the same is with including other project code is not today helping in gcc development process. gcc as the project bottleneck is on those few people who are gcc maintainers. Maintaining code of those inclusions eats part of that precious man/hour resources. Everything else can be scaled horizontally. People like Jakub are thinking that they are helping other people (and by this saving some resources) by spending time on updating and committing .pot files changes, and as well syncing other projects code in gcc tree and they are right .. they are *only thinking* that it is still truth. If may I one more time quote one of my beloved Latin sentences: "errare humanum est perseverare autem diabolicum". Which can be translated to "to err is human, but to *persist* in error (out of pride) is diabolical". All about I'm asking is just wake up and look around because few things have changed in last decades. Consequence of those separations will be that some source code configurations test will be repeated .. so "do we need faster /bin/sh or not?" (if moving to meson would be to difficult). Look on clang/llvm. People maintaining those projects already divided some nonpolitical trees and they are keeping some parts separately. The same was with Xorg. So are those Xorg or clang developers are wrong about dividing and deliberately forcing to repeat many times some configuration stage tests? Answer on that question is "No, they are not" because chance to have situation that some of those (sub)projects tests will be executed in parallel on some well designed packages build machinery are now quite high. Simple sometimes on solving some issues trying to crush them in straight confrontation is not the best way to win. Current gcc state in many areas are really bad because within nonpolitical tree some separations already have been made which make whole build process not scaleable. This is quite easy to spot on that graph which I've decided to post here. In other words gcc source code tree is already in some "brain split" state between be nonpolitical tree and something which is not. This not my decision about which one model for gcc should be *chosen*. What worries me id that I can only bet that some decisions about internal separations within gcc tree had some more aesthetic than technical background/context. As you see whole topic of the gcc has many sometimes orthogonal (sometimes not) aspects. To reach healthy state bore than few things simultaneously needs to be carefully balanced. Only part of that topic is related to /bin/sh and that part stretches waaay beyond gcc. I'll try to hold my finger away from this topic because I think that I've already managed to put enough solid context around more than few things. If someone still do not understand what is discussed after pouring here such bucket of facts it not my problem. I've done all what I can and able to convince few people. My understanding is that now it is more or less *only* matter of time to make some decisions and I'm not going to press on anyone. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an
Re: More than 10% of all Fedora spec files are not POSIX sh compliant
On Tue, 26 Mar 2019 at 07:52, Nicolas Mailhot wrote: [..] > CPU time is cheap, packager time is not. Exchanging CPU time for "you > all should learn to write POSIX-only shell scripts" would be an awful > deal. I need more time. A year for the starter and I can pay good price .. Where I can make such deal? Do you know where is the nearest ATM where I can buy more time? The Java part of Fedora is slowly imploding right now because a > lot of people pushed their complexity on packagers, and the packagers > could not cope. The Fedora target should be to help packagers achieve > more with less work, not achieve less with more work. > Problem with that kind of proving is that you are using *analogy*. Many people are completely unaware that analogy *newer was, isn't and never will be* any kind of tool of proving something. That what learn us LOGIC as general methodology of dealing with problems. Analogy is the only tool of *improving ideas transport process* from brain A to brain B. Only this and nothing more. If you want to prove something you must use *only* pure facts and counter facts. Most difficult part of the proving process is distinguishing what is the relevant fact and what is not and sometimes what is the fact and what isn't. As long as you 'java argument' has nothing to do with not even POXIS sh per se but with *PERFORMANCE of the /bin/sh* please go somewhere else. One more time: we are not discussing POSIX sh compliance topic. One more time: it is *only coincidence that fastest available now sh interpreter it is not bash and all those fastest are 100% POSIX sh **compliant ONLY!!!* All those fastest sh interpreters sh are not faster because they are better designed in some common of the code parts. No. They are faster because they are *simpler and smaller*. Many people even now are investing serious man/hours resources to make some of those interpreters even smaller and by this *faster*. If you want to improve bash speed you must strip down many parts of its code. After that bash would be nothing more than just ~ksh. If you want to bet on which one sh interpreter will be fastest before executing actual tests just look on the size of the binary. Looking from that angle current x86_64 bash it is 1494360 and mksh it is 342800 bytes. Do you see now that .. small .. "difference"? With using sh is the same as with using C++ (if may I use analogy to only *encircle *some important* aspect* of the discussion and to focus your attention on the exact part of the topic). If you want to have fastest possible C++ code by definition you must forget using C++ exceptions and exactly the same here is with abandoning bashisms when /bin/sh is used. Is that clear now? Question only is: "do you care about performance or not?" Everything else after vocalising the answer would be nothing more than just pure consequence of the *decision* .. because dropping or not bashisms still is matter of the *choice*. However even not making conscious decision about that question would be the decision. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Mon, 25 Mar 2019 at 21:57, Japheth Cleaver wrote: [..] > It feels like there's been this vast movement to try to remove every last > bit of shell from Fedora whenever possible, and I really don't understand > the aversion. > In most of the cases it is nothing more than some form of NIH syndrome ( https://en.wikipedia.org/wiki/Not_invented_here) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Mon, 25 Mar 2019 at 21:17, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 25, 2019 at 08:18:34PM +0000, Tomasz Kłoczko wrote: > > Switching to other than bash sh interpreter allow reduce total gcc > package > > build time by ~5%. > > OK. But that just shows that it is — possibly — worth to switch the gcc > build > to a different shell, by working with gcc upstream. Nothing should be > extrapolated from this to other packages and in particular to their > spec files. > Zbyszek .. please .. you are wrong about that I'm using here extrapolation. I've posted only small fragment of what kind of data I'm collecting in my infrastructure. gcc has own set of issues which I've exposed here partially in last 2-3 weeks. All those issues are way more important than what is used as /bin/sh. Really. Speaking about gcc build improvements. Just one number: [tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac | wc -l 42 Funny. Looks like current Fedora gcc poses "The answer to the ultimate question of life, the universe and everything" What does this 42 means in this case? It means that during whole gcc build are repeated 42 times some subset of *autoconf tests*. How it was possible to loose that?!? 樂 gcc is quite monolithic and it should have only one configure.ac. Yes, am/ac can handle multiple gettext domains in single build tree so even this is not the obstacle. How to do this? Just peak on gimp, gtk3 and many other (however those two are kind of out of book examples). IMO by such transition to single ac it should be possible to shorten gcc build time (guessing a bit) by another 10% (optimistically). However IMO it would be better move gcc build framework to meson (because as I wrote few days ago ac/am/lt is effectively dead by now by how it is maintained by GNU people and moving those tools maintenance outside GNU project domain will be not easy task). Just in case: cmake as ac/am/lt replacement is not IMO good because it is yet another project in which coding process maintainers are trying to solve famine problems on Earth. cmake is written in C++ and additionally its C++ code uses exceptions and RTT (only this says that says something .. not so good). Speaking about cmake. Recently trying to fix some cmake issues I found that cmake build using boostrap and cmake themselves does not produce the same results because looks like cmake developers are not using cmake to develop cmake which is really hilarious Moving to meson (with all necessary tests in one place fired one time only) probably should shorten gcc build time by another few percents (maybe even more). I'm almost sure that with not so big effort in 2-3 man/weeks it would be possible to reduce gcc build time by at least 1/3 (totally). Is it worth to divert some people resources to do that? IMO definitely yes as sooner or later gcc build should allow speedup whole gcc development process (during last New Year I've started gcc build on my old laptop and it took on it almost 25h). However I'm fully aware that on top of moving to meson it will be another chunk of man/hours resources and this could be painful for Jakub as it will be necessary to sort out all those SIGSEGVs in gcc test suite and stop doing his gcc magic (Jakub don't take this personally please .. I'm really joking) kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
On Mon, 25 Mar 2019 at 20:47, Stephen John Smoogen wrote: [..] > [Also when giving one graph for one type of build, could you also give a > similar graph showing how it looks with dash or ksh or whatever you used?] > Graph for the gcc will be exactly the same. Only overall time will be shorter. ksh93 is not the good replacement candidate. I've tested it with gcc and using it causes that whole build freezes at some point. I've started my testy from ksh and this is why I've took next on the alphabetic list which was mksh. Maybe it is only some issue with Fedora version and latest ksh93 is fixed .. really I don't care about that as better POSIX sh alternatives are around. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: More than 10% of all Fedora spec files are not POSIX sh compliant
[.all the comments.] All replies are between "who cares?", "it is holy war/waste of time" to something like "be standards compliant is important" .. this thread is hilarious I'm observing all the comments under my post and (with full respect to all of you guys) looks like all of you guys are *wrong* why sticking to POSIX sh is important *Literally all of you lost one very important fact that bash is not fastest sh interpreter which is possible to use and only kind of coincidence is that all those fastest are almost puritanically POSIX sh compliant!!! * OK, so about what kind of performance difference in context of exact numbers we are talking about? I've tested building gcc using mksh as /bin/sh. Only one detail: on doing that test you will find small obstacle that you will be not able to measure whole build time because in the %install of the gcc.spec is used pushd/popd. *Warning*: on looking on whole gcc %install *please* remember wearing welder mask because without it may hurt your brain (Yes, it is yet another my small pebble with name "badly maintained" thrown in direction of the gcc because it forces to do so many things outside pure "make install"). Checked my zabbix and here is the graph with CPU usage made during building gcc on 24 core box (48 CPUs with MT) when bash is used as /bin/sh: [image: image.png] As you can see on the graph ~+60% of whole gcc build time hangs on single thread/core serialised processes. Quite significant part of that time is spend in *running sh scripts*. Only in second half of the build is possible fully saturate potential of that particular HW (on running test suite). Switching to other than bash sh interpreter allow reduce total gcc package build time by ~5%. On my 24 physical CPU core HW it is about 10 minutes. Guys just try to have look around and try to estimate how many Fedora packages are using autoconf/libtool and other POSIX sh based build frameworks or using /bin/sh. As all those frameworks are using sh mostly they are running without parallelism how fast is /bin/sh is crucial. No .. be POSIX sh compliant it is not about any kind of holly war!!! It is pure about performance and for people like me quite often *time spend waiting until package X build will be finished*. Some people cursing that waiting and calling it "PCtology" (waiting on the front of the PC until something will be finished). BTW readline and bash: is there any particular reason why Fedora bash still is statically linked with readline generated out of the own copy of readline code? That not changed from more than decade (if not +13y) so it must be some reason 樂 IIRC readline is relatively high on the list of most frequently affected packages by various CVEs so in case of any new issue with readline someone must remember about that because .. [tkloczko@domek SPECS.fedora]$ grep bundled bash.spec [tkloczko@domek SPECS.fedora]$ Someone must remember about that (somehow) because bash is used as /bin/sh which and is used almost everywhere(tm), and by this attacking bash still is quite popular vector of many security related attacks. Simpler /bin/sh -> lower probability of many security related issues from that angle. Do you see now the subject in proper light? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On Fri, 22 Mar 2019 at 13:18, Jakub Jelinek wrote: [..] > > Sorry to say that but you just told that that you don't know enough about > > maintaining translation :P > > Sorry but you are wrong, it is unclear from what you are judging this. We > as > the GCC project have procedures to maintain translations, new gcc.pot is > not > regenerated daily but usually twice before a major release (usually at the > start of stage4 development phase and shortly before release) and on > major/minor > releases, as you can see in https://translationproject.org/domain/gcc.html > It isn't worth bothering our translators with new changes every day. > The latest gcc.pot regeneration/upload was February 2nd, so there are > almost > two months of further changes. While I'm not a translation maintainer, > I've > spent quite a lot of time including this year working with the translators > to improve the diagnostics, so that it is better translatable or easier to > handle for the translators, see e.g. http://gcc.gnu.org/PR40883 meta-bug > and the recent changes. > In our project rules the *.po files are maintained by the > translationproject.org, we never make changes to those, just regenerate > the > pot and upload it and when updates are available from translators merge > those back. I'm not going to violate this stuff with a GCC downstream > Fedora hat. > 1) I don't see even single fact in what you just wrote which contradicts/undermines what I told. You just wrote that gcc has its "own procedures" and those procedures are not the same as what I've described. In other words using some analogy you did not show that I presented apples but those apples are unhealthy and shpuld not be eaten. You said "Look Tomasz you are wrong because I have plumbs". You just described some facts on axis oriented kind of orthogonality .. only. I'm fully aware of that and this is why I wrote about readjusting some gcc procedures. You simple ignored what I wrote and that's it. 2) It looks like even people from translationproject.org are somehow wrong or they are so polite they dpn't want to hurt gcc maintainers fillings because in the well-maintained project with i18n resources no one keeps .pot files in VCS If you don't believe me go to for example https://gitlab.gnome.org/GNOME/ and take some random project with po/ directory and try to find in that directory .pot file. Even if you would be able to find such file in po/ it will be nothing more than the exception. Do you see this now that ggc is wasting time on maintaining .pot files content which no one is asking for? 3) gcc has a long history, and already many things are behind how some technologies/tooling should be used. I would accept that gettext support is not used as it should be used as long as .po files would be up-to-date but as I proved they are not .. You may only ask "why?" but that is all what you really should do. I wrote that gettext support in gcc is implemented in kind of DYI way. Here is the proof: [tkloczko@barrel gcc-9.0.1-20190312]$ find . -name configure.ac |xargs grep GETTEXT ./libcpp/configure.ac:ZW_GNU_GETTEXT_SISTER_DIR ./intl/configure.ac:AM_GNU_GETTEXT_VERSION(0.12.1) ./intl/configure.ac:AM_GNU_GETTEXT([], [need-ngettext]) ./gcc/configure.ac:ZW_GNU_GETTEXT_SISTER_DIR Only in intl/configure.ac are used AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION macros however that directory is just copy of the gettext files. In gcc/ and cpp/ is used kind of own version aclocal macros, and in libstdc++/ gettext support is done completely DIY method. Why? Why someone is wasting time on reinventing the wheel? You can just remove from VCS few m4 and even some Makefile.* or Makefile files content and just enjoy use AM_GNU_GETTEXT and AM_GNU_GETTEXT_VERSION macros. If this will be done that way whole gcc build framework would be one huge step closer to have whole build framework initialised after VCS checkout by execution of "autoreconf -fiv" in gcc root directory. Whoever as translator would be trying to update gcc .po file will be stuck with a simple thing that there is no update-po make target in any of the gcc po/ directory. That is probably the main factor why all .po files are not up to date. Whoever would be trying to do regular maintenance of .po files will be forced to decipher first DIY gcc own .po files updated procedures (not seen in any other project). You may still try to convince me that I'm wrong and you are right, but whatever you would be able to add cannot not be able to change basic fact that translations in gcc/binutins are not well maintained (even one file). In other words, you will be trying talking to convince those files .. not me. People who like helping translate text resources in some projects are familiar with some exact procedures. gcc is not using those well-known i18n maintenance pro
Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
YS. And as I'me telling about general methodology of maintaining .po files it is yet another "small" detail related to encoding of .po files. I've just checked that and gcc is affected by other issue as well. [tkloczko@barrel gcc-9.0.1-20190312]$ find . -name \*.po | xargs grep Content-Type | grep -v UTF-8 ./libstdc++-v3/po/de.po:"Content-Type: text/plain; charset=ISO-8859-1\n" ./libstdc++-v3/po/fr.po:"Content-Type: text/plain; charset=ISO-8859-1\n" ./libcpp/po/ca.po:"Content-Type: text/plain; charset=ISO-8859-1\n" ./libcpp/po/be.po:"Content-Type: text/plain; charset=utf-8\n" ./libcpp/po/eo.po:"Content-Type: text/plain; charset=utf-8\n" ./libcpp/po/id.po:"Content-Type: text/plain; charset=ISO-8859-1\n" ./libcpp/po/zh_CN.po:"Content-Type: text/plain; charset=utf-8\n" ./libcpp/po/el.po:"Content-Type: text/plain; charset=iso-8859-7\n" ./gcc/po/be.po:"Content-Type: text/plain; charset=utf-8\n" ./gcc/po/id.po:"Content-Type: text/plain; charset=ISO-8859-1\n" ./gcc/po/el.po:"Content-Type: text/plain; charset=utf-8\n" Why above is wrong? Simple .. gettext tools on generate binary .mo files are preserving original encoding used in .po files. What it means? It means that on displaying those translated messages in case of using UTF-8 based locale settings (which is now *common*) glibc needs to load additional translation table to convert those messages to UTF-8 before they will be displayed. So please do "for i in libstdc++-v3 libcpp gcc; do make -C $i/po update-po" then convert all above files to UTF-8 using iconv -> change in all those .po file lines to "Content-Type: text/plain; charset=UTF-8\n" and .. THAN commit all those updates. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
More than 10% of all Fedora spec files are not POSIX sh compliant
Just FTR: [tkloczko@domek SPECS.fedora]$ egrep -w "popd|pushd" * -l| wc -l 2843 Looks like many Fedora packagers forgot that .. [tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell /bin/sh I'm not sure is it would be good to post full list of all spec files here .. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On Thu, 21 Mar 2019 at 12:07, Jakub Jelinek wrote: [..] > Like what exactly? E.g. all the -Wformat-security warnings are about cases > where the format strings are constructed shortly before they are passed to > the format attribute functions, either unmodified or through gettext. KISS principle .. Maybe it is time to remove gettext support from gcc/binutils it is really so hard to maintain? Who needs this? I'm not trying to give any answers on those questions but people like you who are directly maintaining gcc should be able to balance between some priorities like what is most important and what is only decoration on the Christmas Tree. People are writing the code with i18n support which compiles without single warning. This is not a rocket science. I can understand that it may be difficult for some people but not everything needs to be done by single person. Isn't it? Just try to execute "update-po" target in gcc/ and you will see that only by this single command is possible to reduce gcc/po/ directory content by ~2MB (which is about 5% and that is only in one directory with translations) which says that for quite long time no one cares that most of the translations are not up-to-date. Maybe telling other people that if all compile time warnings related to gettex will be not sorted out before final gcc 9 i18n support will be dropped? Let's see how many people cares about that support (?). Chess players sometimes says that in this game more dangerous than chess mat is knowing that in next move you will be under pressure of that state. Every source code maintainer doesn't need to do everything and I'm not asking you why all those problems are or sort out every even minor issue. At least such person needs take care of some problem management by identify the problem and making aware of them people around, and assigning priority to each point of the list problems. It is really good to resent some statistics on each release. Statistics about up-to-date i18n or number of stats about warnings are only two I'm sure that you Am I could be right or not? Going back to main subject about default compile options. I have question for you Jakub :) Quote from redhat-rpm-config package buildflags.md: * `-fexceptions`: Provide exception unwinding support for C programs. See the [`-fexceptions` option in the GCC manual](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions) and the [`cleanup` variable attribute](https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute). This also hardens cancellation handling in C programs because it is not required to use an on-stack jump buffer to install a cancellation handler with `pthread_cleanup_push`. It also makes it possible to unwind the stack (using C++ `throw` or Rust panics) from C callback functions if a C library supports non-local exits from them (e.g., via `longjmp`). Is it still correct? If it is why that kind of issues are solved that way? Someone maybe remember in which one project this caused some issue? Building all code with exceptions when many people spent many hours to have code which does not uses exceptions is kind waste .. and still compile many programs with exceptions only causes that executable code is puffier. As you know even gcc is not compliant with above :) What about use -fno-rtti if it is possible to use it? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On Thu, 21 Mar 2019 at 11:37, Stephen John Smoogen wrote:
[..]
> > Even gcc themselves "is not written with recent gcc in mind".
> >
> > $ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
> > $1}'|sort | uniq -c | sort -nr| head -n 20
> > 485 -Wmissing-profile
> > 106 -Wformat-security
> > 81 -Wmaybe-uninitialized
> > 44 -Wimplicit-fallthrough=
> > 24 -Wunused-function
> > 20 -Wpointer-sign
> > 20 -Wimplicit-function-declaration
> > 19 -Wstringop-truncation
> > 8 -Wformat-truncation=
> > 8 -Wcast-qual
> > 7 -Wcast-function-type
> > 4 -Wcpp
> > 4 -Wbuiltin-declaration-mismatch
> > 3 -Wparentheses
> > 2 -Wunused-value
> > 2 -Wunused-parameter
> > 2 -Wmissing-prototypes
> > 2 -Wmisleading-indentation
> > 2 -Wint-to-pointer-cast
> > 2 -Wdiscarded-qualifiers
> >
> > BTW: each Fedora package build should have as part of the build report
> > something like above.
> >
>
> Could you explain why it should? I am not sure what those flags
> actually mean and why it would tell me anything about a package build.
> If upstream decides that libX needs to be compiled with
> -Wmissing-prototypes but nothing else.. what is it to me?
That list is not in order of importance but how often some warning
happened, and I think that you are fully aware that on that list are
things far more important than missing prototype.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G
On Thu, 21 Mar 2019 at 09:07, Zbigniew Jędrzejewski-Szmek
wrote:
[..]
> The effect of "-Wformat -Wformat-security" without -Werror is only more
> warnings.
> Unfortunately -Wformat will generate spurious warnings if the code is
> not careful to give additional information to the compiler with
> __attribute__((__format__(printf))) and friends. And even that sometimes
> not enough, and explicit #pragma GCC diagnostic ignored "-Wformat-nonliteral"
> is needed. So all in all, it is totally expected that code which is not
> written with recent gcc in mind will generate spurious format warnings, even
> if the code is completely OK. So turning this on will make builds more
> noisy, and possibly break projects which use -Werror.
Even gcc themselves "is not written with recent gcc in mind".
$ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
$1}'|sort | uniq -c | sort -nr| head -n 20
485 -Wmissing-profile
106 -Wformat-security
81 -Wmaybe-uninitialized
44 -Wimplicit-fallthrough=
24 -Wunused-function
20 -Wpointer-sign
20 -Wimplicit-function-declaration
19 -Wstringop-truncation
8 -Wformat-truncation=
8 -Wcast-qual
7 -Wcast-function-type
4 -Wcpp
4 -Wbuiltin-declaration-mismatch
3 -Wparentheses
2 -Wunused-value
2 -Wunused-parameter
2 -Wmissing-prototypes
2 -Wmisleading-indentation
2 -Wint-to-pointer-cast
2 -Wdiscarded-qualifiers
BTW: each Fedora package build should have as part of the build report
something like above.
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: Fedora 30 Beta blocker status mail #4
On Fri, 15 Mar 2019 at 21:32, Ben Cotton wrote: > The Fedora 30 Beta Go/No-Go meeting is next week: > https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/21/#m9491 Still mdadm is not even compiling on current fc30. So no one cares that upcoming fc30 will deliver binaries from fc29? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: HEADS UP: dhcp will ship bunded bind libraries
On Thu, 28 Feb 2019 at 14:11, Neal Gompa wrote: [..] > > tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring > > dhcp-libs-static with bundled version of libisc/libdns/etc > > > > As ISC dropped support of single thread build of BIND libraries [1] and > > dhcp requires one we decided to not patch dhcp/bind build scripts anymore > > and ship bundled bind libraries just like upstream (ISC) does it. It will > > allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be > > expected in rawhide/F31 soon! > > I'm aware of FPG recommendation to avoid shipping of bundled libraries due > > to its maintenance cost but maintaining of heavy patched build sctipts and > > inability to ship newer versions are even worse. > > > > I have not find any application in Fedora repository which link with > > libdhcp/libomapi. Please let me know if you aware of any. > > > Just add the bundled() Provides if it's building with bundled copies, > per the policy: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling I'm only curious (maybe I do not understand something about this issue) .. why dhcpd cannot use standard glibc resolver? IIRC glibc libresolve is thread safe (if this issue it is about thread safe DNS resolution). Can someone explain that topic a bit? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
On Fri, 8 Mar 2019 at 17:37, Kevin Fenzi wrote: [..] > >> There's no glitch I am aware of, so more information would be helpful. > > > > This seems quite OK: > > > > https://admin.fedoraproject.org/mirrormanager/propgation > > > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 > > Well, perhaps you looked at it too soon? > > Right now it's slowly showing mirrors catching up over the last 12 hours > or so. More than 24h later and I'm still not able to find even one European mirror with synced source packages :/ Checked few in US and Canada and situation is the same. Almost half of those mirrors which I've checked are stuck in the same day in the middle of August 2018. Another ~30% are stuck on 17 Feb. It is really hard to believe that on all those out of sync mirrors admins stopped syncing rawhide in one of the two possible days simultaneously. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
On Fri, 8 Mar 2019 at 00:37, Stephen John Smoogen wrote: [..] > We don't push to mirrors. They sync from either our main servers or a > tier 1 or tier 2 mirror which also pull/rsync from the master mirrors. > This means it will take time to get stuff down and out. So like I > said.. do not expect various mirrors to be in sync until Monday at the > latest. The more people trying to get stuff which isn't there just > makes this longer as they are usually getting resource limitations. I must be somehow extremely unlucky because after checking +two dozens of the mirrors from https://admin.fedoraproject.org/mirrormanager/mirrors/Fedora/development available over rsync in UK, Poland, Netherlands, France and US I dd not found even one synced :/ Interesting only is that they are all stopped synchronisation in the middle of the Aug 2018 or 17 Feb 2019. Can someone help and point on mirror accessible over rsync which is up-to-date? Today after clean dnf caches again and rerun upgrade seems like at least indexes are propagated correctly however: Transaction Summary = Install 42 Packages Upgrade489 Packages Remove 3 Packages Total download size: 841 M DNF will only download packages for the transaction. Downloading Packages: [MIRROR] gdm-3.31.91-1.fc31.x86_64.rpm: Status code: 404 for https://mirror.vorboss.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm [FAILED] gdm-3.31.91-1.fc31.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success (2-3/582): gdm-devel-3.31.91-1.fc31.x86_64.rpm 0% [] 103 kB/s | 509 kB139:10 ETA The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Error downloading packages: Cannot download Packages/g/gdm-3.31.91-1.fc31.x86_64.rpm: All mirrors were tried Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync DNF version: 4.1.0 kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
-- Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: http://lnkd.in/FXPWxH On Thu, 7 Mar 2019 at 20:37, Miro Hrončok wrote: [..] > > What ground/public repos do you mean here? The master mirror is > > definitely updated. It's a large pile of changes, so other mirrors may > > take a bit longer than normal to sync. > > > > There's no glitch I am aware of, so more information would be helpful. > > This seems quite OK: > > https://admin.fedoraproject.org/mirrormanager/propgation > > Yet all the mirrors I try randomly show Fedora-Rawhide-20190217.n.0 For example: ftp://ftp.icm.edu.pl/pub/linux/dist/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ ftp://mirror.de.leaseweb.net/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/ Just done "dnf clean all" and on "dnf upgrade -vv" have warnings: repo: downloading from remote: rawhide error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/c1cd3e4d1a46c4f79315b068f1d5a62b36ccc4b5352ac8ac09da1fa56c140296-primary.xml.gz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/c1cd3e4d1a46c4f79315b068f1d5a62b36ccc4b5352ac8ac09da1fa56c140296-primary.xml.gz). error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/7a5d0a2faa3893e6554b0dfcc7f14f4757e3e0b96579d53e64aefe8b7994070c-filelists.xml.gz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/7a5d0a2faa3893e6554b0dfcc7f14f4757e3e0b96579d53e64aefe8b7994070c-filelists.xml.gz). error: Status code: 404 for http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/0890e446db7e56de5765c414d7880997ff6dc809b850c766d18ed1ac32167824-comps-Everything.x86_64.xml.xz (http://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/repodata/0890e446db7e56de5765c414d7880997ff6dc809b850c766d18ed1ac32167824-comps-Everything.x86_64.xml.xz). Fedora - Rawhide - Developmental packages for the next Fedora release 3.3 MB/s | 61 MB 00:18 not found other for: Fedora - Rawhide - Developmental packages for the next Fedora release not found modules for: Fedora - Rawhide - Developmental packages for the next Fedora release not found deltainfo for: Fedora - Rawhide - Developmental packages for the next Fedora release not found updateinfo for: Fedora - Rawhide - Developmental packages for the next Fedora release rawhide: using metadata from Sun 17 Feb 2019 08:11:02 GMT. ^^^^^^^^^^^^ here kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora rawhide compose report: 20190306.n.1 changes
On Thu, 7 Mar 2019 at 12:17, Fedora Rawhide Report wrote: > > OLD: Fedora-Rawhide-20190217.n.0 > NEW: Fedora-Rawhide-20190306.n.1 > > = SUMMARY = > Added images:13 > Dropped images: 7 > Added packages: 128 > Dropped packages:174 > Upgraded packages: 1745 > Downgraded packages: 165 Looks like it is second or third time when after report about release some batch of the packages nothing hit the ground/public repos. My understanding is that it is some glitch in release infrastructure. May we know what is the current situation? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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: Fedora 30 Beta blocker status mail #1
On Fri, 22 Feb 2019 at 19:37, Ben Cotton wrote: > As we've now reached the branch point, it's time to start weekly > blocker status mails. > mdadm does not compile on fc30 https://koji.fedoraproject.org/koji/getfile?taskID=32819259=DEFAULT=build.log=-4000 https://koji.fedoraproject.org/koji/taskinfo?taskID=32819232 It would be really good if someone would create list of packages which build failed on last fc30 MR. kloczek -- Tomasz Kłoczko | http://lnkd.in/FXPWxH ___ 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
Dead packages are still in rawhide tree
SO for example few days ago mongodb has been officially removed from Fedora and in git repo is only dead.package file: https://src.fedoraproject.org/rpms/mongodb/tree/master However binary and source packages are still in public repository: https://www.mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/SRPMS/Packages/m/ The same situation is with few hundreds of other packages. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* ___ 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: Question about gcc test suite failures
On Wed, 20 Feb 2019 at 14:51, Jakub Jelinek wrote: [..] > The aim is to avoid regressions, not zero FAIL rate, which e.g. for the > guality testcase is not really possible as the testing matrix is too large > for debug info coverage, -O levels x targets x ISA choices x GDB issues > and it is impossible to encode that into xfails. > Plus, the rpm builds test both normally and with additional > -fstack-protector-strong as that is what the whole distro does, while > normally the latter isn't included. So, some FAILs might be once with > normal options and once with -fstack-protector-strong, other tests only > FAIL > with the latter e.g. when testing asan and having UB in the test to test it > how asan handles it and -fstack-protector-strong may stand in a way of > that. > There are some flakey tests too (mostly in the go testsuite). > > So, I have a directory with years of testsuite results from koji/brew > builds, essentially build logs from all the architectures massaged through > sed -n -e '/^==*TESTING/,/^==*TESTING END/p' > and compare that regularly for new builds. > OK. Jakub so what kind of method you are using to recognise that something is wrong with gcc/gdb/binutils if none of those packages test suites seems may exit with non-zero exit code and some failures are perfectly OK? (Or maybe logic of the suite should be negated?) Do you have some sort of script/tool extracting results from build logs? or it is some other method? Syntax of the content /^==*TESTING/,/^==*TESTING END/p' looks a bit complicated .. How to trace those results in more or less automated way? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
Question about gcc test suite failures
Recently I've been trying to trace some gcc issue so I've downloaded my gcc src.rpm to try to build my own package. During review build log I found a lot of test suite failures. Initially I've been thinking that something is wrong with my devel env so I've peaked on official gcc build logs and I found that I have even less such failures than number of such issues on rawhide builders. Mine package: $ grep ^FAIL: -c gcc.out 780 Vs. official: $ curl -s https://kojipkgs.fedoraproject.org//work/tasks/681/32910681/build.log | grep -c FAIL: 1114 Some of those failures seems are expected as I'm able to find in my build log fragments like: === gnat Summary for unix/ === # of expected passes2976 # of expected failures 23 # of unsupported tests 3 However I found other like: === gcc Summary for unix/ === # of expected passes143765 # of unexpected failures101 # of unexpected successes 25 # of expected failures 554 # of unsupported tests 2225 Did all those unexpected failures are symptoms some not finished modifications and/or not updated test units or those failures says that something really is wrong with gcc? At the moment I'm not sure but I think that similar situation is with binutils but I think that generally during my build I saw a lot of failures. All together all those tests have been ignored and package build was successful. kloczek -- Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>* ___ 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: Ditch RPM in favor of DPKG
On Tue, 19 Feb 2019 at 11:11, Dridi Boukelmoune wrote: [..] > Apt is a mix of C, Perl and C++ code, so I would be reassured if I > could have a C++ co-maintainer too. I'm only a C developer so if > something goes wrong outside of the C realm that would be helpful. > Doesn't matter in what kind of language is written PM. Probably you are not aware that but initially rpm it was written 100% in perl. Nevertheless forget about such change. DPKG technologically stopped evolving about +15 years ago and today rpm packages relies on many features never implemented in DPKG (not only on area of managing installed/upgraded software but building packages as well). In other words: move from rpm to dpkg would be only a lot of effort spent to make happier really small bunch of people increasing only effort for the rest of packagers and package consumers. What I see which potentially could make a sense would be writing rpm backend to generate deb packages out of spec files. That would be beneficial for part of the Debian community the same way as using rpm spec files to build IPS packages on Solaris. Such goal is possible to archive the same way as in case of IPS by writing short wrapper like that on on http://pkgbuild.sf.net/ Fill free to code such tool .. you have already spec file parser and other bits written so >=80-90% necessary work is already done. As long as it has nothing to do with Fedora for me EOT. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
FC30 Mass Rebuild still not finished
Hi,
Looks like MR which started two weeks ago still is not fully finished.
Below command has been executed in mirrored rawhide source packages tree.
[tkloczko@domek fedora]$ for i in fc{21..30}; do echo "$i $(ls -1
*/*$i.src.rpm | wc -l)"; done; echo; ls -1 ?/*|wc -l
fc21 16
fc22 15
fc23 21
fc24 80
fc25 12
fc26 61
fc27 79
fc28 223
fc29 14133
fc30 25760
[tkloczko@domek fedora]$ find . -mtime +14 | wc -l; ls -1 ?/* | wc -l
20746
40616
Looks like only about half packages actually have been rebuild.
Possible cause: failing Fedora build infra like in rebuild of the mc
package:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32784400
Is it any plan to resend all those pending build requests?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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: signing status
On Sun, 10 Feb 2019 at 21:17, Kevin Fenzi wrote: > Just wanted to update everyone on our current status. > > As you know from the other thread: > > * The mass rebuild happened and finished. > Is there anywhere some summary stats about mass update? How many packages has been sent to rebuild vs those which rebuild failed? kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ 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
