Re: convert everything to rpmautospec?

[Ralf Corsépius]

Am 07.04.24 um 17:15 schrieb Zbigniew Jędrzejewski-Szmek:

Hi everyone,

I'm revisting the topic of rpmautospec because I was doing some work
on various packages, and it's annoying that some packages are using
rpmautospec and others are not.

All my packages have been converted, so in day-to-day work, I don't
even think about %changelog. When working with other packages, I'll
forget to update the Relase and/or %changelog. Today I was rebasing
some pull requests in pagure, and the _only_ conflicts that I had were
about Release and %changelog.

I think it's time to switch to rpmautospec completely.
Thus, the proposal:
- new packages MUST use rpmautospec
- packagers SHOULD convert their packages
- provenpackagers MAY convert existing packages
   (e.g. when they want to push some fix or separately from other
work)
- people submitting pull requests against src.fp.o MAY also
   include a conversion in the pull request and packagers SHOULD
   merge it.

(FTR, 'rpmautospec convert' does the conversion, incl. the commit
to dist-git. Manual conversion should not be used.)

No This would be truly silly and stupid.

Ralf



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

Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump

[Ralf Corsépius]

Am 01.03.24 um 10:29 schrieb Michael J Gruber:

Am Fr., 1. März 2024 um 10:19 Uhr schrieb Ralf Corsépius :




Am 01.03.24 um 09:34 schrieb Michael J Gruber:

Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius :


Hi,

I intend to update gumbo-parser to 0.12.1 in rawhide.
This comes along with an soname bump libgumbo to libgumbo.so.2

This requires a rebuilt of several dependent packages, AFAICT:
claws-mail
litehtml
mupdf
perl-HTML-Gumbo
python3-PyMuPDF
qpdfview
zathura-pdf-mupdf


This was the list of packages depending on gumbo for f39.

In rawhide, for reasons, I don't know, python3-PyMuPDF and
python3-PyMuPDF do not seem to depend on gumbo, anymore.


Grr, this was meant to be "python3-PyMuPDF and zathura-pdf-mupdf".



I'll try to rebuild these packages on side-tag f41-build-side-84865
(Please, bear with me, I haven't used side-tags, before. I couldn't find
any usable docs on how to use them)

Preliminary tests indicate, something unrelated to libgumbo.so.* has
changed with these packages (Probably mupdf), causing gpdfview to FTBFS
and dependency changes in rawhide.


Interesting. I wasn't aware of that dependency - I guess I have to
re-run detection more often.


The version of mupdf in rawhide seems to have dropped libmupdf-third,
which seems to be the origin of qpdfview's FTBFS.

I don't know, if this change is intentional or happened by accident.


Yes, that is what I had tried to explain. mupdf still depends on
tesseract, gumbo etc, but packages depending on mupdf do not need to
build against those, only against mupdf, unless they require the other
ones directly, of course.

I have a working local mockbuild for qpdfview now. 

Me too ;-)

Removing all references to -lmupad-third from qpdfview.spec was 
sufficient to work-around the FTBFS.


BTW: f40 also is affected by the FTBFS.


How do you test the
fitz plugin?


No idea. All I did was to address the FTBFS ;)


(BTW: qpdfview needs to remove deprecated patchN, too.)

I know ;)

I would suggest you to  apply your patches to qpdfview to rawhide, ASAP?
I'd then pick them up and add qpdfview (w/ your patches) to my side-tag.

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

Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump

[Ralf Corsépius]

Am 01.03.24 um 09:34 schrieb Michael J Gruber:

Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius :


Hi,

I intend to update gumbo-parser to 0.12.1 in rawhide.
This comes along with an soname bump libgumbo to libgumbo.so.2

This requires a rebuilt of several dependent packages, AFAICT:
claws-mail
litehtml
mupdf
perl-HTML-Gumbo
python3-PyMuPDF
qpdfview
zathura-pdf-mupdf


This was the list of packages depending on gumbo for f39.

In rawhide, for reasons, I don't know, python3-PyMuPDF and 
python3-PyMuPDF do not seem to depend on gumbo, anymore.



I'll try to rebuild these packages on side-tag f41-build-side-84865
(Please, bear with me, I haven't used side-tags, before. I couldn't find
any usable docs on how to use them)

Preliminary tests indicate, something unrelated to libgumbo.so.* has
changed with these packages (Probably mupdf), causing gpdfview to FTBFS
and dependency changes in rawhide.


Interesting. I wasn't aware of that dependency - I guess I have to
re-run detection more often.


The version of mupdf in rawhide seems to have dropped libmupdf-third, 
which seems to be the origin of qpdfview's FTBFS.


I don't know, if this change is intentional or happened by accident.


qpdfview.spec will need some changes and will most probably lose the
direct dependency on gumbo, tesseract etc. I'll look into that today,
or over the weekend at the latest. In particular, qpdfview would not
have needed a rebuild against gumbo etc if it had been built against
mupdf shared already.


Give me a couple of hours - I am working on this right now.

AFAICS, the only problem qpdfview has is mupdf-third.


And no, side-tags don't hurt, they are fun :)
Only caveat: permissions, i.e. who can build into which side-tags. I
ended up with commit rights to all mupdf dependencies at that time.
That's a none-issue for a pp, of course.
I don't know - I am a proven-packager and have almost universal 
permissions ;-)


Ralf
--
___
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 gumbo-parser to 0.12.1/libgumbo SONAME bump

[Ralf Corsépius]

Hi,

I intend to update gumbo-parser to 0.12.1 in rawhide.
This comes along with an soname bump libgumbo to libgumbo.so.2

This requires a rebuilt of several dependent packages, AFAICT:
claws-mail
litehtml
mupdf
perl-HTML-Gumbo
python3-PyMuPDF
qpdfview
zathura-pdf-mupdf

I'll try to rebuild these packages on side-tag f41-build-side-84865 
(Please, bear with me, I haven't used side-tags, before. I couldn't find 
any usable docs on how to use them)


Preliminary tests indicate, something unrelated to libgumbo.so.* has 
changed with these packages (Probably mupdf), causing gpdfview to FTBFS 
and dependency changes in rawhide.


Ralf
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Ralf Corsépius]

Am 24.02.24 um 10:12 schrieb Samuel Sieb:

On 2/24/24 00:47, Ralf Corsépius wrote:

Am 24.02.24 um 01:36 schrieb Samuel Sieb:

On 2/23/24 15:38, Sérgio Basto wrote:

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:



Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been
retired.
Some group you have installed has that package listed in it.

Ah, this likely explains why neither "dnf repoquery" nor "dnf group
list" could find "multican".


  The comps
groups need to be cleaned out and that's just a warning.

Well, ... IMHO, most about comps and groups is in an embarrassing
unusable shape.


No match for group package "baekmuk-ttf-batang-fonts"

[snip]

No match for group package "util-linux-user"

I got these ones , is something on my rpm db ?


I am seeing these on another machine, too.


I expect you would see that on all machines.

No.  Well, sort of.  As mentioned, those are packages that have been 
removed from the distro, but are still listed in the comps groups. 
dnf checks the installed groups for packages that need to be updated 
and can't find these ones.

Really? How do I check for which groups I have installed?

At least I haven't found any way to check for them, neither with rpm 
nor with dnf.


dnf group list --installed


# dnf group list --installed
Last metadata expiration check: 4:04:39 ago on Sun 25 Feb 2024 01:48:48 
PM CET.

Installed Environment Groups:
   Xfce Desktop
Installed Groups:
   Administration Tools
   LibreOffice
   Fonts
   Hardware Support

# dnf system-upgrade --release=40 download
...
No match for group package "paktype-ajrak-fonts"
No match for group package "eosrei-emojione-fonts"
No match for group package "google-noto-sans-phags-pa-fonts"
No match for group package "multican"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "layla-thuluth-fonts"
No match for group package "layla-digital-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "google-noto-looped-thai-fonts"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "layla-arcyarc-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "gimp-heif-plugin"
No match for group package "kalapi-fonts"
No match for group package "ibus-bogo"
No match for group package "samyak-devanagari-fonts"
No match for group package "scim-sayura"
No match for group package "lohit-malayalam-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "layla-basic-arabic-fonts"
No match for group package "layla-diwani-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "nafees-web-naskh-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "layla-ruqaa-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "layla-boxer-fonts"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "fontawesome-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "layla-koufi-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
...


My actual problem seems to be not being able to get rid of the 
"installed groups".


"dnf group remove " apparently uninstalls all packages from this 
.


This is not what I want. I want to remove the comps-groups from my 
system, because of the harmful effects they obviously have.


Ralf
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Ralf Corsépius]

Am 24.02.24 um 01:36 schrieb Samuel Sieb:

On 2/23/24 15:38, Sérgio Basto wrote:

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:



Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been
retired.
Some group you have installed has that package listed in it.

Ah, this likely explains why neither "dnf repoquery" nor "dnf group
list" could find "multican".


  The comps
groups need to be cleaned out and that's just a warning.

Well, ... IMHO, most about comps and groups is in an embarrassing
unusable shape.


No match for group package "baekmuk-ttf-batang-fonts"

[snip]

No match for group package "util-linux-user"

I got these ones , is something on my rpm db ?


I am seeing these on another machine, too.

No.  Well, sort of.  As mentioned, those are packages that have been 
removed from the distro, but are still listed in the comps groups.  dnf 
checks the installed groups for packages that need to be updated and 
can't find these ones.

Really? How do I check for which groups I have installed?

At least I haven't found any way to check for them, neither with rpm nor 
with dnf.



Finally, another issue:
...
Error:
 Problem: conflicting requests
  - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
  - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from fedora 
conflicts with intel-media-driver provided by 
intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree

  - problem with installed package intel-media-driver-23.4.3-1.fc39.x86_64
  - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages)


I see 2 potential issues in there:
1. I think, I once "dnf swapped" these packages => Does "dnf 
system-upgrade" handle "swapped" packages correctly?


2. Why does dnf system-upgrade wants to pull-in a i686 package in this 
case? IMO, this doesn't make sense.



Ralf
--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Ralf Corsépius]

Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been retired.
Some group you have installed has that package listed in it.
Ah, this likely explains why neither "dnf repoquery" nor "dnf group 
list" could find "multican".


 The comps 
groups need to be cleaned out and that's just a warning.
Well, ... IMHO, most about comps and groups is in an embarrassing 
unusable shape.


Ralf


--
___
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Ralf Corsépius]

# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?
--
___
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

[Ralf Corsépius]

Am 21.02.24 um 18:50 schrieb Maxwell G:

Report started at 2024-02-21 17:04:45 UTC

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



perl-Cache-FastMmap   iarnell, orphan  0 weeks ago

Taken for Fedora.

A whole bunch of further packages I maintain, depend on it.

Ralf
--
___
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: Doubts on /etc/mock/fedora-40-*.cfg

[Ralf Corsépius]

Am 16.02.24 um 12:00 schrieb Ralf Corsépius:

Hi,

today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along

/etc/mock/fedora-40-x86_64.cfg
and
/etc/mock/fedora-40-i386.cfg

Now, I'm wondering about config_opts['package_manager']

fedora-40-*.cfg includes templates/fedora-branched.tpl
which sets
config_opts['package_manager']=dnf

This is unlike fedora-rawhide-*.cfg which sets
config_opts['package_manager']=dnf5

I.e. all fc40 packages having been built before fedora-40*.cfgs were 
introduced, were using "dnf", while packages being built from now on 
will be using "dnf"


Typo: This was meant to be
"... were using "dnf5", ... will be using "dnf".


Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?

Ralf

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

Doubts on /etc/mock/fedora-40-*.cfg

[Ralf Corsépius]

Hi,

today, mock-core-configs-40.1-1.fc39.noarch landed, bringing along

/etc/mock/fedora-40-x86_64.cfg
and
/etc/mock/fedora-40-i386.cfg

Now, I'm wondering about config_opts['package_manager']

fedora-40-*.cfg includes templates/fedora-branched.tpl
which sets
config_opts['package_manager']=dnf

This is unlike fedora-rawhide-*.cfg which sets
config_opts['package_manager']=dnf5

I.e. all fc40 packages having been built before fedora-40*.cfgs were 
introduced, were using "dnf", while packages being built from now on 
will be using "dnf"


Shouldn't fedora-40*.cfgs set config_opts['package_manager']=dnf5 ?

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

[rpms/rt] PR #2: use Droid Sans fonts from distro packages

[Ralf Corsépius]

corsepiu commented on the pull-request: `use Droid Sans fonts from distro 
packages` that you are following:
``
I'll have a look at the proposed font-path changes, but I'll definitely will 
not apply %autosetup changes, because I don't consider them to be helpful.

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/rt/pull-request/2
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Font-AFM] PR #4: Do not depend on files from /usr/share

[Ralf Corsépius]

corsepiu closed without merging a pull-request against the project: 
`perl-Font-AFM` that you
are following.

Closed pull-request:

``
Do not depend on files from /usr/share
``

https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/4
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Font-AFM] PR #4: Do not depend on files from /usr/share

[Ralf Corsépius]

corsepiu commented on the pull-request: `Do not depend on files from 
/usr/share` that you are following:
``
I've applied a differerent hack to work around this dnf5 regression.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/4
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Convert-Color] PR #1: Do not depend on files from /usr/share

[Ralf Corsépius]

corsepiu commented on the pull-request: `Do not depend on files from 
/usr/share` that you are following:
``
I do not agree with this patch nor with the new Guidelines

The package directly accesses this file by its path, which is why this file is 
required.
I.e. letting the package require a package instead of the file would introduce 
regressions.

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Convert-Color/pull-request/1
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The new Change discussion process is painful

[Ralf Corsépius]

Am 13.09.23 um 12:19 schrieb Sandro:

On 13-09-2023 08:09, Adam Williamson wrote:

 From there, it's up to people where they see and respond to them. If
more people are responding in discourse than on the mailing list, that
would seem to suggest that there*is*  a reason to announce things
there...


I'm quite sure Matthew (mattdm) would disagree with above statement. The 
idea was/is, iirc, to only announce on both channels, but have the 
discussion take place on Discourse.


And I could not disagree more with this.

So, making this pick & mix is definitely not the intention and it has 
already proven futile in a previous mishap.


I think, discourse should be dropped, ASAP. It isn't helpful.

Ralf
___
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: KDE and GNOME Join Hands To Add Payments To Turn Flathub Into a Store for the Linux Desktop

[Ralf Corsépius]

Am 04.09.23 um 03:48 schrieb Ryan Bach via devel:

Ryan Bach via devel wrote:

First of all, as has been pointed out by others, the headline is misleading,
since KDE and GNOME are not actually parties to the proposal and since the
proposal was not even accepted.

Secondly, IMHO, allowing fee-charging downloads is an anti-feature of an
application repository that I specifically do not want. One of the nicest
features of GNU/Linux is that I can just open the package manager and
download whatever I want without having to pay anything.

And finally, Red Hat trying to monetize the Desktop would be the worst
nightmare. I do not want my desktop GNU/Linux to be "monetized" by anyone,
neither by Red Hat nor by any other company.

 Kevin Kofler

What is so wrong about buying open source software?


A lot. It's effectively cheating to your users.


Ralf
___
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: koji: No space left on device

[Ralf Corsépius]

Am 01.08.23 um 17:14 schrieb Lubomír Sedlář:


It should be possible as self service:
koji tag-build f37-updates-candidate perl-Calendar-Simple-2.0.3-1.fc37
(If you can trigger the tagging by building, Koji should let you tag it
directly too.)


Great, thanks! This indeed did the job!

Ralf
___
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: koji: No space left on device

[Ralf Corsépius]

Am 01.08.23 um 16:55 schrieb Fabio Valentini:

On Tue, Aug 1, 2023 at 4:49 PM Ralf Corsépius  wrote:


Hi,

Right now, I have a package built in koji, which is in failed and
success state at the same time:

Cf.

https://koji.fedoraproject.org/koji/buildinfo?buildID=2267652

The link above redirects to
https://koji.fedoraproject.org/koji/taskinfo?taskID=104215785

Which contains:
...
OSError: [Errno 28] No space left on device: '/var/tmp/koji/tasks/6001'

The net result of all this is the package being in inconsistent state in
koji and bodhi.


The state isn't inconsistent, the build task failed.

No.

https://koji.fedoraproject.org/koji/packageinfo?packageID=2790
tells the built was successful.

Also, I received a "completed" email.

And, in fact the build apparently completed successfully because
https://koji.fedoraproject.org/koji/buildinfo?buildID=2267652
lists the rpms.

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

koji: No space left on device

[Ralf Corsépius]

Hi,

Right now, I have a package built in koji, which is in failed and 
success state at the same time:


Cf.

https://koji.fedoraproject.org/koji/buildinfo?buildID=2267652

The link above redirects to
https://koji.fedoraproject.org/koji/taskinfo?taskID=104215785

Which contains:
...
OSError: [Errno 28] No space left on device: '/var/tmp/koji/tasks/6001'

The net result of all this is the package being in inconsistent state in 
koji and bodhi.



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

koji: BuildError: error retrieving sources

[Ralf Corsépius]

Hi,

Trying to go after an FTBFS, I am once again, facing a weird koji build 
errors:


From https://koji.fedoraproject.org/koji/taskinfo?taskID=103995751
...
BuildError: error retrieving sources, mock exited with status 56; see 
root.log for more information

...

From https://kojipkgs.fedoraproject.org//work/tasks/5751/103995751/root.log
...
DEBUG util.py:442:  curl: (56) OpenSSL SSL_read: OpenSSL/3.0.8: 
error:0A00010B:SSL routines::wrong version number, errno 0

...

WTH?

Ralf
___
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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Ralf Corsépius]

Am 26.07.23 um 15:55 schrieb Solomon Peachy via devel:

On Wed, Jul 26, 2023 at 09:45:13AM +0200, Ralf Corsépius wrote:

It could be "my bubble", but for me, in all these fwupd is around, it has
never, ever worked on any piece of HW for me.


Most of the stuff I have that is updated through fwupd are peripherals
[1] that are independent of the system vendor.

That said, my two primary systems are a Lenovo laptop and an HP
workstation that are fully supported by fwupd/lvfs,


My (older) lenovo laptop and my HPE Micro-Server are obviously not.


and the UEFI dbx
stuff works on all of the remaining physical systems (including servers)
To my big surprise, for the first time ever, today fwupd installed a dbx 
update on one of my machine - Now, I am still wondering why it didn't do 
so on another, similar machine ;)



[1] Off the top of my head: Logitech wireless stuff, Jabra conference
 speaker, synaptics fingerprint sensor, (Samsung?) NVME storage, and
This is the second time, somebody mentions Samsung NVMEs were supported. 
Well, what shall I say.


I have several of them (and Samsung SATA SSDs), but so far, I always had 
to resort to other means of updating their firmware (Windows+Magician or 
iso-images), because fwupd would not want to update.


Ralf
___
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: Macros in side-tag

[Ralf Corsépius]

Am 26.07.23 um 13:46 schrieb Vít Ondruch:

I think that Perl folks are using something aka %perl_bootstrap. Not 
sure if this is just for historic reasons and they could eventually 
migrate to regular bootstrap method.


No, it's not historical. Perl has cyclic dependencies. To break them, 
some perl modules are built twice.


Ralf
___
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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Ralf Corsépius]

Am 26.07.23 um 08:48 schrieb Dominik 'Rathann' Mierzejewski:

On Wednesday, 26 July 2023 at 06:23, Ralf Corsépius wrote:

Am 23.07.23 um 00:39 schrieb Neal Gompa:

Actually, why wouldn't this be used everywhere?


Because fwupd only works on a small set of machines?


Define small. :)


Almost none?

It could be "my bubble", but for me, in all these fwupd is around, it 
has never, ever worked on any piece of HW for me.


Ralf
___
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: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

[Ralf Corsépius]

Am 23.07.23 um 00:39 schrieb Neal Gompa:

Actually, why wouldn't this be used everywhere?


Because fwupd only works on a small set of machines?

Ralf
___
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: NTFS corruption with Fedora 37 and 38

[Ralf Corsépius]

Am 25.07.23 um 13:29 schrieb Michael Schwendt:

Trying to figure out what has changed in Fedora land that causes NTFS
corruption for some time. This is with default workstation with GNOME
Shell auto-mounting external storage media when plugging them in.

A ticket in bugzilla suggests there has been a changed from ntfs-3g to ntfs3:

https://bugzilla.redhat.com/2182206
( udisks switched to kernel ntfs3 driver instead of ntfs-3g for mounting ntfs 
since the kernel 6.2 update )

The current state of development is highly dangerous.
It could be random coincidence[1], but since Sunday (the date I updated 
kernel-6.4.4), I had 2 serious NTFS corruptions on an external USB-disk.


Win11 was able to repair the first one (Fedora was not), but the second 
one was fatal. Both Linux and Win11 refused any operation on the file 
system. I resorted to reformating.


Ralf

[1] I've only sporadically used NTFS, before, but for a couple of weeks, 
I had to use it more frequently.

___
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: Orphaning packages (was LibreOffice packages)

[Ralf Corsépius]

Am 01.07.23 um 14:28 schrieb Peter Robinson:

On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:


On 01/07/2023 13:36, Chris Adams wrote:

A lot of the corporate world has gone to the "cloud"



don't have to worry about local backups of important documents and
spreadsheets, they get sharing with minimal effort, they can access
things from their mobile devices, etc.


And voluntarily hand over all the corporate secrets to Google and
Microsoft. Brilliant idea.


This sort of comment is off topic, 

It definitely is not off-topic.

It is the core of the problem esp. big US companies tend to ignore.

May-be you guys are not aware of there are tendencies to legally 
prohibit such "cloud solutions" in many countries?



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

Re: What is Fedora?

[Ralf Corsépius]

Am 22.06.23 um 16:08 schrieb Stephen Gallagher:

On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen  wrote:


On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:


Hi all,

Obviously many will have seen:

https://www.redhat.com/en/blog/furthering-evolution-centos-stream

and see, where EL (contributors like you of fedora/EPEL) have been knocked down:

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

Let us face it our efforts with the Fedora project are not valued and it is a 
means nothing to the
new corporate IBM/Red Hat enterprise systems that we have to struggle to get 
access to srpms, to
make a community. What is community now to Red Hat?


My interpretation of the blog post, combined with recent actions
towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as
the new "Fedora" for basing future versions of RHEL.


Just to interject, this is an incorrect interpretation. 


But is Red Hat still commited to open source and to the freedom of software?

I feel no and feel cheated and betrayed.


Ralf
___
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: (lack) of koji stability

[Ralf Corsépius]

Am 16.06.23 um 16:38 schrieb Fabio Valentini:

On Fri, Jun 16, 2023 at 4:37 PM Chris Kelley  wrote:


Mine just failed with this, which doesn't look great:

   File "", line 225, in makedirs
OSError: [Errno 28] No space left on device: 
'/var/tmp/koji/tasks/996/102220996/local/work'


On Fri, 16 Jun 2023 at 15:31, Ralf Corsépius  wrote:


Hi,

I am facing (seemingly non-deterministic) FTBSes in builds, which
flawlessly build local mocks.

On top of that, a couple of minutes ago, koji reported:

   File "/usr/lib/python3.11/site-packages/koji/daemon.py", line 1492, in
runTask
  response = (handler.run(),)
  ^
File "/usr/lib/python3.11/site-packages/koji/tasks.py", line 335, in run
  return koji.util.call_with_argcheck(self.handler, self.params,
self.opts)
 ^^ ...

WTH is going on?


It looks like one of the x86 koji builders has run out of disk space.
It's already been reported: https://pagure.io/releng/issue/11484


Thanks. The situation meanwhile, seems to have been fixed.

Unlike thoughout the whole day, yesterday, all of my builds meanwhile 
finished without any apparent problems (Neither non-deterministic FTBSes 
nor koji-errors).


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

(lack) of koji stability

[Ralf Corsépius]

Hi,

I am facing (seemingly non-deterministic) FTBSes in builds, which 
flawlessly build local mocks.


On top of that, a couple of minutes ago, koji reported:

 File "/usr/lib/python3.11/site-packages/koji/daemon.py", line 1492, in 
runTask

response = (handler.run(),)
^
  File "/usr/lib/python3.11/site-packages/koji/tasks.py", line 335, in run
return koji.util.call_with_argcheck(self.handler, self.params, 
self.opts)

   ^^ ...

WTH is going on?

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

[rpms/perl-FCGI] PR #2: Conditionalize client tests

[Ralf Corsépius]

corsepiu commented on the pull-request: `Conditionalize client tests` that you 
are following:
``
I do not agree neither with this patch nor with the attitude behind it.

It has always been Fedora's convention to "test to the max" and not to cripple 
packages, which are providing self tests.

Besides that, disabling fcgi/fcgi tests is not a clever idea, because in Fedora 
mod_perl had been deprecated, leaving fcgi as the only option.


``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-FCGI/pull-request/2
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Class-Autouse] PR #1: Update Makefile.PL to not use Module::Install::DSL

[Ralf Corsépius]

corsepiu commented on the pull-request: `Update Makefile.PL to not use 
Module::Install::DSL` that you are following:
``
Jitka, I do not understand the part below of your patch. Could you elaborate?

# diff --git a/perl-Class-Autouse.spec b/perl-Class-Autouse.spec
index c0f9d92..3206101 100644
--- a/perl-Class-Autouse.spec
+++ b/perl-Class-Autouse.spec
@@ -33,6 +33,8 @@ BuildRequires:  perl(UNIVERSAL)
 BuildRequires:  perl(vars)
 
 BuildRequires:  perl(inc::Module::Install)
+BuildRequires:  perl(Module::Install::Metadata)
+BuildRequires:  perl(Module::Install::WriteAll)
 
 # for xt tests
 %if %{with xt_tests}

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Class-Autouse/pull-request/1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-05-09)

[Ralf Corsépius]

Am 11.05.23 um 09:09 schrieb Zbigniew Jędrzejewski-Szmek:

On Thu, May 11, 2023 at 12:22:09AM +0200, Kevin Kofler via devel wrote:

Kevin Kofler via devel wrote:

So you folks were not happy with the feedback on the mailing list, so you
just made up a poll somewhere else.

[snip]

Was that poll ever announced on the mailing list? Or did you just expect
people to magically notice it has popped up in the FESCo ticket?


Sorry, looking at the FESCo ticket, I see the stats are actually just your
subjective interpretation of the mailing list replies. Since I do not know
who you counted in what category, I cannot tell whether your interpretation
is correct or not.


Mattdm put in the work to go over replies and count people's sentiment.
If you think he did a bad job, you can do your own calculation. I
doubt you'd get wildly different results. Please post them here.


I am lacking words to express my sentiments about how MattDM and FESCO 
are treating Fedora, to say the least.


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

[rpms/perl-Type-Tiny] PR #1: Add conditions for build with/without big frameworks

[Ralf Corsépius]

corsepiu commented on the pull-request: `Add conditions for build with/without 
big frameworks` that you are following:
``
I am hesitant, because I fail to understand the rationale behind it and am 
close to consider it "featuritis".


``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Type-Tiny/pull-request/1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Ralf Corsépius]

Am 21.04.23 um 16:15 schrieb Solomon Peachy via devel:

On Fri, Apr 21, 2023 at 11:42:20AM +0200, Aleksandra Fedorova wrote:



In all seriousness, I would advise you to hang out at the current
discussion.fedoraproject.org and feel the vibe a bit.


You kinda just demonstrated my point -- "hanging out at 
and feel the vibe" is going to take time, attention, and distruption.


Absolutely.

The proposal is harmful to Fedora and likely based on the distorted view 
of somebody lacking of expericence on practical distribution work.


Ralf
___
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: Unable to install locally built rpms

[Ralf Corsépius]

Am 28.02.23 um 10:34 schrieb Kamil Paral:


That's most certainly this problem:
https://ask.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/31594
 



Yes, it certainly is this problem.

AFAICT, the cause seems to be my old gpg-signing key (created 2013) is 
using "digest algo 2" signature digests (whatever this means).


I don't understand these security measures much, but creating a new key 
using modern tools should be sufficient to resolve this.


Which tools whould you suggest? So far, for me, all such attempts, using 
seahorse on fc37 failed.


Though the newly created key seems to comply to the new rules, now gpg 
-sign and rpm --resign fail:



# rpm --resign libmail-2.3.5-1.fc38.x86_64.rpm
libmail-2.3.5-1.fc38.x86_64.rpm:
gpg: signing failed: Permission denied
gpg: signing failed: Permission denied
error: gpg exec failed (2)

No idea, about what's going on.

See the article 
to learn how to detect and uninstall already affected packages present 
on your system first.


Well, ...

IMHO, this stuff + FC38's rpm and dnf are not in a release-ready shape.
Too many cryptic and non-understandable/non-readable error messages, far 
too radical changes, far too little backward compatibility and far too 
little help.


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

Unable to install locally built rpms

[Ralf Corsépius]

Hi,

[Resending here, because the test list doesn't allow me to post, there]

on f38, I am unable to install any locally built package (signed with a 
local key, I have been using for many years):


# rpm -U xpetri-0.4.8-0.fc38.x86_64.rpm
error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature, 
key ID a6b9312e: BAD

error: xpetri-0.4.8-0.fc38.x86_64.rpm cannot be installed

# rpm -qip xpetri-0.4.8-0.fc38.x86_64.rpm
error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature, 
key ID a6b9312e: BAD
error: xpetri-0.4.8-0.fc38.x86_64.rpm: not an rpm package (or package 
manifest)



# dnf install xpetri-0.4.8-0.fc38.x86_64.rpm
Last metadata expiration check: 1:30:47 ago on Tue 28 Feb 2023 06:25:45 
AM CET.

Dependencies resolved.
...
0.4.8-0.fc38  @commandline
...
Installing dependencies:
...
Downloading Packages:
(1/6): XXX.rpm ...
Total   1.2 MB/s 
| 130 kB 00:00

...
Problem opening package XXX.rpm
...
The downloaded packages were saved in cache until the next successful 
transaction.

You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED



Worse, after trying forcefully to install packages using rpm -U --nogpg 
this happens:


# rpm -qa
gpg-pubkey-d651ff2e-5dadbbc1
gpg-pubkey-8ff214b4-3afa5d46
gpg-pubkey-a6b9312e-5227e975
gpg-pubkey-94843c65-5dadbc64
error: rpmdbNextIterator: skipping h#   5
Header V4 DSA/SHA1 Signature, key ID 8ff214b4: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h#   6
Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
gpg-pubkey-5323552a-6112bcdc
...
=> nogpg is not ignored, as it is supposed to be.


What are people supposed to do?


Ralf
___
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: Shorter Shutdown Timer (System-Wide Change proposal)

[Ralf Corsépius]

Am 30.12.22 um 10:42 schrieb Peter Boy:




Am 30.12.2022 um 06:59 schrieb Nico Kadel-Garcia :


Am 28.12.22 um 11:49 schrieb Peter Boy:


It is a good idea to make the timeout configurable.  But the default timeout 
for servers must remain unchanged.


My problem is not "defined timeouts" it is systemd delaying shutdowns
for no obvious reasons.

...

And as you asked: On my (bare metal) servers, Im am occasionally
experiencing delayed shutdowns in the order of several minutes.

This is simply inacceptable!


If it is not acceptable for you, configure it to your needs.


FWIW: Yesterday, I had an infinite shutdown hanger, which wasn't caused 
by systemd timers, I could only work around by a pressing the reset switch.


Unfortunatly, I don't know the cause, but apparently something related 
to a non-responsive nfs-connection.


Ralf
___
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: Shorter Shutdown Timer (System-Wide Change proposal)

[Ralf Corsépius]

Am 28.12.22 um 11:49 schrieb Peter Boy:


It is a good idea to make the timeout configurable.  But the default timeout 
for servers must remain unchanged.


My problem is not "defined timeouts" it is systemd delaying shutdowns 
for no obvious reasons.


And as you asked: On my (bare metal) servers, Im am occasionally 
experiencing delayed shutdowns in the order of several minutes.


This is simply inacceptable!

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

[rpms/perl-Mo] PR #1: Split Mouse/Moose and Golf parts to separate packages

[Ralf Corsépius]

corsepiu commented on the pull-request: `Split Mouse/Moose and Golf parts to 
separate packages` that you are following:
``
@mspacek  
I think there is a cut'n'pasto next to lines 33/34 inside of the diff:

%package Moose
Summary:Use Mouse instead of Mo

Shouldn't the summary read "Use Moose instead of Mo"?
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Mo/pull-request/1
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange FTBS

[Ralf Corsépius]

Am 09.12.22 um 11:53 schrieb Mamoru TASAKA:

Ralf Corsépius wrote on 2022/12/09 19:01:

Hi,

I am facing a FTBS when trying to rebuild povray due to SPDX-changes:



Not sure this is povray side bug or SDL2 side bug.


Neither am I ;)

Another observation:

Fedora 37's last successful build's build.log [1]
contains this log message:
...
 [Parsing...] ==
error: XDG_RUNTIME_DIR not set in the environment.
Couldn't initialize SDL: No available video device.
...


The same part in current build attempts build.logs contain this
 [Parsing...] ==
error: XDG_RUNTIME_DIR is invalid or not set in the environment.
libEGL warning: MESA-LOADER: failed to open swrast: 
/usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such 
file or directory (search paths /usr/lib64/dri, suffix _dri)

[many more identica libEGL warnings]
...

So, ... no SDL warning this time, but one from mesa/libEGL.

From what I can gather, formerly, "make check" seems to have failed 
hard as running povray failed to open SDL.
Now, povray starts and waits for input (AFAICT, mouse input is necessary 
and keyboard input doesn't work at all ;)


Makes me think there are several bugs interacting.
A packaging bug/dependency issue involving libEGL/mesa, a bug in SDL 
(keyboard input) and a povray issue.



Ralf


[1] 
https://kojipkgs.fedoraproject.org//packages/povray/3.7.0.10/7.fc37/data/logs/x86_64/build.log)

___
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

Strange FTBS

[Ralf Corsépius]

Hi,

I am facing a FTBS when trying to rebuild povray due to SPDX-changes:

- In local mock environments, building suddenly waits for keyboard input.
- In koji, building seemingly hangs and never times out (I killed a 
build job after 48h hours.


Surprising to me is, this package had built flawlessly and not seen 
major changes for years.


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

Ralf
___
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 a lot of (mostly) Go packages owned by @fpokorny

[Ralf Corsépius]

Am 23.11.22 um 12:20 schrieb Miro Hrončok:

Hello.

Based on my conversation with Fridolín Pokorný @fpokorny, I've removed 
them from their Fedora packages.


They left Red Hat and are no longer interested in maintaining Fedora 
packages.


I am wondering, why Red Hat/FESCO/... still hasn't found some "formal" 
successor regulations/proceedures to migitate such cases, provided they 
have happened many times before, in all the years, Fedora is around?


Ralf

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

[Ralf Corsépius]

Am 20.11.22 um 17:38 schrieb Miroslav Suchý:

Dne 19. 11. 22 v 12:37 Miro Hrončok napsal(a):

On 18. 11. 22 15:09, Miroslav Suchý wrote:

|Fun fact: the script with the checks runs on my notebook for 32 hours.|



That sounds pretty bad. What is the biggest bottleneck? Do you clone 
the repositories from dist-git, or use 
https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz ? 


It is not so bad. I am not sitting in front of the computer and waiting 
till the script finish. :) I just wanted emphasis that I cannot gather 
the data daily and the heuristics is already complicated.



Why don't you extract the License-field from *.rpms and check if they 
comply to the new rules?


Ralf
___
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: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

[Ralf Corsépius]

Am 25.10.22 um 16:05 schrieb Ben Cotton:

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

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.


IMHO, this proposal doesn't make any sense.

Fedora is a collection of packages, which all obey different sets of 
language dialects, have various different upstreams and care about 
Fedora to varying extents.


I.e. all Fedora can do is to switch on "modern" C-dialects as 
C-defaults, but that's all.


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

[Ralf Corsépius]

Am 05.10.22 um 17:33 schrieb Chris Murphy:

Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.

I have a very clear opinion - It's a fault and usability regression.

Ralf

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

Re: [fedora-arm] Heads-up / for discussion: dnf not working with 1G of RAM or less

[Ralf Corsépius]

Am 29.08.22 um 15:43 schrieb Dan Čermák:

I agree, this needn't block F37, but I still think that this should be
fixed. Unless I use microdnf, I cannot upgrade my VPS with 1GB RAM that
happily hosts my home page, which is quite a bummer and a bit of a shame
to be honest.
Are you trying to "dnf update" everything at once or "dnf update" one 
package after the other?


I am asking, because several years ago, the latter was the only way to 
update a system, which only used to have 512 RAM. It typically did not 
"bomb out" with dnf crashes, but with some package's installation 
process underneath of dnf running out of memory.


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

Re: Packages silently dropping approved changes

[Ralf Corsépius]

Am 25.08.22 um 23:00 schrieb Iñaki Ucar:

On Thu, 25 Aug 2022 at 19:15, Iñaki Ucar  wrote:


On Thu, 25 Aug 2022 at 18:34, Ralf Corsépius  wrote:


Am 25.08.22 um 13:19 schrieb Iñaki Ucar:


I assume their maintainers didn't do it on purpose, maybe it was
easier for a certain update, didn't have time to look into it and
weren't aware of the guideline. But this is very frustrating. Seeing
many hours of work just wiped out without any notice or explanation is
very frustrating.


In my case (freefem++), it was actually was a mixture of all.

To cut a long story short: This flexblas stuff doesn't "harmonize well"
with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.

Because of this, when going after freefem++'s regressions, years after
the flexiblas changes had been introduced, I inadvertedly and
accidentally reverted the flexblas related changes, because these
apparently do not work out with freefem++.


How exactly does flexiblas break freefem++? I see v4.10 was built just
fine. Then v4.11 reverted to openblas. If it works with openblas, I
see no reason to break with flexiblas, among other things because
openblas is the default backend. Moreover, arpack, superlu,
suitesparse and other BuildRequires link against flexiblas.


In fact, freefem++ was one of the easiest packages to adapt: you just
set the library, and it does nothing fancy nor too-clever to try to
discover anything. 

Then you haven't looked into details (build.log rsp. config.status).

flexiblas causes freefem's configure script to produce bogus results.


Here's a simple patch [1] and a successful scratch

build [2], with all checks passing. Please let me know if I'm missing
anything, but otherwise, I'll open a PR.

Please don't and also abstain from submitting pull requests.

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

Re: Packages silently dropping approved changes

[Ralf Corsépius]

Am 25.08.22 um 13:19 schrieb Iñaki Ucar:


I assume their maintainers didn't do it on purpose, maybe it was
easier for a certain update, didn't have time to look into it and
weren't aware of the guideline. But this is very frustrating. Seeing
many hours of work just wiped out without any notice or explanation is
very frustrating.


In my case (freefem++), it was actually was a mixture of all.

To cut a long story short: This flexblas stuff doesn't "harmonize well" 
with freefem++, rsp. more bluntly speaking, flexblas breaks freefem++.


Because of this, when going after freefem++'s regressions, years after 
the flexiblas changes had been introduced, I inadvertedly and 
accidentally reverted the flexblas related changes, because these 
apparently do not work out with freefem++.


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

Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)

[Ralf Corsépius]

Am 31.07.22 um 18:57 schrieb Richard Fontana:

There are so few non-legacy, today-commonly-used,
generally-accepted-as-FOSS licenses that are not viewed as
GPLv3-compatible that I think it might be better for Ansible to just
list those (the only one I can think of is EPL-2.0), or to list a
small set of recommended/acceptable commonly-used FOSS licenses.

I do not agree with this view and consider this decision not to be helpful.

These licenses might not be "commonly used", but if they are used, these 
are the controversal ones, that need to be looked into, exactly because 
they "not commonly used".


Provocant question: Do you want contributors to contact redhat-legal in 
such cases, as we were required to do in the early days of Fedora?


To me, this reads as a pretty nasty regression in Fedora's workflow, 
which should be reconsidered/reverted.


Ralf
___
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: empty reply from server error

[Ralf Corsépius]

Am 19.07.22 um 16:45 schrieb Globe Trotter via devel:

Thanks, btw, the command here says unknown command (see below).

Btw, the log is here: 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2004683


The trigger of this breakdown is the sped missing "BuildRequires: gcc"

However, I regret having to say this, this package's spec could use a 
major overhaul. It contains quite a of rpm-spec-anachronisms and 
unnecessary things.



Ralf
___
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: Once again, more than 8 days delayed notifications

[Ralf Corsépius]

Am 09.07.22 um 15:36 schrieb Stephen Smoogen:



On Sat, 9 Jul 2022 at 09:25, Ralf Corsépius <mailto:rc040...@freenet.de>> wrote:


Hi,

I thought the notification delay mess was fixed. Apparently, I was
wrong.



No, I believe the service which is behind these emails is called FMN. It 
is very fragile for multiple reasons where it falls over for different 
reasons all the time. It is the reason why it is on the top of being 
replaced by CPE in this quarter (aka by October-ish). Until that 
happens, please be aware that these notifications are likely to come in 
bursts as things go up and down. I would also suggest that turning off 
as many notifications as you can would help the load as one of the 
largest email problems Fedora Infrastructure has is the many people who 
have turned on getting email on a lot of events.


Why don't you turn this stuff off globally and send the guys behind it 
back to the drawing board?


In its present shape it's just dysfunctional and not helpful at all.

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

Once again, more than 8 days delayed notifications

[Ralf Corsépius]

Hi,

I thought the notification delay mess was fixed. Apparently, I was wrong.


I just received this:


Subject: corsepiu pushed 1 commit to rpms/perl-Sub-HandlesVia (rawhide)
Date: Sat,  9 Jul 2022 10:39:46 + (GMT)
From: notificati...@fedoraproject.org
...
Notification time stamped 2022-07-01 05:57:40 UTC
...



Ralf
___
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: proposal idea: EOL notifications

[Ralf Corsépius]

Am 06.07.22 um 17:44 schrieb Zbigniew Jędrzejewski-Szmek:

Hi,

In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
notification when a Fedora stops being supported. Various proposals
for online checks were discussed in the bug, but I think we might make
do with something much simpler.


I am not excited, because I feel it doesn't add any value to Fedora.

I am also concerned about the impact this may have on post-release 
usages of older fedoras and the fedora repos, i.e. to back-track issues 
popping up in newer releases.


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

Re: Fedora SCM requests on the weekend

[Ralf Corsépius]

Am 03.07.22 um 10:46 schrieb Benson Muite:

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


I feel, Fedora's leadership has forgotten, that Fedora is a 
international community project with people being located around the 
globe, which means there are quite a few people, who work on Fedora in 
their spare time, i.e. on "week ends" and on "US holidays".


Ralf
___
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: F37 proposal: Linux Firmware Minimization (late System-Wide Change proposal)

[Ralf Corsépius]

Am 02.07.22 um 18:27 schrieb Ben Cotton:



On Fri, Jul 1, 2022, 1:54 PM Ben Cotton > wrote:


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



This proposal has been withdrawn by the owners.


Any explanation why?

Ralf
___
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: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many announcements

[Ralf Corsépius]

Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek:

On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote:



It certainly is not true that the feedback was not considered by FESCo:
there was a long discussion on IRC, and FESCo members also participated in
the mailing list thread.


Yet, the outcome is diametrically opposed to the mailing list consensus.


I don't think it makes sense to restart the discussion here. I disagree


And I disagree with you.

This decision is such kind of harmful to Fedora, this decision should be 
reverted. This decision communicates the attitude of FESCO not caring 
about security, maintainablity and further related topics.



Personally, I see a lot of value in having Java packaged
for Fedora, and use it for my stuff.


So do I, but this doesn't invalidate the the thought of "bundling" and 
"static linkage" being a prime security risk.


Ralf
___
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: shotcut: problem with unpacked files, after changing from qmake to cmake

[Ralf Corsépius]

Am 23.06.22 um 18:59 schrieb Martin Gansser:

Hi,

I have changed the rpm spec file for shotcut [1] from qmake to cmake.
Now the program compiles to the end and fails when packaging it with the 
following error message:

Processing files: shotcut-debuginfo-22.06.07-1.fc36.x86_64
Provides: debuginfo(build-id) = 50b1149507c39b9362a2aebf0ccee415e68665a6 
shotcut-debuginfo = 22.06.07-1.fc36 shotcut-debuginfo(x86-64) = 22.06.07-1.fc36
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 
4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Recommends: shotcut-debugsource(x86-64) = 22.06.07-1.fc36
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/home/martin/rpmbuild/BUILDROOT/shotcut-22.06.07-1.fc36.x86_64
error: Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/lib/libCuteLogger.so-22.06.07-1.fc36.x86_64.debug
/usr/lib/libCuteLogger.so


RPM build errors:
 Installed (but unpackaged) file(s) found:
/usr/lib/debug/usr/lib/libCuteLogger.so-22.06.07-1.fc36.x86_64.debug
/usr/lib/libCuteLogger.so

How can I solve this error ?


Looks like this package's cmake stuff doesn't honor %{__libdir}

Ralf
___
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: What to do about this Koschei email?

[Ralf Corsépius]

Am 21.06.22 um 23:57 schrieb Scott Talbert:

Look at the timestamps in the body of the notification emails.  Are they 
far in the past?


Unfortunately, the Fedora notification system seems to be suffering from 
massive delays (e.g, several days) lately.


Throughout this week, I've received notification emails, which were 
delayed for about *one week*.


Bluntly said, in its present shape, Fedora notification are not helpful 
at all.


Ralf

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

Re: [RFC] Build tag in RPM: from NVR to NVRB

[Ralf Corsépius]

Am 18.06.22 um 13:05 schrieb Aleksandra Fedorova:

Hi, all,

I'd like to discuss how we can add Build tag in the RPM.

As one of the key points is to turn it into a common standard for rpm
packages across the ecosystem, the conversation is currently opened
upstream [1] and in RHEL Engineering. And I'd like to get Fedora
community on board.

This is not a finalized proposal and I think it is not ready yet to be
a Fedora Change.
But I want to start a conversation and ask for opinions. There are
also some open questions which need help, especially the requirements
around build reason. And alternative suggestions are welcome as well.

I've posted long version at
   https://discussion.fedoraproject.org/t/rfc-build-tag-in-rpms/39954

You can comment there (simply login with your FAS id) or here on the
mailing list.
And I am going to update that post with the new feedback.

Shorter version:

We'd like to introduce Build Number/Tag/Id in the rpm metadata.


I am strongly opposed to this proposal.

It is just useless featuritis and doesn't make any sense at all, breaks 
lots of tools/scripts, breaks 3rd party packaging conventions, and many 
more ...


Ralf
___
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: Archive value is out of time_t range

[Ralf Corsépius]

Am 06.06.22 um 16:38 schrieb Petr Pisar:


I believe that glibc payed a special attention to provide both ABIs. But that
does not apply to other libraries. Maybe it's not so important problem.
Proprietary software tends to bundle the libraries, externally relying only on
kernel and glibc.


How about dlopened libraries? I'd assume these can become problematic.

Ralf
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Ralf Corsépius]

Am 14.04.22 um 13:39 schrieb Kevin Kofler via devel:

Ralf Corsépius wrote:

I do not agree with this statement.  Like previous "Legacy SIGs" this is
a red herring to obfuscate RHATs lack of disinterest with topics, which
do not match into their business objectives.


I am also worried that this is just a delayed retirement, as it was for 32-
bit i686, where the SIG was very quickly declared a failure, without even
being given time to organize.


IMO, the 32bit "retirement" never was a serious "retirement" nor a 
serious attempt "to pass it to the community", either. Some people will 
find this rude, but I perceived as a long term planned assassination!


Ralf
___
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: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?

[Ralf Corsépius]

Am 13.04.22 um 20:05 schrieb David Cantrell:


The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.


I do not agree with this statement.  Like previous "Legacy SIGs" this is 
a red herring to obfuscate RHATs lack of disinterest with topics, which 
do not match into their business objectives.


Ralf
___
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: nothing provides mpich-devel(x86-64) = 3.4.1 needed by petsc-mpich-devel-3.16.5-2.fc37.x86_64

[Ralf Corsépius]

Am 11.04.22 um 19:33 schrieb Zbigniew Jędrzejewski-Szmek:

On Mon, Apr 11, 2022 at 03:37:04PM +0200, David wrote:

On 4/11/22 15:29, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Apr 11, 2022 at 02:36:57PM +0200, Ralf Corsépius wrote:

Hi,

apparently some broken packages have landed in rawhide:

DEBUG util.py:444:  Error:
DEBUG util.py:444:   Problem: conflicting requests
DEBUG util.py:444:- nothing provides mpich-devel(x86-64) = 3.4.1 needed
by petsc-mpich-devel-3.16.5-2.fc37.x86_64
DEBUG util.py:446:  (try to add '--skip-broken' to skip uninstallable
packages)

AFAIU, somebody has pushed an incompatible upgraded for mpich and forgotten
to take care about its dependency.


That someone would be me. But I wasn't aware that petsc binds
to an exact version of mpich. I see this was added by Antonio last year.
Antonio, why is this necessary? Isn't the so-version enough?

Zbyszek

This was added on my request as PETSc ensures that the MPI version is
exactly the same - and without the requires it fails at run time, rather
than at install time.

It is probably fine to patch out the check, but no one really knows ...


OK. I started rebuilds of petsc now.


Did you actually launch a build for rawhide?

I see your changes in git, but can't spot a build rawhide for in koji 
and petsc in rawhide is still broken.


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

nothing provides mpich-devel(x86-64) = 3.4.1 needed by petsc-mpich-devel-3.16.5-2.fc37.x86_64

[Ralf Corsépius]

Hi,

apparently some broken packages have landed in rawhide:

DEBUG util.py:444:  Error:
DEBUG util.py:444:   Problem: conflicting requests
DEBUG util.py:444:- nothing provides mpich-devel(x86-64) = 3.4.1 
needed by petsc-mpich-devel-3.16.5-2.fc37.x86_64
DEBUG util.py:446:  (try to add '--skip-broken' to skip uninstallable 
packages)


AFAIU, somebody has pushed an incompatible upgraded for mpich and 
forgotten to take care about its dependency.


Ralf
___
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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Ralf Corsépius]

Am 07.04.22 um 18:14 schrieb Robbie Harwood:

Robert Marcano via devel  writes:


Is this change only related to install media support for booting with
BIOS only? Would I be able to install newer Fedora releases using Legacy
PXE on BIOS only machines?


The intent is to indicate that new legacy installations are not
supported, regardless of how one gets there.  Mechanically, there are
few ways to actually *prevent* these installations[1] - rather, we send
a message that this is on its way out (i.e., deprecated) and that it's
time for users to consider migrating their setups.

So the direct answer is: yes, probably, if you're willing to work at it
hard enough.  But it wouldn't be supported.


Your answer once more confirms my impression on Red Hat's current role 
in Fedora: Red Hat is abusing Fedora is not willing to contribute to the 
community and is striving to get rid of the community (similar to RHAT's 
management faults wrt. CentOS)


That said, should this change happen, I will probably drop using und 
supporting fedora and switch to a different flavor of Linux. It's 
apparently what RHAT wants.


Ralf
___
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: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Ralf Corsépius]

Am 05.04.22 um 16:52 schrieb Ben Cotton:

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

== Summary ==
Make UEFI a hardware requirement for new Fedora installations on
platforms that support it (x86_64).  Legacy BIOS support is not
removed, but new non-UEFI installation is not supported on those
platforms.  This is a first step toward eventually removing legacy
BIOS support entirely.


Short, but hard and clear answer: No.

Ralf
___
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: Package downgrades on upgrade from F35 to F36 + categorized list

[Ralf Corsépius]

Am 24.03.22 um 18:07 schrieb Fabio Valentini:

On Thu, Mar 24, 2022 at 5:58 PM Ralf Corsépius  wrote:

(...)


Oh noes, the list isn't really getting shorter ...


It's Fedora's old release management flaw ;)

As usual at these times of the release cycle, Fedora 36 is in deep
freeze, i.e. package updates are not getting pushed, which causes
gradually causing them to pile up and "testers" wasting time on testing
outdated stuff.

That said, I am waiting for some packages to getting pushed for almost 4
weeks and me gradually getting angry at everybody being involved!


Did you send this just for TROLZ or did you want to contribute
something productive?
This is absolutely no troll, but a serious complaint about a long 
withstanding issue from FESCO, release-eng or whoever might be involved 
has ever addressed.




If it was the latter, I couldn't find it in your message. Sorry.
It's actually quite simple: There are dozens if not hundreds of unpushed 
updates pending due to the release freeze, which will be released at the 
very moment the freeze will be lifted.


The consequences are:
- You guys are testing outdated stuff
- After fedora goes gold, all these packages will be updated.

Ralf
___
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: Package downgrades on upgrade from F35 to F36 + categorized list

[Ralf Corsépius]

Am 24.03.22 um 17:51 schrieb Fabio Valentini:

On Fri, Mar 18, 2022 at 2:32 PM Fabio Valentini  wrote:


Hi all,

Yes, it's that time of the year again. Looks like it's not *that* bad
this time round, but the fact that this keeps happening probably means
some of our processes are broken ... (or, since some usernames are
attached to multiple entries in the list below, maybe it's just a lack
of understanding).


Oh noes, the list isn't really getting shorter ...


It's Fedora's old release management flaw ;)

As usual at these times of the release cycle, Fedora 36 is in deep 
freeze, i.e. package updates are not getting pushed, which causes 
gradually causing them to pile up and "testers" wasting time on testing 
outdated stuff.


That said, I am waiting for some packages to getting pushed for almost 4 
weeks and me gradually getting angry at everybody being involved!


Ralf
___
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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ralf Corsépius]

Am 10.03.22 um 12:26 schrieb Vitaly Zaitsev via devel:

On 10/03/2022 11:55, Alex wrote:

May I suggest to leave at least the telnet protocol in curl-minimal for
debugging purposes.


Telnet is an extremely vulnerable protocol. It must be disable.


It should not be used on a regular basis, but disabling in a tool is 
just non helpful fanatism.

___
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: VERY late notification emails

[Ralf Corsépius]

Am 28.02.22 um 14:45 schrieb Richard Shaw:

I almost wrote this a week ago but decided not to as it's been recently
discussed but this is really annoying. 6 days later is more than useless.


FWIW: I just received a bunch (ca. 10) of notifications with 5 days of 
delay.


Don't know if somebody just restarted something, but in its present 
shape, things still seem to be dysfunctional.


Ralf

___
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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ralf Corsépius]

Am 24.02.22 um 19:35 schrieb Daniel P. Berrangé:

On Thu, Feb 24, 2022 at 07:16:26PM +0100, Ralf Corsépius wrote:



If someone is setting up a personal private mirror, I struggle
to understand a reason why they would pick FTP over HTTP(S)
today.
Because an ftp server is much lighter and much easier to maintain than a 
fat httpd-server?



Perhaps someone will have a FTP only mirror that's
existed for years and simply haven't got around to enabling
HTTP, but addressing that is not an unreasonable expectation.


Almost. E.g. I am using a LAN-wide (anonymous-only) ftp server, I set up 
a long time ago and rarely touched since then.


Using httpd-server would simply be overkill for this use-case.


IMHO explicitly disabling FTP in dnf would be fine, as any fallout
could be easily dealt with by enabling HTTP. Just ensure we announce
such intent ahead of time via a Fedora feature proposal.
I don't agree. Not using a protocol on public dnf-servers is on thing, 
but removing the "ftp" protocol everywhere is just silly fanatism, IMHO.


Ralf
___
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: F37 Change: Curl-minimal as default (System-Wide Change proposal)

[Ralf Corsépius]

Am 24.02.22 um 19:05 schrieb Kevin Fenzi:

On Wed, Feb 23, 2022 at 10:19:33AM +0100, Vitaly Zaitsev via devel wrote:

On 22/02/2022 21:45, Peter Robinson wrote:

Does it make sense to keep FTP with most browsers obsoleting the
protocol due to lack of security?


Many Fedora mirrors still use FTP. You can check metalink file.


Odd. There shouldn't be any. Can you paste/post what you are seeing?

We disabled and removed all ftp:// urls in mirrormanager in 2016:
https://github.com/fedora-infra/mirrormanager2/issues/99#issuecomment-222630215


dnf isn't restricted to using "official" mirrors, but is also used for 
3rd party add-on-repos and for private repos.


For them, disabling ftp is pretty much a massive regression.

Ralf
___
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: Package notes feature causing build paths to be embedded

[Ralf Corsépius]

Am 27.01.22 um 10:46 schrieb Zbigniew Jędrzejewski-Szmek:


But the problem is more general than this too.  It also turns up in
some *.pc (pkgconf) files.

That's a bug too.


I think this change should be reverted until a cleaner way can be
found to implement it.

I'm all for making better, but please make concrete proposals.

Revert?


Just saying "revert, revert" because some corner case is not satisfied,
when a simple opt-out exists, is IMO not useful.
IMO, we are not talking about corner cases, about about a fundamental 
design flaw, which you, as I perceive it, are trying to play down.



Ralf
___
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: new systemd in rawhide

[Ralf Corsépius]

Am 10.12.21 um 15:13 schrieb Zbigniew Jędrzejewski-Szmek:

Some other replies in this thread assumed that the programs will crash.
I have no idea why you would assume that.
If properly implemented, such programs typically won't crash, they will 
"just not work" oder "error out".


Functionally, dlopening libraries, instead of dynamically linking really 
does not provide any advantages.



We're not complete idiots.With all due respect, tt's not the first time systemd communicates the 
attitude of blindly imitating MS-Windows. Whether you like it or not, 
this appears to be one of these cases.


Ralf
___
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: new systemd in rawhide

[Ralf Corsépius]

Am 10.12.21 um 10:40 schrieb Vitaly Zaitsev via devel:

On 10/12/2021 08:34, Zbigniew Jędrzejewski-Szmek wrote:

We also changed various libraries to be dlopened when actually used,
instead of being dynamically linked. The goal is to reduce the
required dependencies.

dl-opening instead of dynamic linkage doesn't remove these deps.

It only hides away the deps and moves them from "packaging" to run-time.


What happens if these libraries are not installed an cannot be dl-opened?


Programs will fail at run-time.

Openly said, I feel this is a massive regression and design flaw.

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

[rpms/perl-Font-AFM] PR #1: Use NimbusSans-Bold font for afm font metrics testing

[Ralf Corsépius]

corsepiu commented on the pull-request: `Use NimbusSans-Bold font for afm font 
metrics testing` that you are following:
``
I do not agree with any of these patches and will not apply them

Rationale: I consider using package deps instead of file deps to be insane and 
not helpful.

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Font-AFM/pull-request/1
___
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

[rpms/perl-Params-Util] PR #1: Use make macros

[Ralf Corsépius]

corsepiu commented on the pull-request: `Use make macros` that you are 
following:
``
Not OK with me.

I consider %make_build and %make_install to be short-sighted stupidities 
causing functional and usabilty regressions. 



``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Params-Util/pull-request/1
___
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

Re: [perl-Class-ReturnValue] Specify all dependencies

[Ralf Corsépius]

On 06/12/2012 11:15 AM, Petr Pisar wrote:

commit a4ca8b042cc0504051a24fe7e1efb7d87c86f29c
Author: Petr Písařppi...@redhat.com
Date:   Tue Jun 12 11:15:22 2012 +0200

 Specify all dependencies

  perl-Class-ReturnValue.spec |9 -
  1 files changed, 8 insertions(+), 1 deletions(-)
---
diff --git a/perl-Class-ReturnValue.spec b/perl-Class-ReturnValue.spec
index ea50888..efc6e80 100644
--- a/perl-Class-ReturnValue.spec
+++ b/perl-Class-ReturnValue.spec
@@ -10,8 +10,13 @@ BuildRoot:  
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
  Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo 
$version))
  BuildArch:noarch
  Source:   
http://search.cpan.org/CPAN/authors/id/J/JE/JESSE/Class-ReturnValue-%{version}.tar.gz
+BuildRequires:  perl(inc::Module::Install)
+# Run-time
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Data::Dumper)
  BuildRequires:perl(Devel::StackTrace)
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(Exporter)
+# Tests
  BuildRequires:perl(Test::More)

  %description
@@ -19,6 +24,7 @@ A return-value object that lets you treat it as as a boolean, 
array or object.

  %prep
  %setup -q -n Class-ReturnValue-%{version}
+rm -rf inc


Petr, stop this!

Forcing packages to use an external inc:Module::Install instead of 
bundled versions is not helpful.


All you are doing is to corrupt the module's build instructions.

Ralf


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Patches for CVE-2011-0009

[Ralf Corsépius]

On 01/27/2011 12:31 PM, Xavier Bachelot wrote:
 On 01/27/2011 12:43 AM, Xavier Bachelot wrote:
 On 01/26/2011 09:16 PM, Xavier Bachelot wrote:
 On 01/26/2011 12:00 AM, Xavier Bachelot wrote:
 Hi,

 I've been looking at the issue for both rt 3.6 and 3.8.
 I have a rather full featured patch for 3.8 and I took the Debian
 patch
 for 3.6. However, I'm not happy with 3.6, it's lacking the script to
 fix
 all the passwords. I'll try to come up with something better in the
 next
 few days. Here's my WIP for reference.

 Regards,
 Xavier

 Here are the updated patches against master and el5 branches. I only
 have an rt 3.6 to test against, so the 3.8 patch is not run time
 tested,
 but I'm confident.
 The only missing bit is a paragraph about the password mass-update
 script in the UPGRADING file for 3.6.

 Sorry, slightly wrong patches, it was missing the patch to the UPGRADING
 file. Here is a fixed one for 3.8. I've pushed the 3.6 patch to el5.

 http://koji.fedoraproject.org/koji/taskinfo?taskID=2744662
 https://admin.fedoraproject.org/updates/rt3-3.6.10-2.el5

 Ralf, Mark, I let you give a test at 3.8 on Rawhide/F14/F13 and EL6,
 respectively.

 Xavier, please don't try to rush it.

 I'm not trying to rush anything. I'm satisfied with the patches I have, so
 I've built the rpms for the OS release I'm running in production. I've
 indeed tested it locally. However I can't test against rawhide, F13, F14
 and EL6, because I don't have any RT instance with this releases. I
 obviously won't commit anything to this branches and let this for people
 that can actually test the patches.

 So far, from visual inspection only, I am not necessarily opposed to
 your patch but I like the debian patches more.

 Imho, the Debian patches are incomplete. It only fixes password hashes
 upon user login,
This exactly why I like them. They are working transparently without 
user or maintainer interaction.

 which is not enough to fix the security issue. You can't
 expect to force all users to log in and all hashes that have not been
 updated are still vulnerable to a brute force attack. The only real
 solution is to use the vulnerable-passwords script to mass update them.
Partially agreed. A mass update is the only way to assure this.

However, one can not expect maintainers to run this script, nor can we 
run this script during rpm updates.

That said, my current preference for Fedora 13 and 14 is a combination of
* Adopting Debian's patch.
* Adding the vulnerable-passwords script.

For Fedora 15 backporting from bestpractical's upstream (which is, 
AFAIU, you did) is feasible, because upgrading Fedora's will always 
require maintainer interaction.

In an ideal world, IMO, a solution would look differently:
Launching start up would perform a mass conversion.

BTW: Did you check if rt's upgrade scripts take care about this CVE (I 
haven't yet)?

 This script is missing with the Debian patches.
 My own patches were created using the commits from the 3.8-salted_password
 branch from RT's git repository, that I then adapted to target 3.6.

Ralf

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: rpms/perl-Algorithm-Dependency/devel perl-Algorithm-Dependency.spec, 1.19, 1.20

[Ralf Corsépius]

On 04/30/2010 03:06 PM, Marcela Mašláňová wrote:
 Author: mmaslano

 Update of /cvs/pkgs/rpms/perl-Algorithm-Dependency/devel
 In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv23471

 Modified Files:
   perl-Algorithm-Dependency.spec
 Log Message:
 Remove test.



 Index: perl-Algorithm-Dependency.spec
 ===
 RCS file: 
 /cvs/pkgs/rpms/perl-Algorithm-Dependency/devel/perl-Algorithm-Dependency.spec,v
 retrieving revision 1.19
 retrieving revision 1.20
 diff -u -p -r1.19 -r1.20
 --- perl-Algorithm-Dependency.spec29 Apr 2010 15:24:31 -  1.19
 +++ perl-Algorithm-Dependency.spec30 Apr 2010 13:06:45 -  1.20
 @@ -44,6 +44,8 @@ chmod -R u+w $RPM_BUILD_ROOT/*
   rm -rf $RPM_BUILD_ROOT

   %check
 +# remove not needed author test (failing anyway)
 +rm -rf t/99_pmv.t
   make test AUTOMATED_TESTING=1

   %files


Marcela, please revert this change and go after why this package is 
failing to build in your perl-branch.

I am inclined to think there is something wrong in your perl-branch.

Ralf

--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel