Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

[Artur Frenszek-Iwicki]

> I have no strong opinion how to process with the case of
> "MIT and BSD and Bitstream Vera and OFL". I think that 
> converting it to " MIT and BSD and Bitstream-Vera and OFL"
> is probably best option.
I'll go on a tiny bit of a tangent here: SPDX spec says that
license expression operators (AND, OR, WITH) should
be matched in a case-sensitive manner. [0]

If we're going to introduce any kind of (semi-)automatic
conversion of existing license tags, I think it'd be good
to make "convert «and» and «or» to upper-case"
part of the process.

A.FI.

[0] 
https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d2-case-sensitivity
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild problem with rust code

[Artur Frenszek-Iwicki]

https://doc.rust-lang.org/reference/attributes.html
If I understand this page of The Rust Reference correctly,
then moving the #![no_std] attribute from the first line of the file
shouldn't break anything. So you can try side-stepping the issue
by patching the file and adding "// lol pointless comment" at the top.

A.FI.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

pipewalker license change: "GPL-3.0-or-later" to "MIT"

[Artur Frenszek-Iwicki]

Hi all,

the pipewalker package [0] has been updated to the latest release, v1.0. [1]
This release includes a re-licensing of the code from GPL-3.0-or-later to MIT.

pipewalker is a leaf package, so this shouldn't affect anyone.

A.FI.

[0] https://src.fedoraproject.org/rpms/pipewalker
[1] https://github.com/artemsen/pipewalker/releases/tag/v1.0
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

qmltermwidget license correction

[Artur Frenszek-Iwicki]

Hi all, the license tag on qmltermwidget [0] has been corrected from:
GPL2+
to
GPL-2.0-or-later AND LGPL-2.0-or-later

The only two consumers of this package in Fedora repos are:
- cool-retro-term
- qmlkonsole

Cheers,
A.FI.

[0] https://src.fedoraproject.org/rpms/qmltermwidget
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fritzing: moving file generation from build phase to scriptlets

[Artur Frenszek-Iwicki]

Hi all,

I've been maintaining Fritzing, the electronic design software [0]
for some time now. Currently, the program is split into two packages:
"fritzing", providing the executable; and "fritzing-parts", a noarch
package providing data files, including the parts database.
The parts database is generated by running the freshly-built
executable with a specific set of command-line options. [1]

Currently, both packages are built from the same spec file,
and the "executable" package pulls in the parts package, requiring it
to be the exact version-release as in the spec. Lately, I was thinking
about splitting them into separate packages. This would better reflect
the upstream approach, where the program features an auto-updater
that can fetch the latest version of the parts set from git. [2]

However, there's one problem here: the parts database file. Since
there isn't any guarantee that the file will be compatible between
program versions, generating it during the parts package's build
seems a rather risky move. Hence, I got this idea: would it be
sensible to move this to a scriptlet?

Basically, the way I'd see it working would be like this:
1. User installs the "fritzing" package
2. This package pulls in "fritzing-parts" (without requiring
   any specific version)
3. The scriptlet to generate the parts database file
   is run locally on the user's machine

This seems to me like a fairly okay idea, though it would also need
to feature a mechanism where the database file is re-generated
each time any of the two packages is upgraded (or downgraded).

So my two questions here are:
1) Does this seem like a good idea in general?
2) How would one go about implementing this?
   I don't have any experience with scriptlets, unfortunately.

Any opinions and help will be appreciated.
Thanks in advance.

A.FI.

[0] https://fritzing.org/
[1] 
https://src.fedoraproject.org/rpms/fritzing/blob/5f47978fc9965cdc510031b5b2383b061522ad4b/f/fritzing.spec#_124
[2] 
https://github.com/fritzing/fritzing-app/blob/8f5f1373835050ce014299c78d91c24beea9b633/src/version/partschecker.cpp
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packaging guidelines - validation of AppStream metadata files

[Artur Frenszek-Iwicki]

> Ultimately, appstream-util's output is what matters since we use
> appstream-builder (from appstream-glib) to generate our AppStream
> metadata index. If it doesn't pass that tool, it doesn't show up.
Bit of a tangent, but: is this documented anywhere?
Because if if is, then I can't find it.

Without docs, the whole process is a black box.
I recall that a few years ago an announcement
was made saying that apps need to provide
at least a 64x64 icon to show up in the index;
once again, I can't find any reference to that
apart from the mailing list history. This makes
figuring out why an app doesn't show up
in Gnome Software a frustrating experience.

To be clear, I don't want this to be a "someone
do something" kind of message. I'd be happy
to document this myself! But I have zero
idea what's actually going on.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Artur Frenszek-Iwicki]

> Problem 1: package libblockdev-vdo-2.24-2.fc32.x86_64 from @System requires 
> libbd_utils.so.2()(64bit), but none of the providers can be installed
>   - libblockdev-utils-2.28-5.fc38.x86_64 from @System  does not belong to a 
> distupgrade repository
>   - problem with installed package libblockdev-vdo-2.24-2.fc32.x86_64

This one had "fc32" on it, and we allow Obsoletes to be removed after 2 
releases, so dunno if we want do anything about it.

Either way, after manually removing said package, there were no other problems.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 39 Mass Rebuild

[Artur Frenszek-Iwicki]

> I just discovered that the fontawesome-fonts package had no commit or
> build either.  I wonder if it has something to do with this error I
> just encountered while preparing an update for the package:
> 
> $ git push
> Source file '60-%{fontpkgname1}.conf' was neither listed in the
> 'sources' file nor tracked in git. Push operation was cancelled
> Hint: this check (.git/hooks/pre-push script) can be bypassed by
> adding the argument '--no-verify' argument to the push command.
> error: failed to push some refs to
> 'ssh://pkgs.fedoraproject.org/rpms/fontawesome-fonts'
> 
> The error is bogus.  Something failed to expand the %{fontpkgname1}
> macro.  I wonder if the mass rebuilder actually made a commit, but the
> push failed.

Interesting. One of my fonts packages was also skipped during
the Mass Rebuild, though in my case, pushing a manual rebuild
later worked fine.
https://src.fedoraproject.org/rpms/daniel-wikholm-segment16-fonts

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Lazpaint license update: "GPLv3 and LGPLv2 and Boost" -> "GPL-3.0-only AND LGPL-3.0-only"

[Artur Frenszek-Iwicki]

Hi,

I have updated the license on the "lazpaint" package. [0]
LazPaint is an image editor, and a leaf package with no dependents.

a) LGPLv2 -> LGPL-3.0-only
I missed upstream switching from v2 to v3 at some point.

b) Dropping Boost
The Boost license is only relevant to some test files,
No files in the built RPM are subject to it, and our
licensing guidelines say that the tag refers
to the contents of the binary RPM. [1]

Cheers,
A.FI.

[0] https://src.fedoraproject.org/rpms/lazpaint
[1] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_field
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 Cinnamon Desktop - LIGHTDM.SERVICE FAIL..!!!!

[Artur Frenszek-Iwicki]

Any more details?
Anything interesting inside /var/log/lightdm?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Announcing fmt library soversion bump

[Artur Frenszek-Iwicki]

> FTBFS:
> easyrpg-player

Upstream has already updated the program to work with fmt10,
so I just applied the relevant commit to the Fedora package.

Submitted and rebuilt:
https://koji.fedoraproject.org/koji/taskinfo?taskID=102705429

A.FI.
___
devel 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Artur Frenszek-Iwicki]

> I've taken ownership of libreoffice for the time being, at least to keep the 
> lights
> on. Co-maintainers, as always, welcome.

Don't know how much time I'll be able to contribute, but you can count me in.
As Mattia suggested, I think it might be a good idea to set up libreoffice-sig.

A.FI.
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to get a rawhide i686 VM?

[Artur Frenszek-Iwicki]

> What is the simplest way to get a rawhide i686 VM?
I think that's no longer possible, as it's been many years since Fedora stopped 
shipping i686 kernels.
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

I guess you could try creating a VM with some other distro, like Debian, and 
running a Rawhide container in it?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - ZX Spectrum edition

[Artur Frenszek-Iwicki]

> Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase 
> ORs.
Yea. I've been reading through the spec lately, since I want to add proper SPDX 
support to my project,
and it says joiners should be uppercase and parsers should match 
case-sensitively.

> License expression operators (AND, OR and WITH) should be matched in a 
> case-sensitive manner.
https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d2-case-sensitivity

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [HEADS UP] update of kiss-fft library with added shared versions

[Artur Frenszek-Iwicki]

> "dnf repoquery --srpm --whatrequires kiss-fft-static" returns nothing,
That's because there's no "kiss-fft-static" package, only "kiss-fft-devel".

Running "dnf repoquery --releasever=39 --disablerepo='*' 
--enablerepo='*-source' --whatrequires kiss-fft-devel" gives me:
- ckb-next-0:0.5.0-4.fc39.src
- opentoonz-0:1.6.0-11.fc38.src

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Artur Frenszek-Iwicki]

Tested on three different machines. No problems with transaction conflicts,
just some package downgrades:
- inxi-3.3.25-1.fc37 -> inxi-3.3.24-2.fc38 (version downgrade)
- fwupd-1.8.10-2.fc37 -> fwupd-1.8.10-1.fc38 (lower release number)

A.FI.
___
devel 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Intending to unretire arptools

[Artur Frenszek-Iwicki]

Hi all,

I intend to un-retire arptools, which is a small collection of Ethernet ARP 
tools.
The package used to be in Fedora repos, but was retired somewhere between F31 
and F32 due to being orphaned.
https://src.fedoraproject.org/rpms/arptools

I looked through the devel list, but couldn't find any info regarding *why* 
it's been orphaned;
either way, it builds and works fine on my machine.

In case anyone's in the mood for a package review, here's the link:
https://bugzilla.redhat.com/show_bug.cgi?id=2170875

I can review some C / C++ / Pascal / PHP / shell stuff in exchange.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

RE: fedpkg: Failed to get repository name from Git url or pushurl

[Artur Frenszek-Iwicki]

> Should that tutorial work?  Is it perhaps obsolete?
I'd say the opposite of obsolete - it's been updated to suggest using
fedpkg all along the way, instead of the old rpmbuild tools. But it
looks like it wasn't tested enough to make sure everything works.

> My newbie understanding is that fedpkg should get the source from the
> Source0 location and then follow the build instructions.
> Is that even close?
This is a bit complicated. When the package is being built, the list
of files is taken from the Source: tags in the spec file. However,
fedpkg keeps a separate file, "sources" (no extension), where it
lists files uploaded to the Fedora build cache. The justification
is that keeping source tarballs in the repository is a bad idea,
since these files can be really large (1GiB+ for game packages),
so they're stored in a cache instead, and the repository contains
only this "sources" file with references to said cache. (That being
said, you totally can store source files in the repo - this is
often done with stuff like non-standard Fedora configs.)

As for the "get the source from the Source0 location" bit - no.
fedpkg will not download stuff from Source: tags for you,
only the files listed in the "sources" file.

Since my impression is that you want to start experimenting with
RPM packaging in general, and not specifically fedpkg - I'll do
a bit shameless self-promotion and link to an article
on RPM packaging that I wrote some time ago:
https://blog.svgames.pl/article/basics-of-rpm-packaging

In this article, I show how to build RPM packages using the traditional
rpmbuild workflow. If you're just starting out with writing specs
and such, it should get you started enough to make switching
to fedpkg later down the road a no-brainer.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Artur Frenszek-Iwicki]

> Is there another argument to fedpkg?
fedpkg has a --name argument, you can try using that.

Alternatively, if you're just taking your first steps with packaging, you can 
try:
$ rpmbuild -bs path/to/your.spec
$ mock path/to/file-created-by-previous-command.srpm

This will first build an SRPM ("source rpm"), and then build it in mock,
which is pretty much exactly what "fedpkg mockbuild" does.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaning lizardfs

[Artur Frenszek-Iwicki]

Fixing the FTBFS is rather trivial (yet another victim of GCC13 header 
shenanigans)
and I've already created a patch for this, but I didn't want to pick up the 
package since
upstream activity since rather low. If you're saying that the project isn't 
dead yet,
then I'd be willing to pick this up either as main maintainer or as 
co-maintainer.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: FPC repackaging (Self-Contained Change proposal)

[Artur Frenszek-Iwicki]

fpc has a Requires: on the units package, so it should always be installed.

The build failures for packages using FPC, as far as I can see, are all packages
using Lazarus. As far as I can tell, this is because Lazarus seems to quite 
tightly
depend on specific FPC versions, and historically, whenever we updated/rebuilt
FPC, we also rebuilt Lazarus. This time I completely forgot to do this.

I may be wrong here, but I'm like 99% sure that, since Lazarus was eventually 
rebuilt
during the Mass Rebuild, once lazarus-2.2.4-2.fc38 lands in the rawhide 
buildroot,
it should be possible to resubmit any failed packages as-is and they'll work 
this time.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Artur Frenszek-Iwicki]

> cqrlog - Fails for some weird lazbuild issue I don't understand
This is most likely my fault, since Lazarus seems to be quite tightly coupled 
to specific FPC versions.
Historically, whenever we updated/rebuilt FPC, we'd also rebuilt Lazarus. This 
time, when I rebuilt
FPC as part of the repackaging change [1], I completely forgot about rebuilding 
Lazarus as well.

Since Lazarus eventually got rebuilt as part of the Mass Rebuild, I expect that
once lazarus-2.2.4-2.fc38 becomes available in the rawhide buildroot,
it should be possible to just re-submit the failed builds and they'll work this 
time.

Sorry about the mess.
A.FI.

[1] https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild is finished

[Artur Frenszek-Iwicki]

I wanted to resubmit one of my failed builds, but the buildroot seems to be 
broken currently:

> Problem 1: package python3-dnf-4.14.0-2.fc38.noarch requires libmodulemd >= 
> 2.9.3, but none of the providers can be installed
>  - package libmodulemd-2.14.0-5.fc38.x86_64 requires 
> libglib-2.0.so.0()(64bit), but none of the providers can be installed
>  - package libmodulemd-2.14.0-5.fc38.x86_64 requires 
> libgobject-2.0.so.0()(64bit), but none of the providers can be installed
>  - package dnf-4.14.0-2.fc38.noarch requires python3-dnf = 4.14.0-2.fc38, but 
> none of the providers can be installed
>  - package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit), but 
> none of the providers can be installed
>  - conflicting requests
>  - nothing provides libunistring.so.2()(64bit) needed by 
> gnutls-3.7.8-11.fc38.x86_64
> Problem 2: package python3-dnf-plugins-core-4.3.1-2.fc38.noarch requires 
> python3-dbus, but none of the providers can be installed
>  - package python3-dbus-1.3.2-2.fc38.x86_64 requires 
> libglib-2.0.so.0()(64bit), but none of the providers can be installed
>  - package dnf-plugins-core-4.3.1-2.fc38.noarch requires 
> python3-dnf-plugins-core = 4.3.1-2.fc38, but none of the providers can be 
> installed
>  - package glib2-2.74.1-3.fc38.x86_64 requires libgnutls.so.30()(64bit), but 
> none of the providers can be installed
>  - conflicting requests
>  - nothing provides libunistring.so.2()(64bit) needed by 
> gnutls-3.7.8-11.fc38.x86_64

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 mass rebuild started

[Artur Frenszek-Iwicki]

So I'm sure this question has been asked during previous Mass Rebuilds,
but I can't find the answer in the heaps of messages in my mailbox,
so I'll ask again: if my package failed to build during the Mass Rebuild
and I know how to fix it - I don't have to wait for the rebuilt to end,
right? I can just go ahead, push the changes to dist-git and trigger a build.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: FPC repackaging (Self-Contained Change proposal)

[Artur Frenszek-Iwicki]

Haven't planned on this originally, but it seems like a good idea.

Never really used Obsoletes before, so I have to ask:
what's the dnf behaviour when a package is obsoleted by multiple packages?
If it tries to install all of them, then that'd be okay. I'd like to
avoid a situation where dnf decides that it prefers to upgrade by
removing the "old" fpc package and installing only fpc-ide.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Use cases for 'fedpkg scratch-build'

[Artur Frenszek-Iwicki]

> At least in my workflow, I only do scratch builds before pushing,
> to ensure that what I am about to push builds correctly in Koji.
Same here. Some of my packages are prone to break and in need
of patching on non-x86_64, so that's my main use case as well.

Never used "fedpkg scratch-build" since I didn't even know it
existed, but yes, having it be equivalent to "fedpkg srpm &&
koji build --scratch ..." would make sense to me.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Artur Frenszek-Iwicki]

> So you can do
> $ eval `rpm -E '%set_build_flags'`
> in a script to set the flags that RPM uses.
Another solution could be something like:
$ gcc $(rpm -E '%optflags') ... $(rpm -E '%build_ldflags') 

A.FI.
___
devel mailing list -- devel@lists.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Can we retire glib, gtk+, bubblemon, manedit and xconvers ?

[Artur Frenszek-Iwicki]

fpc (the Free Pascal Compiler) also ships with units for developing stuff
with gtk1 - so should we retire gtk+, we'll probably want to patch fpc
so said units are not shipped.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Artur Frenszek-Iwicki]

> eurekaorphan   2 weeks ago

I have a soft spot for classic DOOM, so I took this one.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

colorful license change

[Artur Frenszek-Iwicki]

Hey all,

colorful had a new major release, v2.0, which brought in a licensing change.
I took this as an opportunity to also migrate the License: tags to SPDX.

Old v1.3 license: zlib with acknowledgement

New v2.0 licenses:
- colorful: GPL-3.0-only AND (MPL-2.0 OR Zlib)
- colorful-data: zlib-acknowledgement

Cheers,
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Playing with cross-compilers for FPC

[Artur Frenszek-Iwicki]

> b) Instead of using the default config file, ship a custom one that makes
>the compiler always look in /usr/lib64/ on 64-bit arches
>and /usr/lib/ on 32-bit arches.
I took another look into this and contrary to what I wrote in my previous
message, it turns out we *do* already ship a custom config file (or rather,
a custom template). As such, this is a non-issue; I just need to fix the
template.

Cheers,
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Playing with cross-compilers for FPC

[Artur Frenszek-Iwicki]

Hey all,

I've been maintaining the Free Pascal Compiler [0] in Fedora for some time now.
A couple of times I played around with the idea of building and packaging FPC
cross-compilers. Lately I gave it another go and arrived and some quite
workable results. If you're interested, you can check them out in COPR. [1]

During the process of packaging the cross-compilers, there were a couple of
issues I came across and wanted to ask for some opinion/guidance.


1. Separate package or not
The most basic issue would be whether the cross-compilers should be built from
a separate SRPM, or be a part of the main package. For both possibilities,
I see some pros and cons.

Cross-compilers in one package:
+ Everything's in one place
+ The cross-compilers are built from the same source
- Main .spec file becomes way more complicated
- Package for native compiler can get blocked by cross-compilers not building

Separate package for cross-compilers:
+ The spec for the native compiler can remain relatively simple
+ Worst case scenario, we can ship an updated version of the native compiler
  and fix cross-compiler errors later
- A lot of duplication between native and cross .spec file
- Need to track sources/patches from main package in the cross package,
  comes with a risk of things de-syncing

Personally I'd favour the "separate package" approach.


2. Naming - base name
Yes, the eternal problem. So far, I went with naming the cross-compiler package
"fpcross", which reflects what upstream does - e.g. if the native compiler
for aarch64 is "ppca64", the cross-compiler is "ppcrossa64".

I wonder if using "fpc-cross" would be more readable. Yet another solution
would be to hide the native/cross distinction and use "%package -n" to build
cross-compilers with just the "fpc-" prefix.


3. Naming - per arch
So far, for simplicity, I went with naming the cross-compilers
"fpcross-${ARCH}", e.g. "fpcross-aarch64", with packages for MS Windows
being named "fpcross-win32" and "fpcross-win64". Looking at some other
packages (like binutils), I wonder if it would be better to use the arch+os
format, like "fpcross-i386-linux" and "fpcross-i386-win32".


4. Configuration
FPC uses a configuration file, located at /etc/fpc.cfg (it can be overridden
by a user creating a file at ~/.fpc.cfg, but that's beside the point).
Inside said config file, there's this problematic bit:

#IFDEF CPU64
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/rtl
#ELSE
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
#ENDIF

This tells the compiler that, when compiling for 64-bit targets, it should
look for unit files in "/usr/lib64/fpc/...", and when compiling for 32-bit
targets, to look in "/usr/lib/fpc/...". The problem here is that this is
based on the *target* architecture, not the *host* architecture, so
cross-compiling from x86_64 for i386 will have the compiler look in /usr/lib/
instead of /usr/lib64/. Which brings the following dilemma:

a) Install stuff required to cross-compile for 32-bit targets in /usr/lib/,
   instead of the more appropriate /usr/lib64/. 
   
b) Instead of using the default config file, ship a custom one that makes
   the compiler always look in /usr/lib64/ on 64-bit arches
   and /usr/lib/ on 32-bit arches.

I think that from a packaging perspective, b) would be cleaner,
though it adds yet one more thing that needs maintaining.


Let me know what you think.

Cheers,
A.FI.

[0] https://src.fedoraproject.org/rpms/fpc
[1] https://copr.fedorainfracloud.org/coprs/suve/fpcross/
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Artur Frenszek-Iwicki]

> - rpms/fpc
> - rpms/lazarus
I've been a co-admin on those, so I took 'em.

Several of the orphaned packages are dependencies of stuff I currently maintain.
I'll wait a week or two to see if anyone else wants to take them.

A.FI.
___
devel mailing list -- 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Building two conflicting binaries from the same source

[Artur Frenszek-Iwicki]

Hello, Bojan.

The only way I know is to utilise the "RemovePathPostfixes" tag for this, e.g:
> %package gtk3
> RemovePathPostfixes: .gtk3
> 
> %package qt
> RemovePathPostfixes: .qt
> 
> %files gtk3
> %{_bindir}/%{name}.gtk3
> 
> %files qt5
> %{_bindir}/%{name}.qt5
Then, you just need to rename the binaries appropriately during %install.

If you want to read more, I originally learned about it from the following post:
https://www.pixelbeat.org/docs/conflicting-rpms.html

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Dual licenses question

[Artur Frenszek-Iwicki]

> Would that imply I have to add the LGPL license text to the package myself?
The packaging guidelines state that the desired course of action
is to contact upstream and ask them to provide the licence text.
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

For what it's worth, the typical licence header for LGPL includes this bit:
> You should have received a copy of the GNU Lesser General Public License
> along with this program. If not, see .
So personally, I'd start by submitting an issue upstream and asking for 
clarification.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SRPM macros, EPEL, and side tags

[Artur Frenszek-Iwicki]

I took a look at epel-rpm-macros. Interestingly, in EPEL9,
the package has "Recommends: fpc-srpm-macros". [0]
Despite this, when I try building in the side tag,
the package isn't pulled in. I guess koji is configured
not to pull in weak deps?

Anyway, I've opened a PR on epel-rpm-macros
to change this to a hard Requires. [1]

Thanks for the help, everyone.
A.FI.

[0] 
https://src.fedoraproject.org/rpms/epel-rpm-macros/blob/ee11dd5032353996377a47212cbdbc7af3ec04da/f/epel-rpm-macros.spec#_24
[1] https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/53
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

SRPM macros, EPEL, and side tags

[Artur Frenszek-Iwicki]

Hi all,

some time ago I've built the Free Pascal Compiler [0] for EPEL9,
and recently I got the idea it might be good to do the same with
the Lazarus IDE [1]. Testing things locally with mock,
I realized that Lazarus used a macro from fpc-srpm-macros [2],
which hasn't been built for EPEL9 yet.

No biggie, I thought. I created a side tag, built fpc-srpm-macros there,
then added "BuildRequires: fpc-srpm-macros" to the Lazarus spec
and tried building it in the side tag. The build failed, and looking at
root.log, the fpc-srpm-macros package was not installed [3].

So I guess my question is, did I do something wrong,
or do srpm-macros packages need to be explicitly added to the buildroot?

Thanks in advance,
A.FI.

[0] https://src.fedoraproject.org/rpms/fpc
[1] https://src.fedoraproject.org/rpms/lazarus
[2] https://src.fedoraproject.org/rpms/fpc-srpm-macros
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=92624197
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned firejail

[Artur Frenszek-Iwicki]

Hi, Petr.

I use firejail every now and then, and glancing at the commits, 
the package doesn't require much maintenance, so I adopted it.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Check out the Fedora Packager Dashboard!

[Artur Frenszek-Iwicki]

> Sounds like you need to clear your browser cache or something
Yeah, looks like it. I refreshed the page via F5 and it didn't help.
Doing a full page reload via Ctrl+R helped.

> According to your description, your browser might be broken,
> perhaps due to some content blocking?
> See this screenshot, there are symbolic icons everywhere
The icons are loaded from fontawesome's domain,
not fedoraproject's, which made NoScript block them.

So oops, I done goofed. But hey, at least I got
to see the improvements immediately! :-)

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Check out the Fedora Packager Dashboard!

[Artur Frenszek-Iwicki]

While I really like the idea, I find the interface to be... how do I put it?
Non-obvious and not very discoverable.

For example, at the top of the page, there's a bunch of numbers. I have no idea 
what they mean.
Hovering over each of these displays a tooltip - which is nice - but five 
seconds after that tooltip disappears,
I'll forget the meaning and the numbers will go back to being visual clutter. 
It would be immensely helpful
to have some symbolic icons next to the numbers, which would allow to easily 
guess what each of them means.
Right now I pretty much have to memorize the layout.

The same goes for the comment/karma numbers and priority markings on the list 
of bugs.
Although here it's actually a bit worse, since my browser doesn't display the 
tooltips
and I had to use the dev tools to take a look at the underlying HTML to make 
sense of it.

Similarly, at the top of the page, I get a banner that informs me about FAS 
integration and says:
> After linking the dashboard with your FAS through the settings menu...
Which is all nice and dandy, but doing a Ctrl+F on the page for "settings" 
gives exactly one match -
that being the text in the banner. So there's no visible link to said "settings 
menu" anywhere.
How do I access it?

All in all, while this is a very useful project, the current UI makes it hard 
to make the best of it.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Review swaps

[Artur Frenszek-Iwicki]

Hey all, 

I have two packages which have been sitting in review for some time now:

https://bugzilla.redhat.com/show_bug.cgi?id=2095732
daniel-wikholm-segment16-fonts - collection of 3 font families.
Bit problematic because of missing license text, not having an official source 
website, nor a way to contact the author.

https://bugzilla.redhat.com/show_bug.cgi?id=2098373
gearhead2 - an RPG game, written in Pascal, using SDL1.2.
Fairly straight-forward. The prequel, gearhead1, is already in the repos, and 
the spec files are very similar.

If anyone could take a look at one of these, I'd be grateful.
I'm willing to review some C, C++, Pascal or shell stuff in return.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is system upgrade automatic or not?

[Artur Frenszek-Iwicki]

> Major version updates often change behaviour of the apps or the system itself
It's also worth mentioning that if some packages are retired, they will not be
available in the new Fedora version. In the old days, this would mean you
might get some old & broken packages stuck on your system; nowadays,
fedora-obsolete-packages is used to auto-remove these upon system upgrade.

Personally, I'd be *very* angry if an automatic update removed some programs I 
still use,
with no easy way of getting them back. (Well, you can still grab Fedora (N-1) 
builds
from koji and install them manually, but 1: that often doesn't work because of 
broken deps,
and 2: OP's concern is to have a newbie-friendly solution, which this isn't.)

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedora-review of m3u8 fails

[Artur Frenszek-Iwicki]

In the spec, you have this:
> %setup -n %{module_name}-%{version}

The error message looks like this:
> /usr/lib/rpm/rpmuncompress -x -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz
> rpmuncompress: -v/builddir/build/SOURCES/m3u8-3.1.0.tar.gz: unknown option

On first glance, this looks like a bug in the definition of the "%setup" macro.
Pretty much every packaging tutorial I've seen recommends using the "-q" option 
with "%setup",
which is the "quiet" option. "Verbose" seems like the logical opposition to 
"quiet",
so I guess what happens when you're not passing "-q" to "%setup",
is that it tries to decompress the archive verbosely by passing "-v" to 
rpmuncompress.
Except that, since there's no space between "-v" and the file name, and this 
makes
rpmuncompress try to parse "-v%{SOURCE}" as an option and fail.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: cxxtools - error: aggregate 'tm tim' has incomplete type and cannot be defined

[Artur Frenszek-Iwicki]

Adding "#include " to src/timer.cpp fixes this.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Upstream Release Monitoring - bug report

[Artur Frenszek-Iwicki]

> I would like the bot to stop trying making patches and doing scratch builds 
> on all my packages at all.
> Is that possible? How?
Isn't that controlled in Pagure, via the "monitoring" dropdown on the repo page?
There's "no monitoring", "monitoring" and "monitoring with scratch builds" 
options.
The mariadb-connector-c package has the last option selected.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Some spins/labs to be dropped from F37

[Artur Frenszek-Iwicki]

The docs make it seem like maintaining a spin isn't that much work,
and the kickstart files for spins look rather straightforward.

> ## Maintainer did not respond to pings
> * Games Spin — https://fedoraproject.org/wiki/Games_Spin
Unless someone more experienced comes along, I'd be willing
to take a shot at maintaining the games spin.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring/orphaning my packages

[Artur Frenszek-Iwicki]

I can join bleachbit as a co-maintainer.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Blueman and polkit - safe to remove "wheel" group requirement?

[Artur Frenszek-Iwicki]

Blueman, the bluetooth manager [0], requires the user to be in the "wheel" group
in order to perform certain functions (like enabling/disabling bluetooth).
This leads to a sub-optimal user experience, where the user is prompted
to authenticate as root in order to perform certain actions. [1]

The "wheel" requirement is a result of the polkit rules for blueman, which look 
like this: [2]

/* Allow users in wheel group to use blueman feature requiring root without 
authentication */
polkit.addRule(function(action, subject) {
if ((action.id == "org.blueman.network.setup" ||
 action.id == "org.blueman.dhcp.client" ||
 action.id == "org.blueman.rfkill.setstate" ||
 action.id == "org.blueman.pppd.pppconnect") &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});

This is a simple ruleset, so removing the "wheel" requirement
and allowing any user to perform these four actions is rather trivial.
My question is, would it be safe? Should I limit this change to
the "org.blueman.rfkill.setstate" action only?

A.FI.

[0] https://src.fedoraproject.org/rpms/blueman
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2055253
[2] 
https://raw.githubusercontent.com/blueman-project/blueman/2.3.beta1/data/configs/blueman.rules
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> Too complicated for the average user.
That's debatable. Does the *average user* even care?
We're on the development mailing list, after all,
so there's a lot of bias towards the power user side.

> It should be visible when you click the "Install" button.
I agree that the current placement makes the source dropdown
not very visible and easy to miss. I was thinking if having some
kind of combo-button (i.e. button + dropdown) would be a
better option - something like:
+ --+---+
| Install   |   |
| (From Fedora RPM) | v |
+---+---+
This would make the selected source prominent
and allow to easily switch to a different one.

Either way, this is all a UX discussion, and with
GNOME's take-it-or-leave-it approach, I fear
we'd have to patch gnome-software to achieve
something like the above, which would probably
create a lot of maintenance burden.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Help needed: liquidctl and python3.11

[Artur Frenszek-Iwicki]

Some time ago we've had python3.11 land in Rawhide, with a rebuild of dependent 
packages.
One of my packages, liquidctl, fails to build with the new Python, and since my 
knowledge of the language
stops at "I used it to rewrite some bash scripts", I'd need some help.

Strictly speaking, the package builds fine, and it passes all tests, save one - 
the doctest,
which, as I understand it, somehow checks if the doc-comments match the code.
The doctest fails in a couple of places, but to give you an example, here's one 
of them:

__ [doctest] liquidctl.driver.ddr4.VengeanceRgb.Mode 
___
320 A collection of name/value pairs.
321 
322 Access them by:
323 
324 - attribute access::
325 
326 >>> Mode.FIXED
UNEXPECTED EXCEPTION: NameError("name 'Mode' is not defined")
Traceback (most recent call last):
  File "/usr/lib64/python3.11/doctest.py", line 1350, in __run
exec(compile(example.source, filename, "single",

  File "", line 1, in 

NameError: name 'Mode' is not defined
/builddir/build/BUILD/liquidctl-1.9.1/liquidctl/driver/ddr4.py:326: 
UnexpectedException

The full build log can be found here:
https://kojipkgs.fedoraproject.org//work/tasks/7849/88567849/build.log

If someone knows how to fix this, help will be appreciated.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> I'd imagine a single slider (or drop-down menu or whatever)
Once you open the app screen details, there is a drop-down for this,
integrated into the top bar, next to the app name.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)

[Artur Frenszek-Iwicki]

> Users of RPM-based variants will expect the default package manager to 
> install RPMs,
> not Flatpaks, or they would have chosen a Flatpak-based variant.
Agree on that one.

That being said, what about allowing users to set this preference by themselves?

I also think that the repository information should also be made more visible;
if a package is available from multiple sources, gnome-software will display
a separate search entry for each of those, which looks very odd from a UX
perspective - I'd expect some kind of match-by-id to be performed and
for duplicated packages to either be merged into a single button,
or to have some additional bit of text on them telling me which one
comes from where.

Btw, shouldn't gnome-sofware pull in PackageKit?
I typically only use dnf, so I installed gnome-software and it was unusable
until I manually installed PackageKit as well.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Flatpaks: fedmod has been retired

[Artur Frenszek-Iwicki]

I wanted to try building a Fedora Flatpak, so I headed over to the docs and 
started with the tutorial.
https://docs.fedoraproject.org/en-US/flatpak/tutorial/

The first step instructed me to install some packaging tools:
$ dnf install flatpak-module-tools fedmod

DNF complained that it could not find "fedmod".
I checked in dist-git and it looks like it has been retired over 6 months ago.
https://src.fedoraproject.org/rpms/fedmod

So my question is... what's up with that?
Looking at the tutorial, I get the impression that fedmod was just a helper tool
and isn't strictly required to build a Fedora Flatpak. If that's the case,
I'd appreciate it if someone knowledgeable can update the docs.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List active versions for a package from CLI

[Artur Frenszek-Iwicki]

Just after sending this message, it occurred to me
that I could just use the developer tools in the browser
to check the URL of the API endpoint being called
and then just send a similar request using curl.

So it is quite possible that it was, indeed, my memory
playing tricks on me, and I used to get that info
by calling the API endpoint.

A.FI.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

List active versions for a package from CLI

[Artur Frenszek-Iwicki]

When you go to a package's repo on src.fedoraproject.org,
on the top of the page, you get this nice table that lists
active Fedora and EPEL releases, and for each of those,
prints the package version currently in stable and in testing.

Now, I could swear that fedpkg had a similar feature.
Yet, looking at the list of commands, it's not there.

One way to mimic this would be to call "fedpkg releases-info"
to get the list of releases, and then use "koji latest-build $TAG $PKG",
possibly cross-checking that info with "bodhi updates query --packages $PKG".

So I guess my question is, does fedpkg/koji/bodhi have this feature
and I just can't find it, or is there a separate program for this,
or is it just my memory playing tricks on me?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Where does "redhat-linux-build" come from?

[Artur Frenszek-Iwicki]

$ rpmbuild --showrc

The definition for %cmake is quite long, but includes this line:
%{!?__cmake_in_source_build:-B "%{__cmake_builddir}"} \

%__cmake_builddir is defined as:
%{!?__cmake_in_source_build:%{_vpath_builddir}}%{?__cmake_in_source_build:.}

And then %_vpath_builddir is defined as:
%{_vendor}-%{_target_os}-build

So that's where "redhat-linux-build" comes from.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​

[Artur Frenszek-Iwicki]

> garmintools   orphan   5 weeks ago
I adopted this. The build is now finished.
https://koji.fedoraproject.org/koji/taskinfo?taskID=88328349

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review request: ssr - SimpleScreenRecorder, a screen recorder for Linux

[Artur Frenszek-Iwicki]

SSR is available in RPM Fusion under the name "simplescreenrecorder",
so you may want to coordinate this with the Fusion maintainer - maybe
do something similar to Audacity and Chromium, where the Fedora package
is named "foobar" and the RPM Fusion one is "foobar-freeworld".

A.FI.

https://admin.rpmfusion.org/pkgdb/package/free/simplescreenrecorder/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Maintainer Change

[Artur Frenszek-Iwicki]

This depends on the state of the package.
1. Has an active maintainer? They must go to the package's repo, and in the 
settings, grant you commit/admin access. [1]
2. Has a maintainer, but they're inactive? You must fire up the non-responsive 
maintainer policy. [2]
3. Package is orphaned, but not retired yet? Go to the repo and just click the 
"Take" button. [3]
4. Package has been retired? File a ticket with releng. If it's been retired 
for more than 8 weeks, you'll need to re-submit it to Package Review. [4]

I think that's all the possibilities, unless I missed something.
A.FI.

[1] https://src.fedoraproject.org/rpms/${PKGNAME}/settings
[2] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
[3] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package
[4] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Artur Frenszek-Iwicki]

> Are you manually editing the "sources" file?
No, why would I?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Artur Frenszek-Iwicki]

> I very likely have the files listed in sources 
> around from previous attempts
Well, yeah, but it's also likely that someone:
1. Has multiple machines, hadn't done any work on this package on the current 
machine, and did a fresh "fedpkg clone"
2. Got fed up with clutter in the directory and started their work with "rm 
*.tar.gz *.src.rpm"

In both these cases the old sources wouldn't be around.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Artur Frenszek-Iwicki]

> I somehow don't understand why there should be anything like "unused 
> source files". Why is something like this even possible? 
1. Grab a package
2. Edit the spec file in a way that changes which sources are used (say, update 
to a new version)
3. Do not run "fedpkg new-sources" to upload the new tarballs
4. The "sources" file now lists files that are not actually used by the spec
5. Run "fedpkg mockbuild"
6. Mockbuild attempts to download package sources

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Taking over maintenance for orphaned git-up package

[Artur Frenszek-Iwicki]

git-up has been retired for over a year now. Packages that have been
retired for over 8 weeks need to go through Package Review again.

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

A.FI.
___
devel mailing 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Artur Frenszek-Iwicki]

For me personally, opt-out would be better, since the logic is right most of 
the time.

That being said, how about adding a value for this in 
$HOME/.config/rpkg/fedpkg.conf?
That way, you have some default value, which can be overridden by the config,
which in turn can be overridden by the opt-in/opt-out command-line arg.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License change: cpufetch is now "GPLv2" (used to be "MIT")

[Artur Frenszek-Iwicki]

cpufetch v1.02 has just been released. This new version includes a change in 
licensing, from MIT to GPL-2.0-only.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Artur Frenszek-Iwicki]

I'm not sure if I use any i686 executables, but I sure do use
i686 builds of libraries for cross-compiling. By which I mean
both i686-linux and i686-win32.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Donate 1 minute of your time to test upgrades from F35 to F36

[Artur Frenszek-Iwicki]

On my F35 machine, there are no transaction errors, but the following packages 
get downgraded:
- binutils-x86_64-linux-gnu and cross-binutils-common - from 2.37-3.fc35 to 
2.37-2.fc36 (same version, release downgrade)
- thunderbird and thunderbird-librnp-rnp - from 91.5.0-1.fc35 to 91.4.0-1.fc36 
(version downgrade)

On my second machine that's still running F34, I got the following transaction 
error:
 Problem 1: package python3-argh-0.26.1-19.fc34.noarch requires python(abi) = 
3.9, but none of the providers can be installed
  - python3-3.9.10-1.fc34.x86_64 does not belong to a distupgrade repository
  - problem with installed package python3-argh-0.26.1-19.fc34.noarch
 Problem 2: package tepl-6.00.0-1.fc34.x86_64 requires 
libicui18n.so.67()(64bit), but none of the providers can be installed
  - package tepl-6.00.0-1.fc34.x86_64 requires libicuuc.so.67()(64bit), but 
none of the providers can be installed
  - libicu-67.1-7.fc34.x86_64 does not belong to a distupgrade repository
  - problem with installed package tepl-6.00.0-1.fc34.x86_64

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: nextcloud-client orphaned

[Artur Frenszek-Iwicki]

Are you talking about the "nextcloud-client" package? [0]
'cause that one isn't orphaned, and nonamedotc [1] is listed as the maintainer.

Also, v3.4.2 is currently in testing, but has not been pushed to stable
due to reported bugs. [2]

A.FI.

[0] https://src.fedoraproject.org/rpms/nextcloud-client
[1] https://accounts.fedoraproject.org/user/nonamedotc
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2022-23aa0e100b
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM spec feedback directly in your editor

[Artur Frenszek-Iwicki]

> error: Unable to open /dev/stdin: No such device or address
How about "/proc/self/fd/0"?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to clone by fedpkg ?

[Artur Frenszek-Iwicki]

You need to generate an SSH key and upload it to 
https://accounts.fedoraproject.org
Log in, go to Settings and switch to the "SSH & GPG keys".

If this isn't the only key you're using, you will also need to edit your ssh 
config.
A.FI.
___
devel mailing 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Error: transaction test error

[Artur Frenszek-Iwicki]

> file /usr/bin/icat from install of sleuthkit-4.11.1-1.fc36.x86_64 conflicts 
> with file from package icat-0.5-10.fc36.x86_64
> file /usr/share/man/man1/icat.1.gz from install of 
> sleuthkit-4.11.1-1.fc36.x86_64 conflicts with file from package 
> icat-0.5-10.fc36.x86_64
icat is one of my packages. sleuthkit has been in Fedora for 13 years now,
and "icat" has been part of the package from the very beginning, so this 
conflict is on me.
(And whoever reviewed my package review request, I guess.)

I'll add the Conflicts: tag and rebuild the package later today.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 36 Mass Branching

[Artur Frenszek-Iwicki]

One of my packages ("blueman") had a new release today, so I updated it.
Despite me committing to the rawhide branch, the build was given the ".f36" 
suffix,
so when I pushed to the f36 branch and tried to build the package,
koji berated me that it's been already built.

So what now? Should I just tag the build manually (using the "f36" tag?)
and submit a bodhi update for F36?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in March

[Artur Frenszek-Iwicki]

I contacted Rahul and he made me a co-maintainer on the chocolate-doom package.
I've pushed a commit that fixes the build failures and updates the package from 
v3.0.0 to v3.0.1.
The builds for rawhide, f35 and f34 had finished and have been submitted to 
bodhi.

A.FI.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in March

[Artur Frenszek-Iwicki]

> chocolate-doomsundaram
I've managed to get this to build successfully in koji.
I'll try to contact the maintainer, though looking at bugzilla, they haven't 
been active since April 2020.
I'm willing to adopt the package should the maintainer drop it or be declared 
unresponsive.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: spirv-tools ftbfs no idea what the compiler is telling me.

[Artur Frenszek-Iwicki]

Bumping this since I have an identical issue with colobot - the compilation 
errors out when a C-like string literal is assigned to an std::string, with the 
compiler providing the same "memcpy accessing... overlaps lots-of-bytes at 
offset -3" error message.

A.FI.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Help needed updating Lazarus to v2.2.0

[Artur Frenszek-Iwicki]

Hi all,

some time ago, Lazarus v2.2.0 came out. I tried to update the package
in Rawhide, but the build failed on ppc64le with a linking error.
Link to failed scratch build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=81313575

../units/powerpc64-linux/nogui/project.o: in function 
`WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT':
/builddir/build/BUILD/lazarus-2.2.0/lazarus/ide//project.pp:1:(.text.n_WRPR_$PROJECT_$$_TPROJECT_$_IPROJPACK_$_1_$_CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT+0x4):
 call to `CLASSES$_$TCOMPONENT_$__$$__ADDREF$$LONGINT' lacks nop, can't restore 
toc; (toc save/adjust stub)
/usr/bin/ld: final link failed: bad value

I was wondering if this was a Fedora-specific issue, or some upstream bug,
so I went to the bug tracker. As it turned out, this issue has already
been reported, as openSUSE had stumbled on the exact same error.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39534

So, that was two weeks ago. Why bring it up now?
Because we're fresh after the F36 Mass Rebuild, and several packages
depending on Lazarus failed to build, with very similar errors:
a segmentation fault somewhere in "lazbuild", the CLI tool for
building Lazarus projects.

Affected packages:
- cqrlog: https://koji.fedoraproject.org/koji/taskinfo?taskID=81478836
- doublecmd: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482400
- goverlay: https://koji.fedoraproject.org/koji/taskinfo?taskID=81517949
- lazpaint: https://koji.fedoraproject.org/koji/taskinfo?taskID=81530759
- pasdoc: https://koji.fedoraproject.org/koji/taskinfo?taskID=81557894

So I'm here thinking that maybe, if we were able to solve the pcc64le
issue and update Lazarus to v2.2.0, we can then try rebuilding the affected
packages and see if the segfault this occurs. Only problem is,
unfortunately, I know very little about compilers & linkers & assembly,
so the ppc64le issue is way outside my field of knowledge.
As such, any help regarding coming up with a patch will be greatly appreciated.

For the record, the Lazarus package ships with a couple patches,
and those needed to be updated from v2.0.12 for v2.2.0. I did not
commit those to the main repository yet, but you can grab them from this fork:
https://src.fedoraproject.org/fork/suve/rpms/lazarus

Thanks in advance.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Question on adding a new package to fedora

[Artur Frenszek-Iwicki]

> So far there has been no action on the bug to get it reviewed.
> Does it usually take a while to get the review started?
Well, the thing is - there isn't really anyone obliged to review package 
submissions.
Almost every single review is done by volunteers, using their free time.

> Do I need to inform someone to get this going?
You can try asking people on this mailing list... like you just did! :)
Proposing a review swap is also a somewhat popular process.
The IRC channels are also a place to hang out and ask people.

> I know fedora36 is coming up. It would be good to get it into that
> but if I have missed dates it can wait for f37.
New packages don't have to wait until a new version of Fedora
comes out, they can be added to existing releases.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Artur Frenszek-Iwicki]

I pulled a Rawhide container and tried building there via "fedpkg local".
When I took the g++ command line and replaced "-flto=auto -ffat-lto-objects"
with "-flto=none", the file was compiled without errors.

A.FI.
___
devel mailing list -- devel@lists.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Artur Frenszek-Iwicki]

I tried compiling colobot with the new gcc, expecting it to break in some
new and fascinating way, and got the following error:

In function 'std::char_traits::copy(char*, char const*, unsigned long)',
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
/usr/include/c++/12/bits/basic_string.h:423:21,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_S_copy(char*, char const*, unsigned long)' at 
/usr/include/c++/12/bits/basic_string.h:418:7,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::_M_replace(unsigned long, unsigned long, char const*, 
unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::assign(char const*)' at 
/usr/include/c++/12/bits/basic_string.h:1645:19,
inlined from 'std::__cxx11::basic_string, 
std::allocator >::operator=(char const*)' at 
/usr/include/c++/12/bits/basic_string.h:813:28,
inlined from 'Ui::CList::SetItemName(int, std::__cxx11::basic_string, std::allocator > const&)' at 
/builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28:
/usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing 
9223372036854775810 or more bytes at offsets -4611686018427387902 and 
[-4611686018427387903, 4611686018427387904] may overlap up to 
9223372036854775813 bytes at offset -3 [-Werror=restrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2, 
__n));
  |^

The relevant bit of code is this line:
m_items[i].text =  " ";
Where the ".text" struct member is an std::string.

Any suggestions on how to fix this will be appreciated.

Thanks in advance,
A.FI.

colobot scm: https://src.fedoraproject.org/rpms/colobot/
colobot upstream: https://github.com/colobot/colobot/
koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=81361550
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Request assistance getting a package (usbrelay) into Fedora

[Artur Frenszek-Iwicki]

Hi, Darryl.

> How to clone the GitHub repository in the spec file
RPM packages are build from Source files. You don't clone the repository in the 
spec;
rather, you download the repository as a tarball and use that. For GitHub, you 
can download
a specific git tag (or commit) by using the following URL as a source:
  
https://github.com/darrylb123/usbrelay/archive/%{tag_or_commit}/usbrelay-%{tag_or_commit}.tar.gz

> should there be one package or a separate python package
If the python bindings are usable without the command-line application,
or if the application is usable without the python interface - it can be done.
You don't need to create a separate .spec file; rather, you can build the python
package as a sub-package.

For what it's worth, back in the day I wrote a couple of posts on my blog
that aim to explain some basics of RPM packaging.
Maybe you'll find them useful.
- https://blog.svgames.pl/article/basics-of-rpm-packaging
- https://blog.svgames.pl/article/building-multiple-packages-with-rpm

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Review swaps

[Artur Frenszek-Iwicki]

I've got this sad boy waiting for a review since September:
https://bugzilla.redhat.com/show_bug.cgi?id=2006685
pasdoc - Documentation generator for Pascal source code

I can review some C, C++, Pascal or shell stuff in return.

A.FI.
___
devel mailing 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Koji notifications arriving days late

[Artur Frenszek-Iwicki]

Even if it does, it's unlikely to be the culprit,
since in my case, I only use e-mail notifications.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Koji notifications arriving days late

[Artur Frenszek-Iwicki]

This is happening to me, too - but it doesn't seem to be limited
to koji notifications. It happens with bugzilla notifications as well.

There isn't any pattern to the delays that I can see.
I regularly receive notification digests during the day,
yet every now and then I receive a digest informing me
of stuff that happened 2 or 3 days ago. I think once
it informed me on stuff that was almost a week old.

My settings in Fedora Notifications are "100 messages or 1 hour".
I don't receive many notifications, so 100% of the time,
the time limit kicks in first; most digests I receive
have single-digit message counts. This applies to the delayed digests
as well - I've never seen one actually reach 100.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New tool - license-validate

[Artur Frenszek-Iwicki]

> I have created new tool license-validate: 
> https://pagure.io/copr/license-validate/
I've written something relatively similar a few years back 
(https://github.com/suve/vrms-rpm).
I took a look at the code - using a proper parser is definitely a better 
solution than the error-prone,
manual matching happening in my program. May be a good idea for some v3.0. ;)

My personal suggestion would be to add a "line by line" mode for interactive 
usage,
so instead of:
> $ license-validate --verbose "First"
> $ license-validate --verbose "Second"
one could do something like:
> $ license-validate --stdin < licenses.txt

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package wishlist site?

[Artur Frenszek-Iwicki]

There's been a (short) discussion about having a wishlist last month:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/K3O5WRMT75UCWMRE6PCMBHRGMHMIBM63/

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Raising the attachment size limit in bugzilla?

[Artur Frenszek-Iwicki]

On a related note - could we increase the size limit for FTBFS tickets?
Currently, the when FTBFS bugs are filed, the attachments are limited to 32KiB,
which is often too small to fit the whole build log.

The whole point of attaching these to the bugzilla ticket is that koji deletes 
logs after some time,
and the attachments are meant to provide a non-ephemeral copy.
But when said copy is truncated, it often ends up being of little use,
leading one to re-submit the broken build to koji just to get new copies of the 
full logs.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Adding shields.io badges for Fedora packages to upstream projects

[Artur Frenszek-Iwicki]

> The idea here [...] is for our target audience to quickly be made aware 
> that something is available in Fedora when they go to a GitHub repository.
> They're really not going to go to repology to search
Repology also offers badges. What I meant is that a single Repology badge
listing all known repos is a simpler solution (also requires less maintenance)
than having a separate badge for each distro.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How I test RPM Conditionals ? in shell command line

[Artur Frenszek-Iwicki]

Not sure if there's a way to test a conditional by itself, but if it's 
somewhere in a spec file,
you can use "rpmspec --parse $FILE" to see what the spec looks like after it's 
parsed
and all the conditionals have been evaluated.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Adding shields.io badges for Fedora packages to upstream projects

[Artur Frenszek-Iwicki]

> Would anyone have an idea of how this works and
> where issues should be filed? On our infra or on shields.io?
Fedora badges are listed on shields.io under the "Version" category:
https://shields.io/category/version
Clicking on the "Fedora" badge brings up a pop-up that allows to specify the 
badge's parameters.
The pop-up mentions mdapi, so I guess that's where it gets its information from.

> works for arbor, not for python-libNeuroML
While "python-libNeuroML" doesn't work, "python3-libNeuroML" does,
so I guess this works with binary RPMs, not source RPMs.

> What do people think of opening PRs to (optionally) add these to
> upstream readme files when a software has been included in Fedora to
> increase visibility?
If a project already includes some "get it on Ubuntu/Arch" information,
I see no harm in suggesting to add a note about Fedora. Though personally
I think repology is a better solution, since it gibes you many repos at once
and you don't need to update the README every time a new distro comes along.
But that's just me. 
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: spec file error

[Artur Frenszek-Iwicki]

> ./mkinstalldirs /usr/bin
> make: ./mkinstalldirs: Permission denied
This sounds like "mkinstalldirs" is not executable, perhaps a simple "chmod +x 
mkinstalldirs" will be enough?
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​

[Artur Frenszek-Iwicki]

> SDL2_gfx  ignatenkobrain, orphan   1 weeks ago
I'd like to pick this up, but I have next to zero experience working with 
autotools,
so I'll defer adopting the package until I have a working fix for the FTBFS.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License change: liblcf: "MIT and BSD" -> "MIT and BSD and Boost"

[Artur Frenszek-Iwicki]

I'm currently working on updating liblcf and easyrpg-player to v0.7.0 [0,1]. 

As part of this new release, the liblcf library now bundles some header-only 
C++ libraries [2,3].
Those are Boost-licensed, which means the package's effective license changes 
from "MIT and BSD" to "MIT and BSD and Boost".

A.FI.

[0] https://github.com/EasyRPG/liblcf/releases/tag/0.7.0
[1] https://github.com/EasyRPG/Player/releases/tag/0.7.0
[2] https://github.com/martinmoene/span-lite
[3] https://github.com/martinmoene/string-view-lite
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Claiming ownership of a dropped package

[Artur Frenszek-Iwicki]

> In the docs there is a section about Claiming Ownership of an Orphaned Package
You were looking almost in the right place. There's a separate section about 
claiming retired packages. [1]

tl;dr: If it was retired for more than 8 weeks, it needs to go through the 
Package Review process again.
After the review is approved, instead of filing a "new repo" ticket, you need 
to file a "claim ownership" ticket.

[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package Update Guide: Updating inter-dependent packages

[Artur Frenszek-Iwicki]

> section "Chained builds". What about those, what are they useful for?
Chained builds are mostly useful when you have a package B which depends on 
package A.
Instead of building package A, waiting for a confirmation that the build 
completed
and made it to the buildroot, and then manually launching the package B build,
you can specify the build-chain and koji will automatically handle the process.

They can be used both in rawhide and in side tags. They're not really compatible
with release branches, since the chainbuild would have to wait for however
long it takes package A to go through bodhi and into stable.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora ? Java: The Death of Two SIGs

[Artur Frenszek-Iwicki]

> I believe the only requirements are javac, javah, javadoc (optional)
> and a JVM to run the tests on. Is it possible to keep this going,
> or would that require a lot of work?
+1 on this. Having just the minimum, core packages
available in the repo would be good, especially since:
a) It would mean users can still run third-party Java apps.
b) I believe that, similar to Python, many end-users use maven
   (or whatever else) for installing dependencies, instead of the distro's repo,
   so the removal of other packages didn't affect them as much.

>  I notice that javah no longer seems to exist.
javah is now part of javac, invoked using the -h option.
If my research is right, the last edition with a separate javah was Java SE 9. 

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package Update Guide: Updating inter-dependent packages

[Artur Frenszek-Iwicki]

Sounds good. I took a look at the "multi builds" page - it describes the 
process neatly,
but I think there's one thing that could be added there: what if you already 
built a package
in the main tag (but it didn't go through bodhi and get to stable)? Will it be 
included in the
newly-created side tag, or do you need to execute some command to add it there?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Free Pascal and the new glibc

[Artur Frenszek-Iwicki]

> I've created f35-build-side-46123 and tagged fpc-3.2.2-3.fc35 into that.
> Lazarus rebuild is in progress.
Thanks. Lazarus has been built successfully.

> If the maintainers of those packages want to rebuild their package
> (in the side-tag), please do so, it will speed up the process.
I'll go over my packages (colorful, gearhead1, lazpaint) today.

Thanks again.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Free Pascal and the new glibc

[Artur Frenszek-Iwicki]

> I can take care of creating the side-tag, 
> tagging the fpc build in it (no need to rebuild it again)
> and trying to rebuild all dependent packages there.
Sure, thanks for the help.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Free Pascal and the new glibc

[Artur Frenszek-Iwicki]

The build for f35 was successful: 
https://koji.fedoraproject.org/koji/buildinfo?buildID=1835338
I've submitted an update to bodhi as well: 
https://bodhi.fedoraproject.org/updates/FEDORA-2021-032397269f

Although now that I think of it, it probably would've been cleaner to do create 
a side tag, perform the build there, and then use it to re-build all the 
dependent packages. Should we unpush this update and go the side tag route, or 
just create a buildroot override for the dependants?

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Free Pascal and the new glibc

[Artur Frenszek-Iwicki]

The build was successful: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=76057984
I see you've made a commit to the rawhide branch only; I'll go ahead and apply 
the patch to the f35 branch as well.

Thanks for the help. The patch doesn't look complicated, but unfortunately I 
have zero experience working with assembly, so I couldn't have done it myself.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure