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-20210425.0):
ID: 870083 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
Hi,
Calf packages seem to need some attention:
Problem 1: package calf-0.90.3-6.fc32.x86_64 requires
libfluidsynth.so.1()(64bit), but none of the providers can be installed
- cannot install both fluidsynth-libs-2.1.8-3.fc32.x86_64 and
fluidsynth-libs-1.1.11-7.fc32.x86_64
- cannot install
Hello everyone,
Please join us at the next Open NeuroFedora team meeting on Monday 26th
April (today!) at 1300UTC in #fedora-neuro on IRC (Freenode). The
meeting is a public meeting, and open for everyone to attend. You can
join us over:
IRC:
https://webchat.freenode.net/?channels=#fedora-neuro
Hi,
when compiling [1] vdr-mpv on fc34, i get this error message:
/usr/include/xf86drmMode.h:43:10: fatal error: drm.h: No such file or directory
I already opened a buzilla ticket [2] but still no response.
I can be solve this error by changing line 43 in /usr/include/xf86drmMode.h:
#include
t
Martin Gansser wrote on 2021/04/26 17:37:
Hi,
when compiling [1] vdr-mpv on fc34, i get this error message:
/usr/include/xf86drmMode.h:43:10: fatal error: drm.h: No such file or directory
I already opened a buzilla ticket [2] but still no response.
I can be solve this error by changing line 43
On Monday, 26 April 2021 at 10:17, Marius Schwarz wrote:
> Hi,
>
> Calf packages seem to need some attention:
Opening a bugzilla ticket (or checking if one is open already) is much
better than complaining here. If maintainer is not responding to
bugzilla, perhaps the non-responsive maintainer pro
Thanks a lot for this hint and solution.
Regards
Martin
___
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
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-20210425.0):
ID: 870153 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
It's spring, it's raining sleet where I live, and it's also the season
for new rpm in rawhide. As per
https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been quite large, and
while it's supposed to be backwards compatible with changes this big
i
> On Tue, Apr 13, 2021 at 8:09 AM Zbigniew Jędrzejewski-Szmek
>
> The new metadata guarantees that the ELF data churns, though. For
> example, if I bump the Release in a spec file for something unrelated
> to the build, all the ELF blobs change. The current state means that
> this is deduplicated
Dne 24. 04. 21 v 11:10 Kevin Kofler via devel napsal(a):
Tom Stellard wrote:
This change was never rejected. It become stalled waiting for the change
owners to address some feedback from FESCo. The feedback has been
addressed now, which is why it was resubmitted.
Ah, then I hereby urge FESCo
On 4/26/21 1:36 PM, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season
for new rpm in rawhide. As per
https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been quite large, and
while it's supposed to be b
On Fri, Apr 23, 2021 at 12:35:34PM -0400, Ben Cotton wrote:
> On Fri, Apr 23, 2021 at 12:32 PM Tom Stellard wrote:
>
> > The proposed changes[1] to the packaging guidelines does require packagers
> > document their reasons in bugzilla, but that's it.
> >
> At the risk of getting too bikesheddy, w
On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote:
> On 23.04.2021 17:18, Ben Cotton wrote:
> >The goal is to give the packager the ability to use their own
> >technical judgement to choose the best compiler.
>
> +1 for this change.
Same here. I like the no-nonsense policy
Good thing the maintainer reads -devel or she'd have missed this. :)
Looks like fluidsynth got updated and calf needs a rebuild. I'll get that out.
--
Gwyn Ciesla
she/her/hers
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Will attend the meeting today
___
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 Guidelin
Vít Ondruch wrote:
> Kevin, I'd love to support your stance and use GCC. However, there are
> reasons why we will need to consider Clang for e.g. Ruby:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1721553
>
> And the reason is not even that upstream favors Clang. The situation is
> unfortunate
Hi all,
I'm wanting to update the fwupd package in Fedora rawhide to the
recently released 1.6.0, but this release splits out the EFI binary to
a new source package. I've created
https://bugzilla.redhat.com/show_bug.cgi?id=1953508 for the new
package review process and would appreciate a reviewer
How many more years can I expect it will take to resolve or at least
seriously examine this following BZ?
https://bugzilla.redhat.com/show_bug.cgi?id=1414539
Does the maintainer of the utility care ? Does he check the BZ tickets ?
Does the gnome-sig triage the BZs against gnome components at leas
On Mon, Apr 26, 2021 at 10:38 AM Michal Schorm wrote:
>
> How many more years can I expect it will take to resolve or at least
> seriously examine this following BZ?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1414539
>
> Does the maintainer of the utility care ? Does he check the BZ tickets ?
在 2021-04-26星期一的 08:17 +0200，Michal Schorm写道：
> How many more years can I expect it will take to resolve or at least
> seriously examine this following BZ?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1414539
Just gone through the thread and it seems to be a selinux problem.
Maybe the BZ shoul
On Mon, Apr 26, 2021 at 10:44 AM Michal Schorm wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1414539
>
> Who to contact?
> Who to turn onto ?
>
I suggest filing it upstream:
https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues
--
Ben Cotton
He / Him / His
Senior Program Manager,
Dne 26. 04. 21 v 16:20 Kevin Kofler via devel napsal(a):
Vít Ondruch wrote:
Kevin, I'd love to support your stance and use GCC. However, there are
reasons why we will need to consider Clang for e.g. Ruby:
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
And the reason is not even that upst
On Mon, Apr 26, 2021 at 3:31 AM Chris Murphy
wrote:
> On Sun, Apr 25, 2021 at 12:39 PM Artem Tim wrote:
> > Upcoming 5.12 allow building with dynamic preemption support which
> allows changing mode at boot/run-time so finally no need to rebuild or make
> alternative kernel build anymore[1]. Resp
On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
Vít Ondruch wrote:
Kevin, I'd love to support your stance and use GCC. However, there are
reasons why we will need to consider Clang for e.g. Ruby:
https://bugzilla.redhat.com/show_bug.cgi?id=1721553
And the reason is not even that upstream
On 4/26/2021 8:00 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 23, 2021 at 07:24:28PM +0200, Vitaly Zaitsev via devel wrote:
On 23.04.2021 17:18, Ben Cotton wrote:
The goal is to give the packager the ability to use their own
technical judgement to choose the best compiler.
+1 for this
On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
wrote:
I'll be probably repeating myself, but the two compilers are known to be
ABI incompatible in very important ways, none of the
https://bugs.llvm.org/buglist.cgi?quicksearch=42439%2C1990
On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote:
>
> On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
> > Vít Ondruch wrote:
> > > Kevin, I'd love to support your stance and use GCC. However, there are
> > > reasons why we will need to consider Clang for e.g. Ruby:
> > >
> > > https:/
On 4/24/2021 3:10 AM, Kevin Kofler via devel wrote:
Tom Stellard wrote:
This change was never rejected. It become stalled waiting for the change
owners to address some feedback from FESCo. The feedback has been
addressed now, which is why it was resubmitted.
Ah, then I hereby urge FESCo to f
On 4/26/2021 9:52 AM, Jakub Jelinek wrote:
On Mon, Apr 26, 2021 at 09:43:34AM -0600, Jeff Law wrote:
On 4/26/2021 8:20 AM, Kevin Kofler via devel wrote:
Vít Ondruch wrote:
Kevin, I'd love to support your stance and use GCC. However, there are
reasons why we will need to consider Clang for e.g
Hi,
On Fri, 2021-04-23 at 20:01 +0200, Jakub Jelinek wrote:
> On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> > The Red Hat tools team believes that LLVM/Clang and GCC should be
> > considered equals from
> > a Fedora policy standpoint. Selection of one toolchain over the other
> >
On Mon, Apr 26, 2021 at 09:51:50AM -0600, Jeff Law wrote:
>
> On 4/24/2021 8:26 AM, Michael Catanzaro wrote:
> > On Fri, Apr 23 2021 at 08:01:03 PM +0200, Jakub Jelinek
> > wrote:
> > > I'll be probably repeating myself, but the two compilers are known to be
> > > ABI incompatible in very importa
On 25.04.2021 20:39, Artem Tim wrote:
Please provide full PREEMPT mode by default in 5.12 kernel for desktop
variants. With 5.12 it is possible for user to change it without efforts if
they need this.
+1 for this. Significantly reduces X11 input lag in full-screen games.
--
Sincerely,
Vita
On Sat, 24 Apr 2021, Kevin Fenzi wrote:
On Tue, Jan 12, 2021 at 10:42:28PM -0500, Scott Talbert wrote:
OK, I'm going to make an attempt to move python-qt5 (and its friends) to
sip5. I'm planning to build everything in a copr first.
Hey Scott.
Did you get any further with this?
Anything I
Hi everyone,
In Friday's Go/No-Go meeting, we decided that having 5 hours between
the completion of an RC and the start of the Go/No-Go meeting is not
the ideal situation. So I got assigned the homework of starting the
conversation about how to prevent this in the future. After all, if we
don't st
* Jeff Law:
> There are cases where Clang is the better choice and other cases where
> GCC is the better choice. The upstream projects are in the best
> position to make such decisions for their projects and the Fedora
> maintainers are in the best position to bring that decision into
> Fedora.
Hi everybody,
Long story short, I can no longer in good conscience be the primary
maintainer of (most) Java packages in Fedora. I am not using any of
them, I don't like Java or any other languages targeting the JVM, and
don't get me started on the horrid Java ecosystem. Recently I've been
spending
On Mon, 26 Apr 2021 at 15:20, Fabio Valentini wrote:
> Hi everybody,
>
> Long story short, I can no longer in good conscience be the primary
> maintainer of (most) Java packages in Fedora. I am not using any of
> them, I don't like Java or any other languages targeting the JVM, and
> don't get me
On Mon, Apr 26, 2021 at 3:26 PM Fabio Valentini wrote:
>
> Long story short, I can no longer in good conscience be the primary
> maintainer of (most) Java packages in Fedora. I am not using any of
> them, I don't like Java or any other languages targeting the JVM, and
> don't get me started on the
On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel
wrote:
>
> On 25.04.2021 20:39, Artem Tim wrote:
> > Please provide full PREEMPT mode by default in 5.12 kernel for desktop
> > variants. With 5.12 it is possible for user to change it without efforts if
> > they need this.
>
> +1 for thi
On 4/26/21 12:18 PM, Florian Weimer wrote:
* Jeff Law:
There are cases where Clang is the better choice and other cases where
GCC is the better choice. The upstream projects are in the best
position to make such decisions for their projects and the Fedora
maintainers are in the best position t
On Mon, Apr 26, 2021 at 09:19:44PM +0200, Fabio Valentini wrote:
> Long story short, I can no longer in good conscience be the primary
> maintainer of (most) Java packages in Fedora. I am not using any of
> them, I don't like Java or any other languages targeting the JVM, and
> don't get me started
On Mon, Apr 26, 2021 at 10:26 PM Fabio Valentini
wrote:
> Hi everybody,
>
> Long story short, I can no longer in good conscience be the primary
> maintainer of (most) Java packages in Fedora. I am not using any of
> them, I don't like Java or any other languages targeting the JVM, and
> don't get
On Mon, 2021-04-26 at 21:19 +0200, Fabio Valentini wrote:
> Hi everybody,
>
> Long story short, I can no longer in good conscience be the primary
> maintainer of (most) Java packages in Fedora. I am not using any of
> them, I don't like Java or any other languages targeting the JVM, and
> don't ge
Good to know. I am crossing fingers 🤞 and hope you could improve current
defaults and this will be upstreamed. So at least users who want PREEMPT could
enable it in runtime and not need to rebuild custom kernel every time for this.
___
devel mailing lis
On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for new
rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been quite large, and while
it's supposed to be b
On Mon, Apr 26, 2021 at 1:29 PM Justin Forbes wrote:
>
> On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 25.04.2021 20:39, Artem Tim wrote:
> > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop
> > > variants. With 5.12 it is possible for user
On Mon, Apr 26, 2021 at 5:12 PM Andrew Lutomirski wrote:
>
> On Mon, Apr 26, 2021 at 1:29 PM Justin Forbes wrote:
> >
> > On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel
> > wrote:
> > >
> > > On 25.04.2021 20:39, Artem Tim wrote:
> > > > Please provide full PREEMPT mode by default in
It looks like, in openQA and manual VM testing at least, since kbd-
2.4.0-3.fc35 landed in Rawhide, all characters are invisible at the
console. They're actually there, you just can't seem them. To work
around this, downgrade to kbd-2.4.0-2.fc34 from F34. For more info see
https://bugzilla.redhat.c
Hi,
I hope there are some KDE experts on the list who can help me debug this -
https://bugzilla.redhat.com/show_bug.cgi?id=1953472.
It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart script
in /etc/xdg/autostart/vmware-user.desktop. GNOME seems to work fine.
Could you pleas
Scott Talbert wrote:
> Yes, I got fairly far with porting all PyQt5 SIP consumers (including
> calibre) to use SIPv5. I think I then got discouraged at the thought of
> making a bunch of PRs and having to nag maintainers to merge them in some
> sort of coordinated fashion.
>
> I guess - if I get
Ravindra Kumar wrote:
> Hi,
>
> I hope there are some KDE experts on the list who can help me debug this -
> https://bugzilla.redhat.com/show_bug.cgi?id=1953472.
>
> It looks like KDE in Fedora 34 is not honoring open-vm-tools autostart
> script in /etc/xdg/autostart/vmware-user.desktop. GNOME s
On 4/27/21 12:47 AM, Miro Hrončok wrote:
On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season
for new rpm in rawhide. As per
https://fedoraproject.org/wiki/Changes/RPM-4.17.
The changes to the macro subsystem internals have been qu
53 matches
Mail list logo
