Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2024-04-15)

[Kalev Lember]

Text Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-15/flatpak-sig.2024-04-15-15.03.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-15/flatpak-sig.2024-04-15-15.03.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-15/flatpak-sig.2024-04-15-15.03.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-04-15/flatpak-sig.2024-04-15-15.03.html



=
# #meeting-1:fedoraproject.org: flatpak-sig
=

Meeting started by @kalev:fedora.im at 2024-04-15 15:03:21



Meeting summary
---
* TOPIC: Init process (@kalev:fedora.im, 15:03:31)
* TOPIC: f40 mass rebuild (@yselkowitz:fedora.im, 15:06:26)
* INFO: ~82% of flatpaks are rebuilt for f40 and in testing 
(@yselkowitz:fedora.im, 15:07:12)
* LINK: https://pad.riseup.net/p/Tyg0nsudHLy2v__a0HzE 
(@yselkowitz:fedora.im, 15:07:19)

* TOPIC: openh264 (@yselkowitz:fedora.im, 15:32:14)
* TOPIC: issue trackers (@yselkowitz:fedora.im, 15:40:52)
* INFO: speech-dispatcher-libs are included in f40 runtimes 
(@yselkowitz:fedora.im, 15:41:17)
* LINK: 
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/28 
(@yselkowitz:fedora.im, 15:41:20)
* INFO: no "Fedora Flatpaks" product in RHBZ 
(@yselkowitz:fedora.im, 15:47:02)
* LINK: 
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/29 
(@yselkowitz:fedora.im, 15:47:07)
* INFO: flatpakBuild[Arch] are not searchable in kojiweb 
(@yselkowitz:fedora.im, 15:50:44)
* LINK: https://pagure.io/koji-flatpak/issue/1 
(@yselkowitz:fedora.im, 15:50:48)

* TOPIC: open floor (@yselkowitz:fedora.im, 15:52:27)

Meeting ended at 2024-04-15 16:00:32

Action items


People Present (lines said)
---
* @yselkowitz:fedora.im (63)
* @kalev:fedora.im (44)
* @meetbot:fedora.im (2)
* @zodbot:fedora.im (1)
--
___
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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2024-03-18)

[Kalev Lember]

Text Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-03-18/flatpak-sig.2024-03-18-15.30.log.txt
HTML Log: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-03-18/flatpak-sig.2024-03-18-15.30.log.html
Text Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-03-18/flatpak-sig.2024-03-18-15.30.txt
HTML Minutes: 
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2024-03-18/flatpak-sig.2024-03-18-15.30.html



=
# #meeting-1:fedoraproject.org: flatpak-sig
=

Meeting started by @kalev:fedora.im at 2024-03-18 15:30:41



Meeting summary
---
* TOPIC: Init process (@kalev:fedora.im, 15:31:00)
* TOPIC: Pushing last F38 flatpak runtime update (@kalev:fedora.im, 
15:42:52)
* INFO: All flatpaks are now updated to the F39 runtime and the new 
build infra, and all that remains is EOL'ing the F38 runtime 
(@kalev:fedora.im, 15:51:11)

* TOPIC: Meeting time (@kalev:fedora.im, 16:04:46)
* INFO: ~210 flatpaks currently in testing (@yselkowitz:fedora.im, 
16:13:20)
* LINK: 
https://bodhi.fedoraproject.org/updates/?search==testing=F39F 
(@yselkowitz:fedora.im, 16:13:24)
* TOPIC: speech-dispatcher in flatpaks 
(https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/28) 
(@kalev:fedora.im, 16:15:51)
* ACTION: yselkowitz to file PR to split out speech-dispatcher-libs 
(@yselkowitz:fedora.im, 16:18:01)
* TOPIC: flatpak-module-tools PR for building extensions 
(https://pagure.io/flatpak-module-tools/pull-request/41) 
(@kalev:fedora.im, 16:19:08)

* TOPIC: kicking off F40 flatpaks (@kalev:fedora.im, 16:26:15)
* TOPIC: Open Floor (@kalev:fedora.im, 16:36:36)

Meeting ended at 2024-03-18 16:40:30

Action items

* yselkowitz to file PR to split out speech-dispatcher-libs

People Present (lines said)
---
* @kalev:fedora.im (65)
* @yselkowitz:fedora.im (39)
* @otaylor:fedora.im (13)
* @nirik:matrix.scrye.com (11)
* @meetbot:fedora.im (2)
* @zodbot:fedora.im (1)
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Kalev Lember]

On Thu, Feb 22, 2024 at 12:41 AM Garry T. Williams 
wrote:

>  Problem 3: package network-scripts-ppp-2.5.0-3.fc39.x86_64 from @System
> requires network-scripts, but none of the providers can be installed
>   - network-scripts-10.20-1.fc39.x86_64 from @System  does not belong to a
> distupgrade repository
>   - problem with installed package network-scripts-ppp-2.5.0-3.fc39.x86_64
>

This one should be fixed in
https://bodhi.fedoraproject.org/updates/FEDORA-2024-9289eac273

-- 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Kalev Lember]

On Wed, Feb 21, 2024 at 1:28 PM hhlp  wrote:

> Error:
>
>  Problem: problem with installed package
> gnome-shell-extension-pop-shell-1.2.0^21.aafc945-1.fc39.noarch
>   - package gnome-shell-extension-pop-shell-1.2.0^21.aafc945-3.fc40.noarch
> from fedora requires (gnome-shell >= 45~ with gnome-shell < 46~), but none
> of the providers can be installed
>   - gnome-shell-extension-pop-shell-1.2.0^21.aafc945-1.fc39.noarch from
> @System  does not belong to a distupgrade repository
>   - gnome-shell-45.4-1.fc39.x86_64 from @System  does not belong to a
> distupgrade repository
> (try to add '--skip-broken' to skip uninstallable packages)
>

Thanks! Looks like this one is already filed as
https://bugzilla.redhat.com/show_bug.cgi?id=2257756

-- 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Kalev Lember]

On Wed, Feb 21, 2024 at 12:07 PM hhlp  wrote:

> al good as always good work only add --allowerasing in my case
>

Please don't add --allowerasing when doing this test because it hides the
issues that we are interested in.

-- 
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: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Kalev Lember]

On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber 
wrote:

> Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
> the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
> builds for fc39 and el9 yields
>
> libmupdf.so.23.10()(64bit)
>
> in both cases. I could try and stuff %__elf_provides into the spec for
> a koji scratch debug run ...
>

Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen
only ran on executable files, IIRC. Maybe that has changed in recent
Fedoras, but still is the case in el9?

-- 
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: GNOME package builds this cycle

[Kalev Lember]

On Tue, Jan 23, 2024 at 7:01 PM Florian Weimer  wrote:

> I think I fixed up the RPM spec files of the Vala packages that didn't
> do the required rebuilds with Fedora's patched Vala compiler (roughly:
> run touch **.vala, add BuildRequires: vala, as appropriate).  I changed
> packages only if I saw build failures, so if rebases happen (or file
> systems with different modification time resolution), it's possible that
> more RPM spec files need to be adjusted to re-run the Vala compiler.
>
> The latest upstream submission of the Vala workaround (5ed94310) has
> Clang support:
>
>codegen: Emit diagnostics pragmata for GCC 14, Clang 16 compatibility
>
>
> But I don't think we need this in Fedora, so I haven't imported it yet.
>

Thanks for sorting all that out! David says that he's going to keep an eye
out for build failures related to Vala.

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

GNOME package builds this cycle

[Kalev Lember]

Hi all,

Just a quick heads up that it's David King (amigadave on IRC) and not me
who's doing GNOME package builds in Fedora for the next 6 months or so -
during the Fedora 40 / GNOME 46 release cycle. David has already started
with GNOME 46.alpha builds in rawhide.

We also have a new person helping out and trying to learn how GNOME
packaging works: Nieves Montero. If you see pull requests from her, please
be nice and maybe say hi - she is new to Fedora and packaging in general.

I'll still be around, just focusing on other stuff for a while, but please
direct GNOME packaging related questions to David this cycle and not me :)

-- 
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: Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Thanks for helping think about this, both of you! Let me try to reply to
both of your emails in the same reply.

On Wed, Jan 10, 2024 at 8:04 PM Stephen Gallagher 
wrote:

> On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz 
> wrote:
> >
> > On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
> > > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz
> > > 
> > > wrote:
> > >
> > > > Since the previous libgweather versions were 40.y and the new
> > > > versions
> > > > are 4.4.z, shouldn't there be an Epoch?
> > > >
> > >
> > > I was thinking about this hard as well and I managed to convince
> > > myself
> > > that it should be fine without an epoch, for two reasons:
> > >
> > > 1) The libgweather package was last part of the F38 package set, and
> > > has
> > > been retired ever since (in F39+). Because of that, new F39 installs
> > > don't
> > > have the package, and people who have updated from F38 to either F39
> > > or
> > > current rawhide (F40) don't have the package either (it was obsoleted
> > > in
> > > fedora-obsolete-packages).
> > >
> > > 2) This only leaves people who would do F38->F40 distro upgrade in
> > > the
> > > future, but I think this case should be fine as well because AFAIK
> > > both dnf
> > > and PackageKit use distro-sync for distro upgrades, so they handle
> > > downgrades just fine.
> > >
> > > Normally this should have definitely warranted an epoch, but because
> > > it was
> > > retired for a long time, I believe it should be fine without. We can
> > > also
> > > always add an epoch in the future if it turns out we missed some
> > > case.
> > >
> > > What do you think?
> > > >
> >
> > Still concerned.  You've mentioned those who have already upgraded 38-
> > >rawhide, but what about those who *will* upgrade (e.g. post-branching)
> > 38->40?  Since that is a supported upgrade path, and 38 had 40.0, this
> > will be a downgrade.  If this wasn't landing until F41 the answer could
> > be different, but it really hasn't been out long enough.  After all,
> > the fedora-obsolete-packages entry was set to be removed for F41 for a
> > reason.
>

Replying to Yaakov here:
I actually mentioned this as case (2) above, where my idea was that because
dnf and PackageKit distro upgrades both use the "distro-sync" method by
default, they can handle package downgrades just fine when updating from
F38->F40.

However, Stephan then found a hole in the idea:


> I agree with Yaakov here.
>
> While you're correct that the standard upgrade mechanism now defaults
> to using `dnf distro-sync`, it's not the ONLY upgrade path that people
> take. There are a huge number of users who still insist on doing a
> basic DNF upgrade, no matter how much documentation we write. This
> WILL cause issues for them and will translate into bug reports that
> need to be at least triaged. So please, just support a clean upgrade
> path with the epoch bump.
>

Ah, and that's a fair point. I agree that there are probably a ton of
people just doing dnf update across distro versions.

However, I'm still a bit reluctant to add an epoch to libgweather, and not
because of the one extra Epoch line in libgweather's spec file, but because
of all other packages that would then need to remember to use the epoch
when they want to express a versioned dependency on libgweather. E.g.
'Requires: libgweather >= 4.5' would match _any_ libgweather version if the
epoch is set to 1, and packages would need to use 'Requires: libgweather >=
1:4.5' instead.

So, thinking of alternatives to epoch (and yes, I realize that my timing
was bad here and I should have just waited for F40 branching before doing
the rename), I suddenly realized that nothing in F38 actually uses the old
libgweather at all - we got everything ported over to libgweather4, but
failed to retire libgweather in time.

And that opens up a new possibility: we could add libgweather to
fedora-obsoletes-packages in F38, and by the time F40 is released in
several months time, everybody's F40 systems will have gotten rid of the
old libgweather package and we get a nice clean upgrade path from F38->F40,
without having to worry about adding epoch.

How does that sound? Also keep in mind that the above is only to cater for
people who try to use an unsupported upgrade method - dnf and
PackageKit/gnome-software distro upgrades should already work fine without
it.


> Also, what about RHEL upgrades?  c9s has libgweather-40.0, this will
> > cause c10s to have 4.4.0.
> >
>
> RHEL 

Re: Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Hi Yaakov,

On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz 
wrote:

> Since the previous libgweather versions were 40.y and the new versions
> are 4.4.z, shouldn't there be an Epoch?
>

I was thinking about this hard as well and I managed to convince myself
that it should be fine without an epoch, for two reasons:

1) The libgweather package was last part of the F38 package set, and has
been retired ever since (in F39+). Because of that, new F39 installs don't
have the package, and people who have updated from F38 to either F39 or
current rawhide (F40) don't have the package either (it was obsoleted in
fedora-obsolete-packages).

2) This only leaves people who would do F38->F40 distro upgrade in the
future, but I think this case should be fine as well because AFAIK both dnf
and PackageKit use distro-sync for distro upgrades, so they handle
downgrades just fine.

Normally this should have definitely warranted an epoch, but because it was
retired for a long time, I believe it should be fine without. We can also
always add an epoch in the future if it turns out we missed some case.

What do you think?



> > I expect this only affects places where the package name is hardcoded
> > -
> > CentOS 10 package sync comes to mind. I've added obsoletes and
> > provides for
> > all its subpackages so it should be transparent otherwise.
>
> Please file a PR for content-resolver-input.
>

Thanks, done:

https://github.com/minimization/content-resolver-input/pull/1055

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

Heads up: libgweather4 to libgweather rename in rawhide

[Kalev Lember]

Hi all,

Just a quick heads up that I'm in the process of renaming libgweather4
package
back to libgweather - we only ship a single libgweather version in rawhide
(and
in F39), so there is no need any more to have the API version encoded in the
package name in order to make it parallel installable.

I expect this only affects places where the package name is hardcoded -
CentOS 10 package sync comes to mind. I've added obsoletes and provides for
all its subpackages so it should be transparent otherwise.

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

Heads up: libmutter soname bump in rawhide

[Kalev Lember]

A quick heads up that mutter 46.alpha (par of gnome-shell 46.alpha,
https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7b40ac758) bumped its
soname from libmutter-13.so.0 to libmutter-14.so.0. GNOME packages
depending on mutter (gnome-shell, gnome-kiosk) are all rebuilt as part of
the same bodhi update.

This sadly breaks gala and wingpanel that are going to need adjusting for
new mutter. Fabio and I discussed this on Matrix and we thought that they
can temporarily stay broken and avoid mutter compat package for now. Fabio
is going to file tickets upstream so that gala and wingpanel upstream can
start working on new libmutter support.

-- 
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: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

[Kalev Lember]

On Tue, Jan 9, 2024 at 6:42 PM Milan Crha  wrote:

> On Tue, 2024-01-09 at 18:36 +0100, Kalev Lember wrote:
> > Looks like this has a bit of a mid air collision with gnome-shell
> > 46.alpha that's in a different bodhi update:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7b40ac758
>
> Hi,
> that's a pita. Let me know if I can help with anything. I can rebuild
> gnome-shell 46.alpha in the eds side tag and refresh the update.
>

Yes, that would be good if you could do it. The gnome-shell update just
landed in rawhide, so it needs a few minutes before the build roots are
regenerated. If you can do 'koji wait-repo f40-build-side-80962 --build
mutter-46~alpha-2.fc40' first to make sure new mutter is available in the
build roots, then it should be fine to rebuild.

-- 
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: Re: [heads-up] evolution-data-server libecal-2.0 soname version bump in rawhide

[Kalev Lember]

On Tue, Jan 9, 2024 at 6:25 PM Milan Crha  wrote:

> On Mon, 2024-01-08 at 18:40 -0800, kevin wrote:
> > On Mon, Jan 08, 2024 at 11:05:33AM +0100, Milan Crha wrote:
> > >elementary-calendar
> > >evolution-chime (which is part of pidgin-chime)
> > >gnome-panel
> > >phosh
>
>
> Hi,
> thank you all for the promptly rebuild of the left dependencies. As
> they all are done now, I filled the update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-d3219fb3da


Looks like this has a bit of a mid air collision with gnome-shell 46.alpha
that's in a different bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-d7b40ac758

I think we'll need to rebuild gnome-shell once more because of this - I can
keep an eye on the two bodhi updates and rebuild it one more time depending
on which one lands first.

-- 
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-candidate ~> f39-build stuck or something?

[Kalev Lember]

On Fri, Jan 5, 2024 at 1:01 PM Milan Crha  wrote:

> Hi again,
> with the problem on the rawhide, I managed to build evolution-data-
> server update for F39 with no problem, but the chain-build [1] to
> wait for the f39-build refresh/update to have the new eds. It waited
> for 2 hours, which is quite a lot of time.
>
> For what it's worth:
>
> $ koji wait-repo f39-build --build evolution-data-server-3.50.3-1.fc39
> nvr evolution-data-server-3.50.3-1.fc39 is not current in tag f39-build
>   latest build in f39-build is evolution-data-server-3.50.2-1.fc39
>

Yes, this only works for side tags. The previous F39 build,
https://koji.fedoraproject.org/koji/taskinfo?taskID=109761881 was done in a
side tag as well.

Chain builds kinda work without side tags for rawhide, but they take
forever to complete because each individual build in the chain build needs
to go through bodhi and openqa testing, before it can land in rawhide build
root, so each step (after the build has completed) takes more than an hour.
With a side tag, chain build is much faster and you can submit everything
together to bodhi so that all the new builds are tested as a single unit.

So my suggestion would be to use a self service side tag for rawhide as
well, not just F39.

-- 
Hope this helps,
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: Inactive packages removed from packager group

[Kalev Lember]

I picked up cairo and gtksourceview5.

-- 
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: appstream soname bump in Rawhide (special info for AppStreamQt users!)

[Kalev Lember]

On Tue, Nov 7, 2023 at 9:18 AM Milan Crha  wrote:

> I'm sorry for a late response, I forgot of this. I tried to build
> gnome-software in your side tag, but it fails due to the appstream
> packages cannot be installed together:
>
> Error: Transaction test error:
> DEBUG util.py:446:file /usr/lib64/girepository-1.0/AppStream-
> 1.0.typelib conflicts between attempted installs of appstream0.16-
> 0.16.3-1.fc40.x86_64 and appstream-1.0.0~git20231102.d88ed03-
> 1.fc40.x86_64
>
> Thus I guess the dependencies need to be built in certain order, to not
> pull in old and new appstream packages or there's some problem with
> packaging of the two.
>

Hi Milan,

I went ahead and dropped the conflicting typelib file from the
appstream0.16 compat package in
https://src.fedoraproject.org/rpms/appstream0.16/c/1f216a9f459dcfa5dec851b252c593629bf0cd7c?branch=rawhide

Can you do 'koji wait-repo f40-build-side-76936 --build
appstream0.16-0.16.3-2.fc40' and try building gnome-software again once it
says that the package is available in the repo?

-- 
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: appstream soname bump in Rawhide (special info for AppStreamQt users!)

[Kalev Lember]

On Tue, Nov 7, 2023 at 4:34 AM Neal Gompa  wrote:

> * Flatpak has an upstream change that needs backporting[1] or a new
> release.
> * GNOME Software has a merge request open[2].
> * libadwaita has an upstream change that needs backporting[3].
> * malcontent needs work done.
>
> Please address these ASAP in some meaningful way and submit the result
> into the "f40-build-side-76936" side tag.
>

Hi Neal,

I've backported the appstream 1.0 patches to libadwaita and built it in the
side tag.

-- 
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: OK to have same license file in multiple sub-packages?

[Kalev Lember]

On Tue, Oct 31, 2023 at 5:47 PM Miroslav Suchý  wrote:

> How it conflicts?
>
> %files
>
> %license LICENSE
>
> %files doc
>
> %license LICENSE
>
> should not create any conflicts. And this is recomended way to do it.
>

I guess the conflicts happen when the LICENSE file changes between builds
and individual subpackages that ship it aren't updated in lock step. Often
there is a full NVR version requirement that locks individual subpackages
together, but not in this case. If people for example download just one of
the subpackages from koji (and not the other), it can lead to only one of
them getting updated.

Neal's idea was to make the conflict explicit so that rpm wouldn't allow
installing the subpackages if they differ in NVR.

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

Heads up: libpeas updated to 2.0 together with new libpeas1 compat package

[Kalev Lember]

Hi all,

A quick heads up that I built updated libpeas 2.0 for F39 and rawhide and
added a new libpeas1 compat package so that existing packages that use
libpeas 1.x continue working without needing changes - the libpeas API has
had a major revision in version 2.0 and it's not just the matter of
rebuilding consumers against the new version.

For GNOME 45 we need both APIs - gnome-builder 45 is using libpeas 2.0 but
most other things are still on libpeas 1.x. Totem is getting ported
upstream and was waiting on Fedora libpeas 2.0 packaging.

Dependent package maintainers: I intend to keep libpeas1 around at least as
long as it takes to get all of GNOME ported over, so there is no rush to
get everything ported, but please poke your upstreams and ask them nicely
if they want to switch over to libpeas 2.0 API. After GNOME is ported over
I may hand the package over to someone else if there are still other
packages using libpeas.

-- 
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: Specify koji build machine mem req via. spec file

[Kalev Lember]

On Thu, Oct 5, 2023 at 2:04 PM Julian Sikorski  wrote:

> Does a hammer smaller than -g1 also exist for issues like:
>
> relocation truncated to fit: R_X86_64_32 against `.debug_info'
> https://kojipkgs.fedoraproject.org//work/tasks/1615/107091615/build.log
>
> Thanks for the info in advance.
>

Sorry, I don't know, that's something slightly different. Maybe open a
ticket against gcc and ask the tools team?

-- 
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: Specify koji build machine mem req via. spec file

[Kalev Lember]

On Thu, Oct 5, 2023 at 10:07 AM Miroslav Suchý  wrote:

> Dne 04. 10. 23 v 11:43 Martin Stransky napsal(a):
> > Hello guys,
> >
> > Is there's a way how to set requested amount of ram for koji builders?
> >
> > I'd like to use it as Firefox builds fail recently due low memory, like
> > https://bugzilla.redhat.com/show_bug.cgi?id=2241690
> >
> > Thanks,
> > Martin
> >
> Related - rpm has tunables that allows you to tune the build according the
> available resources. However memory is not there:
>
> https://github.com/rpm-software-management/rpm/pull/2418
>
> https://rpm-software-management.github.io/rpm/manual/buildprocess.html


Oh, nice, I didn't know about that! From a quick look, there are actually
two memory tunables, %_smp_tasksize_proc and %_smp_tasksize_thread.

Looks like the new thing would replace the constrain_build macro that
firefox.spec is using:

Instead of current:

# Require 4 GB of RAM per CPU core
%constrain_build -m 4096

It would use:

# Require 4 GB of RAM per CPU core
%global _smp_tasksize_proc 4096

It doesn't look like a huge win from the packager's point of view, but I am
sure it's better to use the rpm upstream limits instead of external macros
such as constrain_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: Specify koji build machine mem req via. spec file

[Kalev Lember]

On Wed, Oct 4, 2023 at 11:44 AM Martin Stransky  wrote:

> Hello guys,
>
> Is there's a way how to set requested amount of ram for koji builders?
>
> I'd like to use it as Firefox builds fail recently due low memory, like
> https://bugzilla.redhat.com/show_bug.cgi?id=2241690


I looked at the first linked build log in the ticket and it looks like the
build failed in the debuginfo extraction step. In that log, find-debuginfo
is called with -j3, and it could be that it ran out of memory because it
was trying to do 3 debuginfo extractions in parallel. You could try to
stick something like this in the spec file to tune it down:

# Require 32 GB of RAM per CPU core for debuginfo processing
%global _find_debuginfo_opts %limit_build -m 32768

... and see if it helps. With this, it should pass -j1 to find-debuginfo
when the builder has 32 GB RAM, -j2 when it has 64 GB etc.

If that doesn't work, then there's also the option of using -g1 to reduce
the binary sizes so they take less memory to process (but that makes
backtraces much worse so I'd only leave it for emergencies if you can't get
an important build out otherwise).

Another option is that there's a heavybuilder channel in koji, which has
beefier machines, but it has some significant capacity issues (only 2
aarch64 builders, iirc) so it would be best to avoid it, if possible.
Chromium and webkitgtk are using it and sometimes builds have to wait a
long time after each other, especially when building something for all
Fedora branches.

Hope this helps,
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: GNOME 45.0 builds for Fedora

[Kalev Lember]

On Tue, Sep 19, 2023 at 4:09 PM Fabio Valentini 
wrote:

> On Tue, Sep 19, 2023 at 4:00 PM Kalev Lember 
> wrote:
> >
> > On Tue, Sep 19, 2023 at 3:49 PM Fabio Valentini 
> wrote:
> >>
> >> I just prepared updates for rust-glycin-utils, rust-glycin, and
> >> glycin-loaders (from the current v0.1 pre-releases to the recently
> >> published stable releases), and only just now remembered that you
> >> might want to include them in the GNOME mega-update - I'm currently
> >> building them in side tags for rawhide (f40-build-side-73970) and f39
> >> (f39-build-side-73972), but if you want, we can of course move the f39
> >> builds into the f39-gnome tag instead.
> >
> >
> > Yes, please, let me take care of these. Just out of curiosity, what
> prompted you to build the updates for glycin? Not that I'm complaining for
> the help :)
>
> Ok, let me know if there's anything I need to do. Should I submit the
> rawhide update, and let you move the f39 builds into f39-gnome?
>

Sounds like a good plan - let's do it like that.


As for why - I've been going through the pending Rust updates, and
> updating things from pre-releases to stable releases is always good in
> my experience ... and I thought I could help with something in return
> for your help with the gtk-rs updates :)
>

Ahh, I see. Thanks, I appreciate the help! :)

-- 
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: GNOME 45.0 builds for Fedora

[Kalev Lember]

On Tue, Sep 19, 2023 at 3:49 PM Fabio Valentini 
wrote:

> I just prepared updates for rust-glycin-utils, rust-glycin, and
> glycin-loaders (from the current v0.1 pre-releases to the recently
> published stable releases), and only just now remembered that you
> might want to include them in the GNOME mega-update - I'm currently
> building them in side tags for rawhide (f40-build-side-73970) and f39
> (f39-build-side-73972), but if you want, we can of course move the f39
> builds into the f39-gnome tag instead.
>

Yes, please, let me take care of these. Just out of curiosity, what
prompted you to build the updates for glycin? Not that I'm complaining for
the help :)

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

GNOME 45.0 builds for Fedora

[Kalev Lember]

Hi all,

GNOME 45.0 upstream tarball date is this weekend and I'm coordinating
the downstream builds for F39 and rawhide.

A quick note where we are in the release schedule:

Fedora 39 Beta was declared GO yesterday and is going to ship with GNOME
45.beta. We have the 45.rc mega-update in Bodhi
(https://bodhi.fedoraproject.org/updates/FEDORA-2023-d422824191) and it
is queued to stable and hopefully gets pushed to stable later tonight
once the floodgates open again after the F39 Beta freeze.

My plan is to collect all F39 builds in the f39-gnome side tag, but for
rawhide build directly for rawhide. Hopefully there are no soname bumps
between 45.rc and 45.0 complicating things.

If you are helping with builds, please do the following:

For F39, use 'fedpkg build --target f39-gnome' and I'll take care to
submit everything to bodhi as a single mega-update.

For rawhide, if you are building just a single package, build directly
in rawhide. If it's a soname bump or anything else that requires
multiple packages built together, please use a koji self-service side
tag ('fedpkg request-side-tag' while the rawhide branch is checked out)
and build using this. We sadly don't have a good way to do named side
tags (f40-gnome) for rawhide.

openQA is active in rawhide and gating updates so hopefully it prevents
any broken updates landing.

I'm going to be following the above myself and kicking off builds as
soon as they are released upstream.

If you run into any issues (or if there are soname bumps or anything
else that would complicate things), please let me know - I'm available
for sorting things out.

Thanks and looking forward to an exciting GNOME 45.0 release!

--
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: Why %{?dist} started unfolding to fc40{?with_bootstrap:~bootstrap}

[Kalev Lember]

On Fri, Aug 18, 2023 at 11:39 PM Mikhail Gavrilov <
mikhail.v.gavri...@gmail.com> wrote:

> Today %{?dist} in spec file started unfolding to
> fc40{?with_bootstrap:~bootstrap} when I builded mesa locally in the mock
> container.
> Yesterday %{?dist} unfolded to fc40 and it expected behavior.
>

Hi Mikhail,

It was a typo in a fedora-release change that caused this. See
https://pagure.io/releng/issue/11632

It should be all sorted out now though so just try building again please.

-- 
Hope this helps,
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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-08-07)

[Kalev Lember]

The Matrix/IRC bridge is down, so we didn't have the meetbot for today's
meeting.

We discussed 3 things:

1) F37 flatpak runtime retirement
2) Automatic man page compression for flatpak builds is fixed
3) Progress with switching from Modular builds to regular koji builds

Owen has done some nice work with changing the flatpak build infra to
not rely on MBS (Modular Build System), but it still needs landing in
prod to test everything together. If we can't land it before the infra
freeze in two weeks, we'll likely need to postpone the whole thing for F40.

The full meeting log follows down below.





8/7/2023, 4:01:44 PM - Kalev Lember: Welcome to our bi-weekly Flatpak 
SIG meeting.

8/7/2023, 4:01:51 PM - travier (@siosm:matrix.org) joined the room
8/7/2023, 4:01:58 PM - travier (@siosm:matrix.org): 
8/7/2023, 4:02:15 PM - Kalev Lember: We don't have the irc bridge 
operational so it's going to be a bit rough. I'll try to hand-craft 
notes afterwards.
8/7/2023, 4:02:37 PM - Kalev Lember: (We don't have the irc meeting bot, 
that's why the hand crafting meeting notes)

8/7/2023, 4:03:14 PM - Owen Taylor: Sounds fine - thanlsl for doing that!
8/7/2023, 4:03:19 PM - Kalev Lember: OK, so I have some random updates 
and I then maybe we could let Owen give a quick update about the new 
build system status?

8/7/2023, 4:03:23 PM - Kalev Lember: Great :)
8/7/2023, 4:04:09 PM - Kalev Lember: First of all, I think we should be 
done with updating everything to the F38 runtime, and there is nothing 
left on the F37 one. 
8/7/2023, 4:04:57 PM - Kalev Lember: So I went ahead and pushed the 
thing that are needed to mark the F37 runtime as EOL. The EOL'ing update 
is still in testing so if anyone finds something that still uses the F37 
runtime we can hold it back still.
8/7/2023, 4:05:14 PM - Kalev Lember: 
https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-4f477c1954
8/7/2023, 4:05:50 PM - Kalev Lember: Second, I looked into the man page 
compression issue where we didn't get automatic man page gzip 
compression for flatpak /app builds
8/7/2023, 4:06:35 PM - Kalev Lember: It turned out to be a fairly 
trivial fix and hopefully we won't need to go and change all the 
packages any more for flatpak support :) 
https://src.fedoraproject.org/rpms/flatpak-rpm-macros/c/237fc133a30759a1f75a9b0fd4b577a9c5f3190c?branch=rawhide
8/7/2023, 4:06:44 PM - Kalev Lember: I can't believe we didn't try to 
figure it out earlier :)
8/7/2023, 4:08:05 PM - Owen Taylor: Hmm . I think I assumed it would 
require upstream RPM changes - or maybe it even did
8/7/2023, 4:08:33 PM - Kalev Lember: Yeah, I guess I too thought it 
would be complicated :)
8/7/2023, 4:08:40 PM - Kalev Lember: Anyway, that was my updates. Owen, 
the floor is all yours!
8/7/2023, 4:11:12 PM - Owen Taylor: Hmmm ... I guess the basic status is 
"orange" for F40 - I have things more or less fully working, but the 
infrastructure isn't there, and we're two weeks off of the beta 
infrastructure freeze
8/7/2023, 4:12:00 PM - Kalev Lember: should we postpone it to F40 and 
keep on using mbs for F39?
8/7/2023, 4:13:15 PM - Owen Taylor: Let's wait just a bit before making 
that call. After all, we wouldn't typically start working on F39 
Flatpaks until around the beta And maybe I can get it done.

8/7/2023, 4:13:34 PM - Owen Taylor: What is needed to get it done:
8/7/2023, 4:13:42 PM - Kalev Lember: Makes sense to me.
8/7/2023, 4:14:46 PM - Owen Taylor:  A) Fix a couple of remaining issues 
in flatpak-module-tools and koji-flatpaks - the top issues are that I 
don't have arch-specific package support and release numbering is still 
wonky

8/7/2023, 4:15:03 PM - Owen Taylor: B) Get koji-flatpak packaged in Fedora
8/7/2023, 4:15:18 PM - Owen Taylor:  C) Get it onto the staging builders 
... test it out there in some fashion

8/7/2023, 4:15:24 PM - Owen Taylor:  D) Push it live
8/7/2023, 4:15:35 PM - Owen Taylor: That's more-or-less the tasks.
8/7/2023, 4:16:20 PM - Kalev Lember: Oh, about release number - I was 
wondering if you could do it in a way that's similar to eln, where 
there's .eln127, .eln128 etc suffixes to dist tag?
8/7/2023, 4:16:34 PM - Kalev Lember: That would allow us to easily 
rebuild things if we get maybe ordering wrong
8/7/2023, 4:17:21 PM - Owen Taylor: 
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/16 is 
the tracking bug for release numbering
8/7/2023, 4:17:55 PM - Kalev Lember: Like, someone pushes a rebuild for 
a new library to dist-git, we rebuild it for /app but get the order 
wrong, so it's still rebuilt against the old library.
8/7/2023, 4:18:01 PM - Owen Taylor: My initial proposal was 
firefox-flatpak-112.0.2-1 where we use a different koji name
8/7/2023, 4:18:11 PM - Kalev Lember: eln would just bump distro version 
and get a new, higher dist tag in that case
8/7/2023, 4:19:02 PM - Owen Taylor: Ah, yeah, I'm actually talking about 
t

Re: GNOME 45.beta builds for Fedora

[Kalev Lember]

On Mon, Aug 7, 2023 at 5:54 PM Adam Williamson 
wrote:

> On Mon, 2023-08-07 at 12:24 +0200, Kalev Lember wrote:
> > It's also fine to build directly in rawhide if it's just a single
> > package update that doesn't depend on anything else. We are still a
> > while from Bodhi activation point for F39 so we won't be doing
> > mega-updates yet that require everything to be built together in a
> > single side tag.
>
> Well, that's a bit of a wrongly-named milestone these days.
> *Everything* goes through Bodhi all the time. The only thing that
> changes at the "Bodhi activation point" these days is that the
> time/karma requirements kick in. So I'm a bit confused as to why you'd
> do a mega-update for branched releases but not for Rawhide? What's the
> difference?
>

Right, so to expand on this a bit: Most GNOME package updates are actually
self contained and library ABI is almost always backwards compatible.
_Sometimes_ they are not and we need to coordinate stuff to land at the
same time, but more often than not modules can be updated one by one.

Most of the time the following works fine in rawhide and can be two
distinct steps:

 1) Update package A to version 1.2
 2) Update package B to new version that requires A >= 1.2

This however all breaks apart when we are in a freeze, or when package
updates that land in build roots are delayed by a week (after the somewhat
badly named "Bodhi Activation Point"). The reason this doesn't work any
more then is that the time for packages to land in the base repo is just
too long to be able to reasonably do updates separately.

Hence, we do mega-updates: a large update that includes both package A
version 1.2, and package B that requires the new version of A. This solves
the problem with time, so that we can prepare everything in a side tag and
get everything through testing together, as a single unit. For rawhide, and
branched before the Bodhi Activation Point (which like you pointed out, is
a misnomer) this is unnecessary because builds can land in the base repo
quickly.

Now, why don't we use the same mega-update system for rawhide? I can think
of a few reasons:
1) In my opinion, it's best to update packages aggressively, so that we can
get them out to testers (and to openQA hands) as quickly as possible. This
gives us early feedback and makes it much easier to deal with issues, as
they then arise one by one, and we immediately know which package is at
fault.

2) Coordination: It's much easier to coordinate package builds with other
work happening in rawhide if we can integrate everything quickly into the
same repo. Side tags work fine if we don't expect other people to work on
the same packages, but rawhide often gets soname bumps in other, non-GNOME
packages and they need to be able to get packages rebuilt, without waiting
for a long time for GNOME side tags to land.

3) Named side tags (f39-gnome) have certain issues for rawhide (which we
talked about on the releng channel not long ago) and while I like having
them around so it's easier to coordinate with all the people working on
GNOME packaging when we need to land things as a single unit, it doesn't
scale very well (needs work from my side to merge etc). Because of that, I
think it's best to land builds that are self-contained separately in
rawhide.

A piece of a puzzle that made it all possible not long ago is the
activation of openQA gating that makes it possible to test updates
individually. Before that, a human could only run so many integration tests
and it realistically only worked to test all of the updates together. Now
with openQA, we can be reasonably sure that an individual update doesn't
regress the base OS.


Now, for Branched after the Bodhi Activation Point, up until the GA release
(at this point, we should be ABI stable so packages can land separately
again), I think it makes a lot of sense to do mega-updates all the time:

1) We get a way to land a GNOME release all as a single unit if we need to
pull it through a freeze. Once we've started rebuilding packages against
new versions of libraries then the whole unit becomes pretty much
inseparable.

2) We can test the whole thing together (+-karma) - for humans, it doesn't
scale to test updates separately, there's just too many combinations

At this point, I got tired of typing :) What do you think, does it make
sense?

-- 
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: GNOME 45.beta builds for Fedora

[Kalev Lember]

On Mon, Aug 7, 2023 at 12:34 PM Fabio Valentini 
wrote:

> On Mon, Aug 7, 2023 at 12:26 PM Kalev Lember 
> wrote:
> Hi Kalev,
>
> Might it be a better idea to wait with building things until *after*
> the mass branching?
>
> I have only ever seen things fail when rawhide side tags were kept
> open during the mass branching. It might be different for
> releng-managed side tags, but for on-demand side tags, you will only
> be able to merge them into *one* release (i.e. the new F39 release),
> and not two, so you'd need to build a second time for rawhide anyway.
>

Hi Fabio,

I am aware of the issues around branching - that's why I asked people to
avoid doing builds during the branching event (Tuesday). Anything that gets
built in the side tag before that can hopefully get merged before the
branching, so the builds get into both f39 and rawhide. I'm keeping a close
eye on this and cleaning things up if needed. There aren't many packages
that need to be built in the side tag this time around (mostly gnome-shell
and friends) and that makes it much simpler.

It's also not a releng-managed side tag, it's Kalev-managed :)

You made a good point though and thanks for raising it! Due to the F39
branching on Tuesday (and freezing the repos until the composes pass again)
we don't have a lot of days where builds can flow freely and today is one
of them, and I don't want to waste it - we don't have a lot of time left
until the planned GNOME test week.

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

GNOME 45.beta builds for Fedora

[Kalev Lember]

Hi all,

I'm coordinating GNOME builds for Fedora this cycle and we have GNOME
45.beta release coming up. The upstream tarball date was in the weekend,
but a lot of modules are still missing releases and I expect them to
trickle in during the first half of the weekend.

At the same time, on Fedora side we have the F39 branching tomorrow
(Tuesday) which hopefully shouldn't affect this too much. The plan is to
try to build things as much as possible in rawhide ahead of the
branching and then avoid builds during the branching event to make sure
we don't end up in inconsistent states between F39 and rawhide.

Next week the Workstation WG hopes to run a GNOME 45.beta test week and
we should try and get everything lined up for that.

For anyone helping with the builds - we have a f39-gnome side tag for
F39. Please use this if you need to do a multi-package build that needs
some kind of coordination - Florian if you do Shell builds please use
that and I'll help get it merged after the builds are done (it's a bit
special until the branching event). Let me know if any dependencies are
missing.

It's also fine to build directly in rawhide if it's just a single
package update that doesn't depend on anything else. We are still a
while from Bodhi activation point for F39 so we won't be doing
mega-updates yet that require everything to be built together in a
single side tag.

Rawhide has openqa active which makes it nicer and safer to do builds
because we know that the core of the OS is going to get tested for each
build, and builds are not merged into rawhide if the tests don't pass.

Thanks everybody and I'll be on irc/matrix for further coordination.

--
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: Orphaning packages (was LibreOffice packages)

[Kalev Lember]

On 7/3/23 09:23, Victor Toso wrote:

On Sat, Jul 01, 2023 at 10:09:15PM +0200, Kalev Lember wrote:

Victor (CC'd), do you want to pick up grilo and grilo-plugins?


Sure, I'll keep maintaining both in Fedora.


Excellent! Can you click on the "Take" button at
https://src.fedoraproject.org/rpms/grilo and
https://src.fedoraproject.org/rpms/grilo-plugins ? Bastien was the
package owner before and now they are orphaned.

--
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: Orphaning packages (was LibreOffice packages)

[Kalev Lember]

On 6/29/23 16:47, Bastien Nocera wrote:

Hello,

As part of the same process outlined in Matthias Clasen's "LibreOffice 
packages" email, my upstream and downstream work on desktop Bluetooth, multimedia 
applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being 
stopped, and all the rest of my upstream and downstream work will be reassigned depending 
on Red Hat's own priorities, as I am transferred to another team.

While it's possible that some of the maintenance will stay with me in the new 
team, I've not yet been told which team I would be joining.

Here is a list of Fedora packages which I maintained or co-maintained which I 
won't be able to contribute to anymore:
apfs-fuse
bluez
codespell
eosrei-emojione-fonts
geocode-glib
gnome-bluetooth
gnome-epub-thumbnailer
gnome-kra-ora-thumbnailer
gnome-user-share
gom
grilo
grilo-plugins
ifuse
iio-sensor-proxy
libfprint
libglib-testing
libimobiledevice
libpeas
libplist
libportal
libusbmuxd
low-memory-monitor
malcontent
power-profiles-daemon
sloccount
switcheroo-control
totem
totem-pl-parser
umockdev
usbmuxd


I went ahead and picked up some of the GNOME packages from the list:

gnome-bluetooth
gnome-user-share
gom
libglib-testing
libpeas
libportal
totem
totem-pl-parser

Victor (CC'd), do you want to pick up grilo and grilo-plugins?

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

[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: 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: Is there a chance to phase out `/lib64` directory?

[Kalev Lember]

On Tue, Jun 27, 2023 at 11:02 AM Vít Ondruch  wrote:

> I don't think that GCC is always the best example to follow.
>
> Nevertheless, wouldn't it be worth of phasing out the /lib64? I don't
> know what is the history behind, but I don't think this layout is
> conceptual.
>

I would like to have a layout similar to what Debian is doing, so that
shared libraries would go in /usr/lib/x86_64-redhat-linux/ and /usr/lib64
would be a legacy symlink pointing to it.

That kind of layout would make it much easier to do cross compilation
because you could just take the whole /usr/lib/another-host-triplet/
directory from another architecture without it interfering with the host
libraries and use it for cross compilation purposes.

It would be a lot of work transitioning to a new layout though.

-- 
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: releng-bot owns my package in SCM - belcard

[Kalev Lember]

On Sun, Jun 18, 2023 at 12:01 PM Philip Wyett 
wrote:

> Hi,
>
> After completing a package-review for belcard[1], I tried to create the
> repo, seems that the repo
> after a couple of attempts got created, but is owned by 'releng-bot' and
> not myself 'kathenas'. How
> can I get this resolved?
>

Hi Phil,

I would file a releng ticket at https://pagure.io/releng/issues

-- 
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: Fedora ELN Plans for Summer 2023

[Kalev Lember]

On Fri, Jun 16, 2023 at 6:08 PM Todd Zullinger  wrote:

> Stephen Gallagher wrote:
> > On Fri, Jun 16, 2023 at 11:53 AM Miro Hrončok 
> wrote:
> >>
> >> On 16. 06. 23 15:39, Stephen Gallagher wrote:
> >>> This leads me to my next schedule announcement: we will be performing
> >>> the initial CentOS Stream 10 branch creation in Gitlab for all
> >>> packages in the Fedora ELN runtime package set[1]  during the week of
> >>> July 19th, coincident with the Fedora 39 mass-rebuild.
> >>
> >> Will you please, please, please, please import the packages with git
> history
> >> and not via fepdkg srpm -> centpkg import?
> >
> > YES!
>
> Excellent news!  As someone who takes git history (maybe a
> little too) seriously, this is quite welcome.  Thanks to
> all who helped make the change. :)
>

YES!

Excellent, that is going to make my life a lot easier trying to keep GNOME
packages in CentOS Stream 10 up to date (can easily cherry-pick commits)!

Thanks!

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-06-12)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 14:00:07 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-06-12/flatpak-sig.2023-06-12-14.00.log.html
.



Meeting summary
---
* Init process  (kalev, 14:00:07)

* Announcements  (kalev, 14:02:19)

* status update on FlatpaksWithoutModules  (kalev, 14:05:06)
  * Owen has been working on the implementation and we're planning for
landing it for F39.  (KalevLember[m], 14:33:19)

* flatpak container builds broken  (kalev, 14:44:33)
  * LINK:
https://src.fedoraproject.org/flatpaks/stellarium/pull-request/2
(yselkowitz[m], 14:53:22)

Meeting ended at 14:59:05 UTC.




Action Items






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




People Present (lines said)
---
* OwenTaylor[m] (31)
* KalevLember[m] (24)
* kalev (20)
* zodbot (13)
* yselkowitz[m] (10)
* tpopela[m] (7)
* JanGrulich[m] (1)
* matthiasc[m] (1)
* travier (1)




Generated by `MeetBot`_ 0.4

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-05-15)

[Kalev Lember]

It's a bit hard to read format this time because zodbot dropped off irc
half way through and I had to manually capture the log from my irc client.

16:01 < kalev> #startmeeting Fedora Flatpak Packaging SIG
16:01 < kalev> #meetingname flatpak-sig
16:01 < kalev> #topic Init process
16:01 < zodbot> Meeting started Mon May 15 14:01:09 2023 UTC.
16:01 < zodbot> This meeting is logged and archived in a public location.
16:01 < zodbot> The chair is kalev. Information about MeetBot at 
https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:01 < zodbot> Useful Commands: #action #agreed #halp #info #idea #link 
#topic.
16:01 -!- zodbot changed the topic of #fedora-meeting to:  (Meeting 
topic: Fedora Flatpak Packaging SIG)
16:01 < zodbot> The meeting name has been set to 
'fedora_flatpak_packaging_sig'

16:01 < zodbot> The meeting name has been set to 'flatpak-sig'
16:01 -!- zodbot changed the topic of #fedora-meeting to: Init process 
(Meeting topic: Fedora Flatpak Packaging SIG)

16:01 <+tpopela[m]> .hello tpopela
16:01 < zodbot> tpopela[m]: tpopela 'Tomas Popela' 
16:01 <+OwenTaylor[m]> .hello otaylor
16:01 < zodbot> OwenTaylor[m]: otaylor 'Owen Taylor' 
16:01 < kalev> we should have a lot to discuss today about Owen's proposals
16:02 <+JanGrulich[m]> .hello jgrulich
16:02 < zodbot> JanGrulich[m]: jgrulich 'Jan Grulich' 
16:03 < kalev> I think we have almost everyone here now. yselkowitz[m] 
usually comes half an hour late I believe.

16:04 < kalev> #topic Flatpaks without Modules
16:04 -!- zodbot changed the topic of #fedora-meeting to: Flatpaks 
without Modules (Meeting topic: Fedora Flatpak Packaging SIG)

16:04 < kalev> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules
16:04 < kalev> sooo, Owen posted the change proposal and I think it 
would be good to discuss this a bit

16:05 < travier> .hello siosm
16:05 < zodbot> travier: siosm 'Timothée Ravier' 
16:05 < travier> 
16:05 < kalev> I myself think it's a major improvement over the way we 
do flatpaks now. Using standard koji tags makes everything so much 
easier to understand for most of the Fedora packagers
16:05 < kalev> OwenTaylor[m]: are there any specific points we should 
talk about?
16:06 < kalev> when looking at the proposed tag structure, I noticed two 
things
16:06 <+OwenTaylor[m]> Maybe I first should ask if anybody has questions 
- is the general way it's going to work clear to people? I'm sure that 
some details will have to be worked out as we go
16:07 < kalev> one is that there's a bit of an inconsisteny between 
f39-flatpak-runtime and f39-app tags naming - one has "flatpak" in it 
and the other doesn't
16:07 <+OwenTaylor[m]> I filed 
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/17 to 
track that

16:07 < kalev> ah nice, I missed that
16:08 <+OwenTaylor[m]> I'm fine with the second version in there where 
the tags have flatpaks but the %dist are without it. While the 'f38-app' 
thing made sense to me at the time, I certainly appreciate that 
consistency is good
16:09 <+JanGrulich[m]> I assumed '-app' means like application, it never 
occured to me it means just a different prefix

16:10 < kalev> same here :)
16:10 < sberg> +1
16:11 <+OwenTaylor[m]> I think we can just go with f38-flatpak-app. 
Anybody have opinions about the two questions at the bottom of the ticket?
16:12 < kalev> regarding the %dist tag names, there's a bit of an 
ordering question. Do we need the flatpak NVRs to be higher than 
non-flatpak ones? I think it doesn't matter, but not entirely sure
16:12 < kalev> Fedora hasn't moved from fcXX to fXX because of ordering: 
f39 sorts lower for rpm ordering than fc39, I believe
16:12 -!- misuto7 [~misuto@159.223.226.171] has quit [Remote host closed 
the connection]

16:13 -!- misuto7 [~misuto@159.223.226.171] has joined #fedora-meeting
16:13 <+OwenTaylor[m]> Hmmm. I dont' thnk you want to rely on ordering, 
then you could accidentally pull in a non-Flatpak build that was newer.
16:14 -!- misuto7 [~misuto@159.223.226.171] has quit [Remote host closed 
the connection]

16:14 -!- misuto7 [~misuto@159.223.226.171] has joined #fedora-meeting
16:15 <+OwenTaylor[m]> My thought right now is to hav e dnf 
configuration 
includepkgs=abattis-cantarell-fonts,acl,adobe-source-code-pro-fonts,...,(rest 
of runtime packages),*.fc39app

16:16 < kalev> makes sense to me
16:16 <+OwenTaylor[m]> This is a slight variation on the way it works 
right now, where we have a big includepkgs that the runtime packages, 
and then includes the particular NVR's from the composed Flatpak modules
16:17 < kalev> the variation being that the *.fc39app packages would be 
automatically depsolved and included, without an explicit include list?
16:18 <+OwenTaylor[m]> Yeah - anything in the *.f39app (hmmm, apparently 
I can't keep .fc39app vs .f39app straight...)

16:18 <+OwenTaylor[m]> would just be available for installation
16:19 < kalev> I think that's a good simplification and makes it easier 
to create flatpaks
16:20 < kalev> 

Re: disabling yum modular repos by default?

[Kalev Lember]

On Tue, May 9, 2023 at 1:27 PM Neal Gompa  wrote:

> On Tue, May 9, 2023 at 12:32 AM Jens-Ulrik Petersen 
> wrote:
> >
> > I have been thinking about proposing a Change to Fedora 39,
> > which would disable yum modular repos by default in installs.
> > I thought I would float the idea here first.
> >
> > I suspect the vast majority of Fedora users don't use
> > the modular repos, so I don't see the point of enabling
> > them by default anymore. Does this make sense?
> >
> > I know dnf5 is coming with performance improvements
> > but I still think turning off the modular repos would speed up dnf
> > and save users a lot of time.
> >
>
> I'm okay with this. The only case I had for using modular repos was
> Nodejs, but that is demodularizing now.
>
> >
> > ps I think it would be a good idea to disable the cisco-h264 repo too by
> default in the fedora container image, and maybe also for headless Fedora
> editions.
>
> Please don't do this, as ffmpeg will pull the codec in if available,
> and there are tons of headless use-cases for ffmpeg that make the
> availability of this codec useful. It's also a really tiny repository
> anyway...
>

I'd like to second to what Neal said. I think it makes sense to disable the
modular repos by default, but I'd rather keep the cisco openh264 repo
enabled.

-- 
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: Orphaning despite having maintainers?

[Kalev Lember]

On Wed, Apr 26, 2023 at 11:04 AM Alexander Bokovoy 
wrote:

> Hi,
>
> This morning I woke up to find that packages I maintain were orphaned
> out of blue. Nobody contacted the maintainers, nobody raised any tickets
> to releng, as far as I can see. Yet, releng ran the orphaning from what
> I saw in a few bugs.
>
> What is happening? Who and how made those decisions?
>

This looks to be due to inactive packager removal,
https://pagure.io/fedora-infrastructure/issue/11271

I picked up a few GNOME-related packages that got orphaned in the process.

-- 
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: Auto-assign packager sponsors to tickets?

[Kalev Lember]

On Tue, Apr 4, 2023 at 9:22 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 04/04/2023 07:52, Otto Liljalaakso wrote:
> > Perhaps new package requests could more often be handled in a way where
> > an existing packager assumes the maintainer position with the agreement
> > that the submitter keeps the packager updated and in good condition,
> > through pull requests.
>
> We have a serious problem here: non-packages can't upload sources to
> Fedora SCM.
>
> These pull requests require maintainers to do it manually in a separate
> commit that breaks %autorelease+%autochangelog.
>

That's not exactly true. Yes, non-packagers can't upload files to the
lookaside cache, but they can update the 'sources' and '.gitignore' files
in git.

The easiest way to do that is with 'fedpkg new-sources --offline' which
then only does the local modifications that can be committed to git (and
submitted as a PR), but doesn't upload the files to the lookaside cache
servers.

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-04-03)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 14:00:19 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-04-03/flatpak-sig.2023-04-03-14.00.log.html
.



Meeting summary
---
* Init process  (kalev, 14:00:19)

* F38 status  (kalev, 14:02:57)

* defolos would like to propose to use kiwi for flatpak building
  (kalev, 14:18:00)
  * kiwi could replace OSBS for building the flatpak containers  (kalev,
14:46:26)
  * Bigger pain point right now is MBS. One idea that most people agree
on are using custom koji side tags. Still need to figure out the
details.  (kalev, 14:47:15)

Meeting ended at 14:59:30 UTC.




Action Items






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




People Present (lines said)
---
* kalev (77)
* Eighth_Doctor (22)
* defolos (20)
* zodbot (14)
* yselkowitz[m]1 (10)
* travier (6)
* OwenTaylor[m] (5)
* tpopela[m] (4)
* rishi (1)
* JanGrulich[m] (1)
* smooge (1)




Generated by `MeetBot`_ 0.4

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

Re: F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)

[Kalev Lember]

On Wed, Mar 29, 2023 at 12:30 PM Miroslav Suchý  wrote:

> Dne 28. 03. 23 v 16:01 Zbigniew Jędrzejewski-Szmek napsal(a):
> > Hmm, that'd mean thousands of pull requests… I think if we agree to
> > this, it would make sense to just push a fix directly. Each pull request
> > ticket is a few mails, and with 8096 expected pull requests, that is
> > quite a lot of churn.
>
> I am trying to be as polite as possible. And respectful to work of
> maintainers.
>
> Rel-engs bumping release because of mass-rebuild is trivial thing and
> doing direct push is right thing.
>
> But is the change of the license string trivial thing? I do not know. If
> most people (and FESCO) tell me "yeah, push
> directly" then I can push directly. PRs are definitelly more work for me
> (and owners of this proposal). But I am willing
> to do that.
>

Yes, please push directly.  I completely agree with Zbigniew and don't
think that PRs work super well for mass changes like this. However, this
definitely needs FESCo approval first and communication (
https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/) before
pushing.

Package changes are tracked in git and it's trivial for a
package maintainer to revert it for an individual package if needed.

-- 
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 proposal: Changes of defaults in createrepo_c-1.0.0 (System-Wide Change proposal)

[Kalev Lember]

On Sun, Mar 26, 2023 at 5:06 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> We should probably make it ^(/etc/|/bin/|/sbin/|/usr/bin/|/usr/sbin/).
> Split-usr
> distros are a blast from the past, but adding the extra paths wouldn't
> change
> anything for us, since we don't use them.
>

Please add /app/bin/ and /app/sbin/ as well to that list for flatpak rpm
builds.

-- 
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: Status of AVIF support in Fedora

[Kalev Lember]

On Mon, Mar 20, 2023 at 7:29 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 20/03/2023 17:08, Dominik 'Rathann' Mierzejewski wrote:
> > Going forward, I'm going to turn it into an add-on package, i.e. ship
> > only the two plugins we can't ship in Fedora:
>
> In a subpackage libheif-freeworld?
>

I think it would look cleaner to name them according to the plugins, so
that it would be:

%files -n libheif-libde265
%{_libdir}/libheif/libheif-libde265.so

%files -n libheif-x265
%{_libdir}/libheif/libheif-x265.so

and then add reverse soft deps from the newly added packages to the libheif
package so that they'd get pulled in when enabling rpmfusion. Although
thinking about it some more, there was a somewhat recent dnf change that
made it not pull in newly added soft deps, so maybe this approach would not
work so well after all, at least not to automatically pull in the extra
plugins ...

Anyway, libheif-freeworld sounds to me more like something that would
replace the entire libheif package with an alternative version. In this
case, it's only two additional plugins and I think it would be better to
avoid the -freeworld pattern here.

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-03-20)

[Kalev Lember]

===
#fedora-meeting-2: Fedora Flatpak Packaging SIG
===


Meeting started by kalev at 15:03:20 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-03-20/flatpak-sig.2023-03-20-15.03.log.html
.



Meeting summary
---
* Init process  (kalev, 15:03:20)

* Fedora 38  (kalev, 15:07:30)
  * LINK: https://paste.centos.org/view/af48818f would be the diff what
gets dropped  (kalev, 15:47:15)
  * AGREED: Drop Qt 5 from the Fedora runtime (we never had Qt 6 in the
runtime) for F38, and move both Qt 5 and Qt 6 to flatpak-common for
F38  (kalev, 15:58:10)
  * Still need to figure out how to best make qgnomeplatform get
installed when Qt is built as part of flatpak-common and is not part
of the runtime  (kalev, 15:58:59)

Meeting ended at 16:00:34 UTC.




Action Items






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




People Present (lines said)
---
* kalev (71)
* OwenTaylor[m] (20)
* zodbot (8)
* tpopela[m] (8)
* AllanDay[m] (1)




Generated by `MeetBot`_ 0.4

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

Re: The GPG keys listed for the "Fedora rawhide openh264 (From Cisco) - x86_64" repository are already installed but they are not correct for this package.

[Kalev Lember]

On Fri, Mar 17, 2023 at 3:47 PM Reon Beon via devel <
devel@lists.fedoraproject.org> wrote:

> Fedora rawhide openh264 (From Cisco) - x86_64   1.6 MB/s | 1.6 kB
>  00:00
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64
> (0x18B8E74C) is already installed
> The GPG keys listed for the "Fedora rawhide openh264 (From Cisco) -
> x86_64" repository are already installed but they are not correct for this
> package.
> Check that the correct key URLs are configured for this repository..
> Failing package is: gstreamer1-plugin-openh264-1.22.1-1.fc38.x86_64
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64
> Public key for mozilla-openh264-2.3.1-2.fc38.x86_64.rpm is not installed.
> Failing package is: mozilla-openh264-2.3.1-2.fc38.x86_64
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64
> Public key for openh264-2.3.1-2.fc38.x86_64.rpm is not installed. Failing
> package is: openh264-2.3.1-2.fc38.x86_64
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide-x86_64
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>

This is tracked in https://pagure.io/releng/issue/11334

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-03-06)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 15:00:19 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-03-06/flatpak-sig.2023-03-06-15.00.log.html
.



Meeting summary
---
* Init process  (kalev, 15:00:19)

* Announcements  (kalev, 15:05:25)
  * We have initial KDE 5 and 6 runtimes for KDE apps, thanks to
yselkowitz  (kalev, 15:05:34)
  * On top of that, yselkowitz converted a number of KDE apps that
Kinoite needs and a bunch more  (kalev, 15:05:37)
  * Two long standing issues with the regular (non-KDE) runtime got
fixed and we now include gnome-user-docs that's needed for Help
contents, and hunspell dictionaries  (kalev, 15:05:40)
  * we have
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues for
tracking issues thanks to Allan  (kalev, 15:09:03)
  * LINK:

https://src.fedoraproject.org/flatpaks/flatpak-runtime/c/a620aa46a8f83b8ed504ecda7b2478580198f340?branch=f37
is how they are synced  (kalev, 15:13:10)
  * per-user icon themes should now be available in the sandbox -

https://src.fedoraproject.org/flatpaks/flatpak-runtime/c/dee5e14609df2f94b2dbdf92321cae126710cdbc?branch=f37
(kalev, 15:14:57)

* Fontconfig issues  (kalev, 15:16:10)
  * LINK: https://github.com/fedora-silverblue/issue-tracker/issues/305
(kalev, 15:16:12)

* KDE apps and runtimes  (kalev, 15:24:28)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/1
(kalev, 15:24:33)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/2
(kalev, 15:24:47)
  * LINK: https://src.fedoraproject.org/group/kde-sig > kde-sig sorry
(travier, 15:36:27)
  * LINK: https://docs.fedoraproject.org/en-US/fesco/SIG_policy/
(kalev, 15:43:46)

Meeting ended at 15:47:18 UTC.




Action Items






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




People Present (lines said)
---
* kalev (67)
* zodbot (15)
* travier (15)
* smooge (9)
* sberg (5)
* matthiasc[m] (2)
* geraldosimiao (1)
* JanGrulich[m] (1)




Generated by `MeetBot`_ 0.4

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

Re: Some boost breakage in Fedora Rawhide

[Kalev Lember]

On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> The problem is more widespread :(
>
> $ (dnf5 repoquery --whatrequires 'libboost_thread.so.1.78.0()(64bit)';
> dnf5 repoquery --whatrequires 'libboost_iostreams.so.1.78.0()(64bit)'; dnf5
> repoquery --whatrequires 'libboost_system.so.1.78.0()(64bit)') 2>/dev/null
> | sort -u
>
> Field3D-0:1.7.3-20.fc38.x86_64
> FlightCrew-cli-0:0.9.1-30.fc38.x86_64
> FlightCrew-sigil-plugin-0:0.9.1-30.fc38.x86_64
> OpenImageIO-0:2.4.8.1-1.fc39.x86_64
> anyterm-0:1.2.3-14.fc38.x86_64
> aqsis-0:1.8.2-50.fc38.x86_64
> aqsis-core-0:1.8.2-50.fc38.x86_64
> aqsis-libs-0:1.8.2-50.fc38.x86_64
> bear-engine-0:0.7.0-0.40.20200220git2a78522.fc38.x86_64
> boost-http-server-0:0-5.20220116gitcd5245f.fc38.x86_64
> boost-locale-0:1.78.0-11.fc38.x86_64
> boost-log-0:1.78.0-11.fc38.x86_64
> boost-type_erasure-0:1.78.0-11.fc38.x86_64
> boost-wave-0:1.78.0-11.fc38.x86_64
> btbuilder-0:0.5.19-4.fc38.x86_64
> ceph-common-2:17.2.5-11.fc39.x86_64
> ceph-exporter-2:17.2.5-11.fc39.x86_64
> ceph-osd-2:17.2.5-11.fc39.x86_64
> ceph-radosgw-2:17.2.5-11.fc39.x86_64
> ceph-test-2:17.2.5-11.fc39.x86_64
> codeblocks-contrib-0:20.03-16.20230124svn13161.fc38.x86_64
> cpp-hocon-0:0.3.0-26.fc38.x86_64
> cryfs-0:0.11.2-6.fc38.x86_64
> dmlite-dome-0:1.15.2-13.fc38.x86_64
> dmlite-dpm-xrootd-0:1.15.2-13.fc38.x86_64
> dmlite-libs-0:1.15.2-13.fc38.x86_64
> dmlite-plugins-domeadapter-0:1.15.2-13.fc38.x86_64
> dmlite-plugins-mysql-0:1.15.2-13.fc38.x86_64
> dolfin-0:2019.1.0.post0-37.fc38.x86_64
> domoticz-0:2022.1-6.fc38.x86_64
> dssp-0:3.0.0-16.fc37.x86_64
> dyninst-0:12.2.0-2.fc38.x86_64
> eclib-0:20221012-4.fc38.x86_64
> fastnetmon-0:1.2.1-5.20220528git420e7b8.fc38.x86_64
> fcitx5-chinese-addons-0:5.0.16-2.fc38.x86_64
> flamerobin-0:0.9.3.1-24.fc38.x86_64
> freecad-1:0.20.2-3.fc38.x86_64
> freeopcua-0:0-37.20220717.bd13aee.fc38.x86_64
> gazebo-0:10.1.0-34.fc38.x86_64
> gazebo-libs-0:10.1.0-34.fc38.x86_64
> gazebo-ode-0:10.1.0-34.fc38.x86_64
> glob2-0:0.9.4.4-61.fc38.x86_64
> gnuradio-0:3.10.4.0-6.fc38.x86_64
> gr-osmosdr-0:0.2.4-3.fc38.x86_64
> guitarix-0:0.44.1-4.fc38.x86_64
> heaptrack-0:1.2.0-11.fc38.x86_64
> innoextract-0:1.9-9.fc38.x86_64
> kea-hooks-0:2.2.0-3.fc38.x86_64
> kea-libs-0:2.2.0-3.fc38.x86_64
> ledger-0:3.2.1-11.fc38.x86_64
> lgogdownloader-0:3.9-3.fc38.x86_64
> libime-0:1.0.15-2.fc38.x86_64
> libkolabxml-0:1.2.0-15.fc38.x86_64
> liblas-0:1.8.2-0.4.gitded4637.fc38.x86_64
> liborcus-0:0.17.2-8.fc38.x86_64
> liborcus-model-0:0.17.2-8.fc38.x86_64
> libphonenumber-0:8.12.57-6.fc38.x86_64
> librados2-2:17.2.5-11.fc39.x86_64
> librgw2-2:17.2.5-11.fc39.x86_64
> libzypp-0:17.31.1-2.fc38.x86_64
> lucene++-0:3.0.7-36.fc38.x86_64
> lunchbox-devel-0:1.17.0-7.fc38.x86_64
> luxcorerender-core-0:2.6-19.fc38.x86_64
> lv2-c++-tools-devel-0:1.0.5-16.fc38.x86_64
> maeparser-0:1.3.1-1.fc38.x86_64
> mapnik-0:3.1.0-24.fc38.x86_64
> mapnik-utils-0:3.1.0-24.fc38.x86_64
> mir-server-libs-0:2.12.0-1.fc38.x86_64
> mmseq-0:1.0.11-14.fc38.x86_64
> ncmpcpp-0:0.9.2-11.fc38.x86_64
> nextpnr-0:1-16.20230104gita46afc6.fc38.x86_64
> ogre-1:1.9.0-43.fc38.x86_64
> ogre-terrain-1:1.9.0-43.fc38.x86_64
> ogre-volume-1:1.9.0-43.fc38.x86_64
> openshadinglanguage-libs-0:1.12.9.0-1.fc38.x86_64
> opentrep-0:0.07.11-5.fc38.x86_64
> openvdb-libs-0:10.0.1-1.fc38.x86_64
> pcl-0:1.12.0-25.fc38.x86_64
> poedit-0:3.2.2-3.fc38.x86_64
> pokerth-0:1.1.2-24.fc38.x86_64
> povray-0:3.7.0.10-9.fc38.x86_64
> prusa-slicer-0:2.4.2-7.fc38.x86_64
> python-tdlib-0:0.9.2-6.20210929.e8ec911.fc38.x86_64
> python3-gattlib-0:0.20210616-3.fc38.x86_64
> python3-graph-tool-0:2.45-6.fc38.x86_64
> python3-luxcorerender-0:2.6-19.fc38.x86_64
> python3-mapnik-0:3.0.23-22.20200224git7da019c.fc38.x86_64
> radiotray-ng-0:0.2.8-8.fc38.x86_64
> rstudio-0:2022.12.0+353-1.fc38.x86_64
> rstudio-desktop-0:2022.12.0+353-1.fc38.x86_64
> rstudio-server-0:2022.12.0+353-1.fc38.x86_64
> simspark-0:0.3.3-6.fc38.x86_64
> slic3r-0:1.3.0-28.fc38.x86_64
> smesh-0:9.8.0.2-5.fc38.x86_64
> snapper-0:0.10.1-2.fc37.x86_64
> snapper-libs-0:0.10.1-2.fc37.x86_64
> sourcextractor++-0:0.19-5.fc38.x86_64
> supercollider-0:3.12.2-8.fc38.x86_64
> systemtap-client-0:4.8-2.fc38.x86_64
> systemtap-devel-0:4.8-2.fc38.x86_64
> systemtap-runtime-0:4.8-2.fc38.x86_64
> trellis-0:1.2.1-14.20230215git0c522ce.fc39.x86_64
> trellis-devel-0:1.2.1-14.20230215git0c522ce.fc39.x86_64
> uhd-0:4.4.0.0-1.fc38.x86_64
> vsomeip3-0:3.1.20.3-10.fc38.x86_64
> vsomeip3-compat-0:3.1.20.3-10.fc38.x86_64
> wesnoth-0:1.17.13-1.fc39.x86_64
> wesnoth-server-0:1.17.13-1.fc39.x86_64
> wsjtx-0:2.6.1-1.fc38.x86_64
>

I think you got something wrong with your repoquery. Perhaps it picked up
older packages from a published rawhide compose that were still linked with
older boost?

My list of things needing rebuild is much shorter:

$ dnf repoquery --whatrequires 'libboost*.so.1.78.0()(64bit)'
--disablerepo='*' --enablerepo=rawhide-koji -s
0ad-0.0.26-7.fc38.src.rpm
blender-3.4.1-11.fc39.src.rpm

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-02-20)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 15:00:22 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting/2023-02-20/flatpak-sig.2023-02-20-15.00.log.html
.



Meeting summary
---
* Init process  (kalev, 15:00:22)

* Announcements  (kalev, 15:03:47)
  * 15 new flatpaks added over the last two weeks, thanks to yselkowitz
(14) and pwalter (1)  (kalev, 15:03:58)
  * LINK: https://bodhi.fedoraproject.org/releases/F37F has all the
updates  (kalev, 15:04:04)
  * xberry has a fork of flatpak-module-tools to merge in the parts of
fedmod we need   (kalev, 15:04:06)
  * LINK:

https://pagure.io/fork/xberry/flatpak-module-tools/c/1f7eeb562a72aae60e53babc3935ddb6eca54043?branch=master
(kalev, 15:04:09)
  * Allan created a gitlab repo where we can track flatpak-specific
issues: https://gitlab.com/fedora/sigs/flatpak  (kalev, 15:04:12)
  * xberry will also work on porting the "to be bundled" fedmod from
libmodulemd to libmodulemd v2  (tpopela[m], 15:05:51)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7 is
blocking a few apps  (AllanDay[m], 15:06:49)

* Policy for app id discrepencies  (kalev, 15:07:27)
  * LINK:
https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7
(kalev, 15:07:30)
  * LINK: https://docs.fedoraproject.org/en-US/packaging-guidelines/ is
the packaging guidelines that I refer to  (kalev, 15:16:40)

* timeframe for migrating to f38  (kalev, 15:36:19)
  * LINK: https://wiki.gnome.org/FortyFour has the gnome schedule and
44.0 is March 18  (kalev, 15:47:35)

Meeting ended at 16:00:10 UTC.




Action Items






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




People Present (lines said)
---
* kalev (109)
* travier (46)
* zodbot (13)
* yselkowitz[m] (12)
* AllanDay[m] (9)
* tpopela[m] (7)
* chromebittin (6)
* ssmoogen (5)
* rishi[m] (4)
* sberg_ (3)




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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-02-06)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 15:00:13 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-02-06/flatpak-sig.2023-02-06-15.00.log.html
.



Meeting summary
---
* Init process  (kalev, 15:00:13)

* Announcements  (kalev, 15:03:46)
  * gstreamer1-plugins-ugly-free and jxl-pixbuf-loader packages added to
the flatpak runtime  (kalev, 15:05:05)
  * longstanding Cheese issue with camera detection fixed, was due to
gstreamer1-plugins-good needing to be built differently in the
flatpak runtime  (kalev, 15:09:23)
  * libreoffice update done that was blocked by a java build issue
(kalev, 15:09:51)
  * new flatpak packages currently in testing: klavaro, remmina,
gtkhash, exaile, howl, exfalso, audacious  (kalev, 15:10:06)
  * would be useful if people could test new flatpaks and leave karma in
bodhi and report any issues to bugzilla  (kalev, 15:11:52)
  * flatpak-sig group created  (kalev, 15:12:33)
  * new fedmsg bot in irc channel  (kalev, 15:13:03)
  * flatpak 1.15.2 released  (kalev, 15:13:40)
  * LINK: https://github.com/flatpak/flatpak/releases/tag/1.15.2
(kalev, 15:13:41)

* IRC bot  (kalev, 15:14:10)
  * most people find the fedmsg bot too verbose and effectively killed
all communication in the channel  (kalev, 15:16:58)
  * ACTION: Kalev to do an ansible PR to drop the bot from the channel
(kalev, 15:17:34)

* How to test Fedora flatpaks  (kalev, 15:20:32)
  * ACTION: Kalev to start a wiki page with testing instructions
(kalev, 15:24:25)
  * LINK: https://fedoraproject.org/wiki/SIGs/Flatpak/Testing
(travier, 15:25:18)

* libmodulemd1  (kalev, 15:26:37)
  * yselkowitz[m] to look into fixing libmodulemd1 FTBFS  (kalev,
15:40:02)
  * Owen to talk to Jan to see how far along fedmod replacement is
(kalev, 15:40:28)
  * ACTION: tpopela to to talk to Jan to see how far along fedmod
replacement is :-)  (OwenTaylor[m], 15:41:04)
  * LINK: https://koji.fedoraproject.org/koji/taskinfo?taskID=96366742 -
btw. the build succeeded on aarch64..  (tpopela[m], 15:42:47)

* place to track issues  (kalev, 15:44:14)
  * LINK: https://gitlab.com/fedora/sigs   (travier, 15:46:04)

Meeting ended at 15:59:50 UTC.




Action Items

* Kalev to do an ansible PR to drop the bot from the channel
* Kalev to start a wiki page with testing instructions
* tpopela to to talk to Jan to see how far along fedmod replacement is
  :-)




Action Items, by person
---
* **UNASSIGNED**
  * Kalev to do an ansible PR to drop the bot from the channel
  * Kalev to start a wiki page with testing instructions
  * tpopela to to talk to Jan to see how far along fedmod replacement is
:-)




People Present (lines said)
---
* kalev (110)
* travier (19)
* zodbot (14)
* AllanDay[m] (9)
* tpopela[m] (7)
* bcotton (6)
* FelipeBorges[m] (5)
* OwenTaylor[m] (5)
* yselkowitz[m] (5)
* JanGrulich[m] (1)




Generated by `MeetBot`_ 0.4

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

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

[Kalev Lember]

On Thu, Jan 26, 2023 at 11:08 PM Miro Hrončok  wrote:

> Oh but they are different. FTBFS are not urgent and the policy is only set
> to
> retire packages that FTBFS for more than 2 release cycles.
>
> For a package to be considered for retirement in February 23, it would
> have to
> fail to build:
>
>   - During the Fedora 36 mass rebuild in January 22.
>   - During the Fedora 37 mass rebuild in July 22.
>   - During the Fedora 38 mass rebuild in January 23.
>
> That is not urgent, that is "not being fixed".
>
> We can make this even longer, but I don't think it'll make a difference --
> eventually we will just get a list of packages that aren't beign fixed,
> but for
> a longer time.
>

No, please don't make it longer. I think it's fine as is. If it's any
longer then we get packages that cannot be built from source at all, not
even on F36 in this example, and this can lead to very bad situations if
some urgent reason comes up to rebuild them.

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

Summary/Minutes from today's Fedora Flatpak Packaging SIG Meeting (2023-01-23)

[Kalev Lember]

=
#fedora-meeting: Fedora Flatpak Packaging SIG
=


Meeting started by kalev at 15:00:33 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-23/flatpak-sig.2023-01-23-15.00.log.html
.



Meeting summary
---
* First Meeting  (kalev, 15:00:48)

* Introductions  (kalev, 15:02:41)
  * LINK: https://etherpad.opensuse.org/p/fedora-flatpaks-sig ?*
(travier, 15:03:05)

* Announcements  (kalev, 15:09:26)
  * yselkowitz has added ~20 new flatpaks over the last two weeks and
got flatseal packaged -- awesome work!  (kalev, 15:10:16)

* Why do we need Fedora Flatpaks?  (kalev, 15:16:22)

* openh264  (kalev, 15:31:44)
  * Kalev has a plan how to do the openh264 flatpak runtime extension
using Cisco hosted openh264 rpms  (kalev, 15:40:49)
  * LINK: https://github.com/fedora-silverblue/issue-tracker/issues/288
(travier, 15:43:17)

* flatpak-sig Fedora group and access to flatpaks/ namespace in dist-git
  (kalev, 15:45:43)
  * ACTION: Kalev to set up flatpak-sig pagure group for flatpaks/
namespace  (kalev, 15:49:21)

* KDE/Qt runtime?  (kalev, 15:50:55)
  * The KDE SIG is interested in taking the KDE/Qt runtime under KDE SIG
umbrella  (kalev, 15:58:56)

Meeting ended at 16:00:58 UTC.




Action Items

* Kalev to set up flatpak-sig pagure group for flatpaks/ namespace




Action Items, by person
---
* **UNASSIGNED**
  * Kalev to set up flatpak-sig pagure group for flatpaks/ namespace




People Present (lines said)
---
* kalev (86)
* travier (55)
* tpopela[m] (18)
* zodbot (13)
* yselkowitz[m] (12)
* OwenTaylor[m] (10)
* rishi[m] (9)
* JanGrulich[m] (8)
* TheEvilSkeleton (7)
* AllanDay[m] (4)
* JanBeran[m] (1)
* adamw (1)




Generated by `MeetBot`_ 0.4

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

Re: valgrind on Fedora

[Kalev Lember]

On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones 
wrote:

> Also want to mention that your valgrind command line is ... a little
> naive.  Many other options are useful.  Here's what we use in nbdkit:
>
>
> https://gitlab.com/nbdkit/nbdkit/-/blob/a5f804180240aea7031470cb8ed294f904268f0a/wrapper.c#L206-216
>
> (Best to check each of these options in the manual before using)
>
> Also make use of suppressions:
>
>   https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind


Also, to add to this, glib2 has a suppressions file you can use to cut down
on the false positives: /usr/share/glib-2.0/valgrind/glib.supp

-- 
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: List of long term FTBFS packages to be retired in February

[Kalev Lember]

On Wed, Jan 11, 2023 at 5:02 PM Mamoru TASAKA 
wrote:

> Kalev Lember wrote on 2023/01/12 0:03:
> > Hi Mamoru,
> >
> > Out of curiosity, why? Do you actually need libgnome? I was hoping it
> would
> > get removed this cycle so we can finally stop shipping the old gnome 2
> > library stack.
> >
>
> For example, a (rather old) package "fantasdic" I maintain depends on
> libgnome
> as:
> fantasdic <- ruby-gnome2 <- libgnome
> Other example is cbrpager <- libgnomeui <- libgnome
>

Ah, makes sense then :) Thanks!

-- 
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: List of long term FTBFS packages to be retired in February

[Kalev Lember]

On Wed, Jan 11, 2023 at 3:51 PM Mamoru TASAKA 
wrote:

> Miro Hrončok wrote on 2023/01/11 21:58:
> > libgnome alexl, caolanm,
> gnome-sig,
> >   mbarnes, rhughes,
> rstrode,
>
> I've just fixed now:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2109750


Hi Mamoru,

Out of curiosity, why? Do you actually need libgnome? I was hoping it would
get removed this cycle so we can finally stop shipping the old gnome 2
library stack.

-- 
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: Starting Flatpak SIG

[Kalev Lember]

On Thu, Jan 5, 2023 at 10:55 AM Kalev Lember  wrote:

> Hi all,
>
> Hopefully most people are back from vacations now so I think we can go on
> with organizing the first Flatpak SIG meeting.
>
> I have created a whenisgood poll for the next week:
> https://whenisgood.net/s3rzh5h
> Please put your name in there and what times would work for you.
>
> I am thinking that a weekly meeting would be too often, but maybe
> bi-weekly? So that we do one next week, and then again two weeks after etc.
> 10 people have already signed up on the
> https://fedoraproject.org/wiki/SIGs/Flatpak page so I suspect it's going
> to be hard to make it work for everybody, but hopefully we can find
> something that would work for most of the group.
>
> I'll collect the results later this week when it looks like most of the
> people have replied.
>
> Thanks and Happy New Year everybody!
>

OK, we now have a time for the first Flatpak SIG meeting. 10 people replied
to the poll and we managed to find a time slot that actually works for
everybody:

  15:00 GMT on Monday, starting on January 23, and recurring every two
weeks.

Looks like the #fedora-meeting IRC channel is available at that time so
I've gone ahead and made a reservation in
https://calendar.fedoraproject.org/SIGs/2023/1/23/#m10431

Some topics for the first meeting, off the top of my head: introductions,
why do we need to do Fedora Flatpaks, how to handle openh264, announcements.

See you all there!

-- 
Kalev

(I've cross-posted this to the desktop list again but let's try to keep the
discussion on the devel mailing list.)

>
___
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: Starting Flatpak SIG

[Kalev Lember]

Hi all,

Hopefully most people are back from vacations now so I think we can go on
with organizing the first Flatpak SIG meeting.

I have created a whenisgood poll for the next week:
https://whenisgood.net/s3rzh5h
Please put your name in there and what times would work for you.

I am thinking that a weekly meeting would be too often, but maybe
bi-weekly? So that we do one next week, and then again two weeks after etc.
10 people have already signed up on the
https://fedoraproject.org/wiki/SIGs/Flatpak page so I suspect it's going to
be hard to make it work for everybody, but hopefully we can find something
that would work for most of the group.

I'll collect the results later this week when it looks like most of the
people have replied.

Thanks and Happy New Year everybody!

-- 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Kalev Lember]

On Tue, Jan 3, 2023 at 10:27 PM Otto Liljalaakso 
wrote:

> Kalev Lember kirjoitti 3.1.2023 klo 11.19:
> > We might need to update package maintainer documents to be clear about
> this
> > though, so that people know that they should use 'fedpkg srpm' and not
> > 'rpmbuild -bs'.
>
> In Package Maintainer Docs, we have just a single instance of rpmbuild
> usage, at Using the Koji Build System — Scratch Builds [1]. Everything
> else is fedpkg based already. I made a pull request to get rid of that
> single outlier [2].
>
> Did you have some other source of documentation in mind that would need
> more work?
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds
> [2]:
> https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101


Awesome, thanks for doing that! No, I didn't have anything specific in
mind, so hopefully that was all there was to fix :)

-- 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Kalev Lember]

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > - fedpkg mockbuild
> >
> > But it doesn't work correctly (will always use Release: 1) if you run
> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
> "Doctor, it hurts when I do that."
>
> 'rpmbuild -bs' is broken. Don't use it.
>

Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.

-- 
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 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Kalev Lember]

On Tue, Dec 20, 2022 at 2:16 PM Vít Ondruch  wrote:

> Good to know. Thx. Please tell me that part of the plan is renaming dnf5
> => dnf and I'll shut up.
>

I second to this. While it makes sense to temporarily introduce a parallel
installable dnf5 to enable easier early testing, I think dnf5 should get
renamed to dnf when it's made the default. Anything else is just super
confusing.

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

Starting Flatpak SIG

[Kalev Lember]

Hi all,

I would like to kick of a Fedora Flatpak Packaging SIG that meets
regularly and has IRC meetings.

Our flatpaks have gotten some bad rep recently and I think for a good
reason. We don't have a lot of them and we only have a handful of people
working on them. We also have a fairly obvious conflict of interest with
Flathub and a bunch of Fedora people are doing flatpaks in Flathub
instead of Fedora and advocating against using Fedora flatpaks.

Here's an attempt to try to get more people involved :) The awkward
situation here is that I am not 100% convinced myself that we should
continue doing Fedora flatpaks, but maybe with a bit more organization
around this we can get some more eyes on the problem and solve some of
the issues.

Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if
you are interested and I'll try to organize a poll for a weekly meeting
time. I'd suggest to start the meetings on the second week of January
when the holidays are over.

I've added a few people to CC that I thought might be interested in 
this, but anyone that has interest in the area is more than welcome to join.


Some questions I have around organization: Can someone help register the
#fedora-flatpaks IRC channel under the Fedora umbrella? I am not sure
how to best do that. Does matrix need any special sauce to get a room?

What would be a good name for a pagure.io project?
pagure.io/fedora-flatpaks or pagure.io/fedora-flatpak-sig or
pagure.io/flatpak-sig or something else?

Do we need a mailing list? My initial gut feeling is no, but I'm
interested in what other people think.

If you reply to this, please make sure to reply to the
devel@lists.fedoraproject.org post as I am cross-posting it to desktop@
as well.

--
Thanks,
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: Starting Flatpak SIG

[Kalev Lember]

On Thu, Dec 8, 2022 at 8:45 PM Stephen Smoogen  wrote:

>
>
> On Thu, 8 Dec 2022 at 14:39, Onuralp SEZER <
> thunderbir...@fedoraproject.org> wrote:
>
>> Hello Kalev,
>> Please see pagure IRC is place for new channels and etc :
>> https://pagure.io/irc (that is a  better place for track IRC stuff as
>> well)
>>
>>
>
> My apologies.. I sent Kalev to the wrong place.
>

Thanks! I closed the original ticket and filed a new one in
https://pagure.io/irc/issue/75

-- 
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: Starting Flatpak SIG

[Kalev Lember]

On Thu, Dec 8, 2022 at 6:30 PM Timothée Ravier 
wrote:

> > Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if
> > you are interested and I'll try to organize a poll for a weekly meeting
> > time. I'd suggest to start the meetings on the second week of January
> > when the holidays are over.
>
> Done! Thanks for starting that.
>
> > Some questions I have around organization: Can someone help register the
> > #fedora-flatpaks IRC channel under the Fedora umbrella? I am not sure
> > how to best do that. Does matrix need any special sauce to get a room?
>
> If possible, as this is a new channel, I'd recommend going Matrix only.
> This makes things simpler.
>

Not possible because I'm still on IRC :D

Smooge suggested on irc that I open an infra ticket for the irc channel and
the matrix room so I've gone ahead and done that:
https://pagure.io/fedora-infrastructure/issue/11043

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

Starting Flatpak SIG

[Kalev Lember]

Hi all,

I would like to kick of a Fedora Flatpak Packaging SIG that meets
regularly and has IRC meetings.

Our flatpaks have gotten some bad rep recently and I think for a good
reason. We don't have a lot of them and we only have a handful of people
working on them. We also have a fairly obvious conflict of interest with
Flathub and a bunch of Fedora people are doing flatpaks in Flathub
instead of Fedora and advocating against using Fedora flatpaks.

Here's an attempt to try to get more people involved :) The awkward
situation here is that I am not 100% convinced myself that we should
continue doing Fedora flatpaks, but maybe with a bit more organization
around this we can get some more eyes on the problem and solve some of
the issues.

Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if
you are interested and I'll try to organize a poll for a weekly meeting
time. I'd suggest to start the meetings on the second week of January
when the holidays are over.

I've added a few people to CC that I thought might be interested in 
this, but anyone that has interest in the area is more than welcome to join.


[Edit: the email got rejected from the mailing list due to too many 
recipients so I'm re-sending it without the CC list. The CC'd people 
hopefully got the message already.]


Some questions I have around organization: Can someone help register the
#fedora-flatpaks IRC channel under the Fedora umbrella? I am not sure
how to best do that. Does matrix need any special sauce to get a room?

What would be a good name for a pagure.io project?
pagure.io/fedora-flatpaks or pagure.io/fedora-flatpak-sig or
pagure.io/flatpak-sig or something else?

Do we need a mailing list? My initial gut feeling is no, but I'm
interested in what other people think.

If you reply to this, please make sure to reply to the
devel@lists.fedoraproject.org post as I am cross-posting it to desktop@
as well.

--
Thanks,
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: Review Request: ImageMagick7

[Kalev Lember]

On Sat, Dec 3, 2022 at 5:38 PM Neal Gompa  wrote:

> On Sat, Dec 3, 2022 at 11:34 AM Kalev Lember 
> wrote:
> >
> > On Sat, Dec 3, 2022 at 5:26 PM Sérgio Basto  wrote:
> >>
> >> On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote:
> >> > On 03/12/2022 00:30, Sérgio Basto wrote:
> >> > > The proposal now is to keep ImageMagick 6 and make a new package
> >> > > with
> >> > > ImageMagick 7 , when we have all applications use only ImageMagick
> >> > > 7,
> >> > > we move the sources from ImageMagick7 to ImageMagick
> >> >
> >> > I think it would be better to update the ImageMagick package to
> >> > version
> >> > 7 and create a compatibility package ImageMagick6.
> >>
> >> Anyone is going to review the package or not ?
> >>
> >> I already explain the situation in the other emails on this thread .
> >>
> >> I estimate that I will need about 200 hours to do what your brilliants
> >> minds ask .
> >>
> >> And btw, asking to the others to have the work that you maybe don't
> >> have in your packages , is very easy. if I do the compat package and
> >> wait for 200 packages dependency adapt to the change, will be a chaos ,
> >> and I don't like ignore all the tickets opened around it.
> >>
> >> ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022-12-03 so
> >> after 6 Years and 5 Months and 26 Days, we still haven't  any
> >> ImageMagick 7 in Fedora or EL, so or you help me on do it in my way ,
> >> or I won't do it .
> >>
> >> That is why package guidelines should be a guide and not all  and not
> >> the all truth rule, when in practice you don't follow it just claim it.
> >
> >
> > I think it makes sense to do it the way Sergio is planning as it makes
> it all much much easier. I don't think we should set a too high bar here
> wrt the package naming; anything is an improvement if we can start getting
> the distro migrating to ImageMagick 7.
> >
> > We can always rename ImageMagick -> ImageMagick6 and ImageMagick7 ->
> ImageMagick at a later date when someone has the energy to do it.
> >
> > Don't let perfect be the enemy of good :)
> >
>
> It matters in this case because both packages provide stuff in
> /usr/bin, and we only should have one provider of those. ImageMagick
> should retain them, and the ImageMagick6 compat package should only
> provide libraries for stuff that can't link to the IM7 libraries.
>

Ah, yes, that's a good point. I think we have a bunch of packages that
'BuildRequires: ImageMagick' and then use /usr/bin/convert during the build
to convert icons from one format to another. Other packages require
/usr/bin/convert for runtime use.

Sergio, what's your plan for handling /usr/bin/convert?

-- 
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: Review Request: ImageMagick7

[Kalev Lember]

On Sat, Dec 3, 2022 at 5:26 PM Sérgio Basto  wrote:

> On Sat, 2022-12-03 at 11:57 +0100, Vitaly Zaitsev via devel wrote:
> > On 03/12/2022 00:30, Sérgio Basto wrote:
> > > The proposal now is to keep ImageMagick 6 and make a new package
> > > with
> > > ImageMagick 7 , when we have all applications use only ImageMagick
> > > 7,
> > > we move the sources from ImageMagick7 to ImageMagick
> >
> > I think it would be better to update the ImageMagick package to
> > version
> > 7 and create a compatibility package ImageMagick6.
>
> Anyone is going to review the package or not ?
>
> I already explain the situation in the other emails on this thread .
>
> I estimate that I will need about 200 hours to do what your brilliants
> minds ask .
>
> And btw, asking to the others to have the work that you maybe don't
> have in your packages , is very easy. if I do the compat package and
> wait for 200 packages dependency adapt to the change, will be a chaos ,
> and I don't like ignore all the tickets opened around it.
>
> ImageMagick-7.0.1-10 was release on 2016-06-07, today is 2022-12-03 so
> after 6 Years and 5 Months and 26 Days, we still haven't  any
> ImageMagick 7 in Fedora or EL, so or you help me on do it in my way ,
> or I won't do it .
>
> That is why package guidelines should be a guide and not all  and not
> the all truth rule, when in practice you don't follow it just claim it.
>

I think it makes sense to do it the way Sergio is planning as it makes it
all much much easier. I don't think we should set a too high bar here wrt
the package naming; anything is an improvement if we can start getting the
distro migrating to ImageMagick 7.

We can always rename ImageMagick -> ImageMagick6 and ImageMagick7 ->
ImageMagick at a later date when someone has the energy to do it.

Don't let perfect be the enemy of good :)

-- 
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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon

[Kalev Lember]

On Fri, Dec 2, 2022 at 10:30 PM Adam Williamson 
wrote:

> So there's this CI ticket ATM[0] about whether the environment in which
> CI tests are run should or should not include and update from the
> 'buildroot' repo, which contains both:
>
> 1. Packages that have been pushed stable since the last time a compose
> succeeded (for Rawhide that's a Rawhide compose, for Branched it's a
> Branched compose, for stable releases it's an updates compose)
> 2. Packages that have active buildroot overrides
>
> Thinking about this reminded me again why buildroot overrides are such
> a bad idea:
> https://pagure.io/fedora-ci/general/issue/376#comment-830638
>
> Buildroot overrides have unpredictable consequences for builds, updates
> *and* tests. I really feel like we should consider disallowing them and
> requiring all rebases to be done using side tags. Side tags are a
> *much* better design that avoids the problem of packages unexpectedly
> being built against a buildroot override somebody else submitted, and
> means test systems aren't stuck in a bind of not really knowing for
> sure what other packages should be installed when testing any given
> package.
>
> What does everyone else think? Has the time come? Or is there more we
> need to do to make side tags usable for all cases before getting rid of
> overrides?
>

I would say that side tags are almost always the correct tool for ABI
rebuilds. I imagine people who submit global buildroot overrides to handle
a library soname bump are almost always doing it because they haven't
learned the "new" ways of doing it.

I'd go as far as to say that anyone who does ABI rebuilds using global
buildroot overrides are doing it wrong.

However, having said that, I also find buildroot overrides useful. Some
examples:

1) Fedora is in freeze. GNOME has gotten a Freeze Exception to pull a new
version through the freeze, but that includes a library soname bump.

What I would do in that case is submit the GNOME megaupdate to Bodhi, and
also submit the library as a buildroot override to ensure that nothing can
build against the old soname -- I am fairly confident that the GNOME
megaupdate, together with the soname bump makes it to stable first.

2) I need to do a container build and include a new CVE fix (as it's
critical and we need to get fixes out ASAP), but that package build to
include in the container is only in updates-testing.

What I'd do in this case is to submit a buildroot override because
everything that's overridden gets included in container builds. After my
container build is done I'd expire the buildroot override.

3) We've had some "fun" issues with sysprof symbols leaking out from the
GTK stack into other libraries consuming it. This has caused subtle ABI
issues and when working on a fix and to make sure no package can build
against the "wrong" GTK version, I've used buildroot overrides.

4) Compiler issues, with compilers producing broken code.

To test the fixes and make sure packages start using the new fixed versions
ASAP, a buildroot override is often useful.

I could continue with the list but I think you get my point that there are
some cases where it's useful :) However I'd never use buildroot overrides
for soname bump rebuilds; that's what side tags are good for.

Maybe doing occasional blog posts and teaching maintainers how to do multi
package updates would be helpful? Not sure what else we could do to help
improve the situation here.

-- 
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: Can we retire mozjs68 in rawhide?

[Kalev Lember]

On Tue, Nov 29, 2022 at 10:44 AM Florian Weimer  wrote:

> I don't see anything depending on it in the RPM specs file archive.
>
> It looks like the configure script might get confused when building with
> future C compilers which do not accept implicit function declarations,
> and it's probably not worth porting this to C99.
>

According to my repoquery, erlang-js still uses mozjs68:

$ dnf repoquery --whatrequires mozjs68 --disablerepo='*'
--enablerepo=rawhide
Fedora - Rawhide - Developmental packages for the next Fedora release

   36 kB/s |  10 kB 00:00
Fedora - Rawhide - Developmental packages for the next Fedora release

   23 MB/s |  64 MB 00:02
Last metadata expiration check: 0:00:13 ago on Tue 29 Nov 2022 11:18:22 AM
CET.
erlang-js-0:1.9.2-6.fc37.x86_64
mozjs68-devel-0:68.12.0-8.fc37.i686
mozjs68-devel-0:68.12.0-8.fc37.x86_64

When it is time to retire mozjs68 (apparently not yet because of erlang-js,
but hopefully soon :) ), please add mozjs68 to fedora-obsolete-packages
because a lot of users probably still have it installed and it is going to
get broken deps and break the update path as soon as icu gets updated in
rawhide.

-- 
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: Inactive packagers to be removed after the F37 release

[Kalev Lember]

On Mon, Nov 28, 2022 at 8:33 PM Kalev Lember  wrote:

> On Mon, Nov 28, 2022 at 7:20 PM Mattia Verga via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> - rpms/sysprof
>>
>
> I took sysprof as I've been de facto maintaining it for years.
>

... and also baobab, geocode-glib, gnome-font-viewer, gnome-initial-setup,
gnome-photos, gnome-settings-daemon.

-- 
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: Inactive packagers to be removed after the F37 release

[Kalev Lember]

On Mon, Nov 28, 2022 at 7:20 PM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> - rpms/sysprof
>

I took sysprof as I've been de facto maintaining it for years.

-- 
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: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Kalev Lember]

Hi Scott,

On Wed, Nov 23, 2022 at 6:23 PM Scott Talbert  wrote:

> Hi all,
>
> In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
> currently built with OpenGL EGL support) and several package users which
> are expecting OpenGL GLX support, I need to rebuild wxWidgets with a
> different configuration option.  Unfortunately, this results in an ABI
> change, so all packages that link with libwx_gtk3u_gl-3.2.so.0 need to be
> rebuilt.  Unfortunately #2, this also needs to be done in F37.  I've
> opened two side tags to do the rebuilds for F37 and F38.
>
> F37: f37-build-side-60200
> F38: f38-build-side-60198
>
> The following packages need to be rebuilt in the above side tags (note,
> I've already taken care of python-wxpython4 and CubicSDR, which are also
> affected):
>
> 0ad
>

I did 0ad rebuilds for both F37 and F38:

F37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092061
F38: https://koji.fedoraproject.org/koji/buildinfo?buildID=2092060

-- 
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: HEADS-UP: Upcoming retirement of long-term-unused packages for Rust crates

[Kalev Lember]

Hi Fabio,

On Tue, Nov 22, 2022 at 5:14 PM Fabio Valentini 
wrote:

> - rust-constant_time_eq
>

Can you leave rust-constant_time_eq out please? 'authenticator' that I'm
packaging depends on it.

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

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

[Kalev Lember]

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

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

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

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

Re: Orphaned packages looking for new maintainers

[Kalev Lember]

On Mon, Oct 31, 2022 at 3:44 PM Fabio Valentini 
wrote:

> On Mon, Oct 31, 2022 at 3:17 PM Kalev Lember 
> wrote:
> >
> > I went ahead and picked up fragments and gnome-feeds. If anyone else is
> interested in them even a tiny bit, please let me know. I'd appreciate
> co-maintainers a lot here.
>
> I think fragments has recently been rewritten in Rust? You might need
> help with updating to the latest version ...
>

Yep, fragments was rewritten in rust. I'd definitely appreciate help with
updating it if you are interested!

In any case, I'd like to figure out the GNOME + rust packages story. Right
now when someone mentions that something was rewritten in rust, that sounds
a lot like a death sentence for the Fedora package. I don't think it should
be like that; and I'd like to fix that.

I guess for that we have two options: either package up a critical mass of
rust crates that GNOME rust modules are likely going to use, or
alternatively come up with a good guide and rules on how to correctly
bundle rust crates in leaf apps.


And as far as I know, gnome-feeds was superseded by newsflash? Which
> is also written in Rust, but no longer packaged for Fedora (and I
> recommend using the flatpak, because the upstream project is an
> un-package-able mess ...)
>

Ah, could be -- I only picked it up so it wouldn't get removed from Fedora
as it seemed like a useful thing and I didn't want to let Artem's good work
go to waste. It does seem to be getting some attention upstream still
though: https://gitlab.gnome.org/World/gfeeds

Just to be clear, I don't use either fragments nor gnome-feeds, which is
why I'd love co-maintainers :) I only picked them up to avoid them getting
axed immediately.

-- 
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: Orphaned packages looking for new maintainers

[Kalev Lember]

I went ahead and picked up fragments and gnome-feeds. If anyone else is
interested in them even a tiny bit, please let me know. I'd appreciate
co-maintainers a lot here.

Thanks,
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: When is a file dependency appropriate?

[Kalev Lember]

On Thu, Oct 6, 2022 at 2:51 PM Vít Ondruch  wrote:

>
> Dne 06. 10. 22 v 14:38 Kalev Lember napsal(a):
>
> On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch  wrote:
>
>> BTW re-reading the ticket and since there are talks about DNF5, maybe it
>> would be worth of reopening the discussion. I think we could generally
>> do better and I see two options:
>>
>> 1) There seems to be a way to download additional data if needed
>>
>> 2) The metadata we provide in reposotories could be better. I.e. instead
>> of providing full file list, it could be actually enough to collect just
>> the files of the interest. E.g. if there is somewhere `BR:
>> /usr/bin/foo`, then during preparation of repo data, there could be file
>> list with record for bar package, providing entry such as "/usr/bin/foo:
>> bar". This would probably not require any big changes in DNF IMHO.
>>
>
> One problem I have with `BuildRequires: /usr/bin/foo` is that it hardcodes
> the /usr/bin directory, which is the right thing to do when the program
> that uses foo invokes it with full /usr/bin/foo path, but not at all when
> foo is searched from PATH.
>
>
> * I don't think that PATH plays a role here, because otherwise we will be
> back to discussion if and when we should use `env` in shebangs or not.
>
> * We had this issue for SCLs before and I think there are some proposals
> such as:
>
> https://github.com/rpm-software-management/rpm/issues/721
>
> https://github.com/rpm-software-management/rpm/issues/1850
>

Thanks!

This has been a bit of a pain point for flatpak builds in Fedora where the
> rpms are rebuilt for /app prefix. If a package that has `BuildRequires:
> /usr/bin/foo` but the package that provides foo is rebuilt for /app prefix,
> then we no longer have /usr/bin/foo but instead /app/bin/foo and the BR no
> longer finds the package providing foo. Using %{_bindir} doesn't help
> either because not all packages that are used for flatpaks are rebuilt for
> /app (some are part of the flatpak runtime and stay in /usr).
>
> Maybe it would instead make sense to have an abstraction where instead of
> listing /usr/bin/foo in the repo data, we'd have 'Provides:
> executable(foo)' and then other packages could do 'BuildRequires:
> executable(foo)' instead? That would nicely solve the hardcoded path issue.
>
>
> Not sure I like it or not (I would need to give it more thought), but if
> it was autogenerated 
>

Yes, of course autogenerated, anything else would be crazy :) I'll need to
give this some more thought myself, it was just a quick idea I got when
reading this.

I guess a transition plan (if we make up our minds that it makes sense to
do it) could be to first make sure the provides are autogenerated, then do
a mass rebuild, let people try it out in their packages for 6 months, and
then provenpackager-edit all of Requires/BuildRequires: /usr/bin/foo in the
distro to the new format as at that point all of supported Fedora releases
are going to have the provides.

After that, all of /usr/bin provides can be removed from the primary repo
metadata (maybe after 6 more months to give time for 3rd party repos to
catch up) and kept only in the extra filelists metadata.

-- 
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: When is a file dependency appropriate?

[Kalev Lember]

On Thu, Oct 6, 2022 at 11:05 AM Vít Ondruch  wrote:

> BTW re-reading the ticket and since there are talks about DNF5, maybe it
> would be worth of reopening the discussion. I think we could generally
> do better and I see two options:
>
> 1) There seems to be a way to download additional data if needed
>
> 2) The metadata we provide in reposotories could be better. I.e. instead
> of providing full file list, it could be actually enough to collect just
> the files of the interest. E.g. if there is somewhere `BR:
> /usr/bin/foo`, then during preparation of repo data, there could be file
> list with record for bar package, providing entry such as "/usr/bin/foo:
> bar". This would probably not require any big changes in DNF IMHO.
>

One problem I have with `BuildRequires: /usr/bin/foo` is that it hardcodes
the /usr/bin directory, which is the right thing to do when the program
that uses foo invokes it with full /usr/bin/foo path, but not at all when
foo is searched from PATH.

This has been a bit of a pain point for flatpak builds in Fedora where the
rpms are rebuilt for /app prefix. If a package that has `BuildRequires:
/usr/bin/foo` but the package that provides foo is rebuilt for /app prefix,
then we no longer have /usr/bin/foo but instead /app/bin/foo and the BR no
longer finds the package providing foo. Using %{_bindir} doesn't help
either because not all packages that are used for flatpaks are rebuilt for
/app (some are part of the flatpak runtime and stay in /usr).

Maybe it would instead make sense to have an abstraction where instead of
listing /usr/bin/foo in the repo data, we'd have 'Provides:
executable(foo)' and then other packages could do 'BuildRequires:
executable(foo)' instead? That would nicely solve the hardcoded path issue.

-- 
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: Heads up: GNOME 43.0 megaupdate is in testing

[Kalev Lember]

On 9/21/22 12:59, Kalev Lember wrote:
On Wed, Sep 21, 2022 at 12:42 PM Vít Ondruch <mailto:vondr...@redhat.com>> wrote:


I have just reported this against mutter:

https://bugzilla.redhat.com/show_bug.cgi?id=2128660
<https://bugzilla.redhat.com/show_bug.cgi?id=2128660>

This was reported upstream a while ago upstream and there are fixes
since yesterday. Not sure if it qualifies as a blocker and how to mark
it for a review ...


Thanks! I'm happy to help get this fix landed downstream, but I'd like 
the megaupdate to go to stable first.


OK, I went ahead and backported the fixes to mutter-43.0-2.fc37:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c7746c91b6

Can you try if it makes it work right?

--
Thanks,
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: Heads up: GNOME 43.0 megaupdate is in testing

[Kalev Lember]

On 9/21/22 18:02, Kamil Paral wrote:

Hi Kalev,
while it's not essential, I find it unfortunate that Night Light 
controls are now broken, I think many people use it:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2056 

It should be fixed by this commit (I haven't tested it), but it seems 
it's not present in mutter-43.0-1:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2623 



Hi Kamil,

Sure, I went ahead and backported that to mutter-43.0-2.fc37:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c7746c91b6

Can you try if it makes it work?

--
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: Heads up: GNOME 43.0 megaupdate is in testing

[Kalev Lember]

On Wed, Sep 21, 2022 at 12:42 PM Vít Ondruch  wrote:

> I have just reported this against mutter:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2128660
>
> This was reported upstream a while ago upstream and there are fixes
> since yesterday. Not sure if it qualifies as a blocker and how to mark
> it for a review ...
>

Thanks! I'm happy to help get this fix landed downstream, but I'd like the
megaupdate to go to stable first.

To mark something as a blocker, there's two ways: a) Go to
https://qa.fedoraproject.org/blockerbugs/ , Login, and then click Propose.

b) Directly mark it in bugzilla as blocking the blocker (or Freeze
Exception) tracking ticket.

I don't think it's necessary to go through the blocker process in this case
since we can just get it fixed before the freezes start, and also because
vim that's affected isn't on the Workstation install media so it's unlikely
to get accepted as a blocker. What it would qualify as in my opinion is a
Freeze Exception, but it doesn't make much sense to propose it as such
since we aren't in a freeze yet.

-- 
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: Heads up: GNOME 43.0 megaupdate is in testing

[Kalev Lember]

Hi Vit,

On Wed, Sep 21, 2022 at 11:03 AM Vít Ondruch  wrote:

> Kalev,
>
> Could you please look at [1] which was addressed in F36 but never for
> Rawhide, i.e. F37 ATM.
>
> However I see that there is GDM 43 now. I should probably give it a try
> (while the upstream ticket comments [2, 3] don't make me overly
> optimistic).
>
>
> Vít
>
>
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2071394
>
> [2]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5294#note_1551515
>
> [3]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5893


As I understand it, the fixes that were backported for this to
gdm-42.0-2.fc36 are all upstream and included in the new gdm-43.0-1.fc37
build. I commented in the tickets as well. Would you mind giving gdm 43.0 a
spin and see if it actually fixes this?

Thanks!

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

Heads up: GNOME 43.0 megaupdate is in testing

[Kalev Lember]

Hi all,

Just a quick heads up that the GNOME 43.0 final release megaupdate is
now in F37 updates-testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0bd68bbb43

This is the GNOME version that's we'll be shipping F37 Final with, so
please make sure to test it and file issues for things that would need
fixing before F37 GA. I'd suggest starting upstream at gitlab.gnome.org
for most issues, and then letting me (and other people) know in
#fedora-workstation if anything needs backporting to Fedora (since there
won't be any more upstream releases before F37 Final). If anything looks
to be release blockery, then please also file issues downstream at
bugzilla.redhat.com as soon as possible and mark them as blockers using
the blockerbugs page,
https://qa.fedoraproject.org/blockerbugs/milestone/37/final/buglist

At the same time, please don't block the update with -1 karma unless
there's something really amiss: We need the megaupdate to go stable and
we can iterate from there.

It all passed my own smoke testing and things were calm upstream and
it's mostly just bug fixes at this point, compared to 43.rc.

Thanks everybody and let's make this a good release!

--
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: Donate 1 minute of your time to test upgrades from F36 to F37

[Kalev Lember]

On Mon, Sep 19, 2022 at 3:52 PM Michael Catanzaro 
wrote:

> On Mon, Sep 19 2022 at 12:08:10 AM +0200, Robert-André Mauchin
>  wrote:
> > Error: Transaction test error:
> >   file /usr/bin/WebKitWebDriver from install of
> > webkit2gtk4.1-2.37.91-1.fc37.x86_64
> > conflicts with file from package webkit2gtk3-2.38.0-2.fc36.x86_64
>
> This problem would go away if webkit2gtk3 (F36 package) were replaced
> by webkit2gtk4.0 (corresponding F37 package, which does not provide
> /usr/bin/WebKitWebdriver). I don't know why that is not happening, so
> I'm not sure what to do about this.
>

I would guess it happened because the F36 webkitgtk version number was
ahead of the F37 webkitgtk version, so the versioned obsoletes that the F37
webkitgtk packages have didn't match.

-- 
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: WebKitGTK package naming

[Kalev Lember]

On Mon, Sep 12, 2022 at 3:53 AM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
> the latest webkitgtk package now uses the following subpackage names:
> * webkit2gtk4.0 and webkit2gtk4.1 are for GTK 3,
> * webkit2gtk5.0 are for GTK 4.
>
> As you can see, the WebKitGTK soversion ends up appended to "gtk", making
> it
> look like the package targets a different (higher) GTK version than it
> actually does.
>
> I can see why you want the soversion in there, especially to distinguish
> 4.0
> from 4.1, but would it not make more sense to use:
> webkit2gtk3_4.0
> webkit2gtk3_4.1
> webkit2gtk4_5.0
> as the names?
>

Thanks Kevin! I think what you are suggesting makes a lot of sense (but
it's one of few GNOME packages that I'm not calling the shots on and it's
Michael's call here).

By the way, do you have any suggestions for upstream library naming? There
is going to be an API break next cycle in the webkit2gtk-5.0 gtk4 API and
that's a good chance to do something about the shared library naming.

So far it's:
webkit2gtk-4.0.so
webkit2gtk-4.1.so
webkit2gtk-5.0.so

and I know Michael has been working on renaming webkit2gtk-5.0.so to
webkitgtk-5.0.so upstream. Can you come up with any better names for the
gtk4 shared library upstream, Kevin (or anyone else)? The constraint here
is that webkit2gtk-4.0.so and webkit2gtk-4.1.so are set in stone so it's
best to avoid something that can be easily confused with the existing
library names.

-- 
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: Donate 1 minute of your time to test upgrades from F36 to F37

[Kalev Lember]

On Mon, Sep 12, 2022 at 9:52 PM Alexander Ploumistos <
alex.ploumis...@gmail.com> wrote:

> The only issues I've encountered were related to nautilus extensions.
> Bugs are open for all of them and I submitted a PR for an rpmfusion
> package.
>
> However, I think that for people on Workstation who
> encrypt/decrypt/sign files through nautilus (and who are not
> comfortable with a terminal), the loss of seahorse-nautilus is going
> to be a significant problem. Could anyone take a look to see if it can
> be patched to work on F37? I was able to get the compilation going up
> to a point, but the subsequent errors were beyond my knowledge.
>

seahorse-nautilus should be hopefully fixed with
https://bodhi.fedoraproject.org/updates/FEDORA-2022-5d2dea3270

Can you try if it works and leave karma in the bodhi update? Thanks!

-- 
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: Orphaned various packages (GNOME / GObject libraries)

[Kalev Lember]

On Tue, Sep 6, 2022 at 11:47 AM Fabio Valentini 
wrote:

> I expect that editorconfig, graphite2, libcloudproviders to be picked
> up by GNOME package maintainers, since they're dependencies of core
> GNOME or Fedora Workstation components (CC @kalev).
>

Thanks! I picked up those 3.

-- 
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: Thoughts welcome: interface between automated test gating and the "critical path"

[Kalev Lember]

On Fri, Sep 2, 2022 at 3:16 PM Ben Cotton  wrote:

> On Wed, Aug 31, 2022 at 12:00 PM Adam Williamson
>  wrote:
>
> > So, one of the implicit questions here is, is it OK to keep twinning
> > these two sets of consequences, or should we split them up?
>
> Yes, it's okay to keep two sets of consequences together. In fact,
> it's preferable. One critpath to rule them all, etc. We can always
> tune the Bodhi requirements if we find that they're troublesome.
>

I think so too that just keeping one single list (critpath) is fine and
avoids having to maintain two different lists with all the
maintenance costs associated with it (the lists getting out of sync over
time etc).

Zbyzek's idea about reducing Bodhi karma requirements for critpath packages
now that we have OpenQA gating makes sense to me as well. OpenQA already
provides the additional testing that we originally wanted to get when we
introduced the extra karma requirements for critpath packages.

-- 
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: Why install rsyslog by default?

[Kalev Lember]

On Thu, Aug 25, 2022 at 9:07 PM Michael Catanzaro 
wrote:

> On Thu, Aug 25 2022 at 02:45:31 PM -0400, Neal Gompa
>  wrote:
> > We should remove rsyslog from @standard.
>
> Packages in @standard but not in @workstation-product:
>
> at
> crontabs
> dbus
> ed (no, really)
> fprintd-pam
> irqbalance
> rsyslog
> smartmontools
> util-linux-user
>
> Seems like if we remove a few things from @standard, we could have
> Workstation use @standard and then @workstation-product would just need
> to include extra stuff instead of duplicating most of @standard.
>

Yes, I agree that it would be nice if we could do that.

When I did the initial Workstation comps groups years ago I based them on
the idea that the Workstation WG had back then that all of the comps groups
that go into Workstation should be under the control of the Workstation WG
so originally it was by design that @standard didn't get used in
@workstation-product.

I don't share that view any more though and I think it would be nice to
share the maintenance burden for the low level packages that are in
@standard :) We've already got rid of the @gnome-desktop split so I think
it would make sense to do it with @standard as well.

-- 
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: [HEADS-UP] Upcoming retirement of gstreamer-rs and wasm-bindgen stacks

[Kalev Lember]

On Sat, Aug 20, 2022 at 4:16 PM Fabio Valentini 
wrote:

> Hello fellow Rust packagers,
>
> I am progressing with my "spring cleaning" efforts for the Rust stack,
> and it became apparent that there's a few clusters of packages that
> are actually unused, but which regularly take up a non-insignificant
> amount of my package maintenance time.
>
> The gstreamer-rs stack seems to have been imported in preparation for
> packaging an application (maybe shortwave?) over three years ago (!),
> but that effort seems to have been abandoned, and as a result, the
> following packages have been unused since (but were actively
> maintained and updated to new versions):
>
> - rust-gstreamer
> - rust-gstreamer-sys
> - rust-gstreamer-audio
> - rust-gstreamer-audio-sys
> - rust-gstreamer-base
> - rust-gstreamer-base-sys
> - rust-gstreamer-editing-services
> - rust-gstreamer-editing-services-sys
> - rust-gstreamer-pbutils
> - rust-gstreamer-pbutils-sys
> - rust-gstreamer-player
> - rust-gstreamer-player-sys
> - rust-gstreamer-video
> - rust-gstreamer-video-sys
>

Hi Fabio,

tpm pointed out on IRC that gst-plugins-rs uses rust-gstreamer. We don't
have gst-plugins-rs in Fedora, but I suspect it's something we might need
in the future.

I've been meaning to try my hand on rust packaging for a while now so
perhaps I could try to package up gst-plugins-rs and maybe help maintain
the rust-gstreamer stack as well?

It would be a pity to retire the rust-gstreamer packages if it turns out
half a year later that we actually need them.

-- 
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: nspawn for rawhide?

[Kalev Lember]

On Thu, Aug 18, 2022 at 11:02 PM Kevin Fenzi  wrote:

> Greetings everyone.
>
> Many years ago mock introduced and then made default it's isolation to
> use systemd-nspawn instead of chroot. Shortly after the nspawn isolation
> was added, it was used in fedoraproject koji builds, but there were
> issues and since then the fedoraproject koji has defaulted to using
> chroot isolation.
>
> Releng has had a ticket open for a long time to switch
> ( https://pagure.io/releng/issue/6967 )
>
> I think the two items listed there (kernel bind mounts and loop devices)
> have long since been fixed, so I would like to propose we switch rawhide
> to using nspawn and see if any other issues show up.
>
> If everyone is ok with it, I can enable it (just for rawhide) and we can
> look for issues with composes or any other items. At least then we would
> have a good list of things we would like to fix. If it turns out things
> just work ok we can leave it enabled.
>
> I think moving to this will:
> * More closely match developers local test mock builds.
> * Provide better isolation for builds
> * Help with resources as systemd-nspawn is a lot more cgroup aware than
> chroot
> * Allow us to close a 5 year old ticket. ;)
>
> Thoughts?
>

Go for it :) I think now is a good time to do it: Most people are focusing
on getting F37 lined up and some rough waters in rawhide would be fine. F38
is still a long way out.

-- 
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: libbautilus-extension 3 no longer available?

[Kalev Lember]

On 8/14/22 19:20, Richard Shaw wrote:
I have disabled the extension in Brasero for now for F37 and up. There 
was already an issue submitted in gitlab but no response.


Thanks. I agree, disabling the extension is the right thing to do here.

--
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: Heads-up: libgnome-desktop soname bump

[Kalev Lember]

On Wed, Jul 27, 2022 at 6:28 PM Kalev Lember  wrote:

>
> Hi all,
>
> libgnome-desktop (gnome-desktop3 rpm package) bumps its soname in
> 43.alpha release. This breaks the following packages that are currently
> FTBFS in rawhide:
>
> budgie-control-center-1.0.2-3.fc37.src.rpm
> chatty-0.6.7-1.fc37.src.rpm
> gala-6.3.1-3.fc37.src.rpm
> gnome-flashback-3.44.0-1.fc37.src.rpm
> phosh-0.20.0~beta2-1.fc37.src.rpm
>

The soname bump (or rather, old ABI compat hack removal) is done now
with gnome-desktop3-43~alpha-6.fc37 build that just landed in rawhide a few
minutes ago. I see that phosh has been rebuilt in the mean time so that's
one less package to worry about. The rest are still FTBFS.

-- 
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: The R stack in Rawhide is on fire

[Kalev Lember]

On Tue, Aug 2, 2022 at 7:27 PM Miro Hrončok  wrote:

> On 02. 08. 22 19:02, Iñaki Ucar wrote:
> > To begin with, untag Frantisek's build from f37, please. Tom prepared
> > the side tag to rebuild the packages there, but I believe he's not
> > currently available...
>
> I've opened https://pagure.io/releng/issue/10943


I went ahead and untagged the R build, from both f37 and eln. Can someone
make sure to rebuild R once more in the side tag so that it has a higher
release number than the build that was just untagged? Otherwise I am fairly
sure it's going to cause issues when merging the tag (and this also ensures
it's correctly rebuilt against the new icu).

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

Re: [rawhide] ICU upgrade to 71.1

[Kalev Lember]

On Tue, Aug 2, 2022 at 4:03 PM Stephen Gallagher 
wrote:

> On Mon, Aug 1, 2022 at 6:04 PM Frantisek Zatloukal 
> wrote:
> >
> >
> >
> > On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher 
> wrote:
> >>
> >> On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal 
> wrote:
> >> >
> >> > Hi,
> >> >
> >> > Later today, I'll be starting with rebuilds of packages depending on
> icu. The rebuilds will take place in f37-build-side-55935 for all packages
> returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
> attached at the end of the message).
> >> >
> >> > Please, if you're going to make changes in affected packages before
> the side tag gets merged, make the build in the said side tag. I expect to
> merge the side tag with most of the affected packages built and then
> continue building things that take longer to build (webkit/libreoffice)
> later.
> >> >
> >> > For stuff that may fail to build, either due to newer icu or
> unrelated issues, there is a libicu69 compat package already available in
> rawhide, so that should take care of FTI issues that'd arise by merging the
> side tag. I'll try to help the maintainers with fixing the issues.
> >> >
> >> > I'll post updates to this thread as I progress with the bump.
> >> >
> >> > [0]
> >> ...
> >> > v8
> >
> >
> > Yeah, I did a bunch of manual editing/checking up in the list, this
> should actually be v8-314.
>
>
> Apparently this side-tag has been merged and it broke a lot of stuff
> in Rawhide/ELN:
>

I believe Frantisek did a compat package which allowed the side tag to be
merged early while some rebuilds were still in progress. I guess maybe it's
missing from the ELN package set and needs to be added? It should be this
package: https://koji.fedoraproject.org/koji/packageinfo?packageID=35857

-- 
Hope this helps,
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads-up: libgnome-desktop soname bump

[Kalev Lember]

On Wed, Jul 27, 2022 at 6:52 PM Fabio Valentini 
wrote:

> At least in the case of gala, it's already not installable in rawhide
> because of the mutter soname bump.
> So not being installable due to the libgnome-desktop soname bump as
> well doesn't make it any worse :)
>

Ah, good! :)

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

Heads-up: ldc soname bump

[Kalev Lember]

Hi all,

I'm working on updating ldc D compiler to version 1.30. The bumps 
libphobos and libdruntime sonames, but I've already sorted out all the 
build issues and I'm going to take care of rebuilding everything that 
depends on it before merging it into rawhide.


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

Heads-up: libgnome-desktop soname bump

[Kalev Lember]

Hi all,

libgnome-desktop (gnome-desktop3 rpm package) bumps its soname in
43.alpha release. This breaks the following packages that are currently
FTBFS in rawhide:

budgie-control-center-1.0.2-3.fc37.src.rpm
chatty-0.6.7-1.fc37.src.rpm
gala-6.3.1-3.fc37.src.rpm
gnome-flashback-3.44.0-1.fc37.src.rpm
phosh-0.20.0~beta2-1.fc37.src.rpm

These all already failed to build in the F37 mass rebuild last week. I
briefly looked at the build logs and most of these are failing due to
changed gnome_desktop_thumbnail_factory_generate_thumbnail() API that
now has grown GCancellable and GError out params. It should be fairly
straightforward to patch.

The gnome-desktop3 43.alpha update is already in rawhide, however it
currently has an ugly-ugly hack in place that provides the old soname
so that the packages that aren't rebuilt don't (yet) fail to install. My
plan is to remove that hack in 1 week's time which is going to properly
break the packages above.

Thanks for understanding and sorry for the trouble,
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 on the list, report it: 
https://pagure.io/fedora-infrastructure