Hi Thomas
On 20/05/2017 22:31, Thomas Friedrichsmeier wrote:
> Hi,
>
> On Thu, 18 May 2017 14:59:07 +0200
> Hannah von Reth <vonr...@kde.org> wrote:
>> On 18/05/2017 10:29, Thomas Friedrichsmeier wrote:
> [...]
>>> Some questions:
>>> - Does it cache sources (perhaps at least for "archive" downloads,
>>> might be difficult for version controlled sources)? I think one of
>>> the most common causes of build breakage (esp. breakage over time)
>>> has been upstream moving their downloads around, or even removing
>>> some downloads, entirely.
>> We will package also all tool to archive a full KD5 build.
>> Packaging sources isn't planned as for most targets we use tarballs
>> and patches.
>> A build can be reproduced by using Craft, re uploading all KF5
>> tarballs and Qt tarballs wouldn't add much value.
> What I was thinking about was "what if I try to build using a non-cached
> compiler/architecture three months after the release?" In the past
> something similar often meant some of the _downloads_ would fail for
> being (re-)moved upstream. So I was wonderings, whether it would be
> feasible to cache those upstream tarballs. Not the KF5 and Qt ones, but
> libssl, dbus, icu, etc.
>
> Not the most pressing matter, I agree.
Well it would be possible but I'm not sure how many users would be
affected. But it might be a thing for the next release.
I plan to do a blog post for 2017.05 soon.
>
>>> - What's the workflow / commit policy? Are the stable branches to be
>>> considered "frozen", or to what degree? Is it ok to update
>>> extragear applications to new versions, for instance? Is it ok to
>>> patch for compilation with a non-default compiler? Is it ok to
>>> patch for non-critical stuff?
>> Commits to extragear are welcome also changes to KDE Applications.
>> I'd see the frameworks category as semi frozen, only reviewed patches
>> can be applied there and only if they are really needed.
>> So everything that's cached is semi frozen.
>> Updating a 3party lib won't happen besides a severe security issue.
>>
>>> - I suppose the current "stable" branch is "the branch that will
>>> become the _next_ version of the SDK (aka Qt5.6.2/KF5.33.0 or
>>> whatever). How does this relate to master, then? Or is "stable"
>>> just a placeholder label until the branch naming has been decided
>>> on?
>> The branch is a place holder as soon as 2017.05 is branched the stable
>> branch will change again.
>> Currently the only difference in the stable branch are some patches
>> and the default targets for the recipes.
>> Maybe dev would be a better name for the stable branch, I don't know.
>> The stable branch is meant to be the next release.
> Ok. I suppose any naming scheme is ambiguous. Still wondering a bit
> about master vs. stable. For generic work on portage should I commit to
> stable, and cherry-pick to master (or vice versa)? While master is
> for ... anything that does not yet seem ready for the next release?
Well I'm open for suggestions, this is my first distro release xD
I'm a bit undecided about in which direction to cherry-pick but I guess
cherry-picking -x is a good idea.
>
>>> - What - besides voting on the poll - can we do to help? Now, and in
>>> the long run?
>> Besides voting. For now please try to use craft stable, I uploaded a
>> new cache this morning and I plan to do the release this week.
>> The cache should work, but there still might be some issues, so pls
>> build some applications also some qmake projects with the stable
>> branch.
> Craft stable seems to work *really* well for me, so far. I certainly
> don't recall ever building kdelibs4/KF5 on Windows without some kind
> of manual intervention, before. Great! Some notes:
> - Perhaps the craft setup script could give a hint as to which
> platforms are build-cached, or simply mention the fact that some are
> cached, and some are not. I went through most of a MinGW-32 build,
> thinking the cache feature simply wasn't online, yet, before I
> figured it out...
The whole setup experience needs some attention, but setting the default
to a cached version seems reasonable :D
> - Perhaps it was extraordinary bad luck, but somehow craft had cached a
> NULL for the build cache's manifest.json. That kept the cache
> disabled on my second attempt, too. Perhaps it would be worth
> decreasing the json cache lieftime from one day to one or two hours.
> It's not like _this_ is causing a whole lot of traffic, I guess.
Hm the cache definitely has potential for improvements but right now
there is just one cache and recaching the search would have its downside
too.
Maybe separate time outs would be a thing. Anyway the cache = {} might
have been another bug I already fixed, only a 404 should be cached as {}.
> - After setting up craft a few times, I ran into some interesting
> problems due to inconsistent drive letter substs. Problem is that if
> the drive letter substitutions already exist, then simply calling
> subst R: somewhere
> does not have any effect. You have to do
> subst R: /D
> first.
As I said before, there is improvement potential in the setup :D
>
>> After the release we need to upgrade the KF5 and application versions
>> maybe update a few 3rd party libs, but the most important step will be
>> to make sure that the current kf5 tarballs are OK. Of course adding
>> and fixing recipes for KDE Applications is also important and welcome.
>>
>> Well and if everything works, please spread the word after the release
>> and make KDE devs to support the Windows platform and provide a single
>> application installer for their project.
> Regarding this, what is the current "state of the art" approach to
> packaging? For RKWard we had already set up an NSIS installer. This
> seems to work to some degree (produces a package, still struggling with
> missing MinGW runtime, and failure to find Qt plugins). However I have
> an inkling that NSIS wouldn't be the "default" approach to packaging,
> anymore. Where can I read up on this?
Well NSIS is the current way and I think even so the syntax is a
nightmare its one of the best nightmares I had until today.
In some experiments I was even able to create a windows store installer
out of an NSIS installer (you'll need a certificate for that and you'll
need to sign everything).
But if you manage to well integrate wix, patches are welcome.
Regarding the runtime, pls add a dependency to lib/runtime to rkward, it
would be probably reasonable to only set the dep if the compiler is
mingw, as we have a different solution with NSIS to provide the runtime
with msvc.
>
> Regards
> Thomas
Cheers,
Hannah
signature.asc
Description: OpenPGP digital signature
