[389-devel] 389 DS nightly 2021-07-07 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/07/07/report-389-ds-base-2.0.6-20210707gitfb70c5c83.fc34.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

Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)

[Remi Collet]

Le 06/07/2021 à 20:28, David Cantrell a écrit :

On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote:
On Tue, Jul 6, 2021 at 12:29 PM David Cantrell  
wrote:


On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
>https://fedoraproject.org/wiki/Changes/libmemcached-awesome
>
>== Summary ==
>Switch from libmemcached to libmemcached-awesome
>
>== Owner ==
>* Name: [[User:Remi| Remi Collet]]
>* Email: remi at fedoraproject dot org
>
>== Detailed Description ==
>
>libmemcache 1.0.18 was released in February 2014, so hasn't received
>an update for 7 years.
>
>libmemcache-awesome is a fork providing same libraries, tools with
>API/ABI compatibility.
>
>== Benefit to Fedora ==
>
>Rely on a maintained project.
>
>
>
>== Scope ==
>* Proposal owners: Check Koschei status. Test with latest version to
>ensure compatibility. Work with upstream on bug fixing. Needed mass
>rebuild (C extensions) done by change owner.
>
>* Other developers: N/A (not a System Wide Change)
>* Release engineering:
>* Policies and guidelines: N/A (not a System Wide Change)
>* Trademark approval: N/A (not needed for this Change)
>
>
>== Upgrade/compatibility impact ==
>N/A (not a System Wide Change)
>
>== How To Test ==
>
>* install and play with your application
>
>== User Experience ==
>
>Developers and system administrators will have the great benefit or
>running a maintained library.
>
>
>== Dependencies ==
>
>All php-* packages (and some *-php)
>
>== Contingency Plan ==
>* Contingency mechanism: Drop not compatible packages.
>* Contingency deadline: N/A (not a System Wide Change)
>* Blocks release? N/A (not a System Wide Change)
>
>== Documentation ==
>
>* [https://awesomized.github.io/libmemcached/ Upstream documentation]
>

The change proposal indicates this is a drop-in API replacement
project, but will this introduce a new package named
'libmemcached-awesome' and we let libmemcached go out to pasture?  Or
is this changing the Source0 of the libmemcached package to just use
this new upstream?

If the former, will the new package provide proper Provides/Conflicts
against the existing libmemcached package or are there plans to allow
both to be installed at the same time?


From what I can tell, you can't have both installed in parallel, so I
think I'd prefer to see the Source0 in libmemcached change to the fork
rather than introducing a new source package and complicating things.


That's more or less the direction I was going with this thought.

If we are fairly confident libmemcached is dead upstream, then I see
no reason to just replace Source0 with the active project.  On the
other hand, we have seen projects come back from what appears to be a
dead upstream and then you have a name conflict and/or confusion.
Also we do have naming policy for Fedora packages that at least
encourages the package name to match the upstream project name in
cases where that will work.

I don't know the state of libmemcached and whether or not it will come
back to life (or if it's even dead upstream).  With that in mind, I
would prefer to see:

     * Addition of libmemcached-awesome as a new package
     * libmemcached-awesome Provides libmemcached
     * libmemcached-awesome Obsoletes libmemcached
     * Orphan libmemcached


That the plan (new package named, as the project, libmemcached-awesome)

FYI, the rename was an explicit requirement of the old project author.


Additionally, if any packages carry a Requires or dynamic dependency
on libmemcached, those should be updated to libmemcached-awesome.  The
lazy way would be to add Epoch: 1 to libmemcached-awesome and let
libmemcached fade away.


libmemcached will be retired, everything provided by "libmemcached" is 
now provided byt the new one




Remi
___
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 1971305] perl-Dist-Zilla-6.023 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Dist-Zilla-6.022 is|perl-Dist-Zilla-6.023 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 6.023
Current version/release in rawhide: 6.017-3.fc35
URL: http://search.cpan.org/dist/Dist-Zilla/

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


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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  40  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef   
openjpeg2-2.3.1-11.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1ad14f84b0   
ansible-2.9.23-1.el7
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bd790583ee   
seamonkey-2.53.8-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4cfaa8ab63   
djvulibre-3.5.25.3-24.el7


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

python-regex-2021.7.6-1.el7

Details about builds:



 python-regex-2021.7.6-1.el7 (FEDORA-EPEL-2021-61d1701bfe)
 Alternative regular expression module, to replace re

Update Information:

Update python-regex to the latest release.

ChangeLog:

* Tue Jul  6 2021 Thomas Moschny  - 2021.7.6-1
- Update to 2021.7.6.
* Mon Jul  5 2021 Thomas Moschny  - 2021.7.1-1
- Update to 2021.7.1.


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-f77315a931   
seamonkey-2.53.8-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3eb74527f8   
chromium-91.0.4472.114-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4c3bbff96   
libolm-3.2.4-2.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-15c5b7660c   
suricata-5.0.7-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ac096c00b0   
libtpms-0.8.4-0.20210624gita594c4692a.el8.1


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

python-regex-2021.7.6-1.el8

Details about builds:



 python-regex-2021.7.6-1.el8 (FEDORA-EPEL-2021-7991bfb0de)
 Alternative regular expression module, to replace re

Update Information:

Update python-regex to the latest release.

ChangeLog:

* Tue Jul  6 2021 Thomas Moschny  - 2021.7.6-1
- Update to 2021.7.6.
* Mon Jul  5 2021 Thomas Moschny  - 2021.7.1-1
- Update to 2021.7.1.
* Thu Jun  3 2021 Python Maint  - 2021.4.4-2
- Rebuilt for Python 3.10


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

[Bug 1979760] New: perl-Devel-PPPort-3.63 is available

[bugzilla]

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

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



Latest upstream release: 3.63
Current version/release in rawhide: 3.62-478.fc35
URL: http://search.cpan.org/dist/Devel-PPPort/

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


-- 
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: Starting a riscv64 VM from an ArchLinux x86_64 host

[Takayuki Nagata]

Hi,

Maybe, you need to add the "-bios none" option. I booted the image
with the following options on Fedora 33.

~~~
$ qemu-system-riscv64 -bios none -nographic -machine virt -smp 1 -m 1G \
-kernel Fedora-Minimal-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf
\
-device virtio-blk-device,drive=hd0 \
-drive file=Fedora-Minimal-Rawhide-20200108.n.0-sda.raw,format=raw,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,hostfwd=tcp::1-:22
~~~

Takayuki Nagata

2021年7月6日(火) 10:16 Andrej Podzimek via devel :
>
> Hi Fedora developers!
>
> I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on 
> this wiki page: 
> https://fedoraproject.org/wiki/Architectures/RISC-V/Installing I have a 
> reasonably recent qemu and virt-manager:
>
> ```
> qemu 6.0.0-3
> qemu-arch-extra 6.0.0-3
> libvirt 1:7.3.0-1
> virt-manager 3.2.0-1
> ```
>
> All virt-builder steps work perfectly fine and produce an image.
>
> However, I cannot start an instance. I tried the image prepared with 
> virt-builder, the manually downloaded image, the nightly image, direct kernel 
> loading (configured in libvirt / virt-manager), but none of that worked.
>
> For the nightly instances in particular, the wiki says one should extract 
> "firmware" from /opensbi/... in the image. However, there is _no_ such 
> directory in the image (and also no file called .elf). This information may 
> be outdated.
>
> When using the downloaded .elf file (as described in the "Download using 
> virt-builder" section), I get this from qemu:
>
> ```
> qemu-system-riscv64: Some ROM regions are overlapping
> These ROM regions might have been loaded by direct user request or by default.
> They could be BIOS/firmware images, a guest kernel, initrd or some other file 
> loaded into guest memory.
> Check whether you intended to load all this guest code, and whether it has 
> been built to load to the correct addresses.
>
> The following two regions overlap (in the memory address space):
>/usr/bin/../share/qemu/opensbi-riscv64-generic-fw_dynamic.bin (addresses 
> 0x8000 - 0x80012558)
>
> VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf
>  ELF program header segment 0 (addresses 0x8000 - 
> 0x8000d0e0)
> ```
>
> The qemu command line was:
>
> ```
> qemu-system-riscv64 \
>  -nographic \
>  -machine virt \
>  -smp 8 \
>  -m 32G \
>  -kernel 
> VirtualMachineMedia/Fedora-Developer-Rawhide-20200108.n.0-fw_payload-uboot-qemu-virt-smode.elf
>  \
>  -object rng-random,filename=/dev/urandom,id=rng0 \
>  -device virtio-rng-device,rng=rng0 \
>  -device virtio-blk-device,drive=hd0\
>  -drive 
> file=VirtualMachineMedia/Fedora-Developer-Rawhide-20210421.n.0-sda.raw,format=raw,id=hd0
>  \
>  -device virtio-net-device,netdev=usernet \
>  -netdev user,id=usernet,hostfwd=tcp::1-:22
> ```
>
> Idea No. 1: Drop the "-kernel ..." argument. In that case I get an OpenSBI 
> splash that looks like this: https://pastebin.com/5QKJqkRg Sadly, the VM is 
> frozen and nothing else happens. There is no network communication either.
>
> It looks like this^^^ configuration might start something, but fails to load 
> a kernel properly (or the like). The nightly image appears to contain 
> multiple bootloaders, but the wiki doesn't say how to run them.
>
> Idea No. 2: Delete /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin to 
> see if the conflict goes away. (For the record, the file is owned by 
> qemu-arch-extra.) Well, qemu then says 'qemu-system-riscv64: Unable to load 
> the RISC-V firmware "opensbi-riscv64-generic-fw_dynamic.bin"'.
>
> Idea No. 3: Extract the kernel (vmlinuz-5.10.6-200.0.riscv64.fc33.riscv64) 
> and initramdisk (initramfs-5.10.6-200.0.riscv64.fc33.riscv64.img) from the 
> nightly image and load them "directly" (using virt-manager) like this: 
> https://pastebin.com/36RVR75r
>
> This^^^ failed the same way as all virt-manager experiments (with nightly / 
> manually downloaded / built with virt-builder) images: A black console with a 
> blinking cursor and nothing happens. No activity on the virtual bridge either.
>
> Interestingly, each time qemu starts and freezes, host CPU utilization is 
> about 200% (i.e., 2 cores worth of load, not 1 core, not 8 cores etc.). (The 
> host machine is a Ryzen 3950X with 32 CPUs altogether and 128 GB RAM.)
>
> What am I doing wrong (apart from not using Fedora as a host)?
> Why am I getting a weird conflict with a system built-in OpenSBI? Could the 
> built-in firmware be incompatible with the Fedora image?
> Are there any up-to-date instructions on how to get the recent nightly images 
> (without the /opensbi directory) working?
> How can I debug why qemu / OpenSBI freezes? Does OpenSBI need a bit of 
> configuration to boot the image?
>
> I'll retry this on a Fedora VM if need be, but would also like to understand 
> what the issue is on Arch. 

Re: The future of legacy BIOS support in Fedora.

[Neal Gompa]

On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy  wrote:
>
> On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
>  wrote:
> >
> > > […] and move to uefi only supported boot which
> > > has been available on any common intel based x86 platform since atleast
> > > 2005.
> >
> > (U)EFI was not available for the general market in 2005 (except on Apple 
> > devices maybe). It was introduced around 2011.
>
> UEFI support was introduced in Windows Vista, 2007. And it was refined
> in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in
> the Linux world around 2012. And became a requirement for all new
> consumer PC's wanting Windows 10 hardware certification, in 2015.
> Server hardware has had more leeway.
>
> > I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, 
> > manufactured around 2010 when (U)EFI was not available. One is new enough 
> > to having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI 
> > integration so I was forced to install it in legacy BIOS mode.
> >
> > In other words: I think it is too early to drop non-(U)EFI BIOS support.
>
> I think there probably are too many legacy BIOS systems for us to drop
> legacy support in the near term.
>
> We might consider:
>
> (a) Revisiting GPT by default. By revisiting that means exploring the
> bugs and work arounds. The reason for this is moving toward a
> self-describing boot process, and abstracting the low level bootloader
> requirements from user space configuration. There's good reasons to
> get the user space configuration with Boot Loader Spec support
> sufficiently abstracted that we could do a drop in bootloader swap one
> day, either for use case specific reasons, or distro wide.
>
> It could be that we can abandon hardware that can't tolerate GPT, if
> the benefits outweigh the consequences.
>
> (b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm
> not sure about the status of this work though, and if it's intended to
> bring legacy BIOS systems forward with a single UEFI approach in a
> distribution. Or if the intent was only for development purposes until
> native UEFI implementations became more ubiquitous. Would adding this
> kind of layer just be asking for more things to maintain,
> troubleshoot, test, and break?
> https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
>

DUET would probably be the best shot, but it was removed at the end of
2018 due to the lack of interest and usage[1]. If someone wants to
step up to maintain the DuetPkg module for EDK2, we could start going
down the path of streamlining the boot process in the same way that
has occurred in ARM[2]. We'd also benefit from a relatively consistent
UEFI implementation as EDK2 is built on TianoCore[3], which is also
where OVMF/AVMF used for UEFI on KVM is from.

[1]: https://bugzilla.tianocore.org/show_bug.cgi?id=1322
[2]: https://fedoraproject.org/wiki/Changes/ARMv7UEFI
[3]: https://www.tianocore.org/



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

Re: The future of legacy BIOS support in Fedora.

[Chris Murphy]

On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
 wrote:
>
> > […] and move to uefi only supported boot which
> > has been available on any common intel based x86 platform since atleast
> > 2005.
>
> (U)EFI was not available for the general market in 2005 (except on Apple 
> devices maybe). It was introduced around 2011.

UEFI support was introduced in Windows Vista, 2007. And it was refined
in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in
the Linux world around 2012. And became a requirement for all new
consumer PC's wanting Windows 10 hardware certification, in 2015.
Server hardware has had more leeway.

> I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, 
> manufactured around 2010 when (U)EFI was not available. One is new enough to 
> having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI 
> integration so I was forced to install it in legacy BIOS mode.
>
> In other words: I think it is too early to drop non-(U)EFI BIOS support.

I think there probably are too many legacy BIOS systems for us to drop
legacy support in the near term.

We might consider:

(a) Revisiting GPT by default. By revisiting that means exploring the
bugs and work arounds. The reason for this is moving toward a
self-describing boot process, and abstracting the low level bootloader
requirements from user space configuration. There's good reasons to
get the user space configuration with Boot Loader Spec support
sufficiently abstracted that we could do a drop in bootloader swap one
day, either for use case specific reasons, or distro wide.

It could be that we can abandon hardware that can't tolerate GPT, if
the benefits outweigh the consequences.

(b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm
not sure about the status of this work though, and if it's intended to
bring legacy BIOS systems forward with a single UEFI approach in a
distribution. Or if the intent was only for development purposes until
native UEFI implementations became more ubiquitous. Would adding this
kind of layer just be asking for more things to maintain,
troubleshoot, test, and break?
https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg



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

Soname bumps and a review swap

[Jerry James]

Next week, I plan to build the following in Rawhide:
- antic 0.2.4
- e-antic 1.0.1 (soname bump)
- eclib 20210625 (soname bump)
- flint 2.7.1 (soname bump)
- normaliz 3.9.0

The following packages will be rebuilt due to the changes above:
- arb
- polymake
- pynac
- sagemath
- Singular

The eclib update may not be possible.  I am still determining whether
the current sagemath release can handle that update.  If not, eclib
will just be rebuilt for the flint soname bump, but remain at its
current version (20190909).

The new version of normaliz has a new dependency, hash-library:

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

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

Re: Trivial review swap: python-configupdater

[Arthur Bols]

On 06/07/2021 21:06, Ankur Sinha wrote:

Hi folks,

Would someone like to swap reviews please? I've got a trivial Python
package that needs to be reviewed. It's a new BR for the new version of
python-pyscaffold that's currently FTBFS and is blocking a couple of
packages in rawhide.

Review here: https://bugzilla.redhat.com/show_bug.cgi?id=1979708

Hi Ankur,

I don't have a package for the moment, but I'll review it.
I think it would be better for me to start with simpler packages anyway. :)

Kind regards,
Arthur
___
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: The future of legacy BIOS support in Fedora.

[Christian Stadelmann]

> […] and move to uefi only supported boot which 
> has been available on any common intel based x86 platform since atleast 
> 2005.

(U)EFI was not available for the general market in 2005 (except on Apple 
devices maybe). It was introduced around 2011.

I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, 
manufactured around 2010 when (U)EFI was not available. One is new enough to 
having (U)EFI, but it's a mess and never worked with Fedora's (U)EFI 
integration so I was forced to install it in legacy BIOS mode.

In other words: I think it is too early to drop non-(U)EFI BIOS support.
___
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-20210706.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 13/138 (aarch64), 2/199 (x86_64)

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

ID: 921850  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/921850
ID: 921884  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/921884
ID: 921885  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/921885
ID: 921891  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/921891
ID: 922010  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/922010
ID: 922028  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/922028
ID: 922038  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/922038
ID: 922046  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/922046
ID: 922108  Test: aarch64 Minimal-raw_xz-raw.xz 
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/922108
ID: 922112  Test: aarch64 Minimal-raw_xz-raw.xz release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/922112

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

ID: 921810  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/921810
ID: 921811  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/921811
ID: 921867  Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/921867
ID: 921903  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/921903
ID: 922004  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/922004

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

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

ID: 921834  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/921834
ID: 921923  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/921923
ID: 922000  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/922000
ID: 922002  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/922002

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

ID: 921894  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/921894
ID: 921962  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/921962
ID: 922022  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/922022
ID: 922105  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/922105

Passed openQA tests: 193/199 (x86_64), 107/138 (aarch64)

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

ID: 921784  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/921784
ID: 921817  Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/921817
ID: 921818  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/921818
ID: 921819  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/921819
ID: 921820  Test: x86_64 Silverblue-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/921820
ID: 921821  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/921821
ID: 921822  Test: x86_64 Silverblue-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/921822
ID: 921823  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/921823
ID: 921824  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/921824
ID: 921825  Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/921825
ID: 921826  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/921826
ID: 921827  Test: x86_64 

Fedora-IoT-35-20210706.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old failures (same test failed in Fedora-IoT-35-20210705.0):

ID: 922083  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/922083
ID: 922085  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/922085
ID: 922086  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/922086
ID: 922099  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/922099
ID: 922100  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/922100
ID: 922114  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/922114
ID: 922115  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/922115
ID: 922116  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/922116

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210705.0):

ID: 922070  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/922070
ID: 922071  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/922071
ID: 922072  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/922072
ID: 922087  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/922087

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

PyQt6 to Fedora 35

[Cătălin George Feștilă]

Can we add PyQt6 to Fedora 35 repo?
___
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

Trivial review swap: python-configupdater

[Ankur Sinha]

Hi folks,

Would someone like to swap reviews please? I've got a trivial Python
package that needs to be reviewed. It's a new BR for the new version of
python-pyscaffold that's currently FTBFS and is blocking a couple of
packages in rawhide.

Review here: https://bugzilla.redhat.com/show_bug.cgi?id=1979708

-- 
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: F35 Change: tzdata-minimal (Self-Contained Change proposal)

[David Cantrell]

On Tue, Jul 06, 2021 at 01:20:47PM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.

== Feedback ==
We have had requests for this functionality in order to support
minimal container installations.  Currently some container kickstart
installations already ad hoc remove most of the timezone information
provided by tzdata, leaving only UTC support available.  This change
provides a formal method of providing this support.

Both the glibc and python teams are aware of this proposed change.
This change does not currently require changes in their code.  The
goal is for those packages that currently require tzdata as part of
their build or install, move towards recommending tzdata instead.

== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required by tzdata.


== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.


What is supposed to be in tzdata-minimal?  Is it
/usr/share/zoneinfo/UTC or that and more?

Forcibly removing tzdata on a fresh Fedora VM that I just set up has
the system fall back to UTC, as expected.  On this incredibly small
install, tzdata is required glibc-common, python3-libs, and
python3-dateutil.  The last one is reasonable, but for all of them I
ask if tzdata is actually a hard dependency or if it can become a weak
dependency and this change proposal could become "make tzdata
something easily removable" rather than creating more tzdata packages.

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: libmemcached-awesome (Self-Contained Change proposal)

[David Cantrell]

On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote:

On Tue, Jul 6, 2021 at 12:29 PM David Cantrell  wrote:


On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
>https://fedoraproject.org/wiki/Changes/libmemcached-awesome
>
>== Summary ==
>Switch from libmemcached to libmemcached-awesome
>
>== Owner ==
>* Name: [[User:Remi| Remi Collet]]
>* Email: remi at fedoraproject dot org
>
>== Detailed Description ==
>
>libmemcache 1.0.18 was released in February 2014, so hasn't received
>an update for 7 years.
>
>libmemcache-awesome is a fork providing same libraries, tools with
>API/ABI compatibility.
>
>== Benefit to Fedora ==
>
>Rely on a maintained project.
>
>
>
>== Scope ==
>* Proposal owners: Check Koschei status. Test with latest version to
>ensure compatibility. Work with upstream on bug fixing. Needed mass
>rebuild (C extensions) done by change owner.
>
>* Other developers: N/A (not a System Wide Change)
>* Release engineering:
>* Policies and guidelines: N/A (not a System Wide Change)
>* Trademark approval: N/A (not needed for this Change)
>
>
>== Upgrade/compatibility impact ==
>N/A (not a System Wide Change)
>
>== How To Test ==
>
>* install and play with your application
>
>== User Experience ==
>
>Developers and system administrators will have the great benefit or
>running a maintained library.
>
>
>== Dependencies ==
>
>All php-* packages (and some *-php)
>
>== Contingency Plan ==
>* Contingency mechanism: Drop not compatible packages.
>* Contingency deadline: N/A (not a System Wide Change)
>* Blocks release? N/A (not a System Wide Change)
>
>== Documentation ==
>
>* [https://awesomized.github.io/libmemcached/ Upstream documentation]
>

The change proposal indicates this is a drop-in API replacement
project, but will this introduce a new package named
'libmemcached-awesome' and we let libmemcached go out to pasture?  Or
is this changing the Source0 of the libmemcached package to just use
this new upstream?

If the former, will the new package provide proper Provides/Conflicts
against the existing libmemcached package or are there plans to allow
both to be installed at the same time?


From what I can tell, you can't have both installed in parallel, so I
think I'd prefer to see the Source0 in libmemcached change to the fork
rather than introducing a new source package and complicating things.


That's more or less the direction I was going with this thought.

If we are fairly confident libmemcached is dead upstream, then I see
no reason to just replace Source0 with the active project.  On the
other hand, we have seen projects come back from what appears to be a
dead upstream and then you have a name conflict and/or confusion.
Also we do have naming policy for Fedora packages that at least
encourages the package name to match the upstream project name in
cases where that will work.

I don't know the state of libmemcached and whether or not it will come
back to life (or if it's even dead upstream).  With that in mind, I
would prefer to see:

* Addition of libmemcached-awesome as a new package
* libmemcached-awesome Provides libmemcached
* libmemcached-awesome Obsoletes libmemcached
* Orphan libmemcached

Additionally, if any packages carry a Requires or dynamic dependency
on libmemcached, those should be updated to libmemcached-awesome.  The
lazy way would be to add Epoch: 1 to libmemcached-awesome and let
libmemcached fade away.

None of the above is mentioned in the change proposal and since the
change is about the mechanics of how to do this, I'd like to see it
explained out.

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: [Test-Announce] [Test Week] Fedora Linux Kernel 5.13 2021-07-11 through 2021-07-18

[Cătălin George Feștilă]

is this date?
[root@desk mythcat]# koji list-builds --package=kernel --after="2021-07-01"
BuildBuilt by  State
---    

kernel-5.14.0-0.rc0.20210701gitdbe69e433722.6.eln112 jforbes   
COMPLETE
kernel-5.14.0-0.rc0.20210701gitdbe69e433722.6.fc35   jforbes   
COMPLETE
kernel-5.14.0-0.rc0.20210702git3dbdb38e2869.6.eln112 jforbes   
FAILED
kernel-5.14.0-0.rc0.20210702git3dbdb38e2869.6.fc35   jforbes   
FAILED
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] libaom update issue

[Chris Schanzle]

Hi,

I'm getting a yum update failure with seamonkey 2.53.7-4 which requires libaom 
(src rpm=aom), which doesn't have a clean update path:

# yum update seamonkey libaom
Loaded plugins: aliases, changelog, kabi, langpacks, post-transaction-actions, 
priorities, protectbase, ps, remove-with-leaves,
  : tmprepo, verify, versionlock
Loading support for Red Hat kernel ABI
0 packages excluded due to repository protections
Resolving Dependencies
--> Running transaction check
---> Package libaom.x86_64 0:1.0.0-8.20190810git9666276.el7 will be updated
--> Processing Dependency: libaom.so.0()(64bit) for package: 
seamonkey-2.53.7-4.el7.x86_64
---> Package libaom.x86_64 0:3.1.1-1.el7 will be an update
--> Finished Dependency Resolution
Error: Package: seamonkey-2.53.7-4.el7.x86_64 (@epel)
   Requires: libaom.so.0()(64bit)
   Removing: libaom-1.0.0-8.20190810git9666276.el7.x86_64 (@epel)
   libaom.so.0()(64bit)
   Updated By: libaom-3.1.1-1.el7.x86_64 (epel)
  ~libaom.so.3()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Any thoughts why this happened?  It's unclear to me exactly what the issue is 
(note the .so bump from .0 to .3).  No doubt I could likely remove both and 
install again, but just thought I'd inquire before changing anything.  I only 
have a few systems this issue, so not a big deal.

Thanks!

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

F35 Change: GHC 8.10 and Stackage lts-18 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GHC_8.10_%26_Stackage_18

== Summary ==
The GHC Haskell compiler will be updated from major version 8.8 to 8.10,
and Haskell packages will be updated from Stackage LTS 16 to LTS 18 versions.

== Owner ==
* Name: [[User:Petersen| Jens Petersen]] (Haskell SIG)
* Email: 


== Detailed Description ==
For Fedora 35, the GHC Haskell compiler will be updated from version
8.8.4 to the latest stable 8.10.5 release (rebasing from the ghc:8.10
module stream).
Along with this, Haskell packages in [https://www.stackage.org
Stackage] (the stable Haskell source package distribution) will be
updated from the versions in LTS 16 to latest LTS 18 release.
Haskell packages not in Stackage will be updated to the latest
appropriate version in the upstream [https://hackage.haskell.org
Hackage] package repository.

On the s390x architecture, ghc-8.10 now supports the llvm backend,
which should improve s390x performance significantly.


== Benefit to Fedora ==
Fedora users will benefit from access to the latest stable Haskell
compiler release, package tools, and current stable Haskell packages
from Stackage LTS.

GHC 8.10 features performance improvements, new language extension
features, and bugfixes (see the release notes linked in the
Documentation section for more details).

== Scope ==
* Proposal owners:
** rebase ghc to 8.10.5
** update ghc-rpm-macros to the final version for F35 [done]
** refresh packagings with the latest cabal-rpm release
** update packages to latest [https://www.stackage.org/lts-18.1
Stackage LTS 18.1] versions using cabal-rpm
** build all the packages in a Koji sidetag repo in dependency order
** When finished push all builds through Bodhi to Rawhide before the
mass rebuild

* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Any dropped packages will have obsoletes added.
Otherwise there should not be any direct upgrade impact.

Users' Haskell projects will get rebuilt with ghc-8.10 when they next
build them and might need small tweaks.

== How To Test ==
* install ghc and cabal-install
* install pandoc, ShellCheck, git-annex
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep ; cabal install 
* test upgrades of F34 Haskell packages to F35

== User Experience ==
Users will have the most recent stable major version of `ghc` and
Haskell libraries and tools available to them.
This makes it easier to build the latest versions of Haskell projects.

In particular `cabal-install` will be updated from 3.0 to 3.2 and
`stack` from 2.3 to 2.7.

== Dependencies ==
(not provided)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)
** Change owner will drop the new builds and revert back to the versions in F34.
* Contingency deadline: Beta Freeze

== Documentation ==
https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10.1-notes.html


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.

== Feedback ==
We have had requests for this functionality in order to support
minimal container installations.  Currently some container kickstart
installations already ad hoc remove most of the timezone information
provided by tzdata, leaving only UTC support available.  This change
provides a formal method of providing this support.

Both the glibc and python teams are aware of this proposed change.
This change does not currently require changes in their code.  The
goal is for those packages that currently require tzdata as part of
their build or install, move towards recommending tzdata instead.

== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required by tzdata.


== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F35 Change: GHC 8.10 and Stackage lts-18 (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GHC_8.10_%26_Stackage_18

== Summary ==
The GHC Haskell compiler will be updated from major version 8.8 to 8.10,
and Haskell packages will be updated from Stackage LTS 16 to LTS 18 versions.

== Owner ==
* Name: [[User:Petersen| Jens Petersen]] (Haskell SIG)
* Email: 


== Detailed Description ==
For Fedora 35, the GHC Haskell compiler will be updated from version
8.8.4 to the latest stable 8.10.5 release (rebasing from the ghc:8.10
module stream).
Along with this, Haskell packages in [https://www.stackage.org
Stackage] (the stable Haskell source package distribution) will be
updated from the versions in LTS 16 to latest LTS 18 release.
Haskell packages not in Stackage will be updated to the latest
appropriate version in the upstream [https://hackage.haskell.org
Hackage] package repository.

On the s390x architecture, ghc-8.10 now supports the llvm backend,
which should improve s390x performance significantly.


== Benefit to Fedora ==
Fedora users will benefit from access to the latest stable Haskell
compiler release, package tools, and current stable Haskell packages
from Stackage LTS.

GHC 8.10 features performance improvements, new language extension
features, and bugfixes (see the release notes linked in the
Documentation section for more details).

== Scope ==
* Proposal owners:
** rebase ghc to 8.10.5
** update ghc-rpm-macros to the final version for F35 [done]
** refresh packagings with the latest cabal-rpm release
** update packages to latest [https://www.stackage.org/lts-18.1
Stackage LTS 18.1] versions using cabal-rpm
** build all the packages in a Koji sidetag repo in dependency order
** When finished push all builds through Bodhi to Rawhide before the
mass rebuild

* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Any dropped packages will have obsoletes added.
Otherwise there should not be any direct upgrade impact.

Users' Haskell projects will get rebuilt with ghc-8.10 when they next
build them and might need small tweaks.

== How To Test ==
* install ghc and cabal-install
* install pandoc, ShellCheck, git-annex
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep ; cabal install 
* test upgrades of F34 Haskell packages to F35

== User Experience ==
Users will have the most recent stable major version of `ghc` and
Haskell libraries and tools available to them.
This makes it easier to build the latest versions of Haskell projects.

In particular `cabal-install` will be updated from 3.0 to 3.2 and
`stack` from 2.3 to 2.7.

== Dependencies ==
(not provided)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?)
** Change owner will drop the new builds and revert back to the versions in F34.
* Contingency deadline: Beta Freeze

== Documentation ==
https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10.1-notes.html


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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

F35 Change: tzdata-minimal (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/tzdata-minimal

== Summary ==
Split the tzdata package into two parts - tzdata and tzdata-minimal.
tzdata will require tzdata-minimal.  tzdata-minimal provides the
minimal files needed to support UTC on containers.

== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: pa...@redhat.com


== Detailed Description ==
This is the first step towards providing support for a minimal, UTC
only, version of tzdata for containers.  The tzdata-minimal package
will be a stand-alone, UTC only, subset of tzdata. The tzdata package
will require tzdata-minimal.

With this framework in place, other packages can develop code to
detect a minimal tzdata installation.  These packages will also need
to provide appropriate messages when users request timezone
information not available when only tzdata-minimal is installed.

== Feedback ==
We have had requests for this functionality in order to support
minimal container installations.  Currently some container kickstart
installations already ad hoc remove most of the timezone information
provided by tzdata, leaving only UTC support available.  This change
provides a formal method of providing this support.

Both the glibc and python teams are aware of this proposed change.
This change does not currently require changes in their code.  The
goal is for those packages that currently require tzdata as part of
their build or install, move towards recommending tzdata instead.

== Benefit to Fedora ==
This change will reduce the size of base container installations.

== Scope ==
* Proposal owners: Implement the proposal.
* Other developers: Developers need to ensure that their packages
continue to build and install with the new split tzdata/tzdata-minimal
package changes.

* Release engineering: No coordination required with Release Engineering.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==
The only visible change will be a new package tzdata-minimal required by tzdata.


== How To Test ==
Run a dnf upgrade of tzdata and observe that tzdata-minimal is now
also installed as a dependency.


== User Experience ==
Users will see that new updates to tzdata include a new package
dependency on tzdata-minimal.


== Dependencies ==
This change does not require or depend on changes to other packages.
However, we hope that dependent packages will work towards
recommending tzdata for builds and installs rather than requiring it.


== Contingency Plan ==
* Contingency mechanism: If we are unable to complete this feature by
the final development freeze, we will revert to the shipped
configuration.
* Contingency deadline: 100% Code complete deadline
* Blocks release? No

== Documentation ==
No documentation changes are needed at this time.


== Release Notes ==
The tzdata package is now divided into a UTC only package,
tzdata-minimal, and tzdata.



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing fmt library soversion bump

[Richard Shaw]

On Mon, Jul 5, 2021 at 8:19 AM Richard Shaw  wrote:

> folly failed:
>
> /usr/bin/ld: ../../../libfolly.so.2021.06.07.00: undefined reference to 
> `typeinfo for snappy::Source'
> collect2: error: ld returned 1 exit status
>
> I verified that "-lsnappy" is in the command line so not sure what's going
> on there, but it doesn't look fmt related.
>
> https://kojipkgs.fedoraproject.org//work/tasks/5080/71345080/build.log
>

This is due to '-fno-rtti' in the snappy build. Apparently it must be
enabled but is disabled by default. I'm not sure of any consequences of
enabling it or why it's disabled by default.

https://github.com/facebook/proxygen/issues/361

Thanks,
Richard
___
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: libmemcached-awesome (Self-Contained Change proposal)

[Neal Gompa]

On Tue, Jul 6, 2021 at 12:29 PM David Cantrell  wrote:
>
> On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:
> >https://fedoraproject.org/wiki/Changes/libmemcached-awesome
> >
> >== Summary ==
> >Switch from libmemcached to libmemcached-awesome
> >
> >== Owner ==
> >* Name: [[User:Remi| Remi Collet]]
> >* Email: remi at fedoraproject dot org
> >
> >== Detailed Description ==
> >
> >libmemcache 1.0.18 was released in February 2014, so hasn't received
> >an update for 7 years.
> >
> >libmemcache-awesome is a fork providing same libraries, tools with
> >API/ABI compatibility.
> >
> >== Benefit to Fedora ==
> >
> >Rely on a maintained project.
> >
> >
> >
> >== Scope ==
> >* Proposal owners: Check Koschei status. Test with latest version to
> >ensure compatibility. Work with upstream on bug fixing. Needed mass
> >rebuild (C extensions) done by change owner.
> >
> >* Other developers: N/A (not a System Wide Change)
> >* Release engineering:
> >* Policies and guidelines: N/A (not a System Wide Change)
> >* Trademark approval: N/A (not needed for this Change)
> >
> >
> >== Upgrade/compatibility impact ==
> >N/A (not a System Wide Change)
> >
> >== How To Test ==
> >
> >* install and play with your application
> >
> >== User Experience ==
> >
> >Developers and system administrators will have the great benefit or
> >running a maintained library.
> >
> >
> >== Dependencies ==
> >
> >All php-* packages (and some *-php)
> >
> >== Contingency Plan ==
> >* Contingency mechanism: Drop not compatible packages.
> >* Contingency deadline: N/A (not a System Wide Change)
> >* Blocks release? N/A (not a System Wide Change)
> >
> >== Documentation ==
> >
> >* [https://awesomized.github.io/libmemcached/ Upstream documentation]
> >
>
> The change proposal indicates this is a drop-in API replacement
> project, but will this introduce a new package named
> 'libmemcached-awesome' and we let libmemcached go out to pasture?  Or
> is this changing the Source0 of the libmemcached package to just use
> this new upstream?
>
> If the former, will the new package provide proper Provides/Conflicts
> against the existing libmemcached package or are there plans to allow
> both to be installed at the same time?

From what I can tell, you can't have both installed in parallel, so I
think I'd prefer to see the Source0 in libmemcached change to the fork
rather than introducing a new source package and complicating things.



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

Re: Is there a command to expand Source0 from spec file to the final URL?

[Richard W.M. Jones]

On Tue, Jul 06, 2021 at 05:20:16PM +0100, Lyes Saadi wrote:
> Hello,
> 
> It is possible, using spectool:
> 
> spectool -s 0 path/to/specfile.spec

I was looking at the wrong tool for some reason :-)

Thanks all.

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

Re: Starting a riscv64 VM from an ArchLinux x86_64 host

[Andrej Podzimek via devel]

Hi Fedora developers!







I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on 
this wiki page: https://fedoraproject.org/wiki/Architectures/RISC-V/Installing 
I have a reasonably recent qemu and virt-manager:







I'm not sure, but you might want to chat with david in #fedora-riscv



on Libera.







Also it may work better using libvirt to manage the guest.




Alright, I'll try to post into #fedora-riscv then.



For the record, I've re-done all my experiments on a Fedora machine today (an 
all-default Fedora 34 VM installed from the KDE spin live image). (For riscv 
emulation it hopefully shouldn't matter if the host is a VM or not. The machine 
can do nested virtualization, but this is irrelevant for emulation.)



I tried both raw qemu-system-riscv64 and libvirt, but sadly the results were exactly the 
same as before, both the address conflict and the qemu / OpenSBI freeze with the 
"conflicting" firmware image flag removed. Whatever the problem is, the 
ArchLinux host was likely not the cause. The raw qemu at least shows an OpenSBI splash 
text before freezing. With libvirt the console connection is hopelessly frozen and 
nothing appears.



Andrej



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

Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)

[David Cantrell]

On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/libmemcached-awesome

== Summary ==
Switch from libmemcached to libmemcached-awesome

== Owner ==
* Name: [[User:Remi| Remi Collet]]
* Email: remi at fedoraproject dot org

== Detailed Description ==

libmemcache 1.0.18 was released in February 2014, so hasn't received
an update for 7 years.

libmemcache-awesome is a fork providing same libraries, tools with
API/ABI compatibility.

== Benefit to Fedora ==

Rely on a maintained project.



== Scope ==
* Proposal owners: Check Koschei status. Test with latest version to
ensure compatibility. Work with upstream on bug fixing. Needed mass
rebuild (C extensions) done by change owner.

* Other developers: N/A (not a System Wide Change)
* Release engineering:
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
N/A (not a System Wide Change)

== How To Test ==

* install and play with your application

== User Experience ==

Developers and system administrators will have the great benefit or
running a maintained library.


== Dependencies ==

All php-* packages (and some *-php)

== Contingency Plan ==
* Contingency mechanism: Drop not compatible packages.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==

* [https://awesomized.github.io/libmemcached/ Upstream documentation]



The change proposal indicates this is a drop-in API replacement
project, but will this introduce a new package named
'libmemcached-awesome' and we let libmemcached go out to pasture?  Or
is this changing the Source0 of the libmemcached package to just use
this new upstream?

If the former, will the new package provide proper Provides/Conflicts
against the existing libmemcached package or are there plans to allow
both to be installed at the same time?

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: Is there a command to expand Source0 from spec file to the final URL?

[Gwyn Ciesla via devel]

Does spectool -g foo.spec help? Or -f?

-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Tuesday, July 6th, 2021 at 11:15 AM, Richard W.M. Jones  
wrote:

> Is this possible? I've got one with lots of %{macros} in it.
> 

> It seems like this should be possible using rpmspec, but I can't work
> 

> out how.
> 

> Rich.
> 

> -
> 

> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> 

> Read my programming and virtualization blog: http://rwmj.wordpress.com
> 

> virt-p2v converts physical machines to virtual machines. Boot with a
> 

> live CD or over the network (PXE) and turn machines into KVM guests.
> 

> http://libguestfs.org/virt-v2v
> 

> 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

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

Re: Is there a command to expand Source0 from spec file to the final URL?

[Vascom]

You can use command
spectool -g name.spec
to download sources.

вт, 6 июл. 2021 г., 19:15 Richard W.M. Jones :

>
> Is this possible?  I've got one with lots of %{macros} in it.
>
> It seems like this should be possible using rpmspec, but I can't work
> out how.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is there a command to expand Source0 from spec file to the final URL?

[Björn 'besser82' Esser]

Am Dienstag, dem 06.07.2021 um 17:15 +0100 schrieb Richard W.M. Jones:
> 
> Is this possible?  I've got one with lots of %{macros} in it.
> 
> It seems like this should be possible using rpmspec, but I can't work
> out how.
> 
> Rich.


You can either use `spectool -l rpm.spec` to get the URL ('SourceX:[
\t]*' prepended) printed to stdout with the macros expanded, or if you
want to download the files to $PWD you can use `spectool -g rpm.spec`.

`spectool -h` will give you information about more usage options.

Cheers,
Björn


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: Is there a command to expand Source0 from spec file to the final URL?

[Fabio Valentini]

On Tue, Jul 6, 2021 at 6:15 PM Richard W.M. Jones  wrote:
>
>
> Is this possible?  I've got one with lots of %{macros} in it.
>
> It seems like this should be possible using rpmspec, but I can't work
> out how.

There's probably dozens of ways of doing this, but using spectool is very easy:
Running "spectool path-to.spec" - without the "-g" / "--get" flag -
will print all expanded Sources and Patches.
And "spectool path-to.spec -s 0" will only expand and print Source0.

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

Re: Is there a command to expand Source0 from spec file to the final URL?

[Lyes Saadi]

Hello,

It is possible, using spectool:

spectool -s 0 path/to/specfile.spec

Le 06/07/2021 à 17:15, Richard W.M. Jones a écrit :

Is this possible?  I've got one with lots of %{macros} in it.

It seems like this should be possible using rpmspec, but I can't work
out how.

Rich.


___
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

Is there a command to expand Source0 from spec file to the final URL?

[Richard W.M. Jones]

Is this possible?  I've got one with lots of %{macros} in it.

It seems like this should be possible using rpmspec, but I can't work
out how.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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 fmt library soversion bump

[Miro Hrončok]

On 06. 07. 21 17:13, Zbigniew Jędrzejewski-Szmek wrote:

This is Python 3.10 related.

https://docs.python.org/3.10/whatsnew/3.10.html#removed

"Remove deprecated aliases to Collections Abstract Base Classes from the
collections module."

E.g. use collections.abc.Sequence instead of collections.Sequence.
collections.Sequence was deprecated from Python 3.7.


Well the fix looks simple enough but it's the bundled spidermonkey that
needs to be patched and it's gziped inside of the 0ad archive with a
separate patching mechanism. BLEH.

I started looking into this yesterday… The attached patch moves past
the import errors, and cuts the warning noise to a manageable level.
Maybe it'll be useful as a start for someone. The build still fails with:
AttributeError: module 'sysconfig' has no attribute '_get_default_scheme'. Did 
you mean: 'get_default_scheme'?


That is still Python 3.10 relevant. The "private" sysconfig._get_default_scheme 
function has been made public (and hence has a new name, without the leading 
underscore). Since it was private, this is not considered as a breaking change. 
No code outside of Python standard library should have used it 路


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

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

[tdawson]

Dear all,

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

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

A general agenda is the following:

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




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

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

Re: How to (better) deal with library major API changes

[Richard Shaw]

Never mind, not sure if it was the best way but I did:

$ fedpkg clone openexr openexr2

And then edited .git/config and updated the references and then:

$ fedpkg push

And it's all there. Just had to cope over my spec file modifications.

Thanks,
Richard
___
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 (better) deal with library major API changes

[Richard Shaw]

On Sun, Jul 4, 2021 at 2:05 PM Miro Hrončok  wrote:

>
> Technically, you only need --exception, but I also like to use
> --no-initial-commit, so the package can be imported with git history of
> openexr.
>

Ok, I did that, now how do I import the current openexr repo?

Thanks,
Richard
___
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-20210706.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

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

Failed openQA tests: 4/199 (x86_64), 12/138 (aarch64)

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

ID: 921799  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/921799
ID: 921837  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/921837
ID: 921850  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/921850
ID: 921884  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/921884
ID: 921885  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/921885
ID: 921891  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/921891
ID: 922010  Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/922010
ID: 922028  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/922028
ID: 922038  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/922038
ID: 922046  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/922046

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

ID: 921753  Test: x86_64 Server-dvd-iso install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/921753
ID: 921810  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/921810
ID: 921811  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/921811
ID: 921867  Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/921867
ID: 921903  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/921903
ID: 922004  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/922004

Soft failed openQA tests: 4/199 (x86_64), 3/138 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 921834  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/921834
ID: 921923  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/921923
ID: 922000  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/922000
ID: 922002  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/922002

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

ID: 921894  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/921894
ID: 921962  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/921962
ID: 922022  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/922022

Passed openQA tests: 191/199 (x86_64), 101/138 (aarch64)

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

ID: 921784  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/921784
ID: 921817  Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/921817
ID: 921818  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/921818
ID: 921819  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/921819
ID: 921820  Test: x86_64 Silverblue-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/921820
ID: 921821  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/921821
ID: 921822  Test: x86_64 Silverblue-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/921822
ID: 921823  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/921823
ID: 921824  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/921824
ID: 921825  Test: x86_64 Silverblue-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/921825
ID: 921826  Test: x86_64 Silverblue-dvd_ostree-iso desktop_terminal
URL: 

Re: Starting a riscv64 VM from an ArchLinux x86_64 host

[Richard W.M. Jones]

On Tue, Jul 06, 2021 at 03:15:00AM +0200, Andrej Podzimek via devel wrote:
> Hi Fedora developers!
> 
> I'm trying to start a Fedora riscv64 VM on an ArchLinux x86_64 host based on 
> this wiki page: 
> https://fedoraproject.org/wiki/Architectures/RISC-V/Installing I have a 
> reasonably recent qemu and virt-manager:

I'm not sure, but you might want to chat with david in #fedora-riscv
on Libera.

Also it may work better using libvirt to manage the guest.

Rich.

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

Re: Announcing fmt library soversion bump

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 06, 2021 at 10:03:09AM -0500, Richard Shaw wrote:
> On Mon, Jul 5, 2021 at 4:50 PM Miro Hrončok  wrote:
> 
> > On 05. 07. 21 15:14, Richard Shaw wrote:
> > > 0ad failed:
> > >
> > > Traceback (most recent call last):
> > >File
> > >
> > "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/../js/src/../../configure.py",
> >
> > > line 25, in 
> > >  from mozbuild.configure import (
> > >File
> > >
> > "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/configure/__init__.py",
> >
> > > line 33, in 
> > >  from mozbuild.util import (
> > >File
> > >
> > "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/util.py",
> >
> > > line 760, in 
> > >  class HierarchicalStringList(object):
> > >File
> > >
> > "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/util.py",
> >
> > > line 785, in HierarchicalStringList
> > >  class StringListAdaptor(collections.Sequence):
> > > AttributeError: module 'collections' has no attribute 'Sequence'
> > > ERROR: SpiderMonkey build failed
> > >
> > > https://kojipkgs.fedoraproject.org//work/tasks/4873/71344873/build.log
> > > 
> > >
> > > Doesn't look fmt related.
> >
> > This is Python 3.10 related.
> >
> > https://docs.python.org/3.10/whatsnew/3.10.html#removed
> >
> > "Remove deprecated aliases to Collections Abstract Base Classes from the
> > collections module."
> >
> > E.g. use collections.abc.Sequence instead of collections.Sequence.
> > collections.Sequence was deprecated from Python 3.7.
> >
> 
> Well the fix looks simple enough but it's the bundled spidermonkey that
> needs to be patched and it's gziped inside of the 0ad archive with a
> separate patching mechanism. BLEH.

I started looking into this yesterday… The attached patch moves past
the import errors, and cuts the warning noise to a manageable level.
Maybe it'll be useful as a start for someone. The build still fails with:
AttributeError: module 'sysconfig' has no attribute '_get_default_scheme'. Did 
you mean: 'get_default_scheme'?

Zbyszek
diff --git 0ad-python310.patch 0ad-python310.patch
index ea3fa36c5f..978ac2d17c 100644
--- 0ad-python310.patch
+++ 0ad-python310.patch
@@ -1,10 +1,11 @@
 --- libraries/source/spidermonkey/build.sh~	2021-02-06 01:28:31.0 +0100
 +++ libraries/source/spidermonkey/build.sh	2021-07-05 19:28:48.642045840 +0200
-@@ -100,6 +100,8 @@
+@@ -100,6 +100,9 @@
fi
tar xjf "${FOLDER}.tar.bz2"
  
 +  sed -r -i 's/collections.Sequence/collections.abc.Sequence/' ${FOLDER}/python/mozbuild/mozbuild/util.py
++  sed -r -i 's/from collections import Iterable, OrderedDict/from collections.abc import Iterable\nfrom collections import OrderedDict/' ${FOLDER}/python/mozbuild/mozbuild/backend/configenvironment.py
 +
# Clean up header files that may be left over by earlier versions of SpiderMonkey
rm -rf include-unix-debug
diff --git 0ad.spec 0ad.spec
index 6cdf30d25e..319f272494 100644
--- 0ad.spec
+++ 0ad.spec
@@ -140,6 +140,8 @@ Patch2:		%{name}-valgrind.patch
 Patch3:		%{name}-ppc64.patch
 Patch5:		%{name}-rust.patch
 
+Patch6: %{name}-python310.patch
+
 %description
 0 A.D. (pronounced "zero ey-dee") is a free, open-source, cross-platform
 real-time strategy (RTS) game of ancient warfare. In short, it is a
@@ -165,6 +167,7 @@ hobbyist game developers, since 2001.
 %if %{without system_mozjs78}
 %patch5 -p0
 %endif
+%patch6 -p0
 
 %if %{with system_nvtt}
 rm -fr libraries/source/nvtt
@@ -179,6 +182,8 @@ rm -fr libraries/source/valgrind
 %define _lto_cflags %{nil}
 
 %set_build_flags
+CXXFLAGS="$CXXFLAGS -Wno-class-memaccess -Wno-deprecated-copy -Wno-maybe-unitialized -Wno-unused-but-set-variable -Wno-implicit-fallthrough"
+
 build/workspaces/update-workspaces.sh	\
 --bindir=%{_bindir}			\
 --datadir=%{_datadir}/%{name}	\
___
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 fmt library soversion bump

[Richard Shaw]

On Mon, Jul 5, 2021 at 4:50 PM Miro Hrončok  wrote:

> On 05. 07. 21 15:14, Richard Shaw wrote:
> > 0ad failed:
> >
> > Traceback (most recent call last):
> >File
> >
> "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/../js/src/../../configure.py",
>
> > line 25, in 
> >  from mozbuild.configure import (
> >File
> >
> "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/configure/__init__.py",
>
> > line 33, in 
> >  from mozbuild.util import (
> >File
> >
> "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/util.py",
>
> > line 760, in 
> >  class HierarchicalStringList(object):
> >File
> >
> "/builddir/build/BUILD/0ad-0.0.24b-alpha/libraries/source/spidermonkey/mozjs-78.6.0/python/mozbuild/mozbuild/util.py",
>
> > line 785, in HierarchicalStringList
> >  class StringListAdaptor(collections.Sequence):
> > AttributeError: module 'collections' has no attribute 'Sequence'
> > ERROR: SpiderMonkey build failed
> >
> > https://kojipkgs.fedoraproject.org//work/tasks/4873/71344873/build.log
> > 
> >
> > Doesn't look fmt related.
>
> This is Python 3.10 related.
>
> https://docs.python.org/3.10/whatsnew/3.10.html#removed
>
> "Remove deprecated aliases to Collections Abstract Base Classes from the
> collections module."
>
> E.g. use collections.abc.Sequence instead of collections.Sequence.
> collections.Sequence was deprecated from Python 3.7.
>

Well the fix looks simple enough but it's the bundled spidermonkey that
needs to be patched and it's gziped inside of the 0ad archive with a
separate patching mechanism. BLEH.

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

Fedora-IoT-35-20210706.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old failures (same test failed in Fedora-IoT-35-20210705.0):

ID: 922083  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/922083
ID: 922085  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/922085
ID: 922086  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/922086
ID: 922089  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/922089
ID: 922094  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/922094
ID: 922097  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/922097
ID: 922099  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/922099
ID: 922100  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/922100

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210705.0):

ID: 922070  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/922070
ID: 922071  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/922071
ID: 922072  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/922072
ID: 922087  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/922087

Passed openQA tests: 11/16 (x86_64), 8/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.32 to 0.46
Previous test data: https://openqa.fedoraproject.org/tests/921549#downloads
Current test data: https://openqa.fedoraproject.org/tests/922072#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 4.14 to 4.01
Previous test data: https://openqa.fedoraproject.org/tests/921564#downloads
Current test data: https://openqa.fedoraproject.org/tests/922087#downloads
-- 
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 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[François Cami]

Hi Paul, all,

On Tue, Jun 29, 2021 at 1:40 AM Paul Wouters  wrote:
>
> On Mon, 28 Jun 2021, Ben Cotton wrote:
>
> > https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec
>
> > == Detailed Description ==
> >
> > OpenDNSSec changed the default behavior to not include SHA1 DS by
> > default, and added the -sha1 knob as an immediately-deprecated
> > compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
> > default ‘ods-enforcer key export –ds’ included the SHA1 version of the
> > DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
> > use the –sha1 flag. This flag is immediately deprecated and will be
> > removed from future versions of OpenDNSSEC." (see ChangeLog:
> > https://www.opendnssec.org/archive/releases/ ).
> >
> > The proposal is to disable the -sha1 knob in Fedora. I will also open
> > an issue upstream to remove all the sha1-related code.
>
> This change makes me a bit nervous, and I'm the author of RFC 8624 that
> recommennds not using SHA-1 for DS/CDS records anymore.
>
> https://datatracker.ietf.org/doc/html/rfc8624#section-3.3
>
> > Supporting statement
> > [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
> > [from ICANN] (2020-1-24): "Now is the time for administrators of zones
> > at all levels of the DNS to stop using SHA-1 and change to algorithms
> > using stronger hashes."
>
> While this is true, the order of where things need to change are:
>
> 1 Discourage, but not block, the use of SHA-1. Eg remove it from the default 
> set.
> 2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
> 3 remove support for SHA-1
>
> This plan assumes we are in phase3. I would say we are in phase2.
>
> Remember, any domain that depends on SHA-1 is going to be more secure
> than being marked as insecure because SHA-1 is rejected. This is somewhat
> different from like SHA-1 support for authentication where the rejection
> of a weaker algorithm forces the use of a stronger algorithm.
>
> The DNSSEC fallback when an algorithm is not supported is to go insecure,
> not insist on a more secure SHA-2 that is not there. With DNSSEC,
> there is not client-server exchange like with TLS or IPsec. There is
> a producer on one end, and a consumer on the other end. The two do not
> negotiate crypto parameters.
>
> > == Benefit to Fedora ==
> > * This change makes sure OpenDNSSec in Fedora follows ICANN's
> > guidelines and does not propose SHA1 DS. This is is needed given the
> > [https://sha-mbles.github.io/ latest attacks against SHA-1]. More
> > in-depth articles are available
> > [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
> > [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/
>
> I know that a few people believe that shambles can in theory be abused
> with DNSSEC, but a lot of people also believe the constrains of DNS
> RRsets make this impossible. But even _if_ it is possible, it would
> only affect multiple domains that share the same private key that made
> the SHA-1 signature. And then we are talking about RRSIG records and
> not, as in this proposal, the DS/CDS RDATA content.
>
> > Patch the enforcer so that bsha1 is not honored anymore:
>
> I don't think fedora should move faster than upstream opendnssec. I
> believe the people at the IETF and the software developers of the DNS
> software are more aware of where we are in the migration path than
> individual Fedora developers.

Thanks a lot for your input. I am withdrawing the change proposal now
as it makes no sense indeed to have Fedora move faster than upstream
on this.

Regards,
François



> > == Upgrade/compatibility impact ==
> > Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the 
> > zone.
>
> The RRSIG signature is not related to the DS signature. Zone resigning
> is something completely different from the DS/CDS records. Those records
> are signed by the parent zone, and use whatever algorithm the parent
> zone uses, which the child zone cannot dictate.
>
> > This change might break (very old) clients that only recognize SHA-1
> > but these should already be broken (on the Internet at least) because
> > the root zone is signed with SHA-256 only.
>
> The root zone has no DS record, so this statement does not make sense.
> The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
> that contains a hash of the child's public key, where the hash is created
> with SHA-1 or SHA-2.
>
> > == User Experience ==
> >
> > OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
> > With this change, this will no longer be possible. The migration from
> > SHA1 is underway anyway.
>
> So there are two things that really need to be clarified for this
> proposal. Is it talking about DS/CDS signature algorithm as per IANA
> registry http://www.iana.org/assignments/ds-rr-types, or are we talking
> about DNSKEY signature algorithm, that is responsble for signing all

Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)

[François Cami]

Hi Paul, all,

On Tue, Jun 29, 2021 at 1:40 AM Paul Wouters  wrote:
>
> On Mon, 28 Jun 2021, Ben Cotton wrote:
>
> > https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec
>
> > == Detailed Description ==
> >
> > OpenDNSSec changed the default behavior to not include SHA1 DS by
> > default, and added the -sha1 knob as an immediately-deprecated
> > compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By
> > default ‘ods-enforcer key export –ds’ included the SHA1 version of the
> > DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS
> > use the –sha1 flag. This flag is immediately deprecated and will be
> > removed from future versions of OpenDNSSEC." (see ChangeLog:
> > https://www.opendnssec.org/archive/releases/ ).
> >
> > The proposal is to disable the -sha1 knob in Fedora. I will also open
> > an issue upstream to remove all the sha1-related code.
>
> This change makes me a bit nervous, and I'm the author of RFC 8624 that
> recommennds not using SHA-1 for DS/CDS records anymore.
>
> https://datatracker.ietf.org/doc/html/rfc8624#section-3.3
>
> > Supporting statement
> > [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en
> > [from ICANN] (2020-1-24): "Now is the time for administrators of zones
> > at all levels of the DNS to stop using SHA-1 and change to algorithms
> > using stronger hashes."
>
> While this is true, the order of where things need to change are:
>
> 1 Discourage, but not block, the use of SHA-1. Eg remove it from the default 
> set.
> 2 Ensure the migration of SHA-1 based records to SHA-256 is taking place
> 3 remove support for SHA-1
>
> This plan assumes we are in phase3. I would say we are in phase2.
>
> Remember, any domain that depends on SHA-1 is going to be more secure
> than being marked as insecure because SHA-1 is rejected. This is somewhat
> different from like SHA-1 support for authentication where the rejection
> of a weaker algorithm forces the use of a stronger algorithm.
>
> The DNSSEC fallback when an algorithm is not supported is to go insecure,
> not insist on a more secure SHA-2 that is not there. With DNSSEC,
> there is not client-server exchange like with TLS or IPsec. There is
> a producer on one end, and a consumer on the other end. The two do not
> negotiate crypto parameters.
>
> > == Benefit to Fedora ==
> > * This change makes sure OpenDNSSec in Fedora follows ICANN's
> > guidelines and does not propose SHA1 DS. This is is needed given the
> > [https://sha-mbles.github.io/ latest attacks against SHA-1]. More
> > in-depth articles are available
> > [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and
> > [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/
>
> I know that a few people believe that shambles can in theory be abused
> with DNSSEC, but a lot of people also believe the constrains of DNS
> RRsets make this impossible. But even _if_ it is possible, it would
> only affect multiple domains that share the same private key that made
> the SHA-1 signature. And then we are talking about RRSIG records and
> not, as in this proposal, the DS/CDS RDATA content.
>
> > Patch the enforcer so that bsha1 is not honored anymore:
>
> I don't think fedora should move faster than upstream opendnssec. I
> believe the people at the IETF and the software developers of the DNS
> software are more aware of where we are in the migration path than
> individual Fedora developers.

Thanks a lot for your input. I am withdrawing the change proposal now
as it makes no sense indeed to have Fedora move faster than upstream
on this.

Regards,
François



> > == Upgrade/compatibility impact ==
> > Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the 
> > zone.
>
> The RRSIG signature is not related to the DS signature. Zone resigning
> is something completely different from the DS/CDS records. Those records
> are signed by the parent zone, and use whatever algorithm the parent
> zone uses, which the child zone cannot dictate.
>
> > This change might break (very old) clients that only recognize SHA-1
> > but these should already be broken (on the Internet at least) because
> > the root zone is signed with SHA-256 only.
>
> The root zone has no DS record, so this statement does not make sense.
> The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata
> that contains a hash of the child's public key, where the hash is created
> with SHA-1 or SHA-2.
>
> > == User Experience ==
> >
> > OpenDNSSec in Fedora can currently be used to sign zones with SHA1.
> > With this change, this will no longer be possible. The migration from
> > SHA1 is underway anyway.
>
> So there are two things that really need to be clarified for this
> proposal. Is it talking about DS/CDS signature algorithm as per IANA
> registry http://www.iana.org/assignments/ds-rr-types, or are we talking
> about DNSKEY signature algorithm, that is responsble for signing all

[EPEL-devel] Re: libaom update issue

[Troy Dawson]

Looks like the seamonkey you want is still in epel7-testing.
There was an aom update, and it made it through testing, so it's currently
in epel7.
There was also a seamonkey update, to pull in the updated aom.  But it's
still in epel7-testing.

For now, the easiest thing to do is enable epel-testing

yum --enablerepo=epel-testing update seamonkey libaom

Troy

On Tue, Jul 6, 2021 at 7:03 AM Chris Schanzle 
wrote:

> Hi,
>
> I'm getting a yum update failure with seamonkey 2.53.7-4 which requires
> libaom (src rpm=aom), which doesn't have a clean update path:
>
> # yum update seamonkey libaom
> Loaded plugins: aliases, changelog, kabi, langpacks,
> post-transaction-actions, priorities, protectbase, ps, remove-with-leaves,
>: tmprepo, verify, versionlock
> Loading support for Red Hat kernel ABI
> 0 packages excluded due to repository protections
> Resolving Dependencies
> --> Running transaction check
> ---> Package libaom.x86_64 0:1.0.0-8.20190810git9666276.el7 will be updated
> --> Processing Dependency: libaom.so.0()(64bit) for package:
> seamonkey-2.53.7-4.el7.x86_64
> ---> Package libaom.x86_64 0:3.1.1-1.el7 will be an update
> --> Finished Dependency Resolution
> Error: Package: seamonkey-2.53.7-4.el7.x86_64 (@epel)
> Requires: libaom.so.0()(64bit)
> Removing: libaom-1.0.0-8.20190810git9666276.el7.x86_64 (@epel)
> libaom.so.0()(64bit)
> Updated By: libaom-3.1.1-1.el7.x86_64 (epel)
>~libaom.so.3()(64bit)
>   You could try using --skip-broken to work around the problem
>   You could try running: rpm -Va --nofiles --nodigest
>
>
> Any thoughts why this happened?  It's unclear to me exactly what the issue
> is (note the .so bump from .0 to .3).  No doubt I could likely remove both
> and install again, but just thought I'd inquire before changing anything.
> I only have a few systems this issue, so not a big deal.
>
> Thanks!
>
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] [Test Week] Fedora Linux Kernel 5.13 2021-07-11 through 2021-07-18

[Sumantro Mukherjee]

Hey All,

I would like to invite all of you to participate in the Kernel 5.13
Test week, which is happening from 2021-07-11 to 2021-07-18. It's
fairly simple, head over to the wiki [0] and read in detail about the
test week and simply run the test case mentioned in[1] and enter your
results.

As usual, the Fedora QA team will hang out at #fedora-test-...@libera.chat
for question and discussion.


[0] https://fedoraproject.org/wiki/Test_Day:2021-07-11_Kernel_5.13_Test_Week
[1] https://testdays.fedoraproject.org/events/115


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

[Fedocal] Reminder meeting : Fedora Source-git SIG

[csomh]

Dear all,

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

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

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

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


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

___
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 1978704] perl-Math-BigInt-1.999820 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Math-BigInt-1.999819   |perl-Math-BigInt-1.999820
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.999820
Current version/release in rawhide: 1.9998.18-477.fc35
URL: http://search.cpan.org/dist/Math-BigInt/

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


-- 
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: F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

[Florian Weimer]

* Carlos O'Donell:

> On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton  wrote:
>>
>> On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton  wrote:
>> >
>> > == Contingency Plan ==
>> > * Contingency mechanism: If glibc 2.34 provides too disruptive to
>> > compiling the distribution we could revert to 2.33, but given that
>> > Rawhide has started tracking glibc 2.34, no show-stopper problems are
>> > expected.  At this point, we can still revert to upstream version 2.33
>> > if insurmountable problems appear, but to do so may require a mass
>> > rebuild to remove new symbols from the ABI/API.
>> > * Contingency deadline: Upstream glibc ABI freeze deadline of 2021-07-01.
>> >
>> I notice that the listed contingency deadline is two days from now, so
>> it will have passed before this even makes it to FESCo for vote. Is
>> that date correct?
>
> The date is flexible. But undoing the ABI changes requires a mass rebuild.

And due to the extensive nature of the ABI changes, we would need around
ten business days to create a dual-ABI glibc that supports the new
(2.34) ABI, but linking against it results in the old (2.33) ABI.

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

Re: F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

[Carlos O'Donell]

On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton  wrote:
>
> On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton  wrote:
> >
> > == Contingency Plan ==
> > * Contingency mechanism: If glibc 2.34 provides too disruptive to
> > compiling the distribution we could revert to 2.33, but given that
> > Rawhide has started tracking glibc 2.34, no show-stopper problems are
> > expected.  At this point, we can still revert to upstream version 2.33
> > if insurmountable problems appear, but to do so may require a mass
> > rebuild to remove new symbols from the ABI/API.
> > * Contingency deadline: Upstream glibc ABI freeze deadline of 2021-07-01.
> >
> I notice that the listed contingency deadline is two days from now, so
> it will have passed before this even makes it to FESCo for vote. Is
> that date correct?

The date is flexible. But undoing the ABI changes requires a mass rebuild.

Cheers,
Carlos.
___
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: 20210706.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210705.n.0
NEW: Fedora-Rawhide-20210706.n.0

= SUMMARY =
Added images:2
Dropped images:  8
Added packages:  0
Dropped packages:0
Upgraded packages:   57
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   5.79 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -13.35 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: SoaS raw-xz armhfp
Path: Spins/armhfp/images/Fedora-SoaS-Rawhide-20210706.n.0.armhfp.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20210706.n.0.armhfp.raw.xz

= DROPPED IMAGES =
Image: Python_Classroom raw-xz armhfp
Path: 
Labs/armhfp/images/Fedora-Python-Classroom-Rawhide-20210705.n.0.armhfp.raw.xz
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210705.n.0.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210705.n.0.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210705.n.0.ppc64le.qcow2
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210705.n.0.x86_64.vagrant-virtualbox.box
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20210705.n.0.armhfp.raw.xz
Image: Cloud_Base vagrant-libvirt x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20210705.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20210705.n.0.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  annobin-9.80-1.fc35
Old package:  annobin-9.79-1.fc35
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-plugin-clang 
annobin-plugin-gcc annobin-plugin-llvm
Size: 1.25 MiB
Size change:  4.67 KiB
Changelog:
  * Mon Jul 05 2021 Nick Clifton   - 9.80-1
  - Tests: Skip glibc-notes test if the assembler does not support 
--generate-missing-build-notes.  (#1978573)
  - Tests: Skip objcopy test if objcopy does not support --merge-notes.


Package:  arc-theme-20210412-2.fc35
Old package:  arc-theme-20210412-1.fc35
Summary:  Flat theme with transparent elements
RPMs: arc-theme arc-theme-plank
Size: 627.82 KiB
Size change:  70 B
Changelog:
  * Mon Jul 05 2021 Mukundan Ragavan  - 20210412-2
  - Add requires on gnome-themes-extra


Package:  backintime-1.3.1-2.fc35
Old package:  backintime-1.2.1-7.fc35
Summary:  Simple backup tool inspired from the Flyback project and TimeVault
RPMs: backintime-common backintime-plugins backintime-qt
Size: 438.06 KiB
Size change:  4.75 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
1.2.0-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Tue Aug 20 2019 Johannes Lips  - 1.2.0-6
  - added upstream patch to fix #1709064

  * Thu Sep 05 2019 Johannes Lips  - 1.2.1-1
  - update to 1.2.1
  - clean up of post, postun and posttrans sections

  * Tue Jan 28 2020 Fedora Release Engineering  - 
1.2.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild

  * Mon Jul 27 2020 Fedora Release Engineering  - 
1.2.1-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Tue Jul 28 2020 Adam Jackson  - 1.2.1-4
  - Require xdpyinfo not xorg-x11-utils

  * Tue Jan 26 2021 Fedora Release Engineering  - 
1.2.1-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild

  * Sun May 30 2021 Johannes Lips  - 1.2.1-6
  - fix for crash

  * Sun May 30 2021 Johannes Lips  - 1.2.1-7
  - fix non-updating progress bar

  * Sun Jul 04 2021 Johannes Lips  - 1.3.0-1
  - update to latest upstream release

  * Mon Jul 05 2021 Johannes Lips  - 1.3.1-1
  - update to latest upstream release

  * Mon Jul 05 2021 Johannes Lips  - 1.3.1-2
  - added patch to fix tests with python 3.10


Package:  clamtk-6.12-1.fc35
Old package:  clamtk-6.11-2.fc35
Summary:  Easy to use graphical user interface for Clam anti virus
RPMs: clamtk
Size: 199.18 KiB
Size change:  163 B
Changelog:
  * Mon Jul 05 2021 Dave M.  - 6.12-1
  - Updated to release 6.12.


Package:  cmake-3.21.0-3.rc2.fc35
Old package:  cmake-3.21.0-2.rc1.fc35
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 54.87 MiB
Size change:  6.94 KiB
Changelog:
  * Mon Jul 05 2021 Bj??rn Esser  - 3.21.0-3.rc2
  - cmake-3.21.0-rc2
  - Drop libdl patch for glibc >= 2.34, as it is upstreamed


Package:  devscripts-2.21.3-1.fc35
Old package:  devscripts-2.21.2-3.fc35
Summary:  Scripts for Debian Package maintainers
RPMs: devscripts devscripts-checkbashisms
Size: 3.01 MiB
Size cha

[389-devel] UNSUBSCRIBE/DELETE

[Jesse Nicoll]

UNSUBSCRIBE/DELETE
I did not create this account or sign up for your newsletter.
Please delete my account and remove me from future emails



From: vashi...@redhat.com 
Sent: Tuesday, July 6, 2021 1:56 AM
To: 389-devel@lists.fedoraproject.org <389-devel@lists.fedoraproject.org>
Subject: [389-devel] 389 DS nightly 2021-07-06 - 95% PASS

This message has originated from an[External Source]


https://urldefense.com/v3/__https://fedorapeople.org/groups/389ds/ci/nightly/2021/07/06/report-389-ds-base-2.0.6-20210706gitfb70c5c83.fc34.x86_64.html__;!!MEQIFvZ9d4ErIg!Tu_deMzUGAEDT_bU-E9rojSGZMk4Q6mL4-bK713c7bYBsqgI2yvYU8SUu6hf-WDYZAkn8EI$
___
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://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!MEQIFvZ9d4ErIg!Tu_deMzUGAEDT_bU-E9rojSGZMk4Q6mL4-bK713c7bYBsqgI2yvYU8SUu6hf-WDYvy-ZGnM$
List Guidelines: 
https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_guidelines__;!!MEQIFvZ9d4ErIg!Tu_deMzUGAEDT_bU-E9rojSGZMk4Q6mL4-bK713c7bYBsqgI2yvYU8SUu6hf-WDYRAzK-YU$
List Archives: 
https://urldefense.com/v3/__https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org__;!!MEQIFvZ9d4ErIg!Tu_deMzUGAEDT_bU-E9rojSGZMk4Q6mL4-bK713c7bYBsqgI2yvYU8SUu6hf-WDYoF854sU$
Do not reply to spam on the list, report it: 
https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure__;!!MEQIFvZ9d4ErIg!Tu_deMzUGAEDT_bU-E9rojSGZMk4Q6mL4-bK713c7bYBsqgI2yvYU8SUu6hf-WDYbg55wOc$
___
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

MUMPS-5.4.0 in Rawhide

[Antonio T. sagitter]

Hi all.

In a week i will compile MUMPS-5.4.0 in Rawhide; this implicates the 
rebuilds of dependent packages:


$ repoquery --whatrequires MUMPS-openmpi-devel --disablerepo=* 
--enablerepo=*-source


Last metadata expiration check: 0:00:14 ago on Tue 06 Jul 2021 11:32:14 
AM CEST.


amg4psblas-0:1.0.0-2.fc34.src

coin-or-Ipopt-0:3.13.0-11.fc34.src

freefem++-0:4.7-3.fc34.src

mld2p4-0:2.2.2-8.fc34.src

petsc-0:3.14.4-1.fc34.src


Except 'freefem++', they are all packages that i maintain; if the 
maintainer of freefem++ is agree, i will rebuild it independently in the 
MUMPS side-tag.


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

Fedora-Cloud-34-20210706.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210705.0):

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

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

Re: How to (better) deal with library major API changes

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 04, 2021 at 09:04:55PM +0200, Miro Hrončok wrote:
> On 04. 07. 21 16:49, Richard Shaw wrote:
> >On Thu, Jul 1, 2021 at 12:25 PM Miro Hrončok  >> wrote:
> >
> >On 01. 07. 21 18:20, Richard Shaw wrote:
> > > On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok  >
> > > >> wrote:
> > >
> > >     On 01. 07. 21 17:53, Richard Shaw wrote:
> > >      > 1. Create a compat or SOVERSION appended package (requires new
> >review)
> > >
> > >     Packages created so that multiple versions of the same package can
> >coexist in
> > >     the distribution does not require a new review:
> > >
> > >
> >
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> >
> > 
> > > 
> >  >  
> > >
> > >
> > >
> > > Ok, so does require a ticket though.
> >
> >No, it does not. To be exempted from the package review you can create a
> >ticket
> >OR you can create a "multiple versions of the same package" package.
> >
> >
> >Ok, I re-read things a few times and now I get that part, but
> >without a review, how do I get the repo setup?
> >
> >I have prepared an "openexr2" package. I chose just to include the
> >2 because it's possible upstream may release a new 2.x version so
> >"openexr2.5.5" doesn't make any sense.
> 
> 
> $ fedpkg request-repo openexr2 --exception --no-initial-commit
> 
> 
> Technically, you only need --exception, but I also like to use
> --no-initial-commit, so the package can be imported with git history
> of openexr.

This is "documented" in
https://fedoraproject.org/wiki/Package_Review_Process#Review_Purpose.
I put documented in quotes because the text is present, but it sure ain't
easy to find. All the wiki docs about initial package are fairly hard to
use: the information is split over multiple pages without a clear design
to the division, there should be lot more hyperlinking going on, etc.

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

Retiring python-descartes

[Elliott Sales de Andrade]

Hi,

I am retiring python-descartes in Rawhide. Upstream died when
Bitbucket dropped Mercurial support, and has no intention of reviving
it.

Downstream users have stopped using it, and I have removed the
unnecessary dependency from Fedora packages, or patched it out after
reporting upstream.

It is currently FTBFS with Python 3.10, and thus not installable after
the rebuild.

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

Orphaning python-pytest-helpers-namespace

[Elliott Sales de Andrade]

I am orphaning python-pytest-helpers-namespace, which is no longer a
dependency of my packages.

It currently has one bug report [1] for updating to the latest
version, which has grown a new dependency
(setuptools-declarative-requirements) that I do not wish to also
package.

AFAIK, nothing else depends on it in Fedora. Though it is owned by the
saltstack organization on GitHub, it is apparently not used for any of
Salt as packaged in Fedora.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1942610
-- 
Elliott
___
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

Orphaning python-pytest-helpers-namespace

[Elliott Sales de Andrade]

I am orphaning python-pytest-helpers-namespace, which is no longer a
dependency of my packages.

It currently has one bug report [1] for updating to the latest
version, which has grown a new dependency
(setuptools-declarative-requirements) that I do not wish to also
package.

AFAIK, nothing else depends on it in Fedora. Though it is owned by the
saltstack organization on GitHub, it is apparently not used for any of
Salt as packaged in Fedora.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1942610
-- 
Elliott
___
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-33-20210706.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

dropping pt-sans-fonts (ParaType Cyrillic) from the default @fonts group?

[Jens-Ulrik Petersen]

Oops sorry resending to the correct devel list:

-- Forwarded message -
From: Jens-Ulrik Petersen 
Date: Mon, Jun 28, 2021 at 1:38 PM
Subject: dropping pt-sans-fonts (ParaType Cyrillic) from the default @fonts
group?
Cc: fonts , trans <
tr...@lists.fedoraproject.org>

Hi

Currently the pt-sans-fonts package is installed by default as part of the
@fonts yum group.

However as far as I can tell, e.g. looking at
https://tagoh.fedorapeople.org/fonts/status/34.html the font is not used by
default for any of our locales.

Therefore unless there is a strong reason to keep it pre-installed I would
like to propose dropping pt-sans-fonts from @fonts in F35. Obviously we
still have Cyrillic coverage provided by deja-sans-fonts. Any feedback on
this? Note also that langpacks-ru pulls in pt-sans-fonts.

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