[389-devel] 389 DS nightly 2018-10-25 - 91% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/10/25/report-389-ds-base-1.4.0.16-1.fc28.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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
On Wed, 24 Oct 2018 21:16:07 - "Alexey Rochev" wrote: > You can verify that your X session uses different dbus-daemon > that systemd by checking the output of "dbus-send --session > --dest=org.freedesktop.DBus --type=method_call > --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" > command. If it doesn't list org.freedesktop.systemd1 or > org.pulseaudio.Server you have this issue. Yes, I have the issue. ___ 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
[389-devel] Re: Nunc-stans status
> > > > Saying that I think it would be good to have a deadline or a list > > of people we want comments from. Mark, Simon, Ludwig, Viktor, > > yourself and myself come to mind … we need to know what our > > approach is, and this ties back to the “feature gating” discussion > > that I hope you saw. We need a way to have features we are working > > on, so we can test and reason about them, but without letting them > > out in production - and having ways to roll the back. > > Coming in late to the discussion... So, in this case with > nunc-stans(the new PR) I think we should do some basic sanity tests > on > it (which are occurring right now, and one issue was found which you > are > already aware of). Once these basic sanity tests pass then we > should > merge it. After that we can do the more extensive testing on it > from > master branch, but I don't want to commit something that is > completely > broken (even though the current state of NS isn't great). Anyway, I > think that's a fair compromise :-) I agree - now lets hope that I can find a solid few days to work on this so I can give the tests and debugging the attention it deserves ... :| ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
You see no difference because not much programs are affected by this (I discovered this issue when I tried to write systemd service that displays notifications via org.freedesktop.Notification D-Bus interface and was unable to get it to work). If you uncomment "unset DBUS_SESSION_BUS_ADDRESS" in /usr/bin/startx, what's the value of it after you started X? What does "ps -ef | grep dbus-daemon" return for you? You can verify that your X session uses different dbus-daemon that systemd by checking the output of "dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames" command. If it doesn't list org.freedesktop.systemd1 or org.pulseaudio.Server you have this issue. ___ 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
Fedora 29-20181024.n.0 compose check report
No missing expected images. Failed openQA tests: 6/133 (x86_64), 2/24 (i386), 1/2 (arm) ID: 300324 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/300324 ID: 300343 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/300343 ID: 300354 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/300354 ID: 300381 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/300381 ID: 300383 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/300383 ID: 300413 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/300413 ID: 300420 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/300420 ID: 300453 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/300453 ID: 300471 Test: i386 universal install_blivet_software_raid URL: https://openqa.fedoraproject.org/tests/300471 Soft failed openQA tests: 2/133 (x86_64), 2/24 (i386) (Tests completed, but using a workaround for a known bug) ID: 300344 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/300344 ID: 300347 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/300347 ID: 300370 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/300370 ID: 300440 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/300440 Passed openQA tests: 125/133 (x86_64), 20/24 (i386) Skipped openQA tests: 1 of 159 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Package Reviews
On Wed, 2018-10-24 at 19:49 +0200, Robert-André Mauchin wrote: > Hello, > > I'd like some help for a couple of package reviews: > > Review Request: rclone-browser - Simple cross platform GUI for > rclone > https://bugzilla.redhat.com/show_bug.cgi?id=1642570 I've got this one. You already reviewed duperemove for me. Jonathan > Review Request: strawberry - An audio player and music collection > organizer > https://bugzilla.redhat.com/show_bug.cgi?id=1642118 > > I'll review anything in exchange but I will be on vacation starting > Sat 27 to > Wed 7. ___ 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
[389-devel] Re: Nunc-stans status
On 10/24/18 6:02 AM, William Brown wrote: On 24 Oct 2018, at 17:56, thierry bordaz wrote: On 10/21/2018 03:55 AM, William Brown wrote: Thanks for this write up Thierry, On 19 Oct 2018, at 17:15, thierry bordaz wrote: Hi, C10K is a scalability problem that a server can face when dealing with events of thousands of connections (i.e. clients) at the same time. Events can be new connections, new operations on the established connections, closure of connection (from client or server) For 389-ds, C10K problem was resolved with a new framework Nunc-Stans [1]. Nunc-stans was first enabled in RHDS 7.4 and improved/fixed in 7.5. Robustness issues [2] and [3] were reported in 7.5 and it was decided to disable Nunc-stans. It is not known if those issues exist or not in 7.4. William posted a PR to fix those two issues [4]. Nunc-stans is a complex framework, with its own dynamic. Review of this PR is not easy and even a careful review may not guaranty it will fix [2] and [3] and may not introduce others unexpected side effects. From there we discussed two options (but there may be others): • Review and merge the PR [4], then later run some intensive tests aiming to verify [2],[3] and checking the robustness in order to reenable NS I think this is the best solution. If NS is “not working” today, then merging the PR won’t make it “not work” any less ;) Given we have a reliable way to disabled it at build time, I think that merging, testing, and then eventually discussion and decision of enabling by default is the best plan. Hi William, The existing set of tests reveal a single failure[1]. That shows the PR is really promising but at the same time that tests are crucial with NS. Like the two robustness bugs (conn leak and deadlock) only happening is some specific conditions. I think review on large NS PR is bit formal step and the most important are tests/measure. We may agree to push the NS patches base on existing tests results. New tests/measure (for benefits and [2] and [3]) on top of the current PR could be the option. Let's wait for additional feedback Sure. I will work on Viktor's comments and found issues with paged search, and I’ll commit some more time to running the tests if I can. The reason I’m pushing to “just merge and test/fix later” is that at the moment I have very little time, and I don’t want to see my work bit-rot over time, and get further and further away. It’s going to make future fixes and improvements to the space easier once it’s merged. Saying that I think it would be good to have a deadline or a list of people we want comments from. Mark, Simon, Ludwig, Viktor, yourself and myself come to mind … we need to know what our approach is, and this ties back to the “feature gating” discussion that I hope you saw. We need a way to have features we are working on, so we can test and reason about them, but without letting them out in production - and having ways to roll the back. Coming in late to the discussion... So, in this case with nunc-stans(the new PR) I think we should do some basic sanity tests on it (which are occurring right now, and one issue was found which you are already aware of). Once these basic sanity tests pass then we should merge it. After that we can do the more extensive testing on it from master branch, but I don't want to commit something that is completely broken (even though the current state of NS isn't great). Anyway, I think that's a fair compromise :-) Thanks, [1] https://pagure.io/389-ds-base/pull-request/49636#comment-66941 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1608746 deadlock [3] https://bugzilla.redhat.com/show_bug.cgi?id=1605554 connection leaks best regards thierry • Build some tests for • measure the benefit of NS as [2] and [3] do not prevent some performance tests • identify possible reproducers for [2] and [3] • create robustness and long duration NS specific tests • review and merge the PR [4] As PR [4] is not intended for perf improvement, the step 2.1 will impact the priority according to the performance benefits. I think that the test plan is good. 2 and 3 will be hard to reproduce I think, they seem like they require complex state and interactions. The goal of the PR I have open is to reduce the complexity of NS integration into DS, so that tests for situations like 2 and 3 can be more easily created (and hopefully the simpler integration is going to resolve some issues). The “benefit” of NS is hard to say - because the other parts of the server core are still needing threading improvement, NS may help some aspects (connection acceptance performance for example), we won’t see all the of the benefits until we improve other parts. There are many bottlenecks to fix! An example is lib globs high use of atomics (should be COW), and the plugin architecture. At a theoretical level, NS
Re: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
On Wed, 24 Oct 2018 15:32:31 - "Alexey Rochev" wrote: > One effect of this is for example, is inability to control PulseAudio > via D-Bus from X session (although most programs use libpulse API > that works via sockets) or lack of access to user D-Bus services > (e.g. org.freedesktop.Notifications) from user systemd services. This > line was added in pre-systemd times when D-Bus session has been > launching together with X server. Now D-Bus is launched by systemd on > login, and unsetting DBUS_SESSION_BUS_ADDRESS in startx results in > another D-Bus daemon. I don't think I have anything like that happening, so that would explain why I am seeing no difference. ___ 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
Fedora 29 compose report: 20181024.n.0 changes
OLD: Fedora-29-20181022.n.1 NEW: Fedora-29-20181024.n.0 = SUMMARY = Added images:2 Dropped images: 3 Added packages: 0 Dropped packages:0 Upgraded packages: 11 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 627.71 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 468.41 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Server dvd i386 Path: Server/i386/iso/Fedora-Server-dvd-i386-29-20181024.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-29-20181024.n.0.s390x.tar.xz = DROPPED IMAGES = Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-29-20181022.n.1.ppc64le.tar.xz Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-29-20181022.n.1.s390x.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-29-20181022.n.1.s390x.qcow2 = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: anaconda-29.24.7-1.fc29 Old package: anaconda-29.24.3-2.fc29 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-tui anaconda-widgets anaconda-widgets-devel Size: 17.94 MiB Size change: 50.61 KiB Changelog: * Mon Oct 08 2018 Martin Kolman - 29.24.4-1 - Adjust to some DNF 3.6 changes (#1637021) (mkolman) - Ignore errors when trying to activate unsupported swaps (#1635252) (vtrefny) - Add option to set kernel.hung_task_timeout_secs option (rvykydal) - Fix strings not marked for translation (jkonecny) - Drop attempt to add 'nocrypto' to tsflags (awilliam) - Fix librepo logging with new DNF (jkonecny) - Revert "Remove librepo imports from Anaconda (#1626609)" (jkonecny) - Set the VNC password directly (#1592686) (vponcova) - Update the spoke for unsupported hardware in TUI (#1601545) (vponcova) - Update the dialog for unsupported hardware in GUI (#1601545) (vponcova) - Support detection of kernel taints (vponcova) - Fix the rescue mode (#1631749) (vponcova) - Fix the sanity check verify_gpt_biosboot (#1593446) (vponcova) - Flags shouldn't process the kernel options (vponcova) - Fully support the inst.gpt option (vponcova) - Don't set Anaconda-specific flags in Blivet (vponcova) - Remove the class for kernel arguments from pyanaconda.flags (vponcova) - Remove unused false positives (vponcova) - Don't connect to signals of the Network Manager DBus objects (#1582233) (vponcova) - Fix documentation for setting Pykickstart command version (mkolman) - Don't try to get hostnamed proxy in non-installer-image environments (#1616214) (rvykydal) - Use realm data in UI (vponcova) - Use realm data in the DBus module (vponcova) - Create a DBus structure for realm data (vponcova) - Add support for DBus structures (vponcova) - Add Silverblue InstallClass (jkonecny) * Mon Oct 15 2018 Martin Kolman - 29.24.5-1 - nvdimm: update ks data for actions in UI (rvykydal) - nvdimm: use pykickstart constant for setting reconfigure mode (rvykydal) - Revert "Don't allow booting from nvdimm devices" (rvykydal) * Thu Oct 18 2018 Martin Kolman - 29.24.6-1 - installclass: fix variant string for Atomic Host (#1640409) (dusty) * Fri Oct 19 2018 Martin Kolman - 29.24.7-1 - Fix local repo files aren't enabled (#1636739) (jkonecny) Package: dnf-4.0.4-1.fc29 Old package: dnf-3.6.1-2.fc29 Summary: Package manager RPMs: dnf dnf-automatic dnf-data dnf-yum python2-dnf python3-dnf Size: 1.34 MiB Size change: 29.59 KiB Changelog: * Mon Oct 15 2018 Jaroslav Mracek - 4.0.4-1 - Update to 4.0.4 - Add dnssec extension - Set termforce to AUTO to automatically detect if stdout is terminal - Repoquery command accepts --changelogs option (RhBug:1483458) - Calculate sack version from all installed packages (RhBug:1624291) - [module] Allow to enable module dependencies (RhBug:1622566) Package: dnf-plugins-core-4.0.0-2.fc29 Old package: dnf-plugins-core-3.0.4-1.fc29 Summary: Core Plugins for DNF RPMs: dnf-plugins-core dnf-utils python2-dnf-plugin-leaves python2-dnf-plugin-local python2-dnf-plugin-migrate python2-dnf-plugin-show-leaves python2-dnf-plugin-versionlock python2-dnf-plugins-core python3-dnf-plugin-leaves python3-dnf-plugin-local python3-dnf-plugin-show-leaves python3-dnf-plugin-versionlock python3-dnf-plugins-core Size: 509.98 KiB Size change: 10.50 KiB Changelog: * Mon Oct 15 2018 Jaroslav Mracek - 4.0.0-1 - Update to 4.0.0 - Enhance documentation - [repoclosure] check every --pkg attribute separately - [repoclosure] Now accepts nevra as a argument of --pkg option - [reposync] enhancements (RhBug:1550063,1582152,1550064,1405789,1598068)
Re: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
On Wed, 24 Oct 2018 07:40:51 -0700 stan wrote: > I did notice that when I shut down > by closing X, and then using shutdown -P now that the powerdown > does not work. I have to manually turn the system off, though it > does reach shutdown state. Just an additional data point. That must have been a fluke. My next shutdown powered down, and I tried a few more and they worked as well. ___ 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
Package Reviews
Hello, I'd like some help for a couple of package reviews: Review Request: rclone-browser - Simple cross platform GUI for rclone https://bugzilla.redhat.com/show_bug.cgi?id=1642570 Review Request: strawberry - An audio player and music collection organizer https://bugzilla.redhat.com/show_bug.cgi?id=1642118 I'll review anything in exchange but I will be on vacation starting Sat 27 to Wed 7. Best regards, Robert-André ___ 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
[Test-Announce] Fedora 29 Branched 20181024.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 29 Branched 20181024.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: anaconda - 20181014.n.0: anaconda-29.24.3-2.fc29.src, 20181024.n.0: anaconda-29.24.7-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_20181024.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_29_Branched_20181024.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: Fedora should replace mailing lists with Discourse
Kevin Fenzi writes: Thanks for the conversation and a lot of useful information. I think it's mostly moved to "users", which is a channel which I think is more suited to forum style. So I'll go back to lurking, after one comment. > Yep. Perhaps we could (re)direct people to file issues with upstreams so > their problems are at least tracked. These should be triaged by somebody who understands Mailman, as many of the issues that have been mentioned are specific to the Fedora instance. Most prominent is the closure of the web form, with no explicit redirection to social auth or email signup. No need to be massively careful about it, we understand that users find it difficult to identify the right venue to report mail issues in general and list issues in particular. But it's very frustrating for them to get bounced back and forth. Steve ___ 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 1642532] New: Upgrade perl-Graphics-ColorNames to 3.3.0
https://bugzilla.redhat.com/show_bug.cgi?id=1642532 Bug ID: 1642532 Summary: Upgrade perl-Graphics-ColorNames to 3.3.0 Product: Fedora Version: rawhide Component: perl-Graphics-ColorNames Assignee: jples...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, st...@silug.org Latest Fedora delivers 3.2.1 version. Upstream released 3.3.0. When you have free time, please upgrade it -- 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 1642529] Upgrade perl-Clone to 0.40
https://bugzilla.redhat.com/show_bug.cgi?id=1642529 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Clone-0.40-1.fc30 Resolution|--- |RAWHIDE Last Closed||2018-10-24 11:33:43 -- 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: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
One effect of this is for example, is inability to control PulseAudio via D-Bus from X session (although most programs use libpulse API that works via sockets) or lack of access to user D-Bus services (e.g. org.freedesktop.Notifications) from user systemd services. This line was added in pre-systemd times when D-Bus session has been launching together with X server. Now D-Bus is launched by systemd on login, and unsetting DBUS_SESSION_BUS_ADDRESS in startx results in another D-Bus daemon. ___ 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 1642529] New: Upgrade perl-Clone to 0.40
https://bugzilla.redhat.com/show_bug.cgi?id=1642529 Bug ID: 1642529 Summary: Upgrade perl-Clone to 0.40 Product: Fedora Version: rawhide Component: perl-Clone Assignee: tcall...@redhat.com Reporter: jples...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Latest Fedora delivers 0.39 version. Upstream released 0.40. When you have free time, please upgrade it -- 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: Use immutable CRAN URLs
On Wed, 24 Oct 2018 at 15:02, Jason L Tibbitts III wrote:
>
> > "IU" == Iñaki Ucar writes:
>
> IU> This URL format is not recommended by CRAN, but more importantly,
> IU> the Source0 format does not work anymore, as [1] noted, when a new
> IU> version is released. However, there is an immutable format
> IU> available, as [2] pointed out. So my proposal is to use always the
> IU> following lines instead:
>
> IU> URL: https://cran.r-project.org/package=%{packname}
> IU> Source0: %{url}=%{version}
>
> That's good to know. We should consider an %r_source macro similar to
> the existing %pypi_source macro which is used for python packages. See:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi
That would be certainly great. I would call it %cran_source instead,
and a %cran_url would be helpful too, so that we can write the
following:
URL: %cran_url
Source0: %cran_source
or maybe something like %cran_origin could directly resolve into the
above two lines.
> I would be happy to write it, but I don't enough about R packaging to
> know how uniformly the tags you mention above (%packname, specifically)
> are adhered to in the current packaging set.
%packname is a global variable defined by the R2spec util. I've
checked (script attached in case you're interested) and basically all
the packages use this global. So the new macro(s) would accept up to
two arguments: the name of the R package, which should default to
%packname if defined, and the version, by default %version.
> IU> which are both shorter and immutable, and I propose to add this to
> IU> the R packaging guidelines too.
>
> Well you should certainly open a ticket with the packaging committee if
> you wish to propose changes to the packaging guidelines.
> https://pagure.io/packaging-committee/
>
> You can even send a pull request.
Great. I'll wait for that if you're going to push forward this new macro.
> IU> If we agree on this, is there any easy way to request a system-wide
> IU> change like that to all existing packages?
>
> https://fedoraproject.org/wiki/Mass_package_changes
Thanks for the pointer.
>
> - J<
--
Iñaki Ucar
packname.sh
Description: Bourne shell script
___
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: startx unsets DBUS_SESSION_BUS_ADDRESS, which breaks user D-Bus session
On Tue, 23 Oct 2018 22:53:50 - "Alexey Rochev" wrote: > I would like to draw some attention to this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: > startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching > another D-Bus session which breaks communicating with user systemd > services (and any D-Bus services started before launching X) from X > session via D-Bus, since they use two different D-Bus daemons. I > would really like this bug to be fixed. Thanks, Alexey Rochev So, I always start X from runlevel 3 (multiuser) using startx. After reading this, I went into the startx script and commented out the unset for DBUS_SESSION_BUS_ADDRESS. I haven't noticed any effects while running X from doing this. I did notice that when I shut down by closing X, and then using shutdown -P now that the powerdown does not work. I have to manually turn the system off, though it does reach shutdown state. Just an additional data point. I checked in koji, and while the latest version is 1.4, this still remains the same. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Le 2018-10-24 14:50, Bob Mauchin a écrit : I'm talking about dropping the git hash from the release part of the entry. Ah, interesting, that's a side-effect of distprefix being pulled in by dist in now, and mass rebuild changelog scripts typically null dist in release entries… So, probably not possible any longer to do mass rebuilds without full dist in changelogs (unless you want to enter hack-land). Not sure if going full dist is a problem, mass rebuilds are pretty much release specific anyway. I had missed this part, sorry about that. However, I'm pretty sure mass improving changelog entries is not in the scope of https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages Fixing failing builds clearly was. Regards, -- Nicolas Mailhot ___ 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: license of our products on getfedora.org
On Wed, Oct 24, 2018 at 12:49:01PM +, Zbigniew Jędrzejewski-Szmek wrote: > I was trying to answer the question "How is the license of Fedora as a > whole advertised?" (e.g. in the sense of what can I do with an ISO image > I download from https://getfedora.org/en/workstation/download/). > Do we specify how the whole collection is licensed anywhere? https://fedoraproject.org/wiki/Legal:Licenses/LicenseAgreement?rd=Legal/Licenses/LicenseAgreement "Fedora is a compilation of software packages, each under its own license. The compilation itself is released under the MIT license. However, this compilation license does not supersede the licenses of code and content contained in Fedora, which conform to the legal guidelines described at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing.; -- 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: Use immutable CRAN URLs
> "IU" == Iñaki Ucar writes:
IU> This URL format is not recommended by CRAN, but more importantly,
IU> the Source0 format does not work anymore, as [1] noted, when a new
IU> version is released. However, there is an immutable format
IU> available, as [2] pointed out. So my proposal is to use always the
IU> following lines instead:
IU> URL: https://cran.r-project.org/package=%{packname}
IU> Source0: %{url}=%{version}
That's good to know. We should consider an %r_source macro similar to
the existing %pypi_source macro which is used for python packages. See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_source_files_from_pypi
I would be happy to write it, but I don't enough about R packaging to
know how uniformly the tags you mention above (%packname, specifically)
are adhered to in the current packaging set.
IU> which are both shorter and immutable, and I propose to add this to
IU> the R packaging guidelines too.
Well you should certainly open a ticket with the packaging committee if
you wish to propose changes to the packaging guidelines.
https://pagure.io/packaging-committee/
You can even send a pull request.
IU> If we agree on this, is there any easy way to request a system-wide
IU> change like that to all existing packages?
https://fedoraproject.org/wiki/Mass_package_changes
- J<
___
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: @fedoraproject.org email in Bugzilla
On Wed, Oct 24, 2018, 06:19 Till Hofmann wrote: > Hi all, > > I've been using my @fedoraproject.org email alias in Bugzilla for a > while. I regularly get those complaining emails that I should fix my > account, specifically it says: > > > If you recently changed the email address associated with your > > Fedora account in the Fedora Account System, it is now out of sync > > with your bugzilla.redhat.com account. This leads to problems > > with Fedora packages you own or are CC'ed on bug reports for. > > > However, I don't see any of those issues. New bug reports on my packages > are assigned to me properly, and CC'ing also seems to work fine. > > Is there still a reason I should *not* use my @fedoraproject.org email > alias in Bugzilla? I do the same thing. I think somebody had to manually add me to some whitelist to stop getting those spammy notices. Other Fedora services, like pagure and discourse also have issues forcing the use of your forwarding email address instead of your @fedoraproject.org email alias, because that's the email provided by Fedora auth service. It's quite annoying. If you change your forwarding email, you've got to fix it in multiple places, defeating the whole purpose of a centralized Fedora id. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
On Wed, 24 Oct 2018, 09:46 Nicolas Mailhot, wrote: > Le mercredi 24 octobre 2018 à 08:42 +0200, Nicolas Mailhot a écrit : > > Le mercredi 24 octobre 2018 à 00:52 +0200, Robert-André Mauchin a > > écrit : > > > On mardi 23 octobre 2018 23:47:05 CEST you wrote: > > > > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > > > > Anyway, since no one answers when I list the possible fixes and > > > > > ask to > > > > > choose between them, I fixed the Fedora spec files myself. > > > > > > > > > > Feel free to reintroduce %gosetup calls if you really want them, > > > > > once > > > > > the %gosetup implementation has been fixed. > > > > > > > > Thanks for doing but you messed up the bumping of all the > > > > %changelog > > > > entries. > > > > > > Used this Fish script to fix my SPEC: > > > > > > > This does not need any fixing, it may not be the changelog format > > you're > > used to, but it's one of the changelog styles rpm understands, which > > is > > used by packages in Fedora, and which was documented at one point in > > guidelines (no idea where the corresponding paragraph is today with > > the > > doc.fedoraproject changes) > > Concretely the > > * > - version-release > - changes > > format is a tad more flexible and allows publishing several fixes in a > row without duplicating date lines > > * > - version-release > - changes > - version-release > - > changes > > and so on > > And, our infra does not care if a changelog uses mixed style or not, > since mass rebuilds will drop changelog entries in a single format in > all Fedora specs, so you have many mixed style changelogs in the > distribution today. > > (of course it's your specs, you can rewrite changelog entries any way > that makes you feel better) > > Regards, > > -- > Nicolas Mailhot > I'm talking about dropping the git hash from the release part of the entry. > ___ 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
license of our products on getfedora.org
Hi, I was trying to answer the question "How is the license of Fedora as a whole advertised?" (e.g. in the sense of what can I do with an ISO image I download from https://getfedora.org/en/workstation/download/). Do we specify how the whole collection is licensed anywhere? For example, we say "Fedora is always free for anyone to use, modify, and distribute. It is built and used by people across the globe who work together as a community: the Fedora Project." [1] This is hardly a license, and could be even considered misleading, since the ISO includes various components that have licenses with pretty strong restrictions (GPLv2, GPLv3), so not all kinds of "modify and distribute" options are legal. Am I missing something obvious here? Zbyszek [1] https://getfedora.org/, below the freedom/friends/features/first icons. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora should replace mailing lists with Discourse
On 19/10/18 07:03 -0700, Gerald B. Cox wrote: On Fri, Oct 19, 2018 at 6:45 AM Neal Gompa wrote: On Fri, Oct 19, 2018 at 9:16 AM Gerald B. Cox wrote: > > Again, I believe some are trying to do an apples to apples comparison with Discourse and mailing list technologies. Discourse was build from the ground up with the goal of fostering communication and collaboration. Hyperkitty is a bolt on HTML to mailing list archives. It's good for what it is, but it isn't Discourse - and usage numbers tend to bear that out. > That's an unfair characterization. HyperKitty was designed from the ground up with that goal in mind too. The _sole_ difference is the backend approach. Discourse uses a database system while HyperKitty uses a mail list engine. if you think the "sole" difference between HyperKitty and Discourse is the backend approach you're not looking very hard. It's quite apparent just by looking at it. If yperKitty's design goals are the exact same as Discourse they hid it pretty well in their online documentation. The one benefit that Discourse might offer to me is that Gerald's replies might use quoting properly :-P (Yes, I know this is a problem with the text/plain part generated by Gmail's web UI, which can be worked around by just adding a blank line between the quoted text and the reply). ___ 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 Mon, Oct 22, 2018 at 6:56 PM Stephen J. Turnbull wrote: > > Brian (bex) Exelbierd writes: > > > The question was genuine. Additionally, even at this site, the user > > profile doesn't seem to be present. > > I doubt there is a user profile chapter or page for HyperKitty at the > Mailman project. If there is one, it would be in the HyperKitty docs > themselves. As far as I know it is not and is only present as a set of links to a personal blog here: https://wiki.list.org/HyperKitty > > Unrelated, if you have edit rights on that page, the GitHub link is > > out of date and the page still refers to Fedora Hosted. > > I hope you don't mean the Mailman wiki DEV/Home page? Couldn't find > either reference there. This is hte page in question: https://wiki.list.org/HyperKitty I believe my previous email contained the wrong link because of a cut and paste error. regards, bex > > Steve > ___ > 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 -- Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.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: @fedoraproject.org email in Bugzilla
On 24/10/18 10:28 +0100, Till Hofmann wrote: Hi all, I've been using my @fedoraproject.org email alias in Bugzilla for a while. I regularly get those complaining emails that I should fix my account, specifically it says: If you recently changed the email address associated with your Fedora account in the Fedora Account System, it is now out of sync with your bugzilla.redhat.com account. This leads to problems with Fedora packages you own or are CC'ed on bug reports for. However, I don't see any of those issues. New bug reports on my packages are assigned to me properly, and CC'ing also seems to work fine. Is there still a reason I should *not* use my @fedoraproject.org email alias in Bugzilla? Does Bugzilla give extra privs to addresses registered in FAS, according to their group membership? If your Bugzilla login is not the same as your address in FAS then you wouldn't get those extra privs. ___ 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
[389-devel] What are we currently doing with docs?
I remember that Simon did some docs work for lib389. What are we currently using for that? I would like to extend this to the server core so that our man pages are easier to update, more extensive, and are kept up-to-date along with our releases. Sphinx was recommended and the name rings a bell …. — Sincerely, William ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Use immutable CRAN URLs
Hi,
Currently, most of the R packages included in Fedora use the following
lines in the SPEC:
URL: https://cran.r-project.org/web/packages/%{packname}/
Source0: https://cran.r-project.org/src/contrib/%{packname}_%{version}.tar.gz
This URL format is not recommended by CRAN, but more importantly, the
Source0 format does not work anymore, as [1] noted, when a new version
is released. However, there is an immutable format available, as [2]
pointed out. So my proposal is to use always the following lines
instead:
URL: https://cran.r-project.org/package=%{packname}
Source0: %{url}=%{version}
which are both shorter and immutable, and I propose to add this to the
R packaging guidelines too.
If we agree on this, is there any easy way to request a system-wide
change like that to all existing packages?
Regards,
--
Iñaki Ucar
[1] https://stat.ethz.ch/pipermail/r-devel/2018-October/076988.html
[2] https://stat.ethz.ch/pipermail/r-devel/2018-October/076989.html
___
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
[389-devel] Re: Nunc-stans status
> On 24 Oct 2018, at 17:56, thierry bordaz wrote: > > > > On 10/21/2018 03:55 AM, William Brown wrote: >> Thanks for this write up Thierry, >> >>> On 19 Oct 2018, at 17:15, thierry bordaz wrote: >>> >>> Hi, >>> >>> C10K is a scalability problem that a server can face when dealing with >>> events of thousands of connections (i.e. clients) at the same time. Events >>> can be new connections, new operations on the established connections, >>> closure of connection (from client or server) >>> For 389-ds, C10K problem was resolved with a new framework Nunc-Stans [1]. >>> Nunc-stans was first enabled in RHDS 7.4 and improved/fixed in 7.5. >>> Robustness issues [2] and [3] were reported in 7.5 and it was decided to >>> disable Nunc-stans. It is not known if those issues exist or not in 7.4. >>> >>> William posted a PR to fix those two issues [4]. Nunc-stans is a complex >>> framework, with its own dynamic. Review of this PR is not easy and even a >>> careful review may not guaranty it will fix [2] and [3] and may not >>> introduce others unexpected side effects. >>> >>> From there we discussed two options (but there may be others): >>> >>> • Review and merge the PR [4], then later run some intensive tests >>> aiming to verify [2],[3] and checking the robustness in order to reenable NS >> I think this is the best solution. If NS is “not working” today, then >> merging the PR won’t make it “not work” any less ;) >> >> Given we have a reliable way to disabled it at build time, I think that >> merging, testing, and then eventually discussion and decision of enabling by >> default is the best plan. > > Hi William, > > The existing set of tests reveal a single failure[1]. That shows the PR is > really promising but at the same time that tests are crucial with NS. Like > the two robustness bugs (conn leak and deadlock) only happening is some > specific conditions. > > I think review on large NS PR is bit formal step and the most important are > tests/measure. We may agree to push the NS patches base on existing tests > results. New tests/measure (for benefits and [2] and [3]) on top of the > current PR could be the option. Let's wait for additional feedback Sure. I will work on Viktor's comments and found issues with paged search, and I’ll commit some more time to running the tests if I can. The reason I’m pushing to “just merge and test/fix later” is that at the moment I have very little time, and I don’t want to see my work bit-rot over time, and get further and further away. It’s going to make future fixes and improvements to the space easier once it’s merged. Saying that I think it would be good to have a deadline or a list of people we want comments from. Mark, Simon, Ludwig, Viktor, yourself and myself come to mind … we need to know what our approach is, and this ties back to the “feature gating” discussion that I hope you saw. We need a way to have features we are working on, so we can test and reason about them, but without letting them out in production - and having ways to roll the back. Thanks, > > [1] https://pagure.io/389-ds-base/pull-request/49636#comment-66941 > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1608746 deadlock > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1605554 connection leaks > > best regards > thierry > >>> • Build some tests for >>> • measure the benefit of NS as [2] and [3] do not prevent some >>> performance tests >>> • identify possible reproducers for [2] and [3] >>> • create robustness and long duration NS specific tests >>> • review and merge the PR [4] >>> As PR [4] is not intended for perf improvement, the step 2.1 will impact >>> the priority according to the performance benefits. >> I think that the test plan is good. 2 and 3 will be hard to reproduce I >> think, they seem like they require complex state and interactions. The goal >> of the PR I have open is to reduce the complexity of NS integration into DS, >> so that tests for situations like 2 and 3 can be more easily created (and >> hopefully the simpler integration is going to resolve some issues). >> >> The “benefit” of NS is hard to say - because the other parts of the server >> core are still needing threading improvement, NS may help some aspects >> (connection acceptance performance for example), we won’t see all the of the >> benefits until we improve other parts. There are many bottlenecks to fix! An >> example is lib globs high use of atomics (should be COW), and the plugin >> architecture. >> >> At a theoretical level, NS will be faster as we don’t need to lock and poll >> over the connection table, but today the CT may not be the bottleneck, so NS >> may not make this “faster” just by enabling. >> >>> Comments are welcomed >>> >>> Regarding 2.1 plan we made the following notes for the test plan: >>> The benefit of Nunc-Stans can only be measure with a large number of >>>
@fedoraproject.org email in Bugzilla
Hi all, I've been using my @fedoraproject.org email alias in Bugzilla for a while. I regularly get those complaining emails that I should fix my account, specifically it says: > If you recently changed the email address associated with your > Fedora account in the Fedora Account System, it is now out of sync > with your bugzilla.redhat.com account. This leads to problems > with Fedora packages you own or are CC'ed on bug reports for. However, I don't see any of those issues. New bug reports on my packages are assigned to me properly, and CC'ing also seems to work fine. Is there still a reason I should *not* use my @fedoraproject.org email alias in Bugzilla? Thanks, Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 29 Beta - Cannot add printer
Hi Sam, thank you for your opinion! Would you mind telling me what are the features of s-c-p, which makes you think s-c-p is more useful and functional? I'm not control-center maintainer or upstream, but IMHO they will be happy for propositions of enhancements. Or if control-center doesn't make it, there's still CUPS web api, which is enabled by default at localhost:631. You only need to have cups.service running (if you don't want to have the service running forever and you have socket and path units enabled and running, then you can stop and disable the service). On 10/24/18 4:26 AM, Samuel Sieb wrote: > On 10/23/18 3:59 PM, Gilles Dubreuil wrote: >> I'm doing a WIFI mode. >> Installation works fine using CUPS but It's not working through >> gnome-control-center. > > I find that "system-config-printer" is much more useful and functional > than trying to do it through the control center. I have had very > little success in using the control center option. > ___ > 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 -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C 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
[389-devel] Re: Nunc-stans status
On 10/21/2018 03:55 AM, William Brown wrote: Thanks for this write up Thierry, On 19 Oct 2018, at 17:15, thierry bordaz wrote: Hi, C10K is a scalability problem that a server can face when dealing with events of thousands of connections (i.e. clients) at the same time. Events can be new connections, new operations on the established connections, closure of connection (from client or server) For 389-ds, C10K problem was resolved with a new framework Nunc-Stans [1]. Nunc-stans was first enabled in RHDS 7.4 and improved/fixed in 7.5. Robustness issues [2] and [3] were reported in 7.5 and it was decided to disable Nunc-stans. It is not known if those issues exist or not in 7.4. William posted a PR to fix those two issues [4]. Nunc-stans is a complex framework, with its own dynamic. Review of this PR is not easy and even a careful review may not guaranty it will fix [2] and [3] and may not introduce others unexpected side effects. From there we discussed two options (but there may be others): • Review and merge the PR [4], then later run some intensive tests aiming to verify [2],[3] and checking the robustness in order to reenable NS I think this is the best solution. If NS is “not working” today, then merging the PR won’t make it “not work” any less ;) Given we have a reliable way to disabled it at build time, I think that merging, testing, and then eventually discussion and decision of enabling by default is the best plan. Hi William, The existing set of tests reveal a single failure[1]. That shows the PR is really promising but at the same time that tests are crucial with NS. Like the two robustness bugs (conn leak and deadlock) only happening is some specific conditions. I think review on large NS PR is bit formal step and the most important are tests/measure. We may agree to push the NS patches base on existing tests results. New tests/measure (for benefits and [2] and [3]) on top of the current PR could be the option. Let's wait for additional feedback [1] https://pagure.io/389-ds-base/pull-request/49636#comment-66941 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1608746 deadlock [3] https://bugzilla.redhat.com/show_bug.cgi?id=1605554 connection leaks best regards thierry • Build some tests for • measure the benefit of NS as [2] and [3] do not prevent some performance tests • identify possible reproducers for [2] and [3] • create robustness and long duration NS specific tests • review and merge the PR [4] As PR [4] is not intended for perf improvement, the step 2.1 will impact the priority according to the performance benefits. I think that the test plan is good. 2 and 3 will be hard to reproduce I think, they seem like they require complex state and interactions. The goal of the PR I have open is to reduce the complexity of NS integration into DS, so that tests for situations like 2 and 3 can be more easily created (and hopefully the simpler integration is going to resolve some issues). The “benefit” of NS is hard to say - because the other parts of the server core are still needing threading improvement, NS may help some aspects (connection acceptance performance for example), we won’t see all the of the benefits until we improve other parts. There are many bottlenecks to fix! An example is lib globs high use of atomics (should be COW), and the plugin architecture. At a theoretical level, NS will be faster as we don’t need to lock and poll over the connection table, but today the CT may not be the bottleneck, so NS may not make this “faster” just by enabling. Comments are welcomed Regarding 2.1 plan we made the following notes for the test plan: The benefit of Nunc-Stans can only be measure with a large number of connections (i.e. client) above 1000. That means a set of clients (sometime all) should keep their connection opened. Clients should run on several hosts so that clients are not the bootleneck. For the two types of events (new connection and new operations), the measurement could be • Event: New connections • Start all clients in parallel to establish connections (keeping them opened) take the duration to get 1000, 2000, ... 1 connections and check there are drop or not • Establish 1000 connections and monitor during to open 100 more, the same starting with 2000, 1 • Client should not run any operations during the monitoring • Event: New operations • Start all clients and when 1000 connections are established, launch simple operations (e.g. search -s base -b "" objectclass) and monitor how many of them can be handled. The same with 2000, ... 1. • response time and workqueue length could be monitored to be sure the bottleneck are not the worker. At one point I started (but did not finish) ldclt integration with lib389. It would be
Re: Fedora 29 Beta - Cannot add printer
Thanks for letting me know. Would you mind filing the bugzilla report to control-center component with steps to reproduce, mention the printer connection type, model of the printer, mention the fact the installation works through CUPS web api and some other info mentioned in https://fedoraproject.org/wiki/How_to_debug_printing_problems (f.e. cups logs from journal are the most important). Thank you! On 10/24/18 12:59 AM, Gilles Dubreuil wrote: > > Hi Zdenek, > > I'm doing a WIFI mode. > Installation works fine using CUPS but It's not working through > gnome-control-center. > > Thanks, > Gilles > > On 12/10/18 8:42 pm, Zdenek Dohnal wrote: >> >> Hi, >> >> What type of printer do you want to add (ethernet/usb/wifi)? I tried >> to add ethernet and usb types in my clean F29 virtual machine and >> both worked. >> >> If the printer is usb or it is in the same network as your PC, then >> you should see it in CUPS web api when you try to add new printer (on >> localhost:631, when cups.service is running - tab Administration, >> 'Add new printer'). >> >> If you can add printer through CUPS web api, then the issue will be >> in gnome-control-center. >> >> On 10/12/18 12:28 AM, Gilles Dubreuil wrote: >>> Added screenshot >>> >>> >>> On 12/10/18 09:27, Gilles Dubreuil wrote: Hi, Using default Gnome shell on Wayland I cannot add a printer. In Gnome settings, after pressing "unlock" and "add" button and than selecting a driver, a pop up message "Failed to add new printer" There are no messages in system journal. PS: I've SELinux in permissive mode just in case. >>> >>> >>> >>> ___ >>> 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 >> -- >> Zdenek Dohnal >> Associate Software Engineer >> Red Hat Czech - Brno TPB-C > -- > Gilles Dubreuil > Senior Software Engineer - Red Hat - Openstack DFG Integration > Email: gil...@redhat.com > GitHub/IRC: gildub > Mobile: +61 400 894 219 > > > ___ > 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 -- Zdenek Dohnal Associate Software Engineer Red Hat Czech - Brno TPB-C 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: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora
On Wed, Oct 24, 2018 at 08:45:32AM +0200, Igor Gnatenko wrote:
> How can I enable cgroups2 on my laptop?
Put systemd.unified-cgroup-hierarchy on the kernel command line.
Zbyszek
> On Fri, Oct 19, 2018, 17:27 Lennart Poettering wrote:
>
> > On Fr, 19.10.18 09:12, Florian Weimer (fwei...@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.
> > >
> > > Which kernel version is that? Is that a new patch? Or some older
> > > kernel?
> > >
> > > It's definitely not true for kernel 4.18, see the script I posted.
> >
> > I inquired Tejun Heo about this all, this is what he replied:
> >
> >
> > In cgroup1, socket buffers are handled by a separate memory
> > sub-controller. It's cumbersome to use, somewhat broken and doesn't
> > allow for comprehensive memory control. cgroup2, however, by default
> > accounts socket buffer as part of a given cgroup's memory consumption
> > correctly interacting with socket window management.
> >
> > OOM killer too fails to take socket buffer into account and high
> > number of sockets can lead it to make ineffective decisions; however,
> > this failure mode isn't confined to high number of sockets at all -
> > fewer number of fat pipes, tmpfs, mount points or any other kernel
> > objects which can be pinned by processes can trigger this.
> >
> > cgroup2 can track or control most of these usages and at least for us
> > switching to oomd for workload health management solves most of the
> > problems that we've encountered. In the longer term, the kernel OOM
> > killer can be improved to make better decisions too.
> >
> >
> > ("us" in the above is facebook btw.)
> >
> > So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
> > great (unfortunately the container messiness blocks that for now). But
> > as long as we don't, lifting the fd limit is not really making things
> > worse, given that there are tons of other easily exploitable ways to
> > acquire untracked memory...
> >
> > 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
> >
> ___
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Le mercredi 24 octobre 2018 à 08:42 +0200, Nicolas Mailhot a écrit : > Le mercredi 24 octobre 2018 à 00:52 +0200, Robert-André Mauchin a > écrit : > > On mardi 23 octobre 2018 23:47:05 CEST you wrote: > > > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > > > Anyway, since no one answers when I list the possible fixes and > > > > ask to > > > > choose between them, I fixed the Fedora spec files myself. > > > > > > > > Feel free to reintroduce %gosetup calls if you really want them, > > > > once > > > > the %gosetup implementation has been fixed. > > > > > > Thanks for doing but you messed up the bumping of all the > > > %changelog > > > entries. > > > > Used this Fish script to fix my SPEC: > > > > This does not need any fixing, it may not be the changelog format > you're > used to, but it's one of the changelog styles rpm understands, which > is > used by packages in Fedora, and which was documented at one point in > guidelines (no idea where the corresponding paragraph is today with > the > doc.fedoraproject changes) Concretely the * - version-release - changes format is a tad more flexible and allows publishing several fixes in a row without duplicating date lines * - version-release - changes - version-release - changes and so on And, our infra does not care if a changelog uses mixed style or not, since mass rebuilds will drop changelog entries in a single format in all Fedora specs, so you have many mixed style changelogs in the distribution today. (of course it's your specs, you can rewrite changelog entries any way that makes you feel better) Regards, -- Nicolas Mailhot ___ 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
How can I enable cgroups2 on my laptop?
On Fri, Oct 19, 2018, 17:27 Lennart Poettering wrote:
> On Fr, 19.10.18 09:12, Florian Weimer (fwei...@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.
> >
> > Which kernel version is that? Is that a new patch? Or some older
> > kernel?
> >
> > It's definitely not true for kernel 4.18, see the script I posted.
>
> I inquired Tejun Heo about this all, this is what he replied:
>
>
> In cgroup1, socket buffers are handled by a separate memory
> sub-controller. It's cumbersome to use, somewhat broken and doesn't
> allow for comprehensive memory control. cgroup2, however, by default
> accounts socket buffer as part of a given cgroup's memory consumption
> correctly interacting with socket window management.
>
> OOM killer too fails to take socket buffer into account and high
> number of sockets can lead it to make ineffective decisions; however,
> this failure mode isn't confined to high number of sockets at all -
> fewer number of fat pipes, tmpfs, mount points or any other kernel
> objects which can be pinned by processes can trigger this.
>
> cgroup2 can track or control most of these usages and at least for us
> switching to oomd for workload health management solves most of the
> problems that we've encountered. In the longer term, the kernel OOM
> killer can be improved to make better decisions too.
>
>
> ("us" in the above is facebook btw.)
>
> So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
> great (unfortunately the container messiness blocks that for now). But
> as long as we don't, lifting the fd limit is not really making things
> worse, given that there are tons of other easily exploitable ways to
> acquire untracked memory...
>
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Le mercredi 24 octobre 2018 à 00:52 +0200, Robert-André Mauchin a écrit : > On mardi 23 octobre 2018 23:47:05 CEST you wrote: > > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > > Anyway, since no one answers when I list the possible fixes and > > > ask to > > > choose between them, I fixed the Fedora spec files myself. > > > > > > Feel free to reintroduce %gosetup calls if you really want them, > > > once > > > the %gosetup implementation has been fixed. > > > > Thanks for doing but you messed up the bumping of all the %changelog > > entries. > > Used this Fish script to fix my SPEC: > This does not need any fixing, it may not be the changelog format you're used to, but it's one of the changelog styles rpm understands, which is used by packages in Fedora, and which was documented at one point in guidelines (no idea where the corresponding paragraph is today with the doc.fedoraproject changes) Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: PSA: builds using forge macros with tags broken on rawhide
Le mardi 23 octobre 2018 à 23:47 +0200, Robert-André Mauchin a écrit : > On mardi 23 octobre 2018 22:43:16 CEST Nicolas Mailhot wrote: > > Anyway, since no one answers when I list the possible fixes and ask > > to > > choose between them, I fixed the Fedora spec files myself. > > > > Feel free to reintroduce %gosetup calls if you really want them, > > once > > the %gosetup implementation has been fixed. > > > Thanks for doing but you messed up the bumping of all the %changelog > entries. How exactly please? -- Nicolas Mailhot ___ 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: Orphaned python2-astroid and python2-pylint
On Tue, Oct 23, 2018 at 02:59:28PM +0200, Miro Hrončok wrote: > Hi, > > I've just orphaned python2-astroid and python2-pylint. > > I don't need them and I don't want to maintain legacy python2 packages. > > Those are needed for python2-spyder, python2-asttokens, > python2-flake8-import-order. Please consider removing those, so we > can retire python2-astroid and python2-pylint. If you need to keep > them, please consider maintaining python2-astroid and/or > python2-pylint. I dropped python2-flake8-import-order and python2-asttokens now. Zbyszek ___ 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
