FAS email for authentication
by Christopher
Why does FAS use the email forwarding address when I use it to
authenticate, rather than the permanent @fedoraproject.org alias for
the address?
I should be able to change my forwarding address without changing how
authentication works. However, it looks like if I change my forwarding
address, then try to use FAS to log in to Bugzilla, it would tell me
that there is no account for <forwarding address> and asks if I want
to register. This currently happens when I try to log in with FAS,
because I registered my bugzilla account using my
ctubbsii(a)fedoraproject.org alias instead. Obviously, I don't want to
create a new account if I change my forwarding address. I can't
imagine ever wanting to authenticate using my forwarding address,
rather than my Fedora alias for accessing Fedora systems, because my
forwarding address is subject to change.
Every FAS account has a corresponding @fedoraproject.org email alias.
So, why doesn't FAS use that? In my opinion, it should, and to make it
clear, the Fedora Accounts profile page should be changed to have a
grayed out field for Email that shows your @fedoraproject.org email
alias, in addition to the Email field that you can edit to update your
registered/forwarding address.
Also, why doesn't the FAS OAuth login redirect page show the password
and 2FA fields separately, like on the Fedora Accounts
(accounts.fedoraproject.org) page? It would be much nicer on password
managers, which are easily confused into thinking you've changed your
password every time you manually append the 2FA code to the password.
2 years, 11 months
License field is now “effective license” in agenda, appeditor, gaupol, harmonyseq, libinstpatch, notejot, sequeler
by Benjamin Beasley
I’ve updated several of my packages to use only the “effective license” in their License fields, in cases where it was very clear that a single effective license was correct. The following packages are affected:
- agenda: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
- appeditor: “GPLv3 and LGPLv2+ and CC0” becomes “GPLv3”
- gaupol: “GPLv3+ and CC0” becomes “GPLv3+”
- harmonyseq: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- libinstpatch: “LGPLv2 and Public Domain” becomes “LGPLv2”
- notejot: “GPLv3+ and GPLv2+ and CC0” becomes “GPLv3+”
- sequeler: “GPLv3+ and GPLv2+ and LGPLv2+ and CC0” becomes “GPLv3+”
2 years, 11 months
pyproject-rpm-macros can now install Python BuildRequires from
requirements files
by Tomas Hrnciar
Hello,
a new version of pyproject-rpm-macros (0-43) landed in Rawhide. I'll try to
briefly summarize what is new.
%pyproject_buildrequires macro can now optionally take file names as
positional arguments and generate additional build dependencies from them.
You can supply multiple file names to %pyproject_buildrequires macro. E.g.:
%generate_buildrequires
%pyproject_buildrequires requirements/tests.in requirements/docs.in
This adds the requirements listed in the files as python3dist(...)
BuildRequires. Other usages of %pyproject_buildrequires remains the same as
before.
In case you want to use this feature without using the Python build system
(PEP517/setup.py) you can use a new -N (i.e. "No build system") option to
only install the dependencies from the provided files. With -N, any other
automatic generation of requirements is entirely disabled. -N option cannot
be used in combination with other %pyproject_buildrequires options (-r, -e,
-t, -x). In order to use the -N option, you need to have
pyproject-rpm-macros >= 0-43 installed on your developer machine as well
(or no version of that package at all).
Updates are ready for Fedora 33 and 34:
F34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-5476e05676
F33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-cc2936539e
Backport for CentOS Stream 9 can be found here:
https://gitlab.com/redhat/centos-stream/rpms/pyproject-rpm-macros/-/merge...
Regards,
Tomáš Hrnčiar
2 years, 11 months
Bochecha unavailable for a little while
by Pierre-Yves Chibon
Good Morning Everyone,
I am in contact with bochecha who has asked me that I announce his
un-availability for personal reason for a little while.
To this end, he has orphaned the package "buildstream" on Wednesday. There may
be more coming.
Bochecha still wants to come back to Fedora once things have settled down but he
didn't want for anything to wait on him while he is not available.
Pierre
2 years, 11 months
libavif soname bump
by Robert-André Mauchin
Hello everyone,
I'm planning a soname bump from 11 to 12 in libavif for version 0.9.2.
The affected packages are:
darktable-3.4.1-3.fc35.x86_64 libavif.so.11()(64bit)
gd-2.3.2-5.fc35.x86_64 libavif.so.11()(64bit)
kf5-kimageformats-5.83.0-1.fc35.x86_64 libavif.so.11()(64bit)
I will rebuild them using my PP.
If anyone has a question regarding this, feel free to leave any input.
Best regards,
Robert-André
2 years, 11 months