Elliott Sales de Andrade (qulogic) is now in python{,-packagers}-sig
Welcome \o/ https://fedoraproject.org/wiki/User:Qulogic -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Fedora 29 compose report: 20181005.n.0 changes
OLD: Fedora-29-20181002.n.0 NEW: Fedora-29-20181005.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 158 Downgraded packages: 0 Size of added packages: 18.21 MiB Size of dropped packages:0 B Size of upgraded packages: 2.89 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 23.06 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-29-20181005.n.0.s390x.tar.xz = DROPPED IMAGES = = ADDED PACKAGES = Package: nghttp2-1.33.0-1.module_2177+2526c218 Summary: Experimental HTTP/2 client, server and proxy RPMs:libnghttp2 libnghttp2-devel nghttp2 Size:3.76 MiB Package: nodejs-image-size-0.6.3-1.fc29 Summary: A Node module to get dimensions of any image file RPMs:nodejs-image-size Size:18.73 KiB Package: nodejs-less-plugin-clean-css-1.5.1-1.fc29 Summary: Compresses the css output from less using clean-css RPMs:nodejs-less-plugin-clean-css Size:14.78 KiB Package: perl-Dancer2-Plugin-Database-2.17-2.fc29 Summary: Easy database connections for Dancer2 applications RPMs:perl-Dancer2-Plugin-Database Size:22.77 KiB Package: python-trio-0.7.0-1.fc29 Summary: An async/await-native I/O library for humans and snake people RPMs:python3-trio Size:431.60 KiB Package: termy-qt-1.1.1-1.fc29 Summary: TermySequence terminal multiplexer client RPMs:termy-qt Size:13.97 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ArpON-3.0-10.fc29 Old package: ArpON-3.0-9.fc29 Summary: ARP handler inspection RPMs: ArpON Size: 42.33 MiB Size change: -5.52 KiB Changelog: * Tue Sep 04 2018 Arun S A G - 3.0-10 - Fix GCC 8 compiler warnings are treated as errors Package: PackageKit-1.1.11-1.fc29 Old package: PackageKit-1.1.10-4.fc29 Summary: Package management service RPMs: PackageKit PackageKit-command-not-found PackageKit-cron PackageKit-glib PackageKit-glib-devel PackageKit-gstreamer-plugin PackageKit-gtk3-module Size: 7.09 MiB Size change: -75.36 KiB Changelog: * Sat Sep 22 2018 Adam Williamson - 1.1.10-5 - Backport several more fixes from master for libdnf compat * Tue Sep 25 2018 Richard Hughes - 1.1.11-1 - New upstream release - Add --autoremove option to pkcon - De-register callbacks on PkClientHelper finalize - Don't complain if command-not-found get uninstalled while running - Never assert when an interactive TTY is not available - Shut down services cleanly before rebooting after offline updates - Shutdown the daemon on idle by default Package: R-V8-1.5-7.fc29 Old package: R-V8-1.5-6.fc29 Summary: Embedded JavaScript Engine for R RPMs: R-V8 Size: 998.98 KiB Size change: -26.47 KiB Changelog: * Sun Sep 23 2018 Elliott Sales de Andrade - 1.5-7 - Fix unbundling of JavaScript files Package: R-data.table-1.11.6-1.fc29 Old package: R-data.table-1.11.4-3.fc29 Summary: Extension of `data.frame` RPMs: R-data.table Size: 8.43 MiB Size change: 89.38 KiB Changelog: * Sat Sep 22 2018 Elliott Sales de Andrade - 1.11.6-1 - Update to latest version Package: R-fts-0.9.9.2-1.fc29 Old package: R-fts-0.9.9.1-1.fc29 Summary: R Interface to 'tslib' (a Time Series Library in C++) RPMs: R-fts Size: 1.14 MiB Size change: 840 B Changelog: * Sat Sep 22 2018 Elliott Sales de Andrade - 0.9.9.2-1 - Update to latest version Package: R-globals-0.12.3-1.fc29 Old package: R-globals-0.12.2-1.fc29 Summary: Identify Global Objects in R Expressions RPMs: R-globals Size: 82.71 KiB Size change: 1.54 KiB Changelog: * Sat Sep 22 2018 Elliott Sales de Andrade - 0.12.3-1 - Update to latest version Package: R-later-0.7.5-1.fc29 Old package: R-later-0.7.4-1.fc29 Summary: Utilities for Delaying Function Execution RPMs: R-later R-later-devel Size: 551.36 KiB Size change: 18.61 KiB Changelog: * Sat Sep 22 2018 Elliott Sales de Andrade - 0.7.5-1 - Update to latest version Package: R-pkgbuild-1.0.1-1.fc29 Old package: R-pkgbuild-1.0.0-1.fc29 Summary: Find Tools Needed to Build R Packages RPMs: R-pkgbuild Size: 109.37 KiB Size change: 2.66 KiB Changelog: * Sat Sep 22 2018 Elliott Sales de Andrade - 1.0.1-1 - Update to latest version Package: R-prettydoc-0.2.1-3.fc29 Old package: R-prettydoc-0.2.1-2.fc29 Summary: Creating Pretty Documents from R Markdown RPMs: R-prettydoc Size: 224.30 KiB Size change: -119.41 KiB Changelog: * Sun Sep 23 2018 Elliott Sales de Andrade - 0.2.1-3 - Fix unbundling of fonts Package: R-rmarkdown-1.10-4.fc29 Old package: R-rmarkdown-1.10-2.fc29 Summary: Dynamic Documents for R RPMs
[Test-Announce] Fedora 29 Branched 20181005.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 29 Branched 20181005.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: python-blivet - 20180923.n.0: python-blivet-3.1.0-2.fc29.src, 20181005.n.0: python-blivet-3.1.1-1.fc29.src Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/29 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181005.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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://getfedora.org/code-of-conduct.html 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://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: Recent openQA test failures
On Fri, 2018-10-05 at 13:21 -0700, Adam Williamson wrote: > > Two, the upgrade_realmd_client test seems to fail every time lately, > like this: > > https://openqa.fedoraproject.org/tests/288372#step/upgrade_run/19 > > it's failing while trying to upgrade the system, at a step where it > tries to install some packages, because the 'fedora-modular' repo > cannot be synchronized. It seems this was actually happening because FreeIPA wasn't coming up correctly on the server after upgrade, and the tests don't actually *notice* that directly in the upgrade test case - after reboot of the upgraded system, we just sorta assume everything's working fine. So it got exposed in a non-obvious way (something on a client test failing because bind isn't running on the server). FreeIPA isn't coming up after upgrade because the F28 stable freeipa got ahead of the F29 stable freeipa, and that causes FreeIPA's upgrade script to break (it never expects to go from a higher to a lower version and bails if it's asked to do that). I've pushed the F29 update stable now to resolve this. I've written an enhancement to the openQA test to make it hopefully explicitly catch the case where FreeIPA doesn't come up properly on upgrade, but unfortunately I now can't test *that* because of a *different* bug which causes the upgrade process itself to fail: another case where an F28 package got ahead of F29, libxcrypt. libxcrypt-4.2.1-3.fc28 went stable ahead of libxcrypt-4.2.1-3.fc29 - both have been submitted for stable, but the F28 package reached the f28 stable update repo before a new F29 compose got done with the F29 update in it, and files in 4.2.1 conflict with the 4.1.2 that is still currently in the F29 compose that's on the mirrors. This should hopefully be resolved once the compose that's running at present completes... Moral of the story...we really should go back to gating on the upgradepath test...:P -- 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://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
Recent openQA test failures
Hey folks! If anyone's looking at openQA results for their updates, you may have noticed odd failures for several tests for updates submitted in the last day or so. It seems that all runs of tests that communicate with each other have been failing on production openQA since the infra reboot that happened recently, because a key openQA service did not come up properly when the server was rebooted. All these failures are spurious and can be safely ignored. I've just restarted the service in question and rescheduled all the failed tests, but it will take some time for openQA to chew through them all (we only have 14 workers, and these tests are some of the slowest, unfortunately). While I'm on the line, there are a couple of other cases where tests are failing that I know about but haven't managed to look into in detail yet. One, the desktop_update_graphical test sometimes fails because, it seems, GNOME Software / PackageKit fail to properly retrieve the available updates and see the one that should be present (the test tries to make sure an update is definitely available before hitting GNOME Software's "refresh" button). This seems to be a "sometimes works, sometimes fails" kinda thing, it fails about half the time on F27 and F28, it seems to never fail this way on F29 (so I guess some kinda bug got fixed there; there is probably a genuine bug in libdnf or PackageKit or something causing this, and we should find that and fix it, but it's not a bug in *your* update). Two, the upgrade_realmd_client test seems to fail every time lately, like this: https://openqa.fedoraproject.org/tests/288372#step/upgrade_run/19 it's failing while trying to upgrade the system, at a step where it tries to install some packages, because the 'fedora-modular' repo cannot be synchronized. So, if you see any of the failures discussed here for your update, they are not caused by your update and can be ignored. Sorry for the inconvenience, and I'll try to improve the reliability of the two problematic tests ASAP. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On 10/05/2018 11:03 AM, Lennart Poettering wrote: On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote: (cross-posting to devel and desktop lists, ideally reply to both) Coincidentally, at All Systems Go! in Berlin last week I had some discussions with kernel people about RLIMIT_NOFILE defaults. They basically suggested that the memory and performance cost of large numbers of fds on current kernels is cheap, and that we should bump the hard limit in systemd for all userspace processes. I have thus prepared this a few days ago: https://github.com/systemd/systemd/pull/10244 This should have the effect on systemd systems that do not patch around in RLIMIT_NOFILE otherwise that the new default hard limit for all userspace is 256K (though the soft limit remains at 1K, for compat with select()). AFAIK Fedora doesn't override RLIMIT_NOFILE artificially, hence these new systemd upstream defaults should trickle down to Fedora too. I was asked about the file limit for SteamProton a few months ago and I mentioned asking about policy limits publicly for a discussion. It's good to know that the cost is relatively low and we can increase the default in systemd. Thanks, Laura ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Fr, 05.10.18 12:28, Nicholas Miell (nmi...@gmail.com) wrote: > >> This is not quite the 1M you appear to ask for though… I picked 256K > >> mostly because I wanted to stay lower than the kernel built-in max > >> (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick > >> something. Do you have any particular reason to prefer 1M over 256K? I > >> am completely open to suggestions there... > > > > The upstream esync branch requests setting the hard limit to 1M. > > > > https://github.com/zfigura/wine/blob/esync/README.esync > > > > I haven't torn apart the project to see if 1M is really necessary so a > > different limit may be up for discussion. > > esync uses eventfd to reduce IPC to wineserver when emulating Windows > kernel objects, the exact number of eventfds needed depends entirely on > the behavior of the Windows application you are running. So, any idea why they picked 1M? Are there typical apps that require really that many? I mean, it could be two things: 1) yes, they ran into real-life apps that require 500K fds and hence set the limit to 1M since they can't set it any higher anyway, and it's far away from (i.e. double of) 500K. 2) no, they didn't run into real-life apps like this, but didn't want to figure out what a good limit is, hence they set it to the kernel's built-in maximum of 1M. If it's #1 then I figure we should bump the systemd upstream to 1M too. If it's #2, then I figure we can start with 256K as my PR currently does, for now. Lennart -- Lennart Poettering, Red Hat ___ 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: many legit devel@ emails marked as spam by gmail (dmarc reject)
Chris Murphy wrote: > Semi-related to the "Attention Gmail users, please turn off HTML" > thread; anyone *not* using gmail (e.g. all Yahoo email users) are > having their emails put into spam by google mail. > > >>This message has a from address in yahoo.co.uk but has failed yahoo.co.uk's >>required tests for authentication. Learn more > > And from the headers: > > smtp.mailfrom=test-boun...@lists.fedoraproject.org; >dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=yahoo.co.uk > > > And from yahoo's help. > https://help.yahoo.com/kb/SLN24050.html > > The result of the reject policy set by yahoo (and others), and that > gmail is one of the few mail hosting companies that honors p=reject, > is that such emails end up in gmail spam, and no amount of training or > filtering will fix it. And this is a silent failure. I have many > emails in spam by Fedora Project users (not just devel@). On the users list we enabled Mailman's DMARC mitigations several months ago. That has allowed posts from users @yahoo and other domains with strict DMARC settings to reach list subscribers @gmail and other domains which honor those DMARC settings. It may be worthwhile to enable those Mailman mitigations for all project lists by default (allowing lists who may not want it to disable the settings). -- Todd ~~ The secret of life is honesty and fair dealing. If you can fake that, you've got it made. -- Groucho Marx 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On 10/5/18 11:55 AM, Michael Cronenworth wrote: > First off, thanks, Kamil, for starting this discussion. I've been > meaning to bring it up. > > On 10/5/18 1:03 PM, Lennart Poettering wrote: > [snip] >> This is not quite the 1M you appear to ask for though… I picked 256K >> mostly because I wanted to stay lower than the kernel built-in max >> (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick >> something. Do you have any particular reason to prefer 1M over 256K? I >> am completely open to suggestions there... > > The upstream esync branch requests setting the hard limit to 1M. > > https://github.com/zfigura/wine/blob/esync/README.esync > > I haven't torn apart the project to see if 1M is really necessary so a > different limit may be up for discussion. > esync uses eventfd to reduce IPC to wineserver when emulating Windows kernel objects, the exact number of eventfds needed depends entirely on the behavior of the Windows application you are running. ___ 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: Attention Gmail users, please turn off HTML mail
On Fri, Oct 05, 2018 at 08:25:21PM +0200, Florian Weimer wrote: > I'm more worried how these forums exclude commercial contributors. Rust > has the same NC terms. How is this supposed to work for projects which > are not exclusively run and used by hobbyists? How do you incorporate > material that is posted to the forum into free software, when the terms > clearly state that you cannot do this? It looks like Foreman hasn't updated the software's boilerplate terms of service, which puts user content under CC BY-NA-SA. For the Fedora instance, we've changed that whole long page to a much simpler statement that 1. Participants are bound by the Fedora Code of Conduct, and 2. User contributions need to be under an acceptable-for-Fedora license, with the normal Fedora content license (which is CC BY-SA 3.0) by default. (See https://discussion.fedoraproject.org/tos) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
First off, thanks, Kamil, for starting this discussion. I've been meaning to bring it up. On 10/5/18 1:03 PM, Lennart Poettering wrote: [snip] This is not quite the 1M you appear to ask for though… I picked 256K mostly because I wanted to stay lower than the kernel built-in max (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick something. Do you have any particular reason to prefer 1M over 256K? I am completely open to suggestions there... The upstream esync branch requests setting the hard limit to 1M. https://github.com/zfigura/wine/blob/esync/README.esync I haven't torn apart the project to see if 1M is really necessary so a different limit may be up for discussion. Regards, Michael ___ 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: Attention Gmail users, please turn off HTML mail
* Matthew Miller: > The Foreman community recently switched away from mailing lists in this way, > and https://theforeman.org/2018/07/discourse-6-months-on-impact-assesment.html > is really interesting and helpful read on the topic for those who might have > some ... trepidation. I'm more worried how these forums exclude commercial contributors. Rust has the same NC terms. How is this supposed to work for projects which are not exclusively run and used by hobbyists? How do you incorporate material that is posted to the forum into free software, when the terms clearly state that you cannot do this? Thanks, Florian ___ 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: many legit devel@ emails marked as spam by gmail (dmarc reject)
Chris, On 2018-10-06 04:10, Chris Murphy wrote: Semi-related to the "Attention Gmail users, please turn off HTML" thread; anyone *not* using gmail (e.g. all Yahoo email users) are having their emails put into spam by google mail. Not only that but I have had cases where the mails are silently dropped too - the situation doesn't happen often and when it does I am mostly not in a position to ask the recipients to help me debug - but for at least a couple of cases where people were helpful: - I could see from my QMail logs that the mail reached the Google server - It was nowhere to be found in the recipient's account - The mail was never bounced back Regards, Phil. This message has a from address in yahoo.co.uk but has failed yahoo.co.uk's required tests for authentication. Learn more And from the headers: smtp.mailfrom=test-boun...@lists.fedoraproject.org; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=yahoo.co.uk And from yahoo's help. https://help.yahoo.com/kb/SLN24050.html The result of the reject policy set by yahoo (and others), and that gmail is one of the few mail hosting companies that honors p=reject, is that such emails end up in gmail spam, and no amount of training or filtering will fix it. And this is a silent failure. I have many emails in spam by Fedora Project users (not just devel@). -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au ___ 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
[Bug 1635278] Upgrade perl-Glib to 1.328
https://bugzilla.redhat.com/show_bug.cgi?id=1635278 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-Glib-1.328-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-749dd12c7a -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
many legit devel@ emails marked as spam by gmail (dmarc reject)
Semi-related to the "Attention Gmail users, please turn off HTML" thread; anyone *not* using gmail (e.g. all Yahoo email users) are having their emails put into spam by google mail. >This message has a from address in yahoo.co.uk but has failed yahoo.co.uk's >required tests for authentication. Learn more And from the headers: smtp.mailfrom=test-boun...@lists.fedoraproject.org; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=yahoo.co.uk And from yahoo's help. https://help.yahoo.com/kb/SLN24050.html The result of the reject policy set by yahoo (and others), and that gmail is one of the few mail hosting companies that honors p=reject, is that such emails end up in gmail spam, and no amount of training or filtering will fix it. And this is a silent failure. I have many emails in spam by Fedora Project users (not just devel@). -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote: > (cross-posting to devel and desktop lists, ideally reply to both) Coincidentally, at All Systems Go! in Berlin last week I had some discussions with kernel people about RLIMIT_NOFILE defaults. They basically suggested that the memory and performance cost of large numbers of fds on current kernels is cheap, and that we should bump the hard limit in systemd for all userspace processes. I have thus prepared this a few days ago: https://github.com/systemd/systemd/pull/10244 This should have the effect on systemd systems that do not patch around in RLIMIT_NOFILE otherwise that the new default hard limit for all userspace is 256K (though the soft limit remains at 1K, for compat with select()). AFAIK Fedora doesn't override RLIMIT_NOFILE artificially, hence these new systemd upstream defaults should trickle down to Fedora too. This is not quite the 1M you appear to ask for though… I picked 256K mostly because I wanted to stay lower than the kernel built-in max (which is 1M, i.e. /proc/sys/fs/nr_open), and needed to pick something. Do you have any particular reason to prefer 1M over 256K? I am completely open to suggestions there... Lennart -- Lennart Poettering, Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Fri, Oct 5, 2018 at 11:31 AM, Kamil Paral wrote: > (cross-posting to devel and desktop lists, ideally reply to both) > Debian and Ubuntu: > I've installed both Debian (Sid) and Ubuntu (18.10) to verify this, and can > confirm it. The default soft limit stays the same (1024), but the hard limit > is increased from 4096 to 1048576 (2^20). However, this only applies to the > systemd's system instance (systemd --system, PID 1), and not to systemd user > instances (systemd --user). It seems uncontroversial to at least raise it to 65535, about an order magnitude, rather than three. And apply it to both system and user instances. -- 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://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: Attempting to contact unresponsive maintainers:
On 10/5/18 10:13 AM, Jan Koscielniak wrote: > Hi, > >> jkosciel: >> >> conu [product: Fedora EPEL] >> conu [product: Fedora] > > I had already given my project to my co-maintainers on tuesday. I have > changed my FAS email adress to this one. Thank you for your concern. Ah, sorry I missed that... and thanks very much for the reply! kevin signature.asc Description: OpenPGP digital signature ___ 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: Attention Gmail users, please turn off HTML mail
On Fri, Oct 5, 2018 at 10:20 AM, Matthew Miller wrote: > On Fri, Oct 05, 2018 at 02:02:46AM +0100, Andrew Clayton wrote: >> Adam Williamson wrote: >> > On Thu, 2018-10-04 at 17:32 -0400, Matthew Miller wrote: >> > > The fact is, the world has moved away from quoted mail with inline >> > > replies. >> > > Top posting rules basically everywhere except hold-out old-school mailing >> > > lists. >> > ...like this one. ;) >> His email was from mutt as well! I guess fedora-devel just isn't >> old-school enough :( > > Okay, I admit to some level of trolling there. :) > > My point, though, is that I don't think we can afford to be exclusively > old-school to the point where it makes a significant barrier to entry. I agree. And I think this needs rephrasing since forever: https://fedoraproject.org/wiki/Mailing_list_guidelines Place each part of your reply after the text it addresses (i.e., NO Top-Posting, please see "Wikipedia - Top Posting" and links therein for more on this). It's one thing to state a preference for bottom posting, and why. But the present guidelines encourage people to flip out whenever there's a top post. > Top-posting isn't just an annoying Gmail thing; it's a whole different > approach to using email for conversations. And, yeah, it *is* a much worse > one than our old-school threaded, minimal-quoting, usenet-inspired style. > That's why the general trend is *away* from email. For all the faults of gmail, one thing I like is being able to search lists within gmail. > > The Foreman community recently switched away from mailing lists in this way, > and https://theforeman.org/2018/07/discourse-6-months-on-impact-assesment.html > is really interesting and helpful read on the topic for those who might have > some ... trepidation. > > I'm not sayin' we are ready to shut this list down, but it's honestly worth > considering if a different approach will be more effective. Far worse would be fragmented list/forums resulting from mutually exclusive venues. It's probably a joke and not worth the effort to have automagic behind the scenes cross posting between discourse forums and hyperkitty (email) lists. -- 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://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
raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
(cross-posting to devel and desktop lists, ideally reply to both) Hello, this is a request for feedback regarding adjusting process limits to make Steam/Wine work better on Fedora. *A quick background:* In August Valve announced [1] Proton [2], their own fork of Wine, to get included in their Steam Play functionality, and allowing Linux players to run Windows-only games transparently from Steam without any complex configuration, just with a press of a button. Not everything works of course, but the success rate is more than decent [3]. As far as I can tell, the reception by Linux gamers has been *very* enthusiastic. *The technical details:* In order to boost performance, Valve included DXVK [4] which converts DirectX calls to Vulkan (instead of OpenGL in vanilla Wine), and esync [5], an existing wine patchset that performs process synchronization in a more efficient manner than vanilla Wine, using file descriptors. You can read the linked readme for full explanation. The esync patchset is the main subject of this email. It uses a lot of file descriptors and the default kernel limits are not sufficient for many games. Valve notes that in their requirements document (under "FD LIMIT REQUIREMENTS") [6] and it is further described in the esync readme [5]. The documents also say that Debian and its derivatives like Ubuntu have already raised the limit on open file descriptors, so those distributions work out of the box with esync. Fedora is one of those that doesn't. I wonder if we can consider changing that. *Debian and Ubuntu:* I've installed both Debian (Sid) and Ubuntu (18.10) to verify this, and can confirm it. The default soft limit stays the same (1024), but the hard limit is increased from 4096 to 1048576 (2^20). However, this only applies to the systemd's system instance (systemd --system, PID 1), and not to systemd user instances (systemd --user). Most of the apps you start in your session are children of gnome-shell, which doesn't run under the systemd user instance, so the higher limits apply for them as well (including Steam). However some apps (probably started via dbus, I'm not really sure, but importantly this includes also gnome-terminal) are started as children of the systemd user instance and therefore have the original low limits applied. I don't know whether this is intentional or just an omission. I tried really hard to find the place where Debian/Ubuntu patches the upstream limits, so that I could read some justification/explanation of the change, but I wasn't able to find it (I searched the available patches for kernel, systemd and pam). *Configuring the limits:* You can display the soft+hard limits of your current terminal using ulimit: $ ulimit -Sn 1024 $ ulimit -Hn 4096 However, note that gnome-terminal runs under the systemd user session, so at least in Debian/Ubuntu this will not see higher limits (i.e. neither will Steam started from the terminal). You can also use prlimit to see the limits of any running process. You can use this to check limits of the systemd system instance, systemd user instance, running Steam, etc. $ sudo prlimit --nofile --pid 1 RESOURCE DESCRIPTION SOFTHARD UNITS NOFILE max number of open files 1048576 1048576 files You can modify the limits on the fly like this: $ sudo prlimit --nofile=1024:1048576 --pid PID You can increase the default limits by editing /etc/systemd/system.conf (and /etc/systemd/user.conf, if you want to edit systemd user session as well) and setting: DefaultLimitNOFILE=1024:1048576 Alternatively, you can drop a file like this: [Manager] DefaultLimitNOFILE=1024:1048576 into /etc/systemd/system.conf.d/ (and /etc/systemd/user.conf.d/). *Default limits in Fedora:* >From a technical point of view I'm not able to judge whether raising the fileno limits by default is a trivial change or something with important security implications. That's why I'm writing this email to hopefully get replies from more knowledgeable people. The fact that Debian raised the limits gives me hope we could do the same in Fedora (perhaps just in Workstation, if the change in not welcome in the whole distribution). If somebody can find the justification of Debian devs, that would be great. I'd very much like to see Fedora (Workstation) being a good choice for Linux gamers (we already packaged gamemode), and this might be an important step to make sure Steam games don't work worse than on Ubuntu (but hopefully even better, due to our more recent drivers). Thanks for your feedback. [1] https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561 [2] https://github.com/ValveSoftware/Proton [3] https://spcr.netlify.com [4] https://github.com/doitsujin/dxvk [5] https://github.com/zfigura/wine/blob/esync/README.esync [6] https://github.com/ValveSoftware/Proton/blob/proton_3.7/PREREQS.md#fd-limit-requirements ___ devel mailing list -- devel@lists.fedoraproject.org To
Re: Attempting to contact unresponsive maintainers:
Hi, > jkosciel: > > conu [product: Fedora EPEL] > conu [product: Fedora] I had already given my project to my co-maintainers on tuesday. I have changed my FAS email adress to this one. Thank you for your concern. Jan Koscielniak ___ 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: Problem with mock --forcearch=s390x
On Fri, Oct 5, 2018 at 2:53 AM Miro Hrončok wrote: > You could --copyin the rpms and use rpm --noscripts (in mock shell) to > install them. Not sure if it would function later, but should avoid the > scriptlet being run. Hmm, okay, I can give that a try. Thanks for the suggestion. -- Jerry James http://www.jamezone.org/ ___ 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: What to do about sagemath
On Fri, Oct 5, 2018 at 2:48 AM Miro Hrončok wrote: > How can I help with the python3 transition? Thanks for the offer, Miro. I don't know yet. I know that I'm going to have to make the build continue in spite of doctest failures. There are still quite a few of those. I'll try to work through the issues this weekend. If something pops up that you can help with, I will let you know. /me crosses fingers and hopes that upstream continues making good progress on the python 3 transition. Regards, -- Jerry James http://www.jamezone.org/ ___ 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: Attention Gmail users, please turn off HTML mail
On Fri, Oct 05, 2018 at 02:02:46AM +0100, Andrew Clayton wrote: > Adam Williamson wrote: > > On Thu, 2018-10-04 at 17:32 -0400, Matthew Miller wrote: > > > The fact is, the world has moved away from quoted mail with inline > > > replies. > > > Top posting rules basically everywhere except hold-out old-school mailing > > > lists. > > ...like this one. ;) > His email was from mutt as well! I guess fedora-devel just isn't > old-school enough :( Okay, I admit to some level of trolling there. :) My point, though, is that I don't think we can afford to be exclusively old-school to the point where it makes a significant barrier to entry. A few years ago, I think the landscape was different. As more young people come to the project with a new perspective on online communication, we should look at how _our_ practices should evolve. Top-posting isn't just an annoying Gmail thing; it's a whole different approach to using email for conversations. And, yeah, it *is* a much worse one than our old-school threaded, minimal-quoting, usenet-inspired style. That's why the general trend is *away* from email. The Foreman community recently switched away from mailing lists in this way, and https://theforeman.org/2018/07/discourse-6-months-on-impact-assesment.html is really interesting and helpful read on the topic for those who might have some ... trepidation. I'm not sayin' we are ready to shut this list down, but it's honestly worth considering if a different approach will be more effective. -- Matthew Miller Fedora Project Leader ___ 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
[Bug 1632347] perl-MooseX-Getopt-0.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1632347 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-MooseX-Getopt-0.74-1.f ||c29 Resolution|--- |ERRATA Last Closed||2018-10-05 12:02:42 --- Comment #3 from Fedora Update System --- perl-MooseX-Getopt-0.74-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
On Fri, Oct 5, 2018 at 5:21 PM, Nathanael D. Noblet wrote: Ok, I can help with the debugging if needed. I just didn't know what stack this was built on. Let me know if/what you'd like me to do. Honestly I have no clue since the code seems foolproof. A bug report at https://gitlab.gnome.org/GNOME/glib-networking/issues would be a good place to start so we can get it onto some bugtracker, at least. ___ 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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
On Fri, 2018-10-05 at 17:14 +0200, mcatanz...@gnome.org wrote: > On Fri, Oct 5, 2018 at 4:54 PM, Nathanael D. Noblet < > nathan...@gnat.ca> wrote: > > Ok, so should I be filing a bug and if so against which component? > > I > > wasn't sure if the google online accounts part of GNOME used GnuTLS > > or > > not. > > It uses glib-networking, which does use GnuTLS. glib-networking > already enables SNI (off the top of my head, in > GTlsClientConnectionGnutls.c), so some further debugging is going to > be required here to see if indeed it's true that the SNI extension is > not being sent for some reason. Ok, I can help with the debugging if needed. I just didn't know what stack this was built on. Let me know if/what you'd like me to do. -- Nathanael ___ 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: Attention Gmail users, please turn off HTML mail
On Fri, Oct 5, 2018 at 11:11 AM Matthew Miller wrote: > > On Thu, Oct 04, 2018 at 11:27:02PM -, Ray Strode wrote: > > Why switch, when we already have > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ? it does good quoting already, you get to click what you want, and i'm > > guessing this reply i'm sending will show up plaintext. > > Unfortunately, all is not rosy there. See this thread on the users' list > from this fall about confusion with hyperkitty quoting: > https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/HQATMLGPSWGT4PGPUMYOLA6FOL6AV3XO/#ZRYTMEI3HIBLYWGQK4RZUBA4RQZREZR7 > (Look back at your message I'm replying to here, and note that the standard > attribution line is missing. And that's not the only issue identified.) > > Additionally, when one does reply, it's just using the standard web browser > text box, and to my knowledge that doesn't have an easy "delete by line" > keyboard command, let alone things like smart reflow with quoting. So that's > not super-ideal for inline replies. Hyperkitty's threaded view also is > rudimentary compared to a good mail client. > > All of this stuff would be something we could invest development resources > in and make better, but we don't really _have_ those resources, and no > significant outside-of-fedora hyperkitty development community ever > developed. We're left with some pretty awful things like the prominent "Sign > Up" button on every Fedora list leading to a big, ugly "Sign Up Closed: We > are sorry, but the sign up is currently closed" screen — which is not very > inviting, to say the least. > Python is migrating to Mailman 3 now: https://mail.python.org/mm3/mailman3/lists/ And there's interest in the openSUSE community to switch from mlmmj to Mailman 3 with HyperKitty. So the community *is* developing, it's just much later than probably expected. -- 真実はいつも一つ！/ 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://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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
On Fri, Oct 5, 2018 at 4:54 PM, Nathanael D. Noblet wrote: Ok, so should I be filing a bug and if so against which component? I wasn't sure if the google online accounts part of GNOME used GnuTLS or not. It uses glib-networking, which does use GnuTLS. glib-networking already enables SNI (off the top of my head, in GTlsClientConnectionGnutls.c), so some further debugging is going to be required here to see if indeed it's true that the SNI extension is not being sent for some reason. ___ 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: Attention Gmail users, please turn off HTML mail
On Thu, Oct 04, 2018 at 11:27:02PM -, Ray Strode wrote: > Why switch, when we already have > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ? it does good quoting already, you get to click what you want, and i'm > guessing this reply i'm sending will show up plaintext. Unfortunately, all is not rosy there. See this thread on the users' list from this fall about confusion with hyperkitty quoting: https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/thread/HQATMLGPSWGT4PGPUMYOLA6FOL6AV3XO/#ZRYTMEI3HIBLYWGQK4RZUBA4RQZREZR7 (Look back at your message I'm replying to here, and note that the standard attribution line is missing. And that's not the only issue identified.) Additionally, when one does reply, it's just using the standard web browser text box, and to my knowledge that doesn't have an easy "delete by line" keyboard command, let alone things like smart reflow with quoting. So that's not super-ideal for inline replies. Hyperkitty's threaded view also is rudimentary compared to a good mail client. All of this stuff would be something we could invest development resources in and make better, but we don't really _have_ those resources, and no significant outside-of-fedora hyperkitty development community ever developed. We're left with some pretty awful things like the prominent "Sign Up" button on every Fedora list leading to a big, ugly "Sign Up Closed: We are sorry, but the sign up is currently closed" screen — which is not very inviting, to say the least. -- Matthew Miller Fedora Project Leader ___ 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: F29 Self-Contained Change: GnuTLS enables TLS 1.3 by default
On Thu, 2018-10-04 at 21:33 +0200, Michael Schwendt wrote: > > Yes. If Google hands out certificates for other secure services in > the > same way as it does on its IMAP servers, any other TLS based client > will > need to be developed further. Ok, so should I be filing a bug and if so against which component? I wasn't sure if the google online accounts part of GNOME used GnuTLS or not. -- Nathanael ___ 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
[rpms/perl-Sys-Virt] New Commits To "rpms/perl-Sys-Virt" (master)
The following commits were pushed to the repo rpms/perl-Sys-Virt on branch master, which you are following: 83c54fca8dba6727276bed7085386469e60fed22Daniel P. BerrangéUpdate to 4.8.0 release To view more about the commits, visit: https://src.fedoraproject.org/rpms/perl-Sys-Virt/commits/master ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora Modularity Classroom for packagers next Tuesday
Hey all, I'll be hosting a Fedora Modularity Classroom targeted at packagers who want to build multiple versions of software on independent lifecycles for Fedora. When: Tuesday, October 09 at 1400 UTC How: Bluejeans https://bluejeans.com/6638527489 (or simply dial MODULARITY) More details: https://fedoramagazine.org/fedora-classroom-session-fedora-modularity-101/ Recording will be available on YouTube. Cheers! Adam -- Adam Šamalík --- Software Engineer Red Hat ___ 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: Problem with mock --forcearch=s390x
On 5.10.2018 04:58, Jerry James wrote: I am trying to determine why the latest version of bigloo segfaults on s390x during the build. I launched a mock build with mock -r fedora-rawhide-s390x --forcearch=s390x --rebuild bigloo-4.3c-1.fc30.src.rpm, then went away for several hours. I came back to see this: Running scriptlet: desktop-file-utils-0.23-9.fc29.s390x 570/570 Running scriptlet: fontconfig-2.13.1-1.fc30.s390x 570/570 Running scriptlet: adwaita-icon-theme-3.30.0-1.fc30.noarch570/570 Running scriptlet: hicolor-icon-theme-0.17-3.fc29.noarch 570/570 Running scriptlet: shared-mime-info-1.10-2.fc29.s390x 570/570 Running scriptlet: gdk-pixbuf2-2.38.0-4.fc30.s390x570/570 And there it sits. Running ps shows: root 27051 15060 0 Oct4 ?00:00:00 /usr/bin/qemu-s390x-static /bin/sh /var/tmp/rpm-tmp.WNZJDC 0 0 root 27053 27051 99 Oct4 ?10:09:31 /usr/bin/qemu-s390x-static /bin/gdk-pixbuf-query-loaders-64 --update-cache So apparently gdk-pixbuf-query-loaders-64 has hung. This didn't happen during the koji build, so it must be some artifact of building with qemu-static. Does anybody have any idea how I can either diagnose or avoid the hang? You could --copyin the rpms and use rpm --noscripts (in mock shell) to install them. Not sure if it would function later, but should avoid the scriptlet being run. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: What to do about sagemath
On 5.10.2018 04:56, Jerry James wrote: On Mon, Sep 24, 2018 at 7:58 AM Miro Hrončok wrote: IMHO You can build the python3 package as well, but blacklist it from the module. I'm starting to lean back towards migrating to the (experimental, buggy) python 3 build. Lots of python 3 fixes have gone into the (not quite released) sagemath 8.4. That would certainly be less work for me, since I wouldn't have to keep up with python 2 versions of various packages. That would be a good thing. I am soo far behind on Fedora work. My TODO list has never been so long before, so I think adding python 2 package maintenance onto the heap is not a great idea. I still haven't heard anything from Paulo. I don't know what his status is, but he seems to be absent for the time being, which means it's pretty much just me minding the sagemath store. The state of the packages will have to bow to my time pressure, unless somebody else steps up to help with maintenance, which hasn't happened yet. That was a roundabout way of saying, "I haven't figured out how modules work yet. I don't know when I will have time to figure it out, but probably not soon. Sagemath is already broken in Rawhide due to certain python 2 packages disappearing, so something has to be done, and this seems like the least work for me." :-) How can I help with the python3 transition? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
[Bug 1536481] fusioninventory-agent segfaults when running SNMP
https://bugzilla.redhat.com/show_bug.cgi?id=1536481 Johan Cwiklinski changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2018-10-05 04:39:31 --- Comment #3 from Johan Cwiklinski --- No longer reproducible issue, closing. If it happens again and you can provide aditional data, see upstream issue ;) -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1536481] fusioninventory-agent segfaults when running SNMP
https://bugzilla.redhat.com/show_bug.cgi?id=1536481 --- Comment #2 from Johan Cwiklinski --- Hi again, Upstream has requested additional informations: https://github.com/fusioninventory/fusioninventory-agent/issues/571#issuecomment-427258434 -- 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
