Hi guys,
unfortunately i do not have time to maintain opendmarc [0] and thus i am
orphaning it.
Feel free to take the package.
Best regards,
Tomas
[0] - https://src.fedoraproject.org/rpms/opendmarc
___
devel mailing list -- devel@lists.fedoraproject.org
On Mon, Feb 22, 2021 at 12:32:11AM +0100, Henrik Nordström wrote:
> I recently took ownership of Radare2 after it was orphaned,
> unfortunately unknowing of the current turmult in the Radare2 project.
>
> Now realizing that it has a dependent Fedora package Cutter (cutter-re)
> which is at the edg
On Sun, Feb 21, 2021 at 10:18 PM Chris Murphy
wrote:
> On Sun, Feb 21, 2021 at 12:24 PM Tom Seewald wrote:
> >
> > If Gnome is still hanging for 2 minutes on reboot [1] then I think we
> may want to consider that a blocking bug for F34. I can at least confirm
> that this bug is still affecting R
On Sa, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 34 better? Please spend 1 minute of your time and
> try to run:
>
># Run this only if you use default Fedora modules
># next time you run any DNF command default modules will be enabled again
>sudo dn
On Mon, Feb 22, 2021 at 09:10:27AM +, Sven Kieske wrote:
> On Sa, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote:
> > Do you want to make Fedora 34 better? Please spend 1 minute of your time
> > and try to run:
> >
> ># Run this only if you use default Fedora modules
> ># next time y
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-32-20210221.0):
ID: 785443 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On Sat, Feb 20, 2021 10:49:12 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 34 better? Please spend 1 minute of your time and
> try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dn
Hi,
I would like to question the decision that was made by systemd
maintainers to remove the fallback DNS server list:
https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d
And then backported to F33:
https://src.fedoraproject.org/rpms/systemd/c/ed795fb1fc9a2c20ebc
On Mon, Feb 22, 2021 at 09:37:26AM +, Ankur Sinha wrote:
> Problem 2: problem with installed package perf-5.10.11-200.fc33.x86_64
> - package perf-5.11.0-0.rc7.git0.1.fc34.x86_64 requires
> libopencsd_c_api.so.0()(64bit), but none of the providers can be installed
> - perf-5.10.11-200.fc3
On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote:
> Hi,
>
> I would like to question the decision that was made by systemd
> maintainers to remove the fallback DNS server list:
> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d
>
> And then backport
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If
On Sun, 21 Feb 2021 at 18:56, Micah Shennum wrote:
>
> Not sure if it's something weird with my system, but running that exact
> command I get
>
> Error: Unknown repo: 'updates-testing-modular'
>
> Dropping the reference to updates-testing-modular gets me a couple of removed
> packages (obviousl
On Mo, 2021-02-22 at 10:20 +0100, Adrian Reber wrote:
> You probably have an outdated repository definition in /etc/yum.repos.d.
>
> Your /etc/yum.repos.d/fedora-cisco-openh264.repo should have following
> line:
>
> metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$r
OLD: Fedora-Rawhide-20210221.n.0
NEW: Fedora-Rawhide-20210222.n.0
= SUMMARY =
Added images:1
Dropped images: 0
Added packages: 1
Dropped packages:0
Upgraded packages: 63
Downgraded packages: 0
Size of added packages: 60.31 KiB
Size of dropped packages:0 B
Hi Tadej,
I think more effort should be put to configure the instance correctly by
provider. No default should save invalid configuration of container host.
I think there is actually little benefit in systemd-resolved usage in a
container. I would guess the container host would run proper dns cac
Dnia Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež napisał(a):
> Hi,
>
> I would like to question the decision that was made by systemd
> maintainers to remove the fallback DNS server list:
> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d
>
> And then b
On 2/22/21 11:17 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote:
>> Hi,
>>
>> I would like to question the decision that was made by systemd
>> maintainers to remove the fallback DNS server list:
>> https://src.fedoraproject.org/rpms/systemd/c
adf-accanthis-fonts: Taken by mjg :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Gu
Missing expected images:
Minimal raw-xz armhfp
Xfce raw-xz armhfp
Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 21/183 (x86_64), 11/124 (aarch64)
New failures (sa
t this?
I've added a OrderWithRequires statement to tell RPM how to sort this:
https://src.fedoraproject.org/rpms/xorg-x11-font-utils/c/3f6e76ab132da44d2196c035492b34c37df4e4e8
That should help resolve this issue.
Unfortunately, this did not work.
e.g. Fedora-Astronomy_KDE-Live-34-2021022
OLD: Fedora-34-20210221.n.0
NEW: Fedora-34-20210222.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 46
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of
Missing expected images:
Iot dvd x86_64
Iot dvd aarch64
Failed openQA tests: 3/16 (x86_64), 4/15 (aarch64)
New failures (same test not failed in Fedora-IoT-35-20210217.0):
ID: 786236 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/786236
ID: 78
Hi,
On 2/22/21 11:17 AM, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/w
Hi all,
I am about to build new ldc 1.25.0 that comes with a soname bump for
both f34 and rawhide.
I'll handle rebuilds of dependencies -- I did a test run in copr and
everything looked fine, with the exception of two packages,
appstream-generator and glibd that were already FTBFS prior to t
On ma, 22 helmi 2021, Miro Hrončok wrote:
tomcat-taglibs-parent orphan 5 weeks ago
I've taken tomcat-taglibs-{parent,standard} as they are required for
tomcat which is needed for Dogtag which is needed for FreeIPA.
I rebuilt tomcat-taglibs-parent in Rawhid
On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
>>
>> Thanks you for your rapid reply!
>>
>> On 2/21/21 4:57 PM, Michael Young wrote:
>>> On Sun, 21 Feb 2021, Steve Dickson wrote:
>>>
I apologies if I missed something... If ther
On 2/22/21 9:28 AM, Steve Dickson wrote:
>
>
> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
>> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
>>>
>>> Thanks you for your rapid reply!
>>>
>>> On 2/21/21 4:57 PM, Michael Young wrote:
On Sun, 21 Feb 2021, Steve Dickson wrote
No missing expected images.
Failed openQA tests: 22/183 (x86_64), 19/124 (aarch64)
New failures (same test not failed in Fedora-34-20210221.n.0):
ID: 785960 Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/785960
ID: 785963 Test
On 2/22/21 9:31 AM, Steve Dickson wrote:
>
>
> On 2/22/21 9:28 AM, Steve Dickson wrote:
>>
>>
>> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
>>> On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
Thanks you for your rapid reply!
On 2/21/21 4:57 PM, Michael You
On Mon, Feb 22, 2021 at 09:28:53AM -0500, Steve Dickson wrote:
>
>
> On 2/22/21 2:39 AM, Pierre-Yves Chibon wrote:
> > On Sun, Feb 21, 2021 at 05:21:33PM -0500, Steve Dickson wrote:
> >>
> >> Thanks you for your rapid reply!
> >>
> >> On 2/21/21 4:57 PM, Michael Young wrote:
> >>> On Sun, 21 Feb
Hi,
I have submitted new package openresolv [1], which provides resolvconf
tool, similar to Debian's resolvconf package.
Why? I thought about common interface to various DNS cache
implementations for workstations and different VPN providers available.
While I think the best place to direct, which
On Mo, 22.02.21 16:29, Petr Menšík (pemen...@redhat.com) wrote:
It might be OK for systemd's resolvectl to pass the call on to some
other executable if it notices resolved is not there. We do the same
in the "telinit" tool, so that Debian can have multiple init systems,
and when ours owns the "tel
On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz
wrote:
3) Configure DNS resolvers if you want to use DNS.
Or dig deeper: why cloud-init disabled DNS on your installation?
I'm pretty sure cloud-init just doesn't know how to configure
systemd-resolved at all. So I suspect this is a cloud-init bu
Error:
Problem 1: package openmw-0.46.0-2.fc33.x86_64 requires
libboost_filesystem.so.1.73.0()(64bit), but none of the providers can be
installed
- boost-filesystem-1.73.0-9.fc33.x86_64 does not belong to a
distupgrade repository
- problem with installed package openmw-0.46.0-2.fc33.x86_6
I do not think this is a cloud-init problem. None of my hosts are in any cloud
and most failed to resolve after upgrade to F33. Only after reverting to nss
resolver by disabling systemd-resolved did the problem disappear.
I did investigate the new resolver but none of the options worked no ma
Hi,
I was the previous maintainer of radare2 and, among other things, an
upstream developer of the same project. I, and others ex radare2
developers, have forked radare2 with Rizin some time ago. That said, I
failed to follow the radare2 6-weeks schedule even before the forking
decision/mess, so I
No missing expected images.
Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64)
Old failures (same test failed in Fedora-IoT-34-20210220.0):
ID: 786325 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/786325
ID: 786330 Test: aarch64 IoT-dvd
Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
in case I don't want it? Then I don't have to make a proxy, but install
indeed a different package providing resolvconf. I think I would submit
that PR on Fedora package instead. Or don't have any
/usr/sbin/resolvconf, in whic
On Mon, Feb 22, 2021 at 10:57 am, David Both
wrote:
do not think this is a cloud-init problem. None of my hosts are in
any cloud
and most failed to resolve after upgrade to F33. Only after reverting
to nss
resolver by disabling systemd-resolved did the problem disappear.
Hi David, your issu
On Mon, Feb 22, 2021 at 5:15 pm, Petr Menšík
wrote:
Wouldn't it be much simpler, if I could just dnf remove
systemd-resolved
in case I don't want it?
Is there some reason systemd-resolved cannot be a subpackage? Seems
like that would be the easiest solution?
If that's problematic for some
> sudo dnf module reset '*'
>
> sudo dnf --releasever=34 --setopt=module_platform_id=platform:f34 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
F32 x86_64 server:
Error:
Problem 1: package python3-blindspin-2.0.1-9.fc32.noarch requires python
Dnia Mon, Feb 22, 2021 at 09:45:58AM -0600, Michael Catanzaro napisał(a):
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just doesn't
On Fri, 2021-02-12 at 14:19 -0600, Justin Forbes wrote:
> > Some things, like the AMD Radeon GPU drivers, firmware or related
> > code, appear to be completely non-functional on the 64k page size.
> > Insufficient upstream developers are testing such issues on this
> > architecture.
>
> Just as th
On Sat, Feb 20, 2021 at 10:26 AM Jerry James wrote:
> Okay, I will try to get all of these builds done prior to beta freeze.
The builds are all done now, and ocaml-ppx-tools-versioned has been
retired in F34+. As far as I can tell, all OCaml-using packages
except ocaml-dose3 and ocaml-oasis are
On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
wrote:
But "dns = none" seems wrong.
Well it would be the right choice if cloud-init were to manually
configure a static list of DNS servers in /etc/systemd/resolved.conf
(or, previously, /etc/resolv.conf), which is probably what you want for
a
On Mon, Feb 22, 2021 at 09:59:55AM -0700, Jerry James wrote:
> On Sat, Feb 20, 2021 at 10:26 AM Jerry James wrote:
> > Okay, I will try to get all of these builds done prior to beta freeze.
>
> The builds are all done now, and ocaml-ppx-tools-versioned has been
> retired in F34+. As far as I can
After a quick glance at cloud-init code, it seems to me it does not
check /etc/resolv.conf for symlinks.
It just reads /etc/resolv.conf if it is a file, then writes its own
nameservers into target. I have seen no rm of original /etc/resolv.conf,
so I guess it rewritten target of symlink on Fedora
Hi,
I would like to ask about the developers' stance towards supporting PulseAudio
plugins when using `pipewire-pulseaudio`. On some other mainstream
distributions this can easily be achieved as the modules are packaged with the
PA pipewire replacement package, however, in Fedora they are curre
On Sun, Feb 21, 2021 at 03:17:05PM -0700, Jerry James wrote:
> People occasionally drop by bugzilla, but don't know what component to
> file a bug against. For some reason, they tend to pick the very first
> component on the list, "0ad", which is a game. That doesn't help
They also often pick 'd
I just filed
https://bugzilla.redhat.com/show_bug.cgi?id=1931587
on this. Follow along/add whatever you like to it. :)
kevin
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
On Mon, Feb 22, 2021 at 11:04 AM Kevin Fenzi wrote:
> I just filed
> https://bugzilla.redhat.com/show_bug.cgi?id=1931587
> on this. Follow along/add whatever you like to it. :)
Thank you, Kevin!
--
Jerry James
http://www.jamezone.org/
___
devel mailing
On Sun, Feb 21, 2021 at 05:24:06PM +, Mattia Verga via devel wrote:
> Hello folks,
>
> during the last winter holidays I've started to write a new flask app to
> automatize the new package submission process. The goals of this app
> would be:
Awesome. Thanks for working on it!
> - Get rid of
Hi all.
'sundials-5.7.0' is coming in Rawhide branch.
Is reasonable pushing it in f34 too?
Release notes: https://computing.llnl.gov/projects/sundials/release-history
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys
On 22/02/2021 17:55, David Woodhouse wrote:
> On Fri, 2021-02-12 at 14:19 -0600, Justin Forbes wrote:
>>> Some things, like the AMD Radeon GPU drivers, firmware or related
>>> code, appear to be completely non-functional on the 64k page size.
>>> Insufficient upstream developers are testing such
So here is my plan.
Over the next few days I plan to use one or more VMs to test various
configurations using systemd-resolved to see which ones work and which do not.
Then we should be
able to track down why.
Do you have any suggestions?
Thanks.
--
On Mon, Feb 22, 2021 at 09:39:55AM -0500, Steve Dickson wrote:
> > Well it appears this is still the problem
> >
> > origin/rawhide/user/steved/pnfs-rawhide
> > origin/rawhide_old/user/steved/pnfs-rawhide
> Never mind... I just had to recreate the git tree... thanks again!
https://xkcd.com/1597/
Daniel Pocock wrote on 2/22/21 10:41 AM:
> I feel that you underestimate the impact of the GPU driver issue
>
> If the GPU driver doesn't work, people can't even log in and get started
>
> If the GPU vendors don't test their code on ppc64le (and aarch64) then
> those platforms will always lag beh
On Mo, 22.02.21 17:15, Petr Menšík (pemen...@redhat.com) wrote:
> Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
> in case I don't want it? Then I don't have to make a proxy, but install
> indeed a different package providing resolvconf. I think I would submit
> that PR o
Hi,
as a bind-utils maintainer, I have to ask. Why is dig -t TYPE61 used,
when all stable Fedora supports dig -t OPENPGPKEY just fine. Type61
might be used as fallback for older releases
On 2/12/21 8:22 PM, Miroslav Suchý wrote:
> All Fedora's GPG key - starting with Fedora 27 - are now stored in
> I feel that you underestimate the impact of the GPU driver issue
>
> If the GPU driver doesn't work, people can't even log in and get started
I still do not understand why no one from the talos/ppc64le community is
following up on that amdgpu regression[1] that was introduced with the 5.9
ker
On 22/02/2021 21:18, Tom Seewald wrote:
>> I feel that you underestimate the impact of the GPU driver issue
>>
>> If the GPU driver doesn't work, people can't even log in and get started
>
> I still do not understand why no one from the talos/ppc64le community is
> following up on that amdgpu r
On Mon, Feb 22, 2021 at 1:45 pm, David Both
wrote:
Do you have any suggestions?
Run 'resolvectl' and post the output so we can see what your
configuration is. I hinted at this in my previous mail but it seems I
didn't explicitly ask you to post what it outputs. Please post it so we
can see
On Mon, 2021-02-22 at 09:45 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz
> wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just doesn't know how to
On Mon, 2021-02-22 at 11:14 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
> wrote:
> > But "dns = none" seems wrong.
>
> Well it would be the right choice if cloud-init were to manually
> configure a static list of DNS servers in /etc/systemd/resolved.conf
> (
On Fri, Feb 12, 2021 at 10:25 AM Stephen Gallagher wrote:
>
> ELN Special Interest Group (SIG)
...
> A weekly meeting time will be reserved for the ELN SIG to meet. However, it
> will be canceled if there are no issues tagged with the meeting label. The
> meeting time will be selected by a publi
> On 22/02/2021 21:18, Tom Seewald wrote:
>
>
>
> Personally, I have an older GPU, RX 580 Polaris series, I will only
> spend dev time on the AMD Navi GPU issues after AMD makes the RX 6800 XT
> available in my region. I simply don't have that card and I'm not going
> to waste money buying the
How can a package exist in an epel repo but not be reflected at
src.fedoraproject.org/rpms?
For example, according this, mkvtoolnix should not exist in EPEL:
https://src.fedoraproject.org/rpms/mkvtoolnix
Except it does:
> $ repoquery -i mkvtoolnix
> Name: mkvtoolnix
> Version : 46.0
On Mon, Feb 22, 2021 at 4:40 PM Andrew Bauer
wrote:
>
> How can a package exist in an epel repo but not be reflected at
> src.fedoraproject.org/rpms?
>
> For example, according this, mkvtoolnix should not exist in EPEL:
> https://src.fedoraproject.org/rpms/mkvtoolnix
>
> Except it does:
> > $ rep
On 2/22/21 9:12 PM, Lennart Poettering wrote:
> Quite frankly, I am not sure it would be a good idea to do things that
> way.
>
> note that resolved should be fine as a resolvconf replacement, even if
> you don't want to use it as a resolver: just set the /etc/resolv.conf
> symlink to /run/systemd
On Mon, 22 Feb 2021 21:19:26 -
"Tom Seewald" wrote:
> > On 22/02/2021 21:18, Tom Seewald wrote:
> >
> >
> >
> > Personally, I have an older GPU, RX 580 Polaris series, I will only
> > spend dev time on the AMD Navi GPU issues after AMD makes the RX 6800 XT
> > available in my region. I si
Yes, that's right. So why wouldn't the package show on the overview page in the
epel 7 branch then?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https
David Woodhouse wrote:
> On Fri, 2021-02-12 at 14:19 -0600, Justin Forbes wrote:
>> Just as there are many things that expect the 64K page size. I am not
>> doing this.
>
> I don't really find either of those to be compelling arguments, FWIW.
>
> If we have broken code which makes assumptions a
Henrik Nordström wrote:
> 2. Keep Radare2 and switch Cutter to R2Cutter. R2Cutter is the same
> Cutter that currently is in fedora in terms of source, but it's future
> is uncertain. And I am not sure if this is possible policy wise without
> packaging R2Cutter and retiring Cutter.
https://fedorap
I will check because I thought I had TLS up and working. Apparently not. How
did you discover this? I will fix it as soon as possible.
I need to get one of my hosts to fail. When I do that I will send the results
from that as well. These two examples have the correct data from my DHCP server.
On Mon, Feb 22, 2021 at 10:24:41AM +, Carlos "casep" Sepulveda wrote:
> On Sun, 21 Feb 2021 at 18:56, Micah Shennum wrote:
> >
> > Not sure if it's something weird with my system, but running that exact
> > command I get
> >
> > Error: Unknown repo: 'updates-testing-modular'
That's not an er
On Mon, Feb 22, 2021 at 5:43 pm, David Both
wrote:
I will check because I thought I had TLS up and working. Apparently
not. How did you discover this? I will fix it as soon as possible.
All of my mails to you are bouncing. Notice you don't have any direct
mails from me in your inbox. You
Tadej Janež wrote:
> I would argue that the change causes noticeable problems and we want to
> reconsider this change.
> In particular, I think cloud image users would prefer to have their
> cloud instances usable out of the box, i.e. have DNS working out-of-the
> box.
>
> Don't get me wrong, I un
Michael Catanzaro wrote:
> Is there some reason systemd-resolved cannot be a subpackage? Seems
> like that would be the easiest solution?
+1 to making this a subpackage. I really don't see why this has to be part
of the main systemd package.
There are other optional parts of systemd that should
No problem - I need to know this. Thanks!
--
*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBo
Lóránt Perger wrote:
> I would like to ask about the developers' stance towards supporting
> PulseAudio plugins when using `pipewire-pulseaudio`. On some other
> mainstream distributions this can easily be achieved as the modules are
> packaged with the PA pipewire replacement package, however, in
I rescued the giada package after it was orphaned and have updated it to the
latest upstream release, using the new CMake build system. The package now
properly documents its pre-existing bundled dependencies (four direct and many
indirect). Accordingly, the License field has changed from “GPLv3
On Sat, 2021-02-20 at 10:49 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 34 better? Please spend 1 minute of your
> time and try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled
> again
> sudo
Hi,
I am trying to update nextcloud-client to 3.1.3. Build keeps failing
with this -
/builddir/build/BUILD/desktop-3.1.3/src/gui/cloudproviders/cloudprovidermanager.cpp:15:1:
note: 'extern "C"' linkage started here
15 | extern "C" {
Can someone please explain how I can fix this failure
On Mon, Feb 22, 2021 at 6:46 PM Mukundan Ragavan wrote:
> I am trying to update nextcloud-client to 3.1.3. Build keeps failing
> with this -
>
> /builddir/build/BUILD/desktop-3.1.3/src/gui/cloudproviders/cloudprovidermanager.cpp:15:1:
> note: 'extern "C"' linkage started here
> 15 | extern "C"
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-20210222.0):
ID: 786468 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
85 matches
Mail list logo
