Can we stop saying "dist-git" in our docs? Nobody knows what that is.
The service at https://src.fedoraproject.org is clearly branded as "Fedora
Using the jargon "dist-git" in our documentation is simply confusing, since
it doesn't match what the service calls itself, and doesn't match any user
interface packagers use. As far as I can tell, only people with a deep
understanding of Fedora's infrastructure (which does not seem to be most
packagers) know what this term means.
For example, in
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb , instead
of saying "Browse to your project on Pagure over Dist-Git (Top Level
link)", we should say: "Browse to your project's Package Source repository
And, instead of saying "How do I request commit access to a dist-git
repo?", we should say: "How do I request commit access to a Package Source
Using special/internal/historical jargon, especially when that jargon
doesn't correspond to the current packager experience when interacting with
these services, only leads to confusion and should be avoided.
If we really need to use the term "dist-git" in the wiki, it should at
least link to a glossary page that says "Dist-Git: A term which refers to
the Fedora Package Sources repository hosting service at
https://src.fedoraproject.org built on Pagure (an open source git
repository management service)", instead of just assuming everybody seeing
the term "dist-git" knows what that term is and where it came from.
If we can avoid jargon with this term and other similar terms, it'd be a
big help to our documentation.
If this seems reasonable, I'd be happy to help start editing some of the
wiki pages... but it'd be helpful if everybody maintaining infrastructure
documentation was on the same page.
We are adding some features to container projects for User Namespace
support that can take advantage of XFS Reflink. I have talked to some
of the XFS Reflink kernel engineers in Red Hat and they have informed me
that they believe it is ready to be turned on by default.
I am not sure who in Red Hat I should talk to about this? Whether we
should turn it on in the installer or in the mkfs.xfs command?
Who should I be talking to? To make this happen.
Is there a recommend way to get libtool to pass through all flags
specified in CFLAGS and LDFLAGS unchanged, and have the GCC compiler
driver sort out which flags to pass to the compiler/assembler/linker?
I've got two updates sitting in F26 and F27 updates-testing:
I can't push either of them to batched or stable (despite them being in
-testing for over 10 days now), because "no test results found".
Which is really annoying and the error message is ... rather unhelpful,
since it just tells me "I can't do this _shrug_", but not how to fix it.
I guess this is caused by a bug in one of the involved components?
Where can/should I report this issue?
How can I fix this (if I can do it myself), or does somebody with more
power have to step in to fix this?
So I went to request a new branch of an existing package only to find out
fedrepo-req-branch, which hasn't been around that long is already
depreceated and the facility brought into fedpkg... so:
$ fedpkg request-branch <branch>
Could not execute request_branch: The "token" value must be set under the
"fedpkg.pagure" section in your "fedpkg" user configuration
Ok, so where does that get stored?
$ man fedpkg
(not in there...)
$ vi /usr/share/doc/fedpkg/README
(not in there...)
I figured out somewhere else that the default config is in
/etc/rpkg/fedpkg.conf (In /etc/rpkg? That's intuitive!) but I didn't want
to add my token to the site wide config so the search continues...
$ rpm -ql fedpkg
$ vi /usr/lib/python2.7/site-packages/fedpkg/__main__.py
default_user_config_path = os.path.join(
os.path.expanduser('~'), '.config', 'rpkg', '%s.conf' % cli_name)
Now which token do I need? The one from the src.fedoraproject.org pagure or
Oh and the tokens expire all the time and don't seem to have any helper
scripts to automate updating of the tokens so I have to remember where they
all are and manually edit them every time...
Not coming from a programming background I found the learning curve pretty
steep when I first tried to become a packager, I'm not sure I wouldn't have
given up if I had to do it now.
Regarding the inclusion of the fedora-workstation-repositories package in
F28, is there currently a policy in place against including it as a
dependency? From what I understand from the recent fedora magazine article
<https://fedoramagazine.org/third-party-repositories-fedora/> and the policy
the purpose of distributing the third-party repositories an rpm is to
ensure that a user must enable them explicitly.
Is there some some preventative measure in place to protect users from the
package being pulled in silently as a dependency? If repository-enabling
rpms are to become acceptable cases for package submissions, what
considerations are being taken to ensure such submissions are tracked and
Apologies if this has been addressed before, but I haven't been able to
find any documentation on the subject.
I'm upgrading libicu to 61.1 for rawhide, which as usual comes with
a soname bump. I requested a side target f29-icu for the builds, I'll
ask Pete Walter (who already did it for 60.1) to help with rebuilding
the dependent packages, or another proven packager if he's not
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
I was recently surprised that `dnf install boost` brings in python2.
It is like that because boost brings in bost-python and that is python2
ATM. I've reported it as a bug, because it bugs me :)
However Jonathan Wakely (the boost maintainer) says this needs broader
So I'm asking here on devel:
Should the 'boost' metapackage install boost-python at all? If so, what