> "dnf repoquery --srpm --whatrequires kiss-fft-static" returns nothing,
That's because there's no "kiss-fft-static" package, only "kiss-fft-devel".
Running "dnf repoquery --releasever=39 --disablerepo='*'
--enablerepo='*-source' --whatrequires kiss-fft-devel" gives me:
- ckb-next-0:0.5.0-4.fc39.
> Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase
> ORs.
Yea. I've been reading through the spec lately, since I want to add proper SPDX
support to my project,
and it says joiners should be uppercase and parsers should match
case-sensitively.
> License expression o
> What is the simplest way to get a rawhide i686 VM?
I think that's no longer possible, as it's been many years since Fedora stopped
shipping i686 kernels.
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
I guess you could try creating a VM with some other distro, like Debian, an
> I've taken ownership of libreoffice for the time being, at least to keep the
> lights
> on. Co-maintainers, as always, welcome.
Don't know how much time I'll be able to contribute, but you can count me in.
As Mattia suggested, I think it might be a good idea to set up libreoffice-sig.
A.FI.
__
> FTBFS:
> easyrpg-player
Upstream has already updated the program to work with fmt10,
so I just applied the relevant commit to the Fedora package.
Submitted and rebuilt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102705429
A.FI.
___
devel mai
Any more details?
Anything interesting inside /var/log/lightdm?
A.FI.
___
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-U
Hey all,
I've been maintaining the Free Pascal Compiler [0] in Fedora for some time now.
A couple of times I played around with the idea of building and packaging FPC
cross-compilers. Lately I gave it another go and arrived and some quite
workable results. If you're interested, you can check them
> b) Instead of using the default config file, ship a custom one that makes
>the compiler always look in /usr/lib64/ on 64-bit arches
>and /usr/lib/ on 32-bit arches.
I took another look into this and contrary to what I wrote in my previous
message, it turns out we *do* already ship a custo
Hey all,
colorful had a new major release, v2.0, which brought in a licensing change.
I took this as an opportunity to also migrate the License: tags to SPDX.
Old v1.3 license: zlib with acknowledgement
New v2.0 licenses:
- colorful: GPL-3.0-only AND (MPL-2.0 OR Zlib)
- colorful-data: zlib-ackno
> eurekaorphan 2 weeks ago
I have a soft spot for classic DOOM, so I took this one.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fed
fpc (the Free Pascal Compiler) also ships with units for developing stuff
with gtk1 - so should we retire gtk+, we'll probably want to patch fpc
so said units are not shipped.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe s
> So you can do
> $ eval `rpm -E '%set_build_flags'`
> in a script to set the flags that RPM uses.
Another solution could be something like:
$ gcc $(rpm -E '%optflags') ... $(rpm -E '%build_ldflags')
A.FI.
___
devel mailing list -- devel@lists.fedorapro
> At least in my workflow, I only do scratch builds before pushing,
> to ensure that what I am about to push builds correctly in Koji.
Same here. Some of my packages are prone to break and in need
of patching on non-x86_64, so that's my main use case as well.
Never used "fedpkg scratch-build" sinc
Haven't planned on this originally, but it seems like a good idea.
Never really used Obsoletes before, so I have to ask:
what's the dnf behaviour when a package is obsoleted by multiple packages?
If it tries to install all of them, then that'd be okay. I'd like to
avoid a situation where dnf decid
So I'm sure this question has been asked during previous Mass Rebuilds,
but I can't find the answer in the heaps of messages in my mailbox,
so I'll ask again: if my package failed to build during the Mass Rebuild
and I know how to fix it - I don't have to wait for the rebuilt to end,
right? I can j
I wanted to resubmit one of my failed builds, but the buildroot seems to be
broken currently:
> Problem 1: package python3-dnf-4.14.0-2.fc38.noarch requires libmodulemd >=
> 2.9.3, but none of the providers can be installed
> - package libmodulemd-2.14.0-5.fc38.x86_64 requires
> libglib-2.0.so
> cqrlog - Fails for some weird lazbuild issue I don't understand
This is most likely my fault, since Lazarus seems to be quite tightly coupled
to specific FPC versions.
Historically, whenever we updated/rebuilt FPC, we'd also rebuilt Lazarus. This
time, when I rebuilt
FPC as part of the repackag
fpc has a Requires: on the units package, so it should always be installed.
The build failures for packages using FPC, as far as I can see, are all packages
using Lazarus. As far as I can tell, this is because Lazarus seems to quite
tightly
depend on specific FPC versions, and historically, whene
Fixing the FTBFS is rather trivial (yet another victim of GCC13 header
shenanigans)
and I've already created a patch for this, but I didn't want to pick up the
package since
upstream activity since rather low. If you're saying that the project isn't
dead yet,
then I'd be willing to pick this up
> Is there another argument to fedpkg?
fedpkg has a --name argument, you can try using that.
Alternatively, if you're just taking your first steps with packaging, you can
try:
$ rpmbuild -bs path/to/your.spec
$ mock path/to/file-created-by-previous-command.srpm
This will first build an SRPM ("so
> Should that tutorial work? Is it perhaps obsolete?
I'd say the opposite of obsolete - it's been updated to suggest using
fedpkg all along the way, instead of the old rpmbuild tools. But it
looks like it wasn't tested enough to make sure everything works.
> My newbie understanding is that fedpkg
Hi all,
I intend to un-retire arptools, which is a small collection of Ethernet ARP
tools.
The package used to be in Fedora repos, but was retired somewhere between F31
and F32 due to being orphaned.
https://src.fedoraproject.org/rpms/arptools
I looked through the devel list, but couldn't find
Tested on three different machines. No problems with transaction conflicts,
just some package downgrades:
- inxi-3.3.25-1.fc37 -> inxi-3.3.24-2.fc38 (version downgrade)
- fwupd-1.8.10-2.fc37 -> fwupd-1.8.10-1.fc38 (lower release number)
A.FI.
___
devel m
> paintown
> - CC0 and Public Domain and BSD and LGPLv2+
> + CC0-1.0 AND LicenseRef-Fedora-Public-Domain AND License-Callaway-BSD AND
> License-Callaway-LGPLv2+
> - Public Domain
> + LicenseRef-Fedora-Public-Domain
Slightly off-topic, but this package was pulled because of legal issues [0],
a
> aha
Converted manually.
> gearhead1
Ehh, I'll have to contact upstream about this.
The license.txt file is LGPLv3, but all code files have comment headers that
say "version 2.1 or later".
> mingw-SDL_ttf
Converted manually. Also, I missed when upstream switched from LGPL to Zlib.
> php-marcus
Hi, Kevin.
I spotted an issue where one of my Bodhi updates for F41 got marked as
obsoleted by an F42 update
and now F42 is updated, F40 has an update in testing, whereas F41 has the old
package version.
Is is possible to re-tag the F41 build?
Obsoleted update:
https://bodhi.fedoraproject.org/u
I have three machines running F40; here are the results:
#1
Error:
Problem 1: package module-build-service-3.9.2-9.fc41.noarch from fedora
requires python(abi) = 3.12, but none of the providers can be installed
- problem with installed package module-build-service-3.9.2-9.fc40.noarc
Hi all,
I maintain the cpufetch package [0], which is a program that allows the
user to retrieve some info about the CPU of the machine - such as cache
size, frequency, sometimes also the manufacturer and model.
A few weeks ago, the program had a new release and I updated the package.
However, th
Oh, wow. Big thanks, Kevin!
I relayed this info to the upstream developer, along
with an invitation to participate in this thread as to
avoid using me as an intermediary.
Thanks again!
Sincerely,
A.FI.
--
___
devel mailing list -- devel@lists.fedorap
> fpc - can be trivially converted to GPL-2.0-or-later
> AND LGPL-2.1-or-later WITH Qwt-exception-1.0
Please don't. FPC has an ongoing discussion in fedora-license-data [0],
and the conclusion was that this most likely warrants a new exception
identifier [1]. If we want to go with an existing
> lazarus
Hmm, I'm pretty certain I converted that.
> %global license_ide GPL-2.0-or-later AND LGPL-2.0 WITH
> Classpath-exception-2.0
> %global license_lcl GPL-2.0-or-later AND LGPL-2.0 WITH
> Classpath-exception-2.0 AND MPL-1.1 AND Apache-2.0
Bah, silly mistake on my part. This was "LGPLv2
> LGPL-2.0-or-later WITH Classpath-exception-2.0
> is not allowed. Simply because it is not on Fedora list (while it is valid
> SPDX formula).
> Can you please file an issue for this combination at
> https://gitlab.com/fedora/legal/fedora-license-data
The licensing situation for Lazarus is prett
Hi,
I have updated the license on the "lazpaint" package. [0]
LazPaint is an image editor, and a leaf package with no dependents.
a) LGPLv2 -> LGPL-3.0-only
I missed upstream switching from v2 to v3 at some point.
b) Dropping Boost
The Boost license is only relevant to some test files,
No files
> I just discovered that the fontawesome-fonts package had no commit or
> build either. I wonder if it has something to do with this error I
> just encountered while preparing an update for the package:
>
> $ git push
> Source file '60-%{fontpkgname1}.conf' was neither listed in the
> 'sources' f
> Problem 1: package libblockdev-vdo-2.24-2.fc32.x86_64 from @System requires
> libbd_utils.so.2()(64bit), but none of the providers can be installed
> - libblockdev-utils-2.28-5.fc38.x86_64 from @System does not belong to a
> distupgrade repository
> - problem with installed package libbloc
> Ultimately, appstream-util's output is what matters since we use
> appstream-builder (from appstream-glib) to generate our AppStream
> metadata index. If it doesn't pass that tool, it doesn't show up.
Bit of a tangent, but: is this documented anywhere?
Because if if is, then I can't find it.
Wit
Hi all,
I've been maintaining Fritzing, the electronic design software [0]
for some time now. Currently, the program is split into two packages:
"fritzing", providing the executable; and "fritzing-parts", a noarch
package providing data files, including the parts database.
The parts database is ge
Hi all, the license tag on qmltermwidget [0] has been corrected from:
GPL2+
to
GPL-2.0-or-later AND LGPL-2.0-or-later
The only two consumers of this package in Fedora repos are:
- cool-retro-term
- qmlkonsole
Cheers,
A.FI.
[0] https://src.fedoraproject.org/rpms/qmltermwidget
--
_
Hi all,
the pipewalker package [0] has been updated to the latest release, v1.0. [1]
This release includes a re-licensing of the code from GPL-3.0-or-later to MIT.
pipewalker is a leaf package, so this shouldn't affect anyone.
A.FI.
[0] https://src.fedoraproject.org/rpms/pipewalker
[1] https://
https://doc.rust-lang.org/reference/attributes.html
If I understand this page of The Rust Reference correctly,
then moving the #![no_std] attribute from the first line of the file
shouldn't break anything. So you can try side-stepping the issue
by patching the file and adding "// lol pointless comm
Hey all,
I have two packages which have been sitting in review for some time now:
https://bugzilla.redhat.com/show_bug.cgi?id=2095732
daniel-wikholm-segment16-fonts - collection of 3 font families.
Bit problematic because of missing license text, not having an official source
website, nor a way
While I really like the idea, I find the interface to be... how do I put it?
Non-obvious and not very discoverable.
For example, at the top of the page, there's a bunch of numbers. I have no idea
what they mean.
Hovering over each of these displays a tooltip - which is nice - but five
seconds af
> Sounds like you need to clear your browser cache or something
Yeah, looks like it. I refreshed the page via F5 and it didn't help.
Doing a full page reload via Ctrl+R helped.
> According to your description, your browser might be broken,
> perhaps due to some content blocking?
> See this screens
Hi, Petr.
I use firejail every now and then, and glancing at the commits,
the package doesn't require much maintenance, so I adopted it.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fed
Hi all,
some time ago I've built the Free Pascal Compiler [0] for EPEL9,
and recently I got the idea it might be good to do the same with
the Lazarus IDE [1]. Testing things locally with mock,
I realized that Lazarus used a macro from fpc-srpm-macros [2],
which hasn't been built for EPEL9 yet.
No
I took a look at epel-rpm-macros. Interestingly, in EPEL9,
the package has "Recommends: fpc-srpm-macros". [0]
Despite this, when I try building in the side tag,
the package isn't pulled in. I guess koji is configured
not to pull in weak deps?
Anyway, I've opened a PR on epel-rpm-macros
to change t
> 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
Hello, Bojan.
The only way I know is to utilise the "RemovePathPostfixes" tag for this, e.g:
> %package gtk3
> RemovePathPostfixes: .gtk3
>
> %package qt
> RemovePathPostfixes: .qt
>
> %files gtk3
> %{_bindir}/%{name}.gtk3
>
> %files qt5
> %{_bindir}/%{name}.qt5
Then, you just need to rename th
> - rpms/fpc
> - rpms/lazarus
I've been a co-admin on those, so I took 'em.
Several of the orphaned packages are dependencies of stuff I currently maintain.
I'll wait a week or two to see if anyone else wants to take them.
A.FI.
___
devel mailing list -
> I have no strong opinion how to process with the case of
> "MIT and BSD and Bitstream Vera and OFL". I think that
> converting it to " MIT and BSD and Bitstream-Vera and OFL"
> is probably best option.
I'll go on a tiny bit of a tangent here: SPDX spec says that
license expression operators (AND
The XDG spec [0] says that, if the env vars are unset,
or set to an empty value, a compliant application
should fall back to the default value given by the spec.
So I guess the answer is that, since we don't need to use
non-standard directories, setting the env vars to the same
value as the fallb
> SPDX v3 has been published. The biggest change for us is that license
> expression
> allows lowercase operators (and, or, with).
Worth noting is that the spec [0] says thse should be
either all-lowercase or ALL-UPPERCASE:
> License expression operators (AND, and, OR, or, WITH and with)
> shoul
This depends on the state of the package.
1. Has an active maintainer? They must go to the package's repo, and in the
settings, grant you commit/admin access. [1]
2. Has a maintainer, but they're inactive? You must fire up the non-responsive
maintainer policy. [2]
3. Package is orphaned, but not
SSR is available in RPM Fusion under the name "simplescreenrecorder",
so you may want to coordinate this with the Fusion maintainer - maybe
do something similar to Audacity and Chromium, where the Fedora package
is named "foobar" and the RPM Fusion one is "foobar-freeworld".
A.FI.
https://admin.r
> garmintools orphan 5 weeks ago
I adopted this. The build is now finished.
https://koji.fedoraproject.org/koji/taskinfo?taskID=88328349
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsu
$ rpmbuild --showrc
The definition for %cmake is quite long, but includes this line:
%{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} \
%__cmake_builddir is defined as:
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}
And then %_vpath_builddir is defined
When you go to a package's repo on src.fedoraproject.org,
on the top of the page, you get this nice table that lists
active Fedora and EPEL releases, and for each of those,
prints the package version currently in stable and in testing.
Now, I could swear that fedpkg had a similar feature.
Yet, loo
Just after sending this message, it occurred to me
that I could just use the developer tools in the browser
to check the URL of the API endpoint being called
and then just send a similar request using curl.
So it is quite possible that it was, indeed, my memory
playing tricks on me, and I used to
I wanted to try building a Fedora Flatpak, so I headed over to the docs and
started with the tutorial.
https://docs.fedoraproject.org/en-US/flatpak/tutorial/
The first step instructed me to install some packaging tools:
$ dnf install flatpak-module-tools fedmod
DNF complained that it could not f
> Users of RPM-based variants will expect the default package manager to
> install RPMs,
> not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that one.
That being said, what about allowing users to set this preference by themselves?
I also think that the repository informa
> I'd imagine a single slider (or drop-down menu or whatever)
Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubsc
Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.
Strictly speaking, the packag
> Too complicated for the average user.
That's debatable. Does the *average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.
> It should be visible when you click the "Install" button.
I agree that the current placement makes
Blueman, the bluetooth manager [0], requires the user to be in the "wheel" group
in order to perform certain functions (like enabling/disabling bluetooth).
This leads to a sub-optimal user experience, where the user is prompted
to authenticate as root in order to perform certain actions. [1]
The "
I can join bleachbit as a co-maintainer.
A.FI.
___
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-condu
The docs make it seem like maintaining a spin isn't that much work,
and the kickstart files for spins look rather straightforward.
> ## Maintainer did not respond to pings
> * Games Spin — https://fedoraproject.org/wiki/Games_Spin
Unless someone more experienced comes along, I'd be willing
to take
> I would like the bot to stop trying making patches and doing scratch builds
> on all my packages at all.
> Is that possible? How?
Isn't that controlled in Pagure, via the "monitoring" dropdown on the repo page?
There's "no monitoring", "monitoring" and "monitoring with scratch builds"
options.
Adding "#include " to src/timer.cpp fixes this.
A.FI.
___
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-o
In the spec, you have this:
> %setup -n %{module_name}-%{version}
The error message looks like this:
> /usr/lib/rpm/rpmuncompress -x -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz
> rpmuncompress: -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz: unknown option
On first glance, this looks like a bug in t
> Major version updates often change behaviour of the apps or the system itself
It's also worth mentioning that if some packages are retired, they will not be
available in the new Fedora version. In the old days, this would mean you
might get some old & broken packages stuck on your system; nowaday
I wrote to Igor a week ago, but it seems he's away currently, as I didn't get
an answer yet.
Do you know of some document that describes how to "go through Igor's whole
weird rust side tag build procedure"? Or, if it's not too complicated, would
you mind explaining it?
_
Big thanks, these were very helpful.
If anyone's interested, here are the bodhi updates for the packages:
- copydeps: https://bodhi.fedoraproject.org/updates/FEDORA-2020-6b5ea5655a
- desed: https://bodhi.fedoraproject.org/updates/FEDORA-2020-bbc06105dd
A.FI.
__
Recently we've had a new automation introduced, which seeks out stalled
review requests and tries to prod them to move forward.
One of the ways it does this is by looking at reviews which have the
NEEDINFO flag set and, if the ticket reviewer failed to reply
for a long time, it resets the ticket s
>a) failing to check if the NEEDINFO flag is set for the *submitter*,
> instead of a reviewer
>b) failing to clear the NEEDINFO flag for the submitter
Oops, I barely posted the message and I already spotted that I'm wrong.
The NEEDINFO flag, in this case, is set to require action
from "nob...@fe
I took over cpulimit.
___
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: https
> dumb-init orphan 1 weeks ago
I sometimes use 'dumb-init' when playing with containers, so I adopted this one.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel
Less of "very time consuming" and more of "occasional annoyance": "fedpkg
commit" could inspect the .spec file and ensure that every Source has a
matching entry in the sources file, and that every Patch has a corresponding
file in the repo. Every now and then I do a local build, it works, I comm
The php-email-address-validation package [1] has been built using code fetched
from the now-defunct Google Code, which dated back to 2009. The package
received no updates since then. I plan to switch the package to build from a
forked version of the library [2], which is still maintained (last "
Since nobody contacted me regarding this, I'll go ahead and make the change
somewhen tomorrow.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
htt
I maintain two Rust packages, rust-copydeps [1] and rust-desed [2]. Both were
built for F33 ([3], [4]) before it branched off for Rawhide (and submitted to
bodhi ([5], [6])). I gave the F33 beta a spin and when I tried "dnf install
copydeps desed", I got no matches. Other Rust packages, like rus
>Problem 1: package copydeps-4.0-3.fc32.noarch requires python(abi) = 3.8, but
>none of the providers can be installed
> - python3-3.8.5-5.fc32.x86_64 does not belong to a distupgrade repository
> - problem with installed package copydeps-4.0-3.fc32.noarch
This is because copydeps has been rewri
On a related note - could we increase the size limit for FTBFS tickets?
Currently, the when FTBFS bugs are filed, the attachments are limited to 32KiB,
which is often too small to fit the whole build log.
The whole point of attaching these to the bugzilla ticket is that koji deletes
logs after so
There's been a (short) discussion about having a wishlist last month:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K3O5WRMT75UCWMRE6PCMBHRGMHMIBM63/
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To un
> I have created new tool license-validate:
> https://pagure.io/copr/license-validate/
I've written something relatively similar a few years back
(https://github.com/suve/vrms-rpm).
I took a look at the code - using a proper parser is definitely a better
solution than the error-prone,
manual mat
This is happening to me, too - but it doesn't seem to be limited
to koji notifications. It happens with bugzilla notifications as well.
There isn't any pattern to the delays that I can see.
I regularly receive notification digests during the day,
yet every now and then I receive a digest informing
Even if it does, it's unlikely to be the culprit,
since in my case, I only use e-mail notifications.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I've got this sad boy waiting for a review since September:
https://bugzilla.redhat.com/show_bug.cgi?id=2006685
pasdoc - Documentation generator for Pascal source code
I can review some C, C++, Pascal or shell stuff in return.
A.FI.
___
devel mailing li
Hi, Darryl.
> How to clone the GitHub repository in the spec file
RPM packages are build from Source files. You don't clone the repository in the
spec;
rather, you download the repository as a tarball and use that. For GitHub, you
can download
a specific git tag (or commit) by using the followin
I tried compiling colobot with the new gcc, expecting it to break in some
new and fascinating way, and got the following error:
In function 'std::char_traits::copy(char*, char const*, unsigned long)',
inlined from 'std::__cxx11::basic_string,
std::allocator >::_S_copy(char*, char const*, unsi
I pulled a Rawhide container and tried building there via "fedpkg local".
When I took the g++ command line and replaced "-flto=auto -ffat-lto-objects"
with "-flto=none", the file was compiled without errors.
A.FI.
___
devel mailing list -- devel@lists.fe
> 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
Hi all,
some time ago, Lazarus v2.2.0 came out. I tried to update the package
in Rawhide, but the build failed on ppc64le with a linking error.
Link to failed scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575
../units/powerpc64-linux/nogui/project.o: in function
`WRPR_
Bumping this since I have an identical issue with colobot - the compilation
errors out when a C-like string literal is assigned to an std::string, with the
compiler providing the same "memcpy accessing... overlaps lots-of-bytes at
offset -3" error message.
A.FI.
> chocolate-doomsundaram
I've managed to get this to build successfully in koji.
I'll try to contact the maintainer, though looking at bugzilla, they haven't
been active since April 2020.
I'm willing to adopt the package should the maintainer drop it or be declared
unresponsiv
I contacted Rahul and he made me a co-maintainer on the chocolate-doom package.
I've pushed a commit that fixes the build failures and updates the package from
v3.0.0 to v3.0.1.
The builds for rawhide, f35 and f34 had finished and have been submitted to
bodhi.
A.FI.
_
One of my packages ("blueman") had a new release today, so I updated it.
Despite me committing to the rawhide branch, the build was given the ".f36"
suffix,
so when I pushed to the f36 branch and tried to build the package,
koji berated me that it's been already built.
So what now? Should I just
> file /usr/bin/icat from install of sleuthkit-4.11.1-1.fc36.x86_64 conflicts
> with file from package icat-0.5-10.fc36.x86_64
> file /usr/share/man/man1/icat.1.gz from install of
> sleuthkit-4.11.1-1.fc36.x86_64 conflicts with file from package
> icat-0.5-10.fc36.x86_64
icat is one of my packag
You need to generate an SSH key and upload it to
https://accounts.fedoraproject.org
Log in, go to Settings and switch to the "SSH & GPG keys".
If this isn't the only key you're using, you will also need to edit your ssh
config.
A.FI.
___
devel mailing
> error: Unable to open /dev/stdin: No such device or address
How about "/proc/self/fd/0"?
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://
Back in July, during the F35 Mass Rebuild, the Free Pascal Compiler package
failed to build [1] because of linking issues on aarch64, i686 and ppc64le,
related to the new glibc 2.34. x86_64 and arm we unaffected, however.
This was discussed briefly here on devel in thread [2]. The issue was submi
1 - 100 of 152 matches
Mail list logo
