Possibly non-responsive maintainer: olem
by Fabio Valentini
Hi everybody,
The Rust SIG and I have been waiting for responses from Olivier (FAS:
olem) for a while. I had noticed that their Rust packages started
accumulating FTBFS / FTI / release-monitoring bugs, as we get CCd on
those bugzillas. According to koji / dist-git / bodhi / pagure.io,
their last activity in Fedora happened on December 6, 2021, but zero
activity since then.
Initially I thought that this might be related to the holidays, so I
waited until January to reach out. A little over two weeks ago, I
tried contacting Olivier directly via the email address associated
with their FAS account, offering help with those Rust packages, but I
have not received a response, either.
Does anybody know how to contact Olivier, or if they're still
interested in maintaining their (Rust) packages?
Fabio
2 years, 2 months
Re: OpenVPN 2.x with kernel acceleration
by David Sommerseth
[bouncing this msg, as Antonio is not subscribed to this devel list]
Hi,
On 04/02/2022 15:35, David Sommerseth wrote:
>
> On 04/02/2022 15:09, Neal Becker wrote:
>> Does this modified openvpn support all the same features/options as the
>> stable release version?
>
> Almost. I recommend to have a look at the README.dco.md [0]
> documentation for details, as that lists the limitations quite nicely.
>
> [0]
> <https://github.com/OpenVPN/openvpn/blob/dco/README.dco.md#limitations-by-...>
I would like to add that if you use an unsupported option, openvpn will
tell you about that with a warning and will fallback to non-DCO mode
(i.e. will just use tun as usual).
Cheers,
--
Antonio Quartulli
OpenVPN Inc.
2 years, 2 months
OpenVPN 2.x with kernel acceleration
by David Sommerseth
Hi,
An OpenVPN colleague of me, Antonio Quartulli (on Cc), has been working
on a kernel acceleration module for OpenVPN for quite some time. We
call this OpenVPN Data Channel Offload (DCO). This moves the tunnelled
network traffic to a new kernel module (ovpn-dco) and keep only the
control channel (authentication, VPN IP configuration, etc) in
user-space. This is gives a noticeable improved performance.
We have had that support available in the OpenVPN 3 Linux for quite some
time. But that is currently only a client-mode only implementation. So
the real benefit of DCO has been limited when connecting to OpenVPN 2.x
servers.
In parallel with that, we have now reached a point where we also have
code ready for OpenVPN 2.x which can make use of DCO - also for the
server side. This code is currently going through review in among the
developers in the OpenVPN community.
But! We have now a dedicated Fedora Copr repository available for those
willin
g to test this out.
# yum copr enable dsommers/openvpn-dco
# yum copr enable dsommers/openvpn3
# yum install openvpn kmod-ovpn-dco
The ovpn-dco kernel module is tried first, and if that succeeds OpenVPN
2.x will now use that instead of tun.ko. There is a new --disable-dco
option which will force not using DCO, which is useful when testing
performance.
One performance tip ... Ensure your tun-mtu is 1420 or slightly lower,
this is to avoid packet fragmentation which will reduce ability for
ovpn-dco to work optimally. We are looking into ways to make the MTU
settings better by default, but we're not there yet. This is the only
configuration change which might be needed.
Even though, I've mentioned OpenVPN 2.x server mode explicitly here ...
It will also work with OpenVPN 2.x in client mode too. If you also try
the OpenVPN 3 Linux to compare the performance, you should not really
notice much difference - as it's the same kernel module doing th
e heavy
lifting.
If you test this out, feel free to reach out on our OpenVPN developers
mailing list [0], on IRC [0] or to Antonio (Cc) who is overseeing the
DCO development.
[0]
<https://community.openvpn.net/openvpn/wiki/GettingHelp#Developersupport>
--
kind regards,
David Sommerseth
OpenVPN Inc
2 years, 2 months
Package notes feature causing build paths to be embedded
by Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=2043092
This is not about the feature itself but about the way it has been
implemented.
During builds LDFLAGS is modified so it contains a build path,
something like:
-Wl,-dT,/builddir/build/BUILD/.package_note-rubygem-nio4r-2.5.2-6.fc36.x86_64.ld
Many builds embed/store LDFLAGS somewhere. For OCaml it gets embedded
in the ocamlopt binary, and in *.cma files. Similar sort of thing
happening in Ruby, Perl, Haskell, Python, ...
But the problem is more general than this too. It also turns up in
some *.pc (pkgconf) files.
I think this change should be reverted until a cleaner way can be
found to implement it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 2 months
Request repo only with EPEL banch
by Filip Janus
Hi everyone,
I have an issue with requesting repo only with epel8 branch. fedpkg
request-repo doesn`t
support any option related to branch name by default it sends the request
for new repo with rawhide branch. I also tried to request branch epel8 for
non-existing repo, but it failed as expected.
I`ve already asked it in the ticket[1] but it was again closed by
automatization without response.
[1] https://pagure.io/releng/fedora-scm-requests/issue/41693
Thanks
-Filip-
2 years, 2 months
Unannounced soname bump: liborcus
by Ian McInerney
It appears that liborcus had an soname bump yesterday from 0.16 to 0.17,
and the dependent packages were not rebuilt at the time. This seems to
affect only LibreOffice, but makes it non-installable in Rawhide. Can
someone rebuild it for the new library version?
Thanks,
-Ian
2 years, 2 months
CPE Weekly Update – Week of January 31st – February 4th
by Lenka Segura
Hi everyone,
This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).
If you wish to read this in the form of a blog post, check the post on
Fedora community blog:
https://communityblog.fedoraproject.org/?p=10714
# Highlights of the week
## Infrastructure & Release Engineering
Goal of this Initiative
-----------------------
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.
Update
--------
### Fedora Infra
* All fedora ansible hosts (except aws) now using
linux-system-roles/network for network config!
* Several upstream koji issues. One tagging issue fixed, one new one still
being worked on. ;(
* Got networking setup so CentOS iad2 master mirror could read Fedora
netapp. (to prep for adding space there for them)
* Invalid users disabled (ones with _ - . and one char)
### CentOS Infra including CentOS CI
* Centos 8 has been retired and removed from mirrors
* Big [storage reorganization](https://pagure.io/centos-infra/issue/618)
(multiple HDD issues, or pending - pfa mode-) , going from out of warranty
to still out of warranty node (risk mitigation)
* Business as usual
### Release Engineering
* Rawhide composes failing, been a long string of bugs
## CentOS Stream
Goal of this Initiative
-----------------------
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.
Updates
-------
* New version of [Content Resolver](https://tiny.distro.builders/) with an
integrated buildroot resolver is live! There are testing views ([ELN](
https://tiny.distro.builders/view--view-eln-test.html) and [Stream](
https://tiny.distro.builders/view--view-c9s-test.html)) using the new
resolver, the proper ones will be switched to that soon after some extra
validation. All following updates will be again showing up as they come,
this bigger one just had to come at once.
* Started the work on bringing CS8 and CS9 workflows together.
* Otherwise business as usual.
## CentOS Duffy CI
Goal of this Initiative
-----------------------
Duffy is a system within CentOS CI Infra which allows tenants to provision
and
access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the current
state
of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.
Updates
-------
* Still ongoing :)
* Legacy API
* Backend tasks integration
## Image builder for Fedora IoT
Goal of this Initiative
-----------------------
Integration of Image builder as a service with Fedora infra to allow Fedora
IoT migrate their pipeline to Fedora infra.
Updates
-------
* End to end running(ish) locally
* Configuring of the plugins this week
* Image builder team still blocking but not for long as they are landing
PRs now
* Spent some time as a team understanding the full e2e flow of osbuild and
how it will fit in the Fedora IoT architecture
## Bodhi
Goal of this Initiative
-----------------------
This initiative is to separate Bodhi into multiple sub packages, fix
integration and unit tests in CI, fix dependency management and automate
part of the release process.
Read ARC team findings in detail at:
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html
Updates
-------
* Bodhi has been split into multiple packages
* bodhi-ci has been cleaned up (split into multiple source files)
* Vagrant box now works out of the box (previously some systemd services
were failing after provisioning)
* CI tests now run using GitHub Actions
## EPEL
Goal of this initiative
-----------------------
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates, maintains, and manages a high quality set of additional
packages for Enterprise Linux, including, but not limited to, Red Hat
Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux
(OL).
EPEL packages are usually based on their Fedora counterparts and will never
conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror manager
and more.
Updates
-------
* EPEL9 up to 1648 source packages (increase of 109 from last week)
* Three EPEL talks happening at CentOS Dojo, starting tomorrow
Kindest regards,
CPE Team
2 years, 2 months
koji build fails with "No matching package to install"
by Martin Gansser
Hi,
the koji build of Carla-2.4.1-4.fc35.src.rpm [1] fails for F35[2] and rawhide [3]
DEBUG util.py:444: No matches found for the following disable plugin patterns: local, spacewalk, versionlock
DEBUG util.py:444: No matching package to install: 'freetype-devel(x86-32)'
DEBUG util.py:444: No matching package to install: 'gcc-c++(x86-32)'
DEBUG util.py:444: No matching package to install: 'glibc-devel(x86-32)'
DEBUG util.py:444: No matching package to install: 'graphite2-devel(x86-32)'
DEBUG util.py:444: No matching package to install: 'libX11-devel(x86-32)'
DEBUG util.py:444: No matching package to install: 'libXext-devel(x86-32)'
DEBUG util.py:444: No matching package to install: 'wine(x86-32)'
DEBUG util.py:444: No matching package to install: 'wine-devel(x86-32)'
DEBUG util.py:444: Not all dependencies satisfied
DEBUG util.py:444: Error: Some packages could not be found.
DEBUG util.py:598: Child return code was: 1
$ koji build --scratch rawhide ../SRPMS/Carla-2.4.1-4.fc35.src.rpm
$ koji build --scratch f35 ../SRPMS/Carla-2.4.1-4.fc35.src.rpm
[1] https://martinkg.fedorapeople.org/Packages/Carla/Carla-2.4.1-4.fc35.src.rpm
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=82337754
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=82337518
what does this mean and how can i solve this ?
Regards
Martin
2 years, 2 months
hdf5 fortran build failure with gcc 12
by Orion Poplawski
hdf5 is starting to fail to build with gcc 12 in rawhide with:
make[2]: Entering directory
'/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test'
/bin/sh ../../libtool --tag=FC --mode=link gfortran -std=f2008
-Waliasing -Wall -Wcharacter-truncation -Wextra -Wimplicit-interface
-Wsurprising -Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std
-Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination
-Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only
-Winteger-division -Wfrontend-loop-interchange -fdiagnostics-urls=never
-fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld
-fPIC -Wl,-z,now -Wl,--as-needed -o fortranlib_test_1_8 tH5O.o
tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o
libh5test_fortran.la ../../test/libh5test.la
../../fortran/src/libhdf5_fortran.la ../../src/libhdf5.la -lsz -lz -ldl -lm
libtool: link: gfortran -std=f2008 -Waliasing -Wall
-Wcharacter-truncation -Wextra -Wimplicit-interface -Wsurprising
-Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std
-Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination
-Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only
-Winteger-division -Wfrontend-loop-interchange -fdiagnostics-urls=never
-fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-m64 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules
-Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
-Wl,-dT
-Wl,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld
-fPIC -Wl,-z -Wl,now -Wl,--as-needed -o .libs/fortranlib_test_1_8 tH5O.o
tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o
./.libs/libh5test_fortran.a ../../test/.libs/libh5test.a
../../fortran/src/.libs/libhdf5_fortran.so
/builddir/build/BUILD/hdf5-1.12.1/build/src/.libs/libhdf5.so
../../src/.libs/libhdf5.so -lsz -lz -ldl -lm
../../../fortran/test/tf.F90:169:33: warning: type of 'h5_fixname_c'
does not match original declaration [-Wlto-type-mismatch]
169 | full_name, full_namelen)
| ^
../../../fortran/test/t.c:43:1: note: type mismatch in parameter 6
43 | nh5_fixname_c(_fcd base_name, size_t_f *base_namelen, hid_t_f
*fapl, _fcd full_name, size_t_f *full_namelen)
| ^
../../../fortran/test/t.c:43:1: note: type 'void' should match type
'long int'
../../../fortran/test/t.c:43:1: note: 'h5_fixname_c_' was previously
declared here
../../../fortran/test/tf.F90:220:56: warning: type of 'h5_cleanup_c'
does not match original declaration [-Wlto-type-mismatch]
220 | hdferr = h5_cleanup_c(base_name, base_namelen, fapl)
| ^
../../../fortran/test/t.c:85:1: note: type mismatch in parameter 4
85 | nh5_cleanup_c(_fcd base_name, size_t_f *base_namelen, hid_t_f
*fapl)
| ^
../../../fortran/test/t.c:85:1: note: type 'void' should match type
'long int'
../../../fortran/test/t.c:85:1: note: 'h5_cleanup_c_' was previously
declared here
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: warning: relocation against
`minusone.31' in read-only section `.text'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans0.ltrans.o: in function
`__th5a_1_8_MOD_attribute_test_1_8.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.46'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: in function
`__th5a_1_8_MOD_test_attr_info_by_idx.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.18'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: in function
`__th5a_1_8_MOD_test_attr_delete_by_idx.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld:
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84:
undefined reference to `minusone.31'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:999: fortranlib_test_1_8] Error 1
I have no idea what is going on here. Any clues?
--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 years, 2 months
