Best practice for multiple version/OS boot?

[Tim Landscheidt]

Hi,

IIRC fedora-review suggested to test packages on all sup-
ported Fedora releases.  So, with a larger hard disk, I want
to install Fedora 19, 20 (soon) and Rawhide and throw in
(recent) Debian and Ubuntu as well.  As my notebook doesn't
support VMs, I'm interested in best practices for partition-
ing and multi-boot setups.

Currently I use a partition for /boot and another for an en-
crypted LVM, so I only need to worry not to put private data
in /boot, and I would like to keep such flexibility.

I suppose I need to create a /boot partition for each ver-
sion/OS.  I have had different Fedora versions share the
same encrypted LVM without problems; I assume Debian and
Ubuntu will do so as well, but I will keep some free space
and partitions just in case.

More contested seems to be the multi-boot setup.
https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a
myriad of opinions on how it should be set up;
http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide
suggests chainloader, and
http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html
recommends configfile.  Of course there is also GRUB's OS
prober.

So what are Fedora developers /actually/ using?  Creating a
separate GRUB partition and chainloader/configfile?
Running OS prober in the main OS after each installation/
kernel update?  Something else?  How often do the setups al-
low one to shoot oneself in the foot, or are they (more or
less) foolproof?

Thanks in advance,
Tim

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self introduction

[Tim Landscheidt]

Hi,

after posting bug reports and patches for quite some time, I
finally decided to set up a FAS account to see how I can
help with packaging and other tasks at hand.

  I believe my Linux experience started with Vanderbilt af-
ter one encounter with DJ'ing Slackware onto my system and
giving up when I saw the result :-).

  My initial interest will probably lie in pushing out the
Emacs/Perl packages that I found a) useful and b) lacking in
the Fedora distribution, but as works for me will no
longer be a sufficient criteria I have to read up on the
rather voluminous documentation before I will ask for my
first review.

Tim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Firefox not working anymore over ssh?

[Tim Landscheidt]

Michael Catanzaro  wrote:

>> Yes.  This makes it work.  Thanks a lot.

> Then it was probably broken by this update:

> https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253

The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as
well (running Iceweasel on a remote Debian box from a local
Fedora box).  Does that mean that there is an error in Fe-
dora, Firefox/Iceweasel, something else?  Is there a bug
tracking this?

Tim
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Announcing the release of Fedora 24 Beta!

[Tim Landscheidt]

Dennis Gilmore  wrote:

> […]

> Cloud
> -

> We are working hard to make Fedora the best platform for containerized
> applications, from base Fedora container images to a full-featured
> platform as a service to run and manage them. To meet this goal, we are
> packaging OpenShift Origin so it is easy to deploy. OpenShift Origin is
> a distribution of Kubernetes, a container cluster manager from Google.
> It is optimized for enterprise application development and deployment.
> Origin makes it easy for developers to get started building applications
> in containers and for operators to manage them.

> […]

I had looked at
https://fedoraproject.org/wiki/OpenShift_Origin and
https://fedoraproject.org/wiki/Features/OpenShift_Origin for
information about OpenShift Origin (or any PaaS :-)) and Fe-
dora recently and I read it to mean that that combination is
on hold, with the pages not having been updated for two
years.  Are there other sources of information for that fea-
ture?

Tim
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: fedorahosted.org retired today (2017-03-01)

[Tim Landscheidt]

Kevin Fenzi  wrote:

> Today we have retired fedorahosted.org.

> Please see the following wiki page for up to date information:

> https://fedoraproject.org/wiki/Infrastructure/Fedorahosted-retirement

> * ssh pushes will direct you to the above wiki page and not complete.
> * web access will redirect you to the above page.

> We hope you will look to https://pagure.io for your future source and
> issue hosting needs.

> Note that lists.fedorahosted.org is not affected by this and will
> continue moving forward.

There are still several hundred binary packages in F25 that
refer to that host:

| [tim@passepartout ~]$ dnf repoquery --qf '%{url}\t%{name}' | fgrep 
fedorahosted | wc -l
| 464
| [tim@passepartout ~]$

I think mass-filing bugs for those would be helpful to clear
out the backlog.  (In the previous thread there was also
talk of a more systematic approach that checked the status
of all URLs as part of build tests.)

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

Re: Purpose of Makefile in package repository?

[Tim Landscheidt]

Adam Jackson  wrote:

>> I searched a bit in the wiki, and my sense is that at some
>> point in the past packages were maintained in a CVS reposi-
>> tory with Makefiles and that those have been replaced by Git
>> repositories and fedpkg.

>> Is that correct?  Can such a Makefile then be deleted or
>> does it serve any other purpose?

> That is correct. Most packages had a nearly identical copy of this
> Makefile, but a few (most notably the kernel) had extended it with
> other maintainer convenience commands. I suspect what happened here is
> that when we moved to git we preserved any Makefile that didn't match
> the standard one.

> This particular one is certainly not doing anything useful anymore,
> feel free to nuke it.

Thanks for the explanation.

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

Purpose of Makefile in package repository?

[Tim Landscheidt]

Hi,

pytz has a Makefile in its package repository with the con-
tents
(https://src.fedoraproject.org/rpms/pytz/blob/master/f/Makefile):

| # Makefile for source rpm: pytz
| # $Id$
| NAME := pytz
| SPECFILE = $(firstword $(wildcard *.spec))

| define find-makefile-common
| for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ; 
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q 
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
| endef

| MAKEFILE_COMMON := $(shell $(find-makefile-common))

| ifeq ($(MAKEFILE_COMMON),)
| # attept a checkout
| define checkout-makefile-common
| test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo 
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to 
checkout the 'common' module." ; exit -1 ; } >&2
| endef

| MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
| endif

| include $(MAKEFILE_COMMON)

I searched a bit in the wiki, and my sense is that at some
point in the past packages were maintained in a CVS reposi-
tory with Makefiles and that those have been replaced by Git
repositories and fedpkg.

Is that correct?  Can such a Makefile then be deleted or
does it serve any other purpose?

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

Re: Is it possible to upload new sources of a package from a URL?

[Tim Landscheidt]

Hedayat Vatankhah  wrote:

> […]
> Yes, but even if I'm forced to download locally, it is much
> better than being forced to upload it again. (Also, note
> that the current process doesn't prevent MITM if it happens
> when I download the source).
> Also, it is easier to schedule the download for a time when
> it is cheaper (or free), but it'd be harder to do it for an
> upload since it requires authentication.

> […]

If data volume is expensive or difficult for you, you could
look into renting a (virtual) private server and then devel-
oping there via ssh.  Offers usually start at less than
$ 5,-/month.  (I'm not aware of free solutions; it's proba-
bly easier to solicit donations for one's own server than to
get access on someone else's.)

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

Re: Changes Policy & Fedora Release Life Cycle - request for review

[Tim Landscheidt]

Przemek Klosowski  wrote:

>  In MediaWiki, revisions compared in a diff do not need to
> belong to the same article.  So for example, to compare the
> current revision of...(488139) to the current revision of
> ...(505754), you can use the URL
> https://fedoraproject.org/w/index.php?diff=505754=488139
> This is not as convenient (or obvious :-)) as your approach,

> Is there a way to click into that, or do you just know the URL and 
> substituted the IDs by hand? How did you get the IDs of the two pages in the 
> first place?

This kind of URL is not exposed by the UI (AFAIAA).  I as-
sembled the URL by:

1. Going to
   https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle,
   "history", "Compare selected revisions" which gives
   
https://fedoraproject.org/w/index.php?title=Fedora_Release_Life_Cycle=488140=488139
   (which means 488140 is the current revision (on the right
   side of the diff)),

2. doing the same for
   https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
   which gives
   
https://fedoraproject.org/w/index.php?title=User%3AJkurik%2FFedora_Release_Life_Cycle=505754=505738,
   and

3. assembling the URL by removing the "title" parameter
   (just for cosmetics), setting the "oldid" parameter to
   the revision to appear on the left side and the "diff"
   parameter to the revision to appear on the right side.

(Cf. 
https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#View_and_render
for documentation.)

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

Re: Changes Policy & Fedora Release Life Cycle - request for review

[Tim Landscheidt]

Adam Williamson  wrote:

>> I tried to merge together all the changes we were facing during the
>> last time with regards to Changes Policy & Fedora Release Life Cycle.
>> The outcome is available in [1] and [2]. Before I will ask FESCo for a
>> review, I would like to ask anyone who is interested for a review and
>> comments.

> It would be much easier to review if we could see a diff to the current
> contents of the pages. When doing drafts like this, I usually copy the
> original page *without* changes first, *then* make my changes, so the
> 'history' tab can be used to view the changes from the original
> content.

In MediaWiki, revisions compared in a diff do not need to
belong to the same article.  So for example, to compare the
current revision of
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
(488139) to the current revision of
https://fedoraproject.org/wiki/User:Jkurik/Fedora_Release_Life_Cycle
(505754), you can use the URL
https://fedoraproject.org/w/index.php?diff=505754=488139.
This is not as convenient (or obvious :-)) as your approach,
but it does not depend on a) somebody copying the original
first and b) not making a mistake when copying & pasting.

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

Re: Security updates and batched pushes

[Tim Landscheidt]

Kevin Fenzi  wrote:

> […]

 I really don't understand why we do this "batched" thing to begin with.

>>> To reduce the constant flow of updates that are very minor or affect
>>> very few mixed in with the major updates that affect lots of people and
>>> are urgent.

>> But the users were already able to opt to update only weekly. So why force a
>> fixed schedule on them?

> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo. If we
> update a repo for some minor enhancements it means everyone in the world
> has to pay for that. If we just push all those out every tuesday and
> don't update those unless there's something urgent we save everyone a
> lot of bandwith and us computing time/resources.

> […]

BTW, are there technical reasons why the metadata is updated
en bloc and not incrementally like for example delta RPMs,
or is it just that nobody bothered to implement something
like that yet for metadata?

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

Re: Please stop re-adding gtk-update-icon-cache scriptlets (for Fedora)

[Tim Landscheidt]

Igor Gnatenko  wrote:

> […]

>> I was not fully aware of this and I've personally hit this difficulty
>> not on my proposal of the remove hicolor icon caches but on proposing,
>> for example, OpenIPMI or readline changes.
>> Most of my changes were by those packages maintainers simple discarded
>> (readline 100% and in case OpenIPMI ~50%).
>> I'm not trying to blame anyone here but all this only *result* of some
>> assumptions that master branch must be fully compatible with more than
>> one distribution or more than one distribution versions.

> Well, I think because this is simply easy. If we separate changelog to other
> file / make it auto-generated, then it should be easier for people to maintain
> f26/f27/master branches separately. Right now, cherry-picking is never cleanly
> applies due to changelog. Well, we need to do something with Release field as
> well, I don't know why it is still not auto-generated...

> […]

GNU had the same problem in various projects and came up
with a Git merge driver for changelogs
(http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c).
Now that is a text parsing orgy in C, probably provably cor-
rect, but it suggests that a simpler solution for RPM spec
files should be very feasible.

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

Re: RPM packaging and ldconfig handling

[Tim Landscheidt]

Tomasz Kłoczko  wrote:

> […]

> Who said that I'm demanding something?
> Look one more time on https://pagure.io/packaging-committee/issue/736
> Igor took this tasks VOLUNTARILY and started working on necessary specs 
> before I've delivered batch of patches.
> When I found that number of already done modifications is trashing already 
> many patches which I had prepared it was no sense to be (as me) involved in 
> helping finish
> this.
> Now still is not finished about 20%.
> Just please answer on the questions:
> - Who will finish this?
> - Why it is done so badly?
> - What is the sense submitting more such mass changes if it is good chance 
> that they'll be not finished as well? (and now you are telling me that I'm 
> this bad guy because
> I've been showing those "naked pictures" to other people)

You can help move this forward by publishing the script(s)
you used (or the patches that still apply cleanly if you
wrote them manually).

Also, just to state the obvious for most: This is some tidy-
ing up.  It's good if it's done, but it is not blocking any-
thing.  If someone already has patched "only" 20 % of the
specs, that is good, not bad, because the work to be done
has decreased by a fifth.

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

Re: RPM packaging and ldconfig handling

[Tim Landscheidt]

Tomasz Kłoczko  wrote:

> […]

> This is like with with problems on taking care of the production issues or 
> faults.
> Always needs to be someone who is controlling whole situation but this person 
> does not need to to person doing all OS, HW, app, db related things which 
> needs to be
> changed.
> At the end such person in bigger organisation sometimes is taking 
> responsibility to teach other technical personnel about how to prevent 
> similar faults.

Unfortunately, progress in Fedora and similar projects is
not made by telling people what they are doing wrong, but by
doing The Right Thing™ yourself or in collaboration with
others.  And even if one is reporting a fault, there are
ways to enable someone to fix that fault and there ways to
overwhelm them with superfluous information that makes their
work harder.

For example, take the first line of your text I quoted
above.  I can tell you that you used "with" there twice, or
I can hide that nugget in a long diatribe about the English
language, HTML mail and whatever.  If your time is limited,
you will probably prefer one over the other.

Or, to paraphrase perlstyle(1): Be explicit.  Be concise.  Be
nice.

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

Re: RPM Lint Errors

[Tim Landscheidt]

Greg Hellings  wrote:

> I have a package that includes a group of Ansible playbooks embedded into a 
> Python module. The playbooks include a number of templates that are designed 
> to be
> uploaded into remote systems, templated out with appropriate variables, and 
> then executed on the remote system.

> Since the templates are designed to become executables on the remote hosts, 
> they have she-bang lines as appropriate (mostly shell scripts, a few Python 
> scripts). However,
> they are not yet supposed to be executed, since they are template files that 
> generate the executable files.

> Rpmlint flags these files as executables (because of the she-bang) that lack 
> the executable flag (because that flag will be set after templating and 
> upload). Is there a way for
> me to specifically tell rpmlint to ignore that particular error for those 
> files so I can avoid these false positives? Do I just have to pony up and 
> deal with it?

You should be able to ignore certain errors with an
"addFilter()" statement in one of rpmlint's configuration
files (cf. /usr/share/doc/rpmlint/README.md or
https://samthursfield.wordpress.com/2012/02/07/rpmlint/ for
an example).  AFAIUI "fedpkg lint" should consult a .rpmlint
file in the RPM's directory, and I assume the build infra-
structure will do that as well, but I never tested that.

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

/results_* and /*.rpm in .gitignore (was: Source tarballs are being placed in git?)

[Tim Landscheidt]

Todd Zullinger  wrote:

> […]

> For example, the rpmlint's .gitignore contains the
> following¹:

> /*.rpm
> /results_rpmlint/
> /rpmlint-*/
> /rpmlint-*.tar.gz

> […]

Apropos: Many .gitignores only reference the source files,
i. e. not /results_${name} or /${name}-*.rpm.  Therefore I
usually add the latter two to .git/info/exclude and I wonder
how others handle this.

Will fedpkg (and its backend) always create results_${name}
and ${name}-*.rpm in the top directory or is the destination
configurable?  If the former, it would make sense to add
them to .gitignore "for everybody", e. g. recommend that in
the Packaging Guidelines.  If not, I'd find it useful to
have "fedpkg clone" add them to the initial
.git/info/exclude.

Are there other approaches to have a clean "git status" dur-
ing "normal" packaging development, tests, etc.?

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RPYIISZS6625VHMSDW3C6VRXUCQ57RIX/

Re: qarte - compilation fails

[Tim Landscheidt]

"Martin Gansser"  wrote:

> when compiling qarte-4.4.0 with this spec file
> https://martinkg.fedorapeople.org/Packages/test/qarte.spec

>  '[' noarch = noarch ']'
> + case "${QA_CHECK_RPATHS:-}" in
> + /usr/lib/rpm/check-buildroot
> + /usr/lib/rpm/brp-compress
> + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
> + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
> Compiling 
> /home/martin/rpmbuild/BUILDROOT/qarte-4.0.0-1.fc27.x86_64/usr/share/qarte/arteconcert.py
>  ...
>   File "/usr/share/qarte/arteconcert.py", line 385
> def update_pitch(self, *args, html=False):
>  ^
> SyntaxError: invalid syntax

> error: Bad exit status from /var/tmp/rpm-tmp.rp9wQD (%install)

> only when i comment the following line, the program compiles fine:
> #cp -p *.py* %{buildroot}%{_datadir}/%{name}

To state the obvious: arteconcert.py is Python 3,
brp-python-bytecompile uses /usr/bin/python (which is most
likely Python 2):

| [tim@passepartout ~]$ python2 -m py_compile 
~/RPMS/BUILD/qarte-4.0.0/arteconcert.py
|   File "/home/tim/RPMS/BUILD/qarte-4.0.0/arteconcert.py", line 385
| def update_pitch(self, *args, html=False):
|  ^
| SyntaxError: invalid syntax

| [tim@passepartout ~]$ python3 -m py_compile 
~/RPMS/BUILD/qarte-4.0.0/arteconcert.py
| [tim@passepartout ~]$

Following the advice from
https://fedoraproject.org/wiki/Packaging:Python_Appendix#Manual_byte_compilation,
prepending:

| %global __python %{__python3}

to your qarte.spec works, but there may be cleaner solu-
tions.

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

Local test VMs (was: Status of OwnCloud/NextCloud)

[Tim Landscheidt]

James Hogarth  wrote:

> […]

> FIrst thing when I fired up my test harness was that F28 has changed,
> and thus broken, kickstart for the user option compared to a standard
> minimal that worked going back to F22 and EL7 so that had to be
> debugged and fixed ... done

> Next things is the ansible that I use to test ... well the lovely
> folks jumping the gun on dropping python2-* packages is making life
> painful since ansible still uses python2 by default and not everything
> support python3 yet. There is no python2-firewall anymore for the
> ansible firewalld module ... yay another silly thing to work around!

> […]

BTW, it would be very nice if there was (maintained) docu-
mentation on how to generate Fedora VMs and for example use
Ansible to configure complex interactive test setups.
James's article
(https://fedoramagazine.org/day-life-fedora-packager/) is
mouth-watering, but lacking detail and probably outdated by
now.

I'm sure that many Fedora packagers have their own ("obvi-
ous") solutions, but having something general could lower
the bar for new packagers who do not want to dive deep into
all the minutiae just to test a release.

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

Re: some man pages have bugs, can't be grep'd

[Tim Landscheidt]

Chris Murphy  wrote:

> I've been seeing this since clean installing Fedora 30. I don't recall
> ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded
> system (is now the clean installed system).

> [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity
> :176: warning [p 3, 0.8i]: cannot adjust line
> [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr
> [chris@flap mantest]$ ll
> -rw-rw-r--. 1 chris chris62 Jul 16 14:24 rpm.stderr
> -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout

> Is this a bug that should be reported against rpm or something else?
> I'm certain I've seen it in other man pages, but offhand I can't find
> another example.

(This also happens on Fedora 29, JFTR.)  The warning seems
to stem from this line in rpm.8:

| […]
| 175 The default \fIFILELIST\fR is
| 176 
\fI/usr/\:lib/\:rpm/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\:macros.d/\:macros.*\fR:\:\fI/usr/\:lib/\:rpm/\:platform/\:%{_target}/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\
| 176 
:fileattrs/\:*.attr\fR:\:\fI/usr/\:lib/\:rpm/\:redhat/\:macros\fR:\:\fI/etc/\:rpm/\:macros.*\fR:\:\fI/etc/\:rpm/\:macros\fR:\:\fI/etc/\:rpm/\:%{_target}/\:macro
| 176 s\fR:\:\fI~/.rpmmacros
| 177
| […]

This line is too long for the standard layout.  It already
has hints ("\:"; zero-width break points) where it should be
broken, but these seem to be ignored.  So prima facie RPM
has done everything right, and there is an error somewhere
in the groff/man ecosphere.

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

Re: What is the most time consuming task for you as packager?

[Tim Landscheidt]

Josh Boyer  wrote:

>  I am looking for challenges for upcoming year - what I and my team should 
> enhance. I have some ideas, but I want to hear
>  yours.

>  What you - as Fedora packager - find most time consuming on packaging?
>  Where you will welcome more simplicity or automation?

> Deciphering whatever packaging guidelines have changed since the last time I 
> looked and trying to figure out how to update packages to adhere to them even 
> though nobody audits the package set
> anyway.

> […]

I really like Debian's "Standards-Version" field
(https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-standards-version)
in that context; it does not tell what changes in the guide-
lines have occured, but it makes it unambiguous what guide-
lines the package /should/ comply with.

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

Re: src.fedoraproject.org branch conversion status

[Tim Landscheidt]

Todd Zullinger  wrote:

> […]

> In case it's helpful (and not better documented elsewhere),
> it's possible to rename your existing local master branch to
> rawhide and adjust the upstream tracking branch.

> In a typical dist-git clone from the rpms tree, you'd do
> this:

> git fetch && git branch -m master rawhide && git branch -u origin/rawhide 
> rawhide

> The -u option is the short form of --set-upstream-to.

> That should make the switch relatively simple for folks, I
> hope.  It's easier than making a fresh clone, for me.

For simple cases, "git checkout rawhide && git branch -d
master" should also work.

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

Re: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

[Tim Landscheidt]

Miro Hrončok  wrote:

> […]

>> 2. change %check not to rely on unpackaged files in buildroot

> That one is non-trivial and depends on the reason it is needed.

> For example, what is common for Python "namepsace" packages, e.g. 
> pkg_name.foo.

> 1) We want to test installed files, not what is in $PWD, so we set PYTHONPATH 
> to
>%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib} and we
>(try hard to) exclude $PWD from it. This is crucial to ensure the files
>we actually ship are working and the installed file set is complete.
>Our macros do this for the packagers.

> 2) The %{python3_site...}/pkg_name/ directory and
>%{python3_site...}/pkg_name/__init__.py and
>%{python3_site...}/pkg_name/__pycache__/ and
>%{python3_site...}/pkg_name/__pycache__/__init__...pyc
>files must be present in %{buildroot} to successfully run the tests.

> 3) The files from (2) must be excluded from the package because *pkg_name* 
> owns
>them, not *pkg_name.foo*.
>We Require the "toplevel" *pkg_name* package from *pkg_name.foo*.
>The files are not bit-by-bit+metadata identical,
>so both packages cannot ship them.

> […]

My understanding of the RPM spec sections was always that:

- "%prep" is for "./configure",
- "%build" is for "make",
- "%install" is for "make install", and
- "%check" is for "make check".

"make check" (usually executed /before/ "make install")
works in and on the working directory
(https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets).

To test that the resulting binary package is functional, an-
other venue is needed, and in the case of Fedora, for that
purpose Fedora CI was created
(https://docs.fedoraproject.org/en-US/ci/tests/).

That feels like a much cleaner solution than installing some
files, testing and then not shipping them because the test
environment will be the same as a user's who just installed
the package instead of being in the process of building the
package.

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Tim Landscheidt]

Kevin Fenzi  wrote:

> […]

> The purpose here is to make the Fedora project a more welcoming place to
> people who _do_ find those terms unwelcome. That doesn't mean everyone
> does. It means we want to be welcoming and not jerks.
 ^
> I'm personally happy to do things to make people more welcome.
> Even if they are small things and cause a small amount of work for us
> existing contributors.

> […]

"Disagreement is no excuse for poor behavior and poor man-
ners."

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

Please remove "-i" from "%forgemeta" templates on wiki

[Tim Landscheidt]

Hi,

using "%forgemeta" with the "-i" option causes debug infor-
mation to be output which leads to %changelog entries being
garbled:

| [tim@passepartout ~/.cache/rpm-specs]$ grep -l '^.*%forgemeta.\+$' *.spec | 
xargs -r fgrep 'Packaging variables read or set by %forgemeta'
| ddiskit.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| ddiskit.spec:* Mon Jul 27 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| ddiskit.spec:* Tue May 26 2020 Miro Hrončok  - Packaging 
variables read or set by %forgemeta
| ddiskit.spec:* Tue Jan 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| gmediarender.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| gmediarender.spec:* Mon Jul 27 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| kabi-dw.spec:* Wed Jan 29 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Feb 02 2021 Christian Dersch  - 
Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libindi.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Mon Feb 08 2021 Pavel Raiskup  - 
Packaging variables read or set by %forgemeta
| libpqxx.spec:* Tue Jan 26 2021 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Sat Aug 01 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| libpqxx.spec:* Tue Jul 28 2020 Fedora Release Engineering 
 - Packaging variables read or set by %forgemeta
| [tim@passepartout ~/.cache/rpm-specs]$

Therefore, the templates at
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_forges_hosted_revision_control
use "%forgemeta" without options and note:

| #  – remove  “-i” and “-v” before commit

However, the templates on the wiki page at
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples
use "%forgemeta -i" and do not clarify that this needs to be
amended before committing.

It would be nice if the wiki page could be updated to avoid
luring packagers into using these templates, perhaps with a
hatnote that the content is historical (?) and only the tem-
plates in the packaging guidelines should be used.

TIA,
Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Please remove "-i" from "%forgemeta" templates on wiki

[Tim Landscheidt]

Kevin Kofler via devel  wrote:

>> I don't think "documentation is harder to keep up to date there" is right,

> Well, I guess it does not apply that much to the pages which were already in
> an ACL-locked namespace, in particular, the packaging guidelines that can
> only be edited by FPC. I cannot speak for the FPC whether it is easier,
> harder, or the same difficulty to do the edits now vs. on the wiki.

> But as far as I can tell, the move also affects wiki contents that were not
> previously ACL-locked, and for those, it makes a big difference whether
> anyone with a FAS account can just edit them on the wiki or whether one has
> to dig up the source code in some Git repository and send a pull request
> (and not get any instant feedback whether the changes even compile without
> also installing some documentation processing toolchain). I guess most
> people can only try to get someone else to do the editing work, or will just
> shrug it off as "it's wrong and I cannot edit it".

> Wikis have a much lower barrier to entry than setups of the
> docs.fedoraproject.org type.

> […]

Personally, I cannot edit the wiki, but can submit pull re-
quests for the docs (and have done so).

Maybe due to my GNU socialization, I also really like good,
single-truth documentation.  Where wikis are curated to a
degree that makes them usable, the effort spent seems com-
parable to a Git forge (except that as a user, one cannot
discern a wiki edit by someone who knows what they are doing
from one that was overlooked or one that someone wants to
fix in the future, but has not gotten around to it).

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: Please remove "-i" from "%forgemeta" templates on wiki

[Tim Landscheidt]

Otto Urpelainen  wrote:

> […]

> Like I said, I am not expert in forge macros, so if anybody thinks that
> my edit removal was a bad idea, wiki has an undo button.

Thanks!

Tim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Tim Landscheidt]

Zbigniew Jędrzejewski-Szmek  wrote:

> […]

>> - use dynamic buildrequires to detect what plugins are needed

> My problem is that the binary is linked to the libpython3.12.so shared
> library… The detection part is easy, the hard part is how to have the
> binary work when the shared lib is not installed.

Quick 'n' dirty: Have two binaries, unconditionally call
add-determinism-python for *.pyc files, either from
add-determinism or the BRP macro (which essentially should
be called when %__brp_python_bytecompile is called?), rely
on the packager to build-require add-determinism-python or
require that from python3-devel (the missing binary should
fail the build otherwise).

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

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Tim Landscheidt]

Vít Ondruch  wrote:

 %patch otoh (now) is a regular (though internally
 implemented) macro that is expanded with other macros
 and though can be used in other macros and expressions.

>>> Do I read correctly that we can now use `%patch` in
>>> e.g. `%check` section? Interesting. Is this documented?

>> No, while %patch and %setup *could* be made available
>> elsewhere now, they are still only available in %prep
>> because that's the only place where they make sense.

> Working with Ruby, which is interpreted language, there are
> cases where we want to patch tests, while we want to keep
> them in their original form in the package. This might sound
> weird, but the thing is that for running tests, we might be
> limited by infrastructure. E.g. Koji does not have internet
> access, builders are slow, etc. So we might want to apply
> some patch to workaround such issues.

> I have no hopes convincing you. But thank you for clarification.

This feels like the tests should be patched (and these
patches upstreamed) to behave differently depending on some
option, and the spec file should then use this option to
trigger the correct one.  I don't know enough about Ruby to
suggest The Way™ to pass this option; but usually
environment variables will do.  (Other test suites have tags
that can be used to select tests that should (not) be run
which might be another (upstreamable) solution.)

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

Re: SPDX Statistics - L'Aigle meteorite edition

[Tim Landscheidt]

John Reiser  wrote:

>> New projection when we will be finished is 2025-04-06 (+5
>> days from last report).  Pure linear approximation.

> Such a linear approximation, based on the entire tracked history,
> is the second worst possible estimate.  (The worst possible estimate
> is the output of a random date generator.)

> Financial markets and other arenas using serious statistical forecasting
> have known for decades that it is much better to estimate by assuming
> a rate equal to the moving average rate over a fixed-length relevant
> period.  Repeatedly estimating based on the entire history does not
> meet the fixed-length requirement, because the entire history grows.
> Typical periods range from a small number of months to one year.
> For Fedora, one relevant period might be six months, the
> interval between scheduled releases.  Also useful are 90 and
> 120 days.

> Graphing the estimated completion date based on such a moving
> average rate would be much more informative and useful than the
> estimated dates which have been published so far.

Maybe I misunderstood the original post, but I did not per-
ceive the intent of the data's publication to be informative
and useful, but to motivate (converting the licenses).

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

Re: Three steps we could take to make supply chain attacks a bit harder

[Tim Landscheidt]

Kevin Kofler wrote:

>> This is not helpful in the slightest and the tone is not appreciated at
>> all.

> Well, I have been arguing against this exception (exempting prebuilt
> autotools output) from the "no prebuilt blobs" rule for years, and it
> saddens me that something like this had to happen for Fedora to finally
> realize that that exception has always been a bad idea.

> […]

CMIIW, but it would not have made any difference as the
source code had been shipped as part of the tar ball and
auto(re)conf would have happily integrated it into the next
build.  I suspect that a modification to CMakeLists.txt and
its includes would not have been detected either; even a
daring, but obvious change in the 3+ lines of source
itself might have gone unnoticed.

A major factor seems to have been the discrepancy between
"the source code" at GitHub & Co. that was probably
scrutinized by many eyes and the shipped, but different
artifact.  So one step (as a inter-distribution effort)
could be to continuously automatically compare shipped
artifacts with their "make dist" equivalents and publishing
the results.

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

Re: some man pages have bugs, can't be grep'd

[Tim Landscheidt]

I wrote a very long time ago:

>> I've been seeing this since clean installing Fedora 30. I don't recall
>> ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded
>> system (is now the clean installed system).

>> [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity
>> :176: warning [p 3, 0.8i]: cannot adjust line
>> [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr
>> [chris@flap mantest]$ ll
>> -rw-rw-r--. 1 chris chris62 Jul 16 14:24 rpm.stderr
>> -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout

>> Is this a bug that should be reported against rpm or something else?
>> I'm certain I've seen it in other man pages, but offhand I can't find
>> another example.

> (This also happens on Fedora 29, JFTR.)  The warning seems
> to stem from this line in rpm.8:

> | […]
> | 175 The default \fIFILELIST\fR is
> | 176 
> \fI/usr/\:lib/\:rpm/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\:macros.d/\:macros.*\fR:\:\fI/usr/\:lib/\:rpm/\:platform/\:%{_target}/\:macros\fR:\:\fI/usr/\:lib/\:rpm/\
> | 176 
> :fileattrs/\:*.attr\fR:\:\fI/usr/\:lib/\:rpm/\:redhat/\:macros\fR:\:\fI/etc/\:rpm/\:macros.*\fR:\:\fI/etc/\:rpm/\:macros\fR:\:\fI/etc/\:rpm/\:%{_target}/\:macro
> | 176 s\fR:\:\fI~/.rpmmacros
> | 177
> | […]

> This line is too long for the standard layout.  It already
> has hints ("\:"; zero-width break points) where it should be
> broken, but these seem to be ignored.  So prima facie RPM
> has done everything right, and there is an error somewhere
> in the groff/man ecosphere.

That analysis was wrong: "cannot adjust line" does not mean
that the line is too long, but rather that there are no spa-
ces that groff can expand to adjust (justify) the line.

For rpm(8) this was worked around by formatting the default
value as a code block, with line breaks after each colon,
thus not requiring the lines to be adjusted/justified.

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

Re: perl: warning: Setting locale failed.

[Tim Landscheidt]

Petr Šabata  wrote:

>> > Adding
>> > BuildRequires: glibc-all-langpacks
>> > to all the *.specs obviously fixes this issue. However, I doubt this is
>> > right, because I think these warnings originate from some rpm-internal
>> > scripts and not from the packages.

>> I suspect you're running into the glibc-langpacks-all feature:
>> * 
>> https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
>> *
>> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VRIO4YQV2B2G2DUUYNRTVYQDFCMZSZGX/#B5SEICGIAETNXPRIE6VZT2VDKXRLJWSP

> The locale shouldn't be set to en_US.utf8 is glibc-langpack-en is
> not present.  Where does it come from?

Judging from $LANG=de_DE.UTF-8 in my mock, it gets copied
from the "host" environment.  And indeed,
mock/py/mockbuild/util.py has two instances of:

| env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')

Adding:

| config_opts['environment']['LANG'] = 'C'

to ~/.config/mock.cfg seems to solve that.

Tim
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: perl: warning: Setting locale failed.

[Tim Landscheidt]

I wrote:

> […]

> Adding:

> | config_opts['environment']['LANG'] = 'C'

> to ~/.config/mock.cfg seems to solve that.

That was meant to say:

| config_opts['environment']['LANG'] = 'LANG=C.UTF-8'

Tim
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[rpms/perl-PAR-Packer] PR #1: Remove obsolete requirements for %post/%postun scriptlets

[Tim Landscheidt]

scfc opened a new pull-request against the project: `perl-PAR-Packer` that you 
are following:
``
Remove obsolete requirements for %post/%postun scriptlets
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-PAR-Packer/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Macro for a binary package's documentation directory name?

[Tim Landscheidt]

Hi,

on Fedora 38, the binary package python3-collada ships a
broken symlink (CHANGELOG.rst):

| $ rpm -qlv python3-collada | grep /usr/share/doc/python3-collada
| drwxr-xr-x2 root root0 Jan 20  2023 
/usr/share/doc/python3-collada
| -rw-r--r--1 root root  428 Nov 12  2021 
/usr/share/doc/python3-collada/AUTHORS.md
| lrwxrwxrwx1 root root   18 Nov 12  2021 
/usr/share/doc/python3-collada/CHANGELOG.rst -> docs/changelog.rst
| -rw-r--r--1 root root 1095 Nov 12  2021 
/usr/share/doc/python3-collada/README.markdown
| $

So I wanted to fix this by:

| diff --git a/python-collada.spec b/python-collada.spec
| index 1f6a6bf..6178381 100644
| --- a/python-collada.spec
| +++ b/python-collada.spec
| @@ -58,6 +58,7 @@ as well as in-place editing.

|  %install
|  %py3_install
| +install -p -m 0644 -t '%{buildroot}%{_pkgdocdir}' -D CHANGELOG.rst


|  %check
| @@ -66,7 +67,8 @@ as well as in-place editing.

|  %files -n python%{python3_pkgversion}-collada
|  %license COPYING
| -%doc AUTHORS.md CHANGELOG.rst README.markdown
| +%doc AUTHORS.md README.markdown
| +%doc %{_pkgdocdir}/CHANGELOG.rst
|  %{python3_sitelib}/*

But this installs CHANGELOG.rst in
/usr/share/doc/python-collada (not python3-collada):

| $ rpm -qlpv noarch/python3-collada-0.7.2-5.fc38.noarch.rpm | grep /doc
| -rw-r--r--1 root root 8133 Nov 12  2021 
/usr/share/doc/python-collada/CHANGELOG.rst
| drwxr-xr-x2 root root0 Jan 20  2023 
/usr/share/doc/python3-collada
| -rw-r--r--1 root root  428 Nov 12  2021 
/usr/share/doc/python3-collada/AUTHORS.md
| -rw-r--r--1 root root 1095 Nov 12  2021 
/usr/share/doc/python3-collada/README.markdown
| $

as %_pkgdocdir is defined by appending the source package's
name, not the binary's name:

| $ grep -R pkgdocdir /usr/lib/rpm
| /usr/lib/rpm/redhat/macros:%_pkgdocdir %{_docdir}/%{name}
| $

But obviously, rpm(build) must know the binary package's di-
rectory name as it installs %doc files given by only by
their base filename there (AUTHORS.md and README.markdown in
this example).

So how/with which macro can I access a binary package's do-
cumentation directory name in a spec file?

(Posting this on python-devel as %pkgdocdir is used in some
Python packages as well and there is (always?) a difference
between the source and binary package name.)

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

[rpms/perl-AnyEvent-I3] PR #1: Fix URL

[Tim Landscheidt]

scfc opened a new pull-request against the project: `perl-AnyEvent-I3` that you 
are following:
``
Fix URL
``

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