V Fri, Jun 27, 2025 at 11:43:25AM +0200, Frederic Berat napsal(a):
> Hey all,
>
> While packaging the new Automake, I ran into something that got me
> thinking. A bug (since fixed in 1.18.1) made it try to rebuild the info
> documentation from its Texinfo sources, which implied a new BuildRequires
Hey all,
While packaging the new Automake, I ran into something that got me
thinking. A bug (since fixed in 1.18.1) made it try to rebuild the info
documentation from its Texinfo sources, which implied a new BuildRequires:
texinfo dependency on packages that depend on Automake.
This got me wonder
gt; > > Hi all,
> > > >
> > > > A tricky (for me) packaging question:
> > > > xkeyboard-config 2.45 upstream changed the installation directory to
> > > > make future multi-version installs possible. Traditionally files were
> > > > insta
V Sat, Jun 14, 2025 at 09:18:56AM +1000, Peter Hutterer napsal(a):
> On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote:
> > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a):
> > > Hi all,
> > >
> > > A tricky (for me) packaging q
On Sat, Jun 14, 2025 at 1:21 AM Peter Hutterer wrote:
>
> On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote:
> > V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a):
> > > Hi all,
> > >
> > > A tricky (for me) packaging question:
>
On Fri, Jun 13, 2025 at 10:05:32AM +0200, Petr Pisar wrote:
> V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a):
> > Hi all,
> >
> > A tricky (for me) packaging question:
> > xkeyboard-config 2.45 upstream changed the installation directory to
&g
V Fri, Jun 13, 2025 at 03:27:49PM +1000, Peter Hutterer napsal(a):
> Hi all,
>
> A tricky (for me) packaging question:
> xkeyboard-config 2.45 upstream changed the installation directory to
> make future multi-version installs possible. Traditionally files were
> installed in
Hi all,
A tricky (for me) packaging question:
xkeyboard-config 2.45 upstream changed the installation directory to
make future multi-version installs possible. Traditionally files were
installed in /usr/share/X11/xkb with an xkeyboard-config.pc pointing to
those files (though that path is also
On Thu, May 22, 2025 at 12:00:04PM -, Martin Gansser wrote:
> The second question concerns the listing of the individual files and the
> assignment of the SPDX license [2]
> in the rpm spec file.
>
> [2] https://martinkg.fedorapeople.org/ErrorReports/licensecheck_spdx.
Hi,
I am currently preparing a new version of the speed-dreams [3] package for
Fedora.
I have a question about the duplicate files [1] in the package, there are a lot
of them,
how should this be handled?
The second question concerns the listing of the individual files and the
assignment of
Hi,
I want to create the accel-ppp package and am having trouble adding
library versioning. CMake has a SOVERSION but that for some reason isn't
adding versioning.
I'm trying both the accel-pppd itself, didn't work. try each module
individually, fails on build:
CMake Error at CMakeLists.tx
r a status update. Should be the last
thing that needs to get sorted before I can be confident in submitting the
package.
And yes I am aware that pretty much all software has bugs, my question was
mainly about if severe usability bugs are problematic in this situation, I
believe it was issue #12
I
wanted kloak to be among the first packages I submit. I had a question first though, what is the tolerance for
buggy/beta software in Fedora? The project has a couple of notable open issues on Github, mainly
https://github.com/vmonaco/kloak/issues/12 and https://github.com/vmonaco/kloak/issues/
t. I had a question first though,
what is the tolerance for buggy/beta software in Fedora? The project has a
couple of notable open issues on Github, mainly
https://github.com/vmonaco/kloak/issues/12 and
https://github.com/vmonaco/kloak/issues/72. I have already successfully built
with mock and
On Sat, Feb 17, 2024 at 6:32 PM Orion Poplawski wrote:
> simdjson is failing to build with GCC 14 on x86_64:
>
> /usr/bin/cmake -S/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
> -B/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
> --check-build-system CMakeFiles/Makefile.cmake 0
simdjson is failing to build with GCC 14 on x86_64:
/usr/bin/cmake -S/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4
-B/home/tkloczko/rpmbuild/BUILD/simdjson-3.6.4/x86_64-redhat-linux-gnu
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/tkloczko/rpmbui
On Wed, Feb 14, 2024 at 5:55 PM Tom Hughes via devel
wrote:
>
> On 14/02/2024 15:48, Richard W.M. Jones wrote:
> > On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> >> On 14/02/2024 14:54, Richard W.M. Jones wrote:
> >>
> >>> https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
On 14/02/2024 15:48, Richard W.M. Jones wrote:
On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is th
On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> On 14/02/2024 14:54, Richard W.M. Jones wrote:
>
> >https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
> >
> >I don't think what Tom is saying there is correct, or is it?
>
> The answer is that I'm wrong about it breaking thin
On 14/02/2024 14:54, Richard W.M. Jones wrote:
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not t
https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
I don't think what Tom is saying there is correct, or is it?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder qu
Am Do., 7. Sept. 2023 um 14:02 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> I'm testing the upgrade to F39, and I see the following:
>
> Installing group/module packages:
> tlwg-waree-fontsnoarch 0.7.3-9.fc39 fedora
> 250.3 KiB
>replacing thai-scalable-fonts-comm
I'm testing the upgrade to F39, and I see the following:
Installing group/module packages:
tlwg-waree-fontsnoarch 0.7.3-9.fc39 fedora 250.3
KiB
replacing thai-scalable-fonts-common noarch 0.7.3-5.fc38 18.6
KiB
replacing thai-scalable-waree-fonts noarch
On Thu, 13 Jul 2023 at 21:45, Miao, Jun wrote:
> Hi Guys,
>
>
>
> AFAIK, the Yocto Project is an open source collaboration project that
> provides tools, templates, and methods to help developers create custom
> Linux-based systems for embedded devices.
>
>
>
> My confusion is that:
>
>1. wha
On Mon, 2023-07-17 at 02:58 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > This is the wrong question, kinda. There is no detailed step-by-step
> > process. The process for creating a compose is, more or less, "push the
> > magic COMPOSE NOW" butt
Adam Williamson wrote:
> This is the wrong question, kinda. There is no detailed step-by-step
> process. The process for creating a compose is, more or less, "push the
> magic COMPOSE NOW" button. (Okay, there's a *bit* more to it than that,
> but not a lot)
know where it
> could be found.
>
> Do you know of any such detailed documentation, step-by-step
> instructions, or maybe slides/presentations on the compose process or
> overall Fedora OS build systems?
This is the wrong question, kinda. There is no detailed step-by-step
process. Th
Am 16.07.23 um 21:24 schrieb Christopher:
On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
wrote:
Miao, Jun wrote:
Hi Guys,
First of all, we are not all guys. (I happen to be one though.)
I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specif
On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
wrote:
>
> Miao, Jun wrote:
> > Hi Guys,
>
> First of all, we are not all guys. (I happen to be one though.)
I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specific. In its plural form, it has basical
Miao, Jun wrote:
> Hi Guys,
First of all, we are not all guys. (I happen to be one though.)
> AFAIK, the Yocto Project is an open source collaboration project that
> provides tools, templates, and methods to help developers create custom
> Linux-based systems for embedded devices.
>
> My confusi
Hi Guys,
AFAIK, the Yocto Project is an open source collaboration project that provides
tools, templates, and methods to help developers create custom Linux-based
systems for embedded devices.
My confusion is that:
1. what`s the tool to make our Fedora Linux 38 released like Yocto?
2. An
On Wednesday, 05 April 2023 at 11:41, Sébastien Le Roux wrote:
[...]
> Now comes my question: some of these files seem to be configuration
> files, that the 'update-mime-database' simply updates, so I am not
> confident in saying that these should be installed by my RPM, it mig
Dear all,
I am working on my 'Atomes' package (non official yet) and I kindly ask
for your advise.
I have a question regarding my spec file:
https://github.com/Slookeur/Atomes-GNU/blob/main/atomes.spec
I recently figured out how to handle file associations and creating my
custom
Mattia Verga via devel wrote:
> ... I wonder why... AFAIK, GLES should be better for low resource
> systems like raspberry, isn't it?
Probably yes. KDE upstream recommends it for Plasma Mobile, and Manjaro ARM
builds a few qt5-es2-* packages (conflicting with the regular qt5-* ones)
for the comp
Il 03/12/22 19:01, Neal Gompa ha scritto:
>
> Good question, I don't know. Seems glvnd provides the libraries, maybe
> that's enough?
I had a look at mesa specfile, first it is build with
-Dgles1=disabled \
-Dgles2=enabled \
but then:
# XXX can we just not build this
version string: 4.60
> OpenGL context flags: (none)
> OpenGL profile mask: compatibility profile
>
> OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.2.3
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
>
Good question, I don't know. Seems glv
Il 03/12/22 16:29, Neal Gompa ha scritto:
> As far as I know, Qt can only be built with one mode or another. So
> it's a mutually exclusive choice. Also, it looks like we don't have
> the GLES libraries from Mesa at all to even make that choice. :(
So, why glxinfo on my system returns:
> OpenGL
On Sat, Dec 3, 2022 at 9:25 AM Mattia Verga via devel
wrote:
>
> While in the process of updating celestia package to the latest
> snapshot, I was trying to build it with qt interface and opengl_ES for
> rendering. But looking at the build logs of qt6-qtbase:
> OpenGL:
> Desktop OpenGL ..
While in the process of updating celestia package to the latest
snapshot, I was trying to build it with qt interface and opengl_ES for
rendering. But looking at the build logs of qt6-qtbase:
OpenGL:
Desktop OpenGL ... yes
OpenGL ES 2.0 no
Thanks to all respondents - an interesting discussion. I think I'm now
equipped to respond to upstream.
Bob
On Wed, 30 Nov 2022 at 08:15, Björn Persson wrote:
> Vitaly Zaitsev via devel wrote:
> > On 29/11/2022 17:33, Todd Zullinger wrote:
> > > One of reasons being that it's (at least slightly
Vitaly Zaitsev via devel wrote:
> On 29/11/2022 17:33, Todd Zullinger wrote:
> > One of reasons being that it's (at least slightly) easier to
> > notice a change to the public key / keyring when it's in
> > dist-git versus the lookaside cache
>
> It depends on public key format. Armored (ASCII f
On 29/11/2022 20:57, Neal Gompa wrote:
If they're ASCII armored format, then store them in Git, by all means.
Yep. The example[1] stores the keys in binary format. Missing --armor
option.
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_exceptions
--
Sincerely,
Vitaly Zait
On Tue, Nov 29, 2022 at 2:50 PM Vitaly Zaitsev via devel
wrote:
>
> On 29/11/2022 17:33, Todd Zullinger wrote:
> > One of reasons being that it's (at least slightly) easier to
> > notice a change to the public key / keyring when it's in
> > dist-git versus the lookaside cache
>
> It depends on pub
On Tue, Nov 29, 2022, at 3:24 AM, Bob Hepple wrote:
> Here's a question from one of my upstream devels. Not sure I understand
> exactly what he's asking but I thought I'd post here in the hope that
> someone can enlighten him (and me!).
>
> "... Arch supports
On 29/11/2022 17:33, Todd Zullinger wrote:
One of reasons being that it's (at least slightly) easier to
notice a change to the public key / keyring when it's in
dist-git versus the lookaside cache
It depends on public key format. Armored (ASCII format) vs. binary keys.
Storing binaries in Git
Vitaly Zaitsev via devel wrote:
> On 29/11/2022 09:24, Bob Hepple wrote:
>> "... Arch supports signed git tags. I'm hoping Fedora does too.
>
> On Fedora you must upload source tarball, its signature and public key to
> the Fedora look-aside cache
A minor expansion on that; the public key / upstr
On Tue, Nov 29, 2022 at 3:24 AM Bob Hepple wrote:
>
> Here's a question from one of my upstream devels. Not sure I understand
> exactly what he's asking but I thought I'd post here in the hope that someone
> can enlighten him (and me!).
>
> "... Arch suppo
On Tue, 29 Nov 2022 at 07:29, Björn Persson wrote:
>
> As to why the builders lack Internet access, I wasn't around when that
> was decided but it helps ensure that the source RPM packages actually
> contain the source code.
>
>
During the early days of packaging, there were a set of packages whi
Bob Hepple wrote:
> If we _do_ support "signed git tags" how do we code for it in the spec
> file?
As the builders lack Internet access, they can't pull directly from the
upstream Git repository. To verify a signed Git tag during the build,
it would be necessary to package up the whole Git reposit
Adding to what Vitaly has said:
The other question is where you get those signatures from. If upstream does not
sign tarballs any more then there is nothing to check, sadly.
In a source-git based workflow, or if you roll your own using rpkg or such, you
have the upstream source available so
On 29/11/2022 09:24, Bob Hepple wrote:
"... Arch supports signed git tags. I'm hoping Fedora does too.
On Fedora you must upload source tarball, its signature and public key
to the Fedora look-aside cache, because builders have no network access
for security reasons.
--
Sincerely,
Vitaly
Here's a question from one of my upstream devels. Not sure I understand
exactly what he's asking but I thought I'd post here in the hope that
someone can enlighten him (and me!).
"... Arch supports signed git tags. I'm hoping Fedora does too.
I'm thinking of droppin
On Sat, Nov 12, 2022 at 08:29:17PM -, Sergey Mende wrote:
> Hi,
> during development of my own project I hit the bug in `gdb` that is already
> fixed upstream but not backported to rawhide yet.
> I did a backport and ready to submit a PR. What is the right way to proceed:
>
> a) just file a
Thank you, Scott.
Regards,
Sergey
On Sun, Nov 13, 2022 at 6:04 AM Scott Talbert wrote:
> On Sat, 12 Nov 2022, Sergey Mende wrote:
>
> > Hi,
> > during development of my own project I hit the bug in `gdb` that is
> already fixed upstream but not backported to rawhide yet.
> > I did a backport an
On Sat, 12 Nov 2022, Sergey Mende wrote:
Hi,
during development of my own project I hit the bug in `gdb` that is already
fixed upstream but not backported to rawhide yet.
I did a backport and ready to submit a PR. What is the right way to proceed:
a) just file a PR;
b) open a bug in bugzilla,
Hi,
during development of my own project I hit the bug in `gdb` that is already
fixed upstream but not backported to rawhide yet.
I did a backport and ready to submit a PR. What is the right way to proceed:
a) just file a PR;
b) open a bug in bugzilla, submit a PR;
c) submit a PR, open a bug in
On 17-10-2022 12:19, Artur Frenszek-Iwicki wrote:
Would that imply I have to add the LGPL license text to the package
myself?
The packaging guidelines state that the desired course of action is
to contact upstream and ask them to provide the licence text.
https://docs.fedoraproject.org/en-US/pa
On Mon, Oct 17, 2022 at 12:10:26PM +0200, Sandro wrote:
> Hi,
>
> I'm currently updating brewtarget [0] which I recently adopted.
>
> For a handful of PNG files upstream has the following in their COPYRIGHT
> file: License: CC-BY-SA-3.0 or LGPL-3.0 [1].
>
> The text of the CC license is in the f
> Would that imply I have to add the LGPL license text to the package myself?
The packaging guidelines state that the desired course of action
is to contact upstream and ask them to provide the licence text.
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_tex
Hi,
I'm currently updating brewtarget [0] which I recently adopted.
For a handful of PNG files upstream has the following in their COPYRIGHT
file: License: CC-BY-SA-3.0 or LGPL-3.0 [1].
The text of the CC license is in the file, however the text of the LGPL
license is not, nor is it shipped
On Sun, Aug 21, 2022 at 5:21 PM Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:
> Since July 6, I've been seeing a lot of AVC's though I've not changed
> anything in my policies. Any ideas why?
>
> The majority seem to be device_t:sock_file write which implies to me that
> it's a
Since July 6, I've been seeing a lot of AVC's though I've not changed anything
in my policies. Any ideas why?
The majority seem to be device_t:sock_file write which implies to me that it's
a macro that's missing in the base policies.
[root@mail mail]# ausearch -m avc | audit2allow
#
That did it - thank you very much!
On 30/04/2022 23:26, Paweł Marciniak wrote:
I think you need
%pre -n
the same for
%preun %post %postun or all systemd macros will not work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
I think you need
%pre -n
the same for
%preun %post %postun or all systemd macros will not work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://d
Hi all,
I am working on chasing down an issue in preparing a package for review:
The package should create a user and group as part of its installation
and I have attempted to implement this following the instructions/docs
at https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroup
On 2/28/22 16:32, Richard W.M. Jones wrote:
On Mon, Feb 28, 2022 at 04:26:02PM +0200, Panu Matilainen wrote:
On 2/28/22 16:12, Richard W.M. Jones wrote:
On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
I'm writing a simple provides generator. The documentation is a bit
lig
* Panu Matilainen:
> On 2/28/22 16:12, Richard W.M. Jones wrote:
>> On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
>>>
>>> I'm writing a simple provides generator. The documentation is a bit
>>> light on detail:
>>>
>>>
>>> https://rpm-software-management.github.io/rpm/ma
On Mon, Feb 28, 2022 at 04:26:02PM +0200, Panu Matilainen wrote:
> On 2/28/22 16:12, Richard W.M. Jones wrote:
> >On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
> >>
> >>I'm writing a simple provides generator. The documentation is a bit
> >>light on detail:
> >>
> >>
> >>
On 2/28/22 16:12, Richard W.M. Jones wrote:
On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
I'm writing a simple provides generator. The documentation is a bit
light on detail:
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
How do I ge
On Mon, Feb 28, 2022 at 01:46:38PM +, Richard W.M. Jones wrote:
>
> I'm writing a simple provides generator. The documentation is a bit
> light on detail:
>
>
> https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
>
> How do I get the version-release of the pac
I'm writing a simple provides generator. The documentation is a bit
light on detail:
https://rpm-software-management.github.io/rpm/manual/dependency_generators.html
How do I get the version-release of the package currently being built?
At the moment I can only print simple provides like:
:
Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :
> Hello, I have a question about Fedora Package Naming.
>
> php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version
> by upstream. The latest version is 7.4.1.
> https://src.fedoraproject.org/rpms/p
Le 19/02/2022 à 13:58, Hirotaka Wakabayashi via devel a écrit :
Hello, I have a question about Fedora Package Naming.
php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version
by upstream. The latest version is 7.4.1.
https://src.fedoraproject.org/rpms/php-guzzlehttp-g
n package
like php-guzzlehttp-guzlle.
Regrads,
Hirotaka
On Saturday, February 19, 2022, 10:13:20 PM GMT+9, Neal Gompa
wrote:
On Sat, Feb 19, 2022 at 7:59 AM Hirotaka Wakabayashi via devel
wrote:
>
> Hello, I have a question about Fedora Package Naming.
>
> php-guzzlehtt
On Sat, Feb 19, 2022 at 7:59 AM Hirotaka Wakabayashi via devel
wrote:
>
> Hello, I have a question about Fedora Package Naming.
>
> php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version by
> upstream. The latest version is 7.4.1.
> https://src.fed
Hello, I have a question about Fedora Package Naming.
php-guzzlehttp-guzzle's version is 5.3.4, which is already EOL version by
upstream. The latest version is 7.4.1.
https://src.fedoraproject.org/rpms/php-guzzlehttp-guzzlehttps://github.com/guzzle/guzzle#version-guidance
In this situation,
Am 25.01.22 um 21:22 schrieb Miro Hrončok:
If I assume correctlty that both python-augeas and python-boto3 are in RHEL
7,
yes.
this exception applies:
"""
>
The package exists in both Fedora and RHEL, but the packager wants to
ship it in EPEL under an alternative name (as required by EPEL
On 25. 01. 22 21:05, Felix Schwarz wrote:
Hi,
(I sent this to epel-devel but did not get any reply there so maybe
fedora-devel is a better place for this question even though this is about EPEL
packages?)
the packaging guidelines have a few excemptions for the package review process
[1
Hi,
(I sent this to epel-devel but did not get any reply there so maybe fedora-devel
is a better place for this question even though this is about EPEL packages?)
the packaging guidelines have a few excemptions for the package review process
[1]. I'm working on updating certbot to Pyt
ched screenshot, all the icons are missing, and have been replaced
with question marks. I wonder if this could be caused by some Fedora libraries that have
not yet been rebuilt using GCC-12. I don't know if it is possible to "mix and
match" things previously compiled with GCC-11
the icons are missing, and have been
> replaced with question marks. I wonder if this could be caused by some
> Fedora libraries that have not yet been rebuilt using GCC-12. I don't know
> if it is possible to "mix and match" things previously compiled with GCC-11
>
regardless of arch
These are unrelated. The typical example of arch specific package
without debuginfo is "filesystem". There is no arch specific code, but
arch specific content.
- Would lib/amdgcn would be ok if it's noarch?
Probably?
- is this a fesco worthy question?
I created a new review request, hopefully that encourages some conversation on
the topic :)
https://bugzilla.redhat.com/show_bug.cgi?id=2044664
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fed
automatically make it a noarch
package? I don't think bitcode would generate debug information regardless of
arch
- Would lib/amdgcn would be ok if it's noarch?
- is this a fesco worthy question?
Thanks!___
devel mailing list -- devel
I've been able to rebuild KiCad using the new gcc-12.0.1-0.2 compiler rpms on
Rawhide via mock. While KiCad compiles, it doesn't quite run correctly.
As shown in the attached screenshot, all the icons are missing, and have been replaced
with question marks. I wonder if this could
> So far there has been no action on the bug to get it reviewed.
> Does it usually take a while to get the review started?
Well, the thing is - there isn't really anyone obliged to review package
submissions.
Almost every single review is done by volunteers, using their free time.
> Do I need to
I am working on getting the xtrkcad program into fedora. Using
https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_Existing_Contributors/
I have gotten to the point of creating a bug (2040728) for a new package review.
I am not sure how the process works going forwar
JT wrote on 2021/12/28 23:22:
I didn't find the BT that helpful... Although it's possible I've completely
forgotten everything I previously knew about gdb and I need to relearn
everything from the ground up.
I'm perplexed by the BT because the first of the steps it shows on the way
to the segfaul
I didn't find the BT that helpful... Although it's possible I've completely
forgotten everything I previously knew about gdb and I need to relearn
everything from the ground up.
I'm perplexed by the BT because the first of the steps it shows on the way
to the segfault is for main.cpp:79.
> (gdb) b
Is the backtrace not helpful in figuring out where to set up
breakpoints? As in, “gdb foo”, then “run”, wait for the crash, and type
“bt”?
The darktable development documentation suggests[1] the following to log
useful backtraces:
|$ gdb darktable ... crash dt here ... (gdb) set paginatio
Hey all,
I havent used gdb in a while, so I'm trying to knock the rust off my
knowledge and pick up a few more skills.
I'm trying to track down an issue in the Lumina Desktop. One of the
utilities (lumina-screenshot) segfaults when starting up and I'm trying to
deduce why. The problem is that it g
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 w
Sergio Belkin wrote:
> Do you think that (Linux) Software RAID is still relevant in this "breve
> new world" of cloud/devops ?
There are still some people who don't want some cloud to live their
life for them. If anything would make software RAID irrelevant, it
would be ZFS and BTRFS, not clouds o
Dne 01. 12. 21 v 22:32 Sergio Belkin napsal(a):
Hi community,
Sorry for the OT.
I'd like to know your opinion based on current facts :)
Do you think that (Linux) Software RAID is still relevant in this "breve new
world" of cloud/devops ?
Thanks for your opinions :)
Yes! I do not even want to
On Mon, Nov 29, 2021 at 03:15:24PM -0500, Matthew Miller wrote:
> shown that the answer is "probably not, actually". And it's _really
> hard_ for me to go to Red Hat and say "hey, um, I know you're paying
> for this Gitlab contract we can use, but can you please do this huge
> project, with ongoing
Sergio Belkin wrote:
> Do you think that (Linux) Software RAID is still relevant in this "breve
> new world" of cloud/devops ?
Yes! It is *the* solution for desktop computers to be safe from data loss
due to disk failures.
Kevin Kofler
___
deve
On 12/1/21 13:32, Sergio Belkin wrote:
Sorry for the OT.
This is probably a question better suited for the users@ list than devel@.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Hi community,
Sorry for the OT.
I'd like to know your opinion based on current facts :)
Do you think that (Linux) Software RAID is still relevant in this "breve
new world" of cloud/devops ?
Thanks for your opinions :)
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
* Daniel P. Berrangé:
> We do much the same in libvirt
>
> https://github.com/libvirt/libvirt-python/pull/4#issuecomment-662443409
>
> FWIW, there's no need to write a bot to achieve this - there's a
> a github action:
>
> https://github.com/apps/repo-lockdown
>
> you can simply enable for you
On Wed, Dec 01, 2021 at 11:40:43AM -0500, Matthew Miller wrote:
> On Wed, Dec 01, 2021 at 01:20:53PM +, Daniel P. Berrangé wrote:
> > Note the GNOME auto-closer provides a comment telling the user that the
> > primary repo is on gitlab and pointing them to where it is. Logging
>
>
> How hard
1 - 100 of 1106 matches
Mail list logo
