Frameworks releases timing
Frameworks 5.86 haven't been released yet; from the calendar it looks like that will happen next week. However, there's a couple of Linux distro's that have packages up already. This makes the repology.org feed for frameworks a little weird -- 5.86.0 is "green" because it's latest, because it's available from two (?) distro's, but it's not officially released. Nearly everyone is red, because they ship the released 5.85.0. Regular people who might want to build-from-source (released tarballs, not git) can't even get the 5.86 tarballs yet. I happen to have access to the FreeBSD packaging "stage" tree, so I can see that Tobias -- who has access to that tree, and **also** access to the pre- release tarballs -- has prepared the packages for the release, but not pushed the button to move it from staging to the real tree. Pushing that button would break source builds for me, a regular(-ish) user, because I can't fetch the pre-release tarballs. Anyway, long-story short: - should distro's be packaging up pre-release tarballs? - is there a polite tap-on-the-shoulder kind of message to send to distro's if the answer is "no", to remind them not to push out packages before the dust settles? (e.g. for respins ) [ade] signature.asc Description: This is a digitally signed message part.
Re: Requiring Qt 5.15 for KDE Frameworks 5?
On Saturday, 27 March 2021 14:11:38 CET David Faure wrote: > While at it, can we also get your feedback on > * Requiring C++17 > * Requiring CMake >= 3.16 > > Obviously this only matters for distributions that update KF5 every month. FreeBSD is fine with all of that, we track frameworks within a week or two, CMake similarly, and ship recent clang (or gcc 10 on platforms that clang doesn't support). [ade] signature.asc Description: This is a digitally signed message part.
Re: Fwd: KCalendarCore Require Libical 3.0
On Tuesday, 24 November 2020 22:39:44 CET Allen Winter wrote: > On Tuesday, November 24, 2020 8:13:12 AM EST Allen Winter wrote: > > I plan to implement this new requirement 2 weeks from now. > > unless there are good reasons against. > > > > Unless there are objections, I'd like to require libical v3.0 in > > kcalendarcore. libical v3.0.0 was released over 3 years ago (28 Oct 2017) That's fine from the KDE-FreeBSD side, CI builders are up-to-date: libical-3.0.8_1Implementation of the IETF Calendaring and Scheduling protocols [ade] signature.asc Description: This is a digitally signed message part.
Re: Krita 4.4.0 and SeExpr
On Saturday, 5 September 2020 15:42:23 CEST Boudewijn Rempt wrote: > We intend to release krita 4.4.0 this month. Krita 4.4.0 will have a new > dependency: SeExpr. .. ok, that's a Walt Disney open source thing, that's packaged in surprisingly few places already: https://repology.org/project/seexpr/versions . FreeBSD is one of them. > It is important to package the SeExpr we release from invent.kde.org because > of a host of bug fixes and because this version of SeExpr can be > translated. Is there any hope of this getting upstream? For systems with seexpr already packaged, packaging up a one-consumer fork is a pain in the butt (but if it's needed for Krita, then it'll just have to happen, and thank you for the heads- up). > An alpha package is available from > https://files.kde.org/krita/build/dependencies/seexpr-3.4.4.0-alpha.1.tar.g > z. You might want to change the link in the release on invent, which still points to amyspark's dump-files. [ade] signature.asc Description: This is a digitally signed message part.
Re: New required MPFR dependency for kcalc 19.08
On Sunday, 23 June 2019 12:31:04 CEST Christoph Feck wrote: > I have just committed https://phabricator.kde.org/D21495 for kcalc. > It adds a required dependency to MPFR library for the upcoming 19.08 > releases. > > Unfortunately I didn't expect the CI to not have this dependency, so > right now it fails to build for openSUSE (but works for FreeBSD). For reasons not entirely clear to me, we (FreeBSD) already package kcalc with mpfr as a dependency, and have done so since 2018. So it's more of an accidental succes than anything else :S . We'll keep the dependency in preparation for the next update. [ade] signature.asc Description: This is a digitally signed message part.
Re: PIM versioning and dependencies
On Sunday 27 August 2017 22:40:18 Ben Cooksley wrote: > In the case of FreeBSD, those slaves are manually managed at the > moment so there is no easy outside way to check i'm afraid, aside from > examining the CMake output, which should include details on versions > which have been found. The FreeBSD CI builders have Qt 5.7, which is (as far as I know) the documented minimum required Qt version for KDE Frameworks. I assume that that is followed by the rest of KDE code unless well documented on a "required dependencies for this bit" wiki page. [ade] signature.asc Description: This is a digitally signed message part.
Re: Release dates/nomenclature
On Saturday 01 September 2007 23:29, Allen Winter wrote: On Saturday 01 September 2007 11:45:07 am Thomas Zander wrote: On Saturday 01 September 2007 17:30:34 Matt Rogers wrote: That's no different than what we have now. The problem is that people seem to be too interested in fixing Krazy issues rather than fixing actual bugs. How do you propose we get them interested in fixing real bugs? Stop running the not-so-interresting krazy tests? ;) We can pull the plug on the EBN entirely. That's like turning off compiler warnings because you don't want people to fix them either. It's possible, but I'd rather try to rely on the discipline of our developers to fix what is needed. The EBN has always been a reporter of the last mile of little fixes; I don't think we've ever suggested that issues reported by the EBN are related to functionality, real bugs (defects encountered at runtime) or releaseability. The use of the words pull the plug garners a fuck it all, i'll reuse the domain for a LOLcats parody response from me. I don't think that will help get bugs fixed, but at least it will reduce the number unneeded re-compiles. I had no idea Krazy/EBN was doing such so harm to the project. That was not the intention. Communicate that to your developers. Give them priorities. Impress upon them the importance not of polishing th internals of the code until they shine, but on fixing the big ugly warts on the outside. There's a Sirius Cybernetics Corporation segue here, and I'm going to skip it. [ade] ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
