Hey,
great that those features can be used from other KDE software more easily in
future!
But you cannot simply create a new repo/library and depend on it. At least
from a release manager point of view, all software in Gear needs to be
released either in Gear or Frameworks.
Before a new repo
Hey,
On Samstag, 22. Oktober 2022 20:55:20 CEST Devin wrote:
> > KClock and KTrip seem to depend on the unreleased kirigami-addons, they
> > shouldn't be released as stable anywhere.
> kirigami-addons has just had its first stable release:
> https://download.kde.org/stable/kirigami-addons/
Geat
Hey,
> kirigami-addons 0.4 is now released:
>
> https://download.kde.org/unstable/kirigami-addons/0.4/
> The tarball is signed using my GPG key (fingerprint in signature)
the translations are missing in the 0.4 release (no po directory).
regards,
hefee
>
> PS: also fixed the CMakeLists
Hey Nicolas,
I scanned through the KTrip release tarball and there is a license issue for
translations. There are several files without any specific license information
(most of the translations) and those translations tell in the header (po/cs/
ktrip.po):
"This file is distributed under the
Hey,
> > https://invent.kde.org/sysadmin/release-tools/-/blob/master/modules.git
>
> I'll have a look tomorrow to prepare a MR for repo-metadata.
I now have a MR for release-tools:
https://invent.kde.org/sysadmin/repo-metadata/-/merge_requests/75
If that get accepted, KDE Gears still has 47
Hey,
> > The propper solution would either use either repo-metadata or project-api
> > to get the needed bugzilla products. You may also add the metadata first
> > to the repo, if KMail is more or less the only exception, it should be
> > easy ;) I can update the metadata, if someone can tell me
Hey,
well we have this mapping already in repo-metadata and project-api ;) look
here:
https://projects.kde.org/api/v1/identifier/kmail
repo-metadata see bugzilla entry for each repo:
https://invent.kde.org/sysadmin/repo-metadata/-/blob/master/projects-invent/
pim/kmail/metadata.yaml
The
Hi,
in Debian we only can update Debian stable, than this needs to get approved by
the release manages. This is done by filing a diff aganist the old version in
stable. So providing just the patches is fine for Debian, as the commits
normally also explain what they fix. This helps us and the
Hey,
can you please do a respin for messagelib to fix 427091, as it creates broken
signatures for mails for some users:
3a7114399b105cbe159355f600b9d3e08ec10fcb - bug 427091
There also some other patches on the release/20.12 branch that's why I ask for
a respin on
Hi,
> In mostly all files it is not clear if the LGPL or the GPL is meant (stating
> "GNU Library General Public License" and referring to the GPL text at the
> end of the statement). This license statement is used for all files except
> autotests/fakesever.cpp and autotests/fakeserver.h.
>
Hi,
> I'm still unclear why two versions of this are being released at the same
> time. It would seem cleaner to say it has now moved to frameworks and not
> release it with Applications
Well drop releasing a package within the Applications 19.08.X cycle can't be
done, because we guarantee no
Hi Andre,
> rev. db3fd6ea8c6619da75b9903a90fffc0f9330cf12 created a bug in libkleo that
> most keyfilters (which are also used by KMail's signing key selection) show
> random behavior because an uninitalized variable is used for filtering.
>
> This was directly fixed in master but I only just
Hey,
> Do you think the number is "small enough" that you could get them in with
> only 8 days from tagging day on March 4 to your freeze on March 12?
Okay I try it again:
Only till 2019-03-12 packages can enter automatically to the next stable
release. But from 2019-02-12 packages have a
Hey,
next Debian stable aka "Buster" is in the pipeline [1]
2019-01-12 - Transition freeze
2019-02-12 - Soft-freeze
2019-03-12 - Full-freeze
Unfortunately KDEPIM breaks ABI, so we need transitions to get new kdepim
into Debian, so we only have 1,5 month to prepare the transition,
Hey,
On Montag, 19. März 2018 20:26:36 CET Volker Krause wrote:
> On Monday, 19 March 2018 18:15:49 CET Jonathan Riddell wrote:
> > On Mon, Mar 19, 2018 at 06:04:51PM +0100, Volker Krause wrote:
> >
> > https://community.kde.org/Policies/Application_Lifecycle
> >
> > > (1) We do not do
Hey,
> > change those scripts but I understand the necessity. However is it
> > actually possible to automate changes with wordpress, at all?
>
> Earlier versions used to have an API for programmatic access. Not sure
> about now, but I assume so.
We also have a library for that: kde/pim/kblog.
Hey,
this discussion is an outcome of an discussion with distributions , that were
asking us, what they need to do now. That's why I thought, it may make sense
to add an text to the release announcement. Because better to much
information than too less. I think "it'll just work", is a hope -
Hey,
the question came up, what to do with 17.12.2 and 17.12.3 releases according
KHoldidays. As you may know KHolidays has moved from KDEPim (Applications) to
Frameworks and will be released within the next Frameworks release (5.43)
too. So for 17.12.2 and 17.12.3 users can get kHolidays
Hey,
@Volker: Is there a need to rush releasing KHolidays it under frameworks?
As far I see it, the include mechanism do not change find_package do not need
to change and also the target_libraries do not need to changed also the API is
fixed so far -> no changes in kdepim needed. The only
Hey,
with a short discussion with Laurent ( the author of kblog), we decided to
keep kblog
> KBlog is listed at https://api.kde.org/kdepim/index.html so maybe
> someone used it outside of KDEPIM
"if we would remove it, we won't get any application ever using it." It
complies without issue,
Hey,
> > grep -rl 'This file is distributed under the license LGPL version 2.1 or'
> > po po/ca@valencia/akonadinotes5.po
> > po/uk/akonadinotes5.po
> > po/ca/akonadinotes5.po
>
> The license in .po files is dependent for each translation team. Some
> translation teams may have a license
Hey,
I spotted the issue, that not all files under po directory are licensed the
same way.
as example I use akonadi-notes/17.08.3 - spotted the issue also for 17.12.0.
These three translations have a own license:
grep -rl 'This file is distributed under the license LGPL version 2.1 or' po
Hey,
kdav is now splitted out of kdepim-runtime and kdepim-runtime depends now on
kdav on master; boths builds successfully on CI.
Please add kdav to the upcomming release of KDE/Applications 17.04.
Dependencies:
KF5::CoreAddons
KF5::KIO
Qt::Core
Qt::Gui
Qt::XmlPatterns
Qt::Test
@montel: can
Hey,
just a short notice. From Feb to Aug. I won't be available very much at
computer, because I'll do a longer holiday in South France. I'll still will
answer mails, but not as fast as currently and I won't nearly do any
programming.
Best Regards,
sandro
* CI support will come and is already requested :)
Best Regards,
sandro
--
Am Montag, 19. Dezember 2016, 12:29:03 CET schrieb Sandro Knauß:
> Hey,
>
> > > moved Akonadi parts already into own files, that can be enter into
> > > kdepim-runtime.
> >
> > Are you
Hey,
> > So i guess we're in agreement that we need a new tarball? Or can we just
> > tell distro packagers to patch it?
jepp - either way is okay for me.
Best Reagrds,
sandro
Hey,
mmh the description of your problem does not match with the commit you have
pushed, or do i miss anything.
Your patch is "only doing:
QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
right?
that means that we still have the problem with schema prefix in the url? And
Hey,
Sorry picked the wrong header, but it is now fixed in:
messagelib:e978f4d266846c74200424149214b968789f0485
Best regards,
sandro
--
Am Samstag, 3. Dezember 2016, 00:25:33 CET schrieb Albert Astals Cid:
> Sandro, can you please fix this?
>
> Cheers,
> Albert
--
Ich habe meinen
Hi Dan,
I thought kgapi is included in KDE Applications 16.08 already. I read your
mail form 30.7. like that. But it looks like it is not included right now.
@montel: Are there any api changes, why we need gapi > 5.3.1, or is it simply
your script update?
Best Regards,
sandro
--
Am
Hey,
I'm also totally +1 to get rid of kdelib4 sooner than later, but still see
thre is a lot of work. I take Debian as example, because there I can get the
data what depends on what easily and also includes data of external
applications using KDE libraries...
I would like, if we would also
Hey,
> That's good news from my (KGpg) point of view, as we were recently in a
> discussion which versions we need to support. We do not need gpgme itself,
> but we use the headers to get some algorithm defines.
>
> Does that version of GpgME bring a CMake config file with it so we can drop
>
sed hopefully next week and will clean up
some things and extend the API again (moved things from libkleo -> gpgme), but
it is ABI compatible with 1.7.1.
For KDE Applications 17.04 we will raise the minimum version very certainly
again, to get rid of copies in libkleo.
Regards,
Sandro
g list or what you do to
promote the release.
Regards
sandro
--
Sandro Knauß
Software Developer
Kolab Systems AG
Zürich, Switzerland
e: kna...@kolabsys.com
t: +41 43 501 66 91
w: http://kolabsys.com
pgp: CE81539E Sandro Knauß
ation?
>
> Regards,
> Andreas
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
--
Sandro Knauß
Software Developer
Kolab Systems AG
Zürich, Switzerland
e: kna...@kolabsys.com
t: +41 43 501 66 91
w: http://kolabsys.com
pgp: CE81539E Sandro Knauß
Hey,
the patch attached to fix this can't be applied for KDE Frameworks 5.26:
https://quickgit.kde.org/?
p=kcoreaddons.git=commitdiff=96e562d9138c100498da38e4c5b4091a226dde12
you need additionally
https://quickgit.kde.org/?
p=kcoreaddons.git=commitdiff=1be7272373d60e4234f1a5584e676b579302b053
Hey,
> Well, Albert and I use (the same user on) the same server to make releases.
> So the private key will have to be on that server, otherwise it will become
> very inconvenient (download, sign, upload).
>
> But if that's good enough, and if we can tell gpg2 which private key to use
> (so he
Hey,
> Does that really fix anything if noone has my gpg key in the
> trusted/validated signatures area? How do they know it's me that signed the
> package and not some hacker that got access to the server and did sign the
> tarballs?
On the one side, if the privatekey is easy to grab, it does
Hi,
> Please ensure it uses a competent (ie. CMake, failing that, autotools)
> build system.
> Projects that use QMake are a complete royal pain to work with, pretty
> much always requiring patching to be compilable or installable.
>
> If the build system in use is unworkable, you'll need to
Hey,
libkdepim, pimcommon and kdepim-apps-libs are dumping grounds, we know. And
yes the long time plan is to get rid of them. But this wont happen with the
next release, because we want to move them to vaild places, aka many things
should go upstream (KF5 /Qt) / other can be replaced ...
Hi Ben,
thanks for the message. In future this hopefully not happen again.
> On that note: could you folks work on cutting the level of
> interdependency between your "split" repositories? They're all
> effectively still one unit, with a linear build order being absolutely
> required,
Hey,
> Is this a heads up and you will also ping us when all that happens or should
> we be reacting to it already?
>
> I ask because things as akonadi-notes don't seem to really exist yet.
It it is "only" a head up information - Nearly nothing of these things are
done by now. I wanted to make
Hey,
maybe you can help to make it a smoother 16.08 release for KDEPIM than for
16.04. We now had our PIM Sprint in Toulouse and discussed things that will be
done till 16.08 release and have impact for release.
* kdepimlibs is going to be split and been removed afterwards (split to
Hey,
> What could we done to improve this?
I think the ideal way to do this, is to create a bug report at the distros
bugtracker. This is way all distros want to get this kind of input and can
handle it accordingly. Yes I know using others bugtracker is a pain in the
ass, but maybe we can
Hey,
> * breeze-cursors are not/were not packaged correctly resulting in broken
> cursor images (this was a problem visible in almost all distributions)
Well because it was visible in almost all distros shows, that there is a lack
of communication beween upsteam and distros and between the
Moin,
Yes and no from a person that is part of kdepim and as debian manatiner:
* I see it like Christophe, many bugs are already reported with debian
bugtracker and the manpower is too low to push all relevant bugs upstream. So
they are rotting in the debian bugtracker but should go upstream.
Hi,
Thanks for pointing me to that - I also looked the last days at kcalcore,
because I need to do there some work.
> https://build.kde.org/user/aacid/my-views/view/KDE%20Applications%2015.12/jo
> b/kcalcore%20Applications-15.12%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc
>
Hey,
> > kdepim-runtime seems to depend on unreleased versions of libkgapi and
> > libkolabxml
fixed at Applications/15.12 branch:
* downgraded dependcy from libkolabxml 1.2 -> 1.1
* updated kdesrc-build tofollow the libkolabxml-1.1 branch
libkolabxml 1.1.2 and libkolab 1.0.2 were released
Hey,
I already saw the issue yesterday, when i checked the dependencies.
Will push to have a new release of libkolab(xml) the next days.
https://git.kolab.org/T853
> Ah crap, I made a typo in LibKGAPI version, the current (unreleased) version
> is 5.40.0 instead of 5.0.40 (last release was
Hey,
> While l10n might not seem to be that important to you, it might be the
> difference between an unusable system and a useable system. So let's not
> start downplaying the importance of translations ;-)
The point with translations is, if you change i18n strings in stable patches,
than you
Moin,
Let's look at an example: we wanna push the patch releases to debian:
On the one side we have unstable and testing. There the mantainer can upload
most time a new version (if it is not frozen for the upcomming stable release
~ three moth before the release). And any new version inside
Moin,
Let's look at an example: we wanna push the patch releases to debian:
On the one side we have unstable and testing. There the mantainer can upload
most time a new version (if it is not frozen for the upcomming stable release
~ three moth before the release). And any new version inside
Hey,
It's a long shot and I know it's come up before but can I suggest renaming
kdepim to Kontact everywhere?
I don't see any advantage to rename it at the moment. All applications
looks/feel the same like before, so why we should rename it? many users I
know, know one application (kmail,
52 matches
Mail list logo
