Hi all,
libwacom had a soname bump for the upcoming release. I've already rebuilt
- libinput
- cinnamon, cinnamon-control-center and cinnamon-settings-daemon
- mutter, gnome-control-center, gnome-settings-daemon
- kcm_wacomtablet (FTBFS though, #2031611)
That should be it, if you have a package n
On Thursday, December 9, 2021 6:59:17 PM CET Ben Beasley wrote:
> I haven’t looked at pgAdmin4, but I’m the current maintainer of
> nodejs-svgo and several other Fedora packages that use the new NodeJS
> packaging guidelines. I’m not the original packager for nodejs-svgo, and
> I wasn’t the firs
On 12/12/21 15:18, Emmanuel Seyman wrote:
* Volker Fröhlich [12/12/2021 23:03] :
All of my packages are up for grabs.
For the curious, volter maintains the following packages:
* cptutils
* dans-gdal-scripts
* e00compr
* esniper
* freexl
* gdal
* grass
* libgeotiff
* librast
On 12/12/21 15:03, Volker Fröhlich wrote:
I don't want to be a package maintainer anymore.
All of my packages are up for grabs.
Volker (FAS volter)
Volker -
Sorry to see you go. Thank you for all your work over the years!
Orion
--
Orion Poplawski
he/him/his - surely the least important
No missing expected images.
Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 10/228 (x86_64), 18/159 (aarch64)
New failures (same test not failed in Fedora-Rawhide-20
No missing expected images.
Failed openQA tests: 1/15 (aarch64)
Old failures (same test failed in Fedora-IoT-35-20211211.0):
ID: 1085359 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1085359
Soft failed openQA tests: 1/16 (x86_64)
(Tests comple
On Sun, 12 Dec 2021, Steven A. Falco wrote:
I also noticed that python3-wxpython4 appears to require the 3.0 branch, so
that might be what is causing both 3.0 and 3.1 of wxGTK to be dragged in:
$ rpm -q --requires python3-wxpython4
...
libwx_baseu-3.0.so.0()(64bit)
...
Is there a version of p
* Volker Fröhlich [12/12/2021 23:03] :
>
> All of my packages are up for grabs.
For the curious, volter maintains the following packages:
* cptutils
* dans-gdal-scripts
* e00compr
* esniper
* freexl
* gdal
* grass
* libgeotiff
* librasterlite2
* libspatialite
* mingw-polyclipping
* po
I don't want to be a package maintainer anymore.
All of my packages are up for grabs.
Volker (FAS volter)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct
The KiCad package is currently built using wxGTK3-devel (and
python3-wxpython4). The upstream KiCad developers have an interest in
switching to the 3.1 branch of wxGTK, available in the wxGTK-devel package.
I'm running a trial build of KiCad, substituting wxGTK-devel in place of
wxGTK3-devel
OLD: Fedora-Rawhide-20211211.n.0
NEW: Fedora-Rawhide-20211212.n.0
= SUMMARY =
Added images:0
Dropped images: 5
Added packages: 0
Dropped packages:0
Upgraded packages: 67
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
Dear all,
I noticed that Fennel was listed as orphaned on this list. As a great
fan of Lisp and Fennel in particular, I'd be delighted to take on
maintainership of Fennel as my first package. If it still needs a
maintainer, please let know how to adopt the package!
Best wishes and many thanks,
S
# Fedora Quality Assurance Meeting
# Date: 2021-12-13
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat
Greetings testers!
We're coming up on end of year when many folks will be busy over the
holidays, so let's have a final m
On Do, 09.12.21 23:55, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > On Do, 02.12.21 14:36, Ben Cotton (bcotton(a)redhat.com) wrote:
> >
> > Hmm, so what I am really missing on the feature page: what's the
> > attack scenario here? Usually security features come with an attack
* Zbigniew Jędrzejewski-Szmek:
> Some more questions about how the verification happens… IIUC, I need to
> load some keys to the kernel keyring, and then set
> fs.verity.require_signatures.
>
> Where do the keys come from? How are the keys themselves verified?
> At what time are they loaded and b
Fabio Valentini wrote on Sun, Dec 12, 2021 at 12:25:11PM +0100:
> > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> > 56M is okeyish, but 347M seems a lot. I think firefox is going
> > through pipewire-pulse, so that interface might
On Sun, Dec 12, 2021 at 12:25:11PM +0100, Fabio Valentini wrote:
> On Sat, Dec 11, 2021 at 6:46 PM Zbigniew Jędrzejewski-Szmek
> wrote:
> >
> > Hi,
> >
> > on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> > but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> > 56M is okeyish, but 347M s
On Fri, Dec 10, 2021 at 10:47:52AM +0100, Vít Ondruch wrote:
>
> Dne 10. 12. 21 v 0:08 Davide Cavalca via devel napsal(a):
> >On Fri, 2021-12-03 at 22:08 +, Richard W.M. Jones wrote:
> >>I'm unclear about the threat model - this is an attacker who is
> >>someone able to overwrite single files
Some more questions about how the verification happens… IIUC, I need to
load some keys to the kernel keyring, and then set fs.verity.require_signatures.
Where do the keys come from? How are the keys themselves verified?
At what time are they loaded and by whom?
(Let's say that I'm an attacker wit
On Sat, Dec 11, 2021 at 6:46 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> Hi,
>
> on my laptop, /usr/bin/pipewire uses 56M RSS, 5M SHR,
> but/usr/bin/pipewire-pulse uses 347M RSS, 4M SHR.
> 56M is okeyish, but 347M seems a lot. I think firefox is going
> through pipewire-pulse, so that interface
> * at run time, if the fsverity rpm plugin is enabled, rpm will install
> the fsverity signature key and enable fsverity on files that are
> installed.
This requires CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y. Currently our
kernels are built without that. It seems like a simple addition (the
amount of
On 12/12/2021 03:49, Neal Gompa wrote:
So I strongly suspect they'll become the
new standard anyway.
TPM is a typical black box. I can't trust it because all hardware TPM
implementations are proprietary. No one guarantees that it has no backdoors.
--
Sincerely,
Vitaly Zaitsev (vit...@easyc
On Fri, Dec 03, 2021 at 05:31:21PM -, Boris Burkov via devel wrote:
> The top-level hash is calculated for each file, then that hash is signed with
> the inputted rsa key pair and the signed hash is appended to the array of
> signed hashes in the rpm metadata. I am guessing the way we worded
No missing expected images.
Failed openQA tests: 1/8 (aarch64)
New failures (same test not failed in Fedora-Cloud-34-20211211.0):
ID: 1084836 Test: aarch64 Cloud_Base-qcow2-qcow2
base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/1084836
Soft failed openQA tests: 1/
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20211211.0):
ID: 1084812 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
25 matches
Mail list logo
