lots of times, I see name "copr", "Copr", or "COPR" used somewhere but it's
almost never used correctly for the given context. So I would like to make
it clear, what's the correct way to write it down to get the meaning right.
"Copr" or "COPR" = service providing space for community projects
"copr" or "Copr project" = a single community project
So there are two variants how to refer to service ("Copr" and "COPR").
And there are two variants how to refer to a singular project ("copr" and
----- (minor additional notes to be ignored) -----
When referring to a singular project, just saying "copr" is enough. "co"
stands for "community", "pr" stands for "project".
When you write down "Copr project", it literally means "Community projects
project" so it's a bit redundant to write it down that way.
If you liked to refer to the Fedora instance of Copr service, you would
write "Fedora Copr".
If you liked to ignore the previous rule or made it nice for typography,
you would write "fedora copr" like our logo does. This is also good for IRC.
I don't really mind how people write it down but I think it's good to
provide at least some guide in case somebody needs to think about this :).
I'm upgrading sbt and scala packages to 0.13.13 and 2.11.11
respectively. I am looking for a way to point to a jar file for
jansi-native without hard-coding the path (/usr/lib/java).
Is there a macro available that points to that path? what is the best
option to avoid hard-code this specific path?
I'm exploring the Fedora Modularity world and would like to know
whether it's possible to have two different module streams install two
different sets of packages? If that's possible, would installing one
stream remove the packages from the other stream even though the set of
packages don't overlap? I'm aware that it's not a goal of modularity to
support parallel installability. But what if the packages themselves
already allow parallel installability?
Module name: jdk
Streams: 8, 11
1) "dnf module install jdk:8/default" installs these packages:
2) "dnf module install jdk:11/default" installs these packages:
After 1) *and* 2) would I have both module streams' packages on my
system? Would I have only the set from 2) with 1) removed?
Thanks for your help!
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
To convert UTC to your local time, take a look at
date -d '2018-07-02 15:00 UTC'
Links to all issues to be discussed can be found at:
= Discussed and Voted in the Ticket =
None have reached 7 days yet.
= Followups =
= New business =
#topic #1917 F29 System Wide Change: Make BootLoaderSpec-style
configuration files the default
= Open Floor =
For more complete details, please visit each individual
issue. The report of the agenda items can be found at
If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
a new version of gdbm is out. So I would like to update gdbm in
(Important note to my question is that gdbm is in minimal buildroot.)
I've planned to do following (please correct me if I'm wrong it would
result in disaster):
1. build compat-gdbm package with current content of gdbm package
2. rebase gdbm package in rawhide (soname is changed!) and wait for
MassRebuild to rebuild other packages to rely back on gdbm instead
Gdbm was also updated before F28 rebuild. But some packages failed to
build. So they still require compat-gdbm.
$ dnf repoquery --alldeps --whatrequires compat-gdbm
What to do? Is it fine to left these three packages as broken and
normally update gdbm?
I think I finally found a scenario where building some of my (and others')
packages as modules would be beneficial.
The situation is:
- The syncthing package has a lot of golang dependencies.
- Some of them are too old in fedora, even in fedora rawhide, and some of
them have not been touched in years.
- However, some other packages may depend on those older versions, or the
packagers don't have time to check for compatibility.
The idea for a solution I came up with:
- Build syncthing as a module.
- Add "syncthing" branches to all incompatible dependencies (I guess I have
to request commit/admin access to do that for packages I don't own yet?).
- Update those branches to use the exact same commit as the vendored
sources in upstream syncthing.
- Use those modules as dependencies for the syncthing module.
Is that a valid, feasible use case of modularity?
so I'm following "Join the package collection maintainers", I'm at the
late phase when I've submitted new package, ran `fedpkg build` from
master, koji is happy, etc.
Now I tried to just follow with "Update Your Branches (if desired)", but
that fails, because F27 and F28 branches don't exist -- OTOH I don't
expect them to spawn from nowhere; both versions are already released,
so I wonder if it's even possible to add new ones.
So what should I do? Just forget about F27/F28 and wait for F29? Do
[something] to have the F27/28 branches created?
And should the guide be updated? (It seems that this will happen to
every new package)
PS: I don't want to sound impatient; I'm OK if the answer is "wait" or
"jump through these hoops", I'm asking because I want to notify upstream
yet I kinda don't know what can I tell them. :D
Alois Mahdal <amahdal(a)redhat.com>
Platform QE Engineer at Red Hat, Inc.
#brno, #daemons, #preupgrade