Re: fedora-review fails due to no annobin in mock
> - 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 clean --scrub all" help? Yes, that helped. I tried nuking /var/lib/mock before, which didn't help, so I guess clean+scrub-all does something more. Or maybe I nuked that before updating the mock-core-configs package, so it got rebuilt using the outdated config. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-review fails due to no annobin in mock
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 that RPM didn't recognize the "%py3_build" macro and left it as-is, so bash then saw "%" and tried to do job control and failed. I checked the logs for both failed reviews, and looking at root.log, neither review installed python3-rpm-macros, which is where "%py3_build" and "%py3_install" come from. Now, looking at python3.9.spec, there's this bit: > Requires: (python3-rpm-macros if rpm-build) So right now I'm inclined to think that maybe when fedora-review calls mock, and mock installs BuildRequires, it doesn't install them in the rpm-build context? This would explain both the Python and the C/C++ failures, since like python3-rpm-macros, annobin isn't required for "user" builds, but is used for RPM builds. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: fedora-review fails due to no annobin in mock
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: https://bugzilla.redhat.com/show_bug.cgi?id=1869907 ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedora-review fails due to no annobin in mock
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 plugin/annobin.so expanded > from short plugin name annobin: No such file or directory Downloading the SRPM of the package I want to review, adding "BuildRequires: annobin" and running fedora-review on this modified SRPM works, though obviously it's a rather tedious workaround. Does anyone else have this problem, or should I be worried about something being broken in my setup? ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: BleachBit is available in the repos, but does not appear when searching in GNOME Software
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 place I've found that mentions this requirement: https://fedoraproject.org/wiki/Workstation/Guidelines/Applications_and_Launchers#For_launchers: ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Help (or take over) hedgewars?
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 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
lazarus and fpc-srpm-macros: "no matching arches were found" on EPEL8
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 to build lazarus -
which uses the %{fpc_arches} macro from fpc-srpm-macros, the koji tasks fail
with "no matching arches were found".
As I wrote before, fpc-srpm-macros in in the EPEL8 stable repo. I even added
fpc-srpm-macros to BuildRequires for lazarus, but that didn't help. What else
should I do?
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please BuildRequire python3-setuptools explicitly
> 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 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bodhi too eager to push updates to stable?
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 to disable this. When doing this from the command-line... hm, I don't see any field in the template that'd allow to change this. Time to file a feature request? ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Wondering what to do with fritzing versioning
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 Continuous Delivery service. This is fine by itself, but at the same time, upstream switched to using the Continuous Delivery build ID as the main unique identifier for releases - and now there are two releases [2], [3] with the same semver. I suppose this may happen again in the future, so my thought was to use a combination of semver and the CD-build-ID as the Version: of the Fedora package, something like `0.9.4.CD498`. - Looking at the releases page for the parts repository [4], upstream stopped bothering with git tags quite some time ago. The "build & release" script [5] that upstream uses just pulls the latest commit from the fritzing-parts repository when doing a build. So now I'm just wondering: 1) Does the versioning scheme for the main package make sense? 2) For the fritzing-parts package, should I package the commit matching the official release (e.g. version CD-498 was released on 2019-12-01, so pick the 2019-11-24 commit from fritzing-parts, since that was "latest" at time of build), or don't care for synchronizing these and just go with the latest commit? The latter approach is easier, but I worry about potential backwards-incompatible changes. 3) For the fritzing-parts package, should I keep the semver and go with `semver-release.DATEgitCOMMIT`, or switch to `DATE-release.gitCOMMIT`? The latter option makes sense, but I'm not too keen about changing the versioning scheme. If someone's willing to share their thoughts and advice, I'll be grateful. A.I. [1] https://github.com/fritzing/fritzing-app/releases [2] https://github.com/fritzing/fritzing-app/releases/tag/CD-498 [3] https://github.com/fritzing/fritzing-app/releases/tag/CD-415 [4] https://github.com/fritzing/fritzing-parts/releases [5] https://github.com/fritzing/fritzing-app/blob/cb7c9cc452d11bd8fe26e67048e6ff7d92c87e72/tools/linux%20release%20script/release.sh#L98 ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
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 Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
>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 be the main maintainer. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
> > 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 repo has been moved, and there is a different package (mint-themes) built from the new repo; it even has "%package -n cinnamon-themes". So this "original" cinnamon-themes package shouldn't have been orphaned, but straight-out retired. I'll start the procedure later today. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers
> 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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bodhi: "how to install" is supposed to work?
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 devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 security update submitted for stable "marked obsolete" instead of being pushed
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 updates repo is frozen solid, whatever didn't make it in, well shucks". (As we can see, it's the latter.) This got me thinking - could we maybe make bodhi issue some kinda warning? Similar to how you get an e-mail when the package goes from pending to testing to stable, maybe bodhi could also give you a warning about impending EOL. Fedora packages need 7 days in testing (unless they get karma), and the pending->testing and testing->stable pushes take some time, so let's say 10 days - 10 days before EOL, bodhi stars adding a fat warning to the packages that says "better get that karma, 'cause if this ain't gonna make it to stable before -MM-DD, it'll go down the drain". ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging
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 know many people like videos for learning, so it might be a worthwhile investment. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Get a list of scratch builds from koji?
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 devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Get a list of scratch builds from koji?
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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What CPU extensions can we assume are available by arch?
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" in Fedora mean "must support at least AVX2" and it met with a lot of backlash. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Could we increase koji retention time for releng builds?
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" link to koji, opened the latest failing build... and the logs are gone because of retention time. So I had to submit a new scratch build. Minor as it may be, it's a waste of both my time and Fedora's resources. Would it be possible to configure koji in such a way that builds submitted by releng get a longer retention time? [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VGSXES425UY4X5FA5TQETCBBV45OMV2C/ ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Reducing broken dependencies in fedora (32) repositories
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 library + command-line tools), I'd be grateful. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Directory hierarchy in icon-theme packages
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) - (other sizes) However, looking through some icon packs on the Internet, many authors use the following hierarchy instead: - apps | - 16px | - 32px | - (other sizes) - mimetypes | - (sizes) - (other categories) Is there any kind of preference in Fedora for the first option, so that one should move the files around to match it, or should the directory hierarchy be left they way upstream does it? I guess since the "index.theme" file lists all the paths, it doesn't matter from a technical standpoint, but I still thought it'd be better to ask. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F31 to F32
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 repository - cmark-lib-0.28.3-6.fc31.x86_64 does not belong to a distupgrade repository ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F31 to F32
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 protobuf-3.6.1-6.module_f32+6163+c0e6dcb2.x86_64 is filtered out by modular filtering ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Non-responsive maintainer: pocock
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 devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning fluxcapacitor
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 decided I don't want to spend my time on it any more. 1. It fails to build in Rawhide and F32. The new GCC throws errors about function signature mismatches between glibc's functions and the "fake" libc functions that Fluxcapacitor provides. [2] 2. The program uses Python2 for testing. While tests aren't strictly necessary to build it, I'd rather not just disable them and call it a day. If anyone is interested in picking this up, feel free to fire a releng ticket (I have already transferred package ownership to orphan). [1] https://src.fedoraproject.org/rpms/fluxcapacitor [2] https://bugzilla.redhat.com/show_bug.cgi?id=1799347 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1805234 ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64
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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Mass Rebuild
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 use the
%{fpc_arches} macro defined there).
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [fedora-arm] Re: Fedora 32 Mass Rebuild - fpc bootstrap on aarch64
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 binary comes from", then I've cross-compiled it (as described above) on my x86_64 machine. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Mass Rebuild
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 -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/packages/fpmkunit/units_bs/aarch64-linux -Fu/builddir/build/BUILD/fpcbuild-r1430/fpcsrc/rtl/units/aarch64-linux -k"--build-id" /usr/bin/ld: /usr/lib64/libc_nonshared.a(elf-init.oS): in function `__libc_csu_init': (.text+0x38): undefined reference to `_init' ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Mass Rebuild
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 3.2.0-beta from the latest SVN revision. That's the main reason for this lag. Sorry once again. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lagging system with latest kernels
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 Firefox or do some editing in LibreOffice. To be fair, I'm not sure if this is a general issue, or one that manifests itself only on certain hardware, or if it's just a sign that my laptop's SSD is slowly dying, since I also have a tower PC and I'm yet to see this happening there. Either way - the laptop is a Thinkpad X220 with a Samsung SSD PM810 (256GB). ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: couldn't compile vdr-epg-daemon-1.1.147 on rawhide - python: Command not found
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 Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Looking for co-maintainers for blueman
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 such, I want to ask if anyone would be interested in co-maintaining the package and trying to tackle some of the Bugzilla tickets. Thanks in advance, A.I. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning nm-tray
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 don't recall ever tinkering with those, so if my memory serves me right, LXDE does not use nm-tray, choosing nm-applet instead. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0
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 architectures to FPC would
require updating fpc-rpm-macros, and that would make all dependent packages
fail to build, since the new-arch builds would fail with "Package not found:
fpc" until we got FPC available on those.
___
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://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Free Pascal Compiler 3.2.0
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 -- 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned paper-icon-theme
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 Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]
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? Generic LCD/LED monitors does not suffer from this >issue. I never shut down my monitor for years and it works fine. The monitor damage is not the issue here; it's just a possible side effect of the issue. As Chris mentioned earlier - consider a battery-powered system, which will just wait for the password until the battery discharges completely. This behaviour simply isn't sensible, in my opinion, and - forgive the phrase - smells of "works for us, so why bother?" thinking. ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Please help with youtube-dl and possibly other packages of mine.
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: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Mass rebuild with cpio issue ?
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 error? ___ 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://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Problem with cmake's PythonInterp in F29 and F28
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. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Problem with cmake's PythonInterp in F29 and F28
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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Problem with cmake's PythonInterp in F29 and F28
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 the lookaside cache. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Problem with cmake's PythonInterp in F29 and F28
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:
>BUILDSTDERR: CMake Error at
>/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
>BUILDSTDERR: Could NOT find PythonInterp: Found unsuitable version "1.4",
>but required
>BUILDSTDERR: is at least "2.7" (found
>BUILDSTDERR:
>/builddir/build/BUILD/colobot-colobot-gold-0.1.12-alpha/build/%{__python3})
>BUILDSTDERR: Call Stack (most recent call first):
>BUILDSTDERR:
>/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376
>(_FPHSA_FAILURE_MESSAGE)
>BUILDSTDERR: /usr/share/cmake/Modules/FindPythonInterp.cmake:159
>(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>BUILDSTDERR: data/CMakeLists.txt:6 (find_package)
>-- Configuring incomplete, errors occurred!
So, uh, is this in issue with cmake, python3, the project's CMakeLists, or
something totally different?
For anyone interested in the koji builds:
rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215429
fc30: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215430
fc29: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215433
fc28: http://koji.fedoraproject.org/koji/buildinfo?buildID=1215434
___
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: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lazarus 2.0 release - push to Rawhide or wait?
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 devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Lazarus 2.0 release - push to Rawhide or wait?
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 Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Lazarus 2.0 release - push to Rawhide or wait?
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 packages, thus I'd want to avoid just upgrading it to v.2.0 and calling it a day without checking how it affects the dependent packages. I could submit an F30 change proposal, though that would be way past the deadline. On the other hand, putting v.2.0 away until F31 means users will be stuck on the old version for quite some time. I'd be thankful for any input on this dilemma. A.I. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Help needed with meson build for modem-manager-gui
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 Fedora builders. The tl;dr version is that there seems to be some kind of race condition in the build script, and sometimes it will run into a situation where it tries to install a file that hasn't been created yet - this most often happens with translation files. If you want to help out, here's the most recent build log: https://kojipkgs.fedoraproject.org//work/tasks/3908/32513908/build.log Thanks in advance, A.I. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking to give these packages new maintainers
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: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
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. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Organizing a "packager experience" objective and working group
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 a few tools underneath, and it's not always clear which tool is running. This becomes a nuisance when a tool requests a password, since quite often you just get a "Password: " prompt. I think bodhi does exactly that, and every time it does I scratch my head trying to remember if I should provide the GPG passphrase, FAS account password, or something else. - Related to the previous one, error messages could be improved. Recently I had to renew my Pagure token so I could request a new repo. I renewed my token, found the config file, updated it... and nothing changed. Turned out it was the wrong config file - old, legacy location maybe? Don't know. My point is, it'd be helpful if every error that says something like "value X in config is wrong" would also specify which config file it's talking about. - fedpkg clone performs the clone over ssh, instead of HTTPS, so if you're not logged into your FAS account, you get an "access denied" error, which is as amusing as it's irritating, given that the package repos are public. - Now that I've mentioned it, maybe we should add something like "fedpkg fas-login"? Personally I've put "alias koji-init='kinit my-fas-acco...@my-domain.org'" in my .bashrc, because looking up how to solve the "koji says I'm unauthenticated" error got boring after the third time. Cheers, A.I. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 1 week)
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 Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
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 package it anew when I have the time. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does extended F30 cycle mean for F29?
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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OKQNYF6AL5WVHIQB7G3MLIYFUXO37U2Z/ ...which gives F19 a 19-month support window. I wasn't a packager back then, so it may be easy for me to say this, but either way - I agree with Kevin Koffer. The current Release Life Cycle states that release N is supported for one month after N+2 is released. This is a promise we make to our users, and breaking this promise would be a very nasty thing to do. If we arrive at the conclusion that we don't have the manpower to extend F29's support window past the usual 13 months, then I argue that we should NOT prolong the F30 development cycle. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: hibernation — does it work for you?
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 normal operation - but overall, it worked fine. Thinkpad X220: usually works fine. I haven't kept a track of any kind, but generally the issues I had were one of two types: - Ridiculously long time to hibernate. Once I actually noted the hour when I pressed "hibernate" on the keyboard and compared it to when the machine powered off - and it was an astonishing 8 minutes. - Similarly to the point above - long time to awake. This always took the form of the kernel loading the image just fine (and with normal speed), X11 showing up on my screen... and it's all frozen. The system could then take anywhere from 2 seconds to 4 minutes until finally - for lack of a more accurate description - the userspace woke up, and then everything continued working normally as if nothing happened. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Looking for whom to pass the vessel for maitaining youtube-dl
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 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: dokuwiki packagers unresponsive
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 issues and leaving it out of date leaves users vulnerable to security bugs. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 30 System-Wide Change proposal: Remove the Group: Tag From All Packages
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 wouldn't it make more sense to put the "doesn't have a Group: tag" check in fedora-review, instead of rpmlint? ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/53QWKJZPB325VSAWBMLBM2O46HYW63VE/
Re: dokuwiki packagers unresponsive
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 package to the newest version in the following
week. I also think we should drop the "Version: 0; Release:
XY.%{upstream_date}" versioning, since upstream has been consistent in using
release dates as version numbers - I'd switch to "Version: %{upstream_date};
Release: XY" (where XY is your normal bump-after-every-change RPM Release
number).
___
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: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSQ634I5RTHBXC6UU32SSAP4HHILOEWW/
Re: Include qt5pas subpackage to lazarus package
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 -- 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C4VLPBHSBSAF6VRCAZ72O7QOHR5FP6GY/
Re: Include qt5pas subpackage to lazarus package
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 introducing a new package this way is a good idea - hopefully someone with more experience can say something about this. Once again, sorry for not taking care of this sooner. A.I. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DBM2A4O6SD7YMZVQ2IX3RNO5GWGJ7M3G/
Re: dokuwiki packagers unresponsive
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 -- 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J7OG3QNQKJ3ZJKQGAPVT6JCRQTRGARZF/
Re: Source tarballs are being placed in git?
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 a .desktop or an .appdata.xml file (or a systemd .service or whatever) and you add your own. This does not include "new upstream release tarball". I'll try to think of some way to make that more clear and submit a suggestion to change the guide text. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ATPYGXDWE5NUPTSVL7GCBQ2IXOPVLJ4B/
Re: Compilation issue after gcc removal
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 at those two files, the old attr/xattr.h has these lines in it: >#ifndef ENOATTR ># define ENOATTR ENODATA/* No such attribute */ >#endif These are absent in sys/xattr.h, so the compiler rightfully complains that it does not know of ENOATTR. I guess you should either add a patch that replaces usages of ENOATTR to ENODATA, or a patch that adds this define somewhere. ___ 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XDBIKZGW62EI4T3TXH5EOIVHWEW2UZMU/
Re: Which sqlite?
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 upstream site:
https://sqlite.org/download.html
I checked both the Linux and Windows precompiled binaries ("sqlite-tools"
download) and in both cases the binary is named "sqlite3", not "sqlite".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Orphaning ofono
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
Re: Orphaning ofono
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 seems the latest ofono builds for these Fedoras didn't support all architectures, so the mmgui build fails due to unsatisfied dependencies. Would you possibly be willing to unretire ofono, or should I just drop the ofono plugin? I don't know how complicated ofono is and whether I'd be able to unretire and maintain it myself. Thanks, A.I. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25947924 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=25948553 [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=25948505 [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=25948564 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
modem-manager-gui packaging
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 different .so and they're all included in the package. mmgui is smart enough to recognize that a module cannot be used because it's appropriate daemon isn't running, so this isn't a problem by itself. The issue is: the new mmgui version also ships with an ofono plugin and a NetworkManager dispatcher.d script. Shipping these files without having a Requires: on ofono and NM seems dirty to me, but then - requiring all the possible backends would pull in unnecessary packages. I could separate the backends into individual packages, but I wonder - how the handle the dependencies, then? What I'd like to achieve is that one of the backends is the "recommended" one, while the others are optional. I'm not very accustomed to the weak dependencies mechanism, so I wonder: would something like "Recommends: mmgui-modemmanager; Suggests: mmgui-ofono mmgui-some_other_ backend" suffice? 2) Both the old and the new version install a polkit policy (in /usr/share/polkit-1/actions). fedora-review says that even with a "Requires: polkit", the directories have no known owners. 3) Similarly to the above - the package installs some help files in /usr/share/help. These are available in a couple languages. fedora-review says that some of the language directories (like /usr/share/help/pl) are unowned. I ran "dnf provides" and it looks like a few other packages that ship help files simply declare themselves are owning these directories. Should I do the same? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Lazarus vs. FPC updates
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 send an email to devel-le...@lists.fedoraproject.org
Re: Lazarus vs. FPC updates
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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Lazarus vs. FPC updates
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 you install Lazarus compiled with FPC v. X.Y.Z, while you have FPC v. A.B.C installed, things are prone to break. Now, I have submitted an update for FPC. When this update is pushed to stable, it will probably break Lazarus for some use cases, as detailed above. Is there any way I can perform a koji build for Lazarus using the not-yet-stable version of FPC, so I could then push both of them into bodhi as a single update? Or would my best course of action be to change Lazarus's "Requires: fpc" to a fully-versioned dependency, with a comment explaining why I did that? As far as I can see, previously this wasn't an issue, since joost (fpc & lazarus maintainer) didn't usually perform FPC & Lazarus updates, preferring to build new versions in Rawhide / early branched and have them roll out with the next Fedora release. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
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
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
> 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 email to devel-le...@lists.fedoraproject.org
Re: to batch or not to batch?
> 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 might be a good idea to flush the "batch queue" when a package is explicitly pushed to stable by someone. This won't increase the number of metadata expirations - so there isn't really any drawback to end users - while allowing updates to reach users faster. > + batching reduces the number of times repository metadata is updated. > Each metadata update results in dnf downloading about 20-40 mb, > which is expensive and/or slow for users with low bandwidth. As someone with a rather small data cap, I'd say that heavy metadata downloads during "dnf update" are acceptable - since I can just choose to run "dnf update" only once a week or so. But it always irks me a bit when I want to install a new package and dnf starts downloading the repository metadata again. Bandwidth issues aside, it's just incredibly annoying having to wait for a 40MiB download to complete before I can fetch a single 600KiB package. > - batching delays updates of packages between 0 and 7 days after > they have reached karma and makes it hard for people to immediately > install updates when they graduate from testing. I agree with Jerry here - many packages don't get any karma while testing. The only time my packages received testing karma was when I was introducing new packages; didn't happen for updates. So having the package sit in limbo for another week after going through a week of "maybe someone'll take a look at this" is a bit discouraging. > One of the positive aspects of batching — reduction in metadata downloads, > might be obsoleted by improving download efficiency through delta downloads. > A proof-of-concept has been implemented [4]. This could be a rather interesting feature, as it'd resolve some of the issues I wrote two paragraphs above. By the way - does drpm handling depend on repo / mirror settings? I ask because I'm under the impression that lately hardly any package update on my system is done via delta-RPMs; it's about 1-in-100 or so. Is this more a matter of me needing to tweak dnf config, or can this depend on the package mirrors? A.I. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Non-responsive maintainer: joost
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. Alternatively, if you don't feel like taking over the maintainer responsibilities, I would be willing to become the new maintainer for FPC and Lazarus. Thanks for your work. A.I. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Build fails on s390x - complains about missing /usr/lib64/lib*.so* file
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 build process) not
recognizing s390x's bitness properly, thus installing the .so files in the
wrong directory.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Need help debugging hedgewars
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 finished running; debugging with gcc says the error occurs at "dl-error-skeleton.c:187", which is part of glibc. I've contacted a friend of mine to compile the game on Debian (which uses the same version of FPC) and his binary didn't display this problem. What's even more interesting, when I e-mailed him a binary I've compiled on Fedora, it also exited cleanly. If anyone would like to help us get some more data points, you can try downloading Colorful source and compiling it: https://github.com/suve/LD25/tree/devel-2.0 I'll be thankful if anyone can report being able to recreate the error or come up with some clues for its origin. Regards, A.I. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Some wiki notes
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 explains the process, requires some time to understand it properly. Could we rewrite it so the user can get all the info from the wiki page? Sorry if this is the wrong mailing list and I should post this elsewhere. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package name conflict
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 - but as Dominik noted, it's probably best to ask on the fedora-legal list. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Request to package: jid - JSON incremental digger
>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
Request to package: jid - JSON incremental digger
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Packages giveaway
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
Re: Raising requirement for application icons in GNOME Software
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? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Debuginfo problem with fpc
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 +++ patched/src/cqrlog.lpi 2017-09-13 20:02:20.760625562 +0200 @@ -725,6 +725,12 @@ + + + + + + ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Debuginfo problem with fpc
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: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NFJPGB6HIXCK3AUKBZKYPBWZ6YOAZOZ7/ As for your problem - you can try patching the Lazarus project file, so the compiler gets passed the "-gw" switch. At this moment I'm a tad busy, but if you have problems, I should be able to take a look at the package and send you a patch file later in the evening. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Adopting modem-manager-gui
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 adopt the package. Even though upstream seems to be no longer maintaining the software, it works okay (at least on my machine). I imagine a handful of people may find it useful. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
> 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
Re: find-debuginfo fails for fpc-compiled software on i686 and armv7hl
>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 debuginfo, the koji build completes just fine: https://koji.fedoraproject.org/koji/taskinfo?taskID=21089412 Either way, I've read the Bugzilla ticket linked to by Igor and it seems that on i686, fpc defaults to stabs debuginfo, so using the "generate DWARF debuginfo" compiler switch is (currently) the preferred solution to the problem. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
find-debuginfo fails for fpc-compiled software on i686 and armv7hl
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):
https://koji.fedoraproject.org/koji/taskinfo?taskID=20981009
On x86_64 and ppc64, the package builds fine. On i686 and armv7hl, this happens:
> extracting debug info from
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> Stabs debuginfo not supported:
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> gdb-add-index: No index was created for
> /builddir/build/BUILDROOT/colorful-1.3-3.fc27.arm/usr/bin/colorful
> gdb-add-index: [Was there no debuginfo? Was there already an index?]
[ snip ]
>RPM build errors:
>error: Empty %files file
>/builddir/build/BUILD/LD25-e5ecbe39b719f12a1268bcc641eae9ba364221c9/debugsourcefiles.list
I thought this may be a bug with the package, but then I saw that koji builds
for a new fpc-compiled package that I've been working on lately (not yet
submitted for review) suffer the same problem. This one is worse, even, since
find-debuginfo fails with a coredump.
https://koji.fedoraproject.org/koji/taskinfo?taskID=21087076
>extracting debug info from
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>extracting debug info from
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
>Stabs debuginfo not supported:
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-qt
>Stabs debuginfo not supported:
>/builddir/build/BUILDROOT/peazip-6.4.1-3.fc27.i386/usr/bin/peazip-gtk
>dwz: dwz.c:1984: checksum_die: Assertion `((!op_multifile && !rd_multifile &&
>!fi_multifile) || cu != die_cu (ref)) && (!op_multifile || cu->cu_chunk ==
>die_cu (ref)->cu_chunk)' failed.
>/usr/lib/rpm/find-debuginfo.sh: line 518: 8822 Aborted (core
>dumped) dwz $dwz_opts ${dwz_files[@]}
I checked the build & updates status for fpc and there haven't been any updates
to the package lately, so this definitely isn't a regression in the compiler.
Have there been any recent changes to find-debuginfo that may be causing this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package suggestions
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 licence which forbids modification; redistribution is allowed only when keeping everything as it was originally released. That's not FLOSS, but as Zbigniew mentioned, it fits the shareware/firmware packaging guidelines. Still, we want to play it safe to wait for input from the legal folks. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Outdated %fpc_arches macro?
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
copy-pasted the following line:
"ExclusiveArch: %{arm} %{ix86} x86_64 ppc ppc64"
Copy-pasting is a bit iffy, so I wondered if there's a better solution. I
browsed Bugzilla and encountered the following ticket:
https://bugzilla.redhat.com/show_bug.cgi?id=1247925
The last comment in the ticket says that there's an %{fpc_arches} macro that
can be used instead. So I went ahead and changed that in my spec file:
"ExclusiveArch: %{fpc_arches}"
I then submitted my package for a scratch build in koji and noticed that in the
task descendants list, ppc64 is missing. I ran "rpm --eval '%{fpc_arches}'" in
my terminal and I got back:
"i386 i486 i586 i686 pentium3 pentium4 athlon geode armv3l armv4b armv4l
armv4tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl x86_64"
As can be seen, ppc64 is missing from the list. Is this a case of the macro
having an outdated value, or am I doing something wrong?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package suggestions
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 send an email to devel-le...@lists.fedoraproject.org
Re: Package suggestions
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 and unmodified." Is that enough for Fedora, and if yes - what should the License tag for the package say? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Package suggestions
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 World" game recreating "Chip's Challenge"? While it has fan-made level packs, it can also be used with the original game's data - I wonder what Legal's opinion on that would be. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Self introduction: Artur Iwicki
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 utility. - https://bugzilla.redhat.com/show_bug.cgi?id=1433749 - https://bugzilla.redhat.com/show_bug.cgi?id=1441813 I've been using Fedora since F13 and so far I've had a really good experience. I'd like to give back to the project and I guess adding new software might be one way to do so. I could possibly help with maintaining other packages, if needed. Best wishes, A.I. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
