Orphaning nohang
Hi, Userspace OOM killer nohang [1] is orphaned [2] now. This oom killer supports PSI and GUI notifications. The package may be of interest to users who are not suitable for systemd-oomd for some reason. For example, systemd-oomd may kill the whole session (this applies to XFCE, Mate, LXDE etc. i.e DE in which all applications are launched in one control group like session-1.session) [4]. Anyone wishing to take over the maintenance is welcome to do so [1] https://github.com/hakavlad/nohang [2] https://src.fedoraproject.org/rpms/nohang/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1933494 Regards, Alexey Avramov ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
Once upon a time, Nico Kadel-Garcia said: > Local root passwords can be set to expire. SSH keys are not nearly so > easy to enforce expiration for, so there are some use cases. I've > used it for VM's at home, because I may not have my private SSH keys > on the other VM. I think you can set expiration on SSH certificates. For program-used keys (like for Ansible), I tend to add "from=" to limit the use of a key to specific connections. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Thu, Apr 29, 2021 at 4:11 PM Martin Kolman wrote: > > Hi! > At the moment the Anaconda installer used by Fedora contains an option > called "Allow SSH root login with password" on the root password > configuration screen. > > This is how it looks like at the moment, on latest Fedora Rawhide > installer image: > > https://m4rtink.fedorapeople.org/screenshots/fedora/rawhide_f35/root_password_screen.png > If you are aware of some critical Fedora/Fedora spin usecase that > depends on users regularly ticking this option, please let us know! Local root passwords can be set to expire. SSH keys are not nearly so easy to enforce expiration for, so there are some use cases. I've used it for VM's at home, because I may not have my private SSH keys on the other VM. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 5/1/21 8:02 PM, Chris Adams wrote: Once upon a time, PGNet Dev said: my $0.02 leave the root via password option, but simply DISABLE it by default, rather than REMOVING it. That's what is going to happen - the openssh-server package will follow upstream default (PermitRootLogin without-password), and Anaconda will drop the option of changing the sshd config. Sry, I meant _leave_ the *option* in Anaconda, but just ensure it's toggled OFF by default ( if that's not what it already does). But that's 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
Once upon a time, PGNet Dev said: > my $0.02 > > leave the root via password option, but simply DISABLE it by default, rather > than REMOVING it. That's what is going to happen - the openssh-server package will follow upstream default (PermitRootLogin without-password), and Anaconda will drop the option of changing the sshd config. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 5/1/21 7:23 PM, patra...@gmail.com wrote: On 4/30/21 10:23 AM, Richard W.M. Jones wrote: +1 in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS. Ubuntu Server installer handles this in a very nice way by allowing to import SSH keys from a GitHub account given a username, i.e. via an URL like this: https://github.com/patrakov.keys . Maybe it's a good idea to implement the same feature in Anaconda? this is all getting too complicated. my $0.02 leave the root via password option, but simply DISABLE it by default, rather than REMOVING it. let admins worry about SSH keys. the 'rest' can be handled, as mentioned, with kickstart/ansible ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trying to reach "trytond" maintainer - Dan Horák
Hello, As a part of the initiative of replacing "python-mysql" package by "python-mysqlclient" package, we tried to fill PRs to the packages to switch to the new implementation. [1] We filed PR against the "trytond" package [2], however even though the maintainer was active in Fedora since then, he hasn't responded to the PR. Hope this message will reach him and the request will be taken care of. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101 [2] https://src.fedoraproject.org/rpms/trytond/pull-request/3 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
Once upon a time, patra...@gmail.com said: > Ubuntu Server installer handles this in a very nice way by allowing to import > SSH keys from a GitHub account given a username, i.e. via an URL like this: > https://github.com/patrakov.keys . Maybe it's a good idea to implement the > same feature in Anaconda? I think dropping this is okay - Anaconda is an installer, and should do only the bare minimum required to set up the OS. The minimum for authentication is either setting a root password and/or creating an admin user and setting that password (or setting network authentication). There are multiple programs that offer network access, and only SSH gets configured (minimally) by Anaconda, which really doesn't make a lot of sense. This is the upstream default, so I expect it's the case on lots of other distributions/OSes. Especially now that sshd is configured to use /etc/sshd_config.d/*.conf, it's as easy as dropping a one-line file in there (no longer have to edit the existing sshd_config). If you're doing lots of installs (especially VMs), you probably should be using kickstart mode installs, which support setting an SSH key as well as post-install scripting (where you could tweak this). -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Trying to reach "python-sqlobject" maintainer - Peter Lemenkov
Hello, As a part of the initiative of replacing "python-mysql" package by "python-mysqlclient" package, we tried to fill PRs to the packages to switch to the new implementation. [1] We filed PR against the "python-sqlobject" package [2], however even though the maintainer committed since then to the package, he hasn't responded to the PR. Hope this message will reach him and the request will be taken care of. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1929101 [2] https://src.fedoraproject.org/rpms/python-sqlobject/pull-request/1 -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
> On 4/30/21 10:23 AM, Richard W.M. Jones wrote: > > +1 > > in addition to, e.g., an _initial_ setup on a remote/headless box at a VPS. Ubuntu Server installer handles this in a very nice way by allowing to import SSH keys from a GitHub account given a username, i.e. via an URL like this: https://github.com/patrakov.keys . Maybe it's a good idea to implement the same feature in Anaconda? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
On Sat, May 1, 2021 at 7:42 PM Samuel Sieb wrote: > On 2021-05-01 2:42 a.m., Germano Massullo wrote: > > Il 30/04/21 18:33, Kevin Fenzi ha scritto: > >> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: > >>> After running > >>> dnf system-upgrade download --releasever=34 > >>> and downloading all files, I got the following warning > >>> warning: > >>> > /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: > >>> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY > > Wasn't there a prompt after that to import the key? > There was a prompt asking me to import a GPG key after I saw that - which if I recall my F32-F33 upgrade experience is normal for new releases because you would have never had the GPG key imported before, so it wants to check before it imports the new one. -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
pá 30. 4. 2021 v 13:29 odesílatel Otto Urpelainen napsal: > Germano Massullo kirjoitti 30.4.2021 klo 13.23: > > KeepassXC comaintainer here. > > > > There are many Fedora GNOME Wayland users experiencing quirks in using > > KeepassXC. Textboxes not showing text that is being written, other > > quirks with GNOME, etc. > > > > Upstream developers said many times that this only happen with Fedora > users. > > > > Myself I do use KDE Spin and I do not experience these issues (tested on > > Wayland too) > > > > I don't paste bugs titles since they are misleading > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1925130 > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1954742 > > > > https://github.com/keepassxreboot/keepassxc/issues/5608 > > > > plus others that I cannot find again at the moment > > > > I would like to ask if you have any idea about why this happens on GNOME > > only (and not on other distros too) > > > > Octave is suffering from similar problems. I have reported this: > > https://bugzilla.redhat.com/show_bug.cgi?id=1954181 > > and also saw another issue where menus opened in strange places on the > screen, or even partially off-screen. I did not report that yet, because > I do know how to reproduce reliably. > > The best assumption I could produce was simply that Qt5 and Wayland do > not play well together. Maybe Gnome also needs to be involved. Is there > a distribution that has that combination, but does not have these problems? > > As far as I know, Qt 5 reached end of life when Qt 6 came out. To me it > seems unlikely that remaining Qt 5 Wayland problems will ever get fixed. > Is there some downside to forcing XWayland through QT_QPA_PLATFORM=xcb > for Qt 5 applications with problems on Wayland? > That's not true. Fixes are still happening in 5.15 and there is even a public repository for Qt 5.15 in KDE's Gitlab instance. Also, given that Qt6 is not really different from Qt5 that much (at least in QtWayland), then all fixes in Qt6 are easily backportable to Qt5, which is something I do quite often. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
so 1. 5. 2021 v 17:51 odesílatel Jonas Ådahl napsal: > On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote: > > On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: > > > > > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > > > I agree, do we know anyone who understands Mutter that could work with > > > someone who understands Qt to figure this out? I've got a couple of > > > folks in mind who could help on the KDE side (who I've CC'd to this > > > email). > > > > Added Jonas Adahl (all things output), Carlos Garnacho (all things > > input) and Oliver Fourdan (compat problems expert) to the Cc:- one of > > them should be able to help. > > > > Since the context is trimmed, the thread here is: > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ > > I have yet to find any recent bugs in mutter that causes issues that > happens only with Qt; last time I and Jan debugged some issues with > Dolphin and Kate resizing wierdly, there were still some Qt issues with > incorrectly committed surface state. I think he is still looking into > those. > Yes, still working on those, but I don't think this issue is relevant here. And I would really like to know whether the "unable to type... " issue is KeepassXC only thing, because so far I haven't seen it and didn't get any other report. > Some issues likely doesn't cause issues on kwin because kwin takes over > window decoration from Qt applications, meaning Qts inability to commit > correct state is papered over by the incorrect intermediate state not > existing, but for example oddly placed menus (that I have seen and can > reproduce) behave exactly the same in e.g. weston as in mutter. > That's a Qt issue, a known one, and it's probably about time to finally fix it for good so once I fix the resizing issue, I think I can look into this one as well. Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Hi, pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo < germano.massu...@gmail.com> napsal: > KeepassXC comaintainer here. > > There are many Fedora GNOME Wayland users experiencing quirks in using > KeepassXC. Textboxes not showing text that is being written, other quirks > with GNOME, etc. > > Upstream developers said many times that this only happen with Fedora > users. > > Myself I do use KDE Spin and I do not experience these issues (tested on > Wayland too) > > I don't paste bugs titles since they are misleading > > https://bugzilla.redhat.com/show_bug.cgi?id=1925130 > I haven't seen any other application having this issue and I've been using lots of Qt/KDE apps under GNOME. It might be an issue in KeepassXC as they have some custom theme. > https://bugzilla.redhat.com/show_bug.cgi?id=1941731 (CentOS 8) > CentOS doesn't really use Qt Wayland by default. > https://bugzilla.redhat.com/show_bug.cgi?id=1954742 > Again, can be a KeepassXC issue as any other application I've been using doesn't have such problem. > https://github.com/keepassxreboot/keepassxc/issues/5608 > This is the same issue as the first one (about missing focus). There is only one issue I'm aware of and that's misplaced popups/menus. There is a bug in Qt opened for it https://bugreports.qt.io/browse/QTBUG-68636 and it's the only one blocking upstream decision to switch to Wayland by default. I know that there might be some other issues in certain apps, but those issues would be really specific to those apps given their implementation and would need to be probably fixed case by case. I think it's something I can look into for Fedora 35, but reverting this change to use xcb by default will result in not having properly/natively scaled apps in GNOME. Btw. even KDE flatpak runtime uses Wayland by default on GNOME. Regards, Jan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
On 2021-05-01 2:42 a.m., Germano Massullo wrote: Il 30/04/21 18:33, Kevin Fenzi ha scritto: On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: After running dnf system-upgrade download --releasever=34 and downloading all files, I got the following warning warning: /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY Wasn't there a prompt after that to import the key? Why this package does not have a key? That is in fact the f34 key and the package is signed with it. You don't have that key in your rpmdb (which is why it says NOKEY). Mmh why it says that only for that package? It only gives you that message for the first package with each key. There was a fedora-release for f33/f32 that had this key in it, if you updated to that it should have been able to correctly import it. I always upgrade from N to N+1 Fedora versions Hard to say whats going on without more info. What version is there? what version of fedora-release do you have installed? From dnf system upgrade logs I see a fedora-release-common-33-4.noarch That's the latest one. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1955741] perl-experimental-0.024 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1955741 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-experimental-0.023 is |perl-experimental-0.024 is |available |available --- Comment #3 from Upstream Release Monitoring --- Latest upstream release: 0.024 Current version/release in rawhide: 0.022-4.fc34 URL: http://search.cpan.org/dist/experimental/ 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/2857/ -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
On Sat, May 01, 2021 at 11:42:52AM +0200, Germano Massullo wrote: > Il 30/04/21 18:33, Kevin Fenzi ha scritto: > > On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: > >> After running > >> dnf system-upgrade download --releasever=34 > >> and downloading all files, I got the following warning > >> warning: > >> /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: > >> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY > >> > >> Why this package does not have a key? > > That is in fact the f34 key and the package is signed with it. > > > > You don't have that key in your rpmdb (which is why it says NOKEY). > > Mmh why it says that only for that package? Don't know. ;( Do you still have that file? Or it's gone with the upgrade? > > There was a fedora-release for f33/f32 that had this key in it, if you > > updated to that it should have been able to correctly import it. > > I always upgrade from N to N+1 Fedora versions > > > Hard to say whats going on without more info. > > What version is there? what version of fedora-release do you have > > installed? > From dnf system upgrade logs I see a > fedora-release-common-33-4.noarch Yeah, that should definitely have the key in it and if the rest worked I don't see why that one package would be singled out... Perhaps file a bug on dnf system-upgrade plugin and see if they can figure it out? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote: > On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: > > > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > I agree, do we know anyone who understands Mutter that could work with > > someone who understands Qt to figure this out? I've got a couple of > > folks in mind who could help on the KDE side (who I've CC'd to this > > email). > > Added Jonas Adahl (all things output), Carlos Garnacho (all things > input) and Oliver Fourdan (compat problems expert) to the Cc:- one of > them should be able to help. > > Since the context is trimmed, the thread here is: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ I have yet to find any recent bugs in mutter that causes issues that happens only with Qt; last time I and Jan debugged some issues with Dolphin and Kate resizing wierdly, there were still some Qt issues with incorrectly committed surface state. I think he is still looking into those. Some issues likely doesn't cause issues on kwin because kwin takes over window decoration from Qt applications, meaning Qts inability to commit correct state is papered over by the incorrect intermediate state not existing, but for example oddly placed menus (that I have seen and can reproduce) behave exactly the same in e.g. weston as in mutter. Jonas > > Owen > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1955938] New: perl-Term-ReadLine-Gnu-1.41 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1955938 Bug ID: 1955938 Summary: perl-Term-ReadLine-Gnu-1.41 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Term-ReadLine-Gnu Keywords: FutureFeature, Triaged Assignee: emman...@seyman.fr Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: c...@alum.wpi.edu, emman...@seyman.fr, lkund...@v3.sk, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.41 Current version/release in rawhide: 1.40-1.fc35 URL: http://search.cpan.org/dist/Term-ReadLine-Gnu/ 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/7548/ -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1953837] perl-PDL-2.044 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1953837 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-PDL-2.043 is available |perl-PDL-2.044 is available --- Comment #4 from Upstream Release Monitoring --- Latest upstream release: 2.044 Current version/release in rawhide: 2.39.0-1.fc35 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > On Sat, May 1, 2021, 7:51 AM Neal Gompa wrote: > >> > >> In general, I'd like to see if we can figure out *why* Mutter isn't > >> doing the right thing for Qt applications and why they're breaking > >> this way, because the fact that they're fine in Plasma Wayland and not > >> on GNOME Wayland points to Mutter needing work here. > > > > > > That doesn't make any more logical sense than "the fact that GTK > > applications work fine with Mutter points to Qt needing work here." Without > > a diagnosis, it's impossible to say. > > > > GTK applications work fine on KWin (modulo some missing Wayland > protocols not being implemented in GTK3), so I'm reasonably confident > that the problem is in Mutter. How is that relevant? Qt is making some assumptions about the compositor behavior which don't hold with mutter - and we don't know whether it's Qt relying on things that accidentally work with Kwin, or Mutter not properly implementing parts of the Wayland protocol that GTK doesn't use. [roughly speaking ... not comprehensively listing all possibilities] > > If we can put someone who understands Qt together with someone who > > understands Mutter it should be possible to figure out what is going on. If > > the fix is hard, then reverting the Qt change until F35 might be needed, > > but patching a reversion to X into Qt apps one-by-one doesn't seem like > > something we'd want to do: it would leave unpatched apps affected, we might > > forget to remove some of the patches, and it's going to make things > > altogether more confusing. > I agree, do we know anyone who understands Mutter that could work with > someone who understands Qt to figure this out? I've got a couple of > folks in mind who could help on the KDE side (who I've CC'd to this > email). Added Jonas Adahl (all things output), Carlos Garnacho (all things input) and Oliver Fourdan (compat problems expert) to the Cc:- one of them should be able to help. Since the context is trimmed, the thread here is: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
Yes, why not adding an option to anaconda to create a personal ssh key? Same like amazon cloud does. Eg. when you create a el8 server in AWS, AWS gives you an option to create a ssh key before you finish the setup of this machine. With that key you can later login to the root account of your AWS server machine. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > On Sat, May 1, 2021, 7:51 AM Neal Gompa wrote: >> >> >> Note it only looks fine as long as you're not using fractional >> scaling. Once framebuffer/fractional scaling is enabled in Mutter, it >> looks absolutely terrible, because X11 applications are not scaled >> properly. There are also other glitches if Qt5 applications run as X11 >> apps, and I'm not sure if some prominent Qt5 applications expose the >> correct functionality in X11 mode (e.g. OBS Studio uses PipeWire for >> screencasting when it is in Wayland mode). >> >> In general, I'd like to see if we can figure out *why* Mutter isn't >> doing the right thing for Qt applications and why they're breaking >> this way, because the fact that they're fine in Plasma Wayland and not >> on GNOME Wayland points to Mutter needing work here. > > > That doesn't make any more logical sense than "the fact that GTK applications > work fine with Mutter points to Qt needing work here." Without a diagnosis, > it's impossible to say. > GTK applications work fine on KWin (modulo some missing Wayland protocols not being implemented in GTK3), so I'm reasonably confident that the problem is in Mutter. > If we can put someone who understands Qt together with someone who > understands Mutter it should be possible to figure out what is going on. If > the fix is hard, then reverting the Qt change until F35 might be needed, but > patching a reversion to X into Qt apps one-by-one doesn't seem like something > we'd want to do: it would leave unpatched apps affected, we might forget to > remove some of the patches, and it's going to make things altogether more > confusing. > I agree, do we know anyone who understands Mutter that could work with someone who understands Qt to figure this out? I've got a couple of folks in mind who could help on the KDE side (who I've CC'd to this email). -- 真実はいつも一つ！/ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20210501.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 16/189 (x86_64), 12/127 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210430.n.0): ID: 874811 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/874811 ID: 874822 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/874822 ID: 874859 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/874859 ID: 874954 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/874954 ID: 874956 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/874956 ID: 874993 Test: x86_64 universal install_lvmthin URL: https://openqa.fedoraproject.org/tests/874993 ID: 875029 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/875029 ID: 875058 Test: aarch64 universal install_package_set_minimal@uefi URL: https://openqa.fedoraproject.org/tests/875058 Old failures (same test failed in Fedora-Rawhide-20210430.n.0): ID: 874771 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/874771 ID: 874799 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/874799 ID: 874800 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/874800 ID: 874830 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/874830 ID: 874838 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/874838 ID: 874849 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/874849 ID: 874891 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/874891 ID: 874914 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/874914 ID: 874915 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/874915 ID: 874953 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/874953 ID: 874982 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/874982 ID: 875004 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/875004 ID: 875017 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/875017 ID: 875036 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/875036 ID: 875039 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/875039 ID: 875048 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/875048 ID: 875063 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/875063 ID: 875069 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/875069 ID: 875082 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/875082 ID: 875084 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/875084 Soft failed openQA tests: 1/189 (x86_64), 3/127 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210430.n.0): ID: 874881 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/874881 ID: 874882 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/874882 ID: 874936 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/874936 ID: 874963 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/874963 Passed openQA tests: 172/189 (x86_64), 112/127 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210430.n.0): ID: 874846 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/874846 ID: 874906 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/874906 ID: 874907 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi URL: https://openqa.fedoraproject.org/tests/874907 ID: 875074
Re: GNOME only: KeepassXC quirks
On Sat, May 1, 2021, 7:51 AM Neal Gompa wrote: > > Note it only looks fine as long as you're not using fractional > scaling. Once framebuffer/fractional scaling is enabled in Mutter, it > looks absolutely terrible, because X11 applications are not scaled > properly. There are also other glitches if Qt5 applications run as X11 > apps, and I'm not sure if some prominent Qt5 applications expose the > correct functionality in X11 mode (e.g. OBS Studio uses PipeWire for > screencasting when it is in Wayland mode). > > In general, I'd like to see if we can figure out *why* Mutter isn't > doing the right thing for Qt applications and why they're breaking > this way, because the fact that they're fine in Plasma Wayland and not > on GNOME Wayland points to Mutter needing work here. > That doesn't make any more logical sense than "the fact that GTK applications work fine with Mutter points to Qt needing work here." Without a diagnosis, it's impossible to say. If we can put someone who understands Qt together with someone who understands Mutter it should be possible to figure out what is going on. If the fix is hard, then reverting the Qt change until F35 might be needed, but patching a reversion to X into Qt apps one-by-one doesn't seem like something we'd want to do: it would leave unpatched apps affected, we might forget to remove some of the patches, and it's going to make things altogether more confusing. Owen ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-35-20210501.0 compose check report
No missing expected images. Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20210429.0): ID: 875090 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/875090 ID: 875091 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/875091 ID: 875092 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/875092 ID: 875106 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/875106 ID: 875107 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/875107 Skipped non-gating openQA tests: 26 of 31 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210501.n.0 changes
OLD: Fedora-Rawhide-20210430.n.0 NEW: Fedora-Rawhide-20210501.n.0 = SUMMARY = Added images:0 Dropped images: 8 Added packages: 8 Dropped packages:0 Upgraded packages: 96 Downgraded packages: 0 Size of added packages: 156.06 MiB Size of dropped packages:0 B Size of upgraded packages: 13.45 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 166.08 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20210430.n.0.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20210430.n.0.iso Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210430.n.0.iso Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210430.n.0.ppc64le.qcow2 Image: Cinnamon live x86_64 Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210430.n.0.iso Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20210430.n.0.armhfp.raw.xz Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210430.n.0.ppc64le.raw.xz Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20210430.n.0.aarch64.raw.xz = ADDED PACKAGES = Package: c-ares-1.17.1-2.module_f35+11948+8d2b9da3 Summary: A library that performs asynchronous DNS operations RPMs:c-ares c-ares-devel Size:998.52 KiB Package: libqrtr-glib-1.0.0-1.fc35 Summary: Support library to use and manage the QRTR (Qualcomm IPC Router) bus. RPMs:libqrtr-glib libqrtr-glib-devel Size:416.04 KiB Package: libuv-1:1.41.0-1.module_f35+11948+8d2b9da3 Summary: Platform layer for node.js RPMs:libuv libuv-devel libuv-static Size:1.44 MiB Package: nghttp2-1.43.0-2.module_f35+11948+8d2b9da3 Summary: Experimental HTTP/2 client, server and proxy RPMs:libnghttp2 libnghttp2-devel nghttp2 Size:3.39 MiB Package: nodejs-1:16.0.0-1.module_f35+11948+8d2b9da3 Summary: JavaScript runtime RPMs:nodejs nodejs-devel nodejs-docs nodejs-full-i18n nodejs-libs npm v8-devel Size:126.91 MiB Package: nodejs-packaging-2021.01-3.module_f35+11948+8d2b9da3 Summary: RPM Macros and Utilities for Node.js Packaging RPMs:nodejs-packaging nodejs-packaging-bundler Size:29.92 KiB Package: ocaml-atd-2.2.1-2.fc35 Summary: Static Types for Json APIs RPMs:ocaml-atd ocaml-atd-devel ocaml-atdgen ocaml-atdgen-codec-runtime ocaml-atdgen-codec-runtime-devel ocaml-atdgen-devel ocaml-atdgen-runtime ocaml-atdgen-runtime-devel ocaml-atdj Size:22.89 MiB Package: python-op1svg-0.1.0-2.20210430git50a3b01.fc35 Summary: Normalize SVG files so that the OP-1 understands them RPMs:op1svg Size:20.80 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: ModemManager-1.16.4-1.fc35 Old package: ModemManager-1.14.10-2.fc34 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 11.60 MiB Size change: 353.58 KiB Changelog: * Fri Apr 30 2021 Peter Robinson - 1.16.4-1 - Update to 1.16.4 Package: abrt-2.14.5-3.fc35 Old package: abrt-2.14.5-2.fc34 Summary: Automatic bug detection and reporting tool RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon python3-abrt-container-addon python3-abrt-doc Size: 6.87 MiB Size change: -26.53 KiB Changelog: * Tue Mar 02 2021 Zbigniew J??drzejewski-Szmek - 2.14.5-3 - Rebuilt for updated systemd-rpm-macros See https://pagure.io/fesco/issue/2583. Package: annobin-9.70-1.fc35 Old package: annobin-9.69-1.fc35 Summary: Annotate and examine compiled binary files RPMs: annobin-annocheck annobin-docs annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm Size: 1.23 MiB Size change: -7.73 KiB Changelog: * Fri Apr 30 2021 Nick Clifton - 9.70-1 - gcc-plugin: Replace ICE messsages with verbose messages. Package: anthy-unicode-1.0.0.20201109-3.fc35 Old package: anthy-unicode-1.0.0.20201109-2.fc34 Summary: Japanese character set input library for Unicode RPMs: anthy-unicode anthy-unicode-devel emacs-anthy-unicode xemacs-anthy-unicode Size: 34.30 MiB Size change: -1.69 KiB Changelog: * Sat May 01 2021 Takao Fujiwara 1.0.0.20201109-3 - Enable CI Package: awscli-1.19.62-1.fc35 Old package: awscli-1.19.61-1.fc35 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.03 MiB Size change: -133 B Changelog
Re: GNOME only: KeepassXC quirks
On Fri, Apr 30, 2021 at 10:23 AM Hans de Goede wrote: > > Hi, > > On 4/30/21 3:33 PM, Vitaly Zaitsev via devel wrote: > > On 30.04.2021 12:23, Germano Massullo wrote: > >> There are many Fedora GNOME Wayland users experiencing quirks in using > >> KeepassXC. Textboxes not showing text that is being written, other quirks > >> with GNOME, etc. > > > > There are a lot of issues with Mutter and Qt5[1]. That's why the Qt > > upstream forces XCB backend for the Gnome 3, but Fedora removes it in > > downstream[2], as approved by the system-wide proposal[3]. > > > > Please try the following: > > QT_QPA_PLATFORM=xcb /usr/bin/keepassxc > > Ah interesting, I use calibre regularly under a GNOME3 wayland sessions and > I have noticed some weird issues there too, like the "completion" pop-ups > for things like the Author and Series fields which allow you to select an > Author / Series already used for other books showing up in completely > the wrong places, as well as right-click context(sub)menus also showing up > in completely the wrong places too. > > I also use the audacious media-player for music in its x11amp compatible > skinned mode and that is has serious issues when used without > QT_QPA_PLATFORM=xcb under GNOME3. I thought this was just a special case > because of the skinned UI, but I now see that it is part of a wider pattern. > > I was going to write the following here: > > """ > I can understand if the KDE SIG wants to use Wayland by default when running > a KDE Wayland session, but under GNOME3 this indeed seems like a bad idea for > now. > > Maybe instead the QT_QPA_PLATFORM environment option can be set in the > KDE wayland session, so that Wayland is used there while leaving GNOME3 > alone ? > """ > > Which seems like a reasonable compromise to me, but then I looked at the > patch from [2] and it seems that that is the upstream default and the > Fedora packages are actually overriding this sensible upstream default. > > > I think this downstream patch should be dropped from Fedora. > > I tend to agree, it seems this downstream patch breaks at least 3 apps: > > 1. KeepassXC > 2. calibre > 3. audacious > > And I have a feeling it breaks all Qt apps to at least some extend, now the > changes process page [3] does list a couple of reasons why this is necessary, > but I just checked and calibre looks fine with the mutter provided window > decorations for X11 windows instead of using CSD, so this does not seem like > a strong argument. > > I can understand that it is desirable to make this change, but it seems that > QT5 just is not completely ready for this yet. For me the patch[2] breaks > 2/2 Qt apps which I regularly used, so it seems that it would be best to drop > this downstream modification for now. > Note it only looks fine as long as you're not using fractional scaling. Once framebuffer/fractional scaling is enabled in Mutter, it looks absolutely terrible, because X11 applications are not scaled properly. There are also other glitches if Qt5 applications run as X11 apps, and I'm not sure if some prominent Qt5 applications expose the correct functionality in X11 mode (e.g. OBS Studio uses PipeWire for screencasting when it is in Wayland mode). In general, I'd like to see if we can figure out *why* Mutter isn't doing the right thing for Qt applications and why they're breaking this way, because the fact that they're fine in Plasma Wayland and not on GNOME Wayland points to Mutter needing work here. -- 真実はいつも一つ！/ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test-Announce] Fedora 35 Rawhide 20210501.n.0 nightly compose nominated for testing
Works :) On Sat, May 1, 2021 at 12:52 PM wrote: > Announcing the creation of a new nightly release validation test event > for Fedora 35 Rawhide 20210501.n.0. Please help run some tests for this > nightly compose if you have time. For more information on nightly > release validation testing, see: > https://fedoraproject.org/wiki/QA:Release_validation_test_plan > > Notable package version changes: > pungi - 20210428.n.1: pungi-4.2.8-1.fc35.src, 20210501.n.0: > pungi-4.2.9-1.fc35.src > > Test coverage information for the current release can be seen at: > https://openqa.fedoraproject.org/testcase_stats/35 > > You can see all results, find testing instructions and image download > locations, and enter results on the Summary page: > > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Summary > > The individual test result pages are: > > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Installation > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Base > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Server > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Cloud > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Desktop > > https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Security_Lab > > Thank you for testing! > -- > Mail generated by relvalconsumer: > https://pagure.io/fedora-qa/relvalconsumer > ___ > test-announce mailing list -- test-annou...@lists.fedoraproject.org > To unsubscribe send an email to > test-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
On 01.05.2021 12:56, Germano Massullo wrote: wouldn't be better to remove the reference to gnome? So that it the patch will work for all Wayland sessions, like KDE Plasma, etc? Since the root problem is on Qt not the specific desktop environment KDE works fine with the qt-wayland backend. Only Gnome/mutter has major issues with this. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 01/05/21 12:56, Germano Massullo ha scritto: > Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: >> On 30.04.2021 16:09, Germano Massullo wrote: >>> Could you please suggest me how I could implement a patch? >> https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch >> > I have a question: > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch#_26 > wouldn't be better to remove the reference to gnome? So that it the > patch will work for all Wayland sessions, like KDE Plasma, etc? Since > the root problem is on Qt not the specific desktop environment My fault, I did not notice that the downstream qt patch was gnome oriented https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/qtbase-use-wayland-on-gnome.patch ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: > On 30.04.2021 16:09, Germano Massullo wrote: >> Could you please suggest me how I could implement a patch? > > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch > I have a question: https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch#_26 wouldn't be better to remove the reference to gnome? So that it the patch will work for all Wayland sessions, like KDE Plasma, etc? Since the root problem is on Qt not the specific desktop environment ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Fedora 35 Rawhide 20210501.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 35 Rawhide 20210501.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: pungi - 20210428.n.1: pungi-4.2.8-1.fc35.src, 20210501.n.0: pungi-4.2.9-1.fc35.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/35 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_35_Rawhide_20210501.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
On 01.05.2021 11:44, Germano Massullo wrote:
Let's wait also for Jan Grulich. He should be back next days/weeks
Yes, but my simple workaround works fine. We need to add a new method:
```c++
#ifdef Q_OS_LINUX
void wayland_hacks()
{
// Workaround to https://github.com/ksnip/ksnip/issues/416
QByteArray currentDesktop = qgetenv("XDG_CURRENT_DESKTOP").toLower();
QByteArray sessionDesktop = qgetenv("XDG_SESSION_DESKTOP").toLower();
QByteArray sessionType = qgetenv("XDG_SESSION_TYPE").toLower();
if (sessionType.contains("wayland") &&
(currentDesktop.contains("gnome") || sessionDesktop.contains("gnome")))
{
qputenv("QT_QPA_PLATFORM", "xcb");
}
}
#endif
```
Then call it in main(), just before the QApplication initialization:
```c++
int main(int argc, char** argv)
{
#ifdef Q_OS_LINUX
wayland_hacks();
#endif
QApplication app(argc, argv);
}
```
--
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: New RPM submission
* Joan Moreau via devel [01/05/2021 09:21] : > > 1 - Those who have a great piece of software, simply willing to make it > available to the large public. In such case, there should be only quality > barrier of the package + rules of duration (i.e. added packages are not kept > in Fedora if not maintained for instance once a year) I suspect having packages being removed after a year is going to make for a poor user experience. If an upstream author wants his software in Fedora, I would recommend one of two solutions: a) use a COPR repository and publish instructions on enabling the repo b) find an existing maintainer to do the heavy lifting and sign on as a co-maintainer to deal with upstream-related issues. The primary maintainer will then only have to deal with Fedora-related issues. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GNOME only: KeepassXC quirks
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto: > On 30.04.2021 16:09, Germano Massullo wrote: >> Could you please suggest me how I could implement a patch? > > https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch > > >> Would you do it in the .desktop file? > > Patching desktop file is not a good idea. It can break lots of things > and custom themes. > Let's wait also for Jan Grulich. He should be back next days/weeks ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nokey warning during F33->F34 upgrade (fstrm package)
Il 30/04/21 18:33, Kevin Fenzi ha scritto: > On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: >> After running >> dnf system-upgrade download --releasever=34 >> and downloading all files, I got the following warning >> warning: >> /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: >> Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY >> >> Why this package does not have a key? > That is in fact the f34 key and the package is signed with it. > > You don't have that key in your rpmdb (which is why it says NOKEY). Mmh why it says that only for that package? > There was a fedora-release for f33/f32 that had this key in it, if you > updated to that it should have been able to correctly import it. I always upgrade from N to N+1 Fedora versions > Hard to say whats going on without more info. > What version is there? what version of fedora-release do you have > installed? From dnf system upgrade logs I see a fedora-release-common-33-4.noarch Thank you ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-32-20210501.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-20210429.0): ID: 874761 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/874761 ID: 874768 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/874768 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On 4/30/21 3:21 PM, Richard W.M. Jones wrote: On Thu, Apr 29, 2021 at 10:09:12PM +0200, Martin Kolman wrote: Now fast forward to today, it's 2021, any use cases that needed password based root login via SSH had 2 more years to migrate while the amount of password guessing attacks certainly didn't get any lower. Not everything is exposed to the internet. Please leave the option, disabled by default and with a suitable warning if you like. +1 Removing this option is not helpful in a LAN. Ralf ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
On 01.05.2021 10:55, Joan Moreau wrote: COPR is like AUR on ARch or PPA on Debian/Ubuntu Like PPA. Everyone can create its own repository. These are not in the default installation of the user, and not easily acceisble for a non-tech user, so these not really appropriate. sudo dnf copr enable $login/$repo_name sudo dnf install $package_name What I would suggest, is to join the two repositories (being "by default" for the average end user) , except packages coming form the "less involved" people would expire quickly if not maintained "Less involved" people, after a short period of time, can drop their packages in an unmaintained state, and then someone will have to start an non-responsive maintainer procedure. That's why candidates must prove that they are familiar with the Fedora packaging guidelines and will maintain their package for a long time. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
COPR is like AUR on ARch or PPA on Debian/Ubuntu These are not in the default installation of the user, and not easily acceisble for a non-tech user, so these not really appropriate. What I would suggest, is to join the two repositories (being "by default" for the average end user) , except packages coming form the "less involved" people would expire quickly if not maintained On 2021-05-01 09:47, Vitaly Zaitsev via devel wrote: On 01.05.2021 10:21, Joan Moreau via devel wrote: For instance, personally, I am not using Fedora at all (Arch fan ;) ) but just willing to make my piece of software available widely for those interested. I am happy to maintain the package in the long run, but will not get involve to much into Fedora project except my small piece of software contribution. You can use COPR for your software then. No join barrier at all.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
On 01.05.2021 10:42, Mattia Verga via devel wrote: There must be a section that clearly states that if the scope is "I made this piece of software and I'll fire through Fedora repositories, then goodbye", or "I use this software, I'll push into Fedora repositories and never touch it again until this version is fine for me" there are other means to achieve that. "I made this piece of software and I'll fire through Fedora repositories, then goodbye" should go to COPR. Fedora packages must be of high quality with responsive maintainers. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Yes, that distinction is clear to me, but as you said if English is not your first language it might be less clear or the process might seem scary. I feel there could at least be maintenance of the documents themselves, which never hurts. It's a part of Fedora too! We have the nice site for Packaging Guidelines themselves, but Joining the Package Collection Maintainers wiki page is a little dated in layout and whatnot. We could earmark that. I haven't thought of submitting my package at all until last week. I've maintained it on Copr for several months now, and I've spent a few hours with a Debian user who was having troubles with an build script I made for Debian & Ubuntu users (they had library conflicts because of Matlab). It's clear, but it's not plainly stated that package submission to, and more importantly inclusion in, the official package repository is a different thing from simple application distribution. Responding to users, addressing edge cases, and ensuring breakage don't occur is definitely the actual responsibility that comes with hurdling through the process and having a package included in the repo. For all other intents and purposes, Copr, the Outer Rim, is the place to be. It's fun there, a bit of a Kessel run. On Sat., May 1, 2021, 2:42 a.m. Mattia Verga via devel, < devel@lists.fedoraproject.org> wrote: > Il 01/05/21 10:21, Joan Moreau via devel ha scritto: > > > > For instance, personally, I am not using Fedora at all (Arch fan ;) ) > > but just willing to make my piece of software available widely for > > those interested. I am happy to maintain the package in the long run, > > but will not get involve to much into Fedora project except my small > > piece of software contribution. > > > > > That's absolutely fine, but in my opinion the wiki should clarify one > thing: a certain amount of involvement in Fedora should be taken into > account if one wants to become a packager. > > I don't think it's not entirely clear that by publishing a package in > Fedora repositories implies 1) maintain the package updated, 2) maintain > the specfile in line with future Packaging Guidelines changes and 3) get > in touch with the community to handle possible bugs filed by other users > which install your package. > > There must be a section that clearly states that if the scope is "I made > this piece of software and I'll fire through Fedora repositories, then > goodbye", or "I use this software, I'll push into Fedora repositories > and never touch it again until this version is fine for me" there are > other means to achieve that. > > That's the reason for having the "sponsorship barrier" at joining time, > that, I know very well, it's quite scaring if you're not English mother > tongue. Anyway, after a successful review of a package, one could get in > touch with some sponsors by filing a ticket in the appropriate page [1] > and some nice folk will help them to enter the packager group. > > Mattia > > [1] https://pagure.io/packager-sponsors/ > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
On 01.05.2021 10:21, Joan Moreau via devel wrote: For instance, personally, I am not using Fedora at all (Arch fan ;) ) but just willing to make my piece of software available widely for those interested. I am happy to maintain the package in the long run, but will not get involve to much into Fedora project except my small piece of software contribution. You can use COPR for your software then. No join barrier at all. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Il 01/05/21 10:21, Joan Moreau via devel ha scritto: > > For instance, personally, I am not using Fedora at all (Arch fan ;) ) > but just willing to make my piece of software available widely for > those interested. I am happy to maintain the package in the long run, > but will not get involve to much into Fedora project except my small > piece of software contribution. > > That's absolutely fine, but in my opinion the wiki should clarify one thing: a certain amount of involvement in Fedora should be taken into account if one wants to become a packager. I don't think it's not entirely clear that by publishing a package in Fedora repositories implies 1) maintain the package updated, 2) maintain the specfile in line with future Packaging Guidelines changes and 3) get in touch with the community to handle possible bugs filed by other users which install your package. There must be a section that clearly states that if the scope is "I made this piece of software and I'll fire through Fedora repositories, then goodbye", or "I use this software, I'll push into Fedora repositories and never touch it again until this version is fine for me" there are other means to achieve that. That's the reason for having the "sponsorship barrier" at joining time, that, I know very well, it's quite scaring if you're not English mother tongue. Anyway, after a successful review of a package, one could get in touch with some sponsors by filing a ticket in the appropriate page [1] and some nice folk will help them to enter the packager group. Mattia [1] https://pagure.io/packager-sponsors/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
My opinion as a simple enthusiast, is that things should be separated in two 1 - Those who have a great piece of software, simply willing to make it available to the large public. In such case, there should be only quality barrier of the package + rules of duration (i.e. added packages are not kept in Fedora if not maintained for instance once a year) 2 - Those who wants to be much more involved into Fedora project, and this is in deed another story For instance, personally, I am not using Fedora at all (Arch fan ;) ) but just willing to make my piece of software available widely for those interested. I am happy to maintain the package in the long run, but will not get involve to much into Fedora project except my small piece of software contribution. On 2021-05-01 07:03, Otto Urpelainen wrote: Bryce Carson kirjoitti 1.5.2021 klo 3.21: For what it's worth, I'm trying to join and have a package included and there are definitely some areas I would like to improve. Should we make a thread on their mailing list? On Fri., Apr. 30, 2021, 5:50 p.m. Bryce Carson, wrote: Perhaps we could improve the wiki page on Joining** to make it more clear what the process is like? I read through the guidelines and the Joining page a couple times, and only near the end does it state that Joining is more about, well, joining as a person than publishing a package. I believe it then recommendeds Copr around that point for simple publishing. Maybe we could ask Docs and some newer joiners to do a little review of the wiki for Joining and see if we can rewrite and modernize? I joined during 2021, and also I felt that the entry barrier was quite high. Long instructions involving complex toolset and buildsystem and socially scary things like writing introductory messages to mailing lists and publicly commenting on package reviews. I think a lot could be done to make Fedora packaging more approachable. A certain barrier will always be there, because you must have a) the expertise and b) the trust of the Fedora community to maintain your package and acquiring these requires some investment. Regarding joining as a person vs. adding a package, I think the page title "Join the package collection maintainers" already resolves that, as do the first two sentences: "So, you have decided to become a package maintainer in the Fedora Project? This guide will lead you through your first package submission." But I can understand how the page might seem confusing if you start from the "I just want to add this package to Fedora repositories" mindset. Do you think it would help if that page started with a an Overview section, that very briefly explains hwo the process goes and why the different steps are there? For me, the most difficult part was the suggestion that the aspiring packager should immediately comment on other package reviews to get sponsored. I see review as an expert task, so I did not feel secure to do that as the first task. Enough to that I used another method of getting sponsored [1 [1]]. It was not completely clear to me (even though the instructions actually say so) that I could have first get my package reviewed and approved, and only then start doing those preliminary reviews to get sponsored. I guess a simple edit on the "How to get sponsored into the packager group" page could clarify that. Otherwise, in case there are other newcomers who had the same apprehension of preliminary reviews, maybe alternative methods involving pull requests to existing packages etc. could be given more visibility? [1]: https://pagure.io/packager-sponsors/issue/455 Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure Links: -- [1] https://pagure.io/packager-sponsors/issue/455___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20210501.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-20210430.0): ID: 874747 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/874747 ID: 874754 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/874754 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
> Am 29.04.2021 um 22:09 schrieb Martin Kolman : > > Hi! > At the moment the Anaconda installer used by Fedora contains an option > called "Allow SSH root login with password" on the root password > configuration screen. > ... > Note that the checkbox is not ticked by default, the user needs to make > a conscious choice to allow this security problematic SSH login > behavior. > ... > good time to finally drop the "Allow SSH root login with password" from > the Anaconda GUI. I greatly appreciate Fedora's emphasis on establishing the most secure system possible by default. It was one of my reasons to choose Fedora, years ago. But what makes the Anaconda team think that the system administrator could activate the option for no good reason, just for fun, recklessness or the joy of 'adventure'? I don't mean to be unkind, but in my view you are about to patronize the system administrator in a kind of missionary overzealousness. But reading Fedora vision, Fedora is about Freedom, another good reason to decide for it. > If you are aware of some critical Fedora/Fedora spin usecase that > depends on users regularly ticking this option, please let us know! No system administrator will 'regularly' ticking that option! That is an unrealistic assumption. It is reserved for special exceptions (that's why it is off by default). Others have already described such cases. At the very least, I am in favor of leaving the option in the Server Edition as it is. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Bryce Carson kirjoitti 1.5.2021 klo 3.21: For what it's worth, I'm trying to join and have a package included and there are definitely some areas I would like to improve. Should we make a thread on their mailing list? On Fri., Apr. 30, 2021, 5:50 p.m. Bryce Carson, wrote: Perhaps we could improve the wiki page on Joining** to make it more clear what the process is like? I read through the guidelines and the Joining page a couple times, and only near the end does it state that Joining is more about, well, joining as a person than publishing a package. I believe it then recommendeds Copr around that point for simple publishing. Maybe we could ask Docs and some newer joiners to do a little review of the wiki for Joining and see if we can rewrite and modernize? I joined during 2021, and also I felt that the entry barrier was quite high. Long instructions involving complex toolset and buildsystem and socially scary things like writing introductory messages to mailing lists and publicly commenting on package reviews. I think a lot could be done to make Fedora packaging more approachable. A certain barrier will always be there, because you must have a) the expertise and b) the trust of the Fedora community to maintain your package and acquiring these requires some investment. Regarding joining as a person vs. adding a package, I think the page title "Join the package collection maintainers" already resolves that, as do the first two sentences: "So, you have decided to become a package maintainer in the Fedora Project? This guide will lead you through your first package submission." But I can understand how the page might seem confusing if you start from the "I just want to add this package to Fedora repositories" mindset. Do you think it would help if that page started with a an Overview section, that very briefly explains hwo the process goes and why the different steps are there? For me, the most difficult part was the suggestion that the aspiring packager should immediately comment on other package reviews to get sponsored. I see review as an expert task, so I did not feel secure to do that as the first task. Enough to that I used another method of getting sponsored [1]. It was not completely clear to me (even though the instructions actually say so) that I could have first get my package reviewed and approved, and only then start doing those preliminary reviews to get sponsored. I guess a simple edit on the "How to get sponsored into the packager group" page could clarify that. Otherwise, in case there are other newcomers who had the same apprehension of preliminary reviews, maybe alternative methods involving pull requests to existing packages etc. could be given more visibility? [1]: https://pagure.io/packager-sponsors/issue/455 Otto ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
