Re: postgis LTO failure
On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote: > Hi > > postgis seems another one suffering from LTO related failures. > > LTO (results in test failures): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 > > LTO disabled (tests pass): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173 I've been able to reproduce the testsuite failure. I'll try to take it from here. Thanks, jeff > ___ 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
[389-devel] 389 DS nightly 2020-08-02 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2020/08/02/report-389-ds-base-1.4.4.4-20200801git594bf91.fc32.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d4ceeda8e java-latest-openjdk-14.0.2.12-1.rolling.el8 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-cf43d780cc chromium-84.0.4147.89-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2b702ad070 rpki-client-6.7p1-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88b5647c18 radare2-4.5.0-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6ba549ab3a ark-19.12.2-2.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing rdiff-backup-2.0.5-2.el8 Details about builds: rdiff-backup-2.0.5-2.el8 (FEDORA-EPEL-2020-b7e8ce7788) Convenient and transparent local/remote incremental mirror/backup Update Information: Last bug-fix before code clean-up ChangeLog: * Sat Aug 1 2020 Frank Crawford 2.0.5-2 - Bump to separate from COPR build * Wed Jul 29 2020 Fedora Release Engineering - 2.0.3-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Jul 25 2020 Frank Crawford 2.0.5-1 - Last bug-fix before code cleanu-up ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 718 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 457 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 167 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2c80eb66b5 libASL-0.1.7-6.el7 matio-1.5.17-3.el7 openmeeg-2.4-0.4.rc4.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-452d014b82 java-latest-openjdk-14.0.2.12-1.rolling.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c9e7aa6a08 chromium-84.0.4147.89-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-489c36a241 snmptt-1.4.2-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-90cbb3a9ff golang-1.13.14-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-32e4ca563b rpki-client-6.7p1-1.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2a93add193 python34-3.4.10-6.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing rdiff-backup-2.0.5-2.el7 Details about builds: rdiff-backup-2.0.5-2.el7 (FEDORA-EPEL-2020-43359db8cd) Convenient and transparent local/remote incremental mirror/backup Update Information: Last bug-fix before code clean-up ChangeLog: * Sat Aug 1 2020 Frank Crawford 2.0.5-2 - Bump to separate from COPR build * Wed Jul 29 2020 Fedora Release Engineering - 2.0.3-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Sat Jul 25 2020 Frank Crawford 2.0.5-1 - Last bug-fix before code cleanu-up ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: postgis LTO failure
On Sun, 2020-08-02 at 00:36 +0200, Sandro Mani wrote: > Hi > > postgis seems another one suffering from LTO related failures. > > LTO (results in test failures): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 > > LTO disabled (tests pass): > https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173 Thanks. I'll take a look, but note that I've never managed to get postgis to build with or without LTO. It complains with an odd error: make[1]: *** [Makefile:177: liblwgeom.la] Error 139 make[1]: Leaving directory '/builddir/build/BUILD/postgis-3.0.1/liblwgeom' make: *** [GNUmakefile:20: all] Error 1 There's nothing else useful in the logs that I see. But again, I'll take a look and see if I can figure out what's going on. In the mean time, feel free to go ahead and disable LTO as I can't currently give any guidance on what might be going wrong. jeff > ___ 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: Another possible LTO failure in guestfish (or maybe readline)
On Sat, 2020-08-01 at 15:26 -0700, Kevin Fenzi wrote: > On Sat, Aug 01, 2020 at 02:03:40PM -0600, Jeff Law wrote: > > On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote: > > > Hi, > > > > > > seeing the amount of fallout from LTO, I really think that this feature > > > ought to be dropped from F33, and evaluated carefully for F34 (i.e., can > > > it > > > be done without breaking the build of or miscompiling a large part of the > > > distribution, once the bugs such as the ld bug discussed in this thread > > > are > > > fixed, or is it just unsafe to enable by default to begin with?). I.e., > > > revert it for F33 for sure, then decide whether to retry it for F34 or > > > can > > > it permanently. > > Most of the fallout has been Nick pushing through binutils builds that are > > broken. Seriously, there's been at least 4 builds pushed through that kept > > bringing back the *same* problem. > > > > And just to be clear, this has been 6+ months of behind the scenes work to > > find > > and identify issues, fix broken packages, put global mitigations of broken > > crap > > in place in place, opt-out packages that do things that are fundamentally > > incompatible with LTO, etc. In fact it was that behind-the-scenes work that > > pushed this feature from F32 to F33 as it just wasn't ready to go in F32. > > > > I think the chances of a serious mis-compilation large parts of the > > distribution > > are small. The one mis-compilation we know about was a latent linker bug > > that > > just happened to be triggered by LTO and that particular bug we know how to > > identify any packages that might have been broken. > > > > Frankly, there's been more fallout from infrastructure breakage and cmake > > issues > > than anything. I went through the first ~1000 failures proactively looking > > for > > things that were potentially LTO related and fixing them half-dozen or so I > > found, but by far the s390 infrastructure and cmake changes have caused more > > failures than anything. > > > > As has always been the case, I'm here to address any problems that arise > > and use > > my 30 years of experience with GCC development as well as distribution mass > > rebuilds to make informed decisions about the best course of action for any > > particular problem. > > Yeah, the s390x failures were anoying. I have several ideas to make > things more robust that hopefully we can do before next mass rebuild: > > * move the cache host from a z/vm instance to a kvm one. > * We have the kvm ones oversubscribed on cpus, so I'd like to drop all > of them from 4 cpus to 3. > * We might play with the weight on them so koji doesn't run as many jobs > at a time as it does now. > * Make sure ci/koji-simple-ci/koschei isn't doing any long running > builds when the mass rebuild starts. A gcc or libreoffice build can take > up a builder for a long time. > * Run the mass rebuild with --fail-fast so if something fails on some > other arch, it never even needs to run on s390x. > > Anyhow, the mass rebuild is over and tagged in. Rawhide compose is > running and should hopefully finish later today. > > The second pass took failures from 4162 to 2833, so that helped > a lot: https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html Cool. Thanks for the update. I'll start scanning through those. It looks like some of the cmake things are getting addressed which I'm sure helps too. Jeff > ___ 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: libcroco retired on Rawhide, breaking builds
Gary Buhrmaster wrote: > On Sat, Aug 1, 2020 at 9:23 PM Kevin Kofler > wrote: >> Especially the CMake one was completely pointless. > > The goal was not pointless, but I will assert that the > implementation was flawed in practice. The goal was to make more packages do out-of-source builds, which is a build-time-only implementation detail that should theoretically have no effect whatsoever on the produced packages (though, in practice, at least the directory structure of the -debugsource packages will be different). Hence, an end user will probably not notice any difference whatsoever, which is why I call the change pointless. I also do not believe that the change really makes things easier for packagers, just different. And different is bad when it means that dozens of specfiles have to be adapted to such an incompatible change. The boilerplate to do an out-of-source build (even with ancient versions of CMake that did not have the -S and -B options) was very simple and widely used. I also think that it is more valuable to be backwards-compatible with older versions of Fedora (and where possible, also with RHEL/CentOS and EPEL) than to be compatible with other, unrelated distributions that happen to also use RPM. The CMake change, on the other hand, improved cross-compatibility with other distributions at the expense of backwards compatibility with our own distribution. LTO at least promises tangible benefits for the end user. But maybe it should have been opt-in (via the specfile) at first? Kevin Kofler ___ 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
postgis LTO failure
Hi postgis seems another one suffering from LTO related failures. LTO (results in test failures): https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 LTO disabled (tests pass): https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173 Thanks Sandro ___ 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
postgis LTO failure
Hi postgis seems another one suffering from LTO related failures. LTO (results in test failures): https://koji.fedoraproject.org/koji/taskinfo?taskID=48393090 LTO disabled (tests pass): https://koji.fedoraproject.org/koji/taskinfo?taskID=48394173 Thanks Sandro ___ 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: Another possible LTO failure in guestfish (or maybe readline)
On Sat, Aug 01, 2020 at 02:03:40PM -0600, Jeff Law wrote: > On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote: > > Hi, > > > > seeing the amount of fallout from LTO, I really think that this feature > > ought to be dropped from F33, and evaluated carefully for F34 (i.e., can it > > be done without breaking the build of or miscompiling a large part of the > > distribution, once the bugs such as the ld bug discussed in this thread are > > fixed, or is it just unsafe to enable by default to begin with?). I.e., > > revert it for F33 for sure, then decide whether to retry it for F34 or can > > it permanently. > Most of the fallout has been Nick pushing through binutils builds that are > broken. Seriously, there's been at least 4 builds pushed through that kept > bringing back the *same* problem. > > And just to be clear, this has been 6+ months of behind the scenes work to > find > and identify issues, fix broken packages, put global mitigations of broken > crap > in place in place, opt-out packages that do things that are fundamentally > incompatible with LTO, etc. In fact it was that behind-the-scenes work that > pushed this feature from F32 to F33 as it just wasn't ready to go in F32. > > I think the chances of a serious mis-compilation large parts of the > distribution > are small. The one mis-compilation we know about was a latent linker bug that > just happened to be triggered by LTO and that particular bug we know how to > identify any packages that might have been broken. > > Frankly, there's been more fallout from infrastructure breakage and cmake > issues > than anything. I went through the first ~1000 failures proactively looking > for > things that were potentially LTO related and fixing them half-dozen or so I > found, but by far the s390 infrastructure and cmake changes have caused more > failures than anything. > > As has always been the case, I'm here to address any problems that arise and > use > my 30 years of experience with GCC development as well as distribution mass > rebuilds to make informed decisions about the best course of action for any > particular problem. Yeah, the s390x failures were anoying. I have several ideas to make things more robust that hopefully we can do before next mass rebuild: * move the cache host from a z/vm instance to a kvm one. * We have the kvm ones oversubscribed on cpus, so I'd like to drop all of them from 4 cpus to 3. * We might play with the weight on them so koji doesn't run as many jobs at a time as it does now. * Make sure ci/koji-simple-ci/koschei isn't doing any long running builds when the mass rebuild starts. A gcc or libreoffice build can take up a builder for a long time. * Run the mass rebuild with --fail-fast so if something fails on some other arch, it never even needs to run on s390x. Anyhow, the mass rebuild is over and tagged in. Rawhide compose is running and should hopefully finish later today. The second pass took failures from 4162 to 2833, so that helped a lot: https://kojipkgs.fedoraproject.org/mass-rebuild/f33-failures.html kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: module build: BuildrootError: could not init mock buildroot
On Fri, Jul 31, 2020 at 04:05:20PM +0200, Jun Aruga wrote: > Hi, > Sometimes once per a few times, I faced the following weird build > error when building Ruby modules. > Did you see it? Known issue? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48194471 > BuildrootError: could not init mock buildroot, mock exited with status > 20; see root.log for more information > > https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/root.log > => looks ok. > https://kojipkgs.fedoraproject.org//work/tasks/4473/48194473/build.log > => empty. > Weird. The actual error is: "ERROR: Could not find useradd in chroot, maybe the install failed?" But that sounds like what happens when it didn't install the build rpms in there. Can you try again now? we fixed a major issue with mbs, which I wouldn't think was related to this, but who knows... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
On Sat, Aug 1, 2020 at 9:23 PM Kevin Kofler wrote: > Especially the CMake one was completely pointless. The goal was not pointless, but I will assert that the implementation was flawed in practice. I would suggest that a lesson to be learned is that changes that are expected to require updates to > 256(*) packages OR any of the core set of packages, MUST target completion of those updates BEFORE the mass rebuild schedule (and not target the beta release, as this one did). Such requirements would likely either force the change to be less impactful to existing packages and packagers(**), or force the proposers to do the work they committed to accomplish much earlier in the process (or, perhaps more likely, push it off for another release). Hindsight is 20/20, so this is a lesson for the next time (and there will always be a next time). (*) Arbitrary power of two. Pick a different value if you wish. The point is when the proposal says the change may impact > 2**10 packages, that should have raised a flag of some color. (**) Many people have suggested alternative implementations that would have supported allowing existing packages/packagers more time to complete the transition(s), and at least a few were likely viable, although it would have extended the entire process time frame. ___ 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
[Test-Announce] Proposal to CANCEL: 2020-08-03 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting for Monday. I don't have anything urgent this week, and it's a vacation day in Canada. If you're aware of anything important we have to discuss this week, please do reply to this mail, but someone else will need to run the meeting :) I can't run a blocker review meeting either. There are three proposed Beta blockers, we can either wait for next week, vote in-bug, or someone else can run a meeting. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@lists.fedoraproject.org ___ 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 Fedora wiki system sucks
On Sat, 2020-08-01 at 13:18 -0500, Richard Shaw wrote:
> On Sat, Aug 1, 2020 at 1:10 PM Adam Williamson
> wrote:
>
> > On Sat, 2020-08-01 at 12:00 -0500, Richard Shaw wrote:
> > > So I wanted to document a ham radio related howto, so I decided that I
> > > would make it an extension of the Amateur Radio SIG wiki, and I've got an
> > > incomplete version created:
> > >
> > > https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat
> > >
> > > How can a wiki not have some kind of tag?
> >
> > Use {{code|}}, , or just add any number of spaces before each line
> > of the code segment (even one space works).
> >
>
> Yup, got me going for now.
>
>
>
> > > Most other systems in Fedora support markdown, and I would be a fan of
> > > that.
> >
> > wikitext predates markdown by several years. mediawiki first appeared
> > in 2001 and wikitext developed along with it, Markdown was invented in
> > 2004. wikitext is quirky because of its age, development history, and
> > the fact that it's actually more than just markup, it has quite
> > extensive dynamic capabilities (particularly with extensions like
> > https://www.mediawiki.org/wiki/Extension:ParserFunctions , which we
> > have in our instance).
> >
>
> Yeah, the whole interface does look rather "dated", perhaps it's time to
> start looking at a successor?
I don't think there really are any that are particularly more 'modern'
or less quirky than mediawiki. Project wikis in general are going out
of style these days (the infra team would quite like to get rid of
ours, but I won't let them :>) A lot of the reason the wiki is still
around is people (like me...) doing advanced stuff with templates and
ParserFunctions which probably wouldn't be easily transferable to any
other software either.
> > If what you're writing falls under the general heading of
> > 'documentation', you might want to write it for docs.fedoraproject.org
> > rather than the wiki. docs.fp.o is built by a static generator and uses
> > the ASCIIDoc markup language. See
> >
> > https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/
>
>
> Perhaps... Is docs open? Or is there some process for getting this
> approved? I'm heavily making updates right now. I'm somewhat
> selfishly documenting it so I remember how I set everything up as I'm sure
> I won't remember a year from now :) But figured it's worth documenting for
> others as well.
I don't really interact with it much myself, I use the wiki more. So
that page is really all I know. You could contact the docs team on IRC
for more details I guess, if no-one else answers this thread.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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
[Bug 1862721] New: perl-MCE-1.873 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1862721 Bug ID: 1862721 Summary: perl-MCE-1.873 is available Product: Fedora Version: rawhide Status: NEW Component: perl-MCE Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.873 Current version/release in rawhide: 1.868-1.fc33 URL: http://search.cpan.org/dist/MCE/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/5965/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
Michael J Gruber wrote: > I think we should test build with changes like cmake or LTO in isolation > from the typical mass rebuild which exposes many other problems. I think we should just not do this kind of changes that mass-break packages at all. Especially the CMake one was completely pointless. Kevin Kofler ___ 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: We have to talk about annobin... again
Neal Gompa wrote: > Then there'd be the problem of where we'd have the build capacity. We > barely have enough for what we do now... To be honest, I would just ignore the modules and do the side tag rebuilds only for the non-modular Rawhide, and only once a month or so. Kevin Kofler ___ 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: Another possible LTO failure in guestfish (or maybe readline)
On Sat, 2020-08-01 at 21:00 +0100, Richard W.M. Jones wrote:
> On Sat, Aug 01, 2020 at 01:28:09PM -0600, Jeff Law wrote:
> > On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote:
> > > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote:
> > > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > > > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > > > > Looks like it's in the buildroots now. Let me know if that doesn't
> > > > > > fix the
> > > > > > problem.
> > > > >
> > > > > Looks as if "ar" is segfaulting again ...
> > > > >
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > > > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > > > >
> > > > > That was built with binutils 2.35-8.fc33
> > > > Just an FYI binutils-2.35-9 is in the buildroots. It's got the fix for
> > > > the LTO
> > > > issue, but does not turn on LTO for binutils itself (that'll be in the
> > > > -10
> > > > build).
> > > >
> > > > I've confirmed that the -9 build will correctly build binutils-2.35-10.
> > > > I've
> > > > also confirmed that the -9 build will correctly build libguestfs.
> > > >
> > > > I'm going to take my local -10 build and use that to build libguestfs
> > > > as an
> > > > additional sanity check.
> > >
> > > Can confirm that libguestfs has been built correctly and is working (with
> > > LTO).
> > >
> > > FYI I filed this bug about LTO and inheriting warnings in functions
> > > inlined across files:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
> > Yes, that's by design. Conceptually the compiler doesn't really know that
> > the
> > pragma refers to any particular function since they don't appear in any
> > function
> > scope. ASMs outside function scope have similar issues.
> >
> > You could try moving the pragmas into function scope.
>
> I'm not sure exactly what you mean, but this doesn't work (same
> error as before):
>
> --- test.c ---
>
> #include
>
> int
> test (int i)
> {
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wstack-usage="
>
> char str[i];
> memset (str, 0, sizeof str);
> return str[0]+i;
>
> #pragma GCC diagnostic pop
> }
Yea, that's precisely what I meant and precisely what I feared wouldn't work
(I'd
tried it with one of mjw's packages trying to address the same issue). Nor will
it work if you move the pragmas so that they enclose the call site where test
gets inlined.
Given this works with other warnings, I wonder if there's some unexpected
implementation detail with -Wstack-usage= on the GCC side. I'll look at it next
week.
jeff
___
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: Another possible LTO failure in guestfish (or maybe readline)
On Sat, 2020-08-01 at 12:12 +0200, Kevin Kofler wrote: > Hi, > > seeing the amount of fallout from LTO, I really think that this feature > ought to be dropped from F33, and evaluated carefully for F34 (i.e., can it > be done without breaking the build of or miscompiling a large part of the > distribution, once the bugs such as the ld bug discussed in this thread are > fixed, or is it just unsafe to enable by default to begin with?). I.e., > revert it for F33 for sure, then decide whether to retry it for F34 or can > it permanently. Most of the fallout has been Nick pushing through binutils builds that are broken. Seriously, there's been at least 4 builds pushed through that kept bringing back the *same* problem. And just to be clear, this has been 6+ months of behind the scenes work to find and identify issues, fix broken packages, put global mitigations of broken crap in place in place, opt-out packages that do things that are fundamentally incompatible with LTO, etc. In fact it was that behind-the-scenes work that pushed this feature from F32 to F33 as it just wasn't ready to go in F32. I think the chances of a serious mis-compilation large parts of the distribution are small. The one mis-compilation we know about was a latent linker bug that just happened to be triggered by LTO and that particular bug we know how to identify any packages that might have been broken. Frankly, there's been more fallout from infrastructure breakage and cmake issues than anything. I went through the first ~1000 failures proactively looking for things that were potentially LTO related and fixing them half-dozen or so I found, but by far the s390 infrastructure and cmake changes have caused more failures than anything. As has always been the case, I'm here to address any problems that arise and use my 30 years of experience with GCC development as well as distribution mass rebuilds to make informed decisions about the best course of action for any particular problem. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
On Sat, Aug 1, 2020 at 6:43 AM Artem Tim wrote: > > @Chris, thanks, i did some tests and now we have some numbers. tl;rd the > results is pretty satisfying me, even if there no speedup in my case, but > there is a lot disk space could be saved and reduce writes. Probably not > worth file a bug, but a little bit weird that with zstd:1 still a little bit > slower on HDD and on SSD speed equal. Your results look consistently faster with compression, whether HDD or SSD. > ## Results (HDD) > > ### Compression:lzo > Took: 6m53s > ### Compression:zstd:1 > Took: 7m5s > ### Compression:none > Took: 7m18s > > ## Results (SSD) > > ### Compression:lzo > Took: 2m26s > > ### Compression:zstd:1 > Took: 2m26s > ### Compression:none > Took: 2m24s There are quite a lot of complexities when benchmarking compression with workloads. The compression CPU hit is bigger than decompression, and also the decompression cpu and performance is fairly invariant to the level used for compression. This generally means we're more likely to be concerned about negatively impacting max write performance. Some compiles, while they involve lots of writes, don't ever reach the max write rate capability of storage, but are very CPU bound processes. Is it the small amount of CPU, or context switches, that impacts the writes? I don't know. Whereas for ~/.cache - for example Firefox and Chrome, these are tons of small file writes happening all the time and the less to flush the better, and also the less to read later on the better. This might be a good candidate for compression, as well as /var /etc /usr. None of those experience heavy writes that are also time sensitive, about the heaviest is a system upgrade and since those take long enough most folks walk away from them anyway, it might not be a big deal if took slightly longer, although so far I haven't seen that happen. I think the most common case where compression can slow things down is heavy writes to very fast media like NVMe. The NVMe writes are simply faster. And yet, I run compress=zstd:1 on NVMe all day long for all workloads and at least anecdotally it seems no different than without compression or using plain ext4 - and for sure it's all more responsive than when I reboot this same hardware and use Windows 10. I'll summarize 2 of the 4 ways to do compression by default on Fedora, that I've thought of so far. https://bugzilla.redhat.com/show_bug.cgi?id=1851276 a. Anaconda %pre-install script to (1) create /etc /var /usr (2) set a compression zstd XATTR on them. Everything inherits this as the installation happens. b. Anaconda kickstart `--fsoptions compress=zstd:1` will cause that mount option to be used for the installation and add it to fstab. Use %post install script to set a NOCOMPRESS flag on /home. These are not identical, but approximately equivalent. Perhaps the most significant difference is the visibility of the compression option in fstab. This might be a good thing or bad thing, depending on whether the user thinks this compression is happening system wide or not. The other difference is that with the (b) option, any new subvolumes created inside /home do *not* inherit NOCOMPRESS. Should it? Well that's a different conversation, I've gone back and forth on it myself and can argue it both ways, but generally I think maybe it shouldn't inherit because ostensibly a subvolume is a dedicated/independent files tree and should instead inherit file system defaults (and mount options modifying them) rather than XATTR inheritance rules. All of this is already implemented in the installer, so no churn there. -- Chris Murphy ___ 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: Another possible LTO failure in guestfish (or maybe readline)
On Sat, Aug 01, 2020 at 01:28:09PM -0600, Jeff Law wrote:
> On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote:
> > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote:
> > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote:
> > > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote:
> > > > > Looks like it's in the buildroots now. Let me know if that doesn't
> > > > > fix the
> > > > > problem.
> > > >
> > > > Looks as if "ar" is segfaulting again ...
> > > >
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440
> > > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log
> > > >
> > > > That was built with binutils 2.35-8.fc33
> > > Just an FYI binutils-2.35-9 is in the buildroots. It's got the fix for
> > > the LTO
> > > issue, but does not turn on LTO for binutils itself (that'll be in the -10
> > > build).
> > >
> > > I've confirmed that the -9 build will correctly build binutils-2.35-10.
> > > I've
> > > also confirmed that the -9 build will correctly build libguestfs.
> > >
> > > I'm going to take my local -10 build and use that to build libguestfs as
> > > an
> > > additional sanity check.
> >
> > Can confirm that libguestfs has been built correctly and is working (with
> > LTO).
> >
> > FYI I filed this bug about LTO and inheriting warnings in functions
> > inlined across files:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
> Yes, that's by design. Conceptually the compiler doesn't really know that the
> pragma refers to any particular function since they don't appear in any
> function
> scope. ASMs outside function scope have similar issues.
>
> You could try moving the pragmas into function scope.
I'm not sure exactly what you mean, but this doesn't work (same
error as before):
--- test.c ---
#include
int
test (int i)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstack-usage="
char str[i];
memset (str, 0, sizeof str);
return str[0]+i;
#pragma GCC diagnostic pop
}
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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
[EPEL-devel] Re: Continuing playground discussion
On Sat, 1 Aug 2020, Kevin Fenzi wrote: B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL. I find this less compelling because stream changes are supposed to be minor release changes, so typically not abi/api breaks or big version updates. In general epel8 stable packages should keep working fine when the next minor 8.x release comes out, so I don't know that this would be particualrly valuable. We have had a python update which affected a lot of package, and TUV have added lower versions of packages already in EPEL, so the minor releases are not that trivial for packagers. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: Another possible LTO failure in guestfish (or maybe readline)
On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote: > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > > > Looks like it's in the buildroots now. Let me know if that doesn't fix > > > > the > > > > problem. > > > > > > Looks as if "ar" is segfaulting again ... > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440 > > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log > > > > > > That was built with binutils 2.35-8.fc33 > > Just an FYI binutils-2.35-9 is in the buildroots. It's got the fix for the > > LTO > > issue, but does not turn on LTO for binutils itself (that'll be in the -10 > > build). > > > > I've confirmed that the -9 build will correctly build binutils-2.35-10. > > I've > > also confirmed that the -9 build will correctly build libguestfs. > > > > I'm going to take my local -10 build and use that to build libguestfs as an > > additional sanity check. > > Can confirm that libguestfs has been built correctly and is working (with > LTO). > > FYI I filed this bug about LTO and inheriting warnings in functions > inlined across files: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Yes, that's by design. Conceptually the compiler doesn't really know that the pragma refers to any particular function since they don't appear in any function scope. ASMs outside function scope have similar issues. You could try moving the pragmas into function scope. I've had some success with that, but not as much as I'd like. SuSE just disables all the warnings except those which are emitted by the front-end. I think that's a long term mistake, but I don't have much influence over that decision. Jeff ___ 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
[Bug 1862641] perl-Compress-Raw-Bzip2-2.096 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1862641 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Compress-Raw-Bzip2-2.0 ||96-1.fc33 Resolution|--- |RAWHIDE Assignee|jples...@redhat.com |p...@city-fan.org Doc Type|--- |If docs needed, set a value Last Closed||2020-08-01 19:23:13 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=48375099 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[Bug 1862640] perl-Compress-Raw-Zlib-2.096 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1862640 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Compress-Raw-Zlib-2.09 ||6-1.fc33 Resolution|--- |RAWHIDE Assignee|jples...@redhat.com |p...@city-fan.org Doc Type|--- |If docs needed, set a value Last Closed||2020-08-01 19:21:35 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=48375222 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: Continuing playground discussion
On Fri, Jul 31, 2020 at 03:13:00PM -0700, Troy Dawson wrote: > We were having a good discussion about epel8-playground in the > Steering Committee meeting this week. Since we ran out of time I'd > like to continue it via email. > > Most everyone agreed that playground is currently a bit of a mess and > it's hard to explain to end users what it is for, or when to use it. > It was also agreed that we need to decide on a plan of "this is what > playground is for" and then work to setup/cleanup/document things. > > There seemed to be two main opinions of what to set the plan to. > > A) epel8-playground is meant for package development and testing for > major changes. We stop doing the "build on both epel8 and > epel8-playground", and epel8-playground packages only get built from > the epel8-playground dist-git branch. Thats my preferred setup. Note that this will take some releng work to make it inherit right from epel8 and such. > B) epel8-playground is meant for future RHEL/CentOS testing, and thus > everything built in epel8-playground get's built off CentOS Stream. > We would continue the "build on both epel8 and epel8-playground" and > this would make sure packages would be able to build on the newer > RHEL. I find this less compelling because stream changes are supposed to be minor release changes, so typically not abi/api breaks or big version updates. In general epel8 stable packages should keep working fine when the next minor 8.x release comes out, so I don't know that this would be particualrly valuable. > Both of these plans would require epel8-playground cleanup, and > re-implementation. Both would require work. But the work would be > quite different with the different plans. So until we decide which > way to go, we don't know what to do. > > Thoughts on which plan to choose? Or if there is something different? A for me, not sure when I would have time to work on it, but I think thats best. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Re: The Fedora wiki system sucks
On Sat, Aug 1, 2020 at 1:10 PM Adam Williamson
wrote:
> On Sat, 2020-08-01 at 12:00 -0500, Richard Shaw wrote:
> > So I wanted to document a ham radio related howto, so I decided that I
> > would make it an extension of the Amateur Radio SIG wiki, and I've got an
> > incomplete version created:
> >
> > https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat
> >
> > How can a wiki not have some kind of tag?
>
> Use {{code|}}, , or just add any number of spaces before each line
> of the code segment (even one space works).
>
Yup, got me going for now.
> > Most other systems in Fedora support markdown, and I would be a fan of
> > that.
>
> wikitext predates markdown by several years. mediawiki first appeared
> in 2001 and wikitext developed along with it, Markdown was invented in
> 2004. wikitext is quirky because of its age, development history, and
> the fact that it's actually more than just markup, it has quite
> extensive dynamic capabilities (particularly with extensions like
> https://www.mediawiki.org/wiki/Extension:ParserFunctions , which we
> have in our instance).
>
Yeah, the whole interface does look rather "dated", perhaps it's time to
start looking at a successor?
> If what you're writing falls under the general heading of
> 'documentation', you might want to write it for docs.fedoraproject.org
> rather than the wiki. docs.fp.o is built by a static generator and uses
> the ASCIIDoc markup language. See
>
> https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/
Perhaps... Is docs open? Or is there some process for getting this
approved? I'm heavily making updates right now. I'm somewhat
selfishly documenting it so I remember how I set everything up as I'm sure
I won't remember a year from now :) But figured it's worth documenting for
others as well.
Thanks,
RIchard
___
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: libcroco retired on Rawhide, breaking builds
On Sat, Aug 01, 2020 at 06:35:30PM +0100, Richard W.M. Jones wrote: > On Sat, Aug 01, 2020 at 03:13:50PM +0200, Fabio Valentini wrote: > > On Sat, Aug 1, 2020 at 2:44 PM Richard W.M. Jones wrote: > > > > > > On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > > > > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it > > > > provides is used by libtextstyle.so.0, part of gettext. > > > > > > > > gettext is used by many many things. Please unretire libcroco, or > > > > rebuild gettext without it. > > > > > > Yes, can confirm this breaks the whole virt stack, again. Any > > > "Second build" that needs libvirt has been broken by this. > > > > > > I really think we should redo this whole mass rebuild from the start. > > > > > > Rich. > > > > Well, gettext-0.20.2-4.fc33 without the libcroco dependency has now > > been successfully built for f33-rebuild: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1574351 > > > > It looks like f33-rebuild doesn't use its own packages for the > > buildroot though, so anything using gettext is broken in both f33 and > > f33-rebuild :( > > Can we get gettext-0.20.2-4.fc33 tagged into the f33? I'd do it > > myself, if I was sure not to break anything ... would "koji tag > > f33-updates-candidate gettext-0.20.2-4.fc33" be enough? Yeah, I tagged it in a bit ago, sorry for not updating the list. > I don't know if this was done already, but libvirt is now installable > and I was able to build virt-v2v, so it seems I'm now able to build > the remaining virt packages. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48382603 > > https://kojipkgs.fedoraproject.org//work/tasks/2636/48382636/root.log > => gettext 0.20.2-4.fc33 > libvirt 6.5.0-1.fc33 We are just checking to make sure all the f33-rebuild packages are signed, and then will be merging the tag. Waiting on 2020-08-01 17:12:08,374 INFO: Calling koji to write 228467 rpms Fingers crossed. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
On Sat, Aug 01, 2020 at 03:13:50PM +0200, Fabio Valentini wrote: > On Sat, Aug 1, 2020 at 2:44 PM Richard W.M. Jones wrote: > > > > On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > > > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it > > > provides is used by libtextstyle.so.0, part of gettext. > > > > > > gettext is used by many many things. Please unretire libcroco, or > > > rebuild gettext without it. > > > > Yes, can confirm this breaks the whole virt stack, again. Any > > "Second build" that needs libvirt has been broken by this. > > > > I really think we should redo this whole mass rebuild from the start. > > > > Rich. > > Well, gettext-0.20.2-4.fc33 without the libcroco dependency has now > been successfully built for f33-rebuild: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1574351 > > It looks like f33-rebuild doesn't use its own packages for the > buildroot though, so anything using gettext is broken in both f33 and > f33-rebuild :( > Can we get gettext-0.20.2-4.fc33 tagged into the f33? I'd do it > myself, if I was sure not to break anything ... would "koji tag > f33-updates-candidate gettext-0.20.2-4.fc33" be enough? I don't know if this was done already, but libvirt is now installable and I was able to build virt-v2v, so it seems I'm now able to build the remaining virt packages. https://koji.fedoraproject.org/koji/taskinfo?taskID=48382603 https://kojipkgs.fedoraproject.org//work/tasks/2636/48382636/root.log => gettext 0.20.2-4.fc33 libvirt 6.5.0-1.fc33 Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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
Automatic logout due to quota
Hello, I was using my desktop system when I got logged out. After logging back in, I found this message in my logs: Aug 1 13:08:22 x2 journal[1751]: UID 1000 exceeded its 'bytes' quota on UID 1000. which was then followed by: Aug 1 13:08:22 x2 dbus-broker[1751]: Peer :1.200 is being disconnected as it does not have the resources to perform an operation. Aug 1 13:08:22 x2 dbus-broker[1751]: Peer :1.176 is being disconnected as it does not have the resources to receive a signal it subscribed to ... then Aug 1 13:08:22 x2 /usr/libexec/gdm-x-session[1703]: cinnamon-session[1754]: WARNING: t+7310.22685s: Lost name on bus: org.gnome.SessionManager Aug 1 13:08:22 x2 /usr/libexec/gdm-x-session[1703]: cinnamon-session[1754]: CRITICAL: t+7310.22738s: We failed, but the fail whale is dead. Sorry Aug 1 13:08:22 x2 cinnamon-session[1754]: WARNING: t+7310.22685s: Lost name on bus: org.gnome.SessionManager Aug 1 13:08:22 x2 cinnamon-session[1754]: CRITICAL: t+7310.22738s: We failed, but the fail whale is dead. Sorry Aug 1 13:08:23 x2 /usr/libexec/gdm-x-session[1703]: Cinnamon warning: CurrentTime used to choose focus window; focus window may not be correct Aug 1 13:08:23 x2 cinnamon-session[1754]: WARNING: t+7310.45021s: Playing logout sound '/usr/share/cinnamon-control-center/sounds/logout.ogg' Does anyone have any idea what this quota message is about? I don't use quotas on my system since it's not shared. Thanks, -Steve ___ 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 Fedora wiki system sucks
On Sat, 2020-08-01 at 12:00 -0500, Richard Shaw wrote:
> So I wanted to document a ham radio related howto, so I decided that I
> would make it an extension of the Amateur Radio SIG wiki, and I've got an
> incomplete version created:
>
> https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat
>
> How can a wiki not have some kind of tag?
Use {{code|}}, , or just add any number of spaces before each line
of the code segment (even one space works).
> Most other systems in Fedora support markdown, and I would be a fan of
> that.
wikitext predates markdown by several years. mediawiki first appeared
in 2001 and wikitext developed along with it, Markdown was invented in
2004. wikitext is quirky because of its age, development history, and
the fact that it's actually more than just markup, it has quite
extensive dynamic capabilities (particularly with extensions like
https://www.mediawiki.org/wiki/Extension:ParserFunctions , which we
have in our instance).
If what you're writing falls under the general heading of
'documentation', you might want to write it for docs.fedoraproject.org
rather than the wiki. docs.fp.o is built by a static generator and uses
the ASCIIDoc markup language. See
https://docs.fedoraproject.org/en-US/fedora-docs/contributing/adding-new-docs/
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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 Fedora wiki system sucks
On Sat, Aug 1, 2020 at 12:05 PM Tom Hughes wrote: > On 01/08/2020 18:00, Richard Shaw wrote: > > So I wanted to document a ham radio related howto, so I decided that I > > would make it an extension of the Amateur Radio SIG wiki, and I've got > > an incomplete version created: > > > > https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat > > > > How can a wiki not have some kind of tag? > > It does? It's even spelt .. in fact... > > Though I suspect ... is more what you wanted? > Ok, I'll take a look. Thanks. It isn't an option in the builtin editor that I can find. Thanks, Richard ___ 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 Fedora wiki system sucks
On 01/08/2020 18:00, Richard Shaw wrote: So I wanted to document a ham radio related howto, so I decided that I would make it an extension of the Amateur Radio SIG wiki, and I've got an incomplete version created: https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat How can a wiki not have some kind of tag? It does? It's even spelt .. in fact... Though I suspect ... is more what you wanted? Here's the mediawiki documentation: https://www.mediawiki.org/wiki/Help:Formatting#HTML_tags Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
The Fedora wiki system sucks
So I wanted to document a ham radio related howto, so I decided that I would make it an extension of the Amateur Radio SIG wiki, and I've got an incomplete version created: https://fedoraproject.org/wiki/AmateurRadio/Howto/Pat How can a wiki not have some kind of tag? Most other systems in Fedora support markdown, and I would be a fan of that. Thanks, Richard ___ 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: Review swaps
On Saturday, 1 August 2020 05:07:52 CEST Qiyu Yan wrote: > Jerry James 于 2020年8月1日周六 上午5:24写道： > > > I need two packages reviewed to enable some optional functionality in > > the normaliz package. The second depends on the first: > > > > antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862615 > > Done for this. > > > e-antic: https://bugzilla.redhat.com/show_bug.cgi?id=1862616 > > Maybe we should wait the former one to be ready in rawhide, then this? > You can use the -L switch in fedora-review to install packages prior to testing. For example, you create a "deps" folder, and add bug 1862615 RPM results in it. Then you pass -L deps to fedora review: fedora-review -r fedora-rawhide-x86_64 -L deps theSRPM ___ 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: libcroco retired on Rawhide, breaking builds
On Sat, Aug 01, 2020 at 03:37:37PM -, Michael J Gruber wrote: > It is tagged as > > f33-rebuild > f33-updates-candidate > > now but not as > > f33 > > and bodhi does not know about it either. Is it possible/advisable to tag it > as f33 directly to get the other rebuilds going again? You can't tag directly into f33, that would break at least gating and signing. I'll look into getting gettext in... kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
On Sat, Aug 01, 2020 at 03:15:59PM +0200, Fabio Valentini wrote: > On Sat, Aug 1, 2020 at 3:12 PM Michael J Gruber > wrote: > > > > Well, that second mass rebuild made things worse for me. > > The time between the two was really short - we do need time to fix things > > (see below). > > The second rebuild not only forced us to rebase changes which were in QA > > (and rewrite the changelog because of date order stubbornness) > > but - what's worse - made the "buildroot" a moving target. > > I do understand that we want rebuilds against current libraries > > but this seemed to break more dependencies than before, > > maybe because the rebuild was still in progress. Sorry for not communicating better about the second pass. The goal was to just try and rebuild everything that _failed_ in the first pass. We have a lot of packages that failed due to transient failures like the s390x package cache having issues on tuesday night and broken binutils, etc. > I agree, adding the "Mass Rebuild Second Attempt" commit and release > bump was completely unnecessary ... (especially since NEVRs for builds > that didn't succeed aren't reserved, and are overwritten by any > successful build with the same NEVR ...) Normally we would have just resubmitted them, but the eln folks asked us to do another bump to pick up fixes that were not in the first one. The mass rebuild is done now, will get merged soon. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unretire rgbds
I've created a review request to unretire rgbds: https://bugzilla.redhat.com/show_bug.cgi?id=1862705 -ben signature.asc Description: This is a digitally signed message part ___ 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: libcroco retired on Rawhide, breaking builds
It is tagged as f33-rebuild f33-updates-candidate now but not as f33 and bodhi does not know about it either. Is it possible/advisable to tag it as f33 directly to get the other rebuilds going again? ___ 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: libcroco retired on Rawhide, breaking builds
On Sat, Aug 1, 2020 at 8:30 am, Michael Catanzaro wrote: I don't think there's anything else that needs to be done now. OK, I see Fabio's mail that it isn't tagged yet: Can we get gettext-0.20.2-4.fc33 tagged into the f33? I'd do it myself, if I was sure not to break anything ... would "koji tag f33-updates-candidate gettext-0.20.2-4.fc33" be enough? ___ 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: libcroco retired on Rawhide, breaking builds
I got permission from the package owner (Dodji) before retiring it. I'll check with you first next time, sorry. I don't think there's anything else that needs to be done now. First we have to wait for the mass rebuild script to finish. Then we see what all failed ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
Sorry, this is my fault. On Sat, Aug 1, 2020 at 3:25 am, Elliott Sales de Andrade wrote: gettext is used by many many things. Please unretire libcroco, or rebuild gettext without it. It was successfully rebuilt last night by releng, I assume by the mass rebuild script. We were trying to rebuild it yesterday, but failed. I tested the gettext build before retiring libcroco, but I only did a mockbuild and the real build was only failing on armv7hl, so my mockbuild had no chance of catching the breakage. Initially, the armv7hl build of gettext failed due to a testsuite failure, so I thought we should just do a build without the tests and it would be no problem. But when we tried that yesterday, a *second* problem appeared where libtool was somehow dropping part of a shell command that it runs. I have no clue what was going wrong there and was worried I'd have to do a deep dive into libtool today to try for a successful build. I assume somebody fixed something somewhere, because there is a successful build now. Yes, I know I did this in the wrong order, I should not have touched libcroco before I had a successful rebuild of gettext. I also didn't realize the mass rebuild was still in progress. Very sorry. :S ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcroco retired on Rawhide, breaking builds
On Sat, Aug 1, 2020 at 3:12 PM Michael J Gruber wrote: > > Well, that second mass rebuild made things worse for me. The time between the > two was really short - we do need time to fix things (see below). The second > rebuild not only forced us to rebase changes which were in QA (and rewrite > the changelog because of date order stubbornness) but - what's worse - made > the "buildroot" a moving target. I do understand that we want rebuilds > against current libraries but this seemed to break more dependencies than > before, maybe because the rebuild was still in progress. I agree, adding the "Mass Rebuild Second Attempt" commit and release bump was completely unnecessary ... (especially since NEVRs for builds that didn't succeed aren't reserved, and are overwritten by any successful build with the same NEVR ...) Fabio ___ 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: libcroco retired on Rawhide, breaking builds
On Sat, Aug 1, 2020 at 2:44 PM Richard W.M. Jones wrote: > > On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it > > provides is used by libtextstyle.so.0, part of gettext. > > > > gettext is used by many many things. Please unretire libcroco, or > > rebuild gettext without it. > > Yes, can confirm this breaks the whole virt stack, again. Any > "Second build" that needs libvirt has been broken by this. > > I really think we should redo this whole mass rebuild from the start. > > Rich. Well, gettext-0.20.2-4.fc33 without the libcroco dependency has now been successfully built for f33-rebuild: https://koji.fedoraproject.org/koji/buildinfo?buildID=1574351 It looks like f33-rebuild doesn't use its own packages for the buildroot though, so anything using gettext is broken in both f33 and f33-rebuild :( Can we get gettext-0.20.2-4.fc33 tagged into the f33? I'd do it myself, if I was sure not to break anything ... would "koji tag f33-updates-candidate gettext-0.20.2-4.fc33" be enough? Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Btrfs by default, the compression option
@Chris, thanks, i did some tests and now we have some numbers. tl;rd the results is pretty satisfying me, even if there no speedup in my case, but there is a lot disk space could be saved and reduce writes. Probably not worth file a bug, but a little bit weird that with zstd:1 still a little bit slower on HDD and on SSD speed equal. --- ! Note: please use monospace font to save formatting. CPU:Quad Core AMD Athlon X4 845 Kernel: 5.7.11-200.fc32.x86_64 (non-debug) btrfs-progs:5.7-4 Scheduler: mq-deadline Mount options: - HDD: rw,relatime,seclabel,space_cache=v2,autodefrag - SSD: rw,relatime,seclabel,compress=lzo,ssd,space_cache=v2 To produce more precise results do some things before: - Disable ZRAM: sudo systemctl stop zram-swap.service - Download all necessary packages before build to exclude time required for downloading package from internet. After that you can run mock with '--offline' option. - Before every benchmark clean-up mock: mock --isolation=simple clean -r fedora-32-x86_64 ## How to reproduce? 1. git clone https://src.fedoraproject.org/rpms/gnome-flashback.git 2. cd gnome-flashback/ 3. spectool -g gnome-flashback.spec 4. mock --isolation=simple -r fedora-32-(uname -m) --rebuild --sources . --spec gnome-flashback.spec --offline ## Results (HDD) ### Compression:lzo Took: 6m53s Processed 42492 files, 24340 regular extents (26282 refs), 24114 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 63% 992M 1.5G 1.7G none 100% 389M 389M 442M lzo 50% 603M 1.1G 1.3G ### Compression:zstd:1 Took: 7m5s Processed 42492 files, 24232 regular extents (26219 refs), 24861 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 46% 738M 1.5G 1.7G none 100% 280M 280M 317M zstd35% 458M 1.2G 1.4G ### Compression:zstd:3 Took: 7m8s Processed 42492 files, 24104 regular extents (26059 refs), 24940 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 45% 707M 1.5G 1.7G none 100% 270M 270M 306M zstd33% 437M 1.2G 1.4G ### Compression:none Took: 7m18s ## Various combinations with aditional tweaks: ### Compression:zstd:1 Addtional mount options:noautodefrag Took: 7m3s ### Compression:zstd:1 Addtional mount options:noatime Took: 7m1s --- ## Results (SSD) ### Compression:lzo Took: 2m26s ### Compression:zstd:1 Took: 2m26s ### Compression:zstd:3 Took: 2m28s ### Compression:zstd:14 Took: 4m9s Processed 42495 files, 25883 regular extents (27868 refs), 25013 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 42% 673M 1.5G 1.7G none 100% 272M 272M 310M zstd30% 401M 1.2G 1.4G ### Compression:none Took: 2m24s ___ 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
Live Image hanging problem https://bugzilla.redhat.com/show_bug.cgi?id=1768498
I see that this ticket is still NEW. I've update with my experience that the suggested fix works. It would be good to get this fix in for F33. Is there more testing I can do to help? Barry ___ 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: libcroco retired on Rawhide, breaking builds
On 8/1/20 09:25, Elliott Sales de Andrade wrote: libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it provides is used by libtextstyle.so.0, part of gettext. gettext is used by many many things. Please unretire libcroco, or rebuild gettext without it. This is unfortunate. Michael, can you next time discuss with me first before retiring GNOME packages that I take care of? Thanks! I don't have time right now to untangle this mess so someone else has to do that. -- Kalev ___ 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: Disable LTO for now ?
> On Wed, 2020-07-29 at 14:13 +0100, sergio(a)serjux.com wrote: > In general I want to have a very good > indicator the issue is LTO related before I > disable. THe build you referenced doesn't have any good indicators that LTO > is > the problem. > > For ppc64le is that the build was done with p8, but there is one function > (__builtin_altivec_vadub) that requires p9. This seems like a package bug at > first glance, not an LTO issue. I would try a ppc64le test build with and > without LTO, my guess is both are going to fail with similar problems. I don't see p8 mentioned specifically in the opencv spec, but how would one build with p9 (once the buildroot is OK again, gettext...)? ___ 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: libcroco retired on Rawhide, breaking builds
Well, that second mass rebuild made things worse for me. The time between the two was really short - we do need time to fix things (see below). The second rebuild not only forced us to rebase changes which were in QA (and rewrite the changelog because of date order stubbornness) but - what's worse - made the "buildroot" a moving target. I do understand that we want rebuilds against current libraries but this seemed to break more dependencies than before, maybe because the rebuild was still in progress. On the necessary fixes: I remember some system-wide changes that were doen really well (e.g. python setuptools related): e-mailing affected maintainers with clear information what is changing and how to adapt. Not so with cmake: Perfectly working specs were turned into FTBFS without heads-up for affected maintainers (other than on devel). The change description offers no information about what exactly changed (before/after of the macros) but 3 different approaches to adjust, leaving it up to the maintainers to find out which one works (sometimes none of them). Many learned about this just because of the mass rebuild, where a build can fail for many reasons rooted in other packages. This makes it really difficult to fix your own package. Plus LTO ... I think we should test build with changes like cmake or LTO in isolation from the typical mass rebuild which exposes many other problems. ___ 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: libcroco retired on Rawhide, breaking builds
On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it > provides is used by libtextstyle.so.0, part of gettext. > > gettext is used by many many things. Please unretire libcroco, or > rebuild gettext without it. Yes, can confirm this breaks the whole virt stack, again. Any "Second build" that needs libvirt has been broken by this. I really think we should redo this whole mass rebuild from the start. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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: Another possible LTO failure in guestfish (or maybe readline)
On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > > Looks like it's in the buildroots now. Let me know if that doesn't fix > > > the > > > problem. > > > > Looks as if "ar" is segfaulting again ... > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440 > > https://kojipkgs.fedoraproject.org//work/tasks/8440/48288440/build.log > > > > That was built with binutils 2.35-8.fc33 > Just an FYI binutils-2.35-9 is in the buildroots. It's got the fix for the > LTO > issue, but does not turn on LTO for binutils itself (that'll be in the -10 > build). > > I've confirmed that the -9 build will correctly build binutils-2.35-10. I've > also confirmed that the -9 build will correctly build libguestfs. > > I'm going to take my local -10 build and use that to build libguestfs as an > additional sanity check. Can confirm that libguestfs has been built correctly and is working (with LTO). FYI I filed this bug about LTO and inheriting warnings in functions inlined across files: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Rich. > jeff > > ps. I found out why SuSE didn't stumble on these issues. They disabled LTO > in > binutils. Their ChangeLog says it's just the testsuite, but the > implementation > is for the entire build. I suspect they probably have a few packages that are > either silently broken or where they've turned off LTO due to failures > without a > real root-cause-analysis. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ 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: We have to talk about annobin... again
On Sat, Aug 1, 2020 at 7:17 AM Kevin Kofler wrote: > > Neal Gompa wrote: > > I think it does have value, however I think the Red Hat compiler team > > drastically underestimated how much breakage we're willing to tolerate > > for it. > > I think you mean "overestimated" there, not "underestimated", don't you? > Yeah, I meant overestimated here... That's what I get for replying right after waking up. :) > > That's not true. Since Koji 1.18, it's been possible to modify the > > build process by setting simple RPM macros and mock flags in build > > tags. And with the module builds (which operate in chain builds on > > side tags), there is a higher potential for modifications that can > > result in a different set of binaries since it'll generate macros > > packages on demand to do complex build environment changes. > > But the annobin side tag would have the exact same RPM macros and mock flags > set as regular Rawhide. (Ideally, none, because Rawhide should be the > default target of the specfiles.) Modules would of course need their own > annobin side tags (one per module build tag) if you want to cover them too. > Then there'd be the problem of where we'd have the build capacity. We barely have enough for what we do now... -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: We have to talk about annobin... again
Neal Gompa wrote: > I think it does have value, however I think the Red Hat compiler team > drastically underestimated how much breakage we're willing to tolerate > for it. I think you mean "overestimated" there, not "underestimated", don't you? > That's not true. Since Koji 1.18, it's been possible to modify the > build process by setting simple RPM macros and mock flags in build > tags. And with the module builds (which operate in chain builds on > side tags), there is a higher potential for modifications that can > result in a different set of binaries since it'll generate macros > packages on demand to do complex build environment changes. But the annobin side tag would have the exact same RPM macros and mock flags set as regular Rawhide. (Ideally, none, because Rawhide should be the default target of the specfiles.) Modules would of course need their own annobin side tags (one per module build tag) if you want to cover them too. Kevin Kofler ___ 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: Another possible LTO failure in guestfish (or maybe readline)
Hi, seeing the amount of fallout from LTO, I really think that this feature ought to be dropped from F33, and evaluated carefully for F34 (i.e., can it be done without breaking the build of or miscompiling a large part of the distribution, once the bugs such as the ld bug discussed in this thread are fixed, or is it just unsafe to enable by default to begin with?). I.e., revert it for F33 for sure, then decide whether to retry it for F34 or can it permanently. Kevin Kofler ___ 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
libcroco retired on Rawhide, breaking builds
libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it provides is used by libtextstyle.so.0, part of gettext. gettext is used by many many things. Please unretire libcroco, or rebuild gettext without it. -- Elliott ___ 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
