we want to do rebase of mercurial for F29 before beta freeze yet. Currently
we have version v4.4.2 which is already old. Few days ago there have been
release new stable version v4.7. But many applications would be broken because
of changed API (as it is with every bump of minor version). From this point,
I would like to do rebase to v4.5.3 (or v4.6) as I believe that apps with
living upstream (and which requires mercurial) are already compatible with
those versions of mercurial. After the F29 will be branched, we will do rebase
to v4.7 in rawhide so there will be enough time to fix any issues because of
changes in the new version.
Here is the list of components that depends on mercurial:
Please give me a note in case you have troubles with this rebase now. I would
like to do in few days. Add POCs into Cc.
Core Services (In-place upgrades and migrations)
IRC nicks: pstodulk, skytak
it seems that lately there has been more people maintaining Go package in the Fedora. I would like to propose to join up and form Go SIG so we could better co-ordinate and collaborate on the packaging issues and general developer experience.
There are few big outstanding issues that needs to be solved that need more than individual work, most notably the Go packaging guidelines and tooling. I think that should be one of the first tasks for the SIG.
To introduce myself. I'm for some while golang (co-)maintainer and recently started co-maintaining origin package. I'm mostly interested in the compiler and developer experience.
Please reply if you would like to participate.
PS: Also I will be at Flock this year and would like to meet up with anyone interested there.
On Wed, Aug 8, 2018 at 7:09 PM Pascal Terjan <pterjan(a)gmail.com> wrote:
> On 7 August 2018 at 09:50, Michael Schroeder <mls(a)suse.de> wrote:
> > On Mon, Aug 06, 2018 at 04:36:07PM +0000, Zbigniew J??drzejewski-Szmek wrote:
> >> this mail is a continuation of an FPC  and a FESCo  tickets.
> >> A proposal was made is to disallow packages in Fedora from using file
> >> deps, and to optimize dnf to not load filelists.xml. File deps would
> >> still be supported, because external packages and users want to use
> >> them, but they would not be allowed for distro packages.
> >> Not downloading or loading filelists.xml which are required for file
> >> deps would provide significant bandwidth savings (~47 MB compressed)
> >> and noticeable runtime savings (~10s at dnf startup) in many common
> >> cases.
> >> So this is something that is worth exploring, but it's not clear if it
> >> is at all feasible.
> > There's also something that can easily be done and would make
> > loading the filelist unneeded in most of the cases: extend the
> > primary filelist to include some whitelist of files. The whitelist
> > must also be stored in the primary data, so that the solver knows
> > what to expect.
> That's what Mandrake/Mandriva/Mageia/... has been doing for many
> years, there is a small file-deps file containing the ones we end up
> generating, mostly from scriptlets IIRC, and we end up with provides
> added for those in the main metadata when generating it. Then file
> lists are lazily loaded when people want to query them but not used
> for dependency resolution.
> $ GET http://ftp.free.fr/mirrors/mageia.org/distrib/cauldron/x86_64/media/media...
So the primary.xml already includes all that. If you actually look in
the primary.xml.gz files in the Mageia rpm-md data, those are already
there. The problem is that there are people who actually request files
outside of the base whitelist as a means to be able to request
"things" without knowing how they are packaged, because the file path
is the consistent thing across distros. This is supported in YUM and
DNF, just slightly differently.
In this case, the wish is to restore the YUM behavior. The idea is
that stacking this on top of the Zchunk deltarepo extension will yield
incredible boosts for everything.
真実はいつも一つ！/ Always, there's only one truth!