KDE Applications 16.04.0 packages available for packagers
alien at slackware.com
Thu Apr 14 21:21:24 UTC 2016
On Thu, 14 Apr 2016, Albert Astals Cid wrote:
> El dijous, 14 d?abril de 2016, a les 13:42:18 CEST, Eric Hameleers va
>> On Thu, 14 Apr 2016, Albert Astals Cid wrote:
>>> At the usual location.
>>> Haven't had time to compile yet, will try to get to it on monday since
>>> weekend i'm away at Akademy-es.
>>> REVISIONS_AND_HASHES file at https://paste.kde.org/pfq4epsxp
>> Albert, there is a great many new tarballs:
> We do Beta and RC for a reason, seems you're realizing a bit too late ;)
Well... Keeping a KDE package repository uptodate with the ever
evolving Frameworks, Plasma and Application tarballs is already taking
enough time just when tracking stable releases. We are a small team,
KDE packaging is just one of the things I do. Stuff like LibreOffice,
Chromium, multilib compilers and Slackware Live come on top. Know what
- I pass on Beta and RC versions.
> There are more new tarballs, minuet, ktp-call-ui, kde-l10n-ast at least I also
> pointed a list to the new tarballs in old emails about KDE Applications 16.04,
> i'll leave as an exercise for you to search for it.
Helpful, as always. But I can read diffs of directory listings thank
you. It takes me exactly one command to get a listing of tarballs that
are not yet being used in my build framework, so this is a irrelevant
comment... I am interested in *build order* .
>> I assume these belong to KDEPIM. Where is their build order documented
>> - also in relation to the other pre-existing tarballs?
> In their CMakeLists.txt, in the kde-build-metadata repo and in the totally
> random order i use to build packages that seemed to work last time (don't take
> this as anything official) http://paste.ubuntu.com/15838970/
Please understand this.
As a distro packager, I would welcome a simple piece of documentation
written by the developer that is *not* a CMakeLists.txt file. If you
develop software and cut that into 20 tarballs, it does not cost you
blood to write up what a packager needs to do with them.
If every distro needs to figure out a build order, you introduce
randomness in the resulting packages and therefore you make it
a lot more difficult to troubleshoot the resulting bugs when
end users report them back to you.
Now that paste is more like something of a serious answer to a serious
question. You do have some interesting differences in build order,
compared to me. I will figure something out locally, as I do want my
target audience to experience the new Plasma/Applications sooner
rather than later.
Eric Hameleers <alien at slackware.com>
More information about the release-team