date:20211121

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



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025236
___
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 2025236] perl-Module-CoreList-5.20211120 is available

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025236
___
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 2025236] perl-Module-CoreList-5.20211120 is available

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025236
___
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 2025236] perl-Module-CoreList-5.20211120 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC|jose.p.oliveira.oss@gmail.c |
   |om, jples...@redhat.com,|
   |mspa...@redhat.com, |
   |spo...@gmail.com|
   Fixed In Version||perl-Module-CoreList-5.2021
   ||1120-1.fc36
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025236
___
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: Strange s390x/x86_64 build failures

2021-11-21 Thread Vitaly Zaitsev via devel


On 22/11/2021 03:51, Orion Poplawski wrote:

i686:
virtual memory exhausted: Operation not permitted


Memory limit of the 32-bit address space (2 GB) has been reached. Try 
reducing the debuginfo level.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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

Fedora-Cloud-33-20211122.0 compose check report

2021-11-21 Thread 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-2028.0):

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

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

[Bug 2025106] perl-PDL-2.063 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|caillon+fedoraproject@gmail |
   |.com,   |
   |jakub.jedel...@gmail.com,   |
   |jples...@redhat.com,|
   |ka...@ucw.cz,   |
   |lkund...@v3.sk, |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@redhat.com,|
   |tjczep...@gmail.com |
   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025106
___
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: Trying to take an orphaned package

2021-11-21 Thread Tom Hughes via devel


On 21/11/2021 13:11, Stephen Snow wrote:


And I login with my FAS ID and cannot "Take" the package since I am not
a packager.

So I ask again what steps am I missing here? I want to take over
packaging something that is about to be removed from Fedora Linux since
it has been orphaned, I have signed the agreements, I have asked to
become a packager, and this is actually the second package I am trying
to take over.


You say you have "asked to become a packager" but what exactly
do you mean by that?

The official documentation on becoming a packager is here:

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

But actually I think the old wiki version is much more useful
in explaining how things work, especially if you're not coming
at it from the position of submitting a new package:

https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444

Basically you need to find somebody to sponsor you as a
packager - normally that happens as part of having your first
package review but obviously that doesn't work when you want
to take over an existing package.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Trying to take an orphaned package

2021-11-21 Thread Tom Hughes via devel


On 21/11/2021 15:01, Stephen Snow wrote:


But actually I think the old wiki version is much more useful
in explaining how things work, especially if you're not coming
at it from the position of submitting a new package:


And it tells me to read a document that doesn't apparently exist
anymore.


That's why I gave a link to the old version from the wiki history
before it was replaced by a pointer to the new page.


https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444

Basically you need to find somebody to sponsor you as a
packager - normally that happens as part of having your first
package review but obviously that doesn't work when you want
to take over an existing package.


So you see what I was talking about so many (years?!?!) ago, then
recently too on this list. It is a common thing it seems that once a
person steps up to ask for sponsorship something seems to happen. I am
struck by the first line of your response "You say you have "asked to
become a packager" but what exactly do you mean by that?" Well, quite
simply what I stated, but yet I am being questioned about my sincereity
and credibility immediately.


I wasn't questioning your credibility, I was just confused because
there's no formal place to lodge such a request as far as I know other
than a review ticket blocking FE-SPONSOR which doesn't apply here.

I was worried that you had filed some sort of request somewhere
that nobody was looking.


So back to what I was trying to say in my conversation here about some
tool for assessing the prospective newbies like me who want to help but
need a sponsor, I was thinking of an app that tests your knowledge and
the discussion went towards a generic test package to show packaging
knowledge with, then make sponsoring come easier for sponsors. Because
this seems to be really the crux of the matter, trust or lack of it.


I'm not aware of any previous discussions. I was just answering
the questions you asked in your post today.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Strange s390x/x86_64 build failures

2021-11-21 Thread Luya Tshimbalanga



On 2021-11-21 18:51, Orion Poplawski wrote:

On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:
Just noting that I had a strange one-time s390x and x86_64 build 
failure.


More:

s390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231

libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
/usr/bin/ranlib: unable to copy file 
'liboctave/array/.libs/libarray.a'; reason: Input/output error

make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1

i686:

virtual memory exhausted: Operation not permitted

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237

(okay, this is probably your typical out of memory build issue)

I also hit similar issue with arm architecture with scratch build result 
of OpenVDB:


https://koji.fedoraproject.org/koji/taskinfo?taskID=79142031

---

cd /builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb && 
/usr/bin/g++ -DOPENVDB_PRIVATE -DOPENVDB_STATICLIB 
-I/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/.. 
-I/builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb 
-I/builddir/build/BUILD/openvdb-9.0.0/redhat-linux-build/openvdb/openvdb/openvdb 
-I/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/. -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong   
-march=armv7-a -mfpu=vfpv3-d16 -mtune=generic-armv7-a -mabi=aapcs-linux 
-mfloat-abi=hard -Wl,--as-needed -DNDEBUG -std=c++14 -MD -MT 
openvdb/openvdb/CMakeFiles/openvdb_static.dir/io/Archive.cc.o -MF 
CMakeFiles/openvdb_static.dir/io/Archive.cc.o.d -o 
CMakeFiles/openvdb_static.dir/io/Archive.cc.o -c 
/builddir/build/BUILD/openvdb-9.0.0/openvdb/openvdb/io/Archive.cc
virtual memory exhausted: Operation not permitted
gmake[2]: *** [openvdb/openvdb/CMakeFiles/openvdb_static.dir/build.make:625: 
openvdb/openvdb/CMakeFiles/openvdb_static.dir/instantiations/GridOperators.cc.o]
 Error 1
---

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Strange s390x/x86_64 build failures

2021-11-21 Thread Orion Poplawski


On 11/21/21 19:23, devel@lists.fedoraproject.org wrote:

Just noting that I had a strange one-time s390x and x86_64 build failure.


More:

s390x:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143231

libtool: link: /usr/bin/gcc-ranlib liboctave/array/.libs/libarray.a
/usr/bin/ranlib: unable to copy file 'liboctave/array/.libs/libarray.a'; 
reason: Input/output error

make[2]: *** [Makefile:13394: liboctave/array/libarray.la] Error 1

i686:

virtual memory exhausted: Operation not permitted

https://koji.fedoraproject.org/koji/taskinfo?taskID=79143237

(okay, this is probably your typical out of memory build issue)


--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


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

Strange s390x/x86_64 build failures

2021-11-21 Thread Orion Poplawski


Just noting that I had a strange one-time s390x and x86_64 build failure.

s390x:

/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=zEC12 -mtune=z13 
-fasynchronous-unwind-tables -fstack-clash-protection -DH5_USE_110_API 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -shared 
-Wl,-soname,libField3D.so.1.7 -o libField3D.so.1.7.3 
CMakeFiles/Field3D.dir/src/ClassFactory.cpp.o 
CMakeFiles/Field3D.dir/src/DenseFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/Field3DFile.cpp.o 
CMakeFiles/Field3D.dir/src/Field3DFileHDF5.cpp.o 
CMakeFiles/Field3D.dir/src/FieldCache.cpp.o 
CMakeFiles/Field3D.dir/src/Field.cpp.o 
CMakeFiles/Field3D.dir/src/FieldInterp.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMapping.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMappingIO.cpp.o 
CMakeFiles/Field3D.dir/src/FieldMetadata.cpp.o 
CMakeFiles/Field3D.dir/src/FileSequence.cpp.o 
CMakeFiles/Field3D.dir/src/Hdf5Util.cpp.o 
CMakeFiles/Field3D.dir/src/IArchive.cpp.o 
CMakeFiles/Field3D.dir/src/IData.cpp.o 
CMakeFiles/Field3D.dir/src/IGroup.cpp.o 
CMakeFiles/Field3D.dir/src/InitIO.cpp.o 
CMakeFiles/Field3D.dir/src/IStreams.cpp.o 
CMakeFiles/Field3D.dir/src/Log.cpp.o 
CMakeFiles/Field3D.dir/src/MACFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/MIPFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/MIPUtil.cpp.o 
CMakeFiles/Field3D.dir/src/OArchive.cpp.o 
CMakeFiles/Field3D.dir/src/OData.cpp.o 
CMakeFiles/Field3D.dir/src/OgIGroup.cpp.o 
CMakeFiles/Field3D.dir/src/OGroup.cpp.o 
CMakeFiles/Field3D.dir/src/OgUtil.cpp.o 
CMakeFiles/Field3D.dir/src/OStream.cpp.o 
CMakeFiles/Field3D.dir/src/PatternMatch.cpp.o 
CMakeFiles/Field3D.dir/src/PluginLoader.cpp.o 
CMakeFiles/Field3D.dir/src/ProceduralField.cpp.o 
CMakeFiles/Field3D.dir/src/Resample.cpp.o 
CMakeFiles/Field3D.dir/src/SparseFieldIO.cpp.o 
CMakeFiles/Field3D.dir/src/SparseFile.cpp.o  -lhdf5 
/usr/lib64/libOpenEXR-3_1.so.30.3.0 /usr/lib64/libImath-3_1.so.29.2.0 
-lpthread -ldl -lz -lboost_regex -lboost_thread -lboost_program_options 
-lboost_system -lboost_chrono -lboost_date_time -lboost_atomic -lm 
/usr/lib64/libIlmThread-3_1.so.30.3.0 /usr/lib64/libIex-3_1.so.30.3.0 
/usr/lib64/libz.so
/usr/lib/gcc/s390x-redhat-linux/11/../../../../lib64/libhdf5.so: file 
not recognized: file format not recognized

collect2: error: ld returned 1 exit status

https://koji.fedoraproject.org/koji/taskinfo?taskID=79141528

a rebuild worked fine.

Also this on x86_64:

cd /builddir/build/BUILD/alembic-1.8.3/redhat-linux-build/lib/Alembic && 
/usr/bin/g++ -DALEMBIC_EXPORTS -DPLATFORM=LINUX -DPLATFORM_LINUX 
-I/builddir/build/BUILD/alembic-1.8.3/lib 
-I/builddir/build/BUILD/alembic-1.8.3/redhat-linux-build/lib -isystem 
/usr/include/Imath -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-Wl,--as-needed -fvisibility=hidden -DH5_USE_18_API -fPIC   -fPIC -MD 
-MT lib/Alembic/CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o -MF 
CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o.d -o 
CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o -c 
/builddir/build/BUILD/alembic-1.8.3/lib/Alembic/Abc/OScalarProperty.cpp
*** WARNING *** there are active plugins, do not report this as a bug 
unless you can reproduce it without enabling any plugins.

Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function 
annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end 
symbols

during IPA pass: modref
/builddir/build/BUILD/alembic-1.8.3/lib/Alembic/Abc/OScalarProperty.cpp:181:1: 
internal compiler error: Section already exists: 
'.gnu.lto__ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_S5_ESt10_Select1stIS8_ESt4lessIS5_ESaIS8_EE12_M_drop_nodeEPSt13_Rb_tree_nodeIS8_E.9135.b09fa84751fd815e'

  181 | } // End namespace Alembic
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
gmake[2]: *** [lib/Alembic/CMakeFiles/Alembic.dir/build.make:1171: 
lib/Alembic/CMakeFiles/Alembic.dir/Abc/OScalarProperty.cpp.o] Error 1


https://koji.fedoraproject.org/koji/taskinfo?taskID=79141572

a rebuild worked fine.

Are we having any issues with the builders?

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane

[Bug 2022402] Please branch and build an epel8 for perl-Net-Telnet

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Net-Telnet-3.05-3.el8
 Resolution|--- |ERRATA
Last Closed||2021-11-22 01:37:17



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2021-8777402966 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2022402
___
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: jpegxl soname bump

2021-11-21 Thread Björn 'besser82' Esser

Am Sonntag, dem 21.11.2021 um 15:40 -0500 schrieb Scott Talbert:
> Hi @eclipseo,
> 
> Looks like jpegxl soname was bumped, breaking a bunch of stuff:
> 
> 2021-11-21 20:20:51
> Package resolution failed
> 
>  Problem: package gd-2.3.3-3.fc36.x86_64 requires 
> libavif.so.12()(64bit), but none of the providers can be installed
>  - package graphviz-2.49.3-2.fc36.x86_64 requires
> libgd.so.3()(64bit), 
> but none of the providers can be installed
>  - package libavif-0.9.2-2.fc35.x86_64 requires
> libaom.so.3()(64bit), 
> but none of the providers can be installed
>  - conflicting requests
>  - nothing provides libjxl.so.0()(64bit) needed by 
> libaom-3.1.2-1.fc35.x86_64
>  - nothing provides libjxl.so.0(JXL_0)(64bit) needed by 
> libaom-3.1.2-1.fc35.x86_64
>  Problem: package graphviz-2.49.3-2.fc36.x86_64 requires 
> libgd.so.3()(64bit), but none of the providers can be installed
>  - package gd-2.3.3-3.fc36.x86_64 requires libavif.so.12()(64bit),
> but 
> none of the providers can be installed
>  - package doxygen-2:1.9.1-12.fc36.x86_64 requires graphviz, but
> none 
> of the providers can be installed
>  - package libavif-0.9.2-2.fc35.x86_64 requires
> libaom.so.3()(64bit), 
> but none of the providers can be installed
>  - conflicting requests
>  - nothing provides libjxl.so.0()(64bit) needed by 
> libaom-3.1.2-1.fc35.x86_64
>  - nothing provides libjxl.so.0(JXL_0)(64bit) needed by 
> libaom-3.1.2-1.fc35.x86_64


libaom is not rebuildable, as it requires the doxygen package for being
built.  I've requested the new jpegxl build to be untagged from Rawhide
[1], and expired the buildroot-overrides for F35 and F34.

This needs proper preparation and coordination for the rebuilds.  I will
take of that in a side-tag as soon as Rawhide is back to a usable state.

Björn


[1]  https://pagure.io/releng/issue/10397


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: jpegxl soname bump

2021-11-21 Thread Ahmed Almeleh

yikes

On Sun, 21 Nov 2021, 20:40 Scott Talbert,  wrote:

> Hi @eclipseo,
>
> Looks like jpegxl soname was bumped, breaking a bunch of stuff:
>
> 2021-11-21 20:20:51
> Package resolution failed
>
>  Problem: package gd-2.3.3-3.fc36.x86_64 requires
> libavif.so.12()(64bit), but none of the providers can be installed
>  - package graphviz-2.49.3-2.fc36.x86_64 requires libgd.so.3()(64bit),
> but none of the providers can be installed
>  - package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit),
> but none of the providers can be installed
>  - conflicting requests
>  - nothing provides libjxl.so.0()(64bit) needed by
> libaom-3.1.2-1.fc35.x86_64
>  - nothing provides libjxl.so.0(JXL_0)(64bit) needed by
> libaom-3.1.2-1.fc35.x86_64
>  Problem: package graphviz-2.49.3-2.fc36.x86_64 requires
> libgd.so.3()(64bit), but none of the providers can be installed
>  - package gd-2.3.3-3.fc36.x86_64 requires libavif.so.12()(64bit), but
> none of the providers can be installed
>  - package doxygen-2:1.9.1-12.fc36.x86_64 requires graphviz, but none
> of the providers can be installed
>  - package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit),
> but none of the providers can be installed
>  - conflicting requests
>  - nothing provides libjxl.so.0()(64bit) needed by
> libaom-3.1.2-1.fc35.x86_64
>  - nothing provides libjxl.so.0(JXL_0)(64bit) needed by
> libaom-3.1.2-1.fc35.x86_64
>
> Thanks,
> Scott
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Trying to take an orphaned package

2021-11-21 Thread Otto Urpelainen


Matthew Miller kirjoitti 21.11.2021 klo 18.18:

On Sun, Nov 21, 2021 at 08:11:19AM -0500, Stephen Snow wrote:

So I am back here to ask again if I can take a package on that is
currently orphaned as per
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/5FCP5OSV6XXFCAXN5KPKQFBCDLGJSRB6/

And I login with my FAS ID and cannot "Take" the package since I am not
a packager.

So I ask again what steps am I missing here? I want to take over
packaging something that is about to be removed from Fedora Linux since
it has been orphaned, I have signed the agreements, I have asked to
become a packager, and this is actually the second package I am trying
to take over.


I don't think we have a good process for the situation you're in. If the
package you were interested in were entirely new, or if you were reinstating
a package which wsa retired (the step beyond "orphan"), you'd file and go
through the package review process in bugzilla, and at that point if you
hadn't found a sponsor yet, the docs suggest that the sponsor's ticketing
system is the next step.

But without those first steps, how do you get there?

Probably the most straightforward is to pick one of the other routes -- ask
to become a co-maintainer of an existing package, or find something new
you're interested in. Or, go through a number of code reviews for similar
packages and get to know the folks who are working on those, at which point
it should be easy to ask them personally to sponsor you.


A similar situation appeared on devel just recently, where somebody 
without packager rights was interested in taking an orphan package. That 
earlier thread inspired me to submit a pull request for the docs, 
explaining how it can be done [1].


I do not know it is has ever been agreed that this specific case should 
be handled in that way. But I got my first package by adopting an 
orphan, and that is how I got the packager access.


Otto

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/45
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

jpegxl soname bump

2021-11-21 Thread Scott Talbert


Hi @eclipseo,

Looks like jpegxl soname was bumped, breaking a bunch of stuff:

2021-11-21 20:20:51
Package resolution failed

Problem: package gd-2.3.3-3.fc36.x86_64 requires 
libavif.so.12()(64bit), but none of the providers can be installed
- package graphviz-2.49.3-2.fc36.x86_64 requires libgd.so.3()(64bit), 
but none of the providers can be installed
- package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit), 
but none of the providers can be installed

- conflicting requests
- nothing provides libjxl.so.0()(64bit) needed by 
libaom-3.1.2-1.fc35.x86_64
- nothing provides libjxl.so.0(JXL_0)(64bit) needed by 
libaom-3.1.2-1.fc35.x86_64
Problem: package graphviz-2.49.3-2.fc36.x86_64 requires 
libgd.so.3()(64bit), but none of the providers can be installed
- package gd-2.3.3-3.fc36.x86_64 requires libavif.so.12()(64bit), but 
none of the providers can be installed
- package doxygen-2:1.9.1-12.fc36.x86_64 requires graphviz, but none 
of the providers can be installed
- package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit), 
but none of the providers can be installed

- conflicting requests
- nothing provides libjxl.so.0()(64bit) needed by 
libaom-3.1.2-1.fc35.x86_64
- nothing provides libjxl.so.0(JXL_0)(64bit) needed by 
libaom-3.1.2-1.fc35.x86_64


Thanks,
Scott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bash Script to Automount File System (LVM/BTRFS/LUKS) for solving booting trobleshoting issues and include in live-cd image

2021-11-21 Thread Chris Murphy

On Sun, Nov 21, 2021 at 1:49 PM Matthew Miller  wrote:
>
> On Sun, Nov 21, 2021 at 09:45:57AM -0800, Adam Williamson wrote:
> > > Hello., is not precisely my idea but anyone can build a script, which can 
> > > be included in fedora live cd image for solving/troubleshoting this 
> > > issues, at least for a fedora default instalation, if is a custom install 
> > > there is nothing we can do about that.
> > > * Reinstalling the bootloader.
> > > * Rebuilding the initramfs image.
> > > * Upgrading or downgrading packages.
> > > * Resetting a forgotten password.
> > > * Root Account Locked.
> > > * Recover GRUB2 problem.
> >
> > Installer images already have this, it's called 'rescue mode'. Live
> > images do not have it, but any netinst or the Server DVD image does
> > have it.
>
> It does seem like adding a rescue mode to the live image wouldn't be a bad
> idea. Maybe even with some kind of GUI helper. But someone would have to
> develop that software, and as always we have more ideas then implementors.
> And of course, implementing means keeping it up to date, fixing problems
> that occur, and helping test that it still works on new releases, and so on.


Or a way to run the installer in rescue mode from Live media. Maybe
it's possible to invoke from CLI in a terminal program, but I haven't
tried it.

Also note the wiki should be converted into a quickdoc, and replace
the existing one. The wiki entry has been update most recently and
includes a section on using the installer's rescue mode to assemble
pretty much any system that blivet can locate an /etc/fstab for.

https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#I_have_a_grub.3E_prompt.21_Now_what.3F


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

On Sun, 2021-11-21 at 11:18 -0500, Matthew Miller wrote:
-snip-
> 
> I don't think we have a good process for the situation you're in. If
> the
> package you were interested in were entirely new, or if you were
> reinstating
> a package which wsa retired (the step beyond "orphan"), you'd file
> and go
> through the package review process in bugzilla, and at that point if
> you
> hadn't found a sponsor yet, the docs suggest that the sponsor's
> ticketing
> system is the next step.
> 
So what I have figured out from the experiences of others who have
shared with me is I can just do a PR for the fix I think will work for
said package and submit it that way. Thus support in an unoffical
capacity, which is entirely acceptable in my opinion, but it isn't a
documented route nor a formal one, just one that works. 
> But without those first steps, how do you get there?
> 
> Probably the most straightforward is to pick one of the other routes
> -- ask
> to become a co-maintainer of an existing package, or find something
> new
> you're interested in. Or, go through a number of code reviews for
> similar
> packages and get to know the folks who are working on those, at which
> point
> it should be easy to ask them personally to sponsor you.
> 
I guess that is along the lines of what I was saying above and what
others have suggested to me in the past on this topic.

> I know this feels like kind of _a lot_, when you just want to help
> out by
> picking up something that's dropped. But the thing is, once you're in
> the
> pcakaging group, you have a lot of latitude to make a lot of
> technical
> decisions. It's not so much a matter of "do we trust you as a person"
> as it
> is "have you demonstrated that you understand a lot of the nuance and
> complication of packaging and working in our environment."
> 
Yeah so I get this without question and understand emphatically even.
In what I do (Industrial Automation and Machine building) you can spend
years doing the "same thing" differently each time.
> If you'd prefer a less-heavy way to just make a package available, we
> have
> that too, in Copr. There, you can just get started and do it.

Been thinking about that very thing for PLC4X maybe.
> 
> 
> I do think we need to help build a greater pool of people with the
> required
> skills, time, and ability to mentor new packagers -- sponsorship with
> support, not just as a checkbox. We've got some awesome folks who do
> that,
> but... it _is_ a special skill and _definitely_ time consuming. So
> that's an
> area I know we need to invest in. 
I still think a lot of what Mentors and Sponsors could be satisfied the
applicant had a particular set of abilities if they had to get through
some form of app based intruction and test possibly even broken down
into the separate steps of packaging maintenance. With feedback to the
newb and validation testing that would give at least a level of
confidence to the community too. Let's be honest, we want involvement
but all of us want a working Distro more than making it "easier" to get
involved. And getting involved is what we're discussing here, whether
me or others feeling like. To my way of thinking, it's not that the
complexity is a deterent, normally the opposite for most technically
oriented people AFAICT. It is really the lack of a map, which itself
doesn't need to be a hand held journey, just sign posts. Maybe this is
documentation, but I am really reluctant to just chalk it up to that
entirely. So we are talking the same I think but from the opposite side
of the discussion, and this does seem to be the way everyone feels when
this topic comes up.

> But... I hope the above helps explain how
> things are now in practice.
> 
> 
Yes, it is clear in some ways as to why it is done the way it is done
WRT the packages themselves and the requirements of Fedora Linux,
licensing included. What is not clear is how to get from the starting
point most of us have. Which is not hired by RH, or not working at a
company that specifically uses Fedora Linux as part of their business
model. Don't take that wrong either, I entirely appreciate RH et al for
their much needed support, as I would imagine the greater community
does too. But I also appreciate the efforts of each and every non-
business related contributor (ie they don't get paid directly to work
on that thing for Fedora Linux), because quite frankly without them
there likely wouldn't be a Fedora Linux and we'd just be running RHEL
community, so not so delightedly near bleeding edge.

In any case I will keep plugging away, maybe just try to get it to
build and issue a PR with my solution. But it's currently orphaned with
no maintainer AFAIK.

Regards,
Stephen

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

Re: Bash Script to Automount File System (LVM/BTRFS/LUKS) for solving booting trobleshoting issues and include in live-cd image

On Sun, Nov 21, 2021 at 09:45:57AM -0800, Adam Williamson wrote:
> > Hello., is not precisely my idea but anyone can build a script, which can 
> > be included in fedora live cd image for solving/troubleshoting this issues, 
> > at least for a fedora default instalation, if is a custom install there is 
> > nothing we can do about that.
> > * Reinstalling the bootloader.
> > * Rebuilding the initramfs image.
> > * Upgrading or downgrading packages.
> > * Resetting a forgotten password.
> > * Root Account Locked.
> > * Recover GRUB2 problem.
> 
> Installer images already have this, it's called 'rescue mode'. Live
> images do not have it, but any netinst or the Server DVD image does
> have it.

It does seem like adding a rescue mode to the live image wouldn't be a bad
idea. Maybe even with some kind of GUI helper. But someone would have to
develop that software, and as always we have more ideas then implementors.
And of course, implementing means keeping it up to date, fixing problems
that occur, and helping test that it still works on new releases, and so on.

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

packaging group documentation wiki redirect [was Re: Trying to take an orphaned package]

On Sun, Nov 21, 2021 at 04:27:18PM +, Tom Hughes wrote:
> >That page seems substantially (if not completely?) identical to the current
> >doc at 
> >https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
> 
> Ah you're quite right. That was a google fail on my part - the search
> that I did on "fedora become a packager" grouped that wiki page under
> the other docs page I mentioned and I didn't notice that wasn't the
> page the wiki linked to.

There exists a magic wiki macro one can add to the top of a page which
automatically redirects it to the docs (which would probably eventually get
google pointing there too). It would be like this:


{{#fedoradocs: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/}}

... but we don't have a consistent policy about when to use it.


[cc'ing docs list]


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

Re: Trying to take an orphaned package

On Sun, 2021-11-21 at 15:08 +, Tom Hughes wrote:
> 

> That's why I gave a link to the old version from the wiki history
> before it was replaced by a pointer to the new page.
> 
It did help for some info. Thank you.
> > > https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444
> > > 
> > > Basically you need to find somebody to sponsor you as a
> > > packager - normally that happens as part of having your first
> > > package review but obviously that doesn't work when you want
> > > to take over an existing package.
> > 
> > So you see what I was talking about so many (years?!?!) ago, then
> > recently too on this list. It is a common thing it seems that once
> > a
> > person steps up to ask for sponsorship something seems to happen. I
> > am
> > struck by the first line of your response "You say you have "asked
> > to
> > become a packager" but what exactly do you mean by that?" Well,
> > quite
> > simply what I stated, but yet I am being questioned about my
> > sincereity
> > and credibility immediately.
> 
> I wasn't questioning your credibility, I was just confused because
> there's no formal place to lodge such a request as far as I know
> other
> than a review ticket blocking FE-SPONSOR which doesn't apply here.
> 
> I was worried that you had filed some sort of request somewhere
> that nobody was looking.
> 

So maybe we have inadvertently found a crack in the process for
onboarding package maintainers.

> > So back to what I was trying to say in my conversation here about
> > some
> > tool for assessing the prospective newbies like me who want to help
> > but
> > need a sponsor, I was thinking of an app that tests your knowledge
> > and
> > the discussion went towards a generic test package to show
> > packaging
> > knowledge with, then make sponsoring come easier for sponsors.
> > Because
> > this seems to be really the crux of the matter, trust or lack of
> > it.
> 
> I'm not aware of any previous discussions. I was just answering
> the questions you asked in your post today.
> 
> Tom
> 
Again, thank you for taking the time to respond. FWIW I recognize your
name from RH and Fedora for some time, ie years, not trying to make
anyone feel old but it is what it is. The previous discussion was
around onbarding new package maintainers, and the impetus is directly
related to the published orphaned packages, and trying to make them not
be orphaned if needed still. There is a disconnect between the position
taken in the documents around becoming a packager that seems to imply
it is as easy as doing steps #1, #2, then #3, which it isn't. 
Also worth noting is that there is a "dummy onboarding package" that
was started by someone on this list as a result of the conversation but
I haven't found any continuation of the idea.

Regards.
Stephen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Bash Script to Automount File System (LVM/BTRFS/LUKS) for solving booting trobleshoting issues and include in live-cd image

2021-11-21 Thread Adam Williamson

On Sun, 2021-11-21 at 15:25 +, Héctor H. Louzao P. wrote:
> This is my First time here, so Glad to be here:
> 
> Hello., is not precisely my idea but anyone can build a script, which can be 
> included in fedora live cd image for solving/troubleshoting this issues, at 
> least for a fedora default instalation, if is a custom install there is 
> nothing we can do about that.
> 
> * Reinstalling the bootloader.
> * Rebuilding the initramfs image.
> * Upgrading or downgrading packages.
> * Resetting a forgotten password.
> * Root Account Locked.
> * Recover GRUB2 problem.

Installer images already have this, it's called 'rescue mode'. Live
images do not have it, but any netinst or the Server DVD image does
have it.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 2025322] New: EPEL9 Branch Request: perl-utf8-all

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

Bug ID: 2025322
   Summary: EPEL9 Branch Request: perl-utf8-all
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-utf8-all
  Assignee: mspa...@redhat.com
  Reporter: igor.ra...@gmail.com
QA Contact: extras...@fedoraproject.org
CC: mspa...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Hello,

Please provide rubygem-hocon for the EPEL9, it builds fine.

Feel free to add me as a co-maintainer so I can do build myself.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2025322
___
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: Trying to take an orphaned package

2021-11-21 Thread Tom Hughes via devel


On 21/11/2021 16:06, Matthew Miller wrote:

On Sun, Nov 21, 2021 at 10:01:00AM -0500, Stephen Snow wrote:

Thanks read that back then.


But actually I think the old wiki version is much more useful
in explaining how things work, especially if you're not coming
at it from the position of submitting a new package:


And it tells me to read a document that doesn't apparently exist
anymore.

https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444


That page seems substantially (if not completely?) identical to the current
doc at 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/


Ah you're quite right. That was a google fail on my part - the search
that I did on "fedora become a packager" grouped that wiki page under
the other docs page I mentioned and I didn't notice that wasn't the
page the wiki linked to.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Trying to take an orphaned package

On Sun, Nov 21, 2021 at 08:11:19AM -0500, Stephen Snow wrote:
> So I am back here to ask again if I can take a package on that is
> currently orphaned as per
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/5FCP5OSV6XXFCAXN5KPKQFBCDLGJSRB6/
> 
> And I login with my FAS ID and cannot "Take" the package since I am not
> a packager. 
> 
> So I ask again what steps am I missing here? I want to take over
> packaging something that is about to be removed from Fedora Linux since
> it has been orphaned, I have signed the agreements, I have asked to
> become a packager, and this is actually the second package I am trying
> to take over. 

I don't think we have a good process for the situation you're in. If the
package you were interested in were entirely new, or if you were reinstating
a package which wsa retired (the step beyond "orphan"), you'd file and go
through the package review process in bugzilla, and at that point if you
hadn't found a sponsor yet, the docs suggest that the sponsor's ticketing
system is the next step.

But without those first steps, how do you get there?

Probably the most straightforward is to pick one of the other routes -- ask
to become a co-maintainer of an existing package, or find something new
you're interested in. Or, go through a number of code reviews for similar
packages and get to know the folks who are working on those, at which point
it should be easy to ask them personally to sponsor you.

I know this feels like kind of _a lot_, when you just want to help out by
picking up something that's dropped. But the thing is, once you're in the
pcakaging group, you have a lot of latitude to make a lot of technical
decisions. It's not so much a matter of "do we trust you as a person" as it
is "have you demonstrated that you understand a lot of the nuance and
complication of packaging and working in our environment."

If you'd prefer a less-heavy way to just make a package available, we have
that too, in Copr. There, you can just get started and do it.

I do think we need to help build a greater pool of people with the required
skills, time, and ability to mentor new packagers -- sponsorship with
support, not just as a checkbox. We've got some awesome folks who do that,
but... it _is_ a special skill and _definitely_ time consuming. So that's an
area I know we need to invest in. But... I hope the above helps explain how
things are now in practice.

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

Re: Trying to take an orphaned package

On Sun, Nov 21, 2021 at 10:01:00AM -0500, Stephen Snow wrote:
> Thanks read that back then.
> 
> > But actually I think the old wiki version is much more useful
> > in explaining how things work, especially if you're not coming
> > at it from the position of submitting a new package:
> > 
> And it tells me to read a document that doesn't apparently exist
> anymore.
> > https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444

That page seems substantially (if not completely?) identical to the current
doc at 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/


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

Bash Script to Automount File System (LVM/BTRFS/LUKS) for solving booting trobleshoting issues and include in live-cd image

2021-11-21 Thread Héctor H . Louzao P .

This is my First time here, so Glad to be here:

Hello., is not precisely my idea but anyone can build a script, which can be
included in fedora live cd image for solving/troubleshoting this issues, at
least for a fedora default instalation, if is a custom install there is nothing
we can do about that.

* Reinstalling the bootloader.
* Rebuilding the initramfs image.
* Upgrading or downgrading packages.
* Resetting a forgotten password.
* Root Account Locked.
* Recover GRUB2 problem.

### Reason

The $USER has a problem with their computers don't have acces to them, Oh my
system is broken and I've had my mobile or worse don't have it one, and type
all this steps.

https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#restoring-bootloader-using-live-disk

Hovewer there is a PR pending for adding LUKS file system ->
https://pagure.io/fedora-docs/quick-docs/pull-request/406

Is can be as simple as execute the script and voila file system mounted and
chrooted, the $USER do the necesary steps for what their needs and have theirs
box available again, and make it the live easier for all $USER.

### References

https://wiki.archlinux.org/title/Chroot

### Process

```
fedora-chroot /mnt -> magic happend here
```

```
exit -> to exit from chrrot.
```

### Conclusion

Is this posible? Is this complicated to archive?

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

2021-11-21 Thread Globe Trotter via devel

Would anyone be wiling to review this package? I think that it might be 
straightforward given that it was orphaned after F34 and the package seems to 
build without any issues. 

The BZ review request is here: 
https://bugzilla.redhat.com/show_bug.cgi?id=2025138

Would be happy to review in return, of course.

Thanks,
aa...@fedoraproject.org






On Saturday, November 20, 2021, 08:30:24 AM CST, Globe Trotter via devel 
 wrote: 





Thank you, the BZ report is here: 
https://bugzilla.redhat.com/show_bug.cgi?id=2025138

I am already a packager of other packages so I believe that I do not need a 
sponsor.

Best,
aa...@fedoraproject.org





On Saturday, November 20, 2021, 07:49:59 AM CST, Sérgio Basto 
 wrote: 





On Fri, 2021-11-19 at 18:06 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Nov 19, 2021 at 01:57:12PM +, Globe Trotter via devel
> wrote:
> > I opened the following:
> > 
> > https://pagure.io/releng/issue/10396
> > 
> > I am not quite sure what happens after this, so I thought that I
> > would mention this here.
> 
> The package needs to go through re-review, because it was retired for
> more than 8 weeks. See
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
>  .
> 

indeed since package was orphan just in latest release , we should be
allowed to take it without re-review , i.e. I think 8 weeks still a
very short time and should be one release which is about 26 weeks or 6
months . 

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

Re: Trying to take an orphaned package


On Sun, 2021-11-21 at 13:55 +, Tom Hughes wrote:
-snip-
> You say you have "asked to become a packager" but what exactly
> do you mean by that?
> 
I've asked to be sponsored before.

> The official documentation on becoming a packager is here:
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> 
Thanks read that back then.

> But actually I think the old wiki version is much more useful
> in explaining how things work, especially if you're not coming
> at it from the position of submitting a new package:
> 
And it tells me to read a document that doesn't apparently exist
anymore.
> https://fedoraproject.org/w/index.php?title=How_to_get_sponsored_into_the_packager_group=619444
> 
> Basically you need to find somebody to sponsor you as a
> packager - normally that happens as part of having your first
> package review but obviously that doesn't work when you want
> to take over an existing package.
> 
> Tom
> 
So you see what I was talking about so many (years?!?!) ago, then
recently too on this list. It is a common thing it seems that once a
person steps up to ask for sponsorship something seems to happen. I am
struck by the first line of your response "You say you have "asked to
become a packager" but what exactly do you mean by that?" Well, quite
simply what I stated, but yet I am being questioned about my sincereity
and credibility immediately.

The documentation referrals are good, but I have read the doc's and can
read them while in process of doing tasks such as packaging, that's
sort of what higher education is supposed to do for us, teach us how to
research the technical aspects of whatever task we face. 

So back to what I was trying to say in my conversation here about some
tool for assessing the prospective newbies like me who want to help but
need a sponsor, I was thinking of an app that tests your knowledge and
the discussion went towards a generic test package to show packaging
knowledge with, then make sponsoring come easier for sponsors. Because
this seems to be really the crux of the matter, trust or lack of it.

And I really do want to help with this package since ti seems to be a
dependency for some others and it is important to me to see Fedora
Linux remain a usable distribution (entirely selfishly here). 

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

[EPEL-devel] can't install synergy on CentOS/Rocky 8 ...

2021-11-21 Thread KC

Hi,

Just reporting that synergy installation fail on CentOS 8 & Rocky 8.

> dnf install synergy
Last metadata expiration check: 4:17:16 ago on Sun 21 Nov 2021 06:28:05 PM
CST.
Error:
 Problem: conflicting requests
  - nothing provides libdns_sd.so.1()(64bit) needed by
synergy-1:1.11.1-1.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to
use not only best candidate packages)


Regards,
KC
___
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-Rawhide-20211121.n.0 compose check report

2021-11-21 Thread Fedora compose checker

No missing expected images.

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 5/208 (x86_64), 10/142 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20211120.n.1):

ID: 1067602 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1067602
ID: 1067664 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1067664
ID: 1067667 Test: aarch64 Server-dvd-iso 
install_btrfs_preserve_home_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1067667
ID: 1067703 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1067703
ID: 1067722 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1067722
ID: 1067776 Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/1067776
ID: 1067828 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1067828
ID: 1067858 Test: aarch64 universal install_package_set_minimal@uefi
URL: https://openqa.fedoraproject.org/tests/1067858

Old failures (same test failed in Fedora-Rawhide-20211120.n.1):

ID: 1067605 Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1067605
ID: 1067617 Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/1067617
ID: 1067618 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1067618
ID: 1067702 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1067702
ID: 1067731 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1067731
ID: 1067736 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1067736
ID: 1067836 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1067836

Soft failed openQA tests: 3/142 (aarch64), 7/208 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20211120.n.1):

ID: 1067720 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1067720

Old soft failures (same test soft failed in Fedora-Rawhide-20211120.n.1):

ID: 1067592 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1067592
ID: 1067607 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1067607
ID: 1067641 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1067641
ID: 1067642 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1067642
ID: 1067643 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1067643
ID: 1067653 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1067653
ID: 1067745 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1067745
ID: 1067792 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1067792
ID: 1067841 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1067841

Passed openQA tests: 196/208 (x86_64), 129/142 (aarch64)

New passes (same test not passed in Fedora-Rawhide-20211120.n.1):

ID: 1067525 Test: x86_64 Server-dvd-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1067525
ID: 1067668 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1067668
ID: 1067685 Test: aarch64 Server-dvd-iso 
install_repository_nfs_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1067685
ID: 1067705 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/1067705
ID: 1067730 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1067730
ID: 1067737 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1067737
ID: 1067802 Test: x86_64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/1067802
ID: 1067825 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1067825
ID: 1067826 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1067826
ID: 1067865 Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1067865

Installed system changes in test

Trying to take an orphaned package