The license field changed:
-License: LGPLv2+ with exceptions
+License: LGPLv2 with exceptions
but this wasn't because of a change upstream, just we got the wrong
license originally. Jerry James has been writing a tool to synch
Fedora spec files with the opam (OCaml source distributio
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
ID: 748913 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/748913
ID: 748920 Test: aarch64 Cloud_Ba
On Wed, Dec 30, 2020 at 05:08:03PM -0700, Chris Murphy wrote:
> > Upgrades of customized configurations that deviate significantly from
> > defaults aren't supported. It's best effort. We can't be blocking on
> > people's customizations.
> >
> > I think we can come pretty close to atomically renami
On 30.12.2020 23:01, Jerry James wrote:
RPM can query ELF objects (executables and shared libraries) to find
DT_NEEDED fields. That gives it a list of libraries that are depended
on directly.
Except for Qt5Svg, because it is a Qt runtime plugin.
--
Sincerely,
Vitaly Zaitsev (vit...@easycodi
On 30.12.2020 22:49, Germano Massullo wrote:
My question is: how can keepassxc trigger the installation of such
libraries if the spec file does not contain any Requires dependency that
should be the attribute to identify runtime dependencies that are needed
by the package?
Yes, it must. Qt5Sv
On 30.12.2020 20:53, Ben Cotton wrote:
This change makes the GRUB configuration files layout to be consistent
across all the supported architectures. Currently EFI is a special
case since the GRUB configuration file and environment variables block
are stored in the EFI System Partition (ESP) inst
On 30.12.2020 20:53, Ben Cotton wrote:
The proposal is to always store the `grub.cfg` and `grubenv` files in
the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg`
to only be a small configuration file that sets a different `$prefix`
variable and loads the configuration file stored
Vitaly Zaitsev via devel
于2020年12月31日周四 下午6:12写道：
>
> On 30.12.2020 20:53, Ben Cotton wrote:
> > This change makes the GRUB configuration files layout to be consistent
> > across all the supported architectures. Currently EFI is a special
> > case since the GRUB configuration file and environment
On 31.12.2020 11:28, Qiyu Yan wrote:
iirc systemd-boot don't support legacy BIOS system.
Yes of course. Systemd-boot is not a bootloader. It is an EFIStub kernel
manager with a simple menu.
I've been using systemd-boot for over 1.5 years and it works great.
It can only be enabled for Fedora
On Thu, Dec 31, 2020 at 10:10 AM Vitaly Zaitsev via devel
wrote:
>
> On 30.12.2020 20:53, Ben Cotton wrote:
> > This change makes the GRUB configuration files layout to be consistent
> > across all the supported architectures. Currently EFI is a special
> > case since the GRUB configuration file a
On 31.12.2020 11:50, Peter Robinson wrote:
Because it doesn't support traditional BIOS boot, or the boot systems
of POWER, Z-series and numerous other corner cases. Just look at the
thread about BIOS support from a few months ago to see how
controversial even considering that was. If we then move
On Thu, Dec 31, 2020 at 11:29 AM Vitaly Zaitsev via devel
wrote:
>
> On 31.12.2020 11:50, Peter Robinson wrote:
> > Because it doesn't support traditional BIOS boot, or the boot systems
> > of POWER, Z-series and numerous other corner cases. Just look at the
> > thread about BIOS support from a fe
On 31.12.2020 12:37, Peter Robinson wrote:
Of course it could, who do you propose to do that work and support all
the various options and code required?
It can be easily installed during Fedora installation by executing the
following:
1. Make sure the ESP partition has more than 512 MB of free
Hello Chris,
Thanks a lot for the comments.
On Thu, Dec 31, 2020 at 1:02 AM Chris Murphy wrote:
[snip]
>
> That problem was the result of quite old core.img in the MBR gap (or
> BIOS Boot partition). As that change simultaneously depended on
> shipping a new GRUB module without a way to update
On Wed, Dec 30, 2020 at 02:53:13PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Deprecate_xemacs
>
> I have been part of XEmacs upstream for over 20 years, and have
> maintained the Fedora package for over 11 years. Upstream development
Kudos!
> == Summary ==
> Deprecate the
On Wed, Dec 30, 2020 at 11:42 PM Michel Alexandre Salim
wrote:
>
> Howdy,
> One observation (also in the post):
>
> The CLIs for fedpkg and koji is currently meant for human, not machine,
> consumptions. Invoking them from Bash scripts and trying to use the
> output (e.g. getting the name of that
Hello Tomasz,
On Thu, Dec 31, 2020 at 10:55 AM Tomasz Torcz wrote:
[snip]
> > I think either never fixing this, or never updating systems to the
> > "new way" are both untenable. We saw with the BLS switch many users
> > depend on doing in place upgrades. Many were pushing 4 or more years.
>
>
On Thu, Dec 31, 2020 at 12:54 PM Vitaly Zaitsev via devel
wrote:
>
> On 31.12.2020 12:37, Peter Robinson wrote:
> > Of course it could, who do you propose to do that work and support all
> > the various options and code required?
> It can be easily installed during Fedora installation by executing
OLD: Fedora-Rawhide-20201230.n.0
NEW: Fedora-Rawhide-20201231.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 7
Dropped packages:4
Upgraded packages: 84
Downgraded packages: 0
Size of added packages: 876.62 KiB
Size of dropped packages
I maintain a suite of ham radio related packages. The developer is very
active and often creates test versions adding and incrementing the "tweak"
part of the version which is removed for the full releases and the patch
level incremented.
Currently I'm just trying to keep up with them by hand usin
Hi,
On Thu, Dec 31, 2020 at 07:58:53AM -0600, Richard Shaw wrote:
> 4. Build the packages in COPR.
>
> Easy enough using a bash script but is there a better way?
packit allows to create test builds in COPR based on GitHub PRs and
probably also releases. Maybe this can make it easier for you, to
Announcing the creation of a new nightly release validation test event
for Fedora-IoT 34 RC 20201231.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_pl
Hi,
when trying to install pipewire-jack-audio-connection-kit i get this error
message:
# dnf -y install pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem: problem with installed package
jack-audio-connection-kit-1.9.14-
On Thu, Dec 31, 2020 at 9:54 AM Martin Gansser
wrote:
>
> Hi,
>
> when trying to install pipewire-jack-audio-connection-kit i get this error
> message:
>
> # dnf -y install pipewire-jack-audio-connection-kit
> Last metadata expiration check: 1:39:52 ago on Thu Dec 31 14:10:39 2020.
> Error:
> Pr
this means that jack-audio-connection-kit has been replaced by
pipewire-jack-audio-connection-kit ?
but then i get this message:
# dnf swap jack-audio-connection-kit pipewire-jack-audio-connection-kit
Last metadata expiration check: 1:57:23 ago on Thu Dec 31 14:10:39 2020.
Error:
Problem 1: p
On 31/12/2020 16:10, Martin Gansser wrote:
this means that jack-audio-connection-kit has been replaced by
pipewire-jack-audio-connection-kit ?
- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 conflicts
with jack-audio-connection-kit provided by
jack-audio-connection-kit-1
Missing expected images:
Xfce raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 9/180 (x86_64), 9/122 (aarch64)
New failures (same test not failed in Fe
Missing expected images:
Iot dvd x86_64
Iot dvd aarch64
Failed openQA tests: 1/16 (x86_64), 5/15 (aarch64)
ID: 749232 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/749232
ID: 749241 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL:
There will be an outage starting at 2021-01-05 07:00 UTC
which will last approximately 3 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2021-01-05 07:00UTC'
Reason for outage:
Upgrade to a more recent/patched taiga
I rebuilt chromium, but it did not resolve the issue.
~spot
On Wed, Dec 30, 2020 at 5:35 PM Marius Schwarz
wrote:
> Am 30.12.20 um 14:07 schrieb Mattia Verga via devel:
> > Il 30/12/20 10:14, Marius Schwarz ha scritto:
> >> Don't you need to recompile stuff first to have an effect? :)
> >>
> >
On Wed, Dec 30, 2020 at 08:26:42PM -0500, Scott Talbert wrote:
>
> I think fundamentally the version of PyQt5-sip probably needs to match (or
> be very close to) the version of sip that PyQt5 itself was compiled with.
I think for calibre (which is currently failing with):
...
/usr/bin/python3 -
On Thu, Dec 31, 2020 at 5:37 AM Zbigniew Jędrzejewski-Szmek
wrote:
> Is it really worth it to go through a separate deprecation step?
> xemacs users can switch to emacs after xemacs is removed. I see that
> you are concerned about the plugins, but maybe it's just better to
> drop xemacs and the pl
On 2020-12-30 1:48 p.m., Michel Alexandre Salim wrote:
On Wed, 2020-12-30 at 16:28 -0500, Elliott Sales de Andrade wrote:
On Wed, 30 Dec 2020 at 14:53, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
== How to test ==
Existing systems can be converted to
On Wed, Dec 30, 2020 at 12:53 PM Ben Cotton wrote:
>
> ** Update anaconda to perform the installation using mount -o
> compress=zstd:1
> ** Set the proper option in fstab (alternatively: set the XATTR)
I think the most discoverable is using 'compress=zstd:1" as the mount
option, and any one who w
On Wed, 2020-12-30 at 20:40 -0500, Scott Talbert wrote:
> On Wed, 30 Dec 2020, Scott Talbert wrote:
>
> > > Neal and I are looking at getting ButterManager packaged, and it
> > > depends on sip and PyQt5-sip:
> > >
> > >
> > > https://github.com/egara/buttermanager/blob/master/requirements.txt
On Thu, 31 Dec 2020, Kevin Fenzi wrote:
I think fundamentally the version of PyQt5-sip probably needs to match (or
be very close to) the version of sip that PyQt5 itself was compiled with.
I think for calibre (which is currently failing with):
...
/usr/bin/python3 -c import os;
os.chdir('/bu
As in subject; this will be in Rawhide only due to other breaking changes.
--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedor
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-33-20201231.0):
ID: 749262 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
38 matches
Mail list logo
