Re: [Ocaml-devel] Re: Need feedback on ocaml-atd review request

[Michel Alexandre Salim]

On Mon, 2021-04-12 at 15:51 -0600, Jerry James wrote:
> On Fri, Apr 9, 2021 at 5:33 PM Michel Alexandre Salim
>  wrote:
> > ok, the camlzip OPAM module still uses Makefiles to install, and
> > rather
> > than trying to make sure I override the right environment variables
> > to
> > get it to build correctly, I figured I'd rather fix opam2rpm to
> > support
> > Zip archives:
> > 
> > https://pagure.io/opam2rpm/pull-request/6
> 
> Thank you!  I have merged the pull request.  I want to point out,
> too,
> that camlzip is already packaged as ocaml-zip.  Also, I recently
> announced a dependency visualizer, named depict, and included an
> example of visualizing the dependencies of Infer.  See
> 
> 
Oh, thanks, I guess I really should use the `ocaml(...)` notation for
dependencies.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Backfilling missed packages for `fedora-obsolete-packages`?

[Michel Alexandre Salim]

On Thu, 2021-04-15 at 23:00 +0200, Miro Hrončok wrote:
> On 15. 04. 21 22:21, Michel Alexandre Salim wrote:
> 
> > 
> > In this case, presumably only `rxvt` fits the bill here as it is
> > causing a conflict, so... perhaps I should add it to `fedora-
> > obsolete-
> > packages` for F32, F33, and F34? Or just make `rxvt-unicode` properly
> > Provides+Obsoletes `rxvt`?
> 
> Doing it form the "replacing" package is preferred if at all possible.
> That'll 
> work as well.
> 
Ah, that explains it, it's an off-by-one error. last release of rxvt is
2.7.10-36 but the Obsoletes in rxvt-unicode is for <= 2.7.10-36, and
that should be 37 or higher because of %{?dist}.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

I bumped the N-V-R and issued updates:
F32 https://bodhi.fedoraproject.org/updates/FEDORA-2021-0632e9328a
F33 https://bodhi.fedoraproject.org/updates/FEDORA-2021-a2f2c29e27
F34 https://bodhi.fedoraproject.org/updates/FEDORA-2021-5a6e035c19
F35 https://bodhi.fedoraproject.org/updates/FEDORA-2021-d67970ea5a


> > The next question is what to do with packages that are no longer
> > buildable, or are retired, but are still working. Removing it in
> > Fedora
> > might be overkill, in which case we probably will need to come up
> > with
> > our own internal version of fedora-obsolete-packages to remove them.
> 
> Yes, unless they cause conflicts, or are very insecure, we don't
> generally 
> remove those from user machines.
> 
Fair enough, I'll plan on writing our own in-house obsolete package
then, if our security folks deem it necessary. Thanks!

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Re-launch of the OCaml devel list

[Michel Alexandre Salim]

Huzzah!

On Thu, 2021-04-15 at 22:27 +0200, Dan Čermák wrote:
> Dear OCaml devs & packagers,
> 
> thanks to the work of smoodge and the infra team, I am proud to
> announce
> the resurrection of the ocaml-devel list!
> 
> It should be now available again for subscription in hyperkitty [1]
> 
Thanks smooge and everyone involved. Er, did this actually happen a few
days ago? I signed up to the list to post
https://lists.fedoraproject.org/archives/list/ocaml-de...@lists.fedoraproject.org/thread/CQCUX4UK2LK3KRWRKWR35CRMJ3LISXP4/
on April 8, and I'm pretty sure I did it from Hyperkitty.

Best,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Github Action for discovering active Fedora Releases

[Adam Williamson]

On Wed, 2021-04-14 at 13:12 -0400, Stephen Gallagher wrote:
> I'm sure there are others of you out there like me who are using
> Github Actions for continuous integration. Recently, I got tired of
> updating my CI workflow definition every time a new Fedora release
> branched, so I wrote a reusable Github Action[1] to query Bodhi for
> the list of "current" (aka "stable") and "pending" (AKA "branched" or
> "rawhide") releases and return them as a JSON array that can be used
> to dynamically generate the build matrix.
> 
> Since I figured it might be useful to others, I have made it available
> publicly. See the Marketplace link[1] for usage examples.

I really need to keep a count of the number of people who've
implemented approximately this. We could have t-shirts!

You can use Bodhi for this, but beware: Bodhi's definition of when a
release goes "current" or "pending" may not match your expectations.
Particularly, releases go "stable" according to Bodhi several days
before they are actually publicly released in the sense that the
expected mirror locations are populated and publicly accessible. See
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/214 .

There are two other sources you could use for this information. You can
use https://admin.fedoraproject.org/pkgdb/api/collections/ , which used
to be an endpoint of the pkgdb app and is now just a hand-maintained
JSON file that gets updated when someone in releng remembers to do it,
or someone expecting the information to be accurate hits them with a
pointy stick.

You can also use
https://fedorapeople.org/groups/qa/metadata/release.json , which gets
updated when *I* remember to do it or when someone hits *me* with a
pointy stick.

I also wrote https://pagure.io/fedora-qa/releasestream as an attempt to
provide a mechanism for making this all less dumb. But I didn't get
around to trying to get it actually deployed in infra and get releng
processes hooked up to it yet.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: Announcing creation of Fedora Source-git SIG

[Matthew Almond via devel]

On Wed, 2021-04-14 at 10:45 +0200, Tomas Tomecek wrote:
...
> We are looking for maintainers of Fedora Linux packages who'd be
> interested in being early adopters and give us feedback during the
> development process. You don't need to do any coding unless you want
> to :)

I'd like to register interest in this topic on behalf of myself and
Facebook. I'm the maintainer for one (very recently added) package. The
source-git workflow has appeal, especially in context of other SIGs -
namely CentOS Hyperscale which I'm part of. Looking forward to the
meeting!

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

Fedora-34-20210415.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Minimal raw-xz armhfp

Failed openQA tests: 4/189 (x86_64), 7/127 (aarch64)

New failures (same test not failed in Fedora-34-20210414.n.0):

ID: 857601  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/857601
ID: 857652  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/857652
ID: 857726  Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/857726
ID: 857730  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/857730
ID: 857745  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/857745
ID: 857747  Test: aarch64 Server-dvd-iso 
install_repository_nfs_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/857747
ID: 857753  Test: aarch64 Server-raw_xz-raw.xz base_update_cli@uefi
URL: https://openqa.fedoraproject.org/tests/857753
ID: 857892  Test: aarch64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/857892

Old failures (same test failed in Fedora-34-20210414.n.0):

ID: 857671  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/857671
ID: 857783  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/857783
ID: 857858  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/857858

Soft failed openQA tests: 6/127 (aarch64), 4/189 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

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

Old soft failures (same test soft failed in Fedora-34-20210414.n.0):

ID: 857594  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/857594
ID: 857635  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/857635
ID: 857692  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/857692
ID: 857698  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/857698
ID: 857711  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/857711
ID: 857736  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/857736
ID: 857751  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/857751
ID: 857832  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/857832
ID: 857887  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/857887

Passed openQA tests: 181/189 (x86_64), 114/127 (aarch64)

New passes (same test not passed in Fedora-34-20210414.n.0):

ID: 857605  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/857605
ID: 857606  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/857606
ID: 857609  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/857609
ID: 857618  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/857618
ID: 857630  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/857630
ID: 857636  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/857636
ID: 857637  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/857637
ID: 857721  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/857721
ID: 857722  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/857722
ID: 857737  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/857737
ID: 857793  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/857793
ID: 857868  Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/857868
ID: 857877  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/857877
ID: 857895  Test: aarch64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/857895

Installed system changes in test x86_64 Server-boot-iso 

Re: Announcing creation of Fedora Source-git SIG

[Neal Gompa]

On Thu, Apr 15, 2021 at 5:05 PM J. Bruce Fields  wrote:
>
> On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote:
> > On 14.04.2021 16:27, Tomas Tomecek wrote:
> > > Could you, please, be more constructive and say what the actual
> > > problems are for you with such repositories?
> >
> > 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge
> > (more than 100 GiB). I don't want to download them from upstream and then
> > upload to Fedora.
>
> Which one exactly is more than 100 GiB?  The Linux kernel certainly
> isn't (more like 2.5 GiB, last I checked.)
>

Chromium is almost 100GB on disk. It's the only repository where I use
Btrfs subvolumes and snapshots to roll back and forth through changes
instead of using Git commands, because it takes *so* long and can time
out and fail.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1949736] perl-Geo-ShapeFile-3.01 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-Geo-ShapeFile-3.01-1.f
   ||c35




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

[Bug 1949736] perl-Geo-ShapeFile-3.01 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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


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

Re: Announcing creation of Fedora Source-git SIG

[J. Bruce Fields]

On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote:
> On 14.04.2021 16:27, Tomas Tomecek wrote:
> > Could you, please, be more constructive and say what the actual
> > problems are for you with such repositories?
> 
> 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge
> (more than 100 GiB). I don't want to download them from upstream and then
> upload to Fedora.

Which one exactly is more than 100 GiB?  The Linux kernel certainly
isn't (more like 2.5 GiB, last I checked.)

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

Re: Backfilling missed packages for `fedora-obsolete-packages`?

[Miro Hrončok]

On 15. 04. 21 22:21, Michel Alexandre Salim wrote:

 From looking at fedora-obsolete-packages' various branches, it looks
like packages are only meant to be listed for one release cycle, and
then removed (so the Rawhide branch's list of packages will get removed
in F36).


Actually, it should be two releases.


How do we handle packages that were not added to this in time? e.g.
when I distro-synced on my F33 box I noticed the following packages are
out of date:

- rxvt, last built for F31, now conflicts with rxvt-unicode


We add them later, when needed, just open bugzillas for 
fedora-obsolete-packages, with the conflicts you get.



Then I listed all FC31 and FC32 packages and found some more
candidates:

```
~
❯ rpm -qa | grep 'fc31'
adapta-gtk-theme-3.95.0.11-3.fc31.noarch
adapta-gtk-theme-gedit-3.95.0.11-3.fc31.noarch
```

=> this is because, ugh, the package has been failing to build for
newer Fedora releases upstream since Fedora 32:
https://koji.fedoraproject.org/koji/packageinfo?packageID=26035

```
~
❯ rpm -qa | grep 'fc32'
libquvi-0.9.4-16.fc32.x86_64
fipscheck-lib-1.5.0-8.fc32.x86_64
```

ditto for `libquvi`,
https://koji.fedoraproject.org/koji/packageinfo?packageID=12832

`fipscheck`, meanwhile, has not even seen build attempts beyond Fedora
32, https://koji.fedoraproject.org/koji/packageinfo?packageID=7695
as ... it is retired: https://src.fedoraproject.org/rpms/fipscheck

In this case, presumably only `rxvt` fits the bill here as it is
causing a conflict, so... perhaps I should add it to `fedora-obsolete-
packages` for F32, F33, and F34? Or just make `rxvt-unicode` properly
Provides+Obsoletes `rxvt`?


Doing it form the "replacing" package is preferred if at all possible. That'll 
work as well.



The next question is what to do with packages that are no longer
buildable, or are retired, but are still working. Removing it in Fedora
might be overkill, in which case we probably will need to come up with
our own internal version of fedora-obsolete-packages to remove them.


Yes, unless they cause conflicts, or are very insecure, we don't generally 
remove those from user machines.


--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Geo-ShapeFile] PR #1: Tests

[Jitka Plesnikova]

jplesnik merged a pull-request against the project: `perl-Geo-ShapeFile` that 
you are following.

Merged pull-request:

``
Tests
``

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

[Bug 1950054] perlbrew-0.92 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Geo-ShapeFile] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Geo-ShapeFile` 
that you are following:
``
Tests
``

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

Re-launch of the OCaml devel list

[Dan Čermák]

Dear OCaml devs & packagers,

thanks to the work of smoodge and the infra team, I am proud to announce
the resurrection of the ocaml-devel list!

It should be now available again for subscription in hyperkitty [1]


Cheers,

Dan

Footnotes:
[1]  
https://lists.fedoraproject.org/archives/list/ocaml-de...@lists.fedoraproject.org/



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

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

[Fedora compose checker]

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 12/189 (x86_64), 10/127 (aarch64)

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

ID: 857312  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/857312
ID: 857427  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/857427
ID: 857447  Test: aarch64 Workstation-raw_xz-raw.xz desktop_terminal@uefi
URL: https://openqa.fedoraproject.org/tests/857447
ID: 857507  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/857507
ID: 857525  Test: x86_64 universal install_with_swap
URL: https://openqa.fedoraproject.org/tests/857525
ID: 857533  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/857533
ID: 857545  Test: aarch64 universal install_kickstart_hdd@uefi
URL: https://openqa.fedoraproject.org/tests/857545

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

ID: 857305  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/857305
ID: 857353  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/857353
ID: 857368  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/857368
ID: 857423  Test: aarch64 Server-dvd-iso modularity_tests@uefi
URL: https://openqa.fedoraproject.org/tests/857423
ID: 857465  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/857465
ID: 857514  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/857514
ID: 857521  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/857521
ID: 857536  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/857536
ID: 857537  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/857537
ID: 857540  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/857540
ID: 857569  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/857569
ID: 857570  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/857570
ID: 857572  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/857572
ID: 857582  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/857582
ID: 857583  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/857583

Soft failed openQA tests: 3/189 (x86_64), 5/127 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 857276  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/857276
ID: 857317  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/857317
ID: 857374  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/857374
ID: 857380  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/857380
ID: 857393  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/857393
ID: 857418  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/857418
ID: 857433  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/857433
ID: 857455  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/857455

Passed openQA tests: 174/189 (x86_64), 112/127 (aarch64)

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 0.46 to 0.27
Previous test data: https://openqa.fedoraproject.org/tests/855763#downloads
Current test data: https://openqa.fedoraproject.org/tests/857268#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 0.29 to 0.50
Previous test data: https://openqa.fedoraproject.org/tests/855764#downloads
Current test data: https://openqa.fedoraproject.org/tests/857269#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 0.86 to 0.58
Previous test data: https://openqa.fedoraproject.org/tests/855775#downloads
Current test data: https://openqa.fedoraproject.org/tests/857280#downloads

Installed system changes in test 

Backfilling missed packages for `fedora-obsolete-packages`?

[Michel Alexandre Salim]

From looking at fedora-obsolete-packages' various branches, it looks
like packages are only meant to be listed for one release cycle, and
then removed (so the Rawhide branch's list of packages will get removed
in F36).

How do we handle packages that were not added to this in time? e.g.
when I distro-synced on my F33 box I noticed the following packages are
out of date:

- rxvt, last built for F31, now conflicts with rxvt-unicode

Then I listed all FC31 and FC32 packages and found some more
candidates:

```
~ 
❯ rpm -qa | grep 'fc31'   
adapta-gtk-theme-3.95.0.11-3.fc31.noarch  
adapta-gtk-theme-gedit-3.95.0.11-3.fc31.noarch
```

=> this is because, ugh, the package has been failing to build for
newer Fedora releases upstream since Fedora 32:
https://koji.fedoraproject.org/koji/packageinfo?packageID=26035

```
~
❯ rpm -qa | grep 'fc32'   
libquvi-0.9.4-16.fc32.x86_64
fipscheck-lib-1.5.0-8.fc32.x86_64
```

ditto for `libquvi`,
https://koji.fedoraproject.org/koji/packageinfo?packageID=12832

`fipscheck`, meanwhile, has not even seen build attempts beyond Fedora
32, https://koji.fedoraproject.org/koji/packageinfo?packageID=7695
as ... it is retired: https://src.fedoraproject.org/rpms/fipscheck

In this case, presumably only `rxvt` fits the bill here as it is
causing a conflict, so... perhaps I should add it to `fedora-obsolete-
packages` for F32, F33, and F34? Or just make `rxvt-unicode` properly
Provides+Obsoletes `rxvt`?

The next question is what to do with packages that are no longer
buildable, or are retired, but are still working. Removing it in Fedora
might be overkill, in which case we probably will need to come up with
our own internal version of fedora-obsolete-packages to remove them.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1947324] Upgrade perl-SQL-Abstract-Limit to 0.143

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1948957] perl-Crypt-CBC-3.02 requires perl-Math-Int128 which does not exist on 32-bit platforms

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Crypt-CBC-3.02-2.fc35
 Resolution|--- |RAWHIDE
Last Closed||2021-04-15 18:42:55



--- Comment #2 from Paul Howarth  ---
Rawhide build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=66014072


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

Re: 2021-04-15 dnf broken in rawhide?

[Ankur Sinha]

On Thu, Apr 15, 2021 10:57:47 -0700, Kevin Fenzi wrote:
> On Thu, Apr 15, 2021 at 06:35:22PM +0100, Ankur Sinha wrote:
> > Hiya,
> > 
> > I'm trying to build a new package for rawhide but keep running into this
> > error on koji:
> > 
> > Error:
> >  Problem: package dnf-plugins-core-4.0.19-1.fc34.noarch requires 
> > python3-dnf-plugins-core = 4.0.19-1.fc34, but none of the providers can be 
> > installed
> >   - package dnf-4.7.0-1.fc35.noarch conflicts with python3-dnf-plugins-core 
> > < 4.0.20 provided by python3-dnf-plugins-core-4.0.19-1.fc34.noarch
> >   - conflicting requests
> > (try to add '--allowerasing' to command line to replace conflicting 
> > packages or '--skip-broken' to skip uninstallable packages)
> > 
> > Anyone else running into this? Known issue?
> 
> Yes, already untagged those and mailed the maintainer to use a side-tag
> instead. 
> 

Ah, awesome! Thanks very much!


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


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

Re: 2021-04-15 dnf broken in rawhide?

[Kevin Fenzi]

On Thu, Apr 15, 2021 at 06:35:22PM +0100, Ankur Sinha wrote:
> Hiya,
> 
> I'm trying to build a new package for rawhide but keep running into this
> error on koji:
> 
> Error:
>  Problem: package dnf-plugins-core-4.0.19-1.fc34.noarch requires 
> python3-dnf-plugins-core = 4.0.19-1.fc34, but none of the providers can be 
> installed
>   - package dnf-4.7.0-1.fc35.noarch conflicts with python3-dnf-plugins-core < 
> 4.0.20 provided by python3-dnf-plugins-core-4.0.19-1.fc34.noarch
>   - conflicting requests
> (try to add '--allowerasing' to command line to replace conflicting packages 
> or '--skip-broken' to skip uninstallable packages)
> 
> Anyone else running into this? Known issue?

Yes, already untagged those and mailed the maintainer to use a side-tag
instead. 

https://pagure.io/ipsilon/issue/351

kevin


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

Re: 2021-04-15 dnf broken in rawhide?

[Antonio T. sagitter]

See https://bodhi.fedoraproject.org/updates/FEDORA-2021-d90b379f35

On 4/15/21 7:35 PM, Ankur Sinha wrote:

Hiya,

I'm trying to build a new package for rawhide but keep running into this
error on koji:

Error:
  Problem: package dnf-plugins-core-4.0.19-1.fc34.noarch requires 
python3-dnf-plugins-core = 4.0.19-1.fc34, but none of the providers can be 
installed
   - package dnf-4.7.0-1.fc35.noarch conflicts with python3-dnf-plugins-core < 
4.0.20 provided by python3-dnf-plugins-core-4.0.19-1.fc34.noarch
   - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

Anyone else running into this? Known issue?


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



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


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: Announcing creation of Fedora Source-git SIG

[Justin Forbes]

On Wed, Apr 14, 2021 at 1:47 PM Thorsten Leemhuis  wrote:
>
>
> On 14.04.21 10:45, Tomas Tomecek wrote:
> > Good morning, I'd like to announce the creation of Fedora Source-git SIG:
> > https://fedoraproject.org/wiki/SIGs/Source-git
> >
> > Our main goal in the SIG right now is to establish a development
> > workflow for Fedora Linux packages using repositories with sources and
> > upstream history (this is what we call source-git), instead of just
> > distribution files with links to tarballs (dist-git).
>
> Just wondering: will there be some coordination with the Fedora kernel
> developers that are relying on a git based workflow since a few
> weeks now (for rawhide even longer)?
>
> To those who don't know: all the stuff in dist-git kernel is
> generated from https://gitlab.com/cki-project/kernel-ark these days
> afaik, so it might be wise to make sure the solution you work out works
> for them as well. Especially as I find find some parts of how they do it
> a bit questionable. The main tarball they use as Source0 for example
> doesn't match the tarball downloadable from kernel.org(¹); all the
> patches are stashed into one(²); patches for fedora specific stuff (like
> the configs needed for building the kernel) are in the same branch as
> the patches(³). I think that makes things quite confusing, especially
> for outsiders. Sometimes I wonder if some of what the kernel people do
> violates the Fedora Packaging Guidelines(⁴), but the kernel-ark people
> ensured me it's fine.
>
> CU, knurd
>
> (¹)
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/sources for example
> states:
> > SHA512 (linux-5.11.14.tar.xz) = 
> > ccf0eaf6df0dacd2984c361621f67a3d16cf7a7174155ebdf646f1acfec43e19ff942e6c17e5bc3b5dc7a300c32bdc6ee37877162c099f5bd9924244f9445467
> But:
> $ wget --quiet
> https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.14.tar.xz
> $ sha512sum linux-5.11.14.tar.xz
> 8dfc7ff184e5cb33fff74686071f1605f3a834669e201d272f3047aa00657339ec1a3cfd605d8761b8a0f335b8488c02c701e72ed30031856e9c154aa1ff2d88
>  linux-5.11.14.tar.xz
>
likely different compression options used by default, the upstream
tarball is just a bit smaller.  We create the tarballourselves, but
based on greg's tag.  If you explode and compare them, they are
identical:

fedora64:[~/srcchk]>diff -ruNp stable-5.11.14/ ark-5.11.14/
fedora64:[~/srcchk]>ls -l *5.11.14.tar.xz
-rw-rw-r--. 1 jforbes jforbes 123313416 Apr 15 12:38 ark-5.11.14.tar.xz
-rw-r--r--. 1 jforbes jforbes 117651976 Apr 15 12:42 linux-5.11.14.tar.xz

For what it's worth, until they changed compression, we used to
recompress the upstream tarball and end up with a similar result.  As
to your (*) they are tagged in the git tree, you can verify that tag
in our clone of the upstream tree, or directly in the upstream tree if
you wish, both audit sources are available.

As to the single patch vs the broken out, it is a matter of git merge
vs git rebase. If we did a rebase with every release, they could be
broken out cleanly, but the trade off is any update becomes a forced
update, and any pending MR is invalidated.  We do rebase the patches
on the creation of stable branches, so fedora-5.11 was created by
rebasing the rawhide branch over Greg's linux-5.11.y branch.  It is
merged forward from there, but none of the patches should be too
different to quickly figure out.

>
> (²)
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/patch-5.11-redhat.patch
> FWIW, links to the individual patches can be found here:
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/Patchlist.changelog
>
> (³) for example
> https://gitlab.com/cki-project/kernel-ark/-/commits/fedora-5.11
>
> (⁴) like this part "sources used to build a package should be the
> vanilla sources available from upstream. To help reviewers and QA
> scripts verify this, the packager needs to indicate where a reviewer can
> find the source that was used to make the rpm". The quote is from here:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, 

2021-04-15 dnf broken in rawhide?

[Ankur Sinha]

Hiya,

I'm trying to build a new package for rawhide but keep running into this
error on koji:

Error:
 Problem: package dnf-plugins-core-4.0.19-1.fc34.noarch requires 
python3-dnf-plugins-core = 4.0.19-1.fc34, but none of the providers can be 
installed
  - package dnf-4.7.0-1.fc35.noarch conflicts with python3-dnf-plugins-core < 
4.0.20 provided by python3-dnf-plugins-core-4.0.19-1.fc34.noarch
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or 
'--skip-broken' to skip uninstallable packages)

Anyone else running into this? Known issue?

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


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

[Bug 1950067] New: perl-PDL-2.035 is available

[bugzilla]

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

Bug ID: 1950067
   Summary: perl-PDL-2.035 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PDL
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
jakub.jedel...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.035
Current version/release in rawhide: 2.34.0-1.fc35
URL: http://search.cpan.org/dist/PDL/

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


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


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


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


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

[Bug 1950061] New: perl-Number-Fraction-3.0.4 is available

[bugzilla]

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

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



Latest upstream release: 3.0.4
Current version/release in rawhide: 3.0.3-2.fc34
URL: http://search.cpan.org/dist/Number-Fraction/

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


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

[Bug 1950054] New: perlbrew-0.92 is available

[bugzilla]

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

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



Latest upstream release: 0.92
Current version/release in rawhide: 0.91-1.fc34
URL: http://search.cpan.org/dist/App-perlbrew/

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


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

Re: Orphaned packages looking for new maintainers

[Kevin Fenzi]

On Thu, Apr 15, 2021 at 11:38:15AM +0200, Vitaly Zaitsev via devel wrote:
> On 15.04.2021 07:22, Pavel Zhukov wrote:
> > There is (was?) bug in pagure which allows any Fedora package to
> > orphan any package in the distribution.
> 
> Yes. This is not a bug, this is a critical vulnerability. It must be fixed
> ASAP.
> 
> Reported 1 month ago and still not fixed.

No. It was reported a month ago and fixed days later. 

I'm sorry it wasn't announced, but I think there was some followup (we
wanted to make sure we handled it all). I'll go look and see. 

kevin


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

[Bug 1948957] perl-Crypt-CBC-3.02 requires perl-Math-Int128 which does not exist on 32-bit platforms

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||p...@city-fan.org
   Assignee|andr...@bawue.net   |p...@city-fan.org



--- Comment #1 from Paul Howarth  ---
I removed the BuildRequires: (CTR mode is not tested) and dropped the Requires:
down to a Recommends:

Hope that helps.

I requested support for fallback to the old implementation using Math::BigInt
if Math::Int128 is unavailable
(https://github.com/lstein/Lib-Crypt-CBC/issues/3).


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

Re: How to handle pull request with git?

[Robert-André Mauchin]

On 4/15/21 1:24 PM, Mark Wielaard wrote:

On Wed, Apr 14, 2021 at 04:04:21PM +0200, Robert-André Mauchin wrote:

On 4/14/21 3:28 PM, Mark Wielaard wrote:

I got a "pull request" for one of my packages and wanted to make some
changes to discuss with the submitter and see if we could merge it
back with those changes to the rawhide branch. But somehow I did
something wrong and I am not sure what or how to fix it.

So I saw this webpage with the suggested change:
https://src.fedoraproject.org/rpms/valgrind/pull-request/4

I added the following line to my .git/config at the end of the [remote
"origin"] section to be able to pull it:

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then git pulled and checkout pr/4, made the changes, committed them
and pushed them back, hoping that would update the pr.

But it didn't, apparently I created a new origin/pr/4 branch, which I
am now unable to delete because:

$ git push origin --delete pr/4
remote: Branch deletion is not allowed
remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/valgrind
   ! [remote rejected] pr/4 (pre-receive hook declined)
error: failed to push some refs to 'ssh://pkgs.fedoraproject.org/rpms/valgrind'

What did I do wrong and how do I fix this?



1. You clone the forked repository
2. You checkout the branch where the modification has been made
3. You edit the files you want to change
4. You commit (or amend) the new changes
5. You push (or force push) the commit
6. Your commit will appear in the Pull Request ar "Rebased blah blah"
7. Merge your changes


Thanks. So I believed I was doing the above, but apparently not.
Would you mind explaining steps 1, 2 and 5 a bit more.

So what I did to clone the prs was to add that extra fetch line in my
.git/config. Which seemed to allow me to pull and work on the branch
remote pull/4 as pr/4 locally. Then I though I pushed it back, but
apparently that created a new branch in the origin called pr/4 instead
of getting my changes back into the remote pull/4.

Apparently the fetch line doesn't work like I expected.

Thanks,

Mark


So you have this PR: 
https://src.fedoraproject.org/rpms/valgrind/pull-request/4


- You see it is coming from rpms/ahajkova/valgrind
So you go to 
https://src.fedoraproject.org/fork/ahajkova/rpms/valgrind/tree/rawhide 
(by clicking on the first "rawhide")


- and get the clone url and clone that repository:

git clone ssh://m...@pkgs.fedoraproject.org/forks/ahajkova/rpms/valgrind.git

 - You checkout the branch where the changes have been made. Here it's 
already rawhide so you don't need to change.


 - Here you might need to rebase:

git remote add upstream ssh://m...@pkgs.fedoraproject.org/rpms/valgrind.git

git fetch upstream

git rebase upstream/rawhide

(Fix the eventual conflicts)

 - Then make the PR changes you want

 - Commit the changes by amending the previous commit

 - git push --force to force the edit of the commit to the remote

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

Re: Fedora Linux 34 Final blocker status update #4

[Matthew Miller]

On Thu, Apr 15, 2021 at 04:57:46PM +0200, Luna Jernberg wrote:
> Delayed another week:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/2UHYXZ6LDWEQ2EUEL3QUMV753JKEAUXZ/

To be clear, this isn't a "delay". Not yet at least. :)


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing creation of Fedora Source-git SIG

[Daniel P . Berrangé]

On Thu, Apr 15, 2021 at 04:30:26PM +0200, Tomas Tomecek wrote:
> Daniel, thank you for sharing your experience!
> 
> More comments inline.
> 
> On Wed, Apr 14, 2021 at 5:26 PM Daniel P. Berrangé  
> wrote> > > 4. Some project have a weird git workflow between minor releases. 
> I know at
> > > least one project that uses Git tags with cherry-picked and manually
> > > backported commits. Such detached tags cannot be merged into master branch
> > > without resolving merge conflicts.
> >
> > I woudn't expect Fedora to track the git-master in most cases. You
> > generally still want Fedora to be base off releases, so you'd want
> > to track starting fron a release tag or branch.
> 
> Correct, the branches are meant to use upstream release git-tags as a base.
> 
> > > 5. Force pushes must be enabled, which is too dangerous IMO.
> >
> > There are several ways you can do source git and they don't all
> > imply force pushes, so I think this is probably inventing a
> > problem where none yet exists.
> >
> > One example approach to source-git I've used...
> >
> > Rather than having source-git branch names matching dist-git,
> > use a different naming convention that is based off the upstream
> > version primarily.
> >
> > eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
> > branch, and if I rebase Fedora to v1.2, then I'd just switch to
> > using a v1.2-f33 branch instead. The v1.0-f33 history remains
> > intact forever, no force push required to rebase to new version.
> >
> > If upstream has stable branches v1.0-maint and v1.2-maint, then
> > v1.0-f33 branch might be initialized with v1.0-maint content.
> > If upstream adds more commits to v1.0-maint branch, then you
> > wouldn't force push v1.0-f33, you'd just do a git merge to pull
> > them in.
> 
> That's interesting: merge commits make it hard to work with the
> git-history - how do you solve that? Daniel, does your tooling account
> for a merge commit and is it able to still pick up commits and turn
> them into patch files correctly?

I've not actually hit situations where I've needed merge commits
in general, except by my own mistake. My tooling merely consists
of running "git format-patch vN.M..." where "vN.M" is the tag
associated with the release the RPM is based off.

> Our current solution to rebases is to create new branches for every
> upstream release.

Yes, that's the good way IMHO. I was only mentioning merge commits
in the context of tracking changes within a release stream. eg some
projects may have stable branches in their upstream git, but don't
do releases off them very frequently. So you'd conceivably want to
periodically do a merge against upstream stable branche.

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

Re: Announcing creation of Fedora Source-git SIG

[Tomas Tomecek]

On Wed, Apr 14, 2021 at 8:52 PM Thorsten Leemhuis  wrote:
>
>
> On 14.04.21 10:45, Tomas Tomecek wrote:
> > Good morning, I'd like to announce the creation of Fedora Source-git SIG:
> > https://fedoraproject.org/wiki/SIGs/Source-git
> >
> > Our main goal in the SIG right now is to establish a development
> > workflow for Fedora Linux packages using repositories with sources and
> > upstream history (this is what we call source-git), instead of just
> > distribution files with links to tarballs (dist-git).
>
> Just wondering: will there be some coordination with the Fedora kernel
> developers that are relying on a git based workflow since a few
> weeks now (for rawhide even longer)?
>
> To those who don't know: all the stuff in dist-git kernel is
> generated from https://gitlab.com/cki-project/kernel-ark these days
> afaik, so it might be wise to make sure the solution you work out works
> for them as well. Especially as I find find some parts of how they do it
> a bit questionable. The main tarball they use as Source0 for example
> doesn't match the tarball downloadable from kernel.org(¹); all the
> patches are stashed into one(²); patches for fedora specific stuff (like
> the configs needed for building the kernel) are in the same branch as
> the patches(³). I think that makes things quite confusing, especially
> for outsiders. Sometimes I wonder if some of what the kernel people do
> violates the Fedora Packaging Guidelines(⁴), but the kernel-ark people
> ensured me it's fine.
>
> CU, knurd
>
> (¹)
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/sources for example
> states:
> > SHA512 (linux-5.11.14.tar.xz) = 
> > ccf0eaf6df0dacd2984c361621f67a3d16cf7a7174155ebdf646f1acfec43e19ff942e6c17e5bc3b5dc7a300c32bdc6ee37877162c099f5bd9924244f9445467
> But:
> $ wget --quiet
> https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.14.tar.xz
> $ sha512sum linux-5.11.14.tar.xz
> 8dfc7ff184e5cb33fff74686071f1605f3a834669e201d272f3047aa00657339ec1a3cfd605d8761b8a0f335b8488c02c701e72ed30031856e9c154aa1ff2d88
>  linux-5.11.14.tar.xz
>
>
> (²)
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/patch-5.11-redhat.patch
> FWIW, links to the individual patches can be found here:
> https://src.fedoraproject.org/rpms/kernel/blob/f33/f/Patchlist.changelog
>
> (³) for example
> https://gitlab.com/cki-project/kernel-ark/-/commits/fedora-5.11
>
> (⁴) like this part "sources used to build a package should be the
> vanilla sources available from upstream. To help reviewers and QA
> scripts verify this, the packager needs to indicate where a reviewer can
> find the source that was used to make the rpm". The quote is from here:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/

Thorsten, thank you for pointing those out. I spoke with Don Zickus,
one of the leads behind the kernel-ark project (or probably the lead
:) and he confirmed to join the SIG. My hope is to create a platform
that would unify all the different source-git implementations being
used right now into one, which would have clear documentation, tooling
and infra support. Dreaming big :)


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

Re: Announcing creation of Fedora Source-git SIG

[Tomas Tomecek]

Daniel, thank you for sharing your experience!

More comments inline.

On Wed, Apr 14, 2021 at 5:26 PM Daniel P. Berrangé  wrote:
>
> On Wed, Apr 14, 2021 at 04:53:06PM +0200, Vitaly Zaitsev via devel wrote:
> > On 14.04.2021 16:27, Tomas Tomecek wrote:
> > > Could you, please, be more constructive and say what the actual
> > > problems are for you with such repositories?
> >
> > 1. Some upstream repositories (Qt, Chromium, Linux kernel) are very huge
> > (more than 100 GiB). I don't want to download them from upstream and then
> > upload to Fedora.

Fedora kernel is already being maintained like this:

https://gitlab.com/cki-project/kernel-ark

> > 2. Keeping such huge repositories will take up a lot of disk space on the
> > maintainer's computers.
>
> Bear in mind that many maintainers already use a source-git workflow with
> Fedora, and are also involved in the upstream project. IOW, they already
> have these upstream repos present locally, and also be hosting it in some
> remote git server outside normal Fedora dist-git.
>
> source-git isn't proposed to be forced on all packages, and drive-by
> contributors can also take a shallow clone instead of fetching all
> history. Any possible "fedpkg" integration could potentially default
> to a shallow clone.

Agreed, dist-git isn't going anywhere and with the source-git
workflow, we still want to preserve the rel-eng/proven-packager
workflow in dist-git. The source-git repos should make it way more
convenient for maintainers to track downstream patches, as you
describe.

> > 3. Rebase problem. Maintainers will need do a manual rebase on every
> > upstream release/commit. Rebasing to the next major version will be a
> > serious problem for the projects with a lot of of downstream patches.
>
> That's not my experiance. The cases where I know of maintainers are
> using a source-git model with Fedora / RHEL already, are doing so
> precisely because it makes ongoing maint and rebasing way easier
> than with dist-git, especially when there are alot of downstream
> patches (100's or even 1000's).

+1, `git pull --rebase upstream $ref` is more convenient than trying
to fix downstream patches in whatever obscure way.

Shout out to rebase-helper which is trying to automate the patch files
rebase problem via a CLI utility:
https://github.com/rebase-helper/rebase-helper

> > 4. Some project have a weird git workflow between minor releases. I know at
> > least one project that uses Git tags with cherry-picked and manually
> > backported commits. Such detached tags cannot be merged into master branch
> > without resolving merge conflicts.
>
> I woudn't expect Fedora to track the git-master in most cases. You
> generally still want Fedora to be base off releases, so you'd want
> to track starting fron a release tag or branch.

Correct, the branches are meant to use upstream release git-tags as a base.

> > 5. Force pushes must be enabled, which is too dangerous IMO.
>
> There are several ways you can do source git and they don't all
> imply force pushes, so I think this is probably inventing a
> problem where none yet exists.
>
> One example approach to source-git I've used...
>
> Rather than having source-git branch names matching dist-git,
> use a different naming convention that is based off the upstream
> version primarily.
>
> eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
> branch, and if I rebase Fedora to v1.2, then I'd just switch to
> using a v1.2-f33 branch instead. The v1.0-f33 history remains
> intact forever, no force push required to rebase to new version.
>
> If upstream has stable branches v1.0-maint and v1.2-maint, then
> v1.0-f33 branch might be initialized with v1.0-maint content.
> If upstream adds more commits to v1.0-maint branch, then you
> wouldn't force push v1.0-f33, you'd just do a git merge to pull
> them in.

That's interesting: merge commits make it hard to work with the
git-history - how do you solve that? Daniel, does your tooling account
for a merge commit and is it able to still pick up commits and turn
them into patch files correctly?

Our current solution to rebases is to create new branches for every
upstream release.

> > > I understand that upstream repositories can have a long history - we
> > > could optimize and have shallow copies or only fetch recent upstream
> > > history if needed. Also, one would ideally only clone once and kept
> > > fetching new changes.
> >
> > Do you want to force switch all Fedora packages to a new workflow?
>
> There's no mention of forcing everyone to switch to source-git. Some
> upstreams don't even use git.

100%, the workflow is optional, dist-git is staying and both workflows
should be compatible (to some extent, synchronizing downstream patches
b/w the two would be tricky to figure out)

> Regards,
> Daniel
> --
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: 

Re: [Help needed] Possible change from gcc failed both openxr and luxcorerender

[Jonathan Wakely]

On 14/04/21 16:06 -0700, Luya Tshimbalanga wrote:
Due to a possible change related to GCC, packages like openxr and 
luxcorereneder failed to build with these errors:


I don't think there's any relevant change in GCC.

It looks like these packages simply fail to link with -lstdc++fs (or
they have that flag in the wrong position in the link command, it
needs to be after any objects that depend on it).

/tmp/ccHa7xrs.ltrans2.ltrans.o: in function 
`RuntimeManifestFile::CreateIfValid(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::vectorstd::default_delete >, 
std::allocatorstd::default_delete > > >&)':
:(.text+0x3b56): undefined reference to 
`std::experimental::filesystem::v1::current_path[abi:cxx11]()'
/usr/bin/ld: :(.text+0x3ba6): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x3bc6): undefined reference to `std::experimental::filesystem::v1::canonical(std::experimental::filesystem::v1::__cxx11::path 
const&, std::experimental::filesystem::v1::__cxx11::path const&)'
/usr/bin/ld: /tmp/ccHa7xrs.ltrans2.ltrans.o: in function 
`CheckAllFilesInThePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, bool, 
std::vector, 
std::allocator >, 
std::allocatorstd::char_traits, std::allocator > > >&)':
:(.text+0x7da5): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x7dad): undefined reference to `std::experimental::filesystem::v1::status(std::experimental::filesystem::v1::__cxx11::path 
const&)'
/usr/bin/ld: :(.text+0x7e9b): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x7eac): undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::directory_iterator(std::experimental::filesystem::v1::__cxx11::path 
const&, std::experimental::filesystem::v1::directory_options, 
std::error_code*)'
/usr/bin/ld: :(.text+0x7f52): undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator*() 
const'

/usr/bin/ld: :(.text+0x8033): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::directory_iterator::operator++()'
/usr/bin/ld: /usr/bin/ld: DWARF error: invalid abstract instance DIE ref
/tmp/ccHa7xrs.ltrans3.ltrans.o: in function 
`FileSysUtilsGetAbsolutePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator >&)':
:(.text+0x15d7): undefined reference to 
`std::experimental::filesystem::v1::current_path[abi:cxx11]()'
/usr/bin/ld: :(.text+0x1626): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x163e): undefined reference to `std::experimental::filesystem::v1::absolute(std::experimental::filesystem::v1::__cxx11::path 
const&, std::experimental::filesystem::v1::__cxx11::path const&)'
/usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function 
`FileSysUtilsCombinePaths(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator >&) [clone .isra.0]':
:(.text+0x1f05): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x1f69): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x1fc4): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function 
`FileSysUtilsGetParentPath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, 
std::__cxx11::basic_string, 
std::allocator >&) [clone .isra.0]':
:(.text+0x234d): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x235d): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::parent_path() 
const'
/usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function 
`FileSysUtilsIsAbsolutePath(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&) [clone 
.isra.0]':
:(.text+0x25fd): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x2605): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::has_root_directory() 
const'
/usr/bin/ld: /tmp/ccHa7xrs.ltrans3.ltrans.o: in function 
`FileSysUtilsPathExists(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&) [clone 
.isra.0]':
:(.text+0x271d): undefined reference to 
`std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: :(.text+0x2725): undefined reference to `std::experimental::filesystem::v1::status(std::experimental::filesystem::v1::__cxx11::path 
const&)'

collect2: error: ld returned 1 exit status
gmake[2]: *** 

Fedora 34 compose report: 20210415.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-34-20210414.n.0
NEW: Fedora-34-20210415.n.0

= SUMMARY =
Added images:7
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   4
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   30.51 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -367.79 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Python_Classroom raw-xz armhfp
Path: Labs/armhfp/images/Fedora-Python-Classroom-34-20210415.n.0.armhfp.raw.xz
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-34-20210415.n.0.armhfp.raw.xz
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-34-20210415.n.0.iso
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-34-20210415.n.0.armhfp.raw.xz
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-34-20210415.n.0.armhfp.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-34-20210415.n.0.armhfp.raw.xz
Image: Workstation raw-xz armhfp
Path: Workstation/armhfp/images/Fedora-Workstation-34-20210415.n.0.armhfp.raw.xz

= DROPPED IMAGES =
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-34-20210414.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  anaconda-34.24.9-1.fc34
Old package:  anaconda-34.24.8-1.fc34
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 21.60 MiB
Size change:  -354.71 KiB
Changelog:
  * Mon Apr 12 2021 Martin Kolman  - 34.24.9-1
  - Allow to exclude the kernel-lpae package (vponcova)


Package:  fedora-release-34-1
Old package:  fedora-release-34-0.14
Summary:  Fedora release files
RPMs: fedora-release fedora-release-cinnamon fedora-release-cloud 
fedora-release-common fedora-release-compneuro fedora-release-container 
fedora-release-coreos fedora-release-designsuite fedora-release-identity-basic 
fedora-release-identity-cinnamon fedora-release-identity-cloud 
fedora-release-identity-compneuro fedora-release-identity-container 
fedora-release-identity-coreos fedora-release-identity-designsuite 
fedora-release-identity-iot fedora-release-identity-kde 
fedora-release-identity-matecompiz fedora-release-identity-server 
fedora-release-identity-silverblue fedora-release-identity-snappy 
fedora-release-identity-soas fedora-release-identity-workstation 
fedora-release-identity-xfce fedora-release-iot fedora-release-kde 
fedora-release-matecompiz fedora-release-server fedora-release-silverblue 
fedora-release-snappy fedora-release-soas fedora-release-workstation 
fedora-release-xfce
Size: 387.68 KiB
Size change:  -9.49 KiB
Changelog:
  * Thu Apr 01 2021 Stephen Gallagher  - 34-0.15
  - Enable certbot-renew.timer (bz1942011)

  * Mon Apr 12 2021 Mohan Boddu  - 34-1
  - Setup for F34 Final


Package:  fedora-repos-34-1
Old package:  fedora-repos-34-0.13
Summary:  Fedora package repositories
RPMs: fedora-gpg-keys fedora-repos fedora-repos-archive 
fedora-repos-eln fedora-repos-modular fedora-repos-ostree fedora-repos-rawhide 
fedora-repos-rawhide-modular
Size: 183.57 KiB
Size change:  925 B
Changelog:
  * Mon Feb 22 2021 Kamil P??ral  - 34-0.14
  - Sync changes from Rawhide (the rawhide gpg symlink), disable ELN repo

  * Mon Apr 12 2021 Mohan Boddu  - 34-1
  - Setup for F34 Final
  - Disable testing repos


Package:  freeipa-4.9.3-2.fc34
Old package:  freeipa-4.9.3-1.fc34
Summary:  The Identity, Policy and Audit system
RPMs: freeipa-client freeipa-client-common freeipa-client-epn 
freeipa-client-samba freeipa-common freeipa-python-compat freeipa-selinux 
freeipa-server freeipa-server-common freeipa-server-dns freeipa-server-trust-ad 
python3-ipaclient python3-ipalib python3-ipaserver python3-ipatests
Size: 8.35 MiB
Size change:  -4.50 KiB
Changelog:
  * Mon Apr 12 2021 Alexander Bokovoy  - 4.9.3-2
  - Handle failures to resolve non-existing reverse zones during deployment 
with systemd-resolved
  - Resolves: rhbz#1948034



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

Re: Fedora 33 and 34 Workstation images not booting in Hyper-V

[Marius Schwarz]

Am 11.04.21 um 07:27 schrieb Patrick Lang:
I just did a quick test with Fedora 34 beta on Hyper-V on Windows 10 
version 2009, build 19042. These settings should work on Windows 
Server 2016 and later too as far as I know. The live boot and install 
worked as usual.


The hyperv_fb driver defaults to 1024x768, but you can change the 
resolution after you install. I put those steps in the same gist.


Hyper-V example setup for Fedora 34 (github.com) 





I checked it again with all the suggested changes, Fedora 34 Beta bootet 
like a charm.


Windows Server 2019  Hyper-V  MNC Build 1809

The lack of 3D hardware is mention when using Cinnamon
and a gnome crash in the gnome-init-setup are the only "problems" so far.

A reboot later  gnome-init-setup finished successfully.

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

[Bug 1949936] perl-Digest-CRC-0.23 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Digest-CRC-0.23-1.fc35
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2021-04-15 13:02:19



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=65989137


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

[Bug 1949936] New: perl-Digest-CRC-0.23 is available

[bugzilla]

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

Bug ID: 1949936
   Summary: perl-Digest-CRC-0.23 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Digest-CRC
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, p...@city-fan.org,
perl-devel@lists.fedoraproject.org,
steve.tray...@cern.ch
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.23
Current version/release in rawhide: 0.22.2-14.fc34
URL: http://search.cpan.org/dist/Digest-CRC/

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


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

[Bug 1949641] perl-Net-DAVTalk-0.20 is available

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Github Action for discovering active Fedora Releases

[Clement Verna]

On Thu, 15 Apr 2021 at 14:11, Stephen Gallagher  wrote:

> On Thu, Apr 15, 2021 at 6:58 AM Clement Verna 
> wrote:
> >
> >
> >
> > On Wed, 14 Apr 2021 at 20:29, Stephen Gallagher 
> wrote:
> >>
> >> On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz 
> wrote:
> >> >
> >> > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher
> napisał(a):
> >> > > Since I figured it might be useful to others, I have made it
> available
> >> > > publicly. See the Marketplace link[1] for usage examples.
> >> > >
> >> > > [1] https://github.com/marketplace/actions/get-fedora-releases
> >> >
> >> > #v+
> >> >   name: Get Fedora Releases
> >> >   runs-on: ubuntu-latest
> >> > #v-
> >> >
> >>
> >> Yeah, the irony isn't lost on me, but it's the only Linux container
> >> host Github currently offers.
> >
> >
> > You can actually run containers directly [0] (might still be running on
> ubuntu but hey ). I have also been playing with self-hosted runner on
> Fedora CoreOS[1] a blog post will follow soon :)
> >
>
> Yes, but this particular action is basically just a quick
> python-requests GET and then some almost-trivial data manipulation.
> There's no reason to add the overhead of pulling a container image
> when the host has all the necessary pieces.
>
> If you're curious, `uses:
> sgallagher/get-fedora-releases-action@v1.0.0` would get you the first
> version of it that I wrote. That version did exactly what you suggest
> and pulled down a container (specifically, `python:3`) to run in. It
> took a little over 30s to process, whereas the version that just runs
> on the Ubuntu host takes only 6s.
>

Right, that makes sense :-)


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

[Test-Announce] Fedora 34 Branched 20210415.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 34 Branched 20210415.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20210407.n.0: anaconda-34.24.8-1.fc34.src, 20210415.n.0: 
anaconda-34.24.9-1.fc34.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/34

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_34_Branched_20210415.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Github Action for discovering active Fedora Releases

[Stephen Gallagher]

On Thu, Apr 15, 2021 at 6:58 AM Clement Verna  wrote:
>
>
>
> On Wed, 14 Apr 2021 at 20:29, Stephen Gallagher  wrote:
>>
>> On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz  wrote:
>> >
>> > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher napisał(a):
>> > > Since I figured it might be useful to others, I have made it available
>> > > publicly. See the Marketplace link[1] for usage examples.
>> > >
>> > > [1] https://github.com/marketplace/actions/get-fedora-releases
>> >
>> > #v+
>> >   name: Get Fedora Releases
>> >   runs-on: ubuntu-latest
>> > #v-
>> >
>>
>> Yeah, the irony isn't lost on me, but it's the only Linux container
>> host Github currently offers.
>
>
> You can actually run containers directly [0] (might still be running on 
> ubuntu but hey ). I have also been playing with self-hosted runner on Fedora 
> CoreOS[1] a blog post will follow soon :)
>

Yes, but this particular action is basically just a quick
python-requests GET and then some almost-trivial data manipulation.
There's no reason to add the overhead of pulling a container image
when the host has all the necessary pieces.

If you're curious, `uses:
sgallagher/get-fedora-releases-action@v1.0.0` would get you the first
version of it that I wrote. That version did exactly what you suggest
and pulled down a container (specifically, `python:3`) to run in. It
took a little over 30s to process, whereas the version that just runs
on the Ubuntu host takes only 6s.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to handle pull request with git?

[Mark Wielaard]

On Wed, Apr 14, 2021 at 04:04:21PM +0200, Robert-André Mauchin wrote:
> On 4/14/21 3:28 PM, Mark Wielaard wrote:
> > I got a "pull request" for one of my packages and wanted to make some
> > changes to discuss with the submitter and see if we could merge it
> > back with those changes to the rawhide branch. But somehow I did
> > something wrong and I am not sure what or how to fix it.
> > 
> > So I saw this webpage with the suggested change:
> > https://src.fedoraproject.org/rpms/valgrind/pull-request/4
> > 
> > I added the following line to my .git/config at the end of the [remote
> > "origin"] section to be able to pull it:
> > 
> > fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
> > 
> > Then git pulled and checkout pr/4, made the changes, committed them
> > and pushed them back, hoping that would update the pr.
> > 
> > But it didn't, apparently I created a new origin/pr/4 branch, which I
> > am now unable to delete because:
> > 
> > $ git push origin --delete pr/4
> > remote: Branch deletion is not allowed
> > remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw'
> > remote: All changes have been rejected
> > To ssh://pkgs.fedoraproject.org/rpms/valgrind
> >   ! [remote rejected] pr/4 (pre-receive hook declined)
> > error: failed to push some refs to 
> > 'ssh://pkgs.fedoraproject.org/rpms/valgrind'
> > 
> > What did I do wrong and how do I fix this?
> > 
> 
> 1. You clone the forked repository
> 2. You checkout the branch where the modification has been made
> 3. You edit the files you want to change
> 4. You commit (or amend) the new changes
> 5. You push (or force push) the commit
> 6. Your commit will appear in the Pull Request ar "Rebased blah blah"
> 7. Merge your changes

Thanks. So I believed I was doing the above, but apparently not.
Would you mind explaining steps 1, 2 and 5 a bit more.

So what I did to clone the prs was to add that extra fetch line in my
.git/config. Which seemed to allow me to pull and work on the branch
remote pull/4 as pr/4 locally. Then I though I pushed it back, but
apparently that created a new branch in the origin called pr/4 instead
of getting my changes back into the remote pull/4.

Apparently the fetch line doesn't work like I expected.

Thanks,

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

Re: How to handle pull request with git?

[Mark Wielaard]

On Wed, Apr 14, 2021 at 02:38:40PM +0100, Tom Hughes via devel wrote:
> On 14/04/2021 14:28, Mark Wielaard wrote:
> 
> > I added the following line to my .git/config at the end of the [remote
> > "origin"] section to be able to pull it:
> > 
> > fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
> > 
> > Then git pulled and checkout pr/4, made the changes, committed them
> > and pushed them back, hoping that would update the pr.
> 
> Is there anywhere that works?
> 
> I don't think even github allows you to push back to the
> generated head for the PR like that. If the person who opened
> the PR allowed it then you can push to their original branch
> to update the PR - no idea if pagure supports that.

I have no experience with github, but it looked like a normal remote
branch to me, so I expected to be able to push to it. How else are you
supposed to coordinate on a PR/patch like that?

> Possibly src.fpo should reject pushes to the PR heads to
> avoid this kind of accident though.

Yes, I did certainly mess up here, don't completely understand how,
but it would have been nice if the system would have stopped me.

> > But it didn't, apparently I created a new origin/pr/4 branch, which I
> > am now unable to delete because:
> > 
> > $ git push origin --delete pr/4
> > remote: Branch deletion is not allowed
> > remote: Denied push for ref 'refs/heads/pr/4' for user 'mjw'
> > remote: All changes have been rejected
> > To ssh://pkgs.fedoraproject.org/rpms/valgrind
> >   ! [remote rejected] pr/4 (pre-receive hook declined)
> > error: failed to push some refs to 
> > 'ssh://pkgs.fedoraproject.org/rpms/valgrind'
> > 
> > What did I do wrong and how do I fix this?
> 
> You pushed a branch into source git which is bad as hey
> can't be deleted.
> 
> I believe in principle you can ask an admin to delete it
> so long as no builds have been done from it.

That would be nice. How do I contact an admin?

Thanks,

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

Fedora Loves Python sticker/logo update, vote for your favorite

[Miro Hrončok]

Hello Pythonistas,
with the new Fedora logo, I am updating the Fedora Loves Python sticker/logo.

There are currently 4 slightly different proposals in the comments of this PR:

https://github.com/fedora-python/fedora-loves-python/pull/2

If you have a preference, I invite you to use GitHub emojis near the comments to 
express it.


If you don't have an account on GitHub, feel free to communicate your preference 
by replying to this email, ideally off-list.


And if you loved the old logo F❤️P more, don't worry about it, I still have 
plenty stickers with it :)


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

Re: Github Action for discovering active Fedora Releases

[Clement Verna]

On Wed, 14 Apr 2021 at 20:29, Stephen Gallagher  wrote:

> On Wed, Apr 14, 2021 at 1:38 PM Tomasz Torcz  wrote:
> >
> > Dnia Wed, Apr 14, 2021 at 01:12:47PM -0400, Stephen Gallagher napisał(a):
> > > Since I figured it might be useful to others, I have made it available
> > > publicly. See the Marketplace link[1] for usage examples.
> > >
> > > [1] https://github.com/marketplace/actions/get-fedora-releases
> >
> > #v+
> >   name: Get Fedora Releases
> >   runs-on: ubuntu-latest
> > #v-
> >
>
> Yeah, the irony isn't lost on me, but it's the only Linux container
> host Github currently offers.
>

You can actually run containers directly [0] (might still be running on
ubuntu but hey ). I have also been playing with self-hosted runner on
Fedora CoreOS[1] a blog post will follow soon :)


[0] -
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainerimage
[1] - https://github.com/cverna/fcos-actions-runner


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

Fedora rawhide compose report: 20210415.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210414.n.0
NEW: Fedora-Rawhide-20210415.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  9
Dropped packages:0
Upgraded packages:   90
Downgraded packages: 1

Size of added packages:  8.48 MiB
Size of dropped packages:0 B
Size of upgraded packages:   730.71 MiB
Size of downgraded packages: 227.69 KiB

Size change of upgraded packages:   3.44 MiB
Size change of downgraded packages: 6.23 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: gnome-shell-extension-no-overview-4-1.fc35
Summary: GNOME Shell extension for no overview at start-up
RPMs:gnome-shell-extension-no-overview
Size:19.66 KiB

Package: practrand-0.951-2.fc35
Summary: Software package for the Randon number generation & testing
RPMs:practrand
Size:3.23 MiB

Package: python-bluepyopt-1.9.149-1.fc35
Summary: Bluebrain Python Optimisation Library (bluepyopt)
RPMs:python3-bluepyopt python3-bluepyopt-doc
Size:4.62 MiB

Package: seatd-0.5.0-1.fc35
Summary: Minimal seat management daemon
RPMs:libseat libseat-devel
Size:177.56 KiB

Package: vim-editorconfig-1.1.1-1.fc35
Summary: EditorConfig Vim Plugin
RPMs:vim-editorconfig
Size:26.33 KiB

Package: xlsatoms-1.1.2-1.fc35
Summary: X11 atom list utility
RPMs:xlsatoms
Size:71.32 KiB

Package: xlsfonts-1.0.6-1.fc35
Summary: X font list utility
RPMs:xlsfonts
Size:100.83 KiB

Package: xprop-1.2.3-1.fc35
Summary: X property display utility
RPMs:xprop
Size:170.32 KiB

Package: xvinfo-1.1.3-1.fc35
Summary: X video extension query utility
RPMs:xvinfo
Size:81.25 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  FreeSOLID-2.1.1-39.fc35
Old package:  FreeSOLID-2.1.1-38.fc34
Summary:  3D collision detection C++ library
RPMs: FreeSOLID FreeSOLID-devel
Size: 1.11 MiB
Size change:  -325 B
Changelog:
  * Wed Apr 14 2021 Martin Gansser  - 2.1.1-39
  - Fix FTBFS (BZ#1943075) with Autoconf 2.71


Package:  chatterino2-2.3.0-1.fc35
Old package:  chatterino2-2.2.2-3.fc34
Summary:  Chat client for twitch.tv
RPMs: chatterino2
Size: 11.73 MiB
Size change:  951.32 KiB
Changelog:
  * Wed Apr 14 2021 Artem Polishchuk  - 2.3.0-1
  - build(update): 2.3.0


Package:  chatty-0.3.0_beta2-1.fc35
Old package:  chatty-0.3.0_beta-1.fc35
Summary:  A libpurple messaging client
RPMs: chatty
Size: 3.06 MiB
Size change:  29.50 KiB
Changelog:
  * Sun Mar 28 2021 Torrey Sorensen  - 0.3.0_beta-2
  * Add patch for matrix crash in encrypted rooms

  * Wed Apr 14 2021 Torrey Sorensen  - 0.3.0_beta2-1
  - Update to chatty 0.3.0 beta 2


Package:  clevis-17-1.fc35
Old package:  clevis-16-2.fc35
Summary:  Automated decryption framework
RPMs: clevis clevis-dracut clevis-luks clevis-systemd clevis-udisks2
Size: 668.59 KiB
Size change:  8.73 KiB
Changelog:
  * Wed Apr 14 2021 Sergio Correia  - 17-1
  - Update to new clevis upstream release, v17.


Package:  cockpit-242-1.fc35
Old package:  cockpit-241-1.fc35
Summary:  Web Console for Linux servers
RPMs: cockpit cockpit-bridge cockpit-doc cockpit-kdump 
cockpit-networkmanager cockpit-packagekit cockpit-pcp cockpit-selinux 
cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws
Size: 18.75 MiB
Size change:  75.48 KiB
Changelog:
  * Wed Apr 14 2021 Matej Marusak  - 242-1
  - Support for pages built with snowpack
  - Machines: Split out to separate project


Package:  cockpit-machines-243-1.fc35
Old package:  cockpit-machines-242.1-1.fc35
Summary:  Cockpit user interface for virtual machines
RPMs: cockpit-machines
Size: 1.69 MiB
Size change:  40.36 KiB
Changelog:
  * Wed Apr 14 2021 Matej Marusak  - 243-1
  - PatternFly 4 updates
  - Translation updates
  - Correctly manage editing of unknown bus type


Package:  cockpit-podman-30-1.fc35
Old package:  cockpit-podman-29-1.fc35
Summary:  Cockpit component for Podman containers
RPMs: cockpit-podman
Size: 384.86 KiB
Size change:  -653.14 KiB
Changelog:
  * Wed Apr 14 2021 Matej Marusak  - 30-1
  - Translation updates
  - PatternFly 4 updates
  - Fix crash with "Used Images" links


Package:  cups-1:2.3.3op2-4.fc35
Old package:  cups-1:2.3.3op2-3.fc35
Summary:  CUPS printing system
RPMs: cups cups-client cups-devel cups-filesystem cups-ipptool 
cups-libs cups-lpd cups-printerapp
Size: 28.97 MiB
Size change:  21.34 KiB
Changelog:
  * Wed Apr 14 2021 Zdenek Dohnal  - 1:2.3.3op2-4
  - 1935318 - old samsung USB devices malfunction with the current (250ms) 
timeout for usb bulk transaction
  - 1949054 - Use nss-user-lookup.target instead of sssd.service and 
ypbind.service
  - 1949068 - Print queue is paused after ipp backend ends with 
CUPS_BACKEND_STOP
  - backport setting multi-user.target via configure, not via drop-in


Pack

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Lennart Poettering]

On Do, 15.04.21 10:20, Luca Boccassi (bl...@debian.org) wrote:

> > I'm confused about this - I had put forth an idea for how to make rpm
> > create this when installing packages (so it works with older or third
> > party packages) but the same xattr could be created for any packaging
> > system. Can you clarify what is rpm dependent here?
> >
> > Matthew.
>
> Hi,
>
> There's a few issues with using xattr, some minor and one major.
> The minor issues is that it's really not great when you are shipping
> stuff around - the source/transport/medium/archiving format might or
> might not support it. Having to deal with this for cross-building
> Linux binaries from Windows with SELinux labels I can assure it's a
> massive headache I'd rather not replicate :-)

I think this might not just be a minor issue btw. One of the main
goals of this feature is to make coredumps reasonably useful when they
originate from a binary shipped as container image. But do all popular
container envs even ship xattrs in their deployment images? I mean,
it's an optional tar feature, and do they all enable it? iirc original
"aufs" backed Docker didn't support xattrs, simply because aufs
didn't. I figure that leaked into all later versions, too, no?

Lennart

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

Re: F35 Change: Package information on ELF objects (System-Wide Change proposal)

[Luca Boccassi]

> On Wed, 2021-04-14 at 15:29 +, Zbigniew Jędrzejewski-Szmek wrote:
> 
> That's fair - if it were possible to get an fd during dump, we could
> use fgetxattr. If not, we can use /proc/$pid/exe - even when deleted
> you can interact with it:
> 
> [malmond@malmond-x1 ~]$ ls -l /proc/$$/exe
> lrwxrwxrwx. 1 malmond malmond 0 Apr 14 15:45 /proc/364665/exe ->
> '/home/malmond/testbash (deleted)'
> [malmond@malmond-x1 ~]$ attr -l /proc/$$/exe
> Attribute "selinux" has a 54 byte value for /proc/364665/exe
> 
> (this is me copying bash, executing it, then deleting it). My thinking
> is this could go in systemd-coredump as it's invoked when dumping core
> anyway. Libraries are accessible from /proc/$pid/map_files/$range.
> 
> 
> I'm confused about this - I had put forth an idea for how to make rpm
> create this when installing packages (so it works with older or third
> party packages) but the same xattr could be created for any packaging
> system. Can you clarify what is rpm dependent here?
> 
> Matthew.

Hi,

There's a few issues with using xattr, some minor and one major.
The minor issues is that it's really not great when you are shipping stuff 
around - the source/transport/medium/archiving format might or might not 
support it. Having to deal with this for cross-building Linux binaries from 
Windows with SELinux labels I can assure it's a massive headache I'd rather not 
replicate :-)

The major issue though is a different one, if related: one of the central, 
nicest capabilities of this proposal is that the ELF note gets _automatically_ 
included in the generated core file. No change required anywhere for that to 
happen.
This means if you are running a fleet of headless systems, and you collect 
corefiles on each node and ship them off for offline analysis, all the metadata 
is nicely included, automagically. That's because the metadata is a property of 
the binary and assigned at the source, not of the system where it runs on and 
applied at the destination.

If you use xattrs though, the metadata suddenly becomes a property of the 
system where the binary happens to run on. The core file won't have it. The 
only way to see it is to have access to the system. It's no longer nicely 
self-contained and "replicating".

Also you are no longer guaranteed to _always_ have the metadata available as 
long as you add it at build time - suddenly, if your binary ends up installed 
on the 'wrong' system/container/whatever, because they are too old or don't 
have a package manager or whatever else, your metadata is gone.

And just to clarify, these use cases are not theoretical - they are very much 
real and already working. And these are the main reasons the team that handles 
crashdumps at Microsoft suggested adding a '.note' to the ELF rather than a new 
header or other proposals. I realize this is less of a problem if you look at 
things exclusively from the closed-loop of a single distribution building its 
stuff and shipping its installations only, but with this spec and 
implementation we are trying hard to have a general, 'world-wide' solution that 
works across distros, version, flavours, etc etc.

In this sense, the implementation I contributed to systemd-coredump is ""just"" 
a reference implementation of how to parse and use the spec, but it's by no 
means intended to be a systemd-only affair and an internal-only protocol, 
ending at the new journald fields.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing creation of Fedora Source-git SIG

[Daniel P . Berrangé]

On Thu, Apr 15, 2021 at 11:52:40AM +0200, Vitaly Zaitsev via devel wrote:
> On 14.04.2021 17:19, Daniel P. Berrangé wrote:
> > That's not my experiance. The cases where I know of maintainers are
> > using a source-git model with Fedora / RHEL already, are doing so
> > precisely because it makes ongoing maint and rebasing way easier
> > than with dist-git, especially when there are alot of downstream
> > patches (100's or even 1000's).
> 
> In some cases, yes.
> 
> > I woudn't expect Fedora to track the git-master in most cases. You
> > generally still want Fedora to be base off releases, so you'd want
> > to track starting fron a release tag or branch.
> 
> One more question. If the upstream ignores tags, can I create tags myself in
> source-git?

Of course. Downstream source-git can have any additional git tags
it wants. It would be wise to pick a naming scheme for the downstream
tags that is unlikely to clash with potential future upstream tags.

> > There are several ways you can do source git and they don't all
> > imply force pushes, so I think this is probably inventing a
> > problem where none yet exists.
> 
> You need force pushes support in order to perform git rebases.

Err, I illustrated an example showing this is not the case, that
you've quoted right here:

> > eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
> > branch, and if I rebase Fedora to v1.2, then I'd just switch to
> > using a v1.2-f33 branch instead. The v1.0-f33 history remains
> > intact forever, no force push required to rebase to new version.
> 
> Looks like a dirty hack. Another pain for the maintainers.

It isn't a dirty hack. This is a normal model for maintaining
maint branches based off releases.

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

Re: F35 liburing dependent packages require rebuild

[Stefan Hajnoczi]

Thanks to Rich for handling the builds.

The update is here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-3250e0b537

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

Re: Announcing creation of Fedora Source-git SIG

[Vitaly Zaitsev via devel]

On 14.04.2021 17:19, Daniel P. Berrangé wrote:

That's not my experiance. The cases where I know of maintainers are
using a source-git model with Fedora / RHEL already, are doing so
precisely because it makes ongoing maint and rebasing way easier
than with dist-git, especially when there are alot of downstream
patches (100's or even 1000's).


In some cases, yes.


I woudn't expect Fedora to track the git-master in most cases. You
generally still want Fedora to be base off releases, so you'd want
to track starting fron a release tag or branch.


One more question. If the upstream ignores tags, can I create tags 
myself in source-git?



There are several ways you can do source git and they don't all
imply force pushes, so I think this is probably inventing a
problem where none yet exists.


You need force pushes support in order to perform git rebases.


eg if upstream has v1.0 and v1.2 tags, I might have a 'v1.0-f33'
branch, and if I rebase Fedora to v1.2, then I'd just switch to
using a v1.2-f33 branch instead. The v1.0-f33 history remains
intact forever, no force push required to rebase to new version.


Looks like a dirty hack. Another pain for the maintainers.

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

Re: Orphaned packages looking for new maintainers

[Vitaly Zaitsev via devel]

On 15.04.2021 07:22, Pavel Zhukov wrote:

There is (was?) bug in pagure which allows any Fedora package to
orphan any package in the distribution.


Yes. This is not a bug, this is a critical vulnerability. It must be 
fixed ASAP.


Reported 1 month ago and still not fixed.


Some co-maintainers clicked "orphan" button to drop themself from the list
of the maintainers but this button deletes silently main admin.


Must be fixed too.

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

Fedora-Cloud-32-20210415.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20210414.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 15. 04. 21 6:54, Miroslav Suchý wrote:

Dne 12. 04. 21 v 18:32 Miro Hrončok napsal(a):

cura-lulzbot orphan, spot 6 weeks ago
fedora-jam-kde-theme  jvlomax, orphan 0 weeks ago
gnome-desktop alexl, caolanm, fmuellner, gnome-sig, 0 weeks ago
  orphan, rhughes


How this can happen? I.e., orphaned package with one or more co-maintainers.

This is definitively repetitive pattern. I wonder whether we have some process 
problem?


Why the main admin does not ask co-maintainers first?


I think we get lucky if the no-longer-interested maintainers at least care 
enough to actually orphan the packages. In most of the cases, they just go AWOL 
and we wait for non-responsive process / FTBFS / FTI to happen.


In the ideal case, orphanings are reported on devel list and co-maintainers are 
contacted directly, but that almost never happens. (Anecdata: I've even seen Red 
Hat associates who maintain package X in RHEL to silently orphan it in Fedora 
without even being subscribed to devel.)


That's why the co-maintainers are listed in this report and they are Bcced, so 
they get notified about the situation. As far as process goes, I think that 
works nicely.


Anyway, gnome-desktop has reason for being orphaned actually listed in pagure:

"Unmaintained upstream -- Nothing currently maintained should use this anymore. 
A lot of people file general GNOME bugs on this component, thinking it's some 
catch-all, so a lot of time is spent reassigning bugs to gnome-shell etc."


And if they are not 
interested in, why they are still listed as co-maintainers?


There are many possibilities:

1. They don't ever read Fedora email.

2. They are gone from Fedora but nobody non-responsive-removed them yet.

3. They are interested in co-maintaining only,
   rather letting the package to be retired than taking the responsibility
   of being the primary contact person for it.

4. They are co-maintainers only for other branches (EPEL or older Fedora)
   (I even sometimes orphan a package and add myself as co-maintainer so I can
solve the problems in released Fedoras until they all go EOL,
see for example the case of cura-lulzbot: @spot orphaned it, announced it,
but he remains a co-maintainer which is completely fine --
users will report bugs for Fedora 32/33/34).

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1949736] perl-Geo-ShapeFile-3.01 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210415.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20210414.0):

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

Passed openQA tests: 6/7 (x86_64), 6/7 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 liburing dependent packages require rebuild

[Richard W.M. Jones]

On Wed, Apr 14, 2021 at 08:58:51PM +0100, Richard W.M. Jones wrote:
> 
> Once this build has completed:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=65937416
> 
> we'll be all done (except mpd).

That failed because of an unstable qemu test.  I patched that
and submitted this new job:

https://koji.fedoraproject.org/koji/taskinfo?taskID=65970655

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] Fedora Linux 34 Cloud Test Day 2021-04-16 through 2021-04-19

[Sumantro Mukherjee]

Hey All,

We are running a Fedora Linux 34 Cloud Test Day from Friday, April 16
through Monday, April 19. As a part of this test day[0] we will be
testing the Fedora Cloud Images. You can test the regular base image
using testcloud or if you have an Amazon account, you can test the
AMIs listed on the wiki. The results page[1], has the test cases which
are basic and must pass.

As usual, we will be around #fedora-test-day over freenode for any questions!

[0] https://fedoraproject.org/wiki/Test_Day:2021-04-16_Fedora_34_Cloud_Testday
[1] https://testdays.fedoraproject.org/events/112

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

[389-devel] 389 DS nightly 2021-04-15 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/04/15/report-389-ds-base-2.0.4-20210415git0a504c8e7.fc33.x86_64.html
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure