Re: how to do minor bump using %autorelease?

[Michael J Gruber]

Kevin Kofler via devel venit, vidit, dixit 2024-04-28 23:55:37:
> Julian Sikorski wrote:
> > I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> > mame-0.265-1.fc41 is already built against it so I only need to build
> > mame-0.265-1.fc40.1. Can it be done using %autorelease?
> 
> No, which is why you should not be using %autorelease.
> 
> I would just replace %autorelease with a correctly manually bumped Release 
> in the specfile as part of doing the rebuild.
> 
> Just letting %autorelease do its thing and ending up with a full bump would 
> be incorrect, so it should not even be considered as an option.

Bumping to mame-0.265-1.fc40 to mame-0.265-2.fc40 for a rebuild against
a changed dependency is the normal and recommended way of doing
rebuilds, whether you bump manually or using autolease.

A minor bump (as in %{?dist}[.]) only comes into play
if a "lower" branch needs to move forward without creating a version
ahead of a "higher" branch. And (independent of autorelease) you cannot
do that unless you use divergent git branches and cherry-picks in
dist-git, in which case "version" makes sense per branch only anyways.

In a dist-git where you work with release branches "contained" in
rawhide - and use macros extensively - you automatically have commits
which you merge down but which don't affect all branches, e.g. rebuild commits
for dependencies or mass rebuilds. I'm not saying this is the best way
of doing things (we should do it differently), but it's a common
pattern. So you can have the "f40 mass rebuild" commit in an f39 branch.
And in a world where you have and accept that, you can also push a
"rebuild for libfoo" to rawhide and merge down to f40 if that is what
you need to have f40 versions <= rawhide versions.

But as others have pointed out, in the light of distrosync and
macro-determined differences etc. we may just as well give up the
illusion that "-5" means the same in different branches, and
consequently lift the sorting policy between different branches.

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

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Michael J Gruber]

Jan Kolarik venit, vidit, dixit 2024-04-26 08:56:48:
> Hi Kevin,
> 
> Personally, I think this is a beta requirement.
> >
> 
>  IIUC the Fedora 41 Beta requirement is to successfully upgrade the system
> from Fedora 40, as mentioned here:
> https://fedoraproject.org/wiki/QA:Testcase_upgrade_dnf_current_workstation.
> So this still relates to the dnf4 package, which is used in Fedora 40. I
> expect this will become relevant for dnf5 at the Fedora 42 Beta.
> 
> So, how do you rate the chances of having something ready by beta
> > freeze?
> >
> 
> Talking about "something", there's already a system-upgrade command
> available in this dnf5 version from the side-tag :) However, as I mentioned
> earlier, it hasn't been thoroughly tested yet; that's our goal for the
> upcoming months.

Hi folks,

I'm afraid I added to the confusion via a typo. I wondered specifically
about the update F41->F42 because F40->F41 seemed to be off the table:

> On Thu, Apr 25, 2024 at 7:55 PM Kevin Fenzi  wrote:
> 
> > On Thu, Apr 25, 2024 at 11:42:57AM GMT, Jan Kolarik wrote:
> > > Hello Michael,
> > >
> > > Does this mean that distro-upgrade from F41 to F42 is supposed to work
> > > > at F41 release time (ideally at beta time)?

No typo in "F41 to F42", but this functionality needs to be ready by F42 (!)
release time, ideally at beta time, so that it can be used and tested.
If we consider "dnf5 distro-upgrade" to be a feature then it has to be there
by F41 feature freeze time actually. And that is why - if dnf5 as
default comes to rawhide now, which is leading up to F41 - we have to be
reasonably sure that the distro-upgrade feature will be ready in time
for the next (F41) feature freeze.

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

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Michael J Gruber]

Jan Kolarik venit, vidit, dixit 2024-04-25 07:42:10:
> Hello everyone,
> 
> We've prepared a side-tag for testing Rawhide with dnf5 as the default
> package manager. Instructions for installing the packages from the side-tag
> can be found at the following link [1].
> 
> Please provide feedback in Bodhi or on this mailing list regarding the use
> cases you're familiar with from the existing dnf command, and share your
> experience with this new version.
> 
> If there's no negative feedback regarding any critical functionality, we
> plan to push the packages from the side-tag to Rawhide next week.

Does this mean that distro-upgrade from F41 to F42 is supposed to work
at F41 release time (ideally at beta time)?

I'm all for dnf5 and would use it now (and hat an epsisode on F39), but
since distro-ugrades F40->F41 are off the table (as has been stated)
it's not a good idea to use it in F40 unless you are willing to deal
with autoremove trouble and the like.

So, if we push dnf5 as default to rawhide now we have to be reasonably
sure that F41 will distro-ugrade to F42 using dnf5.

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

Re: Orphaned packages looking for new maintainers

[Michael J Gruber]

Michel Lind venit, vidit, dixit 2024-04-12 21:59:42:
> On Fri, Apr 12, 2024 at 07:59:46AM -0700, Carlos Rodriguez-Fernandez wrote:
> > Regarding libteam, the author of the package is the maintainer, email in
> > bugzilla is different than the one on the project. I wonder if Jiro just
> > missed the notification that his package is failing to build in F40.
> > 
> Indeed. cc-ing Jiri to see if he wants to be added back. Jiri, if you do
> so, maybe change your email in
> https://accounts.fedoraproject.org/user/salimma/settings/email/ ?
> 
> Meanwhile I'm doing a build that removes the network-scripts-teamd
> subpackage - my initial glance at the changelog was wrong, most Fedora
> releases are already on 1.32 so we don't need to bump the package yet.
> 

Don't we need to obsolete the subpackage, though, so that it gets
removed on upgrade? Or can we rely on the fact that it had been pulled
in as a dependency only (rather than installed directly)?

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

soname bump: mupdf 1.24.1 coming to rawhide and F40

[Michael J Gruber]

Hi there,

1.24.0 was followed by a mostly bugfix minor release 1.24.1, which
bumped soname, though. I have been using this locally (first on F39,
then on F40 beta) for a while now so that I'm confident we can bring
it to both rawhide and F40. (Also, upstream has slowed down since...).

I built mupdf in a side-tag for rawhide and F40, and will rebuild the following
dependencies:

python-PyMuPDF
zathura-pdf-mupdf

There is one more dependency that I'm aware of. Since I don't have
commit rights I filed a PR:

https://src.fedoraproject.org/rpms/qpdfview/pull-request/5

In case I missed a dependency feel free to:

fedpkg build --target=f41-build-side-87501
fedpkg build --target=f40-build-side-87511

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

Re: convert everything to rpmautospec?

[Michael J Gruber]

Remi Collet venit, vidit, dixit 2024-04-09 10:23:57:
> Le 08/04/2024 à 18:43, Michael J Gruber a écrit :
> 
> > How absurd!
> 
> That is rude, and ONLY your PoV.
> 
> 
> To summarize, there is no agreement on a unique
> workflow, and having one to become the only allowed
> seems to me as a terrible idea.

I would be grateful I you didn't cut the context which explains my
statement (and invalidates your judgement).

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

Re: convert everything to rpmautospec?

[Michael J Gruber]

Zbigniew Jędrzejewski-Szmek venit, vidit, dixit 2024-04-07 17:15:16:
> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

An interesting proposal with unsurprising reactions from the expected
people ;)

Can I add +200 if others add -100, and what does that even mean? Kidding
aside, and putting the obvious "Makes my workflow work", "Destroys my
workflow", "Change? Hell no" aside, too, I think it's worthwhile to
take a step back and widen one's view towards the question:

Do we consider dist-git to be a version control system (vcs) for spec
files?

Historically we have not quite, which is no wonder given the cvs
heritage.  But, assuming for a moment that we do mean version control
seriously and look at the status quo ante rpmautospec ("legacy specs")
and what we do there:

- We put the version ("release" in our terms) of the spec file in the
  version controlled spec file.
- We put the log of the changes in the version controlled files.

How absurd!

Really, from the point of view of version control, anything that takes
this version information out of the versioned spec is better than legacy
specs. rpmautospec is the only such thing which we have right now.

On the practical side, I was sceptical about some shortcomings of
rpmautospec in the beginning, but it's really such a time (and nerve)
saver whenever you need to pick changes - be it from merge requests
against a moved head, from your own feature branches in dist-git forks
where you prepare changes, etc. All information is where it belongs
(change+log), and there are no artificial conflicts (release,
changelog) and no bogus dates.

Also, I find that many packages treat the dist-git log as more or less
worthless nuisance. rpmautospec helps you put both packager and user
info in one place (the commit message) and encourages to care about
both. Since some may not know:
```
Rebase to upstream x.y.z

- shiny new feature S
- various bug fixes

Also, we clean-up the spec file (white space, patch macros).
```
is a commit message which has both user info ("changelog", the first
line/header plus the dashed lines) and the info for other packagers -
how neat is that? You want it, too, admit it :)

We have other "vcs short-comings", of course, such as the fact that we
don't really use merges and feature branches in dist-git. Almost
consequently, rpmautospec does not deal well with merges. It does work
well with cherry-picks, though.

Since it's been mentioned: While (fast forward) merging the ubiquitious
"rebuild for..." commits down to lower releases does not do any "harm",
having a message like "rebuild for bar 24.7" in a release branch where
"bar" is at "23.3" is quite misleading. It's rooted in "cvs think" and
not using feature branches properly. rpmautospec can solves this easily
with cherry-picks now and, possibly, with merges later once it supports
merges better and we accept a true branch model in dist-git ;)

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

Re: "fedpkg local" builds fail for rust packages

[Michael J Gruber]

Fabio Valentini venit, vidit, dixit 2024-04-04 22:41:19:
> On Thu, Apr 4, 2024 at 9:42 PM pfed--- via devel
>  wrote:
> >
> > On Thu, Apr 04, 2024 at 09:51:31AM +0200, Fabio Valentini wrote:
> > > > > The short answer is: No, "fedpkg local" is not expected to work for
> > > > > Rust packages, and probably won't ever work as expected for Rust
> > > > > packages.
> > > > >
> > > > > I am not really interested in adding the "--allow-dirty" flag (not
> > > > > sure if it would even work in this case), since building Rust packages
> > > > > with "fedpkg local" is not working for other reasons. Primarily,
> > > > > "fedpkg local" does not support dynamically generated BuildRequires -
> > > > > this is only supported when building in mock.
> > >
> > > > I don't know what you mean? For me after patching the macro locally
> > > > local builds work as expected. Maybe I'm overlooking something?
> > >
> > > You might be lucky and just tried to package a Rust crate with no
> > > dependencies?
> > > Dependencies on other Rust crates are only resolved dynamically at build
> > > time, which "fedpkg local" does not support. So it works "by accident" for
> > > Rust crates with no crate dependencies, but in general, it can't work.
> >
> > That would have been extremely lucky, but no, I'm building crates with
> > dependencies. And the build generates the requires list just fine.
> >
> > What is not possible is installing build dependencies directly from a
> > spec file from a fresh clone, if that is what you mean? But in this case
> > running a local build generates a `.buildreqs.nosrc.rpm` file with the
> > correct dependencies, which can be passed to `dnf builddep`.
> >
> > And since a local build does not manage build dependencies themselves,
> > rather relies on them just being there, I don't really see an issue in
> > that?
> 
> If you really don't mind jumping through multiple hoops just because
> you want to use "fedpkg local" instead of "fedpkg mockbuild", then I
> guess I can't stop you.
> 
> All I *can* do is tell you that you're not going to like the experience:
> 
> - Using "fedpkg local" is not supported for Rust packages, and I won't
> be adding workarounds to the Rust macros for it.
> - Installing rust-*-devel packages on your local system (i.e. outside
> of ephemeral build environments) is not supported.
> - The "rust-*-devel" packages are build system implementation details,
> if you want to say it like that.
> - They are not shipped to users and are not useful for Rust developers.
> - They are *only* intended to be installed in temporary chroots (like
> those set up by mock).
> - They don't get "Obsoletes" or "Provides" in case there are dropped
> subpackages and / or incompatible updates. This is not an issue
> because they are only ever *installed*, but never supposed to be
> *upgraded* in-place. Any issues you get by installing them on your
> host system are your own.

So you're saying that those packages are in the repos for everyone but
not meant to be installed by anyone (besides mock chroots), and that is
how and why they are packaged.

`This package contains library source intended for building other packages which
use the "xyz" crate.`

Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
mockbuild` it. Does a rebuild from `fedpkg srpm` even work?

Wow!

Is there any other set of packages which we package like that?

If that is how you do things for the rust eco-system, those "devel"
packages should be clearly distinguished from real development packages,
come with a huge boiler plate "do not install" - or, really, be in a
separate repo if installing them is both worthless and misleading for
any "real" user. CRB for Fedora material.

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

Re: soname bump: mupdf 1.24.0 coming to rawhide

[Michael J Gruber]

Am Fr., 22. März 2024 um 11:21 Uhr schrieb Michael J Gruber
:
>
> Hi there,
>
> We recently switched mupdf to shared builds because part of the
> ecosystem relies on this, and because we finally could get upstream to
> version the libs. As a consequence, major mupdf updates will include
> an soname bump now, and this is the first one.
>
> I built mupdf in a side-tag for rawhide and will rebuild the following
> dependencies:
>
> python-PyMuPDF
> zathura-pdf-mupdf
>
> There is one more dependency that I'm aware of. Since I don't have
> commit rights I filed a PR:
> https://src.fedoraproject.org/rpms/qpdfview/pull-request/3
>
> In case I missed a dependency feel free to:
>
> fedpkg build --target=f41-build-side-86089
>
> I have been using copr builds already for a while, so I'm confident
> this update can go into F40 as well before the freeze (in a separate
> side-tag).

Rawhide done, F40 in the works:

https://src.fedoraproject.org/rpms/qpdfview/pull-request/4

f40-build-side-86231

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

soname bump: mupdf 1.24.0 coming to rawhide

[Michael J Gruber]

Hi there,

We recently switched mupdf to shared builds because part of the
ecosystem relies on this, and because we finally could get upstream to
version the libs. As a consequence, major mupdf updates will include
an soname bump now, and this is the first one.

I built mupdf in a side-tag for rawhide and will rebuild the following
dependencies:

python-PyMuPDF
zathura-pdf-mupdf

There is one more dependency that I'm aware of. Since I don't have
commit rights I filed a PR:
https://src.fedoraproject.org/rpms/qpdfview/pull-request/3

In case I missed a dependency feel free to:

fedpkg build --target=f41-build-side-86089

I have been using copr builds already for a while, so I'm confident
this update can go into F40 as well before the freeze (in a separate
side-tag).

Upstream's focus is not so much on distro-packaging and linux rather
than bundling and other platforms. So we have to see how this goes
abi/bumpwise in the future, but they have been willing to do quite
some work to adjust - kudos to them (Artifex) for that.

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

Re: Package conflict management advice

[Michael J Gruber]

Am Di., 19. März 2024 um 11:53 Uhr schrieb Iñaki Ucar :
>
> Dear all,
>
> I'm looking for options/advice here. See [1], and a bit of context:
>
> - RStudio (now Posit.co) publishes two packages named rstudio (with RStudio 
> Desktop) and rstudio-server (with RStudio Server). They are independent and 
> have many files in common. Recent versions are based on Electron (for 
> Desktop) and have Quarto support.
>
> - In Fedora, we decided to package all the common files in the rstudio 
> package, then build rstudio-desktop and rstudio-server for these products, 
> with just the specific files. In our build, we rely on QtWebEngine for the 
> Desktop version and disable Quarto, because it would be a nightmare to 
> package (requires Deno).
>
> Now the issue [1]: there's always been confusion among users that at some 
> point install the rstudio package provided by Posit (which provides 
> everything), many times because RStudio prompts that there's a new version 
> available and they just go click unknowingly. After some time, the package 
> manager "updates" it to our version when we hit stable, and RStudio Desktop 
> is gone (because rstudio-desktop is not present). Some time ago, I disabled 
> the "new version" notification dialog to mitigate this, but these days this 
> happens more and more frequently because users want Quarto and specifically 
> opt for the package provided by Posit.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2270191
>
> What do you think is the best way to mitigate this? Options:
>
> 1. Keep things as they are, just tell the users to exclude the rstudio 
> package in the dnf configuration. Pros: no changes required. Cons: it's clear 
> that users don't know how to do this. And more documentation rarely solves 
> this kind of problem.
>
> 2. Make rstudio Requires rstudio-desktop. Pros: When the package manager 
> updates to our version, at least there's a working version of RStudio 
> installed. Cons: Server users shouldn't need Desktop installed. Still 
> confusing to users.
>
> 3. Rename rstudio as rstudio-common, keep rstudio as a metapackage that just 
> Requires rstudio-desktop. Pros: Same as before + Server doesn't need Desktop. 
> Cons: Still confusing to users.
>
> 4. Rename rstudio as rstudio-common, make this one Conflicts rstudio. Pros: 
> You either install rstudio from Posit, or rstudio-desktop from Fedora. And 
> I'm not sure about this, but does installing one remove the other? Or does 
> dnf at least show the conflict and the user decides? Cons: `dnf install 
> rstudio` doesn't work anymore, so it's less discoverable. And we have a 
> similar issue with rstudio-server anyways that cannot be easily solved. But I 
> suppose that admins installing rstudio-server know how to prevent package 
> updates.
>
> 5. Introduce some version component that makes our package versions be sorted 
> < than Posit's. Pros: Upgrades never happen when a user opts for packages 
> provided by Posit. Cons: I don't know how to do this without breaking our 
> updates. Probably other issues?
>
> Any advice? Other options not considered here?

Wow, contrived situation. I guess this shows again that packaging
should be left to packagers, not upstream :)

4. seems to be the only solution where "problematic but typical" user
behaviour leads to explicit conflicts rather than "funny" behaviour.
`dnf` will bail out and explain the conflicts ("cannot install both
...") and even suggest to use "allow-erasing", which cleans things up.
dnf will not offer "rstudio" updates if there is no such package in
Fedora repos.

Even in this case, one can only hope that users don't switch
inadvertently between "upstream" and Fedora. At least it requires
extra steps with 4 (though I don't now about pkgkit).

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

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

[Michael J Gruber]

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

> BTW: f40 also is affected by the FTBFS.
>
> > How do you test the
> > fitz plugin?
>
> No idea. All I did was to address the FTBFS ;)
>
> > (BTW: qpdfview needs to remove deprecated patchN, too.)
> I know ;)
>
> I would suggest you to  apply your patches to qpdfview to rawhide, ASAP?
> I'd then pick them up and add qpdfview (w/ your patches) to my side-tag.

https://src.fedoraproject.org/rpms/qpdfview/pull-request/2

(I'm not a pp and don't have commit rights there.)

In addition, I've rebuilt qpdfview locally (F39 mock with my mupdf
copr for the rawhide mupdf.spec built on F39), tested and installed.
Display of PDFs and annotations work. I don't know how the fitz plugin
is used, though.

The shared build of mupdf is in rawhide and F40. Since I"ve used it on
F39 myself for a few weeks now, I wouldn't mind merging this down to
F39 if it makes things easier for you.

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

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

[Michael J Gruber]

Am Fr., 1. März 2024 um 10:19 Uhr schrieb Ralf Corsépius :
>
>
>
> Am 01.03.24 um 09:34 schrieb Michael J Gruber:
> > Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius 
> > :
> >>
> >> Hi,
> >>
> >> I intend to update gumbo-parser to 0.12.1 in rawhide.
> >> This comes along with an soname bump libgumbo to libgumbo.so.2
> >>
> >> This requires a rebuilt of several dependent packages, AFAICT:
> >> claws-mail
> >> litehtml
> >> mupdf
> >> perl-HTML-Gumbo
> >> python3-PyMuPDF
> >> qpdfview
> >> zathura-pdf-mupdf
>
> This was the list of packages depending on gumbo for f39.
>
> In rawhide, for reasons, I don't know, python3-PyMuPDF and
> python3-PyMuPDF do not seem to depend on gumbo, anymore.
>
> >> I'll try to rebuild these packages on side-tag f41-build-side-84865
> >> (Please, bear with me, I haven't used side-tags, before. I couldn't find
> >> any usable docs on how to use them)
> >>
> >> Preliminary tests indicate, something unrelated to libgumbo.so.* has
> >> changed with these packages (Probably mupdf), causing gpdfview to FTBFS
> >> and dependency changes in rawhide.
> >
> > Interesting. I wasn't aware of that dependency - I guess I have to
> > re-run detection more often.
>
> The version of mupdf in rawhide seems to have dropped libmupdf-third,
> which seems to be the origin of qpdfview's FTBFS.
>
> I don't know, if this change is intentional or happened by accident.

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

I have a working local mockbuild for qpdfview now. How do you test the
fitz plugin?

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

Michael

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

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

[Michael J Gruber]

Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius :
>
> Hi,
>
> I intend to update gumbo-parser to 0.12.1 in rawhide.
> This comes along with an soname bump libgumbo to libgumbo.so.2
>
> This requires a rebuilt of several dependent packages, AFAICT:
> claws-mail
> litehtml
> mupdf
> perl-HTML-Gumbo
> python3-PyMuPDF
> qpdfview
> zathura-pdf-mupdf
>
> I'll try to rebuild these packages on side-tag f41-build-side-84865
> (Please, bear with me, I haven't used side-tags, before. I couldn't find
> any usable docs on how to use them)
>
> Preliminary tests indicate, something unrelated to libgumbo.so.* has
> changed with these packages (Probably mupdf), causing gpdfview to FTBFS
> and dependency changes in rawhide.

Interesting. I wasn't aware of that dependency - I guess I have to
re-run detection more often. Speaking of - do we have a policy about
this? This is not about blaming, but how do we ensure that everyone is
aware of new dependencies? Frequent re-runs to detect them or
announcements the other way round?

I switched mupdf from the old static build (which required many
side-tag rebuilds) to a shared rebuild which will reduce dependency
rebuilds in the future (and follows upstream's choice for their
dependent package). I coordinated this with all dependent packages
that I was aware of.

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

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

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

Re: google-re2 pacakge update and facebook vs google python bindings ?

[Michael J Gruber]

Am Sa., 24. Feb. 2024 um 03:37 Uhr schrieb Adam Williamson
:
>
> On Fri, 2024-02-23 at 13:36 -0500, Paul Wouters wrote:
> > On Wed, 7 Feb 2024, Ben Beasley wrote:
> >
> > > Subject: Re: google-re2 pacakge update and facebook vs google python 
> > > bindings
> >
> > I haven't heard back from any of the maintainers.
> >
> > I've created a PR to upgrade re2-2022-06-01 to re2-2024-02-01 as the
> > first step towards getting python-google-re2 working.
> >
> > https://src.fedoraproject.org/rpms/re2/pull-request/6
>
> You now seem to have just built re2 for Rawhide without any of the
> deps:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-daa3669e4d
>
> that's not how you're supposed to do things, these days. You should
> build re2 on a side tag and then get all the deps rebuilt on the same
> side tag, then create a combined update. The update failed tests
> because of this.
>
> The best thing to do at this point would be to create a side tag, bump
> re2 and do a new build on the side tag, then ask maintainers of
> dependencies and/or provenpackagers to rebuild the dependencies on the
> side tag.
> --

Also, the commit introduced a switch to autochangelog, which should be
the maintainer's decision, and is best done in a separate commit
before the bump. Besides, the changelog file was not committed to
dist-git. Did this just erase all changelog history from the rpm?

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

Re: Help with creating first PR for a package

[Michael J Gruber]

Am Di., 20. Feb. 2024 um 09:21 Uhr schrieb Loren M. Lang
:
>
> On Sun, Feb 18, 2024 at 06:08:53AM -0300, Priscila Gutierres wrote:
> > I created this post based on my own experience:
> > https://dev.to/prinewgirl/a-recipe-made-to-create-your-first-pr-for-the-fedora-project-21be
> > Hope it helps.
>
> Thanks, with these and an Kan-Ru's instructions, I was able to
> successfully push up my changes to my fork on Pagure. However, I did
> have one issue with the sources. The push initially failed with the
> error:
>
> Source file (or tarball) 'cachelib-0.12.0.tar.gz' wasn't uploaded
> to the lookaside cache.
>
> I assume that this is another restriction of not being a packager?
> However, I didn't see this addressed in the provided docs. I was able to
> bypass it with --no-verify, but the Fedora CI build that was triggered
> when I made my Pull Request fails since it couldn't find the uploaded
> sources.
>
> I was able to manually submit a passing CI build by pushing up the SRPM.
>

Hi there,

I've uploaded the sources to the lookaside cache for you, after
checking and confirming what you had checked already. I guess that is
the reason why uploads are allowed for packagers only - because you
confirm upfront that you will do these checks :)

As for the PR, it's the maintainer's decision, of course. I would
rewrite history at least to fold sources update in with the spec file
bump, and probably also the updated test exceptions.

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

Re: Feedback wanted - pruning old rawhide chroots in Copr

[Michael J Gruber]

Am So., 18. Feb. 2024 um 13:54 Uhr schrieb Miroslav Suchý :
>
> In Copr build system, we noticed that Fedora rawhide chroots can became large 
> and they stay forever as rawhide is never
> EOLed.
> We plan to work on this soon, but we are not sure what is best approach. I 
> want to ask you - the users of Copr - what
> will be convenient for you?
>
> The problem is described here https://github.com/fedora-copr/copr/issues/2933
>
> tl;dr version is:
>
>   * when you build into fedora-39 chroot then the chroot is one day declared 
> as EOLed and if you did not act, then the
> chroot from the project is deleted and we reclaim the storage space.
>
>   * when you build into rawhide chroot, then we keep last builds. Even if you 
> do not submit to this project anything for
> years, we still keep this chroot. And such chroots can occupy gigabytes of 
> storage.
>
>
> The problem is that builds in the rawhide can be packaged configs, and they 
> can be still usable despite the fact that no
> one rebuilds the RPM for years. Or it can be forgotten build that is not even 
> installable in current chroot. We do not
> know. And testing installability of package regularly will be expensive task.
>
> What **you** would find as acceptable policy for pruning rawhide chroots?

I see this somehow connected to the discussion about signing keys that
we had recently. A radical solution would be: branch rawhide, not from
rawhide. So, at the "F40 branch point we had last week", we would:
- switch the "alias" rawhide from "meaning f40" to "meaning f41"
- rename rawhide chroots to f40 in copr
- set up new rawhide chroots ("follow [up] fedora branching")

In most cases, "forked" packages in copr are misleading - they are in
a chroot without having been built against any version of it.

copr users would have to hit "rebuild", which should be OK.

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

Re: Need help with incompatible pointer types on i686

[Michael J Gruber]

Am Fr., 16. Feb. 2024 um 07:15 Uhr schrieb Elliott Sales de Andrade
:
>
> On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski  wrote:
> >
> > We're hitting this with h5py on i686:
> >
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> > ‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
> > passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
> > [-Wincompatible-pointer-types]
> > 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
> > __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
> >|
> >  ^~~
> >|
> >  |
> >|
> >  __pyx_t_5numpy_uint32_t * {aka long unsigned int *}
> > In file included from /usr/include/hdf5.h:25,
> >   from
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
> >   from
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
> > /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
> > ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
> > {aka ‘long unsigned int *’}
> >   1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const
> > hsize_t *offset, uint32_t *filters,
> >|
> >   ~~^~~
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> > ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
> > /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
> > assignment discards ‘const’ qualifier from pointer target type
> > [-Wdiscarded-qualifiers]
> > 31935 |   __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
> >| ^
> >
> >
> > It seems that numpy is defining a uint32_t type as long unsigned int on
> > i686, while glibc(?) is defining it as unsigned int.
>
> Yes, looking at NumPy's header [1], it appears to check `long` first,
> then `long long`, then `int`, then `short`, and assigns the first one
> that matches to the matching bit-length. So it should pick unsigned
> long for npy_uint32 before unsigned int if they are both 4 bytes wide.
>
> >  Now what puzzles
> > me a little is that on i686 aren't these both 4-byte integers and no not
> > incompatible at all?
>
> Yes, I think they are the same size, as demonstrated on a 32-bit mock:

They are the same (bit size, signedness, general type) but not equal
(long int vs int), and with gcc14 this became an error. I"m sure it
always warned about that before.

> > What should be done here?
> >
>
> I guess that depends on how glibc sets things up, but perhaps it would
> work better if NumPy checked from smallest to largest as defined in C
> (short -> int -> long -> long long)?
>
> [1] 
> https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488

numpy definitely needs to fix this. You cannot just go by bitsize and
signedness. You never could and now you can't ;)
I'm surprised this didn't come up during our "gcc 14 ride".

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:43 Uhr schrieb Kalev Lember :
>
> On Thu, Feb 15, 2024 at 5:30 PM Michael J Gruber  
> wrote:
>>
>> Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
>> the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
>> builds for fc39 and el9 yields
>>
>> libmupdf.so.23.10()(64bit)
>>
>> in both cases. I could try and stuff %__elf_provides into the spec for
>> a koji scratch debug run ...
>
>
> Is libmupdf.so.23.10 executable? It used to be the case that the elf depgen 
> only ran on executable files, IIRC. Maybe that has changed in recent Fedoras, 
> but still is the case in el9?

Gotcha! You rock! Thanks a bunch.

chmod +x'ing should be fine on Fedoras, as well. And from looking at
/usr/lib64 it's common anyways.

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:22 Uhr schrieb Petr Pisar :
>
> V Thu, Feb 15, 2024 at 05:10:34PM +0100, Michael J Gruber napsal(a):
> > Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
> > >
> > > V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > > > Hi there
> > > >
> > > > I recently switched mupdf to shared libraries. During test builds on
> > > > COPR for EPEL I noticed a strange difference to fedora builds which I
> > > > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > > > difference is in the automatic provides for the -libs sub package:
> > > >
> > > > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> > > >
> > > > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > > > mupdf-libs(x86-64) = 1.23.10-2.fc39
> > > >
> > > > And, of course, packages built against mupdf-devel automatically
> > > > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> > > >
> > > > I even tested with `%ldconfig_scriptlets libs`, which makes no 
> > > > difference.
> > > >
> > > > Both packages have the same file contents including the lib, the
> > > > SONAME is `libmupdf.so.23.10`.
> > > >
> > > Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion 
> > > about
> > > rpmbuild not to generate provides and requires for a SONAME if the libary 
> > > is
> > > not installed into a standard library path.
> >
> > It's in /usr/lib64/ in both cases (x86_64, checked with
> > rpmdev-extract). spec part is:
> >
> Does running a dependency generator for ELF files on that file report the
> expected provides? Look at /usr/lib/rpm/fileattrs/elf.attr content. There
> should be a ".../elfdeps --provides" command for generating provides. Take
> that command and pass the library file as a possitional argument. An example:
>
> /usr/lib/rpm/elfdeps --provides /usr/lib64/libacl.so.1.1.2301
> libacl.so.1(ACL_1.0)(64bit)
> libacl.so.1(ACL_1.1)(64bit)
> libacl.so.1(ACL_1.1)(64bit)
> libacl.so.1(ACL_1.2)(64bit)
> libacl.so.1(ACL_1.2)(64bit)
> libacl.so.1()(64bit)

Yes. That is: running `/usr/lib/rpm/elfdeps --provides` on F39 against
the two files libmupdf.so.23.10 rpmdev-extracted from the koji scratch
builds for fc39 and el9 yields

libmupdf.so.23.10()(64bit)

in both cases. I could try and stuff %__elf_provides into the spec for
a koji scratch debug run ...

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

Re: Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Am Do., 15. Feb. 2024 um 17:06 Uhr schrieb Petr Pisar :
>
> V Thu, Feb 15, 2024 at 04:57:10PM +0100, Michael J Gruber napsal(a):
> > Hi there
> >
> > I recently switched mupdf to shared libraries. During test builds on
> > COPR for EPEL I noticed a strange difference to fedora builds which I
> > can reproduce with koji scratch builds as well (epel9 vs fc39). The
> > difference is in the automatic provides for the -libs sub package:
> >
> > Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9
> >
> > Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
> > mupdf-libs(x86-64) = 1.23.10-2.fc39
> >
> > And, of course, packages built against mupdf-devel automatically
> > require ibmupdf.so.23.10()(64bit) and fail to install on *EL.
> >
> > I even tested with `%ldconfig_scriptlets libs`, which makes no difference.
> >
> > Both packages have the same file contents including the lib, the
> > SONAME is `libmupdf.so.23.10`.
> >
> Where is the file with libmupdf.so.23.10 SONAME? I remember a discussion about
> rpmbuild not to generate provides and requires for a SONAME if the libary is
> not installed into a standard library path.

It's in /usr/lib64/ in both cases (x86_64, checked with
rpmdev-extract). spec part is:

```
%files libs
%license COPYING
%{_libdir}/%{libname}.so.%{soname}
```

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

Provides: libmupdf.so.23.10()(64bit) missing on *EL

[Michael J Gruber]

Hi there

I recently switched mupdf to shared libraries. During test builds on
COPR for EPEL I noticed a strange difference to fedora builds which I
can reproduce with koji scratch builds as well (epel9 vs fc39). The
difference is in the automatic provides for the -libs sub package:

Provides: mupdf-libs = 1.23.10-2.el9 mupdf-libs(x86-64) = 1.23.10-2.el9

Provides: libmupdf.so.23.10()(64bit) mupdf-libs = 1.23.10-2.fc39
mupdf-libs(x86-64) = 1.23.10-2.fc39

And, of course, packages built against mupdf-devel automatically
require ibmupdf.so.23.10()(64bit) and fail to install on *EL.

I even tested with `%ldconfig_scriptlets libs`, which makes no difference.

Both packages have the same file contents including the lib, the
SONAME is `libmupdf.so.23.10`.

Is there any special magic on *EL which I need to do for the provides?

Differences I noticed in build.log:

epel9 uses `cc` and has
lto-wrapper: warning: using serial compilation of 47 LTRANS jobs

fc39 uses `gcc` and has extra flags
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes

Cheers
Michael

https://koji.fedoraproject.org/koji/taskinfo?taskID=113544172
https://koji.fedoraproject.org/koji/taskinfo?taskID=113544612
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Why branched config pointed to rolling config?

[Michael J Gruber]

Am Mi., 14. Feb. 2024 um 14:48 Uhr schrieb Mikhail Gavrilov
:
>
> Why branched config pointed to rolling config?
> # ls -ln | grep fedora-40
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
> fedora-rawhide-aarch64.cfg
> lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
> fedora-rawhide-i386.cfg
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
> fedora-rawhide-ppc64le.cfg
> lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
> fedora-rawhide-s390x.cfg
> lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
> fedora-rawhide-x86_64.cfg

... because on Jan 25th, f40 was rawhide.

We branched yesterday. So, either you wait for updated mock-config to
land in f40, or you roll it yourself. It's no mock science :)

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

Re: Bisecting an older kernel

[Michael J Gruber]

Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski :
>
> Hello,
>
> I am trying to bisect an issue which appears to have regressed between
> 5.18 final and 5.19-rc2. This is somewhat challenging as most of the
> kernels are since gone from koji, and the ark os-build branch seems to
> have been rebased after kernel 6.7 release, meaning that the required
> commits to the redhat folder are not in sync with the commits to the
> kernel itself.

I'm not sure I'm following this completely - are you saying that (part
of) the old kernel sources are not there (in git) any more because a
branch got rebased?

> I tried cherry-picking them on top, but it does not apply
> cleanly either:
>
> $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git
> $ git bisect start
> $ git bisect bad v5.19-rc2
> $ git bisect good v5.18
> $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659
> $ git cherry-pick
> 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6
>
> Is there a way simpler than trying to fix the cherry-pick conflicts
> every single time?

`rerere` can be really helpful for something like this.

I guess you've checked already whether the problem you're trying to
solve depends on the extra redhat commits.

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

Re: exiv2 and protobuf hard to do soname bump without turbulence

[Michael J Gruber]

Am Fr., 9. Feb. 2024 um 17:23 Uhr schrieb Sérgio Basto :
>
> Hi,
>
> I'd like to bring to your attention that Fedora would benefit with
> update of exiv2 [1] and  protobuf [2] but these packages have lots of
> dependencies and the update of the dependent packages is not trivial .
> tips, ideas and opinions ? to do these soname updates
>
> thank you
>
>
> [1]
> https://src.fedoraproject.org/rpms/exiv2/pull-request/6
>
> [2]
> https://src.fedoraproject.org/rpms/protobuf/pull-request/26

Is the legal question around bff solved?

I guess some time before the mass rebuild would have been a good time
for a major change ...

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

Re: poppler soname bump in Rawhide soon

[Michael J Gruber]

Am Mi., 31. Jan. 2024 um 11:15 Uhr schrieb Marek Kasik :
>
> Hi,
>
> On 1/30/24 12:15, Michael J Gruber wrote:
> > Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34:
> >> Hi,
> >>
> >> I plan to rebase poppler to 24.02.0 once it is released. It will be
> >> probably released this week and I would like to get it to rawhide before
> >> the branching together with rebuilds of dependent packages.
> >>
> >> I'll prepare the build in a side tag and will message relevant
> >> maintainers to rebuild their packages there.
> >>
> >> The packages which will need rebuilds:
> >>calligra
> >>gambas3
> >>gdal
> >>gdcm
> >>inkscape
> >>kf5-kitinerary
> >>libreoffice
> >>pdf2djvu
> >>scribus
> >
> > That list is surprisingly short. For example, poppler-glib requires a
> > specific poppler version, and via poppler-glib-devel that affects more
> > packages (zathura-pdf-poppler comes to my mind).
> >
> > Does libpoppler-glib stay at the same soname and "absorb" all poppler
> > changes behind its ABI?
>
> yes, libpoppler-glib and other front-ends are stable so they'll stay on
> their sonames. The soname which is going to be changed is soname of the
> core library which is not stable. The packages mentioned above uses the
> core library directly so we have to keep the unstable API available.

Thanks, that clarifies everything.

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

Re: poppler soname bump in Rawhide soon

[Michael J Gruber]

Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34:
> Hi,
> 
> I plan to rebase poppler to 24.02.0 once it is released. It will be 
> probably released this week and I would like to get it to rawhide before 
> the branching together with rebuilds of dependent packages.
> 
> I'll prepare the build in a side tag and will message relevant 
> maintainers to rebuild their packages there.
> 
> The packages which will need rebuilds:
>   calligra
>   gambas3
>   gdal
>   gdcm
>   inkscape
>   kf5-kitinerary
>   libreoffice
>   pdf2djvu
>   scribus

That list is surprisingly short. For example, poppler-glib requires a
specific poppler version, and via poppler-glib-devel that affects more
packages (zathura-pdf-poppler comes to my mind).

Does libpoppler-glib stay at the same soname and "absorb" all poppler
changes behind its ABI?

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

Re: Orphaning python-flit

[Michael J Gruber]

Am Fr., 26. Jan. 2024 um 09:26 Uhr schrieb Miro Hrončok :
>
> On 26. 01. 24 4:33, Nico Kadel-Garcia wrote:
> > What is the*fascination*  with splitting and renaming packages this
> > way?
>
> No idea generally, but in the world of Python packaging,
> the two cases I know (poetry, flit) were motivated by folks not wanting to 
> pull
> in full-blown package and environment management apps when they only want to
> pip install something that uses it.
>
> The split made a lot of sense.
>
> core - PEP517 backend https://peps.python.org/pep-0517/
> the rest - an app that let's you "manage" your project
>
> Scenario:
>
> - The developer uses the full app to create and develop the project.
> - The user uses -core to build and install it.
>
> (Obviously a developer is free to just use -core as well, if they like it. 
> Many
> upstream projects use flit-core only.)

It makes a lot of sense also if you think about it this way:
- packaging needs a solid base
- developers and (typical fedora) users want the latest and greatest

A split like in this case gives us both.

I have the impression that we package way too much stuff which would
be installed better on a per user base, such as many python and rust
and go (and ...) packages and fonts. This leads to many interesting
discussions and decisions about what kind of upgrade is right on
Fedora and even EPEL.

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

Re: Orphaning python-flit

[Michael J Gruber]

Am Fr., 26. Jan. 2024 um 09:26 Uhr schrieb Miro Hrončok :
>
> On 26. 01. 24 4:33, Nico Kadel-Garcia wrote:
> > What is the*fascination*  with splitting and renaming packages this
> > way?
>
> No idea generally, but in the world of Python packaging,
> the two cases I know (poetry, flit) were motivated by folks not wanting to 
> pull
> in full-blown package and environment management apps when they only want to
> pip install something that uses it.
>
> The split made a lot of sense.
>
> core - PEP517 backend https://peps.python.org/pep-0517/
> the rest - an app that let's you "manage" your project
>
> Scenario:
>
> - The developer uses the full app to create and develop the project.
> - The user uses -core to build and install it.
>
> (Obviously a developer is free to just use -core as well, if they like it. 
> Many
> upstream projects use flit-core only.)

It makes a lot of sense also if you think about it this way:
- packaging needs a solid base
- developers and (typical fedora) users want the latest and greatest

A split like in this case gives us both.

I have the impression that we package way too much stuff which would
be installed better on a per user base, such as many python and rust
and go (and ...) packages and fonts. This leads to many interesting
discussions and decisions about what kind of upgrade is right on
Fedora and even EPEL.

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

Re: Modern C i686 failures

[Michael J Gruber]

Yaakov Selkowitz venit, vidit, dixit 2024-01-24 21:01:39:
> The GCC 14 and Modern C changes have caused a large number of build
> failures.  No surprise there, but in particular though, a lot of these
> failures have only occurred on i686, e.g.  uint64_t (aka long long
> unsigned int) doesn't match long unsigned int *, etc.
> 
> A few examples:
> 
> gnome-keyring: https://koji.fedoraproject.org/koji/taskinfo?taskID=112010040
> ldns: https://koji.fedoraproject.org/koji/taskinfo?taskID=112074780
> ledmon: https://koji.fedoraproject.org/koji/taskinfo?taskID=112074925
> libfabric: https://koji.fedoraproject.org/koji/taskinfo?taskID=112077476
> libgphoto2: https://koji.fedoraproject.org/koji/taskinfo?taskID=112078167
> 
> Granted, in some cases this can be motivation to retire i686 leaves,
> but for those that are not leaves, they now need to be fixed for i686
> to complete the mass rebuild.
> 
> Given the increasingly limited usage of i686 in Fedora (not to mention
> CentOS Stream and RHEL), is it actually worth the effort to "fix" all
> the code just for 32-bit compatibility?  Or perhaps it's better if we
> focus on issues that pertain to our primary (64-bit) architectures?

That is an understandable impulse.

OTOH, I saw time_t vs int issues as well as uint64 vs int which were a
mismatch between ondisk (file format) and in-memeory data. Fixing these
now means getting ready for potential changes of time_t and similar -
unless you "fix" these things by wrong casts just to quell gcc, of
course. I just whish this had come upon us earlier in the cycle.

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

Re: gtk3 update breaks multiple packages

[Michael J Gruber]

Am Mi., 24. Jan. 2024 um 12:40 Uhr schrieb Milan Crha :
>
> On Wed, 2024-01-24 at 11:34 +0100, Leigh Scott wrote:
> > see
> > https://github.com/GNOME/gtk/commit/77ebdd85091833a7869ece48c3114fa6d9966321
>
> Hi,
> all the bugs you referenced crash in X11 code. The above NEWS file
> commit specifically says it's for Wayland.
>
> What am I missing here, please? Did you pick a wrong commit? What was
> the commit supposed to proof, please?

You missed reading the first NEWS entry ("* Fix a crash introduced in
the X11 changes in 3.24.40") and quoted the third only.

Now, whether that diff fixes our problems can only be "proved" by
rebasing our package or picking those commits and testing.

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

Re: Mass rebuild: git push --no-verify

[Michael J Gruber]

Am Do., 18. Jan. 2024 um 17:14 Uhr schrieb Jerry James :
>
> On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto  wrote:
> > You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
> > define what packages you are going to rebuild ,  in line 93 of mass-
> > rebuild.py [3] you got the list of packages that you go rebuild
> > and since line 132 [4] you have the commands that will run .
> > Is rpmdev-bumpspec that fails ?
>
> Thank you for the pointer, Sérgio.  I have opened
> https://pagure.io/releng/pull-request/11897.
>
> It is not rpmdev-bumpspec that fails.  That works just fine.  But any
> package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
> requires --no-verify today when pushing to git, due to the referenced
> bug.  That's merely annoying for a human, but fatal to an automated
> build script that doesn't pass --noverify.

No, that's not the case. Please re-read the bug.

For *some* of the packages among those which use these macros (but
definitely not all), the python bindings to rpm do not expand that
macro whereas rpm itself does.

Since `spectool` uses the bindings, its check for the presence of all
source files fails if the source macro contains an unexpanded macro.
The packages build fine.

Whether it's the bindings' fault, or the spec files', or the
rpm-font-macros' is unclear at this point. In any case the check
*wrongly* indicates FTBFS.

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

Re: Referencing an upstream subdir in the sources

[Michael J Gruber]

Am Mi., 10. Jan. 2024 um 11:39 Uhr schrieb Iñaki Ucar :
>
> Hi,
>
> A package has its source code embedded as a subdirectory of a larger
> piece of software. Sometimes they publish this subdirectory as a
> separate tar as a release artifact, but sometimes they forget.
>
> To avoid depending on their memory (and opening an issue each time), I
> would like to simply download the full repo and produce the tar
> myself. How should I deal with this in the spec? (Note: building this
> subdir as a subpackage in the main one is not a good idea in this
> case, it's not an option).

Hi,

I assume you don't want to distribute the full tar and simply cd into
it the proper subdir during the build? That would be the easiest
solution.

Alternatively, we (used to?) have several packages which need to clean
upstream sources before even committing them to the lookaside cache.
scribus comes to my mind, some crypto things were like that in the
past. What you typically do is:
- Write a simple script which mangles the upstream package.tar and
repackages it as package-free.tar or such.
- Add the script to dist-git.
- comment out the original source line in spec (and the signature if present)
- specify "source: package-free.tar" instead and comment on the use of
the script
- commit only package-free.tar to dist-git

That way, everyone can reproduce the used source code from the
upstream source code if needed while we only have the actual used
source in dist-git (lookaside).

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

Re: rawhide missing xgettext: command not found

[Michael J Gruber]

Am Do., 4. Jan. 2024 um 18:29 Uhr schrieb Martin Gansser
:
>
> Hi,
>
> when compiling vdr-extrecmenung for rawhide fc40 the error message [1] 
> "/bin/sh: line 1: xgettext: command not found" appears
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/6182/111296182/build.log
>
> How can i solve this ?

Add
BuildRequires: gettext
to the spec?

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

Re: Orphaning python-pytzdata

[Michael J Gruber]

Am Do., 28. Dez. 2023 um 20:34 Uhr schrieb Michael J Gruber
:
>
> Am Do., 28. Dez. 2023 um 16:07 Uhr schrieb Miro Hrončok :
> >
> > On 28. 12. 23 15:28, Michael J Gruber wrote:
> > > Am Di., 19. Dez. 2023 um 18:43 Uhr schrieb Miro Hrončok 
> > > :
> > >>
> > >> Hello,
> > >> I found myself being the main admin of python-pytzdata.
> > >>
> > >> I have not done this on purpose, somebody must have given the package to 
> > >> me.
> > >>
> > >> I'm orphaning it.
> > >>
> > >> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-pytzdata
> > >> python-maya-0:0.6.1-10.fc39.src
> > >> python-pendulum-0:2.1.2-12.fc39.src
> > >> python3-pendulum-0:2.1.2-12.fc39.x86_64
> > >>
> > >
> > > Hi there
> > >
> > > I've taken ownership to quell the warning for a package in the
> > > extended dependency chain. Feel free to take over if you're
> > > interested, or to tell me why and when this package should be retired.
> > > Upstream appears to be "slow" to put it nicely, but the issue tracker
> > > indicates people are still interested.
> > >
> > > Should dependent packages rather switch to pytz or python's own
> > > zoneinfo (from python 3.9 onwards)?
> >
> > I don't know, but at least this should be revisited:
> >
> > https://src.fedoraproject.org/rpms/python-pytzdata/pull-request/2
>
> Yes, I consider pytzdata as API to an external "db", and aligning
> pytzdata with tzdata (e.g. by building against it) is definitely a
> must. I'm wondering, though, why we don't simply use pzdata's feature
> of setting a different path in order to point to
> `/usr/share/zoneinfo`?

... and that is what your pr2 does, of course. Due to the
buildrequires, I misread it first. I'd tie the versions for now and go
with that.

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

Re: Orphaning python-pytzdata

[Michael J Gruber]

Am Do., 28. Dez. 2023 um 16:07 Uhr schrieb Miro Hrončok :
>
> On 28. 12. 23 15:28, Michael J Gruber wrote:
> > Am Di., 19. Dez. 2023 um 18:43 Uhr schrieb Miro Hrončok 
> > :
> >>
> >> Hello,
> >> I found myself being the main admin of python-pytzdata.
> >>
> >> I have not done this on purpose, somebody must have given the package to 
> >> me.
> >>
> >> I'm orphaning it.
> >>
> >> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-pytzdata
> >> python-maya-0:0.6.1-10.fc39.src
> >> python-pendulum-0:2.1.2-12.fc39.src
> >> python3-pendulum-0:2.1.2-12.fc39.x86_64
> >>
> >
> > Hi there
> >
> > I've taken ownership to quell the warning for a package in the
> > extended dependency chain. Feel free to take over if you're
> > interested, or to tell me why and when this package should be retired.
> > Upstream appears to be "slow" to put it nicely, but the issue tracker
> > indicates people are still interested.
> >
> > Should dependent packages rather switch to pytz or python's own
> > zoneinfo (from python 3.9 onwards)?
>
> I don't know, but at least this should be revisited:
>
> https://src.fedoraproject.org/rpms/python-pytzdata/pull-request/2

Yes, I consider pytzdata as API to an external "db", and aligning
pytzdata with tzdata (e.g. by building against it) is definitely a
must. I'm wondering, though, why we don't simply use pzdata's feature
of setting a different path in order to point to
`/usr/share/zoneinfo`? In that case, the version numbering should
probably change.

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

Re: Orphaning python-pytzdata

[Michael J Gruber]

Am Di., 19. Dez. 2023 um 18:43 Uhr schrieb Miro Hrončok :
>
> Hello,
> I found myself being the main admin of python-pytzdata.
>
> I have not done this on purpose, somebody must have given the package to me.
>
> I'm orphaning it.
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-pytzdata
> python-maya-0:0.6.1-10.fc39.src
> python-pendulum-0:2.1.2-12.fc39.src
> python3-pendulum-0:2.1.2-12.fc39.x86_64
>

Hi there

I've taken ownership to quell the warning for a package in the
extended dependency chain. Feel free to take over if you're
interested, or to tell me why and when this package should be retired.
Upstream appears to be "slow" to put it nicely, but the issue tracker
indicates people are still interested.

Should dependent packages rather switch to pytz or python's own
zoneinfo (from python 3.9 onwards)?

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

Re: rpmbuild sagemath 10.1 on Fedora 38

[Michael J Gruber]

Am Fr., 8. Dez. 2023 um 23:58 Uhr schrieb Jerry James :

> Please keep your replies on the public mailing list where the
> conversation started.
>
> On Fri, Dec 8, 2023 at 3:39 PM Rafel Amer Ramon 
> wrote:
> > As a first attempt, I didn't use the patches beacuse a lot of them
> failed.
> > Today I have revised and modified some of the patches and I can apply 20
> > of them.
>
> ...

> That would be great.  Hopefully upstream makes good progress on
> supporting python 3.12.
>

 Are there any packages in Fedora which depend on sagemath?

I don't want to discourage anyone from packaging sagemath. But I do think
that sagemath is a prime example of an "app", something that is best
installed as a user (not system wide) via a package manager such as
pip+venv/conda and the like, in particular isolating dependencies (exact
requirements) for that app.

I also think that we have too many leaf packages in Fedora and packagers'
time is better spent on a solid base, not fighting the dependency hell of
an app. Just my 2cents, and no, I'm not a flatpak fanboy either, but no
matter how you run "apps", a solid Fedora base rocks ;-)

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

Re: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 12:09 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

>
>
> On Wed, Dec 6, 2023 at 11:26 AM Michael J Gruber 
> wrote:
>
>> Hi there,
>>
>> what is the impact of these changes:
>> - Do default installs work the same way as before?
>> - Do existing setups (crontabs) keep working?
>>
>> If yes then I'd consider the permission changes to be fixes, or at least
>> standard packaging changes.
>>
>> What is is the policy for existing cron.allow/cron.deny, i.e. what would
>> `rpmconf -a` tell me?
>>
>>
> The default installs work same as before.
> Existing crontabs keep working as usual.
>
> The only difference is that if you have populated the cron.deny list,
> after update it gets saved as .rpmsave and cron.allow is created.
> If the cron.deny is blank, it will get replaced.
> Also, if you had cron.allow populated before, it will stay this way and
> blank cron.allow.rpmnew is created.
>
>
Thanks, that sounds like the typical things to expect during an upgrade. We
typically don't even have release notes mentioning this, but it would be
nice, since it's even a "plus" for F40 (compliance, hardening).

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

Re: Change of cronie and crontabs CIS compliance

[Michael J Gruber]

Am Mi., 6. Dez. 2023 um 11:17 Uhr schrieb Ondrej Pohorelsky <
opoho...@redhat.com>:

> Hi everyone,
>
> For F40 I would like to change file permissions of few files that are
> provided by cronie and crontabs and swap deny list for allow list. I'm not
> really sure if I should make a change proposal. I figured I'll send an
> email first and see the feedback.
>
> The driving force of this change is feedback from RHEL customers, that
> they would like to have cronie and crontabs CIS compliant out of the box.
> Which means changing some of the file permissions and swapping `cron.deny`
> for `cron.allow`. As it stands now, they have to run their own scripts or
> dnf plugin (post-transaction-actions) to ensure that each update doesn't
> overwrite the file permissions they manually set.
>
> I would like these changes for F40, as this is going to be a branching
> point for next RHEL and I would like to go with upstream first approach.
>
> *cronie* changes:
> `cron.allow` replaces `cron.deny`  (file permission 600)
> `cron.d` permission change (755 → 700)
> `cron.hourly` permission change (755 → 700)
>
> *crontabs* changes:
> `crontab` permission change (644 → 600)
> `cron.{hourly,daily,weekly,monthly}` permission change (755 → 700)
>
> Reference for these changes:
> static.open-scap.org/ssg-guides/ssg-rhel9-guide-cis.html
>
> PR:
> https://src.fedoraproject.org/rpms/cronie/pull-request/12
> https://src.fedoraproject.org/rpms/crontabs/pull-request/6
>
> Let me know what you think.
> Cheers,
> --
>
Hi there,

what is the impact of these changes:
- Do default installs work the same way as before?
- Do existing setups (crontabs) keep working?

If yes then I'd consider the permission changes to be fixes, or at least
standard packaging changes.

What is is the policy for existing cron.allow/cron.deny, i.e. what would
`rpmconf -a` tell me?

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

Re: Proven to be sickened

[Michael J Gruber]

Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36:
> On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
> > 
> > [snip]
> > 
> > > Granted, these are dissimilar to initial Michaels's issue. But how can I 
> > > be
> > > sure that if I touch some of the packages, I won't be told that they were 
> > > in
> > > such state for purpose?
> > 
> > IMHO all changes should be opened as merge requests in pagure. This gives
> > the regular package maintainers a window of opportunity to review the
> > change before it is merged. If there's no response from the package
> > maintainer after a couple of weeks then a proven packager can go ahead
> > and approve the merge request.
> > 
> > Essentially proven packagers can follow the same workflow as anyone else
> > does for contributing to a package that they are not a (co)maintainer of.
> > They just need the extra priv of being able to approve their own MR at
> > their discretion. Pushing directly to git, bypassing merge requests,
> > should not be required in order to achieve what provenpackagers exist
> > to do.

Yes. My main point was communication, i.e. the "how", not the "what" of
those changes. The "what" may influence the "how", of course. An urgent
security fix does not leave time for upfront communication. But there
should always be time for communication afterwards.

> This workflow doesn't really work for mass rebuilds / mass maintenance
> of OCaml packages (I guess it's similar for other language packages).
> We want to be able to rebuild or fix all packages that contain OCaml
> code, and we have a bunch of scripts to do that including the push and
> build in a side tag.

That makes it even more important to communicate: you don't want a
packager to build into rawhide while your side tag is cooking.

Note that "communicate" can be as simple as a commit message "bump for
xy mass rebuild" or "fix FTBFS for xy rebuild", maybe together with a
link to the announcement. If there was an announcement ...
That is something you can do automatically. You only have to take the time
*once* to template a proper dist-git commit message.

> > At the same time I think it is good to remember that Fedora package
> > maintainers should think of themselves as guardians, not owners, and
> > thus should expect to receive contributions from others, including
> > provenpackagers, doing cleanups to follow Fedora guidelines better.
> 
> Yes indeed.

Yes, it goes both ways, and requires communication. That's all.

And, just to clarify: I probably wouldn't have reacted the way I did if
I hadn't experienced something like that over and over again. And that
included quelling test suites completely and other niceties (from
various pp's).

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

Re: Proven to be sickened

[Michael J Gruber]

Jason L Tibbitts III venit, vidit, dixit 2023-12-01 22:41:54:
> So I've been in this situation, both on the receiving end of nasty flames
> because I dared touch someone else's package and having duplicated work
> because I didn't check before trying to update something.
> 
> >>>>> Michael J Gruber  writes:
> 
> > So, due to me following my package (notmuch)
> 
> The idea is that it's really the community's package, but you have
> indicated that you will take a primary role.  That doesn't mean that
> nobody else will ever touch the package.  Communication is encouraged,
> of course.
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity
> 
> > ... and get a reject because someone thought that pushing directly
> > without asking or at least notifying the maintainer would be in order:
> 
> This is collaborative maintenance.  Occasionally you get ninja'd.  It
> happens.  Certainly it's annoying when it happens but it's not evidence
> that anyone did anything wrong.
> 
> If there is something wrong with the work of the maintainer who got
> there before you did, then you can always push a revert, bump and build
> your own copy.  And of course have a discussion with them.
> 
> If there isn't anything wrong with the work of the other maintainer,
> then I guess I don't understand.  They did something in an honest
> attempt to save you the trouble and because of unfortunate timing they
> didn't actually save you any trouble.  But you aren't in a different
> position than if they hadn't tried to help.  (Excluding the time it took
> to start this discussion, of course.)
> 
> > I am sick of this. Really. I am so sick of this way of stomping on
> > each others' feet.
> 
> I can only say that the best thing to do in this situation is to say
> "thanks; would you mind sending me a note on [IRC|Matrix|email] in the
> future so we don't duplicate effort?" and move on.  Surely it's not
> worth strong emotions.
> 
> > It's made worse by failing automated notifications, of course. Not
> > from pagure about the push nor from koji about the build nor from
> > bodhi about the update.
> 
> Now that is a true issue, and perhaps the real underlying issue here.
> If you invested time that you didn't need to invest because you didn't
> receive a notification that the work had already been done, then that is
> problematic.  And yes, it would be incredibly beneficial to
> collaboration if that were fixed, if only because it would help to
> prevent situations such as the one under discussion.  But please don't
> take that out on the person who had no motivation other than to help you
> out.

You are all missing the point that this is not about a (co-) maintainer
but a proven packager. And that "regular maintainership" is not what
this role is for. And it's definitely not what most of them do.

Even as (co-)maintainer I see this as team work, at least among
those who signal interest. If "main admin" doesn't signal that then
what does?

But hey, I can learn, such as not to care either. Just push and build
where you have access. So much easier.

Done with this for now.

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

Proven to be sickened

[Michael J Gruber]

So, due to me following my package (notmuch) upstream and testing early
against upstream's git, reporting and working with upstream, I noticed a
FTBFS and helped fixing it. Nothing urgent since it was basically just a
test failing for the wrong reasons.

Within a few days, upstream releases a patch release. Within hours, I'm
testing (again, since it's basically what was on git already) on copr and
koji, writing a nice commit message, push to rawhide ...

... and get a reject because someone thought that pushing directly without
asking or at least notifying the maintainer would be in order:

https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide

Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue
whatsoever?

I am sick of this. Really. I am so sick of this way of stomping on each
others' feet.

It's made worse by failing automated notifications, of course. Not from
pagure about the push nor from koji about the build nor from bodhi about
the update.

Dunno whether it's the new fmn or what. That works for *my* actions with
pagure/bodhi/koji but fails to report copr actions to me, and
apparently also actions by others.

Thanks for listening ...

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

Re: troff noise when grepping man page?

[Michael J Gruber]

Am Do., 30. Nov. 2023 um 01:14 Uhr schrieb Chris Murphy <
li...@colorremedies.com>:

> $ man 5 btrfs | grep enospc
>enospc_debug, noenospc_debug
> troff::870: warning: cannot select font 'C'
> troff::888: warning: cannot select font 'C'
> troff::905: warning: cannot select font 'C'
> troff::924: warning: cannot select font 'C'
> troff::962: warning: cannot select font 'C'
> troff::977: warning: cannot select font 'C'
> troff::999: warning: cannot select font 'C'
> troff::1013: warning: cannot select font 'C'
> troff::1168: warning: cannot select font 'C'
> troff::1184: warning: cannot select font 'C'
> troff::1259: warning: cannot select font 'C'
> troff::1275: warning: cannot select font 'C'
> troff::1293: warning: cannot select font 'C'
> troff::1354: warning: cannot select font 'C'
> ...snip...
>
> This seems new with Fedora 39. The root file system is newly installed not
> an upgrade, but the ~/ is positively ancient (possibly 5 years). Any ideas
> what's going on, how to get more information, and what component to file a
> bug against?
>
>
> That man page contains `.ft C` sequences to select a font, but that should
probably be `.ft CR` (for constant width Roman) or any other of the C
variants, but not just `C`. Either roff sequences changed ( I don't think
so) or doc generation. More likely, we get warnings on stderr now here we
used to ignore them in /dev/null ...

A quick scan shows indeed many man pages with problems or warnings.

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

Re: Blender 4.0.0 failure on aarch64 and ppc64le

[Michael J Gruber]

Luya Tshimbalanga venit, vidit, dixit 2023-11-24 01:45:37:
> Hello team,
>  Blender 4.0.1 failed to build on both aarch64 and ppc64le on the following 
> lines:
> ```
> /builddir/build/BUILD/blender/intern/cycles/blender/attribute_convert.h:69:44:
>  error: cannot convert ‘ccl::float4’ to ‘float’
>69 | return color_srgb_to_linear(make_float4(byte_to_float(value[0]),
>   | ~~~^
>   ||
>   |ccl::float4
>70 | byte_to_float(value[1]),
>   | 
>71 | byte_to_float(value[2]),
>   | 
>72 | byte_to_float(value[3])));
>   | 
> In file included from 
> /builddir/build/BUILD/blender/intern/cycles/blender/attribute_convert.h:9:
> /builddir/build/BUILD/blender/intern/cycles/util/color.h:62:45: note:   
> initializing argument 1 of ‘float ccl::color_srgb_to_linear(float)’
>62 | ccl_device float color_srgb_to_linear(float c)
>   |   ~~^
> ```
> while the previous version 3.6.5 worked as intendedd and x86_64 is 
> unaffected. Could someone running the above architecture addressing the issue 
> please? 
> See 
> https://copr.fedorainfracloud.org/coprs/g/designsuite/blender/build/6681752/

Hi Luya,

looks like this one:

https://projects.blender.org/blender/blender/pulls/115098

The backport seems to be this one:

https://projects.blender.org/blender/blender/commit/641b7808f24fa6eae593dd8f093878e4cafc4499

So it will be in 4.0.2.

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

Re: SPDX Statistics - Kristallnacht edition

[Michael J Gruber]

Am Do., 16. Nov. 2023 um 01:27 Uhr schrieb Kevin Kofler via devel <
devel@lists.fedoraproject.org>:

> Miroslav Suchý wrote:
> > Why Kristallnachte edition? On today's date at 1938, was i Kristallnacht
> > (Night of Broken Glass) - a pogrom against Jews in Germany. It was first
> > step where every other step was worse than the previous one. It was
> > basicaly a first step that lead to holocaust.
> >
> >
>
> https://en.wikipedia.org/wiki/Kristallnacht#Kristallnacht_as_a_turning_point
>
> Note that the term "Kristallnacht" (or "Reichskristallnacht") is itself a
> nazi propaganda term, and it is nowadays generally agreed in Austria and
> Germany that that term should not be used. Broken glass is just broken
> glass, not "crystal". And the term only (euphemistically) mentions the
> violence against things and neglects to mention the violence against
> people.
>
> ... and that is why Miro mentioned all of that explicitly (and
diligently), and even pointed to a source for more information.

Historical events do not vanish by renaming them - and no single word can
describe the horror, be it "massacre" or "catastrophe" in the language of
your choice. We need to educate ourselves (and then others) about events
and names, and in fact that is what Miro's historical connotations can do,
even when they give us shivers.

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

Re: Orphaned pipenv

[Michael J Gruber]

Am Mi., 15. Nov. 2023 um 15:31 Uhr schrieb Priscila Gutierres <
prgut...@redhat.com>:

> I would like to maintain it, but I'm now just a contributor
> Can someone please sponsor me to allow me to become a maintainer and  take
> this package?
>
> Priscila.
>
> On Wed, Nov 15, 2023 at 10:41 AM Tomáš Orsava  wrote:
>
>> Hi,
>> I just orphaned pipenv: https://src.fedoraproject.org/rpms/pipenv
>>
>> I haven't been using the package for some time, and upstream releases
>> versions too fast for me to keep up. Also I'm not sure how many people
>> use the package.
>>
>> There are two open BZs for the package, but they'll likely be resolved
>> by updating to the latest upstream version.
>>
>> Tomas
>>
>>
Looking at the myriad of py packages which Fedora's pipenv bundles, I'm
really wondering whether we should package this at all, at least in this
form. I'm not saying that unbundling is easy or even feasible. But this
really seems to call for `pip install pipenv` and stretches our packaging
guidelines.

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

Re: Heads up: jbig2dec 0.20 coming to rawhide

[Michael J Gruber]

Am Mo., 6. Nov. 2023 um 22:20 Uhr schrieb Michael J Gruber <
m...@fedoraproject.org>:

> jbig2dec 0.20 (a bugfix release) was released a while ago, and with the
> current ghostscript update, everything is ready for it, as can be seen in
> the copr rebuilds:
> https://copr.fedorainfracloud.org/coprs/mjg/jbig2dec/builds/
>
> I will build jbig2dec 0.20 into a rawhide side tag, along with updates to
> dependent packages:
>
> mupdf 1.23.5
> python-PyMuPDF 1.23.6
> zathura-pdf-mupdf 0.4.1
>
> All of these are interdependent and - besides adjustments to the
> respective versions - come with the latest bug fixes.
>
> Cheers
> Michael
>

Bodhi update submitted from rawhide side-tag. Let's see how happy gs is
with this jbig2dec update.

If all goes well, the contained fixes would justify updating on f39 also
(and maybe f39 - gs updated all the way down), unless maintainers
of zathura-pdf-mupdf and python-PyMuPDF object.

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

Heads up: jbig2dec 0.20 coming to rawhide

[Michael J Gruber]

jbig2dec 0.20 (a bugfix release) was released a while ago, and with the
current ghostscript update, everything is ready for it, as can be seen in
the copr rebuilds:
https://copr.fedorainfracloud.org/coprs/mjg/jbig2dec/builds/

I will build jbig2dec 0.20 into a rawhide side tag, along with updates to
dependent packages:

mupdf 1.23.5
python-PyMuPDF 1.23.6
zathura-pdf-mupdf 0.4.1

All of these are interdependent and - besides adjustments to the respective
versions - come with the latest bug fixes.

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

Re: Wrong branch built into side tags, what to do?

[Michael J Gruber]

Am Mo., 6. Nov. 2023 um 17:12 Uhr schrieb Fabio Valentini <
decatho...@gmail.com>:

> On Mon, Nov 6, 2023 at 5:09 PM Julian Sikorski  wrote:
> >
> > Hello,
> >
> > I have accidentally built f39/rawhide branch of gnumeric and
> > gnome-chemistry-utils for f38 and f37 side tags (f39 too but rawhide and
> > f39 are the same commit). Can this be fixed? Or is the effort not worth
> > it? Thanks.
>
> Are the contents of the package the same except for the changelog
> entries / Release field?
> Then I would not bother trying to fix it.
>
> It is kind of unfortunate that koji does not have guardrails in place
> to prevent building branch X against target Y!=X, but that's probably
> something that actually needs to work for Modularity or other
> configurations ...
>
> Fabio
>
> The spec files differ in content (as far as flatpaks are concerned). But
since this package uses separate branches without forwards/merges but
cherry-picks only, i.e. clearly separates branches in git, it would be
surprising not to care about the branch now ... I guess git branches are
still somewhat foreign to how we drive our dist.

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

Re: DNF5: Checking signatures of packages installed out of a repository?

[Michael J Gruber]

Am Di., 31. Okt. 2023 um 19:31 Uhr schrieb Christopher <
ctubb...@fedoraproject.org>:

> On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch  wrote:
> >
> >
> > Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
> > > Hello,
> > >
> > > DNF5 got a complaint
> > >  that
> "dnf update
> > > https://...; skips verifying package signatures:
> > >
> > >  $ sudo dnf update
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > >  [...]
> > >  Warning: skipped PGP checks for 2 package(s).
> > >
> > > A DNF5 developer confirmed that old DNF4 does not verify signatures
> too.
> > > The verification happens only for packages comming from a repository.
> Why DNF5
> > > looks bad is because it actually prints the warning and thus keeps the
> user
> > > better informed.
> > >
> > > The nonchecking behavior probably exists to make installing local
> packages
> > > easy. If DNF5 would insist on checking the signatures, Fedora users
> would have
> > > to pass --no-gpgchecks option to their "dnf5" commands to override the
> new
> > > default, or start signing their packages. As always security is not
> easy.
> > >
> > > Because this an old behavior and some users probably depend on it,
> enabling
> > > the verification for all cases looks like an abrupt change.
> > >
> > > I would would like to hear your opinion: Should DNF5 start verifying
> all
> > > packages? Should DNF5 keep ignoring signatures for out-of-repository
> packages?
> > > Or should rather narrow the verification skip to packages from a local
> file
> > > system? Any other options?
> >
> >
> > Or maybe verify what it can and report the packages which can't be
> > verified? You can notice that I was actually installing singed packages.
> >
> > But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I
> > still would swear this used to be needed, that is why I try to install
> > the signed packages.
>
> I could have sworn the same thing. I think that it should be an error
> if any package (it doesn't matter if it is local or not) cannot be
> verified, unless `--nogpgcheck` is specified. This seems like the only
> secure-by-default option. No RPM should be allowed to be installed if
> it can't be verified, unless the user explicitly allows it. If less
> secure options are provided (such as only providing a warning message
> or skipping verification of local RPMs), then an option must be
> provided to force the secure-behavior to prevent the installation of
> any RPMs that haven't been verified (something like
> `--requiregpgcheck`). But my strong preference is that it require GPG
> checks by default. That is the behavior that is implied by the
> existence of the `--nogpgcheck` flag and the non-existence of any
> other related flags.
>

Note that there are few differences between local and repo files here:
- A repo comes with a key specification, i.e. an expected signer; a local
package does not. What signature do you expect? What is the value of "any"
signature?
- A package installed via a repo comes "from the internet" without your
control over the exact download location; a local package has been
downloaded or built specifically by you, with you in control.
Therefore, it does make sense that one has its signature checked and the
other hasn't.

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

Re: [Test-Announce] Fedora Linux 39 Final is NO-GO

[Michael J Gruber]

Stephen Gallagher venit, vidit, dixit 2023-10-11 15:03:30:
> On Wed, Oct 11, 2023 at 6:14 AM Kamil Paral  wrote:
> >
> > On Wed, Oct 11, 2023 at 11:06 AM Michael J Gruber  
> > wrote:
> >>
> >> I noticed that we switched off updates-testing by default for F39
> >> installs very recently. Is that something that is tied to the release
> >> date or the final freeze date?
> >
> >
> > There's no exact time defined, but usually this happens shortly before we 
> > start producing Final RC images. Pre-release testers are expected to be 
> > able to configure it. But it's true that giving it more visibility 
> > (announce when we disable updates-testing) would be beneficial for testing 
> > purposes (interested people could toggle it back to enabled right away).
> 
> If the users have not modified the
> /etc/yum.repos.d/fedora-updates-testing.repo manually, then the file
> is automatically disabled for them when the GA fedora-repos package
> gets to their system. It doesn't downgrade any packages they have
> installed from u-t, though. So early adopters *may* want to `dnf
> distro-sync` at this point, but in most cases that isn't necessary. It
> probably wouldn't hurt to add "At some point during this Freeze, an
> update to `fedora-release` and `fedora-repos` will be pushed out,
> disabling updates-testing by default and identifying the system as a
> GA release" to the Final Freeze announcement.

Maybe we shouldn't even confuse release users with this.

I was just wondering what the "anchor" is, say "right after final
freeze" or "7 days before GA". We could put "updates-testing disabled
in fedora-release GA version" as a remark in there, just like "xy plan
on this" and such.

When the release slips like now the anchor time matters. One could
argue either way. I guess anchoring shortly before GA is safer in the
sense that beta testers receive updates longer while they are not being
pushed to stable during freeze.

You know how it goes: We ask them to test beta, beta is all good and
great, so they stay on branched ... In my case, because our uni terms do
not line up well with our release schedule, and I can't possibly defer
upgrades to the Xmas break  ;-)

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

Re: [Test-Announce] Fedora Linux 39 Final is NO-GO

[Michael J Gruber]

Adam Williamson venit, vidit, dixit 2023-10-10 23:03:57:
> Due to outstanding blocker bugs[1], we do not have a release candidate
> for Fedora Linux 39 Final. Thursday's Go/No-Go meeting is cancelled.
> 
> The next Fedora Linux 39 Final Go/No-Go meeting will be held at
> 1700 UTC on Thursday 19 October in #fedora-meeting-1. We will aim for
> the "target date #1" milestone of 24 October. The release schedule[2]
> will be updated accordingly soon.

I noticed that we switched off updates-testing by default for F39
installs very recently. Is that something that is tied to the release
date or the final freeze date?

Early adapters should now how and whether to change this locally, of
course. I couldn't tell the timing from the release schedule.

And, of course, it makes sense to give "late early adopters" what will
be in the release, at the expense of a time frame without any updates.

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

Re: Unretirement: Impallari-Lobster-Fonts

[Michael J Gruber]

Am Do., 5. Okt. 2023 um 07:43 Uhr schrieb Benson Muite
:
>
> Hi,
>
> Would like to unretire Impallari-Lobster-Fonts:
> https://bugzilla.redhat.com/show_bug.cgi?id=2242129

Maybe, somewhere in the bug or here, give a link to upstream (pagure
does not have it either) and spell out whether the reasons leading to
retirement are void now?
Thanks :)

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

Re: Orphaning all my packages

[Michael J Gruber]

Am Di., 3. Okt. 2023 um 16:25 Uhr schrieb Todd Zullinger :
>
> Hi,
>
> I'm orphaning all my packages (which I effectively did
> months ago).  It's been fun being a maintainer since 2006.
>
> However, I am not interested in contributing to a project
> where the primary sponsor and downstream no longer provides
> source code freely and openly.  It's simply not consistent
> with why I use and contribute to Fedora and Free/Open Source
> Software in general.
>
> I'm a maintainer of the following packages:
>
> cgit
> git
> paperkey
>
> I'm an admin of the following packages:
>
> fail2ban
> rubygem-asciidoctor
>
> I have commit privileges on these additional packages:
>
> asciidoc
> git-filter-repo
> rpmlint
>
> Thanks,

Thank you for all the effort you have put into maintaining these
packages so far, for the benefit of all of Fedora, and consequently
its downstream!

Your reasons resonate with me, though I'm not taking the same
conclusions. Have you arranged "succession" with your git
co-maintainers?

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

Re: Automate your Fedora package maintenance using Packit

[Michael J Gruber]

Am Di., 19. Sept. 2023 um 11:24 Uhr schrieb Frantisek Lachman
:
>
> Thank you everyone for your responses!
>
> I have a few updates for you that made it to production this morning
> as part of our weekly release cycle:
>
> * Thanks to Ankur Sinha, the pull requests created by Packit now have
> a clear list of tasks/reminders to check in the description. (E.g.
> https://src.fedoraproject.org/rpms/python-ogr/pull-request/479)

Thanks!

Maybe add: "check the autogenerated changelog" ;-)

(I know 479 was not merged, but the diff looks funny.)
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Michael J Gruber]

Am Mo., 18. Sept. 2023 um 12:39 Uhr schrieb Petr Pisar :
>
> V Mon, Sep 18, 2023 at 10:12:17AM +0100, Daniel P. Berrangé napsal(a):
> > On Mon, Sep 18, 2023 at 09:57:28AM +0200, Petr Pisar wrote:
> > > V Fri, Sep 15, 2023 at 01:27:23PM -0400, Colin Walters napsal(a):
> > > > To state the blindingly obvious thing, RHEL made a decision to 
> > > > centralize on
> > > > Gitlab.  Having Fedora be on pagure creates IMO unnecessary friction 
> > > > for me.
> > > > I would be quite curious to get some sort of survey of other engineers 
> > > > for
> > > > how they feel.
> > >
> > > My selfishly preferable option is not to use Gitlab.com for Fedora exactly
> > > because RHEL uses Gitlab.com. The reason is very practical: You need 
> > > separate
> > > accounts for the two projects and GitLab.com is not good at using multiple
> > > accounts simulatenously. Having different systems makes to problem go 
> > > away and
> > > my life easier.
> >
> > You don't require separate accounts. It is a choice developers can
> > make to keep their upstream vs RHEL work in gitlab.com separated,
> > or under the same account. There are pros & cons, so it is really
> > a matter of personal preference.
> >
> It's is a matter of security. With a single account you give Fedora admins
> an access to RHEL and vice versa.

That is an interesting point, and one that was never clear to me from
the wording "organisation xy wants to manage your account": Which kind
of access do you grant Fedora (resp. RHEL) if you "join" that GitLab
organisation with an existing GitLab account?

If it's a Fedora hosted instance things are much clearer.

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

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Michael J Gruber]

Am Mi., 13. Sept. 2023 um 23:29 Uhr schrieb Neal Gompa :
>
> On Wed, Sep 13, 2023 at 5:24 PM Fabio Valentini  wrote:
> >
> > On Wed, Sep 13, 2023 at 11:19 PM Steven A. Falco  
> > wrote:
> > >
> > > A question about this - the removal of X11 is listed on a change proposal 
> > > for KDE.  Does the removal just apply to KDE or would it be distribution 
> > > wide; i.e. affecting all desktops?
> >
> > I assume the following is not meant literally:
> >
> > """
> > For Fedora Linux, the
> > transition to KDE Plasma 6 will also include dropping support for the
> > X11 session entirely, leaving only Plasma Wayland as the sole offered
> > desktop mode.
> > """
> >
> > I doubt that the intention is to drop X11 sessions entirely and make
> > "Plasma Wayland" the only session available on Fedora *in general*,
> > but rather that the "Plasma X11" session will be dropped, and that
> > "Plasma Wayland" will be the only *Plasma* session available.
> >
>
> Yes! Sorry if it's ambiguous, it's hard to write this to account for
> all the ways it can be interpreted. This is scoped to the KDE Plasma
> solution stack.

The proposal is clearly about KDE plasma and *its* sessions. Or else
"leaving only Plasma Wayland as the sole offered desktop mode" would
have to mean the end of all other desktops on Fedora ;-)

> Other desktops can and will make their own choices on the transition to 
> Wayland.

Rightly so. Fewer and fewer will pull in X11, and that's a good change.

Now, if you (as in "they" - not  you Neal, obviously) see "change" and
something Wayland has not worked in the past and you go ballistic
about it then for you (as in "they") that formulation might be
ambiguous. But if you take a breath or a step back or both then the
proposal is crystal clear. At the same time, there is no way around it
given upstream's directions.

Talking of upstream: I see some upstreams giving up on Wayland
support. Kicad was reported here, Scribus is another one. It's a
surprising time to do that, but probably indicates toolkit issues or
simply lack of people power. I hope we can help at least on the
toolkit side. That would be time well spent - invested in the future
of the platform. Nobody will stop anyone from shipping a plasma-x11
package (and it's ridiculous to try and read that into the proposal)
or even a full stack plasma 5, but that will just drag out the
transition that is happening nonetheless.

Full disclosure: Writing this from F38/X11/i3 ;-)
F39 should be a good release to try the switch (Wayland/sway for me),
and in fact for some releases we have had dual session options now at
least for Gnome and KDE (X11/Wayland) so that one could try and switch
apps gradually. Reliance on WebRTC (and the switches i3/sway, st/foot
etc) made me chicken out so far, but now is the time!

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

Re: Is this number ok?

[Michael J Gruber]

Am Di., 12. Sept. 2023 um 20:28 Uhr schrieb Adam Williamson
:
>
> On Tue, 2023-09-12 at 17:20 +, Alessio wrote:
> > I know about this accepted change:
> > https://fedoraproject.org/wiki/Changes/Color_Bash_Prompt
> >
> > But what is this number that appears time to time in the prompt?
> >
> > user@host:~$ ^C
> > user@host:~130$ ^C
> >
> > user@host:~$ foo
> > bash: foo: command not found
> > user@host:~127$
> >
> > An exit code I suppose?
>
> yeah, it seems to be the exit code of the last command if it's not 0.
>
> It does seem that this change is beyond the scope disclosed in the
> Change, so that could possibly be brought up for discussion. Pulling in
> devel@ and the Change owner for comment. Jens, why was this feature not
> disclosed in the Change scope?

It was disclosed in the "Detailed Description" (screenshots) and "How
To test" (source git repo), but not in the scope. Somewhat borderline.

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

Re: FAS 2FA recovery keys?

[Michael J Gruber]

Am Di., 12. Sept. 2023 um 11:22 Uhr schrieb Barry Scott
:
>
> I have been updating my FAS account security.
> When I setup 2FA I was not offer any recovery keys.

You can register multiple OTP tokens:
https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/2-factor/

> In the event that I lose FreeOTP on my phone how do I recover?

If you lost all of your tokens you can request a reset:
https://fedoraproject.org/wiki/Infrastructure_Two_Factor_Auth#What_happens_if_I_lost_my_token_or_got_a_new_device?

That being said, I'm in the same boat: Getting recovery keys *at the
same time* as activating 2fa has something soothing to it ...
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Michael J Gruber]

Am Sa., 9. Sept. 2023 um 03:05 Uhr schrieb Brendan Conoboy :
>
> Hi folks,
>
> In March of this year, Josh Boyer sent out a message to Fedora's devel list 
> letting everybody know RHEL was going to move from bugzilla.redhat.com to 
> issues.redhat.com (Jira) in the future [1].  The work on this activity has 
> proceeded with relative quiet since, although a couple weeks ago Florian 
> mentioned on centos-devel that Platform Tools had begun to move [2].  I'm now 
> providing a more official followup:
>
> All new issues found or desired in RHEL (Or CentOS Stream) need to be filed 
> on issues.redhat.com.  It's no longer possible to create new BZs for current 
> RHEL (7 through 9) releases.  Over the next few weeks, most RHEL BZs will be 
> migrated to tickets in the RHEL project on issues.redhat.com.  The BZs that 
> are migrated will be closed with resolution MIGRATED and a pointer to the 
> Jira issue included in the external links section of each respective BZ.  
> Issues that don't get migrated may still be worked on in Bugzilla- only new 
> BZ creation is disabled, and only disabled in RHEL products.  Like before, 
> most new RHEL issues are publicly visible by default, without any login 
> required to view.
>
> RHEL making this change does not imply or require that Fedora do the same.  
> Rather, I'm mentioning this here because many community members who 
> contribute to Fedora via Bugzilla also do the same for RHEL and we appreciate 
> those contributions.  People are welcome to create an account on 
> issues.redhat.com, just like was done on bugzilla.redhat.com previously, see 
> what we're up to, file issues, and contribute there as well.  We've created a 
> hopefully-helpful article with account basics to get your account setup [3].
>
> I've sent a similar message to centos-devel, so apologies if you're reading 
> this a second time.
>
> References:
> 1. Initial Announcement - 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/U7TZRWXVUGBCHS6EBJIBSFAVPFUHHV7J/
> 2. Migration Starting - 
> https://lists.centos.org/pipermail/centos-devel/2023-August/143056.html
> 3. Issues.redhat.com account basics - 
> https://access.redhat.com/articles/7032570

I might have overlooked this, but my impression is:
- migration created jira accounts automatically
- they are not necessarily connected to your RH account (or whatever
it is called what you use for RHEL devel licenses)
- Reconneting things does not seem to be covered in that article

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

Re: SPDX MIT license , what todo ?

[Michael J Gruber]

Am Fr., 8. Sept. 2023 um 15:45 Uhr schrieb Sérgio Basto :
>
> On Fri, 2023-09-08 at 08:39 +0200, Sandro wrote:
> > On 08-09-2023 02:36, Sérgio Basto wrote:
> > > xdg-utils is a MIT License [1] what SPDX license have [2] ? if it
> > > is
> > > already a valid SPDX formula , what I should write on changelog ?
> >
> > Something like:
> >
> > - Migrated to SPDX license (noop)
> >
>
> done [1] thanks , btw another question I don't need do a new build
> isn't it ?

No, since there was no license change - in your case not even the
specifier changed :)

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

Re: question about dnf5 upgrade output

[Michael J Gruber]

Am Do., 7. Sept. 2023 um 14:02 Uhr schrieb Zbigniew Jędrzejewski-Szmek
:
>
> I'm testing the upgrade to F39, and I see the following:
>
> Installing group/module packages:
>  tlwg-waree-fontsnoarch 0.7.3-9.fc39  fedora 
> 250.3 KiB
>replacing thai-scalable-fonts-common  noarch 0.7.3-5.fc38 
> 18.6 KiB
>replacing thai-scalable-waree-fonts   noarch 0.7.3-5.fc38
> 229.4 KiB
>
> tlwg-waree-fonts-0.7.3-9.fc39.noarch.rpm doesn't seem special in any way.
> Are they in a separate section of the output because they are pulled in via
> a comps group?

dnf5 orders the sections differently, and summarizes one more:

dnf4:

Installing:
Upgrading:
Installing group/module packages:
Installing dependencies:
Installing weak dependencies:
Removing:
Downgrading:

Transaction Summary
Install  67 Packages
Upgrade3873 Packages
Remove6 Packages
Downgrade 8 Packages


dnf5:

Removing:
Downgrading:
Upgrading:
Installing group/module packages:
Installing:
Installing dependencies:
Installing weak dependencies:

Transaction Summary:
 Installing:   67 packages
 Upgrading:  3873 packages
 Replacing:  3896 packages
 Removing:  6 packages
 Downgrading:   8 packages

My dnf4 lists your fonts basically in the same way as your and my
dnf5, by the way.

Also, dnf5 consumes double the screen space for updates - can we
switch back to 1-line-update info for ordinary updates, at least as an
option?

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

[EPEL-devel] Re: Take the EPEL user and contributor survey 2023!

[Michael J Gruber]

Am Fr., 1. Sept. 2023 um 22:09 Uhr schrieb Stephen Smoogen
:
>
>
>
> On Fri, 1 Sept 2023 at 16:03, Diego Herrera  wrote:
>>
>> Hello, everyone
>>
>> The Fedora EPEL SIG is asking for feedback to improve EPEL via this survey!
>>
>> * https://fedoraproject.limequery.com/2023
>>
>
> The link is incorrect and should be 
> https://fedoraproject.limequery.com/epelsurvey2023
>
None of them is available, it seems.

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

Re: Warning: DNF is unprotected

[Michael J Gruber]

Am Fr., 25. Aug. 2023 um 08:21 Uhr schrieb Adam Williamson
:
>
> On Thu, 2023-08-24 at 21:23 +0200, Tomasz Torcz wrote:
> > On Thu, Aug 24, 2023 at 07:39:07PM +0200, Robert-André Mauchin wrote:
> > > Hello,
> > >
> > > Just a heads-up: for the upgrade to DNF5 in F39, we unprotected the DNF
> > > package, which leaves all of our users vulnerable to a removal of DNF.
> > >
> > >
> > > We have one affected user here: 
> > > https://bsd.network/@claudiom/110944941506724767
> >
> >   Not just on, #fedora-qa:
> > 101441  I've just notice my rawhide system is without `dnf` 
> > command, and this ling dnf-automatic timers do not work. There is `dnf5` 
> > command available, though
>
> That's likely not the result of lack of protection, but just of running
> Rawhide. If you ran Rawhide through the period when dnf5 was made the
> provider of /usr/bin/dnf , then you didn't automatically get dnf
> installed back when you updated to the post-revert versions. This is by
> design, or rather, it's unfortunate but it would be rather icky to try
> and 'fix' it, so folks decided not to. You're expected to be able to do
> 'dnf5 install dnf' if you run Rawhide and want it back.

Not really. On my Fedora 38 with updates,
`/etc/dnf/protected.d/dnf.conf` looks like this:
```
# DNF is obsoleted in Fedora 39 by DNF 5 and should no longer be
marked as protected.

# dnf
```
It's the result of an update on 05/23 (or just before) which
unprotected dnf, protected python3-dnf and with the following diff in
dnf related packages:
```
 -dnf-data,noarch,dnf-data-4.15.0-1.fc38
-dnf,noarch,dnf-4.15.0-1.fc38
-dnf-plugins-core,noarch,dnf-plugins-core-4.4.0-1.fc38
-dnf-utils,noarch,dnf-utils-4.4.0-1.fc38
+dnf-data,noarch,dnf-data-4.15.1-1.fc38
+dnf,noarch,dnf-4.15.1-1.fc38
+dnf-plugins-core,noarch,dnf-plugins-core-4.4.1-1.fc38
+dnf-utils,noarch,dnf-utils-4.4.1-1.fc38

-libdnf,x86_64,libdnf-0.70.0-1.fc38
+libdnf,x86_64,libdnf-0.70.1-1.fc38
-python3-dnf,noarch,python3-dnf-4.15.0-1.fc38
-python3-dnf-plugins-core,noarch,python3-dnf-plugins-core-4.4.0-1.fc38
+python3-dnf,noarch,python3-dnf-4.15.1-1.fc38
+python3-dnf-plugins-core,noarch,python3-dnf-plugins-core-4.4.1-1.fc38

-python3-libdnf,x86_64,python3-libdnf-0.70.0-1.fc38
+python3-libdnf,x86_64,python3-libdnf-0.70.1-1.fc38

-yum,noarch,yum-4.15.0-1.fc38
+yum,noarch,yum-4.15.1-1.fc38
```
[Yes, I store this info redantly on purpose for easy diffing/splitting.]

Currently my dnf is at dnf-4.16.2-1.fc38.noarch, config is unchanged,
and it would happily remove itself. (I also installed dnf5 recently,
it didn't change that config and is not aliased.)

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

Re: Donate 1 minute of your time to test upgrades from F38 to F39

[Michael J Gruber]

Miroslav Suchý venit, vidit, dixit 2023-08-23 20:22:42:
> Do you want to make Fedora 39 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=39 --setopt=module_platform_id=platform:f39 \
> --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 reveal 
> 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 39. Please check existing reports 
> against fedora-obsolete-packages first:
> 
> https://red.ht/2kuBDPu
> 
> and also there is already bunch of "Fails to install" (F39FailsToInstall) 
> reports:
> 
> https://bugzilla.redhat.com/buglist.cgi?bug_id=2168845_id_type=anddependson=tvp_id=12486533
> 
> 
> Two notes:
> 
> * you may want to run the same command with dnf5 to help test new dnf.
> 
> * this command found zero issues on my personal system - great work all 
> everybody!

Yep, fantastic work! No problems here, except: I want to upgrade to F39
now :)

dnf4 and dnf5 report the exact same number of packages - and dnf5 does
so blazingly fast. I want it now!

The order of information is different. In particular, dnf5 reports:
- Removing
- Downgrading
- Upgrading
- Installing dependencies
- Installing weak dependencies

At first I thought it missed remove/downgrade, because they came before
the gazillion of upgrades. I understand why that order makes sense
logically, but the consequence is that you don't see the first two at
all for a distro-sync, unless you pipe to less or have infinite scroll
back.

The dnf4 order makes sense, too, (expected upgrades, then exceptions)
and does not lead to the scroll back buffer problem for large upgrades.

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

Re: Mock v5.0 released (and mock-core-configs v39)

[Michael J Gruber]

Kevin Fenzi venit, vidit, dixit 2023-08-10 21:21:59:
> On Thu, Aug 10, 2023 at 09:58:30AM -0700, Adam Williamson wrote:
> > On Thu, 2023-08-10 at 08:56 -0700, Adam Williamson wrote:
> > > On Thu, 2023-08-10 at 10:58 +0200, Pavel Raiskup wrote:
> > > > Hello maintainers!
> > > > 
> > > > Let me announce a new release of Mock v5.0 (the chroot build environment
> > > > manager for building RPMs).
> > > > 
> > > > This release release brings lots of changes, though the one that I'd
> > > > like to underline is that we turned --use-bootstrap-image ON by default.
> > > > This effectively means that Mock uses Podman to pull the bootstrap image
> > > > from image registries (instead of installing it from scratch with `dnf
> > > > --installroot`).  Thus Podman is now in `Recommends:`, not just
> > > > `Suggests:`. Should you have any issues, you can temporarily revert this
> > > > change with `--no-bootstrap-image` (--scrub=all first!).  Alternatively
> > > > set `config_opts["use_bootstrap_image"] = False` in configuration.
> > > 
> > > Unfortunately this seems to be broken on Rawhide, whether you use the
> > > 'fedora-40' or 'fedora-rawhide' name:
> > 
> > Update: nirik has fixed this for now. We think the Rawhide nightly
> > script is messing up the registry when it runs, he'll try and fix that
> > later.
> 
> And I think thats now fixed (was some leftover armhfp stuff. ;) 
> 

Is this supposed to work now?

With mock-5.0-1.fc38.noarch and after scrubbing, the image is pulled but
then not used because it is "not marked ready" (rawhide, f39, f38). Am I
holding it wrong?

```
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: Using bootstrap image: registry.fedoraproject.org/fedora:38
INFO: Pulling image: registry.fedoraproject.org/fedora:38
INFO: Copy content of container registry.fedoraproject.org/fedora:38 to 
/var/lib/mock/fedora-38-x86_64-bootstrap/root
INFO: mounting registry.fedoraproject.org/fedora:38 with podman image mount
INFO: image registry.fedoraproject.org/fedora:38 as 
/var/lib/containers/storage/overlay/5eb2e729c16708697e84f3cf2648d1ff3f2ce56f2f1eceb0289b226bc96b061a/merged
INFO: umounting image registry.fedoraproject.org/fedora:38 
(/var/lib/containers/storage/overlay/5eb2e729c16708697e84f3cf2648d1ff3f2ce56f2f1eceb0289b226bc96b061a/merged)
 with
podman image umount
INFO: Package manager dnf detected and used (fallback)
INFO: Bootstrap image not marked ready
Start(bootstrap): installing dnf tooling
```

and then dnf builds the chroot.

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

Re: compilation of vdr-epgfixer on rawhide fails

[Michael J Gruber]

Am Mi., 26. Juli 2023 um 10:36 Uhr schrieb Martin Gansser
:
>
> Hi,
>
> the compilation of the package vdr-epgfixer fails on rawhide with the message 
> [1]
> ...
> install -D libvdr-epgfixer.so 
> /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/lib64/vdr/libvdr-epgfixer.so.2.6.3
> install -D -m644 po/fi_FI.mo 
> /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/share/locale/fi_FI/LC_MESSAGES/vdr-epgfixer.mo
> install -D -m644 po/pl_PL.mo 
> /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/share/locale/pl_PL/LC_MESSAGES/vdr-epgfixer.mo
> cp: not replacing 
> '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/blacklist.conf'
> cp: not replacing 
> '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/charset.conf'
> cp: not replacing 
> '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/epgclone.conf'
> cp: not replacing 
> '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/regexp.conf'
> make: *** [Makefile:132: install-conf] Error 1
>
> How can i fix this ?
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/2669/103932669/build.log

You are installing the same files twice: once manually (install), once
via make (%make_install).

Was there a spec or package change, or is it the underlying tooling
which changed? Does this happen on rawhide only or on all releases?

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

Re: speed-dreams-2.3.0: how to handle bundled jar files in spec file ?

[Michael J Gruber]

Am Di., 25. Juli 2023 um 10:19 Uhr schrieb Martin Gansser
:
>
> Hi,
>
> i want to package the current version of speed-dreams 2.3.0, but i noticed 
> that jar files for the trackeditor are included in the package, but they 
> already exist in the system.

Not really, there are two different things going on:

> compilation error:
> Checking for unpackaged file(s): /usr/lib/rpm/check-files 
> /home/martin/rpmbuild/BUILDROOT/speed-dreams-2.3.0-1.fc38.x86_64
> error: Installed (but unpackaged) file(s) found:
>/usr/bin/bsh-2.0b4.jar
>/usr/bin/jdom-1.1.3.jar
>/usr/bin/jgoodies-common-1.8.1.jar
>/usr/bin/jgoodies-looks-2.5.3.jar

This just says that your spec file installs those files as part of the
build process (to the BUILDROOT, where check-files found them) but
that your spec file does not declare them (in the %files section).

> In the file src/tools/trackeditor/CMakeLists.txt from line 181 to line 230 
> the jar files are copied as you can see.
> https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/src/tools/trackeditor/CMakeLists.txt#l181

And that is why they get installed into the BUILDROOT.

I don't think /usr/bin is a good place for jars.

> do i have to use the jar files from the fedora packages now ?
>
> bsh-2.1.0-8.fc38.noarch
> jdom-1.1.3-32.fc38.noarch
> jgoodies-common-1.8.1-17.fc38.noarch
> jgoodies-looks-2.7.0-7.fc38.noarch

You should not "bundle" them with speed-dreams if they are available
as separate packages. In that sense: Yes.

BTW: The jdom package puts its jar into /usr/share/java/ as it should.

> that is, remove the jar files from the speed-dreams package and link to the 
> Fedora jar files in the spec file.

speed-dreams should "require" those packages. And you will need to
adjust speed-dreams so that it uses them - by setting CLASSPATH if
necessary or whatever makes speed-dreams find those jars.

If your package comes with tests you might also need to buildrequire the others.

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

Re: dist-git: Diverging branches can't be fast-forwarded

[Michael J Gruber]

Kevin Kofler via devel venit, vidit, dixit 2023-07-21 15:52:23:
> Miroslav Suchý wrote:
> > When I make SPDX statistics I have git checkout of all dist-gits and do
> > git-pull every two week there. This morning I found that two times I got
> > an error:
> > 
> > hint: Diverging branches can't be fast-forwarded, you need to either:
> > hint:
> > hint: git merge --no-ff
> > hint:
> > hint: or:
> > hint:
> > hint: git rebase
> > hint:
> > hint: Disable this message with "git config advice.diverging false"
> > fatal: Not possible to fast-forward, aborting.
> > Could not execute pull: Failed to execute command.
> > 
> > I was under the impression that our dist-git can have only forward
> > commits.
> 
> You should always (from all upstreams, no matter whether they allow force 
> pushes or not) pull with rebase (git pull --rebase). This rebases your 
> local, not yet pushed, changes on top of the upstream changes. Since it does 
> not change the upstream history, only your local unpushed one, it should 
> never require a force-push and hence always be safe. And it works even if 
> the upstream has been force-pushed (which should never happen in Fedora, but 
> can be an issue in other projects).
> 
> A pull with fast-forward only will fail if you have local changes, as you 
> can see above. A pull with merge will create a merge commit. The pull with 
> rebase is the cleanest option.

... and that is why "you should always (from all upstreams ..." is a very
wrong advice to give in this generality.

In fact:

- rewriting your local history automatically (due to the rebase)
  may not at all be what you want (because you may care about it)

- rebasing your changes on top of the latest upstream may not be what
  upstream wants from you (because they may want to base fixes on the
  earliest commit to which they apply, or the commit which introduced a
  regression)

Rebasing your history is not the cleanest option in these case, but the
wrong option.

The best general advice is to fetch, not pull. Then check $ref@{1}..$ref
for the remote $ref you fetched. (merge --no-ff may do as well)

Just look at it this way: Miroslav would not even have noticed something
strange going on had he done a "pull -rebase".

Use the automatic stuff only in those cases where you are sure about the
source or do not care about the target.

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

Re: [Test-Announce] Kernel 6.4.3 is now available for testing in koji

[Michael J Gruber]

Sumantro Mukherjee venit, vidit, dixit 2023-07-12 18:02:31:
> Hey Folks,
> 
> We are currently running the Fedora Kernel Test Week before we rebase
> 6.4. There is a new
> build 6.4.3 is fresh and you can now provide feedback!
> Thanks a lot to all for making the test weeks so successful. The links
> for test weeks can be found here[0]. Results can be submitted here[1]
> and the new build is [2]
> 
> Happy Testing!
> 
> [0] http://fedoraproject.org/wiki/Test_Day:2023-07-09_Kernel_6.4_Test_Week
> [1] https://testdays.fedoraproject.org/events/160
> [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2230199

Note that the Wiki points to a test iso with 6.4.2. Since that is used
as a live iso, you cannot update its kernel.

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

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Michael J Gruber]

Kevin Kofler via devel venit, vidit, dixit 2023-07-11 12:49:10:
> Oracle has (finally – the community projects Rocky and Alma were much 
> quicker to react) made an announcement about the situation:
> https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/

Thanks for the pointer.

They really make sure that they come out as "the last standing good
ones" from this. Cleverly written. And they do have valid points.

It's kind of sad when you know where RedHat and Oracle are coming from,
and how predictable that PR twist ist.

Now, if Orcale really makes sure to pick from CentOS Stream as closely
(to RHEL) as possible we can take gusses how long it will take Alma and
Rocky to change upstreams, or become obsolete.

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

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

[Michael J Gruber]

Perfect!

https://src.fedoraproject.org/rpms/rst2pdf/pull-request/2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 Python 3.12 rebuilds to start in a side tag this week

[Michael J Gruber]

Some packages may build with py 3.12 but not work with it if they don't have 
tests. For example, python-PyMuPDF fails when it tries to builds its 
documentation, but the error is in rst2pdf. If I disable doc creation then 
python-PyMuPDF builds against py 3.12 (and the tests succeed).

I may have a patch for rst2pdf - how do I chain-scratch build against 
f39-python? I probably don't, so how do I mock build with f39-build chroot?

python-PyMuPDF FTBFS because of rst2pdf: 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2224200

python-PyMuPDF builds without doc: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=102814124

Possible rst2pdf upstream fix: 
https://github.com/rst2pdf/rst2pdf/pull/1171#pullrequestreview-1508457716
(rst2pdf package lags behind upstream releases; upstream patch applies to 0.99 
but not 0.97 where configparser is spelled ConfigParser)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 Python 3.12 rebuilds to start in a side tag this week

[Michael J Gruber]

I took care of lensfun, which was not quite as much fun as it sounds:

https://src.fedoraproject.org/rpms/lensfun/pull-request/4

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

Re: F39 Change Proposal: LibuserDeprecation (System Wide)

[Michael J Gruber]

> https://fedoraproject.org/wiki/Changes/LibuserDeprecation
...
> == Scope ==
> * Proposal owners: Dropping the package, move it to EPEL eventually

If it's not in Fedora it can't be in EPEL (once dropped), can it?

There may also be a language issue here: Does the CP owner mean 
"possibly/maybe"? "Eventually" is a false friend in a few languages.

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

Re: What is Fedora?

[Michael J Gruber]

> On 6/22/23 06:21, Gordon Messmer wrote:
> 
> That's how I understand it well and I'm a bit confused what's the
> "fuss" about. The git.centos.org mirrored sources that were used to build
> CentOS. Since CentOS is no longer supported, and we have the CentOS Stream, 
> the same is
> true - the sources are still available, just at different location [0]. So 
> this
> doesn't seem like RH is "locking things down", just getting rid of things
> that are not needed anymore.
> 
> Note that I'm in a no way endorsing the change, I'm just trying to understand
> what's the big deal (if there's any).
> 
> [0] https://gitlab.com/redhat/centos-stream/rpms
> [1] https://vault.centos.org/centos/8-stream/

The big deal is that it sends wrong signals at the wrong time. Within the last 
few weeks, we had out of the blue (pun intended):
- Lay-off of the Fedora Program Manager
- Dropping LO packages and dependencies the hard way (orphan first, announce 
later when the rubbles are crumbling)
- Retreating from GPL's source distribution requirement to the bare minimum (or 
less, I'm no lawyer)

In each case, the way it was done and communicated was literally begging for 
bad press.

In the specific case of RHEL srpms, it makes life harder for EPEL packagers 
because you can't look at the source easily when they are problems between RHEL 
and EPEL packages. It matches well with RH's standard of shipping libraries 
without headers etc - it is easier for them and limits the scope of support 
contracts but makes upstream's life harder.

So, the signal is either "we don't care about our upstream" or "we do not 
understand upstream's importance and concerns".

And that is why packagers may consider dropping EPEL branches and let RH pick 
from Fedora what they want - at the expense of having to support it themselves. 
That will reduce RHEL to a pure enterprise distribution without community. Is 
that what their customers want?

Groundhog day.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Releasing package updates in multiple Fedora releases

[Michael J Gruber]

> On Sun, Jun 18, 2023 at 09:16:28AM +, Mattia Verga via devel wrote:
> 
> So one alternative is *not* to push the change to all branches.
> 
> Unless it's really necessary, such as fixing an essential bug, I tend
> to leave older Fedora branches on a stable release, to reduce churn

Exactly. Blindly pushing to all active releases is never a good idea. Now, I'm 
not saying people here do that, but those shortcuts make it too easy to do it 
in a rash ...

In particular: Most proposals do it in the wrong order (old to new) and some 
without error catching. You may end up with newer builds in older releases - 
without an update yet, granted, but still.

> ...
> 
> (Also note 'fedpkg clone -B' option to use a separate subdirectory for
> each branch, much more intuitive IMHO.)

That creates a bunch of unrelated git repos. Maybe we should teach fedpkg to 
use current git's method for that, which is worktrees. That way you share not 
only the object store ("one fetch rules them all") but also config such as 
remote definitions (for forks) etc. The main worktree could be a main/rawhide 
checkout.

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

Re: LibreOffice packages

[Michael J Gruber]

The main difference is that Fedora - be it rpms, flatpaks from module rpms 
(current state), flatpaks from whatever - comes with the promise of all the 
four F's, including freedom from legal issues as outlined in our guidelines. 
That enables RedHat to make the guarantees which they make for their offerings.

Flatpaks from third party sources such as flathub come with no promise 
whatsover (AFAICT) - unless you track a specific flatpak's provider and figure 
out their promises/guarantees per flatpak. And without that neither Fedora nor 
RedHat can ship any app on live media and such.

A different question is shipping configuration for third party rpm repos (such 
as rpmfusion) or flatpak hubs (such flathub). Here, the issue is:
- Shipping a Fedora/RHEL specific (enabled) repo/hub config might be considered 
redistribution, or at least RH legal may consider that a risk too high to take.
- Shipping a non-specific (enabled) hub config can hardly be considered 
redistribution, or at least RH legal does not seem to fear that risk (since 
unfiltered flathub).

From a customer perspective: Your on your own with anything you pull in from 
third party sources.

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

Re: LibreOffice packages

[Michael J Gruber]

I've taken up hyphen and the orphaned hyphen-* packages. They don't appear to 
be high maintenance, but co-admins welcome, of course. Similarly, feel free to 
admin as co-admin to other hyphen-* in case something needs coordinations. The 
language packages are basically a "cp" in "%install", though, and nothing to 
build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: LibreOffice packages

[Michael J Gruber]

> Il 02/06/23 01:55, Sandro ha scritto:
> I'm having a bad feeling about Fedora future lately, seeing all these RH 
> withdrawals from the project.

That escalated quickly, yes. More worryingly: It escalated non-openly and 
non-collaboratively.

> I hope to be wrong. But could Fedora survive the day RH says goodbye? 
> Shall we start thinking about having a structure (both government and 
> financial) like libreoffice foundation?

We depend quite a bit on infrastructure (both technical and staff-wise) which 
RedHat still provides generously to us. RH being a profit oriented company (or 
rather, part of an even more profit oriented company), "generous" probably is a 
naive description. They have to justify every investment, of course. 
Apparently, the terms for that justification changed with new stakeholders. I 
don't think that Fedora has changed a lot since. Maybe a governing structure 
outside of RedHat would make it easier for them to support Fedora, 
"lump-sum-wise" (money, man-years), because it would lift their requirement to 
justify each and every individual "item"?

> BTW dropping RPMs for Flatpaks makes the whole Fedora philosophy 
> useless. Flatpaks just bundles what they need, free software or not 
> (i.e. codecs support) so upstreams have no interest in find OSS solutions.

Exactly. To me that seems to be the bigger problem, and it has been developping 
in that direction for a while already:
- Fedora flatpaks never took off, both for technical reasons (it's still 
difficult for packagers) and ideological ones (marketing of flatpaks vs 
reality); both related to the way modules came upon us.
- Codecs/Multimedia were never easy in Fedora; using (and providing) rpmfusion 
is made difficult by feature-reduced versions in Fedora, and by the fact that 
we cannot even include disabled repo config for them in Fedora.
- Flathub flatpak config considered to be OK in Fedora by RH legal *because it 
is not Fedora specific* (as opposed to rpmfusion).

Taking all this together, the direction is: Sell the OS (that is, support and 
assurances) and let the customer be responsible for what "apps" they run on 
that OS (from flathub or wherever). Fedora flatpaks do not have any place there 
(and solve no problem).

I doubt whether that really is what customers want from RedHat. But I'm sure 
that is nothing which Fedora packagers want to be the upstream for. We'd flock 
elsewhere, be it distro A for its technical orientation, distro D for its 
stance on freedom, or some package upstreams to help with that flatpak, on 
whatsoever distro that will run on.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Aspell Depreciation (Self-Contained Change)

[Michael J Gruber]

> === BuildRequires ===
> repoquery -q --repo=rawhide{,-source} --whatrequires 'aspell*' | grep
> -v '^aspell' | grep 'src$' | pkgname
> 
...
> hunspell-az
> 
> hunspell-csb
> 
> hunspell-de
> 
> hunspell-en
> 
> hunspell-fa
> 
> hunspell-gv
> 
> hunspell-ky

Apparantly, our spelling dictionaries for different languages come from quite 
different sources, and some use aspell to convert them during package build. 
This change provides an opportunity to update them to "hunspell-native" 
dictionaries, which can support more functionality (e.g. for compound words, 
block lists).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

[Michael J Gruber]

Makes a lot of sense and improves the information value of the version greatly.

I'm just wondering whether the name suffix is the right place to put "flatpak" 
as if it were a subpackage - can we use the dist tag instead, say `fi39` for 
"fedora immutable based on fedora 39" or something like that? Or `fp39` for 
`fedora flatpak ...`?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: The new version of Fedora Messaging Notifications will arrive this week

[Michael J Gruber]

Speaking of not obvious ...

One starts with no rule at all. Does that mean no notifications? I.e., is 
include or exclude the default?

A few templates might not hurt. Or is that what "tracking rule" means?

Should we disable all rules on the old fmn, i.e. does the old one keep sending, 
or is it just the rule interface which differs?

Is there no documentation/help or did I just fail to find it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: It’s time to transform the Fedora devel list into something new

[Michael J Gruber]

How dare you - I'm glad you did :)

Even though I'm a "mail/mailing list guy" using TUI MUAs, I found myself 
turning delivery off on many high volume MLs where the volume does not 
correspond to my contributor's frequency. I even read fedora-devel via 
hyperkitty's web interface, which is really suboptimal. So I see both the value 
and the problem with MLs. A different transport like public-inbox may help me 
but not many others.

In any case, we have quite a fragmentation right now with the MLs, forum 
(discourse), IRC, Matrix, plus tickets on various platforms (bz, dist-git, 
pagure, gitlab) some of which offer teams and discussions, too. Choice is good, 
fragmentation is not because it makes it hard to know:
- Where can I reach whom?
- Where can I discuss what?

So I'm really all for reducing that fragmentation, and it can be made to work 
as a community decision only (community discussion that you started, whatever 
committee's decision). Ideally, we reduce the platforms to a few which still 
allow choices about how to participate (clickery vs tui, poll vs push/notify). 
More technically oriented folks will be more capable to adapt technically (than 
"pure users") but less willing to communicate by clicking around in a web 
browser. A platform analysis in this regard could support 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: Fedora 38 Workstation boot time and memory improvements

[Michael J Gruber]

> On 2023-04-14 01:28, Michael J Gruber wrote:
> 
> 
> The boot time improvements came from removing iscsi from the critical 
> path.  There's no longer a dependency on network-online in the path to 
> graphical.target.
> 
> The memory improvements came from allowing packagekitd to shut down on idle.

Thanks, and I can confirm that on upgrade F37->F38, iscsi does get removed from 
cp. Great!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora 38 Workstation boot time and memory improvements

[Michael J Gruber]

> I didn't mention this in time to even discuss whether it'd make a good 
> addition to the release notes, but I think users will be happy to see 
> that Fedora 38 Workstation boots faster and uses less baseline memory 
> (measured from a session logged in to GNOME with only a terminal 
> application running to get the output of the "free" command).

Interesting. Can you pin down from you analysis where the difference comes 
from, especially in user-space? I'm asking for a friend :-)
... the point being: Do upgrades profit as well, or should we review systemd 
services at boot which might remain from F37 after upgrade for new defaults?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: %patchN deprecated?

[Michael J Gruber]

Yes, I've figured this out meanwhile. I still see it as the proven packager's 
job to give some information before or at least while pushing a change that was 
neither announced, nor called for by a change proposal.

As you point out correctly, the new syntax just landed in rpm 4.18 (F37 up), so 
there is no proper grace period either.

My solution is to go for `%autosetup` where possible and `%autopatch` with 
`-m`/`-M` where needed. This is in rpm >= 4.11 and therefore a much better 
solution than the one which got force pushed without having a chance to do the 
saner one.

I had failed to notice that `-P` is supported on more versions - that could 
have been the replacement if there was a need to push a change, but rpm docs 
prefer the positional argument over the `-P` option.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

%patchN deprecated?

[Michael J Gruber]

Has `%patchN` been deprecated in favour of `%patch N`?

I got a push by a proven packager to one of the packages which I maintain, 
commit subject and changelog entry "Fix deprecated patch rpm macro". It 
contains no explanation and no reference whatsoever. I didn't find any heads up 
notice, nor info in the packaging guidelines, but I didn't try too hard - 
because it's not my job.

I mean: One person is doing that push. Is it too much to ask to get at least 
the slightest bit of reference or communication before or into a push which 
probably affects hundreds of people? If not out of courtesy then out of mere 
common sense of efficiency?

On the technical side, I'd be interested why this is better (fewer macros?) and 
which releases can take it, and what are the recommendations for 
`PatchN:`-lines (with or without N), and why (or whether) the recommendation 
isn't to go for `%autosetup` or `%autopatch` - maybe all answered in the 
missing reference.

P.S.: There is nothing to "fix" here either, only to "adapt" to the deprecation 
notice, but I'll take that one easy between non-native speakers, presumably.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Strange hook in cloned package repositories

[Michael J Gruber]

Alternatively, rpkg could ship the hook in a more central location (which has 
exec). This would allow you to set `core.hooksPath` for your fedpkg repos, 
maybe even automatically by using something like `git config 
includeif.gitdir:~/fedora/.path ~/.config/git/config.fedora` and putting the 
hook path config there.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Packaging portmidi versions: devel conflicts OK?

[Michael J Gruber]

> I think so , see openssl example : 
> 
> dnf install openssl1.1-devel openssl-devel
> 
> Package openssl-devel-1:3.0.8-1.fc37.x86_64 is already installed.
> Error:
> Problem: problem with installed package openssl-devel-1:3.0.8-
> 1.fc37.x86_64
> - package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl-
> devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64
> - package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl-
> devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64
> - conflicting requests
> - package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with
> openssl-devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64
> - package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with
> openssl-devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64

Thanks for pointing this out. Their compat had this in spec:
```
# The devel subpackage intentionally conflicts with main openssl-devel
# as simultaneous use of both openssl package cannot be encouraged.
# Making the packages non-conflicting would also require further
# changes in the dependent packages.
Conflicts: openssl-devel
```
I'm not sure this beats packaging guidelines, though ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Packaging portmidi versions: devel conflicts OK?

[Michael J Gruber]

> On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber  wrote:
> 
> 
> Compatibility packages do not get a "compat-" prefix any more; they only
> get a version suffix. The old portmidi could be portmidi217 (to match the
> old versioning) or possibly portmidi0 (to match the soversion). It's also
> preferred (but I'm not sure that it's written down or is just a discussion
> within the FPC right now) that the un-suffixed version is the latest one.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

Good point. Whether it's required or just preferred - it's a recommendation 
which I should follow, and why I've been asking here :) 

It forces depending packages to choose between changing their BuildRequires (to 
the new name for the old version) or adjusting if needed (to the new version).

It also forces me to introduce epoch so that version 2.0.4 will be an update of 
the existing 217, right?

Now the big question is: In which releases can I rename the package? I'm afraid 
the answer will be "rawhide only", which means "new" portmidi will be in Fedora 
39 only. Or can I have "portmidi0 + portmidi" there and "portmidi + portmidi2" 
in releases branches?

> Compatibility packages do not need a review.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...

That much is clear. Your preference provides an answer to another question of 
mine: "... and MUST NOT conflict with all other versions of the same package." 
So, while openssl seems to violate that for whatever reasons, I cannot do the 
same.

So, technically speaking:
- I go through the new-package process for a new package (the compat package) 
but note that no review is required.
- Import the package (and history) into the newly created dist-git repo and 
rewrite the spec for the new name (portmidi0 or such).
- Update the package in the old dist-git repo to the new repo.

Or do I request a new repo "portmidi2" and build the new "portmidi" from there 
("and portmidi0" from the "portmidi" dist-git repo)?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Packaging portmidi versions: devel conflicts OK?

[Michael J Gruber]

> Il 03/03/23 19:00, Michael J Gruber ha scritto:
> What about:
> 
> - create a compat-portmidi0 package and move current portmidi there
> (bonus: mark it as deprecated)
> - change frescobaldi to require the compat package until a fix is available
> - update current portmidi package to v2

That is possible in the long term, anyway. But it takes time unless you do this 
on released Fedoras, too.

> BTW, this is not the first time such a discussion arise and I think
> FESCo / Packaging Guidelines must provide a definitive answer for this.

Thanks to Sergio I know a precedent know. I'll take another look at pm2 to see 
if can somehow avoid the conflicts without creating hardships for depending 
packages, and otherwise go for the middleground plan which will require a 
review for te "new" package in any case.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Packaging portmidi versions: devel conflicts OK?

[Michael J Gruber]

SHORT VERSION

The portmidi library in Fedora is at version 217, which is quite old.
Upstream changed to a new version scheme, currently at 2.0.4, and
dumped some subpackages. To serve the needs of different other
packages, it would be easiest for me (as the portmidi maintainer in
Fedora) and them to:

- create a new package portmidi2
- avoid any file conflicts between subpackages of portmidi and portmidi2 except:
- allow file conflicts between portmidi{,2}-devel (.so, headers)

This would allow to build packages against both versions (just not in
the same container) by simply requiring the right devel package, and
the libraries could coexist. Is this allowed by the packaging
guidelines?

LONG STORY

portmidi has been a slow moving package, with some code changes after
the repo split and versioning change upstream. In Fedora land, I got
several requests to update portmidi to 2.0.*, but:

- This requires epoch.
- It is is not a strict update.

In particular, the python bindings are "gone" (separate unmaintained
project) but are required by frescobaldi.
Also, the java bindings were deprecated, then taken up again. We never
shipped them in Fedora but used them to build portmidi-tools which no
package requires.
Several packages buildrequire portmidi:
csound darktable  denemo  mame  mscore  prboom-plus  pygame
(I left out audacity and rpmfusion packages here.)
All of them build fine against portmidi2:

https://copr.fedorainfracloud.org/coprs/mjg/portmidi2/

The failures are only on EPEL chroots, due to missing other BRs of
those packages. portmidi2 builds there, and I got requests for EPEL,
too.

I know that at least darktable maintainers would be happy about having
the new features of portmidi2 specifically. The two usual alternatives
are:

A) put up portmidi2 as an update to portmidi
B) put up portmidi2 as a separate package, no conflicts

In A), it takes much longer to have portmidi2 available in released
Fedoras. In particular, I would have to wait for python bindings or
changes in frescobaldi.

In B) I would need to rename the library and the header install
location. Not only is the upstream build process somewhat stubborn,
but this could also require depending packages to adjust includes and
such (unless everything is picked up from pkconf).

The suggestion under "SHORT VERSION" is a middle ground between A and
B at the expense of conflicting devel packages.

https://src.fedoraproject.org/rpms/portmidi
https://github.com/PortMidi/portmidi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: dnf should offer to update all of the dependencies of any package installed or updated

[Michael J Gruber]

libsoup3 depends on libnghttp2.so.14

Apparantly, either libsoup3 should depend on the minor version (in addition to 
the major version), or libnghhttp2 should have bumped major, depending on the 
"history" of that symbol. Probably the former (API addition in a minor bump to 
the same major).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

dnf ref-counting of identical files?

[Michael J Gruber]

I have two packages which install identical files under the same name in the 
same locations (/usr/share/icons/hicolor/256x256/mimetypes/ and the like). `dnf 
install` does not warn about conflicts, `rpm -qf` shows both packages as owner, 
`dnf erase`ing one leaves the files in place, erasing the last one erases the 
file.

Now, this is all works better than I would have hoped for. Does this work by a 
general mechanism (inclding checksumming), or is this special cased for the 
mimetype icons, or an artefact of installing both packages within the same 
install command?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Use cases for 'fedpkg scratch-build'

[Michael J Gruber]

Yes, testing local changes with `srpm` is the main use case. I would even say 
that using `scratch-build` without `--srpm` is a typical mistake for new 
packagers - thinking they test before they push, when in effect they don't.

Testing (scratch-building) the pushed head makes sense when there are/were 
koschei warnings, or updates to related packages and you want to know whwther 
your package still builds (would build) as is, say before a mass rebuild.

And as you point out, checking out the pushed head gives you almost that at the 
expense of an srpm rebuild, which is not exactly the same as scratch-building 
the "original srpm".

`--srpm` is named misleadingly, by the way, because it names the "transport of 
the source" when indeed it implies a potentially different source version. 
That's another reasons why removing it (the name) and making it the mode of 
operation for `scratch-build` makes sense:
- `scratch-build` is about doing things from (your) scratch. That involves an 
srpm for technical reasons.
- `build` is about building something pushed, and `--scratch` only changes 
where it is build.

Now I'm wondering: Does `fedpkg build --srpm` imply `--scratch`? I would hope 
so, and I'm really wondering whether any srpm-mode should belong to that 
command at all. It's much clearer if `build` deals with sources "in the 
buildsystem" only, and {copr,scratch,local,mock}-build with the local sources. 
(Yes, `local` and `mockbuild` could have helpful aliases, too.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: TeXLive 2022 landing in rawhide today

[Michael J Gruber]

First breakage seems to be here:

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

Related to lua loading of otf fonts
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: rpmautospec - how to add suffix to the current release and don't bump it right now

[Michael J Gruber]

> On Tue, Jan 03, 2023 at 12:00:21PM +0100, Zdenek Dohnal wrote:
> 
> My understanding — which may be not be the whole picture — is that this is not
> supported by rpmautospec natively. Essentially, every spec file change is
> _supposed_ to caused the Release number to grow, so by definition, a commit 
> that
> adds a minorbump will also cause a bump of the release value, which is not
> useful.
> 
> The desired effect can be implemented by overriding %dist:
> 
>   %global dist %dist~test.0
>   Release: %autorelease
> 
> Notice that I used '~' to make the redefined %dist _lower_ than the original.
> Let's say that the last official build had Release==1.
> When this spec is built, you end up with Release==2.fc38~test.0.
> When the %dist override is removed, and the package is built officially,
> we end up with Release==2.fc38  (2.fc38~test.0 < 2.fc38).

While this is nice, note that it will work once only, i.e. you cannot do a 
test.1 against the same "-2" this way.
Have you tried `-b` and `-e` options to `%autorelease`?

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

[Michael J Gruber]

> The devel package are not included in CentOS repositories unless requested

Yes, but Mark reports that his package builds "with EPEL, but not with CentOS". 
As for as I know, we have the following in copr:

chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL
chroot "centos stream 9" has base CentOS Stream 9 and repos 
base+AppStream+Extras+CRB

So, where do the devel packages in Mark's build come from? They can't be in 
EPEL if the lib is in RHEL.

Also: What is the "devel" repo mentioned in the centos FAQ, i.e. what is the 
proper dnf repo name and which copr chroot uses it? Every time I think I 
figured out the EL landscape it gets more complex ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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