Self Introduction: Juanjo Rubio
by Juanjo Rubio
Hi!
My name is Juanjo Rubio, I am 32 and currently working in data science and machine learning engineering related topics. Long time linux user, familiar with open source software and programming (mainly Python) but I have personally never contributed to a Linux distro.
I have been following the mailing list lately to get exposed to the workflow. I haven't found exactly what task to focus on yet but I am hoping to get involved in the packaging process very soon.
Have a lovely day!
2 years, 9 months
Fedora 35 Change: Autoconf-2.71 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Autoconf_271
== Summary ==
Autoconf upgrade from version 2.69 to the last upstream version 2.71 in Fedora.
== Owner ==
* Name: [[User:odubaj| Ondrej Dubaj]]
* Email: odubaj(a)redhat.com
== Detailed Description ==
Upgrading autoconf from version 2.69 to version 2.71 according to new
upstream release. Version 2.70 is skipped due to multiple ABI
incompatibilities, where some of them were fixed in version 2.71.
Years of development differ these two releases, so problems are
expected.
This change might easily cause fails during builds of multiple
packages, as some of them still require autoconf-2.69. This step must
be properly discussed with maintainers of dependent packages, which
should forward this change proposal to their upstream projects.
== Benefit to Fedora ==
Brings a stable and up-to-date version of autoconf according to
upsteam release. It is expected, that in the future many upstream
development teams will use autoconf-2.71 as their default builder, so
Fedora will be prepared for such a step.
== Scope ==
* Proposal owners:
**Prepare autoconf-2.71 as RPM package for Fedora Rawhide
**Check software that requires `autoconf` or `autoconf-2.69` and
rebuild it with autoconf-2.71
**Build autoconf-2.71 to Rawhide in a side-tag
(https://fedoraproject.org/wiki/Package_update_HOWTO#Creating_a_side-tag)
**Rebuild depended packages with autoconf-2.71 in the side-tag
**Merge the side-tag to Rawhide
* Other developers:
**Check if their packages can be build with autoconf-2.71
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Problems during build can appear in multiple packages what can lead to
build failure, as multiple packages require autoconf-2.69 as their
upstream dependency. These problems have to be resolved before adding
autoconf-2.71 into Fedora. It seems aprox. 20% of dependent packages
are having problems during build, which could be caused by a problem
with same pattern.
== How To Test ==
Rebuilding your packages with autoconf-2.71 dependency in copr
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/).
Mass rebuild of dependent packages in a side tag.
== User Experience ==
Users will be able to use the newer version (2.71) of autoconf, and
building packages with autoconf-2.69 won't be available, as it won't
be present on the specific fedora version. This can affect 3rd partly
packages, which are not part of Fedora.
== Dependencies ==
Hundreds of packages have build dependency on autoconf, therefore it
is a huge step forward for Fedora, what should be properly discussed
and tested. List of dependent packages with their ability to be built
with autoconf-2.71 can be found in the given copr project
(https://copr.fedorainfracloud.org/coprs/odubaj/autoconf-2.70/packages/)
We should also look at dependent packages of `libtool` and `automake`
(other critical autotools packages), as there might be some
incompatibilities with the new autoconf version.
== Contingency Plan ==
* Contingency mechanism: moving this change to Fedora 36, if not
successfully finished until Fedora 35 branching from Rawhide
* Contingency deadline: Fedora 35 branching from Rawhide (2021-08-10)
* Blocks release? No
== Documentation ==
Latest autoconf documentation:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/...
== Release Notes ==
Release notes for autoconf-2.70:
https://lists.gnu.org/archive/html/autotools-announce/2020-12/msg00001.html
Release notes for autoconf-2.71:
https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 9 months
Red Hat Bugzilla issues
by Silvia Sánchez
Hello everyone,
I was trying to file a bug following last QA meeting and turns out I
can't. I moved from an old laptop to a new one and in the new one I can't
login. I'm using the correct password and everything, but still is
rejecting me. And using my FAS means that I have to create a new account
with its own password... I don't want to go through all this hassle. I
just want to file a bug.
Can someone tell me what or where is the problem? Why the password that
works in one laptop is not working in the other?
Please, help and thank you
Kind regards,
Silvia
FAS: Lailah
2 years, 9 months
No FESCo Meeting today (2021-08-30)
by Neal Gompa
There is nothing on the agenda, so I'm canceling this week's meeting.
I'll pick this up again next week if we have anything.
= Discussed and Voted in the Ticket =
#2654 Nonresponsive maintainer: Markus Mayer lotharlutz
https://pagure.io/fesco/issue/2654
APPROVED (+3, 0, -0)
--
真実はいつも一つ!/ Always, there's only one truth!
2 years, 9 months
rpkg-3.rc2 built into rawhide
by clime
Hello,
I have built rpkg-3.rc2 (package sources:
https://src.fedoraproject.org/rpms/rpkg-util) into rawhide yesterday.
It should be now available for installation.
It is a complete rewrite of version 2. It aims to be a tool with
minimal deps that allows people to easily transform git repositories
containing spec files into rpm packages.
Historically, the goal of this tool was to provide a single client to
all dist-git instances (i.e Fedora, CentOS, maybe something else too).
This was the idea when I started to work on it still in RedHat under
the lead of Miroslav Suchý. We wanted to tweak the rpkg script
provided by python-rpkg lib (https://pagure.io/rpkg) for that purpose.
However, that script was soon being discontinued. There I created a
separate project (rpkg-util) which would be providing the script so
that I can continue in my goal.
Eventually, I realized that some steps rather need to be taken
server-side (https://github.com/release-engineering/dist-git) for a
generic client to exist so that I did and then it was about adoption
of the dist-git package (which provides the unified interface) by
various dist-git instances.
Meanwhile, I was thinking what to do next with rpkg while being
heavily influenced by Copr that I primarily worked on at that time and
also by discussion on devel list about automatically generating
changelog and release from git. I realized there is an opportunity to
provide a solution for this in the generic dist-git client (rpkg
executable) and that it was not a bad place for it.
This problem was then and even today solved by basically sedding spec
file with regexps which I thought is kind of hacky and that it could
be useful to have a library for common substitutions anyway so that
people can reuse it. So a simple spec templating language was born
(https://docs.pagure.org/rpkg-util/v3/spec_templates_from_scratch.html)
and also a simple library of macros
(https://docs.pagure.org/rpkg-util/v3/macro_reference.html) that use git
content and metadata to render spec file content or parts of it. It
now allows not only to generate changelog or release but also e.g. to
generate a source tarball from a git submodule placed next to the spec
file.
There is also the possibility for users to define their own macros and
therefore customize git->rpm transform in any way.
You can try this now in rawhide (`dnf install rpkg`) or also in Copr
(SCM rpkg build method) but note that in Copr, there is still v2 so
there might be some differences. You might also need to install
python3-setuptools - that package seems to be required by
python3-munch but is not being brought in automatically at the moment.
You can use rpkg tool similarly to fedpkg to work with Fedora dist-git
packages (except that `rpkg build` command builds in Copr and the
command set is mostly trimmed-down) or you can use it to work with
those git layouts that contain unpackaged sources together with spec
file (or rather spec file template) or link to the upstream sources
through a git submodule.
Best regards
clime
P.S.: the project is hosted here: https://pagure.io/rpkg-util
2 years, 9 months
Re: Intent to retire python-typer and python-typer-cli
by Ben Beasley
Thanks for pointing this out.
I’ll unretire typer and typer-cli, then, and give it another chance.
It’s been less than eight weeks (only a few days!) so unretirement will
be quick and will not require re-review.
A little communication from the upstream maintainer would have really
helped!
- Ben
On 8/30/21 6:22 AM, Chandan Kumar wrote:
> Hello Ben,
>
> On Sat, Aug 21, 2021 at 12:36 AM Ben Beasley <ben(a)musicinmybrain.net> wrote:
>>
>> Unless someone convinces me of another plan, I intend to retire
>> python-typer and python-typer-cli in F35 and Rawhide in one week
>> (2021-08-27).
>>
>> I myself introduced these two packages to Fedora quite recently
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1964742,
>> https://bugzilla.redhat.com/show_bug.cgi?id=1974118). No other packages
>> currently depend on them.
>>
>> Upstream was in a period of inactivity that was not too worrisome at the
>> time, but has become much more concerning as they have not responded at
>> all to issues or PR’s on this project and have not made the necessary
>> (nontrivial) changes to work with the new major release (8.x) of
>> python-click. Please see https://github.com/tiangolo/typer/issues/313
>> for an overview of the situation and links to additional relevant issues.
>>
>> It might be possible to sustain these two packages in Fedora 35 by
>> introducing a click 7.x compatibility package, but this is not a
>> long-term solution, and I have no confidence that these projects will be
>> sustainably maintained in the future.
>>
>
> typer-0.4.0 got released today.
> https://github.com/tiangolo/typer/releases/tag/0.4.0
>
> I think it addresses the above issue related to click 7.x compatibility package,
>
> As per https://github.com/tiangolo/typer/issues/313#issuecomment-908181587
> ```
> I just released Typer 0.4.0, which is compatible with both Click 7 and Click 8.
> ```
> I hope it helps.
>
> Thank you for maintaining it.
>
> Thanks,
>
> Chandan Kumar
>
2 years, 9 months