Review Request to unretire MinEdit

[Benson Muite]

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

Re: SoPlex and SCIP review swaps

[Benson Muite]

On 20/02/2024 19.08, Kai A. Hiller wrote:
> I’ll take care of scip. I’d be glad if you could take a look at one or
> more of these (not urgent, though):
> 
> golang-gopkg-macaroon2:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250314
> golang-github-matrix-org-util:
> https://bugzilla.redhat.com/show_bug.cgi?id=2250311
> golang-github-matrix-org-gomatrix:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2250312
> 
>>>> - papilo: https://bugzilla.redhat.com/show_bug.cgi?id=2253360
>>>> - soplex: https://bugzilla.redhat.com/show_bug.cgi?id=2253361
>>>> - scip: https://bugzilla.redhat.com/show_bug.cgi?id=2253362
>>>> - coin-or-HiGHS: https://bugzilla.redhat.com/show_bug.cgi?id=2253363
>>>>
>>>> These will need to be reviewed with respect to the [COPR mentioned
>>>> above](https://copr.fedorainfracloud.org/coprs/jjames/SCIP/), since I
>>>> can't build asl in Rawhide without breaking the existing mp package,
>>>> so the rest all has to be done at once in a side tag.
>>>>
>>>> Let me know what I can review for you in exchange for the above
>>>> reviews.
>>> Thanks to Benson Muite, papilo has been reviewed and soplex is under
>>> review.  I still need reviewers for scip and coin-or-HiGHS.  If you
>>> don't have a package that needs review right now, I can give you a
>>> rain check, or I can do some other task for you.
>> I still need a reviewer for scip.  If we can get the last couple of
>> reviews finished by tomorrow, I will still have time to get this all
>> built before F40 beta freeze.  Please help.
Will get mine done tomorrow.
> -- 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Regaining Packager Status

[Benson Muite]

Hi Anirban,

On 26/01/2024 08.13, Anirban Mitra via devel wrote:
> I want to retake fbf-mukti-fonts and uniol-fonts of which i am the upstream 
> developer. I have lost my membership in packager group and I could not log in 
> the pkg maintenance systtem 
> 

Please see:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/#returning
You will need to open a ticket at
https://pagure.io/packager-sponsors/new_issue/ and reconfirm your identity.

Once done am happy to review the packages. Please create tickets in
Bugzilla.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Review Service and setting the AutomationTriaged keyword

[Benson Muite]

Many thanks Jakub. It is a helpful tool.  Hopefully it will also
encourage more community contributions to help improve and update Fedora
Review as well.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review swaps

[Benson Muite]

On 11/17/23 19:16, Jerry James wrote:
> Who would like to swap package reviews?  I've got 4 packages that need
> to be reviewed:
> 
> ocaml-ptime: https://bugzilla.redhat.com/show_bug.cgi?id=2242903
> 
> ocaml-crunch: https://bugzilla.redhat.com/show_bug.cgi?id=2242904
> 
> ocaml-stdlib-random: https://bugzilla.redhat.com/show_bug.cgi?id=2242905
> 
> JUnitParams: https://bugzilla.redhat.com/show_bug.cgi?id=2247877
> 
> 
Will take JUnitParams
> Let me know what I can review for you.
> 
> A note for those trying to get us to move from this mailing list to
> discussion.fedoraproject.org .  I
> have been asking for these reviews there for 3 weeks now [1], and am
> getting nowhere.  We don't seem to have a critical mass of packagers
> looking there for package reviews.
> 
> [1]
> https://discussion.fedoraproject.org/t/1-c-1-java-and-3-ocaml-reviews/93946 
> 
> -- 
> Jerry James
> http://www.jamezone.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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Benson Muite]

On 11/8/23 07:28, Cristian Delgado wrote:
> Hi Benson,
> I've made the pull request, thanks for your feedback.
> 
Welcome. Merged it.  It is helpful to do a few mock reviews
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#commenting
> Also i've also raised an issue at package sponsors, hoping someone could
> sponsor me, I'll try to contact them through matrix and IRC
> 
> Thanks again
> 
> Cristian Delgado
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Benson Muite]

On 11/7/23 08:21, Cristian Delgado wrote:
> Hi, everyone
> 
> I want to take over python-gpiozero,but I'm not a packager at the
> moment, i'm really eager to contribute to the community.
> 
> I update the package, to the latest version upstream, here you can find
> the spec file
Welcome. Have taken the package until you get sponsored to become a
packager.  Can you make a pull request at:
https://src.fedoraproject.org/rpms/python-gpiozero
> 
> SPEC:https://download.copr.fedorainfracloud.org/results/crisdel/python3-gpiozero/fedora-rawhide-x86_64/06589716-python-gpiozero/python-gpiozero.spec
>  
> 
> SRPM: 
> https://download.copr.fedorainfracloud.org/results/crisdel/python3-gpiozero/fedora-rawhide-x86_64/06589716-python-gpiozero/python-gpiozero-2.0.0-11.fc40.src.rpm
>  
> 
> my FAS username is crisdel
> I kindly request if someone can sponsor me, I really want to become a
> proficient package maintainer so all feedback is always welcome.
> 
See
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
> Thanks for your time.
> Cristian Delgado
> "You can't improve until you make mistakes"

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

[EPEL-devel] Re: Upgrade of mlpack in epel-7

[Benson Muite]

On 10/30/23 16:37, Troy Dawson wrote:
> On Sun, Oct 29, 2023 at 10:35 AM Benson Muite
> mailto:benson_mu...@emailplus.org>> wrote:
> 
> Would like to upgrade mlpack from 3.4.2 to 4.2.1
> Version 3 is no longer maintained, and there do not seem to be
> dependencies on mlpack, at least in Fedora. This is prompted by
> CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
> https://src.fedoraproject.org/rpms/mlpack/pull-request/12
> <https://src.fedoraproject.org/rpms/mlpack/pull-request/12>
> 
> 
> Since this is for a CVE, that is good.
> Also, it looks like nothing depends on it, so that also makes things easier.
> 
> Do you know of any features that were removed between version 3.x and 4.x?
> In short, if someone were actively using version 3.x of mlpack, do you
> know what they would need to change (if anything) to use the version 4.x?
> 
The biggest change is that for development it became a header only
library that requires C++14.  Had not realized non breaking changes
should not be made, so the spec file is for version 4, but it does not
build and so version 3.4.2 is still shipped.  Can revert changes in git
history so that 3.4.2 is used, and update requirements on included stb
header files if that is allowed.
> Troy
> 
> 
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Upgrade of mlpack in epel-7

[Benson Muite]

Would like to upgrade mlpack from 3.4.2 to 4.2.1
Version 3 is no longer maintained, and there do not seem to be
dependencies on mlpack, at least in Fedora. This is prompted by
CVE-2021-28021, CVE-2021-42715, CVE-2021-42716, and CVE-2022-28041
https://src.fedoraproject.org/rpms/mlpack/pull-request/12
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Food SIG

[Benson Muite]

Hi,

Recently submitted a review for AnyMeal - A free and open source recipe
management software[1]. There is other free and open source software
related to food see for example [2]. Would there be interst in a SIG to
discuss FOSS software for food? The target members are all people who
like food of any kind, (eg. healthy, comfort, organic, gluten free,
regional specialities ...) would be encouraged to participate. Possible
activities include sharing recipes, testing, maintaining and improving
FOSS food apps, sharing tips on local food options etc.

1) https://bugzilla.redhat.com/show_bug.cgi?id=2244407
2)
https://gitlab.com/meonkeys/lp2023-digital-recipe-workshop/-/blob/main/workshop.md?ref_type=heads

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

Local network enabled applications

[Benson Muite]

Am reviewing Qnearbyshare:
https://bugzilla.redhat.com/show_bug.cgi?id=2241003
It uses a protocol similar to:
https://github.com/grishka/NearDrop/blob/master/PROTOCOL.md
For sending a file, a temporary server is initiated which is accessible
on the local network.  To receive files, the service temporarily scans
for available servers on the local network and then allows exchange
after entering a shared secret. Dbus and Avahi are used to provide local
network services. Does such a service need a FESCO exception?

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

Unretirement: Impallari-Lobster-Fonts

[Benson Muite]

Hi,

Would like to unretire Impallari-Lobster-Fonts:
https://bugzilla.redhat.com/show_bug.cgi?id=2242129

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

Re: Adding Passim as a Fedora 40 feature?

[Benson Muite]

On 8/25/23 20:24, Richard Hughes wrote:
> On Fri, 25 Aug 2023 at 16:00, Benson Muite  wrote:
>> Better as optional rather than default-enabled.  It would likely be
>> helpful for computers in an institutional setting where the LAN is well
>> controlled.
> 
> So that's the thing; if it's default disabled then I can say with
> certainty that almost nobody will use it and we won't see any
> reduction in network traffic at all.

a) The default time for checking for updates can be increased.
b) In some places, internet access is charged per byte downloaded, so
there will be quite some interest in local caching, and an easy to use
Squid Proxy replacement
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Adding Passim as a Fedora 40 feature?

[Benson Muite]

On 8/25/23 14:42, Richard Hughes wrote:
> Hi all,
> 
> I was thinking of adding Passim as a default-installed and
> default-enabled dep of fwupd in the Fedora 40 release. Before I create
> lots of unnecessary drama, is there any early feedback on what's
> described in https://github.com/hughsie/passim/blob/main/README.md
> please.
>
Better as optional rather than default-enabled.  It would likely be
helpful for computers in an institutional setting where the LAN is well
controlled.

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

Re: Package deprecation policy

[Benson Muite]

On 6/30/23 17:05, Ben Beasley wrote:
> On 6/30/23 04:34, Benson Muite wrote:
>> There is at present no policy on when and why packages should be
>> deprecated.  Have made a proposal to allow deprecation of packages only
>> when they fail to build or are a security concern.  In other cases,
>> orphaning and retirement should be done. Comments and suggestions for
>> improvement are welcome.
> 
> There are other valid reasons to deprecate packages. Upstream
> deprecation is one of them.
> 
> For example, three of the subpackages in python-opentelemetry are
> currently deprecated because upstream has deprecated them, and I expect
> them to disappear in the future. Deprecating the subpackages keeps
> anyone from packaging something that depends on them and then being
> impacted a few months later by their removal in Rawhide.
> 
Deprecation due to upstream deprecation is reasonable.  Would be great
to have this in such a policy.
> In my experience, deprecation is used extremely sparingly (there are
> only 42 spec files in the entire distribution with the string
> “deprecated()”), and I am not aware of any issues with it being used
> carelessly. Furthermore, the current policy already requires a
> FESCo-approved change to deprecate anything that has dependent packages.
>
 > I am not convinced that the proposed Change clearly or accurately
> reflects all of the valid uses for deprecation, nor am I convinced that
> attempting to codify these uses is useful to packagers or solves an
> actual problem in the distribution or community.
>
Aspell was recently deprecated due to lack of recent activity upstream.
It would be good to have guidance for deprecation vs. orphaning.  The
deprecation process does provide advance notice of an action which
orphaning does not. Advance notice is good to have where possible for
packages with many dependencies or a wide user base.

>> This would also likely impact package review guidelines, since there are
>> packages that people may want in Fedora, which build but do not have
>> much upstream activity.
> 
> There certainly is no extant policy on how much upstream activity a
> package needs to have to enter or remain in Fedora, nor do I think it is
> reasonable to regulate this on anything other than a case-by-case basis.
> There are decades-old scientific tools with deceased authors that are
> still perfectly useful, there are tools that are “done” but have
> upstreams that spring into action after ten years of quiescence if a new
> bug is found, there are network libraries with large attack surfaces
> that might cause concern if an upstream PR or issue languishes untriaged
> for a few months, and there is everything in between.
Essential crypto libraries have greater review.
> 
> The document
> https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/
>  already warns about the added maintenance burden of packaging projects with 
> inactive or absent upstreams, and it is reasonable for a package reviewer to 
> warn the submitter about an inactive upstream. It still makes sense to 
> package these projects when they are sufficiently useful or when good 
> alternatives are not yet available.
> 
The recommendations made are reasonable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package deprecation policy

[Benson Muite]

On 6/30/23 14:00, Vít Ondruch wrote:
> 
> Dne 30. 06. 23 v 10:34 Benson Muite napsal(a):
>> There is at present no policy on when and why packages should be
>> deprecated.  Have made a proposal to allow deprecation of packages only
>> when they fail to build
> 
> 
> There is a catch. Packages which are FTBFS cannot be marked as
> deprecated, because there is no way to inject the `Provides:
> deprecated()` there without the build.
> 
> 
Thanks for the feedback.  Python 2 packages went through this because
the eco system no longer supports them.  A regular FTBFS for a single
package can be orphaned and retired.  If a required dependency does not
build in rawhide, then one cannot add a package that requires it to Fedora.
> Vít
> 
> 
>>   or are a security concern.  In other cases,
>> orphaning and retirement should be done. Comments and suggestions for
>> improvement are welcome.
>>
>> This would also likely impact package review guidelines, since there are
>> packages that people may want in Fedora, which build but do not have
>> much upstream activity.
>>
>> 1)
>> https://fedoraproject.org/wiki/Changes/DeprecationPolicy#Upgrade%2Fcompatibility_impact
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Package deprecation policy

[Benson Muite]

There is at present no policy on when and why packages should be
deprecated.  Have made a proposal to allow deprecation of packages only
when they fail to build or are a security concern.  In other cases,
orphaning and retirement should be done. Comments and suggestions for
improvement are welcome.

This would also likely impact package review guidelines, since there are
packages that people may want in Fedora, which build but do not have
much upstream activity.

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

Unretire python-diskcache

[Benson Muite]

Would like to unretire Python-diskcache
https://bugzilla.redhat.com/show_bug.cgi?id=2215710
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

[Benson Muite]

> 
> This doesn't impact Fedora, but will certainly impact the various
> RHEL rebuilds whether community based (AlmaLinux, Rocky Linux),
> or fully commercial (Oracle OEL). Those distros can still provide
> the initial point releases, but will have to do all the work to
> figure out backports for bug fixes/CVEs/etc within the release.
> This is going to be a serious burden for those distros.
> 
At present Red Hat is the primary sponsor for Fedora.  RHEL is one
downstream of Fedora, but there are others including Amazon Linux, Alma,
Rocky, CentOS, Miracle Linux, Qubes OS, Open Euler, Linpux etc. As a
result, Fedora development is healthy and robust, and may cost Red Hat
less than other development models. It may be good to evolve the Fedora
governance model to recognize other significant contributors (both
resources and time), either individually or corporate and provide a
means for these contributors to also contribute to the governance of the
project should they want to do so.
> With regards,
> Daniel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Decommissioning Nuancier

[Benson Muite]

On 6/20/23 06:44, Ryan Lerch wrote:
> Plans are underway to decommission Nuancier[1]. Nuancier was custom
> built for the single task of voting for Fedora supplementary
> wallpapers, and has not been used for this task since Fedora 32.
> 
Had offered to update this. Would it be ok for me to write something
new?  Alternatively, Discourse does have some voting plugins. Could
create another plugin if that would be helpful.  Note that Discourse is
used by the Krita community to enable discussions on artwork
https://krita-artists.org/ though storage requirements can increase
somewhat.

To give better vote privacy, one typically has three separate databases,
ideally run completely separately. One database contains eligible voters
does vote verification, and a third contains a tally. A simpler but well
tested system is implemented in:
https://github.com/benadida/helios-server
Maybe this could also be helpful for Fedora elections?

> As such, Fedora Infra is moving towards decommissioning this
> application, and archiving all the data, images, and voting
> statistics. Also, the source of this application[2] will be archived
> in GitHub.
> 
> For ongoing information and discussion on this process please view the
> fedora-infrastructure ticket [3]
> 
> 
> 
> [1] - https://apps.fedoraproject.org/nuancier/
> [2] -  https://github.com/fedora-infra/nuancier
> [3] - https://pagure.io/fedora-infrastructure/issue/11371
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Herald Yu Betty Liu

[Benson Muite]

On 6/1/23 13:09, Betty Liu wrote:
> Hi I also come from China ~ I'm Betty and now I'm learning about how to 
> become a packager (so I think it's not the time to do a self-introduction in 
> devel now hhh)
> 
> Nice to have someone come from the same country! If you have the time maybe 
> you can teach me about packaging and community! You can find more about me 
> here https://acyanbird.com/ www
你好欢迎  (Hello! Welcome!). You may find it helpful to join a SIG[1], for
example Deepin[2] has a need for packagers and mandarin skills are
useful to co-ordinate with upstream. Kernel development and testing
might also be of interest[3].

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

Re: employment related packager groups

[Benson Muite]

On 5/26/23 20:39, Kevin Fenzi wrote:
> Greetings everyone. 
> 
> Today we have packager groups used in src.fedoraproject.org to allow a
> group of people to maintain packages. In the past this has been used for
> SIGs/packaging areas. ie, python-packaging-sig or robotics-sig or the
> like. 
>
Thanks for the notice.  Can comment on ticket as well if preferred,
though possibly the tickets should be merged.

> FESCo has been asked about creating company related groups.
> ( https://pagure.io/fesco/issue/2966 and https://pagure.io/fesco/issue/2929 )
> ie, foocorp-sig / foocopr-packagers. These groups would then be used to
> help maintain packages that foocorp finds of interest/value. 
> This would help companies manage the people they pay to contribute.
> It would allow them to more easily add/remove employees as time goes on
> instead of someone having to go and add/remove someone from a bunch of
> packages.
> 
> So, I promised to start a thread here about this. 
> 
> Should such groups require FESCo approval?
> 
Probably yes.
> If so, what would be requirements to approve/deny?
> 
May need to revise SIG guidelines, it may be helpful for technology
related to a company rather than just company employees since users of
the technology may want to engage in packaging.  With increasing
diversity in computer architectures, expect to see a number of
specialized builds.

Encouraging inclusion of packages is good - there are people who may not
be packagers but can do the initial preparation to enable a SIG to adopt
a package.  However, want good reviews as well, there may be a
disincentive for thorough reviews just to include a package.  May also
be good to run a light weight version of fedora review on packages to
ensure they get updated after they have been included.
> Should we require some documentation? ie, should the group have to make
> a doc/wiki page explaining what it's for and how to reach group owners
> in case of problems?
> 
Yes.  Should also have a list of group members.
> Thoughts?
> 
> kevin
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Intern Introduction & Goals (Open 3D Engine)

[Benson Muite]

On 5/18/23 16:30, Nicholas Frizzell wrote:
> Hello,
> 
> My name is Nicholas and I'm working this summer as an intern with Red
> Hat. My primary objective this summer is to improve support for the
> O3DE project (https://www.o3de.org/) in Fedora and eventually have it
> packaged and available for install through the official repositories.
> If anyone is interested in this topic or has any advice/suggestions to
> help this project along feel free to reach out.
Welcome to Fedora.  Thanks for improving the available packages.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review request for oclock package (orphaned since F35)

[Benson Muite]

Ranjan,

On 5/14/23 13:46, Globe Trotter via devel wrote:
> Thanks! The package was cleared  on BZ some time ago. Is there some 
> additional review that is needed?
> 
Sorry, that is correct. Usually state is set to post. It seems to have
been unretired:
https://pagure.io/releng/issue/11417

Though project ownership has not been updated:
https://src.fedoraproject.org/rpms/oclock

It seems Slim has been unretired:
https://pagure.io/releng/issue/11310
and project ownership updated:
https://src.fedoraproject.org/rpms/slim
Maybe just need to add the new files?

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

Re: Review request for oclock package (orphaned since F35)

[Benson Muite]

Hi Ranjan,

Thanks for contributing to Fedora and maintaining packages.

On 5/14/23 03:27, Globe Trotter via devel wrote:
> Thanks, Kevin! No  problem, no rush, I did not quite know what to expect, 
> hence the questions. Thanks again!
> 
> 
It seems it is just the review that is needed:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/#unorphaning_and_unretiring_packages

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

Generally reviews go faster if the person asking for the review does a
review of another package - many people ask for review swaps on this
list. For a package with a reviewer you can add NEEDINFO in bugzilla so
that if an person has assigned themselves as reviewer does not respond
after a while, a new reviewer can take it up.
> 
> 
> 
> 
> On Saturday, May 13, 2023 at 06:12:33 PM CDT, Kevin Fenzi  
> wrote: 
> 
> 
> 
> 
> 
> On Sat, May 13, 2023 at 02:41:10AM +0200, Sandro wrote:
> 
>> On 11-05-2023 17:57, Globe Trotter via devel wrote:
>>> Still no movement on my unretire requests for both slim and oclock, not 
>>> even a request for additional information.
>>
>> Tags have been added to the ticket. So, it has come up in one of the
>> meetings. Supposedly, no-one has found the time yet to work on it.
>>
>> Feel free to ping in the ticket or bring it up in one of the meetings.
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Herald Yu

[Benson Muite]

On 4/24/23 09:42, Herald Yu wrote:
> Hello everyone, I am Herald come from Shanghai, China. It's nice to meet you 
> in Fedora Devel Community.
> 
> I am a Tech Writer who is passionate about open-source technology. I have 
> contributed to JuiceFS and I am willing to package and maintain this software 
> package. I hope to join the Fedora developer community, learn from everyone, 
> and contribute to the development of the Fedora ecosystem.
> 
> If you would like to know more information about me, I am willing to further 
> introduce myself to everyone.

Welcome to Fedora and thanks for contributing to packaging. We hope you
like it here and look forward to also learning from 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Benson Muite]

On 4/21/23 23:38, Ben Cotton wrote:
> On Fri, Apr 21, 2023 at 4:05 PM Maxwell G  wrote:
>>
>> What evidence shows that the group is ever shrinking? I often see Self
>> Introduction posts and new people interacting with project. I suppose
>> that whether they continue interacting afterwards is another question.
> 
> I'm glad you asked. Earlier this week I decided to avoid doing other
> work by putting together some quick charts of devel list
> participation. Here's the number of unique participants per month from
> 2004–2022:
> https://bcotton.fedorapeople.org/images/devel-participation-monthly.png
> 
> And for a less-noisy version, the median of the monthly numbers per year:
> https://bcotton.fedorapeople.org/images/devel-participation-mean.png
> 
> There are a lot of questions left unanswered by this quick analysis,
> but there's a clear trend in fewer participants over time. In fact,
> last month had the second smallest participant count (tied with
> October 2022). Of course, these charts don't show _why_, but they do
> support the assertion that folks are dropping out of the conversation
> faster than others are joining.
> 
Ben,
Thanks, this is helpful. Can you make the scripts/programs you used for
these available to allow for a more detailed analysis?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Benson Muite]

On 4/21/23 23:04, Maxwell G wrote:
> Hi Matthew,
> 
> 
> On Thu Apr 20, 2023 at 17:20 -0400, Matthew Miller wrote
>> As it is, devel list is too much for many people to follow — people
>> we’d like to have around.
> 
> I disagree. I find mailing lists much easier to deal with. They're all
> in one place, they're synced between my devices, and I can use whatever
> client I like. I can start writing a message on my phone, save it as a
> draft, and send it from my laptop. I can filter messages to my heart's
> content. Everything is threaded and I can choose to ignore the threads
> I'm uninterested in.
> 
> It's easy to skim the list and I can do so on my terms, as opposed to
> being pushed towards a _centralized_, single point of failure,
> javascript-heavy, bulky web frontend. I understand that Discourse has
> functionality for interacting via email, but that's fundamentally not
> its purpose, and it's apparent that email users are second class
> citizens. With mailing lists, most messages are sent as plain text email
> that displays properly in my TUI email client, and they're easy to quote
> and splice to reply to the parts in which I'm interested. I can both
> create new threads AND reply to existing ones.
> 
Agree with this.

> 
>> We’re scattered in actual practice
>> --
>>
>> Devel list may be the center, but we have _hundreds_ of Fedora mailing
>> lists. A dozen or so are reasonably active (Test, Legal, ARM…) but most
>> are inactive or dead. Some are just meeting reminders over and over —
>> for meetings that aren’t even active anymore. It’s easy to make but
>> hard to _unmake_ a mailing list.
> 
> Yeah, I think the mailing lists could use more organization and cleanup.
Closing inactive and low traffic lists and moving them to Discourse is
fine. Cleanup is helpful. Associated ticket:
https://pagure.io/fesco/issue/2982
> 
>> And, you can interact with it all by email. That interface isn’t
>> perfect, but it’s way better than any other forum software I’ve seen.
>> (I’ve written a guide: https://discussion.fedoraproject.org/t/25960)
>> At the same time, your individual email address is hidden, so it won’t
>> be a spam magnet (or a target for off-list harassment, a problem we
>> unfortunately have with devel list).
> 
> Yeah, I'm not sure the email interface is really comparable to the ML
> experience. You can't post directly via email without the whole
> moderation queue thing mentioned in your linked post. Email interaction
> seems to be a second class citizen. I'm not sure what the point in
> moving off the mailing list is if you keep suggesting ways that people
> can make forum software behave more like the mailing list that we
> already have.
> 
>> That said, it is web-first software. (Or mobile, if that’s your thing.)
>> That requires some adjustment, I know. I hope opening up a Fedora
>> Discussion tab – or keeping one open — becomes an easy habit.
> 
> I wouldn't like that much. The only tab I always have open is Matrix,
> and I'd prefer not to have to have more always open browser tabs. I
> already have an email client.
The web browser Matrix interface uses a lot of javascript and is very
heavy and slow.  Neochat and Nheko are much more performant than the
electron based client.  Have not tried the terminal based clients for
Matrix.  Discourse does seem to have an API, but email interaction is
definitely a second class citizen.  There is no lightweight performant
text interface client for Discourse - it has not been designed for the
power user.
> 
> 
>> Concrete proposal
>> -
> 
> While I think it makes sense for new teams to consider adopting the
> forums instead of mailing lists, I am not convinced that we should shut
> down devel@ and alienate the _current_ devs who seem to favor the
> current approach.
>
Much agreed. If it is challenging for people to join the development
list, making some kind of email first bridge to Discourse or some other
forum software is more reasonable.  Not everything is meant to be web
first.  Some fragmentation in the Fedora ecosystem is good, it allows us
to try new things. The bloated web is the reason for new protocols such
as Gemini.

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

Re: It’s time to transform the Fedora devel list into something new

[Benson Muite]

On 4/21/23 20:52, Matthew Miller wrote:
> On Fri, Apr 21, 2023 at 08:24:14AM +0300, Benson Muite wrote:
>> However, it doesn't seem like we can hack on it to better suite
>> community needs, for example to have the same functionality as mailing
>> lists[2].  It is not standards driven and is primarily developed by one
>> company - something that follows Apache way[3] or has a community
>> governance process would be better in the long term for a large project
>> with many contributors who have technical expertise.
> 
> We definitely _can_ hack on it to better fit community needs. Changes might
> not automatically get accepted, but we've got a good relationship and I
> don't expect any kind of antagonism if we have something important.
> 
Good working relationship is ok for small projects.  Discourse has grown
and adapted because of this.  Discourse is fantastic as a forum which is
not read on a daily basis but periodically as the need arises. Need
stability and a governance model for critical infrastructure. Web first
philosophy kills productivity that a primarily text driven workflow has
for many people.
> On 2) 
> https://discourse.cmake.org/t/cmake-discourse-mailing-list-mode-incorrectly-personally-addresses-all-email/738
> in particular... that's just the Cmake forum admin saying that the
> particular thing doesn't exist, not a Discourse dev saying they won't take a
> change. 
> 
> Although on that specific change Discourse attaches List-Id and other
> standard email headers (as well as some specific X-Discourse headers) to
> each message. Changing the To: line to be some list address could be done
> with a plugin, but might actually have negative consequences for reliable
> delivery.
> 
> 
>> Email clients offer significant customizability that a one size fits all
>> web interface cannot provide.  Mailing list mode for Discourse is
>> helpful, but not at the same level as email lists, where once one has
> 
> "Mailing list mode" was a specific thing in earlier versions of Discourse —
> it sent a notification for every message posted. This is kind of like going
> to Hyperkitty and saying "subscribe me to all 600 lists". I don't recommend
> that. Instead, choose specific tags that you want to subscribe to, just as
> you would subscribe to individual mailing lists.
> 
> I have a post about this and Fedora Discussion specifically:
> 
> https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/3
> 
This is helpful.  Wish it were a magazine article. Those get read.

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

Re: It’s time to transform the Fedora devel list into something new

[Benson Muite]

On 4/21/23 04:24, Chris Adams wrote:
> Once upon a time, Matthew Miller  said:
>> I am proposing that over the course of 2023, starting with the Changes
>> process, we move Fedora development conversations from this mailing list to
>> the Discourse-based Fedora Discussion.
> 
> I feel this is a case of trading one group of people (email list users)
> for a different group of people (web forum users).  I have seen this
> done multiple times over the years, tried to follow a few times, and
> always dropped off fairly rapidly.  I'm solidly in the "email list
> users" group.
Discourse is very nice.  It is open source, uses a reasonable license
[0] (though [1] would be better), and is great for casual interactions
that maybe spread out over time.  Would highly recommend it for moderate
size community discussion.

However, it doesn't seem like we can hack on it to better suite
community needs, for example to have the same functionality as mailing
lists[2].  It is not standards driven and is primarily developed by one
company - something that follows Apache way[3] or has a community
governance process would be better in the long term for a large project
with many contributors who have technical expertise.

Email clients offer significant customizability that a one size fits all
web interface cannot provide.  Mailing list mode for Discourse is
helpful, but not at the same level as email lists, where once one has
gained sufficient knowledge, interaction can be done from the comfort of
the client of your choice. As such, simply adopting it because it can be
deployed may leave out many contributors, in particular those who drive
development forward.  Mailing lists are not perfect, but it is not clear
Discourse is a good replacement for the devel list.

0) https://github.com/discourse/discourse/blob/main/LICENSE.txt
1) https://www.gnu.org/licenses/agpl-3.0.en.html
2)
https://discourse.cmake.org/t/cmake-discourse-mailing-list-mode-incorrectly-personally-addresses-all-email/738
3) https://apache.org/theapacheway/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: subarchitectures and RISC-V, was Re: F39 proposal: RPM 4.19 (System-Wide Change proposal)

[Benson Muite]

On 4/15/23 19:56, Kevin Fenzi wrote:
> On Sat, Apr 15, 2023 at 08:38:47AM -0600, Jeff Law wrote:
>>
>>
>> On 4/15/23 00:10, David Abdurachmanov wrote:
>>
>>
>>>
>>> We have to support SCBs as-is. We even have 64-core OoO (and even
>>> dual-socket 128-core) systems coming that are still RVA20 (what I call
>>> "a large scale SBC trying to be a server").
>> I think elsewhere you suggested treating the profile as the subarch for RPM.
>> That may be a viable way to handle the SBC space.
>>
>> I still worry about supporting multiple profiles and would like to see a
>> clear path to deprecating profiles that are out of date.  The amount of pain
>> I've seen in both the x86 and aarch worlds WRT baselines is something I'm
>> keen to avoid repeating.
> 
> Yeah, completely agreed. From an infrastructure standpoint, I would love
> to get riscv in fedora as a primary arch, but I don't think it's
> practical at all to bring in 3 or 4 or whatever subarches. There's just
> no hardware that could actually keep up with mainline fedora currently
> and the duplication of effort building 23,000 packages over N slightly
> different subarches is not very tenable.
> 
Probably each hardware vendor will need to become more involved in
creating an RPM distribution for their use case and providing hardware
for test builds.  A single monolithic Fedora will not work.  Having a
subset of base packages would be very helpful.
> The rpm subarches might be a useful path, but then determining what you
> build for multiple of them and how needs to be addressed. 
> 
The great thing about Linux is easy customisability.  There may be a few
RISC V variants that are widely used, but not clear which at present.
The D1 chip is very affordable, and can have much use in education and
IoT, though most support at present is available for Debian and OpenWRT.
 Fedora probably seems to need more work for this.
> I think we can point people to arm history and try and get them to not
> repeat it (although perhaps it's too late for a lot of it). 
>>>
>>> But Fedora RISCV as-is is not how future Fedora RISCV should be. The
>>> future is RVA23 (or beyond) and standard compliance. There will be
>>> significant performance differences between profiles for some time.
>>> Especially RVA20 -> RVA23. RVA20 (or RVA64GC) is just way too small
>>> with lack of modern ISA. We have had a toy for ~10 years now, and now
>>> we are moving toward high-performance servers, even HPC, Android (see
>>> latest Google announcements), etc. That's not driven by RVA20. That's
>>> RVA23 (and beyond) + vendor extensions.
> 
> Completely agree.
> 
Maybe we need a RISC V sig?
>>> Yes! Blocked by lack of "hw probe" interface. There will be "hw probe"
>>> syscall for RISCV, in v6.4 and v6.5 kernel (I hope). We don't have
>>> cpuid instruction, HWCAP is way too small for all the extensions
>>> available.
>> I'm sure folks will get this sorted out.  My only concern with the syscall
>> was to make sure the glibc folks were on board with using that to drive
>> ifunc selection.  It's a fairly different approach than has been taken in
>> the past and I want to make sure it's not DOA for glibc.
>>
>> Once the kernel & glibc teams reach API agreement I think we'll be able to
>> make a reasonable query about the system properties in multiple contexts,
>> including the installer, rpm, etc.
> 
> That would be great.
> 
>>> Note that toolchains don't accept RISCV Profiles yet, but that has
>>> been under discussion for quite some time already. I would assume
>>> starting GCC 14 timeframe all of that should work.
>> It'll get sorted out.  We've got some bigger fish to fry WRT landing V
>> support (if you've managed to avoid that mess, consider yourself lucky).
>>
>> Lots of stuff is backed up behind getting gcc-13 out the door so that gcc-14
>> development can open up.   Not sure where profiles will fall into the
>> priority list, it's hard to see past the V effort right now.
> 
> Yep. And a lot of it is things that just need to mature and hardware
> that needs to exist and code and... ;) But hopefully we will get there. 
> 
> kevin
> 
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change my new package name in src.fedoraporject.org ?

[Benson Muite]

On 4/13/23 11:29, Sébastien Le Roux wrote:
> 
> Le 13/04/2023 à 10:26, Benson Muite a écrit :
>> On 4/13/23 11:18, Sébastien Le Roux wrote:
>>> Dear all,
>>> yesterday I created my first package repository:
>>>
>> Congratulations!
> Thank you so much, this is kind of exciting !
>> i) retire the package
>> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
>> ii) update the name in bugzilla
>> iii) request a new repository
>>
>> or follow:
>> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Renaming_Process/
> Will do thanks !
> 
Great. Try to keep information in list for future references and other
suggestions.  My opinion is not authoritative.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Change my new package name in src.fedoraporject.org ?

[Benson Muite]

On 4/13/23 11:18, Sébastien Le Roux wrote:
> Dear all,
> yesterday I created my first package repository:
> 
Congratulations!
> https://src.fedoraproject.org/rpms/Atomes
> 
> I used the command (that you all must be familiar with):
> 
> fedpkg request-repo Atomes 2130607
> 
> After a first try using "atomes" that did not work, indeed fedpkg requested
> the keyword to be "Atomes" because of an information in the bug report.
> 
> I could only certify afterwards that the repo was named "Atomes" and not
> "atomes" as I hoped.
> Can anyone help in renaming the project "atomes" instead of "Atomes" ?
> 
> Thanks in advance for your help.
> 
> Best regards.
> 
> Sébastien
> 
i) retire the package
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/
ii) update the name in bugzilla
iii) request a new repository

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

Re: Self Introduction: Miguel Bernal Marin

[Benson Muite]

On 4/11/23 00:10, Joe Doss wrote:
> On 4/8/23 7:52 PM, Miguel Bernal Marin wrote:
>> Hi Fedora community,
>>
>> My name is Miguel Bernal Marin and usually my nickname is miguelinux,
>> I work at Intel corporation in Guadalajara, Jalisco, Mexico and I
>> would like
>> to add some new packages from Intel to Fedora and keep maintaining them.
>> I will look for a sponsor for those package in a near future.
>>
>> Regarded my past experience on open source projects, I was in the
>> Clear Linux
>> team maintaining some packages, and I had contributed to others open
>> source
>> projects.
>>
>> My FAS user is miguelinux.
> 
> Welcome Miguel. I am glad you have joined us! :)
> 
> Joe
> 
> 
> 
Welcome Miguel.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Auto-assign packager sponsors to tickets?

[Benson Muite]

On 4/4/23 10:14, Vitaly Zaitsev via devel wrote:
> On 04/04/2023 02:59, Jakub Kadlcik wrote:
>> I get the same impression and I would agree with Otto's proposal to
>> get rid of the FE-NEEDSPONSOR entirely.
> 
> Looks good for me too. Opening a new Pagure ticket would be better, IMO.
> 
This is helpful when reviewing. It could be changed to NEW-SUBMITTER or
POTENTIAL-PACKAGER.  However, it should not be taken as an actionable
item for sponsorship for which a Pagure ticket could be opened when
required.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Auto-assign packager sponsors to tickets?

[Benson Muite]

On 4/4/23 08:52, Otto Liljalaakso wrote:
> Benson Muite kirjoitti 4.4.2023 klo 7.02:
>> May
>> also want to automatically track unofficial reviews by prospective
>> packagers, perhaps even requiring a certain number of unofficial reviews
>> for the sponsorship process to start.
> 
> Yes, I think that the sponsorship process should be made more rigid,
> with at least somewhat formally defined requirements. Maybe something
> along the lines "do N unofficial package reviews AND submit M pull
> requests to packages and get them merged AND convince a sponsor". The
> current approach where "convince a sponsor" is the only actual
> requirement creates unfortunate bias:
> 
Pull requests are less easy to judge and vary significantly in
complexity.  It helps to judge, in particular since it is one way to
help maintain a package.  They can be used in assessing, but fixing a
number of these as a requirement is difficult. They may also take time
to merge.
> 1. The easiest way to get in is to know somebody who is already in. This
> is basically the opposite of how I understand "open community".
> 
This is true.
> 2. Applicants who find it easy to engage with unknown people in higher
> community standing and have high confidence in their abilities navigate
> the (ill-defined, unclear) process much easier than more cautious types.
> Such character traits are of course very useful when participating in
> open source communities, but discriminating other kinds of personality
> leads to fewer contributors and lost talent. And it is, well,
> discriminatory, thus not very ethical in my opinion.
> 
> Another thing that can be improved here is to make it much less
> necessary to even get packager status. Working with pull requests should
> be the norm. Perhaps new package requests could more often be handled in
> a way where an existing packager assumes the maintainer position with
> the agreement that the submitter keeps the packager updated and in good
> condition, through pull requests. The packager status should be just an
> optional thing you can apply at some point in your Fedora contributor
> career, *if* a situation demanding that occurs - much like packager
> sponsor, provenpackager or even FESCo member status is, or how in
> upstream projects there often are prominent contributors that take part
> in the conversation and submit pull requests, without any commit access.
>
Response times to pull requests can vary.  Most people who want to be
packagers are submitting something new.  The above would work well for
SIGS which package related software.  In particular, if a package can be
adopted by a SIG, then the person submitting it need not be sponsored to
have the package in Fedora, as the SIG can adopt the package, and the
person submitting it make pull requests to make changes.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Auto-assign packager sponsors to tickets?

[Benson Muite]

Thanks for this initiative Jakub. Automated builds on copr of packages
proposed for review has been very helpful.
On 4/4/23 03:59, Jakub Kadlcik wrote:
> Thank you all for the feedback.
> 
>> The bottom line is that package reviews can be quite time consuming.  I
>> don't think the issue is with sponsorship itself.
> 
> Sorry Jason, I probably didn't communicate my idea as clearly as I
> should. My intention wasn't to assign sponsors to review tickets and
> make them do the actual review. I am trying to address the situation
> where a ticket already has a fedora-review+ flag but it was given by a
> reviewer who is not a sponsor.
> 
> 
>> You're saying that tickets were properly filed with the
>> packager-sponsors tracker and those were not addressed?  I checked the
>> open tickets before responding.  I didn't see anything.  If tickets got
>> closed without any action being taken, could you point out those
>> tickets?  That would be a rather odd state of affairs
> 
> Not in the packager-sponsors tracker, I checked it out, and I must say
> it is being processed flawlessly. Really good job there.
> Reading the discussion, I think we discovered one of the main issues
> elsewhere - We don't properly instruct new contributors to create a
> ticket in the tracker.
> This will be a big improvement:
> https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/118
> 
> To point out the specific tickets that weren't addressed, they are here:
> https://fedoraproject.org/PackageReviewStatus/needsponsor.html
> 
> 
>> But I think this is not outreachy enough.
> 
> I agree, so my next step will be improving the fedora-review-service
> to post a comment about how to find a sponsor, in case fedora-review+
> flag was given by a non-sponsor. More info in this RFE:
> https://github.com/FrostyX/fedora-review-service/issues/18
> 
The packager onboarding experience can be improved. Automation can help.
 If someone has submitted a new package review request and has not
submitted a package review request before, a bot that welcomes the
person and announces this on the devel list would encourage others to
take a look at the ticket.  There is a Fedora ambassador group, maybe
this could also be used?  It is good to increase active participation in
the project.  Am not a sponsor, but have reviewed packages of people
that need sponsorship.
> 
>> From this thread I get
>> the opposite impression, that Pagure tickets are processed quickly and
>> FE-NEEDSPONSOR blockers are not looked at. If so, I propose the policy
>> is updated to ask for a Pagure ticket in every case.
> 
> I get the same impression and I would agree with Otto's proposal to
> get rid of the FE-NEEDSPONSOR entirely. Apart from it not being
> processed as effectively as the package-sponsor repo tickets, the
> FE-NEEDSPONSOR is confusing anyway (it is set to a review ticket but
> the ticket doesn't need to be sponsored, the contributor does. That
> becomes weird when the contributor has more tickets at the same time
> and so on). But if I understand correctly, FESCo needs to be involved
> and therefore this would be a long-term goal.
>
Automating FE-NEEDSPONSOR is helpful for reviewers as one would
typically make more suggestions than for a regular review. Creating a
Pagure ticket after successful package review can then also help.  May
also want to automatically track unofficial reviews by prospective
packagers, perhaps even requiring a certain number of unofficial reviews
for the sponsorship process to start.

> 
>> Please exclude me from such spam.
> 
> I was finally able to find some numbers and it turns out, we
> successfully sponsor ~100 people a year. That is much more than I
> expected, so I now understand your point. We are also much more
> effective than I thought (well you guys are).
> 
> 
>> Sure, just plumb the end of the review process (accepted ticket) to feed
>> right into the sponsor process (let the sponsors know, preferably via
>> the tracker).  But I don't think that assigning unreviewed tickets to
>> random sponsors is the right way.
> 
> This can work and will be easy to implement as well. I like the idea,
> we can try it :-)
> 
> Jakub
> 
> 
> 
> On Mon, Apr 3, 2023 at 11:57 PM Otto Liljalaakso
>  wrote:
>>
>> Jason Tibbitts kirjoitti 3.4.2023 klo 20.09:
 Miroslav Suchý  writes:
>>>
>>> In any case, what I wrote was the procedure I documented it when I set
>>> it up.  If all of that documentation was lost, then I don't know what to
>>> say but that's not what was intended.
>>>
>>> I drove the change that made this happen.  I made sure the documentation
>>> (in the wiki at the time) referenced the procedure.  If that was lost
>>> after the time when I was able to be very active in Fedora, then that's
>>> a sad state of affairs and I don't know why that would happen, but it
>>> would be really good if it could un-happen.  Did FESCo revert the policy
>>> change or something?
>>
>> Somewhat recently, the Packager sponsor policy [1] has 

Re: Review swaps

[Benson Muite]

On 3/21/23 08:18, Riya Bisht wrote:
> Hello,
> 
> I'm interested in reviewing packages. Can you tell me how do I start ?
> I'm beginner trying to understand fedora packaging.
> 
Welcome to Fedora!
https://jamezone.org/pleasure/software/Fedora/packager/
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Unretire IWYU - Include What You Use

[Benson Muite]

Would like to unretire Include What You Use
https://bugzilla.redhat.com/show_bug.cgi?id=2175012
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update of catch to Catch2 v3

[Benson Muite]

On 2/24/23 10:48, Vitaly Zaitsev via devel wrote:
> On 22/02/2023 12:37, Tom Hughes via devel wrote:
>> I have now added catch2 (for Catch2 v2.x) and upgraded the catch
>> package to Catch2 v3.x in rawhide and f38.
> 
> All my catch-dependent packages are now failing due to the missing
> catch.hpp header:
> 
> tests.cpp:32:10: fatal error: catch.hpp: No such file or directory
>    32 | #include "catch.hpp"
>   |  ^~~
> compilation terminated.
> 
> Catch v3 is no longer a single-header library?
> 
No. There are incompatibilities. Maybe it is better to keep the old
name, and use Catch2v3 as a new name, so packages can update more easily
when they are ready to do so?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update of catch to Catch2 v3

[Benson Muite]

On 2/22/23 14:37, Tom Hughes via devel wrote:
> As discussed a few weeks ago the Catch testing framework has
> a slightly weird naming scheme, namely:
> 
> * Catch (v1.x, actually a branch in Catch2 repository)
> * Catch2 v2.x
> * Catch2 v3.x
> 
> Since Catch2 was released we have had catch1 and catch packages
> to support both v1.x and v2.x users.
> 
> I have now added catch2 (for Catch2 v2.x) and upgraded the catch
> package to Catch2 v3.x in rawhide and f38.
> 
Thanks.
> What this means is that if your package uses catch-devel to build
> that you probably need to update your BuildRequire to catch2-devel
> when you next build it - unless your upstream supports v3.x of
> course.
> 
> Tom
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Licenses for UCX

[Benson Muite]

Updated license information to  BSD-3-Clause AND MIT AND CC-PDDC AND
(BSD-3-Clause OR Apache-2.0) after examining while doing SPDX update.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Errors when updating repo information

[Benson Muite]

For builds on COPR and when using Fedora in the cloud, occasionally get
an error when trying to read rawhide repository information:

$ sudo dnf install wget
Fedora - Rawhide - Developmental packages for t  13 MB/s |  21 MB
00:01
Errors during downloading metadata for repository 'rawhide':
  - Curl error (23): Failed writing received data to disk/application
for
https://d2lzkl7pfhq30w.cloudfront.net/pub/fedora/linux/development/rawhide/Everything/aarch64/os/repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
[Failure writing output to destination]
Error: Failed to download metadata for repo 'rawhide': Yum repo
downloading error: Downloading error(s):
repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
- Download failed: Curl error (23): Failed writing received data to
disk/application for
https://d2lzkl7pfhq30w.cloudfront.net/pub/fedora/linux/development/rawhide/Everything/aarch64/os/repodata/9f84bd5273bb6a0e5dd74da9d9726a71912ad7a866f84e0c63072ca0cf0e12df-filelists.xml.zck
[Failure writing output to destination]

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

Updated license information for MLpack

[Benson Muite]

When updating to SPDX, added Apache-2.0 license for some of the included
files in MLpack.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packages with breaking APIs

[Benson Muite]

The review had gone through, and had created the package, then retired
it, but as the APIs are different, and this also applies to another
package I have under review, mbedTLS, wanted to know if there are
general guidelines on this.

For Catch, there was an upgrade from 1 to 2. Similarly for FFTW, the
main package uses the name FFTW, but it was FFTW3 before hand. Maybe one
could use Catch3 or Catch2v3? Then change names later once more packages
use the v3 interface?

On 2/1/23 13:44, Tom Hughes wrote:
> There is already precedent for doing it with catch and I've said
> that I plan to do it again so I don't know what more you want.
> 
> Tom
> 
> On 01/02/2023 10:13, Benson Muite wrote:
>> Packages with breaking APIs between major version changes often keep
>> maintaining the older version for some time after the new version is
>> released.  An example is FFTW which has both FFTW (version 3) and FFTW2
>> (version 2) within Fedora:
>> https://packages.fedoraproject.org/search?query=fftw
>>
>> Is it reasonable to package versions with newer APIs separately? Of
>> particular interest are:
>> i) Catch
>> a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch
>> b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410
>> ii) MbedTLS
>> a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls
>> b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Packages with breaking APIs

[Benson Muite]

Packages with breaking APIs between major version changes often keep
maintaining the older version for some time after the new version is
released.  An example is FFTW which has both FFTW (version 3) and FFTW2
(version 2) within Fedora:
https://packages.fedoraproject.org/search?query=fftw

Is it reasonable to package versions with newer APIs separately? Of
particular interest are:
i) Catch
a) Existing v2.3.10 https://src.fedoraproject.org/rpms/catch
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2165410
ii) MbedTLS
a) Existing v2.28.2 https://src.fedoraproject.org/rpms/mbedtls
b) BZ for v3.3.0 https://bugzilla.redhat.com/show_bug.cgi?id=2154347
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review swap: libblkio (Rust-written library with C API)

[Benson Muite]

On 1/11/23 13:41, Richard W.M. Jones wrote:
> On Wed, Jan 11, 2023 at 10:39:50AM +, Richard W.M. Jones wrote:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=2124697
>>
>> I'm willing to swap this one with a package of similar complexity.
>>
>> This package / review bug has been extensively reviewed -- 87 comments(!!)
>> on the review already.  We are pretty sure it is in good shape now.
>> As it is a "C library" that is actually written in Rust it's a bit
>> unusual because it has to obey the Rust / Cargo guidelines.
> 
> And I was going to add: It does work.  I wrote a whole program against
> the API, developed entirely using the locally installed libblkio &
> libblkio-devel RPMs.
> 
> Rich.
> 
Taken.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review swap

[Benson Muite]

On 12/29/22 22:32, TI_Eugene wrote:
> Can review something against my new package - QCustomPlot/PyQt
> binding: https://bugzilla.redhat.com/show_bug.cgi?id=2156080
> 
> Qt and/or python packages are preferable, but not exactly.
> 
> ___
Taken

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

Re: Inactive packagers to be removed after the F37 release

[Benson Muite]

On 12/2/22 14:04, Vít Ondruch wrote:


Dne 02. 12. 22 v 8:00 Benson Muite napsal(a):



- rpms/ruby-ncurses

Taken



Why? It does not deserve to live, at least in its current (abandoned and 
deprecated) form.



Thanks for the warning. Orphaned it.


Vít


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

Re: Inactive packagers to be removed after the F37 release

[Benson Muite]

- rpms/ruby-ncurses

Taken

- rpms/ucx

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

Unretire lua-coxpcall

[Benson Muite]

Hi

Would like to unretire lua-coxpcall:
https://src.fedoraproject.org/rpms/lua-coxpcall
It is a dependency of https://github.com/lunarmodules/copas which is a 
dependency of https://github.com/lunarmodules/busted which is needed for 
testing other lua packages.


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

Re: Building two conflicting binaries from the same source

[Benson Muite]

Collections can also help manage this:
https://www.softwarecollections.org/en/

On 11/4/22 01:21, Bojan Smojver via devel wrote:

Thank you!

--
Bojan



4 Nov 2022 8:48:25 am Florian Weimer :

* Bojan Smojver via devel:


Sure, it is easy enough to configure/build repeatedly and stash the
results into non-conflicting paths of buildroot, but how does one then
package this in %files sections into exactly the same paths?


See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:

| Name:   test
| […]
| %description
| %{summary}.
|
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
|
| %files test2
| /bin/hello.foobar
| […]

The key enabler is RemovePathPostfixes.

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

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

Re: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Benson Muite]

On 11/2/22 13:03, Florian Weimer wrote:

* Demi Marie Obenour:


On 11/2/22 02:56, Florian Weimer wrote:

* Benson Muite:


On 11/1/22 06:35, Orion Poplawski wrote:

While poking at building openmpi with clang, I started wondering
about flang and some things:
* Should %set_build_flags set FC?  I think it should since it sets
FCFLAGS.
* Is flang-new even worth bothering with?  See the following
configure check:



Yes, this will be helpful.  Significant work has gone into optimizing
this for A64FX


Fedora does not run well on A64FX because we enable PAC+BTI, adding
significant overhead to most function calls.


How is this specific to A64FX?


It just is?  I'm not aware of any other AArch64 CPUs that are impacted
in the same way.
It is not specific to A64-FX, but flang has been optimized for aarch64 
as a result of this.  Thus, use of flang likely to grow in use for 
applications that use MPI.  My expectation is that Fedora is mostly used 
for testing MPI applications, though with increasing core counts, 
production use on workstations will likely grow.


Maybe I don't understand the question.

Thanks,
Florian

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

ELN build failures

[Benson Muite]

If there is a build failure for a package on ELN, does anything need to 
be added to a package spec file?  Currently reviewing a package where 
there is a missing dependency, but helpful to also know if anything 
should be done in general. The documentation at [0] is not clear on 
this.  Unclear also if ExcludeArch: ELN with a comment for the reason 
for build failures on ELN would be a useful thing to have in new spec files.


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

Re: %set_build_flags, clang/flang-new and FC/FCFLAGS

[Benson Muite]

On 11/1/22 06:35, Orion Poplawski wrote:
While poking at building openmpi with clang, I started wondering about 
flang and some things:


* Should %set_build_flags set FC?  I think it should since it sets FCFLAGS.

* Is flang-new even worth bothering with?  See the following configure 
check:
Yes, this will be helpful.  Significant work has gone into optimizing 
this for A64FX




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

Testing of software that utilizes GPUs

[Benson Muite]

Is there any way to test software that uses GPUs on COPR or Koji?  The 
number of such packages will likely increase in future.  In particular 
for software that uses ROCM, SYCL, Vulkan and OpenCL?

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

Re: Propositions to improve the documentation

[Benson Muite]

On 10/12/22 13:03, Sébastien Le Roux wrote:

Dear All,
I joined the packaging team recently, or should I say I joined the 
mailing list, since for the rest I am
still looking for a sponsor and all that ... anyway I want to share few 
ideas with you ...
In my first messages I highlighted that the documentation might need 
some updates / improvements,

for the newbie that I am parts of it were / are still confusing.
There is some documentation scattered online. Quite a lot of discussion 
is on mailing lists also. Maybe the following tutorial will be helpful:

https://jamezone.org/pleasure/software/Fedora/packager/




If anything else comes to mind while I study how to prepare and 
maintained RPMs I will let you know.

That would be great.


On another note, I want to thank you all for the warm welcome I received 
when I joined the list,
this really was nice, I had a somewhat bad experience few years ago in 
an other open source community
and was not sure what to expect here ...  well the feeling is really 
nice, thank you !
Communicating with potentially everybody on the internet is tough. 
Conventions of welcoming behaviour differ quite considerably, but most 
of the time, intentions are good.


Hope this helps.
Best regards.

Sébastien


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

Re: fedpkg new-sources errors - fedorapeople certificate expiry

[Benson Muite]

-- Petr


Possibly related (?), today I've noticed that opening a .fedorapeople
website in a browser I get an error about expired certificate...

Also prevents downloading spec and srpm files.


Mattia

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

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

Re: Unretire rubygem-logging

[Benson Muite]

On 10/4/22 11:29, Vít Ondruch wrote:


Dne 04. 10. 22 v 10:01 Benson Muite napsal(a):

On 10/4/22 02:05, Robby Callicotte via devel wrote:

On Tuesday, September 27, 2022 2:13:25 AM CDT Vít Ondruch wrote:




I have set up copr repos for test-kitchen and kitchen-salt.[1][2]  I 
am also
in the process of opening up bzs for review.  I have a few questions 
regarding
embedded fonts in rdoc... Every rubygem seems to have this... Should 
I be

removing the font files from my specs now? See this thread[3].

I can move discussion to the ruby-sig if that is a more appropriate 
place to

have the embedded font discussion.

There is a related thread on the ruby-sig list:

https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/2O3RID4LX6I53WD3TRUNYE2O54RXDKBX/




I don't think this is worth of removing at this stage. This needs 
systematic solution and it would not help to solve it package by 
package. Not mentioning that removing fonts might break the assumption 
that the documentation might be freely copied on other places and still 
keep working.
The assumption that the documentation can be freely copied elsewhere is 
incorrect, it is made to be used on the installed system.  Bundling the 
fonts also means that the font licenses need to be included with the 
package license.  Bundling the fonts increases package bloat.  If 
documentation that can freely be copied elsewhere is needed, a better 
solution is to have an optional full-documentation sub package.  This 
may also be useful for pdf documentation[4]


[4] https://gitlab.com/fedora/legal/fedora-license-data/-/issues/18



Vít





[1] - https://copr.fedorainfracloud.org/coprs/rcallicotte/test-kitchen/
[2] - https://copr.fedorainfracloud.org/coprs/rcallicotte/kitchen-salt/
[3] - 
https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/thread/ALHIJVZ5MP5Y46UWAQUNGNRDFBJUA5BL/


Cheers!

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

Re: Unretire rubygem-logging

[Benson Muite]

On 10/4/22 02:05, Robby Callicotte via devel wrote:

On Tuesday, September 27, 2022 2:13:25 AM CDT Vít Ondruch wrote:




I have set up copr repos for test-kitchen and kitchen-salt.[1][2]  I am also
in the process of opening up bzs for review.  I have a few questions regarding
embedded fonts in rdoc... Every rubygem seems to have this... Should I be
removing the font files from my specs now? See this thread[3].

I can move discussion to the ruby-sig if that is a more appropriate place to
have the embedded font discussion.

There is a related thread on the ruby-sig list:

https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/message/2O3RID4LX6I53WD3TRUNYE2O54RXDKBX/





[1] - https://copr.fedorainfracloud.org/coprs/rcallicotte/test-kitchen/
[2] - https://copr.fedorainfracloud.org/coprs/rcallicotte/kitchen-salt/
[3] - 
https://lists.fedoraproject.org/archives/list/ruby-...@lists.fedoraproject.org/thread/ALHIJVZ5MP5Y46UWAQUNGNRDFBJUA5BL/

Cheers!

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

Re: Orphaned packages looking for new maintainers

[Benson Muite]

ufo2ft, pt-astra-sans-font and pt-astra-serif-font were created in 
error, the repositories have incorrect names. It seems empty/replicated 
repositories cannot be deleted.

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

Re: Self Introduction: Joel Savitz

[Benson Muite]

Welcome Joel!
On 9/8/22 02:42, Joel Savitz wrote:

Hello everyone,

I am a software engineer at Red Hat working on the kernel.

Over the past three years, I've been leading a program that has evolved 
into a pipeline to get interested people into kernel development with 
emphasis on improving Fedora on the Raspberry Pi. Long story short, here 
is our project website [0]. We are currently running a course this fall 
at UMass Lowell and beyond on kernel development [1]. Contact me if you 
are interested in any aspect of that.


This is awesome. Hopefully use of the course elsewhere, and ports to 
other hardware devices is encouraged.


Best,
Joel Savitz
joelsavitz.com 

[0] https://kdlp.underground.software/ 
[1] https://www.uml.edu/catalog/courses/COMP/5170 

[2] https://pypi.org/project/RPi.GPIO2/ 

[3] https://bugzilla.redhat.com/show_bug.cgi?id=1871171 





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

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

Re: Self Introduction to fedora-devel and package sponsorship

[Benson Muite]

On 8/29/22 09:10, Federico Pellegrin wrote:



Hello all,
It's been a while that I'm following the list and finally wanted to do a 
small self introduction.


I'm Federico, currently living nearby Munich and working at ESO (the 
European Southern Observatory), somehow split, although many topics 
overlap, between build systems and distribution management on one side, 
and real-time systems for the observatories we manage (the currently 
running VLT and the upcoming ELT).

Welcome Frederico! You may also consider joining the SciTech SIG:
https://fedoraproject.org/wiki/Category:SciTech_SIG


Many thanks!
Federico



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

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

Re: Self Introduction: mczernek

[Benson Muite]

On 7/17/22 11:09, Marek Czernek wrote:

Hey folks,

I work as a developer for Red Hat training. As part of our work, we write both 
code and
a lot of English text, which means we want to have linters for both :). 


Hopefully we can add Czech and other languages that areusedin Fedora, 
https://languages.fedoraproject.org/f36/language/

Several of my colleagues

started using Vale, and so I thought I'd package it for Fedora to make the 
installation
on RPM systems easier.

Hope I'll be able to contribute to the Fedora ecosystem :).

Welcome to Fedora Marek!

You can see my RPM proposal at 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2107888

Cheers,
M.

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

Re: Fedora SCM requests on the weekend

[Benson Muite]

Maybe there are contributors where the working week is Sunday-Thursday?

On 7/3/22 10:58, Robert-André Mauchin wrote:

Hello,

I know a lot of you are working on Fedora during the week days, but for 
some of us, the weekend is the only time we can spend time on it. The 
problem is, SCM requests are rarely processed during that time, most of 
them get stuck from Friday afternoon to Monday afternoon (CEST), so it 
really hampers my work. Would it be possible for a volunteer to agree to 
do it on the weekend.


Best regards,

Robert-André
___
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

___
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: Take the Fedora Annual Contributor Survey 2022

[Benson Muite]

On 6/17/22 00:18, Bruno Wolff III wrote:

On Thu, Jun 02, 2022 at 12:33:55 +0200,
  Aleksandra Fedorova  wrote:

Hello, everyone,

Please participate in the Fedora Annual Contributor Survey 2022!

* https://fedoraproject.limequery.com/2022

The survey is anonymous, it has 44 questions targeting Fedora
contributors of all kinds and asks about your default choices of
applications and services.


It would be nice if it worked without javascript. 

Not so many choices:
https://alternativeto.net/software/limesurvey/?license=opensource=2
https://alternativeto.net/browse/search/?q=formspree/?license=opensource


___
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

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

Re: Orphaned packages looking for new maintainers​

[Benson Muite]

  Package  (co)maintainers   Status 
Change

libftdi   hobbes1069, orphan, robert   0 weeks ago


taken, co-maintainers are welcome, minor change was required for its
cmake build to resolve the FTBFS


Interested in co-maintaining this, but working on becoming a packager.


Dan

___
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: Interest in a ROCm SIG?

[Benson Muite]

A heterogeneous computing SIG would be very helpful. In addition to 
machine learning, there are many uses for this in graphics applications 
as well as for scientific computing.


Benson

On 6/13/22 10:01, Armin Wehrfritz wrote:

I would be very much interested in a SIG for that!

Not sure if it should be only for ROCm or more broadly targeting compute 
accelerators, including GPUs by all three major manufacturers. Though, 
my immediate interest on Fedora is in the ROCm stack, and especially in HIP.


Cheers,
Armin


On Mon 13. Jun 2022 at 5.25, Jeremy Newton > wrote:


A few people contact me directly trying to run things like PyTorch,
which requires large amounts of ROCm to get working (most of which
Fedora does not have yet).

I feel like a SIG, or at least some wiki page would help organize
things a bit for those who want to tackle it but are unaware of the
resources available.

Also is there a better mailing list for this? I'd hate to keep
spamming devel with my ROCm related interest :)
___
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



___
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

___
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: Unretire ufo2ft

[Benson Muite]

On 5/30/22 22:28, Otto Urpelainen wrote:

Benson Muite kirjoitti 28.5.2022 klo 22.00:

Hi,

Would like to unretire ufo2ft[1][2].  The package is useful for 
building font packages from source, which the Fedora font packaging 
policy encourages.


That should be fine, because the it seems that back in the day, the 
package was retired just because the former maintainer had lost interest 
and did not fix it for Python 3.7. Upstream also seems to be active.



Thanks.
I assume this notification is step 2 of "Claiming Ownership of a Retired 
Package" [1]. Did you already fix the specfile and submit a package 
review request?

In the process of updating the spec file:
https://bugzilla.redhat.com/show_bug.cgi?id=2091310


You do not say if you are already a member of the packager group. If 
not, you need to get sponsored there to become the maintainer for this 
package. See "Joining the Package Maintainers" [2] for that.


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

[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/ 


___
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

___
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

Unretire ufo2ft

[Benson Muite]

Hi,

Would like to unretire ufo2ft[1][2].  The package is useful for building 
font packages from source, which the Fedora font packaging policy 
encourages.


Regards,
Benson

1 https://github.com/googlefonts/ufo2ft
2 https://src.fedoraproject.org/rpms/python-ufo2ft
___
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: Self Introduction: Rijul Gulati

[Benson Muite]

On 5/15/22 21:05, Rijul Gulati wrote:

Hello Fedora,

My name is Rijul Gulati. I am a Software Developer from India.
I have been using Linux for a couple of years now, and would like to 
contribute to the fedora project.

Awesome. Welcome


About me:
I work as a web developer - primarily as a backend developer, and have 
now started learning and exploring blockchain development.
I mostly write in NodeJs/Typescript, Golang and Rust. I am familiar with 

Fedora Go, Rust and NodeJS SIGs may be helpful:
https://fedoraproject.org/wiki/SIGs/Go
https://fedoraproject.org/wiki/SIGs/Rust
https://fedoraproject.org/wiki/SIGs/Node.js
___
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: Self Introduction: Yunmei Li

[Benson Muite]

On 2/23/22 6:42 AM, Yunmei LI wrote:

Hi,
Thanks for your help! I reworked the Milvus package for EPEL8 based on 
the comments I received, and updated theSpec URL and SRPMURL on 
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596 

I am really lookingforward to someone reviewingMilvus package at the 
earliest convenience.

Not a review, but does it build on Copr[1] or Koji[2] ?
It may be helpful to check the Go SIG recommendations[3],[4].
You may also find OpenBuildService helpful[5].

[1] https://copr.fedorainfracloud.org/
[2] https://koji.fedoraproject.org/koji/
[3] https://fedoraproject.org/wiki/SIGs/Go
[4] https://fedoraproject.org/wiki/PackagingDrafts/Go
[5] https://openbuildservice.org/


Thanks,
Yunmei Li
From: "Ben Beasley">

Date: Mon, Feb 21, 2022, 22:11
Subject: Re: Self Introduction: Yunmei Li
To: mailto:devel@lists.fedoraproject.org>>

All current versions of *Fedora* have CMake 3.20 or later, so you 
shouldn’t have any problems there.


When packaging for EPEL, you rely on the package versions that were 
released with the corresponding version of Red Hat Enterprise Linux. 
RHEL aims to provide long-term stability, so these mostly get bugfix 
releases and security backports rather than significant updates over the 
life of the distribution. This is largely the same update philosophy as 
individual Fedora releases, but with a lifecycle on the order of a 
decade rather than a year. Since RHEL 7.0 was released in 2014, most of 
the packages you can use when building for EPEL7 are based on pretty old 
upstream versions.


In most cases, if the dependency versions in a particular release of 
RHEL don’t meet your needs, it means that it is not practical to build 
your package for the corresponding version of EPEL. There are a few 
exceptions—for example, you can get a newer compiler toolchain by using 
one of the devtoolset releases, e.g. [1].


If you can package for EPEL7 successfully, but only by doing things that 
don’t meet Fedora/EPEL guidelines (bundling dependencies without 
satisfying the conditions in [2], packaging your own 
newer-but-not-parallel-installable version of cmake to build with), then 
you might still be able to offer a package for EL7 distributions via 
COPR[3].


You might find that EPEL8 or EPEL9 are still viable targets. You also 
might find that the epel-devel mailing list is a helpful place to ask 
questions.


– Ben

[1] https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec

[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling

[3] https://docs.pagure.org/copr.copr/user_documentation.html#faq


___
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: Self Introduction: Dr Anirban Mitra

[Benson Muite]

Dear Anirban,
স্বাগতম (welcome)! Awesome story, an inspiration to others.
Regards,
Benson
On 2/8/22 3:29 AM, Anirban Mitra via devel wrote:

Hello
I am Dr Anirban Mitra. I an is open-source enthusiast and amateur 
typographer, I am a physician by profession. I had worked for GNU/ Linux 
Bengali/ Bangla localisation project and worked on a few open source 
OpenType fonts in Bengali.
I had described my journey in open source in an article 
https://opensource.com/article/20/7/linux-bengali
I had joined Fedora developer group to begin packaging my fonts for 
Fedora.  I am learning Fedora packaging now and two of my font package 
are in review stage.

Thanks
Anirban

___
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


___
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: Copr - look back at 2021

[Benson Muite]

On 12/30/21 5:33 PM, Miroslav Suchý wrote:

Let me sum up what the Copr team did during 2021:


Awesome work. Looking forward to a great 2022!
___
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: Self-introduction: Evžen Gasta

[Benson Muite]

On 12/16/21 12:01 PM, evzen...@seznam.cz wrote:

Hello,

My name is Evžen Gasta and I live in Czech Republic.
Currently I'm studying FIT VUT in Brno.

I'm developing New Generation of Fedora MediaWriter as my Bachelor's 
thesis.  About which am I also writing a blog.
Welcome. MediaWriter is a very useful piece of software. Looking forward 
to your improvements.


I'm using Fedora KDE for 3 years so far.

I've learned about Fedora project from long-time member @jgrulich 



Thanks for opportunity to join
Evžen


___
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


___
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: Possibly off topic: Slack will discontinue packaging for Fedora

[Benson Muite]

The Mattermost client is open source and will connect to Slack. There 
are a number of packages in copr:

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

Re: Fedora minimum hardware requirements

[Benson Muite]

On 10/15/21 5:13 AM, Michal Schorm wrote:

Thinking about this more, I always get to a question:
"Who are the consumers of that information and what do they actually
use it for?"

My personal idea is that the _ recommended _ requirements (of any OS)
are seeked by people that
1/ are going to install the system on some hardware on which that OS
wasn't previously present
2/ are looking up values with which they expect fluent, smooth,
experience both today and few year into the future
3/ _ want _ to install that OS, but have to purchase the HW yet, so
they are looking at recommendations on what HW to buy

The _ recommended _ HW requirements could be reviewed periodically
also based on the current market offering.
The market surely can differ through the world, as well as the average
purchase power.
However I wouldn't recommend anyone to e.g. go with less than 8GB of
RAM today, when considering what new HW to buy or what HW to use for a
setup intended to be used for years.
This is useful for development, however much RAM intensive work can be 
done on the cloud or in some institutional settings a shared high 
capacity local server. For most people, largest daily use would come 
from spreadsheets and internet browsing. Many programs are sufficient on 
4Gb of RAM, though many lightweight electron Javascript applications can 
slow performance compared to similar C/C++/GO alternative applications.

Perhaps, we - as a community - might be able to gather our
expectations and make some average for those values?


The _ minimal _ requirements on the other hand are IMO seeked by an
entirely different group of people that
1/ are looking up the minimal requirements on recent HW for e.g. IOT
edition, or other use-cases in which you need to get the most of a not
really powerful but recent HW
2/ are looking up whether some HW from a XYZ years or decades ago
could run the Fedora Linux

Main issue is hardware security.


I understand it may be hard to check whether the HW meets the pure
technical limitations.
Though if we know how to do that, we may automate that and prepare
some package, some script purely for the purpose of this check. We
would also need to think about where to put it - the server edition
maybe, or the net installer, or could we patch the GRUB2 itself with
it, providing a custom call which could be selected as a separate boot
entry in all the bootable media we provide ?


What do you folks think - does the idea of defining the values based
on the use cases of people that are _  actually likely to seek those
values _ make sense as I tried to explain it?
It may be better to ask people using/developing different spins what 
they find works for their spin. Bare OS is probably fine on 512MB - 1GB 
of RAM.  Applications and data used are more important - if you are 
building software locally, doing image processing, video editing, doing 
engineering simulation and design, doing communication, browsing the 
web, gaming, or office applications, your needs will be quite different. 
Possibly one can measure RAM use during CI tests for the applications.



___
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: dropping php-imap (was Re: Orphaned packages looking for new maintainers)

[Benson Muite]

On 2/13/21 1:48 PM, Miro Hrončok wrote:

On 09. 02. 21 12:17, Joe Orton wrote:

On Mon, Feb 08, 2021 at 06:43:29PM +, Gwyn Ciesla via devel wrote:
Can uw-imap be replaced with something else, or should someone pick 
it up?


There has not been an upstream release since 2007 - the maintainer Mark
Crispin sadly died in 2012, and nobody else has formed an upstream
around it.

In my view it makes sense to drop it from Fedora 35+ and take the pain
of disabling functionality until the various upstreams switch to
alternatives.  Hopefully Remi can comment on alternatives.


Since uw-imap does not install in Fedora 34 even, and nobody takes care 
of it, it has been scheduled for early retirement, see 
https://pagure.io/releng/issue/10013 -- I guess if we are to preserve it 
in Fedora 34, somebody needs to take action.


I believe the best course of action is to take over the package and keep 
libc-client, but remove uw-imap.



PHP maintainers seemed to have been relying on Fedora maintenance:
https://github.com/uw-imap/imap
and have a related discussion:
https://bugs.php.net/bug.php?id=78572
How crucial is the libc-client? Probably other distributions have the 
same problem so some collaboration may be possible.

___
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: dropping php-imap (was Re: Orphaned packages looking for new maintainers)

[Benson Muite]

On 2/10/21 5:00 PM, Kevin Kofler via devel wrote:

Joe Orton wrote:

In my view it makes sense to drop it from Fedora 35+ and take the pain
of disabling functionality until the various upstreams switch to
alternatives.  Hopefully Remi can comment on alternatives.


I guess https://dev.horde.org/imap_client/ would be the obvious alternative,
but Remi or other people actively involved with PHP might know more.

The real issue is probably not so much to find an alternative, but to get
all the code out there ported to it. I doubt there is a drop-in replacement
anywhere.

Maybe we should consider packaging only the C client library of uw-imap,
dropping the server? There are enough maintained IMAP servers out there.



There are a number of php-imap implementations such as:
https://github.com/barbushin/php-imap
https://github.com/Webklex/php-imap
Debian seems to just have the C client library though possibly this is 
an issue to bring up on the php mailing list since it may be worth 
updating the C client which is required by php:

https://www.php.net/manual/en/imap.requirements.php
___
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: Serhei Makarov

[Benson Muite]

On 1/18/21 11:41 PM, Serhei Makarov wrote:

Hello all,

My name is Serhei Makarov.

Welcome. Your class scheduler:
https://github.com/serhei/course-scheduler
seems useful. Maybe it can be ported to C/C++/Ruby and packaged?

___
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: Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation Maintainers, Available for testing

[Benson Muite]

On 1/4/21 9:28 AM, Akashdeep Dhar wrote:

Hello,

The suggestions made here 
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/CXXZ6YIL22Y34SIFT6XWK3DL3FD5VCLF/
 and 
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/ZWSKCQ2BQD4UZJAKEDNREF3FX6RVCDAR/
 are taken into account in the most recently made PR 
https://github.com/t0xic0der/syngrafias/pull/94. Feel free to take a look at it.

Thanks for implementing the suggestion.
___
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: Syngrafias - AsciiDocs Collaboration Tool for Fedora Documentation Maintainers, Available for testing

[Benson Muite]

On 12/29/20 2:01 PM, Nasir Hussain wrote:

Hi,

We'd like to announce the public testing of Syngrafias, an Asciidoctor
collaboration tool - a service for Fedora documentation maintainers 
aiming to

provide an environment where they can collaborate by sharing their workspace
among multiple contributors with active synchronization of edits at 
every end

and live preview of the Asciidoctor files.

Good idea.


The preview version for public testing is now available here:
http://35.231.107.163/ 
Nice. Consider using a temporary domain name for this. For example from 
Freenom.


Please note that as it has been deployed on a low-tier Google Cloud 
instance,

the first load might take a while.

Syngrafias leverages WebSockets backend to significantly improve upon the
collaboration experience among multiple documentation writers and ensures an
ultralight implementation of the workspace server. (~2MB above Python 
runtime)
Are there any similar tools in other languages (Go, Rust, Crystal)? 
Python runtime includes heavy batteries, so not great for underpowered 
instances, though useful for rapid development.


It also includes the following features -

- Live Asciidoc editing and preview

A link to an Asciidoc cheatsheet maybe a good tip to have. Examples include:
https://powerman.name/doc/asciidoc
https://www.writethedocs.org/guide/writing/asciidoc/
One could also create one, but the tips and documentation section seems 
not to be currently available at

https://github.com/t0xic0der/syngrafias
___
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 nodeja-svgo

[Benson Muite]

On 12/22/20 9:25 AM, Luya Tshimbalanga wrote:
Due to multiple missing nodejs dependencies needed for nodejs-svgo, I 
had to orphan it. That plugin was intended for Inkscape sgvo. 
Maintainers are welcome to grab it.


https://src.fedoraproject.org/rpms/nodejs-svgo



How does this compare to Scour ?
Is this a better alternative:
https://github.com/juanfran/svgo-inkscape

In the long run, might https://github.com/svgpp/svgpp be a place to add 
SVG cleaning functionality?

___
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: video meeting to discuss Matrix/Element and IRC

[Benson Muite]

I'm not going to give a firm recommendation for or against any platform
but I'd like to make two suggestions:

a) why not slow the process down and allow more ideas to come forward?
There is no urgent need to change things in a month or whatever.
This is a reasonable suggestion. Since one can bridge Matrix and IRC it 
is possible for different IRC channels to try it out. The ability to 
bridge Matrix really helps since one does not need to install another 
client for each new group conversation. One worry with Matrix is that 
the core protocol has less of a structured development and ratification 
process than IRC [1] or XMPP [2], so long term use is unclear.


b) it is really important to look at the organizational factors and not
just the technical factors.  Today, too many organizations allow their
culture to be shaped by whatever tool is available.  I'll refrain from
giving examples of the disasters that follow.  For any free software
organization and any other type of organization too, it needs to be
organization first, tool second.
This is a good point. As has been pointed out, the desktop clients need 
some work, and at present nothing with performance of the Telegram 
client[3].  There are also a number of different implementations of the 
server to consider [4],[5],[6]



[1] https://ircv3.net/irc/
[2] https://en.wikipedia.org/wiki/XMPP
[3] https://github.com/telegramdesktop/tdesktop
[4] https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta
[5] https://gitlab.com/mascarene/mascarene
[6] https://gitlab.com/famedly/conduit
___
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: Nurmukhamed Artykaly

[Benson Muite]

On 7/22/20 9:31 AM, Nurmukhamed Artykaly wrote:
I am an IT engineer, sysadmin, programmer, DevOps, SRE. I study new 
technologies. My Blog is dedicated to IT technologies and (or) events 
related to IT in Kazakhstan, the CIS and the world.




Hi Nurmukhamed,
Welcome to Fedora. We look forward to your contributions. You may find 
it helpful to read the following:

https://fedoramagazine.org/how-to-contribute-to-fedora/
https://fedoramagazine.org/contribute-to-fedora-magazine-2/
Regards,
Benson
___
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: Nikolay Nikolov

[Benson Muite]

On 7/5/20 4:47 AM, nick...@gmail.com wrote:

Hello,

My name is Nikolay Nikolov. I'm a software developer and free/open
source enthusiast. I've been using Linux since Red Hat Linux 5.0. After
Red Hat Linux 9, I upgraded to Fedora Core 1 and I've used every Fedora
version since then. :) I'm a core developer of the Free Pascal Compiler
( https://www.freepascal.org/ ). My Free Pascal contributions include
code generator support for some legacy platforms, such as 16-bit x86
and Z80, as well as modern stuff, such as GDB/MI debugger support
integration in the Free Pascal IDE, x86 optimizations (for all x86
flavours - 16-bit, 32-bit and 64-bit).

I also develop and maintain several open source projects, written in
Pascal.

Things I'm interested in contributing to Fedora:

- co-maintaining the Free Pascal package (fpc) and adding crosscompiler
support for additional targets (e.g. crosscompiling to i386-linux from
x86_64, crosscompiling to win32 and win64, etc.).
- packaging the DOSBox-X fork of DOSBox:
https://github.com/joncampbell123/dosbox-x
- packaging some of my Pascal projects, when they get a release
- eventually, packaging other programs, written in Free Pascal

I know the basics about building RPMs, and I even build some of the
RPMs for the official Free Pascal release myself, but I still haven't
made any official Fedora RPMs (i.e. that strictly conforms to the
Fedora packaging guidelines, or that uses Fedora's build
infrastructure).

I use a lot of systems in order to test Free Pascal's many platforms,
including Windows, Mac OS X, various BSD flavours, but Fedora is my
primary operating system and the only Linux distribution I use, except
for Debian 8 on PowerPC, which I use in the rare circumstances where I
need to test the PowerPC code generator or to check if some of my code
runs correctly on big endian machines. :)

For testing the 16-bit x86 port of Free Pascal, I use the dosbox
emulator. I want to package the dosbox-x fork, because it offers better
CPU compatibility and long file name support, compared to the regular
dosbox. Especially on x86_64 dosbox has a nasty bug, which causes bugs
in specifically Free Pascal and Free Pascal-compiled programs, due to
inaccurate FPU emulation. The i386 version of dosbox doesn't have this
bug (as it uses the actual x86 FPU), but dosbox-x has this fixed also
on x86_64 (also by using the actual x86 FPU), so it's a better option
than compiling and running a 32-bit dosbox. Dosbox-x offers better
emulation accuracy, which allows more programs to run, it can correctly
emulate the 4:3 aspect ratio, which makes dos games look the way their
designed to look like, etc.

Best regards,
Nikolay
___
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



Welcome to Fedora. We look forward to your contributions.
___
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

[Benson Muite]

On 6/3/20 3:31 AM, Егор Артёмов wrote:

Hello there!
I am a C enthusiast from Russia. I'm using Fedora already for 12 years 
and now feel that I can contribute.
I am living in Saint-Petersburg, Russia, and working as C++ and Go 
developer in enterprise and gamedev.
I love Fedora and want to submit the `cgreen` package that I using by 
myself and feel that developers community will love it and use too :)
I also read ALL docs at the Fedora site and will glad to help with 
the review process for other packages.


Not sure what to state here. I also love to play drums and punk-rock:)
Egor.



Hi Egor

Welcome to Fedora. Cgreen (https://github.com/cgreen-devs/cgreen) looks 
useful. Your package seems to be on GitHub:

https://github.com/souryogurt/cgreen-rpm

Could you add it to Koji
https://koji.fedoraproject.org/koji
or if you think it is not quite ready for Fedora repositories to Copr
https://copr.fedorainfracloud.org/

Regards,
Benson
___
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: f32-backgrounds

[Benson Muite]

On Mon, Apr 20, 2020, at 5:56 AM, Paul Dufresne via devel wrote:
> Le 20-04-17 à 09 h 09, Benson Muite a écrit :
> > On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote:
> > Elections for alternative wallpapers are currently open:
> > https://apps.fedoraproject.org/nuancier/elections/
> > Please vote for ones that you like.
> Is the default wallpaper the result of a vote, or only alternatives to 
> the default?

These are alternatives to the default which can be easily enabled. Information 
on enabling a different wallpaper is at:
https://fedoramagazine.org/install-supplemental-wallpapers/

Schedule for Fedora 33 is at:
https://fedorapeople.org/groups/schedule/f-33/f-33-design-tasks.html

Information on how the official wallpaper is produced can be found here:
https://fedoraproject.org/wiki/Design#Fedora_Release_Wallpaper
___
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: f32-backgrounds look like crap

[Benson Muite]

On Fri, Apr 17, 2020, at 4:02 PM, Leigh Scott wrote:
> > Hi Leigh,
> > 
> > 
> > Do you think you could please use nicer language? There's no need to
> > use words like that to describe other people's work in the community.
> 
> That was the nicest term I could use to describe it!
> 
> > 
> > I personally quite like the 90s retro look.
> > 

Hi Leigh,

Elections for alternative wallpapers are currently open:
https://apps.fedoraproject.org/nuancier/elections/
Please vote for ones that you like.

The submission phase for Fedora 32 has unfortunately already closed. 
Please do make wallpaper submissions for Fedora 33 as well to ensure 
there is a wide choice of excellent candidates.
___
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 Chromium Dilemma

[Benson Muite]

On Mon, Apr 13, 2020, at 5:21 PM, Michael Catanzaro wrote:
> Honestly, degraded performance is an expected result of doing component 
> build, so I would say that's just not a bug at all, it's just how 
> Chromium works. Our hand is forced here by upstream's strange and 
> unusual packaging decisions. Other distros do it this way too.
> 
> But you say the difference is *noticeable*, i.e. noticeable to users 
> when not doing benchmarks? That sounds weird.
> 
> On Mon, Apr 13, 2020 at 9:56 am, Tom Callaway  
> wrote:
> > This is my dilemma. (It is not my only dilemma, nor my most pressing, 
> > but it is still mine.) That said, I would love to get input from 
> > other smart Fedorans as to what I should do here.
> 
> Naive proposal: chromium-freeworld could completely rebuild Chromium 
> and Obsoletes the entire Fedora package? It could have an epoch ahead 
> of the Fedora package such that the rpmfusion version is always 
> preferred even if the Fedora package updates a bit? Then 
> chromium-libs-media-freeworld can go away and the main Fedora package 
> can do a static build and you get working krb5. Is there a downside to 
> this approach that I'm missing?
> 
> 

Are the benchmark results available somewhere?  What exactly was measured in 
those benchmarks?
___
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: Dev Singh

[Benson Muite]

On Sun, Apr 12, 2020, at 7:12 PM, Dev Singh wrote:
> Hello everyone,
> My name is Dev Singh and I am a student developer in the Chicagoland area in 
> the US. I have worked in various open-source applications and in FRC 
> robotics. I am hoping to be the package manager for the `thinkpad-tools` 
> package which allows the user manage various Lenovo ThinkPad laptop 
> properties. I am also the upstream developer for this project. I have filed a 
> review request here . 
> 
> I can be found on GitHub as devksingh4, and my GPG fingerprint is: 62DC 96FF 
> 5DA4 7C02 D90D 3EB9 AA2E 907F 4513 25A6.
> 
> I look forward to working with you all at some point. I hope you all have a 
> wonderful day and are staying healthy!
> 
> 
> Best, 
> Dev Singh
> 
> 

Hello Dev and welcome to Fedora. We hope Lenovo users can have a more 
productive experience because of you.

Regards,
Benson
___
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: kinit: Password incorrect while getting initial credentials

[Benson Muite]

On Mon, Mar 30, 2020, at 8:57 PM, Paul Dufresne via devel wrote:
> I am trying to follow instructions at:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> 
> But when I do:
> [paul@localhost ~]$ kinit pa...@fedoraproject.org
> I get:
> Password for pa...@fedoraproject.org: 
> kinit: Password incorrect while getting initial credentials
> [paul@localhost ~]$ 
> 
> Is it because I did not done the Introduce yourself part and that I
> need an administrator to activate my account?
> 
> I use my FAS account password, and it works for other services.

Had a similar problem when trying to push a build to Koji.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Mark Olesen

[Benson Muite]

On Mon, Mar 23, 2020, at 9:47 PM, Mark Olesen wrote:
> I'm involved in the development of OpenFOAM (www.openfoam.com), which is 
> a GPL open source computational fluid dynamics (CFD) software package.
> 
> To improve the overall coverage, I've been generating Fedora/RedHat 
> packages using copr. As I understand, the next stage would be 
> (co)maintaining Fedora packages for OpenFOAM and eventually RedHat packages.
> 
> The copr site:
> https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/packages/
> 
> The src.rpm and spec files can be a bit difficult to find in copr, but 
> the openSUSE version is almost identical
> https://build.opensuse.org/package/view_file/science/openfoam1912/openfoam1912.spec
> 
> The only real difference being the "Release" entry, which is an 
> incremental counter for the openSUSE builds, but a patch level and 
> distribution (eg, 200312%{?dist}) for the Fedora version.
> 
> I would greatly appreciate it if anyone wishes to co-maintain the package.
> 
> Package review:
> https://bugzilla.redhat.com/show_bug.cgi?id=1816301
> 
> Cheers
> /mark
> ___
> 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
>
Welcome to Fedora. You might consider examining the Scitech SIG:
https://fedoraproject.org/wiki/Category:SciTech_SIG
 Spec file can be found in Copr at:
https://download.copr.fedorainfracloud.org/results/openfoam/openfoam/epel-7-x86_64/01304439-openfoam1912/openfoam1912.spec
___
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 help with my packages

[Benson Muite]

On Mon, Mar 2, 2020, at 12:30 AM, Orion Poplawski wrote:
> I have too many packages that I am the maintainer for and need help. If 
> you would like to help out by either becoming a co-maintainer or 
> becoming the primary maintainer, please let me know. The full list 
> follows. Many of these I just made the scitech_sig group co-mainter of 
> as described here:
> 
> https://lists.fedoraproject.org/archives/list/scit...@lists.fedoraproject.org/thread/76IZTKYWTLQL35FJAWEWBNUIGRAQJQX7/
> 
> so if you are interested in those becoming a member of the scitech_sig, 
> if you are not already, would probably be the easiest.
> 
> Thanks!
> 
> ast
> BareBonesBrowserLaunch
> bes
> cmake
> cobbler
> codehaus-parent
> cube
> cups-x2go
> dcw-gmt
> eclipse-photran
> eclipse-ptp
> elfio
> fail2ban
> fcode-utils
> ftnchek
> g2clib
> gdl
> gifsicle
> GMT
> gshhg-gmt-nc4
> guessencoding
> gv
> hdf
> hdf5
> java-sleep
> javatar
> jilter
> koan
> kwalletcli
> lasi
> libdap
> libfabric
> libreoffice-TexMaths
> Lmod
> lua-term
> Mayavi
> moconti
> mod_xsendfile
> MySQL-zrm
> ncl
> nco
> ncview
> netcdf
> netcdf4-python
> netcdf-cxx
> netcdf-cxx4
> netcdf-fortran
> netcdf-perl
> nx-libs
> oct2spec
> octave
> octave-image
> octave-io
> octave-ncarray
> octave-netcdf
> octave-statistics
> opari2
> openblas-srpm-macros
> openvpn-auth-ldap
> otf2
> pam_2fa
> paraview
> pcfi
> perl-Astro-FITS-CFITSIO
> perl-Boulder
> perl-Cflow
> perl-Device-SerialPort
> perl-ExtUtils-F77
> perl-HTML-Table
> perl-Log-Trivial
> perl-Net-IP-CMatch
> perl-Net-Patricia
> perl-String-Approx
> perl-XML-DOM
> perl-XML-RegExp
> plplot
> pslib
> pyhoca-cli
> pyhoca-gui
> python-AppTools
> python-cftime
> python-clyent
> python-conda-package-handling
> python-cytoolz
> python-ecdsa
> python-enthought-sphinx-theme
> python-envisage
> python-fido2
> python-ipython_genutils
> python-locket
> python-nbformat
> python-numpydoc
> python-optcomplete
> python-pamela
> python-pkgconfig
> python-process-tests
> python-pycodestyle
> python-pycosat
> python-pyface
> python-pytest-cache
> python-pytest-cov
> python-pytest-flakes
> python-scp
> python-setuptools_scm
> python-sphinxcontrib-issuetracker
> python-sphinx-gallery
> python-spur
> python-terminado
> python-toolz
> python-traitlets
> python-Traits
> python-traitsui
> python-vsc-install
> python-x2go
> python-xmlrunner
> qtbrowserplugin
> rhash
> scorep
> svgalib
> tcl-signal
> vtk
> wgrib
> wgrib2
> x2goclient
> x2godesktopsharing
> x2goserver
> zfp
> 
> -- 
> Orion Poplawski
> Manager of NWRA Technical Systems 720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> 
> 
> ___
> 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
> 
> 
> *Attachments:*
>  * smime.p7s
Hi,
Have some interest in Octave.
Benson___
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: Subject: Self Introduction: Francis Gesora

[Benson Muite]

On Tue, Feb 25, 2020, at 11:17 AM, Francis Gesora wrote:
> Hi All,
> 
> I am Francis, based in Nairobi, Kenya.
> 
> I am joining as a package maintainer to assist Ankur manage xmedcon and deps 
> as i get up to speed with package maintenance.
Hello/Hujambo Gesora,

Awesome to have you here.

Regards,
Benson
> 
> Thanks!
> 
> -- 
> Regards,
> Gesora.
> ___
> 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: Self Introduction: Chihurumnaya Ibiam

[Benson Muite]

On Thu, Feb 20, 2020, at 2:20 AM, Chihurumnaya Ibiam wrote:
> Good day, 
> 
> I've been working mostly with python at Sugar Labs for some time now, I'm yet 
> to file a review request but I'm currently helping co-maintain the sugar* 
> packages;
> I'm from Nigeria.
> 
> I'm glad to be part of the fedora project maintainers community.
> -- 
> Ibiam Chihurumnaya 
> ibiamchihurumn...@gmail.com

Welcome to Fedora.

> ___
> 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: Java Dev Group and Fedora Quality

[Benson Muite]

On 1/26/20 8:25 AM, Bill Chatfield via devel wrote:

I think that by applying basic engineering techniques like user testing we can 
weed out ideologies that don't provide any value to users. Do the testing and 
let the results decide.The principles of ISO 9000 can be applied to improve 
products. There are also metrics that can measure how good a user interface is, 
like how many clicks does it take to perform a specific task. If these kinds of 
techniques were being applied to Gnome, we'd be able to more impartially 
measure how good Gnome is and also improve it. We'd be able to make more 
informed decisions and get better results. And if the Gnome guys actually had 
information like this, they'd be forced to deal with it. Maybe they'd be forced 
to admit that they care more about their ideology than helping their users be 
more productive. Or maybe the results would support the Gnome ideology. Until 
someone takes a scientific/engineering approach to measuring it, the issue 
can't really be resolved.

My problem with Gnome is that they just do whatever they feel like instead of 
applying well-established engineering or software engineering quality processes.


Desktop change can be done from terminal [0],[1],[2] (though not in 
software center which may be helpful for some users):


sudo dnf -y group install "KDE Plasma Workspaces"


Not sure if any of the available desktops takes the above measurement  
approach. Many linux users value privacy, but some data collection would 
be helpful.



[0] https://computingforgeeks.com/install-kde-plasma-environment-on-fedora/

[1] 
https://computingforgeeks.com/how-to-install-deepin-desktop-environment-on-fedora/


[2] 
https://www.tecmint.com/install-and-switch-desktop-environments-in-fedora/



___
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: Let's talk about Fedora in the '20s!

[Benson Muite]

On 1/15/20 8:33 PM, Przemek Klosowski via devel wrote:

On 1/7/20 11:14 AM, Iñaki Ucar wrote:

I'm far from having a satisfactory response to that, but I see two
fronts here. First, marketing. How does Ubuntu managed to be so
popular among less-experienced Linux users? I'm not sure, but I
suspect that good marketing has something to do with it.
One of their primary aims has been user friendliness. Their forums are 
helpful and it is easier to find information on Ubuntu with a quick 
internet search. A number of other linux distributions now aim to be 
friendly to those who just want things to work.


I can think of several reasons that are important to me; some of them 
were addressed by Fedora and are no longer relevant, but they gave 
Ubuntu enough momentum to last


- Ubuntu provides LTS releases, so people can chose to install and 
forget. Yes, it is a tradeoff with new/shiny, but it's nice to have 
this option for something that is intended to last.
Fedora is positioned somewhere in between Debian and Ubuntu. Debian does 
not have as many users as Ubuntu. Cent OS is available for 10 years, but 
is mostly considered a server distro, though is also very capable 
desktop as many of the things in Fedora can be used in Cent OS or easily 
ported to it.


- as the result of the momentum, Ubuntu became the default in various 
special circumstances: Jupyter notebooks, WSL, etc.; furthermore, this 
popularity attracted packagers  so that some Ubuntu packages lead 
Fedora (see also next point).
Having software packages is helpful. However, things like Flatpak, Snap 
and Appimages may make this less of a concern. Some distributions allow 
using package repositories from other distributions, for example Puppy 
dog linux can use Ubuntu repositories, so with a small number of core 
developers can offer many applications.


- Ubuntu was pragmatic and compromising on non-free software such as 
codecs and video drivers; as a result, it has sometimes better support 
for things like CUDA software, video/multimedia, etc., even though 
nowadays Fedora has practically out-of-box support for these.
It is helpful to know when non-free software is used.  Perhaps better 
communication with hardware vendors is required. Alternatively, a number 
of distributions do have online stores where you can get a pre-installed 
system that should be hassle free. Part of the attraction of linux is 
the freedom to configure things yourself which  requires an investment 
of time.


Regarding the first point, the Fedora/Redhat/CentOS environment 
requires an early decision and commitment to one of the three 
alternatives. If it is production, one would deploy paid-support 
RedHat; less critical but still long-term roles call for CentOS, and 
of course Fedora is best for personal systems, especially for 
development and testing new software stacks.
This mostly needs a good partitioning of the file system and/or multiple 
hard drives, separate, data from the operating system and the 
applications. It is then possible to easily change the operating system. 
It is also possible to have workstations with multiple operating system 
boot options.


It turns out, however, that the initial intent often changes: an 
important production system becomes a less-critical legacy, or a 
cutting-edge development system proves itself and becomes production. 
In these cases it would be nice to transition smoothly between the 
choices: a RHEL system that comes off its entitlement should not just 
sit there unpatched but should smoothly transition to CentOS, and 
maybe there could be a way to transition a no-longer supported Fedora 
to a roughly-equivalent RedHat/CentOS. I realize that this is a big 
ask, but I wished for it often enough that I thought I'd put it out 
here for consideration, especially in the context of competing with 
Ubuntu.
This can work by separating data from operating system. Main problem 
might be that some software package may need to be built again since it 
may not be available in the repository - this would likely need some 
developer/packager time. Transitioning may be challenging to fully 
automate due to application software availability and compatibility, 
though many linux installers now give a choice of where to put the 
operating system and what disks/partitions to leave untouched.

___
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: 

Re: Let's talk about Fedora in the '20s!

[Benson Muite]

On 1/14/20 10:34 AM, Benson Muite wrote:


On 1/14/20 9:00 AM, Luya Tshimbalanga wrote:


On 2020-01-13 12:56 a.m., Benson Muite wrote:


On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years 
and contributions are very difficult when users lack knowledge of 
coding without proper guidance. For example, attempting to improve 
say CellWriter (sorely missing due to the lack of port to Wayland 
compositor) and howdy, a Windows Hello facial recognition like for 
convertible laptops turned out too much as a graphic designer and 
trying to get someone knowing to code turned out complex than 
anticipated.


Only options is to actively test and give input so far.

Deepin Linux seems to have a face recognition login (or at least 
support for this), but still searching for the implementation. The 
two PAM based authentications (Howdy and PAM-facial-auth):


https://github.com/devinaconley/pam-facial-auth

https://github.com/boltgolt/howdy

seem to suggest they are not intended when high security is 
required. Tests on manufacturer developed authentication also seem 
to suggest not so secure:


https://www.blackhat.com/presentations/bh-dc-09/Nguyen/BlackHat-DC-09-Nguyen-Face-not-your-password-slides.pdf 



However, a number of banks and KFC do use this in China, so maybe a 
good open source implementation is missing (something other than a 
trial version). Most of these rely on machine learning algorithms, 
maybe something machine learning SIG might be interested in. 


Thank you for the PDF. However, the presentation is sightly outdated 
given the listed hardware dating from 2008. Some modern laptops are 
equipped with a IR camera Windows Hello type device which could be 
suitable for iris recognition similar to devices like Samsung Galaxy S9. 
Thanks for feedback. Not having to remember many passwords is very 
useful.


Maybe am wrong about faces/fingerprints as passwords:

https://www.openwall.com/lists/oss-security/2019/05/08/5



Speaking about howdy, I packaged it on COPR for testing purpose and 
looking for improvement.


Great, may be of interest:

https://github.com/boltgolt/howdy/issues/233

My initial worry is more on the security of the algorithms used in 
howdy and their effectiveness, rather than correct packaging and linux 
permissions. Internally Howdy uses convolutional neural networks (CNN 
- http://dlib.net/cnn_face_detector.py.html) and OpenCV to find and 
match faces. It would be nice if it had been subjected to stringent 
tests such as those done by NIST:


https://pages.nist.gov/frvt/html/frvt1N.html

see for example:

https://www.necam.com/AdvancedRecognitionSystems/NISTValidation/FingerprintFacial/ 




I am aware of fprintd but it is beyond my scope,


This is already packaged and has a wiki page:

https://koji.fedoraproject.org/koji/packageinfo?packageID=7228

https://fedoraproject.org/wiki/Features/Fingerprint

The source code of fprintd is at 
https://gitlab.freedesktop.org/libfprint/fprintd


For fingerprints, there also seem to be standards:

https://www.nist.gov/programs-projects/fingerprint-recognition

and a NIST implementation:

https://www.nist.gov/services-resources/software/nist-biometric-image-software-nbis 



Not sure if fprintd matches these standards, or if there is something 
significantly better.



For biometric authentication applications such as fprintd and howdy, 
maybe some kind of quality assurances are required, in particular for 
hardware specifications and algorithm effectiveness, in addition to 
the normal packaging procedure.



___
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: Let's talk about Fedora in the '20s!

[Benson Muite]

On 1/14/20 9:00 AM, Luya Tshimbalanga wrote:


On 2020-01-13 12:56 a.m., Benson Muite wrote:


On 1/12/20 9:38 AM, Luya Tshimbalanga wrote:
The challenge about upstream is when they lack activity for years 
and contributions are very difficult when users lack knowledge of 
coding without proper guidance. For example, attempting to improve 
say CellWriter (sorely missing due to the lack of port to Wayland 
compositor) and howdy, a Windows Hello facial recognition like for 
convertible laptops turned out too much as a graphic designer and 
trying to get someone knowing to code turned out complex than 
anticipated.


Only options is to actively test and give input so far.

Deepin Linux seems to have a face recognition login (or at least 
support for this), but still searching for the implementation. The 
two PAM based authentications (Howdy and PAM-facial-auth):


https://github.com/devinaconley/pam-facial-auth

https://github.com/boltgolt/howdy

seem to suggest they are not intended when high security is required. 
Tests on manufacturer developed authentication also seem to suggest 
not so secure:


https://www.blackhat.com/presentations/bh-dc-09/Nguyen/BlackHat-DC-09-Nguyen-Face-not-your-password-slides.pdf 



However, a number of banks and KFC do use this in China, so maybe a 
good open source implementation is missing (something other than a 
trial version). Most of these rely on machine learning algorithms, 
maybe something machine learning SIG might be interested in. 


Thank you for the PDF. However, the presentation is sightly outdated 
given the listed hardware dating from 2008. Some modern laptops are 
equipped with a IR camera Windows Hello type device which could be 
suitable for iris recognition similar to devices like Samsung Galaxy S9. 

Thanks for feedback. Not having to remember many passwords is very useful.


Speaking about howdy, I packaged it on COPR for testing purpose and 
looking for improvement.


Great, may be of interest:

https://github.com/boltgolt/howdy/issues/233

My initial worry is more on the security of the algorithms used in howdy 
and their effectiveness, rather than correct packaging and linux 
permissions. Internally Howdy uses convolutional neural networks (CNN - 
http://dlib.net/cnn_face_detector.py.html) and OpenCV to find and match 
faces. It would be nice if it had been subjected to stringent tests such 
as those done by NIST:


https://pages.nist.gov/frvt/html/frvt1N.html

see for example:

https://www.necam.com/AdvancedRecognitionSystems/NISTValidation/FingerprintFacial/


I am aware of fprintd but it is beyond my scope,


This is already packaged and has a wiki page:

https://koji.fedoraproject.org/koji/packageinfo?packageID=7228

https://fedoraproject.org/wiki/Features/Fingerprint

The source code of fprintd is at 
https://gitlab.freedesktop.org/libfprint/fprintd


For fingerprints, there also seem to be standards:

https://www.nist.gov/programs-projects/fingerprint-recognition

and a NIST implementation:

https://www.nist.gov/services-resources/software/nist-biometric-image-software-nbis

Not sure if fprintd matches these standards, or if there is something 
significantly better.



For biometric authentication applications such as fprintd and howdy, 
maybe some kind of quality assurances are required, in particular for 
hardware specifications and algorithm effectiveness, in addition to the 
normal packaging procedure.



___
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