> So, I'm proposing to remove the support code (and templates, etc.) for
> this mode of operation from rust2rpm with the next major version, and
> to replace it with documentation [...]
Documentation works if people know it exists, so I think it'd be best
if the program still recognised the --path
> Notably, *both* of your examples are already impossible because
> you can't install glib2.i686 on an x86_64 system anymore due to
> https://bugzilla.redhat.com/show_bug.cgi?id=2258600.
The bug is about a conflict in -devel packages. Installing base
glib2.x86_64 and glib2.i686 packages is totall
> icon orphan 2 weeks
> ago
Taking this. Will try to update it to latest version over the weekend.
A.FI.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Tested on three machines running Fedora 41; two of them were a-okay, one had
some errors:
> Problem 1: installed package libreoffice-writer2latex-1.0.2-38.fc37.x86_64
> requires osgi(javax.xml), but none of the providers can be installed
> - xml-commons-apis-1.4.01-47.fc41.noarch does not belon
We're currently in the middle of F42 branching + related freeze.
> All builds that will be running at that time for the rawhide will be
> canceled and can be resubmitted by maintainers after the branching.
>
> All rawhide updates that are pending for rawhide will be unpushed.
https://lists.fedorap
> indi-3rdparty-drivers:
> error: expected ‘;’, identifier or ‘(’ before ‘bool’
> Looks like the syntax 'typedef enum { FALSE, TRUE } bool;' is no more
> accepted, but searching in the net it was perfectly fine.
Looking at the build logs, it seems that while a standard is explicitly
provided for
While I agree with the general idea of building things in order
of requirements, one problem that I can see with this approach is:
what happens when a higher-tier package fails to build?
With the current, alphabetical approach, every package gets rebuilt
and then individual maintainers have to fix
> php-phpseclib fkooman, remi
I've opened a PR against phpseclib that updates it to the latest 2.x release.
[0]
This also fixes the FTBFS issue.
There is a new major version (3.x) available [1], but it would probably
be better to introduce that as a new package.
A.FI.
[0] ht
> Sorry, but I don't really have interest in taking care of that package. [...]
> So it would be great if this could either be fixed by somebody, or removed
> completely.
I'd be willing to take this over. Let me see if I can contact Lubomir.
A.FI.
--
_
> 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
> 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
> 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
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
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
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, 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
> 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
> 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
> 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
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
> 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
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
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://
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,
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
> 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
> 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
> 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
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
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
> 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
> 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.
__
> 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
> 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
> "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.
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
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
> 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
> 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
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
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
> 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
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
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
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
> 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
> 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
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
> 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
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
> 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,
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
> - 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 -
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
> 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
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
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
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
> 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
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
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
> 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
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
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
> 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.
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 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
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 "
> 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
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
> 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
> 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 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
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
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
$ 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
> 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
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
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
> Are you manually editing the "sources" file?
No, why would I?
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
> I very likely have the files listed in sources
> around from previous attempts
Well, yeah, but it's also likely that someone:
1. Has multiple machines, hadn't done any work on this package on the current
machine, and did a fresh "fedpkg clone"
2. Got fed up with clutter in the directory and sta
> I somehow don't understand why there should be anything like "unused
> source files". Why is something like this even possible?
1. Grab a package
2. Edit the spec file in a way that changes which sources are used (say, update
to a new version)
3. Do not run "fedpkg new-sources" to upload the n
git-up has been retired for over a year now. Packages that have been
retired for over 8 weeks need to go through Package Review again.
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
A.FI.
___
devel mailing
For me personally, opt-out would be better, since the logic is right most of
the time.
That being said, how about adding a value for this in
$HOME/.config/rpkg/fedpkg.conf?
That way, you have some default value, which can be overridden by the config,
which in turn can be overridden by the opt-in
cpufetch v1.02 has just been released. This new version includes a change in
licensing, from MIT to GPL-2.0-only.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Co
I'm not sure if I use any i686 executables, but I sure do use
i686 builds of libraries for cross-compiling. By which I mean
both i686-linux and i686-win32.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to deve
On my F35 machine, there are no transaction errors, but the following packages
get downgraded:
- binutils-x86_64-linux-gnu and cross-binutils-common - from 2.37-3.fc35 to
2.37-2.fc36 (same version, release downgrade)
- thunderbird and thunderbird-librnp-rnp - from 91.5.0-1.fc35 to 91.4.0-1.fc36
Are you talking about the "nextcloud-client" package? [0]
'cause that one isn't orphaned, and nonamedotc [1] is listed as the maintainer.
Also, v3.4.2 is currently in testing, but has not been pushed to stable
due to reported bugs. [2]
A.FI.
[0] https://src.fedoraproject.org/rpms/nextcloud-clien
> 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://
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
> 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
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
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.
_
> 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
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.
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_
> 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 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
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
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
1 - 100 of 155 matches
Mail list logo
