Re: Request for help / review / sponsors: kpmcore
Hey So we already have kpmcore packaged here [1], which might be a better place to start. Cheers Rohan Garg [1] https://packaging.neon.kde.org/kde-extras/kpmcore.git/tree/debian?h=Neon/release -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Apologies to Rohan and some more
Hi > And again, Rohan, my apologies. Apologies accepted. Let's move forward and keep doing awesome work together :) Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Setting QT_SELECT globally via debian-qt-kde.mk v3
> So yeah, figuring out where qmake is called from PATH and fixing that > to use Qt5::qmake LOCATION would be best here. > Fair enough. I'll poke it a bit more to see why it's resolving qmake from PATH in certain projects. Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Setting QT_SELECT globally via debian-qt-kde.mk v3
Hi We're currently facing a general problem that a few frameworks packages explicitly export QT_SELECT in their debian/rules ( kdesignerplugin, kjobwidgets, kauth to name a few ). Since v3 of debian-qt-kde.mk only supports Qt5 and Frameworks 5 anyway, I was wondering if I could just go ahead and export QT_SELECT=5 directly in debian-qt-kde.mk instead of each packaging doing it for themselves. Since this only affects v3 of the script, KDE4 packages using v2 should be un affected by this change. Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Setting QT_SELECT globally via debian-qt-kde.mk v3
> I'm not entirely sure this is a good idea (yes, I changed my mind since this > morning). As far as I understand all the KF5 packages are using CMake. If so > they don't require this variable. > Could you perhaps elaborate why you think it's not a good idea? > Is there anything I'm missing here? Right, I think I forgot to mention before that we're using KDE_USE_QT_SYS_PATHS in the packaging scripts which makes triggers a call which essentially looks for qmake, and in some cases, the qmake symlink points to a non existent Qt4 qmake which causes dh_auto_configure to fail. Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Moving forward on fixing bug 721938
2015-04-23 15:28 GMT+02:00 Lisandro Damián Nicanor Pérez perezme...@gmail.com: Does [0] works without patching qt4? I've been told it does work, so I guess it's between me forking the Qt4 packages and maintaining them by myself or using that hack. Ah well ... [0] https://github.com/davidedmundson/qtsystemtraypreloadhack -- http://xkcd.com/150/ Personas como ésta no se encuentran todos los días. Y cuando uno las encuentra, suelen no estar disponibles. Si encontrás una, no la pierdas. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: Qt 5.4 and QtWebEngine
I'll stand up to ship it :) Regards, sandro I can help with whatever needs fixing and what not. Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Re: RFC: Moving kubuntu packaging branches to pkg-kde git
-- Forwarded Message -- Subject: RFC: Moving kubuntu packaging branches to pkg-kde git Date: Tuesday 03 June 2014, 22:00:46 From: Philip Muskovac yo...@gmx.net To: pkg-kde-talk@lists.alioth.debian.org Hi pkg-kde team, as we're currently in another rather painful package merge cycle, and with kf5 and plasma next just outside the door we've been talking about how we could move our packaging branches over to debian git to help with the merging and the rather large about of work duplication on both sides. For the large amount of SC/KF5/plasma packages we use a mostly scripted workflow which we would like to keep using, so we came up with this git branch layout: - master: has the shared packaging and targets the latest upstream (beta?) release (which should really be everything as long as something doesn't cause a problem for the other team) - series (e.g. unstable, utopic): has any distribution specific changes that cannot be kept in master (like specific patches, recommends/suggests changes for archive reasons) and is used to generate the actual archive packages for that specific series. While I believe that this mostly should work fine, at this point I'm not quite sure how to manage the changelog. OdyX suggested generating it from the git commit messages which I think would work out best, as we could then keep our respective distribution changelogs and only share the change messages. A while ago I talked with maxy about commit access permissions, but for now I don't believe this would be an issue as most kubuntu packagers already are members of pkg-kde. For now, I would propose trying this shared repository idea out with the new kf5 and later also the plasma packages as you don't have any repositories for those yet. Would this be something you would consider? It would help us a lot as this would prevent us spending weeks to merge our packages and you would already have the changes for a new release in master when you plan to switch to it. Cheers, Philip Muškovac (yofel) Kubuntu Developer - Could we move this forward maybe? :D @Pino would be awesome to have any comments you might have against this :) Cheers Rohan Garg -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
