Re: RFC authselect: mdns or mdns-minimal

[Zdenek Dohnal]

On 8/7/23 12:38, Pavel Březina wrote:


IIUC, when 2228533 is resolved, I should switch from 
mdns[-|4|6]_minimal to mdns[-|4|6] and otherwise keep it as is?

Yes.

The order of the modules should be also kept:

Current order  is:

hosts: files myhostname libvirt libvirt_guest 
mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns
I wouldn't play with the order, because I don't understand it perfectly 
to make such decisions, so yes, keep the order as it is.


Thanks,
Pavel





But I'm not a nss-mdns or avahi maintainer, just a maintainer of 
stacks which use mdns often - printing and scanning. I've got this 
opinion from issues in past, by checking nss-mdns code and by 
intention of minimizing of new work in authselect, unless it is 
necessary.



Zdenek


Yes, I admit current way of providing different plugins instead of 
one plugin with related configuration is unfortunate. Because it 
depends on avahi-daemon anyway, I hope it can be reduced to single 
plugin, where every customization can be done on side of 
avahi-daemon. But needs code modifications first, so waiting for a 
volunteer.





--
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Disabling rawhide builds during branching

[Tomas Hrcka]

I thought this got through, we will wait with the branching event
after the dnf5 revert has landed.

On Tue, Aug 8, 2023 at 12:15 AM Adam Williamson
 wrote:
>
> On Mon, 2023-08-07 at 23:18 +0200, Tomas Hrcka wrote:
> > Hi All,
> >
> > Fedora Linux 39 is going to be branched from rawhide on 2023-08-08 at 10:30 
> > UTC
> > as per the previous discussion[1] we are going to disable new koji
> > builds for the duration of this event.
>
> I think we should probably work out what we want to do about the dnf5
> revert update failing tests before we do the branching (see
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf#comment-3149533
> and the "Replacing DNF with DNF5: changes reverted and helping steps"
> thread on this list).
>
> I will not be around at 10:30 UTC, I'll be awake about 1500 UTC I
> guess.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



-- 
Tomas Hrcka
fas: humaton
libera.CHAT: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Replacing DNF with DNF5: changes reverted and helping steps

[Ian Laurie]

On 8/8/23 03:59, Nicola Sella wrote:

Hi all,

As discussed[1] DNF will not be obsoleted in fedora 39. The side-tag
with the reverted changes was merged[2,3] just now.
You can now try the new packages by upgrading to the newer version of
DNF5 (dnf5-5.1.1-1.fc39) which will not obsolete DNF (dnf-4-16.2-2.fc39)
anymore.

Note that, if you install the packages from the side-tag, DNF might not
be installed because it would be obsoleted by DNF5-5.1.0, from rawhide
repositories.
Therefore, if you want to upgrade and use DNF < 5 on your rawhide
system, here are some steps that should help you.

1. If you intend to install the new packages from the side-tag, you
might want to exclude rawhide repositories. You have two options:

a. First, upgrade the system to the latest packages in the side-tag:
$ dnf5 upgrade \
   --best --releasever=39 \
   --disablerepo=* \
   --enablerepo=side-tag
--repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
 '
Then, install DNF:
$ dnf5 install dnf \
   --best --releasever=39 \
   --disablerepo=* \
   --enablerepo=side-tag
--repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
 '

b. You can achieve the same goal in one step:
$ dnf5 install "dnf < 5" \
   --best --releasever=39 \
   --disablerepo=* \
   --enablerepo=side-tag
--repofrompath=side-tag,'https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
 '

2. If you would rather not use the side-tag OR you are updating after
the packages are available in rawhide, you should have no issues. The
same two options follow:

a. Upgrade and install:
$ dnf5 upgrade --best
$ dnf5 install dnf --best

b. Or, with the one-liner:
$ dnf5 install "dnf < 5" --best

Please, don't hesitate to reach back if you cannot install the newest
packages,



I think you may need a --nogpgcheck in there to allow it to work.

--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: [Cython3 need help] Re: mass rebuild for opencv 4.8.0 with soname bump on rawhide

[Rich Mattes]

On Mon, Aug 7, 2023 at 7:08 PM Jerry James  wrote:
>
> On Mon, Aug 7, 2023 at 5:02 PM Sérgio Basto  wrote:
> > Error compiling Cython file:
> > 
> > ...
> > def set_depth_callback(DevPtr dev, cb):
> > global _depth_cb
> > if cb is not None:
> > _depth_cb = cb
> > freenect_set_depth_callback(dev._ptr, depth_cb)
> >   ^
> > 
> > /builddir/build/BUILD/libfreenect-
> > 0.7.0/wrappers/python/freenect.pyx:351:46: Cannot assign type 'void
> > (freenect_device *, void *, uint32_t) except * nogil' to
> > 'freenect_depth_cb'
>
> You probably have to patch that declaration to add "noexcept".  See
> https://src.fedoraproject.org/rpms/python-pari-jupyter/blob/rawhide/f/python-pari-jupyter-cython3.patch
> for an example.  If that is the issue, see
> https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html#exception-values-and-noexcept
> for more information.

Thanks for the pointer.  I pushed a patch that should resolve the
build failure, feel free to rebuild against OpenCV 4.8

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

Re: [Cython3 need help] Re: mass rebuild for opencv 4.8.0 with soname bump on rawhide

[Jerry James]

On Mon, Aug 7, 2023 at 5:02 PM Sérgio Basto  wrote:
> Error compiling Cython file:
> 
> ...
> def set_depth_callback(DevPtr dev, cb):
> global _depth_cb
> if cb is not None:
> _depth_cb = cb
> freenect_set_depth_callback(dev._ptr, depth_cb)
>   ^
> 
> /builddir/build/BUILD/libfreenect-
> 0.7.0/wrappers/python/freenect.pyx:351:46: Cannot assign type 'void
> (freenect_device *, void *, uint32_t) except * nogil' to
> 'freenect_depth_cb'

You probably have to patch that declaration to add "noexcept".  See
https://src.fedoraproject.org/rpms/python-pari-jupyter/blob/rawhide/f/python-pari-jupyter-cython3.patch
for an example.  If that is the issue, see
https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html#exception-values-and-noexcept
for more information.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Cython3 need help] Re: mass rebuild for opencv 4.8.0 with soname bump on rawhide

[Sérgio Basto]

ok, all expect libfreenect and player rebuilt well (against opencv
4.8.0) [1]

libfreenect doesn't build because of cython update to 3.0.0 [2] and
player doesn't build because depends on libfreenect .

https://koji.fedoraproject.org/koji/taskinfo?taskID=104468120
here is the result of libfreenect-0.7.0-4.fc39 when failed to build

Searching on google seems cython3 broke some packages but I can't find
a way to fix it. 

Thank you 

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-2023-7ff489c54c

[2]
Error compiling Cython file:

...
def set_depth_callback(DevPtr dev, cb):
global _depth_cb
if cb is not None:
_depth_cb = cb
freenect_set_depth_callback(dev._ptr, depth_cb)
  ^

/builddir/build/BUILD/libfreenect-
0.7.0/wrappers/python/freenect.pyx:351:46: Cannot assign type 'void
(freenect_device *, void *, uint32_t) except * nogil' to
'freenect_depth_cb'

On Sun, 2023-08-06 at 15:38 +0100, Sérgio Basto wrote:
> Hi,
> I will start a mass rebuild in a side-tag, very soon , the goal is
> finish and merge it before the mass branch which is scheduled for 08
> Aug 2023
> 
> Best regards,
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

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

Re: Replacing DNF with DNF5: changes reverted and helping steps

[Adam Williamson]

On Mon, 2023-08-07 at 15:12 -0700, Adam Williamson wrote:
> On Mon, 2023-08-07 at 19:59 +0200, Nicola Sella wrote:
> > 
> > 2. If you would rather not use the side-tag OR you are updating after the
> > packages are available in rawhide, you should have no issues. The same two
> > options follow:
> 
> The update will not land in Rawhide as-is because the removal of any
> `dnf` command on a typical update breaks almost all of the openQA
> tests.
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf#comment-3149533
> 
> If we're really fine with leaving Rawhide systems with no `dnf` on
> update, we will have to do some work to work around this in the test
> system so as not to break tests on all subsequent updates. Also, there
> needs to be a PR for fedora-comps to revert the dnf5 migration there
> (and anywhere else it happened). 

Correction - it seems the comps PR was already merged,
https://pagure.io/fedora-comps/pull-request/866 . I just looked at open
PRs, so I didn't see it.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: Disabling rawhide builds during branching

[Adam Williamson]

On Mon, 2023-08-07 at 23:18 +0200, Tomas Hrcka wrote:
> Hi All,
> 
> Fedora Linux 39 is going to be branched from rawhide on 2023-08-08 at 10:30 
> UTC
> as per the previous discussion[1] we are going to disable new koji
> builds for the duration of this event.

I think we should probably work out what we want to do about the dnf5
revert update failing tests before we do the branching (see
https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf#comment-3149533
and the "Replacing DNF with DNF5: changes reverted and helping steps"
thread on this list).

I will not be around at 10:30 UTC, I'll be awake about 1500 UTC I
guess.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: Replacing DNF with DNF5: changes reverted and helping steps

[Adam Williamson]

On Mon, 2023-08-07 at 19:59 +0200, Nicola Sella wrote:
> 
> 2. If you would rather not use the side-tag OR you are updating after the
> packages are available in rawhide, you should have no issues. The same two
> options follow:

The update will not land in Rawhide as-is because the removal of any
`dnf` command on a typical update breaks almost all of the openQA
tests.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf#comment-3149533

If we're really fine with leaving Rawhide systems with no `dnf` on
update, we will have to do some work to work around this in the test
system so as not to break tests on all subsequent updates. Also, there
needs to be a PR for fedora-comps to revert the dnf5 migration there
(and anywhere else it happened). 
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Disabling rawhide builds during branching

[Tomas Hrcka]

Hi All,

Fedora Linux 39 is going to be branched from rawhide on 2023-08-08 at 10:30 UTC
as per the previous discussion[1] we are going to disable new koji
builds for the duration of this event.

All builds that will be running at that time for the rawhide will be
canceled and can be resubmitted by maintainers after the branching.

All rawhide updates that are in a pending state for rawhide will be unpushed.

Once Fedora Linux 39 is branched we will re enable builds in koji.

1 - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GWY4TIDIP65HA2V33F2ROU2MJLKMRZ7E/#GWY4TIDIP65HA2V33F2ROU2MJLKMRZ7E
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 
the release t

Replacing DNF with DNF5: changes reverted and helping steps

[Nicola Sella]

Hi all,

As discussed[1] DNF will not be obsoleted in fedora 39. The side-tag with
the reverted changes was merged[2,3] just now.
You can now try the new packages by upgrading to the newer version of DNF5 (
dnf5-5.1.1-1.fc39) which will not obsolete DNF (dnf-4-16.2-2.fc39) anymore.

Note that, if you install the packages from the side-tag, DNF might not be
installed because it would be obsoleted by DNF5-5.1.0, from rawhide
repositories.
Therefore, if you want to upgrade and use DNF < 5 on your rawhide system,
here are some steps that should help you.

1. If you intend to install the new packages from the side-tag, you might
want to exclude rawhide repositories. You have two options:

a. First, upgrade the system to the latest packages in the side-tag:
$ dnf5 upgrade \
  --best --releasever=39 \
  --disablerepo=* \
  --enablerepo=side-tag --repofrompath=side-tag,'
https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
'
Then, install DNF:
$ dnf5 install dnf \
  --best --releasever=39 \
  --disablerepo=* \
  --enablerepo=side-tag --repofrompath=side-tag,'
https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
'

b. You can achieve the same goal in one step:
$ dnf5 install "dnf < 5" \
  --best --releasever=39 \
  --disablerepo=* \
  --enablerepo=side-tag --repofrompath=side-tag,'
https://kojipkgs.fedoraproject.org/repos/f39-build-side-71087/latest/x86_64/
'

2. If you would rather not use the side-tag OR you are updating after the
packages are available in rawhide, you should have no issues. The same two
options follow:

a. Upgrade and install:
$ dnf5 upgrade --best
$ dnf5 install dnf --best

b. Or, with the one-liner:
$ dnf5 install "dnf < 5" --best

Please, don't hesitate to reach back if you cannot install the newest
packages,

Cheers,

Nicola

[1]: https://pagure.io/fesco/issue/3039
[2]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5fd964c1bf
[3]: https://koji.fedoraproject.org/koji/taginfo?tagID=71087
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 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

[Adam Williamson]

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?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Self Introduction: Julio Faracco

[Julio Faracco]

Hello all,

My name is Julio Faracco and I have been contributing to open-source
software for a long time in several manners. You can see my name in
some contributions like libvirt, qemu, packagekit, etc. Btw, I love
libvirt project but I'm rusty to return to contribute. I hope I can in
the near future. I have a strong knowledge of packaging in special by
using RPM tools. I looking to help the community by adopting any
orphan package that can be worth to Fedora.

Regards,

--
Julio Faracco
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Dropping of sshd.socket unit

[Petr Menšík]

Wouldn't a relative simple change to fix this would be explicit 
TriggerLimitBurst=0 until some form of timed reactivation is 
implemented? Especially for sshd.socket that change would seem safer. It 
is not a big deal for sshd, it seems to be quite small anyway.


Could simple

[Unit]
Restart=on-failure

solve this issue instead? If it fails, this should be able to keep it 
up. Does it manifest itself a different way?


On 03. 08. 23 11:29, Dmitry Belyavskiy wrote:

Dear colleagues,

I've pushed a fresh build of OpenSSH to rawhide.
We decided to drop the sshd.socket unit from rawhide. We don't think
it's worth going through the changes process, but would like to
provide a heads-up.

See the details in https://bugzilla.redhat.com/show_bug.cgi?id=2025716.


--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: How to: correctly use sysusers.d?

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 05, 2023 at 10:56:19PM +0200, Fabio Valentini wrote:
> I have a draft sysusers.d config file here:
> https://github.com/decathorpe/ntpd-rs-rpms/blob/main/ntpd-rs/ntpd-rs.sysusers
> 
> This looks similar to existing files in /usr/lib/sysusers.d/, but the
> %sysusers_create_compat scriptlet fails to parse this file (apparently
> it doesn't recognise the first line as a comment??) ...

This seems to work here.
$ rpmspec --define '_sourcedir .' --define '_builddir .' -P *.spec | rg -A6 -w 
%pre
%pre

# generated from ntpd-rs.sysusers
getent group 'ntpd-rs' >/dev/null || groupadd -r 'ntpd-rs' || :
getent passwd 'ntpd-rs' >/dev/null || \
useradd -r -g 'ntpd-rs' -d '/var/lib/ntpd-rs' -s '/sbin/nologin' -c 
'ntpd-rs system user' 'ntpd-rs' || : 

> The package needs to create /var/lib/ntpd-rs with mode 700 and have it
> owned by the ntpd-rs user, so if I understand correctly, just dropping
> in the sysusers.d config file is not enough, since the user won't be
> available during the RPM transaction to own this directory. Instead I
> would need to invoke the sysusers_crate macro in the package?

As Dominik wrote in the other reply, a tmpfiles.d drop-in would be be
the best solution for files in /var/lib.

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

Re: zlib-ng as a compat replacement for zlib

[Ali Erdinc Koroglu]

On 07/08/2023 15:29, Tulio Magno Quites Machado Filho wrote:

"Richard W.M. Jones"  writes:


The background to this is I've spent far too long trying to optimize
the conversion of qcow2 files to raw files.  Most existing qcow2 files
that you can find online are zlib compressed, including the qcow2
images provided by Fedora.  Each cluster in the file is separately
compressed as a zlib stream, and qemu uses zlib library functions to
decompress them.  When downloading and decompressing these files, I
measured 40%+ of the total CPU time is doing zlib decompression.


This number may go even higher on s390x [1] because zlib-ng supports
hardware acceleration.

qatzip [2] and libnxz [3] should provide performance on the same order of
magnitude for Intel and Power9 processors, with the negative side of not
using a single library.


We already package zlib-ng in Fedora:

   https://src.fedoraproject.org/rpms/zlib-ng/blob/rawhide/f/zlib-ng.spec
   https://github.com/zlib-ng/zlib-ng

In my test zlib-ng is about 40% faster.

Sadly zlib-ng is not compiled with the ZLIB_COMPAT option.  What this
means in practice is that the zlib functions have different names
(eg. zng_inflateInit instead of inflateInit).  It is not a drop-in
replacement for zlib and software would need to be adjusted to use it.

However there is this bug / RFE to package the compat library.

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

It literally replaces /usr/lib64/libz.so.1, so pretty high stakes.  It
has the appropriate Provides/Conflicts.

Anyway, 40% (or whatever, but significant) performance improvement
sounds good for a very widely used operation.

So I'd like to ask Fedora ...

What do we think about the opt in approach of adding a patch similar
to the one proposed in bug 2145239, where I think you could "simply"
install zlib-ng to get better performance with existing software?
("simply" because it seems high risk of going wrong)


Wearing my zlib-ng fedora maintainer hat:
I like the idea of this patch, although I think it needs a few changes.
I'd like to merge it and add another package with the same source code,
but different value for compat, i.e. package zlib-ng would still
distribute the zlib-ng API while the new package would distribute the
zlib-compatible API.

That way, if there are any projects using the zlib-ng API, they could
still be supported.

[1] https://github.com/rust-lang/libz-sys/pull/72#issuecomment-904020105
[2] https://src.fedoraproject.org/rpms/qatzip
[3] https://src.fedoraproject.org/rpms/libnxz


We were discussing the use of zlib-ng in Hyperscale and ISA SIG with Florian 
Weimer, Honza Horak, Matej Muzila and Neal Gompa for a while.
I've started to prepare a change proposal for Fedora 40, so any additional 
ideas are more than welcome.

--
Ali Erdinc Koroglu
Intel, SSE | Linux OS Systems Engineering
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: RFC authselect: mdns or mdns-minimal

[Petr Menšík]

On 07. 08. 23 12:49, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:

Hi Pavel,

With Avahi upstream maintainer hat on, I would say it still makes sense to
have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be used
just for *.local names. As I have wrote to referenced ticket, I think we
want to prefer mdns_minimal in the future, but it first needs solving
increased timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be better
to configure it on side of avahi-daemon.

Simpler is good if it still offers the features required by Fedora.


I think mdns resolution needs smarter approach from avahi-daemon. It might
be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read its
contents only on timestamp change. Maybe with checking the file stamp only
once per second at most.

Isn't inotify what should be used in such cases?

Regards,
Dominik


inotify is good for such changes, but I would prefer having inotify 
socket on side of avahi-daemon. I think inotify sockets are limited and 
should not be used by every common client application using nss plugin 
for resolution. Let alone by every thread. I think default limit of 
inotify sockets is something around 256.


/proc/sys/fs/inotify/max_user_instances gives 128 on my f37. nss plugin 
files reads /etc/hosts on every resolution too. I made the change to try 
opening /etc/mdns.allow from every call therefore. I am not sure how 
critical this file optimization might be.


I haven't found any good way to store cached structures after calls to 
getaddrinfo() or getnameinfo(), which would be reasonably safe to use in 
simple applications as well as threaded applications. It seems the way 
how glibc handles /etc/resolv.conf is not simple to be reused by other 
plugins. Cached structures might include allocated memory or any kind of 
socket, including inotify. Maybe it is the correct way to rely on 
filesystem caching and just call fopen() and fclose() on every name 
resolution attempt. That is thread-safe and well supported, is 
race-condition free.


res_ninit() call is able to open context for DNS resolution, but that is 
available only fro DNS specific resolution. The abstract getaddrinfo() 
or getnameinfo() have no way to open cache store on start and clean it 
on thread stop or application exit. I think optimizations should be done 
only if there is a correct way how to solve them. It seems to me 
original nss plugin system does not offer something similar.


Cheers,
Petr

--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: zlib-ng as a compat replacement for zlib

[Tulio Magno Quites Machado Filho]

"Richard W.M. Jones"  writes:

> The background to this is I've spent far too long trying to optimize
> the conversion of qcow2 files to raw files.  Most existing qcow2 files
> that you can find online are zlib compressed, including the qcow2
> images provided by Fedora.  Each cluster in the file is separately
> compressed as a zlib stream, and qemu uses zlib library functions to
> decompress them.  When downloading and decompressing these files, I
> measured 40%+ of the total CPU time is doing zlib decompression.

This number may go even higher on s390x [1] because zlib-ng supports
hardware acceleration.

qatzip [2] and libnxz [3] should provide performance on the same order of
magnitude for Intel and Power9 processors, with the negative side of not
using a single library.

> We already package zlib-ng in Fedora:
>
>   https://src.fedoraproject.org/rpms/zlib-ng/blob/rawhide/f/zlib-ng.spec
>   https://github.com/zlib-ng/zlib-ng
>
> In my test zlib-ng is about 40% faster.
>
> Sadly zlib-ng is not compiled with the ZLIB_COMPAT option.  What this
> means in practice is that the zlib functions have different names
> (eg. zng_inflateInit instead of inflateInit).  It is not a drop-in
> replacement for zlib and software would need to be adjusted to use it.
>
> However there is this bug / RFE to package the compat library.
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=2145239
>
> It literally replaces /usr/lib64/libz.so.1, so pretty high stakes.  It
> has the appropriate Provides/Conflicts.
>
> Anyway, 40% (or whatever, but significant) performance improvement
> sounds good for a very widely used operation.
>
> So I'd like to ask Fedora ...
>
> What do we think about the opt in approach of adding a patch similar
> to the one proposed in bug 2145239, where I think you could "simply"
> install zlib-ng to get better performance with existing software?
> ("simply" because it seems high risk of going wrong)

Wearing my zlib-ng fedora maintainer hat:
I like the idea of this patch, although I think it needs a few changes.
I'd like to merge it and add another package with the same source code,
but different value for compat, i.e. package zlib-ng would still
distribute the zlib-ng API while the new package would distribute the
zlib-compatible API.

That way, if there are any projects using the zlib-ng API, they could
still be supported.

[1] https://github.com/rust-lang/libz-sys/pull/72#issuecomment-904020105
[2] https://src.fedoraproject.org/rpms/qatzip
[3] https://src.fedoraproject.org/rpms/libnxz

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

Fedora rawhide compose report: 20230807.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230806.n.0
NEW: Fedora-Rawhide-20230807.n.0

= SUMMARY =
Added images:0
Dropped images:  4
Added packages:  2
Dropped packages:14
Upgraded packages:   134
Downgraded packages: 0

Size of added packages:  3.42 MiB
Size of dropped packages:14.99 MiB
Size of upgraded packages:   2.76 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230806.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230806.n.0.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20230806.n.0.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20230806.n.0.ppc64le.tar.xz

= ADDED PACKAGES =
Package: rust-gix-mailmap-0.16.1-1.fc39
Summary: Parser for mailmap files for gix
RPMs:rust-gix-mailmap+default-devel rust-gix-mailmap+serde-devel 
rust-gix-mailmap-devel
Size:48.24 KiB

Package: rust-tiny-dfr-0.1.1-2.fc39
Summary: Most basic dynamic function row daemon possible
RPMs:tiny-dfr
Size:3.37 MiB


= DROPPED PACKAGES =
Package: golang-github-burntsushi-xgbutil-0-0.14.20210114gitad855c7.fc36
Summary: Utility library to make use of the X Go Binding easier
RPMs:golang-github-burntsushi-xgbutil-devel
Size:192.79 KiB

Package: golang-github-docker-slim-1.36.4-4.fc36
Summary: Minify your Docker container image by up to 30x
RPMs:golang-github-docker-slim golang-github-docker-slim-devel
Size:14.27 MiB

Package: golang-github-facebookarchive-inject-0-0.10.20190326gitf23751c.fc36
Summary: Reflect based injector
RPMs:compat-golang-github-facebookgo-inject-devel 
golang-github-facebookarchive-inject-devel
Size:29.48 KiB

Package: golang-github-facebookarchive-structtag-0-0.10.20190327git217e25f.fc36
Summary: Package providing parsing of the defacto struct tag style
RPMs:compat-golang-github-facebookgo-structtag-devel 
golang-github-facebookarchive-structtag-devel
Size:20.45 KiB

Package: golang-github-facebookgo-ensure-0-0.3.20210705git63f1cf6.fc36
Summary: Ensure the given conditions are met and Fatal if they aren't
RPMs:golang-github-facebookgo-ensure-devel
Size:14.58 KiB

Package: golang-github-facebookgo-stack-0-0.3.20210702git7517733.fc36
Summary: Utilities to capture and pass around stack traces
RPMs:golang-github-facebookgo-stack-devel
Size:13.62 KiB

Package: golang-github-haproxytech-models-2.2.0-4.fc36
Summary: HAProxy Go structs for API
RPMs:compat-golang-github-haproxytech-models-2-devel 
golang-github-haproxytech-models-devel
Size:94.10 KiB

Package: golang-gopkg-seborama-govcr-2-2.4.2-7.fc36
Summary: HTTP mock for Golang
RPMs:golang-gopkg-seborama-govcr-2-devel
Size:28.57 KiB

Package: rust-aparato-6.0.2-4.fc39
Summary: Pci.ids-compliant library for getting information about available PCI 
devices
RPMs:rust-aparato+default-devel rust-aparato-devel
Size:25.49 KiB

Package: rust-clap_complete_fig3-3.2.4-2.fc39
Summary: Generator library used with clap for Fig completion scripts
RPMs:rust-clap_complete_fig3+default-devel rust-clap_complete_fig3-devel
Size:24.15 KiB

Package: rust-gsk4_0.4-0.4.8-3.fc39
Summary: Rust bindings of the GSK 4 library
RPMs:rust-gsk4_0.4+broadway-devel rust-gsk4_0.4+default-devel 
rust-gsk4_0.4+dox-devel rust-gsk4_0.4+v4_2-devel rust-gsk4_0.4+v4_4-devel 
rust-gsk4_0.4+v4_6-devel rust-gsk4_0.4-devel
Size:97.90 KiB

Package: rust-gtk4-macros0.4-0.4.10-2.fc39
Summary: Macros helpers for GTK 4 bindings
RPMs:rust-gtk4-macros0.4+default-devel rust-gtk4-macros0.4-devel
Size:38.39 KiB

Package: rust-gtk4-sys0.4-0.4.8-3.fc39
Summary: FFI bindings of GTK 4
RPMs:rust-gtk4-sys0.4+default-devel rust-gtk4-sys0.4+dox-devel 
rust-gtk4-sys0.4+v4_2-devel rust-gtk4-sys0.4+v4_4-devel 
rust-gtk4-sys0.4+v4_6-devel rust-gtk4-sys0.4+v4_8-devel rust-gtk4-sys0.4-devel
Size:133.03 KiB

Package: rust-num-traits0.1-0.1.43-18.fc39
Summary: Numeric traits for generic mathematics
RPMs:rust-num-traits0.1+default-devel rust-num-traits0.1-devel
Size:23.43 KiB


= UPGRADED PACKAGES =
Package:  Carla-1:2.5.6-1.fc39
Old package:  Carla-1:2.5.5-2.fc39
Summary:  Audio plugin host
RPMs: Carla Carla-devel Carla-vst lv2-carla
Size: 55.27 MiB
Size change:  32.61 KiB
Changelog:
  * Sun Aug 06 2023 Martin Gansser  - 1:2.5.6-1
  - Update to 2.5.6


Package:  OpenImageIO-2.4.14.0-2.fc39
Old package:  OpenImageIO-2.4.14.0-1.fc39
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 21.89 MiB
Size change:  1.89 KiB
Changelog:
  * Mon A

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

Re: Restricting automounting of uncommon filesystems?

[Lennart Poettering]

On Sa, 22.07.23 07:01, Matthew Garrett (mj...@srcf.ucam.org) wrote:

> A discussion within Debian again brought up the problem that:
>
> 1) Automounting of removable media exposes the kernel to a lot of
> untrusted input
> 2) Kernel upstream are not terribly concerned with ensuring that kernel
> filesystems are resilient against deliberately malformed filesystems so
> are mostly not proactively looking for bugs there
> 3) Uncommonly used filesystems are less likely to be tested against
> adverse input in the real world and so are more likely to contain
> exploitable bugs
>
> There are various cases where people do need to make use of uncommon
> filesystems, but the majority of them aren't related to removable media.
> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
> shouldn't be automounted, which means something like:
>
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> # repeat as necessary for anything else that shouldn't be automounted
> LABEL="udisks_insecure_fs_end"

I am not convinced that the udev db is really a great place for such
configuration that is not really related to devices itself, but more
about local policy decisions.

What I think is important to keep in mind is that /bin/mount doesn't
check the udev db (and probably shouldn't) when determining the fstype
to mount when using "-t auto" (which is implied if -t is omitted). I
think it would make sense to devise a mechanism that automatic
mounting for removable disks is covered the same way as "mount -t
auto" by such an allowlist of fstypes.

My preferred mechanism to implement what you are asking for is what
I proposed here:

https://github.com/util-linux/util-linux/issues/1969

And as it turns out Karel actually implemented this recently, see
https://github.com/util-linux/util-linux/commit/1592425a0a1472db3168cd9247f001d7c5dd84b6.

I think it would be a good idea to build on that, i.e. make udisks
just set that mount option to a useful allowlist, and then be done
with it?

Lennart

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

Re: How to: correctly use sysusers.d?

[Dominik 'Rathann' Mierzejewski]

On Saturday, 05 August 2023 at 22:56, Fabio Valentini wrote:
[...]
> Any help would be appreciated.

I think you need a combination of sysusers.d and tmpfiles.d. One example
would be the minidlna package I moved over from RPM Fusion recently:
https://src.fedoraproject.org/rpms/minidlna/blob/rawhide/f/minidlna.spec

Hopefully, that helps.

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

Re: RFC authselect: mdns or mdns-minimal

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
> Hi Pavel,
> 
> With Avahi upstream maintainer hat on, I would say it still makes sense to
> have separate mdns*_minimal and mdns? modules. I would say mdns
> (non-minimal) should be rarely needed, because by default it should be used
> just for *.local names. As I have wrote to referenced ticket, I think we
> want to prefer mdns_minimal in the future, but it first needs solving
> increased timeouts for not present names [1]. As soon as it is solved on
> avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
> variants. If only one family should be resolved, I think it would be better
> to configure it on side of avahi-daemon.

Simpler is good if it still offers the features required by Fedora.

> I think mdns resolution needs smarter approach from avahi-daemon. It might
> be useful to not open and re-parse /etc/mdns.allow on every single
> ``getaddrinfo()`` call, but cache it in thread local storage and re-read its
> contents only on timestamp change. Maybe with checking the file stamp only
> once per second at most.

Isn't inotify what should be used in such cases?

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

Re: RFC authselect: mdns or mdns-minimal

[Pavel Březina]

On 8/2/23 17:04, Petr Menšík wrote:
I have created upstream pull request, which makes non-minimal plugins to 
behave like minimal plugins except it tries to find /etc/mdns.allow. If 
that file does not exist, it copies also reverse queries from minimal 
plugin.


Here:
https://github.com/lathiat/nss-mdns/pull/89

On 02. 08. 23 9:15, Zdenek Dohnal wrote:

On 8/1/23 12:41, Petr Menšík wrote:

Hi Zdenek,
the current logic is:
- with-mdns4: mdns4_minimal
- with-mdns6: mdns6_minimal
- with-mdns4 and with-mdns6? mdns_minimal

Ah, I have missed last part, that it uses mdns plugin for both queries.


If I understand your message correctly, you propose to keep this 
logic but use mdns4/mdns6/mdns instead of minimal and drop support 
for minimal completely. Is that right?


Thank,
Pavel

No, not at all. We want minimal variants preferred until nss-mdns is 
changes significantly. Check nss-mdns issue #88 [1].


1. https://github.com/lathiat/nss-mdns/issues/88


Petr, this issue exists only if mdns.allow exists, so if we don't ship 
it as I recommend, we don't hit this issue. The file will be created 
by a user in case he needs to override settings which are against 
standards, where IMO a delay is tolerable. Thus, the issue is nice to 
have and should not block using mdns4/mdns6 variants. What I would 
support is adding a note into README file of nss-mdns, mentioning the 
delay due the mentioned bug - until it is fixed.


So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead 
of minimal variants, because they provide the same functionality as 
minimal + possibility to override network misconfigurations. And don't 
use complete 'mdns' by default.
Okay, makes sense, once we include required changes into stable 
releases. I have created bug #2228533 to track this change, which once 
in stable, authselect might switch to non-minimal variants.


IIUC, when 2228533 is resolved, I should switch from mdns[-|4|6]_minimal 
to mdns[-|4|6] and otherwise keep it as is? The order of the modules 
should be also kept:


Current order  is:

hosts: files myhostname libvirt libvirt_guest 
mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve 
[!UNAVAIL=return] dns


Thanks,
Pavel





But I'm not a nss-mdns or avahi maintainer, just a maintainer of 
stacks which use mdns often - printing and scanning. I've got this 
opinion from issues in past, by checking nss-mdns code and by 
intention of minimizing of new work in authselect, unless it is 
necessary.



Zdenek


Yes, I admit current way of providing different plugins instead of one 
plugin with related configuration is unfortunate. Because it depends on 
avahi-daemon anyway, I hope it can be reduced to single plugin, where 
every customization can be done on side of avahi-daemon. But needs code 
modifications first, so waiting for a volunteer.



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: zlib-ng as a compat replacement for zlib

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 05, 2023 at 04:45:36PM +0100, Neal Gompa wrote:
> I think it'd be worth us moving to zlib-ng as the sole zlib provider.

+1. zlib-ng is already widely used, so if it has issues, then we'd have a
major problem. So we're not really saving much by having two implementations.
One library is better than two libraries, and 40% is a significant difference.

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

Re: GNOME 45.beta builds for Fedora

[Fabio Valentini]

On Mon, Aug 7, 2023 at 12:26 PM Kalev Lember  wrote:
>

(snip)

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

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.

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

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: Dropping of sshd.socket unit

[Lennart Poettering]

On Do, 03.08.23 11:29, Dmitry Belyavskiy (dbely...@redhat.com) wrote:

> Dear colleagues,
>
> I've pushed a fresh build of OpenSSH to rawhide.
> We decided to drop the sshd.socket unit from rawhide. We don't think
> it's worth going through the changes process, but would like to
> provide a heads-up.

Hmm, why drop it? For many setups, it makes not sense to continously
run sshd, so socket activation should be fine.

I don't understand the reasoning behind this change. You claim a
DoS. Which DoS is that supposed to be? That we enforce a trigger time
limit on socket units by default? If you don't want this, turn it off,
that's what TriggerLimitIntervalSec=/TriggerLimitBurst= is for, see
docs.

The discussion makes this sound as if there was a bug in systemd or
so, but there really isn't, it's literally a safety feature you ran
into. It might not make sense to have the trigger rate limit in place
for all usecases, ssh might be one where it is not advisable, but then
the right approach is to just turn that part off, as documented, via
the aforementioned options.

See for details:

https://www.freedesktop.org/software/systemd/man/systemd.socket.html#TriggerLimitIntervalSec=

I don't care too much whether you make ssh socket-activated by default
or not. But at least the option should exist, already for compat with
existing setups.

Lennart

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

Re: Summary/Minutes from today's FESCo Meeting (2023-07-27)

[Jaroslav Mracek]

Hello,

The release is under testing. See f39-build-side-71087.

Best regards

Jaroslav

On Tue, Aug 1, 2023 at 4:33 PM Miro Hrončok  wrote:

> On 27. 07. 23 20:03, Tom Stellard wrote:
> > * #3039 RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency
> >Mechanism  (tstellar, 17:04:33)
> >* AGREED: APPROVED(+7,0,-0) The switch to DNF5 will be postponed
> >  (likely to Fedora 41, to be determined by the Change Owners) and
> >  reverted in Rawhide for the time being (i.e. dnf 4 will provide
> >  /usr/bin/dnf again).  (tstellar, 17:27:21)
>
> Now when this was agreed upon, could it please be reverted right away? It
> has
> been 5 days already and I see no benefit in further delay when we know we
> will
> ship Fedora 39 with dnf4.
>
> Thnaks
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Test-Announce] Proposal to CANCEL: 2023-08-07 Fedora QA Meeting

[Luna Jernberg]

Hey
Won't attend today having too much headache and needs a relax day,
will try to attend next time

Den sön 6 aug. 2023 kl 19:48 skrev Adam Williamson :
>
> Hi folks! I'm proposing we cancel the QA meeting tomorrow. It's a
> holiday in Canada and some folks may still be recovering from Flock.
> If anyone thinks we should have a meeting and wants to run it instead
> of me, please go ahead and send out an agenda and plan to run the
> meeting - see https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process
>
> Thanks folks!
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> ___
> test-announce mailing list -- test-annou...@lists.fedoraproject.org
> To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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