gmane.linux.ubuntu.devel.kubuntu

Re: SRU xsettings-kde

Jonathan Thomas — 2012-05-25T16:24:30

Steve Langasek already took care of this. Verification is done and the
SRU is pending a copy to -updates shortly. :)

On Fri, May 25, 2012 at 11:46 AM, Michal Zajac <quintasan< at >kubuntu.org> wrote:

Re: SRU xsettings-kde

Michal Zajac — 2012-05-25T15:46:22

Assign me to it please, will get to it tomorrow.
24 maj 2012 22:44, "Harald Sitter" <apachelogger< at >ubuntu.com> napisał(a):

Re: Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas — 2012-05-25T13:09:59

Hello,

On Fri, May 25, 2012 at 5:12 AM, Martin Pitt <martin.pitt< at >ubuntu.com> wrote:

I think that we'd rather not use PackageKit (for Kubuntu at least). We
already have python-apt and QApt as part of the default Kubuntu
install, so having a third apt worker implementation would be
undesirable. Could the new jockey communicate with a "what
provides-helper" written with libqapt that uses DBus for
communication, and use the qaptworker for running installs if I were
to implement such a helper?


This could work, although it would (obviously) require some additional
GUI work on the KDE side of things. Though if we're already going to
have to write additional GUI...

... then I think it would be beneficial to write a KConfig Module so
that it could be integrated as a sub-page of the "Display and Monitor"
page in KDE's System Settings. I attempted to write a Jockey frontend
for this a few years back, but was foiled due to the multithreading in
jockey not playing nice with the KDE plugin apis.


This is undesirable, but could be a fallback as a worst-case scenario.


This could also be another fallback mode, if we get
ubuntu-drivers-common working with QApt as a backend, but don't get
the GUI done in time, etc.


Anyways, those are my opinions.

Overview of Jockey replacement; options for Kubuntu?

Martin Pitt — 2012-05-25T09:12:05

Hello all,

Also sending this to kubuntu-devel< at >, but as I'm not a subscriber
someone needs to moderate; CC'ing Scott and Harald directly.

As discussed at UDS and in [1] we want to dramatically simplify the
machinery for installing extra drivers (NVidia, bcmwl, and friends).
Jockey was originally designed to do a lot more than we are using it
for, and be compatible with other distros as well (I had it working on
Fedora 14 back then, when we discussed it in the Linux Foundation
driver backports workgroup). But we don't use it to that extent, other
distros have moved into a different direction, and thus it has way too
much code and bugs. So Ubuntu will drop it and replace with with
something much simpler and robust, and also use upstream friendly APIs
(PackageKit).

The logic of detecting drivers and providing PackageKit/aptdaemon
plugins is now in the ubuntu-drivers-common package (formerly known
as "nvidia-common"). This now mostly makes PackageKit/aptdaemon able
to answer a "WhatProvides(MODALIAS, pci:s0000DEADv0000BEEF...)" query
to map a piece of hardware to a driver package. It also contains a
command line tool "ubuntu-drivers" with a few commands (list,
autoinstall, and debug at the moment) which replaces jockey's usage in
the installer (which called jockey-text --no-dbus ...).

The user interface will be made a lot simpler and less confusing, and
move into software-properties-gtk (or perhaps software-center at some
point).

The question arises what to do with Kubuntu. We have a few obvious
options:

* Kubuntu uses software-properties-kde, so as long as we keep
software-properties, the new design could be implemented there as
well, and jockey-kde be dropped.

* Kubuntu implements a similar (or their own) design using the
ubuntu-drivers-common API in the KDE control center as an embedded
tab. Then we can also drop jockey-kde.

* Kubuntu keeps jockey-kde, and takes over the Jockey maintenance.
ubuntu-drivers-common does not break Jockey, but it would still
need some maintenance to adapt to newer nvidia driver versions,
changing Qt/KDE APIs, and the like.

* Kubuntu keeps the jockey-kde UI, but drops the backend
(jockey-common) and changes the UI to work with the
ubuntu-drivers-common API.

In either case, automatic driver installation by Ubiquity will Just
Work (e. g. for the Broadcom wifi cards) but there should still be an
UI for enabling or changing drivers (like NVidia, which is not
auto-installed) manually.

Opinions?

Thanks,

Martin

[1] https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation

[Blueprint topic-quantal-flavor-kubuntu] Kubuntu Quantal PLans

Kate Stewart — 2012-05-24T22:49:39

Blueprint changed by Kate Stewart:

    Approver: Kate Stewart => Kubuntu Council

SRU xsettings-kde

Harald Sitter — 2012-05-24T20:43:57

Someone please make
https://bugs.launchpad.net/ubuntu/+source/xsettings-kde/+bug/1002811
so that it meets with ludicrous requirements. I will not. Kthxbai.

Re: Kubuntu and main/universe

Scott Kitterman — 2012-05-23T13:11:21

wrote:

We could split the seeds into a Main/on the $ISO and a Universe/on the $ISO 
seeds.  That would complicate the decision making about what needs to go in 
Main considerably if our images are built to include Universe.  Technically 
it's feasible, but I don't think there's another case of an set of packages 
split this way.  Edubuntu has a bunch of stuff in Main, but that's only because 
of overlap between it's packages and Gnome/KDE.

Scott K

Re: Kubuntu and main/universe

Harald Sitter — 2012-05-23T13:06:03

Does it have to be either or? Couldn't we mixed seed?
i.e. have most of our stuff in main, and when necessary demote/keep
packages in universe to accommodate the build dep issue highlighted

FWIW, having to compromise on available features because a build dep
was not worth getting it into main (or simply does not qualify for
legal reasons) always annoyed me.

HS

Re: Kubuntu and main/universe

Scott Kitterman — 2012-05-23T12:57:48

...
...

This is a good point that I forgot to write.  My preference to stay in Main is 
not strong as I see the benefits of moving, but I would still prefer to stay in 
Main if we can.

Scott K

Re: Kubuntu and main/universe

Scott Kitterman — 2012-05-23T12:55:23

Which, depending on what 'supported' means is accurate (see below).


This is the biggest plus associated with moving to Universe, IMO.  The 
infrastructure is fragile enough that I don't think it's particularly more 
work to unwind it than keep it.  Since upstream KDE already ships per language 
translations the primary advantage with the LP language system isn't 
applicable to KDE.


I suspect we've hit those already, so it's not a major driver.

The benefits to staying in Main, as I see it:

 - Canonical security team support (if they aren't willing to support, then I 
think we're pretty much by definition out of Main)

 - Some PR advantage

 - Limited set of non-Kubuntuish uploaders.  There are some people with MOTU 
upload rights that I wouldn't want going anywhere near Kubuntu packages and so 
I see it as a positive feature that they can't.  The kubuntu-dev process is 
responsive enough that it's easier for someone working on Kubuntu to get that 
then MOTU, so in terms of Kubuntu related upload rights, there's no particular 
advantage moving to Universe.

 - Build priorities: Thanks to Colin's recent efforts our seeded packages would 
still build after unseeded Universe packages, but would build after everything 
in Main/Restrictred is done.  At busy times (and when we're trying to get a 
new KDE SC release uploaded, built, and announced) this is going to have a 
significant impact on how long it takes to get stuff done.

Other than security support (and I would assume the availability of commercial 
support contracts, but I don't actually know about that) there isn't a lot of 
post-release support for Kubuntu specific to it being a supported flavors.  
We're doing post-release microversion KDE SC updates, for example, and those 
are all done by the Kubuntu community.

There are some things we could do in Universe that we can't in Main and we 
avoid the work of the MIR process, but if things are not going to get through 
the MIR process, it's probably just as well we don't ship them by default.  I 
think the process has enough value that it's not just work avoided if we don't 
have to do it, we lose a significant QA point as well.

I have assumed we're going to have to move to Universe, but have a preference 
not to if we have a choice in the matter.

Scott K

Re: Kubuntu and main/universe

Jonathan Thomas — 2012-05-23T12:44:37

Hi Colin,

I regret being unable to attend UDS in person, but I hope you had a
good time and aren't suffering from the Ubuflu. :)

On Wed, May 23, 2012 at 7:49 AM, Colin Watson <cjwatson< at >ubuntu.com> wrote:

I think moving from main would be beneficial to us. Currently, there
are several Kubuntu packages with optional build-dependencies on
universe components providing extra functionality that we cannot build
against. In addition to us missing out on a few nice features, it also
makes packaging diffs with Debian just a bit larger, which is
undesirable. In my experience, I don't think there's any protest
amongst the Kubuntu team about whether or not a move from main ->
universe is desirable, but I'll let them speak for themselves. ;-)


Currently all Muon is doing is running a script based on
update-manager's MetaReleaseCore class to check for distribution
updates, and offering to launch the Qt distribution upgrade frontend
to update-manager if a new release is available. This would mean that
all the Kubuntu packages would show up as "no longer supported by
Canonical." I hadn't thought of this point, but it definitely would
need to be addressed.


The work required wouldn't be exactly non-trivial, but I don't think
it would be too onerous either. After the removal of the packaging
magic that we use to strip the stuff from Kubuntu packages properly,
all that would need to be done would be to rebuild all of the affected
packages. We already upload per-language language packs that KDE
provides. These end up getting stripped down to only providing the
translated documentation KDE distributes, but if these were no longer
stripped, we'd only have to rebuild these, too. This would provide KDE
language packs much like the ones Ubuntu is shipping. (At least in
terms of coverage) We would still probably have to at least keep some
of the language-selector stack around for getting things like
translations for firefox and other non KDE apps that users may
install.


Probably most of the damage was done by Canonical's announcement of
dropping support. We would of course frame this as giving us more
flexibility, but I think it would be better if we didn't make a big
deal about this. (imo)


Thanks again for the update!

Cheers,
Jonathan

Kubuntu and main/universe

Colin Watson — 2012-05-23T11:49:54

Hi Kubuntu folks,

At this UDS, the old "archive reorg" topic came up again
(https://wiki.ubuntu.com/ArchiveReorganisation for those unfamiliar with
it; this page also contains some background for some of the Ubuntu
archive jargon I've inevitably ended up using in this post), and I had a
side discussion with Jonathan about a Kubuntu-related question arising
from it.

Ultimately, I still do plan to move all free software in the archive to
a single consolidated "main" component and express who supports what in
ways that are rather more flexible than (effectively) moving files
around in the pool; but it's clear at this point that I'm only going to
be able to lay the groundwork for that this cycle, not actually do it.
In advance of that, though, my question is as follows: is being in main
actually much more than an obstruction to Kubuntu development these
days?

Up to now, the packages that make up Kubuntu - at least the images you
ship - have been in main at least in part because Canonical was offering
some level of support for them, and thus we wanted to make sure they
passed an explicit review by our security team and the like.  Now that
that isn't the case, though, being in main basically means that
Canonical is requiring main inclusion review for Kubuntu even though we
aren't offering support for it, out of step with all other community
flavours, and thus imposing an extra chunk of work on you that nobody
else has to do.  That seems rather unfair!  When I spoke to him at UDS,
Jonathan seemed to feel the same way, and indicated that you might well
want to consider moving Kubuntu-specific packages to universe.

Now, this is one particular way to look at things, and I realise that
you could cast the question differently.  Since the main component has
that extra level of review associated with it and has a more restricted
uploader group, many people do regard it as having an extra claim of
quality.  I don't want to be the guy "kicking Kubuntu out of main"; if
we make this change in advance of a more sweeping archive
reorganisation, I'd much rather do it with your consent and indeed
enthusiasm.  My conversation with Jonathan suggested that this might
well be forthcoming, but I said I'd mail kubuntu-devel to see what other
people think.

Some other details:

 * What effect would such a change have on upgrades?  update-manager
   shows a "no longer supported by Canonical" message for installed
   packages that have been moved from main to universe between releases;
   does muon have anything like this?  I don't want to scare off Kubuntu
   users.

 * Moving to universe would imply not using language packs any more,
   because uploads to universe don't have translations stripped out and
   sent through the Launchpad translations system.  Jonathan suggested
   that this would be a desirable change for Kubuntu, but I expect that
   at the very least it would be a respectable chunk of work for
   somebody to unwind all of that infrastructure.  (As an aside, we'll
   need to think about how this would work post-archive-reorg if more or
   less everything ends up in main.)

 * A number of Kubuntu-specific packages would need to stay in main for
   transitive-closure reasons: source packages in main that, for
   example, build bindings for both GTKish and Qtish worlds will
   generally build-depend on both, which will cause those
   build-dependencies to stay in main along with all their
   (build-)dependencies.  I don't want to encourage people to start
   splitting source packages for the sake of this, so a number of base
   packages would stay in main regardless.  Still, lots of UI packages
   would be able to drop out to a component with less restrictive
   processes.

   I've attached a file showing a first pass at what the results would
   have been if we'd done this for 12.04.

 * Are there any effects on mirroring that you care about?  Right now,
   it's in principle possible to run an archive mirror useful to Kubuntu
   users with only main (and maybe restricted).  This change would mean
   you'd have to have universe as well.  On the other hand, Xubuntu et
   al have this problem today anyway, and maybe you only care about
   things like the major per-country mirror network which carries
   everything.

 * Would there be any "soft" questions of PR and the like that would
   need to be addressed?

Thanks,

[greenrd< at >gmail.com: Bug report: Mailing list reject message isunfriendly]

Jonathan Riddell — 2012-05-23T11:23:00

----- Forwarded message from Robin Green <greenrd< at >gmail.com> -----

Date: Wed, 23 May 2012 12:19:59 +0100
Subject: Bug report: Mailing list reject message is unfriendly
From: Robin Green <greenrd< at >gmail.com>
To: kubuntu-devel-owner< at >lists.ubuntu.com
Sender: mailman-bounces< at >lists.ubuntu.com

   I am very annoyed because kcrashhandler told me to report a bug in
   apport-kde by email to kubuntu-devel< at >lists.ubuntu.com. But YOU CAN'T
   because YOU GET THE MESSAGE "You are not allowed to post to this mailing
   list, and your message has
   been automatically rejected. "
   This is not at all user-friendly.
   This was the end of a long list of crashes and incorrect behaviours that I
   ran into while trying to report a bug. The user experience needs to be
   improved.

[Blueprint topic-quantal-flavor-kubuntu] Kubuntu Quantal PLans

Kate Stewart — 2012-05-23T02:14:26

Blueprint changed by Kate Stewart:

    Definition Status: Drafting => Approved

[Blueprint topic-quantal-flavor-kubuntu] Kubuntu Quantal PLans

Kate Stewart — 2012-05-23T02:14:15

Blueprint changed by Kate Stewart:

    Definition Status: New => Drafting

[Blueprint topic-quantal-flavor-kubuntu] Kubuntu Quantal PLans

Kate Stewart — 2012-05-23T02:14:02

Blueprint changed by Kate Stewart:

    Priority: Undefined => Medium

RE: How to report a bug.

Clay Weber — 2012-05-21T16:29:27

The procedure world be the same: file report in launchpad and link to any relevant bug in LO bug tracker and also to the relevant fix you found. 

On launchpad you would file it against libreoffice-kde.

Clay Weber

------Original Message------
From: Mitch Golden <mgolden< at >mitchgolden.com>
To: "Kubuntu Developer Discussion" <kubuntu-devel< at >lists.ubuntu.com>
Date: Monday, May 21, 2012 12:12:04 PM GMT-0400
Subject: RE: How to report a bug.

On Mon, 21 May 2012, Alessandro Menti wrote:

Thank you, it does.  From further discussion on the Fedora bugzilla, I see 
that the the fix has already been made on the libreoffice-kde package 
upstream, so what needs to be done is to backport the patch to the current 
kubuntu version.  I will therefore only need to do (2).

The issue is actually pretty serious: because of the bug, you can't use 
the filter dropdown on the Open dialog.  This means you can't open a 
tab-delimited file with extension .txt as a spreadsheet, because if you 
use the open dialog without using the Filter dropdown, it always opens as 
a text file.

   - Mitch Golden

RE: How to report a bug.

Clay Weber — 2012-05-21T16:29:31

Also a work around is to remove the libreoffice-kde package and use LO's native file picker.

Clay Weber

------Original Message------
From: Mitch Golden <mgolden< at >mitchgolden.com>
To: "Kubuntu Developer Discussion" <kubuntu-devel< at >lists.ubuntu.com>
Date: Monday, May 21, 2012 12:12:04 PM GMT-0400
Subject: RE: How to report a bug.

On Mon, 21 May 2012, Alessandro Menti wrote:

Thank you, it does.  From further discussion on the Fedora bugzilla, I see 
that the the fix has already been made on the libreoffice-kde package 
upstream, so what needs to be done is to backport the patch to the current 
kubuntu version.  I will therefore only need to do (2).

The issue is actually pretty serious: because of the bug, you can't use 
the filter dropdown on the Open dialog.  This means you can't open a 
tab-delimited file with extension .txt as a spreadsheet, because if you 
use the open dialog without using the Filter dropdown, it always opens as 
a text file.

   - Mitch Golden

RE: How to report a bug.

Mitch Golden — 2012-05-21T16:12:04


Thank you, it does.  From further discussion on the Fedora bugzilla, I see 
that the the fix has already been made on the libreoffice-kde package 
upstream, so what needs to be done is to backport the patch to the current 
kubuntu version.  I will therefore only need to do (2).

The issue is actually pretty serious: because of the bug, you can't use 
the filter dropdown on the Open dialog.  This means you can't open a 
tab-delimited file with extension .txt as a spreadsheet, because if you 
use the open dialog without using the Filter dropdown, it always opens as 
a text file.

   - Mitch Golden

Re: Looking to contribute

2012-05-21T10:10:04

Great, come on in.

At this early stage in the cycle there will be a bunch of work to merge the packages to minimise the changes against Debian.  So as a way to start I'd suggest grabbing a package and working out the differences against Debian and if they should be kept.

pick a KDE package from https://merges.ubuntu.com/main.html  maybe skanlite

We tend to work best on IRC in #kubuntu-devel so just say hi and ask for help when you get stuck (I'm off IRC for a wee brake until the start of June).

Jonathan

Fwd: Automatic crash report generated by DrKonqi for Apport KDE.

2012-05-21T09:30:43

----- Forwarded message from Dennis Schridde <devurandom< at >gmx.net> -----

From: Dennis Schridde <devurandom< at >gmx.net>
To: kubuntu-devel-owner< at >lists.ubuntu.com
Subject: Fwd: Automatic crash report generated by DrKonqi for Apport KDE.
Date: Mon, 14 May 2012 12:58:19 +0200
Sender: mailman-bounces< at >lists.ubuntu.com

Hello Kubuntu developers!

Apport crashed and started DrKonqi, which then wanted me to send an email to 
the kubuntu-devel mailinglist. This was not possible, because the mailinglist 
is write protected.

--Dennis
Content-Description: kubuntu-devel-owner< at >lists.ubuntu.com: Re: Automatic crash report generated by DrKonqi for Apport KDE.
Subject: Re: Automatic crash report generated by DrKonqi for Apport KDE.
From: kubuntu-devel-owner< at >lists.ubuntu.com
To: devurandom< at >gmx.net
Date: Mon, 14 May 2012 10:04:15 +0000
Sender: kubuntu-devel-bounces< at >lists.ubuntu.com

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
kubuntu-devel-owner< at >lists.ubuntu.com.

From: Dennis Schridde <devurandom< at >gmx.net>
To: kubuntu-devel< at >lists.ubuntu.com
Subject: Re: Automatic crash report generated by DrKonqi for Apport KDE.
Date: Mon, 14 May 2012 12:04:09 +0200

Am Montag, 14. Mai 2012, 12:00:26 schrieben Sie:
Console output was:
python: ../../src/xcb_io.c:528: _XAllocID: Assertion `ret != inval_id' failed.
KCrash: Application '' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit

Content-Description: kubuntu-devel-owner< at >lists.ubuntu.com: Automatic crash report generated by DrKonqi for Apport KDE.
Subject: Automatic crash report generated by DrKonqi for Apport KDE.
From: kubuntu-devel-owner< at >lists.ubuntu.com
To: devurandom< at >gmx.net
Date: Mon, 14 May 2012 10:00:51 +0000
Sender: kubuntu-devel-bounces< at >lists.ubuntu.com

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
kubuntu-devel-owner< at >lists.ubuntu.com.

From: Dennis Schridde <devurandom< at >gmx.net>
To: kubuntu-devel< at >lists.ubuntu.com
Subject: Automatic crash report generated by DrKonqi for Apport KDE.
Date: Mon, 14 May 2012 12:00:26 +0200

Application: python2 (1.0)
KDE Platform Version: 4.8.2 (4.8.2)
Qt Version: 4.8.1
Operating System: Linux 3.2.0-24-generic-pae i686
Distribution: Ubuntu 12.04 LTS