Re: Fedora 36 Mass Branching
On Wed, Feb 9, 2022 at 2:32 AM Kevin Fenzi wrote: > > And I suppose we should really look at disabling builds on mass branch > day (while it's happening) it never ends well. :) Should I open a FESCo / Releng / Infra ticket for this, so we can at least discuss implementing that? I'm a bit tired of troubleshooting branching-related package limbo states twice a year :( Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Action Required: Bugzilla - API Authentication changes
On Wed, Feb 9, 2022, 07:44 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > So, I've updated review-stats container to run on F34 with > python-bugzilla 3.2.0, but it still authenticate using > username+password. Is that enough to avoid authentication errors and > user ban or I need to change the authentication method? > >From what we've seen with Blockerbugs app ( https://pagure.io/fedora-qa/blockerbugs/issue/230 ; https://pagure.io/fedora-qa/blockerbugs/issue/231 ) , it seems you won't be able to use username+password at all and bugzilla api key will be the only api-friendly method of auth. You can give it a shot with testing bugzilla: https://bugzilla.stage.redhat.com/ The error text that Bugzilla throws back at us when trying to login with username/pass is: You have attempted to access the API either using an unsupported method or > using one or more unsupported parameters. You must use the 'Authorization' > header to authenticate to the API and you must remove all unsupported > parameters from the query. The unsupported parameters are: Bugzilla_login, > Bugzilla_password, Bugzilla_token, Bugzilla_api_key. See > https://bugzilla.stage.redhat.com/docs/en/html/api/core/v1/general.html#authentication > for details on using the 'Authorization' header. at > /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855. ___ 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
Suggestions for fedora
Not sure what selinux really is but I think it makes polices based on system mechanics so nekto or netko the vulnerability scanner can be reversed engineered to generate custom policies on the fly Speaking of policy, a politics on the project would be nice And try to use multi dimensional arrays to fill up ram I use mda with binary trees ___ 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-34-20220209.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (aarch64) New failures (same test not failed in Fedora-Cloud-34-20220208.0): ID: 1123437 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1123437 Soft failed openQA tests: 1/8 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20220208.0): ID: 1123424 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1123424 Passed openQA tests: 7/8 (x86_64), 7/8 (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: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
On Tue, 18 Jan 2022 at 14:30, Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
>
> = Wayland by Default for SDDM =
>
> == Summary ==
> Change the default display server mode for SDDM to use a Wayland-based
> greeter rather than an X11-based one.
>
> == Owner ==
> * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> [[User:Jgrulich|Jan Grulich]]
> * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> * Product: KDE Spin, Kinoite
> * Responsible WG: KDE SIG
>
>
> == Detailed Description ==
> With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
> SDDM to support using a Wayland based greeter] and
> [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
> broken fallback when platform drivers are unavailable]], it is now
> possible for the Fedora KDE variants (the regular spin and Kinoite) to
> move to Wayland for the login manager, which effectively completes the
> switch to Wayland for these variants.
>
>
> == Benefit to Fedora ==
> As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
> Change to switch Plasma to Wayland by default]], Fedora is a leader in
> advancing the adoption of the Wayland protocol as part of the overall
> strategy to improve the Linux graphical software stack. We have been
> successful in helping drive Wayland forward in the Plasma Desktop, and
> we intend to do the same for SDDM.
>
> == Scope ==
> * Proposal owners:
> ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> mutually exclusive sddm-wayland-generic and
> sddm-x11 greeter configuration packages.
> ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> *** Enable installation of the SDDM Wayland configuration snippet and
> ship as sddm-wayland-plasma that is mutually exclusive
> with the other sddm greeter configuration packages. This package will
> supplement {{package|sddm}} and plasma-workspace-wayland
> to be automatically installed together.
> ** Modify @kde-desktop comps group for Fedora Linux 36 to
> include sddm-wayland-plasma for the media.
>
>
> * Other developers: N/A (not needed for this Change)
>
> * Release engineering: [https://pagure.io/releng/issue/10536 #10536]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> On upgrade to Fedora Linux 36, SDDM will be transparently switched
> from the X11 greeter to the Wayland one leveraging kwin. In order to
> override this, the user can do one of the following:
> * Drop in a configuration file in /etc/sddm.conf.d to set
> the display server back to X11
> * Swap back to X11 with the configuration package: dnf swap
> sddm-wayland-plasma sddm-x11
>
>
> == How To Test ==
> Once the SDDM and Plasma Wayland changes are made, Rawhide users can
> try this by using nightly KDE ISOs and using them normally to install
> and run a Rawhide KDE Plasma environment.
>
> == User Experience ==
> Ideally, there should be no noticeable impact on the user experience,
> though users may notice that things operate more smoothly and with
> slightly lower resources.
Last time I tried, I couldn't use Synergy and Wayland together, so I
use X11 sessions with KDE still. Will this change only affect the
pre-login greeter screen, or does it also affect the lock screen when
a running X11 session is locked (either explicitly or after the
timeout)? Currently I can still use the mouse and keyboard from a
different machine to unlock that lock screen. If it starts using
Wayland that won't work. It might be worth mentioning that for the
user experience for other Synergy users.
___
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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Tue, Feb 1, 2022 at 3:30 AM Jeff Fearn wrote: > Tl;dr From Monday 28th February, applications making API calls to > Bugzilla may no longer authenticate using passwords or supplying API > keys in call parameters. Instead, API keys must be supplied in the > Authorization header. > > Support for using the Authorization header has been deployed to all Red > Hat Bugzilla instances. You can change your code at any time and not > have to wait for the old methods to be disabled. > > We will require all authenticated API usage to use this new method; this > will break API access to Red Hat Bugzilla for any tools that don't use > the Authorization header [1]. > > If you are not certain your tooling authenticates using this header then > you need to take action to confirm it does and to modify your tooling to > use it if it doesn't. > > This new method does away with logging in and out of the API and uses > API_KEYs in a standard Authorization header. This header needs to be > sent with every call to the API. > > The old methods will be disabled on a rolling basis across the RHBZ > servers. > > Target Dates: > > https://bugzilla.stage.redhat.com - Mon 07th Feb 00:00 UTC > https://bugzilla.redhat.com - Mon 28th Feb 00:00 UTC > Hello Jeff, initially I (and not just me) read the email as "update to the latest python-bugzilla and you'll be fine". But after I played with bugzilla.stage, and read the announcement more carefully, it seems that the only possible authentication method is now using the bugzilla api key, i.e. using the username + password login is no longer possible (for API access). Is that correct? I do have several concerns regarding that. The change seems too sudden and a lot of Fedora tooling interacts with bugzilla. Even worse, there are some tools which will get downright broken or massively impacted with no option to fix that. The first one that comes to mind is the Anaconda installer. If there's a crash during installation, it asks the user for username+password bugzilla credentials to report a bug. This can't get fixed for F35, because the installer images are already created, there is no update mechanism. So we'll lose all installer bug reports (unless reported manually) starting Feb 28th. This could be improved in F36, which is currently scheduled for a release on April 19th. However, even if Anaconda changes the bug reporting mechanism and asks the user to create an API key first, and then provide it to Anaconda, I fear that this will have a devastating impact on the number of bug reports that we receive. It is quite different to fill out a username and a password (which you already remember or have it stored, but is of a reasonable length), from going to bugzilla (on a different computer, because your current one is crashed during installation), creating a new api key (you can't even display your existing ones, so you must have them stored separately or always create a new one), and then retyping a 40-character random string from one computer to another. Who will have the dedication to do this "stuff"? And possibly repeatedly, in case of more crashes? (Even we, the QA team, will hate this. You can't always easily share your clipboard into a VM with the installation environment, or when using bare metal, and if we have to retype a 40-character random string several times per day, because we made the installer crash, that's going to severely impact us on multiple levels). This same issue is shared with Fedora's crash reporting tool, ABRT. Any time something crashes on the desktop, the user is suggested to submit a bug report. Instead of providing the username+password, the user will have to go through the api key creation motions. But at least this time the api key can be remembered by ABRT. But again I fear we'll lose a considerable amount of bug reports. Instead of removing obstacles, we're adding them. And as before, the change is too sudden, the ABRT team might not be able to react in time and we'll lose all bug reports starting Feb 28th. So, basically two questions: 1. Why are we given so little time to react? Can this change wait at least until F36 is released (around the end of April), so that the Anaconda and ABRT teams (as well as others) can incorporate the changes? 2. Is there a good enough justification for completely banning username+password authentication? Because this will have a strong impact on Fedora quality by reducing the amount of crash reports which we receive, I can't imagine it any other way. PS: This is also sent to the Fedora devel list, I hope you can reply there as well. It can be done from the web interface, if you prefer [1]. Thanks, Kamil Páral Fedora QE [1] 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/
Fedora-36-20220209.n.0 compose check report
No missing expected images. Failed openQA tests: 98/226 (x86_64), 61/159 (aarch64) ID: 1122802 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1122802 ID: 1122805 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1122805 ID: 1122806 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/1122806 ID: 1122817 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/1122817 ID: 1122818 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/1122818 ID: 1122819 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/1122819 ID: 1122858 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1122858 ID: 1122859 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1122859 ID: 1122860 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1122860 ID: 1122885 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1122885 ID: 1122906 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1122906 ID: 1122923 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1122923 ID: 1122933 Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1122933 ID: 1122939 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1122939 ID: 1122944 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/1122944 ID: 1122946 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi URL: https://openqa.fedoraproject.org/tests/1122946 ID: 1122953 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1122953 ID: 1122954 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/1122954 ID: 1122955 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi URL: https://openqa.fedoraproject.org/tests/1122955 ID: 1122987 Test: aarch64 Server-raw_xz-raw.xz base_reboot_unmount@uefi URL: https://openqa.fedoraproject.org/tests/1122987 ID: 1122990 Test: aarch64 Server-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1122990 ID: 1122998 Test: aarch64 Workstation-raw_xz-raw.xz release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1122998 ID: 1122999 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1122999 ID: 1123001 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1123001 ID: 1123008 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1123008 ID: 1123012 Test: aarch64 Workstation-raw_xz-raw.xz desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/1123012 ID: 1123020 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1123020 ID: 1123028 Test: x86_64 Workstation-upgrade evince URL: https://openqa.fedoraproject.org/tests/1123028 ID: 1123031 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1123031 ID: 1123032 Test: x86_64 Workstation-upgrade release_identification URL: https://openqa.fedoraproject.org/tests/1123032 ID: 1123034 Test: x86_64 Workstation-upgrade desktop_background URL: https://openqa.fedoraproject.org/tests/1123034 ID: 1123037 Test: x86_64 Workstation-upgrade desktop_printing URL: https://openqa.fedoraproject.org/tests/1123037 ID: 1123048 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1123048 ID: 1123052 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1123052 ID: 1123054 Test: aarch64 Workstation-upgrade desktop_background@uefi URL: https://openqa.fedoraproject.org/tests/1123054 ID: 1123059 Test: aarch64 Workstation-upgrade release_identification@uefi URL: https://openqa.fedoraproject.org/tests/1123059 ID: 1123061 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1123061 ID: 1123094 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1123094 ID: 1123185 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/1123185 ID: 1123186 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1123186 ID: 1123187 Test: x86_64 Everything-boo
Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
On Wed, Feb 9, 2022 at 5:24 AM Jonathan Wakely wrote:
>
> On Tue, 18 Jan 2022 at 14:30, Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
> >
> > = Wayland by Default for SDDM =
> >
> > == Summary ==
> > Change the default display server mode for SDDM to use a Wayland-based
> > greeter rather than an X11-based one.
> >
> > == Owner ==
> > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> > [[User:Jgrulich|Jan Grulich]]
> > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> > * Product: KDE Spin, Kinoite
> > * Responsible WG: KDE SIG
> >
> >
> > == Detailed Description ==
> > With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
> > SDDM to support using a Wayland based greeter] and
> > [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
> > broken fallback when platform drivers are unavailable]], it is now
> > possible for the Fedora KDE variants (the regular spin and Kinoite) to
> > move to Wayland for the login manager, which effectively completes the
> > switch to Wayland for these variants.
> >
> >
> > == Benefit to Fedora ==
> > As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
> > Change to switch Plasma to Wayland by default]], Fedora is a leader in
> > advancing the adoption of the Wayland protocol as part of the overall
> > strategy to improve the Linux graphical software stack. We have been
> > successful in helping drive Wayland forward in the Plasma Desktop, and
> > we intend to do the same for SDDM.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> > mutually exclusive sddm-wayland-generic and
> > sddm-x11 greeter configuration packages.
> > ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> > *** Enable installation of the SDDM Wayland configuration snippet and
> > ship as sddm-wayland-plasma that is mutually exclusive
> > with the other sddm greeter configuration packages. This package will
> > supplement {{package|sddm}} and plasma-workspace-wayland
> > to be automatically installed together.
> > ** Modify @kde-desktop comps group for Fedora Linux 36 to
> > include sddm-wayland-plasma for the media.
> >
> >
> > * Other developers: N/A (not needed for this Change)
> >
> > * Release engineering: [https://pagure.io/releng/issue/10536 #10536]
> > * Policies and guidelines: N/A (not needed for this Change)
> > * Trademark approval: N/A (not needed for this Change)
> > * Alignment with Objectives: N/A
> >
> >
> > == Upgrade/compatibility impact ==
> > On upgrade to Fedora Linux 36, SDDM will be transparently switched
> > from the X11 greeter to the Wayland one leveraging kwin. In order to
> > override this, the user can do one of the following:
> > * Drop in a configuration file in /etc/sddm.conf.d to set
> > the display server back to X11
> > * Swap back to X11 with the configuration package: dnf swap
> > sddm-wayland-plasma sddm-x11
> >
> >
> > == How To Test ==
> > Once the SDDM and Plasma Wayland changes are made, Rawhide users can
> > try this by using nightly KDE ISOs and using them normally to install
> > and run a Rawhide KDE Plasma environment.
> >
> > == User Experience ==
> > Ideally, there should be no noticeable impact on the user experience,
> > though users may notice that things operate more smoothly and with
> > slightly lower resources.
>
>
> Last time I tried, I couldn't use Synergy and Wayland together, so I
> use X11 sessions with KDE still. Will this change only affect the
> pre-login greeter screen, or does it also affect the lock screen when
> a running X11 session is locked (either explicitly or after the
> timeout)? Currently I can still use the mouse and keyboard from a
> different machine to unlock that lock screen. If it starts using
> Wayland that won't work. It might be worth mentioning that for the
> user experience for other Synergy users.
SDDM only affects pre-login, just like GDM for GNOME. If you select
X11 at login, the lock screen will also use X11.
--
真実はいつも一つ！/ 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: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
On Wed, 9 Feb 2022 at 11:00, Neal Gompa wrote:
>
> On Wed, Feb 9, 2022 at 5:24 AM Jonathan Wakely wrote:
> >
> > On Tue, 18 Jan 2022 at 14:30, Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
> > >
> > > = Wayland by Default for SDDM =
> > >
> > > == Summary ==
> > > Change the default display server mode for SDDM to use a Wayland-based
> > > greeter rather than an X11-based one.
> > >
> > > == Owner ==
> > > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> > > [[User:Jgrulich|Jan Grulich]]
> > > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> > > * Product: KDE Spin, Kinoite
> > > * Responsible WG: KDE SIG
> > >
> > >
> > > == Detailed Description ==
> > > With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
> > > SDDM to support using a Wayland based greeter] and
> > > [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
> > > broken fallback when platform drivers are unavailable]], it is now
> > > possible for the Fedora KDE variants (the regular spin and Kinoite) to
> > > move to Wayland for the login manager, which effectively completes the
> > > switch to Wayland for these variants.
> > >
> > >
> > > == Benefit to Fedora ==
> > > As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
> > > Change to switch Plasma to Wayland by default]], Fedora is a leader in
> > > advancing the adoption of the Wayland protocol as part of the overall
> > > strategy to improve the Linux graphical software stack. We have been
> > > successful in helping drive Wayland forward in the Plasma Desktop, and
> > > we intend to do the same for SDDM.
> > >
> > > == Scope ==
> > > * Proposal owners:
> > > ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> > > mutually exclusive sddm-wayland-generic and
> > > sddm-x11 greeter configuration packages.
> > > ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> > > *** Enable installation of the SDDM Wayland configuration snippet and
> > > ship as sddm-wayland-plasma that is mutually exclusive
> > > with the other sddm greeter configuration packages. This package will
> > > supplement {{package|sddm}} and plasma-workspace-wayland
> > > to be automatically installed together.
> > > ** Modify @kde-desktop comps group for Fedora Linux 36 to
> > > include sddm-wayland-plasma for the media.
> > >
> > >
> > > * Other developers: N/A (not needed for this Change)
> > >
> > > * Release engineering: [https://pagure.io/releng/issue/10536 #10536]
> > > * Policies and guidelines: N/A (not needed for this Change)
> > > * Trademark approval: N/A (not needed for this Change)
> > > * Alignment with Objectives: N/A
> > >
> > >
> > > == Upgrade/compatibility impact ==
> > > On upgrade to Fedora Linux 36, SDDM will be transparently switched
> > > from the X11 greeter to the Wayland one leveraging kwin. In order to
> > > override this, the user can do one of the following:
> > > * Drop in a configuration file in /etc/sddm.conf.d to set
> > > the display server back to X11
> > > * Swap back to X11 with the configuration package: dnf swap
> > > sddm-wayland-plasma sddm-x11
> > >
> > >
> > > == How To Test ==
> > > Once the SDDM and Plasma Wayland changes are made, Rawhide users can
> > > try this by using nightly KDE ISOs and using them normally to install
> > > and run a Rawhide KDE Plasma environment.
> > >
> > > == User Experience ==
> > > Ideally, there should be no noticeable impact on the user experience,
> > > though users may notice that things operate more smoothly and with
> > > slightly lower resources.
> >
> >
> > Last time I tried, I couldn't use Synergy and Wayland together, so I
> > use X11 sessions with KDE still. Will this change only affect the
> > pre-login greeter screen, or does it also affect the lock screen when
> > a running X11 session is locked (either explicitly or after the
> > timeout)? Currently I can still use the mouse and keyboard from a
> > different machine to unlock that lock screen. If it starts using
> > Wayland that won't work. It might be worth mentioning that for the
> > user experience for other Synergy users.
>
> SDDM only affects pre-login, just like GDM for GNOME. If you select
> X11 at login, the lock screen will also use X11.
Great, thanks!
___
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: Do we have any policy for disabling inactive users
On Wed, Feb 9, 2022, 02:54 Adam Williamson wrote: The audit described there was done once last February after the policy > was approved. It does not seem to have been done when F35 branched, > though (unless the audit turned up no further dormant provenpackagers > and thus no mail was sent). Ben, I guess it should be done now for F36 > branching? And added to some TODO list, if it was really missed last > time? > Way ahead of you. It was missed last time, so I added it to the schedule. Coincidentally, today is the day I do it. https://fedorapeople.org/groups/schedule/f-36/f-36-pm-tasks.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: GCC changes break "libscrypt" package in F36
On 08/02/2022 21:41, Florian Weimer wrote: CFLAGS?=-O2 -Wall -g -D_FORTIFY_SOURCE=2 -fstack-protector -fPIC LDFLAGS?=-Wl,-z,now -Wl,-z,relro -Wl,-soname,libscrypt.so.0 -Wl,--version-script=libscrypt.version Can be easily fixed by changing ?= with +=. -- 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
[Test-Announce] Fedora-IoT 36 RC 20220209.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 36 RC 20220209.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 Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36iot 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-IoT_36_RC_20220209.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_36_RC_20220209.0_General 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
Fedora-IoT-36-20220209.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20211213.0): ID: 1123661 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1123661 ID: 1123675 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1123675 ID: 1123734 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1123734 Old failures (same test failed in Fedora-IoT-36-20211213.0): ID: 1123630 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1123630 ID: 1123647 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1123647 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
Re: Do we have any policy for disabling inactive users
On Wed, Feb 9, 2022 at 7:25 AM Ben Cotton wrote: > It was missed last time, Now that I've had my coffee I want to correct my use of the passive voice. *I* missed it last time. Carry on. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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-review bugreport 2038828
Hello, a month ago I opened a bugreport against fedora-review https://bugzilla.redhat.com/show_bug.cgi?id=2038828 Today I tried to clean up mock build with various command, and at the end I also tried to delete the content of folder /var/lib/mock/ but I am still experiencing the problem. Since it is blocking a review that I should complete as soon as possible, does anybody know if I can apply any kind of workaround? Using another machine would require me to move all certs, etc. so it's not my preferred option 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
Re: fedora-review bugreport 2038828
V Wed, Feb 09, 2022 at 02:53:27PM +0100, Germano Massullo napsal(a): > Hello, a month ago I opened a bugreport against fedora-review > https://bugzilla.redhat.com/show_bug.cgi?id=2038828 > Today I tried to clean up mock build with various command, and at the end I > also tried to delete the content of folder /var/lib/mock/ but I am still > experiencing the problem. > Since it is blocking a review that I should complete as soon as possible, > does anybody know if I can apply any kind of workaround? Do the review manually without fedora-review tool. -- Petr 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: fedora-review bugreport 2038828
the problem was fedora-review not properly supporting tmpfs. All infos in the bugreport Best regards ___ 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: Mathematical packages: looking for maintainers
Sorry for the slow response. $REAL_LIFE has been keeping me hopping for several days now. On Fri, Feb 4, 2022 at 5:24 AM Richard W.M. Jones wrote: > On Thu, Feb 03, 2022 at 08:03:27PM -0700, Jerry James wrote: > > ocaml-tplib > > I think this is the only ocaml one? I can take it. Yes, it is. It is an optional polymake dependency. The last upstream release was in 2013, which suggests that upstream is dead. If it ever becomes unbuildable, we can drop it without breaking polymake. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Mathematical packages: looking for maintainers
On Tue, Feb 8, 2022 at 1:20 PM Miro Hrončok wrote: > At least a couple of those sound like something our (Python Maint) packages > depend on. > > I'll analyze the dep chain and come back to you. I know for sure we'll need to > take python-sphinx_rtd_theme. Thank you, Miro. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: [Fedora-packaging] Re: font copies in sphinx generated documentation
On 2/8/22 20:13, Miro Hrončok wrote: > On 08. 02. 22 19:50, Petr Menšík wrote: >> Is FESCO okay with bundled javascript libraries in similar >> packages? > > FESCo/FPC does allow bundling. See e.g. > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > This is no different. Except what you describe is a lot of work for > the sphinx maintainers. As one of the I'd rather outright ban packaged > documentation than have to make it work myself. It seems ban is quite radical solution. I thought I have seen that in guidelines and indeed. Fonts should not be bundled by other packages [1]. Are system libraries only native code libraries? Doesn't jquery count as system library itself? If javascript libraries do not require any attempts to not duplicate shared code, shouldn't it be mentioned somewhere in guidelines? It seems they try to avoid current situation [2]. I could certainly help with some pull requests, but any change cannot be done at all without cooperation of theme package maintainers. Fedora theme would help to avoid local fonts, but would leave unresolved jquery and underline bundles. Those are part of basic sphinx theme. So change of theme might help only partially. But it would be self-contained change, I guess worth trying. I admit npm processed theme.css is far outside of my expertise. I found we already have some infrastructure for similar things at /usr/share/web-assets/fonts/ and /usr/share/web-assets/javascript/, perhaps it should be reused also for html manuals. Unless documentation build time would be simple to modify, post-processing of installed documentation to (sym)link to shared assets might be simpler. And would require almost no work from sphinx or themes maintainers. Cheers, Petr 1. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_avoid_bundling_of_fonts_in_other_packages 2. https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/#_wrappers_for_other_languages_or_environments -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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-35-20220209.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20220208.0): ID: 1123876 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1123876 ID: 1123889 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1123889 Passed openQA tests: 7/8 (x86_64), 7/8 (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
JasPer 3.0.0 update in Rawhide and F36
Hi, upstream authors of JasPer library have released a new major version. This rebase will introduce .so name bump from version 4 to version 6. I am going to rebase the library in rawhide on Friday February 11th. For testing purposes, you may use the copr build available at [1]. List of dependent packages and their build results with the new jasper library might be found at [2]. All comments are welcome. [1] https://copr.fedorainfracloud.org/coprs/jridky/jasper/ [2] https://copr.fedorainfracloud.org/coprs/jridky/jasperDepend/ Best regards Josef Ridky Senior Software Engineer Core Services Team Red Hat Czech, s.r.o. ___ 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: Fedora 36 Mass Branching
On Tue, Feb 08, 2022 at 04:30:30PM -0800, Kevin Fenzi wrote: > On Tue, Feb 08, 2022 at 03:53:51PM -0800, Michel Alexandre Salim wrote: > > On Tue, Feb 08, 2022 at 09:28:53PM +0100, Tomas Hrcka wrote: > > > Hi All, > > > > > > Fedora 36 has now been branched, please be sure to do a git pull > > > --rebase to pick up the new branch, as an additional reminder > > > > Most of my packages appear to have f36 branches, but of the two new > > packages I just requested yesterday, > > > > - the_foundation has a f36 branch > > - lagrange doesn't > > > > Should I just request it manually? > > Yep. > That seems to be failing right now: https://pagure.io/releng/fedora-scm-requests/issue/41998 Invalid body, keys: sls missing The problem is... the keys in the request are exactly the same as in every other requests I see. Is f36 not set up properly yet for request-branch? Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
ocaml-odoc license correction: MIT -> ISC
The ocaml-odoc license field should be ISC, but has been incorrectly given as MIT since the package was introduced. The license will be corrected in the builds I am now doing for Rawhide and F36. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Do we have any policy for disabling inactive users
Il 09/02/22 08:54, Adam Williamson ha scritto: > On Wed, 2022-02-09 at 07:03 +, Mattia Verga via devel wrote: >> Just being paranoid here: do we have any policy / automatism for >> disabling "power" users (in packager group or like) which have been >> inactive for long time? > Yes. > > https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status > https://pagure.io/fesco/issue/2549 (ticket where the policy was approved) > That is referring to provenpackagers only. I'd like this to be extended to users in packagers group also. For example, if someone pulls from src.fedoraproject.org a list of users in the packagers group which have been inactive for a long time, check if their email is inactive and if it has been made available for claiming, then they claim the email and reset the Fedora account password to gain access in that account... Mattia ___ 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: Fedora 36 Mass Branching
On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka wrote: > > Hi All, > > Fedora 36 has now been branched, please be sure to do a git pull > --rebase to pick up the new branch, as an additional reminder > rawhide/f36 has been completely isolated from previous releases, so What does this mean? > this means that anything you do for f36 you also have to do in the > rawhide branch and do a build there. Right, f36 is a separate branch from rawhide now. That makes sense. What does "rawhide/f36 has been completely isolated from previous releases" mean? If it's trying to say "rawhide and f36 are now separate branches" it fails to do so. Is it supposed to say rawhide/f37? ___ 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: Unannounced .so version bump: glew
It looks like the recent update to glew 2.2.0[1] in F36 and F37 contained an undetected/unannounced .so version change. This is breaking vtk[2] and presumably a lot of other things. I suggest updating the globs in the %files list[3] to keep this from happening in the future. [1] https://src.fedoraproject.org/rpms/glew/c/94a81ef261f8bd43d1185ddf9c81a57a717a738d?branch=rawhide [2] https://kojipkgs.fedoraproject.org//work/tasks/2673/82602673/root.log [3] https://kojipkgs.fedoraproject.org//work/tasks/2673/82602673/root.log ___ 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: Fedora 36 Mass Branching
On Wed, Feb 9, 2022 at 6:12 PM Jonathan Wakely wrote: > > On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka wrote: > > > > Hi All, > > > > Fedora 36 has now been branched, please be sure to do a git pull > > --rebase to pick up the new branch, as an additional reminder > > rawhide/f36 has been completely isolated from previous releases, so > > What does this mean? > > > this means that anything you do for f36 you also have to do in the > > rawhide branch and do a build there. > > Right, f36 is a separate branch from rawhide now. That makes sense. > What does "rawhide/f36 has been completely isolated from previous > releases" mean? If it's trying to say "rawhide and f36 are now > separate branches" it fails to do so. Is it supposed to say > rawhide/f37? Yeah, that template sounds really archaic by todays standards, and it's at least misleading or even wrong in some regards. So it could benefit from being updateg ... Is it maintained in a public repo somewhere where one could submit a PR to fix it? :) Fabio On Wed, Feb 9, 2022 at 6:12 PM Jonathan Wakely wrote: > > On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka wrote: > > > > Hi All, > > > > Fedora 36 has now been branched, please be sure to do a git pull > > --rebase to pick up the new branch, as an additional reminder > > rawhide/f36 has been completely isolated from previous releases, so > > What does this mean? > > > this means that anything you do for f36 you also have to do in the > > rawhide branch and do a build there. > > Right, f36 is a separate branch from rawhide now. That makes sense. > What does "rawhide/f36 has been completely isolated from previous > releases" mean? If it's trying to say "rawhide and f36 are now > separate branches" it fails to do so. Is it supposed to say > rawhide/f37? > ___ > 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Wed, Feb 09, 2022 at 11:33:24AM +0100, Kamil Paral wrote: > However, even if Anaconda changes the bug reporting mechanism and asks the > user to create an API key first, and then provide it to Anaconda, I fear > that this will have a devastating impact on the number of bug reports that > we receive. It is quite different to fill out a username and a password > (which you already remember or have it stored, but is of a reasonable > length), from going to bugzilla (on a different computer, because your > current one is crashed during installation), creating a new api key (you > can't even display your existing ones, so you must have them stored > separately or always create a new one), and then retyping a 40-character > random string from one computer to another. Who will have the dedication to > do this "stuff"? And possibly repeatedly, in case of more crashes? (Even > we, the QA team, will hate this. You can't always easily share your > clipboard into a VM with the installation environment, or when using bare > metal, and if we have to retype a 40-character random string several times > per day, because we made the installer crash, that's going to severely > impact us on multiple levels). Using API tokens over username/password is a good thing from a security POV, but as you say, the process of creating the token and getting it over to the client is horribly user unfriendly. This feels like a similar problem space to that of signing onto a streaming service, with an app on your smart TV. In the streaming apps I've used this is quite user friendly. The (client) app displays a short unique code (presumably acquired from thue server), which is effectively a one time code to identify that client. The user logs in to the service on their laptop/tablet/mobile, does authentication in whatever way they need to (username / password or a software 2fa, or a hardware token, etc). They then just enter the unique code shown on the TV, thus associating the device with their account and the device is now automagically logged on. I'm assuming that what's going on here is that when you enter the one time identity code, the service is effectively creating an API token behind the scenes in your account, and handing that back to the TV app client. I do wonder what security people think of this kind of approach. To be a significant benefit the one time codes have to be fairly short and simple to type in on your separate browser. So there's still a tradeoff between the amount of entropy they have and the usability. In all the cases I've seen though, the codes are noticably simpler/shorter than a typical API token would be. I'm guessing the very short validity time of these one time tokens lets them get away with having less entropy, than a long lived API token needs. I've not seen this kind of auth dance implemented in any software other than TV streaming apps, and not bugzilla and not any other bug tracker I've come across. So it is not a practical solution today, more of a thought experiment on how API tokens could possibly be made less awful to acquire for something like Anaconda or Abrt. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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: Do we have any policy for disabling inactive users
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel wrote: > That is referring to provenpackagers only. I'd like this to be extended > to users in packagers group also. Given that provenpackagers are group that can do the most potential damage, that process arguably covers the users in the true "power" group in your initial email. Users not in the provenpackagers group have a relatively small blast radius. Perhaps that list of users to "ping" once a release should be extended to eventually include those whose packages are in the @core or @critical-path-base groups, but I would not be at all surprised if most of those people are not already provenpackagers, so they are already covered. ___ 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: Fedora 36 Mass Branching
On Wed, Feb 09, 2022 at 06:26:44PM +0100, Fabio Valentini wrote: > On Wed, Feb 9, 2022 at 6:12 PM Jonathan Wakely wrote: > > > > On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka wrote: > > > > > > Hi All, > > > > > > Fedora 36 has now been branched, please be sure to do a git pull > > > --rebase to pick up the new branch, as an additional reminder > > > rawhide/f36 has been completely isolated from previous releases, so > > > > What does this mean? > > > > > this means that anything you do for f36 you also have to do in the > > > rawhide branch and do a build there. > > > > Right, f36 is a separate branch from rawhide now. That makes sense. > > What does "rawhide/f36 has been completely isolated from previous > > releases" mean? If it's trying to say "rawhide and f36 are now > > separate branches" it fails to do so. Is it supposed to say > > rawhide/f37? > > Yeah, that template sounds really archaic by todays standards, and > it's at least misleading or even wrong in some regards. > So it could benefit from being updateg ... Is it maintained in a > public repo somewhere where one could submit a PR to fix it? :) Well, it means _builds_ are not inherited between them. Long ago we used to let branched inherit into rawhide until there was a branched build. This turned out to cause a number of problems so we stopped doing it. So now if you do a f36 build, you need to also make sure to do a f37 one as well. I am pretty sure the wording here dates to around that time. I would expect that text to be in https://docs.pagure.org/releng/sop_mass_branching.html but I guess it's not. I will ask... 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: Suggestions for fedora
On Wed, Feb 09, 2022 at 09:37:45AM -, Raj J Putari wrote: > Not sure what selinux really is but I think it makes polices based on system > mechanics so nekto or netko the vulnerability scanner can be reversed > engineered to generate custom policies on the fly Well, no. It provides a policy that describes how contexts and processes and files all interact. This policy restricts things to only doing what they need to operate correctly, and deny's them doing things they shouldn't do. > Speaking of policy, a politics on the project would be nice Not sure what you are asking for here? 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: Fedora 36 Mass Branching
On Wed, Feb 09, 2022 at 09:39:16AM +0100, Fabio Valentini wrote: > On Wed, Feb 9, 2022 at 2:32 AM Kevin Fenzi wrote: > > > > And I suppose we should really look at disabling builds on mass branch > > day (while it's happening) it never ends well. :) > > Should I open a FESCo / Releng / Infra ticket for this, so we can at > least discuss implementing that? > I'm a bit tired of troubleshooting branching-related package limbo > states twice a year :( Sure. releng please. The thing thats stopped us from doing this is figuring out a good way to deny users ability to build, but yet let builders work and releng processes work. I suppose we could just block external koji access, but it would be a pretty unfriendly message and get a lot of 'is koji down' messages. But perhaps we can come up with something. 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
Self Introduction: xtify21
Hello, Looking to get back into packaging as I attempted to somewhat help out a few years back. I currently help out with alma linux as far as some infrastructure stuff goes as well. I work as a sysadmin by day as well. I know some python, shell scripting, and familiar with rpm spec files and configurations. Thanks signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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
Inactive provenpackagers to be removed from group
In accordance with FESCo policy[1], the following provenpackagers will be submitted for removal in two weeks based on a lack of Koji builds submitted in the last six months. If you received this directly, you can reply off-list to indicate you should still be in the provenpackager group. Note that removal from this group is not a "punishment" or a lack of appreciation for the work you have done. The intent of the process is to ensure contributors with distro-wide package privileges are still active and responsive. This process is done regularly at the branch point in each release. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status Checked 148 provenpackagers The following 23 provenpackagers have not submitted a Koji build since at least 2021-08-04 00:00:00: akurtakov codeblock iarnell ilianaw jsmith jwilson kanarip karsten law laxathom lutter mcepl nhorman notting oliver pmachata psabata ruben steve tflink till tmraz wtogami -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel-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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
Am I right to suspect that ABRT bug reports are going to disappear for the foreseeable future? ___ 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: Unannounced .so version bump: glew
Compose of f36 still have glew-2.1.0-11.fc36 maybe we can move it to a side tag and start the rebuilds Depending packages (66): FlightGear FlightGear-Atlas OpenColorIO OpenImageIO SFML amanith astromenace avogadro2 avogadro2-libs blender bzflag calligra cegui cegui06 cloudcompare colobot ddnet dreamchess eigen3 enblend endless-sky freedroidrpg freewrl gambas3 gource hedgewars hugin hyperrogue kalzium kicad linphone logstalgia mangohud megaglest meshlab mupen64plus ogre openclonk opencolorio1 opencsg openmsx openscad opensubdiv osgearth paraview pcl pioneer pocl prusa-slicer pymol quesoglc root rss-glx schroedinger scorched3d scummvm sdljava sdrpp slop supertux supertuxkart toped vdrift vtk widelands wxmacmolplt depending on: glew (66) FlightGear (maintained by: bellet) FlightGear-2020.3.12-1.fc36.src requires glew-devel = 2.1.0-11.fc36 FlightGear-2020.3.12-1.fc36.x86_64 requires libGLEW.so.2.1()(64bit) FlightGear-Atlas (maintained by: bellet) FlightGear-Atlas-0.5.0-0.74.cvs20141002.fc36.src requires glew-devel = 2.1.0-11.fc36 FlightGear-Atlas-0.5.0-0.74.cvs20141002.fc36.x86_64 requires libGLEW.so.2.1()(64bit) OpenColorIO (maintained by: hobbes1069) OpenColorIO-2.1.1-2.fc36.src requires glew-devel = 2.1.0-11.fc36 OpenColorIO-tools-2.1.1-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit) OpenImageIO (maintained by: hobbes1069) OpenImageIO-2.3.12.0-1.fc36.src requires glew-devel = 2.1.0-11.fc36 SFML (maintained by: pranvk, sonkun, wtaymans) SFML-2.5.1-10.fc36.src requires glew-devel = 2.1.0-11.fc36 amanith (maintained by: spot) amanith-0.3-48.fc36.i686 requires libGLEW.so.2.1 amanith-0.3-48.fc36.src requires glew-devel = 2.1.0-11.fc36 amanith-0.3-48.fc36.x86_64 requires libGLEW.so.2.1()(64bit) amanith-devel-0.3-48.fc36.i686 requires glew-devel = 2.1.0-11.fc36 amanith-devel-0.3-48.fc36.x86_64 requires glew-devel = 2.1.0-11.fc36 astromenace (maintained by: limb) astromenace-1.4.2-3.fc36.src requires glew-devel = 2.1.0-11.fc36 avogadro2 (maintained by: sagitter) avogadro2-1.95.1-5.fc36.src requires glew-devel = 2.1.0-11.fc36 avogadro2-libs (maintained by: sagitter) avogadro2-libs-1.95.1-6.fc36.i686 requires libGLEW.so.2.1 avogadro2-libs-1.95.1-6.fc36.src requires pkgconfig(glew) = 2.1.0 avogadro2-libs-1.95.1-6.fc36.x86_64 requires libGLEW.so.2.1()(64bit) avogadro2-libs-devel-1.95.1-6.fc36.i686 requires glew-devel(x86-32) = 2.1.0-11.fc36 avogadro2-libs-devel-1.95.1-6.fc36.x86_64 requires glew-devel(x86-64) = 2.1.0-11.fc36 blender (maintained by: design-sw, ignatenkobrain, kwizart, luya, roma, s4504kr, slaanesh) blender-1:3.0.0-2.fc36.src requires pkgconfig(glew) = 2.1.0 blender-1:3.0.0-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit) bzflag (maintained by: jmakey) bzflag-2.4.22-3.fc36.src requires glew-devel = 2.1.0-11.fc36 bzflag-2.4.22-3.fc36.x86_64 requires libGLEW.so.2.1()(64bit) calligra (maintained by: kde-sig, rdieter) calligra-3.2.1-16.fc36.src requires pkgconfig(glew) = 2.1.0 cegui (maintained by: bruno, jwrdegoede, timn) cegui-0.8.7-23.fc36.i686 requires libGLEW.so.2.1 cegui-0.8.7-23.fc36.src requires glew-devel = 2.1.0-11.fc36 cegui-0.8.7-23.fc36.x86_64 requires libGLEW.so.2.1()(64bit) cegui06 (maintained by: bruno, jwrdegoede) cegui06-0.6.2-37.fc36.src requires glew-devel = 2.1.0-11.fc36 cegui06-0.6.2-37.fc36.x86_64 requires libGLEW.so.2.1()(64bit) cloudcompare (maintained by: churchyard) cloudcompare-2.9.1-17.fc36.src requires pkgconfig(glew) = 2.1.0 colobot (maintained by: suve) colobot-0.2.0-1.fc36.src requires glew-devel = 2.1.0-11.fc36 colobot-0.2.0-1.fc36.x86_64 requires libGLEW.so.2.1()(64bit) ddnet (maintained by: sergiomb) ddnet-15.8.1-2.fc36.src requires pkgconfig(glew) = 2.1.0 ddnet-15.8.1-2.fc36.x86_64 requires libGLEW.so.2.1()(64bit) dreamchess (maintained by: raphgro) dreamchess-0.3.0-0.12.20180601git.fc36.src requires glew-devel = 2.1.0- 11.fc36 dreamchess-0.3.0-0.12.20180601git.fc36.x86_64 requires libGLEW.so.2.1()(64bit) eigen3 (maintained by: rmattes, smani) eigen3-3.4.0-4.fc36.src requires glew-devel = 2.1.0-11.fc36 enblend (maintained by: bpostle) enblend-4.2-22.fc36.src requires glew-devel = 2.1.0-11.fc36 endless-sky (maintained by: linkdupont) endless-sky-0.9.14-3.fc36.src requires glew-devel = 2.1.0-11.fc36 endless-sky-0.9.14-3.fc36.x86_64 requires libGLEW.so.2.1()(64bit) freedroidrpg (maintained by: limb) freedroidrpg-1.0-0.fc36.rc2.7.src requires glew-devel = 2.1.0-11.fc36 freedroidrpg-1.0-0.fc36.rc2.7.x86_64 requires libGLEW.so.2.1()(64bit) freewrl (maintained by: spot, stevetraylen) freewrl-4.3.0-11.20200221gite99ab4a.fc36.src requires glew-devel = 2.1.0-11.fc36 gambas3 (maintained by: spot) gambas3-3.16.3-5.fc36.src requires glew-devel = 2.1.0-11.fc36 gambas3-gb-opengl-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit) gambas3-gb-opengl-glsl-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit) gambas3-gb-opengl-sge-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit) gambas3-gb-sdl-3.16.3-5.fc36.x86_64 requires libGLEW.so.2.1()(64bit) gource (maint
Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
st 9. 2. 2022 o 19:39 Michael Catanzaro napísal(a): > > Am I right to suspect that ABRT bug reports are going to disappear for > the foreseeable future? > Nope, we are working on a fix. Thanks, Michal > > ___ > 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Wed, 2022-02-09 at 17:44 +, Daniel P. Berrangé wrote: > > I've not seen this kind of auth dance implemented in any software > other than TV streaming apps, and not bugzilla and not any other > bug tracker I've come across. So it is not a practical solution > today, more of a thought experiment on how API tokens could > possibly be made less awful to acquire for something like Anaconda > or Abrt. Firefox does something similar for signing new instances of Firefox into your account for syncing. I've also seen it on a couple other things but can't quite put my finger on what at the moment. The other way we handle something like this is for FAS authentication; if you try and use e.g. the Bodhi CLI client without being logged in, it will print a browser URL and try to open a browser at that URL automatically, you log in through the browser and a key/token is made available to the app to store for future non-interactive logins. But really, the problem here is not so much "let's come up with an elegant design" as "um it seems like things are going to break catastrophically in 19 days, we need to do something really quite urgently to make that not happen". -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Wed, 2022-02-09 at 20:27 +0100, Michal Srb wrote: > st 9. 2. 2022 o 19:39 Michael Catanzaro napísal(a): > > > > > Am I right to suspect that ABRT bug reports are going to disappear for > > the foreseeable future? > > > > Nope, we are working on a fix. That's great news, but since AFAICT this fix is not even proposed as a PR for upstream libreport yet, we still seem to be cutting things rather fine on the timeline. Per the current timeline, there are 19 days before an attempt to log in with username and password will fail and cause your password to be invalidated. Is the libreport fix going to be finished, tested, merged, released, and an update pushed stable for all distributions that include it, all within 19 days? What do we do about the problem Kamil pointed out, that there are current Fedora (and RHEL?) installer images out there with current libreport baked in, which will offer username/password login for bug reporting forever, and we have no way to change that? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora CoreOS Meeting Minutes 2022-02-09
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-09/fedora_coreos_meeting.2022-02-09-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-09/fedora_coreos_meeting.2022-02-09-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-09/fedora_coreos_meeting.2022-02-09-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by dustymabe at 16:30:01 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-02-09/fedora_coreos_meeting.2022-02-09-16.30.log.html . Meeting summary --- * roll call (dustymabe, 16:30:08) * Action items from last meeting (dustymabe, 16:33:52) * Actually move iptables to the nft backend (dustymabe, 16:35:14) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/676 (dustymabe, 16:35:21) * AGREED: To make it easier to understand and easier to rollout we will couple the conversion to iptables-nft with the rebase to F36. This means the notice period window will be shorter than initially discussed. (dustymabe, 16:44:14) * networking: consider the effects of BOOTIF kernel argument on nm-initrd-generator (dustymabe, 16:44:33) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1048 (dustymabe, 16:44:40) * AGREED: We will try to address the BOOTIF issue by updating our "was networking config provided" logic to handle BOOTIF rather than blanket applying rd.bootif=0 globally (dustymabe, 16:51:58) * New Package Request: qemu-user-static (dustymabe, 16:52:24) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1088 (dustymabe, 16:52:31) * AGREED: There are obviously packaging enhancements that could be made here (removal of python dep, reduction of shipped emulators by splitting out into subpackages) that are worth making even if we don't include qemu-user-static by default. Once those packaging improvements land we'd need to further consider it for inclusion in FCOS. It's a good idea, but maybe not necessary for the base (dustymabe, 17:04:05) * tracker: Fedora 36 changes considerations (dustymabe, 17:06:27) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/918 (dustymabe, 17:06:33) * some of us met earlier today to sift through and weed out changes that we don't think need discussion. (dustymabe, 17:07:06) * ACTION: jlebon to open issue to investigate "102 Introduce module Obsoletes and EOL" (dustymabe, 17:10:50) * ACTION: we think we can pick up DNSoverTLS changes passively but dustymabe will open a ticket to record the discussion here and provide a space for any issues that come up to be discussed. (dustymabe, 17:14:49) * 111 Drop NIS(+) support from PAM may affect users who use NIS+? likely not though. If so, we should direct them to e.g. LDAP or FreeIPA as the Change proposal suggests. so overall, skip. (dustymabe, 17:16:40) * ACTION: miabbott to open a tracking ticket for early testing of golang 1.18 when it's available (dustymabe, 17:21:16) * ACTION: dustymabe to open an issue for investigation into missing packages preventing auto-updates from working (dustymabe, 17:26:57) * we don't currently include the keylime agent in FCOS but we do generate a hashlist at build time for experimentation. Assuming the format of the hashlist hasn't changed we should be good here. (dustymabe, 17:31:41) * open floor (dustymabe, 17:31:52) * f36 just branched from rawhide, so now f37 exists (dustymabe, 17:32:17) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1093 > Container Plumbing Days 2022. Feel free to suggest a talk! (travier, 17:32:37) Meeting ended at 17:36:01 UTC. Action Items * jlebon to open issue to investigate "102 Introduce module Obsoletes and EOL" * we think we can pick up DNSoverTLS changes passively but dustymabe will open a ticket to record the discussion here and provide a space for any issues that come up to be discussed. * miabbott to open a tracking ticket for early testing of golang 1.18 when it's available * dustymabe to open an issue for investigation into missing packages preventing auto-updates from working Action Items, by person --- * dustymabe * we think we can pick up DNSoverTLS changes passively but dustymabe will open a ticket to record the discussion here and provide a space for any issues that come up to be discussed. * dustymabe to open an issue for investigation into missing packages preventing auto-updates from working * jlebon * jlebon to open issue to investigate "102 Introduce module Obsoletes and EOL" * miabbott * miabbott to open a tracking ticket for early testing of golang 1.18 when it's available * **UNASSIGNED** * (none) P
Re: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
st 9. 2. 2022 o 20:37 Adam Williamson napísal(a): > On Wed, 2022-02-09 at 20:27 +0100, Michal Srb wrote: > > st 9. 2. 2022 o 19:39 Michael Catanzaro > napísal(a): > > > > > > > > Am I right to suspect that ABRT bug reports are going to disappear for > > > the foreseeable future? > > > > > > > Nope, we are working on a fix. > > That's great news, but since AFAICT this fix is not even proposed as a > PR for upstream libreport yet, we still seem to be cutting things > rather fine on the timeline. > > Per the current timeline, there are 19 days before an attempt to log in > with username and password will fail and cause your password to be > invalidated. Is the libreport fix going to be finished, tested, merged, > released, and an update pushed stable for all distributions that > include it, all within 19 days? > Fingers crossed. > > What do we do about the problem Kamil pointed out, that there are > current Fedora (and RHEL?) installer images out there with current > libreport baked in, which will offer username/password login for bug > reporting forever, and we have no way to change that? > Yes, that is a problem. Unfortunately I don't see any way to fix Fedora images that are already out there. In RHEL, the option to report to Bugzilla should be available only in pre-release images, i.e. not in GA'ed ones. But this is something we need to confirm with anaconda. I think Bugzilla could automatically send emails that would explain the situation and next steps, if people try to use username+password after the deadline. Such clarity might help to mitigate the problem a bit. Thanks, Michal > -- > Adam Williamson > Fedora QA > IRC: adamw | Twitter: adamw_ha > https://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 > 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
Welcoming Nikita Popov (nikic) to the packager group
At the request[1] of Serge Guelton, who is a package maintainer for llvm, I have just sponsored Nikita Popov (FAS nikic) into the packager group a co-maintainer. Welcome, and thank you for your contributions to Fedora! – Ben Beasley [1] https://pagure.io/packager-sponsors/issue/521 ___ 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On Wed, Feb 09, 2022 at 17:44:35 +, "Daniel P. Berrangé" wrote: Using API tokens over username/password is a good thing from a security POV, but as you say, the process of creating the token and getting it over to the client is horribly user unfriendly. That depends on ypur threat model. If you aren't using third party apps, this doesn't provide much security benefit. For Fedora people are generally going to be using apps provided by Fedora, so not trusting them with your Fedora credentials seems pointless. Though that is from the perspective of someone who treats Fedora and Red Hat as being in the same security domain. That might not be the model that Red Hat employees take. For them Fedora might be considered a third party. ___ 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
On 2/9/22 14:30, Adam Williamson wrote: > On Wed, 2022-02-09 at 17:44 +, Daniel P. Berrangé wrote: >> >> I've not seen this kind of auth dance implemented in any software >> other than TV streaming apps, and not bugzilla and not any other >> bug tracker I've come across. So it is not a practical solution >> today, more of a thought experiment on how API tokens could >> possibly be made less awful to acquire for something like Anaconda >> or Abrt. > > Firefox does something similar for signing new instances of Firefox > into your account for syncing. I've also seen it on a couple other > things but can't quite put my finger on what at the moment. > > The other way we handle something like this is for FAS authentication; > if you try and use e.g. the Bodhi CLI client without being logged in, > it will print a browser URL and try to open a browser at that URL > automatically, you log in through the browser and a key/token is made > available to the app to store for future non-interactive logins. For Bodhi Kerberos seems like a more elegant solution tbh. > But really, the problem here is not so much "let's come up with an > elegant design" as "um it seems like things are going to break > catastrophically in 19 days, we need to do something really quite > urgently to make that not happen". Why does all authentication need to go through a browser? 2FA requirements? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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: Fedora 36 Mass Branching
On Wed, Feb 09, 2022 at 05:12:16PM +, Jonathan Wakely wrote: > On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka wrote: > > > > Hi All, > > > > Fedora 36 has now been branched, please be sure to do a git pull > > --rebase to pick up the new branch This part also doesn't make sense… You can do 'git fetch' to learn about the new branch. There is nothing to pull (no new commits), and nothing to rebase, since none of existing branches are affected. Zbyszek ___ 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
Schedule for Thursday's FPC Meeting (2022-02-10 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at 2022-02-10 17:00 UTC in #fedora-meeting-1 on irc.libera.chat. Local time information (via. uitime): = Day: Thursday == 2022-02-10 09:00 PST US/Pacific 2022-02-10 12:00 EST --> US/Eastern <-- 2022-02-10 17:00 GMT Europe/London 2022-02-10 17:00 UTC UTC 2022-02-10 18:00 CET Europe/Berlin 2022-02-10 18:00 CET Europe/Paris 2022-02-10 22:30 IST Asia/Calcutta New Day: Friday - 2022-02-11 01:00 HKT Asia/Hong_Kong 2022-02-11 01:00 +08 Asia/Singapore 2022-02-11 02:00 JST Asia/Tokyo 2022-02-11 03:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followup Actions = #topic #pr-814 * mhroncok talk to authors again, having a working example might help a lot = Followup Issues = #topic #886 Enable BRP for detecting RPATH .fpc 886 https://pagure.io/packaging-committee/issue/886 #topic #907 Which %__foo macros for executables are acceptable? .fpc 907 https://pagure.io/packaging-committee/issue/907 #topic #1058 How to handle %lang files in package owned directories? .fpc 1058 https://pagure.io/packaging-committee/issue/1058 #topic #1132 Mark comments as scriplets for Sources (automation) .fpc 1132 https://pagure.io/packaging-committee/issue/1132 #topic #1150 request for clarification wrt. base version / compat package naming .fpc 1150 https://pagure.io/packaging-committee/issue/1150 #topic #1159 Ban use of %configure in %prep .fpc 1159 https://pagure.io/packaging-committee/issue/1159 = Followup Pull Requests = #topic #pr-814 Add SELinux Independent Policy Guidelines. https://pagure.io/packaging-committee/pull-request/814 #topic #pr-1045 WIP: Add discussion of macro names beginning with underscores. https://pagure.io/packaging-committee/pull-request/1045 #topic #pr-1046 Improve separate test suite sourcing instructions https://pagure.io/packaging-committee/pull-request/1046 #topic #pr-1071 Overhaul the RPATH section of the guidelines. https://pagure.io/packaging-committee/pull-request/1071 #topic #pr-1097 Use caret in Obsoletes to simplify https://pagure.io/packaging-committee/pull-request/1097 #topic #pr-1144 Weak deps. on subpkgs. MUST NOT be fully versioned https://pagure.io/packaging-committee/pull-request/1144 #topic #pr-1157 Drop redundant Source and Patch numbers https://pagure.io/packaging-committee/pull-request/1157 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ 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: GCC changes break "libscrypt" package in F36
Thank you, all variants work fine. Now I have another issue with "nfdump" package, probably for the same reason: a build flag interference. I use '-fPIC' in LDFLAGS to make "configure" happy: https://src.fedoraproject.org/rpms/nfdump/blob/rawhide/f/nfdump.spec#_49 I suspect that this flag presence affects the package build, or maybe it's related to other changes. It worked for F35 and earlier, and still works with simple "./configure && make" (without RPM build flags). ... libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -c ipconv.c -fPIC -DPIC -o .libs/ipconv.o /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -c -o exporter.lo exporter.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -ggdb -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -c exporter.c -fPIC -DPIC -o .libs/exporter.o /bin/sh ../libtool --tag=CC --mode=link gcc -ggdb -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -release 1.6.23 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld -fPIC -o libnfdump.la -rpath /usr/lib64 output_util.lo output_raw.lo output_json.lo output_csv.lo output_pipe.lo output_fmt.lo util.lo minilzo.lo lz4.lo nffile.lo nfx.lo flist.lo fts_compat.lo grammar.lo scanner.lo nftree.lo ipconv.lo exporter.lo -lresolv -lbz2 libtool: link: gcc -shared -fPIC -DPIC .libs/output_util.o .libs/output_raw.o .libs/output_json.o .libs/output_csv.o .libs/output_pipe.o .libs/output_fmt.o .libs/util.o .libs/minilzo.o .libs/lz4.o .libs/nffile.o .libs/nfx.o .libs/flist.o .libs/fts_compat.o .libs/grammar.o .libs/scanner.o .libs/nftree.o .libs/ipconv.o .libs/exporter.o -lresolv -lbz2 -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -ggdb -g -O3 -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT -Wl,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld -Wl,-soname -Wl,libnfdump-1.6.23.so -o .libs/libnfdump-1.6.23.so libtool: link: (cd ".libs" && rm -f "libnfdump.so" && ln -s " libnfdump-1.6.23.so" "libnfdump.so") libtool: link: ( cd ".libs" && rm -f "libnfdump.la" && ln -s "../ libnfdump.la" "libnfdump.la" ) /bin/sh ../libtool --tag=CC --mode=link gcc -DPCAP -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld -fPIC -o nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o nfcapd-bookkeeper.o nfcapd-expire.o nfcapd-pcap_reader.o libnfdump.la -lpcap -lresolv -lbz2 libtool: link: gcc -DPCAP -g -O3 -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -fno-strict-aliasing -DNSEL -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -Wl,-dT -Wl,/home/mock/rpmbuild/BUILD/nfdump-1.6.23/.package_note-nfdump-1.6.23-3.fc36.x86_64.ld -fPIC -o .libs/nfcapd nfcapd-nfcapd.o nfcapd-nfstatfile.o nfcapd-launch.o nfcapd-nfnet.o nfcapd-collector.o nfcapd-netflow_v1.o nfcapd-netflow_v5_v7.o nfcapd-netflow_v9.o nfcapd-ipfix.o nfcapd-bookkeeper.o nfcapd-expire.o nfcapd-pcap_reader.o ./.libs/libnfdump.so -lpcap -lresolv -lbz2 /usr/bin/ld: nfcapd-nfcapd.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: nfcapd-nfstatfile.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: nfcapd-launch.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: nfcapd-nfnet.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: nfcapd-collector.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: nfcapd-
Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
På Wed, 9 Feb 2022 05:59:03 -0500 Neal Gompa skrev: > On Wed, Feb 9, 2022 at 5:24 AM Jonathan Wakely > wrote: > > Last time I tried, I couldn't use Synergy and Wayland together, so I > > use X11 sessions with KDE still. Will this change only affect the > > pre-login greeter screen, or does it also affect the lock screen > > when a running X11 session is locked (either explicitly or after the > > timeout)? Currently I can still use the mouse and keyboard from a > > different machine to unlock that lock screen. If it starts using > > Wayland that won't work. It might be worth mentioning that for the > > user experience for other Synergy users. > > SDDM only affects pre-login, just like GDM for GNOME. If you select > X11 at login, the lock screen will also use X11. So when using Synergy on login screen - that will stop working for me with this change ? Is there an easy way to set it back to X11 ? Allan. ___ 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 36 compose report: 20220209.n.0 changes
___ 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: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
On Wed, Feb 9, 2022 at 5:46 PM allan2016--- via devel wrote: > > På Wed, 9 Feb 2022 05:59:03 -0500 > Neal Gompa skrev: > > On Wed, Feb 9, 2022 at 5:24 AM Jonathan Wakely > > wrote: > > > Last time I tried, I couldn't use Synergy and Wayland together, so I > > > use X11 sessions with KDE still. Will this change only affect the > > > pre-login greeter screen, or does it also affect the lock screen > > > when a running X11 session is locked (either explicitly or after the > > > timeout)? Currently I can still use the mouse and keyboard from a > > > different machine to unlock that lock screen. If it starts using > > > Wayland that won't work. It might be worth mentioning that for the > > > user experience for other Synergy users. > > > > SDDM only affects pre-login, just like GDM for GNOME. If you select > > X11 at login, the lock screen will also use X11. > > So when using Synergy on login screen - that will stop working for me > with this change ? > Is there an easy way to set it back to X11 ? > Yes. A user can revert using the steps documented in the Change document. https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM#Upgrade.2Fcompatibility_impact -- 真実はいつも一つ！/ 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: Fedora 36 compose report: 20220209.n.0 changes
On Wed, Feb 09, 2022 at 11:02:38PM +, Fedora Rawhide Report wrote: > I guess this doesn't handle the case of the first branched compose of a cycle right. ;) Anyhow, here is the report against the last rawhide compose. OLD: Fedora-Rawhide-20220208.n.0 NEW: Fedora-36-20220209.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 108 Downgraded packages: 0 Size of added packages: 33.07 MiB Size of dropped packages:0 B Size of upgraded packages: 5.39 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -15.98 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: golang-github-grpc-ecosystem-gateway-2-2.7.3-1.fc36 Summary: GRPC to JSON proxy generator following the gRPC HTTP spec RPMs:golang-github-grpc-ecosystem-gateway-2 golang-github-grpc-ecosystem-gateway-2-devel Size:17.93 MiB Package: golang-github-hhrutter-lzw-0-0.1.20220208git6f07a24.fc36 Summary: An extended version of compress/lzw RPMs:golang-github-hhrutter-lzw-devel Size:16.02 KiB Package: golang-github-hhrutter-tiff-0-0.1.20220208git736cae8.fc36 Summary: An extended version of x/image/tiff RPMs:golang-github-hhrutter-tiff-devel Size:24.64 KiB Package: golang-github-pdfcpu-0.3.13-1.fc36 Summary: A PDF processor written in Go RPMs:golang-github-pdfcpu golang-github-pdfcpu-devel Size:14.58 MiB Package: grc-1.13-1.fc36 Summary: Generic Colorizer RPMs:grc Size:55.34 KiB Package: kmscube-0-1.20210207.git9f63f35.fc36 Summary: Example KMS/GBM/EGL application RPMs:kmscube Size:485.09 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: Coin3-3.1.3-31.fc36 Old package: Coin3-3.1.3-30.fc36 Summary: High-level 3D visualization library RPMs: Coin3 Coin3-devel Size: 47.77 MiB Size change: 3.15 KiB Changelog: * Tue Feb 08 2022 Zbigniew Jędrzejewski-Szmek - 3.1.3-31 - Drop ldflags from Libs line in pkgconf file (avoids issues with https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects) Package: CubicSDR-0.2.7-2.fc36 Old package: CubicSDR-0.2.7-1.fc36 Summary: Cross-Platform Software-Defined Radio Panadapter RPMs: CubicSDR Size: 5.48 MiB Size change: -142 B Changelog: * Mon Feb 07 2022 Matt Domsch - 0.2.7-2 - rebuild for liquid-dsp rebuild Package: PyYAML-6.0-3.fc36 Old package: PyYAML-6.0-2.fc36 Summary: YAML parser and emitter for Python RPMs: python3-pyyaml Size: 931.69 KiB Size change: -92 B Changelog: * Tue Feb 08 2022 Miro Hrončok - 6.0-3 - Remove some outdated Obsoletes and Provides, but keep providing python3-yaml and python3-PyYAML for users Package: SDL2-2.0.20-3.fc36 Old package: SDL2-2.0.20-2.fc36 Summary: Cross-platform multimedia library RPMs: SDL2 SDL2-devel SDL2-static Size: 11.10 MiB Size change: 5.16 KiB Changelog: * Tue Feb 08 2022 Neal Gompa - 2.0.20-3 - Backport Wayland and PipeWire fixes from upstream Package: awscli-1.22.50-1.fc36 Old package: awscli-1.22.49-1.fc36 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 2.16 MiB Size change: -71 B Changelog: * Tue Feb 08 2022 Gwyn Ciesla - 1.22.50-1 - 1.22.50 Package: axel-2.17.11-1.fc36 Old package: axel-2.17.10-4.fc36 Summary: Light command line download accelerator for Linux and Unix RPMs: axel Size: 410.15 KiB Size change: 3.99 KiB Changelog: * Tue Feb 08 2022 Ankur Sinha (Ankur Sinha Gmail) 2.17.11-1 - feat: update to 2.17.11 (fixes rhbz#2034429) Package: azure-cli-2.33.0-1.fc36 Old package: azure-cli-2.32.0-7.fc36 Summary: Microsoft Azure Command-Line Tools RPMs: azure-cli python3-azure-cli-core python3-azure-cli-telemetry python3-azure-cli-testsdk Size: 3.87 MiB Size change: 8.44 KiB Changelog: * Tue Feb 08 2022 Major Hayden 2.33.0-1 - Update to 2.33.0 Package: brazil-2.3-29.fc36 Old package: brazil-2.3-28.fc36 Summary: Extremely small footprint Java HTTP stack RPMs: brazil brazil-demo brazil-javadoc Size: 1000.52 KiB Size change: -150.34 KiB Changelog: * Sat Feb 05 2022 Jiri Vanek - 2.3-29 - Rebuilt for java-17-openjdk as system jdk - commented about "our own, better script - it is not better, pls fix upstream pom.xm" - added patch jdk17.patch - preffixed keyword yeald and bumped source/target - https://github.com/mbooth101/brazil/pull/1 Package: chordpro-5.987-1.fc36 Old package: chordpro-5.986-1.fc36 Summary: Print songbooks (lyrics + chords) RPMs: chordpro chordpro-abc chordpro-gui chordpro-lilypond Size: 986.51 KiB Size change: -153 B Changelog: * Tue Feb 08 2022 Johan Vromans - 5.987-1 - Upgrade to upstream. Package:
Re: Do we have any policy for disabling inactive users
On Wed, Feb 9, 2022 at 5:05 PM Mattia Verga via devel wrote: > That is referring to provenpackagers only. I'd like this to be extended > to users in packagers group also. FWIW, the last time this came up, there was a vague idea to require a yearly resigning of the CLA (or something equivalent, but the CLA signing was already in there). However, no one made a formal proposal to (I think) FESCo to approve such a new process. Perhaps you should start that process with a formal (proposed) process to FESCo. The provenpackager process might provide a reasonable starting point for proposed changes to policy; https://pagure.io/fesco/issue/2549 I will note that (as previously documented) there was a proposal over 10 years ago: https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal So, please, make a formal FESCo proposal. That is the way to get things moving forward. ___ 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: Unannounced .so version bump: glew
On 2/9/22 10:09, Ben Beasley wrote: It looks like the recent update to glew 2.2.0[1] in F36 and F37 contained an undetected/unannounced .so version change. This is breaking vtk[2] and presumably a lot of other things. I suggest updating the globs in the %files list[3] to keep this from happening in the future. Sorry about that. It's been a while since I touched glew and (almose) all of the packages I normally maintain already have the sover is the glob that I forgot to check. Kicking off rebuilds of dependencies now... -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)
How will multi-monitor users be able to configure the display arrangement for SDDM now? Currently on my desktop SDDM defaults to an incorrect arrangement and I have /etc/sddm/Xsetup call xrandr to correct it. With SDDM using wayland by default will users just be expected to deal with random monitor arrangements during the login experience? ___ 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: [Bugzilla-announce-list] Action Required: Bugzilla - API Authentication changes
Jeff Fearn replied to my email, but he only copied the internal bugzilla-list, because he wanted to include security details and didn't feel comfortable doing that on a public list. I've selected the most important parts of his replies and deleted the rest. Please see his responses below: On Wed, Feb 9, 2022 at 1:37 PM Jeff Fearn wrote: > On 9/2/2022 20:33, Kamil Paral wrote: > > initially I (and not just me) read the email as "update to the latest > > python-bugzilla and you'll be fine". But after I played with > > bugzilla.stage, and read the announcement more carefully, it seems that > the > > only possible authentication method is now using the bugzilla api key, > i.e. > > using the username + password login is no longer possible (for API > access). > > Is that correct? > > Yes this is correct. > > > I do have several concerns regarding that. The change seems too sudden > and > > a lot of Fedora tooling interacts with bugzilla. > > This has been discussed for some time on the internal bugzilla-list. > > [snip] > > > So, basically two questions: > > 1. Why are we given so little time to react? Can this change wait at > least > > until F36 is released (around the end of April), so that the Anaconda and > > ABRT teams (as well as others) can incorporate the changes > > The time line was based on the feedback we got on bugzilla-list. > Technically it's a pretty easy change and no one raised these kinds of > issues. > > People with blockers should send a mail to bugzilla-list, or open a > ticket, with all the gory details, and we can mash it out. > > The list is better IMO because there are people from other teams who can > contribute to the discussion. > > > 2. Is there a good enough justification for completely banning > > username+password authentication? Because this will have a strong impact > on > > Fedora quality by reducing the amount of crash reports which we receive, > I > > can't imagine it any other way. > > This change is driven by security of credentials > [snip] > Based on Jeff's responses, I'd encourage teams, which own a high-impact application/tooling affected by this change and can't react quickly enough, to post into the internal bugzilla-list and discuss this issue. The deadline could be possibly extended if there are good reasons for it, it seems. Teams without access to the internal bugzilla-list can open a bugzilla ticket (against the Bugzilla product) or contact Jeff directly, I assume. ___ 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
