Converting montserrat spec to new version

[Luya Tshimbalanga]

Hello team,

I started converting the current julietaula-montserrat-fonts spec to the 
new version [1] using ibm-plex-fonts as template [2], but struggled to 
understand the functionality.


Here is an example below:

--

BuildArch:  noarch
%global fontpkgname julietaula-montserrat
%global fontconf 61-%{fontpkgname}

# Override versioning to sync with upstream
Epoch:        1
Version:    7.222
Release:    %autorelease
URL:        https://github.com/JulietaUla/Montserrat

%global foundry julietaula
%global fontlicense OFL
%global fontlicenses    OFL.txt
%global fontdocsex  %{fontlicenses}

%global fontfamily1  Montserrat
%global fontsummary1 Sans-serif typeface inspired from 
Montserrat area

%global fonts1   *.otf
%global fontdescription1 %{expand:
A typeface inspired by signs around the Montserrat area \
of Buenos Aires, Argentina.}

%global fontfamily2  MontserratAlternates
%global fontsummary2 Sans-serif typeface inspired from 
Montserrat area

%global fonts2   *.otf
%global fontdescription1 %{expand:
A typeface inspired by signs around the Montserrat area \
of Buenos Aires, Argentina.}



Source0: %{url}/archive/v%{version}.tar.gz#/Montserrat-%{version}.tar.gz
Source1:    %{name}-fontconfig.conf
Source2:    %{name}-alternates-fontconfig.conf
Source3:    %{fontpkgname}.metainfo.xml
Source4:    %{fontpkgname}-alternates.metainfo.xml

BuildArch:    noarch
BuildRequires:    fontpackages-devel
BuildRequires:    libappstream-glib
Requires:    fontpackages-filesystem

# Reset the old date based versioning
Obsoletes:    %{name} < 1:%{version}-%{release}


%description
%{common_description}

%package common
Summary:  Common files for %{name}
Requires: fontpackages-filesystem

%description common
%{common_description}
This package consists of files used by other %{name} packages.

%package    -n %{fontpkgname}
Summary:    Base version of the Montserrat area inspired typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fo

As noticed, two subpackaged webfonts are listed because they are 
required from the landing page for Fedora Apache. I


ntpkgname}
%{common_description}
This package provide the base fonts.

%package     -n %{fontpkgname}-alternates-fonts
Summary:    A Montserrat area inspired typeface family alternate version
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-alternates-fonts
%{common_description}
This package provide an alternate version of the fonts.

%package    -n %{fontpkgname}-base-web-fonts
Summary:    Web fonts version of the Montserrat area inspired typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-base-web-fonts
%{common_description}
This package include essential web fonts.

%package    -n %{fontpkgname}-extra-web-fonts
Summary:    Extra web fonts version of the Montserrat area inspired typeface
Requires:    %{name}-common = %{epoch}:%{version}-%{release}

%description    -n %{fontpkgname}-extra-web-fonts
%{common_description}
This package includes extra web fonts.

%prep
%autosetup -c

%build
%fontbuild

%install
%fontinstall
install -m 0644 -p Montserrat-%{version}/fonts/webfonts/*.woff 
%{buildroot}%{_fontdir}
install -m 0644 -p Montserrat-%{version}/fonts/webfonts/*.woff2 
%{buildroot}%{_fontdir}


install -m 0755 -d %{buildroot}%{_fontconfig_templatedir} \
    %{buildroot}%{_fontconfig_confdir}

# Install Montserrat fonts
install -m 0644 -p %{SOURCE1} \
    %{buildroot}%{_fontconfig_templatedir}/%{fontconf}.conf

# Install MontserratAlternates fonts
install -m 0644 -p %{SOURCE2} \
%{buildroot}%{_fontconfig_templatedir}/%{fontconf}-alternates.conf

for fconf in %{fontconf}.conf \
     %{fontconf}-alternates.conf ; do
    ln -s %{_fontconfig_templatedir}/$fconf \
    %{buildroot}%{_fontconfig_confdir}/$fconf
done

# Add AppStream metadata file, Repeat for every font family
install -Dm 0644 -p %{SOURCE3} \
%{buildroot}%{_datadir}/metainfo/%{fontpkgname}.metainfo.xml
install -Dm 0644 -p %{SOURCE4} \
%{buildroot}%{_datadir}/metainfo/%{fontpkgname}-alternates.metainfo.xml

%check
appstream-util validate-relax --nonet 
%{buildroot}/%{_datadir}/metainfo/%{fontpkgname}.metainfo.xml
appstream-util validate-relax --nonet 
%{buildroot}/%{_datadir}/metainfo/%{fontpkgname}-alternates.metainfo.xml


%_font_pkg -f %{fontconf}.conf Montserrat-*.otf
%{_datadir}/metainfo/%{fontpkgname}.metainfo.xml
%_font_pkg -n alternates -f %{fontconf}-alternates.conf 
MontserratAlternates-*.otf

%{_datadir}/metainfo/%{fontpkgname}-alternates.metainfo.xml
%_font_pkg -n base-web 
Montserrat-{Regular,Light,Bold,ExtraBold,Italic}.{woff,woff2}

%_font_pkg -n extra-web Montserrat*.{woff,woff2}

%files common
%license Montserrat-%{version}/OFL.txt
%doc Montserrat-%{version}/README.md

%changelog

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Matthew Miller]

On Fri, Oct 08, 2021 at 11:10:17AM +0200, Mario Torre wrote:
> > RPMs. This is a hybrid packaging model, where some Java RPM packages
> > can be built in the traditional way (where code is compiled during
> > rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
> So the only thing left to do is to convince Mr. Fedora to approve this ;)

Well, there's no magical "Mr. Fedora"... what needs to happen is someone
needs to make a proof of concept.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2012093] epel8 request: perl-XML-Generator

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012093

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2021-ae314ea116 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ae314ea116

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012093
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] 2021-10-11 @ 16:00 UTC - Fedora 35 Blocker Review Meeting

[Adam Williamson]

# F35 Blocker Review meeting
# Date: 2021-10-11
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hi folks! We have 6 proposed Final blockers and 1 proposed Final freeze
exceptions to review, so let's have a review meeting on Monday.

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F35 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@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: jaxb* packages retired on f35+ (despite still being used)

[Jerry James]

On Fri, Oct 8, 2021 at 4:29 PM Miro Hrončok  wrote:
> My experience is that even retirements done after a freeze make it to the 
> repo,
> when a compose is done. Not sure if feature or bug, but maybe worth trying.

Okay, I have given it a try.  Fingers crossed that it all works out.
Thanks, Miro.
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: jaxb* packages retired on f35+ (despite still being used)

[Miro Hrončok]

On 08. 10. 21 22:42, Jerry James wrote:

On Fri, Oct 8, 2021 at 2:16 PM Jerry James  wrote:

I think jaxb is only needed for a twitter demo, which we obviously
don't need.  I'll remove the dependency from jakarta-json and do
builds for F35+.  I don't see any binary RPM dependencies on jaxb, so
I think a freeze exception won't be needed.  Let me know if I have
analyzed the situation incorrectly, but this looks like a build-time
problem only.  Regards,


There is another dependency.  The jakarta-ws-rs package also depends
on jaxb, and jakarta-json depends on jakarta-ws-rs.  However, it looks
like jakarta-ws-rs is only needed for the subpackages
jakarta-json-jaxrs and jakarta-json-jaxrs-1x, which nothing seems to
depend on.  So, in addition to dropping the twitter demo from
jakarta-json, I will also remove those two subpackages and remove the
dependency on jakarta-ws-rs.

I can retire jakarta-ws-rs from Rawhide, but it is too late to do so
for F35, of course.  Thoughts on what to do about that are welcome.


My experience is that even retirements done after a freeze make it to the repo, 
when a compose is done. Not sure if feature or bug, but maybe worth trying.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: jaxb* packages retired on f35+ (despite still being used)

[Jerry James]

On Fri, Oct 8, 2021 at 2:16 PM Jerry James  wrote:
> I think jaxb is only needed for a twitter demo, which we obviously
> don't need.  I'll remove the dependency from jakarta-json and do
> builds for F35+.  I don't see any binary RPM dependencies on jaxb, so
> I think a freeze exception won't be needed.  Let me know if I have
> analyzed the situation incorrectly, but this looks like a build-time
> problem only.  Regards,

There is another dependency.  The jakarta-ws-rs package also depends
on jaxb, and jakarta-json depends on jakarta-ws-rs.  However, it looks
like jakarta-ws-rs is only needed for the subpackages
jakarta-json-jaxrs and jakarta-json-jaxrs-1x, which nothing seems to
depend on.  So, in addition to dropping the twitter demo from
jakarta-json, I will also remove those two subpackages and remove the
dependency on jakarta-ws-rs.

I can retire jakarta-ws-rs from Rawhide, but it is too late to do so
for F35, of course.  Thoughts on what to do about that are welcome.
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: jaxb* packages retired on f35+ (despite still being used)

[Jerry James]

On Fri, Oct 8, 2021 at 2:06 PM Jerry James  wrote:
> It looks like antlr4 doesn't depend on jaxb directly, but only
> indirectly via jakarta-json.  Let me see if that dependency can be
> removed.  Still, it would have been nice to have a heads up about jaxb
> disappearing, and doing so right before final freeze is a really
> terrible idea, as you note.

I think jaxb is only needed for a twitter demo, which we obviously
don't need.  I'll remove the dependency from jakarta-json and do
builds for F35+.  I don't see any binary RPM dependencies on jaxb, so
I think a freeze exception won't be needed.  Let me know if I have
analyzed the situation incorrectly, but this looks like a build-time
problem only.  Regards,
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: jaxb* packages retired on f35+ (despite still being used)

[Jerry James]

On Fri, Oct 8, 2021 at 12:01 PM Fabio Valentini  wrote:
> I want to draw attention to the fact that the jaxb stack (Jakarta XML
> Binding for Java) was recently retired for rawhide and F35 (only hours
> before the final freeze went into effect). It looks like edewata did
> not do a comprehensive check whether those packages are still depended
> on by anything other than his own packages, though.
>
> Since there's not been a successful rawhide compose since the packages
> were retired, they now show up in the "orphaned packages" report,
> where their dependency trees are listed thusly:
>
> - Too many dependencies for jaxb, not all listed here
> - Too many dependencies for jaxb-dtd-parser, not all listed here
> - Too many dependencies for jaxb-fi, not all listed here
> - Too many dependencies for jaxb-istack-commons, not all listed here
> - Too many dependencies for jaxb-stax-ex, not all listed here
> - Too many dependencies for xmlstreambuffer, not all listed here
>
> They are all part of the dependency tree of antlr4, which is why there
> are so many dependent packages the report can't even list them all
> (I've CC'd jjames, antlr4's maintainer).
>
> I'm not sure if the packages could be dropped from the antlr4
> dependency tree, but them getting removed so late before the F35 final
> freeze introduced all kinds of problems (including FTBFS and FTI
> issues), which now can't be fixed without going through the Freeze
> Exception process, at a time when we're all busy doing other things.
> :(

It looks like antlr4 doesn't depend on jaxb directly, but only
indirectly via jakarta-json.  Let me see if that dependency can be
removed.  Still, it would have been nice to have a heads up about jaxb
disappearing, and doing so right before final freeze is a really
terrible idea, as you note.
-- 
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2009211] perl-Cache-FastMmap-1.57 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2009211

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-4e485e0e06 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-4e485e0e06`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-4e485e0e06

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2009211
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2012147] perl-Scalar-List-Utils-1.60 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012147

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-fb7d7834e9 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-fb7d7834e9`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-fb7d7834e9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012147
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Al Stone]

On 06 Oct 2021 10:17, Justin Forbes wrote:
> On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller  
> wrote:
> >
> > Hi all! I just got back from Open Source Summit, several of the talks I
> > found interesting were on RISC-V -- a high-level one about the
> > organizational structure, and Drew Fustini's more technical talk.
> >
> > In that, he noted that there's a Fedora build *, but it isn't an official
> > Fedora arch. As I understand it, the major infrastructure blocker is simply
> > that there isn't server-class hardware (let alone hardware that will build
> > fast enough that it isn't a frustrating bottleneck).
> >
> > So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances
> > as builders, could we build fast enough under QEMU emulation to work? We
> > have a nice early advantage, but if we don't keep moving, we'll lose that.
> >
> > But beyond that: What other things might be limits? Are there key bits of
> > the distro which don't build yet? Is there a big enough risc-v team to
> > respond to arch-specific build failures? And, do we have enough people to do
> > QA around release time?
> 
> Kernel is still an issue, in that the changes to support RISC-V have
> not been merged yet, though I expect that is not a massive
> undertaking.
> 
> Justin

Not been merged?  Or just not turned on in the config?

-- 
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Al Stone]

On 04 Oct 2021 21:39, Richard W.M. Jones wrote:
> Personally speaking I think the real barrier is someone with a large
> colourful hat putting up the money to hire a full time developer to
> work on the project.
> 
> Rich.

Big ol' +1 to that.

-- 
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-35-20211008.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 1/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20211007.0):

ID: 1020296 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/1020296
ID: 1020310 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/1020310

Old failures (same test failed in Fedora-IoT-35-20211007.0):

ID: 1020317 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1020317

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-35-20211007.0):

ID: 1020302 Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/1020302

Passed openQA tests: 13/16 (x86_64), 14/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.37 to 0.13
Previous test data: https://openqa.fedoraproject.org/tests/1017867#downloads
Current test data: https://openqa.fedoraproject.org/tests/1020295#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

jaxb* packages retired on f35+ (despite still being used)

[Fabio Valentini]

Hi everybody,

I want to draw attention to the fact that the jaxb stack (Jakarta XML
Binding for Java) was recently retired for rawhide and F35 (only hours
before the final freeze went into effect). It looks like edewata did
not do a comprehensive check whether those packages are still depended
on by anything other than his own packages, though.

Since there's not been a successful rawhide compose since the packages
were retired, they now show up in the "orphaned packages" report,
where their dependency trees are listed thusly:

- Too many dependencies for jaxb, not all listed here
- Too many dependencies for jaxb-dtd-parser, not all listed here
- Too many dependencies for jaxb-fi, not all listed here
- Too many dependencies for jaxb-istack-commons, not all listed here
- Too many dependencies for jaxb-stax-ex, not all listed here
- Too many dependencies for xmlstreambuffer, not all listed here

They are all part of the dependency tree of antlr4, which is why there
are so many dependent packages the report can't even list them all
(I've CC'd jjames, antlr4's maintainer).

I'm not sure if the packages could be dropped from the antlr4
dependency tree, but them getting removed so late before the F35 final
freeze introduced all kinds of problems (including FTBFS and FTI
issues), which now can't be fixed without going through the Freeze
Exception process, at a time when we're all busy doing other things.
:(

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2012019] perl-Encode-3.15 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012019

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Encode-3.14 is |perl-Encode-3.15 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 3.15
Current version/release in rawhide: 3.13-481.fc36
URL: http://search.cpan.org/dist/Encode/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2849/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012019
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: why ccache is not available on epel7 ?

[Stephen John Smoogen]

On Fri, 8 Oct 2021 at 11:56, Sérgio Basto  wrote:
>
> On Fri, 2021-10-08 at 10:13 -0400, Stephen John Smoogen wrote:
> > On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
> > >
> > > Hi,
> > >
> > > I see ccache for epel 7 here
> > > https://src.fedoraproject.org/rpms/ccache
> > > , but is not available in repos ... why ?
> > >
> >
> >
> > https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
> > https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm
> >
> > So it is in the repos. I also was able to install it on a fresh
> > CentOS-7 system. Not sure why it is not showing up for you.
> > >
>
> Sorry , I was using  mock -r centos-7-x86_64
>
> is centos-7 that don't have ccache ! epel-7 have it

Ha! No problem. I spent an hour yesterday trying to find out why a set
of builds were failing because I was using `mock -r centos-8-aarch64`
when I meant `mock -r epel-8-aarch64`

>
> Thank you.
>
> > > Thank you,
> > > --
> > > Sérgio M. B.
> > > ___
> > > 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 on the list, report it:
> > > https://pagure.io/fedora-infrastructure
> >
> >
> >
> > --
> > Stephen J Smoogen.
> > I've seen things you people wouldn't believe. Flame wars in
> > sci.astro.orion. I have seen SPAM filters overload because of
> > Godwin's
> > Law. All those moments will be lost in time... like posts on a BBS...
> > time to shutdown -h now.
> > ___
> > 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 on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
> --
> Sérgio M. B.
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: why ccache is not available on epel7 ?

[Sérgio Basto]

On Fri, 2021-10-08 at 10:13 -0400, Stephen John Smoogen wrote:
> On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
> > 
> > Hi,
> > 
> > I see ccache for epel 7 here 
> > https://src.fedoraproject.org/rpms/ccache
> > , but is not available in repos ... why ?
> > 
> 
> 
> https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
> https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm
> 
> So it is in the repos. I also was able to install it on a fresh
> CentOS-7 system. Not sure why it is not showing up for you.
> > 

Sorry , I was using  mock -r centos-7-x86_64

is centos-7 that don't have ccache ! epel-7 have it 

Thank you.

> > Thank you,
> > --
> > Sérgio M. B.
> > ___
> > 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 on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> --
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in
> sci.astro.orion. I have seen SPAM filters overload because of
> Godwin's
> Law. All those moments will be lost in time... like posts on a BBS...
> time to shutdown -h now.
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-35-20211008.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/204 (x86_64), 5/141 (aarch64)

New failures (same test not failed in Fedora-35-20211007.n.0):

ID: 1019542 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/1019542
ID: 1019552 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/1019552
ID: 1019638 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1019638
ID: 1019821 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1019821

Old failures (same test failed in Fedora-35-20211007.n.0):

ID: 1019592 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1019592
ID: 1019605 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/1019605
ID: 1019607 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/1019607
ID: 1019681 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1019681
ID: 1019704 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1019704
ID: 1019810 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1019810

Soft failed openQA tests: 2/204 (x86_64), 2/141 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-35-20211007.n.0):

ID: 1019566 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1019566
ID: 1019620 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1019620
ID: 1019693 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1019693
ID: 1019711 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1019711

Passed openQA tests: 186/204 (x86_64), 134/141 (aarch64)

New passes (same test not passed in Fedora-35-20211007.n.0):

ID: 1019509 Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/1019509
ID: 1019532 Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/1019532
ID: 1019541 Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/1019541
ID: 1019545 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/1019545
ID: 1019549 Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/1019549
ID: 1019555 Test: x86_64 Server-dvd-iso server_database_client
URL: https://openqa.fedoraproject.org/tests/1019555
ID: 1019595 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1019595
ID: 1019634 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1019634
ID: 1019652 Test: aarch64 Server-dvd-iso 
install_blivet_standard_partition_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1019652
ID: 1019658 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/1019658
ID: 1019728 Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/1019728
ID: 1019746 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1019746
ID: 1019770 Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1019770
ID: 1019788 Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1019788
ID: 1019797 Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1019797
ID: 1019809 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1019809
ID: 1019820 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1019820
ID: 1019840 Test: aarch64 universal install_anaconda_text@uefi
URL: https://openqa.fedoraproject.org/tests/1019840
ID: 1019841 Test: aarch64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1019841

Skipped non-gating openQA tests: 11 of 345

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.01 to 0.22
Previous test data: https://openqa.fedoraproject.org/tests/1017528#downloads
Current test data: https://openqa.fedoraproject.org/tests/1019506#downloads

Installed system changes in test x86_64 Workstation-live-iso 

[Bug 2012093] epel8 request: perl-XML-Generator

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012093

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2021-ae314ea116 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-ae314ea116


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012093
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: why ccache is not available on epel7 ?

[Stephen John Smoogen]

On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
>
> Hi,
>
> I see ccache for epel 7 here https://src.fedoraproject.org/rpms/ccache
> , but is not available in repos ... why ?
>


https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm

So it is in the repos. I also was able to install it on a fresh
CentOS-7 system. Not sure why it is not showing up for you.



>
> Thank you,
> --
> Sérgio M. B.
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure



--
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Fu Wei]

Fu Wei  于2021年10月8日周五 上午11:55写道：
>
> Hi All,
>
> Great thanks for your explanation, Zamir.
>
> Zamir SUN  于2021年10月7日周四 下午9:55写道：
> >
> >
> >
> > On 10/5/21 04:39, Richard W.M. Jones wrote:
> > > On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote:
> > >> On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
> > >>> Hi all! I just got back from Open Source Summit, several of the talks I
> > >>> found interesting were on RISC-V -- a high-level one about the
> > >>> organizational structure, and Drew Fustini's more technical talk.
> > >>>
> > >>> In that, he noted that there's a Fedora build *, but it isn't an 
> > >>> official
> > >>> Fedora arch. As I understand it, the major infrastructure blocker is 
> > >>> simply
> > >>> that there isn't server-class hardware (let alone hardware that will 
> > >>> build
> > >>> fast enough that it isn't a frustrating bottleneck).
> > >>
> > >> We have avoided using emulation in the past because we would be chasing
> > >> bugs in our emulation that aren't in real hardware and vice versa.
> > >> How good is the emulation support? Do we know/have people who can fix
> > >> things in it when we hit them? Tools folks: is emulation an option here?
> > >> Or do we still forbid it?
> > >
> > > Qemu support for RISC-V is very good, it's actually used to develop
> > > some features (virtualization and SBI).  We do know people who can fix it.
> > > If you have the money real hardware is also available now.
>
> the early next spring,  we may can have RISC-V laptop. :-), Hardware
> won't be a problem anymore
>
> > >
> > > Personally speaking I think the real barrier is someone with a large
> > > colourful hat putting up the money to hire a full time developer to
> > > work on the project.
> > >
> >
> > I know Wei FU(FAS: tekkamanninja) is actively working on porting Fedora
> > to RISC-V. He has his BSP for D1 which he already put up a wiki[1]. I'm
> > about to help him get LXQt desktop up on D1 soon.
> >
> > In current situation maybe it makes more sense to start thinking about
> > making all RISC-V contributors work together rather than doing
> > everything on each own, which would be much efficient.
> >
> > [1] https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
> >
> > > Rich.
>
> We are NOT ONLY working on D1, but also continually release Fedora
> Image for StarFive Soc, currently JH7100, will focus on JH7110 later.
>
> https://fedora.starfivetech.com/pub/downloads/BeagleV-release/
>
> we have several Koji systems can be used :
> https://koji.oepkgs.net/koji/   (we will start to use it to build all
> the Fedora packages later)
> https://openkoji.iscas.ac.cn/koji  (Our main playground )
> https://fedora.starfivetech.com/koji (StarFive koji system for Fedora on JH 
> Soc)
>
> Our extra REPO for fedora RISC-V:
> https://repo.oepkgs.net/people/extra-repos/rv64-ext-repo/
>
> for now , I am also working upstream opensbi/uboot/linux kernel
> patches for RISC-V
>
>
> > >
> > >>> So, one question is: if we used, say, ARM or x86_64 Amazon cloud 
> > >>> instances
> > >>> as builders, could we build fast enough under QEMU emulation to work? We
> > >>> have a nice early advantage, but if we don't keep moving, we'll lose 
> > >>> that.
>
> yes, that could work, if we have more then 100 builder( 4~9-core ,
> 32GB) on the cloud,
> that would be enough, I think
>
> > >>>
> > >>> But beyond that: What other things might be limits? Are there key bits 
> > >>> of
> > >>> the distro which don't build yet? Is there a big enough risc-v team to
> > >>> respond to arch-specific build failures? And, do we have enough people 
> > >>> to do
> > >>> QA around release time?
>
> QA is a problem. I and my colleagues can work on engineering  side,
> but we also need QE/QA.
>
> > >>
> > >> Well, one big thing is that it's been a while since we had any secondary
> > >> arches and it's unclear how they would work today. In the distant past
> > >> secondary arches had their own koji and builders and composes and
> > >> releases and used koji-shadow to try and match up with primary koji.
> > >> This was basically more than a full time job for someone and I am sure
> > >> koji-shadow has atrophied in recent years, but perhaps at least some
> > >> subset could be made to work again.
> > >>
> > >> On the other hand we could just add it into primary koji, but then it
> > >> really really has to keep up or it's going to block everything else.
> > >>
> > >> So, probibly a 'secondary' koji and builders to start with to bootstrap
> > >> and to gather info on how hard it is to keep up and good emulation is
> > >> would be worthwhile, but it's gonna need some dedicated work.
>
> any other info you need , other than the koji info above
>
> > >>
> > >> Perhaps we could get a up to date status report from folks working on
> > >> this, answering such questions as:
> > >>
> > >> * How good is emulation support
>
> Good enough as builders :-) please check our kojis in China
>
> > >> * What would it 

Fedora 35 compose report: 20211008.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-35-20211007.n.0
NEW: Fedora-35-20211008.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   6
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   105.65 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -32.81 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  abrt-2.14.6-9.fc35
Old package:  abrt-2.14.6-7.fc35
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon 
python3-abrt-container-addon python3-abrt-doc
Size: 6.64 MiB
Size change:  -24.95 KiB
Changelog:
  * Mon Sep 27 2021 Mat??j Grabovsk??  - 2.14.6-8
  - Use lazy import in the Python exception handler to avoid slowdown in Python
startup (rhbz#2007664)

  * Tue Oct 05 2021 Michal Srb  - 2.14.6-9
  - abrt-dbus: Fix SIGSEGV with glib2 >= 2.69.2 (rhbz#1997315)


Package:  glib2-2.70.0-4.fc35
Old package:  glib2-2.70.0-3.fc35
Summary:  A library of handy utility functions
RPMs: glib2 glib2-devel glib2-doc glib2-static glib2-tests
Size: 38.47 MiB
Size change:  -5.67 KiB
Changelog:
  * Tue Oct 05 2021 Miro Hron??ok  2.70.0-4
  - Produce bit-by-bit identical .pyc files across different architectures,
to avoid multilib conflicts


Package:  gnome-software-41.0-3.fc35
Old package:  gnome-software-41.0-2.fc35
Summary:  A software center for GNOME
RPMs: gnome-software gnome-software-devel gnome-software-rpm-ostree
Size: 10.61 MiB
Size change:  2.21 KiB
Changelog:
  * Thu Oct 07 2021 Milan Crha  - 41.0-3
  - Resolves: #2010740 (Refresh on repository setup change)


Package:  kwin-5.22.5-2.fc35
Old package:  kwin-5.22.5-1.fc35
Summary:  KDE Window manager
RPMs: kwin kwin-common kwin-devel kwin-doc kwin-libs kwin-wayland 
kwin-x11
Size: 31.99 MiB
Size change:  -390 B
Changelog:
  * Tue Oct 05 2021 Adam Williamson  - 5.22.5-2
  - Fix cursor offset on wayland in virtual machines (#2011066)


Package:  mu-1.0.3-11.fc35
Old package:  mu-1.0.3-10.fc35
Summary:  A simple Python editor not only for micro:bit
RPMs: mu
Size: 1.25 MiB
Size change:  -118 B
Changelog:
  * Tue Sep 28 2021 Miro Hron??ok  - 1.0.3-11
  - Fix crash on startup on Python 3.10+
  - Fixes: rhbz#2008378


Package:  mutter-41.0-3.fc35
Old package:  mutter-41.0-2.fc35
Summary:  Window and compositing manager based on Clutter
RPMs: mutter mutter-devel mutter-tests
Size: 16.69 MiB
Size change:  -3.90 KiB
Changelog:
  * Tue Oct 05 2021 Adam Williamson  - 41.0-3
  - Backport MR #2040 to fix cursor offset in VMs (#2009304)



= DOWNGRADED 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: why ccache is not available on epel7 ?

[Troy Dawson]

It looks available to me
[root@centos7 yum.repos.d]# yum list ccache
...
Available Packages
ccache.x86_64
3.7.7-1.el7  epel

Possibly you have an exclude on one of your configurations?
Troy

On Fri, Oct 8, 2021 at 6:55 AM Sérgio Basto  wrote:

> Hi,
>
> I see ccache for epel 7 here https://src.fedoraproject.org/rpms/ccache
> , but is not available in repos ... why ?
>
>
> Thank you,
> --
> Sérgio M. B.
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] why ccache is not available on epel7 ?

[Sérgio Basto]

Hi, 

I see ccache for epel 7 here https://src.fedoraproject.org/rpms/ccache
, but is not available in repos ... why ? 


Thank you,
-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 14:11 schrieb Kevin Kofler via devel 
> :
> 
> Mario Torre wrote:
> 
>> On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
>>> And that is actually a problem rather than a solution. Maven artifacts
>>> are basically write once only. Everything depends on a hardcoded version
>>> which, once uploaded, is normally never touched again. This means that
>>> security bugs and other bugs never get fixed (unless the application
>>> bumps the dependency version, which can take months or years or even just
>>> never happen). That is exactly what the RPM system is designed to avoid.
>> 
>> Well, that's why it should be "curated" and not just a mirror of maven
>> central.
> 
> No amount of "curating" can fix this inherent design limitation of Maven.

Maven may have a lot of design limitations, but this scenario is none of them. 
No build system can completely compensate a careless developer or system 
administrator.

And what is the alternative? If we don't find a way to make building Java 
application rpm easier, there will be no Fedora rpm for many applications at 
all. And then, what happens? The sysadmin installs a binary from some source. 
And then happens exactly what you fear: The program runs forever and  
>  that opens all sorts of cans of worms (caching, reproducibility, 
> changed checksums, etc.).


Peter

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Sérgio Basto]

On Wed, 2021-10-06 at 14:37 +0200, Mikolaj Izdebski wrote:
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller <
> mat...@fedoraproject.org> wrote:
> > 
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a
> > > matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> > 
> > I'd love to see someone interested in this pursue this idea! I know
> > we
> > talked about it as long ago as... Flock Prague... and probably
> > before.
> 
> That's a very old idea that has been partially implemented years ago,
> but never approved for use in Fedora. Maven artifacts can be built in
> Koji (there is an existing "koji maven-build" command). Once built
> they appear in a "curated" Maven repository hosted on Koji, that can
> be synced to mirrors, from where users can consume it. Consumers of
> this Maven repository don't need to be running Fedora, not even Linux.

ah Now I understand better this wiki page 
https://fedoraproject.org/wiki/KojiMavenSupport


> Curated Maven repository contains additional metadata, eg. CVEs
> affecting given artifact version, whether upstream is active, whether
> given artifact is available in Fedora and in which releases, etc. For
> each Fedora Linux release there is an auto-generated BOM (bill of
> materials POM) listing artifacts available in the release.
> 
> Binaries from this trusted/curated Maven repository can also be
> wrapped into RPMs (using "koji wrapper-rpm" command) and put into
> distribution repos and composes. Other packages can depend on such
> RPMs. This is a hybrid packaging model, where some Java RPM packages
> can be built in the traditional way (where code is compiled during
> rpmbuild) and some are built elsewhere, and only wrapped in RPMs.
> 
> --
> Mikolaj Izdebski
> 
> > 
> > --
> > Matthew Miller
> > 
> > Fedora Project Leader
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 14:08 schrieb Kevin Kofler via devel 
> :
> 
> Peter Boy wrote:
>> A valid point, but only in case the app that consumes the maven artefact
>> in unmaintained.
> 
> Many applications are maintained and never (or very rarely, only when they 
> encounter some issue with the version they currently use) bother bumping 
> their dependencies after adding them once. Especially in the corporate 
> world, this is commonplace.

Yes, unfortunately in case of security issues. But those people wouldn’t be 
amused either if you silently exchanged a lib/jar.

As a Fedora rpm, the app will get rebuild about every 6 months. The „curated 
list“ as proposed/implemented by Mikolaj keeps track of upstream maintenance 
and security issues (at least it is constructed to be able to do as he 
described). So we can make a rebuild fail if it uses a security tainted version 
instead of a newer one. 

That would be quite a broad hint. If someone ignores that, the problem is not 
one of jar vs. rpm. 



>>> I think this would be not only a huge
>>> waste of space
>> 
>> given the current size of hard drive space, this really isn't a problem.
>> You won't be able to install a meaningful collection of apps whose
>> cumulative footprint of jars installed in parallel leaves any noticeable
>> trace on a x tb disk.
> 
> Considering that Fedora now also targets devices with as little as 16 or 32 
> GB out-of-the-box storage:
> 
> https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
> https://wiki.pine64.org/index.php/PinePhone#Specifications
> 
> that argument is invalid.

Boxes with these storage limitation have usually other limitations as well and 
are not a device to install a huge bunch of software. But even with 16g GB 
storage, what is a typical size of jars? E.g. the set of log4j jars need about 
2mb. You need a lot of jars installed redundantly to flood 16 gb of storage. 

In theory you are right, but practically this will not be a problem in the vast 
majority of cases.  

And in any case, it is better to have applications as rpm for a large number of 
typical usage scenarios than no rpm version at all for anyone. 

All that under the assumption that said „curated list workflow“  will make it 
easier to build a Java application rpm. 





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2012147] perl-Scalar-List-Utils-1.60 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012147

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-fb7d7834e9 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-fb7d7834e9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012147
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2012147] perl-Scalar-List-Utils-1.60 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012147



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Scalar-List-Utils-1.60-1.fc34.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=76915018


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012147
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2012147] perl-Scalar-List-Utils-1.60 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012147



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1830805
  --> https://bugzilla.redhat.com/attachment.cgi?id=1830805=edit
[patch] Update to 1.60 (#2012147)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012147
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2012147] New: perl-Scalar-List-Utils-1.60 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012147

Bug ID: 2012147
   Summary: perl-Scalar-List-Utils-1.60 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Scalar-List-Utils
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jpazdzi...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.60
Current version/release in rawhide: 1.59-461.fc36
URL: http://search.cpan.org/dist/Scalar-List-Utils/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/6483/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012147
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler via devel]

Mario Torre wrote:

> On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel wrote:
>> And that is actually a problem rather than a solution. Maven artifacts
>> are basically write once only. Everything depends on a hardcoded version
>> which, once uploaded, is normally never touched again. This means that
>> security bugs and other bugs never get fixed (unless the application
>> bumps the dependency version, which can take months or years or even just
>> never happen). That is exactly what the RPM system is designed to avoid.
> 
> Well, that's why it should be "curated" and not just a mirror of maven
> central.

No amount of "curating" can fix this inherent design limitation of Maven. 
You cannot just replace foo-1.2.3 with a different version with security 
fixes, that opens all sorts of cans of worms (caching, reproducibility, 
changed checksums, etc.). So you need to upload something like foo-1.2.3.1 
and then bump the dependency in every single application. How is that any 
easier than just building against the latest foo to begin with?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Kevin Kofler via devel]

Peter Boy wrote:
> A valid point, but only in case the app that consumes the maven artefact
> in unmaintained.

Many applications are maintained and never (or very rarely, only when they 
encounter some issue with the version they currently use) bother bumping 
their dependencies after adding them once. Especially in the corporate 
world, this is commonplace.

I wrote:
>> So you propose to bundle a whole bunch of JARs, some of which have been
>> built many Fedora releases ago and might not even be buildable in any
>> currently supported Fedora anymore?

and Peter Boy replied: 
> No! See above.

Yet, that is exactly what "Once a JAR is built, the resulting bytecode will
work with current and future JVMs. There is no need to mass-rebuild JARs
every 6 months." (Michal Srb) implies.

>> I think this would be not only a huge
>> waste of space
> 
> given the current size of hard drive space, this really isn't a problem.
> You won't be able to install a meaningful collection of apps whose
> cumulative footprint of jars installed in parallel leaves any noticeable
> trace on a x tb disk.

Considering that Fedora now also targets devices with as little as 16 or 32 
GB out-of-the-box storage:

https://fedoraproject.org/wiki/Architectures/ARM/PinePhone
https://wiki.pine64.org/index.php/PinePhone#Specifications

that argument is invalid.

> But you gain a lot in security if as many of these
> apps as possible are managed as rpm.

Sure, a bunch of JARs in an RPM is marginally better than a bunch of JARs in 
a tarball. But it is no replacement for real packaging with unbundling.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2009211] perl-Cache-FastMmap-1.57 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2009211

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-4e485e0e06 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-4e485e0e06


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2009211
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2012093] epel8 request: perl-XML-Generator

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012093

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|jples...@redhat.com,|
   |mspa...@redhat.com  |
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/37202


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012093
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Announcing LLVM Snapshot Packages for Fedora Linux

[Konrad Kleine]

Dear Fedora packagers, developers and users,

we have some good news for you:

We are beginning to build nightly snapshot packages of LLVM for the latest
versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list
of
architectures.

You can grab them here:

https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/

Feel free to enable the copr repository with

$ dnf copr enable @fedora-llvm-team/llvm-snapshots

and then install the i.e. latest clang with

$ dnf install clang

Beware, that a snapshot release of LLVM is probably more unstable than a
regular release! If you run into a problem, I would kindly ask you to wait
and try it again with the next snapshot.

We hope you enjoy this peek into the next version of LLVM that you can now
try without too much hassle and without compiling it every day on your own.

Regards,

Konrad Kleine

Senior Software Engineer, Platform Tools

Red Hat 

kkle...@redhat.com
M: +49(0)151/21000244

D87A 77F4 2A58 C72D 12A7 203B C0A0 2C32 BCB7 3099

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

Fedora-Cloud-34-20211008.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20211007.0):

ID: 1019427 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1019427
ID: 1019435 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1019435

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Fri, Oct 8, 2021 at 2:11 AM Kevin Kofler via devel
 wrote:
>
> Michal Srb wrote:
> > Unlike RPM repositories, Maven repositories can easily hold multiple
> > versions of libraries. Once a JAR is built, the resulting bytecode will
> > work with current and future JVMs. There is no need to mass-rebuild JARs
> > every 6 months. And there is certainly no need to try to run every single
> > Java application with a single "system-wide" version of a library.
>
> And that is actually a problem rather than a solution. Maven artifacts are
> basically write once only. Everything depends on a hardcoded version which,
> once uploaded, is normally never touched again. This means that security
> bugs and other bugs never get fixed (unless the application bumps the
> dependency version, which can take months or years or even just never
> happen). That is exactly what the RPM system is designed to avoid.

Well, that's why it should be "curated" and not just a mirror of maven central.

Cheers,
Mario

-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Wed, Oct 6, 2021 at 2:39 PM Mikolaj Izdebski  wrote:
>
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  
> wrote:
> >
> > On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
> > > I'm not sure what's the best solution, but I guess the number one
> > > reason to have packages within the Fedora distribution is for a matter
> > > of trust, if this is the case I would argue that a curated list of
> > > maven packages served via a Fedora managed repository would be a
> > > better investment.
> >
> > I'd love to see someone interested in this pursue this idea! I know we
> > talked about it as long ago as... Flock Prague... and probably before.
>
> That's a very old idea that has been partially implemented years ago,
> but never approved for use in Fedora. Maven artifacts can be built in
> Koji (there is an existing "koji maven-build" command). Once built
> they appear in a "curated" Maven repository hosted on Koji, that can
> be synced to mirrors, from where users can consume it. Consumers of
> this Maven repository don't need to be running Fedora, not even Linux.
>
> Curated Maven repository contains additional metadata, eg. CVEs
> affecting given artifact version, whether upstream is active, whether
> given artifact is available in Fedora and in which releases, etc. For
> each Fedora Linux release there is an auto-generated BOM (bill of
> materials POM) listing artifacts available in the release.
>
> Binaries from this trusted/curated Maven repository can also be
> wrapped into RPMs (using "koji wrapper-rpm" command) and put into
> distribution repos and composes. Other packages can depend on such
> RPMs. This is a hybrid packaging model, where some Java RPM packages
> can be built in the traditional way (where code is compiled during
> rpmbuild) and some are built elsewhere, and only wrapped in RPMs.

So the only thing left to do is to convince Mr. Fedora to approve this ;)

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Mario Torre]

On Tue, Oct 5, 2021 at 10:20 PM Peter Boy  wrote:
>
>
>
> > Am 04.10.2021 um 21:08 schrieb Fabio Valentini :
> >
> >
> > But then you're back to *exactly how Fedora packages for Java projects
> > already work* - only with the added complication that distributing
> > those build artifacts as plain JARs instead of RPMs now makes them
> > impossible to consume as dependencies from other RPM builds.
>
> I think, the key is "via a Fedora managed repository“, something like a 
> fedora.maven.central. That could make the process easier.
>
> Somewhere I had read on "federated repository“ as a specific narrow 
> defined cooperation with distributions or projects with similar principles as 
> Fedora.

Yes, also distributing jars via maven is a lot simpler than having to
package them (even if just wrapped) as RPM, so there's a lot of saving
just by that.

Those jars could be rebuilt from source, including their transitive
deps, or just a mirror of maven central if we trust the upstream (and
in many cases we do, i.e. for things coming from Eclipse.org or
Apache).

The infrastructure, I can't hardly think of this as an additional
burden, we have already hosted and built every single distribution
since the beginning of time, including those same jars in an RPM form.

Cheers,
Mario
-- 
Mario Torre
Manager, Software Engineering, core OpenJDK
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2012093] New: epel8 request: perl-XML-Generator

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2012093

Bug ID: 2012093
   Summary: epel8 request: perl-XML-Generator
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-XML-Generator
  Assignee: jples...@redhat.com
  Reporter: jakub.jedel...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hello,

could you, please, push perl-XML-Generator to epel8?


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2012093
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 06.10.2021 um 14:37 schrieb Mikolaj Izdebski :
> 
> On Mon, Oct 4, 2021 at 8:50 PM Matthew Miller  
> wrote:
>> 
>> On Mon, Sep 27, 2021 at 03:09:08PM +0200, Mario Torre wrote:
>>> I'm not sure what's the best solution, but I guess the number one
>>> reason to have packages within the Fedora distribution is for a matter
>>> of trust, if this is the case I would argue that a curated list of
>>> maven packages served via a Fedora managed repository would be a
>>> better investment.
>> 
>> I'd love to see someone interested in this pursue this idea! I know we
>> talked about it as long ago as... Flock Prague... and probably before.
> 
> That's a very old idea that has been partially implemented years ago,

That (and the following description) sounds great at first. 

> but never approved for use in Fedora.

Was the process not initiated or were there serious concerns? 

What would you recommend to do with it, discard, pursue, evaluate? 


Thanks
Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Maven? [was: Re: Fedora ? Java: The Death of Two SIGs]

[Peter Boy]

> Am 08.10.2021 um 02:06 schrieb Kevin Kofler via devel 
> :
> 
> Michal Srb wrote:
>> Unlike RPM repositories, Maven repositories can easily hold multiple
>> versions of libraries. ...
> 
> And that is actually a problem rather than a solution. Maven artifacts are 
> basically write once only. Everything depends on a hardcoded version which, 
> once uploaded, is normally never touched again. This means that security 
> bugs and other bugs never get fixed ...

A valid point, but only in case the app that consumes the maven artefact in 
unmaintained. 

The goal of the "curated list“ is to make building an "app-rpm" less burdensome 
and provide for more apps as rpm this way. And the updated „app-rpm“ would use 
an updated version of that jar. And that app would be part of the usual rpm 
update procedure.  



>> Fedora could ship just Java applications that would bundle JARs (whatever
>> version they need) from the Fedora Maven repository. I don't see this as a
>> problem, as long as it would be possible to track what JARs are bundled in
>> what application.
> 
> So you propose to bundle a whole bunch of JARs, some of which have been 
> built many Fedora releases ago and might not even be buildable in any 
> currently supported Fedora anymore?

No! See above.


> I think this would be not only a huge 
> waste of space

given the current size of hard drive space, this really isn't a problem. You 
won't be able to install a meaningful collection of apps whose cumulative 
footprint of jars installed in parallel leaves any noticeable trace on a x tb 
disk. But you gain a lot in security if as many of these apps as possible are 
managed as rpm.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20211008.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20211007.0):

ID: 1019330 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1019330
ID: 1019338 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1019338

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F34 Cloud Amazon AMIs unbootable after updates

[Christopher]

On Thu, Oct 7, 2021 at 5:48 PM Benjamin Herrenschmidt
 wrote:
>
> On Wed, 2021-10-06 at 15:41 -0500, Joe Doss wrote:
> >
> > > Does anybody know how to fix a currently broken instance and can
> > > share
> > > their solution?
> >
> > Is there anything on the console log when you reboot it after the
> > updates? If you can share the log that would be helpful.

I've seen two kinds of errors in the console log.

The first is the kernel panic in the screenshot in my earlier email.
Getting a larger console log dump in that case, when it works at all,
just gets more of the same. I think I can avoid that error by avoiding
certain instance types. m5 seems to work, but m5a and m6 do not. I
think this might be related to the new UEFI boot type that EC2 now
supports. On newer instance types, they default to UEFI mode unless
legacy-bios is specified. Our AMIs do not specify a boot type, so they
would use the instance type's default. m5 defaults to legacy-bios
mode, and seems to work. I think m5a and m6 default to UEFI mode. We
should start specifying our boot mode explicitly in our AMI composes
(and eventually switch to UEFI mode, for a consistent experience in
the cloud that matches modern physical hardware that uses UEFI). In
any case, I could be incorrect, but since this is a boot problem, it
seems possible the boot mode feature is the problem in those instance
types.

The second error is just an infinite scroll of a repeated error
message that looked like: A start job is running for
/dev/dis…f1a0b12a  This is most likely
https://bugzilla.redhat.com/show_bug.cgi?id=2010058 and manually
applying the patch there seems to work (even though I wasn't sure if I
did it correctly).

>
> There's the new "ISC" (interactive serial console) that can help if you
> have grub timeout set to non-0...

I couldn't get that to work over ssh, but it did work on the web UI.
It wasn't very useful there, because the boot was stuck and wasn't
accepting input. I couldn't catch it early enough for grub. I'm not
quite certain of how to edit the grub2 config files to change the
timeout. This would have helped me select the previous kernel, to
avoid https://bugzilla.redhat.com/show_bug.cgi?id=2010058 , but it
wouldn't have helped with the kernel panic on m5a/m6 instance types.

>
> Otherwise, you can detach the EBS volume, attach it to another
> instance, mount & fixup, then back the other way around (the magic to
> re-attach the root device is to call it "xvda" without number).

That's what I ended up doing (but I always re-attach as /dev/sda1, how
it was before). I've done this plenty of times before. The main
problem this time was that there were no logs to investigate, and no
clues what to change to fix the issue.

I did attempt to chroot and do a DNF rollback. However, it seems DNF
history command is buggy, and crashes with a message called "Reason
Change". This appears to be a new thing in DNF transactions, and the
DNF history command doesn't know how to handle it for rollbacks and
undos. I used more primitive tools to change packages one at a time,
eventually reinstalling the kernel after applying the fix in
https://bugzilla.redhat.com/show_bug.cgi?id=2010058


>
> Cheers,
> Ben.

Thanks all for the tips and suggestions. Persistence paid off... eventually.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [RFC] Remove supoort for NIS(+) from PAM

[Alexander Bokovoy]

On pe, 01 loka 2021, Neal Gompa wrote:

On Fri, Oct 1, 2021 at 12:41 PM Frank Ch. Eigler  wrote:


Stephen John Smoogen  writes:

>> > The places I have seen it still being used are in Universities run by
>> > people who learned sysadmin in the 1990's and early 2000's. It is a
>> > light weight system which is simple to set up [...]
>>
>> For those people who like simple to set up and working systems but are
>> willing to consider upgrading if it's also simple and will keep working,
>> is there a NIS->$whatever migration document in fedora someplace?
>
> I don't think anyone has come up with an agreed upon $whatever that a
> majority of people like. There is LDAP but that isn't light. There are
> kerberos but that isn't easy.

"light" in terms of CPU/network, who cares.  "light" in terms of
simplicity and maintenance, you have my attention.  If there is no such
gadget available, then please let's keep NIS around.


> And honestly the cool kids only want web logins these days as servers
> are a pain and why not just login into Google/Facebook/Microsoft and
> let them deal with all that setup.

(OK but seriously that's not a fedora matter.  Well, or rather, I'd love
to have a passwd/nss backed openid gadget.  Is that ipsilon?)



We're currently missing a way to do OpenID or OIDC based login in
Linux like what Windows and macOS has. Ipsilon would be the
server-side aspect of it, we don't have any client-side integration
(sssd, gdm/sddm, etc.)


We are working on that part for SSSD and FreeIPA. Not production ready
yet but aim to have something testable later this year. In a prototype
we have it is possible to authenticate against a thing like Github or
Keycloak.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Retired Packages (Self-Contained Change proposal)

[Miroslav Suchý]

Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a):

When are you supposed to run remove-retired-packages?

After the upgrade.


If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? 



Nothing is broken **now**. But it very often broke N+1 or N+2 upgrade. I remember some package broken N+5 upgrade. And 
then you (or some co-maintainer) hesitated to add it to fedora-obsolete-packages because "it is too old". :)


Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [RFC] Remove supoort for NIS(+) from PAM

[Alexander Bokovoy]

On la, 02 loka 2021, James Szinger wrote:

On Sat, 2 Oct 2021 08:42:02 -0400
Demi Marie Obenour  wrote:


How many of these can be solved by tunneling everything in a WireGuard
mesh network, and using nftables rules to prevent spoofing?


Sounds harder than setting up NIS+, which was supposed to solve many
of these issues 30 years ago, but still has not displaced NIS.  Even
if one can secure NIS on the network, that still leaves the issue of
`ypcat passwd`.

These days, I think FreeIPA or Active Directory are the best choices,
but both are complicated and possibly too much for a SO/HO, workgroup,
or departmental sysadmin.  AD has the advantage of supporting Windows,
MacOS, and Samba; the last time I looked FreeIPA was not good at this.


FreeIPA has integration with Samba (to run Samba file server on IPA
clients) for quite some time, around two years now. You need to run
'ipa-client-samba' tool on IPA client to set it up, that's all. This
will make Kerberos authentication work against smbd and partially
password authentication too.

See man page for ipa-client-samba(1) for more details and
https://freeipa.readthedocs.io/en/latest/designs/adtrust/samba-domain-member.html
for even more technical details.

Samba upstream is planning to eventually remove support for a standalone
domain controller without Kerberos (e.g. not Samba AD or IPA DC). Given
that NTLM authentication will eventually be disabled everywhere, until
we get something better for a standalone use case, Kerberos is there to
handle such cases. Both Samba AD and FreeIPA in Fedora are good to cover
them.

Critique of complexity of a general 'domain controller' setup is
warrant, of course. It is something that FreeIPA really tries to
address and for simple use cases we are almost there if you are using an
integrated approach where FreeIPA runs and configures all the pieces it
needs (DNS, CA, ...). At least a basic understanding of DNS and Kerberos
is still preferrable, of course. We need to improve in this area in
Fedora Server documentation...

NIS+ as a tooling for such configurations is even less secure than
relying on NTLM in SMB protocol.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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