Automatic virtual provides for RPM macros?
by Miro Hrončok
Hello,
today at Nest, somebody said "unfortunately, there is no way to tell what
package to install to get a particular RPM macro".
I think that having an RPM provides generator for "rpm-macro(__python3)" or
similar should be a fairly simple exercise.
Would you folks consider that useful?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 week, 6 days
RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changel...
== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
technical level
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-aut...
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
accordingly.
To get beautiful changelogs, you also need to add
<pre>
%buildsys_name Your name
%buildsys_email Your email
</pre>
in ~/.rpmmacros
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
7 months, 1 week
Problem Compiling yabridge 3.8.0: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'
by Martin Gansser
Hi,
I am trying to compile [1] yabridge 3.8.0 on Fedora 35, but I get the following error message:
[22/35] wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p
/meson-generated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp
FAILED: src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o
wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p/meson-g
enerated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp
In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13:
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp: In function 'void dnd_winevent_callback(HWINEVENTHOOK, DWORD, HWND, LONG, LONG, DWORD, DWORD)':
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:756:36: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'} [-fpermissive]
756 | GetWindowThreadProcessId(hwnd, &process_id);
| ^~~~~~~~~~~
| |
| uint32_t* {aka unsigned int*}
In file included from /usr/include/wine/windows/windows.h:40,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17,
from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9:
/usr/include/wine/windows/winuser.h:3953:61: note: initializing argument 2 of 'DWORD GetWindowThreadProcessId(HWND, LPDWORD)'
3953 | WINUSERAPI DWORD WINAPI GetWindowThreadProcessId(HWND,LPDWORD);
| ^~~~~~~
In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13:
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:793:22: error: invalid conversion from 'unsigned int*' to 'ULONG*' {aka 'long unsigned int*'} [-fpermissive]
793 | &num_formats);
| ^~~~~~~~~~~~
| |
| unsigned int*
In file included from /usr/include/wine/windows/objbase.h:262,
from /usr/include/wine/windows/ole2.h:25,
from /usr/include/wine/windows/wtypes.h:13,
from /usr/include/wine/windows/winscard.h:22,
from /usr/include/wine/windows/windows.h:67,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17,
from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9:
/usr/include/wine/windows/objidl.h:9511:16: note: initializing argument 3 of 'virtual HRESULT IEnumFORMATETC::Next(ULONG, FORMATETC*, ULONG*)'
9511 | ULONG *pceltFetched) = 0;
| ~~~~~~~^~~~~~~~~~~~
winegcc: /usr/bin/g++ failed
ninja: build stopped: subcommand failed.
[1] https://martinkg.fedorapeople.org/ErrorReports/yabridge/yabridge.spec
Is there any solution, how can I solve this ?
Regards
Martin
1 year
EPEL8 build problem
by Steve Cossette
Good morning... I was trying to mockbuild a package for epel8 this morning,
and got an error message that seems to have to do less with my build and
more of (maybe?) a bigger problem:
Start: dnf update
No matches found for the following disable plugin patterns: local,
spacewalk, versionlock
CentOS Stream 8 - BaseOS
19 kB/s | 3.9 kB 00:00
CentOS Stream 8 - AppStream
1.9 kB/s | 4.4 kB 00:02
CentOS Stream 8 - AppStream
9.8 MB/s | 20 MB 00:02
CentOS Stream 8 - Extras
13 kB/s | 3.0 kB 00:00
CentOS Stream 8 - PowerTools
9.0 kB/s | 4.4 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64
20 kB/s | 4.7 kB 00:00
Error:
Problem: problem with installed package rpm-build-4.14.3-21.el8.x86_64
- cannot install the best update candidate for package
rpm-build-4.14.3-21.el8.x86_64
- nothing provides rpm = 4.14.3-22.el8 needed by
rpm-build-4.14.3-22.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to
use not only best candidate packages)
ERROR:
Exception(/home/farchord/build/lutris/lutris/lutris-0.5.9.1-4.el8.src.rpm)
Config(centos-stream+epel-8-x86_64) 0 minutes 11 seconds
INFO: Results and/or logs in:
/home/farchord/build/lutris/lutris/results_lutris/0.5.9.1/4.el8
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M 5bc8223ee6104692a8cb1c3aa3b2cf25 -D
/var/lib/mock/centos-stream+epel-8-x86_64-bootstrap/root -a
--capability=cap_ipc_lock --bind=/tmp/mock-resolv.e_p6y9ke:/etc/resolv.conf
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/centos-stream+epel-8-x86_64/root/installation-homedir
--setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
--setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007"
--setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8
--setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf --installroot
/var/lib/mock/centos-stream+epel-8-x86_64/root/ -y --releasever 8
--setopt=deltarpm=False --allowerasing --disableplugin=local
--disableplugin=spacewalk --disableplugin=versionlock update
--setopt=tsflags=nocontexts
Could not execute mockbuild: Failed to execute command.
Anyone know about this?
Thank you.
1 year
Packaging for EPEL9 question
by Steve Cossette
Hello,
So I am working on building for EPEL9 from fedora 35, but mock was
complaining it had no config file for epel9.
So I created a symlink:
epel-9-x86_64.cfg -> /etc/mock/centos-stream+epel-9-x86_64.cfg
I was looking in the doc files and couldn't find any documentation on this,
is this correct?
Thank you.
1 year
Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Sérgio Basto
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> The time had to come, when two packages would generate the same hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok <mhroncok(a)redhat.com>
> wrote:
> >
> > Hey,
> > apparently some ELF files are identical between Fedora's pypy3.7-
> > libs and
> > pypy3.8-libs packages.
> >
> > On Fedora 34, this leads to installation conflict:
> >
> > Error: Transaction test error:
> > file /usr/lib/.build-
> > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >
> > As reported in https://bugzilla.redhat.com/2053880
> >
> > I've read all the previous discussion about this on Fedora devel
> > list, but I
> > still have no idea what should I do to prevent this conflict.
> >
> > Moving the files to a common component seems like a bad idea given
> > it's not
> > "two packages bundle the same thing" but rather "two packages built
> > in a
> > different way".
> >
> > I see this:
> >
> > https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
> >
> > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> >
> > I suppose I could pass in %{NAME} as well, right?
> >
> > What are the side effects for changing the seed like this?:
> >
> > %global __debug_install_post \
> >
> > %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> > id%-seed%s+"',
> > rpm.expand('--build-id-seed "%{NAME}-')))}
> >
> >
> > Actually, should RPM pass %{NAME} by default? Or at least have a
> > macro I could
> > redefine in a less cryptic and fragile way?
> >
> > --
> > Miro Hrončok
> > --
> > Phone: +420777974800
> > IRC: mhroncok
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
1 year, 1 month
Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Miro Hrončok
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not
"two packages bundle the same thing" but rather "two packages built in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
redefine in a less cryptic and fragile way?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 1 month
Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Miro Hrončok
On 14. 02. 22 10:34, Michal Schorm wrote:
> The time had to come, when two packages would generate the same hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
That's because they both ship the same electron binary.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 year, 1 month
