Re: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

On 28/06/2023 23:39, Kalev Lember wrote:
Why? Now that you've already done all the work of adding the 
compatibility package, why drop it and break all of the unbuilt packages 
in rawhide? I don't think any of the packages from the list are release 
blocking, but it just seems antisocial for rawhide users to break 
packages they might be using, especially if it's no extra work for you 
at this point.


At least one maintainer emailed me that they want to use fmt9-devel 
instead of fixing FTBFS. Sorry, but I can't allow that.


Another possible solution - rebuild fmt9 without -devel subpackage to 
prevent its usage for building new packages.



Another thing that comes in my mind is that there is the ongoing python rebuild 
in f39-python and your rebuilt package set probably intersects with it.


Yes. All packages with Python bindings (dnf5 for example).


Would be good to let Miro know what packages they need to rebuild again once 
your fmt tag is merged.


Another reason to untag it is to make sure all packages are built 
against fmt 10.


Also FTI RHBZ tickets will be generated automatically.

--
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Neal Gompa]

On Thu, Jun 29, 2023 at 1:06 AM Simon de Vlieger  wrote:
>
> On 6/28/23 22:32, Neal Gompa wrote:
> > On Wed, Jun 28, 2023 at 4:26 PM Simon de Vlieger  wrote:
> >>
> >> On 6/28/23 21:12, Adam Williamson wrote:
> >>
> >>> The current Workstation live has the package exclusions from fedora-
> >>> workstation-common.ks in it:
> >>>
> >>> https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks
> >>>
> >>> so it excludes three groups that are part of the 'standard' for live
> >>> images but which Workstation doesn't want to include, and it excludes
> >>> two packages that usually get pulled in as part of the installer
> >>> environment. The reiserfs-utils exclusion could actually be dropped as
> >>> we dropped reiserfs-utils from comps long ago, but the gfs2-utils
> >>> exclusion is still 'active'.
> >>
> >> Thanks, yes I saw this when I ran ksflatten on it to come up with the
> >> package set that was needed for the live installer that can be built by
> >> osbuild-composer at this moment.
> >>
> >>> There is a bit of "defining base Fedora" - that's what fedora-live-
> >>> base.ks does - but there is other stuff too. One very prevalent pattern
> >>> is that we share a lot of stuff between live image and disk image
> >>> definitions. So for e.g. for Workstation, we have these chains:
> >>>
> >>> fedora-live-workstation.ks inherits from fedora-live-base.ks and
> >>> fedora-workstation-common.ks
> >>> fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora-
> >>> disk-xbase.ks and fedora-workstation-common.ks
> >>>
> >>> so things that are 'basic' to each particular type of image are shared,
> >>> but also things that are 'basic' to each edition or spin are shared, so
> >>> we're not doing them twice between the lives and the disk images.
> >>>
> >>> Then we have things like labs/spins that are based on desktop
> >>> spins/editions, but extend them. For e.g., the Design Suite lab is
> >>> based on Workstation, so it inherits from fedora-live-workstation.ks .
> >>> Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE
> >>> kickstarts.
> >>>
> >>> There's also a 'minimization' pattern where several kickstarts inherit
> >>> from fedora-live-minimization.ks , which does/did some shared
> >>> minimization stuff. I kinda disliked that pattern and I've managed to
> >>> pare that file down to just `-hplip` now, but that's still there as I
> >>> haven't managed to shift it.
> >>>
> >>> So, there's a lot going on with the inheritance stuff. :D It definitely
> >>> needs to be evaluated at least. You can just do `grep include *.ks` in
> >>> the fedora-kickstarts repo to get a feel for everything.
> >>
> >> Thanks for that write up, I'm going to go spelunking in this repository
> >> and come up with a plan on how to support an approach like this to
> >> define editions/spins in blueprints so there's no wall in front of us
> >> for future building of those images as well.
> >>
> >> I can see it hopefully becoming *easier* to define spins, editions, and
> >> remixes of Fedora in the future.
> >>
> >
> > Comparatively, the Fedora Asahi Remix is defined using KIWI
> > descriptions using composition and inheritance of profiles and config
> > snippets.
> >
> > Top level file:
> > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/config.xml
> >
> > Desktop environment fragment:
> > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/desktop-environments.xml
> > Common packages:
> > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/base.xml
> > Boot packages: 
> > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/boot.xml
> > Workstation platform:
> > https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/platforms/workstation.xml
> >
> > I would say personally that not being able to do this is a blocker for
> > adopting osbuild-composer blueprints.
>
> Thank you Neal. Is there a reason why Fedora Asahi does not use the
> kickstart system? If so it'd be nice if we can support that use case as
> well in osbuild-composer :)
>
> I'll take the kiwi example files (and the kickstarts) in mind to work on
> a direction for blueprints to take to support these usecases.
>

I wouldn't subject my worst enemies to Oz and ImageFactory (which is
what we use for Cloud images). And since Lorax (which is what we use
for live and ARM images) requires Anaconda to understand the target
system to install, it couldn't be used for creating these images
either because that requires teaching Anaconda about Apple Silicon
Macs. And reintroducing appliance-tools for Fedora images might make
some people upset. :)

As for why kiwi? I understand it quite well, and the kiwi team has
been extremely receptive to community needs above and beyond virtually
any other team I've worked with ever. I became a member of that team a
few years ago too. And there is Koji integration for kiwi, which means
that it can be (eventually) integrat

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Simon de Vlieger]

On 6/28/23 22:32, Neal Gompa wrote:

On Wed, Jun 28, 2023 at 4:26 PM Simon de Vlieger  wrote:


On 6/28/23 21:12, Adam Williamson wrote:


The current Workstation live has the package exclusions from fedora-
workstation-common.ks in it:

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks

so it excludes three groups that are part of the 'standard' for live
images but which Workstation doesn't want to include, and it excludes
two packages that usually get pulled in as part of the installer
environment. The reiserfs-utils exclusion could actually be dropped as
we dropped reiserfs-utils from comps long ago, but the gfs2-utils
exclusion is still 'active'.


Thanks, yes I saw this when I ran ksflatten on it to come up with the
package set that was needed for the live installer that can be built by
osbuild-composer at this moment.


There is a bit of "defining base Fedora" - that's what fedora-live-
base.ks does - but there is other stuff too. One very prevalent pattern
is that we share a lot of stuff between live image and disk image
definitions. So for e.g. for Workstation, we have these chains:

fedora-live-workstation.ks inherits from fedora-live-base.ks and
fedora-workstation-common.ks
fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora-
disk-xbase.ks and fedora-workstation-common.ks

so things that are 'basic' to each particular type of image are shared,
but also things that are 'basic' to each edition or spin are shared, so
we're not doing them twice between the lives and the disk images.

Then we have things like labs/spins that are based on desktop
spins/editions, but extend them. For e.g., the Design Suite lab is
based on Workstation, so it inherits from fedora-live-workstation.ks .
Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE
kickstarts.

There's also a 'minimization' pattern where several kickstarts inherit
from fedora-live-minimization.ks , which does/did some shared
minimization stuff. I kinda disliked that pattern and I've managed to
pare that file down to just `-hplip` now, but that's still there as I
haven't managed to shift it.

So, there's a lot going on with the inheritance stuff. :D It definitely
needs to be evaluated at least. You can just do `grep include *.ks` in
the fedora-kickstarts repo to get a feel for everything.


Thanks for that write up, I'm going to go spelunking in this repository
and come up with a plan on how to support an approach like this to
define editions/spins in blueprints so there's no wall in front of us
for future building of those images as well.

I can see it hopefully becoming *easier* to define spins, editions, and
remixes of Fedora in the future.



Comparatively, the Fedora Asahi Remix is defined using KIWI
descriptions using composition and inheritance of profiles and config
snippets.

Top level file:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/config.xml

Desktop environment fragment:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/desktop-environments.xml
Common packages:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/base.xml
Boot packages: 
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/boot.xml
Workstation platform:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/platforms/workstation.xml

I would say personally that not being able to do this is a blocker for
adopting osbuild-composer blueprints.


Thank you Neal. Is there a reason why Fedora Asahi does not use the 
kickstart system? If so it'd be nice if we can support that use case as 
well in osbuild-composer :)


I'll take the kiwi example files (and the kickstarts) in mind to work on 
a direction for blueprints to take to support these usecases.


Regards,

Simon
___
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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miro Hrončok]

On 29. 06. 23 0:31, Carlos O'Donell wrote:

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

Yes, but see the rest of my email.

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

[Test-Announce] Fedora 39 Rawhide 20230628.n.2 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20230624.n.0: anaconda-39.20-1.fc39.src, 20230628.n.2: 
anaconda-39.22-1.fc39.src

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

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_39_Rawhide_20230628.n.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_39_Rawhide_20230628.n.2_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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Michael Catanzaro]

On Thu, Jun 29 2023 at 12:24:23 AM +0200, Fabio Valentini 
 wrote:
Thanks for the clarification, though this is only partially 
reassuring:

I'm not sure how this accounts for the fact that there are some
situations in which weak dependencies are *not installed at all*.
Most notably, they are not installed into build environments *at all*
(i.e. mock sets `install_weak_deps=0`).


I guess this is OK. It's not what I would have expected, but if 
something important winds up missing, it just means you need more 
BuildRequires and is generally not a big deal.



I'm not sure how the process that builds ISOs and container images
handle this, but I assume they set this option as well.
So we'd need to be careful not to remove "hard" dependencies on tzdata
and replace them with lots of "weak" dependencies all over the place -
just to find out that it ends up missing from important places because
they disable weak dependencies.


For Recommends/Supplements weak dependencies to be useful, packagers 
must be able to assume they are installed by default. With that 
assumption, you can stop second-guessing when to use weak deps; without 
that assumption, nothing works and the weak deps are not useful.  
Accordingly, most ISOs, container images, etc. should be built with 
weak dependencies enabled; it would be a serious bug if weak deps were 
missing from the Fedora Workstation images, for example. Opting out of 
weak deps should be done with the understanding that there will be 
degraded functionality and some features will not work. E.g. minimal 
images will want to be really minimal and not install the weak deps, 
even though this means missing timezones.


Because Recommends and Supplements are installed by default, we need to 
be careful and use them sparingly, only when it really makes sense for 
some package to be pulled in for almost all users of another package. 
Thus far, Fedora and RHEL have done a good job of this, primarily 
because we were very late to the weak dep party and have had much more 
time to learn best practices and much less time to screw up. This is in 
contrast to some other distros where it's common for users to disable 
weak deps to avoid "bloat." We don't ever want our 
Recommends/Supplements to be considered bloat. (That's what 
Suggests/Enhances is for. :) And since they're not bloat, they should 
be respected when building most non-minimal images.


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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/28/23 18:24, Fabio Valentini wrote:
> On Thu, Jun 29, 2023 at 12:15 AM Carlos O'Donell 
> wrote:
>> 
>> On 6/26/23 16:12, Fabio Valentini wrote:
>>> So all this considered, I'm not sure whether this change is
>>> actually worth it, if tzdata databases of some form will likely
>>> be pulled into installs anyway.
>> 
>> Quoting the "Weak Dependencies Policy":
>> 
>> "Weak dependencies allow smaller minimal installations while
>> keeping the default installation feature rich."
>> 
>> The change is worth it for minimizing container runtimes based on
>> Fedora.
>> 
>> Just for clarity, a default install will always have tzdata.
>> 
>>> I'd rather have *one* tzdata that's up-to-date and used by
>>> everything (for example, so Python and Ruby programs can actually
>>> agree what time it is).
>> I agree strongly with this statement.
>> 
>> I have worked with Patsy over the years to remove as many bundled
>> copies of out-of-date tzdata as we can find :-)
>> 
>> It is important for consistency that all language runtimes have the
>> same concept of time.
>> 
>> This change request does not change that.
> 
> Thanks for the clarification, though this is only partially
> reassuring: I'm not sure how this accounts for the fact that there
> are some situations in which weak dependencies are *not installed at
> all*. Most notably, they are not installed into build environments
> *at all* (i.e. mock sets `install_weak_deps=0`).

Yes, this is a general issue with all weak dependencies.

This is similar to the "minimal buildroot" conversation, whose conclusion was
that we should not dictate what should be in the minimal buildroot but have
the packages express the dependencies as required for their build and check
phases.

See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#buildrequires
~~~
You MAY assume that enough of an environment exists for RPM to function, 
to build packages and execute basic shell scripts, but you SHOULD NOT 
assume any other packages are present as RPM dependencies and anything
brought into the buildroot by the build system can change over time.
~~~
https://pagure.io/packaging-committee/issue/497

We have two options:

- glibc-devel 'Requires: tzdata' (close to the current behaviour)
- All packages that neeed tzdata in rpm %check tests add 'BuildRequires: tzdata'

If a testsuite runs in %check and needs tzdata it seems to me that it is 
valuable
to express this as 'BuildRequires: tzdata'. Therefore I lean towards the latter
solution of having packages that truly need tzdata for testing all of their
code to 'BuildRequires: tzdata', but only if actually required.
 
> I'm not sure how the process that builds ISOs and container images 
> handle this, but I assume they set this option as well. So we'd need
> to be careful not to remove "hard" dependencies on tzdata and replace
> them with lots of "weak" dependencies all over the place - just to
> find out that it ends up missing from important places because they
> disable weak dependencies.

Building ISOs and container images must install Recommends: by default otherwise
the Weak Dependency Policy would not work in Fedora.

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 14:14, Peter Robinson wrote:
> On Mon, Jun 26, 2023 at 7:10 PM Miro Hrončok  wrote:
>> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
>> says:
>>
>>
>> """
>> Python distributors are encouraged to ensure that time zone data is installed
> 
> The wording of "encouraged to ensure" doesn't sound like a hard
> requirement to me based on a lot of specs I've dealt with, but it
> depends a bit on how the specific spec defines "encouraged".
> 
>> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
>> for the python package).
>> """
>>
>> from https://peps.python.org/pep-0615/#system-time-zone-information
>>
>>
>> By changing the Requires to Recommends, we would diverge from upstream
>> recommendation.

I agree with Peter. The "Recommends:" will ensure tzdata is installed by 
default.

This work lines up exactly with the Fedora Weak Dependencies Policy:
"Weak dependencies allow smaller minimal installations while keeping the default
 installation feature rich."

Can we allow users to create a minimal installation by hand, while still 
complying
with PEP-615 for default installs?

The size savings for a minimal container that is UTC-only would be quite 
valuable
for Fedora minimal containers.

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Fabio Valentini]

On Thu, Jun 29, 2023 at 12:15 AM Carlos O'Donell  wrote:
>
> On 6/26/23 16:12, Fabio Valentini wrote:
> > So all this considered, I'm not sure whether this change is actually
> > worth it, if tzdata databases of some form will likely be pulled into
> > installs anyway.
>
> Quoting the "Weak Dependencies Policy":
>
> "Weak dependencies allow smaller minimal installations while keeping the 
> default
>  installation feature rich."
>
> The change is worth it for minimizing container runtimes based on Fedora.
>
> Just for clarity, a default install will always have tzdata.
>
> > I'd rather have *one* tzdata that's up-to-date and used by everything
> > (for example, so Python and Ruby programs can actually agree what time
> > it is).
> I agree strongly with this statement.
>
> I have worked with Patsy over the years to remove as many bundled copies of 
> out-of-date
> tzdata as we can find :-)
>
> It is important for consistency that all language runtimes have the same 
> concept of time.
>
> This change request does not change that.

Thanks for the clarification, though this is only partially reassuring:
I'm not sure how this accounts for the fact that there are some
situations in which weak dependencies are *not installed at all*.
Most notably, they are not installed into build environments *at all*
(i.e. mock sets `install_weak_deps=0`).

I'm not sure how the process that builds ISOs and container images
handle this, but I assume they set this option as well.
So we'd need to be careful not to remove "hard" dependencies on tzdata
and replace them with lots of "weak" dependencies all over the place -
just to find out that it ends up missing from important places because
they disable weak dependencies.

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 14:40, Vít Ondruch wrote:
> Yep, this is the case for rubygem-tzinfo. It would deserve recommends
> at minimum, because in theory, the tzdata can be suplied by
> tzinfo-data gem instead.

Thank you for adding the `Recommends: tzdata`!

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/26/23 16:12, Fabio Valentini wrote:
> So all this considered, I'm not sure whether this change is actually
> worth it, if tzdata databases of some form will likely be pulled into
> installs anyway.

Quoting the "Weak Dependencies Policy":

"Weak dependencies allow smaller minimal installations while keeping the 
default 
 installation feature rich."

The change is worth it for minimizing container runtimes based on Fedora.

Just for clarity, a default install will always have tzdata.

> I'd rather have *one* tzdata that's up-to-date and used by everything
> (for example, so Python and Ruby programs can actually agree what time
> it is).
I agree strongly with this statement.

I have worked with Patsy over the years to remove as many bundled copies of 
out-of-date
tzdata as we can find :-)

It is important for consistency that all language runtimes have the same 
concept of time.

This change request does not change that.

With a weak dependency on tzdata the default installs will still have it, but 
someone
making a specifically UTC-only container should be able to remove it.

Python, and other language runtimes should be capable of getting to a point 
where they
operate correctly with only C.UTF-8 (no language packs) and UTC (no tzdata).

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/27/23 05:38, Jiri Vanek wrote:
> JDK will behave similarly. We ave (small) advantage that we have also
> in-jdk-bundled tzdata.  However fallback in case of removed system
> tzdata is not automatic, and requires human touch. Long ago we have a
> patch in jdk which looked to system tzdata - if they were present,
> they were used.  If not, the bundled copy was used.  Also user could
> set up on startup which to use. But it had not prooved itself, as it
> was casue of weird missonfigurations.

Please note that we are only talking about tzdata, not tzdata-java.

We do not intend to allow the removal of tzdata-java because OpenJDK depends 
upon it.

When you say "in-jdk-bundled tzdata" do you mean something other than 
tzdata-java?

> If this proposal will come live, we may introduce this patch again, or
> leave it as it is now - on human touch.

Could you please expand a bit more on this topic?

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

Re: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Carlos O'Donell]

On 6/28/23 03:44, Miroslav Lichvar wrote:
> On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote:
>> * Other developers: Some packages need to change their spec files from
>> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
>> all packages switched in this way, but it is not required. Supporting
>> optional tzdata installation for as many workloads as possible allows
>> those workloads to minimize their container image size.
>> List of packages which need to be changed:
>> * glibc (glibc-common)
> 
> There are packages that rely on the glibc->glibc-common->tzdata
> dependency. The one I know is chrony, which in the default
> configuration needs the "right/UTC" timezone to get the TAI-UTC
> offset. I suspect there are other packages that will need to add
> Recommends or Requires.
 
Thanks, filed against chrony to fix that.

chrony: Uses right/UTC and needs Requires: tzdata
https://bugzilla.redhat.com/show_bug.cgi?id=2218368

My opinion is that this all part of the work required to make the distribution
more flexible for deploying as the basis for containerized workloads.

If you know of any other such missing dependencies we should file bugs and
get them fixed.

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

Re: Announcing fmt library soversion bump

[Kalev Lember]

On Wed, Jun 28, 2023 at 8:03 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> FTBFS:
>
> 0ad
> arbor
> CuraEngine
> bout++
> cachelib
> dolphin-emu
> folly
> freeopcua
> gerbera
> luxcorerender
> mangohud
> wasmedge
> watchman
>

I fixed 0ad from that list and built it in the side tag.


> I think I will merge this side tag without fmt9 compatibility package
> tomorrow.
>

Why? Now that you've already done all the work of adding the compatibility
package, why drop it and break all of the unbuilt packages in rawhide? I
don't think any of the packages from the list are release blocking, but it
just seems antisocial for rawhide users to break packages they might be
using, especially if it's no extra work for you at this point.

Another thing that comes in my mind is that there is the ongoing python
rebuild in f39-python and your rebuilt package set probably intersects with
it. Would be good to let Miro know what packages they need to rebuild again
once your fmt tag is merged.

-- 
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Neal Gompa]

On Wed, Jun 28, 2023 at 4:26 PM Simon de Vlieger  wrote:
>
> On 6/28/23 21:12, Adam Williamson wrote:
>
> > The current Workstation live has the package exclusions from fedora-
> > workstation-common.ks in it:
> >
> > https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks
> >
> > so it excludes three groups that are part of the 'standard' for live
> > images but which Workstation doesn't want to include, and it excludes
> > two packages that usually get pulled in as part of the installer
> > environment. The reiserfs-utils exclusion could actually be dropped as
> > we dropped reiserfs-utils from comps long ago, but the gfs2-utils
> > exclusion is still 'active'.
>
> Thanks, yes I saw this when I ran ksflatten on it to come up with the
> package set that was needed for the live installer that can be built by
> osbuild-composer at this moment.
>
> > There is a bit of "defining base Fedora" - that's what fedora-live-
> > base.ks does - but there is other stuff too. One very prevalent pattern
> > is that we share a lot of stuff between live image and disk image
> > definitions. So for e.g. for Workstation, we have these chains:
> >
> > fedora-live-workstation.ks inherits from fedora-live-base.ks and
> > fedora-workstation-common.ks
> > fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora-
> > disk-xbase.ks and fedora-workstation-common.ks
> >
> > so things that are 'basic' to each particular type of image are shared,
> > but also things that are 'basic' to each edition or spin are shared, so
> > we're not doing them twice between the lives and the disk images.
> >
> > Then we have things like labs/spins that are based on desktop
> > spins/editions, but extend them. For e.g., the Design Suite lab is
> > based on Workstation, so it inherits from fedora-live-workstation.ks .
> > Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE
> > kickstarts.
> >
> > There's also a 'minimization' pattern where several kickstarts inherit
> > from fedora-live-minimization.ks , which does/did some shared
> > minimization stuff. I kinda disliked that pattern and I've managed to
> > pare that file down to just `-hplip` now, but that's still there as I
> > haven't managed to shift it.
> >
> > So, there's a lot going on with the inheritance stuff. :D It definitely
> > needs to be evaluated at least. You can just do `grep include *.ks` in
> > the fedora-kickstarts repo to get a feel for everything.
>
> Thanks for that write up, I'm going to go spelunking in this repository
> and come up with a plan on how to support an approach like this to
> define editions/spins in blueprints so there's no wall in front of us
> for future building of those images as well.
>
> I can see it hopefully becoming *easier* to define spins, editions, and
> remixes of Fedora in the future.
>

Comparatively, the Fedora Asahi Remix is defined using KIWI
descriptions using composition and inheritance of profiles and config
snippets.

Top level file:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/config.xml

Desktop environment fragment:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/desktop-environments.xml
Common packages:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/base.xml
Boot packages: 
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/components/boot.xml
Workstation platform:
https://pagure.io/fedora-asahi/kiwi-descriptions/blob/rawhide/f/platforms/workstation.xml

I would say personally that not being able to do this is a blocker for
adopting osbuild-composer blueprints.


-- 
真実はいつも一つ！/ 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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Simon de Vlieger]

On 6/28/23 21:12, Adam Williamson wrote:


The current Workstation live has the package exclusions from fedora-
workstation-common.ks in it:

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks

so it excludes three groups that are part of the 'standard' for live
images but which Workstation doesn't want to include, and it excludes
two packages that usually get pulled in as part of the installer
environment. The reiserfs-utils exclusion could actually be dropped as
we dropped reiserfs-utils from comps long ago, but the gfs2-utils
exclusion is still 'active'.


Thanks, yes I saw this when I ran ksflatten on it to come up with the 
package set that was needed for the live installer that can be built by 
osbuild-composer at this moment.



There is a bit of "defining base Fedora" - that's what fedora-live-
base.ks does - but there is other stuff too. One very prevalent pattern
is that we share a lot of stuff between live image and disk image
definitions. So for e.g. for Workstation, we have these chains:

fedora-live-workstation.ks inherits from fedora-live-base.ks and
fedora-workstation-common.ks
fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora-
disk-xbase.ks and fedora-workstation-common.ks

so things that are 'basic' to each particular type of image are shared,
but also things that are 'basic' to each edition or spin are shared, so
we're not doing them twice between the lives and the disk images.

Then we have things like labs/spins that are based on desktop
spins/editions, but extend them. For e.g., the Design Suite lab is
based on Workstation, so it inherits from fedora-live-workstation.ks .
Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE
kickstarts.

There's also a 'minimization' pattern where several kickstarts inherit
from fedora-live-minimization.ks , which does/did some shared
minimization stuff. I kinda disliked that pattern and I've managed to
pare that file down to just `-hplip` now, but that's still there as I
haven't managed to shift it.

So, there's a lot going on with the inheritance stuff. :D It definitely
needs to be evaluated at least. You can just do `grep include *.ks` in
the fedora-kickstarts repo to get a feel for everything.


Thanks for that write up, I'm going to go spelunking in this repository 
and come up with a plan on how to support an approach like this to 
define editions/spins in blueprints so there's no wall in front of us 
for future building of those images as well.


I can see it hopefully becoming *easier* to define spins, editions, and 
remixes of Fedora in the future.


Regards,

Simon

___
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

[Tom Stellard]

On 6/26/23 09:21, Aoife Moloney wrote:

https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)

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

This is the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. JDKs in fedora are already static, and we repack portable
tarballs into RPMs. Currently, the portable tarball is built for each
Fedora and EPEL version. Goal here is to build each JDK
(8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
all live Fedoras. If jdk is buitl in epel, it will be built in oldest
possible epel  and repacked in newer live epels.


== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]

* Email: jva...@redhat.com


== Detailed Description ==

As described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
during last year, packaging of JDKs had changed dramatically. As
described in the same wiki page and in individual sub changes and
devel threads, the primary reason for this is to lower maintenance and
still keep Fedora Java friendly.

* In the first system wide change, we have changed the JDKs to build
properly as standalone, portable JDK - the way JDK is supposed to be
built. I repeat, we spent ten years by patching JDK to become properly
dynamic against system libs, and all patches went upstream, but this
has become a fight which can not be won.

* As a second step we introduced portable RPMs, which do not have any
system integration, only build JDK and pack the final tarball in RPM
for Fedora use.

* In third step - without any noise, just verified with fesco -
https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
integrated RPMs. Instead of this, normal RPMs BUildRequire portable
RPMs and just unpack it, and repack it.

Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
oldest live Fedora, and repack everywhere. java-latest-openjdk, which
contains latests STS JDK - currently 20, soon briefly 21 and a bit
after 22... If we would built java-latest-openjdk in  oldest live EPEL
- epel8 now, we have verified, that such repacked JDKs works fine,
however repack from epel seem to not be acceptable, thus
ajva-latest-openjdk will be built twice - one in oldest live fedora,
and once in oldest live epel. Build forme oldest possible epel will be
repacked to that one or newer epels, and build from oldest live fedroa
to all fedoras.

=== theoretical tagging solution ===

   1. request side tags for all releases
   2. build the actual Java in the side tag for the oldest thing


Could you use the real package name here.  I think that will make it easier
to understand.  You can still put 'actual Java' in parens or something.


   3. tag the result ot (2) to all side tags from (1)
   4. waitrepo them
   5. build the repacked java packages in all the side tags from (1)


Same thing here, can you use the real package name.


   6. untag the result of (2) from all the side tags from (1)
   7. ship bodhi updates from side tags OR retag the builds to candidate tags
  (and delete the side tags)

The build from (2) will be eventually garbage collected. To prevent that, it
might be re-tagged regularly. This is where releng might be able to help by
creating a long lived tag to tag this into for preserving.

Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough.



I think this process could be improved if the side-tags in 1. are permanent 
side-tags,
and step 6 is skipped.  That would make it easier to rebuild the packages from
step 5 if needed.

Also, can you put a config file in the dist-git repos to tell fedpkg which 
target
to build against?  I thought I remembered seeing that feature in the past.  If 
so,
then you could configure the dist-gits for the repacked javas to automatically 
build
from those side-tags, which I think would be a lot easier for package 
maintainers and
may help make automated rebuilds possible.

-Tom




 including portable srpms in release (improving of step 6) 

To include portable  rpms in all live Fedoras is currently not
possible. Best solution would be simply make and bodhi update of one
portable rpm to all live fedoras. Bodhi is currenlty not capable to do
so, issue was raised:
https://github.com/fedora-infra/bodhi/issues/5387 investigating
possibility to deliver single build as update to several releases.

"..It's not possible ATM, it would require a heavy rewrite of the
code, starting from the database structure (every build is now related
to a single release)..." Maybe on long run..."

On long run, if bodhi will allow this, that will be way to go.
On short run, there are following options:
  a) ask releng to tag the portables directly
 

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 18:44 +0200, Simon de Vlieger wrote:
> 
> What I would like to know is what is the minimum customizations needed 
> in blueprints for this change proposal and what is necessary for 
> supporting editions and spins down the line.

Thanks, Simon. So, we obviously don't need layering/inheritance
*implemented* to build a single live image. I'm not saying we do, just
that we need a plan to address the need that is currently addressed by
kickstart inheritance.

The current Workstation live has the package exclusions from fedora-
workstation-common.ks in it:

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-workstation-common.ks

so it excludes three groups that are part of the 'standard' for live
images but which Workstation doesn't want to include, and it excludes
two packages that usually get pulled in as part of the installer
environment. The reiserfs-utils exclusion could actually be dropped as
we dropped reiserfs-utils from comps long ago, but the gfs2-utils
exclusion is still 'active'.
> 
> The second one is likely harder but seems to be based very much on 
> 'thats how we do it now'. Personally I'd prefer having base fedora 
> defined in code and each edition/spin being a small blueprint that only 
> adds onto that base Fedora. That way spins would be less affected by 
> changes in inherited kickstarts/blueprints.
> 
> I'll dive into the kickstart repository to see what exactly is being 
> done but it's likely that a lot of what happens in kickstarts currently 
> already happens in code in osbuild-composer (e.g. adjustments to 
> bootloaders/partitions/extra packages to install based on the output 
> image type and architecture).

It's not really, or not entirely, about either of those. Ensuring all
bootloader packages is present is really handled by comps - they are in
the anaconda-tools group, and we always pull that into live images
(it's in fedora-live-base.ks ).

There is a bit of "defining base Fedora" - that's what fedora-live-
base.ks does - but there is other stuff too. One very prevalent pattern
is that we share a lot of stuff between live image and disk image
definitions. So for e.g. for Workstation, we have these chains:

fedora-live-workstation.ks inherits from fedora-live-base.ks and
fedora-workstation-common.ks
fedora-disk-workstation.ks inherits from fedora-disk-base.ks, fedora-
disk-xbase.ks and fedora-workstation-common.ks

so things that are 'basic' to each particular type of image are shared,
but also things that are 'basic' to each edition or spin are shared, so
we're not doing them twice between the lives and the disk images. 

Then we have things like labs/spins that are based on desktop
spins/editions, but extend them. For e.g., the Design Suite lab is
based on Workstation, so it inherits from fedora-live-workstation.ks .
Astronomy_KDE and Scientific_KDE, obviously, inherit from the KDE
kickstarts.

There's also a 'minimization' pattern where several kickstarts inherit
from fedora-live-minimization.ks , which does/did some shared
minimization stuff. I kinda disliked that pattern and I've managed to
pare that file down to just `-hplip` now, but that's still there as I
haven't managed to shift it.

So, there's a lot going on with the inheritance stuff. :D It definitely
needs to be evaluated at least. You can just do `grep include *.ks` in
the fedora-kickstarts repo to get a feel for everything.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Fedora CoreOS Meeting Minutes 2023-06-28

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_coreos_meeting.2023-06-28-16.29.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_coreos_meeting.2023-06-28-16.29.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-06-28/fedora_coreos_meeting.2023-06-28-16.29.log.html


#fedora-meeting-1: fedora_coreos_meeting



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



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

* Action items from last meeting  (dustymabe, 16:33:28)
  * there were no action items from last meeting  (dustymabe, 16:33:35)
  * please review
https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault
and provide feedback for travier and ravanelli   (dustymabe,
16:36:00)

* F39 Change: No default fedora-repos-modular [Consideration]
  (dustymabe, 16:37:26)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1513
(dustymabe, 16:37:43)
  * AGREED: We will communicate the removal of modular repos from Fedora
CoreOS in F39 and give users steps to resolve the problems on the
systems. If users are running `next` or `testing` streams they will
also notice updates not coming in before there `stable` systems stop
receiving updates.  (dustymabe, 16:56:56)

* Adding an LVM devices file by default  (dustymabe, 16:57:17)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1517
(dustymabe, 16:57:21)
  * LINK: https://github.com/coreos/ignition/issues/739   (travier,
17:10:20)
  * AGREED: we will ship an empty lvmdevices file for new installs and
also add a migration script for existing systems that will populate
an lvmdevices file with appropriate content so that existing systems
using LVM will continue to work.  (dustymabe, 17:19:23)

* tracker: Fedora 39 changes considerations  (dustymabe, 17:19:59)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1491
(dustymabe, 17:20:04)

* open floor  (dustymabe, 17:31:14)

Meeting ended at 17:38:38 UTC.




Action Items






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




People Present (lines said)
---
* dustymabe (126)
* travier (43)
* zodbot (18)
* spresti (16)
* ravanelli (12)
* quentin9696[m] (9)
* jdoss (4)
* apiaseck (4)
* gshomo (2)
* marmijo[m] (2)
* Guidon (2)
* mnguyen_ (2)




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: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

FTBFS:

0ad
arbor
CuraEngine
bout++
cachelib
dolphin-emu
folly
freeopcua
gerbera
luxcorerender
mangohud
wasmedge
watchman

I think I will merge this side tag without fmt9 compatibility package 
tomorrow.


--
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: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum

[Demi Marie Obenour]

On 6/26/23 12:21, Aoife Moloney wrote:
> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)
> 
> 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 ==
> 
> This is the last step in
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> effort. JDKs in fedora are already static, and we repack portable
> tarballs into RPMs. Currently, the portable tarball is built for each
> Fedora and EPEL version. Goal here is to build each JDK
> (8,11,17,21,latest (20)) only once, in oldest live Fedora repack in
> all live Fedoras. If jdk is buitl in epel, it will be built in oldest
> possible epel  and repacked in newer live epels.
> 
> 
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> 
> * Email: jva...@redhat.com
> 
> 
> == Detailed Description ==
> 
> As described in
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> during last year, packaging of JDKs had changed dramatically. As
> described in the same wiki page and in individual sub changes and
> devel threads, the primary reason for this is to lower maintenance and
> still keep Fedora Java friendly.
> 
> * In the first system wide change, we have changed the JDKs to build
> properly as standalone, portable JDK - the way JDK is supposed to be
> built. I repeat, we spent ten years by patching JDK to become properly
> dynamic against system libs, and all patches went upstream, but this
> has become a fight which can not be won.
> 
> * As a second step we introduced portable RPMs, which do not have any
> system integration, only build JDK and pack the final tarball in RPM
> for Fedora use.
> 
> * In third step - without any noise, just verified with fesco -
> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> integrated RPMs. Instead of this, normal RPMs BUildRequire portable
> RPMs and just unpack it, and repack it.
> 
> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> contains latests STS JDK - currently 20, soon briefly 21 and a bit
> after 22... If we would built java-latest-openjdk in  oldest live EPEL
> - epel8 now, we have verified, that such repacked JDKs works fine,
> however repack from epel seem to not be acceptable, thus
> ajva-latest-openjdk will be built twice - one in oldest live fedora,
> and once in oldest live epel. Build forme oldest possible epel will be
> repacked to that one or newer epels, and build from oldest live fedroa
> to all fedoras.
> 
> === theoretical tagging solution ===
> 
>   1. request side tags for all releases
>   2. build the actual Java in the side tag for the oldest thing
>   3. tag the result ot (2) to all side tags from (1)
>   4. waitrepo them
>   5. build the repacked java packages in all the side tags from (1)
>   6. untag the result of (2) from all the side tags from (1)
>   7. ship bodhi updates from side tags OR retag the builds to candidate tags
>  (and delete the side tags)
> 
> The build from (2) will be eventually garbage collected. To prevent that, it
> might be re-tagged regularly. This is where releng might be able to help by
> creating a long lived tag to tag this into for preserving.
> 
> Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
> would be easy enough.
> 
> 
>  including portable srpms in release (improving of step 6) 
> 
> To include portable  rpms in all live Fedoras is currently not
> possible. Best solution would be simply make and bodhi update of one
> portable rpm to all live fedoras. Bodhi is currenlty not capable to do
> so, issue was raised:
> https://github.com/fedora-infra/bodhi/issues/5387 investigating
> possibility to deliver single build as update to several releases.
> 
> "..It's not possible ATM, it would require a heavy rewrite of the
> code, starting from the database structure (every build is now related
> to a single release)..." Maybe on long run..."
> 
> On long run, if bodhi will allow this, that will be way to go.
> On short run, there are following options:
>  a) ask releng to tag the portables directly
>- this needs manual approach of rare humans, thus no go unless
> strictly enforced by unpredicted conditions
>- this walks around whole testing repos. For portables tarballs, as
> nothing should depend on them, and are tested indirectly after repack,
> this should be technically ok, but is heavily discouraged in
> principle.
>  b) build portable for all OSes, but do not ship them (don't do bodhi update)
>- this would probably work for all frontiers, only the real
> repacked JDK will be different
>- pros is, that we will be sure that portables builds on live fedoras
>- cons is, tha

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Michael Catanzaro]

On Wed, Jun 28 2023 at 07:06:13 PM +0200, Jiří Konečný 
 wrote:
However, I'm not sure how you can start Orca on the Workstation Live 
environment. Would be great to find that out from someone who knows 
GNOME more than me.


Should be: Alt+Super+S

___
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: Broken link

[Kevin Fenzi]

On Sat, Jun 24, 2023 at 01:41:48PM -0700, Kevin Fenzi wrote:
> 
> I mailed the admin listed for that site... hopefully they can correct
> their mirror and/or mirrormanager to fix it up. 
> 
> I marked it inactive in the mean time... they can reacitivate it when
> it's fixed. 

Just to circle back: They have fixed it and re-enabled. 

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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiří Konečný]

Hi, thanks for this question.

We tested the accessibility and so far looks good. The benefit of this solution 
is that we based on PatternFly components which takes care of accessibility for 
us. For showing Web UI we are going to use Firefox so that should be also fine.

However, I'm not sure how you can start Orca on the Workstation Live 
environment. Would be great to find that out from someone who knows GNOME more 
than me.

Also, side benefit of this should be that this new installer UI can work as 
Wayland app but that needs to be verified.
 
Best Regards,
Jirka

28. června 2023 18:49:23 SELČ, matthew dyer  
napsal:
>Hi,
>
>I am not a developer, I do rely on accessibility such as orca.  I think the 
>last time I tested it, the image booted but there seems to be know way to get 
>orca speaking so could not test accessibility of installing.  I am guessing 
>this is being taking into account?  As it stands now, if an orca user wants to 
>install fedora workstation, you have to switch to org session rather than 
>Wayland to get the current installer to work.  This is just my thoughts of a 
>general fedora user.  Fear mate works fine however.
>
>Matthew
>
>
>
>> On Jun 27, 2023, at 7:11 PM, Jonathan Steffan  
>> wrote:
>> 
>> On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney > > wrote:
>>> == Summary ==
>>> The new PatternFly-based UI has been developed by the Anaconda team
>>> for some time now and we would like to make it available for users of
>>> Fedora to enhance and modernize installation experience. As the first
>>> step in this user adoption process, we are targeting Fedora
>>> Workstation only.
>> 
>> I was pleasantly surprised with the progress here based on the test image I 
>> randomly stumbled upon this year. It's a big change from the familiar and 
>> should be treated as such.
>> 
>> Does it make more sense to focus efforts on releasing an official 
>> alternative Workstation install ISO? Generally, when you make people feel 
>> like they are forced to change it's more likely to cause frustration. We 
>> could make this more a celebration, a special access/preview to what is 
>> next, and attract testers on https://fedoraproject.org/workstation/ with 
>> some simple messaging. Completely understood that this would add yet another 
>> QA target and that might be more burdensome than it's worth. 
>> 
>> If changing the default install experience is the main goal, we should start 
>> producing install media as soon as possible and promote it through the F38 
>> cycle. Maybe as part of the respin process in F38. The more comfortable 
>> everyone is with this change, before the F39 release day, the more likely 
>> this change will be well received.
>>  
>> -- 
>> Jonathan Steffan
>> jonathanstef...@gmail.com 
>> ___
>> 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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Jiří Konečný]

Adam Williamson  napsal:
>On Wed, 2023-06-28 at 18:21 +0200, Jiří Konečný wrote:
>> > 
>> > I think the points discussed in the ticket (layering/inheritance, and
>> > package removals) are critical and they need an answer to be figured
>> > out *before* we start switching Fedora live images to be built with a
>> > different tool. I don't see how it can be good for Fedora if we have
>> > *some* live images built with livemedia-creator and *some* live images
>> > built with Image Builder - but if we start converting images without
>> > figuring out what to do about layering and package exclusions, that's
>> > exactly what we risk.
>> 
>> Honestly, I would rather like having exactly that. Image Builder slowly 
>> taking over the image builds.
>
>Slowly taking over is fine. But there needs to be a clear path to
>slowly taking over. If we have already spotted a wall built across that
>path, our response cannot be "eh, we'll keep driving along and deal
>with the wall when it's a bit closer". We need, at minimum, a Wall
>Removal Plan. :D
>
>>  If you do that at once you can break more and have less time for 
>> improvements.
>> Even now, livemedia-creator used to build Live is not the same workflow as 
>> boot.iso builds by Lorax (even when it is the same codebase).
>
>Indeed. This is part of the bitter past experience which is informing
>my posts in this thread!
>
>(Although, of course, building a live image is just a different thing
>from building an installer image.)
>> 
>> I would be surprised (maybe I'll be :D) if there is no solution for merging 
>> TOML files. In case of kickstart we had to reinvent the wheel because 
>> Kickstart is a new format. With TOML you have benefit of existing ecosystem.
>
>"Kickstart is a new format"? Kickstart is at least 11 years older than
>TOML, though probably much more (with a quick search, the earliest
>definite reference to kickstart that I can find dates to Red Hat Linux
>8.0, released in 2002; TOML's first release was in 2013, per
>Wikipedia).

Sorry, I wanted to write 'was' instead of 'is'. I meant that Kickstart was 
invented for Anaconda and used only there. Noone adopted this format outside of 
Anaconda. My reaction wasn't about how old but more about it is a single 
purpose format. That means, the tooling was created by just a small group of 
people who care about Anaconda. As I'm aware of, all the tooling for Kickstart 
was created by single team.
This is not the case for TOML format.

Jirka
___
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: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[matthew dyer]

Hi,

I am not a developer, I do rely on accessibility such as orca.  I think the 
last time I tested it, the image booted but there seems to be know way to get 
orca speaking so could not test accessibility of installing.  I am guessing 
this is being taking into account?  As it stands now, if an orca user wants to 
install fedora workstation, you have to switch to org session rather than 
Wayland to get the current installer to work.  This is just my thoughts of a 
general fedora user.  Fear mate works fine however.

Matthew



> On Jun 27, 2023, at 7:11 PM, Jonathan Steffan  
> wrote:
> 
> On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney  > wrote:
>> == Summary ==
>> The new PatternFly-based UI has been developed by the Anaconda team
>> for some time now and we would like to make it available for users of
>> Fedora to enhance and modernize installation experience. As the first
>> step in this user adoption process, we are targeting Fedora
>> Workstation only.
> 
> I was pleasantly surprised with the progress here based on the test image I 
> randomly stumbled upon this year. It's a big change from the familiar and 
> should be treated as such.
> 
> Does it make more sense to focus efforts on releasing an official alternative 
> Workstation install ISO? Generally, when you make people feel like they are 
> forced to change it's more likely to cause frustration. We could make this 
> more a celebration, a special access/preview to what is next, and attract 
> testers on https://fedoraproject.org/workstation/ with some simple messaging. 
> Completely understood that this would add yet another QA target and that 
> might be more burdensome than it's worth. 
> 
> If changing the default install experience is the main goal, we should start 
> producing install media as soon as possible and promote it through the F38 
> cycle. Maybe as part of the respin process in F38. The more comfortable 
> everyone is with this change, before the F39 release day, the more likely 
> this change will be well received.
>  
> -- 
> Jonathan Steffan
> jonathanstef...@gmail.com 
> ___
> 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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Simon de Vlieger]

On 6/28/23 17:06, Adam Williamson wrote:

On Wed, 2023-06-28 at 13:01 +0200, Ondřej Budai wrote:

I already answered you here:
https://pagure.io/fedora-workstation/issue/384#comment-862709

TL;DR: Let's figure this out when we are migrating other artifacts. For
now, the blueprint will be empty/minimal.


Thanks a lot for engaging with the feedback. However, I'm not convinced
by that answer, and I would prefer to follow up here; I suspect
feedback to an issue in the workstation tracker might well not be
captured in the Change process.

I think the points discussed in the ticket (layering/inheritance, and
package removals) are critical and they need an answer to be figured
out *before* we start switching Fedora live images to be built with a
different tool. I don't see how it can be good for Fedora if we have
*some* live images built with livemedia-creator and *some* live images
built with Image Builder - but if we start converting images without
figuring out what to do about layering and package exclusions, that's
exactly what we risk.

We do really kinda need inheritance to maintain the live image
definitions sensibly. (Also, a related point Neal didn't mention: we
share some elements of configuration between the live images and the
aarch64 disk images, since both are defined by kickstarts in the
fedora-kickstarts repo.) And we really need package exclusions to keep
some images to a sensible size.

We don't necessarily need these things to be completely implemented in
order to switch Workstation over, I don't think, but I think we should
at least have a *plan* for them. And ideally a timeframe.


Hey Adam (and Neal),

The good news is that the above *can* be done with `osbuild-composer`. 
The bad news is that you can't do it in a blueprint.


Generally we have defined distributions in code, and all of the above 
including sharing, exclusions, inheritance, can be done in those 
definitions in code.


We are in the process of splitting those definitions out of our main 
repository so pull requests and adjustments to those definitions are 
easier and involve less knowledge of the project.


With that out of the way, I would much prefer if all of the above would 
be achievable in blueprints.


What I would like to know is what is the minimum customizations needed 
in blueprints for this change proposal and what is necessary for 
supporting editions and spins down the line.


Taking from a bit further in the thread as well I currently have the 
following list of attention items for *this* change proposal:


- sensible debug logs in koji

And for followup work to support spins, editions, other image formats:

- package exclusions in blueprints
- blueprint inheritance

Of those the first one clashes a bit with the principles of making it 
hard(er) to break your image that osbuild-composer wants to follow but I 
personally see no issue with handing people that footgun.


The second one is likely harder but seems to be based very much on 
'thats how we do it now'. Personally I'd prefer having base fedora 
defined in code and each edition/spin being a small blueprint that only 
adds onto that base Fedora. That way spins would be less affected by 
changes in inherited kickstarts/blueprints.


I'll dive into the kickstart repository to see what exactly is being 
done but it's likely that a lot of what happens in kickstarts currently 
already happens in code in osbuild-composer (e.g. adjustments to 
bootloaders/partitions/extra packages to install based on the output 
image type and architecture).


Regards,

Simon
___
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 18:21 +0200, Jiří Konečný wrote:
> > 
> > I think the points discussed in the ticket (layering/inheritance, and
> > package removals) are critical and they need an answer to be figured
> > out *before* we start switching Fedora live images to be built with a
> > different tool. I don't see how it can be good for Fedora if we have
> > *some* live images built with livemedia-creator and *some* live images
> > built with Image Builder - but if we start converting images without
> > figuring out what to do about layering and package exclusions, that's
> > exactly what we risk.
> 
> Honestly, I would rather like having exactly that. Image Builder slowly 
> taking over the image builds.

Slowly taking over is fine. But there needs to be a clear path to
slowly taking over. If we have already spotted a wall built across that
path, our response cannot be "eh, we'll keep driving along and deal
with the wall when it's a bit closer". We need, at minimum, a Wall
Removal Plan. :D

>  If you do that at once you can break more and have less time for 
> improvements.
> Even now, livemedia-creator used to build Live is not the same workflow as 
> boot.iso builds by Lorax (even when it is the same codebase).

Indeed. This is part of the bitter past experience which is informing
my posts in this thread!

(Although, of course, building a live image is just a different thing
from building an installer image.)
> 
> I would be surprised (maybe I'll be :D) if there is no solution for merging 
> TOML files. In case of kickstart we had to reinvent the wheel because 
> Kickstart is a new format. With TOML you have benefit of existing ecosystem.

"Kickstart is a new format"? Kickstart is at least 11 years older than
TOML, though probably much more (with a quick search, the earliest
definite reference to kickstart that I can find dates to Red Hat Linux
8.0, released in 2002; TOML's first release was in 2013, per
Wikipedia).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: List of long term FTBFS packages to be retired in August

[Miro Hrončok]

On 28. 06. 23 15:33, Hans de Goede wrote:

Hi,

On 6/28/23 09:43, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 39 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 5 weeks, i.e. around 2023-08-01.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 36.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.


So it seems that pretty much all of java is scheduled to go away,


It is not scheduled to go away. It is marked as impacted whent he deps go away.


or at least
have its deps taken away because of:

javapackages-filesystem
javapackages-tools (also through its jpackage-utils alias / Provides)
javapackages-local


This will merely start FTBFS when xmvn-connector-ivy will be retired.


Which all are build from the same javapackages SRPM being FTBFS for a long time 
now.


No?


Does anyone know what is going on here ?


I think so. javapackages-tools BuidlRequires xmvn-connector-ivy.


Can we please exempt the javapackages srpm from being retired
until we have sorted things out?


They will not be retired based on this policy, only xmvn-connector-ivy will be 
retired.



That will remove a ton of deps from the list of affected packages.


To remove the packages from the list, somebody would need to manually hack the 
script or the output. Or javapackages-tools could stop BRing 
xmvn-connector-ivy. Or xmvn-connector-ivy could be fixed. Or retired sooner.


--
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: Towards enabling rpm sysusers integration

[Steve Grubb]

On Wednesday, June 28, 2023 10:15:48 AM EDT Lennart Poettering wrote:
> On Di, 27.06.23 12:04, Panu Matilainen (pmati...@redhat.com) wrote:
> > On 6/22/23 19:55, Steve Grubb wrote:
> > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
> > > 
> > > I would caution against this whole proposal. Not that I'm against it,
> > > but just saying be careful doing it. People often forget about our
> > > security concerns. Currently, shadow-utils has about 400 places which
> > > generate audit events during the managing of system and user accounts.
> > > libuser (I saw the deprecation email) has 55 places where it sends
> > > audit events managing accounts.
> > > 
> > > There is a 10 year old (or more) standard published here:
> > > https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Accou
> > > nt-Lifecycle-Events
> > > 
> > > If %pre getent, useradd, and groupadd  are being replaced by something,
> > > that something needs to conform to the expected security safeguards
> > > that currently exist. It needs to match the kind of events and the
> > > format that currently exists.
> > 
> > Looking at the systemd-sysusers source [1], it seems to do exactly zero
> > audit logging. So there's a bit of work to do on that front...
> 
> last time I looked auditd is started later than
> systemd-sysusers. Hence not sure if sysusers would actually generate
> audit messages that auditd could pick them up.

When booted with audit=1, the kernel will look to audit_backlog_limit and 
hold that many event records until auditd can download them. The typical 
number people set is 8192.

-Steve

> In general though: people who care about audit need to send us patches
> for this, if this matters to them. I don't think anyone in systemd
> upstream wil work on this on their own.



___
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: Announcing fmt library soversion bump

[Mamoru TASAKA]

Richard Shaw wrote on 2023/06/28 23:40:

On Wed, Jun 28, 2023 at 6:37 AM Richard Shaw  wrote:


On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:


Results: 37 builds succeeded, 19 failed.

gnuradio



Issue filed upstream:
https://github.com/gnuradio/gnuradio/issues/6735



I'm currently at work but if a proven packager wants to try the solution
proposed in the above that would be helpful.

Thanks,
Richard



Fixed (build ongoing)
https://koji.fedoraproject.org/koji/buildinfo?buildID=2223120

So with fmt10, it seems fmt::format no longer accepts (unscoped) enum by
default, just casting into int fixes the issue.

dolphin-emu can perhaps be fixed similarly, ref:
https://github.com/dolphin-emu/dolphin/commit/cc5640245cf4316f9bafcb11141d8868881ddffb
If someone can apply the above change, I will appreciate it (because
now I want to take a rest)

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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Jiří Konečný]

Hi all,

Adam Williamson  napsal:
>On Wed, 2023-06-28 at 13:01 +0200, Ondřej Budai wrote:
>> I already answered you here:
>> https://pagure.io/fedora-workstation/issue/384#comment-862709
>> 
>> TL;DR: Let's figure this out when we are migrating other artifacts. For
>> now, the blueprint will be empty/minimal.
>
>Thanks a lot for engaging with the feedback. However, I'm not convinced
>by that answer, and I would prefer to follow up here; I suspect
>feedback to an issue in the workstation tracker might well not be
>captured in the Change process.
>
>I think the points discussed in the ticket (layering/inheritance, and
>package removals) are critical and they need an answer to be figured
>out *before* we start switching Fedora live images to be built with a
>different tool. I don't see how it can be good for Fedora if we have
>*some* live images built with livemedia-creator and *some* live images
>built with Image Builder - but if we start converting images without
>figuring out what to do about layering and package exclusions, that's
>exactly what we risk.

Honestly, I would rather like having exactly that. Image Builder slowly taking 
over the image builds. If you do that at once you can break more and have less 
time for improvements.
Even now, livemedia-creator used to build Live is not the same workflow as 
boot.iso builds by Lorax (even when it is the same codebase).

It's basically the same approach with Anaconda, replace just one for now to 
improve things based on feedback.

>
>We do really kinda need inheritance to maintain the live image
>definitions sensibly. (Also, a related point Neal didn't mention: we
>share some elements of configuration between the live images and the
>aarch64 disk images, since both are defined by kickstarts in the
>fedora-kickstarts repo.) And we really need package exclusions to keep
>some images to a sensible size.

I would be surprised (maybe I'll be :D) if there is no solution for merging 
TOML files. In case of kickstart we had to reinvent the wheel because Kickstart 
is a new format. With TOML you have benefit of existing ecosystem.

Best Regards,
Jirka
___
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 13:01 +0200, Ondřej Budai wrote:
> I already answered you here:
> https://pagure.io/fedora-workstation/issue/384#comment-862709
> 
> TL;DR: Let's figure this out when we are migrating other artifacts. For
> now, the blueprint will be empty/minimal.

Thanks a lot for engaging with the feedback. However, I'm not convinced
by that answer, and I would prefer to follow up here; I suspect
feedback to an issue in the workstation tracker might well not be
captured in the Change process.

I think the points discussed in the ticket (layering/inheritance, and
package removals) are critical and they need an answer to be figured
out *before* we start switching Fedora live images to be built with a
different tool. I don't see how it can be good for Fedora if we have
*some* live images built with livemedia-creator and *some* live images
built with Image Builder - but if we start converting images without
figuring out what to do about layering and package exclusions, that's
exactly what we risk.

We do really kinda need inheritance to maintain the live image
definitions sensibly. (Also, a related point Neal didn't mention: we
share some elements of configuration between the live images and the
aarch64 disk images, since both are defined by kickstarts in the
fedora-kickstarts repo.) And we really need package exclusions to keep
some images to a sensible size.

We don't necessarily need these things to be completely implemented in
order to switch Workstation over, I don't think, but I think we should
at least have a *plan* for them. And ideally a timeframe.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 13:23 +0200, Ondřej Budai wrote:
> We can definitely flatten the JSON output into something that resembles a
> log file. I will let you know when this is done.
> 
> Note that every task also produces a manifest file - this is extremely
> useful, because you can just feed it to osbuild locally. Since the manifest
> basically fully specifies an image build (with locked package versions
> including their hashes), there's a high chance that you will be just able
> to reproduce the issue locally and use any tools you want for deeper
> debugging. This is one of the goals of the project: Make image builds more
> reproducible.

Unless the tool can pull older builds directly from Koji, I don't see
how this will work for more than a day or so. It's a cool capability,
but it seems to hinge on older builds being available, which they kinda
aren't very easily.

Reproducibility is awesome, but it doesn't replace good debug output.
For a start, you still need the useful output to debug the problem when
you reproduce it. And second, I assume building a live image is still
gonna take a significant amount of time, like 30 minutes? Typically, we
can debug a simple live image failure in about thirty seconds ("oh,
look at anaconda.log, it failed because of a broken dependency" is the
most common scenario) and probably fix it in less time than it would
take to reproduce the build.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 12:58 +0200, Ondřej Budai wrote:
> Hi Adam and Ben!
> 
> On Mon, Jun 26, 2023 at 10:14 PM Adam Williamson 
> wrote:
> 
> > 
> > 
> > In terms of testing: we already test the existing toolchain pretty
> > effectively in practice. openQA builds Workstation and KDE live images
> > with every relevant critical path update. If an update breaks live
> > image creation, we find out about it right away, and the update is
> > gated.
> > 
> 
> Can you elaborate the testing setup more? Does openQA somehow call
> livemedia-creator locally, or does it just offload the task to koji? If the
> latter is true, that this shouldn't be an issue. The former option is more
> tricky, we would have to somehow adjust openQA to use a different tool.

It mimics what Koji does:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/main/f/tests/_live_build.pm

If this Change goes through, I will change the openQA test
appropriately.

> > 
> > In terms of file formats: is toml really that much better known or
> > better than kickstart, for an audience of Fedora devs, for the purpose
> > of building a live image? Especially now we (finally) got the livesys
> > stuff out of the kickstarts and they're mostly pretty simple? As a
> > specific nitpick, the documentation on the Image Builder format makes
> > it clear that it supports comps groups, but it's less clear if it
> > supports comps *environment* groups. It really needs to do so to
> > maintain parity with livemedia-creator; we don't want to have to define
> > all the environment groups twice (once in comps, once in imagebuilder
> > TOML files). If it does support this, it should be made clear in the
> > docs.
> > 
> 
> Yes, it does support environment groups.
> 
> Regarding kickstarts vs. blueprint (TOML): From my point of view,
> kickstarts are a specific thing to the "Fedora ecosystem", whereas TOML is
> widely used also in other areas (Go/Rust), thus there is a bigger ecosystem
> of tooling for it. I would also like to introduce JSONSchema (conversion
> between JSON and TOML is mostly lossless) for blueprints, which would allow
> e.g. linting of blueprints. Yet another step in making the tooling more
> user-friendly. Anyway, I don't want to spend much time on this, it feels
> like this is more a matter of taste.

I agree it's a matter of taste, but that was kinda my point: switching
from ks to toml is advertised as a "benefit" of the Change, but to me
it feels like a very small one if it is one at all. (we do have a
checker for kickstart files, ksvalidator, btw). It's part of the
overall point that this Change doesn't really seem to constitute a huge
improvement, therefore it should be set a high bar for not introducing
any *disadvantages* compared to the previous approach.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Adam Williamson]

On Wed, 2023-06-28 at 04:23 -0600, Jonathan Steffan wrote:
> On Wed, Jun 28, 2023 at 12:52 AM Adam Williamson 
> wrote:
> 
> > On Tue, 2023-06-27 at 17:59 -0600, Jonathan Steffan wrote:
> > > The Koji integration leaves many things to be desired. I've had to dig
> > far
> > > more than needed for osbuildimage stuff.
> > 
> [...]
> 
> > > Maybe I'm just using it wrong, but I've not found a different way.
> > 
> > For compose debugging I don't think this part would be terrible in
> > practice, most of the time.
> > 
> > https://pagure.io/releng/failed-composes/issues
> 
> 
> I'm glad there is something better than what I'd found. I'm not
> necessarily trying to debug composes, just find them and use/test them as
> needed. If something like this continued after changing to osbuildimage
> tasks, that would work.

composetracker works at a level where the nature of the task doesn't
exactly matter - it works off pungi metadata, I believe. So it should
still collect failed osbuildimage tasks, as long as they're part of a
compose. The source for composetracker is at
https://pagure.io/releng/compose-tracker , if you want to see how it
works.

failed-compose tickets are a good way to find *failed* attempts to
build deliverables. If you want to find *successful* ones, my
fedora_nightlies is quite popular -
https://openqa.fedoraproject.org/nightlies.html . That, again, works
off Pungi metadata, so it will find anything that looks like an 'image'
in the mainline Fedora composes (for Rawhide and for Branched, when
Branched exists).

> >  Personally I don't usually have
> > much call for downloading the actual artifact from Koji - I'd usually
> > get it from the compose - but maybe you have a workflow where it's
> > important?
> > 
> 
> I've regularly used the images produced at
> https://koji.fedoraproject.org/koji/builds?type=image&order=-build_id for
> doing live system testing for package updates and other changes where I
> don't have a local install already available. It's really nice to have
> these artifacts so easily understandable and accessible. Maybe my workflow
> is off, but having such artifacts available has been super useful.

Unless I'm missing something, the nightlies page above should help you.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: Announcing fmt library soversion bump

[Richard Shaw]

On Wed, Jun 28, 2023 at 6:37 AM Richard Shaw  wrote:

> On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Results: 37 builds succeeded, 19 failed.
>>
>> gnuradio
>>
>
> Issue filed upstream:
> https://github.com/gnuradio/gnuradio/issues/6735
>

I'm currently at work but if a proven packager wants to try the solution
proposed in the above that would be helpful.

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: Announcing fmt library soversion bump

[Felix Wang]

> FTBFS:
> contour-terminal

Applying the related upstream commit as the patch, the rebuild succeeded.

Ref: https://koji.fedoraproject.org/koji/taskinfo?taskID=102707247
___
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: Towards enabling rpm sysusers integration

[Lennart Poettering]

On Di, 27.06.23 12:04, Panu Matilainen (pmati...@redhat.com) wrote:

> On 6/22/23 19:55, Steve Grubb wrote:
>
> > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format
> >
> > I would caution against this whole proposal. Not that I'm against it, but
> > just saying be careful doing it. People often forget about our security
> > concerns. Currently, shadow-utils has about 400 places which generate audit
> > events during the managing of system and user accounts. libuser (I saw the
> > deprecation email) has 55 places where it sends audit events managing
> > accounts.
> >
> > There is a 10 year old (or more) standard published here:
> > https://github.com/linux-audit/audit-documentation/wiki/SPEC-User-Account-Lifecycle-Events
> >
> > If %pre getent, useradd, and groupadd  are being replaced by something, that
> > something needs to conform to the expected security safeguards that 
> > currently
> > exist. It needs to match the kind of events and the format that currently
> > exists.
>
> Looking at the systemd-sysusers source [1], it seems to do exactly zero
> audit logging. So there's a bit of work to do on that front...

last time I looked auditd is started later than
systemd-sysusers. Hence not sure if sysusers would actually generate
audit messages that auditd could pick them up.

In general though: people who care about audit need to send us patches
for this, if this matters to them. I don't think anyone in systemd
upstream wil work on this on their own.

Lennart

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

Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_

[Richard W.M. Jones]

On Thu, Jun 22, 2023 at 12:24:04PM -0500, Jeremy Linton wrote:
> But, IMHO the largest change is moving the boot kernel/initrd to the
> ESP, rather than the use of systemd-boot itself. Given the
> filesystem layout remains the same outside of those two items and
> the BLS entries, all the common tools (dracut/etc) seem to be able
> to deal with it, and random other packages not manipulating
> kernel/initrd images are behavior should not be affected anymore
> than putting reFind/whatever in the boot path.

This change is likely to affect supermin, libguestfs, guestfs-tools &
virt-v2v, some BZs would be appreciated.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

On 28/06/2023 15:00, Aleksei Bavshin wrote:
Known regression in fmt. Please, apply 
https://github.com/fmtlib/fmt/pull/3430.


Thanks for the information. The fix has been ported to fmt-10.0.0-2.fc39.

waybar is now fixed.

--
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: Announcing fmt library soversion bump

[Artur Frenszek-Iwicki]

> FTBFS:
> easyrpg-player

Upstream has already updated the program to work with fmt10,
so I just applied the relevant commit to the Fedora package.

Submitted and rebuilt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102705429

A.FI.
___
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: Announcing fmt library soversion bump

[Aleksei Bavshin]

On 6/28/23 04:10, Vitaly Zaitsev via devel wrote:

Results: 37 builds succeeded, 19 failed.

FTBFS:

waybar


Known regression in fmt. Please, apply 
https://github.com/fmtlib/fmt/pull/3430.


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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Neal Gompa]

On Wed, Jun 28, 2023 at 8:25 AM Ondřej Budai  wrote:
>
>
> On Wed, Jun 28, 2023 at 2:20 PM Jonathan Steffan  
> wrote:
>>
>> On Wed, Jun 28, 2023 at 5:23 AM Ondřej Budai  wrote:
>
> > Maybe I'm just using it wrong, but I've not found a different way.
>>>
>>>
>>> I will take a look. The difference between livemedia and osbuildImage is 
>>> that the osbuildImage task is defined by a plugin and it interacts with 
>>> koji via the content generator API. Koji sometimes have issues presenting 
>>> information nicely for CGs. If anyone has more experience with Koji 
>>> internals, help would be definitely appreciated.
>>
>>
>> It would be great to address this before adopting the proposed change. I do 
>> wonder if there is a way to change the "osbuildimage" to be much more 
>> similar to an "image" build. Or something like that. The information 
>> conveyed by an "image" vs "osbuildimage" is so much more useful. I don't 
>> know the Koji internals much anymore, but there has to be a way to make this 
>> better.
>>
>>> We can definitely flatten the JSON output into something that resembles a 
>>> log file. I will let you know when this is done.
>>>
>>> Note that every task also produces a manifest file - this is extremely 
>>> useful, because you can just feed it to osbuild locally. Since the manifest 
>>> basically fully specifies an image build (with locked package versions 
>>> including their hashes), there's a high chance that you will be just able 
>>> to reproduce the issue locally and use any tools you want for deeper 
>>> debugging. This is one of the goals of the project: Make image builds more 
>>> reproducible.
>>
>>
>> Both the JSON and raw logs are useful. Very glad to know that the manifest 
>> will allow recreation of the build artifact. I'd like to see all of that 
>> presented similar to a build that packagers are used to (e.g. 
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=698). Maybe this 
>> is more a Koji enhancement, but I still question moving this proposal 
>> forward without addressing the buildsys UX/UI. Let's be sure to not bury 
>> very useful things when making changes.
>
>
>
> Yep, that's a shortcoming of how we currently upload the builds to koji. It's 
> something we would like to tackle in the upcoming quarter, see the tracking 
> ticket: https://issues.redhat.com/browse/COMPOSER-1801 (public link).
>

I can't comment on that ticket. :(



-- 
真実はいつも一つ！/ 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: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

On 28/06/2023 14:10, Kalev Lember wrote:
Since you already have the compat package, I would suggest merging the 
side tag as is.


I'm waiting for dnf5:
https://github.com/rpm-software-management/dnf5/issues/675
https://bugzilla.redhat.com/show_bug.cgi?id=2218180

I fixed some packages with trivial issues. Now only 16 packages could 
not be built from sources.


Also I want to untag fmt9 compat package before merging side tag. It was 
introduced only to fix issues with dnf5 in Koji.


--
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: SIG proposal: libreoffice-sig

[Eike Rathke]

Hi,

On Tuesday, 2023-06-27 17:06:56 -, Mattia Verga via devel wrote:

> Anyone interested can join the `#libreoffice-sig:fedoraproject.org` matrix 
> room for discussion.

Nope, it's #libreoffice:fedoraproject.org

  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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Ondřej Budai]

On Wed, Jun 28, 2023 at 2:20 PM Jonathan Steffan 
wrote:

> On Wed, Jun 28, 2023 at 5:23 AM Ondřej Budai  wrote:
>
>> > Maybe I'm just using it wrong, but I've not found a different way.

>>>
>> I will take a look. The difference between livemedia and osbuildImage is
>> that the osbuildImage task is defined by a plugin
>>  and it interacts with koji
>> via the content generator API
>> . Koji sometimes have
>> issues presenting information nicely for CGs. If anyone has more experience
>> with Koji internals, help would be definitely appreciated.
>>
>
> It would be great to address this before adopting the proposed change. I
> do wonder if there is a way to change the "osbuildimage" to be much more
> similar to an "image" build. Or something like that. The information
> conveyed by an "image" vs "osbuildimage" is so much more useful. I don't
> know the Koji internals much anymore, but there has to be a way to make
> this better.
>
> We can definitely flatten the JSON output into something that resembles a
>> log file. I will let you know when this is done.
>>
>> Note that every task also produces a manifest file - this is extremely
>> useful, because you can just feed it to osbuild locally. Since the manifest
>> basically fully specifies an image build (with locked package versions
>> including their hashes), there's a high chance that you will be just able
>> to reproduce the issue locally and use any tools you want for deeper
>> debugging. This is one of the goals of the project: Make image builds more
>> reproducible.
>>
>
> Both the JSON and raw logs are useful. Very glad to know that the manifest
> will allow recreation of the build artifact. I'd like to see all of that
> presented similar to a build that packagers are used to (e.g.
> https://koji.fedoraproject.org/koji/buildinfo?buildID=698). Maybe
> this is more a Koji enhancement, but I still question moving this proposal
> forward without addressing the buildsys UX/UI. Let's be sure to not bury
> very useful things when making changes.
>


Yep, that's a shortcoming of how we currently upload the builds to koji.
It's something we would like to tackle in the upcoming quarter, see the
tracking ticket: https://issues.redhat.com/browse/COMPOSER-1801 (public
link).

Cheers,
Ondřej
___
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Jonathan Steffan]

On Wed, Jun 28, 2023 at 5:23 AM Ondřej Budai  wrote:

> > Maybe I'm just using it wrong, but I've not found a different way.
>>>
>>
> I will take a look. The difference between livemedia and osbuildImage is
> that the osbuildImage task is defined by a plugin
>  and it interacts with koji via
> the content generator API
> . Koji sometimes have
> issues presenting information nicely for CGs. If anyone has more experience
> with Koji internals, help would be definitely appreciated.
>

It would be great to address this before adopting the proposed change. I do
wonder if there is a way to change the "osbuildimage" to be much more
similar to an "image" build. Or something like that. The information
conveyed by an "image" vs "osbuildimage" is so much more useful. I don't
know the Koji internals much anymore, but there has to be a way to make
this better.

We can definitely flatten the JSON output into something that resembles a
> log file. I will let you know when this is done.
>
> Note that every task also produces a manifest file - this is extremely
> useful, because you can just feed it to osbuild locally. Since the manifest
> basically fully specifies an image build (with locked package versions
> including their hashes), there's a high chance that you will be just able
> to reproduce the issue locally and use any tools you want for deeper
> debugging. This is one of the goals of the project: Make image builds more
> reproducible.
>

Both the JSON and raw logs are useful. Very glad to know that the manifest
will allow recreation of the build artifact. I'd like to see all of that
presented similar to a build that packagers are used to (e.g.
https://koji.fedoraproject.org/koji/buildinfo?buildID=698). Maybe this
is more a Koji enhancement, but I still question moving this proposal
forward without addressing the buildsys UX/UI. Let's be sure to not bury
very useful things when making changes.

-- 
Jonathan Steffan
___
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: Announcing fmt library soversion bump

[Kalev Lember]

On Wed, Jun 28, 2023 at 1:12 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> Results: 37 builds succeeded, 19 failed.
>
> FTBFS:
>
> 0ad
> arbor
> CuraEngine
> bout++
> cachelib
> contour-terminal
> dnf5
> dolphin-emu
> easyrpg-player
> folly
> freeopcua
> gerbera
> gnuradio
> luxcorerender
> mangohud
> nheko
> wasmedge
> watchman
> waybar
>
> Please fix your packages and use f39-build-side-69394 side tag:
> fedpkg build --target f39-build-side-69394
>

Since you already have the compat package, I would suggest merging the side
tag as is. The compat package makes it possible for the package maintainers
to switch over at their own pace when they have time to deal with this.

Also, please file FTBFS bugs against packages that failed to build.

-- 
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: Announcing fmt library soversion bump

[Richard Shaw]

On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> Results: 37 builds succeeded, 19 failed.
>
> gnuradio
>

Issue filed upstream:
https://github.com/gnuradio/gnuradio/issues/6735

Also, not all the maintainers may review the devel list as closely. In the
past when I've had a lot of affected packages I wrote a simple bash script
that took the package names and output the -
maintain...@fedoraproject.org email so I could copy and paste it into my
email client.

Not quite the way I did it but ChatGPT came up with this:
```
#!/bin/bash

# Specify the input file containing package names (one per line)
input_file="package_names.txt"

# Initialize an empty string to store the email addresses
email_addresses=""

# Read each package name from the input file
while IFS= read -r package_name; do
  # Construct the email address and append it to the string
  email_address="${package_name}-maintain...@fedoraproject.org"
  email_addresses+="${email_address};"
done < "$input_file"

# Remove the trailing semicolon, if any
email_addresses=${email_addresses%;}

# Print the final email addresses string
echo "$email_addresses"
```

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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Ondřej Budai]

On Wed, Jun 28, 2023 at 12:24 PM Jonathan Steffan 
wrote:

> On Wed, Jun 28, 2023 at 12:52 AM Adam Williamson <
> adamw...@fedoraproject.org> wrote:
>
>> On Tue, 2023-06-27 at 17:59 -0600, Jonathan Steffan wrote:
>> > The Koji integration leaves many things to be desired. I've had to dig
>> far
>> > more than needed for osbuildimage stuff.
>>
> [...]
>
>> > Maybe I'm just using it wrong, but I've not found a different way.
>>
>
I will take a look. The difference between livemedia and osbuildImage is
that the osbuildImage task is defined by a plugin
 and it interacts with koji via
the content generator API .
Koji sometimes have issues presenting information nicely for CGs. If anyone
has more experience with Koji internals, help would be definitely
appreciated.


>
>> For compose debugging I don't think this part would be terrible in
>> practice, most of the time.
>>
>> https://pagure.io/releng/failed-composes/issues
>
>
> I'm glad there is something better than what I'd found. I'm not
> necessarily trying to debug composes, just find them and use/test them as
> needed. If something like this continued after changing to osbuildimage
> tasks, that would work.
>
>
>>  Personally I don't usually have
>> much call for downloading the actual artifact from Koji - I'd usually
>> get it from the compose - but maybe you have a workflow where it's
>> important?
>>
>
> I've regularly used the images produced at
> https://koji.fedoraproject.org/koji/builds?type=image&order=-build_id for
> doing live system testing for package updates and other changes where I
> don't have a local install already available. It's really nice to have
> these artifacts so easily understandable and accessible. Maybe my workflow
> is off, but having such artifacts available has been super useful. The
> osbuildimage tasks, not so much. If we start to migrate the live image
> creation into an osbuildimage task, as currently implemented, it will
> diminish the value of automatically generated install/live images. It has
> been very helpful to be able to grab an ISO from Koji and test whatever is
> needed in a live/virt environment without having to do a full install and
> keep it updated. Keeping that very easily accessible would be awesome.
>
> Personally, I'm more worried about the logs being JSON. Machine-
>> parseable is nice, I guess, but in practice it's usually humans who
>> parse logs, at least in this case, and I see no really nice human way
>> to consume that log.
>
>
> I agree.
>
> Maybe raw text in addition to the JSON logs would be better for this
> workload. For me, the logs on an "image" build are much more familiar to
> regular packagers doing builds and they make sense. I have to dig for
> logs/artifacts in two different places when trying to understand
> "osbuildimage" tasks. The tools for reading JSON are available, but it'd be
> great to add in some easily accessible raw logs.
>

We can definitely flatten the JSON output into something that resembles a
log file. I will let you know when this is done.

Note that every task also produces a manifest file - this is extremely
useful, because you can just feed it to osbuild locally. Since the manifest
basically fully specifies an image build (with locked package versions
including their hashes), there's a high chance that you will be just able
to reproduce the issue locally and use any tools you want for deeper
debugging. This is one of the goals of the project: Make image builds more
reproducible.

Cheers,
Ondřej
___
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Ondřej Budai]

Hi Kevin!

On Tue, Jun 27, 2023 at 12:41 AM Kevin Fenzi  wrote:

> > * Other developers:
> > Our focus for this change is specifically on Fedora Workstation.
> > Nevertheless, we are open to collaborating with all spins/SIG to
> > transition their build pipelines to Image Builder. However, for the
> > initial switch, we aim to minimize the impact by focusing on a single
> > artifact. We anticipate that more artifacts will be transitioned in
> > subsequent releases of Fedora Linux.
>
> I realize you have to start somewhere, but I'm not sure this is
> something that should be driven by the SIGs/spin owners. I mean if the
> images produced are the same, why do they care? :)
>

We are happy to drive this. We just don't want to do any changes without
them. :)


>
> Would it be better to start with a non blocking deliverable and get
> things working, then just switch all the rest?
>

It's important to understand how we got here: We are collaborating with the
installer team on the new Web UI - e.g. we provided the tooling for
building the preview images
 last
cycle, helping with setting up image builder upstream for their CI and we
did some debugging. Thus, it makes sense for us to focus on the same
artifact as the installer team is concentrating on - the Workstation Live
ISO.

Also, another advantage from my point of view is that people really care
about this artifact, so the bar is set high for us. I'm afraid that if we
switched some less-used artifacts, some issues caused by changing the
underlying tool might go live unnoticed. I fully acknowledge that our
approach has also a somewhat high risk, however as the change is trivially
revertible, the risk is manageable.

Anyway, I'm happy for any suggestions how to do this differently.


>
> If we are moving from kickstarts to blueprints, I would guess we need a
> new repo for that and help converting things.
>
> Do we have a sense that livemedia-creator is going to keep being
> used/work? There is likely a bunch of docs pointing to it that I would
> suspect should be updated to point people to them.
>
> > * Release engineering: [https://pagure.io/releng/issue/11500 #11500]
> > Provide ppc64le machines to Image Builder. Switch the pungi config to
> > use Image Builder.
>
> Yeah. ;)
>
> I take it you have x86_64 and aarch64 in hand?
> When we move all images over, will it be able to handle the capacity?
>

Do you know how many builds for Workstation live ISO we have on one day?
I'm 99% sure we can handle it, internally, we are building about 100 images
a day for RHEL with basically the same infra as is currently used for
Fedora.

Cheers,
Ondřej
___
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: Releasing package updates in multiple Fedora releases

[Sérgio Basto]

Hi, 

A little late for the party , I decide publish my helper_scripts on a
github repo, maybe all this will be supersede by Packit 

https://github.com/sergiomb2/herlper_scripts

Usage :

fedpkg clone foo-package

cd foo-packge 

~/bin/update_from_bugzilla.sh id_bug stage_number 
 
echo "stage 0: rpmdev-bumpspec"
echo "stage 1: scratch-build"
echo "stage 2: rfpkg new-sources && fedpkg ci -c && git show"
echo "stage 3: fedpkg push && fedpkg build on rawhide"
echo "stage 4: build all branches"
echo "stage 5: bodhi updates all branches"


On Mon, 2023-06-19 at 13:58 +0200, Sandro wrote:
> On 19-06-2023 12:51, Miroslav Suchý wrote:
> > > Sounds like these tools are worth mentioning in the docs, seeing
> > > how 
> > > many people face the same challenge.
> > 
> > We (I am part of Packit team) plan to do more noise about it later.
> > Especially this feature - we have finished it in January and asked
> > few 
> > people to try it. We have done several rounds of fix-and-try-
> > again.  
> > Today, we have one outstanding issue "manually re-trigger event"
> > and I 
> > believe that once implemented, it will be ready for wide audience.
> > If 
> > you are brave and ready for bleeding edge, you can try it now.
> 
> I didn't realize Packit is still very new. So new, it's still warm,
> like 
> the blood dripping off its edge... ;)
> 
> I'll certainly try it out and provide feedback should I have any. 
> Thanks, Miro!
> 
> -- Sandro
> ___
> 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

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

Re: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

Results: 37 builds succeeded, 19 failed.

FTBFS:

0ad
arbor
CuraEngine
bout++
cachelib
contour-terminal
dnf5
dolphin-emu
easyrpg-player
folly
freeopcua
gerbera
gnuradio
luxcorerender
mangohud
nheko
wasmedge
watchman
waybar

Please fix your packages and use f39-build-side-69394 side tag:
fedpkg build --target f39-build-side-69394

--
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Ondřej Budai]

I already answered you here:
https://pagure.io/fedora-workstation/issue/384#comment-862709

TL;DR: Let's figure this out when we are migrating other artifacts. For
now, the blueprint will be empty/minimal.

Cheers,
Ondřej

On Mon, Jun 26, 2023 at 10:34 PM Neal Gompa  wrote:

> On Mon, Jun 26, 2023 at 4:14 PM Adam Williamson
>  wrote:
> >
> > On Mon, 2023-06-26 at 15:33 +0100, Aoife Moloney wrote:
> > > https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
> > >
> > > 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 ==
> > > Image Builder is a set of modern tools for building operating system
> > > images. Its goal is to make the builds reliable and reproducible.
> > > Moreover, it's designed to give the end users a simple workflow to
> > > build their own custom images. The aim of this change is to switch the
> > > build tool for Fedora Workstation live ISO from livemedia-creator to
> > > Image Builder.
> > >
> > > == Owner ==
> > > * Name: [[User:obudai|Ondřej Budai]]
> > > * Email: obu...@redhat.com
> > > * Name: [[User:Supakeen|Simon de Vlieger]]
> > > * Email: supak...@redhat.com
> > > * Name: [[User:jkonecny|Jiří Konečný]]
> > > * Email: jkone...@redhat.com
> > >
> > >
> > >
> > > == Detailed Description ==
> > > Image builder is currently getting support for building
> > > [https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs].
> > > Once the PR implementing the new image type is merged,
> > > [
> https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7fe92/f/fedora.conf#_530
> > > the pungi-fedora configuration] needs to be updated. This change will
> > > ensure that pungi creates an osbuildImage task in koji instead of the
> > > currently used livemedia one.
> > >
> > > Pungi and Koji already support Image Builder, so no additional work is
> > > required there (refer to the
> > > [
> https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images
> > > pungi] and [https://github.com/osbuild/koji-osbuild/ koji]
> > > documentation). The only missing part in terms of infrastructure is
> > > provisioning ppc64le worker machines for Image Builder, see the
> > > relevant [https://pagure.io/fedora-infrastructure/issue/11243
> > > fedora-infra ticket].
> > >
> > > Note that Image Builder is already used for
> > > [https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild
> > > building ISOs and raw disks of Fedora IoT]. Therefore, this proposal
> > > does not introduce a new tool to the Fedora build pipeline.
> > >
> > > == Feedback ==
> > >
> > > Currently, Image Builder does not populate the DNF database correctly,
> > > leading to all RPMs installed on the target system being marked as
> > > user-installed. This is [https://github.com/osbuild/osbuild/issues/455
> > > a known issue] that the team is planning to address as soon as the
> > > initial support for live ISOs is merged.
> > >
> > >
> > > == Benefit to Fedora ==
> > > The maintainer team of Image Builder believes that the project
> > > undergoes more comprehensive testing compared to
> > > lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora
> > > should experience fewer issues with the image building pipeline.
> > >
> > > Another advantage is the project's emphasis on making Image Builder
> > > more user-friendly. End users can easily build their own customized
> > > version of the live ISO using a simple
> > > [
> https://www.osbuild.org/guides/image-builder-on-premises/blueprint-reference.html
> > > TOML blueprint file] and a
> > > [
> https://www.osbuild.org/guides/image-builder-on-premises/building-an-image-from-cli.html
> > > CLI interface]. This approach, utilizing well-known file formats, is a
> > > positive step compared to livemedia-creator's kickstart files. More
> > > information about building customized images can found on
> > > [https://major.io/p/build-custom-centos-stream-cloud-image/ Major
> > > Hayden's blog] or in
> > > [https://www.youtube.com/watch?v=PsQySAEOeFs&t=17001s a conference
> > > talk] given by Ondřej Budai, one of the proposal owners. Moreover,
> > > Image Builder provides [https://github.com/osbuild/cockpit-composer/ a
> > > graphical interface] for visually defining blueprints, further
> > > simplifying the workflow.
> > >
> > > We believe that Image Builder can also be beneficial to the
> > > [https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely
> > > aligns with their objective of providing a simple method for building
> > > up-to-date, customizable images.
> > >
> > > == Scope ==
> > > * Proposal owners:
> > > Finishing implementing support for the live ISO upstream and
> > > collaborate with release engineering to switch the pungi config to use
> > > Image Build

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Ondřej Budai]

Hi Adam and Ben!

On Mon, Jun 26, 2023 at 10:14 PM Adam Williamson 
wrote:

>
>
> In terms of testing: we already test the existing toolchain pretty
> effectively in practice. openQA builds Workstation and KDE live images
> with every relevant critical path update. If an update breaks live
> image creation, we find out about it right away, and the update is
> gated.
>

Can you elaborate the testing setup more? Does openQA somehow call
livemedia-creator locally, or does it just offload the task to koji? If the
latter is true, that this shouldn't be an issue. The former option is more
tricky, we would have to somehow adjust openQA to use a different tool.


>
> In terms of file formats: is toml really that much better known or
> better than kickstart, for an audience of Fedora devs, for the purpose
> of building a live image? Especially now we (finally) got the livesys
> stuff out of the kickstarts and they're mostly pretty simple? As a
> specific nitpick, the documentation on the Image Builder format makes
> it clear that it supports comps groups, but it's less clear if it
> supports comps *environment* groups. It really needs to do so to
> maintain parity with livemedia-creator; we don't want to have to define
> all the environment groups twice (once in comps, once in imagebuilder
> TOML files). If it does support this, it should be made clear in the
> docs.
>

Yes, it does support environment groups.

Regarding kickstarts vs. blueprint (TOML): From my point of view,
kickstarts are a specific thing to the "Fedora ecosystem", whereas TOML is
widely used also in other areas (Go/Rust), thus there is a bigger ecosystem
of tooling for it. I would also like to introduce JSONSchema (conversion
between JSON and TOML is mostly lossless) for blueprints, which would allow
e.g. linting of blueprints. Yet another step in making the tooling more
user-friendly. Anyway, I don't want to spend much time on this, it feels
like this is more a matter of taste.


>
> I notice the Change doesn't say much about debugging failed builds.
> This is very important. Failed livemedia-creator tasks are quite easy
> to debug. livemedia-creator as run in Koji by Pungi is very good at
> providing sufficient logs to determine what the heck went wrong if an
> image build fails. Other tools - notably ImageFactory - are notoriously
> much worse at this. Where does Image Builder fall?
>

Let's talk about this in the branch about logs in koji.


>
> As I said, I'm not saying we shouldn't do this. But I do think that if
> it doesn't provide any really compelling benefits over livemedia-
> creator, we should set a high bar for it also not having any
> significant *drawbacks* compared with livemedia-creator.

-- 
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
> Ben Cotton:
> What's the impact to QA and release processes? Will the Workstation
> images still be in the regular large compose, or will they be a
> separate compose that will need to be managed independently?

Images will still be in the regular compose, image builder can be just
called via Pungi, so one compose can use multiple image building tools.
Regarding the impact: I'm mostly concerned about the openQA workflow, see
the paragraph above.

Cheers,
Ondřej
___
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: Announcing fmt library soversion bump

[Stephen Smoogen]

On Wed, 28 Jun 2023 at 04:20, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 28/06/2023 08:32, Vitaly Zaitsev wrote:
> > How I can fix that?
>
> Steps how to fix such issues for historical purposes:
>
> 1. Create a new side tag.
> 2. Introduce compatibility fmt9 package.
> 3. Build fmt9 compatibility package.
> 4. Build fmt 10.
> 5. Rebuild dnf5 against fmt 10.
> 6. Untag fmt9 from this side tag.
> 7. Retire fmt9 compatibility package.
>


Thanks for documenting this for other people to find in the future.


-- 
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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Vít Ondruch]

Dne 27. 06. 23 v 10:13 Vít Ondruch napsal(a):


Dne 26. 06. 23 v 22:12 Fabio Valentini napsal(a):

On Mon, Jun 26, 2023 at 8:40 PM Vít Ondruch  wrote:


Dne 26. 06. 23 v 20:24 Fabio Valentini napsal(a):
On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok  
wrote:

(snip)


---

The current problem with Python without tzdata is:

=== 


   >>> from zoneinfo import ZoneInfo
   >>> ZoneInfo("Europe/Prague")
Traceback (most recent call last):
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in 
load_tzdata
   return 
resources.files(package_name).joinpath(resource_name).open("rb")

  ^
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 22, in files

   return from_package(get_package(package))
   
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 53, in

get_package
   resolved = resolve(package)
  
 File "/usr/lib64/python3.11/importlib/resources/_common.py", 
line 44, in resolve

   return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)

^
 File "/usr/lib64/python3.11/importlib/__init__.py", line 126, 
in import_module

   return _bootstrap._gcd_import(name[level:], package, level)

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1126, in 
_find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1126, in 
_find_and_load_unlocked
 File "", line 241, in 
_call_with_frames_removed

 File "", line 1204, in _gcd_import
 File "", line 1176, in 
_find_and_load
 File "", line 1140, in 
_find_and_load_unlocked

ModuleNotFoundError: No module named 'tzdata'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in 
load_tzdata
   raise ZoneInfoNotFoundError(f"No time zone found with key 
{key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with 
key Europe/Prague'
=== 



Not that ZoneInfo("UTC") also fails:

=== 


   >>> ZoneInfo("UTC")
Traceback (most recent call last):
...
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with 
key UTC'
=== 



So we would need to patch Python to detect missing tzdata and 
report something

like:

    ZoneInfoNotInstalledError: 'No time zone information installed 
on the system,

you can only use UTC'

We would also need to ensure UTC work even without tzdata installed.

I would be reluctant to carry this as a downstream-only patch. And 
the upstream

window for changes like this has already closed for Python 3.12.

Does this mean that tzdata needs to be present for doing datetime /
timezone calculations at runtime with the zoneinfo module?
Would this Change require that all Python programs that use this
module add "Requires: tzdata"? I don't think that would be a
reasonable change.

There's a similar issue with some Rust libraries (and probably other
language-specific timezone handling libraries),


Yep, this is the case for rubygem-tzinfo. It would deserve 
recommends at
minimum, because in theory, the tzdata can be suplied by tzinfo-data 
gem

instead.

That might work with something like

Requires: (tzdata or rubygem(tzinfo-data))



We don't have rubygem-tzinfo-data in Fedora. But it can be installed 
via `gem install` or Bundler. So that is the reason for soft dependency.




I have added the soft dependency into rubygem-tzinfo:

https://src.fedoraproject.org/rpms/rubygem-tzinfo/c/6822ef00ad1b64a81ddd64c1728e49fa309d7603?branch=rawhide

If nothing else, the dependency will be visible now.


Vít



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

Re: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)

[Jonathan Steffan]

On Wed, Jun 28, 2023 at 12:52 AM Adam Williamson 
wrote:

> On Tue, 2023-06-27 at 17:59 -0600, Jonathan Steffan wrote:
> > The Koji integration leaves many things to be desired. I've had to dig
> far
> > more than needed for osbuildimage stuff.
>
[...]

> > Maybe I'm just using it wrong, but I've not found a different way.
>
> For compose debugging I don't think this part would be terrible in
> practice, most of the time.
>
> https://pagure.io/releng/failed-composes/issues


I'm glad there is something better than what I'd found. I'm not
necessarily trying to debug composes, just find them and use/test them as
needed. If something like this continued after changing to osbuildimage
tasks, that would work.


>  Personally I don't usually have
> much call for downloading the actual artifact from Koji - I'd usually
> get it from the compose - but maybe you have a workflow where it's
> important?
>

I've regularly used the images produced at
https://koji.fedoraproject.org/koji/builds?type=image&order=-build_id for
doing live system testing for package updates and other changes where I
don't have a local install already available. It's really nice to have
these artifacts so easily understandable and accessible. Maybe my workflow
is off, but having such artifacts available has been super useful. The
osbuildimage tasks, not so much. If we start to migrate the live image
creation into an osbuildimage task, as currently implemented, it will
diminish the value of automatically generated install/live images. It has
been very helpful to be able to grab an ISO from Koji and test whatever is
needed in a live/virt environment without having to do a full install and
keep it updated. Keeping that very easily accessible would be awesome.

Personally, I'm more worried about the logs being JSON. Machine-
> parseable is nice, I guess, but in practice it's usually humans who
> parse logs, at least in this case, and I see no really nice human way
> to consume that log.


I agree.

Maybe raw text in addition to the JSON logs would be better for this
workload. For me, the logs on an "image" build are much more familiar to
regular packagers doing builds and they make sense. I have to dig for
logs/artifacts in two different places when trying to understand
"osbuildimage" tasks. The tools for reading JSON are available, but it'd be
great to add in some easily accessible raw logs.

-- 
Jonathan Steffan
jonathanstef...@gmail.com
___
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: Announcing fmt library soversion bump

[Leigh Scott]

You could bootstrap dnf for the rebuild

https://src.fedoraproject.org/rpms/dnf/blob/rawhide/f/dnf.spec#_298
___
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: Announcing fmt library soversion bump

[Vitaly Zaitsev via devel]

On 28/06/2023 08:32, Vitaly Zaitsev wrote:

How I can fix that?


Steps how to fix such issues for historical purposes:

1. Create a new side tag.
2. Introduce compatibility fmt9 package.
3. Build fmt9 compatibility package.
4. Build fmt 10.
5. Rebuild dnf5 against fmt 10.
6. Untag fmt9 from this side tag.
7. Retire fmt9 compatibility package.

--
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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Miroslav Lichvar]

On Mon, Jun 26, 2023 at 04:54:00PM +0100, Aoife Moloney wrote:
> * Other developers: Some packages need to change their spec files from
> `Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
> all packages switched in this way, but it is not required. Supporting
> optional tzdata installation for as many workloads as possible allows
> those workloads to minimize their container image size.
> List of packages which need to be changed:
> * glibc (glibc-common)

There are packages that rely on the glibc->glibc-common->tzdata
dependency. The one I know is chrony, which in the default
configuration needs the "right/UTC" timezone to get the TAI-UTC
offset. I suspect there are other packages that will need to add
Recommends or Requires.

-- 
Miroslav Lichvar
___
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: Announcing fmt library soversion bump

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 28 June 2023 at 08:32, Vitaly Zaitsev via devel wrote:
> On 23/05/2023 12:22, Vitaly Zaitsev wrote:
> > I will use my proven-packager rights to rebuild all dependent packages
> > in a separate side tag next week.
> 
> Koji is now broken in this side tag (f39-build-side-69392):
> 
> Error:
>  Problem 1: package python3-dnf-4.16.1-2.fc39.noarch from build requires
> dnf-data = 4.16.1-2.fc39, but none of the providers can be installed
>   - package dnf-data-4.16.1-2.fc39.noarch from build requires
> /etc/dnf/dnf.conf, but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libfmt.so.9()(64bit) needed by
> libdnf5-5.0.14-1.fc39.ppc64le from build
>  Problem 2: package python3-dnf-plugins-core-4.4.1-3.fc39.noarch from build
> requires python3-dnf >= 4.11.0, but none of the providers can be installed
>   - package python3-dnf-4.16.1-2.fc39.noarch from build requires dnf-data =
> 4.16.1-2.fc39, but none of the providers can be installed
>   - package dnf-plugins-core-4.4.1-3.fc39.noarch from build requires
> python3-dnf-plugins-core = 4.4.1-3.fc39, but none of the providers can be
> installed
>   - package dnf-data-4.16.1-2.fc39.noarch from build requires
> /etc/dnf/dnf.conf, but none of the providers can be installed
>   - conflicting requests
>   - nothing provides libfmt.so.9()(64bit) needed by
> libdnf5-5.0.14-1.fc39.ppc64le from build
> (try to add '--skip-broken' to skip uninstallable packages)
> 
> How I can fix that?

If dnf requires fmt, then you have to submit a compat fmt package first
so that dnf remains installable. I'd try untaggin the new fmt from that
side tag to fix this.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.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