Re: Moving to salsa: IRC meeting coordination?

Hey, > So what about this saturday 10, 17 UTC? I'm just reusing Dmitry's proposal, > I should be able to take other date/time too. from Friday on I'll be in vacation for one week. But no need to reschedule the event because of me. hefee signature.asc Description: This is a digitally

Further processing kdepim bugs

Hey, > Because they are still valid bugs in Debian. As long as those buggy > versions are present in the archive they are valid bugs. > > Or at least that's what I understand from the text. If the bugs are not > really in the archive then it's really ok to close them. Well the versions for that

Re: Fwd: Bug#529431: marked as done (akregator: Sometimes "unread" is more then "total")

Hey, > This should be marked as wontfix, not being closed. > > Yes, I sadly saw the thread about this too late, my bad on that side. Why you think it is better to keep those bugs open? I can understand the wontfix tag, but still I think that closing those bugs make it easier to get an

Re: Adding salsa to our food^w workflow

Hey, On Mittwoch, 27. Dezember 2017 14:14:32 CET Lisandro Damián Nicanor Pérez Meyer wrote: > El martes, 26 de diciembre de 2017 12:54:22 -03 Boris Pek escribió: > > >> This is not mutually exclusive, see [1] as example. > > >> > > >> [1] https://salsa.debian.org/salsa/support/issues/1 > > > >

Re: kdepim 17.08.3 and kde-l10n

Hey, > I'd kindly ask you to hold that until: > a) KDEPIM 17.08.3 migrates to testing > b) I sort out the coinstallation issues with kdepim4 my thought was to use experimental to prepare 17.12 and also use a debian/ experimental branch in git to not interfere or do you need experimental to

Re: kdepim 17.08.3 and kde-l10n

Hey, I added the release team list, cause they may help explaining interpret the britney output. And help to find the right buttons to push, to get kdepim migrating to testing. > > I tried to understand, why kdepim hasn't moved to testing, but I don't > > understand the britney output

Re: kdepim 17.08.3 and kde-l10n

Hey, > Yes, so far there are no blocking issues on our side, so I'd wait for > the stack to migrate, and then we can do eventually more uploads. > Of course, feel free to add your changes to git in the meanwhile > (pushing them, heh). That's why I didn't want to dig into it, because I wanted to

Re: kdepim 17.08.3 and kde-l10n

Hey, now we got some issues for the new kdepim 17.08 stack. What is the best way to go on? fix them "as fast as possible" or better wait till it migrates to testing? I'm thinking, if it may break the tessting migration, if we upload here a new kdepim-runtime here a new whatsoever... #885111

Re: Fwd: KGlobalAccel regression in latest frameworks release

> On September 13, 2017 10:47:18 PM GMT+02:00, "Sandro Knauß" <he...@debian.org> wrote: > >Hey, > > > >i think we also should look at this issue. > > > >sandro > > > >-- Forwarded Message -- > > > >Subject: KGl

pkgkde-vcs issues

Hey, i actually uploading the fixes for jessie and stretch for CVE-2017-9604. #869573 #869574 #869577 and therefor I have in the distribution field stretch/jessie and this is not handled $pkgkde-vcs tag -s pkgkde-vcs: fatal: invalid Debian distribution for tagging - stretch this issue is

Re: Bug#864803: CVE-2017-9604: Send Later with Delay bypasses OpenPGP

will only changes of the concrete version number. I don't care in the end you is uploading the fixes :) Best Regards, sandro -- On Samstag, 17. Juni 2017 09:12:29 CEST Sandro Knauß wrote: > Hey, > > I have now have a fixed version for stretch and sid (see debdiff). Because &g

Update of Maintainers line in changelog in QtWebEngine

Hey, Many many thanks for starting to updating QtWebEngine Qt 5.9! please do not update the maintainers line in d/changelog, if the package is not released. You did this both in QtWebEngine - see 62d8cc8c6cb76218485fc4c6155cc44a1b869b4a eb04798274417ab265cbc2a468352820021c2539 First updating

Re: Packaging PythonQt for Qt 5

Hey, the SVN link actually pointed me to look at who is actually the maintainer of pythonqt and saw, that is not Debian KDE Maintainers. It is the QA Team . So that are the people that you need to talk to, because only those can add your work. Additonally they may have

Re: Packaging PythonQt for Qt 5

Hey, > How can I submit my packaging changes for review? Are you using pull > requests somewhere? there is no "formal way" nor pull request. The normal workflow is to use mentors and personal repos and send the link around. * mentors.debian.org *

Re: QtWebEngine build fails

Hi, Thanks for all your input till now. I now managed it to get it build on i386 successfully on buildds (5.7.1+dfsg-2) [0] so it uses less RAM but still it needs around 15GB disk space to build. It actually also used to much RAM for an successfull amd64 build on buildds. The fix I did was to

Re: post-receive hook

Hey, > Sorry but I don't get you. Are you talking about adding a hook in alioth's > repos? yes exactly I'm talking about pkg-kde repos on alioth - sorry I was not that precise in my first mail: here is the diff (git.debian.org): --- /git/pkg-kde/pkgkde-post-receive-hook~ 2016-01-05

Re: QtWebEngine build fails

://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=armhf=5.7.1%2Bdfsg-1=1482632568 -- Am Sonntag, 25. Dezember 2016, 02:14:12 CET schrieb Sandro Knauß: > Hey, > > qtwebengine [0] entered sid today and unfortunately it failed for some > archs. well it is one of those packages, tha

QtWebEngine build fails

Hey, qtwebengine [0] entered sid today and unfortunately it failed for some archs. well it is one of those packages, that needs more than 4GB RAM/space for building. IMO I think the i386 build failed just because the buildd has not enough ram/space for the build. [1] For armel[2] i'm not sure

Bug#844247: akonadi-googledata: RM akonadi-googledata - Upstream is dead and kdepim is using libkgapi

. The only problem that can occur for users, is that the new akonadi don't do a default upgrade to the new resource. But the upgrade process from akonadi4 -> akonadi5 must be done anyways and this old package isn't helping in this upgrade process. Best Regards, Sandro Knauß -- h

Re: Request for help / review / sponsors: kpmcore

Hi, warm welcome in packaging world ! so I started to review the version on mentors. My comments may be too short to you to understand, feel free to ask if you don't understand a point or have different opinion in some points, some of the points are recommendations. d/control: * why you use

Re: QtWebEngine ready for upload

Hey, > Please rename the binary packages for consistency with other Qt modules: > > * libqt5webengine-dev → qtwebengine5-dev (cf. qtbase5-dev) > * qt5webengine-examples → qtwebengine5-examples (cf. qtbase5-examples) > * qt5webengine-doc{,-html} → qtwebengine5-doc{,-html} (cf. qtbase5-doc)

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

Hey, > >> -PIC implies -fPIE. Replacing -fPIE with -fPIC is the right thing to do, > >> and is needed to get the code working with Qt 5.4.2+. > > > > And also: yes, -fPIE needs overriding if using hardening flags. > > can you explain that in more detail? what specifically should be >

Re: kmail CVEs and patches

Hey, > I tried to backport the CVE-2016-7966 fix commit to kf 5.26 and it didn't > apply cleanly, it would be nice if the advisory includes the list of the > commits to backport, or maybe a new 5.26.1 kcoreaddons bugfix release. Yes another patch is missing there - I already informed them and

Re: [d...@fifthhorseman.net: Re: gpgme 1.7.0~ alpha or beta to debian experimental?]

Hey, > I'm not entirely sure what to do about the name of the library during > this handoff -- it might drop the "kf5" prefix. If we don't drop the > "kf5" prefix, i suppose we'll need an epoch number in the package > version to make sure that upgrades happen. It's also possible that > we'll

Re: gpgme 1.7.0~ alpha or beta to debian experimental?

Hey, I now started to build cpp and qt bindings for gpgme but ran into a issue with the hardening flags. The problem is the -fPIE. With this enabled configure stops with: configure:19628: checking whether a simple qt program can be built configure:19639: g++ -o conftest -g -O2

Re: Qt install binary path

Hey, Thanks a lot for uploading! > Well, yesterday I took your branch and build it without issues (tests ran > just fine). But somehow buildds seems to disagree with me, as it seems a > test is failing there. > > Is there anything I might be missing? I don't know. From the tests it is the

Qt install binary path

Hey, I try currently to enable tests for qtdeclarative. So far it all works fine, but the tests using: QLibraryInfo::location(QLibraryInfo::BinariesPath) + QLatin1String("/ qmlscene") to run qmlscene. The problem with that is that qmlscene is also part of the package and is not installed

Re: QtWebChannel ready for upload

Moin, > Uploaded with some packaging tweaks and improvements, thanks! > > Please tag the upload when it is accepted. done. Regards, sandro signature.asc Description: This is a digitally signed message part. -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

QtWebChannel ready for upload

Hey Lisandro, I uploaded QtWebChannel to mentors. I think it is ready for upload now: https://mentors.debian.net/debian/pool/main/q/qtwebchannel-opensource-src/qtwebchannel-opensource-src_5.6.1-1.dsc Can you sponsor it? Regards, sandro signature.asc Description: This is a digitally signed

Re: Getting QtWebChannel ready for upload

Hey Dmitry, > On Debian this should be nodejs rather that node (see #614907). Oh thanks for this notice. But changing the node -> nodejs results now in another lintian warning: W: qtwebchannel-examples: script-not-executable usr/lib/x86_64-linux-gnu/qt5/ examples/webchannel/qwclient/qwclient.js

Re: Getting QtWebChannel ready for upload

Hey, Maybe we should use gobby for our uptodate TODO list (install the package named gobby). I used now gobby.debian.org/Teams/KDE/qtwebengine. I think than we will follow the normal qt package rules and create a example, doc and doc-html packages to be consistant. My answers about merging

Re: GpgME C++ / Qt language providers ready for merge?

Hey, > looks reasonable to me. I'm assuming that in debian, we'd have the > gpgme1.0 package (maintained by pkg-gnupg-maint) take over the binary > packages from the gpgmepp souce package (maintained by the Debian Qt/KDE > maintainers). I've cc'ed both groups on this e-mail so that people are >

Re: Qt4's Webkit in Stretch

Hey, > And now that the facts are on the table I will give you my personal opinion: > even if lots of important apps depend on it I would remove it at least from > testing. I can understand your option and also think this is okay, but I would like to get a exception for kdepim/kdepim-runtime.

Re: Qt 5.4 and QtWebEngine

Hey, kdepim in now on the track to release a Qt5 version in August. kdepim has a dependency on QtWebEngine. Of course I won't stop anyone in trying to ship it. But if no one steps up to maintain it I will not hesitate in simply ignoring it as much as possible, even at the point of not