Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On 19.11.2020 23:13, Matthew Miller wrote: Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build. By allowing such packages, we will open the Pandora's box. Most of them will never receive updates and will have known bugs and security vulnerabilities. As a result, the packages that will use them will also be vulnerable. That's why I'm strongly against this proposal. All packages must be equally maintained. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 23:11, Michael Catanzaro wrote: Enjoy: https://github.com/matrix-org/purple-matrix/ I suggest not using purple-matrix as it doesn't support most of the protocol features such as quotes, replies, message editing, etc. due to libpurple's internal limitations (immutable history). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 23:55, Matthew Miller wrote: In this case for our server, we would use FAS single-sign-on for accounts. But this server should support Matrix federation feature. We shouldn't force users to use only this server in order to be able to participate in discussions. I already have my own Matrix server. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 20.11.2020 02:06, Dominik 'Rathann' Mierzejewski wrote: I know the difference and yes, you're able to participate without registration in that room. There are free levels of privacy settings: 1. join via invitation; 2. public group with guests; 3. public room without guests. Most of rooms keep guests feature disabled due to spam attacks. You will need a Matrix account on any federated server to be able to join. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 20.11.2020 05:14, Matthew Miller wrote: When I view this room in a private browser window, I can see the conversation, but at the bottom, it says "Join the conversation with an account" and presents "Sign In" / "Sign Up" buttons. In the room settings, admins can enable or disable guests (users without Matrix accounts). Most of rooms keep this feature disabled due to spam attacks. If the user has a Matrix account on server A, they can easily join the room on server B, and the room will be copied with the full history to their server. The distributed Matrix rooms are a huge advantage of the Matrix protocol. They will cannot be censored or destroyed due to server outages. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-33-20201120.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201119.0): ID: 726218 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/726218 ID: 726225 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/726225 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1899556] perl-PDL-2.025 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899556 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED CC|caillon+fedoraproject@gmail | |.com, | |jakub.jedel...@gmail.com, | |ka...@ucw.cz, | |lkund...@v3.sk, | |rhug...@redhat.com, | |rstr...@redhat.com, | |sandm...@redhat.com,| |tjczep...@gmail.com | Doc Type|--- |If docs needed, set a value -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1898691] perl-Tk-GraphViz-1.07 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1898691 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED CC||jples...@redhat.com Fixed In Version||perl-Tk-GraphViz-1.07-1.fc3 ||4 Resolution|--- |RAWHIDE Assignee|lkund...@v3.sk |jples...@redhat.com Doc Type|--- |If docs needed, set a value Last Closed||2020-11-20 07:09:03 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
I'm not going to give a firm recommendation for or against any platform but I'd like to make two suggestions: a) why not slow the process down and allow more ideas to come forward? There is no urgent need to change things in a month or whatever. This is a reasonable suggestion. Since one can bridge Matrix and IRC it is possible for different IRC channels to try it out. The ability to bridge Matrix really helps since one does not need to install another client for each new group conversation. One worry with Matrix is that the core protocol has less of a structured development and ratification process than IRC [1] or XMPP [2], so long term use is unclear. b) it is really important to look at the organizational factors and not just the technical factors. Today, too many organizations allow their culture to be shaped by whatever tool is available. I'll refrain from giving examples of the disasters that follow. For any free software organization and any other type of organization too, it needs to be organization first, tool second. This is a good point. As has been pointed out, the desktop clients need some work, and at present nothing with performance of the Telegram client[3]. There are also a number of different implementations of the server to consider [4],[5],[6] [1] https://ircv3.net/irc/ [2] https://en.wikipedia.org/wiki/XMPP [3] https://github.com/telegramdesktop/tdesktop [4] https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta [5] https://gitlab.com/mascarene/mascarene [6] https://gitlab.com/famedly/conduit ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Fri, Nov 20, 2020 at 02:06:46AM +0100, Dominik 'Rathann' Mierzejewski wrote: > > > No, you don't. I've just joined a random room without any kind of > > > registration. Try it yourself if you don't believe me: > > > https://app.element.io/#/room/#lounge:privacytools.io > > You are able to view it but are you able to participate? If not, you > > haven't joined > I know the difference and yes, you're able to participate without > registration in that room. When I view this room in a private browser window, I can see the conversation, but at the bottom, it says "Join the conversation with an account" and presents "Sign In" / "Sign Up" buttons. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 in GCP
On Thu, Nov 19, 2020 at 07:41:02PM -0500, Dusty Mabe wrote: > We have published an image into GCP for Fedora 33 (see [1]). > The details are: > image project: fedora-cloud > image name:fedora-cloud-base-gcp-33-1-2-x86-64 > We're hoping to get this information added to the website at some point. What's needed for that? -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2aa68c5f5e tor-0.4.3.7-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-317c124dc0 rpki-client-6.8p1-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c93c61069 pngcheck-2.4.0-2.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3000c1eea seamonkey-2.53.5-2.el8 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b5debb24b chromium-86.0.4240.198-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing adobe-source-han-sans-jp-fonts-2.002-1.el8 ara-1.5.3-1.el8 cowsay-3.04-16.el8 iotop-c-1.15-1.el8 prewikka-updatedb-5.2.0-1.el8 python-bravado-11.0.2-1.el8 python-bravado-core-5.17.0-1.el8 swift-lang-5.3.1-1.el8 Details about builds: adobe-source-han-sans-jp-fonts-2.002-1.el8 (FEDORA-EPEL-2020-80fe310402) Adobe OpenType Pan-CJK font family for Japanese Update Information: New package added for epel8 ChangeLog: References: [ 1 ] Bug #1789558 - Request to package Adobe fonts for EPEL 8 https://bugzilla.redhat.com/show_bug.cgi?id=1789558 ara-1.5.3-1.el8 (FEDORA-EPEL-2020-d83d327b63) Records Ansible playbooks and makes them easier to understand and troubleshoot Update Information: Update to latest upstream release ChangeLog: * Fri Oct 23 2020 David Moreau Simard - 1.5.3-1 - Update to latest upstream release cowsay-3.04-16.el8 (FEDORA-EPEL-2020-74b6d67aa6) Configurable speaking/thinking cow Update Information: Add fox cow. ChangeLog: * Thu Nov 19 2020 Filipe Brandenburger - 3.04-16 - Add fox cow. * Mon Jul 27 2020 Fedora Release Engineering - 3.04-15 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild References: [ 1 ] Bug #1899740 - Please include fox cow with the Fedora/EPEL package https://bugzilla.redhat.com/show_bug.cgi?id=1899740 iotop-c-1.15-1.el8 (FEDORA-EPEL-2020-94dd7506b4) Simple top-like I/O monitor (implemented in C) Update Information: Initial packaging for Fedora ChangeLog: prewikka-updatedb-5.2.0-1.el8 (FEDORA-EPEL-2020-08a0f3dc95) Database update scripts for prewikka Update Information: New package to update the SQL schema of Prewikka ChangeLog: python-bravado-11.0.2-1.el8 (FEDORA-EPEL-2020-25754e44b0) Library for accessing Swagger-enabled API's Update Information: Version 11.0.2 ChangeLog: python-bravado-core-5.17.0-1.el8 (FEDORA-EPEL-2020-6ca71466ba) Library for adding Swagger support to clients and servers Update Information: Initial package.
[Bug 1899180] perl-PAR-Dist-0.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899180 --- Comment #4 from Fedora Update System --- FEDORA-2020-0971c820e4 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0971c820e4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0971c820e4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1899180] perl-PAR-Dist-0.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899180 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- FEDORA-2020-9ac548fe1c has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9ac548fe1c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9ac548fe1c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Mock needs more space
I'm attempting an armhfp build with mock and it insists it needs "At least 243MB more space needed on the / filesystem." I have 1.1 TB free on /, so I'm assuming there's some kind of limit set somehow, but I can't figure out how to adjust it. I don't see anything that looks promising in the config files, or the manpage. Anybody have a clue for me? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: libcap-ng update coming to rawhide
On Wed, 2020-11-18 at 14:32 -0500, Steve Grubb wrote: > On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote: > > A new version of libcap-ng is going to be released next week. Normally this > > isn't newsworthy, nor is this a soname version bump. But it is important > > to let the broader community know something about it. The behaviour of > > capng_apply is changing slightly. > > > > In the past, capng_apply would silently eat errors when the bounding set > > could not be changed. In order to change the bounding set, you have to have > > > > CAP_SETPCAP. A developer reported an issue in github where their project > > needed to know that capng_apply was completely successful changing the > > bounding set. Meaning that they need an error returned. I didn't think too > > much of it and made the change. > > > > Then one day I noticed that I could not update a package against Fedora's > > git or push a change. Looking into this, I found gnome-keyring was not > > working. [1] I dug into the source code and found that it was trying to > > change the bounding set when it had partial capabilities. The fix is to > > simply verify that you have CAP_SETPCAP before attempting this. > > > > I don't know of any other software that is affected. But I wanted to give > > everyone a heads up before I push it out. I always dogfood libraries I > > work on, so maybe this is the only issue. > > > > Eventually libcap-ng needs to get pushed over to F33 because there is a > > problem with ambient capailities that the new release fixes. And speaking > > of ambient capabilities, the new version of libcap-ng contains a new > > library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app > > to drop ambient capabilities leaving the other capabilities intact. All > > the work is done in the constructor, so no function calls are needed. > > Hello, > > The new libcap-ng has been built into rawhide. ...and it does break gnome-keyring, and it also breaks cifs-utils (so you can't mount CIFS/SMB shares), as per this upstream bug report: https://github.com/stevegrubb/libcap-ng/issues/21 whose reporter also noted what looks like a valid problem in your gnome-keyring fix. Was it really necessary to build this when you *knew* a major package did not work with it? Did you talk to the Workstation folks about getting the patch applied to gnome-keyring? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1898438] perl-Search-Xapian-1.2.25.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1898438 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Search-Xapian-1.2.25.3 |perl-Search-Xapian-1.2.25.4 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 1.2.25.4 Current version/release in rawhide: 1.2.25.2-7.fc33 URL: http://search.cpan.org/dist/Search-Xapian/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/6580/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Friday, 20 November 2020 at 02:01, Rahul Sundaram wrote: > On Thu, Nov 19, 2020 at 7:56 PM Dominik 'Rathann' Mierzejewski wrote: > > > > No, you don't. I've just joined a random room without any kind of > > registration. Try it yourself if you don't believe me: > > https://app.element.io/#/room/#lounge:privacytools.io > > You are able to view it but are you able to participate? If not, you > haven't joined I know the difference and yes, you're able to participate without registration in that room. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
Hi On Thu, Nov 19, 2020 at 7:56 PM Dominik 'Rathann' Mierzejewski wrote: > > No, you don't. I've just joined a random room without any kind of > registration. Try it yourself if you don't believe me: > https://app.element.io/#/room/#lounge:privacytools.io > You are able to view it but are you able to participate? If not, you haven't joined Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thursday, 19 November 2020 at 23:52, Michael Catanzaro wrote: > On Thu, Nov 19, 2020 at 11:37 pm, Dominik 'Rathann' Mierzejewski > wrote: > > Instead of channels, you have rooms and users can be either > > unregistered or registered, just like on IRC. > > No, you have to register. No, you don't. I've just joined a random room without any kind of registration. Try it yourself if you don't believe me: https://app.element.io/#/room/#lounge:privacytools.io Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 33 in GCP
We have published an image into GCP for Fedora 33 (see [1]). The details are: image project: fedora-cloud image name:fedora-cloud-base-gcp-33-1-2-x86-64 We're hoping to get this information added to the website at some point. Dusty [1] https://pagure.io/cloud-sig/issue/318 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
I'm opposed to this change as well, due to, imo, making it harder/less obvious/more confusing to see where I have to pull from any given package that I want to consume as an end-user on my system, or as a package maintainer in my buildroot. I've however found myself having to maintain packages that I only needed as builddeps for the packages that I really care about. So that's definitely not ideal, however: I like the notion of a 'metadata-based' approach, where labels are added to packages (or rather, their respective dist-git repos) that potentially fall under the 'lightly maintained' category. These labels could be processed by the distro internally and acted upon accordingly in some way, but I certainly don't want that maintenance status to manifest in the package being made available in one repo or the other (and even potentially moving from one to the other between releases per changes in their apparent quality of maintenance). Cheers, Christian On Fri, Nov 20, 2020 at 12:44 AM Dan Čermák wrote: > Emmanuel Seyman writes: > > >> However, I'm not stuck on that one and it's probably not useful to stay > >> stuck on it if there's not enough support to do it. So, let's find a > >> different solution. > > > > What exactly do you want to do with this list of lightly-maintained > > packages? > > I have been wondering this myself: what advantage will this bring, > besides a bit more peace of mind for the maintainer? > > I'd also like to point out that we actually have a concept for lightly > maintained packages that cannot reach end users: modularity. I know its > not popular, but it would be an option for this. However, I wouldn't be > a fan if it being used like this. > > > Cheers, > > Dan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
Elliott Sales de Andrade writes: >> > I honestly can see exactly zero downsides to using a Matrix setup as >> > compared to using IRC, and a giant pile of upsides, starting with "I no >> > longer need to dedicate a small portion of my brain to remembering how >> > my IRC bouncer setup works and maintaining it". >> >> Well my experience when I looked at matrix desktop clients >> before was that they needed more screen real estate to be >> usable than IRC clients, which is certainly one downside and >> probably a direct consequence of rich media support. >> >> There's also the fact that unless I can get it to talk to all >> the same chat systems I have pidgin talking to I would need to >> be running two clients instead of one. >> > > I don't know if it's packaged and can't speak to its quality, but > there exists a protocol plugin to use Matrix in Pidgin: > https://github.com/matrix-org/purple-matrix/#readme > I have used purple-matrix and purple-discord from the repos for a while and they work pretty well. But I eventually stopped using them, as all pidgin plugins suffer from the same issue: they have to stuff a pretty rich chat experience into a client that was designed for IRC. I.e. threading, replies, reactions, edits, history have to get emulated in (imho) suboptimal ways. Both plugins were very good given these constraints, but running Element.io & Discord in a browser tab or in Ferdi eventually turned out to work better for me. But YMMW. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
Emmanuel Seyman writes: >> However, I'm not stuck on that one and it's probably not useful to stay >> stuck on it if there's not enough support to do it. So, let's find a >> different solution. > > What exactly do you want to do with this list of lightly-maintained > packages? I have been wondering this myself: what advantage will this bring, besides a bit more peace of mind for the maintainer? I'd also like to point out that we actually have a concept for lightly maintained packages that cannot reach end users: modularity. I know its not popular, but it would be an option for this. However, I wouldn't be a fan if it being used like this. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1899767] New: perl-HTTP-Cookies-6.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899767 Bug ID: 1899767 Summary: perl-HTTP-Cookies-6.09 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Cookies Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 6.09 Current version/release in rawhide: 6.08-4.fc33 URL: http://search.cpan.org/dist/HTTP-Cookies/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2974/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 19 Nov 2020 at 14:44, Tom Hughes via devel wrote: > > On 19/11/2020 19:25, Adam Williamson wrote: > > > I mean, I'm an old fogey too, but at *some* point we do have to accept > > that new things can be actively better. > > True. > > > I honestly can see exactly zero downsides to using a Matrix setup as > > compared to using IRC, and a giant pile of upsides, starting with "I no > > longer need to dedicate a small portion of my brain to remembering how > > my IRC bouncer setup works and maintaining it". > > Well my experience when I looked at matrix desktop clients > before was that they needed more screen real estate to be > usable than IRC clients, which is certainly one downside and > probably a direct consequence of rich media support. > > There's also the fact that unless I can get it to talk to all > the same chat systems I have pidgin talking to I would need to > be running two clients instead of one. > I don't know if it's packaged and can't speak to its quality, but there exists a protocol plugin to use Matrix in Pidgin: https://github.com/matrix-org/purple-matrix/#readme > I am interested though, and did actually explore the idea of > running my own home server and what I could bridge it to (so > not that different to running my own bouncer now...) recently. > > Anyway I just looked at the three clients that were suggested > earlier - all three are using Qt which makes them virtually > unusable on a wayland/gnome desktop as far as I can see as the > resize handles are so small they're impossible to use. > > More amusingly one of them crashed as soon as I logged in and > a second went into a "your window is too small mode" as soon > as I resized it to match my IRC client. > > The third was better, but rendered the conversation in that > left/right style of SMS clients, which is horrible for a chat > room. > > No doubt there are others I can try... > > Tom > -- Elliott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
* Matthew Miller [19/11/2020 17:13] : > > Some packagers in Fedora do not have time to maintain the build dependencies > for the packages that they are actually interested in and have time to > build. I suspect that these packages are maintained only to the point where they can build (and thus be used as buildreqs) but their maintainer also doesn't want them to be updated without making sure that the update will not break the package they are really interested in. > However, I'm not stuck on that one and it's probably not useful to stay > stuck on it if there's not enough support to do it. So, let's find a > different solution. What exactly do you want to do with this list of lightly-maintained packages? Is this something you want to present to end-users? Is this a list we should show to people tempted to become packagers? Do we want to generate auto-replies to bugs filed in Bugzilla? Should SIGs keep a lookout for security fixes to apply? I suspect we'll only be able to determine the best approach if we know what problem you're trying to solve. Emmanuel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 5:55 PM Matthew Miller wrote: > > On Thu, Nov 19, 2020 at 04:52:56PM -0600, Michael Catanzaro wrote: > > wrote: > > > Instead of channels, you have rooms and users can be either > > >unregistered or registered, just like on IRC. > > No, you have to register. > > In this case for our server, we would use FAS single-sign-on for > accounts. > However, that would not prohibit folks from visiting rooms on our server from other Matrix servers, as the federation aspect would permit that. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 04:52:56PM -0600, Michael Catanzaro wrote: > wrote: > > Instead of channels, you have rooms and users can be either > >unregistered or registered, just like on IRC. > No, you have to register. In this case for our server, we would use FAS single-sign-on for accounts. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 11:37 pm, Dominik 'Rathann' Mierzejewski wrote: Instead of channels, you have rooms and users can be either unregistered or registered, just like on IRC. No, you have to register. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 23:37 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 19 November 2020 at 21:46, Erich Eickmeyer wrote: > > On 11/19/20 12:32 PM, Dominik 'Rathann' Mierzejewski wrote: > > > I don't know how Matrix works exactly... > > Then I suggest educating yourself. Go to element.io and check it out. > > So I did and it's not that different from IRC from an end-user > perspective. Instead of channels, you have rooms and users can be either > unregistered or registered, just like on IRC. Rooms can be public or only > for registered users, same as on IRC. The only user-visible difference > I found so far is the chat history persistence. This can be either good > or bad, depending on your point of view. So... I don't really see the > advantage here. The chat history persistence - and seamless use across devices - is a huge advantage. The other advantage is that you can sign up for and use this system simply and entirely in a web browser, a process people are comfortable with. It is similar to systems they may well already be familiar with, like Slack and Discord. People are not comfortable with setting up IRC and learning to use nickserv. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 11:37:05PM +0100, Dominik 'Rathann' Mierzejewski wrote: > Oh and it's extremely slow compared to IRC. The federation you mean, or in general? It is true that the free matrix.org can get overwhelmed; this is one of the reasons for having our own server. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thursday, 19 November 2020 at 21:46, Erich Eickmeyer wrote: > On 11/19/20 12:32 PM, Dominik 'Rathann' Mierzejewski wrote: > > I don't know how Matrix works exactly... > Then I suggest educating yourself. Go to element.io and check it out. So I did and it's not that different from IRC from an end-user perspective. Instead of channels, you have rooms and users can be either unregistered or registered, just like on IRC. Rooms can be public or only for registered users, same as on IRC. The only user-visible difference I found so far is the chat history persistence. This can be either good or bad, depending on your point of view. So... I don't really see the advantage here. Oh and it's extremely slow compared to IRC. > If you don't know what it is or how it works, then why chime-in? That adds > nothing to the conversation if you don't know what you're talking about. I used the information provided by other participants in this thread, assuming they were factually correct. Was I mistaken? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Wed, Nov 18, 2020 at 12:22:26PM -0500, Matthew Miller wrote: >http://whenisgood.net/k5brwbd FWIW so far tomorrow and next week are (not surprisingly given the US holidays) much less popular than the week of November 30, so let's continue the discussion here and on the Discourse thread. https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628 -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On Thu, Nov 19, 2020 at 03:04:26PM -0500, Robbie Harwood wrote: > What I believe Alex and I are arguing is that there is no technical > advantage to RHEL-style repo-splitting where some packages go in one > repo and a non-overlapping set goes in another. Rather, it incurs a > large burden both on maintainers and end-users. Remember, I'm trying to solve a real problem here: Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build. The RHEL solution is to not ship those. The packagers don't feel good about just dumping the — as we've said, "lightly maintained" — deps into the package collection. They'd feel better _not packaging the main packages in Fedora at all_. This is not a good outcome. I'd like to find a better approach, and having a repo for these things (which, as I've said, unlike RHEL, we'd absolutely ship) is one idea that came to mind. However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution. One approach suggested was a tag in spec files themselves. Another one might be to have metadata in a separate file in dist-git. Another would be to have an external service which maintains the list — like PDC does for "critical path" packages. Such a system could also be used for other things, like defining a minimal core which we'd want to apply greater CI gating and scrutiny to. (Maybe the existing critical path set is a good start, but I'm thinking something that starts smaller.) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 7:43 pm, Tom Hughes via devel wrote: There's also the fact that unless I can get it to talk to all the same chat systems I have pidgin talking to I would need to be running two clients instead of one. Enjoy: https://github.com/matrix-org/purple-matrix/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1899731] New: perl-ExtUtils-MakeMaker-7.56 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899731 Bug ID: 1899731 Summary: perl-ExtUtils-MakeMaker-7.56 is available Product: Fedora Version: rawhide Status: NEW Component: perl-ExtUtils-MakeMaker Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 7.56 Current version/release in rawhide: 7.54-1.fc34 URL: http://search.cpan.org/dist/ExtUtils-MakeMaker/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2867/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2020-11-20 from 21:00:00 to 22:00:00 UTC At fedora-meet...@irc.freenode.net The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9854/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 11/19/20 12:32 PM, Dominik 'Rathann' Mierzejewski wrote: I don't know how Matrix works exactly... Then I suggest educating yourself. Go to element.io and check it out. If you don't know what it is or how it works, then why chime-in? That adds nothing to the conversation if you don't know what you're talking about. -- Erich Eickmeyer Maintainer Fedora Jam ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thursday, 19 November 2020 at 19:47, Vitaly Zaitsev via devel wrote: > On 19.11.2020 19:31, Dominik 'Rathann' Mierzejewski wrote: > > Just like IRC. > > No. If the FreeNode network goes down, all Fedora IRC chats will > disappear. Network consists of multiple servers. They'd all have to go down. At the time of this writing, there are 5 IPv4 and 3 IPv6 addresses under chat.freenode.net. > In Matrix if one server will stop working, users can easily switch to > another and continue chatting. Just like IRC. > All messages will be saved. Lack of server-side message persistence is a feature of IRC. Granted, that might not be what many new users want. > Also users from the other Matrix servers (matrix.org or self-hosted) > can join without any registration. Federated network. I don't know how Matrix works exactly, but I doubt anyone can join without any authorization. That would be abused pretty quickly. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On Thu, Nov 19, 2020 at 03:04:26PM -0500, Robbie Harwood wrote: > >> As my team has found out within Red Hat, this repo split has been a > >> large PITA. Because RHEL also won't self-host and many sub-packages > >> are missing from released bits that are otherwise available in e.g., > >> BUILDROOT, building our bits in COPR for QE to test has been an > >> impossible battle. After close to a year, this use case still hasn't > >> been enabled internally. > > But that's not what's being proposed. > Isn't it? Some packages go in main, and others go in light (or whatever > it'd be called)? Right, it is not. there's no "many sub-packages are missing from released bits that are otherwise available". In fact, going back to the beginning, making such packages _available_ is exactly the intention. So it's the opposite. > > We've had different repos in Fedora for years -- the main repo, plus > > updates, plus updates-testing. And we have the separate modularity one > > now. Fedora is going to continue to self-host, and doesn't have > > whatever business reason RHEL has for not shipping the buildroot. > I think that conflates uses of the word "different". > > The package sets between main/updates/updates-testing are not > meaningfully different: almost all packages in updates/updates-testing > already have a version in main. That is, you would have a complete > system with pretty much every package available just by setting up main. Okay, fair enough. But still, it's not like "there's more than one repo" is suddenly new science. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thursday, November 19, 2020 5:54:52 PM WET Richard W.M. Jones wrote: > I'm not sure that message editing is a feature. In fairness as long as the grace period is fixed and small that is not a bad thing. E.g it allows you to fix lots of cases where you found that the message was incomplete after sending it or it had incorrect information that you only found after sending it. That allows to clean some noise and it is not a bad thing. :-) -- José Abílio___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 08:00:24PM +, Tom Hughes via devel wrote: > On 19/11/2020 19:49, Neal Gompa wrote: > > > The GNOME-based one is Fractal, which is not available in Fedora as of > > right now. That said, the Qt based ones are in way better shape than > > the GNOME one. And QGnomePlatform should make them work reasonably > > well... > > My problem, at least on this hidpi laptop, is that the bit of the > window edge that I need to grab to resize it is only about one pixel > wide so virtually impossible to grab. Native gnome windows have a > much wider area I can grab. > > It might be better on my desktop that isn't hidpi and has a mouse > instead of a trackpad. You don't have to grab by the edge to resize, GNOME has useful features: - winkey+left mouse button inside the window let you move it (no need to target header bar) - winkey+middle mouse button inside window let you resize closest edge This unfortunately breaks in two cases: - you have scroll emulation enabled on middle button+trackpoint; or - you don't have middle button on your laptop :( -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
Matthew Miller writes: > On Wed, Nov 18, 2020 at 03:37:11PM -0500, Alexander Scheel wrote: >> I second what Robbie has said as well. >> >> I am against the thought of this change. >> >> As my team has found out within Red Hat, this repo split has been a >> large PITA. Because RHEL also won't self-host and many sub-packages >> are missing from released bits that are otherwise available in e.g., >> BUILDROOT, building our bits in COPR for QE to test has been an >> impossible battle. After close to a year, this use case still hasn't >> been enabled internally. > > But that's not what's being proposed. Isn't it? Some packages go in main, and others go in light (or whatever it'd be called)? > We've had different repos in Fedora for years -- the main repo, plus > updates, plus updates-testing. And we have the separate modularity one > now. Fedora is going to continue to self-host, and doesn't have > whatever business reason RHEL has for not shipping the buildroot. I think that conflates uses of the word "different". The package sets between main/updates/updates-testing are not meaningfully different: almost all packages in updates/updates-testing already have a version in main. That is, you would have a complete system with pretty much every package available just by setting up main. That's of course not how RHEL-style repo separation works: packages in AppStream, for instance, or BuildRoot, are wholly disjoint from those in BaseOS. (This is also how generalized modules behave.) What I believe Alex and I are arguing is that there is no technical advantage to RHEL-style repo-splitting where some packages go in one repo and a non-overlapping set goes in another. Rather, it incurs a large burden both on maintainers and end-users. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19/11/2020 19:49, Neal Gompa wrote: The GNOME-based one is Fractal, which is not available in Fedora as of right now. That said, the Qt based ones are in way better shape than the GNOME one. And QGnomePlatform should make them work reasonably well... My problem, at least on this hidpi laptop, is that the bit of the window edge that I need to grab to resize it is only about one pixel wide so virtually impossible to grab. Native gnome windows have a much wider area I can grab. It might be better on my desktop that isn't hidpi and has a mouse instead of a trackpad. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 19:43 +, Tom Hughes via devel wrote: > > No doubt there are others I can try... https://wiki.gnome.org/Apps/Fractal -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 2:44 PM Tom Hughes via devel wrote: > > On 19/11/2020 19:25, Adam Williamson wrote: > > > I mean, I'm an old fogey too, but at *some* point we do have to accept > > that new things can be actively better. > > True. > > > I honestly can see exactly zero downsides to using a Matrix setup as > > compared to using IRC, and a giant pile of upsides, starting with "I no > > longer need to dedicate a small portion of my brain to remembering how > > my IRC bouncer setup works and maintaining it". > > Well my experience when I looked at matrix desktop clients > before was that they needed more screen real estate to be > usable than IRC clients, which is certainly one downside and > probably a direct consequence of rich media support. > > There's also the fact that unless I can get it to talk to all > the same chat systems I have pidgin talking to I would need to > be running two clients instead of one. > > I am interested though, and did actually explore the idea of > running my own home server and what I could bridge it to (so > not that different to running my own bouncer now...) recently. > > Anyway I just looked at the three clients that were suggested > earlier - all three are using Qt which makes them virtually > unusable on a wayland/gnome desktop as far as I can see as the > resize handles are so small they're impossible to use. > > More amusingly one of them crashed as soon as I logged in and > a second went into a "your window is too small mode" as soon > as I resized it to match my IRC client. > > The third was better, but rendered the conversation in that > left/right style of SMS clients, which is horrible for a chat > room. > > No doubt there are others I can try... > The GNOME-based one is Fractal, which is not available in Fedora as of right now. That said, the Qt based ones are in way better shape than the GNOME one. And QGnomePlatform should make them work reasonably well... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19/11/2020 19:25, Adam Williamson wrote: I mean, I'm an old fogey too, but at *some* point we do have to accept that new things can be actively better. True. I honestly can see exactly zero downsides to using a Matrix setup as compared to using IRC, and a giant pile of upsides, starting with "I no longer need to dedicate a small portion of my brain to remembering how my IRC bouncer setup works and maintaining it". Well my experience when I looked at matrix desktop clients before was that they needed more screen real estate to be usable than IRC clients, which is certainly one downside and probably a direct consequence of rich media support. There's also the fact that unless I can get it to talk to all the same chat systems I have pidgin talking to I would need to be running two clients instead of one. I am interested though, and did actually explore the idea of running my own home server and what I could bridge it to (so not that different to running my own bouncer now...) recently. Anyway I just looked at the three clients that were suggested earlier - all three are using Qt which makes them virtually unusable on a wayland/gnome desktop as far as I can see as the resize handles are so small they're impossible to use. More amusingly one of them crashed as soon as I logged in and a second went into a "your window is too small mode" as soon as I resized it to match my IRC client. The third was better, but rendered the conversation in that left/right style of SMS clients, which is horrible for a chat room. No doubt there are others I can try... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 19 Nov 2020 at 14:25, Adam Williamson wrote: > On Thu, 2020-11-19 at 14:15 -0500, Stephen John Smoogen wrote: > > > > My apologies for that misinformation. While a federated chat system is a > > network of servers for people being social, I should not tie them in the > > same crappile as Social Networks where my logins and engagement are > > measured and sold. > > > > Open source is good, but it is still yet another distraction that I have > to > > learn > > a) which tool I need to add as a screen to watch things > > b) how to shut up from pinging me with 'blah mentioned you!', etc. > > c) avoid spending hours looking at it as something to do versus work. > > I mean, I'm an old fogey too, but at *some* point we do have to accept > that new things can be actively better. > > I honestly can see exactly zero downsides to using a Matrix setup as > compared to using IRC, and a giant pile of upsides, starting with "I no > longer need to dedicate a small portion of my brain to remembering how > my IRC bouncer setup works and maintaining it". > > If Fedora just moved to using this clearly superior system rather than > IRC, what would you still need IRC for? My answer to that is "basically > nothing", I think. Especially since GNOME seems to be moving to it too. > And like I said, I am not wanting to stop people from moving to it. I am against people saying it shouldn't be done. I am just getting off the bus, and wanted to say that is a better alternative than trying to generate stop energy. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 05:55:49PM +, Richard W.M. Jones wrote: > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: > > No, please. IRC bridges need to be closed to force users to switch > > to Matrix. > "force"? You may have said the quiet bit aloud ... To be clear, Vitaly isn't an insider to some secret decision here. I think you should just read this as enthusiasm. That said, let me say a couple of things out loud so that no one later thinks I'm trying to sneak anything: 1. Matrix has already been a success for several Fedora sub-communities, and others have been using just personally as a way to access bridged IRC channels for years. If the next-phase pilot I'm proposing (which is: bring those bridged channels to one Fedora-owned server, and to move #fedora-council there as well) is a success, I *definitely* plan to propose "Matrix primary" as the next step. That doesn't mean forcing people to switch, but I would like to see zodbot be replaced with Matrix-native bots (possibly several for different functions, rather than one swiss army knife?), and for our documentation to point to our chat server first. And it means that people on IRC might miss out on some of the rich features of Matrix which don't translate very well. 2. Marie and I spoke with management at Red Hat's Open Source Program Office, and they're willing to fund SaaS hosting for this _separate from the Fedora community budget_, because they also would like Fedora communication channels to feel more approachable. So that's something I'd like to take advantage of. (This would be via Element's hosted services, which are all open source. They'll do both hosting and instance administration, so this is really quite nice for us.) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-resolved in a container
On to, 19 marras 2020, Nikos Mavrogiannopoulos wrote: On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy wrote: On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote: >Hi, > I realized my fedora-based containers have an /etc/resolv.conf which >claims it is managed by resolved, and nsswitch.conf has "resolve" in >hosts. However, doing something like ># systemd-resolve --status > >results to: >sd_bus_open_system: No such file or directory > >Trying to start dbus claims that systemd is not the init: ># systemctl start dbus >System has not been booted with systemd as init system (PID 1). Can't operate. >Failed to connect to bus: Host is down > > >Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. Is that on the "default" fedora container, or do you use something else? On fedora33 I get the same message about dbus and systemd not being pid 1. We build our own Fedora container with systemd based on the 'default' one. I haven't tried 'fedora-init' variant as Dan suggested. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 14:15 -0500, Stephen John Smoogen wrote: > > My apologies for that misinformation. While a federated chat system is a > network of servers for people being social, I should not tie them in the > same crappile as Social Networks where my logins and engagement are > measured and sold. > > Open source is good, but it is still yet another distraction that I have to > learn > a) which tool I need to add as a screen to watch things > b) how to shut up from pinging me with 'blah mentioned you!', etc. > c) avoid spending hours looking at it as something to do versus work. I mean, I'm an old fogey too, but at *some* point we do have to accept that new things can be actively better. I honestly can see exactly zero downsides to using a Matrix setup as compared to using IRC, and a giant pile of upsides, starting with "I no longer need to dedicate a small portion of my brain to remembering how my IRC bouncer setup works and maintaining it". If Fedora just moved to using this clearly superior system rather than IRC, what would you still need IRC for? My answer to that is "basically nothing", I think. Especially since GNOME seems to be moving to it too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 19 Nov 2020 at 13:29, Adam Williamson wrote: > On Thu, 2020-11-19 at 13:23 -0500, Stephen John Smoogen wrote: > > On Thu, 19 Nov 2020 at 12:57, Richard W.M. Jones > wrote: > > > > > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel > wrote: > > > > On 19.11.2020 18:34, Radka Gustavsson wrote: > > > > > Rich, IRC is not being dropped, it is being bridged to modern, > > > > > "IRC-native" (for lack of better word in my vocabulary) platform. > > > > > Contributors who prefer to stay on IRC are welcome to do so and > > > > > won't really notice any difference. > > > > > > > > No, please. IRC bridges need to be closed to force users to switch > > > > to Matrix. > > > > > > "force"? You may have said the quiet bit aloud ... > > > > > > > > Everyone is entitled to their opinions, and honestly I am ok if this is > the > > way Fedora goes. I have no interest in opening any more social network > > accounts, but I am not going to stop people from moving into other > places. > > If I am dropped out of communication to the point I can't do my job, then > > it is time for me to move out of this job and let someone else do it. > > Matrix isn't a social network account. It's an open source federated > chat system. > My apologies for that misinformation. While a federated chat system is a network of servers for people being social, I should not tie them in the same crappile as Social Networks where my logins and engagement are measured and sold. Open source is good, but it is still yet another distraction that I have to learn a) which tool I need to add as a screen to watch things b) how to shut up from pinging me with 'blah mentioned you!', etc. c) avoid spending hours looking at it as something to do versus work. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 05:53:29PM +, Richard W.M. Jones wrote: > > I too love dinosaurs... but I also work on 4 different computers and two > > mobile > > devices every day. Having to literally switch hardware to participate in IRC > > meetings is pain in the ass for some of our contributors (myself included.) > I also use many different computers and have no such problem, because > I use screen + znc. (Same in fact for email: screen + mutt) We were just talking today in the Fedora Council virtual face-to-face about how Fedora could really use a formalized Project Management community of practice -- people interested, skilled, and willing to lend their time and expertise to SIGs and other groups in Fedora who would benefit. I don't want to gate involvement like that on people with those skills and interests also being able to just easily set up ZNC, learn screen, etc. (including for that matter having an always-on system where that makes sense). Sure, it's not actually hard in an absolute sense and I trust any reasonably smart person can figure it out, but... why make people start there when it's not even their interest? -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 19:28 +0100, Vitaly Zaitsev via devel wrote: > On 19.11.2020 19:16, Adam Williamson wrote: > > If we use a central server, only one server needs maintaining, and the > > problem is solved for everyone. The benefit seems pretty clear. > > Matrix don't need a central server. This is a federated network. All > rooms are hosted on multiple servers. I was talking about how it appears to a user, not the technical details. To a Fedora user there's a Fedora server they join and it does all the backlog-maintaining stuff for them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 05:08:08PM +, Richard W.M. Jones wrote: > There's quite a lot wrong here - a video meeting(!) to discuss > dropping a commonly used and well established channel of > communication. Well, I guess at least you didn't decide to use the > proprietary awfulness of Slack. > > Couldn't you just talk about this on email? We can do that too; Neal just suggested a video call as way to get interested parties together. And, yeah, I'm also not interested in slack. > What's the reason why hosting your own server for a fairly uncommon > chat protocol is better than continuing to use IRC? There are a number of things: * We know IRC is a barrier for new users. Any onboarding which has to include explaining what NickServ is is starting underwater -- and that's just the start of it! * IRC doesn't have persistence. People want that. Setting up ZNC is another barrier. * Being able to add reactions, send images, and edit typos are not essential, but really quite nice. * It's not all that uncomming; Mozilla, GNOME, and openSUSE have also moved to Matrix. * Since you mentioned Slack: let's get behind an open source alternative before it's too late. * Matrix has reasonably decent bridging to IRC, which will make migration easy (and if you don't want to migrate ever, that will remain an option). ... and probably others. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 19:31, Dominik 'Rathann' Mierzejewski wrote: Just like IRC. No. If the FreeNode network goes down, all Fedora IRC chats will disappear. In Matrix if one server will stop working, users can easily switch to another and continue chatting. All messages will be saved. Also users from the other Matrix servers (matrix.org or self-hosted) can join without any registration. Federated network. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)
On Wed, Nov 18, 2020 at 03:37:11PM -0500, Alexander Scheel wrote: > I second what Robbie has said as well. > > I am against the thought of this change. > > As my team has found out within Red Hat, this repo split has been a > large PITA. Because RHEL also won't self-host and many sub-packages > are missing from released bits that are otherwise available in e.g., > BUILDROOT, building our bits in COPR for QE to test has been an > impossible battle. After close to a year, this use case still hasn't > been enabled internally. But that's not what's being proposed. We've had different repos in Fedora for years -- the main repo, plus updates, plus updates-testing. And we have the separate modularity one now. Fedora is going to continue to self-host, and doesn't have whatever business reason RHEL has for not shipping the buildroot. > Consider also what other groups such as COPR have to do to support > repo splits. Yeah, it might be quick to split it in Koji and repo > files, but the impact on other teams and contributors is a huge > negative. If people have to go searching for special repos and > dependencies to build their packages, the developer experience of > Fedora will suffer more. That will push more people to Ubuntu. I'm not suggesting anything that would require anyone to "go searching for special repos". All that said, I think we can implement something that serves the purpose I'm looking for as metadata. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 1:32 PM Dominik 'Rathann' Mierzejewski wrote: > > On Thursday, 19 November 2020 at 19:28, Vitaly Zaitsev via devel wrote: > > On 19.11.2020 19:16, Adam Williamson wrote: > > > If we use a central server, only one server needs maintaining, and the > > > problem is solved for everyone. The benefit seems pretty clear. > > > > Matrix don't need a central server. This is a federated network. All rooms > > are hosted on multiple servers. > > Just like IRC. > No, it isn't. Federation implies either freely cross-server identities or freely cross-server access. In order to access a channel on Freenode, you need a Freenode account and log into the Freenode server itself. Matrix allows MXIDs for rooms and users to float across servers freely by synchronizing events across subscribed servers. For example, this allows my MXID on matrix.org to login to kde.org Matrix rooms and chat with folks from kde.org, opensuse.org, mozilla.org, and so on. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thursday, 19 November 2020 at 19:28, Vitaly Zaitsev via devel wrote: > On 19.11.2020 19:16, Adam Williamson wrote: > > If we use a central server, only one server needs maintaining, and the > > problem is solved for everyone. The benefit seems pretty clear. > > Matrix don't need a central server. This is a federated network. All rooms > are hosted on multiple servers. Just like IRC. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 19:16, Adam Williamson wrote: If we use a central server, only one server needs maintaining, and the problem is solved for everyone. The benefit seems pretty clear. Matrix don't need a central server. This is a federated network. All rooms are hosted on multiple servers. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 13:23 -0500, Stephen John Smoogen wrote: > On Thu, 19 Nov 2020 at 12:57, Richard W.M. Jones wrote: > > > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: > > > On 19.11.2020 18:34, Radka Gustavsson wrote: > > > > Rich, IRC is not being dropped, it is being bridged to modern, > > > > "IRC-native" (for lack of better word in my vocabulary) platform. > > > > Contributors who prefer to stay on IRC are welcome to do so and > > > > won't really notice any difference. > > > > > > No, please. IRC bridges need to be closed to force users to switch > > > to Matrix. > > > > "force"? You may have said the quiet bit aloud ... > > > > > Everyone is entitled to their opinions, and honestly I am ok if this is the > way Fedora goes. I have no interest in opening any more social network > accounts, but I am not going to stop people from moving into other places. > If I am dropped out of communication to the point I can't do my job, then > it is time for me to move out of this job and let someone else do it. Matrix isn't a social network account. It's an open source federated chat system. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 19 Nov 2020 at 12:57, Richard W.M. Jones wrote: > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: > > On 19.11.2020 18:34, Radka Gustavsson wrote: > > >Rich, IRC is not being dropped, it is being bridged to modern, > > >"IRC-native" (for lack of better word in my vocabulary) platform. > > >Contributors who prefer to stay on IRC are welcome to do so and > > >won't really notice any difference. > > > > No, please. IRC bridges need to be closed to force users to switch > > to Matrix. > > "force"? You may have said the quiet bit aloud ... > > Everyone is entitled to their opinions, and honestly I am ok if this is the way Fedora goes. I have no interest in opening any more social network accounts, but I am not going to stop people from moving into other places. If I am dropped out of communication to the point I can't do my job, then it is time for me to move out of this job and let someone else do it. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 1:09 PM Daniel Pocock wrote: > > > > On 19/11/2020 18:55, Richard W.M. Jones wrote: > > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: > >> On 19.11.2020 18:34, Radka Gustavsson wrote: > >>> Rich, IRC is not being dropped, it is being bridged to modern, > >>> "IRC-native" (for lack of better word in my vocabulary) platform. > >>> Contributors who prefer to stay on IRC are welcome to do so and > >>> won't really notice any difference. > >> > >> No, please. IRC bridges need to be closed to force users to switch > >> to Matrix. > > > > "force"? You may have said the quiet bit aloud ... > > yes, it got my attention too > > I'm not going to give a firm recommendation for or against any platform > but I'd like to make two suggestions: > > a) why not slow the process down and allow more ideas to come forward? > There is no urgent need to change things in a month or whatever. > > b) it is really important to look at the organizational factors and not > just the technical factors. Today, too many organizations allow their > culture to be shaped by whatever tool is available. I'll refrain from > giving examples of the disasters that follow. For any free software > organization and any other type of organization too, it needs to be > organization first, tool second. > > Maybe I will recommend a platform... > The move to having our own Matrix server is being driven by Fedora subcommunities already wanting to move primacy from IRC to Matrix. Many of our adjunct upstreams have done so (Mozilla, KDE, etc.) or are in the process of doing so (GNOME, openSUSE, etc.). The intent isn't to drop IRC as a gateway to these communities, and indeed the Freenode IRC channels would remain bridged to the Fedora Matrix server. To be blunt, we're struggling to get new folks to come talk to us on IRC. Our largest user community is on Discord today, which eclipses *everything* else by a wide margin. Next up is Telegram, which we have been using somewhat for years through influence by the Russian Fedora community who brought it to us in the first place. Neither of these platforms are FOSS, and we want to provide a rich real-time communications platform that is FOSS and open in many of the same ways that IRC is. Matrix is open, federated, and gaining share in the marketplace, making it a solid replacement for IRC. And unlike alternatives, maintaining links to historical IRC channels with Matrix rooms is easy and straightforward. We want to be approachable, and we want to be appealing. Right now, our usage of IRC hurts us. The Matrix makeover can help smooth out those issues without leaving behind the folks who prefer the IRC interface. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 17:53 +, Richard W.M. Jones wrote: > On Thu, Nov 19, 2020 at 06:34:28PM +0100, Radka Gustavsson wrote: > > Let me start off: > > > > What's the reason why hosting your own server for a fairly uncommon > > chat protocol is better than continuing to use IRC? > > > > > > I too love dinosaurs... but I also work on 4 different computers and two > > mobile > > devices every day. Having to literally switch hardware to participate in IRC > > meetings is pain in the ass for some of our contributors (myself included.) > > I also use many different computers and have no such problem, because > I use screen + znc. (Same in fact for email: screen + mutt) That solves the problem for...you. Everyone else who needs it solved has to run their own bouncer. So we have several thousand people either maintaining an IRC bouncer, or living with the inconvenience. If we use a central server, only one server needs maintaining, and the problem is solved for everyone. The benefit seems pretty clear. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19/11/2020 18:55, Richard W.M. Jones wrote: > On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: >> On 19.11.2020 18:34, Radka Gustavsson wrote: >>> Rich, IRC is not being dropped, it is being bridged to modern, >>> "IRC-native" (for lack of better word in my vocabulary) platform. >>> Contributors who prefer to stay on IRC are welcome to do so and >>> won't really notice any difference. >> >> No, please. IRC bridges need to be closed to force users to switch >> to Matrix. > > "force"? You may have said the quiet bit aloud ... yes, it got my attention too I'm not going to give a firm recommendation for or against any platform but I'd like to make two suggestions: a) why not slow the process down and allow more ideas to come forward? There is no urgent need to change things in a month or whatever. b) it is really important to look at the organizational factors and not just the technical factors. Today, too many organizations allow their culture to be shaped by whatever tool is available. I'll refrain from giving examples of the disasters that follow. For any free software organization and any other type of organization too, it needs to be organization first, tool second. Maybe I will recommend a platform... 73 Daniel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote: > On 19.11.2020 18:34, Radka Gustavsson wrote: > >Rich, IRC is not being dropped, it is being bridged to modern, > >"IRC-native" (for lack of better word in my vocabulary) platform. > >Contributors who prefer to stay on IRC are welcome to do so and > >won't really notice any difference. > > No, please. IRC bridges need to be closed to force users to switch > to Matrix. "force"? You may have said the quiet bit aloud ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 06:46:31PM +0100, Vitaly Zaitsev via devel wrote: > On 19.11.2020 18:08, Richard W.M. Jones wrote: > >What's the reason why hosting your own server for a fairly uncommon > >chat protocol is better than continuing to use IRC? > > IRC is a legacy protocol with no support for modern features like > message editing, history, etc. I'm not sure that message editing is a feature, but for history, screen + znc + irssi works well (there are alternates for all those components, I'm mentioning what I use). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 18:49, Sérgio Basto wrote: How I install matrix/element in my desktop ? I suggest you install nheko instead of Element: sudo dnf install nheko P.S. Fedora 33 is required for nheko due to an ancient version of Boost in Fedora 32. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 06:34:28PM +0100, Radka Gustavsson wrote: > Let me start off: > > What's the reason why hosting your own server for a fairly uncommon > chat protocol is better than continuing to use IRC? > > > I too love dinosaurs... but I also work on 4 different computers and two > mobile > devices every day. Having to literally switch hardware to participate in IRC > meetings is pain in the ass for some of our contributors (myself included.) I also use many different computers and have no such problem, because I use screen + znc. (Same in fact for email: screen + mutt) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 18:34, Radka Gustavsson wrote: Rich, IRC is not being dropped, it is being bridged to modern, "IRC-native" (for lack of better word in my vocabulary) platform. Contributors who prefer to stay on IRC are welcome to do so and won't really notice any difference. No, please. IRC bridges need to be closed to force users to switch to Matrix. There are many native Matrix clients in the repository: nheko, spectral, quaternion. Each user can choose what he likes. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, 2020-11-19 at 18:34 +0100, Radka Gustavsson wrote: > On Thu, Nov 19, 2020 at 6:11 PM Richard W.M. Jones > wrote: > > On Wed, Nov 18, 2020 at 12:22:26PM -0500, Matthew Miller wrote: > > > > > [I posted to the Fedora Council list, but reposting here for > > wider > > > > > distribution.] > > > > > > > > > > As mentioned, we're looking at moving the Fedora Council's main > > chat to > > > > > Matrix. And as part of that, we're considering a hosted Element > > server -- > > > > > which obviously could go quite beyond just #fedora-council. Neal > > suggested a > > > > > video meeting to talk with interested people about this, and so I > > set up > > > > > this when-is-good > > > > > > > > > >http://whenisgood.net/k5brwbd > > > > > > > > > > Anyone interested in a preliminary chat about all of this, please > > sign up > > > > > with your FAS id and availability. Nothing is sent in stone or > > decided > > > > > already, although I must say I'm pretty excited about Element's > > open source > > > > > software-as-a-service offering based on what I've heard from them > > so far. > > > > > > > > There's quite a lot wrong here - a video meeting(!) to discuss > > > > dropping a commonly used and well established channel of > > > > communication. Well, I guess at least you didn't decide to use the > > > > proprietary awfulness of Slack. > > Rich, IRC is not being dropped, it is being bridged to modern, "IRC- > native" (for lack of better word in my vocabulary) platform. > Contributors who prefer to stay on IRC are welcome to do so and won't > really notice any difference. > > > > > Couldn't you just talk about this on email? > > https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628 > > > > > Let me start off: > > > > > > > > What's the reason why hosting your own server for a fairly uncommon > > > > chat protocol is better than continuing to use IRC? > > I too love dinosaurs... but I also work on 4 different computers and > two mobile devices every day. Having to literally switch hardware to > participate in IRC meetings is pain in the ass for some of our > contributors (myself included.) How I install matrix/element in my desktop ? Thank you > > > > Rich. > > > > > > > > ___devel mailing list > > -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python dependency missing during RPM build
On Thu, Nov 19, 2020 at 06:26:04PM +0100, Miro Hrončok wrote: > There is no generator that parses Python imports (and never has been), sorry. OK, fair enough. It's not a big deal because I could add the Requires line by hand. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On 19.11.2020 18:08, Richard W.M. Jones wrote: What's the reason why hosting your own server for a fairly uncommon chat protocol is better than continuing to use IRC? IRC is a legacy protocol with no support for modern features like message editing, history, etc. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Thu, Nov 19, 2020 at 6:11 PM Richard W.M. Jones wrote: > On Wed, Nov 18, 2020 at 12:22:26PM -0500, Matthew Miller wrote: > > [I posted to the Fedora Council list, but reposting here for wider > > distribution.] > > > > As mentioned, we're looking at moving the Fedora Council's main chat to > > Matrix. And as part of that, we're considering a hosted Element server -- > > which obviously could go quite beyond just #fedora-council. Neal > suggested a > > video meeting to talk with interested people about this, and so I set up > > this when-is-good > > > >http://whenisgood.net/k5brwbd > > > > Anyone interested in a preliminary chat about all of this, please sign up > > with your FAS id and availability. Nothing is sent in stone or decided > > already, although I must say I'm pretty excited about Element's open > source > > software-as-a-service offering based on what I've heard from them so far. > > There's quite a lot wrong here - a video meeting(!) to discuss > dropping a commonly used and well established channel of > communication. Well, I guess at least you didn't decide to use the > proprietary awfulness of Slack. > Rich, IRC is not being dropped, it is being bridged to modern, "IRC-native" (for lack of better word in my vocabulary) platform. Contributors who prefer to stay on IRC are welcome to do so and won't really notice any difference. > > Couldn't you just talk about this on email? > https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628 > > Let me start off: > > What's the reason why hosting your own server for a fairly uncommon > chat protocol is better than continuing to use IRC? > I too love dinosaurs... but I also work on 4 different computers and two mobile devices every day. Having to literally switch hardware to participate in IRC meetings is pain in the ass for some of our contributors (myself included.) > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-builder quickly builds VMs from scratch > http://libguestfs.org/virt-builder.1.html > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Python dependency missing during RPM build
On 11/19/20 6:02 PM, Richard W.M. Jones wrote: It's not a big deal because I added the Python Requires: line by hand, but I want to make sure I understand why it happens and whether there's an easy fix. https://koji.fedoraproject.org/koji/taskinfo?taskID=55889416 https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_475 This subpackage contains a Python file: $ rpm -qlp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/lib64/nbdkit/plugins/nbdkit-S3-plugin <--- this one /usr/share/doc/nbdkit-S3-plugin /usr/share/doc/nbdkit-S3-plugin/README /usr/share/licenses/nbdkit-S3-plugin /usr/share/licenses/nbdkit-S3-plugin/LICENSE /usr/share/man/man1/nbdkit-S3-plugin.1.gz The automatically generated dependencies don't pick up the need for python3-boto3. $ grep ^import nbdkit-S3-plugin import nbdkit import boto3 $ rpm -qRp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/sbin/nbdkit nbdkit-python-plugin >= 1.22 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 (As I said above, I added it explicitly, which is why the RPM built in Koji above _does_ contain the boto3 dependency). Now admittedly the Python file doesn't end in .py and doesn't have a python shebang at the top. But: $ file nbdkit-S3-plugin nbdkit-S3-plugin: Python script, ASCII text executable which seems as if it matches the %__python_magic regexp in /usr/lib/rpm/fileattrs/python.attr. So perhaps it _ought_ to work and something is wrong on the machine I'm using to reproduce this? Alternatively is there another way to tell the dependency generator to take a special look at this file? There are three dependency generators for Python and neither of them does what you ask here. /usr/lib/rpm/fileattrs/python.attr This file makes sure that files installed into /usr/lib(64)/pythonX.Y require python(abi) = X.Y. /usr/lib/rpm/fileattrs/pythondist.attr This file makes sure that Python packages (upstream term) require other Python packages. E.g. that requests requires idna, chardet and urllib3. This is read from upstream meatadata (.dist-info or egg-info directories/files). It has nothing to do with imports. See for example data in /usr/lib/python3.9/site-packages/requests-2.24.0-py3.9.egg-info/requires.txt. /usr/lib/rpm/fileattrs/pythonname.attr This file makes sure that packages called python3-requests provide python-requests and python3.9-requests. There is no generator that parses Python imports (and never has been), sorry. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Python dependency missing during RPM build
On 11/19/20 6:02 PM, Richard W.M. Jones wrote: It's not a big deal because I added the Python Requires: line by hand, but I want to make sure I understand why it happens and whether there's an easy fix. https://koji.fedoraproject.org/koji/taskinfo?taskID=55889416 https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_475 This subpackage contains a Python file: $ rpm -qlp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/lib64/nbdkit/plugins/nbdkit-S3-plugin <--- this one /usr/share/doc/nbdkit-S3-plugin /usr/share/doc/nbdkit-S3-plugin/README /usr/share/licenses/nbdkit-S3-plugin /usr/share/licenses/nbdkit-S3-plugin/LICENSE /usr/share/man/man1/nbdkit-S3-plugin.1.gz The automatically generated dependencies don't pick up the need for python3-boto3. $ grep ^import nbdkit-S3-plugin import nbdkit import boto3 $ rpm -qRp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/sbin/nbdkit nbdkit-python-plugin >= 1.22 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 (As I said above, I added it explicitly, which is why the RPM built in Koji above _does_ contain the boto3 dependency). Now admittedly the Python file doesn't end in .py and doesn't have a python shebang at the top. But: $ file nbdkit-S3-plugin nbdkit-S3-plugin: Python script, ASCII text executable which seems as if it matches the %__python_magic regexp in /usr/lib/rpm/fileattrs/python.attr. So perhaps it _ought_ to work and something is wrong on the machine I'm using to reproduce this? Alternatively is there another way to tell the dependency generator to take a special look at this file? There are three dependency generators for Python and neither of them does what you ask here. /usr/lib/rpm/fileattrs/python.attr This file makes sure that files installed into /usr/lib(64)/pythonX.Y require python(abi) = X.Y. /usr/lib/rpm/fileattrs/pythondist.attr This file makes sure that Python packages (upstream term) require other Python packages. E.g. that requests requires idna, chardet and urllib3. This is read from upstream meatadata (.dist-info or egg-info directories/files). It has nothing to do with imports. See for example data in /usr/lib/python3.9/site-packages/requests-2.24.0-py3.9.egg-info/requires.txt. /usr/lib/rpm/fileattrs/pythonname.attr This file makes sure that packages called python3-requests provide python-requests and python3.9-requests. There is no generator that parses Python imports (and never has been), sorry. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
corsepiu pushed to perl-Type-Tie (f33). "Upstream update."
Notification time stamped 2020-11-19 17:20:56 UTC
From 4ea4bcea465d04afef003b277f9f2930c901bd38 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 19 2020 13:31:29 +
Subject: Upstream update.
---
diff --git a/.gitignore b/.gitignore
index 6bf852e..56b4bd7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.014.tar.gz
+/Type-Tie-0.015.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 5954b4f..aba883a 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
Name: perl-Type-Tie
-Version:0.014
-Release:8%{?dist}
+Version:0.015
+Release:1%{?dist}
Summary:Tie a variable to a type constraint
# cf. README
License:GPL+ or Artistic
@@ -18,6 +18,8 @@ BuildRequires: perl(Carp)
BuildRequires: perl(Exporter::Tiny) >= 0.026
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Hash::FieldHash)
+# Optional alternative to perl(Hash::FieldHash)
+# BuildRequires: perl(Hash::Util::FieldHash::Compat)
BuildRequires: perl(Moo)
BuildRequires: perl(Tie::Array)
BuildRequires: perl(Tie::Hash)
@@ -76,6 +78,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
%{_mandir}/man3/*
%changelog
+* Thu Nov 19 2020 Ralf Corsépius - 0.015-1
+- Upstream update.
+
* Tue Jul 28 2020 Fedora Release Engineering -
0.014-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
diff --git a/sources b/sources
index fbf7082..a9ca85e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.014.tar.gz) =
c7952792ea4cd365db28d940945adb295134f2780495700620afd9b0fff0fb619a8589ccd3b5ed0af6b56ad6d9c4589b2ab61605890e897cc1ff7010c5e3bad1
+SHA512 (Type-Tie-0.015.tar.gz) =
3772796ef7a1f5ce0dd9153f061aebdf5097f019b701c217bc296752d304e603b9e97785c02a55a91c18c68d3794a7e2b3f8515c92e7a2022fca628bac99d342
https://src.fedoraproject.org/rpms/perl-Type-Tie/c/4ea4bcea465d04afef003b277f9f2930c901bd38?branch=f33
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1899531] perl-Convert-Binary-C-0.83 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899531 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Convert-Binary-C-0.82 |perl-Convert-Binary-C-0.83 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.83 Current version/release in rawhide: 0.81-1.fc34 URL: http://search.cpan.org/dist/Convert-Binary-C/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7067/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: video meeting to discuss Matrix/Element and IRC
On Wed, Nov 18, 2020 at 12:22:26PM -0500, Matthew Miller wrote: > [I posted to the Fedora Council list, but reposting here for wider > distribution.] > > As mentioned, we're looking at moving the Fedora Council's main chat to > Matrix. And as part of that, we're considering a hosted Element server -- > which obviously could go quite beyond just #fedora-council. Neal suggested a > video meeting to talk with interested people about this, and so I set up > this when-is-good > >http://whenisgood.net/k5brwbd > > Anyone interested in a preliminary chat about all of this, please sign up > with your FAS id and availability. Nothing is sent in stone or decided > already, although I must say I'm pretty excited about Element's open source > software-as-a-service offering based on what I've heard from them so far. There's quite a lot wrong here - a video meeting(!) to discuss dropping a commonly used and well established channel of communication. Well, I guess at least you didn't decide to use the proprietary awfulness of Slack. Couldn't you just talk about this on email? Let me start off: What's the reason why hosting your own server for a fairly uncommon chat protocol is better than continuing to use IRC? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Python dependency missing during RPM build
It's not a big deal because I added the Python Requires: line by hand, but I want to make sure I understand why it happens and whether there's an easy fix. https://koji.fedoraproject.org/koji/taskinfo?taskID=55889416 https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_475 This subpackage contains a Python file: $ rpm -qlp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/lib64/nbdkit/plugins/nbdkit-S3-plugin <--- this one /usr/share/doc/nbdkit-S3-plugin /usr/share/doc/nbdkit-S3-plugin/README /usr/share/licenses/nbdkit-S3-plugin /usr/share/licenses/nbdkit-S3-plugin/LICENSE /usr/share/man/man1/nbdkit-S3-plugin.1.gz The automatically generated dependencies don't pick up the need for python3-boto3. $ grep ^import nbdkit-S3-plugin import nbdkit import boto3 $ rpm -qRp ./nbdkit-S3-plugin-1.23.9-1.fc34.x86_64.rpm /usr/sbin/nbdkit nbdkit-python-plugin >= 1.22 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 (As I said above, I added it explicitly, which is why the RPM built in Koji above _does_ contain the boto3 dependency). Now admittedly the Python file doesn't end in .py and doesn't have a python shebang at the top. But: $ file nbdkit-S3-plugin nbdkit-S3-plugin: Python script, ASCII text executable which seems as if it matches the %__python_magic regexp in /usr/lib/rpm/fileattrs/python.attr. So perhaps it _ought_ to work and something is wrong on the machine I'm using to reproduce this? Alternatively is there another way to tell the dependency generator to take a special look at this file? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-33-20201119.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64), 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-33-20201117.0): ID: 725719 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/725719 ID: 725735 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/725735 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.18 to 0.37 Previous test data: https://openqa.fedoraproject.org/tests/723990#downloads Current test data: https://openqa.fedoraproject.org/tests/725736#downloads -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
corsepiu pushed to perl-Type-Tie (master). "Upstream update."
Notification time stamped 2020-11-19 15:05:56 UTC
From 4ea4bcea465d04afef003b277f9f2930c901bd38 Mon Sep 17 00:00:00 2001
From: Ralf Corsépius
Date: Nov 19 2020 13:31:29 +
Subject: Upstream update.
---
diff --git a/.gitignore b/.gitignore
index 6bf852e..56b4bd7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.014.tar.gz
+/Type-Tie-0.015.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 5954b4f..aba883a 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
Name: perl-Type-Tie
-Version:0.014
-Release:8%{?dist}
+Version:0.015
+Release:1%{?dist}
Summary:Tie a variable to a type constraint
# cf. README
License:GPL+ or Artistic
@@ -18,6 +18,8 @@ BuildRequires: perl(Carp)
BuildRequires: perl(Exporter::Tiny) >= 0.026
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Hash::FieldHash)
+# Optional alternative to perl(Hash::FieldHash)
+# BuildRequires: perl(Hash::Util::FieldHash::Compat)
BuildRequires: perl(Moo)
BuildRequires: perl(Tie::Array)
BuildRequires: perl(Tie::Hash)
@@ -76,6 +78,9 @@ sed -i -e '/^inc\/.*$/d' MANIFEST
%{_mandir}/man3/*
%changelog
+* Thu Nov 19 2020 Ralf Corsépius - 0.015-1
+- Upstream update.
+
* Tue Jul 28 2020 Fedora Release Engineering -
0.014-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
diff --git a/sources b/sources
index fbf7082..a9ca85e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.014.tar.gz) =
c7952792ea4cd365db28d940945adb295134f2780495700620afd9b0fff0fb619a8589ccd3b5ed0af6b56ad6d9c4589b2ab61605890e897cc1ff7010c5e3bad1
+SHA512 (Type-Tie-0.015.tar.gz) =
3772796ef7a1f5ce0dd9153f061aebdf5097f019b701c217bc296752d304e603b9e97785c02a55a91c18c68d3794a7e2b3f8515c92e7a2022fca628bac99d342
https://src.fedoraproject.org/rpms/perl-Type-Tie/c/4ea4bcea465d04afef003b277f9f2930c901bd38?branch=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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1899556] New: perl-PDL-2.025 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899556 Bug ID: 1899556 Summary: perl-PDL-2.025 is available Product: Fedora Version: rawhide Status: NEW Component: perl-PDL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, jakub.jedel...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com, tjczep...@gmail.com Target Milestone: --- Classification: Fedora Latest upstream release: 2.025 Current version/release in rawhide: 2.24.0-1.fc34 URL: http://search.cpan.org/dist/PDL/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3205/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: systemd-resolved in a container
On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote: On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy wrote: On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote: Hi, I realized my fedora-based containers have an /etc/resolv.conf which claims it is managed by resolved, and nsswitch.conf has "resolve" in hosts. However, doing something like # systemd-resolve --status results to: sd_bus_open_system: No such file or directory Trying to start dbus claims that systemd is not the init: # systemctl start dbus System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Is there a way to use systemd resolved in a container? I figured this out yesterday -- at least in Rawhide, dbus-daemon is now replaced by dbus-broker which is not active by default. So you need systemctl enable --now dbus-broker Without it even hostnamectl doesn't work, not just systemd-resolve. Is that on the "default" fedora container, or do you use something else? On fedora33 I get the same message about dbus and systemd not being pid 1. fedora-init container runs with systemd, fedora container does NOT. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1899531] New: perl-Convert-Binary-C-0.82 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899531 Bug ID: 1899531 Summary: perl-Convert-Binary-C-0.82 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Convert-Binary-C Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: al...@users.sourceforge.net, jples...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 0.82 Current version/release in rawhide: 0.81-1.fc34 URL: http://search.cpan.org/dist/Convert-Binary-C/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/7067/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-IoT-34-20201119.0 compose check report
No missing expected images. Failed openQA tests: 2/16 (x86_64), 5/15 (aarch64) Old failures (same test failed in Fedora-IoT-34-20201118.0): ID: 725582 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/725582 ID: 725594 Test: x86_64 IoT-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/725594 ID: 725598 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/725598 ID: 725600 Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/725600 ID: 725602 Test: aarch64 IoT-dvd_ostree-iso podman@uefi URL: https://openqa.fedoraproject.org/tests/725602 ID: 725603 Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi URL: https://openqa.fedoraproject.org/tests/725603 ID: 725606 Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi URL: https://openqa.fedoraproject.org/tests/725606 Passed openQA tests: 14/16 (x86_64), 10/15 (aarch64) New passes (same test not passed in Fedora-IoT-34-20201118.0): ID: 725590 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/725590 ID: 725597 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/725597 ID: 725601 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi URL: https://openqa.fedoraproject.org/tests/725601 ID: 725608 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/725608 ID: 725612 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/725612 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: 1 services(s) added since previous compose: systemd-homed-activate.service Previous test data: https://openqa.fedoraproject.org/tests/724950#downloads Current test data: https://openqa.fedoraproject.org/tests/725599#downloads -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20201119.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 17/177 (x86_64), 21/115 (aarch64) New failures (same test not failed in Fedora-Rawhide-20201118.n.0): ID: 725197 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/725197 ID: 725198 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/725198 ID: 725205 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/725205 ID: 725206 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/725206 ID: 725209 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/725209 ID: 725210 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/725210 ID: 725211 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/725211 ID: 725246 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/725246 ID: 725292 Test: aarch64 Server-dvd-iso install_repository_nfs_variation@uefi URL: https://openqa.fedoraproject.org/tests/725292 ID: 725293 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/725293 ID: 725294 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/725294 ID: 725301 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/725301 ID: 725302 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/725302 ID: 725310 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/725310 ID: 725348 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/725348 ID: 725355 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/725355 ID: 725387 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/725387 ID: 725415 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/725415 ID: 725455 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/725455 Old failures (same test failed in Fedora-Rawhide-20201118.n.0): ID: 725247 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/725247 ID: 725249 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/725249 ID: 725297 Test: aarch64 Server-dvd-iso server_cockpit_default@uefi URL: https://openqa.fedoraproject.org/tests/725297 ID: 725312 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/725312 ID: 725315 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/725315 ID: 725323 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/725323 ID: 725325 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/725325 ID: 725369 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/725369 ID: 725424 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/725424 ID: 725427 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/725427 ID: 725436 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/725436 ID: 725449 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/725449 ID: 725452 Test: aarch64 universal install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/725452 ID: 725453 Test: aarch64 universal install_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/725453 ID: 725464 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/725464 ID: 725465 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/725465 ID: 725468 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/725468 ID: 725470 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/725470 ID: 725472 Test:
Fedora rawhide compose report: 20201119.n.0 changes
OLD: Fedora-Rawhide-20201118.n.0 NEW: Fedora-Rawhide-20201119.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 22 Dropped packages:0 Upgraded packages: 72 Downgraded packages: 0 Size of added packages: 224.82 MiB Size of dropped packages:0 B Size of upgraded packages: 2.38 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -10.76 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201119.n.0-sda.raw.xz = DROPPED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201118.n.0.iso = ADDED PACKAGES = Package: directory-maven-plugin-0.3.1-2.fc34 Summary: Establish locations for files in multi-module builds RPMs:directory-maven-plugin directory-maven-plugin-javadoc Size:290.29 KiB Package: gitjacker-0.0.2-2.fc34 Summary: Leak git repositories from misconfigured websites RPMs:gitjacker golang-github-liamg-gitjacker-devel Size:11.79 MiB Package: golang-github-hbakhtiyor-strsim-0-0.1.20201118git4d2bbb2.fc34 Summary: String similarity based on Dice's coefficient RPMs:golang-github-hbakhtiyor-strsim-devel Size:13.10 KiB Package: jmc-7.1.1-8.fc34 Summary: JDK Mission Control is a profiling and diagnostics tool RPMs:jmc Size:208.71 MiB Package: jmc-core-7.1.1-5.fc34 Summary: Core API for JDK Mission Control RPMs:jmc-core jmc-core-javadoc Size:2.47 MiB Package: koji-osbuild-2-0.fc34 Summary: Koji integration for osbuild composer RPMs:koji-osbuild koji-osbuild-builder koji-osbuild-cli koji-osbuild-hub Size:49.79 KiB Package: owasp-java-encoder-1.2.2-4.fc34 Summary: Collection of high-performance low-overhead contextual encoders RPMs:owasp-java-encoder owasp-java-encoder-javadoc Size:346.90 KiB Package: pamix-1.6-1.fc34 Summary: PulseAudio terminal mixer RPMs:pamix Size:290.14 KiB Package: perl-Net-Ping-2.74-1.fc34 Summary: Check a remote host for reachability RPMs:perl-Net-Ping Size:49.71 KiB Package: python-adext-0.3-1.fc34 Summary: Python module to extend AlarmDecoder module RPMs:python3-adext Size:13.03 KiB Package: python-alarmdecoder-1.13.9-1.fc34 Summary: Python interface for the AlarmDecoder (AD2) devices RPMs:python3-alarmdecoder Size:83.63 KiB Package: python-managesieve-0.6-4.fc34 Summary: Accessing a Sieve-Server for managing Sieve scripts RPMs:python3-managesieve Size:28.56 KiB Package: python-pycomfoair-0.0.4-1.fc34 Summary: Interface for Zehnder ComfoAir 350 ventilation units RPMs:python3-pycomfoair Size:23.14 KiB Package: python-pyemby-1.6-1.fc34 Summary: Python module to interact with a Emby media server RPMs:python3-pyemby Size:24.29 KiB Package: python-pygrocy-0.23.0-1.fc34 Summary: Python API client for grocy RPMs:python3-pygrocy Size:32.58 KiB Package: python-pymochad-0.2.0-1.fc34 Summary: Python library for interacting with moch RPMs:python-pymochad-doc python3-pymochad Size:182.92 KiB Package: python-pynuvo-0.2-1.fc34 Summary: Python API for talking to Nuvo multi zone amplifier RPMs:python3-pynuvo Size:16.07 KiB Package: python-pytile-5.0.1-1.fc34 Summary: Python API for Tile Bluetooth trackers RPMs:python3-pytile Size:19.18 KiB Package: python-rangeparser-0.1.3-2.fc34 Summary: Parses a list of ranges or numbers RPMs:python3-rangeparser Size:13.74 KiB Package: python-waqiasync-1.0.0-1.fc34 Summary: Python API for aqicn.org RPMs:python3-waqiasync Size:10.71 KiB Package: rubygem-ronn-ng-0.9.1-1.fc34 Summary: Builds man pages from Markdown RPMs:rubygem-ronn-ng rubygem-ronn-ng-doc Size:342.31 KiB Package: wayland-logout-1.0.1-0.1.20201117gitc9f0bae.fc34 Summary: Simple program that sends SIGINT to a wayland compositor RPMs:wayland-logout Size:66.07 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: CGAL-5.2-0.1.beta1.fc34 Old package: CGAL-5.1.1-1.fc34 Summary: Computational Geometry Algorithms Library RPMs: CGAL-demos-source CGAL-devel CGAL-qt5-devel Size: 119.86 MiB Size change: 2.03 MiB Changelog: * Wed Nov 18 2020 Laurent Rineau - 5.2-0.1.beta1 - New upstream release Package: awscli-1.18.180-1.fc34 Old package: awscli-1.18.179-1.fc34 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.92 MiB Size change: 71 B Changelog: * Wed Nov 18 2020 Gwyn Ciesla - 1.18.180-1 - 1.18.180 Package: bind-dyndb-ldap-11.5-1.fc34 Old package: bind-dyndb-ldap-11.3-5.fc34 Summary: LDAP back-end plug-in for BIND RPMs: bind-dyndb-ldap Size: 544.96 KiB Size change: -8.52 KiB Changelog: * Wed Nov 18 2020 Alexander Bokovoy - 11.5-1 - Upstream release 11.5 - Use OpenSSL pkcs11 engine in BIND instead of native PKCS11 Package
Re: Retiring some packages from openstack-sig
On Thu, Nov 19, 2020 at 12:41 PM Dan Čermák wrote: > Hi Alfredo, > > Alfredo Moralejo Alonso writes: > > > Hi, > > > > openstack-sig is reviewing the list of packages maintained in Fedora and > > we've found that following packages can be retired from Fedora as they > are > > not longer used or required by any other package or OpenStack: > > I am not interested in these packages, but please orphan them instead of > retiring them directly, as that will include them in Miro's weekly > notification emails. > > Ack, I'll do, thanks! > Cheers, > > Dan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Retiring some packages from openstack-sig
Hi Alfredo, Alfredo Moralejo Alonso writes: > Hi, > > openstack-sig is reviewing the list of packages maintained in Fedora and > we've found that following packages can be retired from Fedora as they are > not longer used or required by any other package or OpenStack: I am not interested in these packages, but please orphan them instead of retiring them directly, as that will include them in Miro's weekly notification emails. Cheers, Dan signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1898583] perl-Algorithm-CheckDigits-1.3.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1898583 Xavier Bachelot changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-11-19 11:16:08 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Retiring some packages from openstack-sig
Hi, openstack-sig is reviewing the list of packages maintained in Fedora and we've found that following packages can be retired from Fedora as they are not longer used or required by any other package or OpenStack: python-cliff-tablib python-tablib python-congressclient python-openstack-doc-tools python-pifpaf python-pika-pool python-positional python-pykafka python-ryu python-setuptools_git python-vulture python-epi If anyone is aware of something needing any of them or is willing to take maintenance of it, please let me know. Best regards, Alfredo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-31-20201119.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64), 7/7 (aarch64) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: new Radeon RX 6800/6900/Big Navi on Fedora
On 19/11/2020 10:04, Felix Schwarz wrote: > Hi Daniel, > > Am 18.11.20 um 18:41 schrieb Daniel Pocock: >> Firmware binary code that isn't yet present in linux-firmware.git >> - is there any way to extract that binary from another platform? > > you probably noticed this yourself, but just in case: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DWHTL7DIYPZ5GPAW2RQC4EKOXH3B4BL2/ > Thanks for helping bring these threads together The local supplier has told me they have no idea when the stock will actually arrive but if and when I do get one I will definitely share my observations about making it work. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20201119.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20201118.0): ID: 725151 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/725151 ID: 725158 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/725158 Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Java reviews (with swaps)
On Mon, Nov 16, 2020 at 8:30 PM Jerry James wrote: > I would like to ask for some input from those of you with Java > packaging experience. The jsonp package has been orphaned, but the > antlr4-project package (which I maintain) still needs it. Since jsonp > has transitioned to the eclipse-ee4j project, I thought it best to let > the current jsonp package die, and replace it with a jakarta-jsonp > package. > > The parent POM for jakarta-jsonp, org.eclipse.ee4j:project:pom:, has > not been packaged for Fedora. Other packages with that parent have > simply added %pom_remove_parent to their spec files. With > jakarta-jsonp, though, I'm running into some difficulties doing so. > The parent POM has default version numbers for various plugins. Those > version numbers are not duplicated in the jakarta-jsonp POM. This > leads to maven telling me that the missing version numbers invoke > deprecated functionality and that the project will stop building with > some future version of maven. I could: This warning is relevant for upstream projects, but you can safely ignore it when building RPM packages with XMvn - it always uses packaged versions of Maven plugins, ignoring versions configured in POM. > (1) add %pom_remove_parent and ignore maven until the project actually breaks; > (2) add %pom_remove_parent and then do some XPath gymnastics to add > the missing version numbers into the jakarta-jsonp POM; or > (3) package the parent POM and stop worrying. > > I've chosen to do (3). Tell me if you think this is wrong. IMHO (1), (3), (2), in that order of preference. (3) is the most elegant solution, but requires maintaining one more package than (1), which also works. (2) doesn't make much sense - it would only silence the warning at the cost of cluttering the spec file, making it harder to maintain. > As for jakarta-jsonp itself, the latest version is 2.0.0, but it fails > to build because it needs jakarta-ws-rs 3.x and jakarta-annotations > 2.x. We have versions 2.1.6 and 1.3.5, respectively, in Rawhide right > now. Therefore, I have gone with version 1.1.6 of jakarta-jsonp for > now. That should be fine. Packaging the latest available version is not always the best choice. > Here's the next bit of input I need: why does "%pom_remove_plugin -r > org.apache.maven.plugins:maven-javadoc-plugin" only remove the plugin > from the top-level POM, in spite of the -r flag? I have to manually > remove it from the subdirectory POMs. It's hard to say without looking at the POM structure. I can check if you give me a reference to the code (upstream, SRPM etc). -- Mikolaj Izdebski ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: new Radeon RX 6800/6900/Big Navi on Fedora
Hi Daniel, Am 18.11.20 um 18:41 schrieb Daniel Pocock: Firmware binary code that isn't yet present in linux-firmware.git - is there any way to extract that binary from another platform? you probably noticed this yourself, but just in case: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DWHTL7DIYPZ5GPAW2RQC4EKOXH3B4BL2/ Felix ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd-resolved in a container
On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy wrote: > > On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote: > >Hi, > > I realized my fedora-based containers have an /etc/resolv.conf which > >claims it is managed by resolved, and nsswitch.conf has "resolve" in > >hosts. However, doing something like > ># systemd-resolve --status > > > >results to: > >sd_bus_open_system: No such file or directory > > > >Trying to start dbus claims that systemd is not the init: > ># systemctl start dbus > >System has not been booted with systemd as init system (PID 1). Can't > >operate. > >Failed to connect to bus: Host is down > > > > > >Is there a way to use systemd resolved in a container? > > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now > replaced by dbus-broker which is not active by default. > > So you need > > systemctl enable --now dbus-broker > > Without it even hostnamectl doesn't work, not just systemd-resolve. Is that on the "default" fedora container, or do you use something else? On fedora33 I get the same message about dbus and systemd not being pid 1. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
