Re: ksysguard 5.22.0 tar for packaging

[Nicolás Alvarez]

The directory was owned by ftpadmin:ftpadmin rather than
ftpadmin:packager. I have now fixed this.

-- 
Nicolás

El vie, 4 de jun. de 2021 a la(s) 16:11, Tobias C. Berner
(tcber...@gmail.com) escribió:
>
> Moin moin
>
> Seems to be inaccessible:
>
> remote readdir("/srv/archives/ftp/stable/ksysguard/5.22.0"): Permission denied
>
> mfg Tobias
>
> On Fri, 4 Jun 2021 at 17:54, Jonathan Riddell  wrote:
> >
> > The 5.22 tar is up on download.kde.org/stable/ksysguard for those with 
> > packager access for packaging ahead of a release on Tuesday.
> >
> > It is signed by me with 2D1D5B0588357787DE9EE225EC94D18F7F05997E
> >
> > Jonathan

Re: Requiring Qt 5.15 for KDE Frameworks 5?

[Nicolás Alvarez]

> El 27 mar. 2021, a la(s) 12:30, Fabian Vogt  escribió:
> Moin,
> 
> Am Samstag, 27. M?rz 2021, 14:11:38 CET schrieb David Faure:
> On samedi 27 mars 2021 12:51:37 CET Kai Uwe Broulik wrote:
 Hi everyone,
 during the ongoing KDE Frameworks 6 sprint we were just contemplating
 whether we can bump the required Qt dependency for Frameworks 5 to Qt 5.15.
 Reason being that Qt 5.15 includes a set of porting aids and
 forward-compatibility with Qt 6, such as version-less "Qt" rather than
 "Qt5" CMake target, various QStringView-related features, and so on.
 We would like to start working on KDE Frameworks 6 on Qt 6 but still
 keep Frameworks 5 supported with as little overhead as possible, i.e.
 not having a gazillion ifdefs or even dedicated branch, which we would
 likely need, should we have to continue supporting Qt 5.14 in the process.
 Are there any objections or concerns or potential release schedule
 conflicts if we did that?
>> While at it, can we also get your feedback on
>> * Requiring C++17
> 
> Which for GCC means at least g++ 9 in practice due to std::filesystem?

I think we need to be more specific and say what is the minimum compiler 
version. Maybe we can set g++8 as the minimum and use C++17 language features 
while avoiding std::filesystem.

But only if someone actually cares about keeping gcc8 support :)

-- 
Nicolás

Re: KDE Frameworks 5.43.0

[Nicolás Alvarez]

2018-02-05 19:40 GMT-03:00 Luca Beltrame :
> Il giorno Mon, 05 Feb 2018 18:55:52 +0100
> David Faure  ha scritto:
>
>> I certainly didn't intend to re-enable it. Are you sure that I did ?
>> I can't see the commit, and I still see this code in file_unix.cpp :
>
> I see, was some commit overwritten? I saw
> https://commits.kde.org/kio/2013f14d82efdedce49b2959d1bb56e53cff897c
> flying by, but it's no longer viewable in cgit.
>
> Archived post: https://marc.info/?l=kde-commits=151765309314964=2

I investigated this in server logs. It looks like David attempted to
push that commit, and our hooks may have spuriously sent email for it,
but it didn't actually make it to the repository. Perhaps he Ctrl-C'd
the push after the commit data was sent to the server but before
refs/heads/master was updated to contain it.

-- 
Nicolás
KDE Sysadmin Team

Re: Umbrello, hybrid repository, Applications/17.08

[Nicolás Alvarez]

2017-07-16 21:14 GMT-03:00 Jack Ostroff :
> On 2017.07.16 18:11, Luigi Toscano wrote:
>>
>> Hi all,
>>
>> umbrello follows an hybrid structure (both Qt4 and Qt5 version at the same
>> time, with a lot of if-defs) which poses some complications to our
>> infrastructure.
>>
>> The maintainer turned on the KF5 version for non-Windows platform in
>> Applications/17.08 today:
>>
>> You can read my comments, but in a nutshell:
>> - the English documentation use a trick (the cmake equivalent of sed) to
>> use
>> the native DTD of Frameworks documentation;
>> - the translated DTDs can't do the same. So they will rely on the DTD of
>> the
>> original
>> - when the translated documentation are injected back, as it happens now
>> for
>> KF5 applications, they will introduce an implicit dependency on
>> KDELibs4Support, which is not defined.
>>
>> I tried to explain the issue with the documentation in the past but with
>> no
>> success. There is also a similar issue related to the usage of a piece of
>> documentation on its own inside the program.
>>
>> The stated reason for keeping this hybrid model is the support of Windows.
>> Now, I think that it's possible to keep this:
>> - keep a "kdelibs4" branch for Windows, commit there the bugfixes
>> - upmerge into "master" (or "Applications/xy.zt"), which would be pure
>> Qt5.
>>
>> I would like to ask to revert the change and keep umbrello officially
>> kdelibs4, and work to move to pure Qt5 before Applications 17.12 (aka
>> fixing
>> the issues on Windows).
>>
>> Otherwise I will have to workaround this in the release scripts in various
>> ways:
>> - not injecting the localized documentation (at least visible on the
>> website)
>> - adding an extra dependency to kdelibs4support in the umbrello cmake code
>> - fixing the DTD while injecting the localized documentation (definitely
>> hard)
>>
>> The last one would be a special rule just for one program, which takes
>> time
>> for no reasons and add a maintenance cost. I personally don't like how the
>> common rule and expectation has not been followed for this repository,
>> which
>> introduces difficulties for the rest of the community.
>>
>> Ciao
>> --
>> Luigi
>
> Luigi,
>
> I have not used KDE/Windows in quite a while, but are they not capable of
> handling Frameworks and Qt5 based builds?  I do not have my Windows box
> handy to actually check myself.
>
> Jack

In my experience, on Windows it's *easier* to deal with Qt5/KF5 than
with the monolithic kdelibs4.

-- 
Nicolás

Re: Calendar and release schedule

[Nicolás Alvarez]

2017-04-16 14:18 GMT-03:00 Luigi Toscano :
> = Status of calendars
> The existing calendar page,  https://www.kde.org/events/month.php aggregates:
>
> - the calendar for KDE Applications, and previously KDE SC releases,
> authoritative source is http://www.kde.org/releaseschedule.ics (manually
> generated?);

The ics is generated "almost by hand" using this custom tool:
https://cgit.kde.org/sysadmin/release-tools.git/tree/tools/releaseschedule

-- 
Nicolás

Re: Re: Stopping release of kdewebdev for Applications 17.04 (was: 16.08)

[Nicolás Alvarez]

2017-02-26 19:43 GMT-03:00 Andreas Sturmlechner
:
> On Sunday, 26 February 2017 at 22:53, Albert Astals Cid wrote:
>> > kfilereplace
>> > kimagemapeditor
>> > klinkstatus
>>
>> And? Apps that work don't need a large amount of commits.
>>
>> If you want us to stop releasing apps personally I need more reasons than
>> "there's not many commits".
>>
>
> Oh, maybe I was under a wrong impression by our past discussion. As there
> haven't been code commits in many many years for any of them, the question was
> rather why keep releasing near bit-perfect copies of tarballs 12 times a year.

Eh, we do the same (bit-perfect tarball copies) with many other apps
and frameworks anyway...
https://cgit.kde.org/kdiamond.git/commit/?id=6fc2700cef2ba872f4d7d85e0bd3ed6423bcf305

-- 
Nicolás

Re: Suggestion to Remove KFloppy and hold back K3b

[Nicolás Alvarez]

> On Feb 15, 2017, at 17:58, Wolfgang Bauer  wrote:
> 
> Am Mittwoch, 15. Februar 2017, 22:21:19 schrieb Martin Gräßlin:
>> Please do not consider starting a GUI application as root a possibility.
> 
> Ok, but partitionmanager does exactly that. It restarts itself as root if run 
> as user.
> So that instantly would rule out partionmanager as a proposed replacement, I 
> suppose.
> 
> But KFloppy is quite a simple application.
> There should not really be a special risk involved running it as root, but I 
> might be mistaken there.

Sounds like you're challenging Martin to write a take-over-machine exploit via 
root KFloppy, and I would bet money that he would succeed ;)

-- 
Nicolás

Re: kconfig_compiler (Re: KDE Frameworks 5.29.0)

[Nicolás Alvarez]

> El 10 dic 2016, a las 17:10, David Faure  escribió:
> 
>> On samedi 10 décembre 2016 19:49:07 CET Martin Graesslin wrote:
>> So from my point of view breaking the incorrect behavior could be acceptable
>> here.
> 
> Yes, but after the next kdevplatform release, then, to avoid breaking 
> compilation of released code.
> 
> Is the kdevplatform bugfix getting into the final 16.12 release?
> If I read
> https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
> correctly, there's still time to sneak it in if needed, before Dec 15.

KDevPlatform and KDevelop are extragear ;)

The fix is already in the 5.0 branch, I guess we could release a v5.0.4 soon if 
needed.

-- 
Nicolás

Re: Stopping release of kdewebdev for Applications 16.08

[Nicolás Alvarez]

2016-10-31 7:54 GMT-03:00 Albert Astals Cid <aa...@kde.org>:
> El dimarts, 25 d’octubre de 2016, a les 23:40:12 CET, Albert Astals Cid va
> escriure:
>> El dilluns, 17 d’octubre de 2016, a les 20:31:50 CEST, Nicolás Alvarez va
>>
>> escriure:
>> > 2016-10-06 19:44 GMT-03:00 Albert Astals Cid <aa...@kde.org>:
>> > > El dimecres, 5 d’octubre de 2016, a les 22:06:22 CEST, Ben Cooksley va
>> > >
>> > > escriure:
>> > >> On Wed, Oct 5, 2016 at 10:46 AM, Luigi Toscano
>> > >> <luigi.tosc...@tiscali.it>
>> > >
>> > > wrote:
>> > >> > Albert Astals Cid ha scritto:
>> > >> >> El dimecres, 13 de juliol de 2016, a les 1:27:21 CEST, Albert Astals
>> > >> >> Cid
>> > >> >> va
>> > >> >>
>> > >> >> escriure:
>> > >> >>> El divendres, 8 de juliol de 2016, a les 11:50:44 CEST, Andreas
>> > >> >>> Sturmlechner>>>
>> > >> >>>
>> > >> >>> va escriure:
>> > >> >>>> On Friday, 8 July 2016 at 11:11, Luigi Toscano wrote:
>> > >> >>>>> On Friday 08 of July 2016 11:03:05 Andreas Sturmlechner wrote:
>> > >> >>>>>> None of them were ported yet, in fact they haven't seen commits
>> > >> >>>>>> in
>> > >> >>>>>> years.
>> > >> >>>>>> They should probably be converted to git, still, but imo no need
>> > >> >>>>>> to
>> > >> >>>>>> keep
>> > >> >>>>>> it releasing.
>> > >> >>>>>
>> > >> >>>>> Some of them could be probably dropped, but also isn't it
>> > >> >>>>> possible
>> > >> >>>>> that
>> > >> >>>>> they slipped out of the radar because not on git? Would it be
>> > >> >>>>> possible
>> > >> >>>>> to
>> > >> >>>>> have them converted first and see if this changes?
>> > >> >>>>
>> > >> >>>> kommander and kfilereplace are not actually webdev related, so
>> > >> >>>> could
>> > >> >>>> be
>> > >> >>>> moved into other categories (kdeutils?) if not dropped.
>> > >> >>>>
>> > >> >>>> Not sure how many people still do image maps (so chances this will
>> > >> >>>> be
>> > >> >>>> picked up again are slim), and klinkstatus still depends on
>> > >> >>>> kdepimlibs-4
>> > >> >>>> to build.
>> > >> >>>
>> > >> >>> Let's move them to git first and then decide if we want to drop
>> > >> >>> them
>> > >> >>> or
>> > >> >>> not.
>> > >> >>>
>> > >> >>> Given the freeze for KDE Applications 16.08 is like in 2 days i
>> > >> >>> would
>> > >> >>> not
>> > >> >>> rush for now, let's all make a note for 2.5 months and decide if we
>> > >> >>> want
>> > >> >>> to
>> > >> >>> release them for KDE Applications 16.12.
>> > >> >>
>> > >> >> So it's 2.5 months later now.
>> > >> >>
>> > >> >> I would like to get them moved to git if possible, get them released
>> > >> >> for
>> > >> >> KDE Applications 16.12 and tell people they need to start caring
>> > >> >> about
>> > >> >> them if they don't want to see them dropped for 17.04
>> > >> >>
>> > >> >> Now the question is, how do we get them into git?
>> > >> >
>> > >> > I think that sysadmins have (or had) a system dedicated to SVN-to-git
>> > >> > conversion, and also the examples of the old conversions. There are
>> > >> > some
>> > >> > instructions here:
>> > >> > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
>> > >>
>> > >> We had such a system - all such machines have since been shutdown
>> > >> though.
>> > >> I think Nicolas has a container on one of our machines which he does
>> > >> the occasional conversion which gets requested in, but it has been a
>> > >> long time since that was last used if I recall correctly.
>> > >
>> > > Any way i can get that 65G svn file somehow or we can't port anything
>> > > else
>> > > from svn to git?
>> > >
>> > > Or Nicolás can I convince you to git-ify kdewebdev?
>> >
>> > It's done! Please review:
>> > kde:scratch/nalvarez/kdewebdev-kfilereplace
>> > kde:scratch/nalvarez/kdewebdev-kimagemapeditor
>> > kde:scratch/nalvarez/kdewebdev-klinkstatus
>> > kde:scratch/nalvarez/kdewebdev-kommander
>>
>> I don't think much changes happened but the branches from
>> https://websvn.kde.org/branches/Applications/
>> are missing (i.e. you only have the KDE/XXX ones), would it be much work to
>> get them in?
>
> Ping?

Sorry for the delay! I have added the Applications branches (without
losing Andreas's changes in master) and pushed to my scratch space.

-- 
Nicolás

Re: Stopping release of kdewebdev for Applications 16.08

[Nicolás Alvarez]

2016-10-06 19:44 GMT-03:00 Albert Astals Cid :
> El dimecres, 5 d’octubre de 2016, a les 22:06:22 CEST, Ben Cooksley va
> escriure:
>> On Wed, Oct 5, 2016 at 10:46 AM, Luigi Toscano 
> wrote:
>> > Albert Astals Cid ha scritto:
>> >> El dimecres, 13 de juliol de 2016, a les 1:27:21 CEST, Albert Astals Cid
>> >> va
>> >>
>> >> escriure:
>> >>> El divendres, 8 de juliol de 2016, a les 11:50:44 CEST, Andreas
>> >>> Sturmlechner>>>
>> >>> va escriure:
>>  On Friday, 8 July 2016 at 11:11, Luigi Toscano wrote:
>> > On Friday 08 of July 2016 11:03:05 Andreas Sturmlechner wrote:
>> >> None of them were ported yet, in fact they haven't seen commits in
>> >> years.
>> >> They should probably be converted to git, still, but imo no need to
>> >> keep
>> >> it releasing.
>> >
>> > Some of them could be probably dropped, but also isn't it possible
>> > that
>> > they slipped out of the radar because not on git? Would it be possible
>> > to
>> > have them converted first and see if this changes?
>> 
>>  kommander and kfilereplace are not actually webdev related, so could be
>>  moved into other categories (kdeutils?) if not dropped.
>> 
>>  Not sure how many people still do image maps (so chances this will be
>>  picked up again are slim), and klinkstatus still depends on
>>  kdepimlibs-4
>>  to build.
>> >>>
>> >>> Let's move them to git first and then decide if we want to drop them or
>> >>> not.
>> >>>
>> >>> Given the freeze for KDE Applications 16.08 is like in 2 days i would
>> >>> not
>> >>> rush for now, let's all make a note for 2.5 months and decide if we want
>> >>> to
>> >>> release them for KDE Applications 16.12.
>> >>
>> >> So it's 2.5 months later now.
>> >>
>> >> I would like to get them moved to git if possible, get them released for
>> >> KDE Applications 16.12 and tell people they need to start caring about
>> >> them if they don't want to see them dropped for 17.04
>> >>
>> >> Now the question is, how do we get them into git?
>> >
>> > I think that sysadmins have (or had) a system dedicated to SVN-to-git
>> > conversion, and also the examples of the old conversions. There are some
>> > instructions here:
>> > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
>>
>> We had such a system - all such machines have since been shutdown though.
>> I think Nicolas has a container on one of our machines which he does
>> the occasional conversion which gets requested in, but it has been a
>> long time since that was last used if I recall correctly.
>
> Any way i can get that 65G svn file somehow or we can't port anything else
> from svn to git?
>
> Or Nicolás can I convince you to git-ify kdewebdev?
>

It's done! Please review:
kde:scratch/nalvarez/kdewebdev-kfilereplace
kde:scratch/nalvarez/kdewebdev-kimagemapeditor
kde:scratch/nalvarez/kdewebdev-klinkstatus
kde:scratch/nalvarez/kdewebdev-kommander

The history seems to be complete, but I haven't tested if the latest
master compiles etc. I think they rely on the global
kdewebdev/CMakeLists.txt and don't build standalone.

I also need to know where to push the final git repos. Should I create
a kdewebdev module in repo-metadata? And what needs to be done with
i18n for a svn->git move?

-- 
Nicolás

Re: Stopping release of kdewebdev for Applications 16.08

[Nicolás Alvarez]

2016-10-06 19:44 GMT-03:00 Albert Astals Cid :
> El dimecres, 5 d’octubre de 2016, a les 22:06:22 CEST, Ben Cooksley va
> escriure:
>> On Wed, Oct 5, 2016 at 10:46 AM, Luigi Toscano 
> wrote:
>> > Albert Astals Cid ha scritto:
>> >> El dimecres, 13 de juliol de 2016, a les 1:27:21 CEST, Albert Astals Cid
>> >> va
>> >>
>> >> escriure:
>> >>> El divendres, 8 de juliol de 2016, a les 11:50:44 CEST, Andreas
>> >>> Sturmlechner>>>
>> >>> va escriure:
>>  On Friday, 8 July 2016 at 11:11, Luigi Toscano wrote:
>> > On Friday 08 of July 2016 11:03:05 Andreas Sturmlechner wrote:
>> >> None of them were ported yet, in fact they haven't seen commits in
>> >> years.
>> >> They should probably be converted to git, still, but imo no need to
>> >> keep
>> >> it releasing.
>> >
>> > Some of them could be probably dropped, but also isn't it possible
>> > that
>> > they slipped out of the radar because not on git? Would it be possible
>> > to
>> > have them converted first and see if this changes?
>> 
>>  kommander and kfilereplace are not actually webdev related, so could be
>>  moved into other categories (kdeutils?) if not dropped.
>> 
>>  Not sure how many people still do image maps (so chances this will be
>>  picked up again are slim), and klinkstatus still depends on
>>  kdepimlibs-4
>>  to build.
>> >>>
>> >>> Let's move them to git first and then decide if we want to drop them or
>> >>> not.
>> >>>
>> >>> Given the freeze for KDE Applications 16.08 is like in 2 days i would
>> >>> not
>> >>> rush for now, let's all make a note for 2.5 months and decide if we want
>> >>> to
>> >>> release them for KDE Applications 16.12.
>> >>
>> >> So it's 2.5 months later now.
>> >>
>> >> I would like to get them moved to git if possible, get them released for
>> >> KDE Applications 16.12 and tell people they need to start caring about
>> >> them if they don't want to see them dropped for 17.04
>> >>
>> >> Now the question is, how do we get them into git?
>> >
>> > I think that sysadmins have (or had) a system dedicated to SVN-to-git
>> > conversion, and also the examples of the old conversions. There are some
>> > instructions here:
>> > https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
>>
>> We had such a system - all such machines have since been shutdown though.
>> I think Nicolas has a container on one of our machines which he does
>> the occasional conversion which gets requested in, but it has been a
>> long time since that was last used if I recall correctly.
>
> Any way i can get that 65G svn file somehow or we can't port anything else
> from svn to git?
>
> Or Nicolás can I convince you to git-ify kdewebdev?

kfilerename pretty much done. Three remaining!

-- 
Nicolás

Re: Stopping release of kdewebdev for Applications 16.08

[Nicolás Alvarez]

> El 6 oct 2016, a las 19:44, Albert Astals Cid  escribió:
> 
> El dimecres, 5 d’octubre de 2016, a les 22:06:22 CEST, Ben Cooksley va 
> escriure:
>> On Wed, Oct 5, 2016 at 10:46 AM, Luigi Toscano 
> wrote:
>>> Albert Astals Cid ha scritto:
 El dimecres, 13 de juliol de 2016, a les 1:27:21 CEST, Albert Astals Cid
 va
 
 escriure:
> El divendres, 8 de juliol de 2016, a les 11:50:44 CEST, Andreas
> Sturmlechner>>> 
> va escriure:
>>> On Friday, 8 July 2016 at 11:11, Luigi Toscano wrote:
 On Friday 08 of July 2016 11:03:05 Andreas Sturmlechner wrote:
 None of them were ported yet, in fact they haven't seen commits in
 years.
 They should probably be converted to git, still, but imo no need to
 keep
 it releasing.
>>> 
>>> Some of them could be probably dropped, but also isn't it possible
>>> that
>>> they slipped out of the radar because not on git? Would it be possible
>>> to
>>> have them converted first and see if this changes?
>> 
>> kommander and kfilereplace are not actually webdev related, so could be
>> moved into other categories (kdeutils?) if not dropped.
>> 
>> Not sure how many people still do image maps (so chances this will be
>> picked up again are slim), and klinkstatus still depends on
>> kdepimlibs-4
>> to build.
> 
> Let's move them to git first and then decide if we want to drop them or
> not.
> 
> Given the freeze for KDE Applications 16.08 is like in 2 days i would
> not
> rush for now, let's all make a note for 2.5 months and decide if we want
> to
> release them for KDE Applications 16.12.
 
 So it's 2.5 months later now.
 
 I would like to get them moved to git if possible, get them released for
 KDE Applications 16.12 and tell people they need to start caring about
 them if they don't want to see them dropped for 17.04
 
 Now the question is, how do we get them into git?
>>> 
>>> I think that sysadmins have (or had) a system dedicated to SVN-to-git
>>> conversion, and also the examples of the old conversions. There are some
>>> instructions here:
>>> https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git
>> 
>> We had such a system - all such machines have since been shutdown though.
>> I think Nicolas has a container on one of our machines which he does
>> the occasional conversion which gets requested in, but it has been a
>> long time since that was last used if I recall correctly.

I had one in fiesta, but I seem to recall you removed it to free space? I can 
recreate it though.

> Any way i can get that 65G svn file somehow or we can't port anything else 
> from svn to git?

It can be downloaded via anonymous rsync, IIRC it's rsync.kde.org::svnmirror.

> Or Nicolás can I convince you to git-ify kdewebdev?

Maybe tomorrow when I manage to wake up. It's adminbeers night today ;)

-- 
Nicolás

Re: kate-15.12 broken with KDE Frameworks-5.17 (was: www/sites/www)

[Nicolás Alvarez]

I don't really follow Kate development, but this is serious enough and
the patch looks good to me, so I took the "be bold" Wikipedia
guideline and cherry-picked the commit to 15.12.

Let me know if I broke something.

-- 
Nicolás

2015-12-13 20:42 GMT-03:00 Albert Astals Cid :
> El Sunday 13 December 2015, a les 20:49:54, Christoph Cullmann va escriure:
>> Hi,
>>
>> it seems that we need fixes for 15.12, see kwrite devel and release
>> coordination list.
>
> Can someone please commit it then?
>
> Cheers,
>   Albert
>
>>
>> I am not sure if the kxmlgui change is a good idea, as all old Kate versions
>> will no longer close sanely if people update their frameworks :/
>>
>> Greetings
>> Christoph
>>
>> - Am 13. Dez 2015 um 18:04 schrieb Albert Astals Cid aa...@kde.org:
>> > El Sunday 13 December 2015, a les 14:23:17, Andreas Sturmlechner va
> escriure:
>> >> > Hi
>> >> >
>> >> > With changes in Frameworks 5.17.0, Kate 15.11.90 no longer closes
>> >> > properly.  Quit the GUI, the app keeps running in Taskmanager for
>> >> > example.
>> >> > Bigger problem this causes is that on reboot you can have 15-20
>> >> > instances
>> >> > of Kate opening right away.
>> >> >
>> >> > [cut]
>> >> >
>> >> > Anke
>> >> > demm at kaosx.us
>> >>
>> >> Indeed, though at first it looks like a dbus timeout (because file open
>> >> with kate breaks as well) all I needed was kate commit
>> >> cd0163d7b956ace0e786a76d8211d06790a2c174 to fix this issue (I also
>> >> backported to 15.08.3). This should really be fixed before 15.12.0
>> >> release.
>> >> It doesn't appear to cause any pre-5.17 breakage since it previously only
>> >> worked by kxmlgui overriding it anyway, according to the commit message.
>> >
>> > Do I understand it correctly that KDE Frameworks 5.17 has been released
>> > with a change that makes existing code break?
>> >
>> > Is that because that existing code was broken to start with?
>> >
>> > Can someone that understands the code better than me please reach to the
>> > conclusion, if what needs fixing is KDE Frameworks or kate and if kate
>> > needs fixing apply the fix on the branches we're releasing and not only
>> > in master?
>> >
>> > Cheers,
>> >
>> >  Albert
>> >
>> >> Andreas
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kate-15.12 broken with KDE Frameworks-5.17 (was: www/sites/www)

[Nicolás Alvarez]

2015-12-13 10:23 GMT-03:00 Andreas Sturmlechner
:
>> Hi
>>
>> With changes in Frameworks 5.17.0, Kate 15.11.90 no longer closes
>> properly.  Quit the GUI, the app keeps running in Taskmanager for example.
>> Bigger problem this causes is that on reboot you can have 15-20 instances
>> of Kate opening right away.
>>
>> [cut]
>>
>> Anke
>> demm at kaosx.us
>
> Indeed, though at first it looks like a dbus timeout (because file open with
> kate breaks as well) all I needed was kate commit
> cd0163d7b956ace0e786a76d8211d06790a2c174 to fix this issue (I also backported
> to 15.08.3). This should really be fixed before 15.12.0 release. It doesn't
> appear to cause any pre-5.17 breakage since it previously only worked by
> kxmlgui overriding it anyway, according to the commit message.

What do you mean "backported to 15.08.3"? I don't see anything in the
15.08 git branch. Do you just mean you tested backporting it locally
and it works, or that you did it in a distro patch?

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Frameworks 5.16.0

[Nicolás Alvarez]

2015-11-08 18:44 GMT-03:00 Luca :
> Hi David,
> I'm not able to download the files on the sftp server, seems that the
> permission are not correct.
>
> drwxr-xr-x3 ftpadmin packager 4096 Oct 10 08:12 5.15
> drwxr-x---3 ftpadmin packager12288 Nov  8 21:03 5.16

Those permissions look correct to me. If you're in the 'packager'
group, you should be able to access 5.16, and the 'ftpchakra' account
is a member of 'packager'.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Nicolás Alvarez]

2014-10-23 11:48 GMT-03:00 Eric Hameleers al...@slackware.com:
 On Thu, 23 Oct 2014, Jeremy Whiting wrote:

 Hey packagers,

 A quick heads up about kdeedu-data strangeness.

 The upcoming KDE Applications 14.12 release will have some
 applications based on kdelibs4 and others based on kf5. Because some
 applications that use libkdeedu/libkeduvocdocument are going to be
 still based on kdelibs4 while others have already been ported to qt5
 and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
 released. Because both used to contain a handful of kvtml files, we
 moved them out into kdeedu-data which both libkdeedu and
 libkeduvocdocument should depend on (or at least khangman(kdelibs4)
 and kanagram(libkeduvocdocument) should depend on in order to run.

 Now kdeedu-data uses ecm instructions to build like other kf5 based
 applications. Is that going to be a problem to make both khangman and
 kanagram run time depend on these packages, while kdeedu-data at build
 time requires ecm to build?

 I'm open to other solutions, but this is the best we could come up
 with at this time.

 thanks,
 Jeremy


 Please explain to me why applications in the 4.14.12 release should depend
 on kf5? The kf5 dependencies must be left out of the tarball for the KDE SC
 4.14 releases.

 And if that is impossible for you, then consider this alternative.

 Anything depending on kf5 or ecm or qt5 will have to be optional when
 compiling the Applications 4.14.12 tarball. Additionally, no build-time
 dependency should be enforced on anything that relates to kf5.

It's 14.12, not 4.14.12. It's a new *major* version, with half the
apps depending on kf5.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Packaging scripts for frameworks

[Nicolás Alvarez]

2013/12/21 Kevin Ottens er...@kde.org:
 On Saturday 21 December 2013 12:38:17 Albert Astals Cid wrote:
 Now, the hard part, how's versioning going to go now and in the future?
 I see you want to do a 5.0 of two frameworks and unstable of the others, so
 let's say 5.0.0 for karchive/threadweaver and 4.9.50 for the others.

 Let's keep it simple and make it 4.9.50 for all of them. We can't exclude that
 karchive or threadweaver won't see some changes between now and the 5.0.

Is that the right number to use? 4.9.50 is less than 4.12...

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: www/sites/www

[Nicolás Alvarez]

2013/11/14 Albert Astals Cid aa...@kde.org:
 SVN commit 1369819 by aacid:

 4.12 Beta 2

 CCMAIL: release-team@kde.org

 [...]

 -Novenber 7, 2013. Today KDE released the first beta of KDE Applications and 
 Platform 4.12.
 +pba href=announcements/announce-4.12-beta2.phpKDE Ships Second Beta 
 of Applications and Platform 4.12/a/bbr/
 +Novenber 14, 2013. Today KDE released the second beta of KDE Applications 
 and Platform 4.12.

There is a typo in the month name there :)

I could fix it myself  but I don't have my ssh keys with me right now.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Apologies for breaking the freeze and a suggestion

[Nicolás Alvarez]

2012/7/11 Aurélien Gâteau agat...@kde.org:
 Le mercredi 11 juillet 2012 11:23:28 Ben Cooksley a écrit :
 On Wed, Jul 11, 2012 at 5:06 AM, Allen Winter win...@kde.org wrote:
  On Tuesday, July 10, 2012 06:32:04 PM Aurélien Gâteau wrote:
  Hi,
 
  This morning I worked on two bug fixes for Gwenview which I pushed to the
  KDE/4.9 branch. Only later in the afternoon did I check email and
  realized I should not have pushed those changes as we were freezing for
  RC2. I want to apologize for that.
 
  Since a git push is a bit too easy to do, I was wondering whether it
  would be possible to have a git hook which would disallow pushing in
  freeze mode. The hook could be designed to only allow commits if they
  have a
  APPROVED_BY_RELEASE_TEAM keyword in the commit message.
 
  This would prevent clueless people like me from pushing when they should
  not. Do you think this is doable?
 
  I don't know if it's doable.  But I like the idea.
 
  Our awesome sysadmins might have some thoughts.

 Whilst this would be possible, it would require maintaining a list of
 all KDE SC repositories which are affected by this freeze, and making
 changes around each freeze period to switch it on and off again.

 I would imagine it would be possible to:
 1. symlink the same hook in all KDE SC repositories so that the hook doesn't
 have to be duplicated.
 2. make this hook read a configuration file so that one only has to update 
 this
 one file for each freeze/unfreeze transition.
 But I may be completely wrong.

It's already the case that a single hook script runs on every
repository hosted in git.kde.org.

What I would do is make the configuration file state the *dates* where
each freeze period starts and ends. That way it doesn't have to be
updated manually exactly when the freeze starts or when it ends, only
if the dates change.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KSecrets State?

[Nicolás Alvarez]

2012/7/10 Albert Astals Cid aa...@kde.org:
 El Dimarts, 10 de juliol de 2012, a les 10:01:53, Rex Dieter va escriure:
 On 07/10/2012 09:56 AM, Jeremy Whiting wrote:
  It seems it has been moved to playground from kdelibs, but the
  application in kdeutils is still sitting there.  Shouldn't that be
  moved to playground also until it works?

 yes, +1

 If noone disagrees, I'll ask sysadmin on thursday to move the app to
 playground too.

I have now moved KSecretsService (repo ksecrets.git) to playground/utils.

(as you probably know, this doesn't affect the git clone URL, only
projects.kde.org)

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Change to tarball generation?

[Nicolás Alvarez]

2012/5/23 Michael Pyne mp...@kde.org:
 As an example, try:

 $ tar cf kdefoo-x.y.z.tar kdefoo-x.y.z/
 $ pixz kdefoo-x.y.z.tar
 # resulting in kdefoo-x.y.z.tar.xz

 Because pixz is parallelized it works on whole blocks of data at a time and as
 far as I can tell makes no special provision for the last bits of compressed
 data being smaller than the block size.

 With a normal tar file the decompressed data you get is:

 0*  (where * is end of data and end of file)

 With a pixz-encoded tar file the decompressed data you get is:

 0*x$  (* is end of data, $ is end of file)

 When you run a command like tar xfJ kdefoo-x.y.z.tar.xz everything will
 still work fine: tar knows exactly where the data should really end and will
 stop decompressing when it needs to.

 When you run a pipeline like xz --decompress kdefoo-x.y.z.tar.xz | tar xf -
 though, there's no way to tell xz to stop decompressing early. It tries to
 write all the decompressed data to the pipe. tar still knows exactly where to
 stop, and does so at the '*', not the '$', and closes its input (a pipe!)
 early.

 When xz tries to write the 'x$' (garble data) of the decompressed output it
 gets sent to a now-broken pipe, which kills xz on SIGPIPE.

 Scripts trying to drive automated extraction of that data using a pipeline
 just see that an error occurred, and will therefore abort. This has affected a
 couple of distributions that are source-based, but is annoying even for those
 manually extracting to have to figure out that their tarball actually
 extracted correctly.

 So the problem is only parallelizing compressors that take advantage of the
 allowance to write garbled data past the end of a file and still have the
 decompressor figure it out. It seems pretty implausible to me that a
 parallelizing compressor would always do this, perhaps this only occurs when
 the compressor is run with tar (e.g. tar cJf) instead of as a separate step?

The garbled data has nothing to do with parallelization. pixz stands
for parallel and indexed xz. Apart from being parallel, it stores a
custom-formatted index at the end of the tarball, apparently to allow
random access.

I also noticed that pixz produces larger results than standard xz,
even when ignoring the extra index data. See:
http://article.gmane.org/gmane.comp.kde.releases/

Please do not use pixz for KDE tarballs again...

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Nicolás Alvarez]

El 09/06/2012, a las 10:30, Aaron J. Seigo ase...@kde.org escribió:

On Saturday, June 9, 2012 13:40:29 Andreas K. Huettel wrote:

Am Samstag 09 Juni 2012, 12:57:16 schrieb Aaron J. Seigo:
now, i really don't understand the use of words like stupid and  
dumb.


I'll leave the fist fighting to others, and would like to apologize  
for my

choice of words.


cool; thanks for that.. this is the KDE i grew to love :)

I still dont think the decision to freeze master was a good or  
necessary
one. It's perfectly reasonable to say hey let's only do bugfix/ 
minimal
changes to *any* kdelibs branch for now, even if for everyone's  
convenience

we keep the usual branch structure.


iirc, that's what we've done. 4.7.x libs branch was similarly  
frozen, and then

we bumped it to 4.8.x ... i assume we'll do the same for 4.9.x.

personally, i think it is completely unnecessary and that we should  
all get
used to it now because it could happen in future that Frameworks are  
released
on a different release cycle to applications so that kdelibs  
version ==
workspaces version will get broken. already kdelibs version != apps  
version
for many KDE applications, particularly many of the bigger ones like  
digikam,

amarok, kdevelop, calligra, etc.


Why not start now and make the next kdelibs 4.8.5? Releasing a kdelibs  
4.9 will just add to the confusion of how kdelibs development is  
working.


Even if we call it 4.9.0, it doesn't need a beta/RC. That causes  
problems because we are releasing multiple versions which *aren't in  
increasing order* and have overlapping release schedules (4.8.80 and  
4.8.4 were very close to each other) from the same branch...


In the past, broken or incomplete fixes in master would simply not get  
backported to the stable branch, or if already backported, reverted in  
the stable branch alone before doing the release (while master got a  
proper fix, eventually). We can't do that now because there is only  
one 4.x branch. In order to release 4.8.4, Dirk couldn't take the  
current 4.8 branch state and wanted to take an older revision and  
cherrypick other commits on top (I forget the exact reason of why this  
was needed, but I think it was because a recent merge in 4.8 broke the  
build). A previous revision had already been tagged as 4.8.80. On my  
suggestion, he made a 4.8.4 *branch* based on an older revision to do  
the needed cherry-picking.


After reading this thread, I see that was not the correct thing to do.  
If some commit in the 4.8 branch was not suitable for 4.8.4 for  
whatever reason, it should have been *reverted*. And IMO there should  
have been no kdelibs 4.8.80 at all.

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.8.80 is out

[Nicolás Alvarez]

2012/6/6, Dirk Mueller muel...@kde.org:
 On Monday 04 June 2012, Albert Astals Cid wrote:

 Good job everyone!

 Hi Albert,

 thanks. it seems you accidentally tagged the KDE/4.8 branch in kdelibs to
 v4.8.80 ?

 git describe
 v4.8.80-19-gc1f6c39


 Could you please double check that you tagged the KDE/4.9 branch on all
 related modules with the release tag?

There is no 4.9 branch in kdelibs. At least not yet.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 4.8.80 is out

[Nicolás Alvarez]

2012/6/6, Albert Astals Cid aa...@kde.org:
 El Dimecres, 6 de juny de 2012, a les 23:09:05, Dirk Mueller va escriure:
 On Wednesday 06 June 2012, Nicolás Alvarez wrote:
   Could you please double check that you tagged the KDE/4.9 branch on
   all
   related modules with the release tag?
 
  There is no 4.9 branch in kdelibs. At least not yet.

 Ah, d'oh. okay, that explains it.

 Well, now we have the mess completed. IMHO we should create a KDE/4.9 and
 move Sebastian Truegs nepomuk branch merge there. then we can also bump
 the
 Qt requirements.

 Why should we move it there? He commited it to KDE/4.8 so he wants it there,
 right?

Where else could he have committed?! There is no master, there is no
4.9. If I wanted something to be in 4.9 but not in 4.8.4, what option
do I have?

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Time to Dump kdewebdev and kdetoys?

[Nicolás Alvarez]

2012/5/22, Alexander Neundorf neund...@kde.org:
 On Tuesday 22 May 2012, Martin Schlander wrote:
 Speaking from a user perspective. I use kfilereplace and klinkstatus, and
 they work fine. Don't see any reason to dump them unless there'd be
 security issues.

 Could they maybe move to kdeutils (does this still exist actually) ?

kdeutils indeed exists, and I'd agree with moving kfilereplace and
klinkstatus there (seems like a fitting category). However, is there
anyone interested in maintaining them?

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdemultimedia move to git aborted for now

[Nicolás Alvarez]

I'm glad to announce that the kdemultimedia git repositories have now
been re-converted. In addition, I rebased the JuK and Dragon MPRIS
work that was done in scratch repos into the newly-converted
repositories.

There are still some minor problems with early (read: ancient) history
of KMix, but fixing that would have delayed the migration too much. I
may fix it in the future, which will need a reconversion of kmix
alone, but don't hold your breath.

I *haven't* tested if the repos can be compiled, and I encourage you
to do test-builds for all ten repositories, and for both master and
KDE/4.8 branches (I heard the 4.8 branches hadn't got the
build-standalone commits backported).

If you had any changes done locally that you couldn't push due to the
repository block, I'll be glad to help with the rebasing in the
mailing list. But if you don't have any local unpushed work, I highly
recommend that you just delete your local repository and clone it
fresh.

Happy hacking!

-- 
Nicolás

2012/4/6, Eike Hein h...@kde.org:
 unfortunately sysadmin woke up today to find that the git conversion
 of the kdemultimedia repositories that was announced yesterday is of
 untenable quality: There is missing history (both in converted branches
 as well as entire missing branches), files are missing from repo-
 sitories and the buildsystem fixes to allow for standalone building
 were not applied consistently across branches, along with potentially
 other problems.

 Due to the brief time window since the migration was announced and
 the relatively few commits that went into them since, we believe
 there is still an opportunity now to abort things and fix up the
 repositories, rather than allow development to happen on top
 of broken repositories and incomplete history.

 As a result all of the kdemultimedia repositories have been locked
 for write access for now.

 Note that this does not mean that development is back in SVN again.
 That is a decision that will have to be made by the kdemultimedia
 maintainers and coordinated with KDE i18n, and will likely depend on
 the time needed to redo the git conversion.

 To the kdemultuimedia maintainers / those in charge of doing the kdemm
 conversion: Please get in touch with our svn2git expert Nicolás Alvarez
 (PovAddict) for details on what needs to be fixed in your conversion
 rules and then figure out a plan for redoing the conversion, as well
 as what steps to take to address the currently-halted kdemultimedia
 development.

 To the kdemultimedia developers: Those of you who have already
 committed to the git repositories may need to see to that your work
 ends up in whatever will be set up to replace them, be that a move
 back to SVN or fixed git repositories, in case that the conversion
 crew is not able to recover them. I trust they will keep you infor-
 med on this front, but stay alert.

 --
 Best regards,
 Eike Hein
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8.3 tarballs uploaded (first part)

[Nicolás Alvarez]

2012/4/29, Dirk Mueller muel...@kde.org:

 Hi,

 I just finished uploading the first part of KDE 4.8.3 tarballs.

 Known issues:

 - the re-assembled kdemultimedia tarball does not compile
 - kde-l10n is still generating.

 I'm on a business trip tomorrow so I'll only have internet access in the
 evening. I'll try to upload the rest and the fixes asap.

 Any help with kdemultimedia is appreciated. the script is in kde-
 common/release/setup-kdemultimedia.sh

The kdemultimedia git repositories are *broken*, and the conversion
rules are in the process of being fixed. Please release kdemultimedia
from the SVN KDE/4.8 branch. The git repositories were locked after
the brokenness was noticed, so there were even some kmix fixes done on
the SVN branch and not on the git repos.

I completely assumed you had already been notified of this by other people...

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Garbage at the end of tar (kde 4.8.2 tarballs)

[Nicolás Alvarez]

2012/4/6, Aleksandar Petrinic petri...@gmail.com:
 There are some data at the end of kdelibs' tar (and maybe in others as
 well). Not sure what kind of data are, but they seem to me like
 garbage.

The trailing garbage data seems to be a non-standard index of the
tarball contents, generated by pixz.

I would advice against using pixz; for the next release use standard
xz instead. For kdelibs, xz even produced a smaller result: the
.tar.xz in KDE mirrors is 11686KiB, but recompressing the tarball
myself with xz -9 gave a 11233KiB file. And down to 11183KiB if I also
remove the pixz-generated index from the end of the .tar.

-- 
Nicolás
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Tags for recent releases are missing in the git repositories of kdelibs and kde-workspace

[Nicolás Alvarez]

2011/12/4, Nicolás Alvarez nicolas.alva...@gmail.com:
 2011/12/4, Allen Winter win...@kde.org:
 For the record:  the tags will be pushed eventually.  But only after Dirk
 is sure the tag is operationally ok.  And sometimes Dirk needs a
 reminder.

 Well, it's understandable that 4.7.4 are missing, since the tarballs
 aren't even out yet.

 However, 4.7.80 tags were already pushed to several repositiories, but
 remain missing in kdelibs, kdepimlibs, kde-workspace, kde-baseapps,
 kde-runtime, blinken, cantor, and probably more (I didn't check
 *everything*). Especially the fact that they're on every kdeedu repo
 except blinken and cantor, points at an oversight and not something
 expected.

Situation remains. The 4.7.80 tags I mentioned are still missing, and
*nothing* has 4.7.4 tags, even though both versions are officially
released now.

-- 
Nicolas
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.8 Beta2 (4.7.90) tarballs uploaded

[Nicolás Alvarez]

2011/12/4, Dominik Haumann dhaum...@kde.org:
 Hi ;)

 On Saturday, 3. December 2011, Dirk Mueller wrote:
 Hi,

 just finished uploading the Beta2 tarballs. I've applied a small patch to
 kdelibs to make it look like a 4.8 version, although it is taken from 4.7
 branch.

 Still doing some basic testing on it, please let me know if you find any
 issues.

 again the question from where the Kate sources come from: there is no 4.8
 branch in the kate.git module. Is it from master?

 Thanks for the info!

 Greetings
 Dominik

Well, there is no 4.8 branch *anywhere* yet, so yes, it's probably from master.

-- 
Nicolas
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Tags for recent releases are missing in the git repositories of kdelibs and kde-workspace

[Nicolás Alvarez]

2011/12/4, Allen Winter win...@kde.org:
 On Thursday 01 December 2011 2:06:35 PM Albert Astals Cid wrote:
 El Dijous, 1 de desembre de 2011, a les 20:46:35, Shlomi Fish va escriure:
  Hi all,
 
  tags for recent releases of KDE (such as KDE-4.7.80) are absent in the
  git
  repositories of kdelibs and kde-workspaces:
 
  
  snip
 
 
  I was told that the tags were applied to the releases locally and not
  pushed. This is confusing, and it should be fixed, and such a practise
  should be avoided into the future.

 You should read the list before complaining about something that has
 already
 been discussed. Please avoid that in the future.

 For the record:  the tags will be pushed eventually.  But only after Dirk
 is sure the tag is operationally ok.  And sometimes Dirk needs a reminder.

Well, it's understandable that 4.7.4 are missing, since the tarballs
aren't even out yet.

However, 4.7.80 tags were already pushed to several repositiories, but
remain missing in kdelibs, kdepimlibs, kde-workspace, kde-baseapps,
kde-runtime, blinken, cantor, and probably more (I didn't check
*everything*). Especially the fact that they're on every kdeedu repo
except blinken and cantor, points at an oversight and not something
expected.

-- 
Nicolas
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Heads-up: kdeutils is moving to git

[Nicolás Alvarez]

On 8/21/11, Aaron J. Seigo ase...@kde.org wrote:
 On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote:
 Superbuild is unrelated and orthogonal to the code in kdeutils to
 allow building as a single module.

 yes, and that's the challenge here: it takes ~10 seconds to put a bunch of
 add_subdirectory calls into a CMakeLists.txt file. the issue is having to
 manually keep up a bunch of git repositories individually, from cloning to
 pulling, ensuring they are in the correct hierarchy initially on disk, etc.

Correct, because that's not the problem it's supposed to solve. The
CMakeLists.txt with add_subdirectory lines is just if someone wants to
make a tarball that works just like the old kdeutils.tar before the
split, ie. recreate the 'whole module' build. For *that* task, I
think superbuild is the wrong tool. For example, if Dirk makes a
monolithic kdeutils tarball, he should use this instead of superbuild.

I see superbuild as a third tool in the same category as kdesrc-build
and build-tool, cloning and pulling a bunch of git repositories,
ensuring they are in the correct hierarchy on disk, etc. And it's
probably a good task for that job.

But this is the release-team list, so here I'm talking about the
release, not the developers' workflow. Jeremy said, If Dirk is going
to use superbuild to do the release tarballs...; *that* is what I
think is a bad idea.

-- 
Nicolas
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team