I'm trying to update the rpcsvc-proto package.
When I try to create a new update, the system
only gives me rpcsvc-proto-devel as a choice
Where do I open up a ticket to get this taken
i tried to update a few of my packages for f28, but this fails with this message:
$ fedpkg clone nuvola-app-jango; cd nuvola-app-jango; git merge master
$ fedpkg switch-branch f28
Could not execute switch_branch: Unknown remote branch origin/f28
f29 package builds fine:
How can i solve this ?
On 29 May 2018 at 15:49, Fedora Rawhide Report <rawhide(a)fedoraproject.org>
> Package: dnf-2.7.5-15.fc29
> Old package: dnf-2.7.5-12.fc29
> Summary: Package manager
> RPMs: dnf dnf-automatic dnf-data dnf-yum python2-dnf python3-dnf
> Added RPMs: dnf-data
> Dropped RPMs: dnf-conf
> Size: 1.82 MiB
> Size change: 342.44 KiB
> * Fri May 25 2018 Martin Hatina <mhatina(a)redhat.com> - 2.7.5-13
> - Rebase to dnf from dnf-2-modularity-6 release.
> * Fri May 25 2018 Martin Hatina <mhatina(a)redhat.com> - 2.7.5-14
> - Fix patch applying.
> * Mon May 28 2018 Martin Hatina <mhatina(a)redhat.com> - 22.214.171.124
> - Do not require libdnf
It is yet another hidden change not listed in above.
python3-dnf subpackage started (again) require deltarp.
Previouselly is spec was "Recommends: deltarpm" and now it is (again)
dnf maintainer(s) knows about this
However for some reason looks like they prefers to apply kind of ostrich
Because today has been published next dnf release I'm going to repeating
the bugzilla ticket question about deltrpm question but this time
I want to believe that it was nothing more than trivial mistake because
Fedora does not offer repo with delta files so fixed instead weak
dependency does not make here IMO sense, and such change only pointlessly
enlarges the size of the @core.
Tomasz Kłoczko | LinkedIn:http://lnkd.in/FXPWxH
Previously discussed several times, most recently:
* 2015 https://firstname.lastname@example.org...
* 2011 https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.htm...
Unison is a fairly widely used file synchronization package. Think of
it as a more efficient, multi-directional 'rsync'.
Unison has the unfortunate property that versions of Unison are not
compatible with each other unless they have the exact same major.minor
release. eg. Unison 2.40.128 is compatible with Unison 2.40.102, but
incompatible with Unison 2.48.3 (the latest upstream).
The reason that matters is you might be running Unison across multiple
machines, running different Linux distros, which have different
versions of Unison.
For this reason, Fedora packages three different Unison branches in
* unison213 (currently Unison 2.13.16)
* unison227 (currently Unison 2.27.157)
* unison240 (currently Unison 2.40.128)
* There was a "unison" package, but it is retired
We don't package the latest upstream versions (Unison 2.48.4,
Unison 2.51.2) at all.
Because of what I said above, it matters what Debian is shipping:
* unison 2.27.57
* unison 2.32.52
* unison 2.40
=> If you wanted to communicate between Fedora and Debian you could
use either 2.27 or 2.40.
It's not likely that Unison will use a stable, cross-version protocol
any time soon.
I'm proposing that we clear up this mess by creating a single unified
package called just "unison" which will build subpackages for each
version. It will contain multiple source tarballs for each major
Although this is very slightly dubious from a packaging point of view,
I believe it's the best solution here. It means we can build multiple
versions, we don't need to go through the new package review process
every time upstream releases a new major version, and it'll make
managing the package simpler at the cost of a somewhat more complex
If no one has any objections, I'll submit a unified unison package to
the new package process.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
[ Broadening the audience to include devel(a)lists.fedoraproject.org ]
Anybody have thoughts about my question below? some examples of places
which will need logic like this to replace PDC usage:
Resolve a module name:stream to a particular build, and do dependency
Get the flatpak-runtime modulemd to find what packages aren't in the
runtime and need to be bundled
Load the modulemd for particular module builds to get profile
information and figure out what to install in a container
Load modulemd and do dependency expansion to build a container locally
Load the modulemd module we are building into a flatpak to find what
runtime it is using, and hence the right build target
On Mon, May 21, 2018 at 1:29 PM, Owen Taylor <otaylor(a)redhat.com> wrote:
> My understanding is that with the planned retirement of the PDC:
> Querying for module information should be done using the MBS and/or Koji
> Various code that I maintain (in OSBS, fedmod, and random tooling) wants
> to do module build lookups - different variations of "look up the modulemd
> for latest build of a NAME:STREAM[:VERSION]". Variations generally being
> exactly what "latest" means here.
> The code generally already is using Koji and the MBS api is quite limited,
> so I've chosen to do the lookups via Koji.
> Is a test tool that incorporates most of the capability that I needed
> across my uses. It's distinctly more than a couple of lines of code - I can
> cut-and-paste it for now, but what's the right long-term home? Is there a
> simpler way?
> My best idea right now is that if the 'base_version' and'status' part of
> my code was simplified to simply be "tag" and avoid reliance on the tag
> structure of Fedora, then this might make a reasonable addition to the Koji
> CLI and API - there are some things that using raw tags for the query makes
> trickier, but it's probably workable.
> Thanks for any input!