fedpkg clone fails with Permission denied (publickey).
by Richard Shaw
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
scratch.
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
real intuitive.
Thanks,
Richard
1 year, 4 months
Mesa in F37- vaapi support disabled for h264/h265/vc1
by Frantisek Zatloukal
Hi,
since this mesa change (
https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373f...
) in F37 and rawhide, the mesa package lost support for vaapi accelerated
encoding and decoding of h264, h265 and decoding of vc1 (
https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ).
It seems like a big regression from F36 for users with GPUs with open
source drivers (mainly AMD, maybe nVidia/other non x86...), that affects
common use-cases of Fedora Workstation, like watching videos, in-house game
streaming, attending online meetings and many more.
I'd like to ask:
- Can somebody elaborate on reasons to change something that was working in
Fedora for some time already?
- Is there any short/mid/long term plan to improve the situation?
- Would it be possible to provide vaapi support at least as an rpmfusion
addon to alleviate the fallout in the short term?
Thanks!
--
Best regards / S pozdravem,
František Zatloukal
Senior Quality Engineer
Red Hat
1 year, 5 months
CVE Tracking Bugs
by Maxwell G
Hi Fedorians,
I think the security tracking bug filing process needs to be amended. The
current process is quite frustrating for me and other contributors. This
is especially bad for Go CVEs, which there are lot of.
Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
_and_ all Red Hat products and CCs a bunch of Fedora maintainers. They
then create separate bugs for each package that they deem affected. The
affected packages are oftened determined in a manner that appears
overzealous and arbitrary.
After the bugs are created, we get spammed with a bunch of notifications
about private bugs, RH product errata, and various other things that are
completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
and obscure actual issues that I need to address. I do not really care
whether a Go CVE has been mitigated in Red Hat Advanced Cluster
Management for Kubernetes 2.4 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8"
or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
---
Some particularly egregious examples:
I maintain an Ansible kubernetes collection, and they reported it as
vulnerable to some CVE with a specific Openshift component. The
collection not vulnerable. They provided no actionable information, and
the description was unclear. When I asked why it was reported, they said
that the package "used OpenShift."
A couple Go CVEs ago[^1], they created bugs against hundreds of Go
libraries. They arbitrarily chose branches and packages. The bugs were
not actionable by packagers of individual go libraries. Only applications
that provide binaries need to be rebuilt. They were reported shortly
before the F34 EOL, so we got a huge amount of emails after the bugs were
automatically closed. In fact, a Go packager reported that these messages
from the _security_ team DOSed their mail server. To their credit, they
have fixed this issue after one of the other Go SIG people talked to
them. Now, these bugs are only filed against the golang component.
[^1]: Really, it was a couple Go releases ago. There are multiple CVEs
reported with each Go release these days.
Another time, their automation posted the exact same comment over 200
times.
---
First and foremost, there needs to be a clear way for packagers to report
problems with this process to prodsec.
I don't think Fedora packagers should be CCed on these global trackers.
We could create a separate "Security Response" component under the
"Fedora" Bugzilla product to create tracker bugs for CVEs that affect
multiple Fedora components, or we could ask prodsec to only CC Fedora
maintainers on the child, package-level bugs. I guess I could acomplish
what I'm proposing by filtering out mails with "X-Bugzilla-Product:
Security Response" headers and not have gone on this rant, but I still
think this needs to be addressed.
Does anyone know how to reach prodsec about this?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
1 year, 5 months
Fedora SCM requests on the weekend
by Robert-André Mauchin
Hello,
I know a lot of you are working on Fedora during the week days, but for some of us, the
weekend is the only time we can spend time on it. The problem is, SCM requests are rarely
processed during that time, most of them get stuck from Friday afternoon to Monday afternoon
(CEST), so it really hampers my work. Would it be possible for a volunteer to agree to do it
on the weekend.
Best regards,
Robert-André
1 year, 5 months
Re: Planning to start unifying native and mingw packages
by Sandro Mani
On 03.09.22 18:09, Richard Shaw wrote:
> On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani <manisandro(a)gmail.com>
> wrote:
>
>
> On 03.09.22 17:10, Richard Shaw wrote:
> > I'm trying to migrate fltk right now and running into an issue:
> >
> > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> >
> > RPM build warnings:
> >
> > RPM build errors:
> > error: Could not open %files file
> > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
> such file
> > or directory
> >
> > Building the mingw packages seems to be interfering with the
> native build.
>
>
> I put %{?mingw_package_header} in the %{with mingw} (disabled)
> conditional this time and the build completed, so something in there
> is causing the issue.
You actually don't need %{?mingw_package_header} anymore at all (it
actually should just be a no-op with a current mingw-filesystem).
Sandro
1 year, 5 months
F37 Final blocker status update
by Ben Cotton
Fedora Linux 37 Final freeze begins Tuesday 4 October.
Action summary
====================
Accepted blockers
-----------------
1. anaconda — Custom partitioning with 2 drives selected, bootloader
fails to install due to one drive not having a BIOS Boot partition —
ON_QA
ACTION: QA to verify FEDORA-2022-c20d42f3bc
2. gnome-contacts — When a single contact is edited, it results in
multiple contacts of the same name. — ON_QA
ACTION: QA to verify FEDORA-2022-acbfee2ce8
3. gnome-initial-setup — Unable to set up enterprise account with
gnome-initial-setup, clicking continue does not join the domain —
ASSIGNED
ACTION: dgilmore to test
https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333
4. gnome-shell — GNOME Initial Setup uses the English keyboard,
instead of the default keyboard — ASSIGNED
ACTION: Upstream to diagnose and resolve issue
5. gnome-shell — Attempting to disconnect VPN connection from system
menu does nothing — VERIFIED
ACTION: (none)
6. gnome-software — Can't install a local rpm package anymore, Install
button missing (for certain RPMs) — VERIFIED
ACTION: (none)
7. greenboot — greenboot-grub2-set-counter.service fails on 38 IoT
with "cannot open `/boot/grub2/grubenv.new`: No such file or
directory." — NEW
ACTION: Maintainers to diagnose issue
8. grub2 — Windows with bitlocker enabled can't be booted, needs to
use bootnext instead of chainloader — NEW
ACTION: Maintainers to diagnose issue or provide status update
9. mesa — totem: nouveau_pushbuf_data(): totem killed by SIGABRT — NEW
ACTION: Maintainers to update mesa with fixes for F37
10. uboot-tools — Regression booting Fedora on rockchip devices
installed on PCIe NVME drives — ON_QA
ACTION: QA to verify FEDORA-2022-c1d9e8daa9
Proposed blockers
-----------------
1. chrome-gnome-shell — Project name and source repository changed to
gnome-browser-connector — NEW
ACTION: Reviewer to approve new gnome-browser-connector package.
2. gnome-shell — screencast doesn't record the top layer — NEW
ACTION: QA to verify if behavior still exists
3. gnome-shell-extension-background-logo — Update
gnome-shell-extension-background-logo to 43.0 — NEW
ACTION: Maintainer to update package
4. systemd — Czech qwerty layout configured in anaconda, but qwertz
layout used in disk unlock and in VT console — NEW
ACTION: kbd maintainers to reconsider the -legacy subpackage split
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. anaconda — https://bugzilla.redhat.com/show_bug.cgi?id=2088113 — ON_QA
Custom partitioning with 2 drives selected, bootloader fails to
install due to one drive not having a BIOS Boot partition
When using custom partitioning on two drives with /boot on a RAID 1
device, the installer only creates one BIOS boot. grub2-install is run
against both drives, but the second fails because it has no BIOS boot
partition. FEDORA-2022-c20d42f3bc contains a candidate fix.
2. gnome-contacts — https://bugzilla.redhat.com/show_bug.cgi?id=2111003 — ON_QA
When a single contact is edited, it results in multiple contacts of
the same name.
Editing a contact results in the contact being properly updated, but
an empty contact is created with the same name. FEDORA-2022-acbfee2ce8
contains a candidate fix.
3. gnome-initial-setup —
https://bugzilla.redhat.com/show_bug.cgi?id=2123494 — ASSIGNED
Unable to set up enterprise account with gnome-initial-setup, clicking
continue does not join the domain
Initially the buttons were missing. Update FEDORA-2022-50e585b456
fixed that issue, however clicking the button does not joing the
domain. Instead, the user is returned to the domain credentials
screen, resulting in an endless loop.
https://koji.fedoraproject.org/koji/taskinfo?taskID=92037333 contains
a backport of upstream's change which may fix it.
4. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2121110 — ASSIGNED
GNOME Initial Setup uses the English keyboard, instead of the default keyboard
Regardless of the default keyboard setting, g-i-s uses the English
keyboard. Relatedly, new users have the English keyboard selected,
even though another language is shown as the default.
FEDORA-2022-52cdfc7920 failed to fix this issue.
5. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125252 — VERIFIED
Attempting to disconnect VPN connection from system menu does nothing
Disabling a VPN doesn't disable the VPN. Fixed in FEDORA-2022-50e585b456.
6. gnome-software —
https://bugzilla.redhat.com/show_bug.cgi?id=2124869 — VERIFIED
Can't install a local rpm package anymore, Install button missing (for
certain RPMs)
What it says on the tin. Fixed in FEDORA-2022-b6246d02fa.
7. greenboot — https://bugzilla.redhat.com/show_bug.cgi?id=2121944 — NEW
greenboot-grub2-set-counter.service fails on 38 IoT with "cannot open
`/boot/grub2/grubenv.new`: No such file or directory."
greenboot service fails on a file-not-found error. This also results
in rebase tests failing because of conflicts with the rebase triggered
by the greenboot failure.
8. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2049849 — NEW
Windows with bitlocker enabled can't be booted, needs to use bootnext
instead of chainloader
Dual-booting recent Windows 10 system with TPM 2.0 fails because
bitlocker can't be unsealed by the TPM. This was waived to F37 under
the "difficult to fix" exception. No additional updates have been
provided.
9. mesa — https://bugzilla.redhat.com/show_bug.cgi?id=2123274 — NEW
totem: nouveau_pushbuf_data(): totem killed by SIGABRT
totem plays ~1 second of video and then crashes. This appears to
happen with all video formats. This appears to be an issue in
multithreading support in the nouveau driver, which is fixed upstream.
The fix is large and may not be suitable for backporting, but would be
available in a mesa-22.3 update.
10. uboot-tools — https://bugzilla.redhat.com/show_bug.cgi?id=2124127 — ON_QA
Regression booting Fedora on rockchip devices installed on PCIe NVME drives
uboot-tools introducted a regression when used with 5.19.x kernels.
FEDORA-2022-c1d9e8daa9 contains a candidate fix.
Proposed blockers
-----------------
1. chrome-gnome-shell —
https://bugzilla.redhat.com/show_bug.cgi?id=2106868 — NEW
Project name and source repository changed to gnome-browser-connector
Upstream has split this into two packages. Package review pending for
renamed package:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2127314
2. gnome-shell — https://bugzilla.redhat.com/show_bug.cgi?id=2125439 — NEW
screencast doesn't record the top layer
Typing and popup windows don't show when recording a screencast. This
may be fixed in pipewire-gstreamer-0.3.57-1.
3. gnome-shell-extension-background-logo —
https://bugzilla.redhat.com/show_bug.cgi?id=2127192 — NEW
Update gnome-shell-extension-background-logo to 43.0
The Fedora logo is not displayed and the package is not compatible
with gnome-shell 43.
4. systemd — https://bugzilla.redhat.com/show_bug.cgi?id=2121106 — NEW
Czech qwerty layout configured in anaconda, but qwertz layout used in
disk unlock and in VT console
The wrong keymap is used when unlocking disks or virtual terminals. It
looks like this may have never worked. It looks like an issue with how
layouts are mapped between console and xkb. Adam is thinking about how
to approach this:
https://bugzilla.redhat.com/show_bug.cgi?id=2121106#c24
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 5 months
The performance impact of various debug options on Fedora Rawhide
debug kernels
by Richard W.M. Jones
The current Fedora Rawhide kernels are too slow to run libguestfs
tests when doing Koji builds. These run in a qemu VM, running the
Rawhide kernel, emulated using software virtualization (ie. TCG).
They now time out because these kernels are so slow. Until fairly
recently they were slow but working.
I wondered if particular debug options had a greater effect on
performance, so I compiled many kernels (v5.19-rc7 from upstream)
using the baseline "no debug" config, then adding each debug option
that we use in turn, and measuring the performance using [1], using
qemu software virtualization (TCG). The tests were run many times
with warmups discarded to get the mean and standard deviation, using
the hyperfine program[2].
The results are below, and not very conclusive, but some options do
have a very large performance impact.
NO_DEBUG is the kernel compiled with no debug options enabled (ie. the
baseline).
In the actual debug kernel I expect the slow downs to be multiplied
together. To test that I did an extra run with all debug options
enabled (ALL_DEBUG).
CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC
were present and enabled in the kernel when it was imported into git
in 2010.
CONFIG_DEBUG_WW_MUTEX_SLOWPATH was turned off in the past
(RHBZ#1114160). It seems to have been switched on again in 2020.
CONFIG_DEBUG_KMEMLEAK seems like it was enabled in 2012.
It's also possible that an existing debug option has got slower in the
upstream kernel, that is, it's not that we've recently changed
something in Fedora.
Rich.
[1] https://libguestfs.org/libguestfs-test-tool.1.html
[2] https://github.com/sharkdp/hyperfine
NO_DEBUG: 12.362 s ± 0.093 s
ALL_DEBUG: 30.134 s ± 0.402 s (+143%)
CONFIG_PROVE_LOCKING=y: 23.435 s ± 0.526 s (+ 88%)
CONFIG_LOCK_STAT=y: 17.707 s ± 0.254 s (+ 43%)
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y: 15.804 s ± 0.161 s (+ 27%)
CONFIG_DEBUG_KMEMLEAK=y: 15.794 s ± 0.261 s (+ 27%)
CONFIG_DEBUG_LOCK_ALLOC=y: 15.696 s ± 0.116 s (+ 27%)
CONFIG_PAGE_TABLE_CHECK_ENFORCED=y: 12.694 s ± 0.104 s (+ 2%)
CONFIG_FAILSLAB=y: 12.679 s ± 0.122 s
CONFIG_NOUVEAU_DEBUG_MMU=y: 12.657 s ± 0.156 s
CONFIG_FAULT_INJECTION_DEBUG_FS=y: 12.630 s ± 0.158 s
CONFIG_DMA_API_DEBUG=y: 12.624 s ± 0.148 s
CONFIG_PERF_USE_VMALLOC=y: 12.611 s ± 0.125 s
CONFIG_NOUVEAU_DEBUG_PUSH=y: 12.608 s ± 0.165 s
CONFIG_DEBUG_SPINLOCK=y: 12.600 s ± 0.132 s
CONFIG_PM_ADVANCED_DEBUG=y: 12.586 s ± 0.132 s
CONFIG_FAIL_IO_TIMEOUT=y: 12.580 s ± 0.131 s
CONFIG_FAIL_MMC_REQUEST=y: 12.571 s ± 0.103 s
CONFIG_INTEL_IOMMU_DEBUGFS=y: 12.569 s ± 0.111 s
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y: 12.564 s ± 0.111 s
CONFIG_SYNTH_EVENT_GEN_TEST=m: 12.552 s ± 0.082 s
CONFIG_LOCK_EVENT_COUNTS=y: 12.551 s ± 0.118 s
CONFIG_FAIL_MAKE_REQUEST=y: 12.550 s ± 0.098 s
CONFIG_TEST_MIN_HEAP=m: 12.545 s ± 0.071 s
CONFIG_DEBUG_RWSEMS=y: 12.543 s ± 0.117 s
CONFIG_FAULT_INJECTION=y: 12.541 s ± 0.153 s
CONFIG_LOCKDEP_BITS=16: 12.532 s ± 0.161 s
CONFIG_FAIL_PAGE_ALLOC=y: 12.532 s ± 0.136 s
CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12: 12.526 s ± 0.068 s
CONFIG_KDB_DEFAULT_ENABLE=0x0: 12.523 s ± 0.143 s
CONFIG_TEST_LIST_SORT=m: 12.522 s ± 0.062 s
CONFIG_SND_VERBOSE_PRINTK=y: 12.522 s ± 0.120 s
CONFIG_WQ_WATCHDOG=y: 12.518 s ± 0.141 s
CONFIG_RTW89_DEBUG=y: 12.517 s ± 0.099 s
CONFIG_KDB_KEYBOARD=y: 12.517 s ± 0.183 s
CONFIG_DETECT_HUNG_TASK=y: 12.517 s ± 0.123 s
CONFIG_TEST_LOCKUP=m: 12.514 s ± 0.080 s
CONFIG_IWLWIFI_DEVICE_TRACING=y: 12.514 s ± 0.139 s
CONFIG_QUOTA_DEBUG=y: 12.511 s ± 0.114 s
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120: 12.511 s ± 0.159 s
CONFIG_DEBUG_RT_MUTEXES=y: 12.511 s ± 0.116 s
CONFIG_EFI_PGT_DUMP=y: 12.507 s ± 0.130 s
CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14: 12.506 s ± 0.095 s
CONFIG_PAGE_TABLE_CHECK=y: 12.504 s ± 0.102 s
CONFIG_DEBUG_VM_PGFLAGS=y: 12.500 s ± 0.106 s
CONFIG_XFS_WARN=y: 12.497 s ± 0.168 s
CONFIG_SND_JACK_INJECTION_DEBUG=y: 12.495 s ± 0.098 s
CONFIG_FAIL_FUNCTION=y: 12.495 s ± 0.127 s
CONFIG_DMAR_DEBUG=y: 12.486 s ± 0.145 s
CONFIG_RTW88_DEBUG=y: 12.484 s ± 0.050 s
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=4096: 12.483 s ± 0.075 s
CONFIG_DEBUG_PERF_USE_VMALLOC=y: 12.481 s ± 0.107 s
CONFIG_KPROBE_EVENT_GEN_TEST=m: 12.478 s ± 0.148 s
CONFIG_LOCKDEP=y: 12.475 s ± 0.095 s
CONFIG_KDB_CONTINUE_CATASTROPHIC=0: 12.474 s ± 0.136 s
CONFIG_DEBUG_ATOMIC_SLEEP=y: 12.469 s ± 0.125 s
CONFIG_SND_PCM_XRUN_DEBUG=y: 12.467 s ± 0.073 s
CONFIG_DEBUG_VM_PGTABLE=y: 12.466 s ± 0.099 s
CONFIG_LOCKDEP_CHAINS_BITS=17: 12.460 s ± 0.148 s
CONFIG_DEBUG_SG=y: 12.456 s ± 0.177 s
CONFIG_MODULE_FORCE_UNLOAD=y: 12.453 s ± 0.150 s
CONFIG_DEBUG_MISC=y: 12.453 s ± 0.133 s
CONFIG_DMADEVICES_DEBUG=y: 12.450 s ± 0.135 s
CONFIG_DEBUG_NET=y: 12.450 s ± 0.088 s
CONFIG_PERCPU_STATS=y: 12.448 s ± 0.097 s
CONFIG_CEPH_LIB_PRETTYDEBUG=y: 12.447 s ± 0.086 s
CONFIG_DMAR_PERF=y: 12.445 s ± 0.146 s
CONFIG_DMABUF_DEBUG=y: 12.445 s ± 0.178 s
CONFIG_TRACE_IRQFLAGS_NMI=y: 12.444 s ± 0.196 s
CONFIG_CAN_DEBUG_DEVICES=y: 12.440 s ± 0.100 s
CONFIG_DMA_API_DEBUG_SG=y: 12.437 s ± 0.159 s
CONFIG_CRYPTO_DEV_CCP_DEBUGFS=y: 12.433 s ± 0.139 s
CONFIG_PTDUMP_DEBUGFS=y: 12.432 s ± 0.129 s
CONFIG_EXT4_DEBUG=y: 12.431 s ± 0.124 s
CONFIG_DEBUG_NOTIFIERS=y: 12.424 s ± 0.140 s
CONFIG_PROVE_RCU=y: 12.420 s ± 0.183 s
CONFIG_SND_CTL_VALIDATION=y: 12.417 s ± 0.152 s
CONFIG_IOMMU_DEBUGFS=y: 12.415 s ± 0.149 s
CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y: 12.414 s ± 0.135 s
CONFIG_DEBUG_STACK_USAGE=y: 12.412 s ± 0.170 s
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y: 12.410 s ± 0.119 s
CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION=y: 12.409 s ± 0.089 s
CONFIG_DEBUG_OBJECTS_WORK=y: 12.408 s ± 0.162 s
CONFIG_CARL9170_DEBUGFS=y: 12.408 s ± 0.054 s
CONFIG_SND_DEBUG=y: 12.406 s ± 0.103 s
CONFIG_RTW89_DEBUGMSG=y: 12.406 s ± 0.144 s
CONFIG_DEBUG_OBJECTS_PERCPU_COUNTER=y: 12.406 s ± 0.081 s
CONFIG_DEBUG_OBJECTS_TIMERS=y: 12.403 s ± 0.177 s
CONFIG_RTW88_DEBUGFS=y: 12.395 s ± 0.177 s
CONFIG_B43_DEBUG=y: 12.392 s ± 0.127 s
CONFIG_B43LEGACY_DEBUG=y: 12.390 s ± 0.135 s
CONFIG_ACPI_APEI_ERST_DEBUG=m: 12.389 s ± 0.124 s
CONFIG_DEBUG_OBJECTS_FREE=y: 12.387 s ± 0.136 s
CONFIG_RTW89_DEBUGFS=y: 12.381 s ± 0.143 s
CONFIG_LOCKDEP_STACK_TRACE_BITS=19: 12.372 s ± 0.136 s
CONFIG_RCU_REF_SCALE_TEST=m: 12.367 s ± 0.102 s
CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y: 12.363 s ± 0.180 s
CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT=1: 12.362 s ± 0.160 s
CONFIG_JBD2_DEBUG=y: 12.361 s ± 0.120 s
CONFIG_TRACE_IRQFLAGS=y: 12.359 s ± 0.121 s
CONFIG_ACPI_CUSTOM_METHOD=m: 12.353 s ± 0.115 s
CONFIG_PREEMPTIRQ_TRACEPOINTS=y: 12.349 s ± 0.099 s
CONFIG_DEBUG_CREDENTIALS=y: 12.346 s ± 0.103 s
CONFIG_DEBUG_OBJECTS=y: 12.344 s ± 0.120 s
CONFIG_ATH_DEBUG=y: 12.328 s ± 0.104 s
CONFIG_ACPI_DEBUGGER=y: 12.326 s ± 0.146 s
CONFIG_DRBD_FAULT_INJECTION=y: 12.314 s ± 0.130 s
CONFIG_BPF_KPROBE_OVERRIDE=y: 12.314 s ± 0.093 s
CONFIG_ACPI_DEBUGGER_USER=m: 12.312 s ± 0.142 s
CONFIG_KGDB_KDB=y: 12.309 s ± 0.131 s
CONFIG_DEBUG_MUTEXES=y: 12.287 s ± 0.109 s
CONFIG_DEBUG_PER_CPU_MAPS=y: 12.286 s ± 0.131 s
CONFIG_ACPI_EC_DEBUGFS=m: 12.285 s ± 0.117 s
CONFIG_ACPI_CONFIGFS=m: 12.280 s ± 0.110 s
CONFIG_ACPI_DEBUG=y: 12.277 s ± 0.101 s
CONFIG_BTRFS_ASSERT=y: 12.268 s ± 0.130 s
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
1 year, 6 months
Confused by packager dashboard: FTBFS (source)
by Richard Shaw
I've really been enjoying using the dashboard, it's pointed out things that
I quite frankly forgot about.
For python-pyside2 though it's showing FTBFS at the source level due to
qt5-qtwebengine not being built for ppc64le and s390x, but I have a
%ifnarch conditional removing it from the build requirements for those
arches.
After convincing myself that it must be being pulled in from another
package I tried playing around with installing qtwebengine by starting a
build of pyside2 in a mock chroot and shelling into it, but I was able to
rpm -e it without conflicts with other installed packages.
I then tried a scratch build which largely succeeded, all arches built but
s390x failed during %check.
https://koji.fedoraproject.org/koji/taskinfo?taskID=92294488
So what gives?
Thanks,
Richard
1 year, 6 months
Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)
by Fabio Valentini
Hello all,
I'm not quite sure how to approach this problem, but as it stands, the
packages for the Pantheon DE and associated "elementary" applications
will probably be mostly broken when Fedora 37 will be released.
Every major GNOME update comes with problems for Pantheon (especially
due to mutter API changes), but this time is *much* worse due to the
additional libsoup 2 -> 3 transition.
Upstream development of the Pantheon / elementary projects is now
focused on finally getting elementary OS 7 out the door (which was
already supposed to have happened, it will be based on ubuntu 22.04
LTS, after all). Support for things that are in the far-off future
(like libsoup3, webkit2gtk-4.1, etc.) are low priority for them,
especially given their diminished manpower.
(The list of currently broken or "in danger of being broken on Fedora
38+" applications and components is included below, including links to
upstream tickets.)
I am already at my limit with the time that I can invest into Fedora,
and GObject C is the bane of my existence - so I can't really help
with these porting efforts, and upstream development is (rightfully
so) focused on their own, more important problems right now.
I doubt that these problems will be fixed in time for the release of
Fedora 37. And because many of these problems result in outdated,
crashing, failing-to-install or failing-to-build packages, I don't
think this is a good outcome at all, least for my users. Rather than
leave the DE available, but in an utterly broken and useless state,
I'd rather remove it from Fedora 37 altogether.
This set of packages also has at least some sentimental value to me,
because they were my first contributions to Fedora - first in COPR,
then getting them through package review (my first review request was
for the granite GTK widget library for elementary applications, which
was reviewed by rathann and ngompa).
The Pantheon components and elementary apps are also probably the
packages with the biggest number of actual users (the combination of
"Pantheon on Fedora" is quite popular for something that's not
available as an official Spin), maybe except for Syncthing, among all
the packages that I maintain.
So, I don't see any "good" way to handle this right now. If somebody
can give me any advice for what to do in this situation, I would be
grateful (even if the advice is: "yes, retire the packages, rather
than leave them broken, they can be added back once they have been
fixed").
Thanks,
Fabio
------------------------------------------------------------------------
Some critical Pantheon DE components that are currently broken:
- gala (window manager): https://github.com/elementary/gala/issues/1447
broken due to mutter API changes between 43.alpha and 43.beta
fails to build + fails to install on Fedora 37+
- elementary-greeter (LightDM greeter):
https://github.com/elementary/greeter/issues/617
broken due to mutter API changes
fails to build + fails to install on Fedora 37+
- wingpanel (top panel, application launcher, indicators, etc.):
https://github.com/elementary/wingpanel/issues/462
broken due to broken gala, and also because of mutter API changes
fails to build + fails to install on Fedora 37+
Creating a compat package for older versions of mutter has previously
worked to work around the worst problems, but it comes with its own
can of worms (i.e. you need to backport upstream patches for
compatibility with the latest gnome-settings-daemon version, etc.),
and this is not something that I can commit to doing again.
Additionally, some applications are broken:
- elementary-calendar: https://github.com/elementary/calendar/issues/756
broken because it directly links libsoup2, but also
evolution-data-server, which has transitioned to libsoup3, and
geocode-glib-1.0, which is the libsoup-2 version
fails to build / install on Fedora 37+
- elementary-mail: https://github.com/elementary/mail/issues/793
broken because it uses webkit2gtk-4.0, but also evolution-data-server,
which has moved to libsoup3
fails to build / install on Fedora 37+
- elementary-tasks: https://github.com/elementary/tasks/issues/340
broken because it uses libsoup2, but also evolution-data-server, and
geocode-glib-1.0, which is the libsoup-2 versionfails to build /
install on Fedora 37+
fails to build / install on Fedora 37+
Other applications aren't broken *yet*, but they will need to be
ported to new library versions at some point (for Fedora 38, or Fedora
39 at the latest, according to current plans for the removal of
libsoup2):
- elementary-photos: https://github.com/elementary/photos/issues/718
needs to be ported to webkit2gtk-4.1 / rest-1 / libsoup-3
- elementary-capnet-assist:
https://github.com/elementary/capnet-assist/issues/84 and 85
needs to be ported to webkit2gtk-4.1 and gcr-4.0
- switchboard-plug-onlineaccounts:
https://github.com/elementary/switchboard-plug-onlineaccounts/issues/243
needs to be ported evolution-data-server 3.45+ / libsoup-3
1 year, 6 months
Self Introduction: Sébastien Le Roux
by Sébastien Le Roux
Dear all,
my name is Sébastien Le Roux, I just join the mailing list today.
I am a computational material scientist,
my work can be separated in two parts: studying the physico-chemical
properties
of materials using computational/theoretical methods, and developing
tools to help
scientists in this field of expertise.
I am the author of several open source programs, so far none being packaged
by Fedora, but I recently released a new software named 'Atomes' and I
would
like to propose Atomes for packaging, and then providing that it can be
packaged
maintain it.
Atomes is a Free (Open Source) cross-platform toolbox developed to analyze,
to visualize and to create/edit three-dimensional atomistic models.
Among the possibilities offered by Atomes:
* Analysis of 3D atomistic model: neutron and x-rays diffraction,
rings statistics, chain statistics, bond order, MSD ...
* Visualization: measures, coordination polyhedras, advanced coloring,
advanced design
* Edition: molecular library, crystal builder, cell edition, surface
creation and passivation ...
* Molecular Dynamics input preparation systems:
o Classical MD: DLPOLY
<https://www.scd.stfc.ac.uk/Pages/DL_POLY.aspx> and LAMMPS
<https://lammps.sandia.gov/>
o ab-initio MD: CPMD <http://www.cpmd.org> and CP2K
<http://cp2k.berlios.de>
o QM-MM MD: CPMD <http://www.cpmd.org> and CP2K
<http://cp2k.berlios.de>
More info about me here: https://www.ipcms.fr/sebastien-le-roux/
More information about Atomes here: https://atomes.ipcms.fr/
So hello world ;-)
Best regards.
Sébastien Le Roux
PS: using Fedora since FC2
--
===========================================================
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail:sebastien.leroux@ipcms.unistra.fr
Webpage:https://www.ipcms.fr/sebastien-le-roux/
ATOMES project:https://atomes.ipcms.fr/
RINGS project:http://rings-code.sourceforge.net/
ISAACS project:http://isaacs.sourceforge.net/
Fax: +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===========================================================
1 year, 6 months
