[Bug 1915891] perl-Module-ScanDeps-1.30 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|anon.am...@gmail.com,   |
   |jose.p.oliveira.oss@gmail.c |
   |om, st...@silug.org |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915904] perl-PAR-Packer-1.052 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PAR-Packer-1.052-1.fc3
   ||4
 Resolution|--- |RAWHIDE
Last Closed||2021-01-14 07:46:43




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915904] perl-PAR-Packer-1.052 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|anon.am...@gmail.com,   |
   |mmasl...@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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

[Guido Aulisi]

Hi,

Il giorno mer, 13/01/2021 alle 13.46 -0700, Chris Murphy ha scritto:
> On Tue, Jan 12, 2021 at 8:48 PM Michel Alexandre Salim
>  wrote:

... snip

> There are separate issues.
> 
> grubenv is "OK" on ext4 and XFS. The issue is that none of the file
> systems developers like anything other than kernel code doing writes.
> One idea for this is a new MBR and GPT partition type, functionally
> identical to the GPT "BIOS Boot" type, that's exclusively for the
> bootloader to use however it wants. On BIOS it'd include core.img and
> grubenv. On UEFI it'd just be used for grubenv. This issue needs to
> be
> taken upstream to sort out the details, so it should be set aside as
> it relates to this proposal.

IMHO boot loaders should not write to filesystems, if this is needed to
hide the GRUB menu when boot is successful, then let's display it
always as it was one time. I don't think it we should follow Windows or
MacOS style here, the boot menu is useful.

> The issue with journaled file systems is that GRUB's file system
> drivers have no ability to do journal replay. Therefore there is a
> small risk the file system is rendered unbootable in a crash, because
> the bootloader only sees the no-replay state of the file system used
> for /boot. e.g. the bootloader can see grub.cfg, bls snippets, or
> even
> the kernel as either missing or as 0 length files, until the journal
> has been replayed. Small risk, big penalty. My suggestion for
> mitigation is to use FAT for /boot in simple cases, and Btrfs in less
> simple cases. It's just an idea, it's not urgent, but if things are
> being reconsidered for simplification anyway, this makes sense to me.
> 
> Ergo the idea for a "bootloader partition that is exclusively owned
> by
> the bootloader" is separate from "bootloaders don't do journal replay
> and therefore can have the wrong view of things, and fail to boot in
> rare cases following a crash."

Yet another partition needed to boot the OS. What when there are no
available paritions in BIOS mode, because other OSes used all the
available 4 partitions?

... snip

Ciao
Guido


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1915876] perl-PAR-1.017 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915876] perl-PAR-1.017 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PAR-1.017-1.fc34




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1916075] New: perl-PPIx-Regexp-0.077 is available

[bugzilla]

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

Bug ID: 1916075
   Summary: perl-PPIx-Regexp-0.077 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.077
Current version/release in rawhide: 0.076-1.fc34
URL: http://search.cpan.org/dist/PPIx-Regexp/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Jens-Ulrik Petersen]

I think it is really worth mentioning here that Transtats
 already provides a lot of
Fedora translation statistics and info.
There is certainly more that could be done and we would like to do, to
enhance it further...
While I know Jean-Baptiste is not a fan and has his own approach here, the
overlap in effort does make me sad.

I also want to call out and thank Jean-Baptiste for all the awesome work he
has done on migrating Fedora L10n to Weblate.

Thank you, Jens
___
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

Schedule for Thursday's FPC Meeting (2021-01-14 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-01-14 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2021-01-14 09:00 PST  US/Pacific
2021-01-14 12:00 EST  --> US/Eastern <--
2021-01-14 17:00 GMT  Europe/London 
2021-01-14 17:00 UTC  UTC   
2021-01-14 18:00 CET  Europe/Berlin 
2021-01-14 18:00 CET  Europe/Paris  
2021-01-14 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-01-15 01:00 HKT  Asia/Hong_Kong
2021-01-15 01:00 +08  Asia/Singapore
2021-01-15 02:00 JST  Asia/Tokyo
2021-01-15 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

#topic Open Floor
 * decathorpe
   look through non-meeting tickets, see if any are stuck/need to be discussed

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-001e4d949f   
dia-0.97.3-16.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd945e3b55   
adplug-2.3.3-1.el8 audacious-plugins-4.0.5-3.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-e976495093   
coturn-4.5.2-1.el8


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

autojump-22.5.3-3.el8
ipv6calc-3.0.1-48.el8
perl-Crypt-GPG-1.64-19.el8
python-pystemd-0.8.0-1.el8
singularity-3.7.1-1.el8

Details about builds:



 autojump-22.5.3-3.el8 (FEDORA-EPEL-2021-2f0e55a233)
 A fast way to navigate your filesystem from the command line

Update Information:

Initial EPEL8 release

ChangeLog:


References:

  [ 1 ] Bug #1899791 - Please branch and build autojump for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1899791




 ipv6calc-3.0.1-48.el8 (FEDORA-EPEL-2021-30d32ca4fb)
 IPv6 address format change and calculation utility

Update Information:

Final release 3.0.1

ChangeLog:

* Wed Jan 13 2021 Peter Bieringer  - 3.0.1-48
- Final release 3.0.1

References:

  [ 1 ] Bug #1915669 - ipv6calc-3.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915669




 perl-Crypt-GPG-1.64-19.el8 (FEDORA-EPEL-2021-1914ea0002)
 Perl Object Oriented Interface to GnuPG

Update Information:

The Crypt::GPG module provides access to the functionality of the GnuPG v1
(www.gnupg.org) encryption tool through an object oriented interface. It
provides methods for encryption, decryption, signing, signature verification,
key generation, key certification, export and import.

ChangeLog:





 python-pystemd-0.8.0-1.el8 (FEDORA-EPEL-2021-f9f8d631cb)
 A thin Cython-based wrapper on top of libsystemd

Update Information:

Initial EPEL8 release

ChangeLog:





 singularity-3.7.1-1.el8 (FEDORA-EPEL-2021-4c2fa578e4)
 Application and environment virtualization

Update Information:

Upgrade to upstream 3.7.1.

ChangeLog:

* Tue Jan 12 2021 Dave Dykstra  - 3.7.1-1
- Upgrade to upstream 3.7.1.

References:

  [ 1 ] Bug #1915866 - singularity-3.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915866


___
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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4a9fc09599   
openjpeg2-2.3.1-10.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a8b2c928f5   
dia-0.97.3-16.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-143227c7ed   
sympa-6.2.60-1.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-5843fdc72c   
adplug-2.3.3-1.el7 audacious-plugins-4.0.5-3.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-6bfa86551f   
coturn-4.5.2-1.el7


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

ipv6calc-3.0.1-48.el7
perl-Crypt-GPG-1.64-19.el7
singularity-3.7.1-1.el7

Details about builds:



 ipv6calc-3.0.1-48.el7 (FEDORA-EPEL-2021-08c5a9b7fc)
 IPv6 address format change and calculation utility

Update Information:

Final release 3.0.1

ChangeLog:

* Wed Jan 13 2021 Peter Bieringer  - 3.0.1-48
- Final release 3.0.1
- add ipv6calc-3.0.1-c99-fix.patch

References:

  [ 1 ] Bug #1915669 - ipv6calc-3.0.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915669




 perl-Crypt-GPG-1.64-19.el7 (FEDORA-EPEL-2021-fbaa5937ba)
 Perl Object Oriented Interface to GnuPG

Update Information:

The Crypt::GPG module provides access to the functionality of the GnuPG v1
(www.gnupg.org) encryption tool through an object oriented interface. It
provides methods for encryption, decryption, signing, signature verification,
key generation, key certification, export and import.

ChangeLog:





 singularity-3.7.1-1.el7 (FEDORA-EPEL-2021-4a81849239)
 Application and environment virtualization

Update Information:

Upgrade to upstream 3.7.1.

ChangeLog:

* Tue Jan 12 2021 Dave Dykstra  - 3.7.1-1
- Upgrade to upstream 3.7.1.

References:

  [ 1 ] Bug #1915866 - singularity-3.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1915866


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Proposal: gate stable release critical path updates on openQA test results

[Adam Williamson]

On Thu, 2021-01-07 at 09:25 -0800, Adam Williamson wrote:
> Hey folks!
> 
> So here's an idea I was thinking about over the RH shutdown: I propose
> we gate stable release critical path updates on the openQA tests.

As feedback on this was mostly positive, I went ahead and did the work.
The PR for the Greenwave policy has been merged already, as that does
not in itself cause any actual behaviour change:
https://pagure.io/fedora-infra/ansible/pull-request/349

The PR for Bodhi is here:
https://github.com/fedora-infra/bodhi/pull/4180

merging that *would* cause the proposal to be implemented, and start
gating updates. Please yell if you think this isn't ready yet and you
didn't yell already, or you see any issues in the practical
implementation. Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1915067] perl-Devel-PatchPerl-2.08 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1912934] perl-Socket-2.031 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1905896] perl-libnet-3.12 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1909508] perl-Module-CoreList-5.20201220 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1903541] perl-Encode-3.08 is available

[bugzilla]

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



--- Comment #10 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



--- Comment #13 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1891478] Upgrade perl-Params-Util to 1.102

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-MODULAR-2021-a187ad8a04 has been pushed to the Fedora 32 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-a187ad8a04

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1912934] perl-Socket-2.031 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1910310] perl-libnet-3.13 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1909508] perl-Module-CoreList-5.20201220 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1905896] perl-libnet-3.12 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1903541] perl-Encode-3.08 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1891478] Upgrade perl-Params-Util to 1.102

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-MODULAR-2021-558ba3f09c has been pushed to the Fedora 33 Modular testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2021-558ba3f09c

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1910811] perl-Dist-Zilla-Plugin-Git-Contributors-0.036 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-
   |Contributors-0.036-1.fc34   |Contributors-0.036-1.fc34
   |perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-
   |Contributors-0.036-1.fc33   |Contributors-0.036-1.fc33
   ||perl-Dist-Zilla-Plugin-Git-
   ||Contributors-0.036-1.fc32



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-91c1f3a5f5 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1912612] perl-HTTP-Cookies-6.10 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-HTTP-Cookies-6.10-1.fc |perl-HTTP-Cookies-6.10-1.fc
   |34  |34
   |perl-HTTP-Cookies-6.10-1.fc |perl-HTTP-Cookies-6.10-1.fc
   |33  |33
   ||perl-HTTP-Cookies-6.10-1.fc
   ||32



--- Comment #7 from Fedora Update System  ---
FEDORA-2021-507bdbfcbd has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1912662] perl-Gnome2-Canvas-1.006 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Gnome2-Canvas-1.006-1. |perl-Gnome2-Canvas-1.006-1.
   |fc34|fc34
   |perl-Gnome2-Canvas-1.006-1. |perl-Gnome2-Canvas-1.006-1.
   |fc33|fc33
   ||perl-Gnome2-Canvas-1.006-1.
   ||fc32



--- Comment #9 from Fedora Update System  ---
FEDORA-2021-671b64c1da has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914367] perl-Net-HTTP-6.20 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Net-HTTP-6.20-1.fc34   |perl-Net-HTTP-6.20-1.fc34
   ||perl-Net-HTTP-6.20-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-01-14 01:39:19



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-cc1cde9ba7 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1914006] perl-libwww-perl-6.52 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.52-1.fc3 |perl-libwww-perl-6.52-1.fc3
   |4   |4
   ||perl-libwww-perl-6.52-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2021-01-14 01:39:15



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-724ee60bff has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1911534] perl-libwww-perl-6.51 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-libwww-perl-6.51-1.fc3 |perl-libwww-perl-6.51-1.fc3
   |4   |4
   ||perl-libwww-perl-6.52-1.fc3
   ||3
 Resolution|--- |ERRATA
Last Closed||2021-01-14 01:39:12



--- Comment #8 from Fedora Update System  ---
FEDORA-2021-724ee60bff has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1910811] perl-Dist-Zilla-Plugin-Git-Contributors-0.036 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Dist-Zilla-Plugin-Git- |perl-Dist-Zilla-Plugin-Git-
   |Contributors-0.036-1.fc34   |Contributors-0.036-1.fc34
   ||perl-Dist-Zilla-Plugin-Git-
   ||Contributors-0.036-1.fc33
 Resolution|--- |ERRATA
Last Closed||2021-01-14 01:37:43



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-82a9b15e0e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1912662] perl-Gnome2-Canvas-1.006 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Gnome2-Canvas-1.006-1. |perl-Gnome2-Canvas-1.006-1.
   |fc34|fc34
   ||perl-Gnome2-Canvas-1.006-1.
   ||fc33
 Resolution|--- |ERRATA
Last Closed||2021-01-14 01:37:25



--- Comment #8 from Fedora Update System  ---
FEDORA-2021-596a590d8c has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Cfitsio soname bump

[Sergio Pascual]

Hello, I'm going to build new cfitsio 3.490 in Rawhide in a week.  This
involves a soname bump.

The affected packages are the following:

CCfits
LabPlot
astrometry
bes
cpl
elements-alexandria
gdal
healpix
indi-gphoto
kst
kstars
libindi
luminance-hdr
nightviewperl-Astro-FITS-CFITSIO
phd2
python-astropy
python-fitsio
python-healpy
root
siril
skyviewer
sourcextractor++
ufraw
vips
wcslib

Best regards, Sergio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chromium built in rawhide does not render most strings

[Kevin Kofler via devel]

Tom Callaway wrote:
> https://bugs.chromium.org/p/chromium/issues/detail?id=1164975
> 
> Please add in this info, it was on my TODO list, but clearly hasn't
> happened yet.

https://bugs.chromium.org/p/chromium/issues/detail?id=1164975#c8

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

Re: libelf now depends on openssl

[Kevin Kofler via devel]

Michael Catanzaro wrote:
> I notice that WebKit, when built with WebRTC enabled, now crashes
> during the build:
> 
> https://bugs.webkit.org/show_bug.cgi?id=214812#c7
> 
> It's a symbol conflict between boringssl (used by libwebrtc) and
> openssl.

Do the boringssl symbols not have hidden visibility in libwebrtc? If they 
do, why are they getting interposed anyway? If they don't, why not? I assume 
the library is private to libwebrtc and its symbols should not be exported.

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

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Adam Williamson]

On Wed, 2021-01-13 at 13:42 -0800, Kevin Fenzi wrote:
> I'm definitely in favor of this effort. ;) 
> 
> A few questions inline...
> 
> On Wed, Jan 13, 2021 at 09:53:36AM -0800, Adam Williamson wrote:
> ...snip...
> > 
> > that is all it does. The "releases" and "events" are entirely
> > arbitrary; a "release" can be any string, and so can the "state" for a
> > given "event". An "event" is defined as a state being either reached or
> > left; any number of events for the same state can be present for a
> > release.
> 
> Might it be good to standardize these? I mean we don't want to have: 
> 
> state: "Fedora 34 Beta Released to mirrors"
> and then in f35 cycle:
> state: "f35b released/mirrors"
> 
> Or at least record somewhere in a doc what we want to use after the
> first cycle in use?

I was following the lessons we learned with taskotron: make the tool
simple and flexible, standardize the usage by convention. (This also
means the tool is flexible: if it works out for Fedora, it could be
used for...pretty much any other software project that has this issue).

Typically submissions should be done by code or at least scripted, and
there shouldn't be *too* many systems submitting events, so it should
be relatively easy to make sure they follow the same names. But yes, we
definitely want everything that submits to call the same release the
same thing :)

We *could* write a "fedora helper" for submitting events that enforces
a house style, but for something this simple I'm not sure it's
worthwhile.

We could use one of the name formats Bodhi has, or we could use the
'dist' / 'short' names from productmd compose metadata, I guess.

> ...snip...
> > 
> > My idea for using this is basically that we deploy an 'official'
> > releasestream instance in infra, and then find things that do the
> > actual work of moving Fedora releases into and out of given "states"
> > and tack on a bit at the end to tell releasestream about it. So when
> > e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
> > "submit 'enter freeze' event to releasestream" to that process somehow
> > - ideally something that has to be run as part of the process anyway
> > would send the POST, but in a pinch a human could do it too. When
> > Fedora 34 is being 'released', we tweak that process to include sending
> > a releasestream event POST. And so on.
> 
> I see right now this keeps the state/messages in a file store?
> I think this is a great app to just run in openshift, but if we do that
> I wouldn't want to loose state, so perhaps we store things in a
> database? I know thats overkill for this simple stuff, but it would mean
> we have everything easily stored/backed up, etc. I guess we could also
> just make a persistent volume and make sure to back it up. 

Yeah, it could be a database too, I guess, I just used a text file
because it was easy, honestly, and it also means you can hand edit
stuff quite easily (this would allow fixups for incorrect names, and
it'd also make it easy to 'reconstruct' historical schedules, which I
might do at some point). If you file a ticket for adding db support
I'll look at it.

> ...snip...
> 
> > 
> > So, what do folks think? Does this seem like a good idea? Should I go
> > ahead with trying to get it deployed and onboard things to it? Any
> > comments, ideas, potential problems? Thanks!
> 
> Yeah, I like it and definitely think it's worth a try!
> 
> Thanks for implementing it.

Thanks for the feedback!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

libelf now depends on openssl

[Michael Catanzaro]

Hi,

I notice that WebKit, when built with WebRTC enabled, now crashes 
during the build:


https://bugs.webkit.org/show_bug.cgi?id=214812#c7

It's a symbol conflict between boringssl (used by libwebrtc) and 
openssl. But why is openssl involved at all? It's a dependency of 
libcurl, which is a dependency of debuginfod, which apparently gets 
initialized by a library constructor of elfutils:


https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/debuginfod-client.c;h=99b66b6eedf4a8a06024b2bb89da4824847fcd4d;hb=HEAD

So my first thought was: does elfutils get linked into... everything? 
It seems the answer is "no" because I can run /usr/bin/true under gdb, 
break on __libdwfl_debuginfod_init, and verify that it doesn't get 
called. Same for gnome-clocks. But when I try running nautilus under 
gdb, I find:


(gdb) break __libdwfl_debuginfod_init
..
(gdb) r
..
(gdb) bt
#0 0x7fffce58dda0 in __libdwfl_debuginfod_init () at 
/lib64/libdw.so.1

#1 0x77fe18ee in call_init
   (l=, argc=argc@entry=1, 
argv=argv@entry=0x7fffe168, env=env@entry=0x7fffe178)

   at dl-init.c:74
#2 0x77fe19d8 in call_init (env=0x7fffe178, 
argv=0x7fffe168, argc=1, l=)

   at dl-init.c:37
#3 _dl_init (main_map=0x55ab, argc=1, argv=0x7fffe168, 
env=0x7fffe178) at dl-init.c:121

#4 0x76e7a095 in __GI__dl_catch_exception
   (exception=, operate=, 
args=) at dl-error-skeleton.c:182
#5 0x77fe5e35 in dl_open_worker (a=0x7fffd840) at 
dl-open.c:783

#6 0x76e7a038 in __GI__dl_catch_exception
   (exception=0x7fffd820, operate=0x77fe5a50 , 
args=0x7fffd840)

   at dl-error-skeleton.c:208
#7 0x77fe566e in _dl_open
   (file=0x7fffd820 "\344\025\207UUU", mode=-2147483647, 
caller_dlopen=0x77064bff , nsid=-2, argc=1, 
argv=0x7fffe168, env=0x7fffe178) at dl-open.c:864
#8 0x7654439c in dlopen_doit (a=a@entry=0x7fffda70) at 
dlopen.c:66

#9 0x76e7a038 in __GI__dl_catch_exception
   (exception=exception@entry=0x7fffda10, operate=0x76544340 
, args=0x7fffda70)

   at dl-error-skeleton.c:208
#10 0x76e7a103 in __GI__dl_catch_error
   (objname=0x557789d0, errstring=0x557789d8, 
mallocedp=0x557789c8, operate=, args=out>) at dl-error-skeleton.c:227
#11 0x76544bd9 in _dlerror_run (operate=0x76544340 
, args=0x7fffda70) at dlerror.c:170
#12 0x76544428 in __dlopen (file=, 
mode=) at dlopen.c:87

#13 0x77064bff in g_module_open () at /lib64/libgmodule-2.0.so.0
#14 0x5561cfce in nautilus_module_load ()
#15 0x771e927b in g_type_module_use () at 
/lib64/libgobject-2.0.so.0

#16 0x5561e8e7 in nautilus_module_setup ()
#17 0x555ae75a in nautilus_application_startup_common ()
#18 0x771e2080 in g_signal_emit_valist () at 
/lib64/libgobject-2.0.so.0

#19 0x771e21a3 in g_signal_emit () at /lib64/libgobject-2.0.so.0
#20 0x772e61c9 in g_application_register () at 
/lib64/libgio-2.0.so.0
#21 0x772e689e in g_application_real_local_command_line () at 
/lib64/libgio-2.0.so.0

#22 0x772e6c46 in g_application_run () at /lib64/libgio-2.0.so.0
#23 0x555ab2be in main ()

What is nautilus dlopening?

#12 0x76544428 in __dlopen (file=, 
mode=) at dlopen.c:87
   args = {file = 0x55933ce0 
"/usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so", mode 
= 1, new = 0x3, caller = 0x77064bff 


And, yes:

$ ldd /usr/lib64/nautilus/extensions-3.0/libtotem-properties-page.so | 
grep elf

libelf.so.1 => /lib64/libelf.so.1 (0x7f6d4f17c000)

So not everything links to libelf, and only things that link to it are 
affected:


$ ldd /usr/lib64/libwebkit2gtk-4.0.so | grep elf
libelf.so.1 => /lib64/libelf.so.1 (0x7f159b53c000)

I guess it's being transitively pulled into these libs via... 
something... but I'm not sure via what.


Anyway, does debuginfod really need to always be initialized? Could it 
be loaded only when running under gdb, perhaps? If it's not truly 
needed, that would be the path of least resistance. Otherwise, I 
suspect openssl 1.2 -> openssl 3.0 may be a more difficult transition 
than expected.


Michael

___
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

[389-devel] Re: Deref plugin entries == NULL #4525

[William Brown]

> On 13 Jan 2021, at 21:24, Pierre Rogier  wrote:
> 
> Thank you Willian,
> So far your scenario (entry found when reading base entry but no more 
> existing when computing the candidates) is the only one that matches the 
> symptoms.

It's a scenario we will need to fix via your BE work because of the MVCC 
transaction model that LMDB will force us to adopt :) 

> And that triggered a thought: 
>  We cannot do anything for SUBTREE and ONE_LEVEL searches
>   because the fact that the base entry id is not in the candidate may be 
> normal
>  but IMHO we should improve the BASE search case.
> In this case the candidate list is directly set to the base entry id
>  ==> if the candidate entry (in ldbm_back_next_search_entry) is not found and 
> the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY error ..

I suspect that Mark has seen this email and submitted a PR to resolve this 
exact case :) 


> 
>Pierre
> 
> 
> On Wed, Jan 13, 2021 at 1:45 AM William Brown  wrote:
> Hey there,
> 
> https://github.com/389ds/389-ds-base/pull/4525/files
> 
> I had a look and I can see a few possible contributing factors, but without a 
> core and the exact state I can't be sure if this is correct. It's all just 
> hypothetical from reading the code.
> 
> 
> The crash is in deref_do_deref_attr() which is called as part of 
> deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by 
> "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb, 
> SLAPI_PLUGIN_PRE_ENTRY_FN);"
> 
> 
> I think what's important here is that the search is conducted in 
> ./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb);  Is *not* in 
> a transaction. That means that while the single search in be_search() is 
> consistent due to an implied transaction, the subsequent search in 
> deref_pre_entry() is likely conducted in a seperate transaction. This allows 
> for other operations to potentially interleave and cause changes - modrdn or 
> delete would certainly be candidates to cause a DN to be remove between these 
> two points. It would be extremely hard to reproduce as a race condition of 
> course. 
> 
> 
> A question you asked is why don't we get a "no such entry" error or similar? 
> I think that this is because build_candidate_list in ldbm_search.c doesn't 
> actually create an error if the base_candidates list is empty, because an IDL 
> is allocated with a value of 0 (no matching entries). this allows the search 
> to proceed, and there are no errors, and the result set is set to NULL with 
> size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in this process, but 
> without looking further into it, my suspicion is that entries of size 0 WONT 
> return an error condition to internal_search_pb, so it's valid for this to be 
> empty.
> 
> Anyway, again, this is just reading the code for 20 minutes, and is not a 
> complete in depth investigation, but maybe it's some ideas about what 
> happened?
> 
> Hope it helps :) 
> 
> 
> 
> —
> Sincerely,
> 
> William Brown
> 
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
> 
> 
> -- 
> --
> 
> 389 Directory Server Development Team
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Chris Murphy  said:
> The issue with journaled file systems is that GRUB's file system
> drivers have no ability to do journal replay. Therefore there is a
> small risk the file system is rendered unbootable in a crash, because
> the bootloader only sees the no-replay state of the file system used
> for /boot. e.g. the bootloader can see grub.cfg, bls snippets, or even
> the kernel as either missing or as 0 length files, until the journal
> has been replayed. Small risk, big penalty. My suggestion for
> mitigation is to use FAT for /boot in simple cases, and Btrfs in less
> simple cases. It's just an idea, it's not urgent, but if things are
> being reconsidered for simplification anyway, this makes sense to me.

I've been bitten by that issue before.  I would probably avoid FAT for a
couple of reasons: no ownership/permissions, and could get stepped on in
dual-boot setups by Windows.  I'd go with one of the Linux
non-journaling filesystems, like good ol' ext2.  With few writes, it
should always be in a "safe" state.

Ideally, it could be left mounted read-only and only remounted RW during
updates (and then back to RO to make sure everything is flushed);
although I guess doing that would generally cover the journaled FSes as
well.

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

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Ben Cotton]

This sounds like a Particularly Delightful Concept. :-) I like the
idea and heartily endorse you doing it.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Migrating the Fedora Developer Portal to Fedora Docs

[Kevin Fenzi]

On Wed, Jan 13, 2021 at 10:15:47AM +, Ankur Sinha wrote:
> Hi folks,
> 
> (CC: docs ML)
> 
> I've seen the Fedora Developer portal continue to exist as a standalone
> project separately from the Fedora docs, and I don't quite understand
> why this is so. I think it'll be much better if the information there
> was moved to the new Fedora docs---so that users and the community have
> all the info they need in one place. It'll also imply that the
> work/resources that are being used to develop and maintain whatever
> platform the Developer Portal is using can be directed towards improving
> the docs project.
> 
> What do you think?
> 
> I've started a discussion here. Please chime in:
> https://github.com/developer-portal/website/issues/112

I'm in favor if you can convince them to do it. ;) 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Schedule for Wednesday's FESCo Meeting (2021-01-13)

[Kevin Fenzi]

On Tue, Jan 12, 2021 at 07:33:18PM -0800, Michel Alexandre Salim wrote:
> On Tue, 2021-01-12 at 21:30 +, Zbigniew Jędrzejewski-Szmek wrote:
> > 
> > Following is the list of topics that will be discussed in the
> > FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on
> > irc.freenode.net.
> > 
> > To convert UTC to your local time, take a look at
> >   http://fedoraproject.org/wiki/UTCHowto
> > 
> > or run:
> >   date -d '2021-01-13 15:00 UTC'
> > 
> > 
> Zbigniew, the calendar entry still lists 14:00 UTC (presumably a
> leftover from when daylight saving is broadly in effect across the
> Europe and NA):
> 
>   https://apps.fedoraproject.org/calendar/fesco/
> 
> Can someone edit it? Also, I wonder what's the best way of applying
> daylight saving while keeping a mostly-UTC time. Maybe we should use
> Europe/Dublin?

In the past we have tried to keep the meeting in UTC so it was clear,
and additionally the fesco meeting at least moves around after elections
often. (Although it hasn't in a while recently). 

The problem with Europe/Dublin is that EU and US DST doesn't change at
the same time. So there's a week or two on either end where one is
changed and not the other, adding to confusion. 

Timezones suck. :( 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-33-20210113.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64)

New failures (same test not failed in Fedora-IoT-33-20210104.0):

ID: 755753  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/755753

Old failures (same test failed in Fedora-IoT-33-20210104.0):

ID: 755755  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/755755
ID: 755768  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/755768

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-33-20210104.0):

ID: 755739  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/755739

Passed openQA tests: 14/16 (x86_64), 13/15 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Kevin Fenzi]

I'm definitely in favor of this effort. ;) 

A few questions inline...

On Wed, Jan 13, 2021 at 09:53:36AM -0800, Adam Williamson wrote:
...snip...
> 
> that is all it does. The "releases" and "events" are entirely
> arbitrary; a "release" can be any string, and so can the "state" for a
> given "event". An "event" is defined as a state being either reached or
> left; any number of events for the same state can be present for a
> release.

Might it be good to standardize these? I mean we don't want to have: 

state: "Fedora 34 Beta Released to mirrors"
and then in f35 cycle:
state: "f35b released/mirrors"

Or at least record somewhere in a doc what we want to use after the
first cycle in use?

...snip...
> 
> My idea for using this is basically that we deploy an 'official'
> releasestream instance in infra, and then find things that do the
> actual work of moving Fedora releases into and out of given "states"
> and tack on a bit at the end to tell releasestream about it. So when
> e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
> "submit 'enter freeze' event to releasestream" to that process somehow
> - ideally something that has to be run as part of the process anyway
> would send the POST, but in a pinch a human could do it too. When
> Fedora 34 is being 'released', we tweak that process to include sending
> a releasestream event POST. And so on.

I see right now this keeps the state/messages in a file store?
I think this is a great app to just run in openshift, but if we do that
I wouldn't want to loose state, so perhaps we store things in a
database? I know thats overkill for this simple stuff, but it would mean
we have everything easily stored/backed up, etc. I guess we could also
just make a persistent volume and make sure to back it up. 

...snip...

> 
> So, what do folks think? Does this seem like a good idea? Should I go
> ahead with trying to get it deployed and onboard things to it? Any
> comments, ideas, potential problems? Thanks!

Yeah, I like it and definitely think it's worth a try!

Thanks for implementing it.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [apt-cacher-ng] Resurrect dead package

[Pablo Sebastián Greco]

Hi Frederic, thanks for doing this, I have a few local fixes for it but 
never got around to resurrect it, I'll likely create some PRs after it 
is back up.


Pablo.

On 13/1/21 17:41, Frédéric Pierret wrote:

Hi,
I've resurrected `apt-cacher-ng` on my fork: 
https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb23a43b4279dab045040717a025c83c?branch=master 
with successful builds on my testing COPR repository for F32+ and 
EPEL8: 
https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/.


I plan to (already) use this package for my current work on 
reproducible builds.


Is the procedure described in 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package 
still available for such case?


Thank you.

Best regards,
Frédéric Pierret


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

[Chris Murphy]

On Tue, Jan 12, 2021 at 10:06 PM Javier Martinez Canillas
 wrote:
>
> The thing is that implementing this proposal should be straightforward
> and something that could be done for F34 but solving the grubenv issue
> will require more time, since we first will need to agree with GRUB
> upstream on the approach.

Agree.

>
> Also, switching existing installations to the configuration scheme
> mentioned in this proposal should be feasible but changing the
> partition layout would be much more risky. That's why I believe that
> even if we solve the grubenv issue (i.e: in F35), this should only be
> for new installations and storing grubenv as a file has to be
> supported for backward compatibility.

Agree. Unless I can track down a magical leopluradon to do a 100% safe
conversion, I think it's OK to just depend on attrition to solve this.

I'm sometimes an outlier, but I'm a strong proponent of GUI tools
constraining the options available to users, to only that which we
recommend and want to support. i.e. it would be a good time for the
installer to stop presenting all bootloader related things in the GUI.
If the installer team folks want to support esoteric customizations in
kickstart, super, I have no complaint. But the GUI, whether auto,
custom, advanced, should just stop inviting users to do hapless
things. If users precreate their own partitions outside the installer,
with a proper GPT GUID, and the installer recognizes and automatically
uses those partitions based on GUID, that'd be cool too. I'm very
reluctant to ask that more and more things be supported without a plan
for either growing resources to support such things. Maintainability
is already a problem in the boot realm, both in Fedora and upstream
(at least in GRUB).



>
> > Chris suggested using a BIOS Boot partition, but another possible
> > option is to use XBOOTLDR from
> > https://systemd.io/BOOT_LOADER_SPECIFICATION/ - which the BLS actually
> > prefers over the ESP if found.
> >
>
> Chris' suggestion (unless I misunderstood) is not to use a partition
> with a filesystem but instead a partition where the grubenv could be
> stored as raw data. That way GRUB should be able to read and write the
> grubenv block without using any of its filesystem code (that's
> supposed to be read-only).

Correct. But also I consider it an implementation detail, decided by
those who will implement and maintain it.

This hypothetical partition can be used by syslinux, sd-boot, uboot,
and others, with whatever they want to put there, in whatever format
or scheme they want to implement. It's just a generic bootloader
partition, exclusively owned by the bootloader, for whatever purpose
it wants to use it for. Likewise, its size is a detail that users
don't need to care about. The upstreams can come up with a recommended
size. As this hypothetical partition is modeled after the GPT "BIOS
Boot" partition it could be 1MiB. If the core.img is pushing that, and
if there's some idea to implement an A/B approach in this partition
for atomic updating, then 2MiB is fine, even 20MiB is fine - to me
those are all the same size :D Even coming from the SD Card in a
Raspberry Pi type use case.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Jan Zerdik

[Frédéric Pierret]

Le 1/13/21 à 4:25 PM, Jan Zerdik a écrit :

Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-maintainer. My 
experience with open source projects is mostly just as a user, but I'm looking 
forward to joining the community.

___
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



Hi Jan,

Welcome and I wish you the best around here.

Frédéric



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

Moving Experts US

[Social M]

When you are planning to make a long-distance move, Moving Experts US can 
provide you with quality long distance movers Chicago has! Are you planning to 
relocate to another place? If you are, do not forget that hiring long distance 
movers Chicago is going to be helpful a lot. Still, it is a crucial thing to 
have reliable and decent movers who will assist you properly during the entire 
process. If you are looking for that type of movers, our Moving Experts US is 
the right option for you! From us, you can expect that you will be provided 
with high-quality moving services and that you will relocate to your new home 
in the easiest way. Just give us a call on time and we will provide you with 
all the information you require! 

Website: https://usmovingexperts.com/
Phone: 7738400957
Address: 640 W Englewood Ave, Chicago, IL 60621, USA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Unify the GRUB configuration files location across all supported architectures (System-Wide Change proposal)

[Chris Murphy]

On Tue, Jan 12, 2021 at 8:48 PM Michel Alexandre Salim
 wrote:
>
> Hi,
>
>
> On Tue, 2021-01-12 at 19:56 +0100, Hans de Goede wrote:

> > So I've read Neal's comment there and what he describes really
> > is a special corner case, but yes it is possible for people to have
> > created the special setup he describes and yes in that case moving
> > grubenv to /boot will break the hidden-menu functionality.
> >
> > I'm not sure if this warrants a -1 to the proposal though,
> > I believe documenting this + some workaround for it should be
> > sufficient.
> >
> > But as mentioned in the fesco issue this has more to do with the
> > fact that storing the grubenv in a filesystem-file is a bad idea
> > in general.
> It's not necessarily bad unless the filesystem is journaled, right,
> since GRUB's filesystem drivers basically don't support this? (so
> basically it's only FAT-like filesystems and ext2 that's perfectly
> safe).

There are separate issues.

grubenv is "OK" on ext4 and XFS. The issue is that none of the file
systems developers like anything other than kernel code doing writes.
One idea for this is a new MBR and GPT partition type, functionally
identical to the GPT "BIOS Boot" type, that's exclusively for the
bootloader to use however it wants. On BIOS it'd include core.img and
grubenv. On UEFI it'd just be used for grubenv. This issue needs to be
taken upstream to sort out the details, so it should be set aside as
it relates to this proposal.

The issue with journaled file systems is that GRUB's file system
drivers have no ability to do journal replay. Therefore there is a
small risk the file system is rendered unbootable in a crash, because
the bootloader only sees the no-replay state of the file system used
for /boot. e.g. the bootloader can see grub.cfg, bls snippets, or even
the kernel as either missing or as 0 length files, until the journal
has been replayed. Small risk, big penalty. My suggestion for
mitigation is to use FAT for /boot in simple cases, and Btrfs in less
simple cases. It's just an idea, it's not urgent, but if things are
being reconsidered for simplification anyway, this makes sense to me.

Ergo the idea for a "bootloader partition that is exclusively owned by
the bootloader" is separate from "bootloaders don't do journal replay
and therefore can have the wrong view of things, and fail to boot in
rare cases following a crash."

> Chris suggested using a BIOS Boot partition, but another possible
> option is to use XBOOTLDR from
> https://systemd.io/BOOT_LOADER_SPECIFICATION/ - which the BLS actually
> prefers over the ESP if found.

I tentatively agree. We should ensure coordination with coreos/bootupd
folks and boot loader spec folks that we're all on the same page.



--
Chris Murphy
___
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

[apt-cacher-ng] Resurrect dead package

[Frédéric Pierret]

Hi,
I've resurrected `apt-cacher-ng` on my fork: 
https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb23a43b4279dab045040717a025c83c?branch=master
 with successful builds on my testing COPR repository for F32+ and EPEL8: 
https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/.

I plan to (already) use this package for my current work on reproducible builds.

Is the procedure described in 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?rd=PackageMaintainers/OrphanedPackages#Claiming_Ownership_of_a_Retired_Package
 still available for such case?

Thank you.

Best regards,
Frédéric Pierret



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

Re: Schedule for Wednesday's FESCo Meeting (2021-01-13)

[Björn Persson]

Zbigniew Jędrzejewski-Szmek wrote:
> I'm not sure why it's in UTC and not some DST zone. It might even have
> been on purpose.

I wasn't involved in that decision but I can tell you one simple and
obvious reason to specify times in UTC: Everybody needs to know only
their own current offset from UTC, and can convert to their local time
with a single addition.

If a time and an offset are specified, then everybody needs to subtract
that offset and then add their own offset, so that requires slightly
more mental arithmetic.

If an acronym like "HKT" is given instead of an offset, then everybody
must either know what offset that acronym stands for, or look it up
before they can convert the time. That's much less friendly to the
reader.

Even worse is to specify a timezone by geographical name. Then the
reader needs to find out whether time jumps are practised in that zone,
and on what days, before they can know what the offset is in that zone
at the time. Then they can subtract that offset, and finally add their
own offset. Times specified this way will also be ambiguous each time
that timezone jumps backwards.

So obviously UTC works best for agreeing on a meeting time across
borders.

Björn Persson


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

Re: Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Jean-Baptiste Holcroft]

I fully agree.

My idea would be to help contributors to understand where to go translate each 
project upstream.

The Language-Team attribute probably is good enough to lead a contributor at 
the right place, here are a few examples for French language:

0ad: "Language-Team: French 
(http://www.transifex.com/wildfire-games/0ad/language/fr/)\n"
ABRT: "Language-Team: French 

Re: Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Jean-Baptiste Holcroft]

Weblate is a translation platform.
Using it to display translations of projects who did not choose to be part of 
our translation would be equivalent to fork what upstream do.

Ubuntu does it with launchpad, but the limit between upstream work and 
distribution work isn't clear enough.
Translators do some work in launchpad but the translation don't go upstream 
automatically (which means most of the time it never goes upstream).

This would probably be really confusing for end-users and Fedora community 
would find it incompatible with Fedora values.

In addition, Weblate is a great tool, but really complex and moving quite fast.
We do share technical components (translate toolkit and language lists), but 
more won't make sense for our usecase.
___
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

Summary/Minutes from today's FESCo Meeting (2021-01-13)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-13/fesco.2021-01-13-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-13/fesco.2021-01-13-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2021-01-13/fesco.2021-01-13-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:19)

* #2532 F34 Change: Enable spec file preprocessing  (zbyszek, 15:03:16)
  * AGREED: REJECTED (0, ±1, -7)  (zbyszek, 15:12:16)
  * Two votes were cast as "for 34", the others without such
qualification.  (zbyszek, 15:12:46)

* Next week's chair  (zbyszek, 15:12:56)
  * ACTION: sgallagh will chair next meeting  (zbyszek, 15:13:18)

* Open Floor  (zbyszek, 15:13:18)

Meeting ended at 15:15:30 UTC.




Action Items

* sgallagh will chair next meeting

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] please review: PR 4543 - Search results are different between RHDS10 and RHDS11

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4543

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

[Bug 1914982] Upgrade perl-Email-MIME-ContentType to 1.026

[bugzilla]

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

Tom "spot" Callaway  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2021-01-13 18:47:29



--- Comment #1 from Tom "spot" Callaway  ---
perl-Email-MIME-ContentType-1.026-1.fc34 in rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Release 5.6.1 of Sundials

[Antonio T. sagitter]

bout++ package is still missing. Please, rebuild it.


--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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

Re: Chromium built in rawhide does not render most strings

[Tom Callaway]

https://bugs.chromium.org/p/chromium/issues/detail?id=1164975

Please add in this info, it was on my TODO list, but clearly hasn't
happened yet.

~spot

On Wed, Jan 13, 2021 at 8:33 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote:
> > Florian Weimer wrote:
> > > Right, and the glibc 2.33 versions all call fstatat64 in the end
> (system
> > > call number 0x106).
> >
> > That would be:
> >
> > #if !defined(__NR_newfstatat)
> > #define __NR_newfstatat 262
> > #endif
> >
> > from:
> >
> >
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h
> >
> > > The older x versions call the earlier system calls
> > > (numbers 4, 5, 6)
> >
> > And these are defined as:
> >
> > #if !defined(__NR_stat)
> > #define __NR_stat 4
> > #endif
> >
> > #if !defined(__NR_fstat)
> > #define __NR_fstat 5
> > #endif
> >
> > #if !defined(__NR_lstat)
> > #define __NR_lstat 6
> > #endif
> >
> > I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like
> > __NR_stat and __NR_lstat, whereas __NR_fstat is under
> > IsAllowedFileSystemAccessViaFd. So the issue is that everything now
> calls
> > the same syscall under the hood, so the sandbox can no longer
> distinguish
> > the two access types just by looking at the syscall ID.
> >
> > The baseline policy disallows everything under IsFileSystem and allows
> only
> > IsAllowedFileSystemAccessViaFd:
> >
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc
> > (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and
> > __NR_newfstatat are not).
>
> I think you wanted to link
>
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc
> here instead.
> __NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that
> plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94).
>
> > It looks like it needs to restrict the arguments to __NR_newfstatat (to
> an
> > empty path and the AT_EMPTYPATH flag) instead of rejecting it outright,
> so
> > that fstat keeps working, see:
> >
> https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD
>
> Is there an upstream bug open for this already?
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
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

Attempting to allow for a source of truth for Fedora release cycle information: releasestream

[Adam Williamson]

Hi folks!

Before the RH holiday shutdown, I started a new project designed to
address a long-standing pain point in Fedora: we don't really have a
good source of truth for release cycle information. I'm thinking of
situations where something:

* Needs to know what the "current stable" Fedora release(s) are
* Needs to know if Fedora X is Branched
* Needs to know whether Fedora X Beta happened yet
* Needs to know whether Fedora X is frozen

...etc etc etc. Some of this information is available...sort of...from
various different systems, with various awkward caveats that I won't
dive into unless someone asks. But there isn't really a single source
of truth for it, and some of it just isn't really available in any
easily machine-consumable way.

So I wrote releasestream:
https://pagure.io/fedora-qa/releasestream

releasestream is intended to be a system that will let us do this. It
is a very very simple webapp with three capabilities:

* It can read a simple record ("stream") of "release events" for a
"release" and produce several static JSON representations of the
information
* It can write an entry to one of these streams in response to a
properly-formatted POST request
* It can publish a message when a new entry is received

that is all it does. The "releases" and "events" are entirely
arbitrary; a "release" can be any string, and so can the "state" for a
given "event". An "event" is defined as a state being either reached or
left; any number of events for the same state can be present for a
release.

The JSON outputs are basically "states by release" and "releases by
state", as you might want either depending on what you're doing. You
can conveniently look up "what releases are currently in state X?" or
"what states is release X currently in?".

This all works right now; the main thing that isn't implemented yet is
any form of authentication. Right now if you can talk to the server you
can submit events. I wanted to check if there is interest in moving
forward with this, and discuss various options, before working on that.
There is a ticket where I sketched out various possible approaches:
https://pagure.io/fedora-qa/releasestream/issue/2

My idea for using this is basically that we deploy an 'official'
releasestream instance in infra, and then find things that do the
actual work of moving Fedora releases into and out of given "states"
and tack on a bit at the end to tell releasestream about it. So when
e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
"submit 'enter freeze' event to releasestream" to that process somehow
- ideally something that has to be run as part of the process anyway
would send the POST, but in a pinch a human could do it too. When
Fedora 34 is being 'released', we tweak that process to include sending
a releasestream event POST. And so on.

The thing I like about this design is that there's a low barrier to
entry, and can easily be adopted piecemeal but still be immediately
useful for some things - as long as the event your code needs to watch
for has been "onboarded", you're good. It also allows for the
implementation details of a state change to change radically - it can
go from being done by a human to being done by system X to being done
by system Y, and all that needs to happen is to ensure the same dead
simple POST request is sent to the same server.

So, what do folks think? Does this seem like a good idea? Should I go
ahead with trying to get it deployed and onboard things to it? Any
comments, ideas, potential problems? Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1915904] New: perl-PAR-Packer-1.052 is available

[bugzilla]

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

Bug ID: 1915904
   Summary: perl-PAR-Packer-1.052 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PAR-Packer
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.052
Current version/release in rawhide: 1.051-1.fc34
URL: http://search.cpan.org/dist/PAR-Packer/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Migrating the Fedora Developer Portal to Fedora Docs

[Matthew Miller]

On Wed, Jan 13, 2021 at 10:15:47AM +, Ankur Sinha wrote:
> What do you think?

I think it's a good idea. Having one place to look makes things easier for
users, especially once we finally get search.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1915891] New: perl-Module-ScanDeps-1.30 is available

[bugzilla]

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

Bug ID: 1915891
   Summary: perl-Module-ScanDeps-1.30 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-ScanDeps
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jose.p.oliveira@gmail.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.30
Current version/release in rawhide: 1.29-1.fc34
URL: http://search.cpan.org/dist/Module-ScanDeps/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915876] perl-PAR-1.017 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|anon.am...@gmail.com,   |
   |mmasl...@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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915876] New: perl-PAR-1.017 is available

[bugzilla]

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

Bug ID: 1915876
   Summary: perl-PAR-1.017 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PAR
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.017
Current version/release in rawhide: 1.016-7.fc33
URL: http://search.cpan.org/dist/PAR/

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Self Introduction: Jan Zerdik

[Jan Zerdik]

Hi. My name is Jan and I'm a new red hatter. I'll be a TuneD co-maintainer.
My experience with open source projects is mostly just as a user, but I'm
looking forward to joining the community.
___
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

usrsctp soversion bump

[Vitaly Zaitsev via devel]

Hello all.

Usrsctp 0.9.5.0 update will include a soversion bump from 1 to 2.

I will rebuild dependent package psi-plus.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: cmake FTBFS in rawhide

[Rex Dieter]

Benjamin Beasley wrote:


> I think you will need to either skip the multi-threaded TXZ test, or bound
> its memory requirements by patching it to use some fixed value for
> CPACK_ARCHIVE_THREADS instead of 0. See
> https://cmake.org/cmake/help/latest/cpack_gen/archive.html#variables-used-by-cpack-archive-generator.

Thanks!  Opted to set CPACK_ARCHIVE_THREADS to some reasonable number (like 
4 for now).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ceph's builds started to fail in Fedora rawhide

[Miro Hrončok]

On 13. 01. 21 14:58, Kaleb Keithley wrote:


On Wed, Jan 13, 2021 at 8:19 AM Miro Hrončok > wrote:


On 13. 01. 21 14:17, Kaleb Keithley wrote:
 >
 > On Tue, Jan 12, 2021 at 3:27 AM mailto:notificati...@fedoraproject.org>
 > >> wrote:
 >
 >     Notification time stamped 2021-01-12 08:26:20 UTC
 >
 >     ceph's builds started to fail in Fedora rawhide
 > https://apps.fedoraproject.org/koschei/package/ceph?collection=f34

 >     >
 >
 >
 > I updated my rawhide box yesterday and it builds fine on that.
 >
 > There is no compiler/compilation error in the build logs, just make
 > terminating.  OOM killed perhaps?
 >
 > What has changed recently in the builders? Memory? Disk space? gcc 
version

gcc version, see https://bugzilla.redhat.com/show_bug.cgi?id=1915803



/me wonders why updating my rawhide box yesterday did not get gcc-11.0.0-0.12. 
Mine is still -0.11.


It was presumably not yet in the compose, only in the buildroot. It takes a 
while.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ceph's builds started to fail in Fedora rawhide

[Kaleb Keithley]

On Wed, Jan 13, 2021 at 8:19 AM Miro Hrončok  wrote:

> On 13. 01. 21 14:17, Kaleb Keithley wrote:
> >
> > On Tue, Jan 12, 2021 at 3:27 AM  > > wrote:
> >
> > Notification time stamped 2021-01-12 08:26:20 UTC
> >
> > ceph's builds started to fail in Fedora rawhide
> > https://apps.fedoraproject.org/koschei/package/ceph?collection=f34
> > 
> >
> >
> > I updated my rawhide box yesterday and it builds fine on that.
> >
> > There is no compiler/compilation error in the build logs, just make
> > terminating.  OOM killed perhaps?
> >
> > What has changed recently in the builders? Memory? Disk space? gcc
> version
>
> gcc version, see https://bugzilla.redhat.com/show_bug.cgi?id=1915803
>
>
/me wonders why updating my rawhide box yesterday did not get
gcc-11.0.0-0.12. Mine is still -0.11.

Updating and trying again.

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Chromium built in rawhide does not render most strings

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 13 January 2021 at 03:14, Kevin Kofler via devel wrote:
> Florian Weimer wrote:
> > Right, and the glibc 2.33 versions all call fstatat64 in the end (system
> > call number 0x106).
> 
> That would be:
> 
> #if !defined(__NR_newfstatat)
> #define __NR_newfstatat 262
> #endif
> 
> from:
> 
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/system_headers/x86_64_linux_syscalls.h
> 
> > The older x versions call the earlier system calls
> > (numbers 4, 5, 6)
> 
> And these are defined as:
> 
> #if !defined(__NR_stat)
> #define __NR_stat 4
> #endif
> 
> #if !defined(__NR_fstat)
> #define __NR_fstat 5
> #endif
> 
> #if !defined(__NR_lstat)
> #define __NR_lstat 6
> #endif
> 
> I see that the sandbox is treating __NR_newfstatat as IsFileSystem, like 
> __NR_stat and __NR_lstat, whereas __NR_fstat is under 
> IsAllowedFileSystemAccessViaFd. So the issue is that everything now calls 
> the same syscall under the hood, so the sandbox can no longer distinguish 
> the two access types just by looking at the syscall ID.
> 
> The baseline policy disallows everything under IsFileSystem and allows only 
> IsAllowedFileSystemAccessViaFd:
> https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/baseline_policy.cc
> (i.e., __NR_fstat is allowed, whereas __NR_stat, __NR_lstat, and 
> __NR_newfstatat are not).

I think you wanted to link
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/sandbox/linux/seccomp-bpf-helpers/syscall_sets.cc
here instead.
__NR_newfstatat is at line 116 and __NR_fstat is at line 170. Note that
plain __NR_stat and __NR_lstat are also rejected (lines 101 and 94).

> It looks like it needs to restrict the arguments to __NR_newfstatat (to an 
> empty path and the AT_EMPTYPATH flag) instead of rejecting it outright, so 
> that fstat keeps working, see:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=io/fstat.c;h=dc117361ffe7064be7c6746465388803e203adcf;hb=HEAD

Is there an upstream bug open for this already?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp
Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 7/180 (x86_64), 9/122 (aarch64)

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

ID: 755303  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/755303
ID: 755531  Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/755531

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

ID: 755302  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/755302
ID: 755324  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/755324
ID: 755329  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/755329
ID: 755334  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/755334
ID: 755343  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/755343
ID: 755394  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/755394
ID: 755406  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/755406
ID: 755408  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/755408
ID: 755497  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/755497
ID: 755524  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/755524
ID: 71  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/71
ID: 755560  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/755560
ID: 755565  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/755565
ID: 755573  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/755573

Soft failed openQA tests: 3/122 (aarch64), 11/180 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 755400  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/755400
ID: 755451  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/755451
ID: 755452  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/755452
ID: 755453  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/755453
ID: 755454  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/755454
ID: 755455  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/755455
ID: 755511  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/755511
ID: 755514  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/755514

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

ID: 755271  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/755271
ID: 755275  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/755275
ID: 755322  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/755322
ID: 755365  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/755365
ID: 755375  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/755375
ID: 755441  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/755441

Passed openQA tests: 162/180 (x86_64), 93/122 (aarch64)

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

ID: 755317  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/755317
ID: 755326  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/755326
ID: 755345  Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/755345
ID: 755357  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/755357
ID: 755379  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: 

Re: ceph's builds started to fail in Fedora rawhide

[Miro Hrončok]

On 13. 01. 21 14:17, Kaleb Keithley wrote:


On Tue, Jan 12, 2021 at 3:27 AM > wrote:


Notification time stamped 2021-01-12 08:26:20 UTC

ceph's builds started to fail in Fedora rawhide
https://apps.fedoraproject.org/koschei/package/ceph?collection=f34



I updated my rawhide box yesterday and it builds fine on that.

There is no compiler/compilation error in the build logs, just make 
terminating.  OOM killed perhaps?


What has changed recently in the builders? Memory? Disk space? gcc version


gcc version, see https://bugzilla.redhat.com/show_bug.cgi?id=1915803

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ceph's builds started to fail in Fedora rawhide

[Kaleb Keithley]

On Wed, Jan 13, 2021 at 8:17 AM Kaleb Keithley  wrote:

>
> On Tue, Jan 12, 2021 at 3:27 AM  wrote:
>
>> Notification time stamped 2021-01-12 08:26:20 UTC
>>
>> ceph's builds started to fail in Fedora rawhide
>>
>> https://apps.fedoraproject.org/koschei/package/ceph?collection=f34
>>
>>
> I updated my rawhide box yesterday and it builds fine on that.
>
> There is no compiler/compilation error in the build logs, just make
> terminating.  OOM killed perhaps?
>

I.e. in the build.logs of the the koji scratch builds I have run.



>
> What has changed recently in the builders? Memory? Disk space? gcc version
>
> --
>
> Kaleb
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ceph's builds started to fail in Fedora rawhide

[Kaleb Keithley]

On Tue, Jan 12, 2021 at 3:27 AM  wrote:

> Notification time stamped 2021-01-12 08:26:20 UTC
>
> ceph's builds started to fail in Fedora rawhide
> https://apps.fedoraproject.org/koschei/package/ceph?collection=f34
>
>
I updated my rawhide box yesterday and it builds fine on that.

There is no compiler/compilation error in the build logs, just make
terminating.  OOM killed perhaps?

What has changed recently in the builders? Memory? Disk space? gcc version

--

Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20210113.n.0 changes

[Mamoru TASAKA]

Fedora Rawhide Report wrote on 2021/01/13 20:49:

OLD: Fedora-Rawhide-20210112.n.0
NEW: Fedora-Rawhide-20210113.n.0

= SUMMARY =
Added images:1
Dropped images:  5
Added packages:  11
Dropped packages:4
Upgraded packages:   159
Downgraded packages: 0

Size of added packages:  111.31 MiB
Size of dropped packages:1.10 MiB
Size of upgraded packages:   2.13 GiB
Size of downgraded packages: 0 B

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

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

= DROPPED IMAGES =
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20210112.n.0.iso


Reported:
https://bugzilla.redhat.com/show_bug.cgi?id=1915725
eclipse-egit is working on this.


Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210112.n.0.x86_64.vagrant-libvirt.box



Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20210112.n.0.iso

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

Really pipewire-jack-audio-connection-kit <-> jack-audio-connection-kit
conflict is annoying...



Image: KDE_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210112.n.0-sda.raw.xz
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210112.n.0.x86_64.vagrant-virtualbox.box



Regards,
Mamoru
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 virt-install + ks has some problem switching root

[Richard W.M. Jones]

On Wed, Jan 13, 2021 at 11:34:09AM +, Daniel P. Berrangé wrote:
> On Wed, Jan 13, 2021 at 10:16:43AM +, Richard W.M. Jones wrote:
> > We use the same process to make these as we have always used, this
> > kickstart:
> > 
> >   
> > https://github.com/libguestfs/libguestfs/blob/master/builder/templates/fedora-33.ks
> 
> Have you tried removing the whole of the %post script there ? The main
> ks rules that all look sane enough. It feels like that dracut invokation
> in %post is most likely thing to be causing a problem. Or perhaps the
> args to the 'bootloader' statement need an change in some manner ? 

Weirdly it works when I comment out the dnf update:

 %post
 # Ensure the installation is up-to-date.
-dnf -y --best upgrade
+#dnf -y --best upgrade

which I certainly wasn't expecting.  At least I can ship a working
image now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1914983] Upgrade perl-Gtk2-SourceView2 to 0.12

[bugzilla]

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

Thomas Moschny  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2021-01-13 12:30:39



--- Comment #1 from Thomas Moschny  ---
Update in rawhide
https://bodhi.fedoraproject.org/updates/FEDORA-2021-a6e69b1107

Not updated for released Fedora versions, as there are seem to be no real
changes besides addition of the deprecation notice.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Fedora rawhide compose report: 20210113.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210112.n.0
NEW: Fedora-Rawhide-20210113.n.0

= SUMMARY =
Added images:1
Dropped images:  5
Added packages:  11
Dropped packages:4
Upgraded packages:   159
Downgraded packages: 0

Size of added packages:  111.31 MiB
Size of dropped packages:1.10 MiB
Size of upgraded packages:   2.13 GiB
Size of downgraded packages: 0 B

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

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

= DROPPED IMAGES =
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20210112.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210112.n.0.x86_64.vagrant-libvirt.box
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20210112.n.0.iso
Image: KDE_Appliance raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20210112.n.0-sda.raw.xz
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210112.n.0.x86_64.vagrant-virtualbox.box

= ADDED PACKAGES =
Package: ghc-haxr-3000.11.4.1-2.fc34
Summary: XML-RPC client and server library
RPMs:ghc-haxr ghc-haxr-devel ghc-haxr-doc ghc-haxr-prof
Size:3.95 MiB

Package: golang-github-dgryski-rendezvous-0-0.1.20210112git9f7001d.fc34
Summary: Rendezvous hashing
RPMs:golang-github-dgryski-rendezvous-devel
Size:10.01 KiB

Package: golang-github-ledisdb-0.6-1.20210112gitd35789e.fc34
Summary: A high performance NoSQL Database Server powered by Go
RPMs:compat-golang-github-siddontang-ledisdb-devel golang-github-ledisdb 
golang-github-ledisdb-devel
Size:89.58 MiB

Package: golang-github-redis-8-8.4.8-2.fc34
Summary: Type-safe Redis client for Golang
RPMs:golang-github-redis-8-devel
Size:114.20 KiB

Package: golang-opentelemetry-otel-0.15.0-1.fc34
Summary: OpenTelemetry Go API and SDK
RPMs:golang-opentelemetry-otel-devel
Size:365.74 KiB

Package: mutter3.38-3.38.2-1.fc34
Summary: Window and compositing manager based on Clutter
RPMs:mutter3.38 mutter3.38-devel mutter3.38-libs mutter3.38-tests
Size:15.22 MiB

Package: nodejs-tape-5.1.1-1.fc34
Summary: Tap-producing test harness for Node.js and browsers
RPMs:nodejs-tape
Size:953.23 KiB

Package: python-niaaml-1.1.0-1.fc34
Summary: Python automated machine learning framework
RPMs:python-niaaml-doc python3-niaaml
Size:305.01 KiB

Package: rust-bytemuck_derive-1.0.1-1.fc34
Summary: Derive proc-macros for `bytemuck`
RPMs:rust-bytemuck_derive+default-devel rust-bytemuck_derive-devel
Size:25.95 KiB

Package: rust-dummy-0.4.0-1.fc34
Summary: Macros implementation of #[derive(Dummy)]
RPMs:rust-dummy+default-devel rust-dummy-devel
Size:22.53 KiB

Package: rust-leb128-0.2.4-1.fc34
Summary: DWARF's LEB128 encoding library and REPL
RPMs:leb128 rust-leb128+default-devel rust-leb128-devel
Size:815.79 KiB


= DROPPED PACKAGES =
Package: bip-0.9.0-0.10.20181225gitc9cc64f.fc33
Summary: IRC Bouncer
RPMs:bip
Size:859.01 KiB

Package: gnome-shell-extension-desktop-icons-20.04.0-2.fc33
Summary: GNOME Shell extension for providing desktop icons
RPMs:gnome-shell-extension-desktop-icons
Size:63.98 KiB

Package: perl-Test-Alien-0.15-12.fc33
Summary: Testing tools for Alien modules
RPMs:perl-Test-Alien
Size:38.25 KiB

Package: qt-avif-image-plugin-0.4.0-2.fc34
Summary: Qt plug-in to read/write AVIF images
RPMs:qt-avif-image-plugin
Size:169.72 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-libreswan-1.2.14-1.fc34
Old package:  NetworkManager-libreswan-1.2.12-1.fc33.2
Summary:  NetworkManager VPN plug-in for IPsec VPN
RPMs: NetworkManager-libreswan NetworkManager-libreswan-gnome
Size: 786.30 KiB
Size change:  32.59 KiB
Changelog:
  * Tue Jan 12 2021 Beniamino Galvani  - 1.2.14-1
  - Update to 1.2.14 release


Package:  awscli-1.18.212-1.fc34
Old package:  awscli-1.18.211-1.fc34
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.95 MiB
Size change:  4.93 KiB
Changelog:
  * Tue Jan 12 2021 Gwyn Ciesla  - 1.18.212-1
  - 1.18.212


Package:  bacula-11.0.0-1.fc34
Old package:  bacula-9.6.6-1.fc34
Summary:  Cross platform network backup for Linux, Unix, Mac and Windows
RPMs: bacula-client bacula-common bacula-console bacula-console-bat 
bacula-devel bacula-director bacula-libs bacula-libs-sql bacula-logwatch 
bacula-storage bacula-traymonitor nagios-plugins-bacula
Size: 26.79 MiB
Size change:  13.96 MiB
Changelog:
  * Tue Jan 12 2021 Simone Caronni  - 9.6.7-1
  - Update to 9.6.7.
  - Drop support for building on CentOS/RHEL 6 and upgrades from version 2.4.
  - Trim changelog.

  * Tue Jan 12 2021 Simone Caronni  - 11.0.0-1

Re: Orphaned python-flexmock

[Hunor Csomortáni]

Hey Lumír,

I've added you as admin to the repo.

Thanks!
Hunor

On Wed, Jan 13, 2021 at 12:03 PM Lumír Balhar  wrote:
>
> I'm a maintainer of micropipenv so I can co-maintain flexmock, if you want.
>
> Have a nice day.
>
> Lumír
>
> On 1/13/21 9:30 AM, Hunor Csomortáni wrote:
> > I will take it over.
> >
> > On Wed, Jan 13, 2021 at 1:38 AM Miro Hrončok  wrote:
> >> I've orphaned python-flexmock.
> >>
> >> It is essentially dead/complete upstream and I have no use for it.
> >>
> >> Dependents:
> >>
> >> micropipenv-0:1.0.2-1.fc34.src
> >> osbs-client-0:0.62-1.fc33.src
> >> pyp2rpm-0:3.3.5-1.fc34.src
> >> python-anymarkup-core-0:0.8.1-3.fc33.src
> >> python-sqlalchemy-utils-0:0.34.2-5.fc33.src
> >> sen-0:0.6.1-7.fc33.src
> >> spec2scl-0:1.2.2-6.fc33.src
> >>
> >> --
> >> Miro Hrončok
> >> --
> >> Phone: +420777974800
> >> IRC: mhroncok
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct: 
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives: 
> >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1915067] perl-Devel-PatchPerl-2.08 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1915067] perl-Devel-PatchPerl-2.08 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|iarn...@gmail.com   |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora 33 virt-install + ks has some problem switching root

[Daniel P . Berrangé]

On Wed, Jan 13, 2021 at 10:16:43AM +, Richard W.M. Jones wrote:
> Sorry for this rather ill-defined bug report, but I'm hoping someone
> will recognize the symptoms or at least suggest a way to debug this.
> 
> Ever since Fedora 33 was released we've been unable to produce a
> working virt-builder template.  The template that we have made fails
> at switch root.
> 
> template:   https://builder.libguestfs.org/fedora-33.xz
> bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1911177
> 
> An additional problem is I cannot find any way to debug the problem.

I would probably suggest to run an interactive anaconda install
that reasonably closely matches the options you desire. This
should give a working installed image that contains a corresponding
working /root/install.ks file.

Compare that to the ks virt-builder is using and bisect the differences.

> Something (systemd? dracut?) asks for a root password in order to get
> to the emergency shell, and I can find no way around this nor any
> password which works.  I wish there was a "stop asking for a password"
> option on the kernel command line.
> 
> We use the same process to make these as we have always used, this
> kickstart:
> 
>   
> https://github.com/libguestfs/libguestfs/blob/master/builder/templates/fedora-33.ks

Have you tried removing the whole of the %post script there ? The main
ks rules that all look sane enough. It feels like that dracut invokation
in %post is most likely thing to be causing a problem. Or perhaps the
args to the 'bootloader' statement need an change in some manner ? 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[389-devel] Re: Deref plugin entries == NULL #4525

[Pierre Rogier]

Thank you Willian,
So far your scenario (entry found when reading base entry but no more
existing when computing the candidates) is the only one that matches the
symptoms.
And that triggered a thought:
 We cannot do anything for SUBTREE and ONE_LEVEL searches
  because the fact that the base entry id is not in the candidate may be
normal
 but IMHO we should improve the BASE search case.
In this case the candidate list is directly set to the base entry id
 ==> if the candidate entry (in ldbm_back_next_search_entry) is not found
and the scope is BASE then we should return a LDAP_NO_SUCH_ENTRY error ..

   Pierre


On Wed, Jan 13, 2021 at 1:45 AM William Brown  wrote:

> Hey there,
>
> https://github.com/389ds/389-ds-base/pull/4525/files
>
> I had a look and I can see a few possible contributing factors, but
> without a core and the exact state I can't be sure if this is correct. It's
> all just hypothetical from reading the code.
>
>
> The crash is in deref_do_deref_attr() which is called as part of
> deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by
> "./ldap/servers/slapd/result.c:1488:rc = plugin_call_plugins(pb,
> SLAPI_PLUGIN_PRE_ENTRY_FN);"
>
>
> I think what's important here is that the search is conducted in
> ./ldap/servers/slapd/opshared.c:818  rc = (*be->be_search)(pb);  Is *not*
> in a transaction. That means that while the single search in be_search() is
> consistent due to an implied transaction, the subsequent search in
> deref_pre_entry() is likely conducted in a seperate transaction. This
> allows for other operations to potentially interleave and cause changes -
> modrdn or delete would certainly be candidates to cause a DN to be remove
> between these two points. It would be extremely hard to reproduce as a race
> condition of course.
>
>
> A question you asked is why don't we get a "no such entry" error or
> similar? I think that this is because build_candidate_list in ldbm_search.c
> doesn't actually create an error if the base_candidates list is empty,
> because an IDL is allocated with a value of 0 (no matching entries). this
> allows the search to proceed, and there are no errors, and the result set
> is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in
> this process, but without looking further into it, my suspicion is that
> entries of size 0 WONT return an error condition to internal_search_pb, so
> it's valid for this to be empty.
>
> Anyway, again, this is just reading the code for 20 minutes, and is not a
> complete in depth investigation, but maybe it's some ideas about what
> happened?
>
> Hope it helps :)
>
>
>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
>


-- 
--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Re: Fedora 33 virt-install + ks has some problem switching root

[Richard W.M. Jones]

On Wed, Jan 13, 2021 at 12:02:33PM +0100, Tomasz Torcz wrote:
> On Wed, Jan 13, 2021 at 10:16:43AM +, Richard W.M. Jones wrote:
> > Sorry for this rather ill-defined bug report, but I'm hoping someone
> > will recognize the symptoms or at least suggest a way to debug this.
> > 
> > Ever since Fedora 33 was released we've been unable to produce a
> > working virt-builder template.  The template that we have made fails
> > at switch root.
> > 
> > template:   https://builder.libguestfs.org/fedora-33.xz
> > bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1911177
> > 
> > An additional problem is I cannot find any way to debug the problem.
> 
>   In this image, initrd-switch-root.service fails because "/sysroot does
> not contain /etc/os-release".  This is visible when you boot with
> "systemd.log_level=debug systemd.journald.forward_to_console=1"
> as described on https://freedesktop.org/wiki/Software/systemd/Debugging/

Interesting thanks - I can reproduce the error using your suggested
command line:

[3.167930] systemctl[272]: Failed to switch root: Specified switch root 
path '/sysroot' does not seem to be an OS tree. os-release file is missing.
[3.174123] systemd[1]: initrd-switch-root.service: Main process exited, 
code=exited, status=1/FAILURE
[3.176615] systemd[1]: initrd-switch-root.service: Failed with result 
'exit-code'.
[3.179342] systemd[1]: Failed to start Switch Root.
[FAILED] Failed to start Switch Root.

I wonder what causes it to say that?  The disk image itself has
/etc/os-release -> ../usr/lib/os-release and /usr/lib/os-release is a
regular file.  The symlink ought to work since it is a relative path.

The kernel finds the virtio disk so it has at least the block
drivers.

> > Something (systemd? dracut?) asks for a root password in order to get
> > to the emergency shell, and I can find no way around this nor any
> > password which works.  I wish there was a "stop asking for a password"
> > option on the kernel command line.
> 
>   This one is weird. I tried "rd.shell" and "rd.break", which should
> just drop to dracut shell, but it didn't work.
> 
>  BTW, partition setup looks weird, too. vda1 is 1MB empty partition,
> then vda2 is /boot and vda3 is rootfs.  Is this how we organise disks by
> default?

AFAIK we don't do anything unusual.  We're using autopart --type=plain
in the kickstart which should make a non-LVM partition.  I suppose
vda1 must have something to do with UEFI.

Thanks anyway, this gets us a little bit further.

Rich.

> -- 
> Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
> Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
> o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

[Peter Robinson]

On Tue, Jan 12, 2021 at 8:21 PM Brian C. Lane  wrote:
>
> On Tue, Jan 05, 2021 at 01:05:01PM -0500, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
> >
> > Note that this change was submitted after the deadline, but since it can be
> > shipped in an complete state, I am still processing it for Fedora 34.
> >
> >
> > == Summary ==
> > We want to add signatures to individual files that are part of shipped RPMs.
> > These signatures will use the Linux IMA (Integrity Measurement
> > Architecture) scheme, which means they can be used to enforce runtime
> > policies to ensure execution of only trusted files.
>
> Who is going to use this feature? My guess is a very limited set of
> users, so it seems unfair to dramatically increase the size of their
> downloads and install footprint to support something they don't use.
> Can't they be shipped on the side? An rpm of signatures that's
> optionally installed would be more user friendly.
>
> Also, I (being unfamiliar with IMA), don't see how this is any better
> than trusting the file hash signed by the fedora keys that we currently
> have.

I wasn't aware the current rpm has functionality integrated with
kernel/tpm and other functionality to do it at runtime access of the
files, I thought it was more an audit style use case such as rpm -V to
see if something had changed. IMA is more about being able to check at
runtime and setting policies of what to do if something has changed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

[Peter Robinson]

> >> > During signing builds, the files in it will be signed with IMA
> >> > signatures..  These signatures will be made with a key that’s kept by
> >> > the Fedora Infrastructure team, and installed on the sign vaults.
> >>
> >> What is the impact on RPM database size?
> >
> > They're stored in xattr so it shouldn't have any noticeable impact,
> > although Patrick can confirm the details of that.
>
> If the signatures end up in RPM headers, they will land in the RPM
> database, too.
>
> “rpm -qla | wc -l” shows around 28,589 files for me, in the Fedora 33
> container image.  / seems to need 183 MiB right now.  If the signatures
> land in the RPM database and the file system, I expect at least 96 bytes
> per file signature (digests in the header are traditionally hex-encoded,
> I think).  That translates to 2.6 MiB, or ~1.4% size increase.
>
> But quite likely there is some per-block overhead, so the numbers should
> be worse.
>
> >> Will GPLv3 packages be excluded, or will the signing keys be provided
> >> upon request?
> >
> > The public key?
>
> The private key.  IMA is typically used for some form of remote

There's no requirement of the GPLv3 to redistribute the private key
for this usecase, we're not denying access or restricting use of the
OS:
https://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys

> attestation, I think.  I'm not sure if it is possible to distribute
> hardware with IMA enforcement.  And as long as enforcement can be turned
> of trivially (as required by the GPLv3, as far as I can tell), IMA seems
> to be pretty useless.

Like most things end users if they're not onselling/distributing to
third parties can use technologies such as IMA to reduce the attack
surface or increase their ability to audit their own systems as they
like.

Like most security tooling it's about layers of security and functionality.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Signed RPM Contents (late System-Wide Change)

[Vitaly Zaitsev via devel]

On 12.01.2021 21:20, Brian C. Lane wrote:

Who is going to use this feature? My guess is a very limited set of
users, so it seems unfair to dramatically increase the size of their
downloads and install footprint to support something they don't use.
Can't they be shipped on the side? An rpm of signatures that's
optionally installed would be more user friendly.


+1. I think a separate -signature subpackage in a separate repository 
(as already done with -debug{info,sources}) would be better.


If the user needs per-file signatures, they can enable fedora-signatures 
repository and install all of them (a dnf plugin can be created to 
automate this process).


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned python-flexmock

[Lumír Balhar]

I'm a maintainer of micropipenv so I can co-maintain flexmock, if you want.

Have a nice day.

Lumír

On 1/13/21 9:30 AM, Hunor Csomortáni wrote:

I will take it over.

On Wed, Jan 13, 2021 at 1:38 AM Miro Hrončok  wrote:

I've orphaned python-flexmock.

It is essentially dead/complete upstream and I have no use for it.

Dependents:

micropipenv-0:1.0.2-1.fc34.src
osbs-client-0:0.62-1.fc33.src
pyp2rpm-0:3.3.5-1.fc34.src
python-anymarkup-core-0:0.8.1-3.fc33.src
python-sqlalchemy-utils-0:0.34.2-5.fc33.src
sen-0:0.6.1-7.fc33.src
spec2scl-0:1.2.2-6.fc33.src

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 virt-install + ks has some problem switching root

[Tomasz Torcz]

On Wed, Jan 13, 2021 at 10:16:43AM +, Richard W.M. Jones wrote:
> Sorry for this rather ill-defined bug report, but I'm hoping someone
> will recognize the symptoms or at least suggest a way to debug this.
> 
> Ever since Fedora 33 was released we've been unable to produce a
> working virt-builder template.  The template that we have made fails
> at switch root.
> 
> template:   https://builder.libguestfs.org/fedora-33.xz
> bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1911177
> 
> An additional problem is I cannot find any way to debug the problem.

  In this image, initrd-switch-root.service fails because "/sysroot does
not contain /etc/os-release".  This is visible when you boot with
"systemd.log_level=debug systemd.journald.forward_to_console=1"
as described on https://freedesktop.org/wiki/Software/systemd/Debugging/

> Something (systemd? dracut?) asks for a root password in order to get
> to the emergency shell, and I can find no way around this nor any
> password which works.  I wish there was a "stop asking for a password"
> option on the kernel command line.

  This one is weird. I tried "rd.shell" and "rd.break", which should
just drop to dracut shell, but it didn't work.

 BTW, partition setup looks weird, too. vda1 is 1MB empty partition,
then vda2 is /boot and vda3 is rootfs.  Is this how we organise disks by
default?

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Localization measurement and tooling (Self-Contained Change proposal)

[Vitaly Zaitsev via devel]

On 13.01.2021 09:26, Jean-Baptiste Holcroft wrote:

Each upstream project decides their translation process.


This is a normal workflow.


What we will measure with this change, is what is what the Linux ecosystem is 
delivering to end users. Which should help to make the Linux community more 
effective.


IMO, translations should be controlled by upstream projects, not 
distributions.


Fedora should stay closer to the upstream projects, not drift away from 
them.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Migrating the Fedora Developer Portal to Fedora Docs

[Jean-Baptiste Holcroft]

Le 2021-01-13 11:15, Ankur Sinha a écrit :

What do you think?


From an internationalization point of view, it would helps a lot.
Both Fedora docs and Websites can be translated, only developer portal 
is stuck in English only.

___
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

[389-devel] Please review: Issue 4534 - libasan read buffer overflow in filtercmp

[Pierre Rogier]

https://github.com/389ds/389-ds-base/pull/4541

Regards,

-- 
--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

Fedora 33 virt-install + ks has some problem switching root

[Richard W.M. Jones]

Sorry for this rather ill-defined bug report, but I'm hoping someone
will recognize the symptoms or at least suggest a way to debug this.

Ever since Fedora 33 was released we've been unable to produce a
working virt-builder template.  The template that we have made fails
at switch root.

template:   https://builder.libguestfs.org/fedora-33.xz
bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1911177

An additional problem is I cannot find any way to debug the problem.
Something (systemd? dracut?) asks for a root password in order to get
to the emergency shell, and I can find no way around this nor any
password which works.  I wish there was a "stop asking for a password"
option on the kernel command line.

We use the same process to make these as we have always used, this
kickstart:

  
https://github.com/libguestfs/libguestfs/blob/master/builder/templates/fedora-33.ks

is fed to this virt-install script:

  
https://github.com/libguestfs/libguestfs/blob/master/builder/templates/fedora-33.virt-install-cmd

and the result is minimized.  (I tried turning off the minimization
steps, it seems the output of virt-install + ks is broken, not
anything we do afterwards).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Migrating the Fedora Developer Portal to Fedora Docs

[Ankur Sinha]

Hi folks,

(CC: docs ML)

I've seen the Fedora Developer portal continue to exist as a standalone
project separately from the Fedora docs, and I don't quite understand
why this is so. I think it'll be much better if the information there
was moved to the new Fedora docs---so that users and the community have
all the info they need in one place. It'll also imply that the
work/resources that are being used to develop and maintain whatever
platform the Developer Portal is using can be directed towards improving
the docs project.

What do you think?

I've started a discussion here. Please chime in:
https://github.com/developer-portal/website/issues/112

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

Re: Fedora 34 Change: Remove Guile Support From Toolchain (Self-Contained Change)

[Florian Weimer]

* Jakub Jelinek:

> A better way to do that is I think what GCC does e.g. with isl,
> patch the source so that for the very rarely if ever used feature it doesn't
> link against the corresponding library, but instead dlopens it and calls it
> through dlsym pointers.
> That way, make would not have the guile dependency, and if somebody ever
> tries to use the guile stuff, it would dlopen the library, if it isn't
> there, it would print some sensible diagnostics like that
> dnf install guilewhatever is needed to make it work and fail.

The functionality is sufficiently isolated for this to be possible, but
given that there are no users of gmk-expand and gmk-eval, I really do
not see the point.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Remove Guile Support From Toolchain (Self-Contained Change)

[Jakub Jelinek]

On Tue, Jan 12, 2021 at 05:10:08PM -0500, Neal Gompa wrote:
> This is probably a bad idea, since that deliberately breaks things for
> things that expect it to be there. If we *really* want to get rid of
> this (and I'm not entirely convinced we should), why not just make an
> alternative build subpackage and make the two conflict? One with Guile
> support and one without? Then if something needs Guile integration for
> Make, for example, they can install "make-guile" instead of "make".

A better way to do that is I think what GCC does e.g. with isl,
patch the source so that for the very rarely if ever used feature it doesn't
link against the corresponding library, but instead dlopens it and calls it
through dlsym pointers.
That way, make would not have the guile dependency, and if somebody ever
tries to use the guile stuff, it would dlopen the library, if it isn't
there, it would print some sensible diagnostics like that
dnf install guilewhatever is needed to make it work and fail.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Remove Guile Support From Toolchain (Self-Contained Change)

[Florian Weimer]

* Neal Gompa:

> This is probably a bad idea, since that deliberately breaks things for
> things that expect it to be there. If we *really* want to get rid of
> this (and I'm not entirely convinced we should), why not just make an
> alternative build subpackage and make the two conflict? One with Guile
> support and one without? Then if something needs Guile integration for
> Make, for example, they can install "make-guile" instead of "make".

With those explicit dependencies on “make”, installing “make-guile”
wouldn't allow you to build much else anymore.  “make-guile” could
perhaps provide “make”, but I'm a bit wary of such ambiguous
dependencies among core packages.

In my opinion, the presence of Guile support in make is a disservice to
our users because other distributions (including downstreams) do not
have it, so it creates non-portable programs if it is ever used.

> Also "shrink the buildroot" for Make isn't a good enough reason to do
> this, since we don't even include Make in the buildroot by default
> anymore[1].
>
> [1]: https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot

It still has to be downloaded and installed for most C/C++ builds.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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