Re: Proposal: drop delta rpms (for real this time)

[Richard W.M. Jones]

It's also been a long time since I've seen any benefit.

Can anyone summarise quickly why delta RPMs don't work?  It seems like
they "obviously" should be possible, because there must be a lot of
commonality in the content of adjacent RPM versions ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
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: Proposal: drop delta rpms (for real this time)

[Gary Buhrmaster]

On Tue, Feb 21, 2023 at 8:48 PM Matthew Miller  wrote:

> What we're doing now — as has been the case for several years, already noted
> in the previous discussion — has very little end-user value.

While occasionally I have seen a small decrease in
the size of the files transferred (which certainly can
benefit some people some of the time), the total
elapsed time of the transaction has always ended
up being higher as the recreation of the original
rpm exceeds the time that it would have taken
me to just download the full new rpm (with an
admittedly reasonably high speed network
provider in my environment).

However, that is an end user experience.  What
about the mirror providers?  Even a small
percentage of bandwidth savings might be
useful for them (depending on their cost model)
at the scale(s) they may be operating.  Has
anyone asked those providers, or do all (or
most) now have a network cost structure
such that it does not matter?
___
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

Test upgrades from F37 to F38 - it will take you just a minute

[Miroslav Suchý]

Do you want to make Fedora 38 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveals 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F38FailsToInstall) 
reports:

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

Thank you

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Petr Pisar]

V Mon, Feb 20, 2023 at 11:16:24AM -0800, Gordon Messmer napsal(a):
> On 2023-02-20 02:06, Petr Pisar wrote:
> > I applaud the struggle for ensuring compatibility. However, I worry that it
> > will make downgrading RPM packages less feasible. Imagine a user who updates
> > a system, finds a regression in a library, attempts to downgrade the library
> > and it will result into downgrading later-built reverse dependencies only
> > because the library applied a (wrong) fix and the triplet has changed.
> > 
> > Do you know meaning of the numbers?
> 
> 
> I will say that there are bits that I do not understand:
> 
> https://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html
> https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
> 
> The documentation describes a system in which the library indicates the
> first interface version it supported, and the latest interface version it
> supports, as well as a revision counter that indicates changes in the source
> that do not change the interface.

I know these documents. However, I'm not sure that this:

> As far as I can tell, this manifests in a
> file name that ends in ".so.$(current - age).$(age).$(revision)", which
> seems like a complicated way to arrive at Semantic Versions.

i.e. how a soname and the file names are constructed is true. libtool
obviously behaves like that, but it's nowhere documented. I feel that it was
an attempt to introduce a versioning schema to enable multiple interfaces
(maybe borrowed from Solaris), but it was never fully implemented. One of the
consequences is that the age does not reflect in soname and that's the gap you
try to fill with your proposal.

> I don't know if "current" and "age" appear in the ELF headers.

They don't. In ELF headers is only a soname string (scanelf --soname
/usr/lib/...).  It's an opaque string without any structure. If the library
implements symbol versioning, then there are additional version strings. But
AFAIK those are always strings. Never comparable versions.

> I'm sympathetic to the idea that providing the entire version number is more
> strict than is necessary, but I'm not sure under what circumstances it is
> safe to provide less.  Are there cases where the version number is more or
> less than three dot-separated number sequences?

First there does not have to any symlinks. Then the symlinks do not have to
be substrings of themselves. And finaly those does not have to by
dot-delimited, digit-based, or exactly-3 components.

However, because ldconfig tool, which maintains ld-config.so's linker cache,
imposes some assumptions, in glibc reality those are always dot-delimitted
numbers after a soname. Though not always 3 components:

lrwxrwxrwx. 1 root root13 20. led  2022 /usr/lib64/libzip.so.5 -> 
libzip.so.5.4
-rwxr-xr-x. 1 root root134392 20. led  2022 /usr/lib64/libzip.so.5.4
lrwxrwxrwx. 1 root root15 22. led  2022 /usr/lib64/libzmq.so.5 -> 
libzmq.so.5.2.4
-rwxr-xr-x. 1 root root648896 22. led  2022 /usr/lib64/libzmq.so.5.2.4

I guess that library files which do not conform to the schema are cached by
ldconfig, but never maintained (= recreating symlinks) by ldconfig.

> If we always truncate to two, is that the correct thing to do for both
> versions with only two numbers and for versions with more than three
> numbers?
> 
You need correctly split soname from the version suffix. In the two examples
above it's:

sonameversion
-
"libzip.so.5" "4"
"libzmq.so.5" "2.4"

Than if you assume that the version is libtool based, then you can safely
handle it as a comparable version string (>= 2.4) and you can safely assume
that that second part of the version string ("2.4" -> "4) is a revision not
affecting ABI and so you can safely remove it (>= 2).

However, all of that are only my assumptions based on observations. One would
need to ask glibc and libtool maintainers to confirm that it indeed works like
that.

-- Petr


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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Artur Frenszek-Iwicki]

Tested on three different machines. No problems with transaction conflicts,
just some package downgrades:
- inxi-3.3.25-1.fc37 -> inxi-3.3.24-2.fc38 (version downgrade)
- fwupd-1.8.10-2.fc37 -> fwupd-1.8.10-1.fc38 (lower release number)

A.FI.
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Petr Pisar]

V Mon, Feb 20, 2023 at 11:48:26AM -0800, Gordon Messmer napsal(a):
> As there is some discussion of whether the ELF dependency generator should
> use the full version string presented by the library file name's suffix, or
> should assume a SemVer-style major.minor and truncate the requirement to the
> first two dot-separated numbers, questions about rpminspect come to mind:
> 
> I see that rpminspect is run in Fedora CI for updates.  For example,
> libnghttp2:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-888dfc8170
> https://artifacts.dev.testing-farm.io/627326f9-7f83-4d0b-aca0-68c50c5e9b09/
> 
> Looking at this result, I think I see one bug and one RFE.
> 
> First, the bug.  From these results, it looks like rpminspect is only
> comparing the primary package to the old build.  I do see a result for the
> package "nghttp2", but I don't see an rpminspect result for "libnghttp2". 
> Are sub-packages not tested, or are the results simply not exposed?  (Or am
> I simply missing the path to find them?)
> 
> Second, the RFE: I am assuming that this test raises an error if abidiff
> reports a breaking change between two packages (either a bumped soname, or a
> removed or changed symbol without an soname bump.)  In order to make the ELF
> dependency generator reliable if it truncates versions to a major.minor
> style version, would it be possible for the tooling to detect a
> backward-compatible change (a new symbol) that didn't also increment the
> major.minor version?
> 
> Should I report those in bugzilla, and if so, against what component?

I think David prefers .

-- Petr


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

Re: Proposal: drop delta rpms (for real this time)

[Kamil Paral]

On Tue, Feb 21, 2023 at 9:48 PM Matthew Miller 
wrote:

> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>

+1 from me. It will speed up the compose, and I haven't seen a positive
impact from deltarpms in a long time. They are rarely available and the
saved bandwidth is usually negligible (and reassembling of the rpm is
usually quite slow).
___
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: Proposal: drop delta rpms (for real this time)

[Neal Gompa]

On Wed, Feb 22, 2023 at 3:37 AM Richard W.M. Jones  wrote:
>
> It's also been a long time since I've seen any benefit.
>
> Can anyone summarise quickly why delta RPMs don't work?  It seems like
> they "obviously" should be possible, because there must be a lot of
> commonality in the content of adjacent RPM versions ...

They don't work because we compose updates wrong. Instead of building
on top of previous updates, we throw them away and rebuild from the
latest. Since we don't merge previous composes into a new compose, we
are missing too much stuff for DeltaRPMs to be continuously useful.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Proposal: drop delta rpms (for real this time)

[Neal Gompa]

On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller  wrote:
>
> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>
> ... and that ticket hasn't moved, because fixing it isn't trivial.
>
>
> What we're doing now — as has been the case for several years, already noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
>

Our tooling has been broken for a long time and contributions to that
tooling is just not going to happen since nobody can run this stuff
outside of Fedora infrastructure. It's a sad state of affairs indeed.

> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>

Please don't try to equate those things to DeltaRPMs, unless you're
trying to equate their general uselessness. OSTree and
"container-delta" stuff is not generally useful or applicable for
Fedora users and they won't be for a very long time.

And they might never be useful because OSTree's approach requires us
to use OSTree remotes (which we're killing for OCI remotes), and
there's no standard for "container-delta" since the baseline OCI
format isn't amenable to delta fetching.







--
真実はいつも一つ！/ Always, there's only one truth!
___
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 of catch to Catch2 v3

[Tom Hughes via devel]

As discussed a few weeks ago the Catch testing framework has
a slightly weird naming scheme, namely:

* Catch (v1.x, actually a branch in Catch2 repository)
* Catch2 v2.x
* Catch2 v3.x

Since Catch2 was released we have had catch1 and catch packages
to support both v1.x and v2.x users.

I have now added catch2 (for Catch2 v2.x) and upgraded the catch
package to Catch2 v3.x in rawhide and f38.

What this means is that if your package uses catch-devel to build
that you probably need to update your BuildRequire to catch2-devel
when you next build it - unless your upstream supports v3.x of
course.

Tom

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

Re: Proposal: drop delta rpms (for real this time)

[Steve Cossette]

Yeah I'd say +1 from here too. Was just wondering about this yesterday.

Le mer. 22 févr. 2023, 05 h 52, Kamil Paral  a écrit :

> On Tue, Feb 21, 2023 at 9:48 PM Matthew Miller 
> wrote:
>
>> But, I think it's time to move on. We have ostree and various
>> container-delta approaches. We should focus on those — and give DeltaRPMs
>> a
>> sad, fond farewell.
>>
>
> +1 from me. It will speed up the compose, and I haven't seen a positive
> impact from deltarpms in a long time. They are rarely available and the
> saved bandwidth is usually negligible (and reassembling of the rpm is
> usually quite slow).
>
> ___
> 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
>
___
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: Test upgrades from F37 to F38 - it will take you just a minute

[Steve Cossette]

Same here, lower version numbers for the following packages:

Downgrading:
 fwupd  x86_64 1.8.10-1.fc38   fedora
1.8 M
 fwupd-plugin-flashrom  x86_64 1.8.10-1.fc38   fedora
 26 k
 fwupd-plugin-modem-manager x86_64 1.8.10-1.fc38   fedora
 60 k
 fwupd-plugin-uefi-capsule-data x86_64 1.8.10-1.fc38   fedora
1.8 M

Le mer. 22 févr. 2023, à 05 h 07, Artur Frenszek-Iwicki <
s...@fedoraproject.org> a écrit :

> Tested on three different machines. No problems with transaction conflicts,
> just some package downgrades:
> - inxi-3.3.25-1.fc37 -> inxi-3.3.24-2.fc38 (version downgrade)
> - fwupd-1.8.10-2.fc37 -> fwupd-1.8.10-1.fc38 (lower release number)
>
> A.FI.
> ___
> 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
>
___
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

Orphaning python-clikit

[Tomáš Hrnčiar]

Hello,

I've orphaned python-clikit package. This was originally a part of 
poetry stack, but they switched to python-cleo. Since no other package 
depends on it, there is no need to keep it in the distro.


$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-clikit
(nothing)

Have a nice day,

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

[Test-Announce] Fedora 38 Branched 20230222.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 38 Branched 20230222.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20230219.n.0: anaconda-38.21-1.fc38.src, 20230222.n.0: 
anaconda-38.23.1-1.fc38.src
lorax - 20230219.n.0: lorax-38.6-3.fc38.src, 20230222.n.0: lorax-38.8-1.fc38.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/38

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_38_Branched_20230222.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Richard Hughes]

On Wed, 22 Feb 2023 at 12:03, Steve Cossette  wrote:
> Downgrading:
>  fwupd  x86_64 1.8.10-1.fc38   fedora 1.8 
> M

Mea culpa. I'm doing a new upstream release tomorrow, and will build
both as 1.8.11-1 -- I guess the drawbacks of %autorelease. From an
upgrade point of view it's harmless.

Richard.
___
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: Proposal: drop delta rpms (for real this time)

[Luna Jernberg]

Dislike -1

On 2/22/23, Steve Cossette  wrote:
> Yeah I'd say +1 from here too. Was just wondering about this yesterday.
>
> Le mer. 22 févr. 2023, 05 h 52, Kamil Paral  a écrit :
>
>> On Tue, Feb 21, 2023 at 9:48 PM Matthew Miller 
>> wrote:
>>
>>> But, I think it's time to move on. We have ostree and various
>>> container-delta approaches. We should focus on those — and give
>>> DeltaRPMs
>>> a
>>> sad, fond farewell.
>>>
>>
>> +1 from me. It will speed up the compose, and I haven't seen a positive
>> impact from deltarpms in a long time. They are rarely available and the
>> saved bandwidth is usually negligible (and reassembling of the rpm is
>> usually quite slow).
>>
>> ___
>> 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
>>
>
___
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

Fedora 38 compose report: 20230222.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-38-20230221.n.1
NEW: Fedora-38-20230222.n.0

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

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

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-38-20230222.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-38-20230222.n.0.iso

= DROPPED IMAGES =
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-38-20230221.n.1.iso
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-38-20230221.n.1.aarch64.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Luna Jernberg]

Did this 16th February and it worked then, other then a few packages
missing in F38 that was in F37 then mostly Google Fonts and RPM Fusion
stuff

On 2/22/23, Miroslav Suchý  wrote:
> Do you want to make Fedora 38 better? Please spend 1 minute of your time and
> try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveals
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
>
> The `--assumeno` will just test the transaction, but does not make the
> actual upgrade.
>
>
> In case you hit dependency issues, please report it against the appropriate
> package.
>
> Or against fedora-obsolete-packages if that package should be removed in
> Fedora 38. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F38FailsToInstall)
> reports:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
>
> Thank you
>
> Miroslav
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Steve Cossette]

I just tried on a second PC, and I see this too on this one:

Lmodx86_64 8.7.18-1.fc38
fedora258 k

Seems Lmod is of a lower version on Fedora 38 as well, compared to Fedora
37.

Le mer. 22 févr. 2023, à 04 h 30, Miroslav Suchý  a
écrit :

> Do you want to make Fedora 38 better? Please spend 1 minute of your time
> and try to run:
>
> # Run this only if you use default Fedora modules
> # next time you run any DNF command default modules will be enabled again
> sudo dnf module reset '*'
>
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo
> --enablerepo=updates-testing-modular) \
> --assumeno distro-sync
>
>
> This command does not replace `dnf system-upgrade`, but it will reveals
> potential problems.
>
> You may also run `dnf upgrade` before running this command.
>
> The `--assumeno` will just test the transaction, but does not make the
> actual upgrade.
>
>
> In case you hit dependency issues, please report it against the
> appropriate package.
>
> Or against fedora-obsolete-packages if that package should be removed in
> Fedora 38. Please check existing reports against
>
> fedora-obsolete-packages first:
>
> https://red.ht/2kuBDPu
>
> and also there is already bunch of "Fails to install" (F38FailsToInstall)
> reports:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=F38FailsToInstall
> Thank you
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Creating a F37 remix/spin LiveCD without a desktop environment (Resolved)

[Globe Trotter via devel]

I wanted to say that Neil is correct, below. Apparently, some packages were not 
being pulled in, and that was creating the problems. So, things appear to have 
changed a little bit, but in general,not that much for non-DE setups.

Best wishes!



On Sunday, February 19, 2023 at 09:25:50 PM CST, Neal Gompa 
 wrote: 





On Sun, Feb 19, 2023 at 9:33 PM Globe Trotter via devel
 wrote:
>
> Hello,
>
> Since about Fedora 20 or so, I have been rolling my own Fedora spin without a 
> desktop environment, and with openbox and slim (simple login manager). All 
> worked well, because I did not need to roll these that often, with dnf 
> upgrade on existing installations, except up until now when I need a new 
> LiveCD for a new machine coming online. I last successfully made a LiveCD 
> with Fedora 34.
>
> Recently, I went back to making a live cd for Fedora 37, and realized that 
> there is a new way of handling these: specifically, I have to install 
> env-group to resolve RH Bug:1891500.
>
> With an environment, it turns out one has to do something like
>
>
> @^lxde-desktop-environment
>
> but I do not want an environment.
>
> I tried putting this in, and removing all the LXDE things
>
> -@'Dial-up Networking Support'
> -@LXDE
> -@Fonts
> -@'LXDE Desktop'
> -@'Multimedia'
> -@base-x
> -@core
> -@fonts
> -@'Guest Desktop Agents'
> -@'Input Methods'
> -@'Printing'
> -@'Hardware Support'
> -lxpanel
> -lxlauncher
> -libfm
> -menu-cache
> -pcmanfm
> -lxde-common
>
> and this works, but not quite. I still get large components of the  LXDE 
> environment, slim (which I roll my personal rpm of) does not get started, and 
> I get a slower system.
> I tried explicitly getting rid of the following that I could see:
>
> -clipit
> -galculator
> -dnfdragora
> -dnfdragora-updater
> -xpad
> -icon
> -xarchiver
> -xscreensaver
> -gigolo
> -samba\*
> -firewall-config
> -firewalld
> -lx\*
>
> but still, there are lx\* things in the LiveCD.
>
> Can I get a LiveCD environment without all this, and with slim?
>

Yes, you can just avoid using environment groups altogether. The bug
you reference should not apply in your case.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: FTBFS bug filed, build already deleted

[Scott Talbert]

On Wed, 22 Feb 2023, Kevin Kofler via devel wrote:


Julian Sikorski wrote:

FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
build [2] has already been deleted. This is not ideal from maintainer
perspective as it effectively is a bug with no info provided whatsoever.
Not to mention being quite wasteful from the resources perspective as
mame builds take quite a while.
While not much can be done now, can we make sure that the mass rebuild
builds do not get garbage collected, or at least the build logs are
saved somewhere? Thanks.


This is a constantly recurring problem. I have run into this very
frequently. The retention period for failed build logs is way too short. It
needs to be at least 13 months (the approximate time we get to fix an FTBFS
bug before the package is retired).


I have to agree here.  There is nothing more frustrating as a contributor 
than going to investigate a FTBFS for a package and finding the logs are 
gone.


At the very least, the 'latest' failure logs should be retained for much 
longer.


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

Re: FTBFS bug filed, build already deleted

[Daniel P . Berrangé]

On Mon, Feb 20, 2023 at 06:46:31PM +0100, Fabio Valentini wrote:
> On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:
> >
> > Hello,
> >
> > FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> > build [2] has already been deleted. This is not ideal from maintainer
> > perspective as it effectively is a bug with no info provided whatsoever.
> > Not to mention being quite wasteful from the resources perspective as
> > mame builds take quite a while.
> > While not much can be done now, can we make sure that the mass rebuild
> > builds do not get garbage collected, or at least the build logs are
> > saved somewhere? Thanks.
> 
> As far as I know, at least some form of truncated build.log used to
> get attached when FTBFS bugs were filed after a mass rebuild ... maybe
> this time this wasn't possible, because bugs were reported *weeks*
> after the mass rebuild?

More often than not I've found the truncated build.log to be too
truncated to be sufficiently useful. Ignoring the current problem
of entirely missing logs, can we not attach the full *uneditted*
build.log + root.log to bugzilla in general ?

Yes, build.log can be quite large, but I've seen way bigger things
attached to BZ, so it ought to cope surely ? I prefer plain text
attachments, but if size is really a concern, even an xz compressed
log is better than a truncated log.

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

Self Introduction: Riya Bisht

[Riya Bisht]

Hello everyone,
I am a junior computer science student from India and have been using Linux as 
my main OS for about a year now.I love how Fedora works and would like to help 
this community by contributing. As I am new to the Fedora ecosystem and to get 
acquainted with it, I would like to start with testing and packaging work 
because I have always been curious about package management systems in Linux.

My previous work:
- EndeavourOS iso testing
- Fixed a few technical bugs for KDE
- Worked on virtual machines to test different Desktop Environments like 
Budgie, KDE, GNOME
- Built QT/QML apps
- Knows Python, C/C++, Git, Shell scripting
- Learnt about the open source ecosystem and attended a few online technical 
talks on FOSS

During my free time, I try to read Linux From Scratch and watch Open source 
events.
This concludes my introduction :)

I would be grateful if anyone could help me to get started with my Fedora 
journey and I'm excited about giving back to this open source community.

Thank you,
Riya Bisht
___
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

HyperKitty broken References and In-Reply-To headers (was: fedpkg: Failed to get repository name from Git url or pushurl)

[Eike Rathke]

Hi,

On Wednesday, 2023-02-22 00:46:19 +0200, Otto Liljalaakso wrote:

> Ok, I found the other parts of the thread now.
> Something strange is going on here - it seems that when Arthur replies,
> threading breaks and I see separate subthreads in Thunderbird.
> Also lists.fedoraproject.org seems to be similarly confused.

That's likely because
| User-Agent: HyperKitty on https://lists.fedoraproject.org/
writes broken References and In-Reply-To headers:

| References: <
|  
>
| In-Reply-To: <
|  
>

Note the doubled <<>> and folding line break after first <.

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


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

%dnl macro not available for epel-8 builds?

[Ron Olson]

Hi all,

I submitted a scratch build of Swift to Koji for EPEL 8 and it pretty much 
immediately failed, and looking at root.log I found:

DEBUG util.py:443:  error: line 71: Unknown tag: %dnl Source31:   
https://github.com/apple/swift-format/archive/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.tar.gz#/swift-format.tar.gz

Fedora and EPEL 9 builds all work, so I guess %dnl isn’t available on EPEL 8?

Thanks for any info!

Ron
___
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: Test upgrades from F37 to F38 - it will take you just a minute

[Steven A. Falco]

I got the following errors:

Error:
 Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires 
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
  - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
  - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64
 Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires 
libembree3.so.3()(64bit), but none of the providers can be installed
  - problem with installed package blender-1:3.4.1-2.fc37.x86_64
  - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository
  - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

I then tried removing blender and its dependencies, and I got the following 
downgrades:

 Lmodx86_64 8.7.18-1.fc38  
fedora 258 k
 autorandr   noarch 1.12.1-3.fc38  
fedora  43 k
 autorandr-bash-completion   noarch 1.12.1-3.fc38  
fedora 8.1 k
 cscope  x86_64 15.9-18.fc38   
fedora 286 k
 fwupd   x86_64 1.8.10-1.fc38  
fedora 1.8 M
 fwupd-plugin-flashrom   x86_64 1.8.10-1.fc38  
fedora  26 k
 fwupd-plugin-modem-manager  x86_64 1.8.10-1.fc38  
fedora  60 k
 fwupd-plugin-uefi-capsule-data  x86_64 1.8.10-1.fc38  
fedora 1.8 M
 gimpx86_64 2:2.10.32-7.fc38   
fedora  21 M
 gimp-devel  x86_64 2:2.10.32-7.fc38   
fedora 1.2 M
 gimp-devel-toolsx86_64 2:2.10.32-7.fc38   
fedora  20 k
 gimp-libs   x86_64 2:2.10.32-7.fc38   
fedora 526 k
 gputils x86_64 1.5.2-1.fc38   
fedora 2.2 M
 gputils-doc noarch 1.5.2-1.fc38   
fedora 1.9 M
 inxinoarch 3.3.24-2.fc38  
fedora 493 k

Steve

On 2/22/23 04:30 AM, Miroslav Suchý wrote:

Do you want to make Fedora 38 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveals 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F38FailsToInstall) 
reports:

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

Thank you

Miroslav


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

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Steven A. Falco]

On 2/22/23 10:28 AM, Steven A. Falco wrote:

I got the following errors:

Error:
  Problem 1: package opencolorio1-1.1.1-3.fc37.x86_64 requires 
libyaml-cpp.so.0.6()(64bit), but none of the providers can be installed
   - yaml-cpp-0.6.3-7.fc37.x86_64 does not belong to a distupgrade repository
   - problem with installed package opencolorio1-1.1.1-3.fc37.x86_64
  Problem 2: package blender-1:3.4.1-11.fc38.x86_64 requires 
libembree3.so.3()(64bit), but none of the providers can be installed
   - problem with installed package blender-1:3.4.1-2.fc37.x86_64
   - embree-3.13.5-3.fc37.x86_64 does not belong to a distupgrade repository
   - blender-1:3.4.1-2.fc37.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

I then tried removing blender and its dependencies, and I got the following 
downgrades:

  Lmod    x86_64 8.7.18-1.fc38  
fedora 258 k
  autorandr   noarch 1.12.1-3.fc38  
fedora  43 k
  autorandr-bash-completion   noarch 1.12.1-3.fc38  
fedora 8.1 k
  cscope  x86_64 15.9-18.fc38   
fedora 286 k


Please ignore the cscope downgrade.  I built my own, so that is a false report.


  fwupd   x86_64 1.8.10-1.fc38  
fedora 1.8 M
  fwupd-plugin-flashrom   x86_64 1.8.10-1.fc38  
fedora  26 k
  fwupd-plugin-modem-manager  x86_64 1.8.10-1.fc38  
fedora  60 k
  fwupd-plugin-uefi-capsule-data  x86_64 1.8.10-1.fc38  
fedora 1.8 M



  gimp    x86_64 2:2.10.32-7.fc38   
fedora  21 M
  gimp-devel  x86_64 2:2.10.32-7.fc38   
fedora 1.2 M
  gimp-devel-tools    x86_64 2:2.10.32-7.fc38   
fedora  20 k
  gimp-libs   x86_64 2:2.10.32-7.fc38   
fedora 526 k


Same for gimp - not really a downgrade.


  gputils x86_64 1.5.2-1.fc38   
fedora 2.2 M
  gputils-doc noarch 1.5.2-1.fc38   
fedora 1.9 M
  inxi    noarch 3.3.24-2.fc38  
fedora 493 k

 Steve

On 2/22/23 04:30 AM, Miroslav Suchý wrote:

Do you want to make Fedora 38 better? Please spend 1 minute of your time and 
try to run:

# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'

dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo 
--enablerepo=updates-testing-modular) \
--assumeno distro-sync


This command does not replace `dnf system-upgrade`, but it will reveals 
potential problems.

You may also run `dnf upgrade` before running this command.


The `--assumeno` will just test the transaction, but does not make the actual 
upgrade.


In case you hit dependency issues, please report it against the appropriate 
package.

Or against fedora-obsolete-packages if that package should be removed in Fedora 
38. Please check existing reports against

fedora-obsolete-packages first:

https://red.ht/2kuBDPu

and also there is already bunch of "Fails to install" (F38FailsToInstall) 
reports:

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

Thank you

Miroslav


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



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

Re: Proposal: drop delta rpms (for real this time)

[Ben Cotton]

On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller  wrote:
>
> What we're doing now — as has been the case for several years, already noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)

The fact that the value of deltas requires frequent updates means that
most people don't get the benefit. And since delta RPMs trade
bandwidth for CPU, it probably makes things worse for folks in
developing countries. So I agree, it's probably not worth keeping
deltas as the default.

> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.

Could we do this as a two-step approach? First change the default to
not use deltas but still allow people to opt-in to it. Then (assuming
we can track this, which maybe we can't) see how much they're used
before we decide to pull the plug on producing them.

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

Unretiring a package

[Globe Trotter via devel]

According to 

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

unretiring a package requires review if retired for more than eight weeks. 
According to releng, the package slim has been retired for 6+ weeks. Do I still 
need to ask for review of this package, and file a BZ request?

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

Changes to Bugzilla API key requirements

[Ben Cotton]

If you did not see the bugzilla-announce-list post[1], there are new
requirements for API keys in Red Hat Bugzilla:

Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
must replace your API keys at least once a year. Additionally, any API
key that is not used for 30 days will be suspended but can be
re-enabled on the account's preferences tab.

All existing API keys have had their creation date set to 2023-02-19.
For more details, see the announcement[1].

[1] 
https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html

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

Re: Unretiring a package

[Alexander Ploumistos]

On Wed, Feb 22, 2023 at 4:43 PM Globe Trotter via devel
 wrote:
>
> According to
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
>
> unretiring a package requires review if retired for more than eight weeks. 
> According to releng, the package slim has been retired for 6+ weeks. Do I 
> still need to ask for review of this package, and file a BZ request?

The package was actually retired almost a year ago, so yes.
___
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: Changes to Bugzilla API key requirements

[Andrej Manduch]

Hi Ben,

Does this make sense? Lot of people (outside of redhat) are using API 
keys just for abrt, so when something crashes they can report bug to 
bugzilla.


I report about 1-2 bugs /year, and it would be inconvenient for me for 
every bugreport to regenerate/reactivate API keys. I would do it, but I 
can imagine lot of people would not do it and you'll get fewer bug 
reports, or at least fewer bug reports with proper backtrace and stuff.


On 2/22/23 16:46, Ben Cotton wrote:

If you did not see the bugzilla-announce-list post[1], there are new
requirements for API keys in Red Hat Bugzilla:

Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
must replace your API keys at least once a year. Additionally, any API
key that is not used for 30 days will be suspended but can be
re-enabled on the account's preferences tab.

All existing API keys have had their creation date set to 2023-02-19.
For more details, see the announcement[1].

[1] 
https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html



--

Kind regards,

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

Re: Proposal: drop delta rpms (for real this time)

[Ahmed Almeleh]

I agree with the idea that Ben suggested of not enabling deltas by default
and giving users the option until a certain time where it can be phased out
fully.

I remember in my personal experience that delta slowed down update
durations.

On Wed, 22 Feb 2023, 15:40 Ben Cotton,  wrote:

> On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller 
> wrote:
> >
> > What we're doing now — as has been the case for several years, already
> noted
> > in the previous discussion — has very little end-user value. Also as
> noted
> > in that thread (as in the ticket)... that's unfortunate, because it did
> > bring some real benefits (and could possibly do even more.)
>
> The fact that the value of deltas requires frequent updates means that
> most people don't get the benefit. And since delta RPMs trade
> bandwidth for CPU, it probably makes things worse for folks in
> developing countries. So I agree, it's probably not worth keeping
> deltas as the default.
>
> > But, I think it's time to move on. We have ostree and various
> > container-delta approaches. We should focus on those — and give
> DeltaRPMs a
> > sad, fond farewell.
>
> Could we do this as a two-step approach? First change the default to
> not use deltas but still allow people to opt-in to it. Then (assuming
> we can track this, which maybe we can't) see how much they're used
> before we decide to pull the plug on producing them.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: Proposal: drop delta rpms (for real this time)

[Demi Marie Obenour]

On 2/22/23 10:39, Ben Cotton wrote:
> On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller  
> wrote:
>>
>> What we're doing now — as has been the case for several years, already noted
>> in the previous discussion — has very little end-user value. Also as noted
>> in that thread (as in the ticket)... that's unfortunate, because it did
>> bring some real benefits (and could possibly do even more.)
> 
> The fact that the value of deltas requires frequent updates means that
> most people don't get the benefit. And since delta RPMs trade
> bandwidth for CPU, it probably makes things worse for folks in
> developing countries. So I agree, it's probably not worth keeping
> deltas as the default.
> 
>> But, I think it's time to move on. We have ostree and various
>> container-delta approaches. We should focus on those — and give DeltaRPMs a
>> sad, fond farewell.
> 
> Could we do this as a two-step approach? First change the default to
> not use deltas but still allow people to opt-in to it. Then (assuming
> we can track this, which maybe we can't) see how much they're used
> before we decide to pull the plug on producing them.

That would be absolutely awesome.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: Changes to Bugzilla API key requirements

[Ben Beasley]

Am I missing something, or does this basically break ABRT for users, since that 
has required an API key rather than a username and password for some time, and 
it’s not usual to report bugs with ABRT even as often as once a month? It 
doesn’t seem reasonable to have to go manually reset an API key every time I 
want to report a bug, and I’m concerned that this will reduce the number of 
useful crash reports we get.

On Wed, Feb 22, 2023, at 10:46 AM, Ben Cotton wrote:
> If you did not see the bugzilla-announce-list post[1], there are new
> requirements for API keys in Red Hat Bugzilla:
>
> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
> must replace your API keys at least once a year. Additionally, any API
> key that is not used for 30 days will be suspended but can be
> re-enabled on the account's preferences tab.
>
> All existing API keys have had their creation date set to 2023-02-19.
> For more details, see the announcement[1].
>
> [1] 
> https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html
>
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to 
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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: Changes to Bugzilla API key requirements

[Solomon Peachy via devel]

On Wed, Feb 22, 2023 at 10:46:12AM -0500, Ben Cotton wrote:
> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
> must replace your API keys at least once a year. Additionally, any API
> key that is not used for 30 days will be suspended but can be
> re-enabled on the account's preferences tab.

I suspect this is going to lead to a lot of grumbling roughly every six 
months, as there's likely to be big spikes in abrt-generated stuff after 
each Fedora release.  Or every three-ish months as major new kernels come out.

Or, more likely, this is going to lead to far fewer ABRT submissions 
from folks that aren't actively developing/maintaining Fedora, as "I 
have to log in *yet again* to get ABRT to work" adds a signigficant 
impediment to the former "set it up once and forget" status quo.

(It's not like we have any meaningful control over how often ABRT is 
 tripped and needs to send a report to the mothership...)

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
Dowling Park, FL  speachy (libra.chat)


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

Re: Changes to Bugzilla API key requirements

[Ben Cotton]

Yes, as I understand it, this will make abrt difficult to use.
Historically, we get about 2500 bug reports via abrt per release.
That's roughly a quarter of reports per release on average. On the
other hand, we're not particularly good at fixing abrt-reported bugs.
Here's the resolution (excluding duplicates) of abrt-reported bugs for
F19–34:

EOL  32675
ERRATA3565
INSUFFICIENT_DATA 2965
CURRENTRELEASE1162
NOTABUG983
UPSTREAM   823
WORKSFORME 680
WONTFIX529
CANTFIX461
NEXTRELEASE423
RAWHIDE199

That's a ~73% EOL closure rate, compared to roughly 50% for all bugs.
Depending on which resolutions you include as "fixed", we fix roughly
14% of abrt-reported bugs.

I just found out about this change yesterday. I suspect it's a
security-driven requirement, so I don't know how much room there will
be for changes. I'll pass this on to the Bugzilla team and see what
they say.

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Nathanael D. Noblet]

On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote:
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
>  --enablerepo=updates-testing \
>  $(rpm -q fedora-repos-modular >/dev/null && echo --
> enablerepo=updates-testing-modular) \
>  --assumeno distro-sync

I got 

Error: 
 Problem: package msv-xsdlib-1:2013.6.1-19.fc33.noarch requires
mvn(relaxngDatatype:relaxngDatatype), but none of the providers can be
installed
  - jaxb-relaxng-datatype-2.3.5-7.fc37.noarch does not belong to a
distupgrade repository
  - problem with installed package msv-xsdlib-1:2013.6.1-19.fc33.noarch
(try to add '--skip-broken' to skip uninstallable packages)


I don't know why those are installed (I don't recognize the packages
and they aren't dependencies of anything I know I need) and just
removed them and everything was good after that.


___
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: Changes to Bugzilla API key requirements

[Michal Srb]

st 22. 2. 2023 o 17:27 Ben Cotton  napísal(a):

> Yes, as I understand it, this will make abrt difficult to use.
> Historically, we get about 2500 bug reports via abrt per release.
> That's roughly a quarter of reports per release on average. On the
> other hand, we're not particularly good at fixing abrt-reported bugs.
> Here's the resolution (excluding duplicates) of abrt-reported bugs for
> F19–34:
>
> EOL  32675
> ERRATA3565
> INSUFFICIENT_DATA 2965
> CURRENTRELEASE1162
> NOTABUG983
> UPSTREAM   823
> WORKSFORME 680
> WONTFIX529
> CANTFIX461
> NEXTRELEASE423
> RAWHIDE199
>
> That's a ~73% EOL closure rate, compared to roughly 50% for all bugs.
> Depending on which resolutions you include as "fixed", we fix roughly
> 14% of abrt-reported bugs.
>
> I just found out about this change yesterday. I suspect it's a
> security-driven requirement, so I don't know how much room there will
> be for changes. I'll pass this on to the Bugzilla team and see what
> they say.
>

Thanks! Please keep us posted.

Michal


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

[Sebastian Crane]

Dear Riya Bisht,

Welcome to Fedora! With your interest and experience with Qt and package
mangers, I would suggest you have a look at the Fedora Kinoite
'spin'. It combines KDE with a very modern package management system
based on containers. I'm sure they would appreciate your involvement and
help you get started :)

https://docs.fedoraproject.org/en-US/fedora-kinoite/

I gave a talk at the online LibrePlanet 2022 conference all about
package managers ("Distributing freedom: How package managers empower
software users"), so you might be interested in watching that:

https://framatube.org/w/uubjKne6swPQpJWiQLfqxd

Best wishes,

Sebastian Crane
___
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: Changes to Bugzilla API key requirements

[Miro Hrončok]

On 22. 02. 23 17:27, Ben Cotton wrote:

I just found out about this change yesterday. I suspect it's a
security-driven requirement, so I don't know how much room there will
be for changes. I'll pass this on to the Bugzilla team and see what
they say.


I suspect the same. Maybe accounts without additional Bugzilla rights/groups 
might be exempted from this policy?


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

Re: Changes to Bugzilla API key requirements

[Fabio Valentini]

On Wed, Feb 22, 2023 at 5:44 PM Miro Hrončok  wrote:
>
> On 22. 02. 23 17:27, Ben Cotton wrote:
> > I just found out about this change yesterday. I suspect it's a
> > security-driven requirement, so I don't know how much room there will
> > be for changes. I'll pass this on to the Bugzilla team and see what
> > they say.
>
> I suspect the same. Maybe accounts without additional Bugzilla rights/groups
> might be exempted from this policy?

Does anybody here know the BugZilla Python API?
/me wonders how hard it would be to write a script that posts bogus "I
am still using the API token" requests to RHBZ, and to run that with a
cron job twice a month ...

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Yaakov Selkowitz]

On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 38 better? Please spend 1 minute of your time and
> try to run:
> 
> dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> --enablerepo=updates-testing \
> $(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-
> testing-modular) \
> --assumeno distro-sync

Problem: package cekit-4.5.0-2.fc38.noarch requires (python3.11dist(packaging)
< 22~~ with python3.11dist(packaging) >= 19), but none of the providers can be
installed
  - problem with installed package cekit-4.5.0-1.fc37.noarch
  - python3-packaging-21.3-6.fc37.noarch does not belong to a distupgrade
repository
  - cekit-4.5.0-1.fc37.noarch does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)

Which is https://bugzilla.redhat.com/show_bug.cgi?id=2162433

-- 
Yaakov Selkowitz
Principal Software Engineer - Platform Enablement
Red Hat, Inc.
___
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: Proposal: drop delta rpms (for real this time)

[Matthew Miller]

On Wed, Feb 22, 2023 at 06:18:23AM -0500, Neal Gompa wrote:
> Please don't try to equate those things to DeltaRPMs, unless you're
> trying to equate their general uselessness. OSTree and

Neal, hyperbole like "general uselessness" is not appropriate in talking
about other people's work. In any case, CoreOS is our fourth-most-common
variant at this point, so clearly some people are finding it useful.

> "container-delta" stuff is not generally useful or applicable for
> Fedora users and they won't be for a very long time.

Maybe, depending on your definition of "very long time". There is work in
the right direction, and supporting that can only help.

-- 
Matthew Miller

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

Re: FTBFS bug filed, build already deleted

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 02:27:47PM +, Daniel P. Berrangé wrote:
> On Mon, Feb 20, 2023 at 06:46:31PM +0100, Fabio Valentini wrote:
> > On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski  wrote:
> > >
> > > Hello,
> > >
> > > FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> > > build [2] has already been deleted. This is not ideal from maintainer
> > > perspective as it effectively is a bug with no info provided whatsoever.
> > > Not to mention being quite wasteful from the resources perspective as
> > > mame builds take quite a while.
> > > While not much can be done now, can we make sure that the mass rebuild
> > > builds do not get garbage collected, or at least the build logs are
> > > saved somewhere? Thanks.
> > 
> > As far as I know, at least some form of truncated build.log used to
> > get attached when FTBFS bugs were filed after a mass rebuild ... maybe
> > this time this wasn't possible, because bugs were reported *weeks*
> > after the mass rebuild?
> 
> More often than not I've found the truncated build.log to be too
> truncated to be sufficiently useful. Ignoring the current problem
> of entirely missing logs, can we not attach the full *uneditted*
> build.log + root.log to bugzilla in general ?
> 
> Yes, build.log can be quite large, but I've seen way bigger things
> attached to BZ, so it ought to cope surely ? I prefer plain text
> attachments, but if size is really a concern, even an xz compressed
> log is better than a truncated log.

They can be... VERY BIG. ;) 

Just looking at gcc... the last f39 build on x86_64 is about 93MB. 
It looks like from comments in the script that bugzilla has a 32MB
limit.

I think we used to include more or the entire thing, but people
complained that they didn't want that in the bug and could just look at
the buildsystem? So, this was a compromise.

But yeah, we could be smarter about it. Perhaps have some cutoff?

Here's the script if anyone would like to propose changes: 
https://pagure.io/releng/blob/main/f/scripts/mass_rebuild_file_bugs.py

kevin


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

Re: %dnl macro not available for epel-8 builds?

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 09:25:15AM -0600, Ron Olson wrote:
> Hi all,
> 
> I submitted a scratch build of Swift to Koji for EPEL 8 and it pretty much 
> immediately failed, and looking at root.log I found:
> 
> DEBUG util.py:443:  error: line 71: Unknown tag: %dnl Source31:   
> https://github.com/apple/swift-format/archive/swift-5.8-DEVELOPMENT-SNAPSHOT-2023-02-20-a.tar.gz#/swift-format.tar.gz
> 
> Fedora and EPEL 9 builds all work, so I guess %dnl isn’t available on EPEL 8?

Correct. rpm is too old there to have that builtin macro. ;( 

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Tue, Feb 21, 2023 at 05:13:26PM -0500, Matthew Miller wrote:
> On Tue, Feb 21, 2023 at 04:44:31PM -0500, Stephen Smoogen wrote:
> > So do we kill it for:
> > 
> > F39/F40 and beyond?
> > F38 and beyond?
> > X-date and all releases?
> 
> My normal response would be... well, I missed the F38 change deadline by a
> wide margin, so F39+.

Just FYI, we do not produce drpms for rawhide/branched at all (since
2017 ish).

> But, I think we could stop producing deltarpms for current releases without
> really affecting those releases (there would just not be more created, which
> as previously explored, would not really have a strong effect). So... I
> wouldn't leave the other options out of the question. 
> 
> What do infra / releng folks think?
> 
> How easy is it to shut things off?

Its one line in bodhi pungi config:
createrepo_deltas = False

> If shut off, can it be turned back on again (in case of Regrets)?

Just change the one line back to True (well, it's more complex because
we only actually do drpms for the 'Everything' repo, not others, but
it's one line).

> Once shut off, is decomissioning infrastructure around it a Project, or just
> more shutting off?

As far as I can think, nothing else needs to be done. They will just
disappear. 

> What risks are there?

None that leap to mind.

> And... how much would be saved in:
> 
>  * compute resources

Some, but not a lot, as we only delta against the previous update
composes and thus don't do too many.

>  * storage

100's of MB... not much at all.

>  * delays
>  * ongoing maintenance work 
>  * other?

Nothing comes to mind. 

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 06:18:23AM -0500, Neal Gompa wrote:
> On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller  
> wrote:
> >
> > I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> > priority. Last time we talked about this we didn't really get anywhere...
> >
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
> >
> > ... and that ticket hasn't moved, because fixing it isn't trivial.
> >
> >
> > What we're doing now — as has been the case for several years, already noted
> > in the previous discussion — has very little end-user value. Also as noted
> > in that thread (as in the ticket)... that's unfortunate, because it did
> > bring some real benefits (and could possibly do even more.)
> >
> 
> Our tooling has been broken for a long time and contributions to that
> tooling is just not going to happen since nobody can run this stuff
> outside of Fedora infrastructure. It's a sad state of affairs indeed.

It's not "broken" just because it doesn't do what you would like it to
do. Please can we not disparage other peoples work?

The reason it behaves this way is because koji has no concept of 'newer
version' or 'older version'. It has only when a valid build was tagged
into a tag, and pungi operates on that with 'give me the latest tagged
packages in these tags'. 

We could merge current repos into the newly created one from pungi, but
it would be a vast amount of work. It would mean all repodata would need
to be regenerated. That said, it could be done, but no one has had the
cycles to work on it.

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 08:37:00AM +, Richard W.M. Jones wrote:
> It's also been a long time since I've seen any benefit.
> 
> Can anyone summarise quickly why delta RPMs don't work?  It seems like
> they "obviously" should be possible, because there must be a lot of
> commonality in the content of adjacent RPM versions ...

pungi creates composes. It does this by asking koji for 'whats the
latest rpm tagged into this tag'. It then operates on those packages. 
It has little concept of other repos/things other than koji.

So, in order to do what might be expected it would have to: 

* query koji/download things as it does now.
* copy in the current repos
* possibly prune based on something (only 2 copies, only X days old)
* then go on with it's repo creation, etc. 

Last I checked pungi developers weren't too excited by pungi growing
that ability/code. I can try asking again. 

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 05:38:23AM +0100, Kevin Kofler via devel wrote:
> Kevin Fenzi wrote:
> > I fear the only way to fix it is to get pungi to merge entire repos, and
> > I don't think thats anything that pungi wants to be on the hook for
> > doing.
> 
> But there are more things than just DeltaRPMs it could be useful for. E.g., 
> I remember that in ancient times (pre Core-Extras Merge), some Fedora 
> repository (IIRC, the old Fedora Extras) used to ship not only the latest 
> build for each package, but the TWO latest builds, so that if the latest 
> build was broken, you could easily downgrade to the previous one. That 
> should really be done in all the rolling repositories (updates, updates-
> testing, Rawhide).

It does have advantages for sure. 

Pros:
* can dnf downgrade easily.
* can choose not to upgrade something thats a big change you aren't
ready for.

Cons:
* It takes a bunch more mirror space.
* It would make composes take longer.
* It will allow for more easily tricking people into downgrading to a
version that has serious security problems so they could be exploited.

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Chris Adams]

Once upon a time, Kevin Fenzi  said:
> Pros:
> * can dnf downgrade easily.

This assumes the N-1 release is working though, which is not always
valid when there's an issue (sometimes release N doesn't work, so
there's release N+1 that still has a problem, but then release N-1 would
be gone).

> Cons:

Wouldn't it also increase the repodata size significantly, which is
already a problem for dnf resource usage, especially on small devices
like Raspberry Pi?

-- 
Chris Adams 
___
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: FTBFS bug filed, build already deleted

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 09:21:37AM -0500, Scott Talbert wrote:
> On Wed, 22 Feb 2023, Kevin Kofler via devel wrote:
> 
> > Julian Sikorski wrote:
> > > FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> > > build [2] has already been deleted. This is not ideal from maintainer
> > > perspective as it effectively is a bug with no info provided whatsoever.
> > > Not to mention being quite wasteful from the resources perspective as
> > > mame builds take quite a while.
> > > While not much can be done now, can we make sure that the mass rebuild
> > > builds do not get garbage collected, or at least the build logs are
> > > saved somewhere? Thanks.
> > 
> > This is a constantly recurring problem. I have run into this very
> > frequently. The retention period for failed build logs is way too short. It
> > needs to be at least 13 months (the approximate time we get to fix an FTBFS
> > bug before the package is retired).
> 
> I have to agree here.  There is nothing more frustrating as a contributor
> than going to investigate a FTBFS for a package and finding the logs are
> gone.

Yeah, I can understand that. 

Currently logs of failed builds are kept for 14 days. 

Currently we are hitting a very nasty hard limit on our koji storage, so
I definitely wouldn't want to change this now, but we could perhaps look
at doing so after that problem is less pressing.

Currently the koji 'work' directory (where failed builds/logs are) is
taking up about 6TB.

> At the very least, the 'latest' failure logs should be retained for much
> longer.

Thats not something thats easy to determine. The script that deletes
failed builds is just a one liner find from cron. In order to know what
the 'latest' failure is it would have to do a lot of koji api calls and
figure out whats deleteable.

kevin


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

Fedora CoreOS Meeting Minutes 2023-02-22

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-22/fedora_coreos_meeting.2023-02-22-16.30.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-22/fedora_coreos_meeting.2023-02-22-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-22/fedora_coreos_meeting.2023-02-22-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:30:34 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-02-22/fedora_coreos_meeting.2023-02-22-16.30.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:30:39)

* Action items from last meeting  (dustymabe, 16:34:29)
  * no action items from last meeting 🎉   (dustymabe, 16:34:46)

* rawhide: upgrades fail with new openssh-9.0p1-10.fc38.1  (dustymabe,
  16:34:58)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1394
(dustymabe, 16:35:02)

* Platform Request: Microsoft HyperV  (dustymabe, 17:09:19)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1411
(dustymabe, 17:09:25)
  * AGREED: We think it's a good idea to enable Windows users who want
to use FCOS and the Windows podman machine efforts by adding a
Hyper-V FCOS platform under the `hyperv` platform ID.  (dustymabe,
17:22:10)

* open floor   (dustymabe, 17:24:16)
  * LINK:

https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/issues/89#note_1285250494
(darknao, 17:26:46)

Meeting ended at 17:35:14 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (92)
* jlebon (31)
* dbelyavs (24)
* travier (22)
* bgilbert (22)
* zodbot (20)
* darknao (8)
* apiaseck (3)
* marmijo[m] (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 12:51:54PM -0600, Chris Adams wrote:
> Once upon a time, Kevin Fenzi  said:
> > Pros:
> > * can dnf downgrade easily.
> 
> This assumes the N-1 release is working though, which is not always
> valid when there's an issue (sometimes release N doesn't work, so
> there's release N+1 that still has a problem, but then release N-1 would
> be gone).

Right. Also, for things that incompatibly upgrade your data, rolling
back will not be as easy as a dnf downgrade. ;( 
Luckily those things are rare.
 
> > Cons:
> 
> Wouldn't it also increase the repodata size significantly, which is
> already a problem for dnf resource usage, especially on small devices
> like Raspberry Pi?

Yep. Thats another con.

kevin


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

Re: HyperKitty broken References and In-Reply-To headers

[Björn Persson]

Eike Rathke wrote:
> On Wednesday, 2023-02-22 00:46:19 +0200, Otto Liljalaakso wrote:
> 
> > Ok, I found the other parts of the thread now.
> > Something strange is going on here - it seems that when Arthur replies,
> > threading breaks and I see separate subthreads in Thunderbird.
> > Also lists.fedoraproject.org seems to be similarly confused.  
> 
> That's likely because
> | User-Agent: HyperKitty on https://lists.fedoraproject.org/
> writes broken References and In-Reply-To headers:
> 
> | References: <
> |  
> >
> | In-Reply-To: <
> |  
> >
> 
> Note the doubled <<>> and folding line break after first <.

Yes, it looks like Hyperkitty has trouble with unfolding folded header
fields.

Kenneth's Message-ID fields are folded over two lines. That's unusual
but perfectly valid syntax. It's even recommended by RFC 5322 because 
Kenneth's message IDs are rather long.

This line folding seems to trigger some defect in Hyperkitty so that it
fails to recognize the message ID each time somebody replies to Kenneth,
and shows the reply as a separate thread.

And then, when Artur uses Hyperkitty to reply to Kenneth, Hyperkitty
seems to think the line break is part of the message ID, which results
in that invalid syntax.

That's just one example of how difficult it is to write a correct email
parser. It's even a rather simple case compared to the monstrosities
that are allowed in valid email syntax.

Björn Persson


pgp1A9BxCsgXQ.pgp
Description: OpenPGP digital signatur
___
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: Changes to Bugzilla API key requirements

[Andrej Manduch]

I think this should be sufficient (according original e-mail):

```

curl "https://bugzilla.redhat.com//rest/user/1?exclude_fields=name"; -H 
"Authorization: Bearer YOUR_API_KEY"


```

But do you really want to ask users to put this to their cron?

On 2/22/23 18:05, Fabio Valentini wrote:

Does anybody here know the BugZilla Python API?
/me wonders how hard it would be to write a script that posts bogus "I
am still using the API token" requests to RHBZ, and to run that with a
cron job twice a month ...


___
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: HyperKitty broken References and In-Reply-To headers

[Maxwell G]

On Wed Feb 22, 2023 at 20:20 +0100, Björn Persson wrote:
> That's just one example of how difficult it is to write a correct email
> parser. It's even a rather simple case compared to the monstrosities
> that are allowed in valid email syntax.

It doesn't help that Fedora's mailman3 setup is running on an ancient
mailman3 version (for example, the hyperkitty version is from 2017) on
an ancient Python version (3.4), neither of which receive any bugfixes.

--
Maxwell G (@gotmax23)
Pronouns: He/They
___
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: Proposal: drop delta rpms (for real this time)

[Mattia Verga via devel]

Il 22/02/23 19:46, Kevin Fenzi ha scritto:
> On Wed, Feb 22, 2023 at 08:37:00AM +, Richard W.M. Jones wrote:
>> It's also been a long time since I've seen any benefit.
>>
>> Can anyone summarise quickly why delta RPMs don't work?  It seems like
>> they "obviously" should be possible, because there must be a lot of
>> commonality in the content of adjacent RPM versions ...
> pungi creates composes. It does this by asking koji for 'whats the
> latest rpm tagged into this tag'. It then operates on those packages.
> It has little concept of other repos/things other than koji.
>
> So, in order to do what might be expected it would have to:
>
> * query koji/download things as it does now.
> * copy in the current repos
> * possibly prune based on something (only 2 copies, only X days old)
> * then go on with it's repo creation, etc.
>
So, does that mean that every time a compose is performed pungi
downloads all RPMs tagged with a specific tag in a directory and then it
operates on those to create repository metadata? Or it just downloads
the rpms headers, or whatever?

Can we have a persistent compose root directory as base, then download
the latest builds (if newer), do the pruning "based on something",
create the repo and save the state as the base for the next run? Or will
that eat way too much disk space? On the other hand we could save
bandwith because we would not download all the rpms which were not
updated from the previous run... what's more valuable for our
infrastructure, disk space or network bandwith usage?

Mattia

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

Re: Proposal: drop delta rpms (for real this time)

[Adam Williamson]

On Wed, 2023-02-22 at 10:40 -0800, Kevin Fenzi wrote:
> On Wed, Feb 22, 2023 at 06:18:23AM -0500, Neal Gompa wrote:
> > On Tue, Feb 21, 2023 at 3:48 PM Matthew Miller  
> > wrote:
> > > 
> > > I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> > > priority. Last time we talked about this we didn't really get anywhere...
> > > 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
> > > 
> > > ... and that ticket hasn't moved, because fixing it isn't trivial.
> > > 
> > > 
> > > What we're doing now — as has been the case for several years, already 
> > > noted
> > > in the previous discussion — has very little end-user value. Also as noted
> > > in that thread (as in the ticket)... that's unfortunate, because it did
> > > bring some real benefits (and could possibly do even more.)
> > > 
> > 
> > Our tooling has been broken for a long time and contributions to that
> > tooling is just not going to happen since nobody can run this stuff
> > outside of Fedora infrastructure. It's a sad state of affairs indeed.
> 
> It's not "broken" just because it doesn't do what you would like it to
> do. Please can we not disparage other peoples work?
> 
> The reason it behaves this way is because koji has no concept of 'newer
> version' or 'older version'. It has only when a valid build was tagged
> into a tag, and pungi operates on that with 'give me the latest tagged
> packages in these tags'. 
> 
> We could merge current repos into the newly created one from pungi, but
> it would be a vast amount of work. It would mean all repodata would need
> to be regenerated. That said, it could be done, but no one has had the
> cycles to work on it.

I'm guessing this would also make composes slower and less reliable?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: Changes to Bugzilla API key requirements

[Ben Beasley]

To make things slightly worse, it looks like an API key that is manually 
“un-revoked” will be revoked again the next day if it is not also *actually 
used*. So the 30 days are evaluated every day based on time since the last API 
call, and “un-revoking” the key does not count as using it.

On Wed, Feb 22, 2023, at 10:56 AM, Ben Beasley wrote:
> Am I missing something, or does this basically break ABRT for users, 
> since that has required an API key rather than a username and password 
> for some time, and it’s not usual to report bugs with ABRT even as 
> often as once a month? It doesn’t seem reasonable to have to go 
> manually reset an API key every time I want to report a bug, and I’m 
> concerned that this will reduce the number of useful crash reports we 
> get.
>
> On Wed, Feb 22, 2023, at 10:46 AM, Ben Cotton wrote:
>> If you did not see the bugzilla-announce-list post[1], there are new
>> requirements for API keys in Red Hat Bugzilla:
>>
>> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
>> must replace your API keys at least once a year. Additionally, any API
>> key that is not used for 30 days will be suspended but can be
>> re-enabled on the account's preferences tab.
>>
>> All existing API keys have had their creation date set to 2023-02-19.
>> For more details, see the announcement[1].
>>
>> [1] 
>> https://listman.redhat.com/archives/bugzilla-announce-list/2023-February/000101.html
>>
>> -- 
>> Ben Cotton
>> He / Him / His
>> Fedora Program Manager
>> Red Hat
>> TZ=America/Indiana/Indianapolis
>> ___
>> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
>> To unsubscribe send an email to 
>> devel-announce-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
> ___
> 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
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

The f39-boost side tag builds have finished.

The following packages are new FTBFS likely due to the Boost update -
- mapnik [[https://bugzilla.redhat.com/show_bug.cgi?id=2172635][PR2172635]]
Boost.Phoenix related
- credentials-fetcher  [[
https://bugzilla.redhat.com/show_bug.cgi?id=2172636][PR217636]]
Boost.Filesystem related
- vsomeip3  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172639][PR2172639]]
Boost.Asio related

The following packages are still FTBFS from the f38 mass rebuild -
- 0ad [[https://bugzilla.redhat.com/show_bug.cgi?id=2171424][PR2171424]]
- cryfs [[https://bugzilla.redhat.com/show_bug.cgi?id=2171464][PR2171464]]
- folly [[https://bugzilla.redhat.com/show_bug.cgi?id=2165219][PR2165219]]
- fbthrift [[https://bugzilla.redhat.com/show_bug.cgi?id=2171488][PR2171488
]]
- fast-netmon  [[
https://bugzilla.redhat.com/show_bug.cgi?id=2171487][PR2171487]]
- nextpnr  [[https://bugzilla.redhat.com/show_bug.cgi?id=2171618][PR2171618
]]
- rstudio [[https://bugzilla.redhat.com/show_bug.cgi?id=2171710][PR2171710]]
- widelands [[https://bugzilla.redhat.com/show_bug.cgi?id=2171759][PR2171759
]]

The following packages are new FTBFS not apparently related to Boost 1.81.0
-
- condor [[https://bugzilla.redhat.com/show_bug.cgi?id=2172630][PR2172630]]
- galera  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172633][PR2172633]]
- gnu-cash  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172637][PR2172637
]]
- inkscape  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172638][PR2172638
]]
- sourcextractor++ [[
https://bugzilla.redhat.com/show_bug.cgi?id=2172642][PR2172642]]
- wesnoth [[https://bugzilla.redhat.com/show_bug.cgi?id=2172627][PR2172627]]

The following packages FTBFS but the build logs provide no useful
information -
- blender [[
https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
]]
- hugin  [[
https://kojipkgs.fedoraproject.org//work/tasks/5732/97785732/build.log][build.log
]]
- libyui-mga-gtk  [[
https://kojipkgs.fedoraproject.org//work/tasks/3208/97843208/build.log][build.log
]]
- luxcorerender [[
https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
]]
- mcrouter  [[
https://kojipkgs.fedoraproject.org//work/tasks/7420/97847420/build.log][build.log
]]
- openshadinglanguage [[
https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
]]
- OpenImageIO  [[
https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
]]
- usd [[
https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
]]

On Mon, Feb 20, 2023 at 9:16 AM Thomas Rodgers  wrote:

> Builds are starting now.
>
> On Thu, Feb 16, 2023 at 9:54 AM Thomas Rodgers 
> wrote:
>
>> We expect to start rebuilds for
>> https://fedoraproject.org/wiki/Changes/F39Boost181
>> in the f39-boost side tag Monday 2022-02-20.
>>
>> If your package depends on Boost, or just if you see a "Rebuilt for
>> Boost 1.81" commit pushed to your package's dist-git repo, please
>> coordinate with me about any updates to the package. If you need
>> to push other changes to rawhide then you will need to build in the
>> side tag, or we'll have to rebuild it multiple times.
>>
>> I expect to complete the builds and request the merge of the f39-boost
>> side tag by Friday 2022-02-24.
>>
>>
>>
___
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: Proposal: drop delta rpms (for real this time)

[Daniel Alley]

Well, regarding the "based on something", you can hand off a list of packages 
to createrepo_c with --pkglist, and avoid the need to download files with 
--update + --skip-stat.  Unfortunately that doesn't help you with the package 
file management.  In a vacuum --baseurl would help here because you could have 
one root directory, however in reality it breaks repository mirroring because 
any mirror be telling clients to fetch the packages from the source-of-truth.

I'm not 100% sure how --basedir works, the description is a bit vague.

Another option is to use something like Pulp which stores all the information 
required for metadata generation inside Postgresql and thus can do so without 
ever touching the packages / headers again.  That approach isn't necessarily 
free of downsides either, but it does abstract the whole file management 
problem.
___
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: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 12:43:20PM -0800, Adam Williamson wrote:
> > It's not "broken" just because it doesn't do what you would like it to
> > do. Please can we not disparage other peoples work?
> > 
> > The reason it behaves this way is because koji has no concept of 'newer
> > version' or 'older version'. It has only when a valid build was tagged
> > into a tag, and pungi operates on that with 'give me the latest tagged
> > packages in these tags'. 
> > 
> > We could merge current repos into the newly created one from pungi, but
> > it would be a vast amount of work. It would mean all repodata would need
> > to be regenerated. That said, it could be done, but no one has had the
> > cycles to work on it.
> 
> I'm guessing this would also make composes slower and less reliable?

yep.

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 08:12:01PM +, Mattia Verga via devel wrote:
> So, does that mean that every time a compose is performed pungi
> downloads all RPMs tagged with a specific tag in a directory and then it
> operates on those to create repository metadata? Or it just downloads
> the rpms headers, or whatever?

Yes. It downloads them all, because it needs the ones signed with the
specific keys in it's config. It can optionally however look at a
previous config and decide that nothing changed in koji so it can reuse
them, but in practice I think this doesn't happen much.

> Can we have a persistent compose root directory as base, then download
> the latest builds (if newer), do the pruning "based on something",
> create the repo and save the state as the base for the next run? Or will
> that eat way too much disk space? On the other hand we could save
> bandwith because we would not download all the rpms which were not
> updated from the previous run... what's more valuable for our
> infrastructure, disk space or network bandwith usage?

Definitely disk space is more important right now. 

kevin


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

Re: Orphaned packages looking for new maintainers

[Raphael Groner]

Hi,

why are those packages orphan? lxsession-edit, lxpolkit and parcellite? Is LXDE 
spin officially dead, what's current maintainer or do we still need mentioned 
packages as additional option?

Regards, Raphael
___
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

[Luna Jernberg]

Hey!

Think LXDE is pretty much dead and LXqt is much more alive as it seems now

On 2/22/23, Raphael Groner  wrote:
> Hi,
>
> why are those packages orphan? lxsession-edit, lxpolkit and parcellite? Is
> LXDE spin officially dead, what's current maintainer or do we still need
> mentioned packages as additional option?
>
> Regards, Raphael
> ___
> 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
>
___
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: Proposal: drop delta rpms (for real this time)

[Stephen Smoogen]

On Wed, 22 Feb 2023 at 15:56, Daniel Alley  wrote:

> Well, regarding the "based on something", you can hand off a list of
> packages to createrepo_c with --pkglist, and avoid the need to download
> files with --update + --skip-stat.  Unfortunately that doesn't help you
> with the package file management.  In a vacuum --baseurl would help here
> because you could have one root directory, however in reality it breaks
> repository mirroring because any mirror be telling clients to fetch the
> packages from the source-of-truth.
>
> I'm not 100% sure how --basedir works, the description is a bit vague.
>
> Another option is to use something like Pulp which stores all the
> information required for metadata generation inside Postgresql and thus can
> do so without ever touching the packages / headers again.  That approach
> isn't necessarily free of downsides either, but it does abstract the whole
> file management problem.
>

I think we need to begin by figuring out what happens in at least the
'pungi' part of the daily 'let's make updates and rawhide'. There are a LOT
of things which are going on which interrelate with each other and are
prone to cascading breakage when something is 'added', 'removed', 'fixed',
or 'changed'. There are also some hard resource limitations on how much
CPU/disk/memory is available, how close things must be to 'work', and
places where things break a lot but trying to remove/fix/change would
require longer downtimes than the project has allowed in the past.

I say this from having done all of the above at one point or another and
caused all kinds of chaos in doing so. I have probably used up more of
Kevin's patience on those than was right.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Raphael Groner]

> Think LXDE is pretty much dead and LXqt is much more alive as it seems now

That does not answer my question. Again: Who takes responsible for LXDE spin, 
as we still have in Fedora officially?
___
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: Proposal: drop delta rpms (for real this time)

[Neal Gompa]

On Wed, Feb 22, 2023 at 1:40 PM Kevin Fenzi  wrote:
>
> The reason it behaves this way is because koji has no concept of 'newer
> version' or 'older version'. It has only when a valid build was tagged
> into a tag, and pungi operates on that with 'give me the latest tagged
> packages in these tags'.
>

We have compose metadata for every single compose that has succeeded
and failed. In that metadata, we know what NVRs from Koji were pulled
in, and we can reconstitute any historical update push with that data.

> We could merge current repos into the newly created one from pungi, but
> it would be a vast amount of work. It would mean all repodata would need
> to be regenerated. That said, it could be done, but no one has had the
> cycles to work on it.
>

Maybe we should just publish into Pulp and have them do that bit for
us automatically. I wouldn't personally be comfortable with that until
Pulp is available in Fedora for people to easily deploy, but I know
the COPR folks are investigating it for their tooling. And the
AlmaLinux folks use Pulp for their system for similar reasons.

Pulp is designed to handle super-huge repositories like that.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Proposal: drop delta rpms (for real this time)

[Gregory Bartholomew]

On Wed, Feb 22, 2023 at 12:49 PM Kevin Fenzi  wrote:

> It does have advantages for sure.
>
> Pros:
> * can dnf downgrade easily.
> * can choose not to upgrade something thats a big change you aren't
> ready for.
>
>
I don't know enough about RPM packaging or DNF CoW to say either way, but I
wonder if these enhancements might also contribute to getting DNF CoW's
"reusable extents" feature working? If I understood the FOSDEM presentation
correctly, DNF CoW would not only save the installer from having to rewrite
the file to the user's disk on update when the file has not changed, it
would also not download the file in the first place if it hasn't changed.
Presumably this depends on the same functionality that deltarpm would need
to identify unchanged files in RPM packages? So if these enhancements to
deltarpm would also contribute to DNF CoW, I would consider that another
plus.

Here is the DNF CoW FOSDEM presentation if anyone is interested in it.
https://www.youtube.com/watch?v=-qYgkcs6Uxk

Just my two cents.
___
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

[Mamoru TASAKA]

Raphael Groner wrote on 2023/02/23 6:11:

Hi,

why are those packages orphan? lxsession-edit, lxpolkit and parcellite? Is LXDE 
spin officially dead, what's current maintainer or do we still need mentioned 
packages as additional option?



lxsession-edit, lxpolkit is now built from lxsession.src.rpm, so no need for 
these
anymore.
parcellite is not in LXDE spin, LXDE spin uses clipit, so I did not take this.

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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Mamoru TASAKA]

Thomas Rodgers wrote on 2023/02/23 5:51:

The f39-boost side tag builds have finished.

The following packages are new FTBFS likely due to the Boost update -

The following packages FTBFS but the build logs provide no useful
information -
- blender [[
https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
]]


This is because of fail_fast = True. Actually other arch shows this build 
failed due
to unresolved dependency:
https://koji.fedoraproject.org/koji/taskinfo?taskID=97841240
https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/root.log


- luxcorerender [[
https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
]]
- openshadinglanguage [[
https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
]]
- OpenImageIO  [[
https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
]]
- usd [[
https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
]]



The above 4 are all related to blender (I think), perhaps these all failed due 
to
unresolved dependency, and perhaps these all needs some chainbuild (for new 
boost).

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

Re: Inactive packager check for F38

[Sérgio Basto]

On Wed, 2023-02-15 at 14:02 -0500, Ben Cotton wrote:
> In accordance with FESCo's Inactive Packager Policy[1], packagers
> that
> have been identified as inactive have a ticket in the
> find-inactive-packagers repo[2]. One week after the final release,
> packagers who remain inactive will be removed from the packager
> group.
> (Note that pagure.io is one of the systems checked for activity, so
> commenting on your ticket that you're still around will prevent you
> from showing up in the second round.)
> 
> If you have suggestions for improvement, look for the open feature
> issues[3] and file an issue in the find-inactive-packagers repo[4] if
> it's not there already.
> 
> For the curious, here are the stats from today's run:
> 
> ### Found 2129 users in the packager group. ###
> ### Found 914 users with no activity in pagure/src.fp.org over the
> last year. ###
> ### Found 845 users which also show no activity in Bodhi over the
> last year. ###
> ### Found 812 users which show also no activity in mailing lists over
> the last year. ###
> ### Found 812 users which also show no activity in Bugzilla over the
> last year. ###
> 
> As we approach
> 
> [1]
> https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
> [2]
> https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&status=Open
> [3] https://pagure.io/find-inactive-packagers/issues?tags=feature
> [4] https://pagure.io/find-inactive-packagers/new_issue


I think we may though in one way to avoid retire packages after 6 weeks
of being orphan when they still perfectly usable. 

For example slim-1.3.6-22.fc36 was retired when a user want use it and
now want un-retire it 
 
For example on Java many packages was retired and we still use it, like
hsqldb1.

IMHO the retirement of the packages just because the packager
maintainer was inactive or unresponsive or just leave the project,
bring to us others problems and much more work for others packager
maintainers (like me) . 
I don't know really what is better but I think the process can be
improved 

Best regards, 




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

Re: HyperKitty broken References and In-Reply-To headers

[Neal Gompa]

On Wed, Feb 22, 2023 at 3:11 PM Maxwell G  wrote:
>
> On Wed Feb 22, 2023 at 20:20 +0100, Björn Persson wrote:
> > That's just one example of how difficult it is to write a correct email
> > parser. It's even a rather simple case compared to the monstrosities
> > that are allowed in valid email syntax.
>
> It doesn't help that Fedora's mailman3 setup is running on an ancient
> mailman3 version (for example, the hyperkitty version is from 2017) on
> an ancient Python version (3.4), neither of which receive any bugfixes.
>

There are newer versions in Fedora, but not yet branched into EPEL 9
because things are a little stuck. That prevents us from figuring out
an upgrade for the list server software.

If anyone wants to help, here's the tracker BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=2030061



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Richard Shaw]

On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers  wrote:

> The f39-boost side tag builds have finished.
>
> The following packages FTBFS but the build logs provide no useful
> information -
> - OpenImageIO  [[
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
> ]]
>

It may be true that the build logs weren't useful, but that's because the
problem was in root.log. Either deps need to be analyzed to determine
rebuild order, or after the initial build attempts have been done, they
need to be repeated.

root.log shows the problem:
DEBUG util.py:443:  Error:
DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64
requires libopenvdb.so.10.0()(64bit), but none of the providers can be
installed
DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64 requires
openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be
installed
DEBUG util.py:443:- conflicting requests
DEBUG util.py:443:- nothing provides
libboost_iostreams.so.1.78.0()(64bit) needed by
openvdb-libs-10.0.1-1.fc38.x86_64

I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at this
point.

Thanks,
Richard
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Miro Hrončok]

On 22. 02. 23 21:51, Thomas Rodgers wrote:

The f39-boost side tag builds have finished.

The following packages are new FTBFS likely due to the Boost update -
- mapnik [[https://bugzilla.redhat.com/show_bug.cgi?id=2172635][PR2172635 
]] 
Boost.Phoenix related
- credentials-fetcher  
[[https://bugzilla.redhat.com/show_bug.cgi?id=2172636][PR217636 
]] 
Boost.Filesystem related
- vsomeip3  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172639][PR2172639 
]] Boost.Asio 
related


The following packages are still FTBFS from the f38 mass rebuild -
- 0ad [[https://bugzilla.redhat.com/show_bug.cgi?id=2171424][PR2171424 
]]
- cryfs [[https://bugzilla.redhat.com/show_bug.cgi?id=2171464][PR2171464 
]]
- folly [[https://bugzilla.redhat.com/show_bug.cgi?id=2165219][PR2165219 
]]
- fbthrift [[https://bugzilla.redhat.com/show_bug.cgi?id=2171488][PR2171488 
]]
- fast-netmon  [[https://bugzilla.redhat.com/show_bug.cgi?id=2171487][PR2171487 
]]
- nextpnr  [[https://bugzilla.redhat.com/show_bug.cgi?id=2171618][PR2171618 
]]
- rstudio [[https://bugzilla.redhat.com/show_bug.cgi?id=2171710][PR2171710 
]]
- widelands [[https://bugzilla.redhat.com/show_bug.cgi?id=2171759][PR2171759 
]]


The following packages are new FTBFS not apparently related to Boost 1.81.0 -
- condor [[https://bugzilla.redhat.com/show_bug.cgi?id=2172630][PR2172630 
]]
- galera  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172633][PR2172633 
]]
- gnu-cash  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172637][PR2172637 
]]
- inkscape  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172638][PR2172638 
]]
- sourcextractor++ 
[[https://bugzilla.redhat.com/show_bug.cgi?id=2172642][PR2172642 
]]
- wesnoth [[https://bugzilla.redhat.com/show_bug.cgi?id=2172627][PR2172627 
]]


The following packages FTBFS but the build logs provide no useful information -
- blender 
[[https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log ]]
- hugin  
[[https://kojipkgs.fedoraproject.org//work/tasks/5732/97785732/build.log][build.log ]]
- libyui-mga-gtk  
[[https://kojipkgs.fedoraproject.org//work/tasks/3208/97843208/build.log][build.log ]]
- luxcorerender 
[[https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log ]]
- mcrouter  
[[https://kojipkgs.fedoraproject.org//work/tasks/7420/97847420/build.log][build.log ]]
- openshadinglanguage 
[[https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log ]]
- OpenImageIO  
[[https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log ]]
- usd 
[[https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log ]]


Hello.

A package I co-maintain, prusa-slicer, also failed to build and now it fails to 
install, but is not listed above.


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

The error was:

Error:
 Problem 1: package openvdb-devel-10.0.1-1.fc38.x86_64 requires 
libopenvdb.so.10.0()(64bit), but none of the providers can be installed
  - package openvdb-devel-10.0.1-1.fc38.x86_64 requires openvdb-libs(x86-64) = 
10.0.1-1.fc38, but none of the providers can be installed

  - conflicting requests
  - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
openvdb-libs-10.0.1-1.fc38.x86

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Miro Hrončok]

On 23. 02. 23 0:56, Richard Shaw wrote:
On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers > wrote:


The f39-boost side tag builds have finished.

The following packages FTBFS but the build logs provide no useful 
information -
- OpenImageIO 
[[https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log ]]



It may be true that the build logs weren't useful, but that's because the 
problem was in root.log. Either deps need to be analyzed to determine rebuild 
order, or after the initial build attempts have been done, they need to be 
repeated.


root.log shows the problem:
DEBUG util.py:443:  Error:
DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64 
requires libopenvdb.so.10.0()(64bit), but none of the providers can be installed
DEBUG util.py:443:    - package openvdb-devel-10.0.1-1.fc38.x86_64 requires 
openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be installed

DEBUG util.py:443:    - conflicting requests
DEBUG util.py:443:    - nothing provides libboost_iostreams.so.1.78.0()(64bit) 
needed by openvdb-libs-10.0.1-1.fc38.x86_64


I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at this point.


It appears openvdb wasn't rebuilt because there was a missing dependency 
(imath). But is should be possible to build openvdb now.


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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Richard Shaw]

On Wed, Feb 22, 2023 at 6:05 PM Miro Hrončok  wrote:

> On 23. 02. 23 0:56, Richard Shaw wrote:
> > On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers  > > wrote:
> >
> > The f39-boost side tag builds have finished.
> >
> > The following packages FTBFS but the build logs provide no useful
> information -
> > - OpenImageIO
> > [[
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
> <
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log%5D%5Bbuild.log
> >]]
> >
> >
> > It may be true that the build logs weren't useful, but that's because
> the
> > problem was in root.log. Either deps need to be analyzed to determine
> rebuild
> > order, or after the initial build attempts have been done, they need to
> be
> > repeated.
> >
> > root.log shows the problem:
> > DEBUG util.py:443:  Error:
> > DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64
> > requires libopenvdb.so.10.0()(64bit), but none of the providers can be
> installed
> > DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64
> requires
> > openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be
> installed
> > DEBUG util.py:443:- conflicting requests
> > DEBUG util.py:443:- nothing provides
> libboost_iostreams.so.1.78.0()(64bit)
> > needed by openvdb-libs-10.0.1-1.fc38.x86_64
> >
> > I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at
> this point.
>
> It appears openvdb wasn't rebuilt because there was a missing dependency
> (imath). But is should be possible to build openvdb now.
>

It's building now...
https://koji.fedoraproject.org/koji/taskinfo?taskID=97878135

Thanks,
Richard
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Miro Hrončok]

On 23. 02. 23 1:05, Miro Hrončok wrote:

On 23. 02. 23 0:56, Richard Shaw wrote:
On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers > wrote:


    The f39-boost side tag builds have finished.

    The following packages FTBFS but the build logs provide no useful 
information -
    - OpenImageIO 
[[https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log ]]



It may be true that the build logs weren't useful, but that's because the 
problem was in root.log. Either deps need to be analyzed to determine rebuild 
order, or after the initial build attempts have been done, they need to be 
repeated.


root.log shows the problem:
DEBUG util.py:443:  Error:
DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64 
requires libopenvdb.so.10.0()(64bit), but none of the providers can be installed
DEBUG util.py:443:    - package openvdb-devel-10.0.1-1.fc38.x86_64 requires 
openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be installed

DEBUG util.py:443:    - conflicting requests
DEBUG util.py:443:    - nothing provides 
libboost_iostreams.so.1.78.0()(64bit) needed by 
openvdb-libs-10.0.1-1.fc38.x86_64


I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at this point.


It appears openvdb wasn't rebuilt because there was a missing dependency 
(imath). But is should be possible to build openvdb now.


Trying that in https://koji.fedoraproject.org/koji/taskinfo?taskID=97878133

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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Iñaki Ucar]

I've pushed a fix for rstudio to rawhide. Can you please send a build
to the side tag?

Iñaki


On Wed, 22 Feb 2023 at 21:52, Thomas Rodgers  wrote:
>
> The f39-boost side tag builds have finished.
>
> The following packages are new FTBFS likely due to the Boost update -
> - mapnik [[https://bugzilla.redhat.com/show_bug.cgi?id=2172635][PR2172635]] 
> Boost.Phoenix related
> - credentials-fetcher  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172636][PR217636]] 
> Boost.Filesystem related
> - vsomeip3  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172639][PR2172639]] Boost.Asio 
> related
>
> The following packages are still FTBFS from the f38 mass rebuild -
> - 0ad [[https://bugzilla.redhat.com/show_bug.cgi?id=2171424][PR2171424]]
> - cryfs [[https://bugzilla.redhat.com/show_bug.cgi?id=2171464][PR2171464]]
> - folly [[https://bugzilla.redhat.com/show_bug.cgi?id=2165219][PR2165219]]
> - fbthrift [[https://bugzilla.redhat.com/show_bug.cgi?id=2171488][PR2171488]]
> - fast-netmon  
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2171487][PR2171487]]
> - nextpnr  [[https://bugzilla.redhat.com/show_bug.cgi?id=2171618][PR2171618]]
> - rstudio [[https://bugzilla.redhat.com/show_bug.cgi?id=2171710][PR2171710]]
> - widelands [[https://bugzilla.redhat.com/show_bug.cgi?id=2171759][PR2171759]]
>
> The following packages are new FTBFS not apparently related to Boost 1.81.0 -
> - condor [[https://bugzilla.redhat.com/show_bug.cgi?id=2172630][PR2172630]]
> - galera  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172633][PR2172633]]
> - gnu-cash  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172637][PR2172637]]
> - inkscape  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172638][PR2172638]]
> - sourcextractor++ 
> [[https://bugzilla.redhat.com/show_bug.cgi?id=2172642][PR2172642]]
> - wesnoth [[https://bugzilla.redhat.com/show_bug.cgi?id=2172627][PR2172627]]
>
> The following packages FTBFS but the build logs provide no useful information 
> -
> - blender 
> [[https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log]]
> - hugin  
> [[https://kojipkgs.fedoraproject.org//work/tasks/5732/97785732/build.log][build.log]]
> - libyui-mga-gtk  
> [[https://kojipkgs.fedoraproject.org//work/tasks/3208/97843208/build.log][build.log]]
> - luxcorerender 
> [[https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log]]
> - mcrouter  
> [[https://kojipkgs.fedoraproject.org//work/tasks/7420/97847420/build.log][build.log]]
> - openshadinglanguage 
> [[https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log]]
> - OpenImageIO  
> [[https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log]]
> - usd 
> [[https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log]]
>
> On Mon, Feb 20, 2023 at 9:16 AM Thomas Rodgers  wrote:
>>
>> Builds are starting now.
>>
>> On Thu, Feb 16, 2023 at 9:54 AM Thomas Rodgers  wrote:
>>>
>>> We expect to start rebuilds for 
>>> https://fedoraproject.org/wiki/Changes/F39Boost181
>>> in the f39-boost side tag Monday 2022-02-20.
>>>
>>> If your package depends on Boost, or just if you see a "Rebuilt for
>>> Boost 1.81" commit pushed to your package's dist-git repo, please
>>> coordinate with me about any updates to the package. If you need
>>> to push other changes to rawhide then you will need to build in the
>>> side tag, or we'll have to rebuild it multiple times.
>>>
>>> I expect to complete the builds and request the merge of the f39-boost
>>> side tag by Friday 2022-02-24.
>>>
>>>
> ___
> 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



-- 
Iñaki Úcar
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Kevin Fenzi]

On Thu, Feb 23, 2023 at 02:08:09AM +0100, Iñaki Ucar wrote:
> I've pushed a fix for rstudio to rawhide. Can you please send a build
> to the side tag?

The side tag has been merged back in. Just build in rawhide as normal. 

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Wed, Feb 22, 2023 at 04:44:29PM -0500, Neal Gompa wrote:
> > We could merge current repos into the newly created one from pungi, but
> > it would be a vast amount of work. It would mean all repodata would need
> > to be regenerated. That said, it could be done, but no one has had the
> > cycles to work on it.
> >
> 
> Maybe we should just publish into Pulp and have them do that bit for
> us automatically. I wouldn't personally be comfortable with that until
> Pulp is available in Fedora for people to easily deploy, but I know
> the COPR folks are investigating it for their tooling. And the
> AlmaLinux folks use Pulp for their system for similar reasons.
> 
> Pulp is designed to handle super-huge repositories like that.

I haven't looked at pulp in years... but back when I did it seemed
pretty complex and heavy, but sure we could look at it again. I suspect some
of the things we do wouldn't be to compatible, like bodhi injecting
security/bugfix/enhancement data into repodata after it's made. 

In any case we don't have it now, so I still think dropping drpms for
now is the way to go. 

kevin


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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

Looks like I missed capturing some dependencies in the Makefile that drives
these rebuilds. I'll adjust accordingly for the next time we update Boost.

On Wed, Feb 22, 2023 at 3:57 PM Richard Shaw  wrote:

> On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers 
> wrote:
>
>> The f39-boost side tag builds have finished.
>>
>> The following packages FTBFS but the build logs provide no useful
>> information -
>> - OpenImageIO  [[
>> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
>> ]]
>>
>
> It may be true that the build logs weren't useful, but that's because the
> problem was in root.log. Either deps need to be analyzed to determine
> rebuild order, or after the initial build attempts have been done, they
> need to be repeated.
>
> root.log shows the problem:
> DEBUG util.py:443:  Error:
> DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64
> requires libopenvdb.so.10.0()(64bit), but none of the providers can be
> installed
> DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64
> requires openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers
> can be installed
> DEBUG util.py:443:- conflicting requests
> DEBUG util.py:443:- nothing provides
> libboost_iostreams.so.1.78.0()(64bit) needed by
> openvdb-libs-10.0.1-1.fc38.x86_64
>
> I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at this
> point.
>
> Thanks,
> Richard
> ___
> 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
>
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed
now.

On Wed, Feb 22, 2023 at 4:05 PM Miro Hrončok  wrote:

> On 23. 02. 23 0:56, Richard Shaw wrote:
> > On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers  > > wrote:
> >
> > The f39-boost side tag builds have finished.
> >
> > The following packages FTBFS but the build logs provide no useful
> information -
> > - OpenImageIO
> > [[
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
> <
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log%5D%5Bbuild.log
> >]]
> >
> >
> > It may be true that the build logs weren't useful, but that's because
> the
> > problem was in root.log. Either deps need to be analyzed to determine
> rebuild
> > order, or after the initial build attempts have been done, they need to
> be
> > repeated.
> >
> > root.log shows the problem:
> > DEBUG util.py:443:  Error:
> > DEBUG util.py:443:   Problem: package openvdb-devel-10.0.1-1.fc38.x86_64
> > requires libopenvdb.so.10.0()(64bit), but none of the providers can be
> installed
> > DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64
> requires
> > openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be
> installed
> > DEBUG util.py:443:- conflicting requests
> > DEBUG util.py:443:- nothing provides
> libboost_iostreams.so.1.78.0()(64bit)
> > needed by openvdb-libs-10.0.1-1.fc38.x86_64
> >
> > I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at
> this point.
>
> It appears openvdb wasn't rebuilt because there was a missing dependency
> (imath). But is should be possible to build openvdb now.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Kevin Kofler via devel]

Gordon Messmer wrote:
> I'm not sure if that means that you are opposed to the proposal, or to
> the idea of truncating the version numbers, or something else entirely. 
> :)

I see the value of the proposal, but I am worried that it may run into 
issues with upstream packages using very weird library version numbers, so I 
am not yet convinced that it is really a good idea.

The more operations you do to the version numbers (e.g., truncating), the 
higher the risk that something gets messed up. I can see why you would want 
to avoid unnecessarily strict requirements, but some libraries add APIs even 
in last-digit version numbers, so you may end up missing a needed versioned 
dependency.

In the end, I am not sure whether this is really safe to automate. Though 
the current practice of manually adding such versioned requirements is 
clearly not working, as we packagers often have no idea what version we 
should require, also depending on what version happened to be used at build 
time. (I do not blame the packagers for that. I am one myself and really do 
not want to get into adding such versioned dependencies manually.)

On the other hand, I do not know how many of the weird versioning examples I 
have shown below actually come up in the wild. I am pretty sure I have seen 
examples of the:
>> libfoo.so → libfoo.so.1 → libfoo.so.4.5.6
>> libfoo.so → libfoo.so.4 → libfoo.so.1.2.3
type (and cursed at them), and I definitely have seen non-numeric versioning 
(such as Fedora using a downstream soversion with "rh" in it, e.g., 
"libfoo.so.7rh"). But I have not yet run into projects using SCM revisions 
(monotonic or not) in the version numbers.

>> The full version (or even the soversion, for that matter) is also not
>> guaranteed to be monotonic in any way. E.g., you could have:
>> libfoo.so → libfoo.so.1 → libfoo.so.1.deadbeef
>> or even just:
>> libfoo.so → libfoo.so.1 → libfoo.so.deadbeef
>> where "deadbeef" is a non-monotonic SCM hash (e.g., a git hash).
> 
> Right... as above, those would remain unversioned.

Well, there is a corner case in that a git hash is a hex number, which can 
happen to be all digits.

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

Unannounced .so version bump (F38/F39): openexr2

[Ben Beasley]

The openexr2 compat package was just updated from 2.5.7 to 2.5.8 in 
F39/Rawhide. This included a bump of the “imfsover,” the .so version for the 
libIlmImf-2_5 and libIlmImfUtil-2_5 libraries.

The following packages will need to be rebuilt in F39/Rawhide.

- CTL
- aqsis
- bcd
- kde-runtime
- kdebase3
- kdelibs
- luminance-hdr (I will take care of this one)
- synfig

There are other packages that link libraries from openexr2, but these should be 
the only ones that link the libraries affected by the .so version bump.

The package was also updated in F38/Branched, but the build is still only 
tagged into f38-updates-candidate, and no Bodhi update has been created. If the 
maintainer proceeds with the update for F38, all of the above dependent 
packages will need to be rebuilt there, too, once the update reaches stable. 
Alternatively, maybe the F38 build could be tagged into a side tag.___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

On Wed, Feb 22, 2023 at 2:41 PM Mamoru TASAKA 
wrote:

> Thomas Rodgers wrote on 2023/02/23 5:51:
> > The f39-boost side tag builds have finished.
> >
> > The following packages are new FTBFS likely due to the Boost update -
> >
> > The following packages FTBFS but the build logs provide no useful
> > information -
> > - blender [[
> >
> https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
> > ]]
>
> This is because of fail_fast = True. Actually other arch shows this build
> failed due
> to unresolved dependency:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=97841240
> https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/root.log
>
> > - luxcorerender [[
> >
> https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
> > ]]
> > - openshadinglanguage [[
> >
> https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
> > ]]
> > - OpenImageIO  [[
> >
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
> > ]]
> > - usd [[
> >
> https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
> > ]]
> >
>
>
OpenImageIO and openshadinglanguage are built in rawhide now.
luxcorereder is FTBFS on bcd dependency.
USD is FTBFS for a Boost related change PR2172762


The above 4 are all related to blender (I think), perhaps these all failed
> due to
> unresolved dependency, and perhaps these all needs some chainbuild (for
> new boost).
>
> Regards,
> Mamoru
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: Changes to Bugzilla API key requirements

[Kevin Kofler via devel]

Ben Cotton wrote:
> Red Hat Bugzilla has introduced a 12 month lifetimes for API keys. You
> must replace your API keys at least once a year. Additionally, any API
> key that is not used for 30 days will be suspended but can be
> re-enabled on the account's preferences tab.

So Red Hat Bugzilla API use again got unfriendlier.

The previous change was already unacceptable IMHO (going as far as 
invalidating any passwords accidentally attempted to be used through the 
API!), this makes it even worse.

IMHO, Fedora really needs its own bug tracker that is not driven by this 
kind of enterprise-grade security requirements.

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

Re: Unannounced .so version bump (F38/F39): openexr2

[Thomas Rodgers]

I rebuilt bcd, luxcorender is failing on it.

On Wed, Feb 22, 2023 at 7:43 PM Ben Beasley  wrote:

> The openexr2 compat package was just updated from 2.5.7 to 2.5.8 in
> F39/Rawhide. This included a bump of the “imfsover,” the .so version for
> the libIlmImf-2_5 and libIlmImfUtil-2_5 libraries.
>
> The following packages will need to be rebuilt in F39/Rawhide.
>
> - CTL
> - aqsis
> - bcd
> - kde-runtime
> - kdebase3
> - kdelibs
> - luminance-hdr (I will take care of this one)
> - synfig
>
> There are other packages that link libraries from openexr2, but these
> should be the only ones that link the libraries affected by the .so version
> bump.
>
> The package was also updated in F38/Branched, but the build is still only
> tagged into f38-updates-candidate, and no Bodhi update has been created. If
> the maintainer proceeds with the update for F38, all of the above dependent
> packages will need to be rebuilt there, too, once the update reaches
> stable. Alternatively, maybe the F38 build could be tagged into a side tag.
> ___
> 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
>
___
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

Self Introduction: Dalton Hubble

[Dalton Hubble]

Hey folks,

I'm an engineer working in the Go, cloud, and infrastructure space. I've been a 
Linux user for a while, a Fedora user for the last ~8 years, and used to work 
for CoreOS. I maintain a few open source Go libraries, maintain a Kubernetes 
distro, and operate the AS207563 network. When I can, I enjoy hiking and 
tinkering on my infra.

I'm glad to get aquainted and help with containerd packaging.

Dalton Hubble
https://github.com/dghubble
https://fosstodon.org/@dghubble
___
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: Self Introduction: Dalton Hubble

[Philip Rhoades via devel]

Dalton,

You have a famous name - are you related?

Phil.


On 2023-02-23 16:19, Dalton Hubble wrote:

Hey folks,

I'm an engineer working in the Go, cloud, and infrastructure space.
I've been a Linux user for a while, a Fedora user for the last ~8
years, and used to work for CoreOS. I maintain a few open source Go
libraries, maintain a Kubernetes distro, and operate the AS207563
network. When I can, I enjoy hiking and tinkering on my infra.

I'm glad to get aquainted and help with containerd packaging.

Dalton Hubble
https://github.com/dghubble
https://fosstodon.org/@dghubble
___
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


--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

On Wed, Feb 22, 2023 at 8:33 PM Thomas Rodgers  wrote:

>
>
> On Wed, Feb 22, 2023 at 2:41 PM Mamoru TASAKA 
> wrote:
>
>> Thomas Rodgers wrote on 2023/02/23 5:51:
>> > The f39-boost side tag builds have finished.
>> >
>> > The following packages are new FTBFS likely due to the Boost update -
>> >
>> > The following packages FTBFS but the build logs provide no useful
>> > information -
>> > - blender [[
>> >
>> https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
>> > ]]
>>
>> This is because of fail_fast = True. Actually other arch shows this build
>> failed due
>> to unresolved dependency:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=97841240
>> https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/root.log
>>
>> > - luxcorerender [[
>> >
>> https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
>> > ]]
>> > - openshadinglanguage [[
>> >
>> https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
>> > ]]
>> > - OpenImageIO  [[
>> >
>> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
>> > ]]
>> > - usd [[
>> >
>> https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
>> > ]]
>> >
>>
>>
> OpenImageIO and openshadinglanguage are built in rawhide now.
> luxcorereder is FTBFS on bcd dependency.
>

I rebuilt bcd, but luxcorender is FTBFS see PR2172776


USD is FTBFS for a Boost related change PR2172762
> 
>
> The above 4 are all related to blender (I think), perhaps these all failed
>> due to
>> unresolved dependency, and perhaps these all needs some chainbuild (for
>> new boost).
>>
>> Regards,
>> Mamoru
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-22 19:17, Kevin Kofler via devel wrote:

I see the value of the proposal, but I am worried that it may run into
issues with upstream packages using very weird library version numbers, so I
am not yet convinced that it is really a good idea.I



In case it helps: I started with the filelist in the "fedora" repo, and 
a list of all of the deps printed by dnf repoquery that ended with 
'()(64bit)', which should be a list of all of the ELF dependencies that 
don't have versioned symbols.  I compared the two to build a list of 
dependencies that match the prefix of a file in the file list, but not 
the entire file name (so the dependency "libssl.so.1.1()(64bit)" matches 
"libssl.so.1.1.1q").


In the "fedora" repo, I can only currently find about 11 dependencies 
that look like they'd be a symlink to a full name, where the full name 
suffix isn't a numeric version:


https://paste.centos.org/view/7e996c65 ("odd" full names)

https://paste.centos.org/view/0b26cb00 (the full list)

CentOS paste links don't last very long, so let me know if those expire 
too quickly.


___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Thomas Rodgers]

On Wed, Feb 22, 2023 at 12:51 PM Thomas Rodgers  wrote:

> The f39-boost side tag builds have finished.
>
> The following packages are new FTBFS likely due to the Boost update -
> - mapnik [[https://bugzilla.redhat.com/show_bug.cgi?id=2172635][PR2172635]]
> Boost.Phoenix related
> - credentials-fetcher  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2172636][PR217636]]
> Boost.Filesystem related
> - vsomeip3  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2172639][PR2172639]]
> Boost.Asio related
>
> The following packages are still FTBFS from the f38 mass rebuild -
> - 0ad [[https://bugzilla.redhat.com/show_bug.cgi?id=2171424][PR2171424]]
> - cryfs [[https://bugzilla.redhat.com/show_bug.cgi?id=2171464][PR2171464]]
> - folly [[https://bugzilla.redhat.com/show_bug.cgi?id=2165219][PR2165219]]
> - fbthrift [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2171488][PR2171488]]
> - fast-netmon  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2171487][PR2171487]]
> - nextpnr  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2171618][PR2171618]]
> - rstudio [[https://bugzilla.redhat.com/show_bug.cgi?id=2171710][PR2171710
> ]]
> - widelands [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2171759][PR2171759]]
>
> The following packages are new FTBFS not apparently related to Boost
> 1.81.0 -
> - condor [[https://bugzilla.redhat.com/show_bug.cgi?id=2172630][PR2172630
> ]]
> - galera  [[https://bugzilla.redhat.com/show_bug.cgi?id=2172633][PR2172633
> ]]
> - gnu-cash  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2172637][PR2172637]]
> - inkscape  [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2172638][PR2172638]]
> - sourcextractor++ [[
> https://bugzilla.redhat.com/show_bug.cgi?id=2172642][PR2172642]]
> - wesnoth [[https://bugzilla.redhat.com/show_bug.cgi?id=2172627][PR2172627
> ]]
>
> The following packages FTBFS but the build logs provide no useful
> information -
> - blender [[
> https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
> ]]
> - hugin  [[
> https://kojipkgs.fedoraproject.org//work/tasks/5732/97785732/build.log][build.log
> ]]
>
Missed transitive boost dependency on openexr, built now.

> - libyui-mga-gtk  [[
> https://kojipkgs.fedoraproject.org//work/tasks/3208/97843208/build.log][build.log
> ]]
>
Built now.

> - luxcorerender [[
> https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
> ]]
> - mcrouter  [[
> https://kojipkgs.fedoraproject.org//work/tasks/7420/97847420/build.log][build.log
> ]]
>
FTBFS # folly dependency

> - openshadinglanguage [[
> https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
> ]]
> - OpenImageIO  [[
> https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
> ]]
> - usd [[
> https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
> ]]
>
> On Mon, Feb 20, 2023 at 9:16 AM Thomas Rodgers 
> wrote:
>
>> Builds are starting now.
>>
>> On Thu, Feb 16, 2023 at 9:54 AM Thomas Rodgers 
>> wrote:
>>
>>> We expect to start rebuilds for
>>> https://fedoraproject.org/wiki/Changes/F39Boost181
>>> in the f39-boost side tag Monday 2022-02-20.
>>>
>>> If your package depends on Boost, or just if you see a "Rebuilt for
>>> Boost 1.81" commit pushed to your package's dist-git repo, please
>>> coordinate with me about any updates to the package. If you need
>>> to push other changes to rawhide then you will need to build in the
>>> side tag, or we'll have to rebuild it multiple times.
>>>
>>> I expect to complete the builds and request the merge of the f39-boost
>>> side tag by Friday 2022-02-24.
>>>
>>>
>>>
___
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: Changes to Bugzilla API key requirements

[Leigh Scott]

I wont be using the API again due to the 30 day limit.
If they change the password requirement again I will dump redhat bugzilla!
___
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: Help with systemd/cgroup task limits in koji

[Than Ngo]

Am 21.02.23 um 07:41 schrieb Florian Weimer:

* Kevin Fenzi:


Greetings.

We are running into some anoying limits on koji builds of chromium.

First, since a long time ago, the koji.service file we are using has:

TasksMax=infinity

But yet, chromium was failing, seemingly hitting a task limit.
"ninja: fatal: posix_spawn: Resource temporarily unavailable"
in the build and:
"kernel: cgroup: fork rejected by pids controller in
/machine.slice/machine-7d12b2e6dcfb4230b04d2c2c0b499171.scope/payload"
on the builder.

Investigation and some help from folks in the #devel room
(many thanks glb!)
Showed that the systemd-nspawn container mock started has:

systemctl show systemd-nspawn@0b3f01a2a8e345a389b30c477812c471
TasksMax=16384

So, I put in place a:
/etc/systemd/system/systemd-nspawn@.service.d/override.conf
with:

[Service]
TasksMax=infinity

and that seemed to be used for the mock systemd-nspawn containers.

However, the builds with lots of cpus is now failing later with:

Error: spawn /usr/bin/node-18 EAGAIN
     at Process.ChildProcess._handle.onexit
(node:internal/child_process:283:19)
     at onErrorNT (node:internal/child_process:476:16)
     at processTicksAndRejections (node:internal/process/task_queues:82:21)
[!] Error: unfinished hook action(s) on exit:

Is there yet another layer here that has another limit?

Is there anything here I can set that says "infinity all the way down' ?

Assistance welcome. I can file a systemd bug, but I am not sure
this is a bug more than a lack of documentation.

It could be an old kernel bug:

   Task exit is signaled before task resource deallocation, leading to
   bogus EAGAIN errors
   

There have been recent namespace optimizations which introduce a similar
pattern there.  While they improve throughput in many cases, continuous
allocation and deallocation can now fail, even though the program logic
ensures that resources are never exceeded.


i am not sure if it's an old kernel bug, because 
kernel-6.1.7-200.fc37.aarch64 is running on koji builds of chromium.


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