Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Vitaly Zaitsev via devel]

On 15/11/2022 23:25, Gordon Messmer wrote:
I had thought that the Fedora 37 mesa packages retained accelerated 
video for open codecs (for AMD hardware)


To accelerate H.264/H.265, you need to replace the stripped Fedora 
versions with the full versions from the RPM Fusion repository:


sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld --allowerasing


However, the Fedora wiki[1] indicates that even open codecs are no longer 
accelerated without third party packages.  Is that true?


On Intel, you need to install the libva-intel-driver (i915) and 
intel-media-driver (iHD) packages.


On NVIDIA, you're forced to use proprietary drivers as hardware 
acceleration on nouveau only works on very old GPUs.


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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 16 November 2022 at 09:22, Vitaly Zaitsev via devel wrote:
> On 15/11/2022 23:25, Gordon Messmer wrote:
> > I had thought that the Fedora 37 mesa packages retained accelerated
> > video for open codecs (for AMD hardware)
> 
> To accelerate H.264/H.265, you need to replace the stripped Fedora
> versions with the full versions from the RPM Fusion repository:
> 
> sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing
> sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld --allowerasing
> 
> > However, the Fedora wiki[1] indicates that even open codecs are no
> > longer accelerated without third party packages.  Is that true?
> 
> On Intel, you need to install the libva-intel-driver (i915) and
> intel-media-driver (iHD) packages.

Actually, it's either one or the other as they don't support the same
CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for
older ones (Ice Lake is the first one it doesn't support). See
https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-API_Video_decoding_on_Intel
https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers

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

Heads up: pytest 7.2 update for rawhide

[Lumír Balhar]

Hi.

I'm working on an update of pytest to 7.2.0 for rawhide. This version 
contains some breaking changes.


 * pytest no longer depends on py - it bundles a small subset of py's
   functionalities instead. py is kinda deprecated so if a project
   depends on it it'd be better to drop that dependency. If this is not
   possible, add explicit BuildRequire: python3-py to the specfile.
 * pytest no longer depends on setuptools. If your package needs
   setuptools to build, make sure that setuptools is explicitly
   mentioned in the list of build dependencies.
 * pytest newly raises some new warnings related to the support of nose
   tests. This may also cause your builds to fail. It's easy to fix and
   the warnings tell you how to do it.

All affected packages already have a bugzilla a PR or both filled from 
me. I'll do my best to help their maintainers as much as I can. My plan 
is to ship the update during the last November week.


Have a nice day.

Lumír
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Bad paths in *.pc (pkgconf) files

[Richard W.M. Jones]

David (CC'd) is working on the Fedora RISC-V port and he noticed that
some *.pc files in Fedora contain incorrect paths.  For example[1]:

  $ pkgconf --libs libcares
  -L/usr/usr/lib64 -lcares

  $ pkgconf --libs libasyncns
  -L/usr/lib -lasyncns 

On non-riscv64 this happens to work because the default search path
includes the right directory anyway (eg. /usr/lib64).

On riscv64 this causes build failures since meson seems to go off and
search for the *.so files and then tries to construct an absolute path
to them (I'm not sure if this isn't a bug in meson TBH).  For example:

  http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782

This problem appears to be widespread.  I scanned just the *-devel
packages that I happen to have installed, results below.  Not sure how
to scan all *-devel packages in Fedora.

What should we do here?  Is it worth having an RPM build step that
checks for this problem?

Rich.

package libibmad refers to non-existent path -I/usr/usr/include
package libibmad refers to non-existent path -L/usr/usr/lib64
package libcares refers to non-existent path -L/usr/usr/lib64
package libibnetdisc refers to non-existent path -I/usr/usr/include
package libibnetdisc refers to non-existent path -L/usr/usr/lib64
package libmlx5 refers to non-existent path -I/usr/usr/include
package libmlx5 refers to non-existent path -L/usr/usr/lib64
package libefa refers to non-existent path -I/usr/usr/include
package libefa refers to non-existent path -L/usr/usr/lib64
package libibumad refers to non-existent path -I/usr/usr/include
package libibumad refers to non-existent path -L/usr/usr/lib64
package librdmacm refers to non-existent path -I/usr/usr/include
package librdmacm refers to non-existent path -L/usr/usr/lib64
package valgrind refers to non-existent path -L/usr/lib64/valgrind
package libmlx4 refers to non-existent path -I/usr/usr/include
package libmlx4 refers to non-existent path -L/usr/usr/lib64
package libibverbs refers to non-existent path -I/usr/usr/include
package libibverbs refers to non-existent path -L/usr/usr/lib64

[1] Proposed fix for c-ares issue:
http://fedora.riscv.rocks:3000/rpms/c-ares/commit/e5acf4bc513b425793a30fa1fe12af48a15eadd7

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


check-pkgconf.sh
Description: Bourne shell script
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bad paths in *.pc (pkgconf) files

[Richard W.M. Jones]

On Wed, Nov 16, 2022 at 10:34:42AM +, Richard W.M. Jones wrote:
> David (CC'd) is working on the Fedora RISC-V port and he noticed that
> some *.pc files in Fedora contain incorrect paths.  For example[1]:
> 
>   $ pkgconf --libs libcares
>   -L/usr/usr/lib64 -lcares
> 
>   $ pkgconf --libs libasyncns
>   -L/usr/lib -lasyncns 

Actually I realise my script doesn't catch this case (32 bit path)
since the path exists.  I hacked it up to catch this and the complete
results are:

package libasyncns refers to 32 bit path -L/usr/lib
package libwebp refers to 32 bit path -L/usr/lib
package grpc_unsecure refers to 32 bit path -L/usr/lib
package grpc++_unsecure refers to 32 bit path -L/usr/lib
package libwebpdecoder refers to 32 bit path -L/usr/lib
package libibmad refers to non-existent path -I/usr/usr/include
package libibmad refers to non-existent path -L/usr/usr/lib64
package libcares refers to non-existent path -L/usr/usr/lib64
package libibnetdisc refers to non-existent path -I/usr/usr/include
package libibnetdisc refers to non-existent path -L/usr/usr/lib64
package libwebpdemux refers to 32 bit path -L/usr/lib
package libwebpmux refers to 32 bit path -L/usr/lib
package libmlx5 refers to non-existent path -I/usr/usr/include
package libmlx5 refers to non-existent path -L/usr/usr/lib64
package gpr refers to 32 bit path -L/usr/lib
package libefa refers to non-existent path -I/usr/usr/include
package libefa refers to non-existent path -L/usr/usr/lib64
package libibumad refers to non-existent path -I/usr/usr/include
package libibumad refers to non-existent path -L/usr/usr/lib64
package librdmacm refers to non-existent path -I/usr/usr/include
package librdmacm refers to non-existent path -L/usr/usr/lib64
package valgrind refers to non-existent path -L/usr/lib64/valgrind
package grpc refers to 32 bit path -L/usr/lib
package libmlx4 refers to non-existent path -I/usr/usr/include
package libmlx4 refers to non-existent path -L/usr/usr/lib64
package grpc++ refers to 32 bit path -L/usr/lib
package libibverbs refers to non-existent path -I/usr/usr/include
package libibverbs refers to non-existent path -L/usr/usr/lib64

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


check-pkgconf.sh
Description: Bourne shell script
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: moby-engine (also known as Docker) maintenance in Fedora

[Dan Čermák]

Hi Timothée,

On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" 
 wrote:
>Hi everyone,
>
>The moby-engine package [1] (also known as Docker) has been orphaned in Fedora 
>and is looking for a new maintainer. The waiting period will soon be over and 
>the package will be retired if nobody steps in.
>
>This means that the package will be unavailable starting with the next release 
>of Fedora (Fedora 38) that should happen in approximately 5 to 6 months.
>
>If you are using this package and are interested in helping maintaining it, 
>now is the time to come forward!

I'm using docker for $dayjob and would be willing to help out a bit, but I will 
not be the main maintainer, as I don't feel comfortable taking such a huge 
package and lack the cycles for that.

>
>This notably impacts Fedora CoreOS as we are including the moby-engine package 
>by default to let users pick their container engine of choice whithout 
>deciding for them in advance. We offer both major container engines by default 
>in the image (podman and moby-engine).

No offense, but this sounds like that this is something the Fedora coreos team 
should tackle. Given that Fedora coreos appears to be driven to a large extend 
by redhat (at least that's my impression, please correct me if I'm wrong), I 
find it a bit odd that the business is asking volunteers to step up to help the 
business out...

>
>If the moby-engine package ends up being retired for Fedora 38, then we will 
>have to recommend to its users on Fedora CoreOS that they either switch to the 
>official Docker packages [2] or move to containerd or podman when the rebase 
>to Fedora 38 happens alongside the Fedora 38 release [3].
>
>Note that we will likely not remove the containerd package from Fedora CoreOS 
>as it is still maintained in Fedora and is currently used by Kubernetes 
>distributions based on Fedora CoreOS (such as Typhoon for example).
>
>See also the Fedora CoreOS tracker issue [4] for more details.
>
>[1] https://src.fedoraproject.org/rpms/moby-engine
>[2] https://docs.docker.com/engine/install/fedora/
>[3] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html
>[4] https://github.com/coreos/fedora-coreos-tracker/issues/1291
>
>Thanks,
>
>Timothée Ravier for the Fedora CoreOS team
>___
>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, report it: 
>https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bad paths in *.pc (pkgconf) files

[Kalev Lember]

On Wed, Nov 16, 2022 at 11:35 AM Richard W.M. Jones 
wrote:

> David (CC'd) is working on the Fedora RISC-V port and he noticed that
> some *.pc files in Fedora contain incorrect paths.  For example[1]:
>
>   $ pkgconf --libs libcares
>   -L/usr/usr/lib64 -lcares
>
>   $ pkgconf --libs libasyncns
>   -L/usr/lib -lasyncns
>
> On non-riscv64 this happens to work because the default search path
> includes the right directory anyway (eg. /usr/lib64).
>
> On riscv64 this causes build failures since meson seems to go off and
> search for the *.so files and then tries to construct an absolute path
> to them (I'm not sure if this isn't a bug in meson TBH).  For example:
>
>   http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
>
> This problem appears to be widespread.  I scanned just the *-devel
> packages that I happen to have installed, results below.  Not sure how
> to scan all *-devel packages in Fedora.
>
> What should we do here?  Is it worth having an RPM build step that
> checks for this problem?
>

Maybe it would make sense to have a brp check for that, so that the builds
error out with invalid paths? Similar to e.g. how /usr/lib/rpm/check-rpaths
is hooked into %__os_install_post in /usr/lib/rpm/redhat/macros

-- 
Kalev
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bad paths in *.pc (pkgconf) files

[Daniel P . Berrangé]

On Wed, Nov 16, 2022 at 10:34:42AM +, Richard W.M. Jones wrote:
> David (CC'd) is working on the Fedora RISC-V port and he noticed that
> some *.pc files in Fedora contain incorrect paths.  For example[1]:
> 
>   $ pkgconf --libs libcares
>   -L/usr/usr/lib64 -lcares
> 
>   $ pkgconf --libs libasyncns
>   -L/usr/lib -lasyncns 
> 
> On non-riscv64 this happens to work because the default search path
> includes the right directory anyway (eg. /usr/lib64).
> 
> On riscv64 this causes build failures since meson seems to go off and
> search for the *.so files and then tries to construct an absolute path
> to them (I'm not sure if this isn't a bug in meson TBH).  For example:
> 
>   http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
> 
> This problem appears to be widespread.  I scanned just the *-devel
> packages that I happen to have installed, results below.  Not sure how
> to scan all *-devel packages in Fedora.
> 
> What should we do here?  Is it worth having an RPM build step that
> checks for this problem?

Not only should the directory exist, but I think it should
exist in the same RPM that is shipping the .pc file itself.
ie the -devel package should contain the pkg-config file,
header file(s) and at least 1 unversioned .so file(s) in
the directories listed. If any of those are in different
sub-RPMs from each other it would indicate a packaging bug
as well.

Could be done as an rpmlint check, so it is caught during
package review, in addition to doing it in some post
build CI process.

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

Re: Bad paths in *.pc (pkgconf) files

[Vitaly Zaitsev via devel]

On 16/11/2022 12:14, Kalev Lember wrote:
Maybe it would make sense to have a brp check for that, so that the 
builds error out with invalid paths?


+1. Such a check would be very helpful.

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

Re: Direct to stable updates

[Stephen Smoogen]

On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Kevin Fenzi wrote:
> > I think we are going to just have to agree to disagree here.
> >
> > I think we have had this discussion a number of times now and aren't
> > going to convince the other.
>
> So Bodhi will continue to become more and more unmaintainable due to
> piling
> up more and more complicated rules that it needs to enforce, and obvious
> defects such as the one that started this thread will never get addressed.
>
> It is really sad that you are not willing to open your eyes and see the
> amount of damage that this dead-end policy has caused and is still causing.
>
>
Could you possibly pick the fight with the right people for once? It
doesn't matter if Kevin Fenzi agreed with you because he isn't the person
who a) writes the guidelines which were asked to be implemented or b) works
on bodhi codebase in any way. He just makes sure it and the other 240
services runs and that the builds generally flow. That already takes up
about 60 hours of his work week.

If you have problems with this please bring it up with FESCO and the Fedora
Packaging Committee and probably the Council. They are the ones who over
time have listened to packagers, users, and developers about what was
expected from the build system and they are the ones who have given general
guidance over the last 10+ years of bodhi development.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bad paths in *.pc (pkgconf) files

[Richard W.M. Jones]

On Wed, Nov 16, 2022 at 12:14:21PM +0100, Kalev Lember wrote:
> On Wed, Nov 16, 2022 at 11:35 AM Richard W.M. Jones  wrote:
> 
> David (CC'd) is working on the Fedora RISC-V port and he noticed that
> some *.pc files in Fedora contain incorrect paths.  For example[1]:
> 
>   $ pkgconf --libs libcares
>   -L/usr/usr/lib64 -lcares
> 
>   $ pkgconf --libs libasyncns
>   -L/usr/lib -lasyncns
> 
> On non-riscv64 this happens to work because the default search path
> includes the right directory anyway (eg. /usr/lib64).
> 
> On riscv64 this causes build failures since meson seems to go off and
> search for the *.so files and then tries to construct an absolute path
> to them (I'm not sure if this isn't a bug in meson TBH).  For example:
> 
>   http://fedora.riscv.rocks/koji/taskinfo?taskID=1305782
> 
> This problem appears to be widespread.  I scanned just the *-devel
> packages that I happen to have installed, results below.  Not sure how
> to scan all *-devel packages in Fedora.
> 
> What should we do here?  Is it worth having an RPM build step that
> checks for this problem?
> 
> 
> Maybe it would make sense to have a brp check for that, so that the builds
> error out with invalid paths? Similar to e.g. how /usr/lib/rpm/check-rpaths is
> hooked into %__os_install_post in /usr/lib/rpm/redhat/macros

Yes this is exactly what I was thinking too.  I filed a bug to track
the work:

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

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direct to stable updates

[Kevin Kofler via devel]

Stephen Smoogen wrote:
> On Tue, 15 Nov 2022 at 16:04, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
> 
>> Kevin Fenzi wrote:
>> > I think we are going to just have to agree to disagree here.
>> >
>> > I think we have had this discussion a number of times now and aren't
>> > going to convince the other.
>>
>> So Bodhi will continue to become more and more unmaintainable due to
>> piling
>> up more and more complicated rules that it needs to enforce, and obvious
>> defects such as the one that started this thread will never get
>> addressed.
>>
>> It is really sad that you are not willing to open your eyes and see the
>> amount of damage that this dead-end policy has caused and is still
>> causing.
>>
>>
> Could you possibly pick the fight with the right people for once? It
> doesn't matter if Kevin Fenzi agreed with you because he isn't the person
> who a) writes the guidelines which were asked to be implemented or b)
> works on bodhi codebase in any way. He just makes sure it and the other
> 240 services runs and that the builds generally flow. That already takes
> up about 60 hours of his work week.
> 
> If you have problems with this please bring it up with FESCO and the
> Fedora Packaging Committee and probably the Council.

Kevin Fenzi is currently a member of FESCo (see 
https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for 
years. So pushing the blame off to "someone else" is not going to work.

And I have brought this issue to FESCo (which is where most of the update 
policies came from, not FPC or the Council) more than once. Usually, it was 
not even brought to a vote. And whenever there was a vote about the issue, 
it was always in favor of either the status quo or even stricter rules.

> They are the ones who over time have listened to packagers, users, and
> developers about what was expected from the build system

And that is exactly what I am disputing, that they are listening to what 
packagers expect. Because it can surely not be the packagers' wish to have 
some piece of software stubbornly dictate that no, that package can not be 
pushed to stable now because it reached testing only 6 days, 23 hours, 59 
minutes and 59.99 seconds ago. (I believe the timestamps in Bodhi have 
microsecond resolution internally. They used to be displayed that way, at 
least.)

Nor can it be in the interest of the Bodhi developers to have to maintain 
all that complex logic: you pointed out yourself that "what happens is that 
you will get into about 1/3rd of the way into it and find you have now to 
add a bunch of new requirements" – surely that is not what the developers 
expect.

> and they are the ones who have given general guidance over the last 10+
> years of bodhi development.

If by "general guidance" you mean skyrocketing requirements, then I agree. 
Otherwise, I don't, sorry. See above, you admitted yourself that the 
requirements keep increasing all the time, forcing a major refactoring.

These days, even Rawhide (!) gets forced through Bodhi, though with an 
entirely different workflow (but in turn, that means the Bodhi developers 
get to maintain 2 completely different workflows with completely different 
rules). That is something Bodhi was never designed for. And the policy 
changes that have been made for Rawhide over the years have also changed 
things for the worse: It used to be that you were able to just do 
development in Rawhide, without having to bother about broken dependencies 
(which would just show up in the daily dependency report and get fixed 
there: I remember provenpackagers, mainly Alex Lancaster and me, mass-
rebuilding packages to fix broken dependencies; Rawhide composes did NOT 
fail due to broken dependencies at the time, the deliverables that failed to 
compose would just be missing that day), upgrade paths (from Rawhide to 
Rawhide, really no reason to not just let the users use distro-sync there 
and allow the version to go backwards; upgrade paths make sense only for 
releases), test failures (Rawhide was expected to be broken, as is normal), 
etc. Now we just make life harder for everyone, both package maintainers and 
Bodhi developers, for no reason.

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

Re: moby-engine (also known as Docker) maintenance in Fedora

[Kevin Kofler via devel]

Dan Čermák wrote:
> I find it a bit odd that the business is asking volunteers to step up to
> help the business out...

Is that not the whole concept of Fedora?

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

koji down?

[Richard Shaw]

I didn't see any other threads but I can't have been the first to notice...

I can't access the koji web interface or initiate builds...

Kerberos authentication fails: unable to obtain a session (gssapi auth
failed: requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='
koji.fedoraproject.org', port=443): Read timed out. (read timeout=60))

Anyone else seeing this?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: moby-engine (also known as Docker) maintenance in Fedora

[Peter Robinson]

On Wed, Nov 16, 2022 at 11:09 AM Dan Čermák
 wrote:
>
> Hi Timothée,
>
> On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" 
>  wrote:
> >Hi everyone,
> >
> >The moby-engine package [1] (also known as Docker) has been orphaned in 
> >Fedora and is looking for a new maintainer. The waiting period will soon be 
> >over and the package will be retired if nobody steps in.
> >
> >This means that the package will be unavailable starting with the next 
> >release of Fedora (Fedora 38) that should happen in approximately 5 to 6 
> >months.
> >
> >If you are using this package and are interested in helping maintaining it, 
> >now is the time to come forward!
>
> I'm using docker for $dayjob and would be willing to help out a bit, but I 
> will not be the main maintainer, as I don't feel comfortable taking such a 
> huge package and lack the cycles for that.
>
> >
> >This notably impacts Fedora CoreOS as we are including the moby-engine 
> >package by default to let users pick their container engine of choice 
> >whithout deciding for them in advance. We offer both major container engines 
> >by default in the image (podman and moby-engine).
>
> No offense, but this sounds like that this is something the Fedora coreos 
> team should tackle. Given that Fedora coreos appears to be driven to a large 
> extend by redhat (at least that's my impression, please correct me if I'm 
> wrong), I find it a bit odd that the business is asking volunteers to step up 
> to help the business out...

Why? Red Hat no longer uses or ships moby-engine or any of it's
derivatives, it's moved all it's focus to the podman ecosystem, if it
was up to Red Hat they would have dropped moby from FCoS long ago, I
suspect it's there up until now to give the community a choice.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Richard Shaw]

On Wed, Nov 16, 2022 at 3:19 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Wednesday, 16 November 2022 at 09:22, Vitaly Zaitsev via devel wrote:
> > On 15/11/2022 23:25, Gordon Messmer wrote:
> > > I had thought that the Fedora 37 mesa packages retained accelerated
> > > video for open codecs (for AMD hardware)
> >
> > To accelerate H.264/H.265, you need to replace the stripped Fedora
> > versions with the full versions from the RPM Fusion repository:
> >
> > sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing
> > sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
> --allowerasing
> >
> > > However, the Fedora wiki[1] indicates that even open codecs are no
> > > longer accelerated without third party packages.  Is that true?
> >
> > On Intel, you need to install the libva-intel-driver (i915) and
> > intel-media-driver (iHD) packages.
>
> Actually, it's either one or the other as they don't support the same
> CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for
> older ones (Ice Lake is the first one it doesn't support). See
>
> https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-API_Video_decoding_on_Intel
> https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers


The fact that it's this confusing on the -devel list means it's going to be
VERY confusing to end users. We need good documentation, which
unfortunately has been one of our weak points, and it needs to be
broadcasted everywhere.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Richard W.M. Jones]

On Wed, Nov 16, 2022 at 07:19:37AM -0600, Richard Shaw wrote:
> I didn't see any other threads but I can't have been the first to notice...
> 
> I can't access the koji web interface or initiate builds...
> 
> Kerberos authentication fails: unable to obtain a session (gssapi auth failed:
> requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='
> koji.fedoraproject.org', port=443): Read timed out. (read timeout=60))
> 
> Anyone else seeing this?

Yes, up and down most of the morning.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: moby-engine (also known as Docker) maintenance in Fedora

[Dusty Mabe]

On 11/16/22 06:09, Dan Čermák wrote:
> Hi Timothée,

Hey Dan 
> 
> On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" 
>  wrote:
>> Hi everyone,
>>
>> The moby-engine package [1] (also known as Docker) has been orphaned in 
>> Fedora and is looking for a new maintainer. The waiting period will soon be 
>> over and the package will be retired if nobody steps in.
>>
>> This means that the package will be unavailable starting with the next 
>> release of Fedora (Fedora 38) that should happen in approximately 5 to 6 
>> months.
>>
>> If you are using this package and are interested in helping maintaining it, 
>> now is the time to come forward!
> 
> I'm using docker for $dayjob and would be willing to help out a bit, but I 
> will not be the main maintainer, as I don't feel comfortable taking such a 
> huge package and lack the cycles for that.

I think there are others that would be willing to help mentor you if
you'd be interested in the challenge (with help). The Golang SIG has
regular meetings and various ways to communicate, which might be a
good way to engage: https://fedoraproject.org/wiki/SIGs/Go

> 
>>
>> This notably impacts Fedora CoreOS as we are including the moby-engine 
>> package by default to let users pick their container engine of choice 
>> whithout deciding for them in advance. We offer both major container engines 
>> by default in the image (podman and moby-engine).
> 
> No offense, but this sounds like that this is something the Fedora coreos 
> team should tackle. Given that Fedora coreos appears to be driven to a large 
> extend by redhat (at least that's my impression, please correct me if I'm 
> wrong), I find it a bit odd that the business is asking volunteers to step up 
> to help the business out...

No offense taken. This is a great opportunity to add some clarity. Red Hat
doesn't ship Docker in products any longer.  It was dropped in RHEL8+:
https://access.redhat.com/solutions/3696691

Docker (moby-engine) is in Fedora because of the community, which is
obviously what makes Fedora so great.


Dusty
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Luna Jernberg]

Did notice it too, and reported it on Pagure and IRC and smooge said
it was sad due to the database using too much RAM memory


On Wed, Nov 16, 2022 at 2:20 PM Richard Shaw  wrote:
>
> I didn't see any other threads but I can't have been the first to notice...
>
> I can't access the koji web interface or initiate builds...
>
> Kerberos authentication fails: unable to obtain a session (gssapi auth 
> failed: requests.exceptions.ReadTimeout: 
> HTTPSConnectionPool(host='koji.fedoraproject.org', port=443): Read timed out. 
> (read timeout=60))
>
> Anyone else seeing this?
>
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Stephen Smoogen]

On Wed, 16 Nov 2022 at 08:20, Richard Shaw  wrote:

> I didn't see any other threads but I can't have been the first to notice...
>
> I can't access the koji web interface or initiate builds...
>
> Kerberos authentication fails: unable to obtain a session (gssapi auth
> failed: requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='
> koji.fedoraproject.org', port=443): Read timed out. (read timeout=60))
>
> Anyone else seeing this?
>
>
Currently the backend database is running out of memory (128GB) and CPU (90
cpus) and is running at a continuous load average of over 300. The system
earlier crashed hard and needed to be rebooted but that did not seem to
help any. The release engineers are looking into it but I do not have any
information than that.



> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Michael Cronenworth]

On 11/16/22 3:18 AM, Dominik 'Rathann' Mierzejewski wrote:

Actually, it's either one or the other as they don't support the same
CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for
older ones (Ice Lake is the first one it doesn't support).


To be pedantic there is some overlap in support in iHD and i965.

What will also rock your noggin is that i965 is faster than iHD.

https://github.com/intel/media-driver/issues/925
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : Prioritized bugs and issues

[Luna Jernberg]

Joined now, sorry for being a bit late

On Tue, Nov 15, 2022 at 10:27 PM Ben Cotton  wrote:
>
> On Tue, Nov 15, 2022 at 11:29 AM  wrote:
> >
> > You are kindly invited to the meeting:
> >Prioritized bugs and issues on 2022-11-16 from 10:00:00 to 11:00:00 
> > America/Indiana/Indianapolis
> >At fedora-meetin...@irc.libera.chat
> >
> > More information available at: 
> > https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/
>
> We will discuss the following nominated bug:
>
> * ABRT on KDE can't store any passwords: Secret Service is not available
> - https://bugzilla.redhat.com/show_bug.cgi?id=2141237
>
> --
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bad paths in *.pc (pkgconf) files

[Ben Beasley]

The following reflect an upstream bug in grpc:

package grpc_unsecure refers to 32 bit path -L/usr/lib
package grpc++_unsecure refers to 32 bit path -L/usr/lib
package gpr refers to 32 bit path -L/usr/lib
package grpc refers to 32 bit path -L/usr/lib
package grpc++ refers to 32 bit path -L/usr/lib

Now that I know about the problem, I was able to submit a PR upstream[1] 
to fix it. I will patch and update the Fedora packages over the next few 
days.


[1] https://github.com/grpc/grpc/pull/31671

On 11/16/22 06:01, Richard W.M. Jones wrote:

On Wed, Nov 16, 2022 at 10:34:42AM +, Richard W.M. Jones wrote:

David (CC'd) is working on the Fedora RISC-V port and he noticed that
some *.pc files in Fedora contain incorrect paths.  For example[1]:

   $ pkgconf --libs libcares
   -L/usr/usr/lib64 -lcares

   $ pkgconf --libs libasyncns
   -L/usr/lib -lasyncns

Actually I realise my script doesn't catch this case (32 bit path)
since the path exists.  I hacked it up to catch this and the complete
results are:

package libasyncns refers to 32 bit path -L/usr/lib
package libwebp refers to 32 bit path -L/usr/lib
package grpc_unsecure refers to 32 bit path -L/usr/lib
package grpc++_unsecure refers to 32 bit path -L/usr/lib
package libwebpdecoder refers to 32 bit path -L/usr/lib
package libibmad refers to non-existent path -I/usr/usr/include
package libibmad refers to non-existent path -L/usr/usr/lib64
package libcares refers to non-existent path -L/usr/usr/lib64
package libibnetdisc refers to non-existent path -I/usr/usr/include
package libibnetdisc refers to non-existent path -L/usr/usr/lib64
package libwebpdemux refers to 32 bit path -L/usr/lib
package libwebpmux refers to 32 bit path -L/usr/lib
package libmlx5 refers to non-existent path -I/usr/usr/include
package libmlx5 refers to non-existent path -L/usr/usr/lib64
package gpr refers to 32 bit path -L/usr/lib
package libefa refers to non-existent path -I/usr/usr/include
package libefa refers to non-existent path -L/usr/usr/lib64
package libibumad refers to non-existent path -I/usr/usr/include
package libibumad refers to non-existent path -L/usr/usr/lib64
package librdmacm refers to non-existent path -I/usr/usr/include
package librdmacm refers to non-existent path -L/usr/usr/lib64
package valgrind refers to non-existent path -L/usr/lib64/valgrind
package grpc refers to 32 bit path -L/usr/lib
package libmlx4 refers to non-existent path -I/usr/usr/include
package libmlx4 refers to non-existent path -L/usr/usr/lib64
package grpc++ refers to 32 bit path -L/usr/lib
package libibverbs refers to non-existent path -I/usr/usr/include
package libibverbs refers to non-existent path -L/usr/usr/lib64

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Re: moby-engine (also known as Docker) maintenance in Fedora

[Maxwell G via devel]

On Wed Nov 16, 2022 at 08:25 -0500, Dusty Mabe wrote:
> On 11/16/22 06:09, Dan Čermák wrote:
> > On November 14, 2022 7:18:45 PM UTC, "Timothée Ravier" 
> >  wrote:

> > I'm using docker for $dayjob and would be willing to help out a bit, but I 
> > will not be the main maintainer, as I don't feel comfortable taking such a 
> > huge package and lack the cycles for that.

Yes, the package is complicated :(. It could use some cleanup (see the
end of [1]), but I'm trying to step away from the package, and I haven't
had time to.

[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DMPZRAUO3H5EHOCZDULYORYJVQU2WBIJ/

> I think there are others that would be willing to help mentor you if
> you'd be interested in the challenge (with help). The Golang SIG has
> regular meetings and various ways to communicate, which might be a
> good way to engage: https://fedoraproject.org/wiki/SIGs/Go

That's true. Our next meeting is the 21st at 19:00 UTC in
#fedora-golang. As always, anybody is welcome to attend :).

> >> This notably impacts Fedora CoreOS as we are including the moby-engine 
> >> package by default to let users pick their container engine of choice 
> >> whithout deciding for them in advance. We offer both major container 
> >> engines by default in the image (podman and moby-engine).
> >
> > No offense, but this sounds like that this is something the Fedora coreos 
> > team should tackle. Given that Fedora coreos appears to be driven to a 
> > large extend by redhat (at least that's my impression, please correct me if 
> > I'm wrong), I find it a bit odd that the business is asking volunteers to 
> > step up to help the business out...
>
> No offense taken. This is a great opportunity to add some clarity. Red Hat
> doesn't ship Docker in products any longer.  It was dropped in RHEL8+:
> https://access.redhat.com/solutions/3696691

Yes, Docker and Containerd are no longer Supported in RHEL, but that's
besides the point here. Fedora CoreOS ships moby-engine. The CoreOS
Working Group apparently care about moby-engine and want it to be
included in FCOS. I picked up on this and asked if they'd be willing to
help maintain it. The two developers involved (who are paid by RH to
work on FCOS) made clear that they are uninterested in doing so[^1] and
took it upon themselves to find a volunteer to maintain the package. We
got more contributions from an outside contributor who wasn't a package
maintainer (3 PRs which involved rebasing patches, updating
dependencies, and diagnosing build failures) than the FCOS team (0 PRs,
5 pings on their issue tracker and IRC, this email). I'm not trying to
cause unnecessary strife here and they have apologized, but I'd be
dishonest if I said I wasn't disappointed with the way this situation
was handled.

[^1]: which is alright. Everyone is free to choose what packages
they do or don't want to maintain.


--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Kevin Fenzi]

Everything should be back up now...

I'm watching it for a bit before I declare things are back fully to
normal though. ;) 

Do note that mailing list threads aren't a great place to report
outages. Please report them to the infrastructure ticket tracker: 
https://pagure.io/fedora-infrastructure/

Thanks. 

kevin


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

Re: Direct to stable updates

[Mattia Verga via devel]

Il 10/11/22 21:49, Kevin Fenzi ha scritto:
> On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
>> Il 10/11/22 01:58, Kevin Kofler via devel ha scritto:
>>> Kevin Kofler via devel wrote:
>>>
 Mattia Verga via devel wrote:
> with the current workflow, Bodhi doesn't know when a release is freezed.
> There is support for a "Freeze" state, but it was never used.
 How do we prevent then that pushes to stable actually move forward? If
 rel- eng just hits a different button / runs a different script to push
 testing only instead of both testing and stable, that is the "can we push
 to stable?" property Bodhi needs to check.
>>> PS: The "worst mistake" that can happen then is that if we push only testing
>>> to a non-frozen release for whatever reason, the update will be included in
>>> that testing push, and then move forward to stable in the next stable push.
>>> I do not see this as a real issue.
>>>
>> I'm working on fixing some bits in Bodhi before proposing to releng the
>> use of the 'frozen' release state. That will enable Bodhi to avoid
>> pushing updates directly to stable if the release is frozen, as well as
>> some small tweaks that were requested and would make life easier for
>> releng folks.
> Thanks!
>
> To explain a bit to everyone the current workflow:
>
> * In non freeze times, we have a cron job that pushes "all pending
> updates" at 00:14 UTC every day. This is stable and testing for anything
> thats pending moving to a new state.
>
> * In freezes however, we have to disable the cron job and manually:
> - First push branched version updates-testing by itself.
> - Then push everything else (minus the branched version).
>
> This sucks, because it's manual, there's a hour or so wait for
> updates-testing to finish before we can do the rest, and you have to
> remember to list:
> --releases 
> EPEL-9N,EPEL-7,EPEL-8,F36,F36C,EPEL-8M,EPEL-9,EPEL-8N,F35,F35M,F35C,F36M,F35F,F36F
>
> If we could just mark branched frozen and have it not push stable there
> (without specific builds, because we do still need to push stable
> requests through the freeze) that would be great. We could also actually
> note this in updates so people don't get confused why their update
> didn't get pushed stable.
>
>> It shouldn't be too hard, it's just that Bodhi code is
>> sometimes so contorted that by making a simple change it's easy to break
>> something else... moving updates from one state to another and tagging
>> builds in the correct way without losing the right track is one of those
>> contorted part.
> Yeah. ;(
>
> Thanks again for working on it!
>
> kevin

Kevin, the PR for Bodhi is nearly finished, it will add support for
using the 'frozen' release state to avoid pausing the push cron job and
avoid direct pending to stable push of updates when the release is frozen.

I'll open a ticket to releng for changing the usual workflow of new
releases once the PR gets merged and a new Bodhi release is drafted and
pushed to prod. About the avoidance of direct to stable pushing, do you
think it needs to be discussed by FESCo?

Mattia

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Richard Shaw]

On Wed, Nov 16, 2022 at 11:32 AM Kevin Fenzi  wrote:

> Everything should be back up now...
>
> I'm watching it for a bit before I declare things are back fully to
> normal though. ;)
>
> Do note that mailing list threads aren't a great place to report
> outages. Please report them to the infrastructure ticket tracker:
> https://pagure.io/fedora-infrastructure/


I recently switched internet providers so I was looking for an ACK that it
wasn't just me.

But on a related note, it can be somewhat difficult to remember all the
different sites and which is appropriate for what when you don't deal with
them on a regular basis..

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direct to stable updates

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 05:37:07PM +, Mattia Verga via devel wrote:
> 
> Kevin, the PR for Bodhi is nearly finished, it will add support for
> using the 'frozen' release state to avoid pausing the push cron job and
> avoid direct pending to stable push of updates when the release is frozen.

Awesome.

> I'll open a ticket to releng for changing the usual workflow of new
> releases once the PR gets merged and a new Bodhi release is drafted and
> pushed to prod. About the avoidance of direct to stable pushing, do you
> think it needs to be discussed by FESCo?

No, I think it's a implementation detail that makes things better for
releng, but has no end visible changes, so no need to run it by FESCo. 

kevin


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

Re: Direct to stable updates

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 02:09:47PM +0100, Kevin Kofler via devel wrote:
> 
> Kevin Fenzi is currently a member of FESCo (see 
> https://docs.fedoraproject.org/en-US/fesco/) and has been in that role for 
> years. So pushing the blame off to "someone else" is not going to work.

You're welcome to bring anything you like to me. (That goes for
everyone!)

That said, it doesn't mean I have to agree with you or do what you want.

> And I have brought this issue to FESCo (which is where most of the update 
> policies came from, not FPC or the Council) more than once. Usually, it was 
> not even brought to a vote. And whenever there was a vote about the issue, 
> it was always in favor of either the status quo or even stricter rules.

Indeed.
That might be an indicator that not so many people agree with you? 
 
> > They are the ones who over time have listened to packagers, users, and
> > developers about what was expected from the build system
> 
> And that is exactly what I am disputing, that they are listening to what 
> packagers expect. Because it can surely not be the packagers' wish to have 
> some piece of software stubbornly dictate that no, that package can not be 
> pushed to stable now because it reached testing only 6 days, 23 hours, 59 
> minutes and 59.99 seconds ago. (I believe the timestamps in Bodhi have 
> microsecond resolution internally. They used to be displayed that way, at 
> least.)

With my packager hat on, yes, I am completely fine with bodhi telling me
that. 

> Nor can it be in the interest of the Bodhi developers to have to maintain 
> all that complex logic: you pointed out yourself that "what happens is that 
> you will get into about 1/3rd of the way into it and find you have now to 
> add a bunch of new requirements" – surely that is not what the developers 
> expect.

I agree that bodhi is a complex application, but I disagree most
strongly that the solution is to just make it not do all those things
that I find useful and desireable. 

> > and they are the ones who have given general guidance over the last 10+
> > years of bodhi development.
> 
> If by "general guidance" you mean skyrocketing requirements, then I agree. 
> Otherwise, I don't, sorry. See above, you admitted yourself that the 
> requirements keep increasing all the time, forcing a major refactoring.
> 
> These days, even Rawhide (!) gets forced through Bodhi, though with an 
> entirely different workflow (but in turn, that means the Bodhi developers 
> get to maintain 2 completely different workflows with completely different 
> rules). That is something Bodhi was never designed for. And the policy 
> changes that have been made for Rawhide over the years have also changed 
> things for the worse: It used to be that you were able to just do 
> development in Rawhide, without having to bother about broken dependencies 
> (which would just show up in the daily dependency report and get fixed 
> there: I remember provenpackagers, mainly Alex Lancaster and me, mass-
> rebuilding packages to fix broken dependencies; Rawhide composes did NOT 
> fail due to broken dependencies at the time, the deliverables that failed to 
> compose would just be missing that day), upgrade paths (from Rawhide to 
> Rawhide, really no reason to not just let the users use distro-sync there 
> and allow the version to go backwards; upgrade paths make sense only for 
> releases), test failures (Rawhide was expected to be broken, as is normal), 
> etc. Now we just make life harder for everyone, both package maintainers and 
> Bodhi developers, for no reason.

I think the current situation is much better than what we had then. 
Blocking updates that break things is desireable, they will be fixed
sooner and not break everyone else that is trying to integrate their
changes. 

We can of course make things better, but I don't have any desire to go
back to the "good old days". 

Anyhow, I am done, feel free to get the last words in the thread. :) 

kevin


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

FESCo election nominations are now open

[Ben Cotton]

Now through 30 November, you may nominate candidates for the open
seats on the Fedora Engineering Steering Committee (FESCo).

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.

For more information, see the Community Blog post:
https://communityblog.fedoraproject.org/f37-election-nominations-now-open/

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

Re: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

[Gordon Messmer]

On 2022-11-16 00:22, Vitaly Zaitsev via devel wrote:

To accelerate H.264/H.265, you need to...



I'm aware.  My question was intended to be very specific to the 
statement made in Fedora's wiki with regard to open codecs like VP9 on 
AMD.  I've since updated the wiki.

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Kevin Fenzi]

On Wed, Nov 16, 2022 at 11:37:43AM -0600, Richard Shaw wrote:
> On Wed, Nov 16, 2022 at 11:32 AM Kevin Fenzi  wrote:
> 
> > Everything should be back up now...
> >
> > I'm watching it for a bit before I declare things are back fully to
> > normal though. ;)
> >
> > Do note that mailing list threads aren't a great place to report
> > outages. Please report them to the infrastructure ticket tracker:
> > https://pagure.io/fedora-infrastructure/
> 
> 
> I recently switched internet providers so I was looking for an ACK that it
> wasn't just me.
> 
> But on a related note, it can be somewhat difficult to remember all the
> different sites and which is appropriate for what when you don't deal with
> them on a regular basis..

Yeah. 

I'm not sure how to make things more visible, but really the best link
to know is the one you get to via docs.fedoraproject.org, engineering
teams, fedora infra, working with fedora infra. ie,
https://docs.fedoraproject.org/en-US/infra/day_to_day_fedora/

kevin


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

Re: SPDX - How to handle MIT and BSD

[Miroslav Suchý]

Dne 16. 11. 22 v 7:47 Bob Mauchin napsal(a):


I package askalono-cli which can detect license texts and outputs an SPDX identifier: 
https://github.com/jpeddicord/askalono


This is is great. I have added it to Change documentation.

Mirek
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: yaml-cpp 0.7.0 soname bump for Rawhide is complete

[Richard Shaw]

On Tue, Nov 15, 2022 at 5:19 PM Mamoru TASAKA 
wrote:

> Richard Shaw wrote on 2022/11/16 1:10:
> > I had to back off updating OpenColorIO as it needed a newer version of
> > minizip-ng than what's available.
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2022-518f2de934
> >
> > The only fallout is supercollider which failed to build for other
> reasons:
> >
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=2085987
>
> supercollider is fixed in -7, backporting upstream fix for libsndfile
> 1.1.x .
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2089036
>
> repoquery says cantera also needs rebuilding for new yaml-cpp, so it's
> done.
>

Thanks for following up!

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: koji down?

[Gary Buhrmaster]

On Wed, Nov 16, 2022 at 5:38 PM Richard Shaw  wrote:

> I recently switched internet providers so I was looking for an ACK that it 
> wasn't just me.

I am curious, did you try https://status.fedoraproject.org and did
it show the outage at the time (since it is manually updated, it
would typically lag the actual status, but it might have provided
a hint)?
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update

[Jilayne Lovejoy]

Hi all,

Sorry for joining the thread late, but a few thoughts below!

> Tl;dr Please start migrating your license tag to SPDX now. Tool 
> `license-fedora2spdx` is
> your friend. The JSON format 
> changed - but is backwards compatible.
> 
> 
> Hi.
> 
> I want to update you on where we are with SPDX Change
> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 
> ;:
> 
> 
>  1. All parts that are part of this phase are done. We are missing only one 
> optional item,
> and we want to automatize the
> generation of legal-docs. Right now I have to manually create PR for 
> legal-docs
> whenever I release fedora-license-data.
> 
Miroslav - having to do this manually doesn't seem optimal, do you need some 
help on automating this?

Also, for the Allowed page 
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ - we have separate 
tables for each type of allowed and the full table with columns for each type 
of allowed license. Do people like having both options? Just wondering if it 
would be easier to use if we went one way or the other (I'd lean to one table, 
personally!)


>  5. Please, start migrating your spec files **now**. You can use the tool
> `license-fedora2spdx` from package
> `license-validate`. Use this opportunity to check if your package license 
> matches the
> upstream version - especially
> if you took over the package from the previous maintainer. If you are not 
> sure what
> SPDX string to use, ask for help
> on the “legal” mailing
> listhttps://lists.fedoraproject.org/archives/list/legal@lists.fedoraproje...
> 
>  

Can you remind me what 'license-fedora2spdx' does / how it's being used in this 
context?
I recall an earlier version of this, but is this now pulling data from the 
fedora-license-data repo in Gitlab (TOML files)?

> 
>  7. When your license does not have an SPDX identifier, then please follow 
> this
> 
> documentationhttps://docs.fedoraproject.org/en-US/legal/update-existing-p...
> 
> 
Note, I recently updated the a few things related to this, namely the info on 
Public Domain. 
I also revised the advice on using SPDX-license-diff a bit here 
https://docs.fedoraproject.org/en-US/legal/license-review-process/#_how_to_determine_if_a_license_or_exception_is_on_the_spdx_license_list
 based on my own observations. 
If there is any other suggestions people have, please make an issue in the 
documentation repo and tag me!

> 
> 10.
> 
> As of 2022-10-27:
> 
>  1.There are 23302 spec files in Fedora
> 
>  2.264 mentions "SPDX" in the spec changelog
> 
>  3. out of the remaining, 173 packages mention "SPDX" in dist-git 
> log
> 
>  4. 22865 packages need to be migrated yet.
> 
>  5.11371 package has straight answer from `license-fedora2spdx` 
> and the migration is
> trivial.

What do you mean by "has a straight answer"? Is this when license-fedora2spdx 
gives you a single SPDX expression based on the Fedora shortname already in the 
spec License: field and based on the current fedora-license-data repo?

> 
> 11. Right now, we are finalizing the Change proposal for phase 2
>   https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2 is yet about to be finished and approved. The main takeaway is that we do 
> not plan to
> do any mass action before
> Fedora 38 branching (I.e. 2023-02-07)
> 
Thanks for putting up the Change Proposal - I'll add anything other thoughts 
there.

Jilayne
> 
> Miroslav
> 
> on behalf of other owners of this Change (Jillayne, Neal, David, Richard, 
> Matthew)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora CoreOS Meeting Minutes 2022-11-16

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-16/fedora_coreos_meeting.2022-11-16-16.29.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-16/fedora_coreos_meeting.2022-11-16-16.29.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-16/fedora_coreos_meeting.2022-11-16-16.29.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:29:42 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-11-16/fedora_coreos_meeting.2022-11-16-16.29.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:29:48)

* Action items from last meeting  (dustymabe, 16:33:52)
  * travier sent communications about docker maintenance:

https://discussion.fedoraproject.org/t/moby-engine-also-known-as-docker-maintenance-in-fedora/44037
(dustymabe, 16:34:07)

* open floor  (dustymabe, 16:34:50)
  * The `testing` stream is now on Fedora 37 content:

https://discussion.fedoraproject.org/t/fedora-coreos-streams-rebasing-to-fedora-linux-37/44085
(dustymabe, 16:35:14)

Meeting ended at 17:16:30 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (56)
* jlebon (19)
* lucab (17)
* zodbot (15)
* fifofonix (11)
* Nemric (9)
* travier (6)
* aaradhak[m] (1)
* aaradhak (1)
* ravanelli (1)
* walters (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Change update - Missing identifier for XDebug

[Jilayne Lovejoy]

> Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):
> 
> 
> Open an issue for
> 
> https://gitlab.com/fedora/legal/fedora-license-data
> 
> if there is need for new SPDX id then Jilayne will request it for you and add 
> it to
> fedora-license-data.
> 
Just a quick process clarification here! 

Generally, please follow the process as described here: 
https://docs.fedoraproject.org/en-US/legal/license-review-process/

If a license does need to be submitted to SPDX, then it is best if a Fedora 
community member (not me) submit it. This is because, as per SPDX process, the 
person who submits the license is not expected to weigh in on as an SPDX-legal 
team member on the approval.  

More on the process for SPDX can be found here: 
https://github.com/spdx/license-list-XML/blob/main/DOCS/request-new-license.md

Relatedly, Richard has made a bunch of license submissions to SPDX License List 
on behalf of Fedora: see 
https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+label%3A%22new+license%2Fexception+request%22
As per SPDX process, usually the submitter is asked to help create the files 
once a license is accepted, but I'm not sure it's fair for Richard to do all of 
those - it'd be great to get a little help on the from the Fedora community 
since these are licenses that will be added to the Fedora license data. 

Thanks,
Jilayne
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

hackrf package

[Steven A. Falco]

I just upgraded my system to Fedora 37 and noticed that the package "hackrf" 
was still from Fedora 36.  I found a failed build from the f37-rebuild, dated 2022-07-21 
[1].  It apparently failed on aarch64, but the logs are long gone - at least I don't see 
them on koji.

I tried a scratch build, and it went fine [2].

What is the correct procedure to request a rebuild for situations like this?  
Should I ask the maintainers, or file an infra ticket, or ...?

Steve

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=89804049
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=94253032
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: hackrf package

[Scott Talbert]

> I just upgraded my system to Fedora 37 and noticed that the package "hackrf" 
> was
> still from Fedora 36.  I found a failed build from the f37-rebuild, dated 
> 2022-07-21 [1]. 
> It apparently failed on aarch64, but the logs are long gone - at least I 
> don't see
> them on koji.
> 
> I tried a scratch build, and it went fine [2].
> 
> What is the correct procedure to request a rebuild for situations like this?  
> Should I ask
> the maintainers, or file an infra ticket, or ...?
> 
>   Steve
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=89804049
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=94253032

There's already an open bug: https://bugzilla.redhat.com/show_bug.cgi?id=2113439

You might want to follow-up on that bug, or perhaps initiate a non-responsive 
maintainer process, if the maintainer continues to not respond.

Scott
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Test-Announce] Fedora 38 Rawhide 20221116.n.1 nightly compose nominated for testing

[rawhide]

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

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Rawhide_20221116.n.1_Security_Lab

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

Fedora rawhide compose report: 20221116.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221115.n.0
NEW: Fedora-Rawhide-20221116.n.1

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  3
Dropped packages:23
Upgraded packages:   176
Downgraded packages: 1

Size of added packages:  279.08 KiB
Size of dropped packages:3.02 MiB
Size of upgraded packages:   6.63 GiB
Size of downgraded packages: 495.72 KiB

Size change of upgraded packages:   -276.67 MiB
Size change of downgraded packages: 607 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20221116.n.1.s390x.tar.xz

= DROPPED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20221115.n.0.s390x.tar.xz
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20221115.n.0.aarch64.tar.xz
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20221115.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: rsakeyfind-1.0-2.fc38
Summary: Locate BER-encoded RSA private and public keys in memory images
RPMs:rsakeyfind
Size:73.65 KiB

Package: rust-yeslogic-fontconfig-sys-2.11.2-1.fc38
Summary: Raw bindings to Fontconfig
RPMs:rust-yeslogic-fontconfig-sys+default-devel 
rust-yeslogic-fontconfig-sys-devel
Size:21.41 KiB

Package: synce4l-0-3.20221114gitca51d5.fc38
Summary: SyncE implementation for Linux
RPMs:synce4l
Size:184.02 KiB


= DROPPED PACKAGES =
Package: drupal7-advanced_help-1.5-9.fc37
Summary: Provide extended help and documentation
RPMs:drupal7-advanced_help
Size:148.36 KiB

Package: drupal7-calendar-3.5-16.fc37
Summary: This module will display any Views date field in calendar formats
RPMs:drupal7-calendar
Size:70.57 KiB

Package: drupal7-ckeditor-1.19-7.fc37
Summary: Enables the usage of CKEditor (WYSIWYG) instead of plain text fields
RPMs:drupal7-ckeditor
Size:230.47 KiB

Package: drupal7-context-3.10-9.fc37
Summary: Allows contextual conditions and reactions management
RPMs:drupal7-context
Size:93.20 KiB

Package: drupal7-cs_adaptive_image-1.0-19.fc37
Summary: Client-side adaptive image
RPMs:drupal7-cs_adaptive_image
Size:21.57 KiB

Package: drupal7-ctools-1.15-9.fc37
Summary: Primarily a set of APIs and tools to improve the developer experience
RPMs:drupal7-ctools
Size:475.31 KiB

Package: drupal7-date_ical-3.9-14.fc37
Summary: Enables import/export of iCal feeds
RPMs:drupal7-date_ical
Size:65.21 KiB

Package: drupal7-entity-1.9-9.fc37
Summary: Extends the entity API to provide a unified way to deal with entities
RPMs:drupal7-entity
Size:127.34 KiB

Package: drupal7-entity_translation-1.1-8.fc37
Summary: Allows entities to be translated into different languages
RPMs:drupal7-entity_translation
Size:103.31 KiB

Package: drupal7-features-2.10-14.fc37
Summary: Provides feature management for Drupal
RPMs:drupal7-features
Size:102.15 KiB

Package: drupal7-file_entity-2.27-8.fc37
Summary: File entity (fieldable files)
RPMs:drupal7-file_entity
Size:109.34 KiB

Package: drupal7-fivestar-2.2-14.fc37
Summary: Enables fivestar ratings on content, users, etc
RPMs:drupal7-fivestar
Size:245.08 KiB

Package: drupal7-l10n_update-2.3-8.fc37
Summary: Provides automatic downloads and updates for translations
RPMs:drupal7-l10n_update
Size:94.75 KiB

Package: drupal7-lang_dropdown-2.6-11.fc37
Summary: Provides a dropdown select to switch between available languages
RPMs:drupal7-lang_dropdown
Size:40.37 KiB

Package: drupal7-link-1.7-8.fc37
Summary: Defines simple link field types
RPMs:drupal7-link
Size:59.08 KiB

Package: drupal7-metatag-1.27-7.fc37
Summary: Adds support and an API to implement meta tags
RPMs:drupal7-metatag
Size:252.02 KiB

Package: drupal7-panels-3.9-13.fc37
Summary: Allows a site administrator to create customized layouts
RPMs:drupal7-panels
Size:387.76 KiB

Package: drupal7-potx-3.0-0.14.alpha2.fc37
Summary: Translation template extractor
RPMs:drupal7-potx
Size:73.40 KiB

Package: drupal7-title-1.0-0.20.alpha9.fc37
Summary: Replaces entity legacy fields with regular fields
RPMs:drupal7-title
Size:35.48 KiB

Package: drupal7-token-1.7-13.fc37
Summary: Provides a user interface for the Token API and some missing core 
tokens
RPMs:drupal7-token
Size:49.54 KiB

Package: drupal7-views_slideshow-3.9-13.fc37
Summary: Views Slideshow can be used to create a slideshow of any content
RPMs:drupal7-views_slideshow
Size:59.06 KiB

Package: drupal7-webform-4.22-7.fc37
Summary: Enables the creation of forms and questionnaires
RPMs:drupal7-webform
Size:228.98 KiB

Package: python-hs-dbus-signature-0.07-10.fc37
Summary: Hypothesis Strategy for Generating Arbitrary DBus Signatures
RPMs:python3-hs-dbus-signature
Size:16.71 KiB


= UPGRADED PACKAGES

Schedule for Thursday's FPC Meeting (2022-11-17 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2022-11-17 17:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

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


 Links to all tickets below can be found at: 

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

= Followup Actions =

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

= New Pull Requests =

#1201 initial Ansible Collection guidelines 
https://pagure.io/packaging-committee/pull-request/1201

#1207 Ruby: update instructions for checking out excluded tests 
https://pagure.io/packaging-committee/pull-request/1207

= Followup Issues =

#topic #1159 Ban use of %configure in %prep
.fpc 1159
https://pagure.io/packaging-committee/issue/1159

#topic #1193 Clarify packaging guidelines for .NET applications 
.fpc 1193
https://pagure.io/packaging-committee/issue/1193

= Followup Pull Requests =

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

#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097

= Open Floor = 

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

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

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






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