Re: [INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Sun, Oct 09, 2022 at 10:58:58PM +0200, Dan Čermák wrote:
> Hi Stephen,
> 
> Stephen Gallagher  writes:
> 
> > On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:
> 
> > *snip*
> 
> > When a Node.js release goes out of support, we have a question to
> > answer: do we Obsolete it with a newer version? If so, which one? The
> > most recent version or the oldest one? It will not be 100% compatible
> > in either case. Do we Obsolete it with fedora-retired-packages? Do we
> > just leave the packages in Fedora forever (possibly patching the
> > `/usr/bin/node` binary to warn that it's out of support)?
> 
> I would definitely obsolete it. I personally would obsolete it with the
> default nodejs version, if there is one.
> 
> > There's another potential upgrade issue: We have multiple choices of
> > how to upgrade from the nodejs package to the nodejsXX packages:
> > 1) Upgrading from either F36 or F37 will result in you getting Node.js
> > 18. (This method is closest to how things worked prior to this Change,
> > where the nodejs package would just get updated to the latest stable
> > release)
> > 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading
> > from F37 will move you onto Node.js 18 in F38. (This method maintains
> > compatibility with applications running on the current system)
> > 3) Upgrading from F36 or F37 will *remove* the nodejs package and the
> > user will need to manually select one to install. (This method has
> > increased friction, but more user choice)
> > 4) Upgrading from F36 or F37 will leave the existing nodejs package on
> > the system, receiving no updates. Users of F38 will need to manually
> > remove and install a newer version. (This method is high-friction,
> > offers nothing over any of the others and potentially leaves people
> > vulnerable)
> >
> > With options 1), 3) and 4), we can make the change in F38 exclusively.
> > However if we want to do 2), we *also* need to either backport this
> > Change to Fedora 37 and Fedora 36 because otherwise we would have to
> > continuously update the Obsoletes: values in F38. With 1) I can update
> > the Obsoletes: to just treat any Node.js with an epoch < 3 as the
> > trigger to move to nodejs18.
> >
> > My questions to those brave souls who have read this far:
> > 1) Which do you think is the best of the above options for upgrades to F38?
> 
> My personal preference would be Option 1. Imho it's a bit expected that
> you might have to do some cleanup after a system upgrade. So moving to
> the latest stable version sounds like a good overall compromise for most
> users: you'll get the latest stable version and if you need an older
> version, you'll (hopefully) figure it out during the post-upgrade
> cleanup. (And we could implement it without backporting)

+1. It also sounds like this option is easiest on the maintainers.

Zbyszek

> > 2) What do we do about future upgrades in the following scenarios:
> > a. The user has nodejsXX installed as the default interpreter. The
> > nodejsXX package is no longer available upon upgrade (EOL).
> 
> I would upgrade to the new default version.
> 
> > b. The user has nodejsXX installed as the default interpreter. The
> > nodejsXX package is available but non-default upon upgrade.
> 
> Unless it is very simple to upgrade to that non-default version on
> upgrade, I'd just upgrade to the new default/latest stable as well in
> this case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: DNF5 Blockers

[Jaroslav Mracek]

Please can you be more specific which kind of functionality is required for 
particular command? Why is it important to know what user case you want to 
resolve it? Commands has multiple options and some of them could be unused. 
Specially repoquery has tons of options. Knowing critical usercase will help us 
a lot to not only provide the same option but to improve DNF5 behavior in 
comparison to DNF4.

I recommend to create for each user case or command an issue - 
https://github.com/rpm-software-management/dnf5/issues. Please provide as much 
as possible information to understand the user case to be able to set a proper 
priority.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg new-sources errors

[Petr Pisar]

V Fri, Oct 07, 2022 at 02:35:51PM +, Mattia Verga via devel napsal(a):
> Il 07/10/22 13:50, Petr Pisar ha scritto:
> > V Thu, Oct 06, 2022 at 08:17:15PM -0500, Richard Shaw napsal(a):
> >> I'm still getting this on occasion and have no idea what the issue is:
> >>
> >> $ fedpkg new-sources OpenImageIO-2.4.4.2.tar.gz
> >> Uploading: OpenImageIO-2.4.4.2.tar.gz
> >> #
> >>   52.0%Could not execute new_sources: (56, 'OpenSSL SSL_read:
> >> error:0A0003FC:SSL routines::sslv3 alert bad record mac, errno 0')
> >>
> > It can be caused by anything. From a currupted IP packet to a TLS
> > implementation (either server or client) wich does not understand or
> > misimplements some TLS extensions. Example at
> > .
> >
> > -- Petr
> 
> Possibly related (?), today I've noticed that opening a .fedorapeople
> website in a browser I get an error about expired certificate...
> 
I think that's an independent bug. The certificate was successfully renewed in
the meant time:

Serial Number:
04:e8:a4:9d:11:95:f8:01:7d:ea:f8:37:05:ba:c6:45:16:9c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = R3
Validity
Not Before: Oct  7 14:19:33 2022 GMT
Not After : Jan  5 14:19:32 2023 GMT
Subject: CN = *.fedorapeople.org

-- Petr


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)

[Vít Ondruch]

Dne 07. 10. 22 v 20:54 Stephen Gallagher napsal(a):

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:

https://fedoraproject.org/wiki/Changes/NodejsRepackaging

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We are reworking the Node.js packaging to make Node.js versions
available as parallel-installable packages.

So, I'd like to give an update here and address potential issues that
I discovered this week surrounding the upgrade path.

First and most exciting: I've got the packaging work for Node.js 16
and Node.js 18 in good shape and it can be tried out by using my COPR
at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/
(`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems.
Thanks to the input of folks on this thread, I've now put together
parallel-installable versions, any of which can provide the
/usr/bin/node by installing the appropriate
`nodejsXX-interpreter-default` package. I've also got the dependencies
established in such a way that a fresh install of `dnf install nodejs`
on releases will result in automatically installing the latest stable
version that was available at the Fedora release's Beta Freeze. (So
for F38 it will be Node.js 18, for F39 it will be Node.js 20).

On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the
nodejs18 package will Obsolete the nodejs package. On upgrade of the
same system to Fedora 39 later, it will continue on the Node.js 18
package. To switch to the newer version, the user will need to
manually run `dnf swap nodejs18-interpreter-default
nodejs20-interpreter-default). While this may seem unexpected
behavior, I feel that it's better to maintain compatibility on upgrade
with any applications in use rather than to force the upgrade unless
the current version is going out of support.

When a Node.js release goes out of support, we have a question to
answer: do we Obsolete it with a newer version? If so, which one? The
most recent version or the oldest one? It will not be 100% compatible
in either case. Do we Obsolete it with fedora-retired-packages? Do we
just leave the packages in Fedora forever (possibly patching the
`/usr/bin/node` binary to warn that it's out of support)?



If you kept nonversioned rolling nodejs package, which would be the 
default, you would not have the issues with upgrade. And if somebody 
installed the versioned package, then it would be up to the user to take 
action.


I would strongly suggest against introducing the versioned packages. It 
never made anything good for Fedora. If you want to keep providing some 
version for backward compatibility, so be it, add the versioned package. 
But don't do that by default.



Vít



There's another potential upgrade issue: We have multiple choices of
how to upgrade from the nodejs package to the nodejsXX packages:
1) Upgrading from either F36 or F37 will result in you getting Node.js
18. (This method is closest to how things worked prior to this Change,
where the nodejs package would just get updated to the latest stable
release)
2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading
from F37 will move you onto Node.js 18 in F38. (This method maintains
compatibility with applications running on the current system)
3) Upgrading from F36 or F37 will *remove* the nodejs package and the
user will need to manually select one to install. (This method has
increased friction, but more user choice)
4) Upgrading from F36 or F37 will leave the existing nodejs package on
the system, receiving no updates. Users of F38 will need to manually
remove and install a newer version. (This method is high-friction,
offers nothing over any of the others and potentially leaves people
vulnerable)

With options 1), 3) and 4), we can make the change in F38 exclusively.
However if we want to do 2), we *also* need to either backport this
Change to Fedora 37 and Fedora 36 because otherwise we would have to
continuously update the Obsoletes: values in F38. With 1) I can update
the Obsoletes: to just treat any Node.js with an epoch < 3 as the
trigger to move to nodejs18.

My questions to those brave souls who have read this far:
1) Which do you think is the best of the above options for upgrades to F38?
2) What do we do about future upgrades in the following scenarios:
 a. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is no longer available upon upgrade (EOL).
 b. The user has nodejsXX installed as the default interpreter. The
nodejsXX package is available but non-default upon upgrade.

Thank you for reading to the end.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
ht

[side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Zdenek Dohnal]

Hi all,

I maintain qpdf in Fedora, which recently got a new major release 
version, which breaks compatibility with other packages, so I created a 
side tag for other maintainers to use for building, and then releasing 
it altogether in rawhide.


However the side tag:

f38-build-side-58658

got automatically deleted, even when it had builds connected to it 
already. Documentation [1] does not mention any automatic side-tags 
cleanup and its deadlines.


Although packagers can create a new side tag easily, I found it 
inconvenient for maintainers, because the synchronization among the 
maintainers can take weeks to finish the rebuild and release the update 
and automatic removal without notice (do excuse me if I missed a 
notification email about this - I have many filters and it could end up 
somewhere where I wasn't able to find it) prolongs this process.


What I would like to propose are the following options:

A) don't do side-tag cleanups after a specific time frame, but only when 
the specific event happens - branching, GA, EOL - it can be consuming to 
our resources, but maintainer are still able to remove the side tags 
manually in case it contains a big set of packages and AFAIK the process 
itself is not such spread in usage...


or

B) do a side-tags cleanup and mention it in the documentation together 
with specification what the removal's time frame is, so maintainers can 
act accordingly


or

C) (my preferred) Koji or releng (depends on whether the cleanup 
happened automatically or manually) will send an email to a side tag 
creator with 'Hi, your side tag is going to expire - do you need it?' Or 
with automaton - 'use this command to prolong it.' And if there is no 
response or if the creator approves, remove the side tag.



WDYT?


Zdenek


[1] https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-10-10.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

Falconorphan   1 weeks ago
amora orphan   4 weeks ago
blueberry nonamedotc, orphan, rathann  4 weeks ago
brewtargetorphan   0 weeks ago
capstone  orphan, rebus, ret2libc  1 weeks ago
containerdgo-sig, gotmax23, orphan 0 weeks ago
csoundorphan   1 weeks ago
espresso-ab   avigne, orphan   5 weeks ago
geompporphan   3 weeks ago
geteltorito   orphan   4 weeks ago
giada orphan   3 weeks ago
gimp-focusblur-plugin orphan   5 weeks ago
gmqcc orphan   5 weeks ago
golang-github-beevik-etreego-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-crewjam-httperr go-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-crewjam-samlgo-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-dchest-uniuri   go-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-logr-stdr   eclipseo, go-sig, orphan 2 weeks ago
golang-github-magefile-mage   go-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-russellhaering- go-sig, mgoodwin, nathans,   2 weeks ago
goxmldsig orphan
golang-github-timberio-datemath   go-sig, mgoodwin, nathans,   2 weeks ago
  orphan
golang-github-ua-parser-uap   go-sig, mgoodwin, nathans,   2 weeks ago
  orphan
hct   avigne, orphan   5 weeks ago
kelbt orphan   5 weeks ago
llvm11.0  orphan, tstellar 0 weeks ago
moby-engine   go-sig, gotmax23, orphan 0 weeks ago
monobristol   orphan   5 weeks ago
nautilus-search-tool  orphan   3 weeks ago
origingo-sig, orphan, tdawson  5 weeks ago
owl-lisp  huzaifas, orphan 4 weeks ago
perl-Parse-Debian-Packagesorphan   5 weeks ago
php-psr-http-client   orphan   5 weeks ago
pinpoint  orphan   3 weeks ago
pt-astra-sans-fontorphan   4 weeks ago
pt-astra-serif-font   orphan   4 weeks ago
python-APSchedulerorphan, zuul 1 weeks ago
python-PyRSS2Gen  orphan   0 weeks ago
python-cached_propertyadamwill, orphan 0 weeks ago
python-charon orphan   2 weeks ago
python-coreapiorphan   5 weeks ago
python-coreschema orphan   5 weeks ago
python-drf-yasg   orphan   5 weeks ago
python-hbmqtt orphan   3 weeks ago
python-hs-dbus-signature  ignatenkobrain, jbaublitz,   1 weeks ago

Re: Orphaned packages looking for new maintainers

[Daniel P . Berrangé]

On Mon, Oct 10, 2022 at 10:31:24AM +0200, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will fail to install and/or build when the affected package gets 
> retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2022-10-10.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains,
> see https://packager-dashboard.fedoraproject.org/
> For all orphaned packages,
> see https://packager-dashboard.fedoraproject.org/orphan
> 
> Package  (co)maintainers   Status 
> Change
> 
> capstone  orphan, rebus, ret2libc  1 weeks ago


If neither of the existing co-maintainers wants to claim formal ownership,
I can see about finding someone in the Red Hat virt team to take over,
since this is in the critical path for QEMU.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: openshadinglanguage failure on non x86_64

[Dan Horák]

On Mon, 10 Oct 2022 10:09:32 +0900
Mamoru TASAKA  wrote:

> Luya Tshimbalanga wrote on 2022/10/10 2:46:
> > Hello team,
> > 
> > openshadinglanguage 1.12.6.2 only successfully built on x86_64 architecture 
> > but failed on others due to the following errors:
> > 
> > In file included from 
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
> >   from 
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
> > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10:
> >  fatal error: immintrin.h: No such file or directory
> >      7 | #include 
> >    |  ^
> > compilation terminated.
> > 
> > 
> > That "immintrin.h" is provided by both gcc and clang according to "dnf -C 
> > repoquery --whatprovides */immintrin.h". Could someone investigate the 
> > cause and provide a patch?
> > 
> > See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862
> > 
> > Thanks in advance
> > 
> 
> Well, gcc immintrin.h is 
> "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note that 
> "x86_64-" path).
> 
> And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
> --
> #if !defined(__i386__) && !defined(__x86_64__)
> #error "This header is only meant to be used on x86 and x64 architecture"
> #endif
> --
> 
> AFAIK immintrin.h is available only on x86 / x86_64.
> 
> Then as far as I looked at src/include/OSL/mask.h, it looks like actually 
> this supports non-x86 architectures
> (as I see #elif defined(__GNUC__) || defined(__clang__) or so),
> so just try to guard the inclusion like
> 
> #if defined(__i386__) || defined(__x86_64__)
> #include 
> #endif
> 
> and see how it goes. Maybe some additional modification is needed, but for 
> now I expect that
> most things may go well.

if I see right, then the reason for the inclusion of "immintrin.h" is to
provide popcount and coutr_zero implementations when built with C++
standard below C++20, see
https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/include/OSL/mask.h#L18
or when not using GCC or clang where the functions are "builtin". So
the inclusion is made from a wrong place. I am going to submit a PR to
upstream.


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

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Petr Pisar]

V Fri, Oct 07, 2022 at 04:09:01PM +, Mattia Verga via devel napsal(a):
> Il 07/10/22 17:28, Chris Adams ha scritto:
> > Once upon a time, Mattia Verga  said:
> >> I don't understand, why RPM automatically adds a dependency on a noarch
> >> subpackage which consists only of data files?
> >>
> >> https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
> >>
> >> Any idea?
> > Because it isn't just data files?  /usr/share/xephem/auxil contains two
> > executable perl scripts.
> > --
> > Chris Adams 
> 
> Thanks, I'll try to unset the exec bit on those two scripts.
> 
If you want to demote the file from a script level, you should also remove the
first line (#!/usr/bin/perl). Otherwise, rpmbuild (or rpmlint?) will complain.

-- Petr



signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Miro Hrončok]

On 10. 10. 22 10:46, Petr Pisar wrote:

Thanks, I'll try to unset the exec bit on those two scripts.


If you want to demote the file from a script level, you should also remove the
first line (#!/usr/bin/perl). Otherwise, rpmbuild (or rpmlint?) will complain.


rpmlint



--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Petr Pisar]

V Fri, Oct 07, 2022 at 11:56:51AM -0500, Chris Adams napsal(a):
> Once upon a time, Mattia Verga  said:
> > Il 07/10/22 17:28, Chris Adams ha scritto:
> > > Once upon a time, Mattia Verga  said:
> > >> I don't understand, why RPM automatically adds a dependency on a noarch
> > >> subpackage which consists only of data files?
> > >>
> > >> https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
> > >>
> > >> Any idea?
> > > Because it isn't just data files?  /usr/share/xephem/auxil contains two
> > > executable perl scripts.
> > 
> > Thanks, I'll try to unset the exec bit on those two scripts.
> 
> I think it'd be better to consider the packaging - should those scripts
> be in this subpackage at all?  Do they belong somewhere else, or do they
> even need to be shipped?  If they belong with the data... then it's
> probably correct for the data package to depend on perl.
> 
> Don't just try do things to avoid dependencies, understand why it's
> there.

Indeed. /usr/share/xephem/auxil/README reads:

This directory contains support files that are used by xephem.

If the script is used, unsetting executable bit could break xephem.

I was able to find mpcorb2edb.pl mentioned this documention
/usr/share/xephem/help/xephem.html:

When the Get
button is clicked, XEphem downloads the appropriate file, uncompresses
it, reformats it to .edb format and splits the results into two files
for convenience. One file will contain all asteroids which can ever
become brighter than magnitude 13, and the other (with a "_dim" suffix)
contains all the rest. All files are created in the user's Private
XEphem directory. The real work is performed by two perl scripts,
mpcorb2edb.pl and astorb2edb.pl, respectively. These may be run 
independently
of XEphem if desired.

And indeed the script name is compiled into /usr/bin/xephem binary.

I guess you should keep the script executable and keep the dependency on
perl.

-- Petr


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Next Open NeuroFedora Meeting: 1300 UTC on Monday, 10 October September (Today)

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday 10th
October(today!) at 1300UTC in #fedora-neuro on Matrix or IRC (Libera.chat).
The meeting is a public meeting, and open for everyone to attend. You
can join us over:

Matrix: https://matrix.to/#/#neuro:fedoraproject.org
IRC: https://webchat.libera.chat/?channels=#fedora-neuro

You can use this link to see the local time for the meeting:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20221010T13&p1=%3A&ah=1

or you can use this command in a terminal:
$ date --date='TZ="UTC" 1300 today'

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: 
https://meetbot.fedoraproject.org/fedora-neuro/2022-10-10/neurofedora.2022-10-10-13.00.html
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check for F37/F38: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:
https://neuroblog.fedoraproject.org/2022/10/09/next-open-neurofedora-meeting-10-october-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: openshadinglanguage failure on non x86_64

[Dan Horák]

On Mon, 10 Oct 2022 10:46:20 +0200
Dan Horák  wrote:

> On Mon, 10 Oct 2022 10:09:32 +0900
> Mamoru TASAKA  wrote:
> 
> > Luya Tshimbalanga wrote on 2022/10/10 2:46:
> > > Hello team,
> > > 
> > > openshadinglanguage 1.12.6.2 only successfully built on x86_64 
> > > architecture but failed on others due to the following errors:
> > > 
> > > In file included from 
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
> > >   from 
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
> > > /builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10:
> > >  fatal error: immintrin.h: No such file or directory
> > >      7 | #include 
> > >    |  ^
> > > compilation terminated.
> > > 
> > > 
> > > That "immintrin.h" is provided by both gcc and clang according to "dnf -C 
> > > repoquery --whatprovides */immintrin.h". Could someone investigate the 
> > > cause and provide a patch?
> > > 
> > > See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862
> > > 
> > > Thanks in advance
> > > 
> > 
> > Well, gcc immintrin.h is 
> > "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note that 
> > "x86_64-" path).
> > 
> > And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
> > --
> > #if !defined(__i386__) && !defined(__x86_64__)
> > #error "This header is only meant to be used on x86 and x64 architecture"
> > #endif
> > --
> > 
> > AFAIK immintrin.h is available only on x86 / x86_64.
> > 
> > Then as far as I looked at src/include/OSL/mask.h, it looks like actually 
> > this supports non-x86 architectures
> > (as I see #elif defined(__GNUC__) || defined(__clang__) or so),
> > so just try to guard the inclusion like
> > 
> > #if defined(__i386__) || defined(__x86_64__)
> > #include 
> > #endif
> > 
> > and see how it goes. Maybe some additional modification is needed, but for 
> > now I expect that
> > most things may go well.
> 
> if I see right, then the reason for the inclusion of "immintrin.h" is to
> provide popcount and coutr_zero implementations when built with C++
> standard below C++20, see
> https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/blob/main/src/include/OSL/mask.h#L18
> or when not using GCC or clang where the functions are "builtin". So
> the inclusion is made from a wrong place. I am going to submit a PR to
> upstream.

https://github.com/AcademySoftwareFoundation/OpenShadingLanguage/pull/1605
should be the proper fix


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

Capstone (was: Re: Orphaned packages looking for new maintainers)

[Richard W.M. Jones]

On Mon, Oct 10, 2022 at 10:31:24AM +0200, Miro Hrončok wrote:
> capstone  orphan, rebus, ret2libc  1 weeks ago

[Affecting lots of packages]

This is a disassembly library / framework used by qemu.  It seems like
it has two maintainers so I guess it's not really an orphan, but I can
take the package if neither of the two existing maintainers wants to
become owner.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: openshadinglanguage failure on non x86_64

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/10/10 10:09:

Luya Tshimbalanga wrote on 2022/10/10 2:46:

Hello team,

openshadinglanguage 1.12.6.2 only successfully built on x86_64 architecture but 
failed on others due to the following errors:

In file included from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
  from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10: 
fatal error: immintrin.h: No such file or directory
 7 | #include 
   |  ^
compilation terminated.


That "immintrin.h" is provided by both gcc and clang according to "dnf -C repoquery 
--whatprovides */immintrin.h". Could someone investigate the cause and provide a patch?

See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862

Thanks in advance



Well, gcc immintrin.h is "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note 
that "x86_64-" path).

And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
--
#if !defined(__i386__) && !defined(__x86_64__)
#error "This header is only meant to be used on x86 and x64 architecture"
#endif
--

AFAIK immintrin.h is available only on x86 / x86_64.

Then as far as I looked at src/include/OSL/mask.h, it looks like actually this 
supports non-x86 architectures
(as I see #elif defined(__GNUC__) || defined(__clang__) or so),
so just try to guard the inclusion like

#if defined(__i386__) || defined(__x86_64__)
#include 
#endif

and see how it goes. Maybe some additional modification is needed, but for now 
I expect that
most things may go well.


Actually this guard makes build successful:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92870693

Dan has proposed another fix in this thread, I think it should work well 
similarly.

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

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Mattia Verga via devel]

Il 10/10/22 10:57, Petr Pisar ha scritto:
> V Fri, Oct 07, 2022 at 11:56:51AM -0500, Chris Adams napsal(a):
>> Once upon a time, Mattia Verga  said:
>>> Il 07/10/22 17:28, Chris Adams ha scritto:
 Once upon a time, Mattia Verga  said:
> I don't understand, why RPM automatically adds a dependency on a noarch
> subpackage which consists only of data files?
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
>
> Any idea?
 Because it isn't just data files?  /usr/share/xephem/auxil contains two
 executable perl scripts.
>>> Thanks, I'll try to unset the exec bit on those two scripts.
>> I think it'd be better to consider the packaging - should those scripts
>> be in this subpackage at all?  Do they belong somewhere else, or do they
>> even need to be shipped?  If they belong with the data... then it's
>> probably correct for the data package to depend on perl.
>>
>> Don't just try do things to avoid dependencies, understand why it's
>> there.
> Indeed. /usr/share/xephem/auxil/README reads:
>
>  This directory contains support files that are used by xephem.
>
> If the script is used, unsetting executable bit could break xephem.
>
> I was able to find mpcorb2edb.pl mentioned this documention
> /usr/share/xephem/help/xephem.html:
>
>  When the Get
>  button is clicked, XEphem downloads the appropriate file, uncompresses
>  it, reformats it to .edb format and splits the results into two files
>  for convenience. One file will contain all asteroids which can ever
>  become brighter than magnitude 13, and the other (with a "_dim" suffix)
>  contains all the rest. All files are created in the user's Private
>  XEphem directory. The real work is performed by two perl scripts,
>  mpcorb2edb.pl and astorb2edb.pl, respectively. These may be run 
> independently
>  of XEphem if desired.
>
> And indeed the script name is compiled into /usr/bin/xephem binary.
>
> I guess you should keep the script executable and keep the dependency on
> perl.
>
> -- Petr

Indeed, you're right. I thought those were support files not directly
consumed by the main program itself. I'll add an explicit perl dependency.

I'm now facing a build failure on EPEL, which I can't figure out:
/usr/bin/ld: lilxml.o (symbol from plugin): undefined reference to
symbol 'xmlMalloc@@LIBXML2_2.4.30'
/usr/bin/ld: /usr/lib64/libxml2.so.2: error adding symbols: DSO missing
from command line

Does anyone have some spare time to give me any advice?
https://koji.fedoraproject.org/koji/taskinfo?taskID=92750018

Mattia

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

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Dan Čermák]

Hi,

On October 10, 2022 8:17:15 AM UTC, Zdenek Dohnal  wrote:
>Hi all,
>
>I maintain qpdf in Fedora, which recently got a new major release version, 
>which breaks compatibility with other packages, so I created a side tag for 
>other maintainers to use for building, and then releasing it altogether in 
>rawhide.
>
>However the side tag:
>
>f38-build-side-58658
>
>got automatically deleted, even when it had builds connected to it already. 
>Documentation [1] does not mention any automatic side-tags cleanup and its 
>deadlines.
>
>Although packagers can create a new side tag easily, I found it inconvenient 
>for maintainers, because the synchronization among the maintainers can take 
>weeks to finish the rebuild and release the update and automatic removal 
>without notice (do excuse me if I missed a notification email about this - I 
>have many filters and it could end up somewhere where I wasn't able to find 
>it) prolongs this process.
>
>What I would like to propose are the following options:
>
>A) don't do side-tag cleanups after a specific time frame, but only when the 
>specific event happens - branching, GA, EOL - it can be consuming to our 
>resources, but maintainer are still able to remove the side tags manually in 
>case it contains a big set of packages and AFAIK the process itself is not 
>such spread in usage...
>
>or
>
>B) do a side-tags cleanup and mention it in the documentation together with 
>specification what the removal's time frame is, so maintainers can act 
>accordingly
>
>or
>
>C) (my preferred) Koji or releng (depends on whether the cleanup happened 
>automatically or manually) will send an email to a side tag creator with 'Hi, 
>your side tag is going to expire - do you need it?' Or with automaton - 'use 
>this command to prolong it.' And if there is no response or if the creator 
>approves, remove the side tag.

This sound like the preferred solution to me as well.


Cheers,

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

Re: Orphaned packages looking for new maintainers

[Adam Williamson]

On Mon, 2022-10-10 at 10:31 +0200, Miro Hrončok wrote:
> python-cached_property    adamwill, orphan 0 weeks ago

I'll take this, I've effectively been the maintainer for years anyway.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Handle sysroot.readyonly=true migration in other rpm-ostree Fedora(s)

[Antonio Murdaca]

Hi folks, in rpm-ostree based systems like fedora iot I would love to handle 
the migration process similar to what happens today in silverblue et all wrt 
sysroot.readonly 
https://pagure.io/workstation-ostree-config/blob/main/f/postprocess.sh - 
unfortunately that systemd service and script aren't packaged anywhere and I'd 
love to have it versioned in RPMs to be used by other spins too. I couldn't 
find any other conversations around this so I'm opening this one to discuss how 
and where such a migration should be handled/shipped/run in other systems.
Thanks a lot in advance
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Mamoru TASAKA]

Zdenek Dohnal wrote on 2022/10/10 17:17:

Hi all,

I maintain qpdf in Fedora, which recently got a new major release version, 
which breaks compatibility with other packages, so I created a side tag for 
other maintainers to use for building, and then releasing it altogether in 
rawhide.

However the side tag:

f38-build-side-58658

got automatically deleted, even when it had builds connected to it already. 
Documentation [1] does not mention any automatic side-tags cleanup and its 
deadlines.

Although packagers can create a new side tag easily, I found it inconvenient 
for maintainers, because the synchronization among the maintainers can take 
weeks to finish the rebuild and release the update and automatic removal 
without notice (do excuse me if I missed a notification email about this - I 
have many filters and it could end up somewhere where I wasn't able to find it) 
prolongs this process.

What I would like to propose are the following options:

A) don't do side-tag cleanups after a specific time frame, but only when the 
specific event happens - branching, GA, EOL - it can be consuming to our 
resources, but maintainer are still able to remove the side tags manually in 
case it contains a big set of packages and AFAIK the process itself is not such 
spread in usage...

or

B) do a side-tags cleanup and mention it in the documentation together with 
specification what the removal's time frame is, so maintainers can act 
accordingly

or

C) (my preferred) Koji or releng (depends on whether the cleanup happened 
automatically or manually) will send an email to a side tag creator with 'Hi, 
your side tag is going to expire - do you need it?' Or with automaton - 'use 
this command to prolong it.' And if there is no response or if the creator 
approves, remove the side tag.



IMO basically side-tag is not expected to exist for such a long time, side-tag 
requester should
take effort to merge it into main buildroot within, say, one week at most.

Even when side-tag buildroot exists, of source main buildroot evolves at the 
same time,
and as soname bump on another library can happen for example, when side-tag 
merge gets delayed,
confusion is going to happen, e.g. R side-tag v.s. icu side-tag confusion which 
happened
about two months ago.

So if side-tag cannot be merged into main buildroot within some "reasonable" 
period
(I would expect within two weeks at most), I want side-tag requester to once 
dispose it.

If rebuilding depdening packages are not ready, please create copr repository 
first,
check if depending packages are ready, and if not file a ticket on bugzilla or 
so,
and when it is ready to rebuild, then create side-tag.

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

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Adam Williamson]

On Mon, 2022-10-10 at 21:02 +0900, Mamoru TASAKA wrote:
> Zdenek Dohnal wrote on 2022/10/10 17:17:
> > Hi all,
> > 
> > I maintain qpdf in Fedora, which recently got a new major release version, 
> > which breaks compatibility with other packages, so I created a side tag for 
> > other maintainers to use for building, and then releasing it altogether in 
> > rawhide.
> > 
> > However the side tag:
> > 
> > f38-build-side-58658
> > 
> > got automatically deleted, even when it had builds connected to it already. 
> > Documentation [1] does not mention any automatic side-tags cleanup and its 
> > deadlines.
> > 
> > Although packagers can create a new side tag easily, I found it 
> > inconvenient for maintainers, because the synchronization among the 
> > maintainers can take weeks to finish the rebuild and release the update and 
> > automatic removal without notice (do excuse me if I missed a notification 
> > email about this - I have many filters and it could end up somewhere where 
> > I wasn't able to find it) prolongs this process.
> > 
> > What I would like to propose are the following options:
> > 
> > A) don't do side-tag cleanups after a specific time frame, but only when 
> > the specific event happens - branching, GA, EOL - it can be consuming to 
> > our resources, but maintainer are still able to remove the side tags 
> > manually in case it contains a big set of packages and AFAIK the process 
> > itself is not such spread in usage...
> > 
> > or
> > 
> > B) do a side-tags cleanup and mention it in the documentation together with 
> > specification what the removal's time frame is, so maintainers can act 
> > accordingly
> > 
> > or
> > 
> > C) (my preferred) Koji or releng (depends on whether the cleanup happened 
> > automatically or manually) will send an email to a side tag creator with 
> > 'Hi, your side tag is going to expire - do you need it?' Or with automaton 
> > - 'use this command to prolong it.' And if there is no response or if the 
> > creator approves, remove the side tag.
> > 
> 
> IMO basically side-tag is not expected to exist for such a long time, 
> side-tag requester should
> take effort to merge it into main buildroot within, say, one week at most.

I'm not sure this is always going to be realistic. We are increasingly
encouraging folks to do big complicated rebases in side tags rather
than breaking Rawhide or Branched for days at a time; sometimes this
might take more than a week. I don't want folks to be discouraged from
using side tags and just go back to breaking Rawhide because of this
kind of cleanup.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

** s390x builders Outage **

[Tomas Hrcka]

There is an ongoing BOS power outage impacting s390x builders.

Reason for outage: Power outage in the DC


-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
freenode: jednorozec
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Grub menu with 3 kernels by default

[Gerd Hoffmann]

  Hi,

> > Thus any attempt to validate the the grub.conf PCR eventlog, as it
> > exists in typical distro deployments today, is going to be both
> > complex and fragile, which is a bad combination.
> 
> But this is only a problem if you're assuming grub2-mkconfig is
> nondeterministic, which just isn't the case.  I'll grant that the event
> log isn't terse, but what's valid isn't be hard to precompute.

It might be workable on the installed system, by running grub.cfg
through grub shell or something like that.  But even that has its
challenges, see below.

It's next to impossible for a third party though.

> On generally identical systems, what will differ is uuids and
> partition numbers...

Would be nice if it would be that simple.  Unfortunately it is not.

For starters naming grub.cfg "configuration" is wrong.  It's a script
language.  So grub2 does not measure the configuration, it measures
the control flow.

Now several features are implemented using the grub script language.
Selecting the next kernel to boot via grub2-reboot for example.  Also
boot counting.  So the control flow can be different from boot to boot,
depending on how the kernel was picked and what value the boot counter
has, leading to different measurements.

Also the same config file can lead to different measurements with
different grub versions, when the menu entries generated by blscfg
change.

> Glibly, if you don't want a config change, don't run grub2-mkconfig :)
> We don't run mkconfig on the system after install because it doesn't
> change - it only get run to change something.

So installed systems can have different config files.  When the default
grub config changes a Fedora N install upgraded to Fedora N+1 will
differ from a fresh Fedora N+1 install.

> And if you update configuration, you'd want to know that things
> changed - that's the whole point of logging it.

Depends.  Some things clearly matter (root uuid, ...).  Some things not
so much (menu timeout, menu hidden/shown, ...).

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

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Petr Pisar]

V Mon, Oct 10, 2022 at 09:41:52AM +, Mattia Verga via devel napsal(a):
> Indeed, you're right. I thought those were support files not directly
> consumed by the main program itself. I'll add an explicit perl dependency.
> 
You don't need to add an explicit run-time dependency on perl. It
(/usr/bin/perl) is already found by rpmbuild. Bear in mind that "perl" and
"/usr/bin/perl" (resolves to "perl-interpreter" package) are two different
packages. perl-interpreter is feature-wise a subset of perl and it is good
enough for the mpcorb2edb.pl script.

Acutally styding mpcorb2edb.pl reveals that it executes other program which
you should explicitly run-require:

curl (line 251)
gzip (line 258)

> I'm now facing a build failure on EPEL, which I can't figure out:
> /usr/bin/ld: lilxml.o (symbol from plugin): undefined reference to
> symbol 'xmlMalloc@@LIBXML2_2.4.30'
> /usr/bin/ld: /usr/lib64/libxml2.so.2: error adding symbols: DSO missing
> from command line
> 

That says that lilxml.o object file (found in a static liblilxml.a library)
refers to an xmlMalloc symbol. But no library (the -l options) passed to the
linker command:

gcc -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  -L/usr/lib -L/opt/X11/lib 
-L../../libastro -L../../libip -L../../liblilxml -o xephem aavso.o annotmenu.o 
broadcast.o calmenu.o closemenu.o compiler.o coordsmenu.o datamenu.o db.o 
dbmenu.o earthmap.o earthmenu.o fallbacks.o favmenu.o formats.o fsmenu.o 
gallerymenu.o glance.o gsc.o gscnet.o helpmenu.o homeio.o hznmenu.o indimenu.o 
imregmenu.o jpeg2pm.o jupmenu.o listmenu.o mainmenu.o marsmenu.o marsmmenu.o 
moonmenu.o moviemenu.o msgmenu.o netmenu.o objmenu.o obslog.o patchlevel.o 
plot_aux.o plotmenu.o preferences.o progress.o ps.o query.o rotated.o satmenu.o 
saveres.o scope.o sites.o skybinary.o skyeyep.o skyfifos.o skyfiltmenu.o 
skyfits.o skyhist.o skyip.o skylist.o skytoolbar.o skyviewmenu.o solsysmenu.o 
splash.o srchmenu.o sunmenu.o time.o tips.o trailmenu.o uranusmenu.o ucac.o 
usno.o versionmenu.o webdbmenu.o xe2.o xe3.o xephem.o xmisc.o -lXm -lXt -lXext 
-lXmu -lX11 -lastro -lip -llilxml -ljpeg -lpng -lz -lm -lssl

actually defines that symbol. Thus the linker reported an error.

For a user's convenience, the linker searched system libraries
and found /usr/lib64/libxml2.so.2 to be defining the system.

Hence a solution is patch a xephem build script in order to add -lxml2 to the
linker flags used when linking xephem executable. You should report this bug
to xephem upstream.

-- Petr


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F38 proposal: RPM Sequoia (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/RpmSequoia

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

Change RPM to use [https://sequoia-pgp.org/ Sequoia] based OpenPGP
parser instead of it's own, flawed and limited implementation.

== Owner ==
* Name: [[User:pmatilai| Panu Matilainen]]
* Email: pmati...@redhat.com


== Detailed Description ==
For the last 20 years or so, RPM has used a home-grown OpenPGP parser
for dealing with keys and signatures. That parser is rather infamous
for its limitations and flaws, and especially in recent years has
proven a significant burden to RPM development. In order to improve
security and free developer resources for dealing with RPM's "core
business" instead, RPM upstream is in the process of deprecating the
internal parser in favor of [https://sequoia-pgp.org/ Sequoia PGP]
based solution written in Rust.
At this point the change is mostly invisible in normal daily use.

== Feedback ==


== Benefit to Fedora ==

The main, direct benefit to Fedora is improved security and
standards-compliance (RFC-4880) in one of the corner-stones of the
whole distribution. Longer term, we can expect better error messages
and other functional improvements regarding key and signature
handling.

== Scope ==
* Proposal owners:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]
** Build rpm with --with-crypto=sequoia
** Watch out for the unexpected

* Other developers:
** Help [https://bugzilla.redhat.com/show_bug.cgi?id=2087499
package/review rpm-sequoia]

* Release engineering: [https://pagure.io/releng/issue/11077 #11077]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally overlaps with
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
which has effectively the same effect on rpm.

== How To Test ==

In general, normal rpm/dnf use provides sufficient test coverage. For
more advanced testers: try signing and verifying with different keys
and their subkeys, using different algorithms etc.

== User Experience ==
For normal usage, the change is quite invisible. The notable exceptions are
- Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
in line with the stronger crypto settings proposed elsewhere for F38)
- Key import may accept some previously rejected keys, in part due to
limitations of old parser etc but in particular, the old
implementation verifies self-signatures at import time whereas Sequoia
verifies them at time of use.
- Key import may reject some previously accepted keys due to better validation.

== Dependencies ==

The change introduces one new direct dependency:
[https://github.com/rpm-software-management/rpm-sequoia/ rpm-sequoia].
The rpm-sequoia package also takes over other crypto besides OpenPGP,
currently Sequoia uses nettle as its low-level crypto provider, but
work is underway to
[https://gitlab.com/sequoia-pgp/sequoia/-/merge_requests/1361 support
openssl in Sequoia], and the plan is to have Sequoia in Fedora use
that once it becomes available. This plan
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EY5VVR2VPKSISHRANZTK2HYA6RP6345L/
has support of the crypto team].

== Contingency Plan ==

* Contingency mechanism: Revert back to the internal PGP parser
* Contingency deadline: Beta release
* Blocks release? No

== Documentation ==

There's not much in the way of documentation as there's not much to
document, except for the deprecation of the internal parser:
https://github.com/rpm-software-management/rpm/issues/1935

rpm-sequoia build instructions can be found in
https://github.com/rpm-software-management/rpm-sequoia/

== Release Notes ==



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Update on libsoup 3 migration

[Michael Catanzaro]

Hi developers,

An update on the libsoup 3 migration change proposal. I had previously 
proposed:


https://fedoraproject.org/wiki/Changes/libsoup_3:_Part_Two

This proposal was rejected by FESCo, and I've decided not to put forth 
any alternate proposal. Accordingly, we're done with downstream work on 
libsoup 3 migration and will not retire the libsoup 2 package as 
previously proposed. We will still orphan it after Fedora 38 is 
branched, but if you want to keep libsoup 2 alive, you are allowed to 
do so. Beware: it is a security-sensitive network library that is no 
longer maintained upstream.


Michael

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

Unschedule for Tuesday's FESCo Meeting (2022-10-11)

[Miro Hrončok]

There are no topic to be discussed in the FESCo meeting
Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat.

Hence I decided to cancel it.

I will chair the next meeting.

= Discussed and Voted in the Ticket =

Nonresponsive maintainer: Pete Travis immanetize
https://pagure.io/fesco/issue/2866
APPROVED (+2,0,-0)

FESCo Policy missing: Package Rename Policy
https://pagure.io/fesco/issue/2874
APPROVED (+5,0,-0)

Change: PHP 8.2
https://pagure.io/fesco/issue/2875
APPROVED (+8,0,-0)

Fedora 37: Retire non-installable packages still requiring Python 3.10
https://pagure.io/fesco/issue/2876
APPROVED (+7,0,-0)

Change: SWIG 4.1.0
https://pagure.io/fesco/issue/2877
APPROVED (+7,0,-0)


For more complete details, please visit each individual
issue.

If you would like to have the meeting and add something to the agenda,
you can reply to this e-mail, file a new issue at
https://pagure.io/fesco or e-mail me directly. Note
that added topics may be deferred until the following meeting.

--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpm pulls in a dependency on perl in a noarch subpackage

[Mattia Verga via devel]

Il 10/10/22 15:46, Petr Pisar ha scritto:
> I'm now facing a build failure on EPEL, which I can't figure out:
>> /usr/bin/ld: lilxml.o (symbol from plugin): undefined reference to
>> symbol 'xmlMalloc@@LIBXML2_2.4.30'
>> /usr/bin/ld: /usr/lib64/libxml2.so.2: error adding symbols: DSO missing
>> from command line
>>
> That says that lilxml.o object file (found in a static liblilxml.a library)
> refers to an xmlMalloc symbol. But no library (the -l options) passed to the
> linker command:
>
> gcc -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  -L/usr/lib -L/opt/X11/lib 
> -L../../libastro -L../../libip -L../../liblilxml -o xephem aavso.o 
> annotmenu.o broadcast.o calmenu.o closemenu.o compiler.o coordsmenu.o 
> datamenu.o db.o dbmenu.o earthmap.o earthmenu.o fallbacks.o favmenu.o 
> formats.o fsmenu.o gallerymenu.o glance.o gsc.o gscnet.o helpmenu.o homeio.o 
> hznmenu.o indimenu.o imregmenu.o jpeg2pm.o jupmenu.o listmenu.o mainmenu.o 
> marsmenu.o marsmmenu.o moonmenu.o moviemenu.o msgmenu.o netmenu.o objmenu.o 
> obslog.o patchlevel.o plot_aux.o plotmenu.o preferences.o progress.o ps.o 
> query.o rotated.o satmenu.o saveres.o scope.o sites.o skybinary.o skyeyep.o 
> skyfifos.o skyfiltmenu.o skyfits.o skyhist.o skyip.o skylist.o skytoolbar.o 
> skyviewmenu.o solsysmenu.o splash.o srchmenu.o sunmenu.o time.o tips.o 
> trailmenu.o uranusmenu.o ucac.o usno.o versionmenu.o webdbmenu.o xe2.o xe3.o 
> xephem.o xmisc.o -lXm -lXt -lXext -lXmu -lX11 -lastro -lip -llilxml -ljpeg 
> -lpng -lz -lm -lssl
>
> actually defines that symbol. Thus the linker reported an error.
>
> For a user's convenience, the linker searched system libraries
> and found /usr/lib64/libxml2.so.2 to be defining the system.
>
> Hence a solution is patch a xephem build script in order to add -lxml2 to the
> linker flags used when linking xephem executable. You should report this bug
> to xephem upstream.
>
> -- Petr

Thanks!

Still, I'm surprised I hit this only in EPEL, while on Fedora everything
was built fine.

Mattia

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

Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)

[Clemens Lang]

Hi Ben,

Ben Cotton  wrote:


Within Fedora package set, this has no impact as everything is already
using sufficiently strong crypto. Third party repositories / packages
could be signed with insecure crypto, and those may require working
around with --nosignature. However this incidentally overlaps with
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2
which has effectively the same effect on rpm.


Note that the StrongCryptoSettings3Forewarning2 proposal recently failed to
gather enough votes to be accepted, so it will likely not be happening (or
not in this form) for Fedora 38.

Additionally, crypto-policies would have supported switching to LEGACY to
allow installation of non-conforming RPMs, so you should at least provide a
method to also install such old RPMs, ideally while still verifying the old
SHA-1 signature rather than ignoring it completely.


HTH,
Clemens

--
Clemens Lang
RHEL Crypto Team
Red Hat


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

Re: Capstone (was: Re: Orphaned packages looking for new maintainers)

[drago01]

On Mon, Oct 10, 2022 at 11:11 AM Richard W.M. Jones  wrote:
>
> On Mon, Oct 10, 2022 at 10:31:24AM +0200, Miro Hrončok wrote:
> > capstone  orphan, rebus, ret2libc  1 weeks 
> > ago
>
> [Affecting lots of packages]
>
> This is a disassembly library / framework used by qemu.  It seems like
> it has two maintainers so I guess it's not really an orphan, but I can
> take the package if neither of the two existing maintainers wants to
> become owner.
>

Its FTBS because of the java bindings (removed deps): see
https://koji.fedoraproject.org/koji/taskinfo?taskID=92887668 /
https://koji.fedoraproject.org/koji/getfile?taskID=92887668&volume=DEFAULT&name=mock_output.log&offset=-4000
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Capstone (was: Re: Orphaned packages looking for new maintainers)

[Jonathan Wright via devel]

I have some packages that rely on this so I'm happy to jump on as a
co-maintainer.  Giving someone else a chance to take lead but if no one
else does I'll pick it up.

On Mon, Oct 10, 2022 at 1:57 PM drago01  wrote:

> On Mon, Oct 10, 2022 at 11:11 AM Richard W.M. Jones 
> wrote:
> >
> > On Mon, Oct 10, 2022 at 10:31:24AM +0200, Miro Hrončok wrote:
> > > capstone  orphan, rebus, ret2libc  1
> weeks ago
> >
> > [Affecting lots of packages]
> >
> > This is a disassembly library / framework used by qemu.  It seems like
> > it has two maintainers so I guess it's not really an orphan, but I can
> > take the package if neither of the two existing maintainers wants to
> > become owner.
> >
>
> Its FTBS because of the java bindings (removed deps): see
> https://koji.fedoraproject.org/koji/taskinfo?taskID=92887668 /
>
> https://koji.fedoraproject.org/koji/getfile?taskID=92887668&volume=DEFAULT&name=mock_output.log&offset=-4000
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


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

Re: Orphaned packages looking for new maintainers

[Lyes Saadi]

Does anyone know what happened to python-yapsy?

I'm considering taking it if no one else wants to, since I have a 
package in COPR depending on it.


Regards,
Lyes Saadi

Le 10/10/2022 à 10:31, Miro Hrončok a écrit :

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for 
sure

that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the 
affected
packages or a package that depends on one. Please adopt the affected 
package or

retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets 
retired.


Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2022-10-10.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

     Package  (co)maintainers   
Status Change


Falcon    orphan   1 
weeks ago
amora orphan   4 
weeks ago
blueberry nonamedotc, orphan, rathann  4 
weeks ago
brewtarget    orphan   0 
weeks ago
capstone  orphan, rebus, ret2libc  1 
weeks ago
containerd    go-sig, gotmax23, orphan 0 
weeks ago
csound    orphan   1 
weeks ago
espresso-ab   avigne, orphan   5 
weeks ago
geompp    orphan   3 
weeks ago
geteltorito   orphan   4 
weeks ago
giada orphan   3 
weeks ago
gimp-focusblur-plugin orphan   5 
weeks ago
gmqcc orphan   5 
weeks ago
golang-github-beevik-etree    go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-crewjam-httperr go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-crewjam-saml    go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-dchest-uniuri   go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-logr-stdr   eclipseo, go-sig, orphan 2 
weeks ago
golang-github-magefile-mage   go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-russellhaering- go-sig, mgoodwin, nathans,   2 
weeks ago

goxmldsig orphan
golang-github-timberio-datemath   go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
golang-github-ua-parser-uap   go-sig, mgoodwin, nathans,   2 
weeks ago

   orphan
hct   avigne, orphan   5 
weeks ago
kelbt orphan   5 
weeks ago
llvm11.0  orphan, tstellar 0 
weeks ago
moby-engine   go-sig, gotmax23, orphan 0 
weeks ago
monobristol   orphan   5 
weeks ago
nautilus-search-tool  orphan   3 
weeks ago
origin    go-sig, orphan, tdawson  5 
weeks ago
owl-lisp  huzaifas, orphan 4 
weeks ago
perl-Parse-Debian-Packages    orphan   5 
weeks ago
php-psr-http-client   orphan   5 
weeks ago
pinpoint  orphan   3 
weeks ago
pt-astra-sans-font    orphan   4 
weeks ago
pt-astra-serif-font   orphan   4 
weeks ago
python-APScheduler    orphan, zuul 1 
weeks ago
python-PyRSS2Gen  orphan   0 
weeks ago
python-cached_property    adamwill, orphan 0 
weeks ago
python-charon orphan   2 
weeks ago
python-coreapi    orphan   5 
weeks ago
python-coreschema   

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 10. 10. 22 21:05, Lyes Saadi wrote:

Does anyone know what happened to python-yapsy?


https://pagure.io/fesco/issue/2866

--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Orphaned packages looking for new maintainers

[Sandro]

On 10-10-2022 10:31, Miro Hrončok wrote:

brewtargetorphan


Taken.

"Open source and home-brewed beer...two great things that go great 
together!" [linux.com]


What could possibly go wrong... Co-brewers welcome! New brew for rawhide 
coming soon.


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

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

So, just to add some data... sidetags are cleaned up via a cron job that
calls: 

/usr/sbin/koji-sidetag-cleanup --empty-delay=14 --old-delay=30

So, it should have only deleted it if it was empty after 14 days, but it
looks like it deleted it with things tagged into it. ;( 
Would you be willing to file a koji bug on this? 
( https://pagure.io/koji ) or if you prefer I can. 

On Mon, Oct 10, 2022 at 02:08:26PM +0200, Adam Williamson wrote:
> On Mon, 2022-10-10 at 21:02 +0900, Mamoru TASAKA wrote:
> > Zdenek Dohnal wrote on 2022/10/10 17:17:
> > > Hi all,
> > > 
> > > I maintain qpdf in Fedora, which recently got a new major release 
> > > version, which breaks compatibility with other packages, so I created a 
> > > side tag for other maintainers to use for building, and then releasing it 
> > > altogether in rawhide.
> > > 
> > > However the side tag:
> > > 
> > > f38-build-side-58658
> > > 
> > > got automatically deleted, even when it had builds connected to it 
> > > already. Documentation [1] does not mention any automatic side-tags 
> > > cleanup and its deadlines.

We should update the docs. We did announce adding this. 

> > > Although packagers can create a new side tag easily, I found it 
> > > inconvenient for maintainers, because the synchronization among the 
> > > maintainers can take weeks to finish the rebuild and release the update 
> > > and automatic removal without notice (do excuse me if I missed a 
> > > notification email about this - I have many filters and it could end up 
> > > somewhere where I wasn't able to find it) prolongs this process.
> > > 
> > > What I would like to propose are the following options:
> > > 
> > > A) don't do side-tag cleanups after a specific time frame, but only when 
> > > the specific event happens - branching, GA, EOL - it can be consuming to 
> > > our resources, but maintainer are still able to remove the side tags 
> > > manually in case it contains a big set of packages and AFAIK the process 
> > > itself is not such spread in usage...

Side tags are actually pretty costly on the server end. It means every
single time a build lands in the parent tag they have to have their
rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up
as quickly as we can, but no quicker. :) 

> > > 
> > > or
> > > 
> > > B) do a side-tags cleanup and mention it in the documentation together 
> > > with specification what the removal's time frame is, so maintainers can 
> > > act accordingly

We should do this in any case. 

> > > or
> > > 
> > > C) (my preferred) Koji or releng (depends on whether the cleanup happened 
> > > automatically or manually) will send an email to a side tag creator with 
> > > 'Hi, your side tag is going to expire - do you need it?' Or with 
> > > automaton - 'use this command to prolong it.' And if there is no response 
> > > or if the creator approves, remove the side tag.

Doable, but more notifications and things to deal with. 

Note that sidetag cleanup has a newer option we aren't using yet too: 

  --inactive-delay=DAYS
delete tags inactive for DAYS (no build was un/tagged
there)

We could perhaps use this.

> > IMO basically side-tag is not expected to exist for such a long time, 
> > side-tag requester should
> > take effort to merge it into main buildroot within, say, one week at most.
> 
> I'm not sure this is always going to be realistic. We are increasingly
> encouraging folks to do big complicated rebases in side tags rather
> than breaking Rawhide or Branched for days at a time; sometimes this
> might take more than a week. I don't want folks to be discouraged from
> using side tags and just go back to breaking Rawhide because of this
> kind of cleanup.

I agree... I'm open to adjusting the cleanup script, but I do think we
should limit sidetags somewhat. 

We should in any case document and fix the empty thing. 

kevin


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Kevin Fenzi]

Oh, also I forgot to mention... 

If your sidetag is deleted, you can just request a new one, tag the old
builds back into it and be back in business. I realize that that could
be anoying if you told people a specific one and then had to make a new
one, but it's not like those builds are lost. 

kevin


signature.asc
Description: PGP 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue