Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
KDE SC 4.10
40 views
Skip to first unread message
Martin Steigerwald
Mar 17, 2013, 11:10:02 AM3/17/13
to
Hi!
I have browsed some basic packages at git.debian.org and it seems
José and others work on KDE SC 4.10.
Are any of these already in a testable state? I may be inclined to build
some during the free week after the coming week.
Anyway, keep up the good work.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201303171601...@lichtvoll.de
I have browsed some basic packages at git.debian.org and it seems
José and others work on KDE SC 4.10.
Are any of these already in a testable state? I may be inclined to build
some during the free week after the coming week.
Anyway, keep up the good work.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201303171601...@lichtvoll.de
José Manuel Santamaría Lema
Apr 1, 2013, 6:20:01 PM4/1/13
to
Hello Marin,
Martin Steigerwald <Mar...@lichtvoll.de>
packages for that project from now on. The packages of debian's git are almost
ready but they probably need some few changes (some Breaks/Replaces here and
there), I have hacked them a bit and I released them for siduction, While this
packages are meant to be included in that distro, I tried to install them in a
debian machine and they work, you can install them adding this line to your
sources.list or sources.list.d/whatever:
deb http://packages.siduction.org/kdenext experimental-snapshots
and then you can install siduction-archive-keyring and upgrade. Pretty much as
you did with qt-kde.debian.net.
Hint: don't upgrade with the X server running if you are upgrading from 4.9.5,
we got some hangs.
[1] It's a rolling release based on debian sid, so no freezes because they are
not needed.
Martin Steigerwald <Mar...@lichtvoll.de>
> Hi!
>
> I have browsed some basic packages at git.debian.org and it seems
> José and others work on KDE SC 4.10.
>
> Are any of these already in a testable state? I may be inclined to build
> some during the free week after the coming week.
>
> Anyway, keep up the good work.
>
> Thanks,
I have switched to siduction[1], this means I will be working providing
>
> I have browsed some basic packages at git.debian.org and it seems
> José and others work on KDE SC 4.10.
>
> Are any of these already in a testable state? I may be inclined to build
> some during the free week after the coming week.
>
> Anyway, keep up the good work.
>
> Thanks,
packages for that project from now on. The packages of debian's git are almost
ready but they probably need some few changes (some Breaks/Replaces here and
there), I have hacked them a bit and I released them for siduction, While this
packages are meant to be included in that distro, I tried to install them in a
debian machine and they work, you can install them adding this line to your
sources.list or sources.list.d/whatever:
deb http://packages.siduction.org/kdenext experimental-snapshots
and then you can install siduction-archive-keyring and upgrade. Pretty much as
you did with qt-kde.debian.net.
Hint: don't upgrade with the X server running if you are upgrading from 4.9.5,
we got some hangs.
[1] It's a rolling release based on debian sid, so no freezes because they are
not needed.
José Manuel Santamaría Lema
Apr 1, 2013, 6:30:02 PM4/1/13
to
José Manuel Santamaría Lema <panf...@gmail.com>
> deb http://packages.siduction.org/kdenext experimental-snapshots
Oops, I actually meant:
deb http://packages.siduction.org/kdenext experimental-snapshots main
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201304020028....@gmail.com
> deb http://packages.siduction.org/kdenext experimental-snapshots
Oops, I actually meant:
deb http://packages.siduction.org/kdenext experimental-snapshots main
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Baron
Apr 3, 2013, 3:30:03 PM4/3/13
to
Up and running, quite nicely
My wife's desktop came up, no problem.
Mine crashed plasma-desktop. Had to start over, new .kde.
Found problem was actually the yaWP weather plasmoid. When I put that back,
crashed, so had to do some surgery on plasma-desktop-appletrc to get rid of
it.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/0MKP00M9...@a-mtaout20.012.net.il
My wife's desktop came up, no problem.
Mine crashed plasma-desktop. Had to start over, new .kde.
Found problem was actually the yaWP weather plasmoid. When I put that back,
crashed, so had to do some surgery on plasma-desktop-appletrc to get rid of
it.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
José Manuel Santamaría Lema
Apr 3, 2013, 7:10:02 PM4/3/13
to
David Baron <d_b...@012.net.il>
rebuilt against 4.8. Do you still have the same problem?
> Up and running, quite nicely
>
> My wife's desktop came up, no problem.
> Mine crashed plasma-desktop. Had to start over, new .kde.
>
> Found problem was actually the yaWP weather plasmoid. When I put that back,
> crashed, so had to do some surgery on plasma-desktop-appletrc to get rid of
> it.
I have updated the KDE packages to 4.10.2 and plasma-widget-yawp to 0.4.5
>
> My wife's desktop came up, no problem.
> Mine crashed plasma-desktop. Had to start over, new .kde.
>
> Found problem was actually the yaWP weather plasmoid. When I put that back,
> crashed, so had to do some surgery on plasma-desktop-appletrc to get rid of
> it.
rebuilt against 4.8. Do you still have the same problem?
José Manuel Santamaría Lema
Apr 3, 2013, 7:20:02 PM4/3/13
to
José Manuel Santamaría Lema <panf...@gmail.com>
> rebuilt against 4.8
ugh, I meant rebuilt against KDE workspaces 4.10.
Diederik de Haas
Apr 4, 2013, 2:30:01 AM4/4/13
to
The upgrade fails on my system, each time with kde-runtime-data.
Details:
# aptitude safe-upgrade
Resolving dependencies...
The following packages will be upgraded:
kde-runtime-data
The following partially installed packages will be configured:
dolphin kate kde-baseapps kde-baseapps-bin kde-plasma-desktop kde-runtime
kdebase-apps kdebase-bin kdepasswd kfind klipper kmenuedit konq-plugins konqueror
konqueror-nsplugins kwrite libkateinterfaces4
1 packages upgraded, 0 newly installed, 0 to remove and 57 not upgraded.
Need to get 0 B/6,018 kB of archives. After unpacking 1,144 kB will be used.
Do you want to continue? [Y/n/?]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 157908 files and directories currently installed.)
Preparing to replace kde-runtime-data 4:4.9.5-0r1 (using .../kde-runtime-
data_4%3a4.10.2-1_all.deb) ...
Unpacking replacement kde-runtime-data ...
dpkg: error processing /var/cache/apt/archives/kde-runtime-
data_4%3a4.10.2-1_all.deb (--unpack):
trying to overwrite '/usr/share/man/man1/plasmapkg.1.gz', which is also in
package kde-workspace-bin 4:4.9.5-0r5
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Errors were encountered while processing:
/var/cache/apt/archives/kde-runtime-data_4%3a4.10.2-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
dpkg: dependency problems prevent configuration of kde-runtime:
kde-runtime depends on kde-runtime-data (>= 4:4.10.2-1); however:
Version of kde-runtime-data on system is 4:4.9.5-0r1.
... whole bunch of similar dpkg errors follows ...
A full-upgrade basically wants to remove kde-pim apps, so didn't continue.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201304040821.39...@cknow.org
Details:
# aptitude safe-upgrade
Resolving dependencies...
The following packages will be upgraded:
kde-runtime-data
The following partially installed packages will be configured:
dolphin kate kde-baseapps kde-baseapps-bin kde-plasma-desktop kde-runtime
kdebase-apps kdebase-bin kdepasswd kfind klipper kmenuedit konq-plugins konqueror
konqueror-nsplugins kwrite libkateinterfaces4
1 packages upgraded, 0 newly installed, 0 to remove and 57 not upgraded.
Need to get 0 B/6,018 kB of archives. After unpacking 1,144 kB will be used.
Do you want to continue? [Y/n/?]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 157908 files and directories currently installed.)
Preparing to replace kde-runtime-data 4:4.9.5-0r1 (using .../kde-runtime-
data_4%3a4.10.2-1_all.deb) ...
Unpacking replacement kde-runtime-data ...
dpkg: error processing /var/cache/apt/archives/kde-runtime-
data_4%3a4.10.2-1_all.deb (--unpack):
trying to overwrite '/usr/share/man/man1/plasmapkg.1.gz', which is also in
package kde-workspace-bin 4:4.9.5-0r5
Processing triggers for desktop-file-utils ...
Processing triggers for man-db ...
Errors were encountered while processing:
/var/cache/apt/archives/kde-runtime-data_4%3a4.10.2-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
dpkg: dependency problems prevent configuration of kde-runtime:
kde-runtime depends on kde-runtime-data (>= 4:4.10.2-1); however:
Version of kde-runtime-data on system is 4:4.9.5-0r1.
... whole bunch of similar dpkg errors follows ...
A full-upgrade basically wants to remove kde-pim apps, so didn't continue.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Baron
Apr 4, 2013, 2:40:02 AM4/4/13
to
I rebuilt 0.4.5 and still crashed.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Diederik de Haas
Apr 4, 2013, 2:40:02 AM4/4/13
to
On Thursday 04 April 2013 08:21:39 Diederik de Haas wrote:
> The upgrade fails on my system, each time with kde-runtime-data.
Please disregard my previous msg, since I was upgrading from the 'normal'
> The upgrade fails on my system, each time with kde-runtime-data.
experimental.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
Apr 4, 2013, 4:30:02 AM4/4/13
to
On 2013-04-04, Diederik de Haas <didi....@cknow.org> wrote:
> On Thursday 04 April 2013 08:21:39 Diederik de Haas wrote:
>> The upgrade fails on my system, each time with kde-runtime-data.
>
> Please disregard my previous msg, since I was upgrading from the 'normal'
> experimental.
the 'normal' experimental is where the action happens, but it happens
> On Thursday 04 April 2013 08:21:39 Diederik de Haas wrote:
>> The upgrade fails on my system, each time with kde-runtime-data.
>
> Please disregard my previous msg, since I was upgrading from the 'normal'
> experimental.
currently dripwise and not as a big chunk, as it makes stuff easier for
the developers. It includes prepearation for the modern kdepim.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Baron
Apr 4, 2013, 4:50:02 AM4/4/13
to
On Thursday, 04 April, 2013 09:32:04 AM David Baron wrote:
> On Thursday, 04 April, 2013 02:08:00 AM José Manuel Santamaría Lema wrote:
> > David Baron <d_b...@012.net.il>
> >
> > > Up and running, quite nicely
> > >
> > > My wife's desktop came up, no problem.
> > > Mine crashed plasma-desktop. Had to start over, new .kde.
> > >
> > > Found problem was actually the yaWP weather plasmoid. When I put that
> > > back, crashed, so had to do some surgery on plasma-desktop-appletrc to
> > > get rid of it.
> >
> > I have updated the KDE packages to 4.10.2 and plasma-widget-yawp to 0.4.5
> > rebuilt against 4.8. Do you still have the same problem?
>
> Question is are the appropriate dev packages up-to-date?
> I rebuilt 0.4.5 and still crashed.
All siduction pakages upgraded today, saw -dev packages there as well.
> On Thursday, 04 April, 2013 02:08:00 AM José Manuel Santamaría Lema wrote:
> > David Baron <d_b...@012.net.il>
> >
> > > Up and running, quite nicely
> > >
> > > My wife's desktop came up, no problem.
> > > Mine crashed plasma-desktop. Had to start over, new .kde.
> > >
> > > Found problem was actually the yaWP weather plasmoid. When I put that
> > > back, crashed, so had to do some surgery on plasma-desktop-appletrc to
> > > get rid of it.
> >
> > I have updated the KDE packages to 4.10.2 and plasma-widget-yawp to 0.4.5
> > rebuilt against 4.8. Do you still have the same problem?
>
> Question is are the appropriate dev packages up-to-date?
> I rebuilt 0.4.5 and still crashed.
Rebuild yaWP 0.4.5
Still crashes.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
Apr 4, 2013, 5:00:02 AM4/4/13
to
On 2013-04-04, David Baron <d_b...@012.net.il> wrote:
> All siduction pakages upgraded today, saw -dev packages there as well.
Please take siduction support off this list.
> All siduction pakages upgraded today, saw -dev packages there as well.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Martin Steigerwald
Apr 4, 2013, 6:50:03 AM4/4/13
to
Am Dienstag, 2. April 2013 schrieb José Manuel Santamaría Lema:
> Hello Marin,
Hi José,
> > Hi!
> >
> > I have browsed some basic packages at git.debian.org and it seems
> > José and others work on KDE SC 4.10.
> >
> > Are any of these already in a testable state? I may be inclined to
> > build some during the free week after the coming week.
> >
> > Anyway, keep up the good work.
> >
> > Thanks,
>
> I have switched to siduction[1], this means I will be working providing
> packages for that project from now on. The packages of debian's git are
> almost ready but they probably need some few changes (some
> Breaks/Replaces here and there), I have hacked them a bit and I released
> them for siduction, While this packages are meant to be included in that
> distro, I tried to install them in a debian machine and they work, you
José, thank you.
I am reluctant about switching (partly) to a Debian derivative. I didn´t
switch to Ubuntu and seeing the recent stuff happening there I now know why.
And while I think end of freeze period times in Debian are sometimes difficult
to deal with I am also a bit tired of the ton of Debian derivatives, their
renames, closings and reopenings somewhere else and so on and would like a
rolling Debian instead :).
Debian is a constant for me, it has always been there, since I use it. It
may not have been the best in all cases, but at last its still there and
rocking.
And anyway, there is a way to provide rolling KDE SC in qt-kde.debian.net or
wasn´t there?
Also I don´t like to ask for feedback regarding any possible installation of
your packages on this list, cause, well, the list is called debian-kde not
siduction-kde :)
> [1] It's a rolling release based on debian sid, so no freezes because
> they are not needed.
> Hello Marin,
Hi José,
> > Hi!
> >
> > I have browsed some basic packages at git.debian.org and it seems
> > José and others work on KDE SC 4.10.
> >
> > Are any of these already in a testable state? I may be inclined to
> > build some during the free week after the coming week.
> >
> > Anyway, keep up the good work.
> >
> > Thanks,
>
> I have switched to siduction[1], this means I will be working providing
> packages for that project from now on. The packages of debian's git are
> almost ready but they probably need some few changes (some
> Breaks/Replaces here and there), I have hacked them a bit and I released
> them for siduction, While this packages are meant to be included in that
> distro, I tried to install them in a debian machine and they work, you
I am reluctant about switching (partly) to a Debian derivative. I didn´t
switch to Ubuntu and seeing the recent stuff happening there I now know why.
And while I think end of freeze period times in Debian are sometimes difficult
to deal with I am also a bit tired of the ton of Debian derivatives, their
renames, closings and reopenings somewhere else and so on and would like a
rolling Debian instead :).
Debian is a constant for me, it has always been there, since I use it. It
may not have been the best in all cases, but at last its still there and
rocking.
And anyway, there is a way to provide rolling KDE SC in qt-kde.debian.net or
wasn´t there?
Also I don´t like to ask for feedback regarding any possible installation of
your packages on this list, cause, well, the list is called debian-kde not
siduction-kde :)
> [1] It's a rolling release based on debian sid, so no freezes because
> they are not needed.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201304041244...@lichtvoll.de
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Baron
Apr 4, 2013, 7:00:02 AM4/4/13
to
on qt-kde.debian.net/debian and now the 4.10 on
packages.siduction.org/kdenext. This is certainly not desirable and
probably, the 4.10 shouild be copied or moved to the debian snapshots. Once
4.10 is installed, it is not possible to go back so no need for both.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Julian
Apr 5, 2013, 3:50:02 AM4/5/13
to
On 04/04/13 21:54, David Baron wrote:
>
> I agree. I have two (count 'em) experimental snapshot sets of KDE, the KDE4.9
> on qt-kde.debian.net/debian and now the 4.10 on
> packages.siduction.org/kdenext. This is certainly not desirable and
> probably, the 4.10 shouild be copied or moved to the debian snapshots. Once
> 4.10 is installed, it is not possible to go back so no need for both.
>
>
Were the servers down at qt-kde.debian.net? Sorry I'm just confused as
>
> I agree. I have two (count 'em) experimental snapshot sets of KDE, the KDE4.9
> on qt-kde.debian.net/debian and now the 4.10 on
> packages.siduction.org/kdenext. This is certainly not desirable and
> probably, the 4.10 shouild be copied or moved to the debian snapshots. Once
> 4.10 is installed, it is not possible to go back so no need for both.
>
>
to why 4.10 isn't there?
siduction is not something that I'll install as an complete OS for now,
rolling release distributions aren't as important as you think, but IMO
serve a different purpose.
Having a stable and tested operating system and its core packages is
important and packages end up in stable that have gone through the
rigmarole.
Rolling releases of individual packages are everywhere (downloadable
.deb packages or little source repos), most of the time (all the time?)
these are not critical core OS libraries or applications.
But there was nothing like this for KDE unless you built your own and
didn't give a damn about that "oh so very important package six versions
down" (that I won't mention DIE ****** DIE), you were stuck.
So for that siduction is doing a great service to the community.
May their rolling releases end up in "experimental"
I can only see benefits.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
Apr 5, 2013, 4:00:02 AM4/5/13
to
On 2013-04-05, Julian <tem...@internode.on.net> wrote:
> Were the servers down at qt-kde.debian.net? Sorry I'm just confused as
> to why 4.10 isn't there?
pushing things to qt-kde.debian.net is quite some extra work for
> Were the servers down at qt-kde.debian.net? Sorry I'm just confused as
> to why 4.10 isn't there?
everybody, for example it is not hooked up to debian autobuilder
infrastructure, so it is basicalyl doubling the work if the work is
planned to end up in the real debian archive.
personally, I also think that qt-kde.debian.net isn't a good solution to
any problem. Stuff should in my opinion happen in the debian archive.
Oh. and it is me who has pushed most stuff to the archive so far.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Martin Steigerwald
Apr 5, 2013, 4:40:02 AM4/5/13
to
Am Freitag, 5. April 2013 schrieb Sune Vuorela:
> On 2013-04-05, Julian <tem...@internode.on.net> wrote:
> > Were the servers down at qt-kde.debian.net? Sorry I'm just confused as
> > to why 4.10 isn't there?
>
> pushing things to qt-kde.debian.net is quite some extra work for
> everybody, for example it is not hooked up to debian autobuilder
> infrastructure, so it is basicalyl doubling the work if the work is
> planned to end up in the real debian archive.
>
> personally, I also think that qt-kde.debian.net isn't a good solution to
> any problem. Stuff should in my opinion happen in the debian archive.
> Oh. and it is me who has pushed most stuff to the archive so far.
What was the reason for qt-kde.debian.net then? From the page:
> On 2013-04-05, Julian <tem...@internode.on.net> wrote:
> > Were the servers down at qt-kde.debian.net? Sorry I'm just confused as
> > to why 4.10 isn't there?
>
> pushing things to qt-kde.debian.net is quite some extra work for
> everybody, for example it is not hooked up to debian autobuilder
> infrastructure, so it is basicalyl doubling the work if the work is
> planned to end up in the real debian archive.
>
> personally, I also think that qt-kde.debian.net isn't a good solution to
> any problem. Stuff should in my opinion happen in the debian archive.
> Oh. and it is me who has pushed most stuff to the archive so far.
"The primary purpose of this repository is to provide package versions of
the KDE applications which for some reason cannot be uploaded to unstable or
experimental."
So a goal can be to have experimental always be ready to accept new KDE SC
packages? At what times wasn´t it? Does it have to do with the freeze? I
always thought the freeze would only affect sid.
Well but then this discussion is out of scope here on the list, since it
basically is a users mailing list.
I continue looking forward to KDE SC 4.10 for Debian via official means.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201304051034...@lichtvoll.de
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
Apr 5, 2013, 4:50:02 AM4/5/13
to
On 2013-04-05, Martin Steigerwald <Mar...@lichtvoll.de> wrote:
> What was the reason for qt-kde.debian.net then? From the page:
Some people thinks experimental is hard. Other people dislike doing the
> What was the reason for qt-kde.debian.net then? From the page:
copyright-documentation that is required for the official archive. And
qt-kde.d.n also could allow people who isn't a DD/DM to put packages
there.
I think 1) is bogus. But note that experimental is also sometimes used
for stuff that is *experimental*.
2) is just a way to delay work that anyways needs to be done. so just
get it done.
and 3) I just think is a bad idea.
> So a goal can be to have experimental always be ready to accept new KDE SC
> always thought the freeze would only affect sid.
It is completely unrelated to the freeze.
> Well but then this discussion is out of scope here on the list, since it
> basically is a users mailing list.
Oh. and note that what's in experimental now is still considered
experimental. so ensure you have backups ready if you install it.
And it is definately not ready for bug reports like 'you miss <foo>'.
Actual upgrade issues, like file overlaps and such - you are most
welcome to report those. But remember your backup.
And finally, if any newcomer wants to help on easy tasks (there is lots
of easy packages left), please contact me.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rainer Dorsch
Apr 6, 2013, 3:40:01 AM4/6/13
to
Hello,
Am Friday 05 April 2013 schrieb Sune Vuorela:
> Actual upgrade issues, like file overlaps and such - you are most
> welcome to report those. But remember your backup.
not sure if this has the same root cause as the amarok upgrade issue I
reported in the previous post. If yes, please ignore:
blackbox:~# aptitude install -t experimental digikam
2 packages upgraded, 0 newly installed, 0 to remove and 667 not upgraded.
Need to get 19.8 MB of archives. After unpacking 3206 kB will be used.
The following packages have unmet dependencies:
digikam : Conflicts: libkdcraw-data but 4:4.8.4-1 is installed.
Conflicts: libkdcraw20 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-10 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-data but 4:4.8.4-1 is installed and it is kept
back.
Conflicts: libkipi-data but 4:4.8.4-1 is installed and it is kept
back.
Conflicts: libkipi8 but 4:4.8.4-1 is installed.
Conflicts: libksane0 but 4:4.8.4-1 is installed.
digikam-data : Conflicts: libkdcraw-data but 4:4.8.4-1 is installed.
Conflicts: libkdcraw20 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-10 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-data but 4:4.8.4-1 is installed and it is
kept back.
Conflicts: libkipi-data but 4:4.8.4-1 is installed and it is
kept back.
Conflicts: libkipi8 but 4:4.8.4-1 is installed.
Conflicts: libksane0 but 4:4.8.4-1 is installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) digikam
2) digikam-data
3) kipi-plugins
Accept this solution? [Y/n/q/?]
Thanks,
Rainer
--
Rainer Dorsch
http://bokomoko.de/
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013040609...@bokomoko.de
Am Friday 05 April 2013 schrieb Sune Vuorela:
> Actual upgrade issues, like file overlaps and such - you are most
> welcome to report those. But remember your backup.
reported in the previous post. If yes, please ignore:
blackbox:~# aptitude install -t experimental digikam
The following packages will be upgraded:
digikam{b} digikam-data{b}
2 packages upgraded, 0 newly installed, 0 to remove and 667 not upgraded.
Need to get 19.8 MB of archives. After unpacking 3206 kB will be used.
The following packages have unmet dependencies:
digikam : Conflicts: libkdcraw-data but 4:4.8.4-1 is installed.
Conflicts: libkdcraw20 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-10 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-data but 4:4.8.4-1 is installed and it is kept
back.
Conflicts: libkipi-data but 4:4.8.4-1 is installed and it is kept
back.
Conflicts: libkipi8 but 4:4.8.4-1 is installed.
Conflicts: libksane0 but 4:4.8.4-1 is installed.
digikam-data : Conflicts: libkdcraw-data but 4:4.8.4-1 is installed.
Conflicts: libkdcraw20 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-10 but 4:4.8.4-1 is installed.
Conflicts: libkexiv2-data but 4:4.8.4-1 is installed and it is
kept back.
Conflicts: libkipi-data but 4:4.8.4-1 is installed and it is
kept back.
Conflicts: libkipi8 but 4:4.8.4-1 is installed.
Conflicts: libksane0 but 4:4.8.4-1 is installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) digikam
2) digikam-data
3) kipi-plugins
Accept this solution? [Y/n/q/?]
Thanks,
Rainer
--
Rainer Dorsch
http://bokomoko.de/
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Rainer Dorsch
Apr 6, 2013, 3:40:01 AM4/6/13
to
Am Friday 05 April 2013 schrieb Sune Vuorela:
> Actual upgrade issues, like file overlaps and such - you are most
> welcome to report those. But remember your backup.
Hmm...I am hesitant to open a bug report here, because that seems so obvious
> Actual upgrade issues, like file overlaps and such - you are most
> welcome to report those. But remember your backup.
that I am almost sure that I miss something. Does anybody see what I might
miss?
blackbox:~# apt-get install -t experimental amarok
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
be installed
E: Unable to correct problems, you have held broken packages.
blackbox:~# apt-cache policy libavcodec-extra-53
libavcodec-extra-53:
Installed: (none)
Candidate: 6:0.8.6-1
Version table:
6:0.8.6-1 0
500 http://ftp-stud.fht-esslingen.de/debian/ wheezy/main i386 Packages
300 http://ftp-stud.fht-esslingen.de/debian/ sid/main i386 Packages
4:0.7.2.1+b1 0
100 /var/lib/dpkg/status
blackbox:~#
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013040609...@bokomoko.de
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Modestas Vainius
Apr 6, 2013, 5:40:02 AM4/6/13
to
Hello,
On Friday 05 April 2013 08:42:54 Sune Vuorela wrote:
> On 2013-04-05, Martin Steigerwald <Mar...@lichtvoll.de> wrote:
> > What was the reason for qt-kde.debian.net then? From the page:
> Some people thinks experimental is hard. Other people dislike doing the
> copyright-documentation that is required for the official archive. And
> qt-kde.d.n also could allow people who isn't a DD/DM to put packages
> there.
Well, qt-kde.d.n as distribution channel has probably outlived its purpose
even if it can still be useful sometimes.
The rest of the mail will be a bit OT for this list, however, in my opinion,
users might still be interested what some of the challenges are with KDE
packaging. Actually, these are the main things which turn (have turned) me off
from KDE packaging these days.
IMO, it is very complicated to maintain anything that is more like 5-10 highly
coupled source packages in Debian. You have to spend so much time on internal
development infrastructure (constantly) that little time (or motivation)
remains to do actual packaging changes. And as far as I know, KDE approaches
100 source packages, so do the math (funtunately, the number of core packages
is low). Especially, it is very expensive (in terms of both time and knowledge
required) to start KDE packaging for the first time or "resume" work after
longer time of inactivity.
I wish there was some "Continuous integration" for KDE packaging which took
the load of:
* Package building and dependency management.
* Package uploading to development repository for testing.
* Automatted Lintian reports and other Q/A.
* Any other repetitive, boring but useful tasks.
experimental is not suitable for that because it's a distribution channel
rather than a development one. Nowadays experimental latency is OK for
distribution channel however it is very slow for development (anything more
than 5-30 minutes is slow because time is expensive). Not to mention the fact
that you don't want to distribute half baked packages for the sake of yourself
and your users since you still need to test before distribution.
Even for distribution alone (no testing), uploading 100 source packages needs
way too much of mantime. Once you do this a couple of times, it is no fun at
all.
P.S. It may sound that monolithic KDE packages were better. Well, no. They
were awful with respect to actual packaging tasks (where is all the fun)
however "development infrastructure" was more manageable with fewer source
packages (even if their size was a huge disadvantage and PITA).
On Friday 05 April 2013 08:42:54 Sune Vuorela wrote:
> On 2013-04-05, Martin Steigerwald <Mar...@lichtvoll.de> wrote:
> > What was the reason for qt-kde.debian.net then? From the page:
> Some people thinks experimental is hard. Other people dislike doing the
> copyright-documentation that is required for the official archive. And
> qt-kde.d.n also could allow people who isn't a DD/DM to put packages
> there.
even if it can still be useful sometimes.
The rest of the mail will be a bit OT for this list, however, in my opinion,
users might still be interested what some of the challenges are with KDE
packaging. Actually, these are the main things which turn (have turned) me off
from KDE packaging these days.
IMO, it is very complicated to maintain anything that is more like 5-10 highly
coupled source packages in Debian. You have to spend so much time on internal
development infrastructure (constantly) that little time (or motivation)
remains to do actual packaging changes. And as far as I know, KDE approaches
100 source packages, so do the math (funtunately, the number of core packages
is low). Especially, it is very expensive (in terms of both time and knowledge
required) to start KDE packaging for the first time or "resume" work after
longer time of inactivity.
I wish there was some "Continuous integration" for KDE packaging which took
the load of:
* Package building and dependency management.
* Package uploading to development repository for testing.
* Automatted Lintian reports and other Q/A.
* Any other repetitive, boring but useful tasks.
experimental is not suitable for that because it's a distribution channel
rather than a development one. Nowadays experimental latency is OK for
distribution channel however it is very slow for development (anything more
than 5-30 minutes is slow because time is expensive). Not to mention the fact
that you don't want to distribute half baked packages for the sake of yourself
and your users since you still need to test before distribution.
Even for distribution alone (no testing), uploading 100 source packages needs
way too much of mantime. Once you do this a couple of times, it is no fun at
all.
P.S. It may sound that monolithic KDE packages were better. Well, no. They
were awful with respect to actual packaging tasks (where is all the fun)
however "development infrastructure" was more manageable with fewer source
packages (even if their size was a huge disadvantage and PITA).
Beojan Stanislaus
Apr 6, 2013, 8:00:01 AM4/6/13
to
sure)? It means packaging git trunk rather than just tarballs, but that is
probably a good thing.
Sincerely,
Beojan Stanislaus
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pino Toscano
Apr 6, 2013, 8:00:02 AM4/6/13
to
Alle sabato 6 aprile 2013, Rainer Dorsch ha scritto:
> not sure if this has the same root cause as the amarok upgrade issue
> I reported in the previous post. If yes, please ignore:
>
> blackbox:~# aptitude install -t experimental digikam
The digikam version currently experimental is not compilatible neither
> not sure if this has the same root cause as the amarok upgrade issue
> I reported in the previous post. If yes, please ignore:
>
> blackbox:~# aptitude install -t experimental digikam
with KDE 4.8 (in unstable) nor with KDE 4.10 (in experimental).
Yes, it is a known issue due to the braindead way upstream releases
digikam, kipi-plugins and other libraries all together.
Most probably the experimental version could be made compatbile with KDE
4.10 in experimental once all the kdegraphics libraries it uses are
available.
--
Pino Toscano
Modestas Vainius
Apr 6, 2013, 1:10:02 PM4/6/13
to
Hello,
On Saturday 06 April 2013 12:51:13 Beojan Stanislaus wrote:
> > I wish there was some "Continuous integration" for KDE packaging which
> > took
> > the load of:
> >
> > * Package building and dependency management.
> > * Package uploading to development repository for testing.
> > * Automatted Lintian reports and other Q/A.
> > * Any other repetitive, boring but useful tasks.
>
> Isn't this essentially what Kubuntu's Project Neon is (perhaps was, I'm not
> sure)? It means packaging git trunk rather than just tarballs, but that is
> probably a good thing.
> Sincerely,
Project Neon is about distribution of the latest software completely
disregarding quality of packaging and other issues (packages are purposively
dumbbed down). So in the end Project Neon has basically nothing to do with
quality packaging.
On Saturday 06 April 2013 12:51:13 Beojan Stanislaus wrote:
> > I wish there was some "Continuous integration" for KDE packaging which
> > took
> > the load of:
> >
> > * Package building and dependency management.
> > * Package uploading to development repository for testing.
> > * Automatted Lintian reports and other Q/A.
> > * Any other repetitive, boring but useful tasks.
>
> Isn't this essentially what Kubuntu's Project Neon is (perhaps was, I'm not
> sure)? It means packaging git trunk rather than just tarballs, but that is
> probably a good thing.
> Sincerely,
disregarding quality of packaging and other issues (packages are purposively
dumbbed down). So in the end Project Neon has basically nothing to do with
quality packaging.
Diederik de Haas
Apr 6, 2013, 5:00:02 PM4/6/13
to
Sune said:
> the 'normal' experimental is where the action happens, but it happens
> currently dripwise and not as a big chunk, as it makes stuff easier for
> the developers. It includes prepearation for the modern kdepim.
Is that the reason that if I want to do a full-upgrade, the 'solution' to the
> the 'normal' experimental is where the action happens, but it happens
> currently dripwise and not as a big chunk, as it makes stuff easier for
> the developers. It includes prepearation for the modern kdepim.
conflicts is to remove the kdepim apps? And will that be resolved once the modern
kdepim (thanks!) is uploaded as well?
Btw I still get the upgrade issue I mentioned earlier, so I've now put kde-
runtime(-data) on hold. Is that because not all packages are uploaded and/or I
don't want to remove kontact or is there something broken on my system?
If so, hints pointing in the right direction is much appreciated.
Cheers,
Diederik
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Julian
Apr 6, 2013, 8:50:01 PM4/6/13
to
On 07/04/13 06:54, Diederik de Haas wrote:
> Sune said:
>> the 'normal' experimental is where the action happens, but it happens
>> currently dripwise and not as a big chunk, as it makes stuff easier for
>> the developers. It includes prepearation for the modern kdepim.
>
> Is that the reason that if I want to do a full-upgrade, the 'solution' to the
> conflicts is to remove the kdepim apps? And will that be resolved once the modern
> kdepim (thanks!) is uploaded as well?
>
> Btw I still get the upgrade issue I mentioned earlier, so I've now put kde-
> runtime(-data) on hold. Is that because not all packages are uploaded and/or I
> don't want to remove kontact or is there something broken on my system?
> If so, hints pointing in the right direction is much appreciated.
>
> Cheers,
> Diederik
>
>
Theres really no point to installing experimental packages to begin
> Sune said:
>> the 'normal' experimental is where the action happens, but it happens
>> currently dripwise and not as a big chunk, as it makes stuff easier for
>> the developers. It includes prepearation for the modern kdepim.
>
> Is that the reason that if I want to do a full-upgrade, the 'solution' to the
> conflicts is to remove the kdepim apps? And will that be resolved once the modern
> kdepim (thanks!) is uploaded as well?
>
> Btw I still get the upgrade issue I mentioned earlier, so I've now put kde-
> runtime(-data) on hold. Is that because not all packages are uploaded and/or I
> don't want to remove kontact or is there something broken on my system?
> If so, hints pointing in the right direction is much appreciated.
>
> Cheers,
> Diederik
>
>
with, let alone unstable.
But I guess people are desperate for 4.10 and I do sympathize. Just
thought I'd mention that.
These are after all:
"...a series of monthly stabilization updates to the 4.10 series".
Its really obvious that debian in its present state can't work with
that. However KDE fell way behind even when there was no freeze going on.
A "rolling release" repo dedicated to packages available for debian
stable and/or testing is what some people do behind the scenes impatient
on waiting for an "official" distro package.
I have this for a few packages, heres an example of a public one:
deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main
This is official enough for me.
Theres a bigger issue here that I wont bother with ATM. But this is a
solution I support for non core lower level OS *longer shelf life*
critical libraries and applications that are better candidates for the
rigmarole of debian release cycle (perhaps a *hint* to the bigger issue).
Regards,
Jules.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sune Vuorela
Apr 8, 2013, 3:10:02 AM4/8/13
to
On 2013-04-06, Diederik de Haas <didi....@cknow.org> wrote:
> Sune said:
>> the 'normal' experimental is where the action happens, but it happens
>> currently dripwise and not as a big chunk, as it makes stuff easier for
>> the developers. It includes prepearation for the modern kdepim.
>
> Is that the reason that if I want to do a full-upgrade, the 'solution' to the
> conflicts is to remove the kdepim apps? And will that be resolved once the modern
> kdepim (thanks!) is uploaded as well?
Yes. and yes.
> Sune said:
>> the 'normal' experimental is where the action happens, but it happens
>> currently dripwise and not as a big chunk, as it makes stuff easier for
>> the developers. It includes prepearation for the modern kdepim.
>
> Is that the reason that if I want to do a full-upgrade, the 'solution' to the
> conflicts is to remove the kdepim apps? And will that be resolved once the modern
> kdepim (thanks!) is uploaded as well?
I do have - completely untested - but allright-looking packages
available - and if there is a couple of interested people with a good
personal backup strategy, I don't mind sharing them a bit.
Feel free to contact me privately. But note that that you need to have a
good personal backup strategy.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pino Toscano
Apr 11, 2013, 6:40:02 PM4/11/13
to
Alle sabato 6 aprile 2013, Pino Toscano ha scritto:
> Most probably the experimental version could be made compatbile with
> KDE 4.10 in experimental once all the kdegraphics libraries it uses
> are available.
And since yesterday, digikam in experimental depends on the rest of the
> Most probably the experimental version could be made compatbile with
> KDE 4.10 in experimental once all the kdegraphics libraries it uses
> are available.
KDE 4.10 libraries.
--
Pino Toscano
Benjamin Eikel
Apr 12, 2013, 4:00:02 AM4/12/13
to
album browsing, face detecting, raw import). Thank you!
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Libor Klepáč
Apr 12, 2013, 10:00:03 AM4/12/13
to
Hello,
I have build kdepim 4.10.2 packages from git, everything looks fine (i was
building previous version of kdepim from git too, so no migration here)
there is one conflict, it shows during upgrade
------
Preparing to replace kleopatra 4:4.8.3-0r0 (using
.../kleopatra_4.10.2-0r4_amd64.deb) ...
Unpacking replacement kleopatra ...
dpkg: error processing
/root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb (--unpack):
trying to overwrite '/usr/lib/libkleopatraclientgui.so.0.3.0', which is also
in package libkleopatraclientgui0 4:4.8.3-0r0
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
-------
With regards,
Libor
Dne Sunday 07 April 2013 19:50:57, Sune Vuorela napsal(a):
I have build kdepim 4.10.2 packages from git, everything looks fine (i was
building previous version of kdepim from git too, so no migration here)
there is one conflict, it shows during upgrade
------
Preparing to replace kleopatra 4:4.8.3-0r0 (using
.../kleopatra_4.10.2-0r4_amd64.deb) ...
Unpacking replacement kleopatra ...
dpkg: error processing
/root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb (--unpack):
trying to overwrite '/usr/lib/libkleopatraclientgui.so.0.3.0', which is also
in package libkleopatraclientgui0 4:4.8.3-0r0
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
/root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb
-------
With regards,
Libor
Dne Sunday 07 April 2013 19:50:57, Sune Vuorela napsal(a):
Edward J. Shornock
Apr 12, 2013, 10:40:02 AM4/12/13
to
* Benjamin Eikel <deb...@eikel.org> [12-04-2013 11:00 EEST]:
settings -> Kipi Plugins it says "No Kipi Plugin installed" with "Kipi
Plugins 3.1.0" and "LibKipi 2.0.0" shown on the right.
I've not investigated the problem, yet, nor restarted KDE, etc..
> On Friday 12 April 2013 00:30:57 Pino Toscano wrote:
> > Alle sabato 6 aprile 2013, Pino Toscano ha scritto:
> > > Most probably the experimental version could be made compatbile with
> > > KDE 4.10 in experimental once all the kdegraphics libraries it uses
> > > are available.
> >
> > And since yesterday, digikam in experimental depends on the rest of the
> > KDE 4.10 libraries.
>
> Digikam (package version 4:3.1.0-3) works fine for me (I tested installation,
> album browsing, face detecting, raw import). Thank you!
The only thing I've not had success with is 'exporting'. In digikam
> > Alle sabato 6 aprile 2013, Pino Toscano ha scritto:
> > > Most probably the experimental version could be made compatbile with
> > > KDE 4.10 in experimental once all the kdegraphics libraries it uses
> > > are available.
> >
> > And since yesterday, digikam in experimental depends on the rest of the
> > KDE 4.10 libraries.
>
> Digikam (package version 4:3.1.0-3) works fine for me (I tested installation,
> album browsing, face detecting, raw import). Thank you!
settings -> Kipi Plugins it says "No Kipi Plugin installed" with "Kipi
Plugins 3.1.0" and "LibKipi 2.0.0" shown on the right.
I've not investigated the problem, yet, nor restarted KDE, etc..
Sune Vuorela
Apr 12, 2013, 10:50:01 AM4/12/13
to
On 2013-04-12, Libor Klepáč <libor....@bcom.cz> wrote:
Hi
> Preparing to replace kleopatra 4:4.8.3-0r0 (using
This is not a version we have been providing, so upgrading from it is on
your own.
> .../kleopatra_4.10.2-0r4_amd64.deb) ...
This is also not a package we have been providin so upgrading to it is
on your own.
you should be able to recover with repaeting the install a couple of
times.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/slrnkmg7ll...@sshway.ssh.pusling.com
Hi
> Preparing to replace kleopatra 4:4.8.3-0r0 (using
your own.
> .../kleopatra_4.10.2-0r4_amd64.deb) ...
This is also not a package we have been providin so upgrading to it is
on your own.
you should be able to recover with repaeting the install a couple of
times.
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Edward J. Shornock
Apr 12, 2013, 12:30:02 PM4/12/13
to
* Libor Klepáč <libor....@bcom.cz> [12-04-2013 16:58 EEST]:
<http://qt-kde.debian.net/>) packages
> Hello,
> I have build kdepim 4.10.2 packages from git, everything looks fine (i was
> building previous version of kdepim from git too, so no migration here)
> there is one conflict, it shows during upgrade
>
> ------
> Preparing to replace kleopatra 4:4.8.3-0r0 (using
> .../kleopatra_4.10.2-0r4_amd64.deb) ...
> Unpacking replacement kleopatra ...
> dpkg: error processing
> /root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb (--unpack):
> trying to overwrite '/usr/lib/libkleopatraclientgui.so.0.3.0', which is also
> in package libkleopatraclientgui0 4:4.8.3-0r0
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
> /root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb
I had no issues upgrading from the official (experimental) and semi-official (experimental-snapshot from
> I have build kdepim 4.10.2 packages from git, everything looks fine (i was
> building previous version of kdepim from git too, so no migration here)
> there is one conflict, it shows during upgrade
>
> ------
> Preparing to replace kleopatra 4:4.8.3-0r0 (using
> .../kleopatra_4.10.2-0r4_amd64.deb) ...
> Unpacking replacement kleopatra ...
> dpkg: error processing
> /root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb (--unpack):
> trying to overwrite '/usr/lib/libkleopatraclientgui.so.0.3.0', which is also
> in package libkleopatraclientgui0 4:4.8.3-0r0
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
> /root/debs/./kdepim-4.10.2/kleopatra_4.10.2-0r4_amd64.deb
<http://qt-kde.debian.net/>) packages
Sune Vuorela
Apr 13, 2013, 1:10:01 PM4/13/13
to
On 2013-04-07, Sune Vuorela <nos...@vuorela.dk> wrote:
> Feel free to contact me privately. But note that that you need to have a
> good personal backup strategy.
Based on various feedback from the nice volunteers including Diane,
> Feel free to contact me privately. But note that that you need to have a
> good personal backup strategy.
Andreas, Martin, Marco, Edward and Michael, the package is now in
experimental.
Good luck! :)
/Sune
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Libor Klepáč
Apr 13, 2013, 1:30:03 PM4/13/13
to
Hi
you are right, it's not upgrade from or to version in official debian, i forgot that.
Just wanted to help with possible conflict, i didn't realise, that it won't affect users, who use official packages
With regards,
Libor
Markus Raab
Apr 17, 2013, 1:10:01 PM4/17/13
to
Hello!
Julian wrote:
> Having a stable and tested operating system and its core packages is
> important and packages end up in stable that have gone through the
> rigmarole.
I fully agree!
> Rolling releases of individual packages are everywhere (downloadable
> .deb packages or little source repos), most of the time (all the time?)
> these are not critical core OS libraries or applications.
I would not forget backports as "rolling release" for stable. I am looking
forward to wheezy lifetime if backports are more used when they are directly
in main archive.
best regards
Markus
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/kkmjli$9us$1...@news.albasani.net
Julian wrote:
> Having a stable and tested operating system and its core packages is
> important and packages end up in stable that have gone through the
> rigmarole.
> Rolling releases of individual packages are everywhere (downloadable
> .deb packages or little source repos), most of the time (all the time?)
> these are not critical core OS libraries or applications.
forward to wheezy lifetime if backports are more used when they are directly
in main archive.
best regards
Markus
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Julian
Apr 17, 2013, 9:20:01 PM4/17/13
to
On 18/04/13 02:46, Markus Raab wrote:
> Hello!
>
> Julian wrote:
>> Having a stable and tested operating system and its core packages is
>> important and packages end up in stable that have gone through the
>> rigmarole.
>
> I fully agree!
>
>> Rolling releases of individual packages are everywhere (downloadable
>> .deb packages or little source repos), most of the time (all the time?)
>> these are not critical core OS libraries or applications.
>
> I would not forget backports as "rolling release" for stable. I am looking
> forward to wheezy lifetime if backports are more used when they are directly
> in main archive.
>
> best regards
> Markus
>
>
There's no wheezy backports until its release, or thats the process afaik.
> Hello!
>
> Julian wrote:
>> Having a stable and tested operating system and its core packages is
>> important and packages end up in stable that have gone through the
>> rigmarole.
>
> I fully agree!
>
>> Rolling releases of individual packages are everywhere (downloadable
>> .deb packages or little source repos), most of the time (all the time?)
>> these are not critical core OS libraries or applications.
>
> I would not forget backports as "rolling release" for stable. I am looking
> forward to wheezy lifetime if backports are more used when they are directly
> in main archive.
>
> best regards
> Markus
>
>
Something more KDE focused. I do understand that fragmenting releases
can create problems on its own. But I can't see a problem if packages
are strictly allocated officially by debian.
"-t wheezy-kde" works for me, but I can't see why a structure such as
"/debian-rolling-release-kde wheezy main" wouldn't work either.
People desperate for 4.10 are installing experimental, which is crazy,
experimental is the crucible of package pain and will always be that
way, but it is unnecessary for alot of applications out there, including
KDE.
I'd rather test application bugs than package dependency bugs in
experimental. Thats mental.
For example:
At the highest level, the packaging process for the xorg packages should
remain. Every level higher than that? Not important enough and KDE is
just not important, don't let the size of it confuse you, its really not
important.
It would be nice to see debian sleek again and an end to the
insanity of every package that exists on the planet must endure the
release cycle rigmarole even if obsolete by the time it comes out of
freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
Regards.
Jules.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Diane Trout
Apr 17, 2013, 11:10:01 PM4/17/13
to
> People desperate for 4.10 are installing experimental, which is crazy,
> experimental is the crucible of package pain and will always be that
> way, but it is unnecessary for alot of applications out there, including
> KDE.
>
> I'd rather test application bugs than package dependency bugs in
> experimental. Thats mental.
the KDE packaging out from git and build my own against wheezy.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Modestas Vainius
Apr 18, 2013, 8:40:03 AM4/18/13
to
Hello,
On 2013 m. of April 18 d., Thursday 04:04:01 Julian wrote:
> release cycle rigmarole even if obsolete by the time it comes out of
> freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
You know there are many people who do not care (or does not know) about
version at all. All they care about is that stuff just works (tm).
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201304181532...@debian.org
On 2013 m. of April 18 d., Thursday 04:04:01 Julian wrote:
> release cycle rigmarole even if obsolete by the time it comes out of
> freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
version at all. All they care about is that stuff just works (tm).
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Edward J. Shornock
Apr 18, 2013, 12:40:01 PM4/18/13
to
* Modestas Vainius <mo...@debian.org> [18-04-2013 15:34 EEST]:
"experimental". Updating everything to the versions in "experimental"
would be insane.
> You know there are many people who do not care (or does not know) about
> version at all. All they care about is that stuff just works (tm).
Indeed, people like my wife couldn't care less. She knows I'm
testing/using 4.10.2 on my PC but she's perfectly happy with her KDE 4.8
installation because "it just works".
> On 2013 m. of April 18 d., Thursday 04:04:01 Julian wrote:
> > release cycle rigmarole even if obsolete by the time it comes out of
> > freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
> > release cycle rigmarole even if obsolete by the time it comes out of
> > freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
> > People desperate for 4.10 are installing experimental, which is
> > crazy, experimental is the crucible of package pain and will always be that
> > way, but it is unnecessary for alot of applications out there, including
> > KDE.
I don't have a problem with cherry-picking what I want to use from
> > crazy, experimental is the crucible of package pain and will always be that
> > way, but it is unnecessary for alot of applications out there, including
> > KDE.
"experimental". Updating everything to the versions in "experimental"
would be insane.
> You know there are many people who do not care (or does not know) about
> version at all. All they care about is that stuff just works (tm).
testing/using 4.10.2 on my PC but she's perfectly happy with her KDE 4.8
installation because "it just works".
Julian
Apr 18, 2013, 11:50:02 PM4/18/13
to
On 18/04/13 22:32, Modestas Vainius wrote:
> Hello,
>
> On 2013 m. of April 18 d., Thursday 04:04:01 Julian wrote:
>> release cycle rigmarole even if obsolete by the time it comes out of
>> freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
>
> You know there are many people who do not care (or does not know) about
> version at all. All they care about is that stuff just works (tm).
>
*These* people don't care either way then? So its a moot point.
> Hello,
>
> On 2013 m. of April 18 d., Thursday 04:04:01 Julian wrote:
>> release cycle rigmarole even if obsolete by the time it comes out of
>> freeze and is burned to 100's of blurays...no one wants 4.8 anymore.
>
> You know there are many people who do not care (or does not know) about
> version at all. All they care about is that stuff just works (tm).
>
And why wouldn't it "just work"?
Its a high level application that runs on, what rightly should be, a
well tested lower (dependency) levels of a stable core (debian base).
So it has a lot to be thankful for when it comes to stability *out of
the box* or are you saying 4.10 doesn't "just work?".
You know whats really amazing? 4.10 "just works better" than 4.8.
It still builds against qt 4.7 and "works for me".
Of course everything I'm saying goes against the current philosophy of
debian, there's only variants of one level, and its all in for stable.
Regards.
Jules.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Modestas Vainius
Apr 20, 2013, 10:10:01 AM4/20/13
to
Hello,
On Friday 19 April 2013 13:48:04 Julian wrote:
> Its a high level application that runs on, what rightly should be, a
> well tested lower (dependency) levels of a stable core (debian base).
>
> So it has a lot to be thankful for when it comes to stability *out of
> the box* or are you saying 4.10 doesn't "just work?".
KDE (in a broad extent) is just too big to "just work" without any effort. You
probably have never tried to make it work and you have no idea what it takes
and how much time it eats.
If KDE was of a size of kcalc, I would agree with you. However, now it's 100
source packages and 2-3 times as many binary packages. On the architectural
side, it is complicated (akonadi, nepomuk, mysql, virtuoso, phonon and other N
number of daemons/framework/moving parts which have to 'play nice' and
integrate together).
> You know whats really amazing? 4.10 "just works better" than 4.8.
> It still builds against qt 4.7 and "works for me".
If you managed to build it, you are in the power user group already so "works
for you" is probably not the same as what "works for Joe Average" is.
> Of course everything I'm saying goes against the current philosophy of
> debian, there's only variants of one level, and its all in for stable.
There is a way to do this - backports. It is an official service as of wheezy.
However, I see the main problem here - noone is interested in actually doing
the necessary work and invest their days/weeks of time to make it reality.
Debian developers typically use unstable while stable or testing is already
good enough for less tech-savvy users or those who do not care about versions.
Backporting a single package is one thing, backporting 100 tightly related
source packages is another. And it's more than 100 times harder.
On Friday 19 April 2013 13:48:04 Julian wrote:
> Its a high level application that runs on, what rightly should be, a
> well tested lower (dependency) levels of a stable core (debian base).
>
> So it has a lot to be thankful for when it comes to stability *out of
> the box* or are you saying 4.10 doesn't "just work?".
probably have never tried to make it work and you have no idea what it takes
and how much time it eats.
If KDE was of a size of kcalc, I would agree with you. However, now it's 100
source packages and 2-3 times as many binary packages. On the architectural
side, it is complicated (akonadi, nepomuk, mysql, virtuoso, phonon and other N
number of daemons/framework/moving parts which have to 'play nice' and
integrate together).
> You know whats really amazing? 4.10 "just works better" than 4.8.
> It still builds against qt 4.7 and "works for me".
for you" is probably not the same as what "works for Joe Average" is.
> Of course everything I'm saying goes against the current philosophy of
> debian, there's only variants of one level, and its all in for stable.
However, I see the main problem here - noone is interested in actually doing
the necessary work and invest their days/weeks of time to make it reality.
Debian developers typically use unstable while stable or testing is already
good enough for less tech-savvy users or those who do not care about versions.
Backporting a single package is one thing, backporting 100 tightly related
source packages is another. And it's more than 100 times harder.
Nina Steiger
Apr 21, 2013, 9:20:01 AM4/21/13
to
Hello,
does anyone experience the same behaviour of kphotoalbum?
I updatet from wheezy over qt-experimental to experimental. I can start
kphotoalbum, but when I select Plugins (=kipi-plugins) or Settings->Configure
from the menu kphotoalbum crashes without any message (even when started from
the commandline). Kipi-plugins are available in digikam, gwenview and
ksnapshot.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/3979284.NgNx1H6Tn6@chronos
does anyone experience the same behaviour of kphotoalbum?
I updatet from wheezy over qt-experimental to experimental. I can start
kphotoalbum, but when I select Plugins (=kipi-plugins) or Settings->Configure
from the menu kphotoalbum crashes without any message (even when started from
the commandline). Kipi-plugins are available in digikam, gwenview and
ksnapshot.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Julian
Apr 22, 2013, 3:10:02 AM4/22/13
to
On 21/04/13 00:04, Modestas Vainius wrote:
>
> There is a way to do this - backports. It is an official service as of wheezy.
> However, I see the main problem here - noone is interested in actually doing
> the necessary work and invest their days/weeks of time to make it reality.
> Debian developers typically use unstable while stable or testing is already
> good enough for less tech-savvy users or those who do not care about versions.
>
> Backporting a single package is one thing, backporting 100 tightly related
> source packages is another. And it's more than 100 times harder.
Hi,
>
> There is a way to do this - backports. It is an official service as of wheezy.
> However, I see the main problem here - noone is interested in actually doing
> the necessary work and invest their days/weeks of time to make it reality.
> Debian developers typically use unstable while stable or testing is already
> good enough for less tech-savvy users or those who do not care about versions.
>
> Backporting a single package is one thing, backporting 100 tightly related
> source packages is another. And it's more than 100 times harder.
I actually understand this. But theses are, IMO, choices made, rather
than any restrictions in man power or tools available. Simply it should
be just "backports" from the beginning, but there is more to it.
There is a paradigm here, however I'm so far below the lowest rung of
the debian hierarchy is that all I can do is somehow allude to people
figuring it out for themselves. Because I know that saying "Give up
developing high level application packages for debians main release
cycles and give them their own repos and/or release cycles" won't get me
far.
Its a time cycle issue (speed). For example, user interactive
applications gain features, fix bugs, create bugs etc. They develop
differently. Critical System libraries and applications are more likely
to require a need to remain stable and have less (if any) drastic
changes to API's over a greater cycle.
I care about a stable Operating System, I care much less about the 1000s
of packages that run on top of it. To me debian is buried by it all (its
the bane of most distros).
In my spare time. I'm playing with some ideas on a build system, where,
roughly, suites (e.g. system, gnu base, misc apps, gnome, KDE),
including meta packages and sub packages - are all partitioned off.
i.e. <some_package>'s "system" dependency on version "2.14" for "glibc"
does not exist in the "stable" release suite for "system"". This is not
a build error, this is a failed package dependency attribute db entry.
Just adding another dimension to the build process. I hope someone else
does it before me so I can do other stuff. But I'm majorly enthusiastic
about it.
All the best for now.
Jules.
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/5174E009...@internode.on.net
--
To UNSUBSCRIBE, email to debian-kd...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages