Hi Oliver! Welcome!
--
___
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 Guidelines:
I am resuming this discussion because today I was about to run such
command on another machine and in the preview of packages that would
have been removed there were important packages like:
- firefox
- ffmpeg
- libreoffice suite
and many others. It's a pretty destructive behaviour for such
A long time ago upstream keepassxc obsoleted upstream keepassx.
I now added obsoletes/provides [1] to the former spec file, following
Fedora packaging guidelines [2] and I would like to ask for your
feedback about the correctness of the commit.
Thank you
[1]:
Il 30/03/24 23:12, Sandro ha scritto:
From what I understood, F40 Beta, the official Beta release, available
from the website as of March 26, has updates-testing disabled by
default. That was confirmed by several people in #devel yesterday when
the Fedora Magazine article was still being
regarding sabotaged Landlock sandbox
https://mastodon.social/@dander...@hachyderm.io/112185746170709381
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
It would be interesting to study how SELinux would have reacted to such
kind of attack against sshd
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I recently updated to F40 KDE, but Jami software [1] bundled Qt6 RPM
package messed up with system Qt6 (see later fix at [2]), so I had to run:
# dnf autoremove
# dnf reinstall $(rpm -qa)
I have noticed an aggressive packaging removal behaviour from "dnf
autoremove", indeed it removed various
I hope this is the last time I have to deal with minizip invasive
changes (both upstream and downstream).
With the new keepassxc release, I had to test it against all minizip*
packages on all active branches
What does it mean that FESCo is applying an injunction?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
22/06/23 11:06, Matthew Miller wrote:
On Thu, Jun 22, 2023 at 08:44:13AM -, Michael J Gruber wrote:
In the specific case of RHEL srpms, it makes life harder for EPEL
packagers because you can't look at the source easily when they are
problems between RHEL and EPEL packages. It matches well
As I wrote in
https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c11
I did not know that epel packages are used also in CentOS Stream,
sometimes causing issues like the one previously mentioned.
In fact this behaviour obliges epel maintainers that wanted to maintain
RHEL only, to work to
There hasn't been a qt update in CentOS Stream 8 or 9 since May 2022,
so you'll have to give more information.
I double checked and I found out the origin of my misunderstanding. I
wrote everything in this comment
https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c8
any update on this matter? A few days ago I got another bugreport
concerning CentOS Stream Qt update breaking an application
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to
A colleague suggested me to use
http://elrepo.org/tiki/kernel-ml
so I no longer need help for the Copr build.
Best regards
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to
Good day,
on Fedora Copr I am trying to build kernel 4.x [1] for EL7.
The problem is that the build [2] fails on "No Package found for
llvm-toolset-7.0"
I checked the srpm and devtoolset for llvm are present and also enabled
(line 1110), so I really wonder what is wrong.
Thank you for
Il 29/04/22 21:42, Troy Dawson ha scritto:
On Fri, Apr 29, 2022 at 11:28 AM Germano Massullo
wrote:
Recent CentOS Stream Qt update broke some EPEL packages like
keepassxc
that needed a rebuild against the new Qt version.
Can we talk about a way to prevent this from happening
Recent CentOS Stream Qt update broke some EPEL packages like keepassxc
that needed a rebuild against the new Qt version.
Can we talk about a way to prevent this from happening again?
Best regards
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2077742
Hello, in my opinion we should add to Fedora Packaging Guidelines, a
paragraph concerning GCC Toolset usage.
I recently experienced some problems in building darktable for
epel8/epel8-next due bad configuration of gcc-toolset-11 in the spec
file. In a few words, gcc-toolset-11 was not really
I confirm Dan's analysis. Problem solved. All details at
https://bugzilla.redhat.com/show_bug.cgi?id=2074663#c7
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Il 12/04/22 20:59, Dan Horák ha scritto:
On Tue, 12 Apr 2022 18:20:25 +0200
Germano Massullo wrote:
Hello, a new kind of failure is happening, still on same package and CPU
arch
https://koji.fedoraproject.org/koji/taskinfo?taskID=85563318
Maybe an OpenMP bug?
so now it chokes on inlined
Hello, a new kind of failure is happening, still on same package and CPU
arch
https://koji.fedoraproject.org/koji/taskinfo?taskID=85563318
Maybe an OpenMP bug?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Thank you very much Mamoru! Why don't you submit your patch to upstream
repository, so you get the credit? We will need to patch such thing
upstream anyways!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Hello, on Fedora > 35 I am experiencing build failures on boinc-client
on non x86 architectures. I do not understand the reason
https://koji.fedoraproject.org/koji/taskinfo?taskID=85413241
F35 instead builds correctly
https://koji.fedoraproject.org/koji/taskinfo?taskID=85413347
Thank you
All these are somehow related to Steam and x86 32 bit games
# rpm -qa | grep 686 | sort
alsa-lib-1.2.6.1-3.fc35.i686
atk-2.36.0-4.fc35.i686
at-spi2-atk-2.38.0-3.fc35.i686
at-spi2-atk-debuginfo-2.38.0-3.fc35.i686
at-spi2-atk-debugsource-2.38.0-3.fc35.i686
at-spi2-core-2.42.0-1.fc35.i686
Il 24/02/22 00:25, Germano Massullo ha scritto:
This problem should have been fixed with commit
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d4367f8f815bb9
after checking which Qt version includes such commit, I will remove
xcb.patch [1] and release a new
This problem should have been fixed with commit
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=dda7dab8274991e4a61a97c352d4367f8f815bb9
after checking which Qt version includes such commit, I will remove
xcb.patch [1] and release a new keepassxc release to test its behaviour
[1]:
After having dealt for the n-th time with libvirt dependencies messing
up [1] with zfs packages installed from ZFS On Linux repository, I
wondered if we could just include them in Fedora repository.
They are not in the Fedora Forbidden Items [2] list.
Fedora Wiki ZFS page [3] says:
"Fedora
Il 10/01/22 00:30, Germano Massullo ha scritto:
Thank you, and what about EPEL8 build failure? Such branch is not
affected by that bug
https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476
Thank you
new darktable release build failure on EL8 ppc64le
https://koji.fedoraproject.org/koji
the problem was fedora-review not properly supporting tmpfs.
All infos in the bugreport
Best regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hello, a month ago I opened a bugreport against fedora-review
https://bugzilla.redhat.com/show_bug.cgi?id=2038828
Today I tried to clean up mock build with various command, and at the
end I also tried to delete the content of folder /var/lib/mock/ but I am
still experiencing the problem.
Since
Thank you everybody for your suggestions!
___
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/
Good day. I have to search gcc-toolset among all Fedora packages specs
files, in order to read some example of usage.
Is that possible? For example cloning the whole git repository.
Best regards
___
devel mailing list -- devel@lists.fedoraproject.org
Thank you, and what about EPEL8 build failure? Such branch is not
affected by that bug
https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476
Thank you
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Good day. darktable maintainer here.
I am experiencing a ppc64le build failure on F34 and EPEL8, EPEL8-next only.
https://koji.fedoraproject.org/koji/taskinfo?taskID=81021540
https://koji.fedoraproject.org/koji/taskinfo?taskID=81021476
On F34 the error is
Il giorno gio 2 dic 2021 alle ore 12:20 Björn Persson
ha scritto:
> But the licensing situation makes ZFS painful, and BTRFS seems to take
> forever to mature, so it should be expected that many people will choose
> software RAID
No The. ZFS licensing problems you mentioned have nothing to do
I apologize, previous message was not meant to be sent on the mailing list
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Moreover it does not even compile on Fedora
https://kojipkgs.fedoraproject.org//work/tasks/7311/71287311/mock_output.log
file /usr/lib64/python3.10/site-packages/imath.so conflicts between
attempted installs of python3-openexr-2.5.5-2.fc35.x86_64 and
python3-imath-3.0.2-4.fc35.x86_64 file
I maintain one single spec file for all branches (Fedora + EPEL) by
using spec file macros.
The majority of times a proven packager offers his help on packages I
maintain, he breaks the EPEL branch.
Proven packagers, if you see macros of EPEL branches could you please
take care of testing them
I opened ticket "revert Qt Wayland By Default On Gnome"
https://bugzilla.redhat.com/show_bug.cgi?id=1965539
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Il 01/05/21 21:01, Jan Grulich ha scritto:
> Hi,
>
> pá 30. 4. 2021 v 12:30 odesílatel Germano Massullo
> mailto:germano.massu...@gmail.com>> napsal:
>
> KeepassXC comaintainer here.
>
> There are many Fedora GNOME Wayland users experiencing quirks in
&g
Il 01/05/21 12:40, Vitaly Zaitsev via devel ha scritto:
> On 01.05.2021 11:44, Germano Massullo wrote:
>> Let's wait also for Jan Grulich. He should be back next days/weeks
>
> Yes, but my simple workaround works fine. We need to add a new method:
>
> ```c++
>
Il 01/05/21 20:41, Samuel Sieb ha scritto:
> On 2021-05-01 2:42 a.m., Germano Massullo wrote:
>> Il 30/04/21 18:33, Kevin Fenzi ha scritto:
>>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote:
>>>> After running
>>>> dnf system-upgrade dow
Il 01/05/21 19:49, Kevin Fenzi ha scritto:
> On Sat, May 01, 2021 at 11:42:52AM +0200, Germano Massullo wrote:
>> Il 30/04/21 18:33, Kevin Fenzi ha scritto:
>>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote:
>>>> After running
>>>> d
Il 01/05/21 12:56, Germano Massullo ha scritto:
> Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto:
>> On 30.04.2021 16:09, Germano Massullo wrote:
>>> Could you please suggest me how I could implement a patch?
>> https://src.fedoraproject.org/rpms/ksnip/blob
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto:
> On 30.04.2021 16:09, Germano Massullo wrote:
>> Could you please suggest me how I could implement a patch?
>
> https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch
>
I have
Il 30/04/21 19:11, Vitaly Zaitsev via devel ha scritto:
> On 30.04.2021 16:09, Germano Massullo wrote:
>> Could you please suggest me how I could implement a patch?
>
> https://src.fedoraproject.org/rpms/ksnip/blob/rawhide/f/ksnip-wayland-workaround.patch
>
>
>> Woul
Il 30/04/21 18:33, Kevin Fenzi ha scritto:
> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote:
>> After running
>> dnf system-upgrade download --releasever=34
>> and downloading all files, I got the following warning
>> warning:
>> /
Il 30/04/21 16:23, Hans de Goede ha scritto:
> I tend to agree, it seems this downstream patch breaks at least 3 apps:
>
> 1. KeepassXC
> 2. calibre
> 3. audacious
I think also nextcloud-client. I have been receiving bugreports about
quirks on GNOME
___
Il 30/04/21 15:33, Vitaly Zaitsev via devel ha scritto:
> On 30.04.2021 12:23, Germano Massullo wrote:
>> There are many Fedora GNOME Wayland users experiencing quirks in
>> using KeepassXC. Textboxes not showing text that is being written,
>> other quirks with GNOME, etc
After running
dnf system-upgrade download --releasever=34
and downloading all files, I got the following warning
warning:
/var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm:
Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY
Why this package does not
Il 30/04/21 14:11, Robert Marcano via devel ha scritto:
> The bug about input fields not able to take text input happen
> occasionally on passwords fields on XCA.
What is XCA?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
KeepassXC comaintainer here.
There are many Fedora GNOME Wayland users experiencing quirks in using
KeepassXC. Textboxes not showing text that is being written, other
quirks with GNOME, etc.
Upstream developers said many times that this only happen with Fedora users.
Myself I do use KDE Spin
Done!
Review Request: memleax - Debugs memory leak of a running process -
https://bugzilla.redhat.com/1946499
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Il 04/04/21 23:55, Ian McInerney ha scritto:
>
> On Sun, 4 Apr 2021, 21:53 Germano Massullo,
> mailto:germano.massu...@gmail.com>> wrote:
>
> Good day, I am creating a spec file [0] for memleax memory leaks
> analyzer [1], but during build [2] I am getti
Good day, I am creating a spec file [0] for memleax memory leaks
analyzer [1], but during build [2] I am getting error "invalid option:
--build=x86_64-redhat-linux-gnu.". Where can be the problem?
Thank you
[0]: https://pagure.io/memleax/blob/master/f/memleax.spec
[1]:
Il 09/02/21 19:06, Gwyn Ciesla via devel ha scritto:
> I'll take care of it.
Thank you!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Can anybody please help updating Audacity package? I cannot help this
time. Despite this package has 2 maintainers, the software is no
up-to-date and is highly unstable and crashes every time you use it
https://bugzilla.redhat.com/show_bug.cgi?id=1836497
Also this build seems to be related to this problem
https://koji.fedoraproject.org/koji/taskinfo?taskID=61482059
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Il giorno dom 31 gen 2021 alle ore 01:38 Robert-André Mauchin
ha scritto:
> It seems out of tree builds are not supported by the build script.
> Just copy the xpi to the build directory to make it work:
>
> cp -a *.xpi %{_vpath_builddir}/
>
> (after the %cmake call)
Thank you, it worked!
apcupsd package has been fixed by Jason L Tibbitts III
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I tried fixing apcupsd and firefox-pkcs11-loader that started to fail
after introduction of "CMake to do out-of-source builds", but I got some
errors about missing files, that is strange since package structure has
not changed, it's the same that built successfully on older Fedora
branches
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. It generates Requires for those dependencies
> automatically; see /usr/lib/rpm/find-requires. So the keepassxc
>
I am one of the keepassxc maintainers. Bugreport
"Missing dependency: qt5-qtsvg libQt5Svg.so.5"
https://bugzilla.redhat.com/show_bug.cgi?id=1911210
made me wonder about the following thing:
I just installed a basic Fedora server to do a test concerning keepassxc
libs. Keepassxc spec file [1]
ganglia EPEL 7 successfully builds on mock and copr [1] but fails on
koji [2], complaining about a missing close in a %if block. By seeing
the spec file I don't see any missing closure in the block, and I don't
understand this different behaviour between copr and koji
What do you think about?
https://pagure.io/irc-support-sig/issue/200
___
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/
Il 06/09/20 23:03, Kevin Fenzi ha scritto:
> On Sat, Sep 05, 2020 at 12:54:34AM +0200, Germano Massullo wrote:
>> Il 19/07/20 19:41, Kevin Fenzi ha scritto:
>>> On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote:
>>>> Is it necessary to have in #fedora I
Il 26/09/20 03:03, Luya Tshimbalanga ha scritto:
>
> On 2020-09-25 12:53 p.m., Germano Massullo wrote:
>> I apologize, this happened because F33 was branched in the same days I
>> was building darktable. I must have missed the announcement.
>> Anyways for any problem re
I apologize, this happened because F33 was branched in the same days I
was building darktable. I must have missed the announcement.
Anyways for any problem related to a package users should leave a
comment on bugzilla rather than the mailing list
___
Il 19/07/20 19:41, Kevin Fenzi ha scritto:
> On Fri, Jul 17, 2020 at 05:34:13PM +0200, Germano Massullo wrote:
>> Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times
>> per day about Fedora respins update?
>>
>> [16:51] *** F32-20200715 update
I solved the previous error about macros expanded in comments, and now
the build fails for other strange reasons.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/
By the way by commenting my patch on spec file, the kernel builds
successfully
I think soon we will have a big boost in Koji performances thanks to
Giuliano Belinassi and his work on addressing GCC parallelization
bottlenecks. According to Phoronix, compiling individual files in
parallel may have up to ~1.9x speedup:
I solved the previous error about macros expanded in comments, and now
the build fails for other strange reasons.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1616496/
By the way by commenting my patch on spec file, the kernel builds
successfully
Il 18/08/20 09:40, Fabio Valentini ha scritto:
> On Tue, Aug 18, 2020, 02:15 Laura Abbott <mailto:la...@labbott.name>> wrote:
>
> On 8/17/20 7:36 PM, Germano Massullo wrote:
> > Hi there, I would need help in understanding why this kernel
> build failed.
>
Hi there, I would need help in understanding why this kernel build failed.
https://copr.fedorainfracloud.org/coprs/germano/kernel_204253_comment_14_patch/build/1613735/
The SRPM is the same of Fedora repository except for a small patch file
that I have added to run some tests against blk-mq
All desktop oriented Fedora installers install on the system packages:
hunspell
hunspell-en
hunspell-en-GB
hunspell-en-US
When a user opens the language list of the spell checker, is has ~24
different English options, like English (Antigua and Barbuda), English
(Australia), English (Bahamas),
Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times
per day about Fedora respins update?
[16:51] *** F32-20200715 updated lives available:
https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more
info #fedora-respins ***
Good day, package "apcupsd" (client for APC Uninterruptible Power Supply) is
now available on EPEL 8.
So if you own such UPS and an Enterprise Linux 8 workstation you can enjoy
using this service.
Best regards
___
epel-devel mailing list --
Good day, BOINC Text User Interface is now available on EPEL 7 and 8, so
you can better manage BOINC client on headless systems.
Just install boinc-tui package and enjoy!
P.S. you may want to join BOINC volunteers to help scientific research
against COVID19. More informations at
Hi Stefano, welcome among Fedora contributors!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hello, in comment
https://bugzilla.redhat.com/show_bug.cgi?id=1767576#c7
I wrote my experience about fedora-review / mock bug that returns message
%{python3_pkgversion} expanded too early.
As workaround I renamed
python3-dateutil-2.8.0-2.fc30.src.rpm
to
pythonX-dateutil-2.8.0-2.fc30.src.rpm
but
Welcome and thank you for your future contributions!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Il dom 6 ott 2019, 10:09 Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> ha scritto:
> On 06.10.2019 09:08, Germano Massullo wrote:
> > I would like to package OnlyOffice Desktop Editors [1]
>
> Packaging of Electron is not allowed:
> https://fedorap
I would like to package OnlyOffice Desktop Editors [1], but since it
is the first time I see a Github tree very particular like this one, I
don't know what effort would be required for packaging.
What do you think about?
[1]: https://github.com/ONLYOFFICE/DesktopEditors
Hello, BOINC client maintainer here.
I made a new package version containing a patch. When I run BOINC
client as system service, I will get crash errors on journalctl,
errors like
boinc[2543]: /usr/bin/boinc(+0x8b894)[0x5572ee5ac894].
By the way there are not symbols, like it does not care about
Il giorno mar 4 giu 2019 alle ore 19:00 Björn Persson
ha scritto:
I'll be surprised if you can do that
> to another user's session without help from some privileged service.
That is a very good question, thank you for pointing it out. I will let you know
Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson
ha scritto:
> So the question isn't what desktop the user is using, but rather what
> desktops, if any, other users on the machine are using.
Well when I started the thread I had not thought that BOINC client
service is running on a confined
A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service
with its own user, I don't think it will be able to read
XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I
need another kind of solution
___
devel mailing list --
Il giorno mer 29 mag 2019 alle ore 22:12 Stephen Gallagher
ha scritto:
>
> On Wed, May 29, 2019 at 1:16 PM Kalev Lember wrote:
> I realize you said that the reasons are off-topic, but in general I'd
> recommend not making desktop-specific decisions at a high-level
I need to retrieve user idle
I am working on implementing a piece of code that allows BOINC client
[1] to detect the desktop environment used by the user (mainly GNOME,
KDE Plasma, XFCE, LXDE/LXQT).
This feature will be needed for various reason that are off topic.
One idea is to use GDBus to scan DBus to detect the running
Hi Radka, could you please try using a new ~/.config/Nextcloud/ folder
and see if this happens again?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hello, I need some testers for getting karma feedbacks about
nextcloud-client 2.5.2 that is in updates-testing
https://bodhi.fedoraproject.org/updates/?packages=nextcloud-client
Thank you
___
devel mailing list -- devel@lists.fedoraproject.org
To
Joe, I found a machine on which I can reproduce the problem. I installed
wireguard-dkms-0.0.20190123-2.fc29.noarch
on top of
wireguard-dkms-0.0.20190123-1.fc29.noarch
but the machine while running
# dkms autoinstall
still returns
Error! Could not locate dkms.conf file.
File:
Il giorno gio 31 gen 2019, 00:15 Joe Doss ha scritto:
> Hey Germano,
>
> I have a working RPM that does not error out with Error! Could not locate
> dkms.conf file if you want to test it out before I push it to copr.
>
Hi Joe, I can test it on next Wireguard snapshot release, actually I cannot
Thank you Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
Il giorno mar 29 gen 2019 alle ore 17:39 Nicolas Chauvet
ha scritto:
> There is a wireguard package maintained by Robert-André Mauchin on RPM
> Fusion that at least... works.
Ah I did not know that, thank you
___
devel mailing list --
This [1] is the Wireguard spec file from upstream Copr repo [2].
Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms.
The only problem is that at every Wireguard upgrade, a manual action
is required.
For example now that I have installed 0.0.20190123, I have to remove
Ok now everything it is clear. Thank you very much to everybody
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
I reply to your message in the bottom part, just let me explain how I got this
situation, because my previous message lacked of informations.
I have built and installed a new BOINC release with a systemd unit file patch,
and I have noticed that the service behaviour has not changed.
Therefore I
Andreas Schneider [1] that is aware of Fedora community work on packaging ROCm
stack, showed me his pending pull request [2] that
"cleans up cmake so that the library can be correctly packaged for
distributions. It also cleans up cmake as there are several things which should
not be done in
Hello, I am testing various changes in boinc-client systemd unit file.
At every RPM package update, it happens really often that on a machine
that installs the new RPM version, does not get the new systemd unit
file version, so it is not updated. To successfully update the file, I
have to remove
1 - 100 of 252 matches
Mail list logo
