Re: ksysguard 5.22.0 tar for packaging
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?
> 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
Bad merge on dolphin.git rolled back
FYI, someone accidentally merged master into stable in dolphin.git: https://phabricator.kde.org/T8127 I rolled back Applications/17.12 to a618383df3. It's now missing: - All the master commits that shouldn't have been there - "Add icons to Edit menu" (D10503) which was probably targeted for master only, but could be cherry-picked to 17.12 if that was the intention - a scripty change to a .desktop file, which I guess it will do again tomorrow As usual, this may cause some disruption to people's local clones. We've had to do this kind of git rewind more than once, but usually we notice in hours. In this case the mistake was done 2 weeks ago and we never noticed until now, so I guess more local clones will be affected. If you had any change pending push to dolphin 17.12 you'll have to rebase it. (I feel like I had something else to mention but I'm too tired to remember) -- Nicolás KDE Sysadmin Team
Re: KDE Frameworks 5.43.0
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&m=151765309314964&w=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
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
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)
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
> 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)
> 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
2016-10-31 7:54 GMT-03:00 Albert Astals Cid : > 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 : >> > > 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 >> >> 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
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
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
> 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)
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)
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
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: KF 5.5.0 release
2014-12-06 10:31 GMT-03:00 David Faure : > Here's KDE Frameworks 5.5.0 > > Public release on, hmm, I'm not available until Dec 15. > > If someone can take care of making it public on Thursday, that might be a > better idea. > > Changelog coming up later today. This change is required for anything using FutureBookmark to compile on Windows; such as Konversation (beta recently released): https://git.reviewboard.kde.org/r/121075/ I'm not sure if it's worth rerolling the tarball though. -- Nicolás ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KF 5.4.0 released
2014-11-02 14:20 GMT-03:00 David Faure : > On Sunday 02 November 2014 17:28:50 David Faure wrote: >> Dear packagers, >> >> here's KDE Frameworks 5.4.0. > > Hmm, I just realized that one of my new APIs (KIO::drop) wasn't > ready for public consumption (and will change), so I disabled it > in this release (nothing is calling it yet). > > kio v5.4.0-rc2 > 065996dbed46327a7936b79501e6c8c1c73b722c > c852f21faa0b4b6cad9396c530d526868bcfaa865925ce03bbe79418739549d1 > sources/kio-5.4.0.tar.xz KIO also doesn't build on Windows. I submitted a patch to gerrit: https://gerrit.vesnicky.cesnet.cz/r/141 -- Nicolás ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: kdeedu-data
2014-10-23 11:48 GMT-03:00 Eric Hameleers : > 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: KF 5.3.0
2014-10-04 18:41 GMT-03:00 David Faure : > After some compilation fixes (related to .po files and the new > kf5_entry.desktop files in kconfigwidgets), I re-packed > kio, kconfigwidgets, kdoctools and kwallet. > > Thanks to shumski and demm for reporting these issues (and fixing some of > them, even). > > Updated REVISIONS_AND_HASHES attached. kio doesn't build on Windows, because kio_trash_win is apparently not even ported to Qt5(!). I'll need some help though, so I'll wait until tomorrow (european awakeness time) to do it. -- Nicolás ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Packaging scripts for frameworks
2013/12/21 Kevin Ottens : > 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
2013/11/14 Albert Astals Cid : > 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. > +KDE Ships Second Beta > of Applications and Platform 4.12 > +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: KSecrets State?
2012/7/10 Albert Astals Cid : > 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: Apologies for breaking the freeze and a suggestion
2012/7/11 Aurélien Gâteau : > Le mercredi 11 juillet 2012 11:23:28 Ben Cooksley a écrit : >> On Wed, Jul 11, 2012 at 5:06 AM, Allen Winter 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: Change to tarball generation?
2012/5/23 Michael Pyne : > 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+
El 09/06/2012, a las 10:30, "Aaron J. Seigo" 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
2012/6/6, Albert Astals Cid : > 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: 4.8.80 is out
2012/6/6, Dirk Mueller : > 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: Time to Dump kdewebdev and kdetoys?
2012/5/22, Alexander Neundorf : > 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
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 : > 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)
2012/4/29, Dirk Mueller : > > 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)
2012/4/6, Aleksandar Petrinic : > 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
2011/12/4, Nicolás Alvarez : > 2011/12/4, Allen Winter : >> 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
2011/12/4, Dominik Haumann : > 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
2011/12/4, Allen Winter : > 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
On 8/21/11, Aaron J. Seigo 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