> - Do you have custom mock configuration in ~/.config/mock.cfg?
No, I don't even have that file.
> - Are files in /etc/mock/ up-to-date, or are there lots of .rpmnew files?
mock-core-configs is up to date (32.7-1.fc32), there's no .rpmnew files.
> - Does running "mock -r fedora-rawhide-x86_64
Today I tried reviewing some Python packages:
- x-tile: https://bugzilla.redhat.com/show_bug.cgi?id=1861020
- python-iptools: https://bugzilla.redhat.com/show_bug.cgi?id=1870907
And the mock build done by fedora-review failed. The error message I got was:
> line XX: fg: no job control
Which means
I had this issue a month ago when reviewing sane-airscan:
https://bugzilla.redhat.com/show_bug.cgi?id=1859207
Also a week later, when reviewing wev:
https://bugzilla.redhat.com/show_bug.cgi?id=1860772
And today, when I tried to review spirv-llvm-translator:
Recently (happened today and happened a month ago), whenever I try to run
fedora-review for a Review Request that includes a C/C++ program, the mock
build fails immediately due to gcc/g++ not being able to find the annobin
plugin.
> cc1plus: fatal error: inaccessible plugin file
We also have an icon size requirement. The app needs to provide an icon that's
at least 64x64 (or maybe even 128x128?). I vaguely remember there being a
discussion here on devel when the requirement was introduced.
I tried searching the wiki and the Packaging Guidelines and this is the only
Hedgewars is mostly Pascal, so with me maintaining FPC and Lazarus, I'd be
willing to take it over. However, I don't know any Haskell, so some help from
someone who does would be appreciated.
___
devel mailing list -- devel@lists.fedoraproject.org
To
So I'm trying to package the Free Pascal Compiler and Lazarus (the most popular
IDE + GUI framework for FPC) for EPEL8. I have requested an epel8 branch for
fpc and for fpc-srpm-macros; both of those have been built, submitted to bodhi,
and are now in the stable repo for EPEL8. Yet when I try
> suve copydeps dnstwist python-ssdeep
Fixed in rawhide (just dist-git, didn't run the builds). Should there be a new
release for any of these, I'll fix it for F32/31, too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Isn't this how bodhi always worked? One week (two weeks for EPEL) and if
doesn't get negative karma, it gets pushed - no matter if it's an enhancement,
or a bugfix, or a security update.
When creating an update from the web panel, you can un-check the "Auto-request
stable based on time?" box
A few days ago I adopted fritzing and fritzing-parts, which were orphaned by
their original maintainer.
I looked at the package and at the upstream project and noticed a few things:
- Looking at the releases page for the app [1], upstream stopped doing releases
manually and relies on a
Took over both "fritzing" and "fritzing-parts". If anyone would like to join as
co-maintainer, let me know.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
>fritzing logic, orphan1 weeks ago
>fritzing-partslogic, orphan1 weeks ago
I'd be willing to help with this one, but since there already is a
co-maintainer listed, I'll ask first if they're willing to step up to
Welp, too late, I already took it. I tried to trigger the retirement procedure,
but I can't get write access to git-scm, so I decided to just file a releng
ticket: https://pagure.io/releng/issue/951
___
devel mailing list --
> > cinnamon-themes jcpunk, orphan 5
weeks ago
> I use Cinnamon as the main DE on one of my machines, and the package
> doesn't look like something that requires a lot of maintenance, so I'll take
> it.
...right, so I took a better look at the package. The
> cinnamon-themes jcpunk, orphan 5 weeks ago
I use Cinnamon as the main DE on one of my machines, and the package doesn't
look like something that requires a lot of maintenance, so I'll take it.
___
devel mailing list
In a similar vein - "dnf upgrade" will fail if the package is not already
installed on the system. Maybe bodhi should suggest "dnf install --best"
instead?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
While I understand the mechanism, I think that this needs to be communicated
more clearly. I've been a packager for close to 3 years now and I admit until I
read this e-mail I wasn't quite sure whether "no updates after EOL" meant "you
can't submit stuff to bodhi", or whether it meant "the
I've written blog posts about packaging and gave a talk about it on a local
Linux group, so I'd be glad to participate in workshops or some other
initiative.
One idea that comes to my mind right now is - how about making a video
tutorial? While I personally dislike those and prefer text, I
Ah. Scratch builds aren't considered real builds, so they don't show up in the
builds list and I was peeking around there. Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
I looked through the help / --help for the command and tried searching the wiki
and didn't find an answer, so I'm asking here: is there any way to retrieve a
list of scratch builds I've submitted to koji?
___
devel mailing list --
Regarding x86_64 and AVX2, last year we had a very heated discussion about this
on the mailing list.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U
tl;dr: there was a proposal to make "x86_64"
Today, Miro sent out a message [1] about FTBFS packages to be orphaned soon. On
the list I saw one package that's of interest to me, so I figured I should take
a look - maybe I'll be able to fix it and submit a Pull Request to dist-git.
After opening Pagure, I clicked on the "latest builds"
Dokuwiki has broken dependencies because one of them got retired recently due
to no upstream activity. There is an open Review Request for a still-maintained
fork of the original package:
https://bugzilla.redhat.com/show_bug.cgi?id=1809097
If anyone has a moment to review it (it's a PHP
I couldn't find an answer in the Packaging Guidelines, so I'm writing here.
My question is as follows: looking at the various icon-theme packages in
Fedora, they seem to adhere to the following directory hierarchy:
- 16x16
| - apps
| - emblems
| - (other categories)
- 32x32
| - (categories)
-
On my second machine:
Problem with installed package mkvtoolnix-gui-41.0.0-1.fc31.x86_64
- package mkvtoolnix-gui-41.0.0-2.fc32.x86_64 requires
libcmark.so.0.28.3()(64bit), but none of the providers can be installed
- mkvtoolnix-gui-41.0.0-1.fc31.x86_64 does not belong to a distupgrade
Problem with installed package mumble-1.2.19-15.fc31.x86_64
- package mumble-1.2.19-15.fc31.x86_64 requires libprotobuf.so.17()(64bit),
but none of the providers can be installed
- protobuf-3.6.1-5.fc31.x86_64 does not belong to a distupgrade repository
- package
On FSF Europe's mailing lists, DP's using the "daniel at pocock dot pro"
address. I guess you could try messaging him using that address.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
I have just orphaned fluxcapacitor. [1]
I've packaged the program for Fedora since it seemed to me, at the time, that
it provides a useful gimmick. I have to admit I've got a lot less use from the
package than I anticipated, and given that there are currently two major issues
with it, I
No, this was done on a Fedora install. But thanks for the input! I've looked
into the sources and with patched paths and rebuilt bootstrap compiler, the
koji scratch build went ok. Gonna make a commit to dist-git soon.
___
devel mailing list --
I've finished the build for ppc64le (bootstrapped from a cross-compiled
compiler): https://koji.fedoraproject.org/koji/taskinfo?taskID=41106187
It should be noted, though, that to enable ppc64le for dependent packages, the
fpc-srpm-macros package must be edited (since packages depending on fpc
If you're asking "what's the source code", then it's built using the same
source as the RPM. After going through %setup (i.e. extracting everything and
applying patches), do:
$ cd fpcsrc/
$ make all CPU_TARGET=aarch64 OS_TARGET=linux BINUTILSPREFIX=aarch64-linux-gnu-
If you're asking "where the
Here's a koji scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41102368
The ppc64le bootstrap went fine, the aarch64 one fails at:
/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/compiler/ppca64 fpmake.pp -n
Yes, sorry about that. I'm working on it right now. Should be done before
midnight CET.
FPC 3.2.0 was originally to come out before the end of 2019, but it still
hasn't been released. Reading the forums and the bug tracker, none of the
remaining issues affect Fedora, so I decided to go with
I recently began having a similar issue - with some programs, whereas
previously the system would slow down slightly due to load, now it freezes for
like half a second or a full second. This is most prominent when I launch
Chromium, but is also visible when I switch to a long-unused tab in
You'll need to either edit the Makefile so it explicitly calls python3, or add
a BuildRequires: for "python-unversioned-command".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Some time ago I adopted blueman, as it has been orphaned and I, being a user,
wanted to keep it around.
Unfortunately I know very little Python (which blueman is written in) and even
less about the Bluetooth stack on Linux, and as a result the bug reports for
blueman have been piling up. As
Kevin Kofler wrote:
> I think it is of use to users of non-GNOME, non-Plasma desktops,
> especially Qt ones (in particular, LXQt).
Anecdotes are not evidence and all that, but I use LXDE on my laptop and don't
have nm-tray installed. I have nm-applet, which also provides a tray icon/menu.
I
Yes, dependent packages should use %{fpc_arches}. FPC itself doesn't do that.
I imagine the reason is that this allows us to add new architectures to FPC and
do some trial-and-error builds of FPC without affecting dependent packages - if
FPC itself used %{fpc_arches}, then adding new
FPC 3.2.0 hasn't been released yet - this Change Proposal is a bit of a early
heads-up. The FPC website says it should be out before the end of the year.
Once it's released, after updating rawhide, a COPR repo can be prepared.
___
devel mailing list --
I've never maintained an icon theme package before, but I like the Paper icons,
so I guess I could adopt this.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
The fact whether we're in the OS or not, whether it's a bootloader or a
pre-init script or whatever is irrelevant from the end-user perspective. The
end-user sees that the system will wait the password endlessly and I agree with
Joseph that it's not good behaviour.
>Do you have OLED monitor?
I use youtube-dl regularly, so I'd be happy to assist in maintaining the
package.
FAS: suve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
My packages built fine on i686, but I've had a different cpio-related error on
s390x:
>DEBUG util.py:585: BUILDSTDERR: error: unpacking of archive failed on file
>[...]: cpio: read failed - Inappropriate ioctl for device
Is this just some random one-off thing, or did anyone else get the same
The builds for the previous versions succeeded with a python3 BR, so either
something has changed along the way, or the package has a bit of a history with
accidentally successful builds. :)
Either way - changing the BR to python3-devel worked! Thanks for the help.
Done; committed and pushed.
___
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:
Yeah, I made the mistake of putting some music in the repo instead of the cache.
I wanted to write "too late to fix that now", but now that I think of it -
well, doing a full `git clone` will still be slow, but at least `--depth=1`
clones will go fast. I'll make a commit that moves the files to
I've got a package (colobot) which has a build-time dependency on Python3. The
program had a new upstream release today, so I updated the spec file and fired
up the builds.
Everything went smooth on rawhide and F30, whereas the F29 and F28 builds
failed with a rather amusing error message:
I've made a COPR repo with Lazarus 2.0. If you can test Hedgewars using it,
that'd be great.
https://copr.fedorainfracloud.org/coprs/suve/lazarus-2.0/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
I've made a COPR repo so you can test if your packages build ok.
https://copr.fedorainfracloud.org/coprs/suve/lazarus-2.0/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
Just a couple of minutes ago, version 2.0 of Lazarus, the Pascal IDE / GUI
toolkit was released.
Here's the link to the changelog; there are a few compatibility-breaking
changes:
http://wiki.lazarus.freepascal.org/Lazarus_2.0.0_release_notes
Lazarus is used to compile a few other Fedora
Hello everyone,
I'd be really grateful if someone versed in meson could help me fix build
errors in modem-manager-gui.
The error is a bit of a random thing, as only some builds fail, and some work
fine; I actually haven't been able to reproduce the error on my machines and
only see it in
I'd like to become a co-maintainer for openarena.
My FAS username: suve
A.I.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Just checked myself, I don't have the file either, and I use a separate local
account for RPM packaging (that uses a different name than my FAS login). No
idea what that's about, I can't recall any tool ever complaining about the file
missing.
___
Thanks for bringing some attention to this, Ben. I don't do a whole lot of
packaging, but I admit there are some places where the workflow could be
improved. I'd be willing to join the group and help where I can.
Some notes off the top of my head that I ran into recently:
- fedpkg hides quite
I'll need to learn myself some python to be able to work with the code, but I'm
willing to take over blueman.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
I'd be willing to adopt sonar, but given that:
1) the package is several years out-of-date
2) upstream name of the project changed
3) I'm a tad busy at the moment and don't have much free time
...I think it'll be a better course of action on my side to let the package be
retired, and then
No, we did NOT do that.
A quick search on the devel list archives shows that F19 was released in July
2013:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSLJL6ZJC7M7TAOPNHJY7UAS7MA66PMR/
...and EOL'd on in January 2015:
Panasonic Toughbook CF-29: Worked fine, though the last time I used that
machine was back in 2015, so can't say anything about recent kernels.
There were a few kernel versions where the machine refused to hibernate -
basically, after 2-5 seconds of trying to hibernate it gave up and resumed
I use youtube-dl a lot, so I could help as a co-maintainer.
___
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
Thanks for the PR! I've merged it and used it to build the updated dokuwiki
package for Rawhide and F29.
I've also done builds for F28 and F27, though I'm wondering if they should be
pushed to updates - on one hand, there's the risk of breaking changes. On the
other, the package has multiple
If we remove the Group: tag from existing packages (assuming 100% accuracy),
this would mean that the only way for a package to have the Group: tag would be
to:
a) have a maintainer add it back in
b) accept a new package with the Group: tag present
If we assume option a) to be unlikely, then
So, I've contacted the maintainers. Adam Tkac has granted me commit access,
saying that he's no longer interested in the package. Topdog didn't respond to
my e-mail, but I see that he's no longer listed as the package admin... so I
guess that leaves me in charge.
I will take to updating the
I asked Igor Gnatenko and Neal Gompa, as they're both experienced packagers, of
their opinion and they said that introducing a new package this way is ok. I
will merge the PR today in the evening or sometime tomorrow.
A.I.
___
devel mailing list --
Hello, Vaasiliy.
Sorry for not replying to your PR. I was a bit wary of merging the PR, seeing
how Joost is the main admin for the package (as has been for the last several
years) and I didn't want to make substantial changes without his approval.
Personally I'm also a bit unsure if
I've used dokuwiki a couple times so I took a look at the package and it seems
rather reasonable. If there's no answer from the maintainers I could start the
Unresponsive Maintainer process and take over.
___
devel mailing list --
That section of the guide is a bit poorly worded. You should *not* use "git
add" on source tarballs. These should be added only via means of "fedpkg
new-sources $FILES; git add ./sources". I believe what the guide means under
"new source files" is e.g. when upstream does not provide an icon or
I looked at libattr and in the changelog, there's this:
>* Tue Jul 17 2018 Kamil Dudka 2.4.48-3
>- temporarily provide attr/xattr.h symlink until users are migrated (#1601482)
The bugzilla ticket says that attr/xattr.h was removed from libattr and is now
a symlink to sys/xattr.h. Taking a look
While this behaviour may be a bit confusing for users, it is consistent with
what upstream does.
Check: https://sqlite.org/quickstart.html
>At a shell or DOS prompt, enter: "sqlite3 test.db". This will create a new
>database named "test.db".
Or look at one of the downloads offered at the
I've built modem-manager-gui for F28, F27 and F26 and submitted the updates to
bodhi.
Thank you, Rex.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Hello, Rex.
Recently a new version of modem-manager-gui has been released. This new release
added an option to use ofono as the modem manager. I've updated the mmgui
package and ran into a problem where the rawhide [1] and F28 [2] builds
succeed, but the F27 [3] and F26 [4] builds fail, as it
Some time ago I've adopted modem-manager-gui. Recently upstream has released a
new version, and while packaging this new version, I noticed a couple of issues:
1) mmgui can work with a couple of backends (different modem managers and
connection managers). Each backend module is compiled into a
Is there a way I can automatically do something like "BuildRequires: fpc
(whatever version); Requires: fpc = version-used-during-build", or would I have
to control this manually?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
I believe that won't be necessary, as I took a look Lazarus's koji build for
F28 (https://koji.fedoraproject.org/koji/taskinfo?taskID=25292607) and on all
arches root.log says that fpc 3.0.4 was used during the build.
___
devel mailing list --
There's an "fpc" package, which is a compiler, and a "lazarus" package, which
is a fancy IDE. Though not always, sometimes when compiling GUI applications,
Lazarus recompiles parts of its codebase using FPC. Unfortunately, this makes
the IDE dependent on a specific version of the compiler - if
modem-manager-gui and tworld have been fixed on all actively used branches.
A.I.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> If you fixed package(s),
Just to make sure: the missing "BuildRequires:" should be added only on the
master (Rawhide) dist-git branch, or on all actively-in-use branches?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
> Batching is now the default, but maintainers can push theirs updates
> to stable, overriding this default, and make the update available the
> next day.
I think that since "batch override" doesn't push the package immediately, but
rather schedules it for the next day, I agree with Fabio that it
Hi, Richard.
What's the status on trying to reach joost? I use Pascal for some of my
personal projects, so it's important to me that the Pascal stack in Fedora is
operational.
Have you began the procedure to take over the packages from joost? I'd be
willing to join as a co-maintainer.
I took a quick look at build.log for i686, x86_64 and s390x and one thing I've
noticed is that during make install, the s390x build puts the .so files in
%{buildroot}/usr/lib, not %{buildroot}/usr/lib64. The only thing that comes to
my mind now is the qmake script (or some other part of the
Hello, Richard.
I've happened to stumble across a very similar issue recently. I've been
working on an update to Colorful - which, like Hedgewars, is a game written in
Pascal and compiled with FPC - and the game gives me an Access Violation upon
exiting. This happens after all of "my" code has
I have some notes regarding the Fedora wiki:
1) A few days ago, the layout changed. Now, I can't find the "search" link. I
imagine that's a rather important feature.
2) The "What Happened to PkgDB" page says that, to unretire a package, you
should follow a Pague ticket... Which, while it
I think that the vendor name should go at the beginning of the package name,
since suffixes are mostly used in Fedora to denote subpackages, like -data,
-docs, -devel, or modules, plugins, and such.
We have a couple of "google-*" font packages, so this usage of the vendor name
should be okay -
>If this is not too urgent, you can grab it for now on my COPR: [...]
Thank you, Robert-André! That was quick.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
I'd like to ask if someone would be willing to package the following program
for Fedora: https://github.com/simeji/jid
The software is written is Go (which is the main reason I didn't package it
myself). I can package or review some C / Cpp / Pascal stuff in exchange.
Thanks,
A.I.
Thank you for all you work, Fabio.
I can take over feh. I'll file a pagure ticket for adopting the package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
One question from me: quite a few games don't actually have separate icon art,
instead they just reuse one of the game's assets (the hero avatar, for
example). Would simply upscaling the "iconized" asset be enough, or do we want
a high quality "real" icon instead?
Hello, Richard, and sorry for the late reply.
I've patched the Lazarus project file and got the package to compile
successfully (koji scratch build) on i686. I attach the patch below. Hope
you'll find it useful.
--- cqrlog-2.0.5/src/cqrlog.lpi 2017-03-12 21:09:12.0 +0100
+++
I've had a similar problem before - the issue is that on 32-bit targets, fpc
defaults to generating debuginfo in stabs format (instead of DWARF) and that is
no longer supported by find-debuginfo.
You can read my thread here:
I see that modem-manager-gui has been orphaned recently. I took a look at the
package and didn't see any build failures, so this seems just a case of the
packager dropping the pkg. I've managed to built it locally and have a scratch
koji build, without any problems. As such, I'm willing to
> It is problem of FPC, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1475223.
Thank you. Very insightful.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Stabs is a ancient debuginfo format that isn't supported by any/most modern
>tools.
Hm. But it seemed to worked fine as recently as July 25.
>You should definitely see if [...] you can produce normal DWARF debuginfo.
I edited the makefile to use a different compiler switch, and with DWARF
I maintain a package written in Pascal, which uses fpc for compiling. I noticed
that recently, koji builds started failing on i686 and armv7hl due to the
find-debuginfo script failing to, well, extract the debuginfo.
Here's a link to a failed koji build (mass-rebuild by releng):
I think you're misunderstanding the discussion; the issue is not whether it's
okay to package the game at all - as noted by Matthew and Zbigniew, being able
to use copyrighted levels and such is okay; see: Fedora packs Doom ports.
The current blocker is that the level packs (CCLPs) use a
Hello. I was trying to package some software written in Pascal, which means
using the Free Pascal Compiler for building. FPC isn't available for all
architectures that Fedora supports, so it was necessary to use the
ExclusiveArch tag. I navigated to fpc in PkgDB, opened the spec file and
To anyone interested: I've finished packaging the game and would be grateful
for a review. I can do a review swap in exchange.
https://bugzilla.redhat.com/show_bug.cgi?id=1462412
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
I took a shot at packaging the game and it went rather smoothly. The only issue
I have is that the level packs don't really have a licence; the only copyright
info is a line at the end of the readme, stating: "This package [...] may be
distributed freely, as long as its contents are left intact
I have a bit of personal interest in Tox, so I took a look. qTox cannot be
included in the official repo because of dependency on ffmpeg. The dependency
list for uTox looks like it could be worked with (the filter_audio lib looks
the worst to me).
I searched for tworld, is that the "Tile
Good day, everyone.
My name is Artur Iwicki. I am a hobbyist game developer (going by the nickname
"suve")
and I would like to bring some of my works to the official repositories.
Currently I have submitted two review requests, one game and one command-line
utilit
98 matches
Mail list logo
