Re: tasksel's task-kde-desktop seems to be outdated

[Scott Kitterman]

On Monday, April 09, 2018 06:46:39 PM Maximiliano Curia wrote:
> Hi,
> 
> It seems to be that time again when task-kde-desktop needs to be updated.
> And I think that it would be better to send one single bug with all the
> changes to that we want to do.
> 
> Currently task-kde-desktop recommends:
>  - k3b.
>Does anybody uses their cd burner nowadays?
>-> I'm inclined towards a remove from task-kde-desktop
>-> lisandro via irc suggest to remove it and to add to kde-full
>  - dragonplayer
>Already installed by kde-standard
>-> My suggestion: remove
>  - kdesudo
>kde4 based, we also have kdesu which uses sudo by default (but it's
> shipped in a libexec dir, so it's not really for "public" use), but at the
> same time upstream disrecommends launching qt apps as root.
>  - apper
>I'm not sure if this should be replaced by plasma-discover, I guess
>Matthias is the right person to make a call here.
>  - gimp
>While it's a great piece of software, is it really worth having it in the
> default installation?

If we want something like this, would krita be an adequate replacement?

> Other desktops seems to also provide:
>  - xsane / some way to use a scanner
>We have skanlite (currently suggested by kde-standard) and/or digikam,
>should we recommend these?

digikam, while it supports this, is focused on another use and is a large 
application.  I use skanlite and find it suitable for this use.  I think it 
should be included as 'scan a document' is a common thing to need to do.

> Other packages:
>  - kdeaccessibility depends upon jovie (KDE4 based), kaccessible (KDE4
> based), kmouth (KDE4 based), I'm not even sure if these are usable right
> now. :/ - should we recommend/suggest krita?
>  - Does anybody really uses dragonplayer? Shouldn't we recommend vlc
> instead?

I don't use any of the above, but my kids use VLC.  My recollection is that 
dragonplayer isn't much maintained these days, perhaps someone else knows 
more.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Mailing List Continuation

[Scott Kitterman]

On Monday, January 22, 2018 03:39:36 PM Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On 21 January 2018 at 14:19, Boris Pek  wrote:
> > Hi team,
> > 
> > Some news about the future of mailing lists on Alioth:
> > https://wiki.debian.org/Alioth/MailingListContinuation#Announcement
> 
> Which lists do we really need?
> 
> The commits lists should probably go away.
> 
> For starters I would say this one (pkg-kde-talk), the others are
> @lists.debian.org which should just stay. I don't know what to do with
> pkg-kde-extras.

Since pkg-kde-talk is a list for humans to discuss things and not just a 
target for bug reports and such, it's a reasonable target to move to 
lists.d.o.

There does need to be a list to get all the bug reports (i.e. the target of 
the maintainer/uploader field), but I don't think that's a lists.d.o list.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kwallet-kf5 on mips

[Scott Kitterman]

On December 4, 2016 10:44:44 AM EST, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>On domingo, 4 de diciembre de 2016 15:40:21 ART Sandro Knauß wrote:
>> Hey,
>> 
>> with current kwallet 5.28.0, kwallet fails to build on mips archs
>> (mips, mips64el and mipsel) [0].
>> It complains about a missing symbol, that is defined in [1] and used
>in [2]:
>> [...]/kwalletd.cpp:1805: undefined reference to
>> `KWallet::Backend::entryDoesNotExist(QString const&, QString const&)
>const'
>> [...]/kwalletd.cpp:1810: undefined reference to
>> `KWallet::Backend::entryDoesNotExist(QString const&, QString const&)
>const'
>
>There was a binutils bug wrt linking stuff. I *think* it should not be
>present 
>anymore, but maybe a package needs a binNMU to fix it?
>
>Yes, a wild guess here.

A give back should be sufficient.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Bug#827194: RM: qtquick1-opensource-src -- ROM; Deprecated, will not build anymore with current Qt 5

[Scott Kitterman]

On Monday, June 13, 2016 12:17:33 PM Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi FTP masters! I would like to ask you to remove qtquick1-opensource-src
> from both unstable and experimental.
> 
> It will not longer build with the current version of Qt in unstable
> (actually the one being built right now).
> 
> Affected packages are kadu, kadu-mime-tex and musescore:
> 
>  ian.org;tag=qtquick1-removal>
> 
> Thanks in advance, Lisandro.

Please remove the moreinfo tag once the reverse-depends issues are resolved.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Debian, (Py)Qt5 and QtWebKit

[Scott Kitterman]

On Monday, January 25, 2016 08:12:02 AM Florian Bruhin wrote:
> Hey,
> 
> (Cc'ing Kovid/Detlev because I think they'll be impacted by this
> as well as the upstreams of Eric/Calibre, Cc'ing Axel Beckert because
> I'm working with him for the package mentioned later in this mail)

OK, kept them in CC.

> I'd like to discuss the future of Qt5's QtWebKit (and PyQt's bindings
> for it) in Debian. Looking at the Qt 5.6 beta, it seems like Qt
> upstream will definitely remove QtWebKit - not only from the binary
> releases, but from source releases as well.

As far as PyQt5 goes, I expect we'll support it as long as upstream does and 
Debian is shipping Qt5 WebKit (which I don't maintain, so I won't address).

> As it's likely many packages will still need a Qt5 QtWebKit, and based
> on [1] ("Qt5's WebKit is expected to stay supported until Qt6") it
> looks like Debian will still continue to support it, if necessary
> building from upstream's git[2]?
> 
> As for the PyQt5 wrappers for QtWebKit, upstream says[3]:
> > AIUI, they are still providing source releases.  You're going to
> > continue to support that, right?
> 
> Yes, if they are part of the official release. If not then I won't
> do anything to break things, but they won't be officially
> supported.
> 
> I'm planning to open an ITP for my project[4] using PyQt and
> (currently) QtWebKit soon, and I'm guessing for at least Eric[5] and
> Calibre[6] this is a problem as well.
> 
> Will Debian also support PyQt's QtWebKit until Qt 6 if possible?
> If not, what will happen with the packages which depend on it?

I think that is the goal.  WebKit (and support for it in PyQt4) are, however, 
definitely going away sooner rather than later.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt4's Webkit in Stretch

[Scott Kitterman]

On Friday, January 22, 2016 05:24:41 PM Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Friday 22 January 2016 17:16:26 Lisandro Damián Nicanor Pérez Meyer
> wrote: [snip]
> 
> > Does anyone has a better idea?
> 
> Not necesarily better, but an idea after all:
> 
> (partialremove) check which packages use qt4's webkit for web browsing and
> only remove those from testing.

It's say to process untrusted data (which could be more than just web 
browsing), but with the modification, I agree it would be an option.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: New Base for symbols in Qt5.6

[Scott Kitterman]

On Monday, December 28, 2015 11:08:27 AM Adam Majer wrote:
> On Mon, Dec 28, 2015 at 02:57:50PM +0300, Dmitry Shachnev wrote:
> > On Sun, Dec 27, 2015 at 03:41:39PM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > >> In any case I think we should keep the logic in pkg-kde-tools package,
> > >> i.e.
> > >> replace the existing script with mine or extend its logic. I hope
> > >> Python
> > >> dependency is not a problem, is it?
> > > 
> > > I'm totally for it. If it becomes a problem for someone we can consider
> > > generating a new binary package from the same source and adding the
> > > python
> > > dependency there. We might even do that from the beginning.
> > 
> > Maybe we should actually rewrite it in Perl or shell. (Any volunteers? :))
> 
> AFAIK, this is only to check symbols at build time? So Build-Depends
> on python (or python-minimal) and no additional runtime depends. There
> is no use creating work where none is required, especially if we
> already have the most readable language out of the three :D

Not python{3}-minimal as nothing outside the core python/python3 stack is 
supposed to depend on those.  Also, it'd be nice for it to be python3 vice 
python since that's the future.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Scott Kitterman]

On Tuesday, December 22, 2015 03:52:00 PM Dmitry Shachnev wrote:
> Hi Scott,
> 
> On Tue, Dec 22, 2015 at 07:08:06AM -0500, Scott Kitterman wrote:
> > It's not a new package.  It was just behind several releases and the
> > question was to either update to the last Qt4 release or an unreleased Qt5
> > version.
> 
> By “new package” I meant kgeomanip, which was never packaged.

Ah.  That's a bit different.  I still think it's not a problem if a Qt5 version 
is coming soon.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Scott Kitterman]

On December 22, 2015 6:31:11 AM EST, Dmitry Shachnev  wrote:
>Hi all,
>
>On Mon, Dec 21, 2015 at 11:38:41PM -0500, Scott Kitterman wrote:
>> Digikam is notoriously difficult to package before final release due
>to
>> depending on unreleased library versions and/or embedded code copies.
> Not
>> packaging pre-release versions of Digikam is an eminently reasonable
>thing
>> to do.  This is particularly true right now when no one else was
>working on
>> it at all AFAICT.
>>
>> It's not entirely clear is we'll succeed in getting entirely rid of
>Qt4 this
>> cycle.  The thing we know for sure is going away is QtWebKit for Qt4.
>
>If nobody is developing a Qt 5.x version of Digikam, then maybe
>packaging the
>Qt 4.x version is OK. Otherwise I would rather not introduce any new Qt
>4.x
>packages to Debian (especially provided that the official support for
>Qt 4
>ended 3 days ago [1]).

It's not a new package.  It was just behind several releases and the question 
was to either update to the last Qt4 release or an unreleased Qt5 version.

In standard Debian style the person doing the work decided (well IMO) and we 
who didn't do the work ought to lay off the second guessing.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Building DigiKam 4.14 with libkgeomanip and other former "extras"

[Scott Kitterman]

On December 21, 2015 10:18:29 PM EST, Adam Majer  wrote:
>On Mon, Dec 21, 2015 at 08:49:34PM -0600, Steve M. Robbins wrote:
>> I am aware of 5.x betas.  I hesitate to use them right now because of
>the 
>> "beta" status.  The announcement post itself [1] says "This version
>is for 
>> testing purposes. It’s not currently advised to use it in
>production."  
>> 
>> Maybe this is overcautious?  Opinions welcome.
>
>I think this is overcautious. Qt 4 is to be removed from Debian so
>removing dependencies on Qt 4 is preferred to adding new ones.

Digikam is notoriously difficult to package before final release due to 
depending on unreleased library versions and/or embedded code copies.  Not 
packaging pre-release versions of Digikam is an eminently reasonable thing to 
do.  This is particularly true right now when no one else was working on it at 
all AFAICT.

It's not entirely clear is we'll succeed in getting entirely rid of Qt4 this 
cycle.  The thing we know for sure is going away is QtWebKit for Qt4.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: AppStream, Discover and metadata

[Scott Kitterman]

On Monday, November 23, 2015 06:26:49 PM Rohan Garg wrote:
> Hi
> 
> > For Debian, I'd like to know what we need to do to get Qapt + Appstream
> > working.
> 
> Any particular reason why we shouldn't use packagekit + appstream?

All the work I've done with Muon so far is with the QApt backend.  Personally, 
I prefer using something specifically designed to work with Apt.  It seems to 
be working reasonably well.  The problematic bits for Debian seem to be around 
the parts of Muon that use update-manager, which is no longer in Debian.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: AppStream, Discover and metadata

[Scott Kitterman]

On Monday, November 23, 2015 06:03:54 PM Matthias Klumpp wrote:
> 2015-11-23 17:59 GMT+01:00 Aleix Pol :
> > Hi Debian KDE,
> > Most of the discussion also applies to Debian, I've been requested to
> > ask you as well.
> > 
> > Note that I created a branch called "qapt+appstream". Maybe somebody
> > can give it a go. If you don't want to fix PackageKit, that is.
> 
> ...if PK needs fixing at all ;-) I'm PK developer, and judging from
> the bug reports, there is nothing major which needs fixing.
> Parallel-processing support would be nice, and a few papercuts exist,
> but nothing is really broken, actually.
> GNOME is using PK by default without problems for two release cycles
> already.

The fixing PK comment was an unfortunate carryover from Ubuntu where the issue 
is that it's out of date.

For Debian, I'd like to know what we need to do to get Qapt + Appstream 
working.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Getting rid of kde{base}-workspace-dev

[Scott Kitterman]

Since we no longer provide a KDE 4 workspace, pretty much any package that 
build-depends on workspace-dev is partly or fully non-functional.  We ought 
to, in short order, get rid of it.  Here's the affected packages:

reverse-depends -b kdebase-workspace-dev
Reverse-Build-Depends
=
* bespin
* kshutdown
* ktorrent
* plasma-widget-yawp
* sentinella

reverse-depends -b kde-workspace-dev
Reverse-Build-Depends
=
* apper
* kcometen4
* kdeplasma-addons
* kdevelop
* kget
* knemo
* ktux
* plasma-widget-adjustableclock
* plasma-widget-smooth-tasks
* redshift-plasmoid

I did an upload today that took care of ktorrent.  The rest of the packages 
will either need an rm bug, update to a Plasma 5 version if one exists, or 
some kind of packaging adjustment to build without workspace-dev to provide 
the subset of functionality that works with Plasma 5.

Kubuntu has already gotten rid of the package, so in many cases there will be 
hints in what they've done to follow.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdecoration2 mess - std::function makes the world fun

[Scott Kitterman]

On Thursday, August 20, 2015 10:50:39 PM Maximiliano Curia wrote:
> ¡Hola Lisandro!
> 
> El 2015-08-20 a las 14:25 -0300, Lisandro Damián Nicanor Pérez Meyer 
escribió:
> >> After having spent quite some time today looking at the current
> >> kdecoration2 mess (tracked at
> >> https://bugs.kde.org/show_bug.cgi?id=350964 ,  at debian:796194,
> >> debian:796184 and probably many more)
> >> 
> >> The crash happens around when a std::function (a c++11 feature) is passed
> >> across a library boundary and some parts of it is built with gcc5 and
> >> others with 4.9.
> > 
> > Matthias: is there any chance to make this simbol part of the new ABI? In
> > this way stuff will not migrate to testing as it happened for us.
> 
> std::function seems to be a header only thing, so there is no related symbol
> in libstdc++6.
> 
> >> According to Matthias Klose, upstream actually gives no guarantees for
> >> for
> >> their abi for c++11, so I guess the steps forward should be:
> >> 
> >> 1) Immediately binNMU src:kdecoration2 in testing, then when that is
> >> done,
> >> binNMU src:kwin, src:oxygen and src:breeze all in testing. (that's for
> >> release team)
> > 
> > I don't know if we can binNMU something in testing with a testing chroot.
> > I
> > think it needs a sourcefull upload to t-p-u. RT, please confirm.
> 
> The release team asked us to do this after having a newer version in
> unstable blocked by a transition. So we need to request the binNMU after
> 2).
> >> 2) At the same time, do a library transition for libkdecoration2-5 and
> >> rename it to libkdecoration2-5v5 and binNMU the rdeps (the same as
> >> mentioned above)
> > 
> > I can do this if the RT ACKs it (all B-Ds are ready).
> 
> I'm preparing this upload.

FYI, I've just accepted it into Unstable, so hopefully it'll be there shortly.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Removing Qt4 in Strech

[Scott Kitterman]

On April 16, 2015 7:21:44 PM EDT, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>On Thursday 16 April 2015 18:43:52 Scott Kitterman wrote:
>[snip]
>> If you look at what paultag started regarding python3 migration (see
>dda), I
>> think that's a good model for creating positive motivation to work on
>> porting thing.
>
>Right, although we don't have the porting team ;)
>
>**Maybe** we should consider just announcing that Qt4 enters
>just-security-
>bugs maintainance only and if someone wants to remove a dependency from
>Qt4's 
>B-Ds we will do it as long as it just affects plugins and not API/ABI
>(which 
>they shouldn't...)

He didn't have a porting team either until he called for volunteers today. 

Scott K


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Removing Qt4 in Strech

[Scott Kitterman]

On April 16, 2015 6:29:17 PM EDT, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>On Thursday 16 April 2015 22:37:52 Andreas Cord-Landwehr wrote:
>> On Thursday 16 April 2015 15:58:58 Scott Kitterman wrote:
>[snip] 
>> Hi, the porting progress of KDE Applications is currently working
>quite
>> nicely IMO. An overview on what currently is already ported is e.g.
>here:
>> 
>>   http://developer.kde.org/~cfeck/portingstatus.html
>> 
>> Yet some important applications (e.g. the whole of PIM, Okular,
>Calligra...)
>> have not seen any Qt5/KF5 based release yet. Trying to not make too
>bold
>> statements, my gut feeling is that the KDE Applications release after
>15.08
>> (probably around X-Mas) should provide ports for "most" of the
>> applications, making early 2016 sound a feasible date. If you add 4
>more
>> months for another Applications release cycle for safety, there
>should have
>> been two Qt5/KF5 based release cycles for most applications at spring
>2016.
>> 
>> Talking about the Workspace, it is already quite usable IMO (whereas
>I am
>> running master branches).
>
>Thanks you all for the feedback!
>
>Having KDE at that guesstimate of june/july 2016 is actually quite
>good, 
>although it would have been better sooner for other non-KDE stuff to
>follow. 
>Anyways good news :)
>
>Does any of you think of any way to gently push people to port their
>stuff to 
>Qt5 without calling it a "removal" at once? I do understand that we
>might not 
>be able to remove Qt4, but I *think* we should start pushing it
>somehow. I'm 
>open to other ideas :)

If you look at what paultag started regarding python3 migration (see dda), I 
think that's a good model for creating positive motivation to work on porting 
thing.

Scott K


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Removing Qt4 in Strech

[Scott Kitterman]

On April 16, 2015 6:29:17 PM EDT, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>On Thursday 16 April 2015 22:37:52 Andreas Cord-Landwehr wrote:
>> On Thursday 16 April 2015 15:58:58 Scott Kitterman wrote:
>[snip] 
>> Hi, the porting progress of KDE Applications is currently working
>quite
>> nicely IMO. An overview on what currently is already ported is e.g.
>here:
>> 
>>   http://developer.kde.org/~cfeck/portingstatus.html
>> 
>> Yet some important applications (e.g. the whole of PIM, Okular,
>Calligra...)
>> have not seen any Qt5/KF5 based release yet. Trying to not make too
>bold
>> statements, my gut feeling is that the KDE Applications release after
>15.08
>> (probably around X-Mas) should provide ports for "most" of the
>> applications, making early 2016 sound a feasible date. If you add 4
>more
>> months for another Applications release cycle for safety, there
>should have
>> been two Qt5/KF5 based release cycles for most applications at spring
>2016.
>> 
>> Talking about the Workspace, it is already quite usable IMO (whereas
>I am
>> running master branches).
>
>Thanks you all for the feedback!
>
>Having KDE at that guesstimate of june/july 2016 is actually quite
>good, 
>although it would have been better sooner for other non-KDE stuff to
>follow. 
>Anyways good news :)
>
>Does any of you think of any way to gently push people to port their
>stuff to 
>Qt5 without calling it a "removal" at once? I do understand that we
>might not 
>be able to remove Qt4, but I *think* we should start pushing it
>somehow. I'm 
>open to other ideas :)

If you look at what paultag started regarding python3 migration (see dda), I 
think that's a good model for creating positive motivation to work on porting 
thing.

Scott K


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Removing Qt4 in Strech

[Scott Kitterman]

On Thursday, April 16, 2015 03:59:58 PM Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Hi everyone! I have drafted a Qt4-removal announce in gobby, Teams→KDE→Qt4,
> right at the top.
> 
> As many of you might know there are different feelings about this removal.
> On one hand we will not be having anything else but security-related bugs
> fixed in Qt4 from the next point release which should happen really soon
> until possibly 2017 (which is possibly one year after Strech's release). On
> the other hand the number of apps using Qt4 is just enormous.
> 
> My suggestion to this is to simply try to get the removal done and see what
> happens during Strech's developing life cycle. Our experience with Qt3 was
> actually better that many think it was, having only 13 source packages using
> Qt3 when we asked for it's removal, and all of them where dead upstream
> (even if functional, like Twinkle).
> 
> As usual I would like you to review the aforementioned removal announce.
> Feel free to edit it, that's why we have Gobby there.
> 
> I would also like some input from the KDE maintainers, specially (but not
> limited to) maxy on how KDE's porting efforts are being developed (for
> example, do you think we will have a usable KDE with Qt5 experience by the
> end of the year?) I haven't tried it myself yet so any input in this regard
> will be highly appreciated.

Since Kubuntu is doing a largely Plasma5/Kf5/Qt5 release this month, I think 
we'll have a very good idea based on user feedback to Kubuntu about how usable 
the KDE/Qt5 experience is.  I haven't tried it either.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdeconnect naming

[Scott Kitterman]

OK.  I misread the email then.  I'd just call it what upstream is going to 
call it then if Debian is willing to do the same.  I agree it's inelegant, but 
users will rarely see it since this will get installed primarily via 
metapackage (I assume).

Scott K

On Monday, March 02, 2015 11:32:00 PM Jonathan Riddell wrote:
> Debian haven't made a decision as it hasn't been packaged yet.  The
> question for now is should we diverge from probable upstream naming.
> 
> Jonathan
> 
> On 2 March 2015 at 22:45, Scott Kitterman  wrote:
> > I don't see a reason to diverge from Debian here.
> > 
> > Scott K
> > 
> > On Monday, March 02, 2015 08:24:26 PM Jonathan Riddell wrote:
> > > I'm packaging the Plasma 5 version of kdeconnect, I'd like to ask for a
> > 
> > FFe
> > 
> > > and any testers very welcome
> > > https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1427349
> > > ppa:jr/ppa  install kdeconnect-plasma5
> > > 
> > > Upstream releases the kdelibs4 version as kdeconnect-kde and plans to
> > > release the plasma 5 version as kdeconnect-plasma5.  The naming is
> > > inelegant and debian have changed the source and binary to just
> > > kdeconnect.  What should I name the plasma 5 version?  It does overlap
> > 
> > and
> > 
> > > replace the kdelibs4 version in various ways but with be released with a
> > > different tar upstream.
> > > 
> > > Jonathan
> > 
> > --
> > kubuntu-devel mailing list
> > kubuntu-de...@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kdeconnect naming

[Scott Kitterman]

I don't see a reason to diverge from Debian here.

Scott K

On Monday, March 02, 2015 08:24:26 PM Jonathan Riddell wrote:
> I'm packaging the Plasma 5 version of kdeconnect, I'd like to ask for a FFe
> and any testers very welcome
> https://bugs.launchpad.net/ubuntu/+source/kdeconnect/+bug/1427349
> ppa:jr/ppa  install kdeconnect-plasma5
> 
> Upstream releases the kdelibs4 version as kdeconnect-kde and plans to
> release the plasma 5 version as kdeconnect-plasma5.  The naming is
> inelegant and debian have changed the source and binary to just
> kdeconnect.  What should I name the plasma 5 version?  It does overlap and
> replace the kdelibs4 version in various ways but with be released with a
> different tar upstream.
> 
> Jonathan


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Maintaining common Kubuntu/Debian packages in Debian

[Scott Kitterman]

As KDE is broken down into more and more smaller packages there are 
increasingly many of them that the only difference between Debian and Kubuntu 
is the  Vcs-foo and the maintainer.  

It would be nice if we could get to the point where it was easy to have 
packages with no real diff sync from Debian to Kubuntu.

Please see the attached lskat package diff (it's a diff from Debian's but other 
than the changelog entries, it's the same as Kubuntu's) as a prototype for how 
we might autogenerate correct Vcs-foo for both Debian and Kubuntu out of one 
source package. 

By design, it should give Debian Vcs-foo for any non-Ubuntu derivative and 
Ubuntu Vcs-foo for Kubuntu.  I think it's reasonably extensible if there are 
other Debian derivatives that care about this (it'd be a change in debian-qt-
kde.mk to do this for more derivatives, no additional per-package change).

If an approach like this makes sense, my thought is the rules changes would be 
integrated into debian-qt-kde.mk from pkg-kde-tools so that the only per 
package change needed would be to add control.in

Does this seem reasonable?  Keep in mind this is just a prototype.  It 
doesn't, for instance, proceed sanely in the absence of control.in.  With KF5 
packages landing rapidly for Kubuntu and starting to appear in Debian, I think 
it would be a good time.

Scott Kdiff -Nru lskat-4.13.1/debian/changelog lskat-4.13.2/debian/changelog
--- lskat-4.13.1/debian/changelog	2014-05-23 04:45:30.0 -0400
+++ lskat-4.13.2/debian/changelog	2014-07-08 10:34:24.0 -0400
@@ -1,3 +1,11 @@
+lskat (4:4.13.2-1) UNRELEASED; urgency=medium
+
+  * New upstream release.
+  * Add control.in and new rules to generate correct Vcs-* on Debian and
+Ubuntu
+
+ -- Scott Kitterman   Mon, 07 Jul 2014 22:58:37 -0400
+
 lskat (4:4.13.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru lskat-4.13.1/debian/control lskat-4.13.2/debian/control
--- lskat-4.13.1/debian/control	2014-05-23 04:45:30.0 -0400
+++ lskat-4.13.2/debian/control	2014-07-08 10:28:02.0 -0400
@@ -20,6 +20,8 @@
 Homepage: http://games.kde.org/
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-kde/kde-sc/lskat.git
 Vcs-Git: git://anonscm.debian.org/pkg-kde/kde-sc/lskat.git
+X-Ubuntu-Vcs-Browser: http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/lskat
+X-Ubuntu-Vcs-Bzr: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/lskat
 
 Package: lskat
 Architecture: any
diff -Nru lskat-4.13.1/debian/control.in lskat-4.13.2/debian/control.in
--- lskat-4.13.1/debian/control.in	1969-12-31 19:00:00.0 -0500
+++ lskat-4.13.2/debian/control.in	2014-07-08 10:04:46.0 -0400
@@ -0,0 +1,33 @@
+Source: lskat
+Section: games
+Priority: optional
+Maintainer: Debian Qt/KDE Maintainers 
+Uploaders: Daniel Schepler ,
+   Sune Vuorela ,
+   Fathi Boudra ,
+   Modestas Vainius ,
+   George Kiagiadakis ,
+   Eshat Cakar ,
+   Lisandro Damián Nicanor Pérez Meyer ,
+   Maximiliano Curia 
+Build-Depends: cmake,
+   debhelper (>= 9),
+   kde-sc-dev-latest (>= 4:4.11),
+   kdelibs5-dev (>= 4:4.11),
+   libkdegames-dev (>= 4:4.11),
+   pkg-kde-tools (>= 0.14)
+Standards-Version: 3.9.5
+Homepage: http://games.kde.org/
+@BROWSER@
+@VCS@
+@OTHERBROWSER@
+@OTHERVCS@
+
+Package: lskat
+Architecture: any
+Depends: kdegames-card-data (>= 4:4.10), ${misc:Depends}, ${shlibs:Depends}
+Recommends: khelpcenter4
+Description: Lieutnant Skat card game
+ Lieutnant Skat is a simplified variant of the Skat card game for two players.
+ .
+ This package is part of the KDE games module.
diff -Nru lskat-4.13.1/debian/rules lskat-4.13.2/debian/rules
--- lskat-4.13.1/debian/rules	2014-05-23 04:45:30.0 -0400
+++ lskat-4.13.2/debian/rules	2014-07-08 10:32:53.0 -0400
@@ -2,6 +2,22 @@
 
 include /usr/share/pkg-kde-tools/qt-kde-team/2/debian-qt-kde.mk
 
+changelog_values := $(shell dpkg-parsechangelog \
+| awk '/^(Version|Source):/ {print $$2}')
+PKGSOURCE  := $(word 1, $(changelog_values))
+PKGVERSION := $(word 2, $(changelog_values))
+
+DEBIAN_WEB_HOST := \:\/\/anonscm\.debian\.org\/gitweb\/\?p\=pkg-kde\/kde\-sc\/
+DEBIAN_VCS_HOST := \:\/\/anonscm\.debian\.org\/pkg-kde\/kde-sc\/
+DEBIAN_VCS := Git
+DEBIAN_VCS_PROTOCOL := git
+UBUNTU_WEB_HOST := \:\/\/bazaar\.launchpad\.net\/\~kubuntu\-packagers\/kubuntu\-packaging\/
+UBUNTU_VCS_HOST := \:\/\/code\.launchpad\.net\/\~kubuntu\-packagers\/kubuntu\-packaging\/
+UBUNTU_VCS := Bzr
+UBUNTU_VCS_PROTOCOL = https
+
+distribution := $(shell dpkg-vendor --query Vendor)
+
 .PHONY: override_dh_auto_test
 
 override_dh_auto_configure:
@@ -10,6 +26,31 @@
 override_dh_auto_install:
 	$(overridden_command) --destdir=debian/tmp
 
+override_dh_auto_clean:
+ifeq ($(distribution),Ubuntu)
+	sed -e "s/^@BROWSER@/Vcs-Br

Re: Qt5 switching qreal from float to double on arm*

[Scott Kitterman]

"Lisandro Damián Nicanor Pérez Meyer"  wrote:
>Note: only for pkg-kde-talk.
>
>On Saturday 02 November 2013 15:29:05 Lisandro Damián Nicanor Pérez
>Meyer 
>wrote:
>> Hi! Starting from Qt 5.2.0 (most probably from rc1 and definitely not
>from
>> beta1 currently in experimental) Qt5 will switch qreal from float to
>double
>> on arm*.
>> 
>> We have the option to keep some archs in float by passing a
>compilation
>> parameter. I've done so for armel and sh4, so only armhf will switch
>to
>> double.
>> 
>> Of course we are still on time to discuss this, and this is the
>reason of
>> this mail. What do you think WRT the above changes?
>> 
>> On the other hand, if the above change is kept, symbols for Qt5 on
>armhf
>> managed with pkg-kde-tools' symbolshelper will need an explicit
>double for
>> armhf instead of using qreal's subst. This is because on Qt4 qreal
>will be
>> kept as float.
>
>There's still the chance of doing **quite a bit** of work and
>backporting the 
>changes to Qt4 and make qreal a double on armhf too. But this means a
>**big** 
>transition for armhf would be needed, but on the other hand
>pkg-kde-tools' 
>symbolshelper could be changed to properly manage Qt4 and Qt5.
>
>I want to be clear: this last option could mean *lots* of work and I
>would 
>definitely *not* go ahead with it without a patch to Qt4 ACKed by
>upstream and 
>the rest of Qt/KDE-team.
>
>But I think at least should be considered and team approved/discarded.
>
>Kinds regards, Lisandro.

Doesn't this break binary compatibility? Did you discuss this with upstream 
already? 

Scott K


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: kstarsmerge

[Scott Kitterman]

The no GL on arm* changes aren't relevant to Debian.

Scott K

Jonathan Riddell  wrote:

>   - don't install GL on armhf
>libglu1-mesa-dev [!armhf], libnova-dev, libqt4-opengl-dev [!armhf]
>
>
>Jonathan


-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: cmake merge

[Scott Kitterman]

Jonathan Riddell  wrote:

>   * Merge with Debian, remaining changes:
>- Add ubuntu_qt_import_dir_variable.diff
>define QT_IMPORTS_DIR even when that dir does not exist.
>- Add multiarch-python-include-dirs.patch
>  * Fix FindPythonLibs to specify both include paths to Python.h &
>  pyconfig.h in PYTHON_INCLUDE_DIRS. Packages should not use deprecated
>PYTHON_INCLUDE_PATH, nor only PYTHON_INCLUDE_DIR (which will only
>point to Python.h location).
>
>http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/cmake/saucy/files/head:/debian/patches/
>
>Jonathan

Debian won't need the multi-arch change until after the Python changes in 
experimental hit unstable. 

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Question about low-fat-settings

[Scott Kitterman]

"l...@telefonica.net"  wrote:

>Hi,
>
>sorry to bother you again... I'm just looking for some information that
>maybe you are able to give me. 
>I need to know what certain (sections?) of ubuntu-low-fat-settings do
>very precisely, and I cannot find a way to get in touch with the
>developers or some document that explain it. The sections are the
>following: 
>
>- kde/share/config/krunnerrc
>- kde/share/config/ksmserverrc
>- kde/share/config/kwinrc
>- kde/share/config/nepomukserverrc
>
>The problem is that I can guess some things that they do, but not
>everything, and, as I said before, I need to know all the possible
>functionalities.
>
>Thank you,
>
>Elisabeth R.

You want kubuntu-de...@lists.ubuntu.com.  You'll need to subscribe before 
posting. 

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: Qt Multiarch Transition

[Scott Kitterman]

On Sunday, October 02, 2011 01:09:59 AM Praveen A wrote:
...
> Thanks! I found a solution in ubuntu package. It has a ...

For Debian people working on the Qt Multiarch transition, the Ubunt package is 
definitely a good place to look, since Ubuntu has already done this 
transistion.  I don't personally vouch for the quality of everything since I 
didn't review it all, but it's worth a look.

Scott K

-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

polkit-kde-1 merge feedback from Kubuntu

[Scott Kitterman]

I've reviewed the Kubuntu diff with Debian for polkit-kde-1 and it consists of 
a single patch that looks like it would be useful in Debian as well 
(attached).  The purpose (from debian/changelog) is:

  * Add kubuntu_01_fix_dialog_focus.diff to prevent the auth dialog from
popping up in the background where it can't be seen

This has also been committed upstream, so it will be included in the next 
polikit-kde-1 release.

Scott K
Index: polkit-kde-agent-1-0.99.0/policykitlistener.cpp
===
--- polkit-kde-agent-1-0.99.0.orig/policykitlistener.cpp	2011-01-19 10:24:09.413897000 -0500
+++ polkit-kde-agent-1-0.99.0/policykitlistener.cpp	2011-01-19 10:24:36.577897000 -0500
@@ -22,6 +22,7 @@
 #include "AuthDialog.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -100,6 +101,7 @@
 kDebug() << "WinId of the dialog is " << m_dialog.data()->winId() << m_dialog.data()->effectiveWinId();
 m_dialog.data()->setOptions();
 m_dialog.data()->show();
+KWindowSystem::forceActiveWindow(m_dialog.data()->winId());
 kDebug() << "WinId of the shown dialog is " << m_dialog.data()->winId() << m_dialog.data()->effectiveWinId();
 
 m_numTries = 0;
-- 
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk

Re: towards KDE 4.5? (mail to -release, filling the needed info)

[Scott Kitterman]

On Wednesday, August 04, 2010 05:31:22 am Tom Albers wrote:
> On Wed, 4 Aug 2010 12:25:05 +0300, Modestas Vainius 
> 
> wrote:
> >> Finally, it is kdepim. The "official" planning currently says they will
> >> skip 4.5.0 and release with 4.5.1 and well, the changes will be big.
> >> Should we keep 4.4.x anyway?
> > 
> > My vote goes to kdepim 4.4.x stack. kdepim-akonadi will be too fresh and
> > 
> > untested for stable Debian release.
> 
> +1.
> Nowhere near ready for debian stable.

Kubuntu is staying with kdepim 4.4.x for it's next release.  I understand 
Fedora is likely to do this as well.  I think there's roughly a zero percent 
chance of it being ready for a Debian stable release.

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: /usr/share/doc/kde4 (Debian) vs. /usr/share/doc/kde (Kubuntu)

[Scott Kitterman]

"Sune Vuorela"  wrote:

>On Sunday 23 May 2010 14:07:28 Modestas Vainius wrote:
> 
>> So obviously this difference does not make kubuntu people very happy
>> because extra work is needed for merging packages from Debian. As far as I
>> understand, they want Debian to switch.
>
>I thought they just asked to do s/kde4/kde\*/ in the install files, making the 
>install files working on both debian and ubuntu.
>

That's correct. 

I think kde is more logical than kde4, so I think it would be a good change to 
make and would be willing to help with the change in Debian if you decide to go 
to kde,  but I think it's entirely up to you to decide if you want to do it.

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Fwd: Re: Naming scheme for KDE Configuration Modules

[Scott Kitterman]

FYI,

I forwarded the naming scheme message to the Kubuntu Developers list for 
comment (since Kubuntu will follow Debian's lead on this).  I'll forward any 
other replies I get too.

Scott K


--  Forwarded Message  --

Subject: Re: Naming scheme for KDE Configuration Modules
Date: Tuesday 02 February 2010
From: Celeste Lyn Paul 
To: Kubuntu Developer Discussion 

Option D kde-config-*. KCM is a description of the technical
implementation and not a description of the purpose of system
settings. If a new module framework was developed, the concept of kcm
could become obsolete. D would also work well with standalone modules
outside the shell.

On Tue, Feb 2, 2010 at 11:34 AM, Scott Kitterman  wrote:
> FYI. We should plan on following Debian in this,  so now is the time to 
weigh in.
>
> Scott K
>
>  Original Message 
> Subject: Naming scheme for KDE Configuration Modules
> From: "Didier 'OdyX' Raboud" 
> To: pkg-kde-talk@lists.alioth.debian.org
> CC:
>
> Hi all,
>
> as was discussed this afernoon (GMT+1) on IRC, we have no clear consensus on
> binary package names for KDE Configuration Modules, mainly because we don't
> have many packages of that sort yet. The question arises because there is an
> ITP on kcm-touchpad (#568040).
>
> I think that such a consensus is a good thing, even if not absolutely
> necessary.
>
>   What we have now 
>
>system-config-gtk-kde   (src: gtk-qt-engine)
>system-config-printer-kde   (src: kdeadmin)
>
> The "KDE System Configuration" binary is in the
>
>systemsettings  (src: kdebase-workspace)
>
> And I think that's mostly it.
>
>   Options 
>
> We have discussed those four options (there are certainly more):
>
>a) system-config-*-kde
>b) kcm-*
>c) kde-control-module-*
>d) kde-config-*
>
>   Pros and cons 
>
> a)  system-config-*-kde
>+ Is already in the archive, down to Squeeze
>+ Is pretty explicit
>- was mostly pushed by myself, with no real consensus
>- pollutes the system-config-* namespace, originally used for
>  RedHat utilities, which have then been ported to KDE (thus the
>  -printer-kde)
>
> b)  kcm-*
>+ Short
>+ Already in use by other distros (OpenSuse, Ubuntu, …)
>- Not really explicit
>
> c)  kde-control-module-*
>+ Explicit
>- Might become really long
>
> d)  kde-config-*
>+ Explicit, even if slightly less than the latter
>
>   My opinion (if that matters…) ===
>
> I am now in favor of changing our actual packages to d) (kde-config-*), but
> I am of course open to discussion. And for what matters, I really find b)
> (kcm-*) ugly.
>
> I also note that this could lead to a renaming of systemsettings to the "no-
> wildcard" version of the naming scheme we could now choose.
>
>  = Conclusion ===
>
> So what is your opinion ?
>
> Best regards and thanks for reading so far.
>
> OdyX
>
>
>
>
> --
> http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk
> --
> kubuntu-devel mailing list
> kubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
>



-- 
Celeste Lyn Paul
KDE Usability Project
KDE e.V. Board of Directors
www.kde.org

-- 
kubuntu-devel mailing list
kubuntu-de...@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel


---
-- 
What have you done to help win the war TODAY?

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Packaging of new plasma-foo work spaces

[Scott Kitterman]

> Hello,
>
> On trečiadienis 25 Lapkritis 2009 18:25:28 Scott Kitterman wrote:
>> Our thought is to not split Plasma Desktop out into a separate binary,
>> but
>> leave it in kdebase-workspace as something that should always be
>> installed
>> (somewhat as a fallback) even if it's not started by default on some
>>  devices.
>
> Why?

When we were discussing it, it felt safer.  Considering it further, my
opinion has evolved.  Particularly given the rebranding move by KDE so
that "Plasma Desktop" is a clearly separate entity that users might want
to install and your point below about not entirely reducing code
installed, I think it should be a separate binary.  More beloew.

>>  Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be
>>  in separate binaries so they would only be installed on devices
>>  appropriate for the specialized plasma.  The files built from:
>>
>> http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/
>>
>> would all go in a plasma-netbook package built from the
>> kdebase-workspace
>> source.
>
> plasma-netbook package makes sense.
>
>>
>> This approach seems reasonably scalable and future proof and also
>> minimizes
>> the amount of code installed on most systems.
>
> It might be scalable, but it does not minimize amount of code installed.
> plasma-desktop is still uselessly installed where otherwise it is not
> needed.

Agreed (see above).  It's less code than not breaking anything out (all
plasmas installed in all systems), but it's certainly not minimal.

> Anyway, more justification on technical grounds please.

In our KDE 4.3 release, we built an experimental plamsa-netbook package
from playground with these contents:

http://packages.ubuntu.com/karmic/i386/plasma-netbook/filelist

Similarly, we'd build plamsa-netbook for KDE 4.4 with:

http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/

I'm also suggesting a similar plasma-desktop package that would split out
from kdebase-workspace-bin.

Based on my short IRC conversation with pusling, I checked with upstream
and there is a KCM that allows users to select which plasma to run if
multiple plasmas are installed.  It is not active if only one is
installed.

Here is the summary of what notmart had to say about it:

> There is a kcontrol module that lets you chose the shells that starts. It
> automatically gets disabled if either plasma-desktop or plasma-netbook
> executables aren't present.  It uses KAutostart that basically puts
> desktop files in ~/.config/autostart.

> In the netbook version you could not install the desktop parts (they are
> quite separated in the source dir so it should be easy to package them
> separately).  Then, in the netbook package, or better as a separate
> package you can put an autostart desktop file that installs globally.  If
> the user then installs plasma-desktop and chooses it the autostart of
> plasma-netbook gets disabled on a per-user basis.  We are still wondering
> how to avoid autostarting of both if the global autorun desktop file is
> installed for plasma-netbook, perhaps installing it it could delete the
> one of plasma-desktop and viceversa?

It sounds to me like the upstream concept supports the idea of only
installing one plasma and letting the user install an alternative one if
they prefer (we have had requests for this with our Kubuntu Netbook tech
preview).

I was thinking that perhaps we could use the alternatives system to
control which plasma is autostarted on first run, but I need to review
policy on alternatives to know if it's appropriate.

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Packaging of new plasma-foo work spaces

[Scott Kitterman]

If you look at kdebase-workspace/plasma in KDE trunk, it's somewhat different 
than in past releases:

http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/

We now have both Plasma Desktop and Plasma Netbook with at least Plasma Mobile 
and probably others coming in the future.

We discussed this among the Kubuntu developers and have some consensus around 
a packaging approach for this, but want to coordinate this with Debian first 
and make sure both distros use a common approach.

Also, slightly related, is the KDE rebranding effort:

http://dot.kde.org/2009/11/24/repositioning-kde-brand

This makes first class brands out of Plasma Desktop and Plasma Netbook.

Our thought is to not split Plasma Desktop out into a separate binary, but 
leave it in kdebase-workspace as something that should always be installed 
(somewhat as a fallback) even if it's not started by default on some devices.  
Then additional plasmas (Plasma Netbook for KDE SC 4.4) would be in separate 
binaries so they would only be installed on devices appropriate for the 
specialized plasma.  The files built from:

http://websvn.kde.org/trunk/KDE/kdebase/workspace/plasma/netbook/

would all go in a plasma-netbook package built from the kdebase-workspace 
source.

This approach seems reasonably scalable and future proof and also minimizes 
the amount of code installed on most systems.

Comments?

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: metapackage for lokalize

[Scott Kitterman]

On Sunday 12 July 2009 19:46:35 Sune Vuorela wrote:
> On Thursday 09 July 2009 08:21:17 Nick Shaforostoff wrote:
> > > And your first commit looks good.
>
> One thing though, please add a changelog entry. I currently added a dummy
> entry for you ;)
>
> > should I somehow communicate my changes to ubuntu?
> > or they are on their own?
>
> I think they sync from time to time from us.

We (Kubuntu) do merge our packages with the Debian updates and make an effort 
to feed back useful changes to Debian once per 6 month release cycle.  Sune 
did point these changes out to me on IRC and so I'll pull them from the Debian 
svn.  Thanks for thinking of us.  You are welcome to visit (#kubuntu-devel) on 
freenode anytime you wish to chat with us about anything Kubuntu specific.

Thanks.

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: meta-kde4 and meta-kde

[Scott Kitterman]

On Wed, 8 Apr 2009 23:49:07 +0200 Sune Vuorela  wrote:
>On Wednesday 08 April 2009 20:31:04 Rainer Kluge wrote:
>> Ana Guerrero schrieb:
>> > - kde-minimal (just rename current kde4-mininal) I am not sure kde-core
>> > longer fits.
>> > - kde-full (renamed from current kde4) I agree it is clearer than kde.
>>
>> The real question is about the need of the kde/kde4/kde-full package with
>> all this game stuff and dependencies to almost all debian packages. Why 
not
>> suppress it and rename kde4-minimal to kde?
>
>Exactly because of this debate.
>
>What should be KDE?
>
>The thing that upstream ships as KDE?
>The thing that Developer A and Developer B has agreed upon?
>The thing that Developer C and Developer D has agreed upon?
>Whan when users wants more?
>
>If I was to define what should be installed, I would add:
>
>kdebase-workspace (for the desktop
>kdebase (for dolphin, konqueror and such)
>kdepim (or at least most of it: kontact, kmail, korga, kaddressbook, 
akregator 
>and kjots)
>kdeplasma-addons
>A few games (maybe kpat and kmines or so)
>parts of kdenetwork (at least kopete)
>parts of kdemultimedia (at least juk as media player and kmix and 
something 
>for playing cd's)
>At least ark, maybe other parts of kdeutils
>kdegraphics
>Maybe a bit more.
>
>But I know other people would disagree.
>And shipping what we currently ship as kde-minimal would I very much like 
to 
>not ship as "KDE", as it brings not the full kde experience.
>

I think moving things (like games) that it's nice to provide to recommends, 
so they can be removed without removing the metapackage, will defuse a lot 
of the tension of these discussions.  If it turns out a few too many things 
get added to recommends for some people's tastes, they can just remove them.

Scott K

--
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)

[Scott Kitterman]

On Wed, 4 Feb 2009 08:05:10 +0100 Sune Vuorela  wrote:
>On Tuesday 03 February 2009 23:15:55 Scott Kitterman wrote:
>
>> In Kubuntu we just migrated people in .kde without the backup tool and I
>> would describe it as mostly OK.
>pppo

I have two systems here that were upgraded from 3.5.10 to 4.1.2 (and later 
4.1.3/4) without issue, so I have seen no problems with upgrading myself.

I have helped users with problems where moving .kde away and recreating it 
helped (I don't recall specifics).  Of course this also happens with KDE3 
and not-upgraded-from-KDE3-KDE4 systems too, so I don't actually know that 
it's KDE3 to KDE4 problems that are being resolved.  I recently also saw 
that work with a Gnome system that had KDE4 installed onto it.

Sorry I don't have more specifics.

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: [DRAFT for discussion] KDE 4.2 upload to unstable

[Scott Kitterman]

On Wed, 4 Feb 2009 02:38:28 +0100 Ana Guerrero  wrote:
>- Reintroduce kde 3 apps standalone that we think it is work it (at least 
pino
>  wanted to package kregexpeditor). The less here, the better.
>
I repackaged kdvi for Kubuntu because of (I think it was) inverse search 
funtions that a class of users found important and weren't available with 
the KDE4 tools in 4.1.  Perhaps that has changed, but it's one to consider.

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Uploads to Squeeze and the $KDEHOME dilemma (was: Uploads to lenny and the $KDEHOME dilemma)

[Scott Kitterman]

On Tue, 3 Feb 2009 22:56:27 +0100 Armin Berres  wrote:
>I meant Squeeze and not Lenny for sure.
>
>On Tuesday 03 February 2009 22:53:42 Armin Berres wrote:
>> Hi all!
>>
>> As you all know Lenny is near, which also means that our 4.2 packages 
will
>> enter Unstable in the very near future. Until today, we still have not
>> decided how to handle KDEHOME.
>> The current situation is, that KDE 3 applications use ~/.kde and KDE 4
>> applications use ~/.kde4. The problem with this approach is, that no
>> data/settings are automatically converted to be used by KDE 4.
>>
>> The question is now: should we
>> a) continue to use ~/.kde4 for KDE 4 applications
>> b) use ~/.kde for KDE 4 applications.
>>
>> The problem with a) is, that as mentioned no data is is moved to KDE 4. 
The
>> problem with b) is, that we don't know for sure, if all upgrade scripts
>> work and users don't loose critical data. Apart from that users already
>> using KDE 4 won't find their settings copied.
>> (Add here more pros and cons for either option.)
>>
>> To overcome this, we had the following idea in IRC: Provide a little Qt
>> application which starts at the first KDE 4 start and allows the users to
>> copy their KDEHOMEs around.
>> In case we would use ~/.kde for KDE 4 the script could offer to create a
>> backup in ~/.kde3 so lost data can be reverted if anything goes wrong.
>> If we continue to use ~/.kde4 the application could offer to copy ~/.kde 
to
>> ~/.kde4.
>> Non-KDE users are a bit lost here, we could document what to copy where.
>>
>> So, which options do you see? What would you prefer?
>> Don't forget that we have to decide/code all this before we upload 
kde4libs
>> to unstable.
>>

In the long run KDE is KDE4. I'd recommend KDE4 in .kde and a backup in 
.kde3.  Do it the other way and eventually it'll be .kde4, no .kde, and 
people finding it odd.

In Kubuntu we just migrated people in .kde without the backup tool and I 
would describe it as mostly OK.

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Need to download KDE 4.1 iso

[Scott Kitterman]

On Sat, 24 Jan 2009 12:07:55 +0100 Sune Vuorela  wrote:
>Please take this off this list.
>
Will do (I hadn't got this far in my inbox when I wrote the last one, 
sorry).

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Need to download KDE 4.1 iso

[Scott Kitterman]

On Sat, 24 Jan 2009 09:56:48 + Beojan Stanislaus  
wrote:
>On Friday 23 January 2009 22:15:50 Scott Kitterman wrote:
>> On Thu, 22 Jan 2009 20:10:00 + Beojan Stanislaus 
>>
>> wrote:
>> >Kubuntu, the KDE version of Ubuntu, offers KDE4.1 for Intrepid Ibex, but
>>
>> provides a relatively poor implementation.
>>
>> Relative to what?
>>
>> Scott K
>Compared to the standard, full KDE that you get if you install the debian 
>packages, Kubuntu 
remove many packages usually distributed as part of KDE, in order to fit the 
entire system onto 
a single CD.
>

All the rest of which can be installed online from the repository.  I think 
your initial 
message is a pretty harsh way to say "only makes one CD and so you have to 
download stuff that didn't fit".

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: Need to download KDE 4.1 iso

[Scott Kitterman]

On Thu, 22 Jan 2009 20:10:00 + Beojan Stanislaus  
wrote:
>Kubuntu, the KDE version of Ubuntu, offers KDE4.1 for Intrepid Ibex, but 
provides a relatively poor implementation. 

Relative to what?

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk

Re: KDE version in Lenny: KDE 3.5.9 vs KDE 4.1

[Scott Kitterman]

On Thursday 05 June 2008 16:03, Ana Guerrero wrote:
> Hi folks,
>
> We have been delaying taking a decision about this for too much time now,
> the freeze is coming up [0], and we need to have it clear, for our users,
> the release team and the rest of Debian.
>
> Basically we can ship either KDE 3.5.9 or KDE 4.1. For some people in the
> team it seems clear we should ship KDE 4.1, for some other it is clear we
> should ship KDE 3.5.9. The latter is my opinion, so here you have a mail
> explaining why we should release with 3.5.9. Feel free to reply with a nice
> mail of why we should ship with KDE 4.1, detailing as well how much time
> *you* are planning to invest in this goal.
> By the way, my proposal is shipping KDE 3.5.9 with the KDE 4.1 development
> platform: kde4libs, kdepimlibs and kdebase-runtime.

Kubuntu is committed to ship KDE 4.1 in it's October release.  If it doesn't 
work out so well, you might see me migrate to a Lenny that had 3.5.9.  

>From my perpsective as a Kubuntu developer trying to get 4.1 working (and the 
needed KDE3 bits) in the Kubuntu Intrepid repository, KDE 4.1 seems to me to 
be pretty scary for a release that will be THE Debian KDE release for at 
least a year and will have to be supported for at least two years.

I fully expect that Kubuntu Intrepid with KDE 4.1 will end up being labled 
as "For Intrepid adventurers" (e.g if you want to get serious work done, wait 
for the next release).  Debian is, by design, more conservative than the 
various Ubuntu parts and I think that's good.  

The one caution I will give you is around displayconfig (in kde-guidance).  
I'm still working on refactoring the current Kubuntu package to make it 
suitable for Debian.  It would be a major improvement from what you have now, 
but expect it to be fundamentally broken for dual screen configurations.  KDE 
really needs a good Xrandr display tool.  The only one I know of ships with 
KDE4.

Good luck making the decision, it doesn't look like an easy one.

Scott K

-- 
http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk