wlroots 0.15 update is coming to rawhide
by Aleksei Bavshin
Greetings,
By the end of this week I'm planning to update wlroots in rawhide to
0.15 (libwlroots.so.10) and sway to the latest release candidate.
No breakages are expected as wlroots0.14 compatibility package will be
introduced in the same side-tag.
Additionally, I intend to retire wlroots0.12 and wlroots0.13 before f36
is branched.
Currently only `phoc` and `gamescope` depend on these compatibility
packages. Both have releases or patches with support for new wlroots
versions, so I'll retire the compat libs once we get the updates in rawhide.
--
Best regards,
Aleksei Bavshin
2 years, 3 months
[Discussion] Future of the CLI APP packaging
by Jiri Konecny
Hi everyone,
I would like to do here a bit of brainstorming and ask if there is an
existing solution to this problem. To explain my problem,
recently I found more and more apps likes terminals, prompt and command
line tooling, which are great to use but not
packaged or are outdated in our repositories. The reason for this is
simple. These apps are written in languages like Rust or
Go which works the way that there are plenty of smaller libraries and
these are really a hell to package or maintain in
Fedora. On the other hand it's pretty simple to build it from the source
(most of the time) but hard to split it into packages.
Great example of this is Startship command line prompt, we have outdated
version but when you look to dependencies[1]
you have to completely understand.
I don't want to start here a discussion if that is insecure or a good
idea. That is something which has to be solved by
people creating the ecosystem around these languages. What I would like
to discuss here is how Fedora could improve
the situation.
I would say, that for GUI apps we already done that. We have Flatpak
which is doing great job to get these apps there
and motivate people to do that because it's then consumable on plenty of
places. However, this is not really usable if you
need app which is core part of the system (like prompt) or emacs/vim
which needs a lot of dependencies from the system
based on user configuration.
My question is, what we can do to avoid situations as in Windows? I mean
that first thing what Win users are doing is to
look on internet and start to download random binaries. Do we have
something like Flatpaks for core parts of the system
now? Is there something we could adopt? Am I completely wrong with my
assumptions :D?
Also want to mention that I don't have much experience with this. It's
more that I'm worried and maybe this discussion
could lead to something in the future.
Best Regards,
Jirka Konecny
2 years, 3 months
Re: gcc-12.0.0-0.4.fc36 in rawhide
by Richard W.M. Jones
On Sat, Jan 15, 2022 at 01:50:19PM -0700, Martin Sebor wrote:
> Having said that, checking and handling possible truncation before
> calling snprintf() is doing double the work. I would suggest to get
> rid of the check and instead handle the truncation after it happens.
> This is both simpler and faster, and avoids the warning:
>
> if (snprintf (*sockpath, UNIX_PATH_MAX,
> "%s/%s", g->sockdir, filename) < UNIX_PATH_MAX)
> return 0;
>
> error (g, _("socket path too long: %s/%s"), g->sockdir, filename);
> return -1;
> }
Oh that's a good idea, thanks!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
2 years, 3 months
Heads-up: trousers (TPM 1.2) silently orphaned
by Michel Alexandre Salim
Hi all,
`trousers` got silently orphaned around the time an EPEL9 branch for it
was requested: https://bugzilla.redhat.com/show_bug.cgi?id=2032258
Looks like we're slowly uncoupling ourselves from it, e.g.
- for ARM, uboot-tools no longer pulls in vboot-utils which pulls in
trousers: https://lists.fedoraproject.org/archives/list/scm-commits@lists.fedorapro...
- Neal disabled TPM/TSS 1.2 support in strongswan, dropping the trousers
dependency, in https://src.fedoraproject.org/rpms/strongswan/pull-request/13
but there are several dependencies still around (strongswan still shows
up here as the PR just got merged a few hours ago)
```
~
❯ sudo dnf repoquery --disablerepo=\* --enablerepo=rawhide-source --whatrequires trousers-devel
Last metadata expiration check: 0:00:10 ago on Thu 16 Dec 2021 10:08:04 AM PST.
ecryptfs-utils-0:111-25.fc36.src
gnutls-0:3.7.2-2.fc35.src
golang-github-google-tspi-0:0.2.0-6.fc35.src
openconnect-0:8.10-7.fc35.src
strongswan-0:5.9.4-3.fc36.src
tpm-quote-tools-0:1.0.4-8.fc35.src
tpm-tools-0:1.3.9-12.fc36.src
vboot-utils-0:20190823-8.git595108c0.fc36.src
```
Do we want to keep trousers in Fedora? If so someone who needs it should probably step up, if not, we should toggle it off in these packages. Maintainers BCC:ed.
Best regards,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
2 years, 3 months
koji hubs and builders updated
by Kevin Fenzi
Just thought I would share that (finally) we have completed upgrades on
the koji hubs and builders.
The hubs have been upgraded to Fedora 35 and
the latest koji version (1.17.1).
Builder hypervisors have been upgraded to RHEL8.5 and the latest
advanced virt stack. Builders have been upgraded/reimaged to Fedora 35
and the latest packages.
On armv7 builders: As you all know due to
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
( Overeager OOM kills on 5.10 kernels on 32bit arm with lpae )
we had been running an old kernel on them, but after some testing in
staging it seemed that the upcoming 5.16 kernel worked pretty well.
So, All of them are running that now. There have been some OOM kills
already, I'm playing around with options on them to try and get that
number to 0. Hopefully they will be ok for the mass rebuild.
On s390x builders: We got some more resources, so the kvm builders now
have more memory and cpus. I've asked for some more disk space and once
we have that I plan to spread those resources out to have 2x as many
builders (ie, now: 4 cpus, 20gb mem x 10, after: 2 cpus, 10gb mem x 20)
I don't know if this will be done in time for the mass rebuild, but
hopefully so.
On ppc64le: We have some more power9 hardware waiting to be put in
service, so we should be adding some builders here, and/or spreading out
resources.
Thanks for everyone's patience with builds that have been taking a while
or restarting. Do continue to report them and we will do the best we can
to fix things.
kevin
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 3 months
