Incomprehensible rpmlint error messages

[Stephan Bergmann]

Trying to review  
"Review Request: zxing-cpp - C++ version of ZXing ("Zebra Crossing") 
barcode scanning library" on Fedora 35, `fedora-review -b 2029219` 
produces a 2029219-zxing-cpp/review.txt that states



Rpmlint
---
Cannot parse rpmlint output:


(with no further information), and a manual `rpmlint 
2029219-zxing-cpp/results/zxing-cpp-1.2.0-1.fc36.x86_64.rpm` fails with



== rpmlint session starts 
==
rpmlint: 2.1.0
configuration:
/usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/licenses.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1

zxing-cpp.x86_64: E: shlib-policy-name-error 1
zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
libZXing.so.1.2.0
=== 1 packages and 0 specfiles checked; 2 errors, 0 warnings, 2 
badness; has taken 2.5 s ===


and I don't understand what either the shlib-policy-name-error nor the 
invalid-ldconfig-symlink errors are actually about, and can't find any 
documentation.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2030148] New: perl-PDF-API2-2.043 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2030148

Bug ID: 2030148
   Summary: perl-PDF-API2-2.043 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDF-API2
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.043
Current version/release in rawhide: 2.042-1.fc36
URL: http://search.cpan.org/dist/PDF-API2/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3202/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2030148
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Björn Persson  said:
> Chris Adams wrote:
> > If the admin has done one thing to lock down the system, then they can
> > do another (removing the sulogin --force addition).
> 
> How do you propose to ensure that the admin is made aware of the need
> to do that?

The same way as any change - documentation.

> Experienced sysadmins won't just instinctively know that in this new
> release of this particular distribution they need to run this special
> command to prevent boot problems from granting root access to whoever
> can type on the keyboard.

It's not a "special command", it's just removing an RPM that has the
sulogin overrides, or just set a root password (this change only affects
the case of a locked root account).  Experienced sysadmins should
already know that the OS changes from release to release.  I don't
install a brand new OS and give it to users without checking it out
myself (and reading at least the release notes).

This is NOT some new "hole" - out of the box, Fedora already allows
someone with console access to get root access (in less convenient, but
more confusing, ways).  As noted in the change proposal, this change is
already in Fedora CoreOS.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2029201] perl-Net-Amazon-S3-0.99 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029201

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-942138a7e7 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-942138a7e7`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-942138a7e7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029201
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2029516] Please branch and build perl-Any-URI-Escape in epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029516

Troy Dawson  changed:

   What|Removed |Added

Version|epel8   |epel9




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029516
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2028912] Please branch and build perl-Linux-Inotify2 in epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2028912

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2021-98d7654945 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-98d7654945

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028912
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d5e825b208   
isync-1.3.6-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

freetds-1.3.3-1.el7
libmysofa-1.2.1-1.el7
rpminspect-data-fedora-1.7-1.el7

Details about builds:



 freetds-1.3.3-1.el7 (FEDORA-EPEL-2021-0cd46dc751)
 Implementation of the TDS (Tabular DataStream) protocol

Update Information:

Update to 1.3.3

ChangeLog:

* Wed Dec  8 2021 Dmitry Butskoy  - 1.3.3-1
- update to 1.3.3




 libmysofa-1.2.1-1.el7 (FEDORA-EPEL-2021-bc5821ce86)
 C functions for reading HRTFs

Update Information:

various smaller security bug fixes

ChangeLog:

* Mon Dec  6 2021 Nicolas Chauvet  - 1.2.1-1
- Update to 1.2.1
* Thu Jul 22 2021 Fedora Release Engineering  - 1.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #1935083 - CVE-2020-6860 libmysofa: stack-based buffer overflow in 
readDataVar in hdf/dataobject.c [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1935083
  [ 2 ] Bug #2019194 - CVE-2021-3756 libmysofa: heap-based buffer overflow in 
loudness(), mysofa_check() and readOHDRHeaderMessageDataLayout() [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2019194
  [ 3 ] Bug #2019195 - CVE-2021-3756 libmysofa: heap-based buffer overflow in 
loudness(), mysofa_check() and readOHDRHeaderMessageDataLayout() [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2019195




 rpminspect-data-fedora-1.7-1.el7 (FEDORA-EPEL-2021-57e50b8620)
 Build deviation compliance tool data files

Update Information:

Upgrade to rpminspect-data-fedora-1.7

ChangeLog:

* Tue Dec  7 2021 David Cantrell  - 1.7-1
- Upgrade to rpminspect-data-fedora-1.7


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b43e85f297   
isync-1.4.4-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-cb6918af8b   
python-markdown2-2.4.2-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

fira-code-fonts-6.2-1.el8
freetds-1.3.3-1.el8
holland-1.2.9-2.el8
libmysofa-1.2.1-1.el8
libolm-3.2.7-1.el8
python-pytelegrambotapi-4.2.1-1.el8
redir-3.3-3.el8
rpminspect-data-fedora-1.7-1.el8
systemd-extras-249.7-1.el8
zswap-cli-0.6.0-1.el8

Details about builds:



 fira-code-fonts-6.2-1.el8 (FEDORA-EPEL-2021-5f9ded8d8e)
 Monospaced font with programming ligatures

Update Information:

Update to 6.2    Update to 6.1

ChangeLog:

* Tue Dec  7 2021 Michael Kuhn  - 6.2-1
- Update to 6.2
* Fri Dec  3 2021 Michael Kuhn  - 6.1-1
- Update to 6.1
* Mon Nov 29 2021 Michael Kuhn  - 6-1
- Update to 6
* Wed Jul 21 2021 Fedora Release Engineering  - 5.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #2027533 - fira-code-fonts-6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2027533
  [ 2 ] Bug #2029053 - fira-code-fonts-6.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2029053




 freetds-1.3.3-1.el8 (FEDORA-EPEL-2021-bb332405d6)
 Implementation of the TDS (Tabular DataStream) protocol

Update Information:

Update to 1.3.3

ChangeLog:

* Wed Dec  8 2021 Dmitry Butskoy  - 1.3.3-1
- update to 1.3.3




 holland-1.2.9-2.el8 (FEDORA-EPEL-2021-7710ef3501)
 Pluggable Backup Framework

Update Information:

Added pg_basebackup from PRs #9 & #10    Latest upstream release.

ChangeLog:

* Tue Dec  7 2021 Sam P  - 1.2.9-2
- Incorporated soulen's changes from #10. Fixed Changelog formatting.
* Fri Dec  3 2021 Sam P  - 1.2.9-1
- Latest upstream release.




 libmysofa-1.2.1-1.el8 (FEDORA-EPEL-2021-7525891ee4)
 C functions for reading HRTFs

Update Information:

various smaller security bug fixes

ChangeLog:

* Mon Dec  6 2021 Nicolas Chauvet  - 1.2.1-1
- Update to 1.2.1
* Thu Jul 22 2021 Fedora Release Engineering  - 1.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #1935083 - CVE-2020-6860 libmysofa: stack-based buffer overflow in 
readDataVar in hdf/dataobject.c [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1935083
  [ 2 ] Bug #2019194 - CVE-2021-3756 libmysofa: heap-based buffer overflow in 
loudness(), mysofa_check() and readOHDRHeaderMessageDataLayout() [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2019194
  [ 3 ] Bug #2019195 - CVE-2021-3756 libmysofa: heap-based buffer overflow in 
loudness(), mysofa_check() and readOHDRHeaderMessageDataLayout() [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2019195




 libolm-3.2.7-1.el8 (FEDORA-EPEL-2021-e896294dd4)
 Double Ratchet cryptographic library

Update Information:

Updated to version 3.2.7.

ChangeLog:

* Tue Dec  7 2021 Vitaly Zaitsev  - 3.2.7-1
- Updated to version 3.2.7.




 

Re: How to handle ABI breakage in Rawhide

[Florian Weimer]

* Robert Relyea:

> On 12/6/21 7:11 PM, Kevin Kofler via devel wrote:
>> Florian Weimer wrote:
>>> That's not actually true, though, and it does not make much sense.  If
>>> upstream commits to an ABI, versioning is not even required technically.
>> Hardly any upstream actually commits to an ABI *forever*. Even if the ABI
>> has not changed for 10 years, that does not mean that at some point a new
>> ABI will not be implemented. Even glibc has a soversion (which has not
>> changed for years, but it has one).
>
> Upstream NSS commits to changing the major version number (which is
> included in the library name) if it were to change the ABI. ABI breaks 
> are fixed upstream when they occur, and there is a CI abi scanner
> which runs on all upstream commits to identify ABI issue. The current
> ABI has been stable for 2 decades now.
>
> I don't know of any other package that maintains that level of
> commitment.

There were/are issues around the size of global data:

  using the external array SSL_ImplementedCiphers[] directly should be
  deprecated
  

  Add accessor functions for SSL_ImplementedCiphers
  

ELF targets with copy relocations do not allow shared objects to change
the size of exported symbols.

(I have a build of GCC 2.7.2.3 from December 1998 that still works, but
to some degree that's easier: it's just turning one text file into
another.  Admittedly I had to fix a glibc regression likely probably
before 2000 to get them working again.)

But my point is that the rule about soname versioning seems overly
strict.  Downstream-specific sonames are very poor substitute for
upstream ABI management.

Thanks,
Florian
___
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: How to handle ABI breakage in Rawhide

[Robert Relyea]

On 12/6/21 7:11 PM, Kevin Kofler via devel wrote:

Florian Weimer wrote:

That's not actually true, though, and it does not make much sense.  If
upstream commits to an ABI, versioning is not even required technically.

Hardly any upstream actually commits to an ABI *forever*. Even if the ABI
has not changed for 10 years, that does not mean that at some point a new
ABI will not be implemented. Even glibc has a soversion (which has not
changed for years, but it has one).


Upstream NSS commits to changing the major version number (which is 
included in the library name) if it were to change the ABI. ABI breaks 
are fixed upstream when they occur, and there is a CI abi scanner which 
runs on all upstream commits to identify ABI issue. The current ABI has 
been stable for 2 decades now.


I don't know of any other package that maintains that level of commitment.

bob



 Kevin Kofler
___
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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[przemek klosowski via devel]

On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:


  If available, use
the TPM2 to additionally tie the password to local hardware. If the
user is removed, also remove that password from that storage.

During boot, if it is necessary to authenticate before the root file
system has been mounted, allow admin users to log in using the credentials
that were stored previously.

Is this being worked on? Do you have any references?

Latest systemd versions have been getting some support for the low-level
parts, i.e. the low-level encrypted-secret storage. But we're missing the
upper parts, i.e. how to actually use and update the passwords. I didn't
even mention this, because we don't have a comprehensive story yet.


A scenario that wasn't mentioned here yet is using a disk from a failed 
system: either moving it to another system, or even simply accessing the 
data. If the credentials (including the LUKS encryption key/password) 
are protected by TPM2, it may effectively prevent any further access. It 
would be useful if any such new scheme avoided that.


In enterprise system, there usually is a backup decryption key, 
accessible to the enterprise admins. I am not sure what would be 
appropriate for single-user systems: some sort of install-time rescue 
passphrase [1] perhaps, that the user would write down and safely store [2]?


[1] https://xkcd.com/936/

[2] conveniently stored next to the rubber hose so that the attackers 
could forgo its use and type the rescue passphrase themselves. 
https://xkcd.com/538/
___
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: openQA tests in Pull Requests?

[Dan Čermák]

Hi,

Adam Williamson  writes:

> On Tue, 2021-12-07 at 13:21 +0100, Miro Hrončok wrote:
>> Hello QA,
>> 
>> is there a way (even a hacky one) to run openQA tests (the ones that run on 
>> Bodhi updates of critpath packages) on an open Pull Request?
>
> Hey Miro! Right now there really isn't, I'm afraid. The least official
> thing we can run the tests for right now is a scratch build, so you
> need to at least turn the PR into a scratch build somehow.
>
> There's no public/self-serve way to schedule for a scratch build at the
> moment; someone with admin/moderator access (so, usually, me) needs to
> do it for you.
>
> If there is substantial interest I could look at implementing something
> here...I would expect that some system or other (CI? Koschei?) must
> surely have a way of turning pull requests into package builds already,
> so I'd want to find that and build on it rather than reinventing it if
> possible.
>
> The other stumbling block is that we still don't run these tests on
> Rawhide, so if you want to test the PR in the context of the
> rawhide/main branch, it would be more difficult (even just doing a one-
> off, because the tests use pre-rolled disk images as a base, and we
> don't build several of the needed images for Rawhide currently).
>
> That's something that could change, but it would be a fairly major
> thing and might possibly require me to beg infra for more hardware or
> finally find the time to see if we can run openQA tests In The Cloud. I
> can provide more details on that whole area if you're interested...

So, opensuse and suse do the following for the released distributions
(e.g. opensuse Leap):
each update gets put into a staging area in the build service, which
rebuilds a subset of the distribution, creates the installation images
and publishes repositories from the staging area. Then openqa is
triggered for the staging area and a bot reports back.

This is not exactly a test on a pull request though, because the actual
pull request equivalent happens in a different place. It is more
equivalent to testing a bodhi update or a side tag.

What I could imagine would be the following: some CI (e.g. Zuul) builds
an image from the pull request and publishes that image somewhere
publicly accessible. Then Zuul would trigger an openqa job and set
ISO_1_URL or HDD_1_URL to the published image, openqa then pulls these
and runs all tests. It would however require that no repositories are
accessed during the tests. And we'd also need some bot to report back an
pagure, but that shouldn't be impossible either, as openqa publishes all
test results via mqtt.

And yes, that will require more hardware to run so many tests.


Hope this helps,

Dan

> -- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> qa-devel mailing list -- qa-devel@lists.fedoraproject.org
> To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Adding python3.10dist(pp) to python-ppft

[Ankur Sinha]

Hi folks,

I was looking to unretire the unmaintained python-pp because some neuro
packages still use it but then was reminded by @music that we already
provide python-ppft which is a maintained fork and drop-in replacement
for pp.

https://github.com/uqfoundation/ppft

Currently python3-ppft provides these:

$ rpm -q --provides python3-ppft
python-ppft = 1.6.6.4-2.fc35
python3-ppft = 1.6.6.4-2.fc35
python3.10-ppft = 1.6.6.4-2.fc35
python3.10dist(ppft) = 1.6.6.4
python3dist(ppft) = 1.6.6.4

Can we also provide all these for `pp` so that packages in Fedora that
require pp automatically use ppft?

I tried adding `%py_provides pp` to python3-ppft, and while that does
add a few of these, it does not add the python3.10dist(pp) or
python3dist(pp) ones (which are autogenerated from the metadata?):

$ rpm -q --provides -p 
./results_python-ppft/1.6.6.4/3.fc36/python3-ppft-1.6.6.4-3.fc36.noarch.rpm 
python-pp = 1.6.6.4-3.fc36
python-ppft = 1.6.6.4-3.fc36
python3-pp = 1.6.6.4-3.fc36
python3-ppft = 1.6.6.4-3.fc36
python3.10-pp = 1.6.6.4-3.fc36
python3.10-ppft = 1.6.6.4-3.fc36
python3.10dist(ppft) = 1.6.6.4
python3dist(ppft) = 1.6.6.4

Would there be a way to include these machine readable provides too
since these forms are used by other packages in the automatically
generated requires etc. (if this is the right thing to do)?

I guess the alternative would be that every package that requires pp be
patched to require ppft, but tweaking a single python-ppft package would
be less work. :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unretiring python-pp

[Ankur Sinha]

On Tue, Dec 07, 2021 16:51:22 +, Ankur Sinha wrote:
> Hi everyone,
> 
> I'm unretiring python-pp which was automatically retired after it was
> orphaned. Some neuroscience packages still use it, and it seems to still
> work on Python 3.10 (even though the latest release was a few years
> ago).
> 
> https://src.fedoraproject.org/rpms/python-pp
> 
> Here's the re-review ticket:
> https://bugzilla.redhat.com/show_bug.cgi?id=2029963


Turns out we have a maintained drop-in replacement in Fedora already,
python-ppft (which I maintain but had forgotten about), so we will make
that provide pp instead of un-retiring this unmaintained module.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Björn Persson]

Chris Adams wrote:
> If the admin has done one thing to lock down the system, then they can
> do another (removing the sulogin --force addition).

How do you propose to ensure that the admin is made aware of the need
to do that?

Experienced sysadmins won't just instinctively know that in this new
release of this particular distribution they need to run this special
command to prevent boot problems from granting root access to whoever
can type on the keyboard.

Björn Persson


pgpUpKi2TnP15.pgp
Description: OpenPGP digital signatur
___
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: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 12:03:04PM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > The second case is when the admin has actually
> > locked down the kernel command line and relies on the normal
> > authentication mechanisms to protect the system. In both cases your
> > proposal creates an additional method of attack that activates at a
> > later point where the system is already running and the integrity of
> > the system must be maintained to protect unencrypted data. With the
> > proposal, any mechanism which leads to the system entering emergency
> > mode results in a compromise.
> 
> If the admin has done one thing to lock down the system, then they can
> do another (removing the sulogin --force addition).  Right now, Fedora
> is shipping an inconsistent (and frustrating) state: one part is locked
> down, but another is not (so the first can be bypassed, in an annoying
> way).  Prompting for a root password at rescue/emergency mode is not
> security in the default config and so should not be done (at least when
> no such password is set, as some of the default Fedora configs have).

I agree that prompting for an unset root password is annoying: we
should just say upfront that the login is not possible that way. But I
don't agree that we should punch an new hole just because a different
one exists. The existing shortcomings are well known, and can be worked
around, and are not relevant in all circumstances. The new mechanism
opens the system from a different side. I also don't think we should
assume that the admin will do a series of "hardening steps". This is what
we had in the 90's: you'd install a stock distro and then go over a checklist
of basic steps to make things secure. Let's not go back to that.

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

Re: openQA tests in Pull Requests?

[Miro Hrončok]

On 07. 12. 21 18:21, Adam Williamson wrote:

On Tue, 2021-12-07 at 13:21 +0100, Miro Hrončok wrote:

Hello QA,

is there a way (even a hacky one) to run openQA tests (the ones that run on
Bodhi updates of critpath packages) on an open Pull Request?


Hey Miro! Right now there really isn't, I'm afraid. The least official
thing we can run the tests for right now is a scratch build, so you
need to at least turn the PR into a scratch build somehow.


That we already have. Each pull request has a "Fedora CI - scratch build" job.


There's no public/self-serve way to schedule for a scratch build at the
moment; someone with admin/moderator access (so, usually, me) needs to
do it for you.


Got it. At the moment, I am mostly interested in 
https://src.fedoraproject.org/rpms/python3.10/pull-request/87 but it fails for 
now, will let you know when it is ready.

The reason is to avoid the failure wqe have seen in Fedora 34 recently.


If there is substantial interest I could look at implementing something
here...I would expect that some system or other (CI? Koschei?) must
surely have a way of turning pull requests into package builds already,
so I'd want to find that and build on it rather than reinventing it if
possible.


Yes, this exists. Both in Zuul and as a "Fedora CI" job. How to retrieve that 
job programmatically, I have no idea. But it is there.



The other stumbling block is that we still don't run these tests on
Rawhide, so if you want to test the PR in the context of the
rawhide/main branch, it would be more difficult (even just doing a one-
off, because the tests use pre-rolled disk images as a base, and we
don't build several of the needed images for Rawhide currently).


For now, I am interested in Fedora 34/35. Once the tests run in Bodhi for 
Rawhide, we would want them run in PRs as well. The point is that I don't want 
to merge+build+bodhi an update just to find out it fails the tests -- I want to 
know before I merge the PR.



That's something that could change, but it would be a fairly major
thing and might possibly require me to beg infra for more hardware or
finally find the time to see if we can run openQA tests In The Cloud. I
can provide more details on that whole area if you're interested...


As much as I'd love to see those tests on Rawhide as well, all I ask for here 
is to have it 1:1 Bodhi updates and Pull Requests.



Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20211207.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 6/142 (aarch64), 3/208 (x86_64)

New failures (same test not failed in Fedora-Rawhide-20211206.n.0):

ID: 1079442 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1079442
ID: 1079523 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1079523
ID: 1080002 Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/1080002
ID: 1080003 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/1080003

Old failures (same test failed in Fedora-Rawhide-20211206.n.0):

ID: 1079315 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1079315
ID: 1079361 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1079361
ID: 1079399 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1079399
ID: 1079582 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1079582
ID: 1079587 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1079587

Soft failed openQA tests: 7/208 (x86_64), 2/142 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Rawhide-20211206.n.0):

ID: 1079339 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1079339
ID: 1079340 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1079340
ID: 1079350 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1079350
ID: 1079489 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1079489
ID: 1079538 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1079538
ID: 1079571 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1079571
ID: 1079993 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1079993
ID: 1080051 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1080051
ID: 1080066 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1080066

Passed openQA tests: 198/208 (x86_64), 134/142 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20211206.n.0):

ID: 1079335 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1079335
ID: 1079352 Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1079352
ID: 1079380 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1079380
ID: 1079522 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1079522
ID: 1079533 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1079533

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
1 packages(s) added since previous compose: 
google-noto-sans-gurmukhi-vf-fonts
1 packages(s) removed since previous compose: 
google-noto-sans-gurmukhi-fonts
System load changed from 1.25 to 1.42
Previous test data: https://openqa.fedoraproject.org/tests/1078683#downloads
Current test data: https://openqa.fedoraproject.org/tests/1079307#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 6 MiB to 1 MiB
1 packages(s) added since previous compose: 
google-noto-sans-gurmukhi-vf-fonts
1 packages(s) removed since previous compose: 
google-noto-sans-gurmukhi-fonts
System load changed from 1.28 to 0.64
Average CPU usage changed from 31.01904762 to 17.69523810
Previous test data: https://openqa.fedoraproject.org/tests/1078003#downloads
Current test data: https://openqa.fedoraproject.org/tests/1079309#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run contents changed to 72.13953488% of previous size
Used swap changed from 9 MiB to 10 MiB
System load changed from 1.30 to 0.86
Average CPU usage changed from 31.91428571 to 9.45714286
Previous test data: https://openqa.fedoraproject.org/tests/1078021#downloads
Current test data: https://openqa.fedoraproject.org/tests/1079327#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Mount /run contents changed to 72.13190896% of previous size
1 services(s) added 

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> The second case is when the admin has actually
> locked down the kernel command line and relies on the normal
> authentication mechanisms to protect the system. In both cases your
> proposal creates an additional method of attack that activates at a
> later point where the system is already running and the integrity of
> the system must be maintained to protect unencrypted data. With the
> proposal, any mechanism which leads to the system entering emergency
> mode results in a compromise.

If the admin has done one thing to lock down the system, then they can
do another (removing the sulogin --force addition).  Right now, Fedora
is shipping an inconsistent (and frustrating) state: one part is locked
down, but another is not (so the first can be bypassed, in an annoying
way).  Prompting for a root password at rescue/emergency mode is not
security in the default config and so should not be done (at least when
no such password is set, as some of the default Fedora configs have).

Fedora should ship in a consistent state, and this is the most
straight-forward way of getting there.  Locking down a system beyond the
default requires changing a bunch of things, so I do not see adding this
to that list to be a problem.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: openQA tests in Pull Requests?

[Adam Williamson]

On Tue, 2021-12-07 at 13:21 +0100, Miro Hrončok wrote:
> Hello QA,
> 
> is there a way (even a hacky one) to run openQA tests (the ones that run on 
> Bodhi updates of critpath packages) on an open Pull Request?

Hey Miro! Right now there really isn't, I'm afraid. The least official
thing we can run the tests for right now is a scratch build, so you
need to at least turn the PR into a scratch build somehow.

There's no public/self-serve way to schedule for a scratch build at the
moment; someone with admin/moderator access (so, usually, me) needs to
do it for you.

If there is substantial interest I could look at implementing something
here...I would expect that some system or other (CI? Koschei?) must
surely have a way of turning pull requests into package builds already,
so I'd want to find that and build on it rather than reinventing it if
possible.

The other stumbling block is that we still don't run these tests on
Rawhide, so if you want to test the PR in the context of the
rawhide/main branch, it would be more difficult (even just doing a one-
off, because the tests use pre-rolled disk images as a base, and we
don't build several of the needed images for Rawhide currently).

That's something that could change, but it would be a fairly major
thing and might possibly require me to beg infra for more hardware or
finally find the time to see if we can run openQA tests In The Cloud. I
can provide more details on that whole area if you're interested...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-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 with NVIDIA proprietary Driver (System-Wide Change)

[Vitaly Zaitsev via devel]

On 07/12/2021 15:45, Ben Cotton wrote:

That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.


Crashes with Qt+Wayland and WebKit/Blink/QtWebEngine+Wayland need to be 
fixed first.


https://bugzilla.redhat.com/show_bug.cgi?id=2019367
https://github.com/NVIDIA/egl-wayland/issues/41
https://github.com/mpv-player/mpv/issues/9393

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Tue, Dec 7, 2021 at 11:21 AM Kevin Kofler via devel
 wrote:

> The thing is, the path stripping of %doc path/to/README is a feature. The
> directory path in the sources is not necessarily useful to replicate in the
> installed documentation directory. Removing that path stripping would be an
> incompatible change and make the doc directories of some packages a mess of
> unnecessary subdirectories. If desired, this needs a new syntax that does
> not clash with existing usage.
>
> Kevin Kofler

A binary '__doc_path_stripping' flag, set to "true" by default, might
serve to preserve the paths and avoid overlaps if and as desired. I'd
agree that changing default behavior should be unwelcome.

This path stripping behavior is not mentioned in the RPM
documentation, though people may have become accustomed to it. And
"not necessarily useful" does not mean "never useful", as we are
seeing right now.
___
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

Unretiring python-pp

[Ankur Sinha]

Hi everyone,

I'm unretiring python-pp which was automatically retired after it was
orphaned. Some neuroscience packages still use it, and it seems to still
work on Python 3.10 (even though the latest release was a few years
ago).

https://src.fedoraproject.org/rpms/python-pp

Here's the re-review ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=2029963

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

[EPEL-devel] KDE Plasma Desktop on epel9 plans

[Troy Dawson]

The building of KDE Plasma Desktop is underway.  But it's going to take at
least a month to complete.  Some parts might take a few months.

I'm trying things a little differently this time.

On epel8 and epel8-next I would build all the packages and then do one big
bodhi update (or three at the same time, to keep the size down).  That was
ok, because it didn't take me as long to get everything done.

With this first build of epel9, I am doing a bodhi update each day, with
those packages I was able to build that day.  I'll keep those in
epel-testing until there are enough packages to do at least a minimal KDE
install that brings up a desktop.
Summary: Don't expect the KDE Plasma Desktop in epel9-testing to work for
at least another month, possibly longer.

Note 1 - Biggest problem: python2 in qt5-qtwebengine
RHEL9 has no python2.  qtwebengine is based on chromium which (until
recently) required python2.  The updated chromium which doesn't require
python2 has not been ported to qt5-qtwebengine, or qt6-qtwebengine.

Note 2 - Progress;
87 packages built  out of 380 packages total

Note 3 - Biggest blocker by smallest package: perl-Any-URI-Escape
This small perl package blocks kf5-kdoctools from building.  And many
packages require kf5-kdoctools to create their documentation.  And those
packages block others.
This isn't as scary as qtwebengine. We're working on getting this package
in epel9.  I just thought it funny how one tiny package can block so many
others.


Thank you for your patience.
Troy Dawson
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)

[Julian Sikorski]

Am 07.12.21 um 15:45 schrieb Ben Cotton:

https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA

== Summary ==
Enable Wayland sessions by default in GDM even with the NVIDIA
proprietary driver.

== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]]
* Email: 


== Detailed Description ==
Recent updates in NVIDIA proprietary driver allow Xwayland to benefit
from hardware acceleration and X11 applications can have their
rendering hardware accelerated.

That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.

This proposal is to make Wayland by default with newer versions of the
NVIDIA proprietary driver to remain consistent with other drivers.

GDM already has a set of udev rules which check for the driver and its
version, so this would only require a tweak in the udev rules to make
Wayland session the default with the next version of the NVIDIA driver
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in].

Note that currently Xorg is also preferred in the case of multiple
GPU, this would remain the case with this proposal.

This change is just about changing the default with NVIDIA proprietary
driver on supported configurations, “GNOME on Xorg” still remains an
option, just like with other drivers.


== Benefit to Fedora ==
Fedora has changed to Wayland by default since [[Changes/Login Screen
Over Wayland|Fedora 22]], but the NVIDIA proprietary driver has been
an exception ever since (either because originally Wayland would be
disabled with NVIDIA drivers, or more recently Xorg would be used by
default).

Currently, when first installing Fedora on NVIDIA hardware, users get
Wayland by default with the Open Source "nouveau" driver, with Xorg
being an option in the login screen. If they later decide to enable
the rpmfusion repository and install the NVIDIA proprietary driver,
they get Xorg by default and Wayland as an option.

This change would make the default consistent regardless of the
driver, for single GPU systems.

== Scope ==
* Proposal owners: Tweak the gdm udev rule to enable Wayland with the
NVIDIA proprietary driver above a given version
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in#L7-17]
* Other developers: [[User:Rstrode| Ray Strode]] for reviewing the
changes in the udev rules from GDM
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No


== Upgrade/compatibility impact ==


== How To Test ==
# Requires an NVIDIA GPU supported by the recent NVIDIA proprietary
driver and `nvidia-drm.modeset=1` set in the kernel command line to
enable KMS 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html]
(rpmfusion packages for the NVIDIA driver do that automatically)
# Enable the rpmfusion “nonfree” repository to install the NVIDIA
graphics drivers
[https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/]
# Install the NVIDIA proprietary driver (and the
`xorg-x11-drv-nvidia-power` package for suspend/resume support - see
[https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29#Suspend]
and 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/powermanagement.html]
for more details) from the rpmfusion repository
# Reboot the machine
# Ensure graphical login screen comes up
# Try to log into a "GNOME" session
# Check whether this is a "GNOME on Wayland" session (both `$DISPLAY`
and `$WAYLAND_DISPLAY` are set)
# Log out
# Try to log into a "GNOME on Xorg" session
# Check whether this is a "GNOME on Xorg" session (`$DISPLAY` is set,
`$WAYLAND_DISPLAY` is not set)


== User Experience ==
Users with NVIDIA hardware and NVIDIA proprietary driver installed
will get a Wayland session by default when selecting the "GNOME"
session in the login screen.


== Dependencies ==
This depends on the NVIDIA proprietary driver and its support for Wayland.

Typically, this proposal would change the default in a future version
of the NVIDIA driver which is not released yet.


== Contingency Plan ==
* Contingency mechanism: Revert the default to Xorg for NVIDIA driver
by reverting the changes in the udev rule shipping with GDM
* Contingency deadline: Beta Freeze
* Blocks release? No

== Documentation ==
NVIDIA's own documentation
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/]:

  * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html
  * 
http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland.html
  * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/gbm.html



Night light does not work with NVIDIA running Wayland:
- https://gitlab.gnome.org/GNOME/mutter/-/issues/290
- 
https://forums.developer.nvidia.com/t/gnome-night-light-not-working-under-wayland/193590

Until this is fixed, I do not think 

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2021-12-08 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




Source: https://calendar.fedoraproject.org//meeting/9854/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Kevin Kofler via devel]

Nico Kadel-Garcia wrote:
> It seems that the problem existed as well with earlier versions of
> rpmbuild, say on RHEL 7, but the warning messages about "files listed
> twice" weren't generated. And various slightly differently named
> README.md and LICENSE.md files make it not as obvious as one might
> expect.

The thing is, the path stripping of %doc path/to/README is a feature. The 
directory path in the sources is not necessarily useful to replicate in the 
installed documentation directory. Removing that path stripping would be an 
incompatible change and make the doc directories of some packages a mess of 
unnecessary subdirectories. If desired, this needs a new syntax that does 
not clash with existing usage.

Kevin Kofler
___
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: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 03:41:02PM +0100, Vít Ondruch wrote:
> 
> Dne 07. 12. 21 v 12:26 Zbigniew Jędrzejewski-Szmek napsal(a):
> >On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> >>Fedora defaults to locking the root account, which is needed by
> >>single-user mode. This Change uses `sulogin --force` so the password
> >>request is bypassed under this circumstance.
> >I think this is a terrible idea. The problem is real, but this
> >solution addresses it in the wrong place. Essentially, you are proposing
> >a behaviour of "something is wrong, let's make everything open without
> >authentication", which is good for debugging and development, but not
> >acceptable for a real system.
> 
> 
> I think that while ago, I have already proposed to drop the rescue mode
> altogether, because ATM, it just makes things worse. If I cannot regularly
> boot and I open rescue mode, then I am asked for root password, which is not
> set. That is like adding salt into injury.
> 
> 
> >
> >The correct solution is to enhance login mechanisms so that it is
> >possible to authenticate using existing credentials also in the rescue
> >mode. The fact that this is not possible right now is a bug that needs
> >to be fixed.
> >
> >There are two features (in the sense of bits of technology) which we
> >didn't have in the past and which will most likely should be part of
> >the solution. The first is yescrypt/argon2 hashing for functions: the
> >complexity of brute-forcing such passwords is high enough that a
> >password of sufficient length should be safe even if the hash is
> >exposed (i.e. the passwd/shadow split is not important anymore). This
> >means that we can consider embedding a password somewhere in the initrd
> >or elsewhere in the unencrypted storage.
> >
> >The second is using tpm2 for protection of local secrets: the tpm2
> >can enforce limits on brute-force attacks on the password.
> >
> >So we have some mechanisms to reasonably store a password in boot
> >configuration outside of the encrypted file systems. What we currently
> >don't have is a mechanism to make use of it, and a mechanism to update
> >the password.
> >
> >I would expect a solution along those lines: when initially installing
> >a system using Anaconda and setting the root password, or when 
> >setting/updating
> >the password at some later point
> 
> 
> You have probably meant s/root/user with admin privileges/ ?

I meant both: the root user and all other "admin-type" users.

(I don't think we should allow "normal" users to log in when the
machine is not fully up. They don't have administrative privileges
to fix things anyway. Skipping those users has the advantage that we
avoid exposing potentially weaker passwords (i.e. we can count on the
admin users to know to ensure password strength, but not so for the other
users necessarily), and we avoid frequent access to the storage.)

> >, if the user in question has admin
> >privileges (is root or e.g. is part of the wheel group), propagate the
> >yescrypted password to some accessible-at-boot-time storage. On EFI
> >systems that would most likely be some EFI variable. If available, use
> >the TPM2 to additionally tie the password to local hardware. If the
> >user is removed, also remove that password from that storage.
> >
> >During boot, if it is necessary to authenticate before the root file
> >system has been mounted, allow admin users to log in using the credentials
> >that were stored previously.
> 
> 
> Is this being worked on? Do you have any references?

Latest systemd versions have been getting some support for the low-level
parts, i.e. the low-level encrypted-secret storage. But we're missing the
upper parts, i.e. how to actually use and update the passwords. I didn't
even mention this, because we don't have a comprehensive story yet.
I think it'd be necessary to write some pam module and/or authentication
helper from scratch. It's probably not too much work, but nobody has
signed up to do this.

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

[Bug 2028912] Please branch and build perl-Linux-Inotify2 in epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2028912

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2021-98d7654945 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-98d7654945


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028912
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA

== Summary ==
Enable Wayland sessions by default in GDM even with the NVIDIA
proprietary driver.

== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]]
* Email: 


== Detailed Description ==
Recent updates in NVIDIA proprietary driver allow Xwayland to benefit
from hardware acceleration and X11 applications can have their
rendering hardware accelerated.

That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.

This proposal is to make Wayland by default with newer versions of the
NVIDIA proprietary driver to remain consistent with other drivers.

GDM already has a set of udev rules which check for the driver and its
version, so this would only require a tweak in the udev rules to make
Wayland session the default with the next version of the NVIDIA driver
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in].

Note that currently Xorg is also preferred in the case of multiple
GPU, this would remain the case with this proposal.

This change is just about changing the default with NVIDIA proprietary
driver on supported configurations, “GNOME on Xorg” still remains an
option, just like with other drivers.


== Benefit to Fedora ==
Fedora has changed to Wayland by default since [[Changes/Login Screen
Over Wayland|Fedora 22]], but the NVIDIA proprietary driver has been
an exception ever since (either because originally Wayland would be
disabled with NVIDIA drivers, or more recently Xorg would be used by
default).

Currently, when first installing Fedora on NVIDIA hardware, users get
Wayland by default with the Open Source "nouveau" driver, with Xorg
being an option in the login screen. If they later decide to enable
the rpmfusion repository and install the NVIDIA proprietary driver,
they get Xorg by default and Wayland as an option.

This change would make the default consistent regardless of the
driver, for single GPU systems.

== Scope ==
* Proposal owners: Tweak the gdm udev rule to enable Wayland with the
NVIDIA proprietary driver above a given version
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in#L7-17]
* Other developers: [[User:Rstrode| Ray Strode]] for reviewing the
changes in the udev rules from GDM
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No


== Upgrade/compatibility impact ==


== How To Test ==
# Requires an NVIDIA GPU supported by the recent NVIDIA proprietary
driver and `nvidia-drm.modeset=1` set in the kernel command line to
enable KMS 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html]
(rpmfusion packages for the NVIDIA driver do that automatically)
# Enable the rpmfusion “nonfree” repository to install the NVIDIA
graphics drivers
[https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/]
# Install the NVIDIA proprietary driver (and the
`xorg-x11-drv-nvidia-power` package for suspend/resume support - see
[https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29#Suspend]
and 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/powermanagement.html]
for more details) from the rpmfusion repository
# Reboot the machine
# Ensure graphical login screen comes up
# Try to log into a "GNOME" session
# Check whether this is a "GNOME on Wayland" session (both `$DISPLAY`
and `$WAYLAND_DISPLAY` are set)
# Log out
# Try to log into a "GNOME on Xorg" session
# Check whether this is a "GNOME on Xorg" session (`$DISPLAY` is set,
`$WAYLAND_DISPLAY` is not set)


== User Experience ==
Users with NVIDIA hardware and NVIDIA proprietary driver installed
will get a Wayland session by default when selecting the "GNOME"
session in the login screen.


== Dependencies ==
This depends on the NVIDIA proprietary driver and its support for Wayland.

Typically, this proposal would change the default in a future version
of the NVIDIA driver which is not released yet.


== Contingency Plan ==
* Contingency mechanism: Revert the default to Xorg for NVIDIA driver
by reverting the changes in the udev rule shipping with GDM
* Contingency deadline: Beta Freeze
* Blocks release? No

== Documentation ==
NVIDIA's own documentation
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/]:

 * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html
 * 
http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland.html
 * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/gbm.html





-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to 

F36 Change: Wayland By Default with NVIDIA proprietary Driver (System-Wide Change)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA

== Summary ==
Enable Wayland sessions by default in GDM even with the NVIDIA
proprietary driver.

== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]]
* Email: 


== Detailed Description ==
Recent updates in NVIDIA proprietary driver allow Xwayland to benefit
from hardware acceleration and X11 applications can have their
rendering hardware accelerated.

That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.

This proposal is to make Wayland by default with newer versions of the
NVIDIA proprietary driver to remain consistent with other drivers.

GDM already has a set of udev rules which check for the driver and its
version, so this would only require a tweak in the udev rules to make
Wayland session the default with the next version of the NVIDIA driver
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in].

Note that currently Xorg is also preferred in the case of multiple
GPU, this would remain the case with this proposal.

This change is just about changing the default with NVIDIA proprietary
driver on supported configurations, “GNOME on Xorg” still remains an
option, just like with other drivers.


== Benefit to Fedora ==
Fedora has changed to Wayland by default since [[Changes/Login Screen
Over Wayland|Fedora 22]], but the NVIDIA proprietary driver has been
an exception ever since (either because originally Wayland would be
disabled with NVIDIA drivers, or more recently Xorg would be used by
default).

Currently, when first installing Fedora on NVIDIA hardware, users get
Wayland by default with the Open Source "nouveau" driver, with Xorg
being an option in the login screen. If they later decide to enable
the rpmfusion repository and install the NVIDIA proprietary driver,
they get Xorg by default and Wayland as an option.

This change would make the default consistent regardless of the
driver, for single GPU systems.

== Scope ==
* Proposal owners: Tweak the gdm udev rule to enable Wayland with the
NVIDIA proprietary driver above a given version
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in#L7-17]
* Other developers: [[User:Rstrode| Ray Strode]] for reviewing the
changes in the udev rules from GDM
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No


== Upgrade/compatibility impact ==


== How To Test ==
# Requires an NVIDIA GPU supported by the recent NVIDIA proprietary
driver and `nvidia-drm.modeset=1` set in the kernel command line to
enable KMS 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html]
(rpmfusion packages for the NVIDIA driver do that automatically)
# Enable the rpmfusion “nonfree” repository to install the NVIDIA
graphics drivers
[https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/]
# Install the NVIDIA proprietary driver (and the
`xorg-x11-drv-nvidia-power` package for suspend/resume support - see
[https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29#Suspend]
and 
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/powermanagement.html]
for more details) from the rpmfusion repository
# Reboot the machine
# Ensure graphical login screen comes up
# Try to log into a "GNOME" session
# Check whether this is a "GNOME on Wayland" session (both `$DISPLAY`
and `$WAYLAND_DISPLAY` are set)
# Log out
# Try to log into a "GNOME on Xorg" session
# Check whether this is a "GNOME on Xorg" session (`$DISPLAY` is set,
`$WAYLAND_DISPLAY` is not set)


== User Experience ==
Users with NVIDIA hardware and NVIDIA proprietary driver installed
will get a Wayland session by default when selecting the "GNOME"
session in the login screen.


== Dependencies ==
This depends on the NVIDIA proprietary driver and its support for Wayland.

Typically, this proposal would change the default in a future version
of the NVIDIA driver which is not released yet.


== Contingency Plan ==
* Contingency mechanism: Revert the default to Xorg for NVIDIA driver
by reverting the changes in the udev rule shipping with GDM
* Contingency deadline: Beta Freeze
* Blocks release? No

== Documentation ==
NVIDIA's own documentation
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/]:

 * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html
 * 
http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland.html
 * http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/gbm.html





-- 
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 

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Vít Ondruch]

Dne 07. 12. 21 v 12:26 Zbigniew Jędrzejewski-Szmek napsal(a):

On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:

Fedora defaults to locking the root account, which is needed by
single-user mode. This Change uses `sulogin --force` so the password
request is bypassed under this circumstance.

I think this is a terrible idea. The problem is real, but this
solution addresses it in the wrong place. Essentially, you are proposing
a behaviour of "something is wrong, let's make everything open without
authentication", which is good for debugging and development, but not
acceptable for a real system.



I think that while ago, I have already proposed to drop the rescue mode 
altogether, because ATM, it just makes things worse. If I cannot 
regularly boot and I open rescue mode, then I am asked for root 
password, which is not set. That is like adding salt into injury.





The correct solution is to enhance login mechanisms so that it is
possible to authenticate using existing credentials also in the rescue
mode. The fact that this is not possible right now is a bug that needs
to be fixed.

There are two features (in the sense of bits of technology) which we
didn't have in the past and which will most likely should be part of
the solution. The first is yescrypt/argon2 hashing for functions: the
complexity of brute-forcing such passwords is high enough that a
password of sufficient length should be safe even if the hash is
exposed (i.e. the passwd/shadow split is not important anymore). This
means that we can consider embedding a password somewhere in the initrd
or elsewhere in the unencrypted storage.

The second is using tpm2 for protection of local secrets: the tpm2
can enforce limits on brute-force attacks on the password.

So we have some mechanisms to reasonably store a password in boot
configuration outside of the encrypted file systems. What we currently
don't have is a mechanism to make use of it, and a mechanism to update
the password.

I would expect a solution along those lines: when initially installing
a system using Anaconda and setting the root password, or when setting/updating
the password at some later point



You have probably meant s/root/user with admin privileges/ ?



, if the user in question has admin
privileges (is root or e.g. is part of the wheel group), propagate the
yescrypted password to some accessible-at-boot-time storage. On EFI
systems that would most likely be some EFI variable. If available, use
the TPM2 to additionally tie the password to local hardware. If the
user is removed, also remove that password from that storage.

During boot, if it is necessary to authenticate before the root file
system has been mounted, allow admin users to log in using the credentials
that were stored previously.



Is this being worked on? Do you have any references?


Vít





This does not pose an increased security risk: - [if] you can already
boot with init=/sysroot/bin/bash anyway - anyone with physical
access to a machine can probably compromise it - you can enforce the
need for a root password in single-user mode by setting it

I disagree with the assessment. There are at least two important cases
where the assumption that anyone with local access can escalate to
full access does not hold. If the data is encrypted, then being able
to override the init doesn't achieve anything, until the decryption
has been performed. The second case is when the admin has actually
locked down the kernel command line and relies on the normal
authentication mechanisms to protect the system. In both cases your
proposal creates an additional method of attack that activates at a
later point where the system is already running and the integrity of
the system must be maintained to protect unencrypted data. With the
proposal, any mechanism which leads to the system entering emergency
mode results in a compromise.

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


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

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

You are kindly invited to the meeting:
   Fedora Source-git SIG on 2021-12-08 from 14:30:00 to 15:30:00 GMT
   At meet.google.com/mic-otnv-kse

The meeting will be about:
Meeting of the Fedora source-git SIG

Agenda:
https://pagure.io/fedora-source-git/sig/issues?tags=meeting=Open

SIG Info:
https://fedoraproject.org/wiki/SIGs/Source-git


Source: https://calendar.fedoraproject.org//meeting/10101/

___
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: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Nico Kadel-Garcia]

On Tue, Dec 7, 2021 at 5:46 AM Panu Matilainen  wrote:
>
> On 12/5/21 05:07, Nico Kadel-Garcia wrote:
> > I've been trying to bundle the current ansible-5.0.1 release as an RPM
> > for Fedora and EPEL use. Leaving aside the peculiar decisions to
> > replace the pypi.org "ansible" tarball with a tarball of roughly 150
> > modules from the "ansiblee-collections" repos, and moving the actual
> > ansible software to a distinct python tarball called "ansible-core"
> > without changing the source repo or the actual critical installed
> > python modules, the new "ansible" has more than 300 files called
> > "README.md" and more than 100 files called "LICENSE.md".
> >
> > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
> > '%license' macros strip off the subdirectories of the files and
> > install them directly at the top of the docdir.
> >
> > Basicely these only generate one file:
> >
> > %doc README.md
> > %doc dir1/README.md
> > %doc dir2/README.md
> >
> > %license LICENSE.md
> >  %license dir1/LICENSE
> >  %license dir2/LICENSE.md
> >
> > When compiled, these would only produce:
> >
> >/usr/share/doc/package-%{fersion}/README.md
> >/usr/share/doc/package-%{fersion}/LICENSE.md
> >
> > RHEL 7 didn't have this problem. I'm not sure if other folks have
> > noticed this for tools that are built with multiple internal tarballs.
> > The new "ansible" tarball is fairly unique ints authors insistance on
> > putting more than one hundred distinct third party packages in the
> > same master tarball. But for now, this is going to cause a license and
> > documentation problem in packaging it due to an "optimization" of
> > stripping out the directory names of document files and licenses.
> >
> > Does anyone know a decent workaround, or a specfile setting to disable
> > this filename stripping and restore the RHEL 7 behavior?
>
> There were changes in how %doc is handled around rpm 4.13 (whereas
> RHEL-7 has 4.11), maybe there's a regression that nobody noticed (or
> complained about) until now. The use-case there seems quite reasonable
> to me.
>
> File a bug on rpm (preferably upstream ticket) to have it looked at.
>
> - Panu -

I've submitted one, at https://bugzilla.redhat.com/show_bug.cgi?id=2029877 .

It seems that the problem existed as well with earlier versions of
rpmbuild, say on RHEL 7, but the warning messages about "files listed
twice" weren't generated. And various slightly differently named
README.md and LICENSE.md files make it not as obvious as one might
expect.
___
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

Planned Outage - bodhi.fedoraproject.org - 2021-12-08 9:00 UTC

[Adam Saleh]

Planned Outage - bodhi.fedoraproject.org - 2021-12-08 9:00 UTC

There will be a partial outage starting on wednesday at 2021-12-08 9:00 UTC
which will last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-12-08 9:00 UTC'

Reason for outage:

Bodhi will be properly upgraded to 5.7.3 - the code has actually been
running in prod as a hotfix for over a week, so we might as well make
it official.

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during
the upgrade window

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10406

Please join #fedora-admin or #fedora-noc on libera.chat
or add comments to the ticket for this outage above.
___
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

Planned Outage - bodhi.fedoraproject.org - 2021-12-08 9:00 UTC

[Adam Saleh]

Planned Outage - bodhi.fedoraproject.org - 2021-12-08 9:00 UTC

There will be a partial outage starting on wednesday at 2021-12-08 9:00 UTC
which will last approximately 1 hour.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2021-12-08 9:00 UTC'

Reason for outage:

Bodhi will be properly upgraded to 5.7.3 - the code has actually been
running in prod as a hotfix for over a week, so we might as well make
it official.

Affected Services:

bodhi / updates.fedoraproject.org may be down or unresponsive during
the upgrade window

Ticket Link:

https://pagure.io/fedora-infrastructure/issue/10406

Please join #fedora-admin or #fedora-noc on libera.chat
or add comments to the ticket for this outage above.
___
devel-announce mailing list -- devel-announce@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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Why CVEs are being filed for EPEL?

[Ondřej Holý]

Hi all,

do you have any idea why CVE bugs are being filed for Fedora EPEL
product in the case of the freerdp component
(https://src.fedoraproject.org/rpms/freerdp) when there aren't any
builds for epel7, or epel8? What needs to be done to avoid that, or is
this a normal approach for other components as well? Should I close
them as WONTFIX, or what is the expected workflow here?

Regards

Ondrej
___
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: Anyone interested in helping to convert the Ubuntu Discourse Docker setup to Fedora Podman?

[Daniel Walsh]

On 12/6/21 14:11, Philip Rhoades via devel wrote:

People,

I cloned this:

  https://github.com/discourse/discourse_docker

and did a "podman build" on the Dockerfile and it made it to step 39 
(of 59) before stopping with a complaint about a missing dir . .


It would be great to get a Fedora Podman Discourse container going (in 
a separate exercise some time ago I was able to get a development-only 
version going but I eventually gave up on the too-hard production 
version) - anyone interested in helping / advising?


Thanks,

Phil.

What was podman complaining about on stpe 39?  Could you attach the 
build 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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Lennart Poettering]

On Fr, 03.12.21 13:46, Florian Weimer (fwei...@redhat.com) wrote:

> We can likely add the official path to the dynamic linker as a macro in
> .

That would be lovely!

Lennart

--
Lennart Poettering, Berlin
___
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

openQA tests in Pull Requests?

[Miro Hrončok]

Hello QA,

is there a way (even a hacky one) to run openQA tests (the ones that run on 
Bodhi updates of critpath packages) on an open Pull Request?


Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Lennart Poettering]

On Do, 02.12.21 14:36, Ben Cotton (bcot...@redhat.com) wrote:

Hmm, so what I am really missing on the feature page: what's the
attack scenario here? Usually security features come with an attack
scenario they are supposed to address. But there's no discussion about
that.

This protects file contents, not the metada, right? So what about the
metadata? if I see a fs-verity enabled inode with libssl.so data in it
today, and it's a vulnerably version, and I make a hardlink to it, and
then it gets replaced by a fixed version (with a slightly updated
name) — how you intend to make sure, that i can't fool you into loading
my copy of the old file but under the new name?

What about signing anyway? What is this precisely signed with? The
keys for that when are they rolled over? Who manages those keys? The
tea for that, who's doing that in Fedora? Is there any protection
against downgrades between RPM package versions? Does this in any way
protect combinations of binaries/libraries? I mean, pretty much all
programs we ship consist of a large number of ELF objects, and you
probably need to sign the combination of them, but this model doesn't
look like it offers that at all? If a security bug is found in library
X, how is it taken out of equation? What would the workflow for that
look like on the Fedora side of things?

The security model seems really strange to me I must say: so much
infrastructure, and it doesn't protect at all how our programs are
usually combined?

Puzzled,

Lennart
___
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: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 12:01:32PM +, Richard W.M. Jones wrote:
> On Tue, Dec 07, 2021 at 11:26:37AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> > > This does not pose an increased security risk: - [if] you can already
> > > boot with init=/sysroot/bin/bash anyway - anyone with physical
> > > access to a machine can probably compromise it - you can enforce the
> > > need for a root password in single-user mode by setting it
> 
> I don't understand this bit:
> 
> > I disagree with the assessment. There are at least two important cases
> > where the assumption that anyone with local access can escalate to
> > full access does not hold. If the data is encrypted, then being able
> > to override the init doesn't achieve anything, until the decryption
> > has been performed.
> 
> How does the locked root account make anything more secure in this case?

There are many many different ways in which systems are installed,
but the general principle is that one the system is up, you need valid
credentials to log in. So protecting the system before it's running,
i.e. protecting the data at rest, can be done in many different ways
and is your responsibility, after it is up, you know that the normal
system mechanisms apply. With the proposal this promise is broken.

Having the root account locked just avoid violating that promise.

One trivial example: a kiosk where you can type on the keyboard, but
can't physically touch the machine, and the boot loader is locked
down. With the proposed change, if you can affect the system so that
it does not boot properly, even by causing a sufficient delay, is
enough to get unrestricted access.

> On the flip side I have hit the problem described and it's incredibly
> annoying - it makes rescue mode useless in the default case.

Yeah, I agree that the issue is annoying and real.

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

[Bug 2028912] Please branch and build perl-Linux-Inotify2 in epel9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2028912

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/39058


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028912
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Richard W.M. Jones]

On Tue, Dec 07, 2021 at 11:26:37AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> > This does not pose an increased security risk: - [if] you can already
> > boot with init=/sysroot/bin/bash anyway - anyone with physical
> > access to a machine can probably compromise it - you can enforce the
> > need for a root password in single-user mode by setting it

I don't understand this bit:

> I disagree with the assessment. There are at least two important cases
> where the assumption that anyone with local access can escalate to
> full access does not hold. If the data is encrypted, then being able
> to override the init doesn't achieve anything, until the decryption
> has been performed.

How does the locked root account make anything more secure in this case?

> The second case is when the admin has actually
> locked down the kernel command line and relies on the normal
> authentication mechanisms to protect the system. In both cases your
> proposal creates an additional method of attack that activates at a
> later point where the system is already running and the integrity of
> the system must be maintained to protect unencrypted data. With the
> proposal, any mechanism which leads to the system entering emergency
> mode results in a compromise.

Again, if you have the LUKS password you can easily mount the disk and
make any changes you like.  How does the locked root account help?

On the flip side I have hit the problem described and it's incredibly
annoying - it makes rescue mode useless in the default case.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2029822] New: Upgrade perl-PDL to 2.063

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029822

Bug ID: 2029822
   Summary: Upgrade perl-PDL to 2.063
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDL
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
jakub.jedel...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.62.0 version. Upstream released 2.063. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029822
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​​

[Sérgio Basto]

On Mon, 2021-12-06 at 11:17 +, Mat Booth wrote:
> On Mon, 6 Dec 2021 at 10:43, Richard W.M. Jones 
> wrote:
> > 
> > On Mon, Dec 06, 2021 at 11:21:34AM +0100, Miro Hrončok wrote:
> > > Full report available at:
> > > https://churchyard.fedorapeople.org/orphans-2021-12-06.txt
> > > grep it for your FAS username and follow the dependency chain.
> > 
> > Could we get rid of the limit
> > 
> >   "Too many dependencies for wsdl4j, not all listed here"
> > 
> > in the long reports?  I don't really care how big that text file is
> > in
> > my browser.
> > 
> > > For human readable dependency chains,
> > > see https://packager-dashboard.fedoraproject.org/
> > > For all orphaned packages,
> > > see https://packager-dashboard.fedoraproject.org/orphan
> > 
> > This is nicer, not sure if I've seen this before.
> > 
> > Looks like the main breakage is:
> > 
> >   mingw-nsis -> scons -> fop -> tomcat -> wsdl4j
> > 
> > That gets increasingly weird.  NSIS is an installer builder for
> > Windows (fine), scons is a Python-based build system (also fine),
> > fop is a documentation formatting tool, tomcat is an application
> > server (!)
> > 
> > So I wonder why a Python-based build system relies on a Java-based
> > application server.
> > 
> 
> Well, for whatever reason, upstream fop contains a servlet
> implementation (which requires an app server) but we don't even build
> or ship this servlet in our fop package.
> 
> I removed an unnecessary BR on 'servlet' from the fop package:
> https://src.fedoraproject.org/rpms/fop/c/fba0361894999fbf17c8672e96d4dc95cc06314f?branch=rawhide
> 
> Does that add more sanity to the dep chain?

from https://churchyard.fedorapeople.org/orphans.txt [1] now seems just
tomcat needs directly wsdl4j 

[1]
Depending on: wsdl4j (10), status change: 2021-12-02 (0 weeks ago)
tomcat (maintained by: coolsvap, csutherl, gzaronikas, huwang,
van)
tomcat-1:9.0.55-1.fc36.src requires wsdl4j = 1.6.3-21.fc35




-- 
> Mat Booth
> http://fedoraproject.org/get-fedora
> ___
> 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

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2029818] New: Upgrade perl-Config-Model to 2.147

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029818

Bug ID: 2029818
   Summary: Upgrade perl-Config-Model to 2.147
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Config-Model
  Assignee: david.hanneq...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 2.145 version. Upstream released 2.147. When you have
free time, please upgrade it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029818
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> Fedora defaults to locking the root account, which is needed by
> single-user mode. This Change uses `sulogin --force` so the password
> request is bypassed under this circumstance.

I think this is a terrible idea. The problem is real, but this
solution addresses it in the wrong place. Essentially, you are proposing
a behaviour of "something is wrong, let's make everything open without
authentication", which is good for debugging and development, but not
acceptable for a real system.

The correct solution is to enhance login mechanisms so that it is
possible to authenticate using existing credentials also in the rescue
mode. The fact that this is not possible right now is a bug that needs
to be fixed.

There are two features (in the sense of bits of technology) which we
didn't have in the past and which will most likely should be part of
the solution. The first is yescrypt/argon2 hashing for functions: the
complexity of brute-forcing such passwords is high enough that a
password of sufficient length should be safe even if the hash is
exposed (i.e. the passwd/shadow split is not important anymore). This
means that we can consider embedding a password somewhere in the initrd
or elsewhere in the unencrypted storage.

The second is using tpm2 for protection of local secrets: the tpm2
can enforce limits on brute-force attacks on the password.

So we have some mechanisms to reasonably store a password in boot
configuration outside of the encrypted file systems. What we currently
don't have is a mechanism to make use of it, and a mechanism to update
the password.

I would expect a solution along those lines: when initially installing
a system using Anaconda and setting the root password, or when setting/updating
the password at some later point, if the user in question has admin
privileges (is root or e.g. is part of the wheel group), propagate the
yescrypted password to some accessible-at-boot-time storage. On EFI
systems that would most likely be some EFI variable. If available, use
the TPM2 to additionally tie the password to local hardware. If the
user is removed, also remove that password from that storage.

During boot, if it is necessary to authenticate before the root file
system has been mounted, allow admin users to log in using the credentials
that were stored previously.

> This does not pose an increased security risk: - [if] you can already
> boot with init=/sysroot/bin/bash anyway - anyone with physical
> access to a machine can probably compromise it - you can enforce the
> need for a root password in single-user mode by setting it

I disagree with the assessment. There are at least two important cases
where the assumption that anyone with local access can escalate to
full access does not hold. If the data is encrypted, then being able
to override the init doesn't achieve anything, until the decryption
has been performed. The second case is when the admin has actually
locked down the kernel command line and relies on the normal
authentication mechanisms to protect the system. In both cases your
proposal creates an additional method of attack that activates at a
later point where the system is already running and the integrity of
the system must be maintained to protect unencrypted data. With the
proposal, any mechanism which leads to the system entering emergency
mode results in a compromise.

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

[Bug 2029201] perl-Net-Amazon-S3-0.99 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029201



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-942138a7e7 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-942138a7e7


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029201
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2029201] perl-Net-Amazon-S3-0.99 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2029201

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Assignee|ppi...@redhat.com   |jples...@redhat.com
   Fixed In Version||perl-Net-Amazon-S3-0.99-1.f
   ||c36
 CC||jples...@redhat.com
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029201
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Panu Matilainen]

On 12/5/21 05:07, Nico Kadel-Garcia wrote:

I've been trying to bundle the current ansible-5.0.1 release as an RPM
for Fedora and EPEL use. Leaving aside the peculiar decisions to
replace the pypi.org "ansible" tarball with a tarball of roughly 150
modules from the "ansiblee-collections" repos, and moving the actual
ansible software to a distinct python tarball called "ansible-core"
without changing the source repo or the actual critical installed
python modules, the new "ansible" has more than 300 files called
"README.md" and more than 100 files called "LICENSE.md".

This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
'%license' macros strip off the subdirectories of the files and
install them directly at the top of the docdir.

Basicely these only generate one file:

%doc README.md
%doc dir1/README.md
%doc dir2/README.md

%license LICENSE.md
 %license dir1/LICENSE
 %license dir2/LICENSE.md

When compiled, these would only produce:

   /usr/share/doc/package-%{fersion}/README.md
   /usr/share/doc/package-%{fersion}/LICENSE.md

RHEL 7 didn't have this problem. I'm not sure if other folks have
noticed this for tools that are built with multiple internal tarballs.
The new "ansible" tarball is fairly unique ints authors insistance on
putting more than one hundred distinct third party packages in the
same master tarball. But for now, this is going to cause a license and
documentation problem in packaging it due to an "optimization" of
stripping out the directory names of document files and licenses.

Does anyone know a decent workaround, or a specfile setting to disable
this filename stripping and restore the RHEL 7 behavior?


There were changes in how %doc is handled around rpm 4.13 (whereas 
RHEL-7 has 4.11), maybe there's a regression that nobody noticed (or 
complained about) until now. The use-case there seems quite reasonable 
to me.


File a bug on rpm (preferably upstream ticket) to have it looked at.

- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20211207.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20211206.n.0
NEW: Fedora-Rawhide-20211207.n.0

= SUMMARY =
Added images:1
Dropped images:  7
Added packages:  15
Dropped packages:3
Upgraded packages:   110
Downgraded packages: 0

Size of added packages:  425.73 MiB
Size of dropped packages:8.07 MiB
Size of upgraded packages:   4.19 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   91.17 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20211207.n.0.iso

= DROPPED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20211206.n.0.iso
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211206.n.0.s390x.qcow2
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20211206.n.0.s390x.tar.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211206.n.0.s390x.raw.xz
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20211206.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20211206.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20211206.n.0.iso

= ADDED PACKAGES =
Package: cri-o-1.20.6-2.module_f36+13501+d604a069
Summary: Kubernetes Container Runtime Interface for OCI-based containers
RPMs:cri-o
Size:101.32 MiB

Package: cri-tools-1.20.0-2.module_f36+13501+d604a069
Summary: CLI and validation tools for Container Runtime Interface
RPMs:cri-tools
Size:35.71 MiB

Package: fluent-bit-1.8.10-8.fc36
Summary: Fast data collector for Linux
RPMs:fluent-bit
Size:3.46 MiB

Package: galera-26.4.9-3.module_f36+13483+3b9a6c03
Summary: Synchronous multi-master wsrep provider (replication engine)
RPMs:galera
Size:5.32 MiB

Package: golang-github-alecaivazis-survey-2-2.3.2-1.fc36
Summary: A golang library for building interactive and accessible prompts
RPMs:golang-github-alecaivazis-survey-2-devel
Size:62.49 KiB

Package: golang-github-itchyny-timefmt-0.1.3-1.fc36
Summary: Efficient time formatting library (strftime, strptime) for Golang
RPMs:golang-github-itchyny-timefmt-devel
Size:20.25 KiB

Package: llhttp-6.0.6-1.fc36
Summary: Port of http_parser to llparse
RPMs:llhttp llhttp-devel
Size:236.55 KiB

Package: mariadb-3:10.7.1-1.module_f36+13483+3b9a6c03
Summary: A very fast and robust SQL database server
RPMs:mariadb mariadb-backup mariadb-common mariadb-connect-engine 
mariadb-cracklib-password-check mariadb-devel mariadb-embedded 
mariadb-embedded-devel mariadb-errmsg mariadb-gssapi-server 
mariadb-oqgraph-engine mariadb-pam mariadb-rocksdb-engine mariadb-s3-engine 
mariadb-server mariadb-server-galera mariadb-server-utils mariadb-sphinx-engine 
mariadb-test
Size:278.22 MiB

Package: python-pytn3270-0.12.0-1.fc36
Summary: Python TN3270 library
RPMs:python3-pytn3270
Size:41.75 KiB

Package: python-ukkonen-1.0.1-3.fc36
Summary: Implementation of bounded Levenshtein distance (Ukkonen)
RPMs:python3-ukkonen
Size:89.55 KiB

Package: rust-combine-4.6.0-1.fc36
Summary: Fast parser combinators on arbitrary streams with zero-copy support
RPMs:rust-combine+bytes-devel rust-combine+bytes_05-devel 
rust-combine+default-devel rust-combine+futures-03-devel 
rust-combine+futures-io-03-devel rust-combine+futures-util-03-devel 
rust-combine+mp4-devel rust-combine+pin-project-devel 
rust-combine+pin-project-lite-devel rust-combine+regex-devel 
rust-combine+std-devel rust-combine+tokio-02-dep-devel 
rust-combine+tokio-02-devel rust-combine+tokio-dep-devel 
rust-combine+tokio-devel rust-combine-devel
Size:221.94 KiB

Package: rust-env_proxy-0.4.1-1.fc36
Summary: Determination of proxy parameters for a URL from the environment
RPMs:rust-env_proxy+default-devel rust-env_proxy-devel
Size:25.43 KiB

Package: rust-rand_isaac0.2-0.2.0-1.fc36
Summary: ISAAC random number generator
RPMs:rust-rand_isaac0.2+default-devel rust-rand_isaac0.2+serde-devel 
rust-rand_isaac0.2+serde1-devel rust-rand_isaac0.2-devel
Size:45.80 KiB

Package: rust-subprocess-0.2.7-1.fc36
Summary: Execution of and interaction with external processes and pipelines
RPMs:rust-subprocess+default-devel rust-subprocess-devel subprocess
Size:924.26 KiB

Package: rust-toml_edit-0.2.1-1.fc36
Summary: Yet another format-preserving TOML parser
RPMs:rust-toml_edit+default-devel rust-toml_edit-devel
Size:81.58 KiB


= DROPPED PACKAGES =
Package: gdata-sharp-1.4.0.2-29.fc34
Summary: .NET library for the Google Data API
RPMs:gdata-sharp gdata-sharp-devel
Size:1.06 MiB

Package: rust-nickel-0.11.0-8.fc35
Summary: Express.js inspired web framework
RPMs:rust-nickel+default-devel rust-nickel-devel
Size

Fedora-Cloud-34-20211207.0 compose check report

[Fedora compose checker]

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-34-20211206.0):

ID: 1079153 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1079153
ID: 1079161 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1079161

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

Fedora-Cloud-35-20211207.0 compose check report

[Fedora compose checker]

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-20211206.0):

ID: 1079024 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1079024
ID: 1079032 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1079032

Passed openQA tests: 7/8 (aarch64), 7/8 (x86_64)

New passes (same test not passed in Fedora-Cloud-35-20211206.0):

ID: 1079031 Test: aarch64 Cloud_Base-qcow2-qcow2 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1079031
-- 
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