Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)

[Andy Mender]

On Mon, 3 May 2021 at 10:24, Miro Hrončok  wrote:

> (The subject line referes to https://www.youtube.com/watch?v=E3418SeWZfQ)
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets
> retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2021-05-03.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
>
>   Package   (co)maintainers Status
> Change
>
> 
> [snip]
>


Hello,

Took the following, because it's a dep of coolreader, which I'm maintaining:

> libunibreak  orphan3
weeks ago

Cheers,
Andy
___
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: Guidance on new package

[Andy Mender]

I think it's entirely up to you.

The source tree in Fedora uses "main" for the Rawhide version of the
package and f32, f33, etc. for releases. Also, the %changelog in the SPEC
file is in a way an immediate history of the SPEC file, including
versioning and revisions.

I usually keep external SPEC files on GitHub and use a linear history with
a single "master/main" branch, but it does make sense to leverage git tags
or versioned branches if you intend to keep multiple versions worth of the
SPEC file.

~Andy

On Tue, 29 Dec 2020 at 22:19, FreedomBen  wrote:

> rpmlint complains (which I fully expected from reading the packaging
> guidelines) about my spec file being named "pick-v4.0.0.spec" instead of
> "pick.spec".
>
> What's the best way to manage spec files for different versions?  git tags
> in the repo?  directories with version info?  something else?
>
> Ben
>
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 28, 2020 1:53 PM, Andy Mender <
> andymenderu...@gmail.com> wrote:
>
>
> On Mon, 28 Dec 2020 at 21:12, FreedomBen via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Hi all,
>>
>> I've read a crap ton of pages now about package creation/maintenance but
>> feel like I'm missing stuff and spinning wheels so I wanted to ask.  The
>> process seems pretty muddled :-D
>>
>> I've got an RPM package I maintain called "pick" (I'm already working
>> with the upstream project and have their blessing/encouragement to do
>> this).  It's a reasonably successful project that really should be in the
>> official repos.  Here's the upstream: https://github.com/mptre/pick
>>
>> Here's an example spec file I use.  I have a scrip that generates these
>> automa6tically based on the version available upstream:  example spec
>> file:
>> https://github.com/FreedomBen/pick-rpm/blob/master/spec-files/pick-v4.0.0.spec
>>
>>
>> The build of my build is this script (
>> https://github.com/FreedomBen/pick-rpm/blob/master/build.sh) plus the
>> Dockerfile (https://github.com/FreedomBen/pick-rpm/blob/master/Dockerfile).
>> That's probably not relevant for what we're doing here, just wanted to
>> share in case it's useful for somebody evaluating me ;-)
>>
>> I have a COPR repo now for "pick" here:
>> https://copr.fedorainfracloud.org/coprs/freedomben/pick/:
>>
>> All my scripts I use to build RPMs are here.  Basically I just use podman
>> to crank out all versions.  There's a script to generate a stand alone spec
>> file as well (which is where the one above came from):
>> https://github.com/freedomben/pick-rpm
>>
>> I want to get this package included in Fedora proper.  I've never been a
>> Fedora maintainer before but I'm a long time Fedora user and programmer and
>> generally pretty good at stuff kind of guy.  I'm mostly familiar with
>> packaging guidelines, though I'm not an expert on the various macros (yet).
>>
>> Is there someone who can guide me on what to do next?  Or who will
>> sponsor me?
>>
>> Thanks in advance,
>>
>> Ben
>>
>
> Hello Ben!
>
> I see "pick" is available on quite some platforms! :)
> The simplest approach would be to submit a request to add your package to
> Fedora at: https://bugzilla.redhat.com/
> Here are the links I usually use for reference:
> - On becoming a packager:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join
> - Packaging Guidelines:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/
> - An in-depth guide to RPM packaging (slightly outdated, but still
> useful): http://ftp.rpm.org/max-rpm/
> - On getting sponsored:
> https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
>
> You're already on the right track with your SPEC file from what I saw.
> What I'd recommend is the following:
> 1. Read through the above docs to make sure you have all the necessary
> tools like "fedora-review", "rpmlint", "mock" and "rpmbuild".
> 2. Generate a RPM and SRPM of your package and check it with the above
> tools to make sure it's clean.
> 3. Submit a review request to https://bugzilla.redhat.com/ and mark your
> request as blocking the FE-NEEDSPONSOR tracker so that people are aware
> that sponsorship is required. Be sure to link the SPEC file, a SRPM
> generated via "rpmbuild" and a successful Koji scratch build (not
> mandatory, but it helps).
> 4. Wait for someone to pick up your request and join us ;).
>
> Cheers,
> Andy
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Guidance on new package

[Andy Mender]

On Mon, 28 Dec 2020 at 21:12, FreedomBen via devel <
devel@lists.fedoraproject.org> wrote:

> Hi all,
>
> I've read a crap ton of pages now about package creation/maintenance but
> feel like I'm missing stuff and spinning wheels so I wanted to ask.  The
> process seems pretty muddled :-D
>
> I've got an RPM package I maintain called "pick" (I'm already working with
> the upstream project and have their blessing/encouragement to do this).
> It's a reasonably successful project that really should be in the official
> repos.  Here's the upstream: https://github.com/mptre/pick
>
> Here's an example spec file I use.  I have a scrip that generates these
> automa6tically based on the version available upstream:  example spec
> file:
> https://github.com/FreedomBen/pick-rpm/blob/master/spec-files/pick-v4.0.0.spec
>
>
> The build of my build is this script (
> https://github.com/FreedomBen/pick-rpm/blob/master/build.sh) plus the
> Dockerfile (https://github.com/FreedomBen/pick-rpm/blob/master/Dockerfile).
> That's probably not relevant for what we're doing here, just wanted to
> share in case it's useful for somebody evaluating me ;-)
>
> I have a COPR repo now for "pick" here:
> https://copr.fedorainfracloud.org/coprs/freedomben/pick/:
>
> All my scripts I use to build RPMs are here.  Basically I just use podman
> to crank out all versions.  There's a script to generate a stand alone spec
> file as well (which is where the one above came from):
> https://github.com/freedomben/pick-rpm
>
> I want to get this package included in Fedora proper.  I've never been a
> Fedora maintainer before but I'm a long time Fedora user and programmer and
> generally pretty good at stuff kind of guy.  I'm mostly familiar with
> packaging guidelines, though I'm not an expert on the various macros (yet).
>
> Is there someone who can guide me on what to do next?  Or who will sponsor
> me?
>
> Thanks in advance,
>
> Ben
>

Hello Ben!

I see "pick" is available on quite some platforms! :)
The simplest approach would be to submit a request to add your package to
Fedora at: https://bugzilla.redhat.com/
Here are the links I usually use for reference:
- On becoming a packager:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join
- Packaging Guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/
- An in-depth guide to RPM packaging (slightly outdated, but still useful):
http://ftp.rpm.org/max-rpm/
- On getting sponsored:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

You're already on the right track with your SPEC file from what I saw. What
I'd recommend is the following:
1. Read through the above docs to make sure you have all the necessary
tools like "fedora-review", "rpmlint", "mock" and "rpmbuild".
2. Generate a RPM and SRPM of your package and check it with the above
tools to make sure it's clean.
3. Submit a review request to https://bugzilla.redhat.com/ and mark your
request as blocking the FE-NEEDSPONSOR tracker so that people are aware
that sponsorship is required. Be sure to link the SPEC file, a SRPM
generated via "rpmbuild" and a successful Koji scratch build (not
mandatory, but it helps).
4. Wait for someone to pick up your request and join us ;).

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Stale proven packagers

[Andy Mender]

On Tue, 22 Dec 2020 at 21:40, Adam Williamson 
wrote:

> that's 90 of the 251 who still have provenpackager privileges, but
> haven't run any kind of Koji build since at least 2019-01-01 (if you
> check, it turns out many of them haven't run a build since long before
> then). Many of them, to my knowledge, don't work on Fedora at all any
> more and haven't for years. At least one of them, to my and everyone
> else's knowledge, is sadly dead and has been for some time. One account
> - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't
> exist in koji (any more?)
>
> Perhaps we need a process for cleaning up membership of this extremely
> powerful group? If the FAS password of *any one* of those user accounts
> were somehow compromised (or if just one of them decided they had a
> grudge against Fedora now and were going to have some fun), the results
> could be...unfortunate.
>

Security implications are one thing, but it's also unfortunate that these
accounts (and related packages) exist in limbo.
Would it perhaps make sense to extend/improve your script, run it once
every half a year and contact the packagers to check with them whether
they're still interested in Fedora?

Best,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andy Mender]

On Mon, 21 Dec 2020 at 15:10, Miro Hrončok  wrote:

> Dear maintainers.
>
> Based on the current fail to build from source policy, the following
> packages
> will be retired from Fedora 34 approximately one week before branching
> (February
> 2021).
>
> Policy:
>
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> Note that some listed packages are orphaned and hence may be retired even
> sooner.
>
> The packages in rawhide were not successfully built at least since Fedora
> 32.
>
> This report is based on dist tags.
>
> Packages collected via:
>
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process, please let
> me
> know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>   Package  (co)maintainers  Latest
> build
>
> ===
> VirtualGL   gsgatlin   Fedora
> 31
>
> If there are no takers, I would be interested in VirtualGL.

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaning python-pykafka

[Andy Mender]

Hello,

Recently, I picked the python-pykafka package, since it was orphaned.
Unfortunately, upon closer inspection I noticed it has been neglected quite
a bit.

During the build process, it would download several dependencies via "pip"
which were not listed as BuildRequires in the SPEC file. 3 of them are not
packaged for Fedora at all (python-xxhash, python-parametrized,
python-lz4tools), one of which is incorrectly listed in the upstream
requirements.txt file (python-parametrized exists, but the latest version
is 0.1, not 0.7 as the requirements.txt file wants).

To make matters worse, it seems like both the upstream and several of the
dependencies are dead/abandoned.

I'm orphaning the package, since it doesn't make sense to keep it.

Incidentally, there is https://src.fedoraproject.org/rpms/python-kafka,
which was retired, but the upstream is alive so I might pick this one up.

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction

[Andy Mender]

On Fri, 11 Dec 2020 at 19:52, LinuxGeek46  wrote:

> Hello - my name is David Both and I want to introduce myself. Ankur Sinha
> "FranciscoD" is mentoring me as I start with Fedora Fusion package
> maintenance.
>
> I have been working with computers for just a bit over 50 years now, and
> almost 25 with Linux, most of which is Red Hat (old), RHEL, CentOS, and
> Fedora.  I am not going to give you my life story - at least as it relates
> to computers - because you can get that from my web site.
> http://www.both.org/?page_id=2  Suffice it to say that I have never used
> Windows as a primary OS on any of my own computers. Ever.
> DOS=>TopView=>OS/2=>Linux.
>
> I am honored to be part of this team and I look forward to contributing in
> a more active way.
>
> Thanks!
>
 Impressive! My computer life also started with MS-DOS, but then
transitioned through a couple of Windows editions out of necessity.

Welcome to the team! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Sohan Kunkerkar

[Andy Mender]

On Mon, 7 Dec 2020 at 16:42, Sohan Kunkerkar  wrote:

> Hi Folks,
> Good day! I hope everyone is keeping well in these unprecedented and
> difficult times.
> My name is Sohan Kunkerkar and I'm a software engineer at Red Hat Inc
> helping to develop and maintain a container-focused operating system.
> Before working on Fedora-CoreOS, I was involved in efforts to building the
> foundational aspects of the k8s cluster federation-v2 (KubeFed) prototype.
> I've been a Fedora user for the past 5 years and am looking forward to
> contributing to this ecosystem. I'm passionate about large-scale
> distributed systems, cloud-native infrastructure, and container tools. In
> my free time, I try to explore the open-source community with their recent
> concepts and solutions and try to contribute to it.
>
> Regarding packaging, I would like to apply for co-maintainership of the
> following packages:
> 1. https://src.fedoraproject.org/rpms/rust-coreos-installer
> 2. https://src.fedoraproject.org/rpms/fedora-coreos-config-transpiler
> 3. https://src.fedoraproject.org/rpms/ignition
> 4. https://src.fedoraproject.org/rpms/rust-afterburn
>
> Thanks!


Welcome Sohan! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Introduction

[Andy Mender]

On Mon, 7 Dec 2020 at 16:55, Robin Opletal  wrote:

> Hi,
>
> My name is Robin Opletal, I am from the Czech Republic and online I tend
> to go under the name of "fourstepper".
>
> I would like to help out with maintaining packages of interest for
> Fedora, currently, I am interested in getting aerc, the terminal e-mail
> client packaged for Fedora. (https://git.sr.ht/~sircmpwn/aerc)
>
> For Aerc, I have so far created a COPR repository, which currently lives
> here: https://copr.fedorainfracloud.org/coprs/fourstepper/aerc/builds/
>
> I would also be thrilled to help with other packages if needed and learn
> and help with the Fedora's package build system.
>

Welcome Robin! :)

If you're interested in Golang, there are quite a bit of packages to pick
from.

Cheers,
Andy
___
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

coolreader: license change from GPLv2 to GPLv2+ and GUI from Qt4 to Qt5

[Andy Mender]

Hello,

The license of coolreader was previously set to GPLv2 in the SPEC file,
however per the short discussion in a related thread, it was always GPLv2+:
https://github.com/buggins/coolreader/issues/80

This was now amended and a PR with the license file itself submitted to
upstream: https://github.com/buggins/coolreader/pull/205

In addition, upstream at some point changed the main tested GUI from QT
(Qt4) to QT5 (Qt5). I tried triaging the many source code related build
failures for Qt4, but it's pretty clear Qt4 is no longer their main focus.
Thus, I switched to Qt5 in the SPEC file.

The change already landed in Fedora 34/Rawhide.

Repo: https://src.fedoraproject.org/rpms/coolreader

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reducing noise on devel list

[Andy Mender]

On Fri, 4 Dec 2020 at 22:43, Dennis Gilmore  wrote:

> Hi all,
>
> I filed https://pagure.io/fesco/issue/2512 asking FESCo to move all
> automated emails to a separate list where people who want to follow
> can, while I was part of the proliferation of compose reports coming
> here, there is now a great deal of them, and they no longer seem to
> trigger any conversation. I think that devel list would benefit from
> having all automated reports sent to a reports-list and letting people
> bring reports over when there is something to discuss. I was asked to
> bring the request to the list for people to weigh in.
>

Big thanks for doing this Dennis! It definitely helps :).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change proposal: ibus-anthy for default Japanese IME (System-Wide Change)

[Andy Mender]

On Mon, 30 Nov 2020 at 20:07, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/ibus-anthy_for_default_Japanese_IME
>
> == Summary ==
> The current default Japanese IME(input method engine) is ibus-kkc and
> the default is going to change to ibus-anthy to develop Japanese IME
> more effectively.
>
>
> == Owner ==
> * Name: [[User:Fujiwara|Takao Fujiwara]]
> * Email: fujiwara [at] redhat [dot] com
>
>
> == Detailed Description ==
> Currently some development plans have been pending because of the
> delay of [https://github.com/ueno/ibus-kkc ibus-kkc] [1] which is the
> default IME for Japanese and I make the default IME to bring back to
> [https://github.com/ibus/ibus-anthy ibus-anthy] now. Originally the
> default was changed from ibus-anthy to ibus-kkc because the
> [https://osdn.net/projects/anthy/ upstream anthy] is no longer
> updated. Recently I got the agreement with the original developer of
> anthy and forked it to [https://github.com/fujiwarat/ibus-anthy
> anthy-unicode] and start to change the default IME again.
>
> I also considered about [https://github.com/google/mozc ibus-mozc] for
> the default but the configuration GUI is based on Qt which has the
> different theme from GNOME desktop in Fedora.
>
> [1] https://github.com/ibus/ibus/wiki/GSettingsMigration
>
>
> == Benefit to Fedora ==
> Make the effective developments in the Japanese IME and apply the
> latest updates in ibus to each IME more effectively because I'm the
> maintainer of both ibus and ibus-anthy.
>
>
> == Scope ==
> * Proposal owners:
> * Other developers: gnome-desktop3 for default ja_JP
>
> * Release engineering: (a check of an impact with Release Engineering is
> needed)
> * Policies and guidelines: N/A
> * Trademark approval: N/A
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> The default installed package will be changed from ibus-kkc to ibus-anthy.
>
>
> == How To Test ==
> Install Fedora with Japanese and the default IME is ibus-anthy.
>
>
> == User Experience ==
> # The Japanese detabase and some keybindings will be changed
> # The setting UI is a little different
> # The package size and depended packages are different
> # The memory usage is a little different
>
>
> == Dependencies ==
> anthy-unicode and kasumi
> # comps has to be updated
> # gnome-desktop3 has to be updated
>
>
> == Contingency Plan ==
> * Contingency mechanism: Revert comps and gnome-desktop3
> * Contingency deadline: Beta release
> * Blocks release? No
>
> == Documentation ==
> TBD
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> 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


As a user of a Japanese IME I would say it's a good move. However, it might
also be worth considering fcitx5. It has been recently (this year) packaged
for Fedora and supports both Japanese (skk) and Chinese (chewing) input
methods currently. It offers a GTK3 and Qt5 GUI.

I used to use ibus-anthy in the past and noticed that input switching
between Japanese and English is a lot smoother with fcitx5 and works very
well regardless of text editor, browser, etc. It even works in a terminal
emulator.

Here's the GitHub page: https://github.com/fcitx/fcitx5
And here's the SKK addon's page: https://github.com/fcitx/fcitx5-skk
If it's important to keep the anthy addon, that's also an option:
https://github.com/fcitx/fcitx5-anthy

Note: I'm a co-maintainer of the fcitx5 packages. The main maintainer is
Qiyu Yan.

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Andy Mender]

On Mon, 30 Nov 2020 at 12:12, Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-30.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see
> https://packager.fedorainfracloud.org/orphan
>
>  Package  (co)maintainers   Status
> Change
>
> 
> [snip]


Took over coolreader. The project is still very much alive :).

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Retiring some packages from openstack-sig

[Andy Mender]

On Thu, 19 Nov 2020 at 11:57, Alfredo Moralejo Alonso 
wrote:

> Hi,
>
> openstack-sig is reviewing the list of packages maintained in Fedora and
> we've found that following packages can be retired from Fedora as they are
> not longer used or required by any other package or OpenStack:
>
> python-cliff-tablib
> python-tablib
> python-congressclient
> python-openstack-doc-tools
> python-pifpaf
> python-pika-pool
> python-positional
> python-pykafka
> python-ryu
> python-setuptools_git
> python-vulture
> python-epi
>
> If anyone is aware of something needing any of them or is willing to take
> maintenance of it, please let me know.
>

I'd be interested in taking over python-pykafka and python-vulture. You can
assign me as co-maintainer instead of orphaning them, I think? :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NeuroFedora review swap: python-meautility

[Andy Mender]

On Fri, 27 Nov 2020 at 14:14, Ankur Sinha  wrote:

> On Fri, Nov 27, 2020 13:07:06 +0100, Andy Mender wrote:
> > 
> >
> > Hiya Ankur!
>
> Hi Andy!
>
> > I reviewed your package. No swap expected, but could you push your
> > gargi-fonts package to Rawhide?
> > I'm working on an update to Widelands and I might need it :).
>
> Thanks very much! I'll complete the review after work this evening.
>
> I've also kicked off a build for gargi-fonts for rawhide. I hadn't
> realised it hadn't been built there yet.
>

Not a problem and you're very welcome! :)

Widelands itself is also not in Rawhide yet so I'll have to get that going,
too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NeuroFedora review swap: python-meautility

[Andy Mender]

On Fri, 27 Nov 2020 at 11:07, Ankur Sinha  wrote:

> Hi folks,
>
> I hope everyone is safe and doing well.
>
> python-meautility is a new dependency needed to update python-lfpy to
> its latest release, so I've packaged it up and submitted a package
> review here: https://bugzilla.redhat.com/show_bug.cgi?id=1902102
>
> It's a standard Python package. Would anyone like to swap reviews
> please?
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
>

Hiya Ankur! I reviewed your package. No swap expected, but could you push
your gargi-fonts package to Rawhide?
I'm working on an update to Widelands and I might need it :).

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Andy Mender]

On Fri, 20 Nov 2020 at 17:28, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
>
> == Summary ==
> This change proposal is to route all audio from PulseAudio and JACK to
> the PipeWire Audio
> daemon by default.
>
> == Owner ==
> * Name: [[User:Wtaymans| Wim Taymans]]
> * Email: wim.taym...@gmail.com
>
>
> == Detailed Description ==
> Currently, all desktop audio is handled by the PulseAudio daemon.
> Applications make use of the
> PulseAudio client library to communicate with the PulseAudio daemon
> that mixes and manages the audio streams from the clients.
>
> The desktop shell (gnome-shell) and the control panel
> (gnome-control-panel) both use the
> Pulseaudio client libraries to manage the volume and configuration of
> the PulseAudio daemon.
>
> This proposal is to replace the PulseAudio daemon with a functionally
> compatible implementation
> based on PipeWire. This means that all existing clients using the
> PulseAudio client library
> will continue to work as before, as well as applications shipped as
> Flatpak.
>
> All PRO audio is handled with the JACK client library, which talks to
> the JACK server. This
> proposal will install a JACK client library replacement that talks
> directly to PipeWire. All
> existing PRO audio jack applications will then work on top of PipeWire.
>
> For legacy ALSA clients, we will install an ALSA plugin that routes
> the audio directly to
> PipeWire.
>
> With these 3 changes, all audio will be routed to PipeWire. There will
> then be no more need to
> install the PulseAudio and JACK daemons.
>
> == Feedback ==
> The owner of this proposal has been in context with both the
> PulseAudio and JACK maintainers and community.
> PipeWire is considered to be the successor of both projects.
>
> == Benefit to Fedora ==
> The end goal is to end up with one audio infrastructure for both
> Desktop and Pro audio use cases.
> This will end the fragmentation of the audio landscape.
>
> Some of the benefits that PipeWire will bring:
>
>  * PRO Audio features
>
>PipeWire can support both Desktop and PRO Audio use cases. PRO
> Audio application tend to use
>the JACK API and JACK daemon, which is hard to setup and integrates
> poorly with the rest of
>the system (and PulseAudio in particular).
>
>With a replacement libjack library, PRO Audio application can run
> directly on PipeWire and
>integrate seamlessly with other ALSA and PulseAudio applications.
> This would bring Fedora
>closer to the experience of other operating systems.
>
>  * Flexibility/Integration
>
>PipeWire is designed to be multiprocess. It separates the
> processing of the multimedia graph
>and the management into separate processes. This makes it possible
> to better integrate with
>the other system components or swap out the default policy for a
> highly customized one (such as
>for automotive or embedded). This is in contrast to PulseAudio,
> which has all logic embedded
>into the daemon with limited configuration options.
>
>In the next phase we expect to greatly expand the user experience
> and configuration of the
>audio infrastructure with better integration throughout the system.
>
>  * Performance
>
>PipeWire was designed for high performance and low-latency, using
> much of the same design as
>JACK. JACK application should run with comparable performance even
> in low-latency situations.
>
>  * Security
>
>PipeWire enforces per client security. Object visibility and the
> actions on them can be
>configured independently per client. This makes it possible to
> enforce a security policy for
>sandboxed applications (Flatpak) such as denying access to certain
> audio capture devices or
>block them from interfering with other applications.
>
>  * Maintainability
>
>Both PulseAudio and JACK have very slow development cycles with few
> new features. The more
>flexible and distributed nature of the design of PipeWire should
> encourage more new features
>and use-cases.
>
> == Scope ==
> * Proposal owners:
> We would make a pipewire-pulse package that provides the same features
> as the pulseaudio (daemon) package.
> We would only provide a drop-in replacement daemon, the pulseaudio
> client libraries will remain unchanged.
>
> The idea is that when installing pipewire-pulse, only the pulseaudio
> package is removed and replaced by the
> pipewire-pulse implementation. In the same way, installing the
> pulseaudio package would remove the pipewire-pulse
> package, making it possible to switch between implementations. This
> will also allow for an easy rollback.
>
> We also need to check and correct the dependencies of other packages.
> As of this writing, some packages do
> not state their dependencies correctly and get removed when pulseaudio
> is removed. We also need to check the
> JACK to make sure they still install with the replacement JACK client
> library.
>
> The JACK client libraries will be 

Re: NEEDINFO nag 2 days after bug creation?

[Andy Mender]

On Tue, 17 Nov 2020 at 16:17, Richard Shaw  wrote:

> On Mon, Nov 16, 2020 at 5:10 PM Miro Hrončok  wrote:
>
>> On 11/16/20 11:31 PM, Richard Shaw wrote:
>> > The logic behind the NEEDINFO stuff may need to be updated... The
>> subject says
>> > it all and it's quite annoying.
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1897496
>> > 
>>
>> The script runs every 3 weeks, on a Sunday. Sometimes, this happens to be
>> right
>> after the bug was opened. Sorry about that.
>>
>> Sure, we *should* adapt that script to check the creation date of the
>> bug. The
>> script is here if you are interested to take a look:
>>
>
> Now that I know that, it's not as big of a deal but yeah, it would be good
> to check the BZ creation date, then I would say it should probably run
> every week (assuming it's not run more frequently due to resource usage.)
>
>
> https://pagure.io/releng/blob/master/f/scripts/ftbfs_weekly_reminder.py
>
>
> I may take a look but $DAYJOB is insane right now and my Python
> programming days ended a long time ago :)
>
> Thanks,
> Richard
>
>
Python dev here. I can have a look at it over the weekend :).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: quota-4.06 license change

[Andy Mender]

On Tue, 10 Nov 2020 at 13:02, Petr Pisar  wrote:

> Upstream relicensed and dropped an old BSD code in 4.06 release. Hence the
> RPM package changes license from "BSD and LGPLv2+ and GPLv2 and GPLv2+"
> to "LGPLv2+ and GPLv2 and GPLv2+".
>
> -- Petr
>
> Thanks for the heads-up! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretiring foo2zjs and argyllcms

[Andy Mender]

On Sun, 18 Oct 2020 at 10:54, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> Hello all.
>
> I want to unretire foo2zjs and its direct dependency argyllcms.
>
> These packages require re-review:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1889072
> https://bugzilla.redhat.com/show_bug.cgi?id=1889073
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
>

I'll review both, but please indicate in the Bugzilla request for foo2zjs
that argyllcms is its dependency so they're linked together.
Also, I created a COPR project for you so you can track updates and
improvements accordingly. Request access to receive permissions :),

COPR: https://copr.fedorainfracloud.org/coprs/andymenderunix/foo2zjs/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretiring python-googletrans

[Andy Mender]

On Sat, 17 Oct 2020 at 23:17, Lyes Saadi  wrote:

> Hello,
>
>
> In order to package dialect[1], I'm unretiring python-googletrans[2].
>
> Since this package was released for more than a year now, I am going
> through a re-review[3].
>
>
> Sincerely,
> Lyes Saadi
>
>
> [1]: https://github.com/gi-lom/dialect
> [2]: https://src.fedoraproject.org/rpms/python-googletrans
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1889104
>

Thanks for letting us know! Package reviewed.

Cheers,
Andy

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: License correction: python-cligj MIT -> BSD

[Andy Mender]

On Thu, 15 Oct 2020 at 11:50, Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:

> The license tag on python-cligj appears to have always been wrongly
> tagged as MIT. I have now corrected it to BSD in Rawhide while
> updating to its latest beta, and will let this trickle down to other
> releases once the new release is out.
>

Thanks for the heads-up and paying extra attention to this :).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NeuroFedora review swap: mod2c

[Andy Mender]

On Mon, 12 Oct 2020 at 11:22, Ankur Sinha  wrote:

> On Sat, Oct 10, 2020 14:04:43 +0200, Andy Mender wrote:
> > 
> >
> > Reviewed and approved! Good job!
>
> Thanks for the quick review, Andy. Please do let me know if I can help
> review your packages any time.
>

Thanks a lot for the offer :). I might have something coming, but just not
yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Preferred way to ask for package update

[Andy Mender]

On Sun, 11 Oct 2020 at 15:24, Kai A. Hiller  wrote:

> Hello,
>
> what ways are there to let other maintainers know that I need them to
> update a package? What is the preferred way to do it? Some ways that came
> to my mind are:
>
>- PR with the required changes to their package
>- Blocking on the release monitoring bugzilla bug
>- Opening a new bug against their package
>- Mailing them
>
> I am asking because I tried those unsuccessfully, but wanted to make sure
> I did my part before bothering someone with the unresponsive maintainer
> procedure.
>
> Best wishes
> Kai
>

I'd say you did your share already. How long was it since you attempted all
of the above?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: NeuroFedora review swap: mod2c

[Andy Mender]

On Fri, 9 Oct 2020 at 22:07, Ankur Sinha  wrote:

> Hello,
>
> Another really simple single binary package for NeuroFedora is ready for
> review:
> mod2c: https://bugzilla.redhat.com/show_bug.cgi?id=1886957
>
> This is required to build the optimised CoreNeuron component of the
> NEURON simulator.
>
> Would anyone like to swap reviews please?
>
>
Reviewed and approved! Good job!

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Red Hat Bugzilla] Your Outstanding Requests

[Andy Mender]

On Thu, 8 Oct 2020 at 04:10,  wrote:

> The following is a list of bugs or attachments to bugs in which a user has
> been
> waiting more than 3 days for a response from you. Please take
> action on these requests as quickly as possible. (Note that some of these
> bugs
> might already be closed, but a user is still waiting for your response.)
>
> We'll remind you again tomorrow if these requests are still outstanding,
> or if
> there are any new requests where users have been waiting more than 3
> days for your response.
>
> If you want these mails to stop you need to go to the bug[s] and cancel or
> ack the
> needinfo flags. See:
>
>  * https://bugzilla.redhat.com/page.cgi?id=faq.html#flags point 3
>  * https://bugzilla.redhat.com/page.cgi?id=faq.html#miscellaneous point 2
>
> needinfo
> 
>
>   Bug 1872427: Review Request: ec2-hibinit-agent - support for hibernation
> for Amazon ec2 (6 days old)
> https://bugzilla.redhat.com/show_bug.cgi?id=1872427
>
> To see all your outstanding requests, visit:
>
> https://bugzilla.redhat.com/request.cgi?action=queue=package-review%40lists.fedoraproject.org=type
> ___
> package-review mailing list -- package-rev...@lists.fedoraproject.org
> To unsubscribe send an email to
> package-review-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/package-rev...@lists.fedoraproject.org


The above email was sent to the package-rev...@lists.fedoraproject.org
mailing list and keeps popping up due to a needinfo? flag set on the review
request: https://bugzilla.redhat.com/show_bug.cgi?id=1872427

The review request received quite a bit of feedback so not sure why the
flag is still active and why were not specific people pinged instead?

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Indroduction: Rafael Jeffman

[Andy Mender]

On Mon, 5 Oct 2020 at 22:47, Rafael Jeffman  wrote:

> Hello,
>
> I am involved in the development of ansible-freeipa (
> https://github.com/freeipa/ansible-freeipa) and plan to co-maintain it
> for Fedora.
>
> Years ago I helped with the development and packages for an alternative
> Linux distribution, GoboLinux (https://gobolinux.org), which I helped
> develop from the start.
>
> I'm still learning the tools for building packages for Fedora, but since I
> am doing the upstream development on the project, it is convenient to do
> both, so the package can be updated in a more responsive way, avoiding
> issues due to outdated versions, as happened recently.
>
> Regards,
>
> Rafael
>

Welcome! :)

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: Orphaned packages of skisela

[Andy Mender]

On Fri, 2 Oct 2020 at 11:53, Vít Ondruch  wrote:

> Hi,
>
> I was in contact with Sebastian, who used to work for RH and maintained
> several Fedora packages. However, due to chances in his live, he decided to
> orphan his packages. Since he is not subscribed to fedora-devel ML, I'm
> forwarding his email.
>
>
> Vít
>
>
>
>
>  Přeposlaná zpráva 
> Předmět: Fwd: Orphaned packages of skisela
> Datum: Fri, 2 Oct 2020 11:48:32 +0200
> Od: Sebastián Kisela 
> 
> Komu: Vít Ondruch  
>
>
>
> -- Forwarded message -
> From: 
> Date: Fri 2. Oct 2020 at 11:32
> Subject: Orphaned packages of skisela
> To: 
>
>
> Your message to the devel mailing-list was rejected for the following
>
> reasons:
>
>
>
> The message is not from a list member
>
>
>
> The original message as received by Mailman is attached.
>
>
>
>
> -- Forwarded message --
> From: "Sebastián Kisela" 
> To: devel@lists.fedoraproject.org
> Cc:
> Bcc:
> Date: Fri, 2 Oct 2020 11:31:16 +0200
> Subject: Orphaned packages of skisela
> Dear all,
>
> sorry for leaving so much time for that, but I finally orphaned the
> packages I did not manage to maintain.
>
> The list is:
>
> lockdev
> pstoedit
> psutils
> python-ansicolors
> python-yattag
>

If possible, I'd like to pick up python-ansicolors.

Thanks!
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: drop extras-qa from all fedora bugs

[Andy Mender]

On Tue, 29 Sep 2020 at 18:31, Kevin Fenzi  wrote:

> Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> "QA Contact" field set to: extras...@fedoraproject.org.
>
> Bugzilla describes "QA Contact" as:
>
> "The person responsible for confirming this bug if it is unconfirmed,
> and for verifying the fix once the bug has been resolved."
>
> However, also since at least 2007-04-20 emails to that address go to
> /dev/null. (Before that they went to a linux.duke.edu address, so I am
> not sure where they went).
>
> I'd like to propose dropping this from all Fedora bugs.
>
> It's a useless extra email that bugzilla has to generate, network has to
> send and deliver and we have to drop in the bitbucket.
>
> But, perhaps there's some secret clever use for it I am not aware of?
>
> If you can think of some reason to keep it, speak up. ;)
>
> kevin
>

+1 from me as well. It's good to remove it if it doesn't work,
because it gives an impression that extras...@fedoraproject.org is an
existing group.

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Need assistance for luxcorerender to use c++14

[Andy Mender]

On Sun, 20 Sep 2020 at 03:27, Luya Tshimbalanga 
wrote:

> On 2020-09-19 1:32 p.m., Andy Mender wrote:
>
> On Sat, 19 Sep 2020 at 22:27, Richard Shaw  wrote:
>
>> On Sat, Sep 19, 2020 at 3:16 PM Luya Tshimbalanga 
>> wrote:
>>
>>> Hello team,
>>>
>>> openvdb is updated to 7.1.0 in Rawhide and luxcorerender needs to switch
>>> to -std=c++14 similar to that upstream ticket:
>>> https://github.com/AcademySoftwareFoundation/openvdb/issues/795.
>>>
>>> Is there anyone knowing how to do it on the spec file?
>>>
>>> https://src.fedoraproject.org/rpms/luxcorerender/
>>>
>>> It seems  "sed -i 's|${CMAKE_CXX_FLAGS} -std=c++11|${CMAKE_CXX_FLAGS}
>>> -std=c++14|' CMakeLists.txt"  is not enough because "-std=c++11" still
>>> comes back.
>>>
>>
>> Looks like it's specified here:
>>
>>  cmake/PlatformSpecific.cmake
>>
>> I would just patch it instead.
>>
>>
> I would also suggest patching the main CMakeLists file, for instance the
> following way:
> set(CMAKE_CXX_STANDARD 14)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
>
> If that's not too invasive, of course.
>
> Thanks for quick response. The suggestion seems to work. Unfortunately,
> the build failed on openvdb (either using the bundled and 7.1.0 version)
> while working fine on Fedora 32.
>

The build.log logfile isn't informative at all :(. I would try checking all
of the flags the %cmake macro adds to the regular cmake call and try to
build the thing outside of mock, locally.
Also, maybe set the compiler to clang to get better output:
CXX=clang++
CC=clang
Clang, at least in my experience, tends to be a lot more pedantic and
verbose. However, it may behave differently and fail the build in other
ways.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Need assistance for luxcorerender to use c++14

[Andy Mender]

On Sat, 19 Sep 2020 at 22:27, Richard Shaw  wrote:

> On Sat, Sep 19, 2020 at 3:16 PM Luya Tshimbalanga 
> wrote:
>
>> Hello team,
>>
>> openvdb is updated to 7.1.0 in Rawhide and luxcorerender needs to switch
>> to -std=c++14 similar to that upstream ticket:
>> https://github.com/AcademySoftwareFoundation/openvdb/issues/795.
>>
>> Is there anyone knowing how to do it on the spec file?
>>
>> https://src.fedoraproject.org/rpms/luxcorerender/
>>
>> It seems  "sed -i 's|${CMAKE_CXX_FLAGS} -std=c++11|${CMAKE_CXX_FLAGS}
>> -std=c++14|' CMakeLists.txt"  is not enough because "-std=c++11" still
>> comes back.
>>
>
> Looks like it's specified here:
>
>  cmake/PlatformSpecific.cmake
>
> I would just patch it instead.
>
>
I would also suggest patching the main CMakeLists file, for instance the
following way:
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

If that's not too invasive, of course.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Giving away two of my package

[Andy Mender]

On Tue, 15 Sep 2020 at 12:04, Charalampos Stratakis 
wrote:

> Hello,
>
> I've got some packages that I do not have any use for anymore and I'd like
> to give them away. If noone wants them I'll retire and orphan them in ~ a
> week.
>
> python-bna: https://src.fedoraproject.org/rpms/python-bna
>
> This is a Python library of Battle.net Authenticator routines, which
> contains a command-line Battle.net authentication.
>
> Upstream https://github.com/jleclanche/python-bna seems somewhat active
> with last commit on the 23rd of May. Latest version on rawhide is 4.1.0 and
> upstream latest version is 5.0.0
>
> Nothing depends on the package on rawhide.
>

Could I take that package?

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Looking for new Python package maintainers

[Andy Mender]

On Sat, 12 Sep 2020 at 12:16, Dhanesh B. Sabane 
wrote:

> Hey Andy!
>
> > On Mon, 7 Sep 2020 at 07:44, Dhanesh B. Sabane  
> > wrote:
> >
> > If there are no takers, I'd like to maintain the python-blindspinner
> > package. I see there is some room to bring in its "click" dependencies.
>
> I've provided you admin access on python-blindspinner. Thank you so much
> for taking it up! :)
>
> Cheers!
>
>
Cheers! I already started working on it!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Looking for new Python package maintainers

[Andy Mender]

On Mon, 7 Sep 2020 at 07:44, Dhanesh B. Sabane 
wrote:

> Hello folks!
>
> I've been away from all Fedora activities for quite some time and I
> don't see a return anytime soon. There are 6 Python packages which are
> maintained by me and I'd like to hand them over. Following is the list
> of packages:
>
> https://src.fedoraproject.org/user/dhanesh95/projects
>
> Please let me know if anyone would like to take these up by replying to
> this email. I'll orphan all the packages that don't attract a
> maintainer till Sunday, 13th Sept 2020.
>
> Cheers!
>
>
If there are no takers, I'd like to maintain the python-blindspinner
package. I see there is some room to bring in its "click" dependencies.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Is s390 (32-bit) relevant for Fedora alt arch ?

[Andy Mender]

On Fri, 4 Sep 2020 at 11:46, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Friday, 04 September 2020 at 11:00, Daniel P. Berrangé wrote:
> > I'm looking at cleaning up some parts of the QEMU spec and we have
> > conditionals in there testing for s390 arch (aka 32-bit). IIRC it
> > was previously a secondary arch, at least back in the Fedora 22-ish
> > timeframe. I'm not seeing it listed in the alternative arch list
> > currently though:
> >
> >   https://fedoraproject.org/wiki/Architectures
> >
> > Am I right in concluding that 's390' does not need to be considered in
> > RPM spec files now, and thus we can purge any 's390' arch checks ?
>
> Looking at qemu.spec, are you talking about this one?
> https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec#_1005
> Does it also happen on armv7hl and i686? I guess not.
>
> The rest if %ifarch s390 can be dropped as far as I can tell.
>
> You can also drop ppc, ppc64 and mips64, too. For example, here:
> https://src.fedoraproject.org/rpms/qemu/blob/master/f/qemu.spec#_1201
>
>
Will this affect COPR-hosted projects?  So far I've been considering both
i386 and s390 on equal terms to x86_64.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can a bugzilla issue be locked because of spam?

[Andy Mender]

On Mon, 31 Aug 2020 at 14:22, Qiyu Yan  wrote:

> Fabio Valentini  于2020年8月31日周一 下午7:54写道：
> > I'm getting *pretty annoyed* with a similar (but way worse) issue as
> well:
> > https://bugzilla.redhat.com/show_bug.cgi?id=810049
> >
> > It's worse because there are way more spam comments and they get
> > amplified by the mails to the package-review lists as well ...
>
> Thanks to god they didn't spam to mailing list directly.
>
> > I was told to just mark comments as spam and by "magic" those accounts
> > will get banned.
> > Thing is, new accounts get created and just keep on posting spam.
>
> If tons of spam accounts are getting created continuously, then I think
> locking
> bugs won't help. IMHO the only way that will help is ask RedHat to set
> a more strict
> anti-spam procedure when creating new accounts.
>

Pretty much this. I remember seeing similar spam 1-2 months ago and was a
little amused.
Back then it DID hit the packaging mailing list as well, unfortunately.

We probably need one of those "I am human" captchas as part of the
registration process.
Not sure what is Red Hat's policy on this?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bringing fcitx5 to Fedora, and Review Swap

[Andy Mender]

On Fri, 14 Aug 2020 at 12:10, Qiyu Yan  wrote:

> Hello all,
>
> I am going to bring fcitx5 to fedora, fcitx5 is the next generation
> for fcitx and upstream decided to treat fcitx and fcitx5 as a
> different project (different git repo, different file paths and names
> and configuration files). So, like most other distro do, I think we
> are going to treat fcitx5 as a different package.
>
> So I opened several review requests at Bugzilla, overall there are 11
> packages and you can see a block tree here:
>
> https://bugzilla.redhat.com/buglist.cgi?bug_id=1868845_id_type=andblocked=tvp_id=11288407_dir=blocked
>
> The review process should be:
> Stage1: https://bugzilla.redhat.com/show_bug.cgi?id=1868845
> Stage2: https://bugzilla.redhat.com/show_bug.cgi?id=1868846
> Stage3: https://bugzilla.redhat.com/show_bug.cgi?id=1868847
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868848
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868849
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868851
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868854
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868861
> Stage4 :
> https://bugzilla.redhat.com/show_bug.cgi?id=1868853
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868857
>   https://bugzilla.redhat.com/show_bug.cgi?id=1868850
>
> And a copr for the whole thing can be found
> https://copr.fedorainfracloud.org/coprs/yanqiyu/fcitx5 , this may help
> when you are looking for built packages.
>
> This is a lot work, take it freely, and I can do reviews in exchange.
>

I'd be happy to help with this :). I kind of need kana and kanji support as
well.

Cheers,
Andy
___
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

aobook - reviving review request?

[Andy Mender]

Hello all :)

I was just going through the swath of "needinfo cancelled" emails and a
certain package piqued my interest:
https://bugzilla.redhat.com/show_bug.cgi?id=1289070

Just wanted to clarify, if I'm interested in this package, the closed bug
report should not be re-opened and instead I should open a new one and
request a review, correct?

As a beginner Japanese learner this package is of personal interest, but it
might be useful to other people as well.

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: neuro-sig COPR group clean up

[Andy Mender]

On Thu, 6 Aug 2020 at 19:30, Ankur Sinha  wrote:

> Hello,
>
> We've got quite a few unmaintained repos on COPR under the neuro-sig
> group.  I intend to do a bit of housekeeping to remove projects there
> that aren't in use any more. Please take a look and let me know if you
> do not want me to delete a project:
>
> https://copr.fedorainfracloud.org/groups/g/neurofedora/coprs/
>
> I will delete all projects apart from the neurofedora-extra copr on
> Monday, the 10th of August.
>

Of some interest to me would be the python-joblib package, but I see that a
more recent version is already in the repos.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire rgbds

[Andy Mender]

On Sun, 2 Aug 2020 at 21:42, Robert-André Mauchin  wrote:

> On Sunday, 2 August 2020 11:45:13 CEST Andy Mender wrote:
> > On Sat, 1 Aug 2020 at 18:55, Benjamin Lowry  wrote:
> > > I've created a review request to unretire rgbds:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1862705
> > >
> > > -ben
> >
> > Nice, GameBoy development! I'll review it. Do you need a sponsor? I'm not
> > senior enough to be one, but perhaps someone else would be willing to :).
> >
> > Cheers,
> > Andy
>
> Benjamin Lowry is a packager. If you're on Freenode IRC, you can check it
> with
> zodbot .fas/.fasinfo commands.
>
>
My bad and thanks! I haven't used IRC in a while. I'll make sure to drop by
the Fedora channels :).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire rgbds

[Andy Mender]

On Sat, 1 Aug 2020 at 18:55, Benjamin Lowry  wrote:

> I've created a review request to unretire rgbds:
> https://bugzilla.redhat.com/show_bug.cgi?id=1862705
>
> -ben
>

Nice, GameBoy development! I'll review it. Do you need a sponsor? I'm not
senior enough to be one, but perhaps someone else would be willing to :).

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help with reviewing a compiler toolchain

[Andy Mender]

On Wed, 29 Jul 2020 at 15:51, Jonathan Wakely 
wrote:

> On 28/07/20 22:46 +0200, Andy Mender wrote:
> >Dear Fedorians,
> >
> >I really need some help with a review of a GCC toolchain variant I've
> >started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884
> >
> >A Koji build of the most recent SRPM:
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=48035045
> >
> >Some minor issues have been fixed already, but the toolchain seems quite
> >complicated and frankly it went over my head :(.
>
> I'll take a look.
>

Thank you so much, Jonathan! Let me if you'd like me to review something
for you in exchange.
___
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

Help with reviewing a compiler toolchain

[Andy Mender]

Dear Fedorians,

I really need some help with a review of a GCC toolchain variant I've
started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884

A Koji build of the most recent SRPM:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48035045

Some minor issues have been fixed already, but the toolchain seems quite
complicated and frankly it went over my head :(.

I'd be more than happy to review someone else's package(s) in exchange.

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: ar (binutils) segfaulting in Rawhide - known bug?

[Andy Mender]

On Sat, 25 Jul 2020 at 09:11, Jeff Law  wrote:

> On Fri, 2020-07-24 at 22:29 +0100, Richard W.M. Jones wrote:
> > Just upgraded a development machine to:
> >
> > binutils-2.34.0-10.fc33.x86_64
> > gcc-10.1.1-2.fc33.x86_64
> > glibc-2.31.9000-21.fc33.x86_64
> >
> > and a very simple C compile (non-LTO) is now segfaulting:
> >
> > make[3]: Entering directory '/home/rjones/d/nbdkit/common/protocol'
> > /bin/sh ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I../..-Wall -Wshadow -Wvla -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE  -MT
> libprotocol_la-protostrings.lo -MD -MP -MF
> .deps/libprotocol_la-protostrings.Tpo -c -o libprotocol_la-protostrings.lo
> `test -f 'protostrings.c' || echo './'`protostrings.c
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD
> -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c  -fPIC
> -DPIC -o .libs/libprotocol_la-protostrings.o
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wshadow -Wvla
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE -MT libprotocol_la-protostrings.lo -MD
> -MP -MF .deps/libprotocol_la-protostrings.Tpo -c protostrings.c -o
> libprotocol_la-protostrings.o >/dev/null 2>&1
> > mv -f .deps/libprotocol_la-protostrings.Tpo
> .deps/libprotocol_la-protostrings.Plo
> > /bin/sh ../../libtool  --tag=CC   --mode=link gcc -Wall -Wshadow -Wvla
> -Werror -O0 -g -Wp,-U_FORTIFY_SOURCE   -O0 -g -Wp,-U_FORTIFY_SOURCE  -o
> libprotocol.la  libprotocol_la-protostrings.lo
> > libtool: link: ar cru .libs/libprotocol.a
> .libs/libprotocol_la-protostrings.o
> > ../../libtool: line 1734: 2572327 Segmentation fault  (core dumped)
> ar cru .libs/libprotocol.a .libs/libprotocol_la-protostrings.o
> >
> > Core was generated by `ar cru .libs/libprotocol.a
> .libs/libprotocol_la-protostrings.o'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x in ?? ()
> >  binutils-2.34.0-10.fc33.x86_64
> > (gdb) bt
> > Missing separate debuginfos, use: dnf debuginfo-install#0
> 0x in ?? ()
> > #1  0x7f15bd3e03d0 in make_relative_prefix_1.part ()
> >from /lib64/libbfd-2.34.0.20200522.so
> > #2  0x7f15bd3d22db in bfd_plugin_object_p.lto_priv ()
> >from /lib64/libbfd-2.34.0.20200522.so
> > #3  0x7f15bd3401ce in bfd_check_format_matches ()
> >from /lib64/libbfd-2.34.0.20200522.so
> > #4  0x7f15bd340e7a in _bfd_write_archive_contents ()
> >from /lib64/libbfd-2.34.0.20200522.so
> > #5  0x7f15bd348b2a in bfd_close () from /lib64/
> libbfd-2.34.0.20200522.so
> > #6  0x559ee83994b6 in write_archive ()
> > #7  0x559ee8396ac3 in main ()
> >
> > I can't find any BZ for this.  Any ideas what it could be?
> After banging my head on the wall for a few hours, I think I see what's
> happening
> here.
>
> So at a high level ar makes a call to lrealpath.  That naturally goes
> through the
> PLT.  The PLT stub loads the value out of the GOT and jumps to it.  The
> problem
> is the entry in the GOT is *zero* when it should be pointing to the
> resolver.
>
> Now lrealpath is provided by libiberty and a copy is in libbfd.so and the
> GOT
> entry in libbfd.so looked right.  But by the time the program has hit
> main, the
> GOT entry has been reset to zero.  Naturally that's happening inside the
> dynamic
> linker (as expected, confirmed with a watchpoint).  If you've ever had to
> debug
> ld.so, you'll know it's an insanely painful experience, but it proved
> fruitful.
>
> The key was finding out that we were not using the libbfd.so linker map to
> resolve lrealpath, instead we were using the linker map for the main
> program (ar
> in this case).  So natrually it's time to look a bit more closely at the
> symbol
> table for ar.
>
> The main symbol table for ar it doesn't mention lrealpath.  But that's
> just a
> confusing byproduct of having two symbol tables.  What matters to ld.so is
> the
> *dynamic* symbol table.  And ar has lrealpath in its dynamic symbol
> table.  And
> here's the kicker, it's an absolute symbol with the value 0:
>
>  A lrealpath
>
> A symbol in the main program takes precedence over a symbol in a DSO.  So
> the
> dynamic linker was actually doing the right thing given the input it was
> provided.
>
> Now why (*&@#$ does ar have lrealpath as an absolute symbol?  It's got to
> be
> related to the fact that when we link ar we pull in another copy of
> libiberty.
>  In fact, ar links against libiberty twice.  Once via -liberty then again
> against
> libiberty.a (and kindof a 3rd time indirectly via libbfd).  BUt even so
> that
> shouldn't be creating an absolute symbol.  That's just weird.
>
> This smells like a linker bug to me.  Not surprisingly if I force the
> system to
> use ld.gold, then I don't see the bogus absolute symbol and the resultant
> ar
> works just fine.
>
> It's late and I'll dig further over the weekend, but right now this looks
> 

Re: Branch creation for unretired package

[Andy Mender]

On Wed, 22 Jul 2020 at 22:14, Mohamed El Morabity 
wrote:

> Hello,
>
> I'm the maintainer of the nicotine+ package. This package was retired
> before F32 branching last year (no Python 3 support at this time) and
> I unretired it after a review request and a unretirement request
> ticket to releng.
> I requested a branch creation for f32 using "fedpkg request-branch",
> as suggested in the reply to my unretirement ticket. The SCM ticket is
> at https://pagure.io/releng/fedora-scm-requests/issue/27217
> As replied on the ticket, I'm supposed to create by myself the branch
> using git (git branch -b f32/git push -u origin f32), since "The
> branch in PDC already exists" (sic). And I have no right to perform
> the branch creation as suggested:
>
> Am I missing something? Is there a particular procedure for unretired
> packages?
>
>
I was in a similar situation recently. Please, have a look here:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package

In order to unretire a package you need to claim its maintainership and all
already existing branches.

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Help me bring AVIF to Fedora

[Andy Mender]

On Sun, 19 Jul 2020 at 23:15, Robert-André Mauchin 
wrote:

> Hello,
>
> I'd like some help to review:
>  - libavif: https://bugzilla.redhat.com/show_bug.cgi?id=1858419
>
>  - qt-avif-image-plugin:
> https://bugzilla.redhat.com/show_bug.cgi?id=1858639
>
> I can swap with anything.
>
>
Took libavif. Will give it a spin tomorrow after work :).

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: if we want to advocate btrfs

[Andy Mender]

On Sun, 12 Jul 2020 at 18:09, Chris Murphy  wrote:

> On Sun, Jul 12, 2020 at 5:39 AM Andy Mender 
> wrote:
> >
> >On updates, a single automatic corrupted snapshot can
> > potentially hose the entire snapshotted volume.
>
> How do you mean? If this is a sort of superficial corruption like a
> bad/failed/partial update, inconsistency between package manager and
> what's installed - this can be self-contained to a specific snapshot.
> One possible idea for updates is snapshot and do the update out of
> band (not the current running sysroot) on a snapshot. If the update
> fails for whatever reason, destroy the snapshot. Corruption that
> affects multiple subvolumes wouldn't be related to snapshotting, but
> the shared trees: extent, chunk, csum, uuid, etc. trees.
>

I'm sorry, I should've been a little more specific. What I meant was that a
corrupted snapshot can potentially impact the subvolume and put it in a
state in which simply deleting the latest snapshot is not going to help or
can't easily be done.

>
> >Also, if your system is almost broken after the change,
> > no snapshot will help.
>
> I'm not sure about the nature of the brokenness in your example. Btrfs
> does have a concept of a volume wide snapshot, which is the seed
> device. The file system is merely marked read-only, but can have a
> second device added that accepts all writes. If this two device volume
> were to become irreversibly confused, it'd still be possible to revert
> to the read-only device - even temporarily - as a kind of "recovery"
> boot. With extreme prejudice, a true factory reset is possible by
> wiping the read-write 2nd device and starting over. It's also possible
> to use it for replication - by adding a 2nd device and removing the
> 1st, an exact copy is made. This is a whole separate ball of wax, and
> while there are ideas how it might be leveraged, there's no plan to do
> so yet.
>
> I agree, but it requires adding a second device and sometimes that's not
possible or tricky. I extrapolated a lot, but sometimes btrfs tools are
marketed as a "catch all" which can save the user from accidental
installations or updates and that's not always true.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction Ludovic Hirlimann

[Andy Mender]

On Fri, 17 Jul 2020 at 16:14, Ludovic Hirlimann via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
>
> I'm ludo. I've been involved with opensource for a long time now (using
> my first linux in 1996). I have been a mozilla employee for 10 years (as
> the Thunderbird QA lead and then as an IT staffer). I'm back to linux
> since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my
> distribution of choice and been running it since version 21. I like
> opendata and have particpated in musicbrainz and still participate to
> openstreetmap. I've always like maps and thus I'd like to join de Fedora
> packaging community to maintain, or help maintain two packages that are
> Map related : josm and qgis.
>
> I don't have much experience in maintaining packages but I'm more than
> willing to learn.
>
> Have a nice day.
>
> Ludovic
>
> --
> https://www.hirlimann.net/Ludovic/carnet/
>

Maps are super fun! Welcome aboard! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 Change proposal: Replace Linux kernel with BSD kernel

[Andy Mender]

On Sat, 18 Jul 2020 at 04:53, John M. Harris Jr 
wrote:

> On Thursday, July 16, 2020 2:37:55 PM MST Ben Cotton wrote:
> > > F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide
>
> Well, which BSD kernel? ;)
>
>
> This email just serves as a neat example of that potential new format for
> Change proposals.
>

And I thought it's an April Fools' follow-up to the "ditch rpm in favor of
dpkg"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Remove all non UK/USA English spell checker variants from default Fedora installation

[Andy Mender]

On Sat, 18 Jul 2020 at 14:44, Germano Massullo 
wrote:

> All desktop oriented Fedora installers install on the system packages:
> hunspell
> hunspell-en
> hunspell-en-GB
> hunspell-en-US
>
> When a user opens the language list of the spell checker, is has ~24
> different English options, like English (Antigua and Barbuda), English
> (Australia), English (Bahamas), English (Belize), etc. (See screenshot [1])
> People who are not native English speakers have this list even bigger
> because they will have their own language entry, plus others.
>

I never quite understood the necessity for all of those extra English
language packages since early Windows versions. I assumed there was some
forced name overlap with locale packages so that for instance locale
"English (Antigua and Barbuda)" knows that it should look for the "English
(Antigua and Barbuda)" language package.


> Since the huge list is brought by hunspell-en, can we just ship Fedora
> with hunspell-en-GB and hunspell-en-US ?
> Another option could be to move all non GB/USA English variants to other
> hunspell-en-* packages as I said in ticket [2]
>
>
> [1]: https://bugzilla.redhat.com/attachment.cgi?id=1701536
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1858241
>

I see there is a bit of a chicken and egg problem with the GB/US
hunspell-en variants, because they're pulled in as dependencies of
hunspell-en, right? I think your idea (shipping only the GB/US variants
instead of the main hunspell-en package) makes sense.

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: if we want to advocate btrfs

[Andy Mender]

On Sat, 11 Jul 2020 at 18:05, Neal Becker  wrote:

> I think if we really want to advocate for btrfs, we also should provide
> the
> tools to take full advantage of it.  I've been using btrfs since it was
> offered as an option on Fedora.  On Ubuntu, there is a tool "snapper" to
> help manage snapshots.  Unfortunately I didn't manage to get this setup on
> Fedora.  A tool like this would really enhance the btrfs experience, I
> believe.
>
> It's been a while, but I think the reason I didn't get snapper running on
> my
> system is that the arrangement of btrfs subvolumes didn't match the
> default
> ubuntu used.  I have 2 subvolumes, 1 for root and 1 for home.
>

I think it's a great idea and if it's possible to adapt Ubuntu's snapper or
OpenSUSE's solution
(afaik, they have it as a feature within YaST2 and snapshots are taken
prior to each update).
that would make our lives easier. A 1-click GNOME3 integration (through
Files, for instance?)
would be the icing on the cake.

>
> A primary use of snapshots would be to snapshot just before system update,
> so update could easily be rolled back.  This could also be helpful for
> large
> updates within the user directory, for example, using pip to update
> packages.
>

As mentioned above, the way OpenSUSE does it. However, I agree that
snapshots are
more useful when taken intentionally. On updates, a single automatic
corrupted snapshot can
potentially hose the entire snapshotted volume. Also, if your system is
almost broken after the change,
no snapshot will help.

Best,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Need assistance to build openshadinglanguage

[Andy Mender]

On Sat, 11 Jul 2020 at 21:47, Robert-André Mauchin 
wrote:

> %build
> %cmake \
>-B build \
>-DUSE_BOOST_WAVE=ON \
>-DUSE_PARTIO=OFF \
>-DCMAKE_CXX_STANDARD=14 \
>-DLLVM_STATIC=0 \
>-DENABLERTTI=ON \
>-DSTOP_ON_WARNING=OFF \
>-DOSL_BUILD_MATERIALX:BOOL=ON \
>-DCMAKE_INSTALL_DOCDIR:PATH=%{_docdir}/%{name} \
>-DOSL_SHADER_INSTALL_DIR:PATH=%{_datadir}/%{name}/shaders/
>

I'm not familiar with openshadinglanguage, but I don't think enforcing
C++14 like this is a good idea. Conformance to a particular C++ standard
should be left to the project. I am actually contributing to a project
which uses C++11 and builds properly with llvm/clang 10. If it's used as a
workaround, I would add a comment to the spec file + a link to an issue
ticket on GitHub if one exists (or create such a ticket if that's not the
case) :).

Best,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: The future of legacy BIOS support in Fedora.

[Andy Mender]

On Tue, 30 Jun 2020 at 17:26, Adam Williamson 
wrote:

> On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
> > W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
> > > changes it beg the question if now would not be the time to stop
> > > supporting booting in legacy bios mode and move to uefi only
> > > supported boot which has been available on any common intel based x86
> > > platform since atleast 2005.
> >
> > Will you provide replacement for laptop I bought in 2013? Still has some
> > use, runs Fedora 31 just fine. BIOS mode only.
> >
> > My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
> > old but with some hard drives and 16GB of ram it has a use.
>
> I'm also still using a laptop from 2010:
>
>
> https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13-1in-laptop
>
> it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
> (9360 gen) recently stopped booting so unless I can fix that, it will
> have outlived two...
>
> it has no UEFI support either.
>
> HP EliteBook 8570p here. A perfectly capable machine, great for coding,
allowing up to 16GB RAM. I wouldn't just wave off any machine from around
2010-2012, because many are quite sturdy and still useful.

The other thing is virtualization as many have mentioned. It defaults to
BIOS, because it Just Works. I think the idea to get rid of the legacy
"burden" of BIOS is a good one in the long-term, but I don't think the
ecosystem is ready for it yet :(.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please BuildRequire python3-setuptools explicitly

[Andy Mender]

On Tue, 23 Jun 2020 at 18:37, Adam Williamson 
wrote:

> IMBW, but I think I recall the Python packaging guidelines specifically
> said that you could or should (I forget which) just BR python-devel and
> not BR python-setuptools at some point. At this point there seems to be
> no explicit mention, but the sample spec file looks a lot like a
> project that uses setuptools, but does not explicitly BuildRequire
> it...
>
>From the Python packaging guidelines here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
*Packages building for Python 3 will need BuildRequires: python3-devel.*
And also this:

*Packages MAY use the automatic Python dependency generator. This generator
uses upstream egg/dist metadata (such as setuptool’s install_requires
) *

Considering the file vs dir difference in metadata storage, I would say
it's fair to expect dependencies to be strict.
I myself don't have any Python packages yet, but I'll try to pay extra
attention to python3-setuptools in the future :).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Andy Mender]

On Sat, 20 Jun 2020 at 00:38, Miro Hrončok  wrote:

> On 19. 06. 20 23:11, Ben Cotton wrote:
> > All make invocations in spec files that don't use the install target
> will be
> > modified to use the %make_build macro
>
> Many Python packages build Sphinx documentation with variant of "make
> html".
> Such invocation will always be just 1 job. Hence there is no benefit of
> parallel
> make. Replacing it with %make_build will only make it harder to read.
>
> Can we exclude such cases? Or do we want all make invocations to be
> mecronized,
> even if there is no benefit?
>

The way I understand it is that %make_build would be a replacement for the
"make all" target with N jobs, which is called by default when you just run
"make". That would be the all-in-1 scenario when you want to build the main
binaries, docs and examples. If there is only 1 target (html) and you run
"make" with N jobs, there is no downside, because only that single target
gets picked up.

I really like the proposal and kind of sort of agree with Tomasz that if a
build requires -j1 explicitly and fails with -jN, it means the target
dependency tree was not defined properly and should be fixed. The only time
I ever run "make" with -j1 is when debugging to get a clean, sequential log
output. So the way one can handle target resolution issues is with the
proposed %global _smp_mflags -j1 or with a unified patch + submission to
upstream to fix the bug.

~Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Highlights from the latest Copr release 2020-06-10

[Andy Mender]

> - Copr project "runtime" dependencies were implemented.  Newly you can
>   specify set of repositories your project depends on. Such repositories
>   will be installed together with the copr project repo file (e.g., by
>   'dnf copr enable YOU/YOUR_PROEJCT').  Those repositories can be other
>   project in Copr or some 3rd party repository.  This is very similar to
>   build-time dependencies implemented long time ago.  Take a look at
>   blog post:
>
> https://fedora-copr.github.io/posts/runtime-dependencies


 This is fantastic news! In one of my COPR projects the cross-dependency
prevented me from being able to host the project properly.

- Cancel build feature was fixed, and the "cancel" request should reliably
>   release all occupied builder machines (allowing them to be re-used, or
>   terminated).
>
> Also this. Thank you!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Regression in build_make macro?

[Andy Mender]

On Wed, 17 Jun 2020 at 20:47, Igor Raits 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Wed, 2020-06-17 at 20:38 +0200, Andy Mender wrote:
> > Howdy everyone!
> >
> > Some time ago we discussed the misuse of the make %{?_smp_mflags}
> > construct
> > and that one should switch to %build_make. I tried that and all of my
> > COPR
> > builds failed completely. Here's a log from one of them:
> >
> https://download.copr.fedorainfracloud.org/results/andymenderunix/7kaa/fedora-32-x86_64/01475167-7kaa/builder-live.log.gz
> >
> > Is there anything I'm missing?
>
> Yes, the macro is named %make_build :)
>
> That did the trick, thanks! I guess I need more sleep after all.
___
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

Regression in build_make macro?

[Andy Mender]

Howdy everyone!

Some time ago we discussed the misuse of the make %{?_smp_mflags} construct
and that one should switch to %build_make. I tried that and all of my COPR
builds failed completely. Here's a log from one of them:
https://download.copr.fedorainfracloud.org/results/andymenderunix/7kaa/fedora-32-x86_64/01475167-7kaa/builder-live.log.gz

Is there anything I'm missing?

Cheers,
Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

[Andy Mender]

On Tue, 16 Jun 2020 at 07:10, Igor Raits 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2020-06-16 at 02:21 +0200, Kevin Kofler wrote:
> > Ben Cotton wrote:
> > > == Summary ==
> > > %cmake macro will be adjusted (-B
> > > parameter)
> > > to use separate build folder (already standardized
> > > %{_vpath_builddir} macro). Additionally,
> > > %cmake_build, %cmake_install and
> > > %ctest macro will be created (and backported to the
> > > older
> > > supported Fedora releases) to perform various operations that are
> > > commonly used with CMake in a backend-agnostic (Makefiles, Ninja,
> > > etc.) way.
> > >
> > > Packages that will stop building are trivial to fix and will be
> > > adjusted either by maintainers or change owners.
> > >
> > > == Owner ==
> > > * Name: [[User:ignatenkobrain|Igor Raits]], [[User:besser82|Björn
> > > Esser]], [[User:ngompa|Neal Gompa]]
> > > * Email: ignatenkobr...@fedoraproject.org,
> > > besse...@fedoraproject.org,
> > > ngomp...@gmail.com
> >
> > How does this affect the many packages that already build in a
> > separate
> > build folder manually? There are even several specfile templates that
> > contain the boilerplate for that.
>
> If they assume that builddir will be in `.`, they will break. And we
> will fix them.
>
> To prevent breaking, it is enough to specify `-B .` or setting
> `%{_vpath_builddir}` to `.`.
>
> I've been using CMake very actively for around a month now and I always
assumed that using the `-B` flag to point to a `build` dir is the way to
go. It's even nicely covered in the Modern CMake guide:
https://cliutils.gitlab.io/modern-cmake/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Regression] Blender build failure on armv7 architecture

[Andy Mender]

On Fri, 12 Jun 2020 at 04:58, Luya Tshimbalanga 
wrote:

> Hello team,
>
> Blender 2.83.0 successfuly built on all but one architecture: armv7h.
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1522859
>
> Could these maintainers investigate the cause ? I intend to temporarly
> exclude it until the fix is publishe.
>
> Thanks
>
> I'm not a maintainer, but I had a quick look at the build log and other
than a lot of regular compiler warnings, it doesn't seem clear why the
build fails. Could it be that the environment ran out of disk space? I've
seen this happen in my COPR builds on arm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Increasing the packaging team: regular workshops/vFADs/classroom sessions on packaging

[Andy Mender]

Hiya,

As someone who is trying to get into packaging in Fedora, I would really
really appreciate the docs being less dispersed:
- https://docs.fedoraproject.org/en-US/packaging-guidelines/
- https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package
- https://rpm-packaging-guide.github.io/
- etc.

more up-to-date and more comprehensive. I used to work with FreeBSD a lot
before and there although packaging was a lot harder due to the clunky
reliance on Makefiles, the FreeBSD Porter's Handbook thoroughly covered
almost everything, from absolute basics to minute details. Many of the RPM
packaging guides are extremely basic and miss important macros like
%{qmake_qt5}
or changes like the obsolition of %{?_smp_mflags}. Heck, at one point I
even had to refer to some ancient guides (http://ftp.rpm.org/max-rpm/ and
http://wiki.rosalab.ru/en/index.php/Rpmlint_Errors), because the official
docs omit important nuances. In all honesty, there should ever be only *one*
document on packaging, possibly split into multiple pages for committing
convenience. Also, changes and updates to RPM spec design should be
simultaneously reflected in the official docs.

The Fedora Magazine articles are great to lower the barrier of entry, but
after that the prospective packager is lost in details which will
eventually come up in the review process and will have to be addressed on a
per-package basis.

As someone who just recently started out with packaging and has a fresh
view on the problem, I would be more than happy to help out with the docs
:).

Best,
Andy

On Wed, 27 May 2020 at 12:31, Miroslav Suchý  wrote:

> Dne 21. 05. 20 v 10:52 Ankur Sinha napsal(a):
> > Hi folks,
> >
> > The packaging team is generally quite stretched, and we frankly need
> > more people helping us out.
> >
> > The main issue with newcomers taking on packaging is that the learning
> > curve here is much more technical then a lot of other areas in Fedora.
> > So, while it is still expected that folks read the docs and learn things
> > themselves, perhaps we could be more active in helping them?
> >
> > We've had rpm packaging classroom sessions in the past. Are any folks
> > interested in restarting these? Maybe a different SIG could do a session
> > each month to help newcomers get started with packaging their tools?
> > Sponsors, what do you think?
>
> There is already:
>
> https://docs.pagure.org/copr.copr/user_documentation.html#how-can-i-package-software-as-rpm
> It already includes two recordings of such workshops.
>
> And I encourage everyone to particapate on
>   https://rpm-packaging-guide.github.io/
> You can contribute to this at:
>   https://github.com/redhat-developer/rpm-packaging-guide
>
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
>
> ___
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning a bunch of my packages (part 1 of X)

[Andy Mender]

>
> LXQt as a general project:
>  rpms/featherpad
>  rpms/libfm-qt
>  rpms/liblxqt
>  rpms/liblxqt-mount
>  rpms/light-locker
>  rpms/lximage-qt
>  rpms/lxmenu-data
>  rpms/lxqt-about
>  rpms/lxqt-admin
>  rpms/lxqt-build-tools
>  rpms/lxqt-common
>  rpms/lxqt-config
>  rpms/lxqt-config-randr
>  rpms/lxqt-globalkeys
>  rpms/lxqt-l10n
>  rpms/lxqt-notificationd
>  rpms/lxqt-openssh-askpass
>  rpms/lxqt-panel
>  rpms/lxqt-policykit
>  rpms/lxqt-powermanagement
>  rpms/lxqt-qtplugin
>  rpms/lxqt-runner
>  rpms/lxqt-session
>  rpms/lxqt-sudo
>  rpms/lxqt-themes
>  rpms/lxqt-wallet
>  rpms/nm-tray
>  rpms/obconf-qt


I'm a heavy LXQt user. Does that mean that if those packages get orphaned
for good, they will be dropped from the repositories?

Cheers,
Andy

On Fri, 5 Jun 2020 at 08:41, Didier Fabert  wrote:

> Hi,
>
> I'm taking cmatrix, thank you Raphael
>
> Regards,
>
> Didier.
>
> Le 04/06/2020 à 20:02, Raphael Groner a écrit :
> > Hi,
> >
> > src.fedoraproject.org tells me I'm involved in exactly 100 packages at
> the moment. Therefore I decided to orphan at least a bunch of them or drop
> membership as co-maintainer, because I'm running out of time to actively
> maintain all of them. Most of those packages didn't get updates in the
> recent times or have stalled upstreams.
> >
> > Thanks for the great experience and the fun in the last years. Please
> feel free to pick those packages if you still think there of any usefulness
> in Fedora.
> >
> > Regards,
> > Raphael
> >
> >  rpms/amqp
> >  rpms/cmatrix
> >  rpms/csvdiff
> >  rpms/ecryptfs-utils
> >  rpms/jp2a
> >  rpms/json-table
> >  rpms/libsysstat
> >  rpms/mockito
> >
> > LXQt as a general project:
> >  rpms/featherpad
> >  rpms/libfm-qt
> >  rpms/liblxqt
> >  rpms/liblxqt-mount
> >  rpms/light-locker
> >  rpms/lximage-qt
> >  rpms/lxmenu-data
> >  rpms/lxqt-about
> >  rpms/lxqt-admin
> >  rpms/lxqt-build-tools
> >  rpms/lxqt-common
> >  rpms/lxqt-config
> >  rpms/lxqt-config-randr
> >  rpms/lxqt-globalkeys
> >  rpms/lxqt-l10n
> >  rpms/lxqt-notificationd
> >  rpms/lxqt-openssh-askpass
> >  rpms/lxqt-panel
> >  rpms/lxqt-policykit
> >  rpms/lxqt-powermanagement
> >  rpms/lxqt-qtplugin
> >  rpms/lxqt-runner
> >  rpms/lxqt-session
> >  rpms/lxqt-sudo
> >  rpms/lxqt-themes
> >  rpms/lxqt-wallet
> >  rpms/nm-tray
> >  rpms/obconf-qt
> > ___
> > 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
> >
> ___
> 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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: unretiring llvm7.0

[Andy Mender]

If I understand correctly, the sudden disappearance of llvm7.0 means that
now ghc is in danger as a package, because it's missing the toolchain
needed to build & package it?

I did a quick `dnf search llvm` and I see the following on my main Fedora
32 box:
llvm5.0.i686 : The Low Level Virtual Machine
llvm5.0.x86_64 : The Low Level Virtual Machine
llvm6.0.i686 : The Low Level Virtual Machine
llvm6.0.x86_64 : The Low Level Virtual Machine
llvm7.0.i686 : The Low Level Virtual Machine
llvm7.0.x86_64 : The Low Level Virtual Machine
llvm8.0.i686 : The Low Level Virtual Machine
llvm8.0.x86_64 : The Low Level Virtual Machine
llvm9.0.i686 : The Low Level Virtual Machine
llvm9.0.x86_64 : The Low Level Virtual Machine

However, https://apps.fedoraproject.org/packages lists only llvm9.0 and
llvm10.0 builds.

I think it's an interesting problem in general. Perhaps it would be good to
have at least 1 extra version of GCC and LLVM other than the current
mainline?

Best,
Andy

On Sat, 30 May 2020 at 08:32, Jens-Ulrik Petersen 
wrote:

> In March llvm7.0 which had been orphaned for some reason, got retired.
> Unfortunately I missed the warning mails that Miro sent here.
>
> llvm7.0 is needed for aarch64 ghc:8.8,
> and for ghc-8.8.3 planned for F33.
>
> So I would like to unretire llvm7.0.
>
> Thanks, Jens
>
> ___
> 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
>
___
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

Self Introduction: Andrzej Bylicki (Andy Mender)

[Andy Mender]

Hello everyone!

Introduction:
After reading the Fedora docs on packaging, I decided I would like to join
the Fedora project initially as a package maintainer/reviewer and perhaps
later as a source code committer. Here's the bug report for the package I'd
like to revive/unorphan: https://bugzilla.redhat.com/show_bug.cgi?id=1837107

About me:
I'm a seasoned Python developer and Unix aficionado. I would consider
myself above intermediate in Python (2 and 3), but also quite advanced in
C/C++ and beginner in Go and Java. Currently, I work as a software
engineer/devops, though I have plenty of experience in Unix system
administration as well.

Hope to hear from you all soon :)
~Andy
___
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