Re: Direct to stable updates

[Demi Marie Obenour]

On 11/10/22 21:02, Gary Buhrmaster wrote:
> On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen  wrote:
>> On Thu, Nov 10, 2022 at 18:55 Neal Gompa  wrote:
>>>
>>> I sympathize greatly here. It was a pain to wire up "logout" to the
>>> "relogin" property in updateinfo (the field had been in bodhi for a
>>> decade and nobody wired it up to the appropriate rpm metadata field!).
>>> Bodhi is an unusually difficult codebase for what it does.
>>>
>>
>> From what I can tell is that every time someone says that and then tries to 
>> fix it they find about 20 reasons why the code is not complex enough for all 
>> the corner cases and “obvious” requirements that people expect of it
>>
> 
> The code is both too complex, and nowhere near complex
> enough.
> 
> I really dislike code like that.
Time for some serious refactoring?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: OpenMPI tests blocked

[Orion Poplawski]

On 11/6/22 07:31, Dominik 'Rathann' Mierzejewski wrote:

On Saturday, 05 November 2022 at 21:27, Antonio T. sagitter wrote:

Hi all.

Many OpenMPI tests in RPM packaging are blocked for unknown reason, no
output or error, just hanged until test timeout.
For example, PETSc test is blocked with this message:


Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca
btl_base_warn_component_unused 0 -n 1
/tmp/petsc-p7fo3olx/config.packages.MPI/conftest
Running Executable with threads to time it out at 120
Executing: /usr/lib64/openmpi/bin/mpiexec -n 8 --mca
btl_base_warn_component_unused 0 -n 1
/tmp/petsc-p7fo3olx/config.packages.MPI/conftest
Runaway process exceeded time limit of 120
ERROR while running executable: Could not execute
"['/usr/lib64/openmpi/bin/mpiexec -n 8 --mca btl_base_warn_component_unused
0 -n 1 /tmp/petsc-p7fo3olx/config.packages.MPI/conftest']":
Runaway process exceeded time limit of 120

Something like this happened with Sundials and Ipopt, when OpenMPI is used,
not with MPICH.

At this time, these tests in Rawhide (and ELN) cannot be executed.


I've got the same issue with elpa. OpenMPI hangs, MPICH works fine.
Let's open a bug against OpenMPI and compare notes. ;)

Regards,
Dominik


We have:

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

I've reported it upstream as well.  Hopefully they can help.

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

Re: Direct to stable updates

[Kevin Kofler via devel]

Neal Gompa wrote:
> Bodhi is an unusually difficult codebase for what it does.

IMHO, the main reason the Bodhi code is so complex is because of all the 
policy that it enforces: karma (counting), update policies (minimum 
karma/time), critical path, autopushes, gating (automatic QA), …

If we would just let Bodhi do what the maintainer asks in the common case 
(i.e., no karma, no autopushes, no gating, just two buttons "push to 
testing" and "push to stable" that the maintainer can click at any time, as 
Bodhi was initially designed), it would be a lot easier to implement those 
few special cases that are actually needed, such as freezes.

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: Direct to stable updates

[Gary Buhrmaster]

On Fri, Nov 11, 2022 at 12:52 AM Stephen Smoogen  wrote:
>
>
>
> On Thu, Nov 10, 2022 at 18:55 Neal Gompa  wrote:
>>
>> I sympathize greatly here. It was a pain to wire up "logout" to the
>> "relogin" property in updateinfo (the field had been in bodhi for a
>> decade and nobody wired it up to the appropriate rpm metadata field!).
>> Bodhi is an unusually difficult codebase for what it does.
>>
>
> From what I can tell is that every time someone says that and then tries to 
> fix it they find about 20 reasons why the code is not complex enough for all 
> the corner cases and “obvious” requirements that people expect of it
>

The code is both too complex, and nowhere near complex
enough.

I really dislike code like that.
___
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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Demi Marie Obenour]

On 11/10/22 08:59, Michael Catanzaro wrote:
> On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel 
>  wrote:
>> According to tests, this will slow down your system to 2.5%+, which is
>> unacceptable for a general purpose distribution.
> 
> Of course, without the frame pointers, profiling software is impossible 
> and performance engineers are unable to investigate performance 
> problems using Fedora. Seems kind of silly to block performance work 
> just for a 2.5% benefit
> 
> Michael

Have you considered submitting kernel patches for DWARF unwinding?  The
actual unwinding can be done in the vdso, so bugs do not crash the kernel.
That eliminates the main reason for Linus’s objection IIUC.  It does mean
that user stack unwinding needs to move from NMI context to just before
system call return, but that is a good thing anyway as it allows faulting
in stack pages if needed.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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 Thu, Nov 10, 2022 at 18:55 Neal Gompa  wrote:

> On Thu, Nov 10, 2022 at 3:49 PM Kevin Fenzi  wrote:
> >
> > On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> > > 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!
> >
>
> I sympathize greatly here. It was a pain to wire up "logout" to the
> "relogin" property in updateinfo (the field had been in bodhi for a
> decade and nobody wired it up to the appropriate rpm metadata field!).
> Bodhi is an unusually difficult codebase for what it does.
>
>
>From what I can tell is that every time someone says that and then tries to
fix it they find about 20 reasons why the code is not complex enough for
all the corner cases and “obvious” requirements that people expect of it




>
> --
> 真実はいつも一つ！/ 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, 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: Direct to stable updates

[Neal Gompa]

On Thu, Nov 10, 2022 at 3:49 PM Kevin Fenzi  wrote:
>
> On Thu, Nov 10, 2022 at 05:16:44PM +, Mattia Verga via devel wrote:
> > 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!
>

I sympathize greatly here. It was a pain to wire up "logout" to the
"relogin" property in updateinfo (the field had been in bodhi for a
decade and nobody wired it up to the appropriate rpm metadata field!).
Bodhi is an unusually difficult codebase for what it does.



-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Robbie Harwood]

Ben Cotton  writes:

> By design, ostree does not manage bootloader updates as they can not
> (yet) happen in a transactional, atomic and safe fashion.

As we've talked about before, it's not possible to make updates
transactional.  It involves, per spec and depending on processor
architecture, updating multiple files in different directories,
potentially on different filesystems entirely, one of which is fat32.

> * User will be able to easily update the bootloader on their system.
> This will let them apply Secure Boot dbx updates that block old
> bootloaders with known vulnerabilities from loading. See:
> ** https://github.com/fedora-silverblue/issue-tracker/issues/355
> ** https://bugzilla.redhat.com/show_bug.cgi?id=2127995

What's the plan to apply the outstanding security updates (shim, grub2,
and dbx push from June) to fedora silverblue 36 + 37 that aren't covered
by this change?

Be well,
--Robbie


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

FYI: mutter + wayland are broken in F36 ATM

[Marius Schwarz]

Hi,

Mutter for Gnome 42.5.3 does not work with wayland for AST and Intel 
Graphics .

ATM, it ends in a black screen.

This involves M$ Surface devices, server onboard graphics and maybe more.

Workarounds for users are switching to lightdm or downgrading to mutter 
41.9-1.


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

best regards,
Marius





___
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: New OpenColorIO 2.2.0 requires yaml-cpp 0.7.0

[Richard Shaw]

Update on progress...

I have one build failure unrelated to yaml-cpp for a package I don't
maintain, supercollider:

In file included from /usr/include/sndfile.h:6,
 from
/builddir/build/BUILD/SuperCollider-3.12.2-Source/server/plugins/DiskIO_UGens.cpp:27:
/usr/include/sndfile-64.h:356:33: error: conflicting declaration 'typedef
struct sf_private_tag SNDFILE'
  356 | typedef struct sf_private_tag   SNDFILE ;
  | ^~~
In file included from
/builddir/build/BUILD/SuperCollider-3.12.2-Source/include/plugin_interface/SC_World.h:31,
 from
/builddir/build/BUILD/SuperCollider-3.12.2-Source/include/plugin_interface/SC_PlugIn.h:23,
 from
/builddir/build/BUILD/SuperCollider-3.12.2-Source/server/plugins/DiskIO_UGens.cpp:25:
/builddir/build/BUILD/SuperCollider-3.12.2-Source/include/plugin_interface/SC_SndBuf.h:25:28:
note: previous declaration as 'typedef struct SNDFILE_tag SNDFILE'
   25 | typedef struct SNDFILE_tag SNDFILE;
  |^~~

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

And OpenColorIO 2.2.0 apparently also needs minizip-ng 3.0.6 which isn't
yet in Rawhide...

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: F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)

[Miro Hrončok]

On 10. 11. 22 21:23, Ben Cotton wrote:

The macro ''%perl_require_compat'' will evaluate the run-require based
on ''%{_target_cpu}''. The macro will be defined in the rpm
''perl-srpm-macros'' and the definition is:

`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" :
"%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}"
]`


Jitka,
have you considered making this an RPM dependency generator instead? What are 
the reasons not to use 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Direct to stable updates

[Kevin Fenzi]

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


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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Kevin Fenzi]

On Wed, Nov 09, 2022 at 04:26:23AM +, Naheem Zaffar wrote:
> On Tue, 8 Nov 2022, 19:22 Vitaly Zaitsev via devel, <
> devel@lists.fedoraproject.org> wrote:
> 
> > On 08/11/2022 19:53, Naheem Zaffar wrote:
> > > Has there been any consideration to turn on frame pointers for atleast
> > > dev releases?
> >
> >
> > Fedora has no dev releases. Mass rebuild is a huge pain for maintainers
> > due to FTBFS issues, and doing it multiple times is unacceptable.
> >
> I think I explained the idea poorly.
> 
> Not all builds in rawhide are release builds. You will get for instance the
> whole gnome stack beta releases and rc releases during development.
> 
> This isnt limited to gnome, most software will go into rawhide first to
> stabilise.
> 
> It is almost never intended for these builds to end up in the final
> release  ll, but they are useful and necessary parts of the development
> cycle. Theywill be replaced before general availability, all without a mass
> rebuild.
> 
> It's not a silver bullet solution but atleast it starts things off on a
> path where profiling can be done in a limited manner compared to the other
> proposed alternatives where the tooling doesnt exist and will likely not
> ever be written.

The problem is, there's no one size fits all here.
Different upstreams do wildly different things. 

Some have "stable" releases and "dev" releases before that. (Like gnome)
Some just mix features and bugfixes into a single stream.
Some only seem to have prereleases and take years to actually do a point
release. 

etc. 

So, asking that "dev" releases use different options I think would just
result in a bunch of confusion along with a mix of things with some
using frame pointers and some things not. 

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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 10/11/2022 14:59, Michael Catanzaro wrote:
Of course, without the frame pointers, profiling software is impossible 
and performance engineers are unable to investigate performance problems 
using Fedora.


99.999% shouldn't suffer because of 0.001%.

--
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: Help understanding Fedora CI failure wrt RPM Sequoia

[Kevin Fenzi]

On Thu, Nov 10, 2022 at 11:39:27AM +0200, Panu Matilainen wrote:
> 
> So, overnight somebody updated the koji package in
> https://kojipkgs.fedoraproject.org/repos/rawhide/ to the current unsigned
> rawhide build, which makes the issue go away.

Nothing should have updated the koji package. 

The last change was in october:

Wed Oct 26 14:08:39 2022 koji-1.30.1-2.fc38 tagged into f38 by bodhi [still 
active]

In fact there's no such actual build: 

➜  ~ koji list-history --build koji-1.28.1-1.fc38
2022-11-10 12:39:45,017 [ERROR] koji: GenericError: No such build: 
'koji-1.28.1-1.fc38'

Very odd that ci would use a build that doesn't exist. (I guess it's a
scratch build it made itself?)

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: F38 proposal: MobilityPhoshImage (Self-Contained Change proposal)

[Kevin Fenzi]

On Thu, Nov 10, 2022 at 01:35:36AM -, Scott Anecito via devel wrote:
> What is the driver for choosing Phosh over GNOME Shell?

There's no choosing something over something else. This isn't a Fedora
Mobility Edition, but rather a first look at a Phosh based setup. 

Phosh has been around a long while, the remix that the mobility sig
makes currently uses it, and it seems to be making progress all the
time. 

The plasma mobile desktop has also been around a while, but I am not
sure if it's all packaged up yet or how it fits together. The kde sig
has been working on this. If they reach a point where things are
working, they can submit a plasma-mobile change. 

If down the road we think this area should be covered by a edition, then
we would need to closely decide what would meet our users needs.

> Let me first say the amount of work put in by both Purism and the GNOME 
> community into Phosh and other mobile components like libhandy has been 
> critical to Linux mobile space. While mobile friendly GNOME Shell 
> improvements only recently started and is not currently as feature rich as 
> Phosh, the recent focus on it by the GNOME community has lead to some fast 
> and impressive development as seen on the GNOME blog: 
> https://blogs.gnome.org/shell-dev/2022/09/09/gnome-shell-on-mobile-an-update/
> 
> Most of the changes in the blog look to be targeting merging upstream in time 
> for 44's release which I believe would be in Fedora 38. Even then though 
> GNOME Shell wouldn't be at feature parity with Phosh. However, the main 
> argument long term for having a mobile image that uses GNOME Shell over Phosh 
> is more resourcing due to mutual benefits on mobile and desktop with things 
> like the new gesture API referenced in the blog.

gnome-shell's mobility changes look really interesting and I would
encourage folks interested in that to work on a gnome mobility spin?

> If feature set is the driver, I understand, but as a Librem5 owner and 
> someone with all their boxes imaged with Fedora I'd be curious if there would 
> be any plans to eventually switch to GNOME Shell once feature parity happens.

I don't know of any plans right now, but I think it's likely to happen
if things are merged and are in a workable state. :) 

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

F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

By design, ostree does not manage bootloader updates as they can not
(yet) happen in a transactional, atomic and safe fashion. Thus bootupd
(https://github.com/coreos/bootupd) was created to solve this issue
and enable admin-lead bootloader updates. This change is about
enabling bootupd integration in Fedora Silverblue and Fedora Kinoite
to make bootloader updates easier.

== Owner ==

* [[User:Siosm| Timothée Ravier]] 
* [[User:Tpopela| Tomáš Popela]] 
* [[User:Walters| Colin Walters]] 


== Detailed Description ==

Adding bootupd full bootupd support has two immediate benefits:

* User will be able to easily update the bootloader on their system.
This will let them apply Secure Boot dbx updates that block old
bootloaders with known vulnerabilities from loading. See:
** https://github.com/fedora-silverblue/issue-tracker/issues/355
** https://bugzilla.redhat.com/show_bug.cgi?id=2127995

* We can start planning for the removal of the ostree-grub2 package
from the images to solve the "all deployments are shown twice in GRUB"
issue. This bug comes from the fact that old GRUB versions that do not
have BLS support and we thus can not only rely on BLS support in
ostree to generate boot and have to also update the grub configuration
for every updates via the scripts in the ostree-grub2 package. This
has already (indirectly) caused a major upgrade issue on
Silverblue/Kinoite requiring manual interventions from all users. See:
** 
https://fedoramagazine.org/manual-action-required-to-update-fedora-silverblue-kinoite-and-iot-version-36/
** https://github.com/fedora-silverblue/issue-tracker/issues/120

Note that we can not yet enable unattended bootloader updates as even
though bootupd tries hard hard to make those updates as safe as
possible, it is currently not possible that they are safe if the
system crashes (or loses power) at the wrong time. The following
change in shim (https://github.com/rhboot/shim/pull/502) should help
with that.

Thus bootloaders updates will remain a manually user triggered
operation for now.

Also note that this change currently relies on the image being
composed via rpm-ostree in unified core, which is the subject of the
following change also proposed for Fedora 38:
https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore

== Feedback ==

None so far.



== Benefit to Fedora ==

Fedora Silverblue and Fedora Kinoite users can easily do bootloaders
updates (that includes security fixes) and we can remove support for
legacy GRUB versions thus simplify the upgrade process and making it
more reliable.


== Scope ==

* Proposal owners: Testing of the integration and new builds. The code
changes are mostly done and the integration changes are mostly already
ready as bootupd has already been integrated in a similar fashion in
Fedora CoreOS.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.

== How To Test ==

We will extend the test instructions once the unified core changes
have landed. You can follow:
https://github.com/fedora-silverblue/issue-tracker/issues/120 and
https://github.com/fedora-silverblue/issue-tracker/issues/355.

== User Experience ==

For now, users will have to update their bootloader manually via the
command line. Integration to GNOME Software and Plasma Discover might
be interesting to make that easier.

Once the fallback EFI feature is available in shim (and support
implemented in bootupd), we can consider implementing automated
updates.

== Dependencies ==

N/A

== Contingency Plan ==

* Contingency mechanism: Revert the change in the rpm-ostree
manifests. Owners will do it. Nothing to do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No

== Documentation ==

We will write docs to let users update their bootloaders manually.
They will look very similar to
https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/.

== Release Notes ==

Will have to be written.


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

F38 proposal: Build Fedora Silverblue & Kinoite using rpm-ostree unified core mode (Self-Contained Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

rpm-ostree upstream development is focusing on the "unified core" mode
and the previous mode is being deprecated. Fedora Silverblue and
Fedora Kinoite are currently building using the old mode and we've
wanted to move over for a while. The main advantage of the unified
core mode is that it is stricter and safer, while enabling some post
processing steps to happen during or after the image build.

== Owner ==

* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:Walters| Colin Walters]]
* Email: . ,



== Detailed Description ==

For more details about the difference between the two mode, you can
read the upstream issue:
https://github.com/coreos/rpm-ostree/issues/729. See also the history
in https://pagure.io/workstation-ostree-config/issue/137.

On top of the advantages listed above, we need unified core support to
be able to add bootupd integration to Fedora Silverblue & Kinoite.
See:
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
* https://github.com/fedora-silverblue/issue-tracker/issues/120
* https://pagure.io/workstation-ostree-config/pull-request/313

The in-progress changes are in:
* Support in Pungi: https://pagure.io/pungi/pull-request/1626 &
https://pagure.io/pungi/pull-request/1629
* Fedora Pungi configuration change:
https://pagure.io/pungi-fedora/pull-request/1115
* Fedora Silverblue & Kinoite changes in progress in:
https://pagure.io/workstation-ostree-config/pull-request/296

GitHub issue used to track this work and testing:
https://github.com/fedora-silverblue/issue-tracker/issues/333

== Feedback ==

None yet.



== Benefit to Fedora ==

The old mode in rpm-ostree is not maintained anymore and less tested
thus more prone to bugs. Moving to the new mode will unify Silverblue
& Kinoite to the same code that is used to build Fedora CoreOS and
that receives a lot of testing. This will remove maintenance burden on
the rpm-ostree project as they will thus be able to remove the old
code. The new mode also makes composes work the same on the server
side and the client side and makes them safer by more strictly
confining scriptlets execution.

== Scope ==

* Proposal owners: Testing of builds with the new mode to make sure
there is not regression. The infra & configurations changes for Pungi
should be ready.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

There should be not visible change for users when upgrading. The
change only impacts the way the images are composed on the server.

== How To Test ==

Use the commands from the justfile in
https://pagure.io/workstation-ostree-config/pull-request/296 to test
building in unified core mode. Update an existing installation and
verify that everything works as expected. Once we merge that in
Rawhide, updating will be enough (no need to rebuild).

== User Experience ==

N/A

== Dependencies ==

N/A

== Contingency Plan ==

* Contingency mechanism: Revert to non unified core build mode (single
change in Fedora's Pungi configuration). Owners will do it. Nothing to
do for users.
* Contingency deadline: Can happen anytime.
* Blocks release? No

== Documentation ==

N/A

== Release Notes ==

N/A


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

F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`.
When an RPM package is built, mtimes of packaged files will be clamped
to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest
`%changelog` entry. As a result, more RPM packages will be
reproducible: The actual modification time of files that are e.g.
modified in the `%prep` section or built in the `%build` section will
not be reflected in the resulting RPM packages. Files in RPM packages
will have mtimes that are independent of the time of the actual build.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]], [[User:Zbyszek|Zbigniew
Jędrzejewski-Szmek]]
* Email: mhroncok at redhat.com, zbyszek at in.waw.pl


== Detailed Description ==
This change exists to make RPM package builds more reproducible. A
common problem that prevents [https://reproducible-builds.org/ build
reproducibility] is the mtime (modification times) of the packaged
files.

Suppose we package an RPM package of software called `skynet` in
version `1.0`. Upstream released this version at datetime A. A Fedora
packager creates the RPM package at datetime B. Unfortunately, the
packager needs to patch the sources in the RPM `%prep` section. When
the build runs at datetime C, the modification datetime of the patched
file is set to C. When the build runs again in an otherwise identical
environment at datetime D, the modification datetime of the patched
file is set to D. As a result, the build is not bit-by-bit
reproducible, because the datetime of the build is saved in the
resulting package.
Patching is not necessary to make this happen. When a source file is
compiled into a binary file, the modification datetime is also set to
the datetime of the build. In practice, the modification datetime of
many files packaged in RPM packages is dependent on when the package
was actually built.

To eliminate this problem, we propose to clamp build mtimes to
`$SOURCE_DATE_EPOCH`. RPM build in Fedora already sets the
`$SOURCE_DATE_EPOCH` environment variable based on the latest
`%changelog` entry because the `%source_date_epoch_from_changelog`
macro is set to `1`. We will also set the
`%clamp_mtime_to_source_date_epoch` macro to `1`. As a result, when
files are packaged to the RPM package, their modification datetimes
will be clamped to `$SOURCE_DATE_EPOCH` (to the latest changelog entry
datetime). Clamping means that all files which would otherwise have a
modification datetime higher than `$SOURCE_DATE_EPOCH` will have the
modification datetime changed to `$SOURCE_DATE_EPOCH`; files with
mtime lower (or equal) to `$SOURCE_DATE_EPOCH` will retain the
original mtimes.

This functionality is already implemented in RPM. We will enable it by
setting `%clamp_mtime_to_source_date_epoch` to `1`.

=== Non-goal ===

We do not aim to make all Fedora packages reproducible (at least not
as part of this change proposal). We just eliminate one problem that
we consider the biggest blocker for reproducible builds.

=== Python bytecode ===

When Python bytecode cache (a `.pyc` file) is built, the mtime of the
corresponding Python source file (`.py`) is included in it for
invalidation purposes. Since the `.pyc` file is created before RPM
clamps the mtime of the `.py` file, the mtime stored in the `.pyc`
file might be higher than the corresponding mtime of the `.py` file.

With the previous example, if `skynet` is written in Python:
# `skynet.py` is modified in `%prep` and hence has mtime set to the
time of the build
# `skynet.pyc` is generated in `%install` and the mtime of `skynet.py`
is saved in it
# RPM clamps the mtime of `skynet.py`
# `skynet.pyc` is considered invalid by Python on runtime, as the
stored and actual mtime of `skynet.py` don't match

To solve this, we will modify Python to clamp the stored mtime to
`$SOURCE_DATE_EPOCH` as well (when building RPM packages). Upstream
Python chooses to invalidate bytecode cache based on hashes instead of
mtimes when `$SOURCE_DATE_EPOCH` is set, but that could cause
performance issues for big files, so Fedora's Python already deviates
from upstream behavior when building RPM packages. To avoid
accidentally breaking the behavior when
`%clamp_mtime_to_source_date_epoch` is not set to `1`, RPM macros and
buildroot policy scripts for creating the Python bytecode cache will
be modified to unset `$SOURCE_DATE_EPOCH` when
`%clamp_mtime_to_source_date_epoch` is not set to `1`.

This behavior might be proposed upstream if it turns out to be
superior to the current upstream choice, in case we
[https://discuss.python.org/t/14594 won't redesign the bytecode-source
relationship entirely] instead.

=== Opting out ===

Packages bro

F38 proposal: Perl: Replace versioned MODULE_COMPAT_ requires by macro (System-Wide Change proposal)

[Ben Cotton]

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

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

A ''perl(:MODULE_COMPAT_%(eval "`%{__perl}
-V:version`"; echo $version))'' run-time dependency will be
replaced with a new ''%perl_require_compat'' macro in all Perl spec
files.

The macro will expand differently based on architecture specificity of
the binary packages. That will significantly shrink an amount of Perl
packages required to be rebuilt with each Perl upgrade.

== Owner ==
* Name: [[User:jplesnik| Jitka Plesnikova]]
* Email: 


=== Completed items ===

=== Items in progress ===
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F38
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F37
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F36
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in F35
* Add `%perl_require_compat` macro to ''perl-srpm-macros'' in RHEL 9
* Update [[Packaging:Perl | Fedora Packaging Guidelines for Perl]]
* Replace ''perl(:MODULE_COMPAT_XXX)'' by `%perl_require_compat`
run-time in all F38 spec files (3259)

== Detailed Description ==

The list of packages that need to be rebuilt with the new major
version of Perl is determined according to the dependency on
''perl(:MODULE_COMPAT_XXX)'' now.

In Fedora, all Perl modules run-require the versioned
''perl(:MODULE_COMPAT_XXX)'' provided by ''perl-libs'' now.

However, only multi-arch packages need to have a dependency on the
particular version of Perl it was built against, or on a newer version
of Perl that provides backward compatibility with it. For those
packages, we need to ensure that the packages will use the right
version of ''libperl.so'' for the Perl used during the rebuild.

The noarch packages don't need to be rebuilt against each new major
version of Perl, they only have to require non-versioned ''perl-libs''
which includes all directories used by all Perl modules.

The macro ''%perl_require_compat'' will evaluate the run-require based
on ''%{_target_cpu}''. The macro will be defined in the rpm
''perl-srpm-macros'' and the definition is:

`%perl_require_compat %[ "%{_target_cpu}" == "noarch" ? "perl-libs" :
"%{!?perl_version:perl-libs}%{?perl_version:perl(:MODULE_COMPAT_%{perl_version})}"
]`

The macro ''%perl_requires_compat'' will evaluate to the correct
value. There is a known, yet harmless, imperfection: The macro will
evaluate to ''perl(:MODULE_COMPAT_XXX)'' even in noarch subpackages of
a multi-arch main package. In this case, I recommend to use `Requires:
%perl_require_compat`. The purpose of the change is a matter of
simplifying the rebuild, where it depends if the source package
produces at least one multi-arch binary package. Not on whether it
makes a noarch subpackage next to it.
If you don't want to see this imperfection you could use directly
`Requires: perl-libs`.

The macro will work for all supported Fedoras and EPEL 9.

For EPEL 8 and older, it won't work, because the
[https://rpm-software-management.github.io/rpm/manual/macros.html
Expression Expansion] is not implemented there. In these versions,
''perl(:MODULE_COMPAT_%(eval "`%{__perl}
-V:version`"; echo $version))'' must be used.

== Benefit to Fedora ==

It will simplify the rebuild and reduce the number of packages which
have to be rebuild from 3259 to approximately 600. It should currently
be enough to rebuild only multi-arch packages and those that are part
of the Perl itself (dual-life packages). Here we need to ensure that
the packages will use the right ''libperl.so'' for the Perl used. The
new syntax will also be shorter and clearer for packagers.

== Scope ==
* Proposal owners:
** Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
** Update and rebuild perl-srpm-macros source package.
** Add ''%perl_require_compat'' to ''perl-srpm-macros'' package in
older Fedoras.
** Replace Requires for ''perl(:MODULE_COMPAT_XXX)'' with
''%perl_require_compat'' in all spec files.

* Other developers: Get familiar with new Fedora Packaging Guidelines for Perl.

* Release engineering: No action needed.
[https://pagure.io/releng/issues #Releng issue number] 

* Policies and guidelines: N/A (not needed for this Change) 


* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives:

== Upgrade/compatibility impact ==
N/A

== How To Test ==

All multi-arch packages which use the macro should run-require
''perl(:MODULE_COMPAT_%{perl_version})'' and the ''noarch'' packages
should run-require ''perl-libs'' except the case listed in '''Detailed
Description'''.

== User Experience ==
There should not be any remarkable change in user experience.

== Dependencies ==
This change will affect 3259 source packages and all binary noarch
p

[Test-Announce] Fedora Linux 37 Final is GO

[Ben Cotton]

The Fedora Linux 37 Final RC 1.7 compose is GO and will be shipped
live on Tuesday, 15 November. For more information please check the
Go/No-Go meeting minutes[1] or log[2].

[1] 
https://meetbot.fedoraproject.org/fedora-meeting/2022-11-10/f37-final-go_no_go-meeting.2022-11-10-17.02.html
[2] 
https://meetbot.fedoraproject.org/fedora-meeting/2022-11-10/f37-final-go_no_go-meeting.2022-11-10-17.02.log.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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

Re: Direct to stable updates

[Mattia Verga via devel]

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

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: Deprecating intents in Modularity

[Petr Pisar]

V Wed, Nov 02, 2022 at 04:45:41PM +0100, Petr Pisar napsal(a):
> do you know intents
> ?
[...]
> 
> * I was told that even RHEL, from version 9, does not use system purposes and
> that it's quite possible that the interface will disappear from
> subscription-manager.
> 
A correction: A subscription experience product manager replied after sending
my original message that "System Purpose isn’t going away [... it] is used by
the subscriptions service [...] to show the user their usage." In other words,
system purposes will be kept in subscription-manger for statistical purposes.

> Summing all these facts suggests that intents in Modularity are completely
> unused and their future won't be better. Therefore I'd like to deprecate
> intents in Modularity.
> 
> What would it mean? The current YAML specification for module-defaults would
> warn that intents are deprecated. Any future tools or speciciations for
> modularity would not implement the intents.
> 
> Does anybody have a problem with deprecating intents?
> 
Thanks for your replies. I did not receive any negative feedback. Therefore
I deprecated intents in modulemd-defaults-v1 specification and in
libmodulemd API
.

-- Petr



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

gaps test failed

[Steve Dickson]

Hello,

My update [1] failed because the gaps test failed

sbin/mount.nfs: gap:  (0x5590..0x55a0 probable component: __printf_chk) 
in annobin notes.
/sbin/mount.nfs: gap:  (0x11760..0x11770 probable component: 
__printf_chk) in annobin notes.
/sbin/mount.nfs: FAIL: gaps test because gaps were detected in the 
annobin coverage


which means I can not move the update to stable.

What is a gap test and how do I fix it?

tia,

steved.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2022-e83239c44f
___
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: Heads-up: python-pytest-bdd 6.1.1 coming to Rawhide

[Scott Talbert]

On Thu, 10 Nov 2022, Ben Beasley wrote:


In one week (2022-11-17), or slightly later, I will update python-pytest-bdd
from version 5.0.0 to version 6.1.1[1] in Rawhide. This will bring
significant API-breaking changes[2] from 5.x.
The sole dependent package, jrnl, does not support version 6.x yet[3], and
the changes required are nontrivial. I will therefore maintain a
python-pytest-bdd5 compat package until jrnl is ready for 6.x. Because the
changes required to support parallel-installability would be too complex and
invasive to be practical, the compat package will explicitly conflict with
python-pytest-bdd. The impact of this conflict will be minimal since jrnl
uses pytest-bdd only as a BuildRequires for running its tests, and the
compat package will not typically be installed on user systems.

[1] https://src.fedoraproject.org/rpms/python-pytest-bdd/pull-request/2
[2] https://github.com/pytest-dev/pytest-bdd/releases/tag/6.0.0
[3] https://github.com/jrnl-org/jrnl/issues/1534


It begs the question: if the only user of python-pytest-bdd doesn't 
support the new version, then why update it?  Why not just wait until jrnl 
supports it?  Seems like it would be less work than adding a compat 
package.


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

Heads-up: python-pytest-bdd 6.1.1 coming to Rawhide

[Ben Beasley]

In one week (2022-11-17), or slightly later, I will update python-pytest-bdd 
from version 5.0.0 to version 6.1.1[1] in Rawhide. This will bring significant 
API-breaking changes[2] from 5.x.

The sole dependent package, jrnl, does not support version 6.x yet[3], and the 
changes required are nontrivial. I will therefore maintain a python-pytest-bdd5 
compat package until jrnl is ready for 6.x. Because the changes required to 
support parallel-installability would be too complex and invasive to be 
practical, the compat package will explicitly conflict with python-pytest-bdd. 
The impact of this conflict will be minimal since jrnl uses pytest-bdd only as 
a BuildRequires for running its tests, and the compat package will not 
typically be installed on user systems.

[1] https://src.fedoraproject.org/rpms/python-pytest-bdd/pull-request/2
[2] https://github.com/pytest-dev/pytest-bdd/releases/tag/6.0.0
[3] https://github.com/jrnl-org/jrnl/issues/1534___
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

[Steven A. Falco]

On 11/10/22 09:47 AM, Eike Rathke wrote:

Hi Miroslav,

On Monday, 2022-11-07 18:46:26 +0100, Miroslav Suchý wrote:


Tl;dr Please start migrating your license tag to SPDX now.


Is it ok to have SPDX tags on all currently supported release branches,
i.e. f37, f36, f35?


Yes.

Steve

___
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

[Eike Rathke]

Hi Miroslav,

On Monday, 2022-11-07 18:46:26 +0100, Miroslav Suchý wrote:

> Tl;dr Please start migrating your license tag to SPDX now.

Is it ok to have SPDX tags on all currently supported release branches,
i.e. f37, f36, f35?

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Neal Gompa]

On Thu, Nov 10, 2022 at 9:00 AM Michael Catanzaro  wrote:
>
> On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel
>  wrote:
> > According to tests, this will slow down your system to 2.5%+, which is
> > unacceptable for a general purpose distribution.
>
> Of course, without the frame pointers, profiling software is impossible
> and performance engineers are unable to investigate performance
> problems using Fedora. Seems kind of silly to block performance work
> just for a 2.5% benefit
>

It's not silly if we know we can't guarantee to get it back or make it
better after the fact.


-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Michael Catanzaro]

On Wed, Nov 9 2022 at 09:39:04 AM +0100, Vitaly Zaitsev via devel 
 wrote:

According to tests, this will slow down your system to 2.5%+, which is
unacceptable for a general purpose distribution.


Of course, without the frame pointers, profiling software is impossible 
and performance engineers are unable to investigate performance 
problems using Fedora. Seems kind of silly to block performance work 
just for a 2.5% benefit


Michael

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

Re: Heads-up: Side-tag rebuild due to minizip-ng soname bump

[Richard Shaw]

On Mon, Nov 7, 2022 at 6:41 AM Lukas Javorsky  wrote:

> Hi,
>
> Minizip-ng has changed its soname name from "libminizip.so.3.0" to
> "libminizip.so.3" thus we need to rebuild all the packages that are
> requiring this soname.
>

Are you also updating to 3.0.6? The latest version of OpenColorIO requires
that version at a minimum.

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: SPDX Change update - Missing identifier for XDebug

[Remi Collet]

Le 10/11/2022 à 13:48, Miroslav Suchý a écrit :

Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):



What is the process to ask for a new SPDX id ?


Open an issue for

https://gitlab.com/fedora/legal/fedora-license-data


Done as https://gitlab.com/fedora/legal/fedora-license-data/-/issues/95



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

Fedora rawhide compose report: 20221110.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20221109.n.0
NEW: Fedora-Rawhide-20221110.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  2
Dropped packages:1
Upgraded packages:   87
Downgraded packages: 0

Size of added packages:  68.61 KiB
Size of dropped packages:10.80 MiB
Size of upgraded packages:   12.30 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20221109.n.0.iso
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20221109.n.0.iso

= ADDED PACKAGES =
Package: rust-primal-0.3.1-3.fc38
Summary: `primal` puts raw power into prime numbers
RPMs:rust-primal+default-devel rust-primal+unstable-devel rust-primal-devel
Size:42.51 KiB

Package: rust-transpose-0.2.2-1.fc38
Summary: Utility for transposing multi-dimensional data
RPMs:rust-transpose+default-devel rust-transpose-devel
Size:26.10 KiB


= DROPPED PACKAGES =
Package: Falcon-0.9.6.8-25.fc38
Summary: The Falcon Programming Language
RPMs:Falcon Falcon-devel Falcon-doc
Size:10.80 MiB


= UPGRADED PACKAGES =
Package:  ansible-lint-1:6.8.6-1.fc38
Old package:  ansible-lint-1:6.8.3-1.fc38
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 470.56 KiB
Size change:  4.19 KiB
Changelog:
  * Thu Nov 10 2022 Parag Nemade  - 1:6.8.6-1
  - Update to 6.8.6 version (#2138333)


Package:  awscli-1.27.5-1.fc38
Old package:  awscli-1.27.4-1.fc38
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.24 MiB
Size change:  -105 B
Changelog:
  * Wed Nov 09 2022 Gwyn Ciesla  - 1.27.5-1
  - 1.27.5


Package:  certbot-1.32.0-1.fc38
Old package:  certbot-1.30.0-1.fc38
Summary:  A free, automated certificate authority client
RPMs: certbot python3-certbot
Size: 586.67 KiB
Size change:  854 B
Changelog:
  * Wed Nov 09 2022 Nick Bebout  - 1.32.0-1
  - Update to 1.32.0


Package:  cmake-3.25.0-0.6.rc4.fc38
Old package:  cmake-3.25.0-0.5.rc3.fc38
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 48.51 MiB
Size change:  -12.04 KiB
Changelog:
  * Wed Nov 09 2022 Bj??rn Esser  - 3.25.0-0.6.rc4
  - cmake-3.25.0-rc4
Fixes rhbz#2141122


Package:  dotnet6.0-6.0.110-2.fc38
Old package:  dotnet6.0-6.0.109-1.fc38
Summary:  .NET Runtime and SDK
RPMs: aspnetcore-runtime-6.0 aspnetcore-targeting-pack-6.0 dotnet 
dotnet-apphost-pack-6.0 dotnet-host dotnet-hostfxr-6.0 dotnet-runtime-6.0 
dotnet-sdk-6.0 dotnet-sdk-6.0-source-built-artifacts dotnet-targeting-pack-6.0 
dotnet-templates-6.0 netstandard-targeting-pack-2.1
Size: 6.58 GiB
Size change:  3.59 MiB
Changelog:
  * Fri Oct 28 2022 Omair Majid  - 6.0.110-1
  - Update to .NET SDK 6.0.110 and Runtime 6.0.10

  * Mon Oct 31 2022 Omair Majid  - 6.0.110-2
  - Set OPENSSL_ENABLE_SHA1_SIGNATURES=1 when building


Package:  fantasdic-1.0-0.21.beta7.fc38
Old package:  fantasdic-1.0-0.20.beta7.fc38
Summary:  Dictionary application using Ruby
RPMs: fantasdic
Size: 935.11 KiB
Size change:  1.55 KiB
Changelog:
  * Wed Nov 09 2022 Mamoru TASAKA  - 1.0-0.21.beta7
  - Use YAML.unsafe_load for psych 4.0.x
  - Some misc fixes for ruby 3.1
  - Server configuration update for DICT
  - Enable testsuite


Package:  ffmpeg-5.1.2-2.fc38
Old package:  ffmpeg-5.1.2-1.fc38
Summary:  A complete solution to record, convert and stream audio and video
RPMs: ffmpeg-free ffmpeg-free-devel libavcodec-free 
libavcodec-free-devel libavdevice-free libavdevice-free-devel libavfilter-free 
libavfilter-free-devel libavformat-free libavformat-free-devel libavutil-free 
libavutil-free-devel libpostproc-free libpostproc-free-devel libswresample-free 
libswresample-free-devel libswscale-free libswscale-free-devel
Size: 34.49 MiB
Size change:  65.96 KiB
Changelog:
  * Wed Nov 09 2022 Neal Gompa  - 5.1.2-2
  - Unconditionally enable Vulkan


Package:  flatbuffers-22.10.26-3.fc38
Old package:  flatbuffers-2.0.8-3.fc38
Summary:  Memory efficient serialization library
RPMs: flatbuffers flatbuffers-compiler flatbuffers-devel 
flatbuffers-doc python3-flatbuffers
Size: 5.13 MiB
Size change:  125.34 KiB
Changelog:
  * Sat Oct 29 2022 Benjamin A. Beasley  22.9.24-1
  - Update to 22.9.24 (.so version 2???22)

  * Sat Oct 29 2022 Benjamin A. Beasley  22.9.29-1
  - Update to 22.9.29

  * Sat Oct 29 2022 Benjamin A. Beasley  22.10.25-1
  - Update to 22.10.25

  * Sat Oct 29 2022 Benjamin A. Beasley  22.10.26-1
  - Update to 22.10.26 (close RHBZ#2130864)

  * Sat Oct 29 2022 Benjamin A. Beasley  22.10.26-2
  - Update flatc.1 man page

  * Sat Oct 29 2022

Re: SPDX Change update - Missing identifier for XDebug

[Miroslav Suchý]

Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):

I'm searching for License identifier for php-pecl-xdebug
which was "BSD"

It is based on PHP-3.0 which is based on BSD-3-Clause

What should I use ?


You are speaking about

 https://github.com/xdebug/xdebug/blob/master/LICENSE

I pasted the content to:

https://tools.spdx.org/app/check_license/

and it says that it does not match any SPDX license.


What is the process to ask for a new SPDX id ?


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.

Miroslav


___
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 37 compose report: 20221110.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20221109.n.0
NEW: Fedora-37-20221110.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: SPDX Change update - Missing identifier for XDebug

[Remi Collet]

I'm searching for License identifier for php-pecl-xdebug
which was "BSD"

It is based on PHP-3.0 which is based on BSD-3-Clause

What should I use ?
What is the process to ask for a new SPDX id ?


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

Re: SPDX Change update

[Miroslav Suchý]

Dne 09. 11. 22 v 17:00 Fabio Valentini napsal(a):

On Wed, Nov 9, 2022 at 2:52 PM Miroslav Suchý  wrote:

Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a):

What do we do if the SPDX tag is the same as the existing license
tag (eg ISC) though? Do we just add a dummy change/commit entry that
mentions SPDX to confirm we've reviewed it?

Don't bother. Eventually, we'll re-process all spec files and identify
what to do next anyway.

Actually... if you add there the dummy changelog entry, it makes my work easier.

Which data source are you using to check changelog contents?


https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-in-spec-changelog.sh

https://pagure.io/copr/license-validate/blob/main/f/print-spec-changelog.py



For packages that use rpmautospec, you'll need to check changelog
contents in the SRPM, not the unprocessed spec file.
And if you're querying changelogs from RPMs or SRPMs, adding a dummy
changelog entry also won't do anything unless a new build is done in
either case.


Yes. Because I do not open the spec file in dist-git checkout then the %changelog is empty, but next script checks 
dist-git log


https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-in-distgit-changelog.sh

which is the source for %autochangelog The result is the same at the end.


Also note that for Rust packages, conversion to SPDX has been an
ongoing process since rust2rpm made SPDX expressions the default with
version 22, and the conversion itself was usually just a side product
of updating packages to a newer version, and in these cases, the
changelog doesn't mention SPDX at all.

If you want to include Rust packages which have switched to SPDX in
your analysis, you can grep spec files for the string "# Generated by
rust2rpm 22" or "# Generated by rust2rpm 23" (since spec files
generated by rust2rpm v22+ use SPDX).


Good idea. On the other hand, even when you are using SPDX identifier it does not mean that it is approved in 
fedora-license-data.


I validated all licenses in rust-* packages and 1003 packages out of 2000 packages do not validate. The list of rust 
packages with invalid license is here:


https://pagure.io/copr/license-validate/blob/main/f/rust-notvalid.txt

I checked just few of them and it seems that they been generated by older 
rust2rpm. I will appreciate if you can check them.

Miroslav
___
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: Help understanding Fedora CI failure wrt RPM Sequoia

[Panu Matilainen]

On 11/9/22 11:12, Panu Matilainen wrote:

On 11/9/22 10:08, Panu Matilainen wrote:

On 11/8/22 21:45, Adam Williamson wrote:

On Tue, 2022-11-08 at 08:11 -0800, Adam Williamson wrote:

On Tue, 2022-11-08 at 13:32 +0200, Panu Matilainen wrote:


But I don't know the slightest thing about ansible, beyond a very 
rough

idea of what kind of tool it is. Just understanding what exactly it's
trying to do here would go a long way, I think. But either it's not in
the logs, or I don't know how to read them.


well, to expand on my previous answer, it gets a bit interesting. At
this point in the process the CI system has installed the packages to
be tested and verified that they're installed, which implies RPM does
at least basically work or else that would have failed. you can see
this in these logs:

https://artifacts.dev.testing-farm.io/700d486d-d409-44fe-b7c3-01634243558e/guest-setup-554c73be-c472-4007-9f14-23eea462c69d/artifact-installation-554c73be-c472-4007-9f14-23eea462c69d/

then it hands off to ansible to actually 'run the tests', and that's
when the error happens. I believe it happens here in ansible's code:

https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/dnf.py#L1366

so that may help you figure it out. I'd look further but I have to run
out right now...


well, I'm back now. Looking into it a bit further, I think the codepath
we're on compresses to this, where `self.base` is a DNF base object:

self.base.upgrade_all()
try:
 self.base.resolve(allow_erasing=self.allowerasing)
 [cut internal stuff that couldn't raise a DNF error]
 for package in self.base.transaction.install_set:
 fail = False
 gpgres, gpgerr = self.base._sig_check_pkg(package)
 [cut more stuff that couldn't raise the error]
 self.base.do_transaction()
except dnf.exceptions.Error as e:
 failure_response['msg'] = "Unknown Error occurred: 
{0}".format(to_native(e))

 self.module.fail_json(**failure_response)

I'm pretty sure that's the path we're on, and "An rpm exception
occurred: package not installed" is the text of a dnf.exceptions.Error
exception that's raised by one of those actions that actually involves
the DNF base object (I cut stuff that doesn't involve it, and one
branch where we'd do something different if we hit a
dnf.exceptions.Error). Next step would be to see why dnf is throwing
that error, I guess. It'd be nice if it said *what* package it thinks
is "not installed"...


Indeed. It is an exceptional situation though.

Anyway, Maxwell G's PR showed that it is indeed a weak signature 
someplace (thanks again!), and with clues learned from that I could 
debug it further on my own.


https://artifacts.dev.testing-farm.io/a1c1cc94-0f2b-41f0-a0c2-2456dd50359a/work-tests.ymllY4cuv/ansible-output.txt

and the smoking gun is here:

494 python3-koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)
495 koji-1.28.1-1.fc38.noarch (not an OpenPGP signature)

Despite the fc38 disttag, this is not the koji package from Fedora 
rawhide, the real rawhide version is koji-1.30.1-2.fc38 and *that* is 
signed with RSA/SHA256. What the heck?


Time to file a ticket someplace. Rel-eng, I suppose?


Filed https://pagure.io/fedora-ci/general/issue/371


So, overnight somebody updated the koji package in 
https://kojipkgs.fedoraproject.org/repos/rawhide/ to the current 
unsigned rawhide build, which makes the issue go away.


Thanks to whoever did that.

And now off to build the thing while the lights are green...

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

Re: SPDX Change update

[Miroslav Suchý]

Dne 09. 11. 22 v 15:05 Gary Buhrmaster napsal(a):

Does it make sense for your script in some future
iteration to add in the capability to check if the
license is identical pre/post SPDX if the spec does
not have a changelog or commit message mentioning
SPDX?  Either hard code the cases (not ideal?), or
run license-fedora2spdx and compare the results?
That (I think) would handle the ISC example.


I hesitate to assume that if license tag changed, that the new one is the SPDX. 
Because the licenses change anyway.

I will rather enhance it with check

  license-validate --old

  license-validate --new

and if the first one fail, and the second one succeed then I will assume it is 
converted.

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

Wayland support on Blender coming to Fedora

[Luya Tshimbalanga]

Hello everyone, 
Upstream Blender developers are on the way to bring Wayland support for the 
next release [1] which will benefit Fedora users running on Workstation edition.
The Fedora version already has support on Rawhide [2] since 3.3.0 noticeable 
with a different window decoration which use libdecor library. Wearing 
maintainer hat, I am planning to bring to  Fedora 37
as an update so test is much needed to insure the stability of Wayland support.

The build is available on 
https://copr.fedorainfracloud.org/coprs/g/design-suite/blender-3d/build/5030047/
 to try it out. Alernatively, try 3.4.0 on upstream daily build on 
https://builder.blender.org/download/daily/


Reference:
---
[1] https://code.blender.org/2022/10/wayland-support-on-linux/
[2] 
https://src.fedoraproject.org/rpms/blender/c/917ed85d61e564dfda426234c1d1007a69486f5e?branch=rawhide

Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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