On 12/24/24 01:59 PM, Neal Gompa wrote:
On Tue, Dec 24, 2024 at 10:13 AM Steven A. Falco wrote:
This proposal mentions major versions 3, 5, and 6, but I don't see any mention
of major version 4.
I don't pretend to understand this in detail, but I am maintaining a project that
This proposal mentions major versions 3, 5, and 6, but I don't see any mention
of major version 4.
I don't pretend to understand this in detail, but I am maintaining a project that
currently calls for "protoc 25.3" or older, which I think comes from major
version 4. Fedora currently has 3.19.
I'm trying to build the KiCad package on rawhide via koji. I'm getting the
following errors:
DEBUG util.py:459: Repositories loaded.
DEBUG util.py:459: Failed to resolve the transaction:
DEBUG util.py:459: Problem: package vtk-devel-9.2.6-21.fc42.x86_64 from build
requires libvtkCommonCore.
On 9/5/24 10:54 AM, Simone Caronni wrote:
Hi everyone,
I've noticed that we're really behind on xorg-x11-server releases (almost 3
years!) and that by rebasing we would drop tons of patches that have already
been upstreamed during this time.
No one that is listed in the maintainer list of tha
On 9/5/24 06:57 AM, Miroslav Suchý wrote:
dnf --releasever=41 --enablerepo=updates-testing --assumeno distro-sync
Most of my issues are due to gimp: gutenprint-plugin, gimp-resynthesizer,
gimp-lqr-plugin.
Problem #2 relates to kicad-nightly which comes from Copr, so that may not be a
fair te
On 7/15/24 09:27 PM, 'Seth Hillbrand' via KiCad Developers wrote:
Hi Folks-
As of 77797103f7, we have a new dependency on libzstd compression library.
This is used to compress embedded files before storing them in our files.
Please be sure to update your local build environments to account fo
https://bugs.kde.org/show_bug.cgi?id=468817
--- Comment #6 from Steven A. Falco ---
I've switched to XFCE.
I guess you can just close this bug.
--
You are receiving this mail because:
You are watching all bug changes.
On 5/21/24 10:39 AM, Sandro wrote:
On 21-05-2024 16:32, Ben Cotton wrote:
On Tue, May 21, 2024 at 10:28 AM Sandro wrote:
However, now the link is in the open, we might have to change it again
and invalidate the link you posted. It's not meant to be out in the open.
It's probably fine. If so
On 5/21/24 10:17 AM, Sandro wrote:
On 21-05-2024 15:47, Vít Ondruch wrote:
Dne 21. 05. 24 v 15:45 Vít Ondruch napsal(a):
Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):
I'm getting the "410 Gone" message, too. Tried multiple times since yesterday
with no luck.
Yes, this
I'm getting the "410 Gone" message, too. Tried multiple times since yesterday
with no luck.
Steve
On 5/21/24 05:21 AM, Aoife Moloney wrote:
I've seen someone in the Red Hat Waterford office be able to claim it no
problem so the issue may be individually based as the link is definitel
On 5/3/24 03:14 PM, Wayne Stambaugh wrote:
I am please to announce that James Jackson has accepted an invitation to become
a member of the KiCad lead development team. For those of you who are not
aware, James recently contributed the schematic rule area feature which will be
released in vers
On 4/24/24 06:50 AM, Tom Hughes wrote:
On 24/04/2024 02:28, Xose Vazquez Perez wrote:
# mkdir /etc/systemd/system/httpd.service.d/
# vi /etc/systemd/system/httpd.service.d/override.conf
[Service]
ProtectHome=false
Better than just opening up whole trees again would
be to use ReadWritePaths=
I upgraded to F40, and suddenly an apache cgi script that was working perfectly in F39
(and earlier) is giving me a "Read-only file system" error when trying to write
data into a file.
The directory where the cgi is trying to write is owned by apache:apache, and
it is mode 777. The file the c
I noticed that the load average on a rawhide vm was higher than expected, and
according to 'top' I had two copies of /usr/bin/spice-vdagent running, with one
of them taking up a whole cpu core.
I removed /etc/xdg/autostart/spice-vdagent.desktop and rebooted. Now there is
only one copy of spic
On 4/2/24 03:50 PM, Steve Cossette wrote:
Well, we did submit this yesterday around 2:30-3:00PM EST, guessing it was a
bit too late.
But the proposal is 1000% serious.
I'm glad to hear you say that, as I switched to KDE around the time of Gnome3
and never looked back.
Steve
--
_
On 2/23/24 12:13 PM, Wayne Stambaugh wrote:
If you are not aware, 7.0.11 was release yesterday. This will most likely be
the last 7.0 branch bug fix release. We will continue to back port fixes to
this branch if they are trivial to back port so users who continue to run the
7.0 branch will b
On 2/21/24 11:46 AM, Jakub Jelinek wrote:
On Wed, Feb 21, 2024 at 11:34:37AM -0500, Steven A. Falco wrote:
I am getting an error "template-id not allowed for constructor in C++20" but
according to the Copr log [0], the compiler is being given -std=c++17:
It is a warning, but you&#x
I am getting an error "template-id not allowed for constructor in C++20" but
according to the Copr log [0], the compiler is being given -std=c++17:
Building CXX object
thirdparty/clipper2/CMakeFiles/clipper2.dir/Clipper2Lib/src/clipper.engine.cpp.o
cd /builddir/build/BUILD/kicad-7.0.11/redhat-l
On 2/8/24 05:44 AM, Neal Gompa wrote:
The Wayland protocol in question is this one:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
That said, even X11's version isn't widely supported. Typically,
support for this is plumbed through linking libSM, and GTK notably
doe
On 2/3/24 01:12 AM, Kevin Kofler via devel wrote:
Any interested people can already request comaintainership now (e.g., by
replying to this mail), and I will almost certainly grant it (though I will
have reservations about some specific types of requests, such as blanket
admin permissions for the
On 2/1/24 11:46 AM, Neal Gompa wrote:
I'd like to think that the gaps will be fixed, but it seems to me that because
of policy, some gaps (like apps controlling their own window placement) will
never be fixed.
That is not necessarily true. For your example about window placement,
there is th
On 2/1/24 11:28 AM, Neal Gompa wrote:
On Thu, Feb 1, 2024 at 4:21 PM Roberto Ragusa wrote:
On 2/1/24 14:29, Steve Cossette wrote:
And yes, that /is/ the whole point: We want to foster the use of Wayland, to
increase it's adoption, to force people using it to hit snags along the road
and fi
On 1/30/24 08:55 AM, Richard W.M. Jones wrote:
On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
3) Fedora has a long-standing and well-communicated stance that we are
a Wayland distribution first and foremost and that X11 support is
intended as a migration-support tool rather t
I used to get notifications of failed builds, but that no longer seems to
happen. I'm not sure what changed.
For example, please see [1]. There were a bunch of failed builds, and I only
found out about it when a user told me. I'd like to be proactive and fix
problems when they first occur.
On 12/21/23 08:53 AM, Neal Gompa wrote:
On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote:
I'm -1 for this change, it shouldn't be enabled by default as it will cause
issues for users using router mac filtering.
What this seems to state is that the MAC address would be unique for
each SSID,
On 9/18/23 11:33 AM, Neal Gompa wrote:
On Mon, Sep 18, 2023 at 11:12 AM Steven A. Falco wrote:
On 9/17/23 05:48 PM, Kevin Kofler via devel wrote:
Ian Laurie wrote:
I didn't think the greeter used Wayland? So there may be something else
going on. I cannot swear to it, but I don&#x
On 9/17/23 05:48 PM, Kevin Kofler via devel wrote:
Ian Laurie wrote:
I didn't think the greeter used Wayland? So there may be something else
going on. I cannot swear to it, but I don't think I've noticed problems
in the greeter before.
As Adam posted, the offset problem already has a bug fo
On 9/18/23 08:41 AM, Pavel Raiskup wrote:
Thank you Steven for the report,
On sobota 16. září 2023 19:47:10 CEST Steven A. Falco wrote:
For the last two days I've been seeing build errors like [1] and [2]:
ERROR: Command failed:
# mount -n -t tmpfs -o mode=0755 -o nr_inodes=0 -o
For the last two days I've been seeing build errors like [1] and [2]:
ERROR: Command failed:
# mount -n -t tmpfs -o mode=0755 -o nr_inodes=0 -o size=140g mock_chroot_tmpfs
/var/lib/mock/fedora-38-x86_64-1694797525.338111/root
Prior to this, the KiCad builds have been running pretty smoothly.
On 9/14/23 04:20 PM, Steven A. Falco wrote:
I've written a bug [1] stating that window placement appears to be ignored.
Specifically the following command ignores the requested placement under
Plasma(Wayland) but the placement is honored under Plasma(X11). That is a big
problem in a
On 9/14/23 06:36 AM, Ian McInerney wrote:
On Thu, 14 Sep 2023, 00:17 Neal Gompa, mailto:ngomp...@gmail.com>> wrote:
On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
>
> On 9/13/23 05:23 PM, Neal Gompa wrote:
> &
On 9/13/23 07:16 PM, Neal Gompa wrote:
On Wed, Sep 13, 2023 at 7:02 PM Steven A. Falco wrote:
On 9/13/23 05:23 PM, Neal Gompa wrote:
Right. And I want to stress we are not dropping support for X11
applications. Anything running as an X client in a desktop should work
as it has before.
I&#
mending it as a viable option.
Seth
KiCad Services Corporation Logo
Seth Hillbrand
*Lead Developer*
+1-530-302-5483
Long Beach, CA
www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com
<mailto:i...@kipro-pcb.com>
On Wed, Sep 13, 2023 at 9:20 AM Steven A. Falco mailto:st
On 9/13/23 05:23 PM, Neal Gompa wrote:
Right. And I want to stress we are not dropping support for X11
applications. Anything running as an X client in a desktop should work
as it has before.
I'm not convinced KiCad will work in that scenario, so please let me summarize
what I've read here, an
On 9/13/23 12:10 PM, Steven A. Falco wrote:
On 9/13/23 11:53 AM, Aoife Moloney wrote:
Wiki https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
There is a proposed change for Fedora 40 [1] where the proposal is to upgrade
KDE to version 6, and exclusively support wayland, dropping all support for X11.
I've posted to the development list [2] expressing my concerns. At the moment,
dropping X11 is just a proposal, but it seems likely to
On 9/13/23 11:53 AM, Aoife Moloney wrote:
Wiki https://fedoraproject.org/wiki/Changes/KDE_Plasma_6
== Summary ==
KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE
Community. It is based on Qt 6 and KDE Frameworks 6 and brings many
changes and improvements over previous versions. Fo
On 8/23/23 04:12 PM, Richard Shaw wrote:
On Wed, Aug 23, 2023 at 1:41 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
On 8/23/23 02:22 PM, Miroslav Suchý wrote:
> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
> --enablerepo=updates-testing \
On 8/23/23 02:22 PM, Miroslav Suchý wrote:
dnf --releasever=39 --setopt=module_platform_id=platform:f39 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo
--enablerepo=updates-testing-modular) \
--assumeno distro-sync
Problem 1: problem with installed package fre
On 8/22/23 02:57 PM, Steven A. Falco wrote:
Nightly build looks to be broken by latest clipper2 code.
Steve
Full logs available here:
https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/6334769/
--
You received this message because you are subscribed to the Google
Looks like it is a mirror issue. Adding --enablerepo=local corrects it.
Please disregard my previous email.
Steve
On 8/21/23 02:41 PM, Steven A. Falco wrote:
Not sure if this is a known problem, but I'm getting build failures from mock
on rawhide. F37, F38, and F39 a
Not sure if this is a known problem, but I'm getting build failures from mock
on rawhide. F37, F38, and F39 are ok.
Steve
Error:
Problem: package wxGTK-devel-3.2.2.1-5.fc39.x86_64 from fedora requires
libwx_gtk3u_webview-3.2.so.0()(64bit), but none of the providers can be
installed
Looks good now. Thanks for the super quick fix!
Steve
On 8/18/23 03:42 PM, Alex Shvartzkop wrote:
Should be fixed now.
On Fri, Aug 18, 2023 at 10:23 PM Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
I don't know if this is already fixed, but the nightly builds
I don't know if this is already fixed, but the nightly builds are failing on
Fedora 38 and up. Curiously, F37 is ok, so perhaps the compiler has gotten
more picky.
I can enter a bug if desired. Just let me know...
Steve
[ 42%] Building CXX object
common/CMakeFiles/pcbcommon.dir/__/
On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote:
## How to run things locally?
You can use mock. Make sure to:
1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local
...
That doesn't appear correct. At
On 6/21/23 05:32 PM, Steven A. Falco wrote:
Hi - For a while the following project has been building fine:
https://copr.fedorainfracloud.org/coprs/g/kicad/kicad-testing/builds/
In the last few days, the automatic builds have been failing very early,
without too much useful information
Hi - For a while the following project has been building fine:
https://copr.fedorainfracloud.org/coprs/g/kicad/kicad-testing/builds/
In the last few days, the automatic builds have been failing very early,
without too much useful information. However, manual builds that I trigger
from my own
I ran a KiCad build yesterday on Copr [1] (so not the same as Koji), but while
it all completed, curiously the rawhide PPC build took 6 hours while the f37
and f38 PPC builds only took 2 hours.
The corresponding Koji build [2] took close to 4 hours, so it is in the
ball-park.
KiCad is a bit u
The following pertains to KiCad availability on Fedora Linux. Please note that
none of what follows affects the official builds hosted by Fedora in any way.
Everything below pertains only to the Copr repositories hosted by the KiCad
team itself.
Previously, there was only one Copr repository
https://bugs.kde.org/show_bug.cgi?id=468817
--- Comment #4 from Steven A. Falco ---
Created attachment 158401
--> https://bugs.kde.org/attachment.cgi?id=158401&action=edit
After waking monitors
Note that one Desktop window has disappeared and the backround is now just
plain black.
https://bugs.kde.org/show_bug.cgi?id=468817
--- Comment #3 from Steven A. Falco ---
Created attachment 158400
--> https://bugs.kde.org/attachment.cgi?id=158400&action=edit
windows before sleeping
Two desktop windows, proper desktop background.
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=468817
--- Comment #2 from Steven A. Falco ---
I opened the kwin debug window before letting the screens go to sleep. At that
point it shows two X11 Desktop windows - one for the 2560x1600 monitor and one
for the 1920x1080 monitor.
I then let the screens go
https://bugs.kde.org/show_bug.cgi?id=468817
Bug ID: 468817
Summary: Screen energy saving causes multiple problems when
waking up
Classification: Plasma
Product: kwin
Version: git-stable-Plasma/5.27
Platform: Fedora RPMs
I've gotten a similar result. Without --allowerasing:
Error:
Problem 1: conflicting requests
- problem with installed package gimp-heif-plugin-1.1.0-12.fc37.x86_64
- gimp-heif-plugin-1.1.0-12.fc37.x86_64 does not belong to a distupgrade
repository
Problem 2: problem with installed package
On 4/4/23 09:56 AM, Neal Gompa wrote:
On Tue, Apr 4, 2023 at 9:49 AM Steven A. Falco wrote:
On 4/4/23 05:58 AM, ser...@serjux.com wrote:
On 2023-04-03 21:13, Steven A. Falco wrote:
I'm confused by the Requires for redhat-lsb-core.
According to "dnf repoquery --requires redha
On 4/4/23 05:58 AM, ser...@serjux.com wrote:
On 2023-04-03 21:13, Steven A. Falco wrote:
I'm confused by the Requires for redhat-lsb-core.
According to "dnf repoquery --requires redhat-lsb-core" there is no
requirement for esmtp. But according to "dnf repoquery --whatreq
On 4/3/23 04:21 PM, Stephen Gallagher wrote:
On Mon, Apr 3, 2023 at 4:15 PM Steven A. Falco wrote:
I'm confused by the Requires for redhat-lsb-core.
According to "dnf repoquery --requires redhat-lsb-core" there is no requirement for
esmtp. But according to "dnf repo
I'm confused by the Requires for redhat-lsb-core.
According to "dnf repoquery --requires redhat-lsb-core" there is no requirement for
esmtp. But according to "dnf repoquery --whatrequires esmtp", redhat-lsb-core does
require esmtp.
Perhaps there is some sort of transitive requirement that the
On 3/23/23 06:14 AM, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 22 March 2023 at 17:12, Steven A. Falco wrote:
On 3/22/23 11:23 AM, stan via devel wrote:
On Tue, 21 Mar 2023 17:14:44 -0400
"Steven A. Falco" wrote:
I think I'm finally getting somewhe
On 3/22/23 11:23 AM, stan via devel wrote:
On Tue, 21 Mar 2023 17:14:44 -0400
"Steven A. Falco" wrote:
I think I'm finally getting somewhere with this problem.
My motherboard has a built-in VGA interface, which shows up as
"astdrmfb" on fb0. My AMD video card is &
how to force a framebuffer to be ignored, I'd
appreciate it.
Steve
On 3/21/23 03:26 PM, Steven A. Falco wrote:
On 3/21/23 02:26 PM, stan via devel wrote:
On Tue, 21 Mar 2023 10:25:36 -0400
"Steven A. Falco" wrote:
I recently put a new machine together using an
On 3/21/23 02:26 PM, stan via devel wrote:
On Tue, 21 Mar 2023 10:25:36 -0400
"Steven A. Falco" wrote:
I recently put a new machine together using an AMD Radeon PRO W6600
Graphics Card. CPU is a threadripper pro. Motherboard is an ASUS
Pro WS WRX80E-SAGE SE WIFI II sWRX8 E-ATX. S
I recently put a new machine together using an AMD Radeon PRO W6600 Graphics
Card. CPU is a threadripper pro. Motherboard is an ASUS Pro WS WRX80E-SAGE SE
WIFI II sWRX8 E-ATX. Software is the KDE spin of Fedora 37.
It mostly works perfectly, but if I try to access a virtual terminal with
Ct
As a workaround until the dust settles, I did a dnf downgrade of libheif and
added an exclude in dnf.conf. I'll revert that when the add-ons are published.
Steve
On 3/20/23 02:39 PM, Kalev Lember wrote:
On Mon, Mar 20, 2023 at 7:29 PM Vitaly Zaitsev via devel mailto:devel@lists.fedora
Thanks for the clarification. I'll leave the downstream as is until v8.
Steve
On 3/20/23 01:44 PM, Ian McInerney wrote:
Thanks for updating the nightlies. Just to clarify though, this change will not
be backported to v7, so you should keep the flag for the downstream v7 packages
unti
lso wouldn't be
trivial to move F36 to the wx 3.2-ish branch anyway, since it has wx 3.1.5 and
a wxPython version for wx 3.0.5, so doing so would require custom packaging of
wxPython, which isn't something that seems work doing just for a few months of
support.
-Ian
On Sat, Mar 4,
The Fedora 36 nightly builds are failing because wx 3.0 doesn't have the
GetCharExcludes() function. F37 and newer are ok, because they have wx 3.2
which does have that function.
I don't intend to produce a 7.0 build for F36, unless I'm forced to by a CVE
that cannot be fixed in 6.0.
I suppo
On 2/22/23 10:28 AM, Steven A. Falco wrote:
I got the following errors:
Error:
Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
- yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
I got the following errors:
Error:
Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
- yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
- problem with installed package opencolorio1-1.
A user has reported a bug: https://bugzilla.redhat.com/show_bug.cgi?id=2169876
I'm at a bit of a loss, because there are no error messages yet. I've made
some suggestions of things to try, but if any devs have other thoughts, I'll
relay them to the user.
Steve
--
You received this me
ains about Nextcloud.
Steve
On 2/14/23 05:52 PM, Steven A. Falco wrote:
Thanks! That does sound very similar. I'll try the approach that the
easyBackup page suggested, and see if it helps.
Steve
On 2/14/23 12:28 PM, Martin Simmons wrote:
If Nextcloud works like OneDrive, then it could
p.com/knowledge-base/error-media-is-write-protected-backing-up-onedrive-with-vss/
On Sat, 11 Feb 2023 10:52:29 -0500, Steven A Falco said:
I have been using Bacula to back up a Windows 10 virtual machine client in
addition to a number of physical Linux clients without any problems for several
I have been using Bacula to back up a Windows 10 virtual machine client in
addition to a number of physical Linux clients without any problems for several
years.
Recently I upgraded the win10 vm to Windows 11, and I am now getting an error
message from the VSS snapshot system. I don't know if
libhackrf has updated from 0.7.0 to 0.8.0 in rawhide.
No dependent packages depend on the exact version, so nothing else should need
rebuilding. Tested with CubicSDR and gnuRadio.
Steve
___
devel mailing list -- devel@lists.fedoraproject.org
KiCad will shortly be upgraded from 6.0.11 to 7.0.0-rc2 in Rawhide.
Designs created with KiCad 6 and earlier are readable / editable by KiCad 7.
However, once a design is saved with KiCad 7, it will no longer be readable by
KiCad 6 or earlier.
Steve
Another thing that might help is the attached script. I use it to make test
builds of KiCad, and it doesn't require any special privileges. Just do a git
clone, then make a build subdirectory, and run the script like so:
git clone https://gitlab.com/kicad/code/kicad.git
cd kicad
mkdir build-m
On 1/22/23 07:42 PM, William Douglas wrote:
Just tried compiling the latest version of KiCad direct from source. For the
"INSTALL_PREFIX" I specified a directory within my home directory. This was to
prevent the new build from impacting my system.
After building I attempted to install as the
Fedora 36 / 37 will stay on the 6.0 series unless a CVE forces us to do an
upgrade to KiCad 7, so I don't foresee any issues for the production builds.
The nightlies could possibly be affected, but I'd guess that anyone testing
nightlies could upgrade to F37 or Rawhide without too much trouble.
On 12/12/22 07:19 PM, Wayne Stambaugh wrote:
The 6.0.10 stable release of KiCad is planned for Monday, December 19th. If
you have any last minute changes to get into any of the repos, now is the time.
I plan on tagging the 6.0 branch on Saturday to allow time for our builders to
complete and
The nightly Copr builds for KiCad are failing on the ppc64le builders [1].
Is this a known problem? It looks like there has been an issue for the past 3
days or so [2].
Steve
[1] https://copr.fedorainfracloud.org/coprs/g/kicad/kicad/build/5119571/
[2] https://copr.fedorainfracloud.org
On 12/7/22 09:14 AM, Tomas Hrcka wrote:
Fedora 36 will continue to receive updates until approximately one
month after the release of Fedora 37.
Shouldn't that be "until approximately one month after the release of Fedora
_38_"?
Steve
___
de
On 11/24/22 08:45 AM, Kalev Lember wrote:
Hi Scott,
On Wed, Nov 23, 2022 at 6:23 PM Scott Talbert mailto:s...@techie.net>> wrote:
Hi all,
In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
currently built with OpenGL EGL support) and several package users wh
On 11/23/22 12:58 PM, Steven A. Falco wrote:
On 11/23/22 12:23 PM, Scott Talbert wrote:
Hi all,
In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
currently built with OpenGL EGL support) and several package users which are
expecting OpenGL GLX support, I need to
On 11/23/22 12:23 PM, Scott Talbert wrote:
Hi all,
In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is
currently built with OpenGL EGL support) and several package users which are
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different
configuration o
The package hackrf has several open bugs [1], [2].
I've started the non-responsive maintainer process by filing [3].
I've CC'd the maintainer on this email, but if anyone knows how else to contact
them, please let me know.
Thanks,
Steve
[1] https://bugzilla.redhat.com/show_bug
On 11/16/22 06:25 PM, Scott Talbert wrote:
I just upgraded my system to Fedora 37 and noticed that the package "hackrf" was
still from Fedora 36. I found a failed build from the f37-rebuild, dated
2022-07-21 [1].
It apparently failed on aarch64, but the logs are long gone - at least I don't
se
I just upgraded my system to Fedora 37 and noticed that the package "hackrf"
was still from Fedora 36. I found a failed build from the f37-rebuild, dated 2022-07-21
[1]. It apparently failed on aarch64, but the logs are long gone - at least I don't see
them on koji.
I tried a scratch build,
On 11/10/22 09:47 AM, Eike Rathke wrote:
Hi Miroslav,
On Monday, 2022-11-07 18:46:26 +0100, Miroslav Suchý wrote:
Tl;dr Please start migrating your license tag to SPDX now.
Is it ok to have SPDX tags on all currently supported release branches,
i.e. f37, f36, f35?
Yes.
Steve
On 11/3/22 02:14 PM, Jon Evans wrote:
> you won't have access to the footprints you had previously used.
You can make a project-local library and export the old footprints to it if
desired. I think that is a reasonable workflow.
That works well. Thanks.
Steve
--
You received thi
On 11/3/22 12:11 PM, Jon Evans wrote:
KiCad 6.x should still be able to open these files even if they used old symbols and
footprints. I'm not sure they would need "porting" other than saving in the
updated format. New schematics can be made with new symbols/footprints as desired.
True, but
On 11/3/22 11:38 AM, Marco Ciampa wrote:
Can somebody address this request or at least point to the right
direction of how to solve it in the easiest way?
I suspect the biggest issue would be the libraries, as they have changed over
time. For example, I had a design that used:
R_0603_1608Met
On 10/14/22 05:32 PM, Steven A. Falco wrote:
I've received a bug: https://bugzilla.redhat.com/show_bug.cgi?id=2134832
The basic issue is that Fedora uses both /usr/lib/python3.10 and
/usr/lib64/python3.10; i.e. they separate the 32-bit and 64-bit files. The
KiCad build scripts currentl
I've received a bug: https://bugzilla.redhat.com/show_bug.cgi?id=2134832
The basic issue is that Fedora uses both /usr/lib/python3.10 and
/usr/lib64/python3.10; i.e. they separate the 32-bit and 64-bit files. The
KiCad build scripts currently put _pcbnew.so into /usr/lib/python3.10, but
becau
On 9/28/22 09:59 AM, Stephen Smoogen wrote:
On Wed, 28 Sept 2022 at 09:53, Steven A. Falco mailto:stevenfa...@gmail.com>> wrote:
Yesterday, I had a build that failed. The task ID is 92381483.
I tried rebuilding it today in task 92397327 but I get the error m
Yesterday, I had a build that failed. The task ID is 92381483.
I tried rebuilding it today in task 92397327 but I get the error message:
"GenericError: Build already in progress (task 92381483)"
I tried doing "koji cancel 92381483" but that doesn't help. Another attempt
(task 92398262) faile
On 9/12/22 08:59 AM, Miroslav Suchý wrote:
dnf --releasever=37 --setopt=module_platform_id=platform:f37 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo
--enablerepo=updates-testing-modular) \
--assumeno distro-sync
Error:
Problem: package nautilus-dropbox-1:2
License changed from GPLv3 to GPL-3.0-or-later
(In the past it should have been GPLv3+ rather than GPLv3, so I fixed that in
the process of converting to SPDX, in case anyone was wondering...)
Steve
___
devel mailing list -- devel@lists.fedora
On 9/8/22 06:44 AM, Miroslav Suchý wrote:
Quick heads up where we are:
I had been following this discussion, and I vaguely remember that there was
talk of it having to be conditional, perhaps with a macro.
Has all that now been resolved? Can one simply convert to the new SPDX license
identi
On 8/23/22 10:30 AM, Chris Murphy wrote:
On Sun, Aug 21, 2022, at 2:31 PM, Chris Murphy wrote:
https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation
I found a small problem, fixed in the latest version.
Gory details:
If you've ever used grubby, an /etc/kernel/cmdline
On 8/22/22 09:31 PM, Jon Evans wrote:
Hi all,
The initial work to support database libraries will be merged this week, which
will introduce a dependency on unixodbc for non-Windows platforms. We've been
testing this on Ubuntu, Fedora, and macOS with no issues so far. Please let me
know if a
1 - 100 of 825 matches
Mail list logo
