Re: Installing ffmeg-free degrades firefox video support

[Otto Urpelainen]

Martin Stransky kirjoitti 6.6.2022 klo 11.48:


You can get exact info by running Firefox with

MOZ_LOG="PlatformDecoderModule:5"

env variable.


Thank you, this is a good thing to know.
However, te problem was resolved by ffmpeg-free update,
so I do not need to delve into the output this produces now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Otto Urpelainen]

Dominik 'Rathann' Mierzejewski kirjoitti 6.6.2022 klo 11.54:

On Saturday, 04 June 2022 at 00:05, Otto Urpelainen wrote:

I have discovered that installing the ffmpeg-free package degrades Firefox
video support. Without any kind of ffmpeg installed, Firefox is able to play
all the videos I want to watch. Installing RPM Fusion's ffmpeg package does
not change this. But, installing ffmpeg-free from Fedora repositories causes
some videos not to play.


Could it be https://bugzilla.redhat.com/show_bug.cgi?id=2089986 ?

There's an update fixing it, so please test:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-e3c5f45422


Thank you for the pointer!
By the time I got around testing this update,
it was already stable and installed on my system.
The problem is now gone, so most probably it this bug.

I now have another failure,
but it is a corner case that involves disabling ffmpeg in Firefox
and rejecting YouTube cookies,
and is also fixed by page refresh,
so I am not sure if I have the energy to investigate 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Otto Urpelainen]

Michael Catanzaro kirjoitti 5.6.2022 klo 16.08:
On Sat, Jun 4 2022 at 01:05:58 AM +0300, Otto Urpelainen  
wrote:

It seems clear that there is a bug somewhere, but I cannot decide,
where, hence this post to devel. Should Fedora's Firefox actually have
media.ffmpeg.enabled set to false by default, because Fedora's variant
of ffmpeg has this problem? Should upstream Firefox be smarted about
which decoder library it attempts to use? Or should ffmpeg-free package
do something to avoid this from happening. Any opinions are welcome!


Only the developers will be able to tell you for sure, but I would start 
with a Firefox bug report. That's the place where code changes are most 
likely to be required, and the Firefox developers can always punt the 
bug to ffmpeg if they think it is doing something wrong.


Thank you. It seems that Firefox is the best direction to ask about this.
I will report this to their issue tracker.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Installing ffmeg-free degrades firefox video support

[Otto Urpelainen]

Vitaly Zaitsev via devel kirjoitti 4.6.2022 klo 14.04:

On 04/06/2022 00:05, Otto Urpelainen wrote:
It seems clear that there is a bug somewhere, but I cannot decide, 
where, hence this post to devel. Should Fedora's Firefox actually have 
media.ffmpeg.enabled set to false by default, because Fedora's variant 
of ffmpeg has this problem? Should upstream Firefox be smarted about 
which decoder library it attempts to use? Or should ffmpeg-free 
package do something to avoid this from happening. Any opinions are 
welcome!


1. Enable RPM Fusion repository.
2. sudo dnf install ffmpeg-libs --allowerasing


Sure, RPM Fusion's ffmpeg does not suffer from this problem. But the 
question is, what needs to be done so that ffmpeg-free will not suffer, 
either.

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

Re: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Otto Urpelainen]

Ben Cotton kirjoitti 2.6.2022 klo 22.27:

* Policies and guidelines:
** The Fedora packaging policy will be updated to require that new
flags added to redhat-rpm-config come with their own RPM macro.


By the proposal owners, I presume? The guidelines should also be updated 
to present the new macros as the preferred way of modifying build flags.

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

Installing ffmeg-free degrades firefox video support

[Otto Urpelainen]

I have discovered that installing the ffmpeg-free package degrades 
Firefox video support. Without any kind of ffmpeg installed, Firefox is 
able to play all the videos I want to watch. Installing RPM Fusion's 
ffmpeg package does not change this. But, installing ffmpeg-free from 
Fedora repositories causes some videos not to play.


This is unexpected, because one would expect that installing any variant 
of ffmpeg would improve video support, not degrade it. My hypothesis is 
that Firefox prefers ffmpeg over openh264, but is not careful enough to 
check if the ffmpeg it detects actually supports h264.


As a workaround, I can set media.ffmpeg.enabled in Firefox's 
about:config to false. Then all videos play again, even with ffmpeg-free 
installed.


Here is an example video from Youtube that can be used as a reproducer:
https://www.youtube.com/watch?v=ETsAH96BsBg

It seems clear that there is a bug somewhere, but I cannot decide, 
where, hence this post to devel. Should Fedora's Firefox actually have 
media.ffmpeg.enabled set to false by default, because Fedora's variant 
of ffmpeg has this problem? Should upstream Firefox be smarted about 
which decoder library it attempts to use? Or should ffmpeg-free package 
do something to avoid this from happening. Any opinions are welcome!

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

Re: Unretire ufo2ft

[Otto Urpelainen]

Benson Muite kirjoitti 28.5.2022 klo 22.00:

Hi,

Would like to unretire ufo2ft[1][2].  The package is useful for building 
font packages from source, which the Fedora font packaging policy 
encourages.


That should be fine, because the it seems that back in the day, the 
package was retired just because the former maintainer had lost interest 
and did not fix it for Python 3.7. Upstream also seems to be active.


I assume this notification is step 2 of "Claiming Ownership of a Retired 
Package" [1]. Did you already fix the specfile and submit a package 
review request?


You do not say if you are already a member of the packager group. If 
not, you need to get sponsored there to become the maintainer for this 
package. See "Joining the Package Maintainers" [2] for that.


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

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

Re: SPDX identifiers in old branches?

[Otto Urpelainen]

Neal Gompa kirjoitti 25.5.2022 klo 16.49:

On Wed, May 25, 2022 at 9:34 AM Daniel P. Berrangé  wrote:


On Wed, May 25, 2022 at 09:25:01AM -0400, Neal Gompa wrote:

On Wed, May 25, 2022 at 8:40 AM Daniel P. Berrangé  wrote:


On Wed, May 25, 2022 at 10:49:15AM +0200, Miroslav Suchý wrote:

Dne 25. 05. 22 v 2:44 Miro Hrončok napsal(a):

2) There are tags that might mean slightly different things in each
notation. E.g. MIT. Is this package licensed with the SPDX MIT? Or is it
a old-style MIT that might mean different SPDX notation? Note that the
old-style MIT seems to be a superset of SPDX MIT, so this isn't probably
getting worse than it is, it's just a tad confusing.


I think that we can assume that if

gitlog --pretty=oneline

contains `spdx` or similar string, than the spec file use the new notation.


E, please no. Apps need to know whether a given RPM is using SPDX
or not, independantly of whether they have Fedora git source history
available. We just need to record this fact in the specfile explicitly,
so it is available both to maintainers and to any apps parsing the
spec and to any apps querying the installed RPMDB.



I think people assume we do more with the License tag than we actually
do. We have no active automated auditing or validation of package license tags
at this time. That may come in later phases, and lead to total
conversion to SPDX identifiers, but right now, this is overthinking
the problem way too much.


I don't think it is overthinking. The change proposal says

   "There will be [[Changes/SPDX_Licenses_Phase_2|Phase 2]], where
we identify the remaining packages and help them to migrate to
the SPDX formula."

so whatever we do in phase 1 needs to leave us in a state where
we have a reliable way to identify outstanding packages needing
converting in phase 2.  I don't think relying on git logs is a
satisfactory solution to that problem, compared to the suggestion
to use 'License: SPDX: ' in the spec which is unambiguous
and explicit.



Phase 2 will likely include a total audit anyway, so I don't think we
should worry about that now.


Yes, any proposal that involves something else that adding new allowed 
license ids, removing unused allowed license ids and updating packages 
to use correct, allowed license ids is over-complicating this issue.


Are the other identifiers that appear both in the current list and 
proposed new SPDX list, or is "MIT" the only instance?


My proposal: Define a new identifier "MIT-family" (or some better name) 
with the same meaning as current "MIT". Run a provenpackager script to 
update every existing with "MIT" to "MIT-family". Remove "MIT" from the 
list, as it is not in use now. Reintroduce "MIT" when the SPDX update 
happens, with its new meaning.

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

Re: FESCo election nominations are now open

[Otto Urpelainen]

Ben Cotton kirjoitti 18.5.2022 klo 20.03:

We currently have three candidates for five open seats. This math does
not work out. You may nominate yourself (or someone else, with their
permission) before 2359 UTC on Wednesday 25 May.

On Wed, May 11, 2022 at 9:05 AM Ben Cotton  wrote:


Now through 25 May, you may nominate candidates for the five open
seats on the Fedora Engineering Steering Committee (FESCo).

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations


You write five seats, but that wiki page says four seats.
Which is correct?
Either way, the math does not work out.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Rijul Gulati

[Otto Urpelainen]

Rijul Gulati kirjoitti 15.5.2022 klo 21.05:

Hello Fedora,



My name is Rijul Gulati. I am a Software Developer from India.

I have been using Linux for a couple of years now, and would like to contribute 
to the fedora project.


Welcome Rijul! Contributions are much appreciated.


I would like to start contributing as a Package maintainer, and then would 
probably branch out to other domains (core development/infrastructure is what I 
would like to get involved in as well.),

Are there any packages looking for new maintainers? Or maintainers looking for 
someone to adopt their packages? I would like to give them a try and adopt some 
maybe.
Please let me know how I can start.


Yes there are.
Periodically, mails with title "Orphaned packages looking for new 
maintainers" are sent to this list.

You can check the latest one [1] if there is anything you are interested in.

I also suggest that you check Bugzilla for any open issues in packages 
that you actually use.

If you find any,
you can see if you can fix them and submit pull requests to those packages.
It is more motivating to work on packages that you actually use,
and submitting pull requests gets you started easier than trying to 
tackle the sponsorship process right away.


If anything is unclear, please ask!

[1]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V73JRRCDZ532RVZ2UFVGMDS4AAQYU4RV/

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

Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

[Otto Urpelainen]

Neal Gompa kirjoitti 18.5.2022 klo 19.40:

On Wed, May 18, 2022 at 12:27 PM Vít Ondruch  wrote:



Dne 18. 05. 22 v 15:51 David Cantrell napsal(a):

On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:

On 17. 05. 22 21:49, Miro Hrončok wrote:

On 17. 05. 22 17:06, Miroslav Suchý wrote:

Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):

Thanks for the explanation. Could this be explicitly written in
the change proposal?

Yes. I will amend the proposal with FAQ posted in this thread.


Also, when you say "after F38 branching", does that mean it will
not be allowed in f35, f36 and f37 branches?

No. Old branches i.e. f35, f36 and f37 will keep using the old short
names. No change there. The same for epel9-.


Do we need to %if-%else it in the spec file? I recall some
discussion about this on the legal list, but I see no guidelines
proposed here.

If you maintain one spec for all branches then you will need
%if-%else. And yes, it works.

I just got an idea. Do I assume right that while the old Fedora tags ->
SPDX mapping is ambiguous, but the reverse is well defined? If that's
the case, can we make a macro that would:

1. Validate an SPDX expression for correct syntax, errors if invalid
2. On Fedora > X || RHEL > Y returns the input unchanged
3. On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)

You would use it like this:


 License: %{spdx BSD-3-Clause and BSD-2-Clause}

This would evaluate to either of the following depending on the release:

 License: BSD-3-Clause and BSD-2-Clause

or

 License: BSD

Does that make sense? If we package spdx2fedora data in a Lua-readbale
form, I believe I can draft a naïve implementation of that macro.

Here is an absolutely naïve proof of concept. It does not validate and it
does not deduplicate.

https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3

I also see that we have 5 SPDX abbrevs that have multiple options in the old
Fedora abbrevs. The macro warns about that and uses the first value it
founds, which is the one that was written first in the data, so we can
control the priority by the data.

I think this is a good idea and thanks for making this a MR on the
fedora-license-data project, because that's where this should go.



I have proposed something similar here:

https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/V6V5KWV6SFRZF5VUZFTOGCQNRBZFFLVC/

And at that time, you did not think "using a macro for the License tag
is a good idea". But I don't mind you changing your position :)



I wouldn't bother with any of this. As I said earlier, once we enable
SPDX tags in our tools, it'll be purely additive and functional across
all Fedora and EPEL targets, so we could start using SPDX identifiers
pretty much immediately after we implement it and have the policy done.


Neal's proposal seems simple and safe.
Hiding licenses under macros and defining which license ids are allowed 
in which releases, not so much.


Add the new ids to existing lists of allowed ids.
Add some text to the Packaging Guidelines etc. recommending their use.
Run a provenpackager script that replaces all the automatically 
convertible ones.

Run a script that files issues about the non-automatically convertible ones.
Remove old ids from the lists of allowed licenses, one by one, as soon 
as nothing is using them.

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

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Otto Urpelainen]

Neal Gompa kirjoitti 10.5.2022 klo 2.10:

On Mon, May 9, 2022 at 7:00 PM Kevin Fenzi  wrote:


On Mon, May 09, 2022 at 01:21:53PM -0400, Neal Gompa wrote:

On Mon, May 9, 2022 at 1:13 PM Kevin Fenzi  wrote:


On Wed, May 04, 2022 at 09:45:55PM +0300, Otto Urpelainen wrote:

Ondrej Nosek kirjoitti 4.5.2022 klo 18.01:

Hi all,

A few months ago fedpkg introduced a change which avoids downloading source
files (from dist-git) that are not used in the specfile and therefore
downloading them would be wasting of resources and time.
The original request was opened here [1] and implemented here [2]. The
logic is part of the command "fedpkg sources" and currently can't be
disabled manually. The logic parses specfile, but doesn't do a deep
analysis, so it is doesn't always right.

Recently we got a request for opt-in implementation of this. It means you
should actively use some argument (ie. --skip-unused) to avoid downloading
unused sources. The requestor points out that it broke the original
functionality and it is not possible to add any extra arguments into the
complicated release process (RHEL kernel).


Author of the patch under discussion here.

The premise was that "specfile sources" equal "sources file sources". Since
there is a request like this, that is apparently not always the case. From
that perspective, the patch is wrong and opt-in would be the correct way.


I think opt-in will be useless and make the entire option pointless.
Most maintainers won't be aware it exists.

Why would someone want to opt-out of this?



I need to when working on ffmpeg updates, since it clobbers my
regenerated tarballs when I'm working normally. I had no idea about
this until someone pointed it out to me.


I have difficulties understanding this. If the problem is that downloads 
clobber locally modified files, how can "opting out of avoiding 
downloading" help? I would think "opting in to avoid downloading" or, 
equivalently, "opting out of downloading" would help.



So you mean where you have modified the source, but the name is the same
as in spec and it overwrites your local changes by downloading
the lookaside one over it?



Yes.


Such problem is not related to the original post. The discussion here is 
if a file listed in the sources file, but *not* as Source in the 
specfile, should be downloaded.


Fedpkg also has the feature that is avoids downloading sources that are 
locally available with matching hash. So, as already suggested in other 
replies, to avoid clobbering, after local changes, update the hash in 
the sources file. 'fedpkg new-sources --offline' will do that for you.

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

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Otto Urpelainen]

Sérgio Basto kirjoitti 8.5.2022 klo 7.52:

On Wed, 2022-05-04 at 21:45 +0300, Otto Urpelainen wrote:


Author of the patch under discussion here.

The premise was that "specfile sources" equal "sources file sources".
Since there is a request like this, that is apparently not always the
case.


Hi,
Again where is the request ? I'd like to see a bit better why it is
needed and if we really need that.
But if he want download sources that aren't use in spec file,  I prefer
opt-in in sources :

fedpkg sources --force


Just to be clear, all I know about the request is what has been said in 
this thread. Also I would be interested in more details, what is being 
stored in the lookaside cache and why it cannot/should not be listed as 
Source or Patch in the specfile?

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

Re: fedpkg sources - downloading unused source files: opt-in/opt-out

[Otto Urpelainen]

Ondrej Nosek kirjoitti 4.5.2022 klo 18.01:

Hi all,

A few months ago fedpkg introduced a change which avoids downloading source
files (from dist-git) that are not used in the specfile and therefore
downloading them would be wasting of resources and time.
The original request was opened here [1] and implemented here [2]. The
logic is part of the command "fedpkg sources" and currently can't be
disabled manually. The logic parses specfile, but doesn't do a deep
analysis, so it is doesn't always right.

Recently we got a request for opt-in implementation of this. It means you
should actively use some argument (ie. --skip-unused) to avoid downloading
unused sources. The requestor points out that it broke the original
functionality and it is not possible to add any extra arguments into the
complicated release process (RHEL kernel).


Author of the patch under discussion here.

The premise was that "specfile sources" equal "sources file sources". 
Since there is a request like this, that is apparently not always the 
case. From that perspective, the patch is wrong and opt-in would be the 
correct way.


The suggestion to also allow configuring this in fedpkg.conf is good, 
because for the majority of users who do not encounter these special 
packages could avoid the effort to adding an extra parameter every time.


It is also good to keep in mind that the original reason why unused 
sources were bothering packagers was that they easily happen during 
package version updates, when test builds are done with 'fedokg 
mockbuild' after specfile has been updated to the new package version, 
but before lookaside cache has been updated with new sources. At the 
same time wiht #564, I also wrote another path #561 [1] that enabled 
'fedpkg new-sources --offline'. That allows a package update workflow 
that also avoids unnecessary downloads:


$ rpm-bumpspec -n 1.2.3 *.spec
$ spectool -g *.spec
Downloading: https://example.com/downloads/package-1.2.3.tar.gz
Downloaded: package-1.2.3.tar.gz
$ fedpkg new-sources --offline package-1.2.3.tar.gz
Uploading: package-1.2.3.tar.gz
*Upload disabled*
Source upload succeeded. Don't forget to commit the sources file
$ fedpkg mockbuild
Not downloading already downloaded package-1.2.3.tar.gz

Given availability of this method, if there are no other, major cases 
where unused sources appear, I do not think opt-in is a bad solution.


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

Re: asterisk (FTBFS, upgrade)

[Otto Urpelainen]

26. huhtikuuta 2022 10.23.23 GMT+03:00 Michal Josef Spacek  
kirjoitti:
>Hi all,
>
>We have asterisk FTBFS for long time
>(https://bugzilla.redhat.com/show_bug.cgi?id=1977579)
>And we have asterisk not upgraded for long time.
>We have many of CVEs in bugzilla (mostly fixed in upstream).
>
>I prepared PR for fix and upgrade of 18 version in rawhide.
>(https://src.fedoraproject.org/rpms/asterisk/pull-request/15)
>Is there someone who could review or/and move forward this package?

If the package maintainer is not taking care of the package, the right thing to 
do is to follow the Nonresponsive Maintainer Policy [1].

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

Re: PackageKit Password Prompt on Fedora 36

[Otto Urpelainen]

Mark Bidewell kirjoitti 16.4.2022 klo 16.23:

I hope this is the right mailing list since this is about Fedora 36.  I
upgraded from Fedora 35 to the Fedora 36 Alpha (at the time).


Just to clarify, there are no Alpha releases in Fedora anymore.
A new release starts out as Branched, then becomes Beta and then Final.
I could not find a page that explains the whole system,
but at least some pieces can be found at [1].


Occasionally
when coming out of sleep I get a password prompt from, I believe,
PackageKit.  Before I filed a bug I was curious if this was a known issue.


I have seen this once, too.
It first prompted for the password in Finnish (the system language),
then again in English.

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

Re: adding GCC Toolset usage docs

[Otto Urpelainen]

Germano Massullo kirjoitti 13.4.2022 klo 20.08:
Hello, in my opinion we should add to Fedora Packaging Guidelines, a 
paragraph concerning GCC Toolset usage.


I recently experienced some problems in building darktable for 
epel8/epel8-next due bad configuration of gcc-toolset-11 in the spec 
file. In a few words, gcc-toolset-11 was not really enabled, so the 
builder was still using GCC 8.5.


Since this is about EPEL only, the right place to update would be EPEL 
docs [1].


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

Re: swtpm Fails to Upgrade After system-upgrade F36

[Otto Urpelainen]

3. huhtikuuta 2022 20.38.52 GMT+03:00 "Garry T. Williams" 
 kirjoitti:
>After upgrading to f36, a dnf upgrade resulted in 156 packages to
>upgrade, including swtpm.  This resulted in the following errors:
>
>...
>Upgrading: swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64  
>159/315
>error: lsetfilecon: (/usr/bin/swtpm;6249a295,
>system_u:object_r:swtpm_exec_t:s0) Invalid argument
>error: Plugin selinux: hook fsm_file_prepare failed
>
>Error unpacking rpm package
>swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64
>Cleanup  : libvirt-8.0.0-3.fc36.x86_64   
>160/315
>error: unpacking of archive failed on file /usr/bin/swtpm;6249a295:
>cpio: (error 0x2)
>error: swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64: install failed
>
>Running scriptlet: libvirt-daemon-driver-storage-8.0.0-3.fc36.x86_6  
>161/315
>...
>Running scriptlet: libvirt-daemon-8.1.0-2.fc36.x86_64
>314/315
>error: swtpm-0.7.2-1.20220307git21c90c1.fc35.x86_64: erase skipped
>
>Running scriptlet: libvirt-daemon-driver-storage-core-8.1.0-2.fc36.  
>314/315
>...
>Failed:
>  swtpm-0.7.2-1.20220307git21c90c1.fc35.x86_64
>  swtpm-0.7.2-1.20220307git21c90c1.fc36.x86_64
>
>Error: Transaction failed
>
>So it looks like this same package failed to upgrade originally during
>the `sudo dnf system-upgrade reboot` transaction.  (This is a headless
>system and I did not review the dnf logs after the upgrade.)
>
>I see nothing reported in bugzilla, so:
>
>https://bugzilla.redhat.com/show_bug.cgi?id=2071413 

Looks like
https://bugzilla.redhat.com/show_bug.cgi?id=2056303

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

Re: F36 - Errors/Warnings with `dnf update`

[Otto Urpelainen]

Panu Matilainen kirjoitti 1.4.2022 klo 16.26:

On 3/31/22 14:10, Daniel Walsh wrote:

On 3/31/22 02:35, Carmelo Sarta wrote:

Hello there!
I've never seen this error before
`error: Plugin selinux: hook fsm_file_prepare failed`
but I would try
`dnf reinstall container-selinux`
and maybe
`dnf reinstall podman`
There seems to be an error appening when people are installing 
container-selinux, that I have not pinned down.  It does not happen on 
my system.


There's a bug on this now as well: 
https://bugzilla.redhat.com/show_bug.cgi?id=2070942


Should I reassign to container-selinux?


Looks like a duplicate of [1].

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

Re: F36 - Errors/Warnings with `dnf update`

[Otto Urpelainen]

Ankur Sinha kirjoitti 31.3.2022 klo 12.51:

On Thu, Mar 31, 2022 12:16:43 +0300, Otto Urpelainen wrote:

Otto Urpelainen kirjoitti 31.3.2022 klo 11.22:

Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26:

Hello,

    Just wondering if this is a bug and what to report against. I
upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update`
and saw some odd output. Not sure if its a bug with dnf or selinux or
the packages being installed. Let me know if its a known issue or if I
need to file a bug and where.


There is a Bugzilla entry for this [1].
If you are like me and try to recover by doing selinux relabeling,
you can end up in a situation where login is not possible anymore [2].

This seems to be affecting multiple users,
so perhaps this is worth reporting as a Common Bug [3].
I will do so a bit later, unless somebody beats me to it.


Ok, I tried, but ask.fedoraproject.org gives me a permission error
when I click Create Topic.
(In Finnish, even though I changed the UI language to English
so that I could paste the error here.)
After running into multiple issues with discussion.fedoraproject.org,
I am weary of Discourse.


That's odd. Can you please try in a clean private or incognito window
where you're not using any browser extensions/add-ons that may be
blocking various bits?


I found out what the problem was.
Discussion can continue at Ask Fedora Site Feedback [1].

[1]: 
https://ask.fedoraproject.org/t/trouble-trying-to-propose-a-common-bug/20985

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

Re: F36 - Errors/Warnings with `dnf update`

[Otto Urpelainen]

Otto Urpelainen kirjoitti 31.3.2022 klo 11.22:

Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26:

Hello,

   Just wondering if this is a bug and what to report against. I
upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update`
and saw some odd output. Not sure if its a bug with dnf or selinux or
the packages being installed. Let me know if its a known issue or if I
need to file a bug and where.


There is a Bugzilla entry for this [1].
If you are like me and try to recover by doing selinux relabeling,
you can end up in a situation where login is not possible anymore [2].

This seems to be affecting multiple users,
so perhaps this is worth reporting as a Common Bug [3].
I will do so a bit later, unless somebody beats me to it.


Ok, I tried, but ask.fedoraproject.org gives me a permission error
when I click Create Topic.
(In Finnish, even though I changed the UI language to English
so that I could paste the error here.)
After running into multiple issues with discussion.fedoraproject.org,
I am weary of Discourse.
So I will not propose a common bug about this.
Hopefully somebody else does.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 - Errors/Warnings with `dnf update`

[Otto Urpelainen]

Nathanael D. Noblet kirjoitti 31.3.2022 klo 5.26:

Hello,

   Just wondering if this is a bug and what to report against. I
upgraded from F35 to F36Beta last night. Today I ran `sudo dnf update`
and saw some odd output. Not sure if its a bug with dnf or selinux or
the packages being installed. Let me know if its a known issue or if I
need to file a bug and where.


There is a Bugzilla entry for this [1].
If you are like me and try to recover by doing selinux relabeling,
you can end up in a situation where login is not possible anymore [2].

This seems to be affecting multiple users,
so perhaps this is worth reporting as a Common Bug [3].
I will do so a bit later, unless somebody beats me to it.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2056303
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2069102
[3]: https://ask.fedoraproject.org/tags/c/common-issues/141/all/f36
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

fedora-review release schedule?

[Otto Urpelainen]

Fedora-review [1] is very widely used in package review. I do not think 
I have ever seen a package review where fedora-review was not used. The 
last release is 0.7.6, released on 2020-11-11, i.e. more than a year 
ago. Since then, there have been multiple improvements.


Would it be possible to release a new version, so that the work that has 
been done would actually get used in package reviews? And what is the 
release schedule generally speaking, if there is any?

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

Re: How to make a Pagure Pull Request and How it is licensed by default for contributors outside of 'packagers' group ?

[Otto Urpelainen]

Michal Schorm kirjoitti 22.3.2022 klo 18.23:

Hello,

I'm trying to answer this question:
"Under which license are the contributions done to Fedora Project,
unless license is specified - and how make this clear to the
contributors (or whether we make this clear enough)".
The answer is _probably_ FPCA [1].

But I've run into practical questions of how contributions can be made
to the Fedora Project in the first place. Let's start with
contributions to Fedora Linux.

--

The first Google result for "Fedora pull request" query points to [2].
On the first glance it looks fine, but it has two major issues.
1/ The instructions won't work and are holey
2/ It is a page under a "Fedora CI" project.

1/
Nowadays, we have a way for contributors outside of the 'packager'
group to make pull requests. It is a git push via HTTPS [3].
Neither [2] nor [3] describes that you need to have a FAS account
first, since without it you can't log in the pagure to fork a project
(otherwise there's nowhere you can push to).
I wanted to propose an update, but ...

2/
... this leads to a belief that such an important piece of
documentation should be probably placed outside of the "Fedora CI"
project, as it can be generalized to any project.
What could be this better location for a new documentation page to
which other pieces of documentation would point to?


The CI docs page does not seem to explain doing pull requests to the CI 
project, but to Package Sources at src.fedoraproject.org. I suppose the 
CI project documents the process, because some of the CI is supposed to 
run on pull requests. (But I am not sure if any useful CI actually runs 
— I personally have not ever seen any useful CI results for pull 
requests to packages.)


A better place for that information would be the Package Maintainer 
Docs. Current coverage is very thin [1]. A ticket about making it better 
was opened recently [2]. Contributions are welcome!


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#using_fedpkg_anonymously

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

Re: nextcloud-client orphaned

[Otto Urpelainen]

py0xc3 kirjoitti 13.3.2022 klo 22.12:

Hi all,

I'm Chris, I'm currently mostly active in ask.fedora and since some time 
in the Docs. I just started to check out the mailing list to find out if 
I can support here or at testing as well :)


I just recognized that the package nextcloud-client seems to be orphaned.


That is not what I see.
In the Package Sources page for that package [1],
I see a named maintainer (left pane, under "Bugzilla Assignee: Fedora"),
and under "Members", also two co-maintainers.

[1]: https://src.fedoraproject.org/rpms/nextcloud-client

The version in the updates repo is 3.3.6-1.fc35, which is from 28 Oct 
2021 and outdated since 20 Dec 2021 (then updated to release 3.4.1). 
Current is 3.4.3:


In the same page,
I see that 3.4.2 has been submitted for testing in F34 and F35.
But it seems to have spent two months there.
The relevant Bodhi update [2] has some discussion if you want to know, why.

[2]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-23aa0e100b

Unfortunately, I have no experience in packaging yet (is there someone 
specific in charge for this package?).


If the package really was orphaned,
it would mean exactly that there is nobody in charge.
But as the package is not orphaned,
the maintainer listed in Package Sources is in charge.

In general, if you want to request a package update,
you should file a Bugzilla issue about that.
Fedora also has tooling to file such issues automatically,
so there is an issue for 3.4.3 already [3].

Apart from Bugzilla, it is often useful to query also Bodhi, Koji and 
Package Sources to get a picture what is going on with a package.
Of course you can also ask here on devel if there is something that 
bothers you.


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

Re: Let's retire original glib and gtk+ (new report)

[Otto Urpelainen]

Leigh Scott kirjoitti 9.3.2022 klo 18.15:

Sérgio Basto kirjoitti 7.3.2022 klo 18.17:
Crossfire and freedroidrpg are games, so "is it needed?" and
"does it
have a replacement?" are not good questions to ask. A better question
would be "does anybody want to play it?". Games do not really ever
become obsolete, each is a unique experience and cannot be replaced by a
"modern alternative to X with more features".

Personally, I have never played either of these games, and I suspect I
will not ever play them. Retiring them is probably not a great loss to
Fedora. But, if there is no pressing reason, security issue, lack of
maintainer or such, to retire the compatibility lib, I would prefer to
keep all the games that somebody is willing to maintain.


Otto


Both those games don't use gtk+-devel.


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

Re: Let's retire original glib and gtk+ (new report)

[Otto Urpelainen]

Sérgio Basto kirjoitti 7.3.2022 klo 18.17:

Hi,
In resume glib still required for 20 packages  [1],
apart of the sweet memories that some package bring to us , any of
these packages is needed ? or haven't replacement ?

Depending packages (rawhide) (20): crossfire crossfire-client crossfire-maps
freedroidrpg
Crossfire and freedroidrpg are games, so "is it needed?" and "does it 
have a replacement?" are not good questions to ask. A better question 
would be "does anybody want to play it?". Games do not really ever 
become obsolete, each is a unique experience and cannot be replaced by a 
"modern alternative to X with more features".


Personally, I have never played either of these games, and I suspect I 
will not ever play them. Retiring them is probably not a great loss to 
Fedora. But, if there is no pressing reason, security issue, lack of 
maintainer or such, to retire the compatibility lib, I would prefer to 
keep all the games that somebody is willing to maintain.



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

Re: Why I get some random notifications from discourse?

[Otto Urpelainen]

Kevin Kofler via devel kirjoitti 3.3.2022 klo 0.48:

Matthew Miller wrote:

I put #introductions in the default for "watching first post" because ...
I think seeing and welcoming new people joining our community is a good
default.


Frankly, I think most existing maintainers will not be interested in all
those self-introductions. If the new maintainer ends up working on the same
set of packages, they will get to know each other soon enough anyway,
otherwise, the interest will obviously be limited.

So I am not convinced that this is a valid reason for sending a notification
e-mail by default.


Fedora Discussion is not only for maintainers, it is for all kinds of 
discussion about Fedora. Package maintainers are probably not even the 
primary audience, because devel mailing list is so well established.


Personally, I do not have anything against a setting up some 
notifications on first login. Having Introductions as one of them also 
seems reasonable to me.


However, if Vít and others already had a Discussion account and had all 
notifications, I do understand that it is irritating and confusing to 
suddenly start getting notifications. User preferences should be honored.


Regarding notifying about this change, it was actually announced at 
devel-announce [1]. But, the announcement is long and it is not clear, 
if mentioned at all, that the notification settings of existing users 
will be adjusted.


[1]: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/ONAWFCLHQ2N6HMNU7CEIQKQYNVGRXT2A/


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

Re: Why I get some random notifications from discourse?

[Otto Urpelainen]

Vít Ondruch kirjoitti 25.2.2022 klo 21.08:
Is that intentional that i get some random notifications from Discourse 
or what is going on? In past month, I was notified about following topics:



* Join us for the EPEL office hours every month [Fedora] epel

* It's #FedoraShareYourScreen week [Fedora] events


These two could explained by this from "From Navigating Fedora 
Discussion — Tags, Categories, and Concepts" [1]: " As a new site user, 
you’ll be set to Watching First Post for :category_news: News & 
Announcements, and to Tracking for the Podcast and Community Blog 
subcategories."


> * Self-intro glaringgibbon [Fedora] introductions
>
> * Tempted to switch full-time to Fedora, but I got some noob questions
> [Fedora] introductions

No idea why you got these two.

[1]: 
https://discussion.fedoraproject.org/t/navigating-fedora-discussion-tags-categories-and-concepts/3

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

Re: Self Introduction: Malcolm Inglis (mcinglis)

[Otto Urpelainen]

Kevin Fenzi kirjoitti 17.1.2022 klo 22.05:

On Mon, Jan 10, 2022 at 10:47:13AM -0800, Kevin Fenzi wrote:

On Mon, Jan 10, 2022 at 11:07:33AM +0100, Vít Ondruch wrote:


Just FTR, I don't think that as a sponsor, I can close the ticket and that
is a bit discouraging.


There's no way to tell pagure.io "everyone in the fedora packager group
thats a manager is a admin here", so I have manually been adding any
sponsor who replies to a ticket.

I suppose if we wanted we could manually list everyone out and add them
and then add new folks as they became sponsors.


Additionally, I fear it would also leed to 'HI, make me a packager' type
tickets (with no other info). We could of course close those or ask for
more info, but then someone has to manage that.



You have already volunteered for providing the template, that should help to
solve this.


Hopefully. :)


ok. I have a first cut of a template there now.

Open a new issue and you should see it.

Happy to accept changes/additions/fixes via direct email or here.


Thank you, this is great!

Those two seem to contradict each other:

# If you are a new packager seeking sponsorship via new package or reviews
# please close this

and

# If you are a new packager seeking sponsorship after your new package 
submission
# was approved, please note the link to that review and your background 
here

# for sponsors to review.

For the re-reviewing of orphaned packages, I opened a FESCo ticket [1] 
so it can be properly added to relevant policies, or have the decision 
logged that those should not be required.


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

dosbox-staging license change: from GPLv2+ to GPLv3+

[Otto Urpelainen]

I have changed the License field of dosbox-staging from GPLv2+ to 
GPLv3+. That has been the correct license from start, but previously, 
licenses of this package's many bundled dependencies were not 
considered. Most of the licenses are permissive or public domain-like, 
but one is GPLv3+, which becomes the effective license.

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

Re: Does anybody still use `starship'?

[Otto Urpelainen]

Igor Raits kirjoitti 9.1.2022 klo 13.24:

Hello,

I'm interested to hear if there are any users of the `starship'
application here in Fedora that consume it from the repositories.
Please speak up if you do!


I use it, 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Malcolm Inglis (mcinglis)

[Otto Urpelainen]

Kevin Fenzi kirjoitti 8.1.2022 klo 1.23:

On Fri, Jan 07, 2022 at 11:43:15PM +0200, Otto Urpelainen wrote:


I can give a couple of reasons why just using the packager-sponsors tracker
always would be better. This is from the point of view of somebody who had
to find a sponsor. I am not a sponsor myself, so I do not really know this
looks from that side.

1. The process is currently so complicated that newcomers are frequently
confused and dissuaded by it. Having just a single way would make it
simpler. Of these two options, the single way would have to be the tracker,
because the FE-NEEDSPONSOR method only works for new package submissions.

2. In the tracker, you can write your "letter of application" in the
description, and add all the proof you have. So you can first evaluate
yourself, gather more proof if you think it will be needed, and only submit
an application when you feel you are ready. For FE-NEEDSPONSOR, it is not so
clear. The same thing can be done in the review request comments, of course.
But then the review request and the sponsorship request get mixed up, but
actually they are two different things.

3. It may be just my impression, but the system of adding the FE-NEEDSPONSOR
link feels a bit like "don't call us, we'll call you". Saying that you can
file an issue and it will be looked at feels more friendly and inviting.


Sure, I agree with all of that. However, If everyone who wanted to be
added to packager was told to file a issue, I am not at all sure we
can promise 'it would be looked at'. All the packager-sponsors tickets
go to everyone in the packager sponsors group, but I've only ever seen a
small fraction of them respond to any tickets. ;( I am not sure if thats
because they don't want to deal with sponsoring co-maintainers (the
current 'reason' to file a ticket there) or something else, but I worry
that it would just result in a big backlog of tickets there. :(


Ok, I start to see this better now. I was under the impression that both 
FE-NEEDSPONSOR and the tracker were on equal footing and generally 
speakin, receive similar attention from the sponsors. But, if the reason 
for having the tracker is (or: originally was) just the co-maintainer 
requests, where the primary maintainer actually mentors the new 
packager, then it makes sense that just a couple of sponsors keep an eye 
on that tracker and accept the request on behalf of the primary maintainers.



Additionally, I fear it would also leed to 'HI, make me a packager' type
tickets (with no other info). We could of course close those or ask for
more info, but then someone has to manage that.


One easy thing that can be done now is to add an issue template to the 
tracker repo.



Apart from co-maintenance, the tracker is also important for the case where
somebody wants to become a pacakger to rescue an orphaned package.


Well, in the past we have asked such folks to file a review request and
get the orphaned package re-reviewed.


Interesting. Previously, there was no documented process for handling 
this case at all, so I wrote section "Adopting orphaned packages" [1] to 
How to Get Sponsored page. As you can see, that section currently points 
to the tracker. Do you think we should change that to ask for a 
re-review? The current wording is not just my invention, though. There 
was discussion on devel first, and the change went through a docs pull 
request.


In case a review is required, I would like to understand, why? My 
understanding was this: Orphaned packages are assumed to be is 
acceptable condition, because existing maintainers can adopt them 
without a review. The new packager are assumed to be equal to existing 
maintainers, because somebody has agreed to sponsor them and is 
available for mentoring as needed. Some caution is certainly needed, 
since some orphaned packages can be minefields, it just did not occur to 
me that package review would be the appropriate safeguard here.


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#adopting_orphaned_packages

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

Re: [ELN] Why is rubygem-liquid included in eln?

[Otto Urpelainen]

Troy Dawson kirjoitti 7.1.2022 klo 16.46:

On Fri, Jan 7, 2022 at 12:20 AM Otto Urpelainen  wrote:


I am the maintainer of rubygem-liquid package in Fedora. Every now and
then is receive notification that this package has been built and
updated for eln, for example [1,2].

I have been trying to understand why this package is included in eln. As
far as I can understand, it should be somehow visible in Content
Resolver [3]. I have not found a "search by package name" feature there,
so I have also grepped the content-resolver-input repository [4]. I
cannot find anything there, either.

Could somebody explain how this package ends up being included in eln?

The reason why I care is that I have deferred the Liquid 5 update in
Fedora on the basis that its only consumer, Jekyll, is still on 4. These
eln builds make me suspect that rubygem-liquid is used for something
else there. I would like to check with the correct people that my
decision to stay on 4 is ok for them, too.

Otto

[1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=1873495
[2]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-11b99445de
[3]: https://tiny.distro.builders/
[4]: https://github.com/minimization/content-resolver-input



It is a build dependency of  rubygem-sinatra and rubygem-tilt [5]
Currently, the only way to find that was to go into the buildroot section
of ELN
Views -> eln -> x86_64 -> buildroot

This problem of the build dependencies being sort of hidden is being worked
on.
We are hoping to have the next major release of Content Resolver out in a
month or two.  It will make it much easier to see why a package is in the
list.


Thank you Troy, that explains the situation. I also shows that my 
original query for Fedora reverse dependencies was the build-requires.


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

Re: Self Introduction: Malcolm Inglis (mcinglis)

[Otto Urpelainen]

Kevin Fenzi kirjoitti 7.1.2022 klo 22.05:

On Thu, Jan 06, 2022 at 10:25:50PM +, Inglis, Malcolm via devel wrote:

Well, turns out https://pagure.io/packager-sponsors isn't allowing PRs.

I've pushed to a branch here with updates and dead-link-fixes for the README: 
https://pagure.io/fork/mcinglis/packager-sponsors/tree/pr-readme-update

@Kevin Fenzi , you're welcome to pull that (or use it) into the repo if you think it 
looks good. Aside link fixes, it conditionalizes the blurb about "don't apply for 
sponsorship unless you have packages that have gone through package review process", 
which I think is what deterred me here.


Thanks for the PR! Pushed.

Perhaps we could make things more clear here (or in the how to get
sponsored document). The intent is not to use the packager-sponsors
tracked for everyone who wants to be sponsored (although I suppose we
could consider doing that). It was only established for the cases where
someone wanted to add a co-maintainer and wasn't able to sponsor them
themselves or someone has a approved / reviewed package and no sponsor
lined up. I guess it makes sense to try and use it for any of the corner
cases that are not 'I don't intend to submit a new package but want to
be sponsored to do other things'.

If that all makes sense...


I can give a couple of reasons why just using the packager-sponsors 
tracker always would be better. This is from the point of view of 
somebody who had to find a sponsor. I am not a sponsor myself, so I do 
not really know this looks from that side.


1. The process is currently so complicated that newcomers are frequently 
confused and dissuaded by it. Having just a single way would make it 
simpler. Of these two options, the single way would have to be the 
tracker, because the FE-NEEDSPONSOR method only works for new package 
submissions.


2. In the tracker, you can write your "letter of application" in the 
description, and add all the proof you have. So you can first evaluate 
yourself, gather more proof if you think it will be needed, and only 
submit an application when you feel you are ready. For FE-NEEDSPONSOR, 
it is not so clear. The same thing can be done in the review request 
comments, of course. But then the review request and the sponsorship 
request get mixed up, but actually they are two different things.


3. It may be just my impression, but the system of adding the 
FE-NEEDSPONSOR link feels a bit like "don't call us, we'll call you". 
Saying that you can file an issue and it will be looked at feels more 
friendly and inviting.


Apart from co-maintenance, the tracker is also important for the case 
where somebody wants to become a pacakger to rescue an orphaned package.


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

[ELN] Why is rubygem-liquid included in eln?

[Otto Urpelainen]

I am the maintainer of rubygem-liquid package in Fedora. Every now and 
then is receive notification that this package has been built and 
updated for eln, for example [1,2].


I have been trying to understand why this package is included in eln. As 
far as I can understand, it should be somehow visible in Content 
Resolver [3]. I have not found a "search by package name" feature there, 
so I have also grepped the content-resolver-input repository [4]. I 
cannot find anything there, either.


Could somebody explain how this package ends up being included in eln?

The reason why I care is that I have deferred the Liquid 5 update in 
Fedora on the basis that its only consumer, Jekyll, is still on 4. These 
eln builds make me suspect that rubygem-liquid is used for something 
else there. I would like to check with the correct people that my 
decision to stay on 4 is ok for them, too.


Otto

[1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=1873495
[2]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-11b99445de
[3]: https://tiny.distro.builders/
[4]: https://github.com/minimization/content-resolver-input
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to handle ABI breakage in Rawhide

[Otto Urpelainen]

Vitaly Zaitsev via devel kirjoitti 6.12.2021 klo 11.01:

On 06/12/2021 03:39, Bernie Innocenti via devel wrote:
What are the current Fedora packaging guideline regarding ABI 
stability of shared libraries?


The package maintainer should ask upstream to bump the soversion field 
and if it is rejected, bump it manually in downstream.


And here is the reference for this: Packaging Guidelines, section 
"Downstream .so name Versioning" [1]. It is notable that the same 
section also says this: "Under no circumstances should the unversioned 
library be shipped in Fedora."


As for notifying about abi changes in packages, see the Updates policy 
[2]. These items are relevant:


* When a proposed update contains an ABI or API change: notify a week in 
advance both the devel list and maintainers directly (using the 
packagename-maintain...@fedoraproject.org alias) whose packages depend 
on yours to rebuild or offer to do these rebuilds for them.


* Use a side-tag when dealing with mass builds of many packages, so they 
can land at the same time. See Rawhide Gating/Multi Builds.


Otto

[1]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_downstream_so_name_versioning

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

Re: Seeking maintainers of mathematical packages

[Otto Urpelainen]

Jerry James kirjoitti 19.11.2021 klo 23.49:


To help those who may be new to packaging, I have started documenting some
of my workflows.  I have a set of web pages rooted here:

https://jamezone.org/pleasure/software/Fedora/packager/

Those pages contain walk-throughs and examples illustrating how I approach
various tasks.  I'm willing to donate any of that content to Fedora, so if
you see something you think should be on docs.fedoraproject.org, feel free
to tell me so.  Also feel free to suggest additions or changes to what I
have there.


That is a great site, with lots of great material that could well be in 
the Package Maintainer Docs. My comments here:


Determine the package license: This page could be imported to the Docs 
as it is. The only thing I would change it to avoid trying to explaing 
the correct content of License: or %license. The authoritative source 
for those rules is elsewhere, better just link there. If the 
authoritative source is unclear, that should be improved. It is 
confusing and error prone to try to explain the same thing in multiple 
places that will inevitably drift apart.


Case studies: These would also nicely supplement the current Packaging 
Tutorial: GNU Hello [1]. Perhaps some duplication could be removed by 
ordering these tutorials, then being very concise about topics that have 
already been covered in earlier tutorials. Also, my vision of the 
Package Maintainer Docs is that as few tools as possible need to be 
invoked. In particular, this means that everything that can be done with 
fedpkg, is done with fedpkg. So I would prefer to replace direct calls 
to rpmbuild, mock and rpmlint with 'fedpkg mockbuild' and 'fedpkg lint', 
and only resort to lower level tooling when 'fedpkg' cannot handle 
something.


Build packages with mock: Good material I have not seen elsewhere. Mock 
documentation for Fedora Packagers is not in good shape at the moment 
[2], it seems that making it good will need quite a bit of work.


Import a new package: This link is broken.

Update a Fedora Package: ABI Compatibility check instructions look like 
it would be useful in the Package Maintainer Docs. As for the content, 
it is not just good manners to announce abi breaks on devel, but 
according to Updates Policy, something that MUST be done.


Use a side tag: Guidance for debugging failing builds locally would be 
useful in the Package Maintainer Docs, too. Unfortunately multi-build 
docs are in bad shape [3]. I suppose the new material could first be 
added somewhere in the docs, then reorganized with all the other 
material when that eventually happens.


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/44
[3]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/33

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

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Otto Urpelainen]

Nico Kadel-Garcia kirjoitti 5.12.2021 klo 5.07:

I've been trying to bundle the current ansible-5.0.1 release as an RPM
for Fedora and EPEL use. Leaving aside the peculiar decisions to
replace the pypi.org "ansible" tarball with a tarball of roughly 150
modules from the "ansiblee-collections" repos, and moving the actual
ansible software to a distinct python tarball called "ansible-core"
without changing the source repo or the actual critical installed
python modules, the new "ansible" has more than 300 files called
"README.md" and more than 100 files called "LICENSE.md".

This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
'%license' macros strip off the subdirectories of the files and
install them directly at the top of the docdir.

Basicely these only generate one file:

%doc README.md
%doc dir1/README.md
%doc dir2/README.md

%license LICENSE.md
 %license dir1/LICENSE
 %license dir2/LICENSE.md

When compiled, these would only produce:

   /usr/share/doc/package-%{fersion}/README.md
   /usr/share/doc/package-%{fersion}/LICENSE.md


Path stripping only happens if you list relative paths with %doc or 
%license, which which case rpm looks for them from the build directory. 
If you specify absolute paths, rpm looks for them in the buildroot like 
it does for any other files. See section %doc and %license at rpm spec 
file format reference [1].


So something like this should work:

%install
cp README.md 
%{buildroot}/%{_datadir}/doc/%{package}-%{version}/README.md
cp dir1/README.md 
%{buildroot}/%{_datadir}/doc/%{package}-%{version}/dir1/README.md

# ...

%files
%doc %{_datadir}/doc/%{package}-%{version}/README.md
%doc %{_datadir}/doc/%{package}-%{version}/dir1/README.md
# ...

[1]: https://rpm-software-management.github.io/rpm/manual/spec.html

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

Re: Trying to take an orphaned package

[Otto Urpelainen]

Blaise Pabon kirjoitti 29.11.2021 klo 18.38:

Hi Otto

On Sat, Nov 27, 2021 at 7:17 AM Otto Urpelainen  wrote:


The first link is about other docs than the Package Maintainer Docs,


with some critical comments from you about the use of Antora in

docs.fp.o. The latter two are about Pagure. So if I understand
correctly, when you say that the older docs were better, you did not
mean the content, but that managing the docs with MediaWiki in the
Fedora Wiki was better than the current Antora and Pagure based approach
that used at docs.fp.o. Did I get that right?


Yes, you're correct.
I'm sorry I conflated the content question with the toolchain discussion.

Content: How to become a packager (checklist / decision tree)
It might help to step through the process and enrich the new docs.


Ah yes, the wiki Join page had a flowchart about adding a new package. I 
did not bring it over to the new docs, because it had issues:


1. Joining the Package Maintainers is not (only) about adding a new 
package, but starting the article with the diagram gave exactly that 
impression.


2. There was no caption or explanation, so it was quite unclear what the 
diagram was about. Probably because the surrounding text was living its 
own life, but the diagram remained in its original form.


I agree, such diagrams are good to have. Removing it with no replacement 
was a step backwards.


The old diagram could be meaningfully imported to "New Package Process 
for New Contributors", maybe also to "Package Review Process", I think.



ToolChain: Antora/Pagure are more aligned with the code development cycle.
Sphinx and Mediawiki are more aligned with describing practices and
cross-references.


Before I implemented the move from wiki to docs.fp.o, I did bring the 
topic up in the devel list. There were some people who thought that this 
was a bad idea. Others were supportive.


Personally, I think the system over at docs.fp.o has many advantages:

1. It is easier to make the large changes with a proper editor locally.

2. Git allows atomic commits spanning multiple pages.

3. Pull requests allow easily asking for feedback and iterating on that 
before going live.


4. It is easy to put things in categories and hierarchies at docs.fp.o, 
whereas in the extreme free structure of wiki caused materials of 
different nature become mixed up. The situation here was so bad, that 
during the move, no less than 5 FESCo policies [1,2,3,4,5] were added 
the to the FESCo docs. These were hiding in the wiki, mixed with other 
material in various degrees, editable by anyone without FESCo even 
getting notified that policies they are supposed to have define were 
being altered.


[1]: https://pagure.io/fesco/fesco-docs/pull-request/43
[2]: https://pagure.io/fesco/fesco-docs/pull-request/44
[3]: https://pagure.io/fesco/fesco-docs/pull-request/45
[4]: https://pagure.io/fesco/fesco-docs/pull-request/46
[5]: https://pagure.io/fesco/fesco-docs/pull-request/49

Still, the greatest motivation for choosing docs.fp.o was that that is 
the current docs solution of Fedora. Choosing anything else would make 
the Package Maintainer Docs an outlier, and would prevent taking 
advantage of any available tooling for docs. For example, we now have 
online editing, localization and automatic periodic deployment without 
having to work on them separately (though I admit, I have never tried 
the former two, so I do not know how well they work in practice, if at all).


Perhaps there would be an even better solution for docs.fp.o, I do not 
know. As I see it, it is out of scope for the Package Maintainer Docs, 
which should just use what is in use distro-wide.



I would be happy to make myself useful if you have any suggestions.
The last time I just jumped in to try to do things and that didn't work
well.


I am not sure what happened, but I am sad to hear that the end result 
was not good even if you had good intentions.


Be that as it may, the Package Maintainer Docs welcome contributions. 
Since you already mentioned the lack of checklists and decision charts, 
adding such where they are needed would be great. I noticed in the links 
you sent earlier that you have some ideas how to add diagrams in 
maintainable way, having something else that just uploading bitmaps 
would be great, even if update requires some manual steps.


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

Re: Onboarding package

[Otto Urpelainen]

Ken Dreyer kirjoitti 30.11.2021 klo 20.56:

On Sun, Oct 10, 2021 at 2:33 PM Dan Čermák
 wrote:

Maybe we can make a VM image (for KVM/qemu + VirtualBox) with a small
set of Fedora infra, including Koji+Bodhi.


How about a vagrant box or a docker-compose file :)

However, I'm a little worried that this might be too fat or not too
simple to set up automatically (koji itself uses Kerberos for auth,
which by itself is a huge beast…)


Here's my Vagrant file that sets up Kerberos and Koji.
https://github.com/ktdreyer/koji-playbooks/tree/master/vagrant

It's overkill for new Fedora contributors but it helps with setting up
dev Koji environments.


Have you considered submitting a link to this to the Koji docs? A while 
ago, I tried to set up a dev Koji environment just by following the 
docs. Having a pointer to this would have been very useful.


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

Re: Question about toolbox purpose/usage

[Otto Urpelainen]

Sergio Belkin kirjoitti 29.11.2021 klo 3.32:

Hi,
I've been playing a bit with toolbox, what is it intended for?

I understand that was intended primarily for immutable OS. But
documentation says that it can be used on the Workstation edition too.
AFAIK it's only useful if you don't want to mess up your /usr of your host
operating system by installing apps. Beyond that, you can happily destroy
your very $HOME, from overwriting dot files to removing any other of your
important files.
Am I missing something?
Please correct me if I'm wrong.
Thanks in advance!


You have understood it correctly. With Toolbox, your data and user 
config is shared through mounting the home directory.


Toolbox may be useful if you have two projects that need different 
versions of the same tools, or otherwise require conflicting toolchains. 
Or if you need different operating system releases for different 
projects. Or if you have just a single project, but want to keep it in 
specified release, independently of upgrading the base operating system.


I have used Toolbox to test that Fedora package updates work correctly 
in Rawhide and all active releases.


There was also a Fedora Magazine article recently that lists various use 
cases [1].


[1]: https://fedoramagazine.org/toolbx-a-developers-new-best-friend/

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

Re: Trying to take an orphaned package

[Otto Urpelainen]

Blaise Pabon kirjoitti 26.11.2021 klo 18.01:

Hi Otto,

On Thu, Nov 25, 2021 at 2:27 AM Otto Urpelainen  wrote:


Blaise Pabon kirjoitti 25.11.2021 klo 5.43:





When the docs were migrated, the intent was, of course, to make them
better, not worse. If things have regressed in some way, I would like to
fix them. Could you be more specific, in what ways the new docs less
useful? Is there some particular content in the retired wiki pages that
is not available at docs.fp.o, or what is the problem?


TL;DR: We could mitigate a pervasive "works-on-my-machine" anti-pattern
with a few simple measures.

(Two years earlier)
After 30 years at the fringe of Open Source, I decided to throw myself into
the Fedora community and find ways to contribute. I observed a few common
anti-patterns. "works-on-my-machine" happens when there is no distinction
between internal and external behavior. So, a developer has no guidance on
how to describe {{ process | artifact }} to an external stakeholder.


I am not sure what you are referring to here. I suspect that I 
misunderstood what you were referring to with "older docs" and "new 
docs". I thought what you referred as "new docs" were the current 
Package Maintainer Docs [1] and "older docs" were the Fedora Wiki pages 
that they were imported from (there is a list of those at [2]). I do not 
think the move between the two changed anything related to 
"works-on-my-machine anti-pattern" — unless you are talking about 
tooling, not content.


[1]: https://docs.fedoraproject.org/en-US/package-maintainers/
[2]: 
https://github.com/iagorubio/fedora-docs/blob/main/issue20/package-maintainer-imports.txt



Looking at the current state, one thing I notice it that currently, the
"Joining the Package Maintainers" page barely mentions sponsorship. This
is fallout from trying to make that page sound less like you have to
submit a new package to join, previously it was discussed in the "Adding
a new package" section, which is now a separate page. I will add a note
with a link in the Joining page summary, so that part is clear from the
outset.



These links include examples.
Docs community contribution hackfest (discussion)
<https://discussion.fedoraproject.org/t/fedora-docs-community-contribution-hack-fest-with-user-communities/503/23>
Write contributing guidelines in markup file and make them more visible in
a project <https://pagure.io/pagure/issue/4131>
[RFE] Expand the README to include "How to provide feedback"
<https://pagure.io/pagure/issue/4125>


The first link is about other docs than the Package Maintainer Docs, 
with some critical comments from you about the use of Antora in 
docs.fp.o. The latter two are about Pagure. So if I understand 
correctly, when you say that the older docs were better, you did not 
mean the content, but that managing the docs with MediaWiki in the 
Fedora Wiki was better than the current Antora and Pagure based approach 
that used at docs.fp.o. Did I get that right?


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

Re: Trying to take an orphaned package

[Otto Urpelainen]

Blaise Pabon kirjoitti 25.11.2021 klo 5.43:

I appreciate all the constructive suggestions, particularly those that
acknowledge the, uh , inconsistencies in the documentation.


(snip)


Regarding the docs, yes the older ones are more useful.
IMHO, it would be better for the new docs to paint a more realistic picture
of the process so that newbies don't feel like there is something wrong
with them for not figuring it out.

I'm busy trying to find a job right now, so I don't expect that I'll be
able to do much wordsmithing until I have a source of income.


When the docs were migrated, the intent was, of course, to make them 
better, not worse. If things have regressed in some way, I would like to 
fix them. Could you be more specific, in what ways the new docs less 
useful? Is there some particular content in the retired wiki pages that 
is not available at docs.fp.o, or what is the problem?


Also, could you elaborate a bit, in what ways the current docs are 
unrealistic? I would like to make them more realistic.


Looking at the current state, one thing I notice it that currently, the 
"Joining the Package Maintainers" page barely mentions sponsorship. This 
is fallout from trying to make that page sound less like you have to 
submit a new package to join, previously it was discussed in the "Adding 
a new package" section, which is now a separate page. I will add a note 
with a link in the Joining page summary, so that part is clear from the 
outset.


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

Re: Request for a new reviewer for RPi.GPIO2

[Otto Urpelainen]

Ben Beasley kirjoitti 24.11.2021 klo 4.18:
For reference, the process for a stalled review in which the reviewer is 
not responding can be found at 
https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#reviewer_not_responding. 


Also, I *think* that if you set the Bugzilla needinfo for the review, 
that processing happens automatically. If it does not, then it can be 
done manually when the conditions are met.


Anyhow, the one month period has not elapsed yet, so please be patient.

Otto


On 11/23/21 11:14, Mwesigwa Guma wrote:

Hello,

I hope you had a good week. I am sending this email because I would 
like to request for a new reviewer for the RPi.GPIO2 package. My 
previous reviewer for this package is not responding and I would like 
some feedback. Here is the bugzilla link 
.

I have CC'd Joel Savitz, the original maintainer of this package.

Thank you,
Guma

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 

Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Re: Unowned system directories

[Otto Urpelainen]

Maxwell G via devel kirjoitti 24.11.2021 klo 2.11:

Hi,

On Tuesday, November 23, 2021 1:37:36 PM CST Steve Grubb wrote:

Hello,

I am preparing to migate a F35 system to new hardware and was sanity checking
the whole system. One thing I found was that there are a number of system
directories that that are not owned by the package that uses them:

/var/cache/ibus
/var/cache/PackageKit
/var/cache/cups
/var/log/anaconda
/var/lib/tpm2-tss
/var/lib/machines
/var/lib/hsqldb
/var/lib/cs
/var/lib/rpcbind
/var/lib/portables
/etc/module-build-service
/etc/default
/etc/pesign
/etc/ipa
/etc/ndctl
/etc/flatpak


Yes,  I have also noticed issues with directory ownership. However, I am not 
sure what the rules are about packages owning directories under `/var/cache` or 
`/var` in general.  I can tell you that the `filesystem` package owns 
`/var/cache` itself:

```
$ rpm -qf /var/cache
filesystem-3.14-7.fc35.x86_64
```


The guidelines do not have any special discussion of /var or its 
subdirectories, so all the usual rules apply.


However, for /var/cache and /var/log subdirectories at least, I may be 
that the package does not actually place any files to those directories. 
I that case the %ghost directive can be used to flag a path as "at 
runtime, this path may be created; if so, it is owned by this package". 
I do not see anything about that in the guidelines, though. Perhaps 
there should be an entry about that, too?


By the way, some of those have already been fixed in Rawhide, for 
example PackageKit [1].


[1]: 
https://src.fedoraproject.org/rpms/PackageKit/c/7b07cba28db86c0983ec51caaf33868f598fb3dd?branch=rawhide



There are also some directories that are owned by multiple packages, e.g. shell 
completions packages[1,2], instead of none at all.


This is allowed by the guidelines, in certain cases at least.

In general, the current guidelines regarding directory ownership are 
terribly unclear. Some time ago, I submitted a pull request to explain 
everything more clearly [2]. I am not sure why it is not being merged, 
as I have addressed all feedback that has been given.


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

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

[Otto Urpelainen]

Matthew Miller kirjoitti 21.11.2021 klo 20.45:

On Sun, Nov 21, 2021 at 04:27:18PM +, Tom Hughes wrote:

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


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


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


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

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


Should this be read as "I would prefer flagging handle pages that were 
moved from wiki to docs.fp.o with the redirect macro"? I added the 
current notes to all pages that were moved to the Package Maintainer 
Docs, there was discussion about using the redirect macro with no strong 
argument either way, so I just picked what the Packaging Guidelines are 
doing. I can switch all of them to use the redirect, if that is the 
preferred way.


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

Re: Trying to take an orphaned package

[Otto Urpelainen]

Matthew Miller kirjoitti 21.11.2021 klo 18.18:

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

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

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

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


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

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

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


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


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


Otto

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

Re: I will take orphaned plantUML

[Otto Urpelainen]

Hello Blaise,

I am not familiar with this particular package, but about becoming a 
packager and unorphaning packages in general:


Blaise Pabon kirjoitti 18.11.2021 klo 16.35:

This is my first fedora package.
(I have tried before, but not made it this far.)


Good luck, I hope you make it this time!


In the spirit of begging forgiveness rather than permission, I opened:
https://pagure.io/releng/issue/10393


There is no need involve releng when unorphaning packages. Packagers can 
do that themselves, with the Take button that you are already familiar with.


I assume you filed the ticket because of section Claiming Ownership of 
an Orphaned Package [1] in the Package Maintainer Docs. That section 
needs to be clarified a bit. In your case releng cannot (or perhaps 
should not?) help you — you just have to gain access to the packager so 
that you can help yourself.



Is the next step for me to:

- get added to the packagers group so that I can "take" ownership


Yes. Instructions are at How to Get Sponsored into the Packager Group [2].

Also this page needs to be improved, the instructions are not very clear 
for your case. I would say a good way to proceed would be to first do 
enough of the things listed in "Convincing someone to sponsor you", then 
submit a ticket to the sponsors ticketing system [3], listing all those 
things.



- use my fork to update the broken dependencies and submit a PR?


That will not directly help. The package is orphaned, so there is no 
maintainer to merge your pull request and issue a new build.


However, submitting pull requests is one of the suggested ways to 
convince somebody to sponsor you. So please do open a pull request. It 
helps you get sponsored, and as a bonus, when you eventually get 
sponsored, you can merge the pull request and proceed to build the package.


Regards,
Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/#claiming_ownership_of_an_orphaned_package
[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/

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

Re: Intro and ownership of orphaned package.

[Otto Urpelainen]

Jan K kirjoitti 13.11.2021 klo 8.55:

My name is Jan Kuparinen
I work as a DevOps engineer. In the past I have made rpm packages of a private 
project, so I have some idea of packaging progress. I have also made some 
contributions to various Fedora projects.

I took a look at the orphaned package list for packages needing maintenance and 
found that https://src.fedoraproject.org/rpms/truth is in retired state, but is 
needed by quite a few other packages.

There have been several commits in the last few weeks to the repo, so is this 
actually maintained?

If indeed this package is in need of a maintainer, I think I can help with that.


Hello Jan,

The Package Sources page you link has the following visible, confirming 
that the package really has been is orphaned:


* "Package is currently unmaintained"
* Bugzilla Assignee: Fedora: orphan

To adopt it, you simply need to click the "Take" button on the left hand 
side. To do this, you need to be a member of the "packager" FAS group. 
You need to follow the sponsoring process [1].


However, as you already noticed in the Git log, @orion seems to be doing 
something with this package right now [2]. Perhaps it would make sense 
to contact him directly and ask what is going on and express your 
interest in (co-)maintaining the package?


Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
[2]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TO6ZK3XVYV6KRIXQ7J24RF2GIT42JXJD/

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

Re: Fedora 35 - gedit

[Otto Urpelainen]

Michael J. Baars kirjoitti 9.11.2021 klo 17.56:

On Tue, 2021-11-09 at 15:31 +0100, Vitaly Zaitsev via devel wrote:

On 09/11/2021 14:18, Michael J. Baars wrote:

Nothing with 'sudo dnf upgrade --advisory=FEDORA-2021-4ce970eca6' either. It keeps 
saying: "Nothing to do"???


sudo dnf upgrade --refresh --advisory=FEDORA-2021-4ce970eca6
--enablerepo=updates-testing



Does that work on you machine??? Still nothing on mine.


Please check the package versions you have installed against the 
versions in the update. Instructions:


First, check what the update installs. In the linked Bodhi page, open 
tab Builds and check what is in there. In this case, you will see these:


gnome-shell-41.1-1.fc35
mutter-41.1-1.fc35

Then check your local versions:

$ dnf -C info --installed gnome-shell mutter

If you see "Version: 41.1" and "Release: 1.fc35" for both of these, then 
you have the update already. That would explain why dnf says nothing to do.


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

Re: sssd-2.6.0 update in F35 breaks klist/kinit here

[Otto Urpelainen]

Ankur Sinha kirjoitti 22.10.2021 klo 17.56:

Hi folks,

I just updated two F35 systems with updates-testing enabled and then
`klist` etc. stopped working for me. Some investigation seems to
indicate that the sssd-2.6.0 update may be involved---downgrading back
to 2.5.2 immediately fixes the issue on both systems. The update
however, has 3+ karma already, so it's on it's way to stable:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-360425682d

Could more folks please test it out to see if it's a package update
related bug? (I've not touched my configs at all as far as I can
remember, so it *shouldn't* be specific to my two machines).

If it's a general issue, it'll break kinit etc. for all package
maintainers as soon as they get the update. (Running `fedpkg
new-sources` was how I ran into the issue).


Hi,

I am sure exactly what should break, but I could not reproduce this:

1. $ sudo dnf upgrade --enablerepo=updates-testing 
--advisory=FEDORA-2021-360425682d

2. reboot just to be sure
3. $ kinit u...@fedoraproject.org
4. Enter password as requested
5. $ klist
6. $ fedpkg new-sources 

Everything still works. In the new-sources step I used a file that was 
already in the cache, so that the cache would not be polluted by files 
added just for testing. Does that make a difference?


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

Re: Self Introduction: Maxwell G (@gotmax23)

[Otto Urpelainen]

Maxwell G via devel kirjoitti 12.10.2021 klo 6.44:

Hi everyone,

I am Maxwell G or @gotmax23 on FAS and Github. I am relatively new to
Linux but after trying different distros, I settled on Fedora. I don't
have a lot of time between school and having chronic pain, but I'd like
to give back and contribute as much as I can.


Welcome to the Fedora Project, Maxwell! I hope you will enjoy your time 
here.



I created a package for yt-dlp, a fork of youtube-dl with extra fixes
and features, and submitted a [review request][1] on Bugzilla. I still
need a sponsor and someone to review my submission.


Thank you for the contribution.

In cases like this, it is worth considering if the fork can be complete 
replacement for youtube-dl. If yt-dlp does everything youtube-dl does, 
just better, it could be a good idea to just replace the original with 
the improved version.


Naturally, such replacement needs to be discussed with the current 
maintainers of the youtube-dl package first. So perhaps you want to tag 
the youtube-dl maintainers with a 'needinfo' in your review request and 
ask for their view on this?



As I said, I have [contributed][2] to a couple Fedora packages on
src.fedoraproject.org prior to submitting this application; I have some
feedback on improving the contribution process for those who aren't
part of the packager group. When I have a chance to type it up, where
should I send it?

[3]:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#one_off_contributions


Contribution of this kind if very much appreciated. The first steps of a 
new packager are currently quite rough, any ideas on how to make them 
easier are very welcome.


In case you did not find it already, the source repository for the 
Package Maintainer Docs is this:


https://pagure.io/fedora-docs/package-maintainer-docs

You can file an issue or a pull request there. If the matter needs to be 
discussed first, the right place is here on the devel mailing list.


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

Re: Reasons to subscribe to the package-announce list?

[Otto Urpelainen]

Otto Urpelainen kirjoitti 11.10.2021 klo 21.45:

Kevin Fenzi kirjoitti 10.10.2021 klo 23.49:

On Sun, Oct 10, 2021 at 02:14:06PM +0300, Otto Urpelainen wrote:

Hello,

Package Maintainer Docs currently recommend joining the package-announce
mailing list in two places [1,2], describing it as follows:


You should also consider joining the package-announce mailing list — 
The commits mailing list gets notifications on all commits in any
package in the Fedora repository. This is a very high traffic mailing
list. The Fedora package database sends commit mails for packages you
(co-)maintain.


Odd. thats... not the right description. Thats the description for the
scm-commits list?

package-announce gets updates announcements of all the packages going to
stable updates through bodhi.


Thank you for this information. This explains why I saw only Bodhi 
updates in the package-announce archives.


I wonder, would it be better to drop this recommendation? Instead, it 
could

be recommended to go to Package Sources and adjust the Watch setting for
individual packages as needed? The paragraph quoted above is already 
kind of

recommending that approach in the last sentence.

What are the use cases where subscribing to the package-announce mailing
list is better than watching individual packages? Are the use cases 
common

enough that the mailing list deserves to be called "important" and be
recommended for everybody interested in Fedora packaging?


Yes, I think it might be worth mentioning these lists, but not
reccomending subscribing unless interested. Something like:

There are some completely optional lists that contain posts about all
packages: scm-commits, which has the commits for every package in fedora
posted to it, and package-announce, which has every stable update notice
posted to it as packages are pushed stable. Both of these are very high
traffic mailing lists and are only suggested if you have the time and
energy to watch all the changes going on in fedora packages.

Or something like that.


Sure, making people aware of all the tooling that is available is good. 
But the volume of messages in those lists is so large that I cannot 
believe it is a good idea to subscribe, unless some kind of automatic 
processing is implemented.


So, I am no thinking of keeping the list of important mailing lists 
really short, but the modify the "Find software you wish to 
package/maintain for Fedora" a bit. It now starts from the assumption 
that each new maintainer is going to add their very own package. Since 
it is also useful to help out with the existing ones, that section could 
also explain how to get notifications from interesting packages. There, 
both the Watch setting at Package Sources and these mailing lists can be 
discussed.


Here is a try at implementing these ideas:

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

Re: Reasons to subscribe to the package-announce list?

[Otto Urpelainen]

Kevin Fenzi kirjoitti 10.10.2021 klo 23.49:

On Sun, Oct 10, 2021 at 02:14:06PM +0300, Otto Urpelainen wrote:

Hello,

Package Maintainer Docs currently recommend joining the package-announce
mailing list in two places [1,2], describing it as follows:


You should also consider joining the package-announce mailing list — 
The commits mailing list gets notifications on all commits in any
package in the Fedora repository. This is a very high traffic mailing
list. The Fedora package database sends commit mails for packages you
(co-)maintain.


Odd. thats... not the right description. Thats the description for the
scm-commits list?

package-announce gets updates announcements of all the packages going to
stable updates through bodhi.


Thank you for this information. This explains why I saw only Bodhi 
updates in the package-announce archives.



I wonder, would it be better to drop this recommendation? Instead, it could
be recommended to go to Package Sources and adjust the Watch setting for
individual packages as needed? The paragraph quoted above is already kind of
recommending that approach in the last sentence.

What are the use cases where subscribing to the package-announce mailing
list is better than watching individual packages? Are the use cases common
enough that the mailing list deserves to be called "important" and be
recommended for everybody interested in Fedora packaging?


Yes, I think it might be worth mentioning these lists, but not
reccomending subscribing unless interested. Something like:

There are some completely optional lists that contain posts about all
packages: scm-commits, which has the commits for every package in fedora
posted to it, and package-announce, which has every stable update notice
posted to it as packages are pushed stable. Both of these are very high
traffic mailing lists and are only suggested if you have the time and
energy to watch all the changes going on in fedora packages.

Or something like that.


Sure, making people aware of all the tooling that is available is good. 
But the volume of messages in those lists is so large that I cannot 
believe it is a good idea to subscribe, unless some kind of automatic 
processing is implemented.


So, I am no thinking of keeping the list of important mailing lists 
really short, but the modify the "Find software you wish to 
package/maintain for Fedora" a bit. It now starts from the assumption 
that each new maintainer is going to add their very own package. Since 
it is also useful to help out with the existing ones, that section could 
also explain how to get notifications from interesting packages. There, 
both the Watch setting at Package Sources and these mailing lists can be 
discussed.


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

Reasons to subscribe to the package-announce list?

[Otto Urpelainen]

Hello,

Package Maintainer Docs currently recommend joining the package-announce 
mailing list in two places [1,2], describing it as follows:


> You should also consider joining the package-announce mailing list — 
> The commits mailing list gets notifications on all commits in any
> package in the Fedora repository. This is a very high traffic mailing
> list. The Fedora package database sends commit mails for packages you
> (co-)maintain.

I wonder, would it be better to drop this recommendation? Instead, it 
could be recommended to go to Package Sources and adjust the Watch 
setting for individual packages as needed? The paragraph quoted above is 
already kind of recommending that approach in the last sentence.


What are the use cases where subscribing to the package-announce mailing 
list is better than watching individual packages? Are the use cases 
common enough that the mailing list deserves to be called "important" 
and be recommended for everybody interested in Fedora packaging?


Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/#important_mailing_lists
[2]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#join_the_important_mailing_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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

[Otto Urpelainen]

Vít Ondruch kirjoitti 6.10.2021 klo 10.51:


Dne 06. 10. 21 v 7:35 Otto Urpelainen napsal(a):

Stephen Snow kirjoitti 5.10.2021 klo 15.39:

we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about
the
result.

However, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:

1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR ;)


I like this approach, but I was also thinking of a small tutorial/app
to actually package a piece of software as required, going through the
various steps but be a "fake" package that is only used to teach and
test with. This app could record the FAS user ID and assign a badge to
it once they complete the tutorial successfully. Sort of a base
starting point for all new packagersd that give both them some
confidence going in and the sponsors some confidence too about the
level of the new committers capabilities.


Well, in the Quick Docs, we already have Creating RPM packages [1]. It 
has subpage "Publishing your software on Copr", which somehow covers 
the publishing aspect. But honestly, when I was starting out, I spent 
some time with those instructions, but could not understand them or 
complete the tutorials. So one thing would be to revisit these 
instructions and make the better — there is a task about moving them 
over to Package Maintainer Docs [2], it was in progress at some point, 
but apparently stalled now. After that, improvement could happen.


About every packager publishing their own test package, in Copr that 
can be done for sure. If it is deemed too far from the official Fedora 
repositories, the perhaps it could be done in staging. I have never 
really used it, I cannot say if that is a good idea or not.


A similar but different idea I have is to create a "Fedora Packaging 
Guidelines Web Course" that you can complete by yourself. It could be 
implemented as a Git repository. For each entry in the the Review 
Guidelines [3], there would be a directory with a specfile and a srpm. 
For simplicity, we could first implement cases which fedora-review can 
check automatically. The student's assignment would be to run 
fedora-review on the specfile, find the error it gives, refer to the 
Packaging Guidelines to figure out how to fix it, modify the specfile 
as needed and run fedora-review again to check their answer. The 
assignment is completed when fedora-review does not complain any more.


Later, the course could be expanded also to cases where there is no 
automated check available, either by involving a mentor, or simply by 
adding a SOLUTION file.


Awarding a badge for completing this course would be a good idea, if a 
technical solution can be found.


I see this course as complementary to Vít's original proposal about 
the onboarding package. The orboarding package tasks are about 
learning the build system, certainly a required skill for packages. 
The course is about learning the Guidelines. Currently the recommended 
method to do that is to submit inofficial reviews to live Review 
Requests. That has the advantage of exposing the applicant to real 
packages with real problems, but 1) has no guarantee of producing an 
effective learning path, the package that is picked may well be a very 
tricky case and thus unsuitable for starting out and 2) is 
psychologically unsafe, because a total newcomer must participate in 
discussion of two experts who are actually trying to get a package 
into Fedora, not educating the packagers.



Just FTR, I like these ideas. Nevertheless, as with every idea, they 
need to be implemented and maintained. Therefore, from the experience, I 
think that onboarding package could survive longer, because it 
(hopefully) needs less maintenance.


It is a valid concern. The onboarding package is just a single package, 
whereas if the would be N assignments, there would be also N specfiles 
to maintain as the guidelines change. Starting from the sections that 
are the least probable to change would help.


Also note that I did not intend to propose to do something like this 
instead of the onboarding package, which is a good idea. Rather, this 
could be done in addition to that, and serves a different need.


If there is another way, requiring less maintenance work, that allows 
learning how to apply the Packaging Guidelines, even better. It is just 
that the the current method of "just read the Guidelines" is too 
theoretical, and "comment on live reviews" is too hands-on.


Otto
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le

Re: Onboarding package

[Otto Urpelainen]

Stephen Snow kirjoitti 5.10.2021 klo 15.39:

we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about
the
result.

However, discussing this back and forth, we figured that it might
also
where new coming package maintainer could gradually gain experience
with
the packaging workflows. So the simplest tasks could be:

1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively
this
current Fedora contributors might be interested to send such PR ;)


I like this approach, but I was also thinking of a small tutorial/app
to actually package a piece of software as required, going through the
various steps but be a "fake" package that is only used to teach and
test with. This app could record the FAS user ID and assign a badge to
it once they complete the tutorial successfully. Sort of a base
starting point for all new packagersd that give both them some
confidence going in and the sponsors some confidence too about the
level of the new committers capabilities.


Well, in the Quick Docs, we already have Creating RPM packages [1]. It 
has subpage "Publishing your software on Copr", which somehow covers the 
publishing aspect. But honestly, when I was starting out, I spent some 
time with those instructions, but could not understand them or complete 
the tutorials. So one thing would be to revisit these instructions and 
make the better — there is a task about moving them over to Package 
Maintainer Docs [2], it was in progress at some point, but apparently 
stalled now. After that, improvement could happen.


About every packager publishing their own test package, in Copr that can 
be done for sure. If it is deemed too far from the official Fedora 
repositories, the perhaps it could be done in staging. I have never 
really used it, I cannot say if that is a good idea or not.


A similar but different idea I have is to create a "Fedora Packaging 
Guidelines Web Course" that you can complete by yourself. It could be 
implemented as a Git repository. For each entry in the the Review 
Guidelines [3], there would be a directory with a specfile and a srpm. 
For simplicity, we could first implement cases which fedora-review can 
check automatically. The student's assignment would be to run 
fedora-review on the specfile, find the error it gives, refer to the 
Packaging Guidelines to figure out how to fix it, modify the specfile as 
needed and run fedora-review again to check their answer. The assignment 
is completed when fedora-review does not complain any more.


Later, the course could be expanded also to cases where there is no 
automated check available, either by involving a mentor, or simply by 
adding a SOLUTION file.


Awarding a badge for completing this course would be a good idea, if a 
technical solution can be found.


I see this course as complementary to Vít's original proposal about the 
onboarding package. The orboarding package tasks are about learning the 
build system, certainly a required skill for packages. The course is 
about learning the Guidelines. Currently the recommended method to do 
that is to submit inofficial reviews to live Review Requests. That has 
the advantage of exposing the applicant to real packages with real 
problems, but 1) has no guarantee of producing an effective learning 
path, the package that is picked may well be a very tricky case and thus 
unsuitable for starting out and 2) is psychologically unsafe, because a 
total newcomer must participate in discussion of two experts who are 
actually trying to get a package into Fedora, not educating the packagers.


[1]: https://docs.fedoraproject.org/en-US/quick-docs/creating-rpm-packages/
[2]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/19
[3]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process



packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.

This could be extended in the future. E.g. next step could be:

3) Submit module update.

Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring
guidelines
could be refreshed suggesting/requesting to take these steps at some
point.

Thoughts?


Personnaly I am for this type of approach since it is also clarifying
the roles a bit more too. It wouldn't hurt to outline what is expected
of a packager of Fedora Linux in general. You know expectations are
very often left unsaid thinking that roles and responsibilities fill in
the info, but that is not always the case.


Are you aware of the page "Package maintainer responsibilities" [4]? Is 
there some aspects of the responsibilities that are not covered there?


[4]: 
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/

Re: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)

[Otto Urpelainen]

Robert-André Mauchin kirjoitti 2.10.2021 klo 19.02:

On 7/19/21 18:17, Ben Cotton wrote:

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

== Summary == PipeWire currently uses a simple example session
manager. This proposal is to move to the more powerful WirePlumber
session manager.

== Owner == * Name: [[User:Wtaymans| Wim Taymans]] * Email:
wim.taym...@gmail.com

== Detailed Description == PipeWire requires a session manager that
at least needs to implements the following features:

* create and configure detected devices in the system. This includes 
audio cards, video and bluetooth devices. * configure applications

and route audio/video to/from them to the devices and filters. * keep
track of prefered devices and volumes. * move audio/video streams
when devices appear and disappear.

PipeWire uses a simple example session manager with limited features 
and configuration options. The proposal is to move to WirePlumber.


WirePlumber is built on GNOME (GObject) technologies and has
bindings for most languages using GObject introspection.

WirePlumber allows one to implement many of the rules for setup and 
configuration using small LUA scripts, which are easier to maintain

and customize. These are some of the functions that are scriptable in
LUA:

* setup and configuration of the devices and streams. This includes 
deciding if devices and streams need to operate in 5.1 or stereo

mode, depending on the available devices. * routing of the streams
based on metadata of the streams (Roles) and overall state of the
system. * volume/mute restore of devices and streams


== Benefit to Fedora ==

PipeWire currently uses a simple example session manager with mostly 
hardcoded logic and rules. This proposal wants to replace the

session manager with a more advanced session manager, called
WirePlumber.

WirePlumber brings to following improvements

* Drop-in replacement session manager for PipeWire, implements the 
exact same features as the example session manager * built with

GObject, which provides a richer development experience and adds
bindings for most languages * extensible with loadable modules *
scriptable policy using small lua scripts * better integration with
desktop settings

The main benefits will be that this session manager would allow for 
more customization of the policy and rules. Initially we aim for

feature parity with the current solution and work on more features in
the next releases.

== Scope == * Proposal owners: This is a rather isolated changed.
Instead of starting the pipewire-media-session executable we would
need to package and start WirePlumber instead.

WirePlumber has been kept up to data with the features in the
example session manager and would need testing.

* Other developers: None. This is an isolated PipeWire change. *
Release engineering: A new systemd service will need to be activated 
in the default install. * Policies and guidelines: N/A (not needed

for this Change) * Trademark approval: N/A (not needed for this
Change) * Alignment with Objectives:

== Upgrade/compatibility impact == Should not cause any change.

== How To Test ==

Experience should be the same as before. Retest all audio testcases.


== User Experience == Should not cause any visible change.


== Dependencies == None.

== Contingency Plan == * Contingency mechanism: (What to do?  Who
will do it?): If the feature can not be completed we continue using
the existing pipewire-media-session. * Contingency deadline: N/A (not
a System Wide Change) * Blocks release? N/A (not a System Wide
Change)


== Documentation == 
[WirePlumber](https://gitlab.freedesktop.org/pipewire/wireplumber)





Just switched to F35 beta, no sound card was detected, I had to get back
to pipewire-media-session to get sound again.


Problems here as well.

I am affected by the inability to change systems sounds volume, as 
already reported in this thread.


Additionally, opening certain Matroska videos with VLC suffer from about 
20 second delay before starting to play. The problem disappears if I 
revert back to pipewire-media-session and reboot.


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

Re: Changes to Bugzilla query limits

[Otto Urpelainen]

Ben Cotton kirjoitti 29.9.2021 klo 23.41:

On Fri, Sep 17, 2021 at 11:05 AM Miro Hrončok  wrote:


What bothers me as well is that this appears to have been communicated trough
internal channels only.


The manager of that team told me that future announcements will be
sent to the bugzilla-announce-list[1], which is public. It was an
oversight that it didn't get sent this time.


Is that really the correct list? The last message I see in the archives 
of that list is from 2020-May, announcing 5.0.4-rh44, the original Open 
Source Red Hat Bugzilla. Latest release is -rh62. I would have expected 
to see all the releases announced there, plus maybe some other things 
not tied to releases.



I've submitted a PR[2] to
add this to the package maintainer docs.


Thanks!

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

Re: Package Update Guide: Updating inter-dependent packages

[Otto Urpelainen]

I logged an issue about this for the Package Maintainer Docs [1].
Similarly to all other other issues in that list,
I intend to do something about this at some point,
unless somebody else beats me to it.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/33

Otto

Miro Hrončok kirjoitti 23.9.2021 klo 12.29:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages 



Says:

"""
You may need a buildroot override to complete a multi-package update 
successfully. For instance in the case described above, you may need to 
rebuild bar against the new libfoo package and submit both packages 
together as a multi-package update. However, in the normal course of 
events, you would not be able to build another package against your new 
libfoo build until it reached the stable state. To resolve this dilemma, 
you can request a buildroot override, which causes the libfoo build to 
be included in the buildroot for a short time in order to get the bar 
package build done.

"""

However, I think side-tags should be the preferred solution, as their 
impact is isolated. Buildroot overrides create temporary broken 
dependencies for everybody, while side-tags don't.


My understanding was that this is the de-facto consensus, so I'd lie to 
update the docs to say something like:


"""
You may need to build the inter-dependent packages in a side tag.
For instance in the case described above, you may need to rebuild bar 
against the new libfoo package and submit both packages together as a 
multi-package update. However, in the normal course of events, you would 
not be able to build another package against your new libfoo build until 
it reached the stable state. To resolve this dilemma, you can request a 
side tag and build both packages in it, which causes the libfoo build to 
be included in the bar build's buildroot.

"""

And than instead of describing the details, link to 
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/


Any suggestions or objections?


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

Re: Package Update Guide: Updating inter-dependent packages

[Otto Urpelainen]

Vít Ondruch kirjoitti 24.9.2021 klo 11.13:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages 



Shouldn't it be somehow aligned with this ^^ chapter? Maybe the chapter 
should be referenced at least, because it explains how to request the 
side tag.


The difference between these two sections is that one is under "Rawhide 
and early branched", the other "Later Branched and stable releases". 
Currently, one prescribes a side tag and the other, a buildroot 
override. Probably one could just refer to the other, or both refer to 
another place.


Pointing to the Rawhide Gating page for instructions is fine, but I 
wonder would it actually be better to do it the other way, describe the 
process correctly in Package Maintainer Docs and link there from the 
Rawhide Gating page, which, judging from its title, has quite narrow scope.


There is also the page "Using the Koji build system" [1] which 
recommends yet another solution: section "Chained builds". What about 
those, what are they useful for?


Otto

[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/



Dne 23. 09. 21 v 11:29 Miro Hrončok napsal(a):
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#updating_inter_dependent_packages 



Says:

"""
You may need a buildroot override to complete a multi-package update 
successfully. For instance in the case described above, you may need 
to rebuild bar against the new libfoo package and submit both packages 
together as a multi-package update. However, in the normal course of 
events, you would not be able to build another package against your 
new libfoo build until it reached the stable state. To resolve this 
dilemma, you can request a buildroot override, which causes the libfoo 
build to be included in the buildroot for a short time in order to get 
the bar package build done.

"""

However, I think side-tags should be the preferred solution, as their 
impact is isolated. Buildroot overrides create temporary broken 
dependencies for everybody, while side-tags don't.


My understanding was that this is the de-facto consensus, so I'd lie 
to update the docs to say something like:


"""
You may need to build the inter-dependent packages in a side tag.
For instance in the case described above, you may need to rebuild bar 
against the new libfoo package and submit both packages together as a 
multi-package update. However, in the normal course of events, you 
would not be able to build another package against your new libfoo 
build until it reached the stable state. To resolve this dilemma, you 
can request a side tag and build both packages in it, which causes the 
libfoo build to be included in the bar build's buildroot.

"""

And than instead of describing the details, link to 
https://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/


Any suggestions or objections?


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

Re: Mangling shebangs in text files: How to detect them, bug in the current implementation and possible solutions

[Otto Urpelainen]

Steve Grubb kirjoitti 23.9.2021 klo 18.15:

On Wednesday, September 22, 2021 5:34:17 PM EDT Miro Hrončok wrote:

 From all the scan that we've done on fullish installs in the past,
there's
only 2 others that you might run across: application/x-elc (lisp) and
application/x-java-applet.

Maybe you just build in logic to workaround these 3 types? application/
javascript is really the only one I can think of that is common.


Yeah, maybe we should just do that. However, that would not cleanup the
executable pngs.


They should be easy to identify, they start with 'image'. There's not many
types on a typical system. This is what I see in /usr on a system with 5000
packages installed:

application/gzip
application/javascript
application/json
application/octet-stream
application/vnd.ms-fontobject
application/x-bad-elf
application/x-executable
application/x-kdelnk
application/x-sharedlib
application/zip
audio/ogg
font/sfnt
image/gif
image/jpeg
image/png
image/vnd.microsoft.icon
text/html
text/plain
text/x-awk
text/x-c
text/x-gawk
text/x-lua
text/x-luatex
text/x-perl
text/x-python
text/x-ruby
text/x-shellscript
text/x-systemtap
text/x-tcl

You might just make a map since the list is not all that big. The biggest
issue is when you have things text/plain or application/octet-stream. That
means we don't know what it is.


What about keeping the "detect mime type" approach, then dividing the 
results into three categories?


1. Can be executable, if so, must have a shebang, which is mangled: 
text/* is already there, add application/javascript and possibly others 
as needed.
2. Cannot be executable, remote the executable bit if found: image/* 
would take care of the executable pngs, many more like application/json 
can be added as needed.

3. The rest: do nothing with these.

Maybe that would be good enough, even if the mime type detection 
uncertainty sets a limit on how precise it can be?


Keeping the mime type detection approach, but using less data (the first 
8 bytes approach) does not sound good. If 'file' really works better 
that way, then there is something wrong with it.


As for the application/javascript type, there is an IETF proposal that, 
among other things, tries to deprecate that and de-deprecate 
text/javascript [1]. So, perhaps some day category 1 could be reasonably 
equated with text/* again.


[1]: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs

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

Re: Orphaned packages looking for new maintainers

[Otto Urpelainen]

Jonathan Schleifer kirjoitti 20.9.2021 klo 19.16:

Am 20.09.21 um 13:31 schrieb Miro Hrončok:

0ad  ignatenkobrain, orphan, pwalter   1 
weeks ago


Also, how is the flatpak package handled? I know how it works for RPM, 
but flatpak's all new to me and I see there's also a flatpak for 0ad.


The thing that is orphaned is the rpm package at 
src.fedoraproject.org/rpms [1]. Flatpaks live at 
src.fedoraproject.org/flatpaks. The 0ad flatpak there has not been 
orphaned [2].


I do not know much about the flatpak build process in Fedora, but 
perhaps the Flatpak section at docs.fedoraproject.org is helpful if you 
want to know more about it [3]?


[1]: https://src.fedoraproject.org/rpms/0ad
[2]: https://src.fedoraproject.org/flatpaks/0ad
[3]: https://docs.fedoraproject.org/en-US/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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packaging guidelines - clarification required - Users and Groups

[Otto Urpelainen]

Vít Ondruch kirjoitti 17.9.2021 klo 13.11:


Dne 16. 09. 21 v 16:01 Michal Schorm napsal(a):

Hello,
I seek a clarification on the "Users and Groups Guidelines" [1]
chapter of the "Fedora Packaging Guidelines" [2]

Please note I want such case to be clear to newcomers too.
While I am an experienced packager who has a fair idea how to navigate
in Fedora documentation, the same issue might be very confusing to the
packaging beginners among us.

--

During an attempt to update packages I maintain to match the Fedora
Packaging Guidelines, I encountered two different documents, from
which I cannot decide the correct one.
One is the (for me obviously) old [3] Guidelines page on the Wiki, but
it is NOT marked as obsolete, with the new guidelines ( I assume [1] )
linked, at the beginning of the document.



I think Otto has pointed the same issue here:

https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/Z4XX3RQMXXY4UY4G663HLNV2DOMIVT3N/ 



Probably wort of opening ticket at

https://pagure.io/packaging-committee/issues


Yes, I did.
Turns out there already is an issue about this:

https://pagure.io/packaging-committee/issue/1050

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

Re: License of mpir package simplified to LGPLv3+

[Otto Urpelainen]

Benjamin Beasley kirjoitti 8.9.2021 klo 22.07:

The license for the mpir package has been simplified from “LGPLv3+ and LGPLv2+ 
and (LGPLv3+ or GPLv2+) and BSD” back to the effective license of “LGPLv3+”.

See also 
https://fedoraproject.org/wiki/Licensing:FAQ#What_is_.22effective_license.22_and_do_I_need_to_know_that_for_the_License:_tag.3F.
 While not strictly required when there is a single effective license, a 
breakdown of the exact licenses for various source files is still included.


I have followed several discussions about effective licensing already, 
but I still do not understand it. I apologize for asking a question that 
has most probably been asked and answered many times already, but there 
really is something I do not understand here.


I do understand that the various GNU license here can be combined into 
just LGPLv3+. But what happened to the following clause from the BSD 
license?


> 2. Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in the 
documentation and/or other materials provided with the distribution.


Was that condition somehow erased because the BSD source was compiled 
together with other source? I have hard time believing it did.


Or does the License tag encode only some subset of the binary's 
licensing conditions? If so, it cannot be used to determine what you are 
allowed and not allowed to do with the binary. What is the intended use 
of the License tag then?


I would like to have that explained in the FAQ. Even better, the 
licensing guidelines [1] should have explanation of this, or a link to 
the wiki pages that have licensing related rules and guidance.


Otto

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

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[Otto Urpelainen]

Solomon Peachy kirjoitti 7.9.2021 klo 23.25:

On 07.09.2021 18:14, Miroslav Suchý wrote:

System 7  (Special Snowflake Fedora 33 server)

   This one is really bad, with pretty much anything relying on PHP
   breaking.  (Problem 1 is a local site package that just needs rebuilding
   for F35's perl stuff)

   - package php-imap-7.4.23-1.fc33.x86_64 requires php-common(x86-64) = 
7.4.23-1.fc33, but none of the providers can be installed


This line repeats a lot in your output. I think you will get forward 
with this if you figure out what happened to php-imap in Fedora 34 and, 
whatever that was, how to recover from it.


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

Re: Donate 1 minute of your time to test upgrades from F34 to F35

[Otto Urpelainen]

Miroslav Suchý kirjoitti 7.9.2021 klo 19.14:


sudo dnf --releasever=35 --setopt=module_platform_id=platform:f35 \

--enablerepo=updates-testing --enablerepo=updates-testing-modular \

distro-sync


Error:
 Problem 1: package arduino-core-1:1.8.13-5.fc34.noarch requires 
mvn(org.ow2.asm:asm-all), but none of the providers can be installed
  - objectweb-asm-8.0.1-2.fc34.noarch does not belong to a distupgrade 
repository

  - problem with installed package arduino-core-1:1.8.13-5.fc34.noarch

Already reported:
https://bugzilla.redhat.com/show_bug.cgi?id=2001333

Problem 3: problem with installed package gnuradio-3.9.0.0-5.fc34.x86_64
  - package gnuradio-3.9.2.0-5.fc35.x86_64 requires 
libcodec2.so.0.9()(64bit), but none of the providers can be installed
  - gnuradio-3.9.0.0-5.fc34.x86_64 does not belong to a distupgrade 
repository

  - codec2-0.9.2-7.fc34.x86_64 does not belong to a distupgrade repository

This is already discussed in this thread, but was not in Bugzilla, so I 
reported it there:

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

Problem 4: problem with installed package gqrx-2.14.4-1.fc34.x86_64
  - package gqrx-2.14.4-5.fc35.x86_64 requires 
libboost_thread.so.1.75.0()(64bit), but none of the providers can be 
installed

  - gqrx-2.14.4-1.fc34.x86_64 does not belong to a distupgrade repository
  - boost-thread-1.75.0-4.fc34.x86_64 does not belong to a distupgrade 
repository


Reported twice already:
https://bugzilla.redhat.com/show_bug.cgi?id=1991876
https://bugzilla.redhat.com/show_bug.cgi?id=2002104

 Problem 5: package postgresql-server-devel-13.4-1.fc35.x86_64 requires 
postgresql-private-devel, but none of the providers can be installed
  - package postgresql-private-devel-13.4-1.fc35.i686 conflicts with 
libpq-devel provided by libpq-devel-13.4-1.fc35.x86_64
  - package postgresql-private-devel-13.4-1.fc35.x86_64 conflicts with 
libpq-devel provided by libpq-devel-13.4-1.fc35.x86_64
  - problem with installed package 
postgresql-server-devel-13.4-1.fc34.x86_64

  - problem with installed package libpq-devel-13.4-1.fc34.x86_64
  - postgresql-server-devel-13.4-1.fc34.x86_64 does not belong to a 
distupgrade repository
  - libpq-devel-13.4-1.fc34.x86_64 does not belong to a distupgrade 
repository
  - package 
postgresql-private-devel-13.4-1.module_f35+12619+a275bc38.x86_64 is 
filtered out by modular filtering


This is apparently a case where the user just has to pick one or the other:
https://src.fedoraproject.org/rpms/postgresql/blob/f35/f/postgresql.spec#_215
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package Maintainer Docs published

[Otto Urpelainen]

Vít Ondruch kirjoitti 31.8.2021 klo 11.43:


Dne 31. 08. 21 v 7:39 Otto Urpelainen napsal(a):

Greetings,

Some months ago, I announced [0] that I will move the package 
maintainer docs from wiki to docs.fedoraproject.org.



Thx a lot.



All changes to the documentation is intended to happen through pull
requests. However, following the spirit of earlier wiki based
documentation, the documentation is intended to be maintainer
collectively by all Fedora packagers.

Due to technical issues, the packager group from Fedora Account
System cannot be granted access, so there is a separate group
package-maintainer-docs with commit access. Membership is granted to
any packager requesting it. Please file an issue in the repository if
you want to join.




Everybody whose PR was accepted should get commit bit IMO. 


So you mean that even people not in the 'packager' group would be 
granted access after they have one accepted PR? Sounds reasonable, there 
is still some minimal barrier of entry to block spam and such, and would 
help getting the parts that are relevant to new contributors fixed.


Also, it 
would probably help it there was explained how to get some attention if 
nobody responds to PR.


Yes, this is needed. Perhaps something like this: If your pull request 
is simple and you have commit rights, just merge it. If you do not have 
commit rights, or the change is not simple and really would need a 
review, notify people marked as repo admins by mentioning them in a 
comment. If that does not lead anywhere, complain in the devel list.


I suppose direct commits for trivial changes like typo fixes and broken 
links could be recommended, too.


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

Package Maintainer Docs published

[Otto Urpelainen]

Greetings,

Some months ago, I announced [0] that I will move the package maintainer 
docs from wiki to docs.fedoraproject.org. I am happy to announce that 
this task is complete and the docs are public in their new location now 
[1]. Hopefully, this will allow existing and new packagers to find 
relevant documentation more easily, and foster more concentrated efforts 
to make it better.


Let me explain how the docs are set up now. I worked mainly alone to get 
the actual move done. From this point on, I hope that maintenance is 
done by all package maintainers collectively, similarly to how the wiki 
documentation was under shared ownership. This also means that 
everything here is a draft, open for changes based on your feedback. 
Comments are welcome!


The imported content was selected by going through wiki category Package 
Maintainers [2] and choosing the pages that seemed useful. In general, 
the pages were imported without modification, however in some cases 
there were such serious issues that I did some editing.


Going forward, documentation for package maintainers should be added to 
this repo, instead of wiki. There is an issue for replacing the imported 
wiki pages with pointers to the new urls [3] which will be done soon. 
Policies, guidelines and other material owned by FESCo or the Packaging 
Committee is excluded from this repository and is handled like before.


One change that moving from wiki to a Git repository at pagure.io brings 
is access control. I would like to allow all members of the 'packager' 
group, but unfortunately that group is not visible at pagure.io. So 
instead I wrote this in the README, to serve as a basis for iterating a 
good solution:



All changes to the documentation is intended to happen through pull
requests. However, following the spirit of earlier wiki based
documentation, the documentation is intended to be maintainer
collectively by all Fedora packagers.

Due to technical issues, the packager group from Fedora Account
System cannot be granted access, so there is a separate group
package-maintainer-docs with commit access. Membership is granted to
any packager requesting it. Please file an issue in the repository if
you want to join.


If you have any interest in the docs at all, I hope you file an issue 
for membership, or just reply to this mail and I will add you.


Currently, I am the maintainer of the repository. There are four other 
people listed as admins: pingou, mattdm, kevin, codeblock. This list of 
a leftover from an older, unpublished iteration of the docs. To my 
understanding, none of these people have expressed interest in 
maintaining the repository, for whatever tasks there may be that cannot 
be handled by the committer group. So, I plan to remove everybody but 
myself. Naturally, to avoid non-responsive admins situation, there 
should be more than one admin. If you are interested, please let me know 
an I will add you.


Otto

[0]: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4UPDUFVHULLELBKSOYJ233WU3E4BCGYI/

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

fedpkg 1.41: write build results to a subdirectory

[Otto Urpelainen]

Hello,

New releases of rpkg and fedpkg are now in testing [1]. There are many 
improvements included, of which I would like to point out "Add config 
option for writing dist-git build results to a subdirectory" [2] because 
it is not enabled by default, at least not yet.


The new feature is enabled by setting "results_dir = subdir" in fedpkg 
config. After that is done, fedpkg sets 'rpm' command's builddir, 
srcrpmdir and rpmdir to 'results' instead of the default repository 
root. So if find it annoying how fedpkg writes it output files directly 
to repository root, now there is way to do less of that. Output of 
'fedpkg mockbuild', which does not invoke 'rpm' directly, is not affected.


Unfortunately, sources are still downloaded to repository root. There 
was some hurdle I cannot quite remember anymore that prevented using 
'results' as sourcedir as well.


Otto

[1]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-55652a7b38
[2]: https://pagure.io/rpkg/pull-request/540
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packager docs on docs.fp.o (Was: Re: New maintainer experience)

[Otto Urpelainen]

Ankur Sinha kirjoitti 21.8.2021 klo 11.56:




For some time already, I have all of the package maintainer docs already
rewritten and improved at package-maintainer-docs [1], with the intent to
keep improving them. They remain unpublished because, despite my pleas, the
main docs page maintainers keep ignoring two oneliner pull requests to
publish them [2,3].

For cases like this., Fedora would need something like the Nonreponsive
Package Maintainer Process for non-package repositories too.


[1]: https://pagure.io/fedora-docs/package-maintainer-docs
[2]: https://pagure.io/fedora-docs/docs-fp-o/pull-request/171
[3]: https://pagure.io/fedora-docs/pages/pull-request/14#request_diff


Thanks for working on these.

I've tagged @pbokoc and @bcotton there who may have the necessary
permissions (and know-how) to merge the PRs.


Thanks!


I don't think having a non-responsive maintainer policy works quite as
well for such repos.


Sure, the cases are different. What I meant is that for packaging 
related issues there is a standard way to escalate issues, defined in 
that policy, and just following that path will get the issue eventually 
resolved. For issues not related to packaging, it is not what is the 
appropriate next step if nothing you tried before helped.



We need to encourage more folks to join the docs
team to help out so there is enough human-power there (something we have
to do for all teams/SIGs in Fedora in general).


Certainly, having things running in such a way that pull requests are 
processed fast is better than having policies to handle cases where they 
are not!

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

Re: New maintainer experience

[Otto Urpelainen]

Kevin Fenzi kirjoitti 20.8.2021 klo 22.32:

On Thu, Aug 19, 2021 at 11:03:27PM +0200, Iago Rubio wrote:

On Wed, 2021-08-18 at 08:56 -0700, Kevin Fenzi wrote:

On Wed, Aug 18, 2021 at 08:15:36PM +0700, Didik Supriadi wrote:

I think ppl now can go to
https://packager-dashboard.fedoraproject.org/user/orphan to see
orphaned
packages.


IMHO, we should not point people to this list.y


Then I messed it up by editing the Wiki.

Should I revert the Wiki to the non-working orphans page ?


No, I don't know that we have any kind of consensus on this, that was
just my opinion.


Sure, there are dragons in the orphaned packages list. But the wiki page 
with that link also has the appropriate warning:


> Claiming Ownership of a Retired Package
>
> If you really want to maintain a retired package, you need to be aware
> that if upstream is dead, fixing release critical bugs, etc becomes
> your responsibility. This is to ensure the high quality and standards
> of packaging remain for Fedora package collection. There may be
> additional issues with retired packages. If possible, consult with the
> former maintainer for more information.

There are also ideal candidates for helping out, useful and almost 
functional packages orphaned simply because the previous maintainer does 
not need them anymore or like that.


This could be further improved by more structured listing of possible 
paths into joining packages, adopting an orphaned package being one of 
them. The sensible safety checks could be described there.



For some time already, I have all of the package maintainer docs already 
rewritten and improved at package-maintainer-docs [1], with the intent 
to keep improving them. They remain unpublished because, despite my 
pleas, the main docs page maintainers keep ignoring two oneliner pull 
requests to publish them [2,3].


For cases like this., Fedora would need something like the Nonreponsive 
Package Maintainer Process for non-package repositories too.



[1]: https://pagure.io/fedora-docs/package-maintainer-docs
[2]: https://pagure.io/fedora-docs/docs-fp-o/pull-request/171
[3]: https://pagure.io/fedora-docs/pages/pull-request/14#request_diff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New maintainer experience

[Otto Urpelainen]

Iago Rubio kirjoitti 20.8.2021 klo 0.03:


[iago@rawhide]$ dnf repoquery --releasever rawhide --whatrequires
"rarian*"
Last metadata expiration check: 0:00:26 ago on Thu 19 Aug 2021 10:34:56
PM CEST.
alleyoop-0:0.9.8-18.fc35.x86_64
etherape-0:0.9.18-8.fc35.x86_64
gnome-translate-0:0.99-39.fc35.x86_64
grhino-0:0.16.1-13.fc35.x86_64
mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64
pioneers-0:15.6-3.fc35.x86_64
rarian-compat-0:0.8.1-27.fc34.x86_64
rarian-devel-0:0.8.1-27.fc34.i686
rarian-devel-0:0.8.1-27.fc34.x86_64
ucview-0:0.33-21.fc35.i686
ucview-0:0.33-21.fc35.x86_64


If you use 'dnf repoquery --whatrequires' to find packages dependees, it 
is a good idea to to check also the source repositories, so you will not 
miss packages that only depend at build time:


$ sudo dnf --enablerepo='*source' repoquery --whatrequires 'rarian*'
Last metadata expiration check: 0:00:18 ago on Sat Aug 21 10:26:20 2021.
alleyoop-0:0.9.8-18.fc35.x86_64
bless-0:0.6.3-3.fc35.src
dia-1:0.97.3-18.fc35.src
etherape-0:0.9.18-8.fc35.src
etherape-0:0.9.18-8.fc35.x86_64
florence-0:0.6.3-15.fc35.src
gconf-editor-0:3.0.1-23.fc35.src
glade2-0:2.12.2-35.fc35.src
gnome-search-tool-0:3.6.0-20.fc35.src
gnome-translate-0:0.99-39.fc35.src
gnome-translate-0:0.99-39.fc35.x86_64
grhino-0:0.16.1-13.fc35.src
grhino-0:0.16.1-13.fc35.x86_64
gtk-v4l-0:0.4-22.fc35.src
ignuit-0:2.24.3-10.fc35.src
mail-notification-0:5.4-100.git.9ae8768.fc35.src
mail-notification-0:5.4-100.git.9ae8768.fc35.x86_64
mdbtools-0:0.9.3-2.fc35.src
moserial-0:3.0.16-2.fc35.src
pioneers-0:15.6-3.fc35.src
pioneers-0:15.6-3.fc35.x86_64
qalculate-gtk-0:3.20.1-1.fc35.src
quarry-0:0.2.0-31.fc35.src
rarian-compat-0:0.8.1-27.fc34.x86_64
rarian-devel-0:0.8.1-27.fc34.i686
rarian-devel-0:0.8.1-27.fc34.x86_64
stardict-0:3.0.6-17.fc35.src
ucview-0:0.33-21.fc35.i686
ucview-0:0.33-21.fc35.x86_64
viking-0:1.8-7.fc36.src
xiphos-0:4.2.1-11.fc35.src

See how there are some .src rpms that were missed by your query?

Depending on what you are trying to do, using --recursive as well may be 
a good idea.


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

Re: Specfile description and summary translations

[Otto Urpelainen]

Zbigniew Jędrzejewski-Szmek kirjoitti 18.8.2021 klo 12.06:

On Wed, Aug 18, 2021 at 08:57:39AM +0300, Otto Urpelainen wrote:

I have problems interpreting the following check from fedora-review:


[ ]: Description and summary sections in the package spec file

contains translations for supported Non-English languages, if
available.


My understanding is that this is about translations of %description
and Summary:

E.g. autofs has this:

Summary(de): autofs daemon



...
%description -l de
autofs ist ein Dämon, der Dateisysteme automatisch montiert, wenn sie
benutzt werden, und sie später bei Nichtbenutzung wieder demontiert.
Dies kann Netz-Dateisysteme, CD-ROMs, Disketten und ähnliches einschließen.


Yes, I also interpreted the check being about those. It was just unclear 
if "translation available" should be interpreted as having translated 
specfile summaries and/or descriptions specifically, or just some 
translated strings that would fit in there.



In one of the first package reviews I made, I recall suggesting
copying such translations from the desktop file which had many
suitable translations. In the end, this suggestion was not followed,
because a more experienced reviewer said that having translations in
desktop file is not what is meant by 'translations are available'
here — only an upstream specfile with translations would count.

I would like to update fedora-review as well as Review and Packaging
Guidelines to explain what is expected for these translations. For
that, I would need to understand the purpose of this check better.
Perhaps somebody here has some insight?


I'd propose dropping the check. I think it's fine to let people do
those translations, it is a LOT of work to do them for multiple languages
and to keep them updated as the original version changes.
And since this is only available only for a tiny subset of packages,
it's close to useless. (You'd need to know English anyway to read
most descriptions…).

If we wanted to invest in translations, (and this is a big if), I'd
try to do this as the level of appdata, so at least the graphical
installer can show translations. This would also let upstreams get
involved in the translations, instead of doing it at the level of the
distro. I assume people who don't speak English are more likely to use
the graphical installer too, since so many commands have English
options and output in English.


Unless further points are made for retaining this check (and 
consequently making the Packaging Guidelines stricter, so the check can 
refer to it), I will submit PRs to remove it from fedora-review and the 
Review Guidelines. In that case, it does not pay to discuss the correct 
interpretation of the details.


I have my system set to Finnish language and I really appreciate all the 
parts where that works. I do not appreciate the "Fin-glish" parts where 
I get mostly English with occasional translations here and there. So it 
should be a concentrated investment to get high translation count and 
quality. I am also afraid that for rpms, current tooling makes success 
impossible: nothing tracks when the main Summary is changed and flags 
translations as outdated, and any volunteer translator would have to 
endure a dist-git pull request workflow to contribute fixes.

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

Re: Fwd: A new version of "OCamlbuild" has been detected: "4.02.3" newer than "0.10.0", packaged as "ocaml-ocamlbuild"

[Otto Urpelainen]

Kevin Fenzi kirjoitti 18.8.2021 klo 18.52:

On Wed, Aug 18, 2021 at 09:20:46AM -0400, Ben Beasley wrote:

It looks like the project changed version schemes at some point. The 4.02.3 
release was in 2015, before 0.9.0; a long list of 4.x and 3.x releases preceded 
it.

I don’t see where it got 0.10.0 as the currently-packaged version; the actual 
bug (https://bugzilla.redhat.com/show_bug.cgi?id=1992935) correctly has 0.14.0.

On Wed, Aug 18, 2021, at 8:52 AM, Richard W.M. Jones wrote:

This seems to have failed in some way.  Firstly it says that we're
currently packaging 0.10.0, which is not true.  The latest version of
ocamlbuild (0.14.0) is packaged.  But more seriously it seems to have
found some imaginary version (4.02.3) and I can't even see where it
got that number from.


Can you file a issue at: https://github.com/fedora-infra/anitya/issues

Thats the application/project that does this.


If you look at the release-monitoring.org config for OCamlbuild [1], you 
see that is has "Version scheme: RPM", so yes, 4.02.3 is a latter 
release than 0.14.0 than that. A pre-release filter is used to flag 
those 3.x and 4.x releases, I do not know if pre-releases should produce 
notifications and Bugzillas or not.


One way to hide 3.x and 4.x would be to add those to "Version filter" 
instead, that would exclude them from the fetch completely. But since 
they have already been fetched, you would also need to "Flag" this 
project and ask an admin to remove the ones that have already been fetched.


I do not know if it is normal to send "new version" notifications when 
the version was out years ago. Perhaps this is related to the fact that 
in release-monitoring.org, 4.02.3 says "Retrieved on (UTC): Date 
information unavailable". That sounds like an Anitya bug to me, because 
upstream GitHub has a date for this release.


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

Re: New maintainer experience

[Otto Urpelainen]

Iago Rubio kirjoitti 18.8.2021 klo 14.32:

Hi all,

Following my messages on the "The Death of Java Packages" thread on
this list(1), Ankur Shina suggested to me to give a go at being a
package maintainer and let the mailing list know how it goes.

I hope this to be a constructive and helful way to help get more people
onboard.


Thank you for taking the time to report you experiences! Long time 
Fedora contributors have already learned all the common pitfalls and 
learned to avoid them, so it is really useful to get the newcomers 
perspective, especially when it is written as clearly as you do here. 
Please keep posting.



I pointed my browser to  the orphaned packages that need new
maintainers(3) page, as it seems the most appropriate for the task, and
it gave me some guidelines and a link to the "Lists of Orphan and
Retired Packages"(4) where I found a 500 response.

I have informed the webmaster at fedoraproject.org email address of the
issue.


Reporting this kind of issues is certainly the right thing to do. There 
are many issues, large and small, in Fedora tooling. Filing issues is 
the first step to get things fixed.


I am not sure if you got or will get a response to your email. In this 
case, the problem seems to be in Pagure engine that powers 
src.fedoraproject.org, so I filed a bug there [1].


[1]: https://pagure.io/pagure/issue/5209


Meanwhile I went for other preparation steps as I was asked to join
some mailing lists, devel (already on it), package-announces, devel-
announce, package-review, packaging. At the lists suscription page (5)
I was asked to log in, tried with  fedora account, but that did not
worked, so I guess the hyperkitty account is not linked to the fedora
account system.
,
AnywayI put my email address in the suscribe form and joined the
mailing lists.


At least for me, the login screen at lists.fedoraproject.org has a 
button (the first and largest one) saying "Fedora", which does the right 
thing.


I am not sure what is the use of the other options, including creating a 
separate account for that service only. Maybe it is just that some 
component that was used to make Fedora login possible gave those others 
for free.


Anyhow, as you just discovered, lists.fedoraproject.org can be very well 
used without ever logging in. Actually, I did it for the first time 
while writing this post.



Then I went to the package review status page (7) to get a look at the
review proccess and I found a bit shocking the first package from
review seems to be lurking around since 2015 and the guy still did not
found an sponsor. May be I did not understood what was going, but that
alone would be enought to demotivate many folk around. If you think
it's going to be 6 years to get sponsored and submit a package, is
somewhat easy to back down being a packager at Fedora.


If you had looked there half a year ago, you would have seen one from 
2008. Unfortunately, reviews sometimes get stalled because either the 
reviewee or reviewer drops the ball for whatever reason. There is 
automation to detect and close these automatically, but if they are in a 
Bugzilla state that is no picked up, they can stay there indefinitely.


I have been going through those manually and closing them if they really 
are dead. Some were even completed after years of silence. I have 
reached November 2016 already. The 'giza' review request you mention 
still has some activity going on, that is why it has not been closed. It 
is a sad story if you read through the comments, not a typical package 
review issue at all, all kinds of trouble just stacking on top of each 
other. Let us just hope that the remaining issues get resolved.


I have hard time believing that anybody would not get sponsored if they 
just follow the instructions on doing the informal package reviews and 
then file an issue at package-sponsors issue tracker [2], explaining 
what they have done.


What I have not been able to understand is why Fedora has two parallel 
processes for getting sponsored, the FE-NEEDSPONSOR flag and the 
package-sponsors issue tracker. I have a feeling that the former is just 
a relic and Fedora would be better off by just instructing aspiring 
packager group members to file a properly filled ticket in the latter. 
But I am not a packager sponsor myself, so I do not really know how this 
appears from that side.


[2]: https://pagure.io/packager-sponsors/issues


By the way not on https://fedoraproject.org/wiki/Join nor at
https://whatcanidoforfedora.org/ there exists a packager role. I guess
this is on purpose, but it doesn't helps to recruit people.


I am not really familiar with these pages, but at the former, packager 
seems to be a sub role of "OS Developer" and the latter actually has it 
[3]. Not sure why these two use different categorization, perhaps they 
are from different periods or made by different people?


[3]: https://whatcanidoforfedora.org/en/#packaging

Specfile description and summary translations

[Otto Urpelainen]

I have problems interpreting the following check from fedora-review:

> [ ]: Description and summary sections in the package spec file 
contains translations for supported Non-English languages, if available.


In one of the first package reviews I made, I recall suggesting copying 
such translations from the desktop file which had many suitable 
translations. In the end, this suggestion was not followed, because a 
more experienced reviewer said that having translations in desktop file 
is not what is meant by 'translations are available' here — only an 
upstream specfile with translations would count.


I would like to update fedora-review as well as Review and Packaging 
Guidelines to explain what is expected for these translations. For that, 
I would need to understand the purpose of this check better. Perhaps 
somebody here has some insight?


I addition to the fedora-review check given above, I can find the 
following references:


Review Guidelines [1] have this entry, which is quite clearly the origin 
of the fedora-review check.


> SHOULD: The description and summary sections in the package spec file 
should contain translations for supported Non-English languages, if 
available.


That entry refers to Packaging Guidelines: Summary and description [2]. 
It has milder wording, saying 'can' instead of 'should':


> Packages can contain additional translated summary/description for 
supported Non-English languages, if available.


Assuming that the Packaging Guidelines are correct and that 'can' there 
means 'you can do it either way, Fedora as a distribution does not have 
any preference', I would say the above listed entries should simply be 
removed from both Review Guidelines and fedora-review. If Fedora has no 
preference either way, why should reviewers consider this at all?


There are some but not very many specfiles that actually have translations:

$ grep -c 'Summary(' * | grep -v .spec:0 | wc -l
137

Any thoughts?

[1]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
[2]: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_summary_and_description

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

Re: Running rawhide mockbuild on Fedora 33 fails with GPG check

[Otto Urpelainen]

Sérgio Basto kirjoitti 15.8.2021 klo 3.12:

Hi,

I'm seeing the same problem,  for a quick fix, we need update
/etc/mock/templates/fedora-rawhide.tpl line 12 with
config_opts['releasever'] = '36', as reference [1] ...

We need a new mock-core-configs package with configurations for "Fedora
35 branched" some work in progress here [2]


Having followed the Fedora process for some time now, I have noticed 
that issues of this kind happen at every branching.


I wonder if more things could work like dist-git branches already do, 
where rawhide is always rawhide, branching does not affect it, and 
branched releases receive a new configuration at the moment of 
branching? Opposed to that, Mock and other places follow a model where 
rawhide is Fedora N+1 and branching means a) reconfiguring rawhide as 
Fedora N+2 and b) creating a new configuration for the actual Fedora 
N+1. The need to do a) means that rawhide easily breaks when branching 
occurs.


When you branch B off from A, it is understandable that B won't be 
completely functional until the branching is completed. But there should 
be no reason for A to stop working, simply because there should not be 
any reason to modify A at all.


I am not very familiar with Mock internals, but I suppose that Mock is 
*not* one of the places where such change of approach would be easy. I 
suppose it has a relation with dist tags, and if you changed rawhide's 
dist tag from 'fc(n+1)' to 'rawhide', you should probably do mass 
rebuild only after branching to get dist tag right in the branched 
release. And you would probably have to consider a lot of other things, too.


But there are also places where it would be easy to avoid breakage 
simply calling rawhide, 'rawhide': At least the thing where a Toolbox 
container build from f34 image can be either actually Fedora 34 or 
Fedora Rawhide, depending on things [1].


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

Re: Systemd unit files installed into unowned directories

[Otto Urpelainen]

Björn Persson kirjoitti 6.8.2021 klo 2.44:

Petr Menšík wrote:

No, that is the reason why I proposed it. Guidelines already state
*-filesystem packages does not have to be depended on [1]. Just one,
probably systemd or systemd-libs, should depend on it to get it
installed. All other can then just ignore the directory exactly as you
have proposed. In this case it would not be breaking guidelines, but
according to them instead.

1.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership


That is contradicted by the following quote from the Packaging
Guidelines:

| Sometimes, it may be preferable for such directories to be owned by
| an "artificial filesystem" package, such as mozilla-filesystem. These
| packages are designed to be explicitly required when other packages
| store files in their directories, thus, in such situations, these
| packages should explicitly Require the artificial filesystem package
| and not multiply own those directories.

That is, each of those 1600 packages would need to require
systemd-filesystem.


I have also had problems interpreting this part of the guidelines 
correctly. It is unclearly written. Already some months ago, I submitted 
a pull request to clarify things [1]. If somebody has ideas on how to 
make things even more clear, please comment on the pull request.


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

Re: rpmautospec deployment into production

[Otto Urpelainen]

Peter Oliver kirjoitti 19.7.2021 klo 10.53:

On Mon, 19 Jul 2021, 08:08 Otto Urpelainen,  wrote:



However, copr seems to understand rpmautospec.



Not really.  The release will always be 1.  When a package builds again,
end users won't receive the updated version.

https://pagure.io/fedora-infra/rpmautospec/issue/199


Thank you for correcting me. This is a reminder for me to always check 
the output, rather than just being happy when there are no errors.


Now that I have used rpmautospec a little, I have also discovered that 
it only considers the first line of Git changelog. The rest is silently 
dropped. So what would be like this in rpm changelog language:


- Update to version 1.2.3
- Re-enable the test suite
- Fixes rhbz#123456
- Fixes rhbz#234567

is this oneliner in rpmautospec language:

Update to version 1.2.3; Re-enable the test suite; Fixes 
rhbz#123456; Fixes rhbz#234567


That is not your usual Git changelog entry, but something special to 
rpmautospec. Worse, forgetting that you should not use newlines produces 
a specfile changelog with information missing.


This situation considerably reduces my enthuasism about rpmautospec. For 
some reason I thought I could think about it as "just fill the Git 
changelog, you get rpm changelog for free".


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

Re: rpmautospec deployment into production

[Otto Urpelainen]

Dan Čermák kirjoitti 18.7.2021 klo 23.38:

Otto Urpelainen  writes:


Dan Čermák kirjoitti 17.7.2021 klo 23.10:

Robert-André Mauchin  writes:


What is the situation wrt new packages? Should we enforce the use of
rpmautospec during reviews or is it completely optional?


I think we should encourage the usage of rpmautospec for new packages,
provided that the packager feels comfortable enough to use it. E.g. I
wouldn't suggest it for someone's first package. But this shouldn't
become a *MUST*, at least not yet.


I am curious regarding the reasons for not recommending rpmautospec for
new maintainers? It is an automation feature that removes manual steps
from the process. Using it is simpler than doing the same manually. I
think we should offer the simplest possible process for newcomers and
only recommend manual overrides for use cases that automation cannot
handle (yet).


Well, I think that a total newcomer is already struggling enough to
produce a good spec file for their first package, but now they also need
to keep in mind that their changelog is tied to the git history (and can
thus not be changed easily anymore). Back when I started packaging, I
found a lot of the details quite confusing and was building packages on
copr and locally for a few years before I dared to go near koji. At
least for me using rpmautospec would've been another one of these
confusing details. That's why I would only recommend its usage, until
most other build system out there use something comparable and beginners
can be expected to know this concept already.


Understood. That makes sense. This is a case of different backgrounds. 
The only rpm packages I have ever built are Fedora official packages. 
From that angle, using rpmautospec is just simpler. In your case, it is 
the other way round.


However, copr seems to understand rpmautospec. Here is a build that 
started from a specfile that uses rpmautospec and completed successfully:


https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/build/2329596/

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

Re: Review swaps: A bunch of PHP libraries

[Otto Urpelainen]

Christopher Engelhard kirjoitti 16.7.2021 klo 11.39:

Hi all,
I finally found some time to unbundle all the 3rdparty PHP/composer
libraries from the nextcloud package.

The bad news is that due to their various dependency trees, I now have a
total of 24 new packages that need reviewing.
The good news is that I think quite a few of them will be generally
useful beyond just nextcloud.

They are all fairly small & simple PHP libraries, build without issues
and are basically identical in terms of packaging. If there are people
out there who'd like to try their hand at reviewing for the first time,
one of these might be a good place to start.

Obviously, if you need something reviewed in return, I'd be happy to do
that.

Full list of links is below, but to make it easier for people
- I set up a dependency tree (
https://bugzilla.redhat.com/buglist.cgi?bug_id=1981857_id_type=anddependson=tvp_id=12016550
) so you can pick a leaf.
- I made a copr repository (
https://copr.fedorainfracloud.org/coprs/lcts/nextcloud/packages/ ) that
has builds for all of these, including fedora-review/rpmlint logs (and a
big thank you to whoever made that last bit possible in Copr, that was
*extremely* useful). The repo also contains a few forks of existing
packages, ignore those :) .


I will review at least some of these, depending on how much time I find. 
I will flag anything I have ongoing as appropriate, so others are free 
to take any that have not been flagged.


In exchange, you could take a look at either or both of these that I 
have waiting for a reviewer:


mt32emu - C/C++ library for emulating Roland MT-32, CM-32L and LAPC-I 
synthesizer modules
A cmake project that is somewhat complicated by the fact that it comes 
from a monorepo that also contains other related projects.

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

rubygem-sync - A module that provides a two-phase lock with a counter
Ruby library whose specfile was automatically generated with gem2rpm, 
only small adjustements were needed on top of that.

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

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

Re: rpmautospec deployment into production

[Otto Urpelainen]

Dan Čermák kirjoitti 17.7.2021 klo 23.10:

Robert-André Mauchin  writes:


What is the situation wrt new packages? Should we enforce the use of
rpmautospec during reviews or is it completely optional?


I think we should encourage the usage of rpmautospec for new packages,
provided that the packager feels comfortable enough to use it. E.g. I
wouldn't suggest it for someone's first package. But this shouldn't
become a *MUST*, at least not yet.


I am curious regarding the reasons for not recommending rpmautospec for 
new maintainers? It is an automation feature that removes manual steps 
from the process. Using it is simpler than doing the same manually. I 
think we should offer the simplest possible process for newcomers and 
only recommend manual overrides for use cases that automation cannot 
handle (yet).


A transition period where all the tools are updated to cope with 
rpmautospec may be needed. We do not want to offer a process that prints 
errors and warnings that should just be ignored. At least fedora-review 
and rpmlint have issues, discussed in another subthread.


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

Re: rpmautospec deployment into production

[Otto Urpelainen]

17. heinäkuuta 2021 10.23.34 GMT+03:00 Christopher Engelhard  
kirjoitti:
>On 17.07.21 00:59, Miro Hrončok wrote:
>> On 16. 07. 21 19:58, Robert-André Mauchin wrote:
>>> On 6/16/21 6:03 PM, Nils Philippsen wrote:
 Hi everybody,

 we've scheduled the rpmautospec plugin to be deployed into
>production
 for tomorrow, from 14:00 UTC on.

 This means installing the relevant packages and restarting kojid
 processes on the builders, which will restart any tasks which are
>being
 processed at that time, i.e. expect delays for builds in-flight at
>the
 time.

 We'll announce when the deployment is done.

 Cheers,
 Nils

>>>
>>> What is the situation wrt new packages? Should we enforce the use of
>>> rpmautospec during reviews or is it completely optional?
>> 
>> It is completely optional.
>> 
>
>One thing to note: If people *are* using it, then right now
>fedora-review will complain about a missing dist-tag and rpmlint will
>warn about macros in the changelog.

Fedora-review master already has a fix for dist-tag complaint:

https://pagure.io/FedoraReview/pull-request/417

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

Re: Permanent Updates Policy exception for PrusaSlicer, Cura, Black, tox, HTTPie and ownCloud Desktop Client

[Otto Urpelainen]

Miro Hrončok kirjoitti 12.7.2021 klo 14.30:

Hello,

I happen to maintain some applications in Fedora where I am strongly 
confident our users would prefer "latest and greatest" over 100 % 
"stability" of the user interface and/or results.


For some of them, I've been more or less silently breaking the Updates 
Policy hoping that nothing would break (nothing did so far). For others, 
I've requested FESCo exceptions for individual updates. I'd like to 
request a *permanent exception* to allow upgrading the following tools 
and apps to latest versions in stable Fedora releases.


For transparency reasons, I've decided to share the list of packages on 
this mailing list before approaching FESCo. If you see potential 
problems, do let me know.


(snip)


ownCloud Desktop Client
===

- owncloud-client

As OwnCloud serves are updated, users might need the latest version of 
the client installed to be able to use them. Hence, I'd like to be able 
to update this package freely.


OTOH I don't actually plan to do that often, because I maintain the 
package "to scratch my own itch" and I would only do that if the server 
used by our university requires client updates. However, if 
co-maintainers appear, this could happen more often.


I wonder if Updates Policy should have general wording that would allow 
you to update this package without asking for exceptions, or at least 
"make it more likely to grant a request"? It does not make much sense to 
disallow client program updates because they contain "new features" when 
the remote backends it is connecting to require those features.


Web browsers are another example of this, and maybe also your 3d printer 
control apps.


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

Re: Packager sponsors site

[Otto Urpelainen]

Jakub Kadlcik kirjoitti 12.7.2021 klo 3.36:

Hello,

I am happy to announce that I deployed this little site
https://docs.pagure.org/fedora-sponsors/


Thank you for doing this. Finding a sponsor if one of the difficult 
steps in the onboarding process, making is easier is very valuable.



Please share the site with new packagers if you get a chance.


I suggest you update the relevant wiki page [1] (which is moving to 
docs.fp.o, just pending a pull request approval [2] — I will check any 
pages for recent edits and process them after docs.fp.o move goes live.)


[1]: 
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

[2]: https://pagure.io/fedora-docs/docs-fp-o/pull-request/171


If you would like to know more about the project, see
https://github.com/FrostyX/fedora-sponsors
Feedback is always appreciated, so don't hesitate to file a new issue or
reply here.


I filed your first ticket, about how timezones are displayed.

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

Re: I would like to take dropwatch

[Otto Urpelainen]

Hangbin Liu kirjoitti 2.7.2021 klo 6.47:

Hi,

The dropwatch package[1] was retired as Neil Horman left RedHat[2]. But the
upstream status is still active[3]. Since this is still an useful feature
(dump the dropped packets from kernel) for networking debugging. And there
is no replace yet (bpftrace may replace it in future, but not now).

So I'd like to take it first and make it build on latest Fedora. Any comments?


I am not aware of the state this particular package, but in general, you 
are free to take over any retired package by submitting a new review 
request for it. This is described in the wiki [1, 2, 3]. I understand 
that you have not been sponsored to packagers group, so that is a 
necessary step as well. That is also described in the linked documentation.


Otto

[1]: https://fedoraproject.org/wiki/Policy_for_Orphan_and_Retired_Packages
[2]: 
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers

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

Re: F35 Change: LLVM 13 (Self-Contained Change proposal)

[Otto Urpelainen]

Ben Cotton kirjoitti 28.6.2021 klo 19.57:

https://fedoraproject.org/wiki/Changes/LLVM-13

== Summary ==
Update all llvm sub-projects in Fedora to version 13.

== Scope ==
* Proposal owners:
** When the upstream LLVM project releases version 12.0.0-rc1 (Late
July 2021), package this and build it into the side tag.


This is a copy-parse error and should be 13.0.0-rc1, right?

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

Re: Updating sources file using fedpkg

[Otto Urpelainen]

Ewoud Kohl van Wijngaarden kirjoitti 21.6.2021 klo 14.50:

On Thu, Jun 17, 2021 at 09:02:12PM +0300, Otto Urpelainen wrote:
I am a bit confused about this discussion. My fedpkg does not care 
about the 'sources' file or the lookaside cache at all on 'fedpkg 
mockbuild'. It simply looks up the expected filename of downloaded 
Source, grabs it from the local working directory and uses that. So 
for me this works:


   rpmdev-bumpspec -D -n 1.2.3 *.spec
   # Update specfile as needed
   spectool -g *.spec
   fedpkg mockbuild


Now it also downloads the old files mentioned in sources. In my 
experience it certainly does care about it.


Maybe my request can be reduced to: mockbuild should not download files 
not mentioned in the spec file. Ken did give a good workaround. Taking 
that a step further I think something like this would suffice for me:


spectool -l *.spec | awk '/https?:/ { print $2 }' | xargs -n 1 basename 
| xargs sha512sum --tag > sources


Ah, you are right. Since I settled on my current workflow, I did not 
even notice those useless files being downloaded. I guess I have not 
encounters are very large one, then.


I filed an issue about this: https://pagure.io/rpkg/issue/559

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

Re: Updating sources file using fedpkg

[Otto Urpelainen]

Ken Dreyer kirjoitti 17.6.2021 klo 19.04:

On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw  wrote:


On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden 
 wrote:



To be clear: I don't want to fiddle with the sources file, hence this
email. However, I would like to at least complete a local mockbuild
before uploading to the lookaside cache. It is my understanding that
new-sources always does this.



That's actually a nit I've been tempted to complain about. If I'm upgrading a 
package to a new version I update the spec file:

rpmdev-bumpspec -n  -c "Update to ." *.spec

And download the new source:

spectool -g *.spec

But then I have to upload the new source with 'fedpkg new-sources' if I don't 
want it to download the old version.


Yeah, the way I deal with this is I zero out the sources file, like ">
sources". Or another alternative that I use sometimes is "sha512sum
--tag", like:

   sha512sum --tag kstart-4.2.tar.gz > sources


Hi Ewould and everybody,

I am a bit confused about this discussion. My fedpkg does not care about 
the 'sources' file or the lookaside cache at all on 'fedpkg mockbuild'. 
It simply looks up the expected filename of downloaded Source, grabs it 
from the local working directory and uses that. So for me this works:


rpmdev-bumpspec -D -n 1.2.3 *.spec
# Update specfile as needed
spectool -g *.spec
fedpkg mockbuild

After that is done, the rpm is available at results_mypackage, I install 
it locally and see that everything works. At that point it is a good 
time do 'fedpkg new-sources'.


This also means that non-packagers actually *can* properly test their 
changes. The maintainer has to do new-sources, commit, push and build 
after merging the pull request, so annoyingly there are those steps to 
remember. But at least the pull request author does not have to submit 
their changes blindly.


A simple test to make sure that it really uses the local download:

$ sed -i 's/^Source.*/Source:https:\/\/example.com\/foo/' *.spec
$ fedpkg mockbuild
SOME_OUTPUT
error: Bad file: SOMEPATH/foo: No such file or directory
$ touch foo
$ fedpkg mockbuild
LOTS_OF_OUTPUT
SOME_ERROR_DUE_TO_EMPTY_SOURCE

When I started, I was having exactly the same trouble, so wrote 
something in the wiki:


https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously

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

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[Otto Urpelainen]

przemek klosowski via devel kirjoitti 17.6.2021 klo 6.21:


On 6/16/21 6:26 PM, Kevin Kofler via devel wrote:

Otto Urpelainen wrote:

Also, if the intent is to get rid of the package completely, should not
adding it to fedora-obsolete-packages be required as well?

Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the 
repository.

That is a major disservice to the users. fedora-obsolete-packages makes
sense to use only when having the package still present actually breaks
something (and I personally think that it is unhelpful even in that case,
that is really what dnf --allowerasing is for, at least when we are 
talking

about package-level conflicts).


This is correct from the strict OS packaging point of view, but I think 
we should be concerned about the accumulation of detritus: packages that 
broke over time and simply do not work any more, for example like this one


Note that the documentation in question is not about normal package 
retirement, it is about the case where "there are special factors at 
work, like licensing issues, or package being removed completely from 
Fedora". That is quite muddy, but it is clear that the procedure is only 
intended for some special case where it is considered important to 
somehow erase the whole package, end-of-life releases and all.


The only example that is given are "licensing issues" with no 
explanation. I imagine what is meant is that it turns out that package 
useful-app is packaged in Fedora, then later it turns out it actually it 
has a proprietary license and Fedora has no right to distribute it. So 
distribution is ceased by removing the package from all channels, 
including end-of-life releases. In this case, the question is, is Fedora 
also obliged to do a recall the copies that were already illegally 
distributed. Obsoleting it would help with that.


Another case I could imagine would be that a package is found to contain 
malware, in which case I suppose it would be a good idea to attempt to 
remove it from as many installations as possible.


From documentation point of view, the problem is that a large and 
complicated topic is just hinted at when describing a different procedure.


Anyhow, since the obsoletes part is unclear and it was my own invention 
anyhow, I edited the page a bit to just say that it should be considered 
in that situation.


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

Re: Experience on src.fedoraproject.org as non-packager

[Otto Urpelainen]

Kevin Fenzi kirjoitti 16.6.2021 klo 19.57:

On Wed, Jun 16, 2021 at 03:05:59PM +0200, Ewoud Kohl van Wijngaarden wrote:

It would be my recommendation to add a third "URL" to it and that's the
fedpkg command to clone.


Yeah, might be a reasonable idea indeed. Can you file a issue at
https://pagure.io/pagure/issues/ ?



I like this.

Even better, fedpkg could be the first option, and there could be a 
warning text about the other two saying something like "Pushing to 
Fedora Package Sources requires use of fedpkg". Something simple that 
leads the potential contributors to choose the method that does not lead 
to an auth error later on.


The warning could be hidden in case the user is already in the packagers 
group and has ssh configured, assuming Pagure gets this information from 
Accounts.


Pull requests ("I fixed it") are much preferable over Bugzillas ("could 
you fix it?"), hence creating one should be as easy as possible. They 
are also a low barrier way to get involved in packaging. I am quite sure 
that there are many more people who are willing to submit a PR than 
those who are willing to go through the "find something you use but that 
is not already in the repo, get it reviewed, get sponsored" process 
which is quite intimidating for a newcomer.


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

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[Otto Urpelainen]

Miro Hrončok kirjoitti 14.6.2021 klo 22.05:

On 14. 06. 21 19:50, Kevin Fenzi wrote:

It might be somehow 'fedpkg retire' doesn't handle this case?


While the wiki probably predates this feature, `fedpkg retire` will 
refuse to retire a package on a stable Fedora branch and it does not 
appear to have a --force switch.


Thank you for input everybody. I added a separate section "Completely 
Removing a Package" on the same page, using 'git rm'and also adding 
dead.package and updating fedora-obsolete-packages.


https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Completely_Removing_a_Package

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

Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[Otto Urpelainen]

Hello,

As part of the effort to move the Package Maintainer docs to 
docs.fedoraproject.org [1], I have been reviewing the existing wiki 
documentation. I would like to ask for insight on the following item:


Page _How to remove a package at end of life_ [2] first says that 
retirement is done by running 'fedpkg retire', then later alludes to a 
special case:


> 'git rm' all files in the other branches *only if* there are special 
factors at work, like licensing issues, or package being removed 
completely from Fedora.


I understand this to mean that in special conditions, the package cannot 
remain behind even in stable or end-of-life Fedora releases. However, I 
do not understand why 'git rm' is mandated instead of 'fedpkg retire' 
that is used in the normal case — is the 'dead.package' tombstone 
somehow unwanted in this case? I cannot understand why it would be.


Also, if the intent is to get rid of the package completely, should not 
adding it to fedora-obsolete-packages be required as well? And would 
that even work for end-of-life releases?


Lastly, even if this complete removal case is rare, it seems to be 
important enough to have its own process description. Should it be given 
its own page, "Package Withdrawal Process" or "Package Removal Process" 
or such, with content like "1) retire the package 2) do these additional 
steps"?


Thank you,
Otto

[1]: 
https://pagure.io/fork/oturpe/fedora-docs/package-maintainer-docs/tree/wiki-import

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

License change: rubygem-term-ansicolor

[Otto Urpelainen]

I took the recently orphaned rubygem-term-ansicolor. It was behind on 
releases, so I updated it from 1.4.0 to 1.7.1, the latest. In the 
meantime, upstream has changed the license from GPLv2 to ASL 2.0.

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

Re: doxbox-staging package conflict

[Otto Urpelainen]

Hans de Goede kirjoitti 1.6.2021 klo 21.02:

Hi,

On 6/1/21 6:20 PM, Vitaly Zaitsev via devel wrote:

Hello all.

doxbox-staging is trying to overwrite the regular dosbox package:

Installing:
  dosbox-staging    x86_64    0.76.0-2.fc34  fedora    
1.4 M
  replacing  dosbox.x86_64 0.74.3-7.fc34

 From its SPEC[1]:

# This package is a drop-in replacement for dosbox
Provides:  dosbox = %{version}-%{release}
Obsoletes: dosbox < 0.74.4

Is this Okay? These packages has different maintainers. According to the Fedora 
packaging guidelines, one package cannot introduce conflicts with another.


This is intentional, regular dosbox is more-or-less (*) unmaintained upstream 
so we have decided to switch to dosbox-staging, also see the Package Review for 
dosbox staging:
https://bugzilla.redhat.com/show_bug.cgi?id=1884608

As such dosbox-staging is intended as a replacement for the regular dosbox (and 
it is fully compatible with the regular dosbox). This was coordinated with the 
dosbox owner, but we have forgotten to actually retire dosbox, sorry about 
that. I'll retire dosbox in rawhide right away.


I think it is great that Fedora now has dosbox-staging and arrow keys 
work again. Many games were quite annoying to play without them. And 
there are other improvements as well.


But the complaint I have about this process is that, if you use the 
default dosbox-staging config, quite many games that actually ran with 
dosbox crash on dosbox-staging startup. That problem should be patched 
around somehow before dosbox can go. See Bugzilla discussion [1].


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1933849#c4

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

Re: New Fedora Packages Ready For Testing

[Otto Urpelainen]

Zbigniew Jędrzejewski-Szmek kirjoitti 30.5.2021 klo 12.59:

On Sat, May 29, 2021 at 09:38:46PM -0500, Brendan Early wrote:

Hi all,

Fedora Packages Static is intended to replace the old Fedora
Packages app and is now available for testing at
https://packages.stg.fedoraproject.org. Any feedback would be
appreciated here or on Pagure at
https://pagure.io/fedora-packages-static.


Which pages is it supposed to replace? What is the relation to
https://src.fedoraproject.org/rpms/?


(snip)


- "SCM" links to a page that calls itself "fedora PACKAGE SOURCES" and
   that everybody seems to refer to as "dist-git" or "pagure" in
   conversations. Maybe it would be better to call the link "sources"
   or "dist-git source" or "package source"?

   (And "FAF" links to "retrace.fedoraproject.org" page that calls itself
   "ABRT Analytics". I don't even know what to suggest here ;| .)


I think it would also be good to compare these links to basically 
identical links at the package sources [1]. The corresponding names 
there are:


Bodhi -> Updates Status
Bugzilla -> Bug Reports
FAF -> not included, why the difference?
Koji -> Builds Status
SCM -> not included, because it would link to the same page

and package source have two items not found in this app:

Packages -> should link to this app when this is deployed? currently 
returns 503

Koschei Status -> would make sense to have in this app also?

[1]: https://src.fedoraproject.org/rpms/firefox

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

Re: F34: AVCs on dbus socket from GNOME

[Otto Urpelainen]

Tim Jackson kirjoitti 25.5.2021 klo 0.58:
Since upgrading from a fairly clean F33 (installed from scratch a few 
months ago) to F34 I get regular (upon each desktop login, I believe) 
SELinux denials on what appears to be a dbus socket from gnome-shell and 
other components:


type=AVC msg=audit(1621790705.033:963): avc:  denied  { write } for 
pid=136319 comm="gnome-shell" name="dbus-QyPy1X95QF" dev="tmpfs" ino=368 
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 
tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file permissive=0


Similar denials occur immediately following for gsd-keyboard, gsd-power, 
gsd-media-keys, gsd-color and gsd-wacom, always in that order as far as 
I can tell.


Is this a bug in the upgrade process? A known bug? Something 
misconfigured by me? (I didn't readily find anything in Bugzilla or by 
searching)


I can obviously trivially fix it for myself (audit2allow says "allow 
xdm_t tmp_t:sock_file write;") but if it's an SELinux policy or upgrade 
bug then it should presumably be fixed.


Is this the same as bug 1941853 [1]? Your AVC is similar to the one in 
the report, though not identical). That bug is being discussed in bug 
comments: "Yes, this needs to be addressed in the policy."


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

Licensing guidelines for AppStream project_license

[Otto Urpelainen]

I asked this question a while ago on the packaging mailing list [0], but 
did not receive any replies. Let me try again here on devel with more 
subscribers:


During the package review of qvge [1], the following question came up: 
Are the any requirements placed on the contents of AppStream metadata, 
particularly the field project_license [2]? It feels natural that is 
MUST be the same (modulo differences in notation) as specfile License, 
since both have the same meaning. However, I cannot find anything in 
Licensing Guidelines about this.


In my experience, this comes up quite often, since upstreams often have 
bundled dependencies or other copy-pasted code with different license 
than upstream's own code, yet AppStream metadata, LICENSE file, README 
and so only list upstream's own license.


[0]: 
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/thread/HMDNWXRVTW37E5TOY6SU2BJ24KFJNZLY/

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1913870
[2]: 
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-project_license


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