Re: Versions mismatch and upload methodology for KDE applications

2022-11-12 Thread Martin Steigerwald
Luigi Toscano - 04.11.22, 21:58:58 CET:
> Shmerl ha scritto:
> > I noticed that versions of KDE applications in Debian repos are
> > all over the place. Examples:
> > 
> > kmail: 22.08.2
> > konsole: 22.08.1
> > okular: 22.04.3
> > and etc.
> > 
> > So method of uploading them seems random or ad hoc.
> > 
> > Why aren't KDE maintainers uploading the whole suite of
> > applications at once for all of them to have the same version?
> 
> I can't speak for the maintainers, but please consider that those
> programs are part of KDE Gear, which is just a collection of software
> which is released together, but it doesn't automatically imply a
> dependency between the various applications. There may be some (for
> example, all bits which mades KDE PIM) but that's not the general
> rule, so they can be updated separately.

Additionally the version numbers of all apps are updated on each KDE 
Gear release, no matter whether there have been changes to them.

That written for Okular for example I expect changes on every major KDE 
Gear release.

Also it can happen that for some reason a package needs to go through 
NEW again and approved by ftpmasters.

Thanks,
-- 
Martin




Re: Versions mismatch and upload methodology for KDE applications

2022-11-10 Thread Patrick Franz
Hej,

Am Freitag, 4. November 2022, 20:47:41 CET schrieb Shmerl:
> I noticed that versions of KDE applications in Debian repos are
> all over the place. Examples:
> 
> kmail: 22.08.2
> konsole: 22.08.1
> okular: 22.04.3
> and etc.
> 
> So method of uploading them seems random or ad hoc.
> 
> Why aren't KDE maintainers uploading the whole suite of
> applications at once for all of them to have the same version?

In short, lack of manpower.

We've automated the packaging of the Frameworks, Plasma and PIM for the 
most part, but Gear isn't quite there yet for various reasons.

If you're interested in getting everything up-to-date, feel free to join 
the effort.


-- 
Med vänliga hälsningar

Patrick Franz




Re: Versions mismatch and upload methodology for KDE applications

2022-11-04 Thread Shmerl
Yeah, I get that they don't always depend on each other,
but it's more about keeping them up to date in the repos.

I thought it might be easier to upload them all at once,
that's why I was asking about methodology of updating
them in Debian.

Shmerl.

On Fri, Nov 4, 2022 at 4:59 PM Luigi Toscano 
wrote:

> I can't speak for the maintainers, but please consider that those programs
> are
> part of KDE Gear, which is just a collection of software which is released
> together, but it doesn't automatically imply a dependency between the
> various
> applications. There may be some (for example, all bits which mades KDE PIM)
> but that's not the general rule, so they can be updated separately.
>


Re: Versions mismatch and upload methodology for KDE applications

2022-11-04 Thread Luigi Toscano
Shmerl ha scritto:
> I noticed that versions of KDE applications in Debian repos are
> all over the place. Examples:
> 
> kmail: 22.08.2
> konsole: 22.08.1
> okular: 22.04.3
> and etc.
> 
> So method of uploading them seems random or ad hoc.
> 
> Why aren't KDE maintainers uploading the whole suite of
> applications at once for all of them to have the same version?

I can't speak for the maintainers, but please consider that those programs are
part of KDE Gear, which is just a collection of software which is released
together, but it doesn't automatically imply a dependency between the various
applications. There may be some (for example, all bits which mades KDE PIM)
but that's not the general rule, so they can be updated separately.

-- 
Luigi



Versions mismatch and upload methodology for KDE applications

2022-11-04 Thread Shmerl
I noticed that versions of KDE applications in Debian repos are
all over the place. Examples:

kmail: 22.08.2
konsole: 22.08.1
okular: 22.04.3
and etc.

So method of uploading them seems random or ad hoc.

Why aren't KDE maintainers uploading the whole suite of
applications at once for all of them to have the same version?

Thanks!

Shmerl.


Re: Kind request to package kpart-webkit for modern Debian versions

2022-05-19 Thread ValdikSS

On 09.05.2022 23:29, Aurélien COUDERC wrote:

The package was removed from Debian for a specific reason : it's dependency on 
Qt4 :
https://tracker.debian.org/news/902784/removed-134-2-from-unstable/

Since it seems to have been ported to Qt5 / KF5 in the meantime I see no 
technical reason why it shouldn't be reintegrated into Debian.

However this is still a relatively niche use case and the Qt/KDE Team in Debian 
is generally more interested in on-boarding more contributors than more 
packages. 😉

So if you want to see it back I'd advise you fork the repo and start getting 
the package up to date with upstream and Debian standards, so we can review and 
upload your work to the archive. Feel free to join #debian-qt-kde on IRC and 
ask for help/review.


Could you clarify which upstream are you referring to? This package is a 
standard KDE package, not a third-party one.


https://invent.kde.org/libraries/kwebkitpart


OpenPGP_signature
Description: OpenPGP digital signature


Re: Kind request to package kpart-webkit for modern Debian versions

2022-05-09 Thread Aurélien COUDERC
[adding pkg-kde-talk@alioth-lists to the thread, where we discuss packaging 
topics]


Le 9 mai 2022 20:10:19 GMT+02:00, ValdikSS  a écrit :
>Hello, mailing list.

Hi ValdikSS,

>Is there any chance to get kpart-webkit package into newer Debian versions? 
>https://packages.debian.org/stretch/kpart-webkit
>
>This package allows to use Webkit renderer in Konqueror browser. This renderer 
>is outdated and not compatible with all the websites, however it is much 
>faster and lower on RAM consumption than modern WebEngine used by default. 
>This would allow to browse the web using very low-end machines by current 
>standards, such as 32-bit PCs with 512 MB RAM.
>
>Debian is basically the only major Linux distribution which still supports 
>i386, and there's Webkit packaged for Surf and Qutebrowser packages, and it's 
>even present as a module for KDE Frameworks (libkf5webkit5), but it can't be 
>used in Konqueror due to missing kpart.
>
>Kindly asking to bring old kpart-webkit package from Stretch to newer 
>Bullseye, to extent the lifespan of older hardware. Surf and QuteBrowser still 
>could be used, but that browsers are aimed at keyboard controls, not a regular 
>interface such as Konqueror.

The package was removed from Debian for a specific reason : it's dependency on 
Qt4 :
https://tracker.debian.org/news/902784/removed-134-2-from-unstable/

Since it seems to have been ported to Qt5 / KF5 in the meantime I see no 
technical reason why it shouldn't be reintegrated into Debian.

However this is still a relatively niche use case and the Qt/KDE Team in Debian 
is generally more interested in on-boarding more contributors than more 
packages. 😉

So if you want to see it back I'd advise you fork the repo and start getting 
the package up to date with upstream and Debian standards, so we can review and 
upload your work to the archive. Feel free to join #debian-qt-kde on IRC and 
ask for help/review.

>P.S. libkf5webkit5 package description says it provides kpart component, which 
>is does not. Could it be the whole reason of missing webkit in Konqueror?

The description is purely … hem … descriptive. I'll have a look at what's in 
the package and fix the description accordingly.


Happy hacking !
--
Aurélien



Kind request to package kpart-webkit for modern Debian versions

2022-05-09 Thread ValdikSS

Hello, mailing list.

Is there any chance to get kpart-webkit package into newer Debian 
versions? https://packages.debian.org/stretch/kpart-webkit


This package allows to use Webkit renderer in Konqueror browser. This 
renderer is outdated and not compatible with all the websites, however 
it is much faster and lower on RAM consumption than modern WebEngine 
used by default. This would allow to browse the web using very low-end 
machines by current standards, such as 32-bit PCs with 512 MB RAM.


Debian is basically the only major Linux distribution which still 
supports i386, and there's Webkit packaged for Surf and Qutebrowser 
packages, and it's even present as a module for KDE Frameworks 
(libkf5webkit5), but it can't be used in Konqueror due to missing kpart.


Kindly asking to bring old kpart-webkit package from Stretch to newer 
Bullseye, to extent the lifespan of older hardware. Surf and QuteBrowser 
still could be used, but that browsers are aimed at keyboard controls, 
not a regular interface such as Konqueror.


P.S. libkf5webkit5 package description says it provides kpart component, 
which is does not. Could it be the whole reason of missing webkit in 
Konqueror?


OpenPGP_signature
Description: OpenPGP digital signature


Info on versions for me

2018-09-28 Thread Eric Valette

  
  
Just to add my config : Linux : debian unstable
=> kdeconnect 1.3.1 (all tested linuxes) and two mobiles
tested : android Oreo (8.1.0) 1.8.x and even tested beta
    versions 1.9, and android nougat 7.1.x  kdeconnect 1.8.x from
play store.
  

  
-- eric

  




Re: Up to date information on plasma versions in testing?

2016-10-22 Thread Sami Erjomaa
On 22 October 2016 at 13:45, Shawn Sörbom wrote:

> Hi folks,
> Just wondering where one can find up to date information on the plasma
> versions currently in stretch? the obvious answer would be to check
> individual
> packages of course, but I find that they often have confusing (and
> conflicting) version numbers. Is a package like Kwin a good overall
> progress
> indicator for the state of which version is (mostly) being used?
> Thanks,
> --Shawn
>
>
This page has all the packages and their versions in different releases
maintained by the qt-kde team

https://qa.debian.org/developer.php?login=debian-qt-...@lists.debian.org

-- 
Sami Erjomaa


Up to date information on plasma versions in testing?

2016-10-22 Thread Shawn Sörbom
Hi folks,
Just wondering where one can find up to date information on the plasma 
versions currently in stretch? the obvious answer would be to check individual 
packages of course, but I find that they often have confusing (and 
conflicting) version numbers. Is a package like Kwin a good overall progress 
indicator for the state of which version is (mostly) being used?
Thanks,
--Shawn



Re: Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Diederik de Haas
On Friday 19 July 2013 12:59:25 Pino Toscano wrote:
> If you really want deb-multimedia in your repositories (which I do not
> recommend), then you should better use apt's pinning to give to the
> suites of this repository priorities lower than the ones for the main
> archive (this implies also raising the priority for experimental to
> more than 100, if you use it).

And that was the key to solving my issue (experimental is now at 150) :-)
And I also took your suggestions about the other versions available and now 
the only package I have from deb-multimedia is libdvdcss2 (which I guess is 
still needed to watch dvds).

Dunno how I kept having these brainfarts, but I'm glad it's now solved.

Thanks!

PS: My command to get non-debian packages is this:
aptitude search '?narrow(~i, !?origin(debian))'
and if you want to paste the output in a mail, you could append  
-F '%c%2M%p%v'

-- 
GPG: 0x138E41915C7EFED6

signature.asc
Description: This is a digitally signed message part.


Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Pino Toscano
Alle venerdì 19 luglio 2013, Diederik de Haas ha scritto:
> On Friday 19 July 2013 12:18:19 Pino Toscano wrote:
> > Ok then; just to tule out any other deb-multimedia issue, could you
> > please check the output of
> > $ dpkg -l '*' | grep ^ii | grep -- -dmo
> 
> $ dpkg -l '*' | grep ^ii | grep -- -dmo
> ii  handbrake-cli 0.9.9-dmo3
> ii  handbrake-gtk 0.9.9-dmo3
> ii  mencoder  3:1.1.1-dmo4

These exist in sid/experimental, although slightly older.

> ii  lame  1:3.99.5-dmo2
> ii  libmp3lame0:amd64 1:3.99.5-dmo2
> ii  libtag1-vanilla:amd64 1.8-dmo1
> ii  libtag1c2a:amd64  1.8-dmo1

These exist in sid, and should better use them from there instead of
deb-multimedia.

> ii  libdvdcss2:amd64  1.2.13-dmo1
> ii  libfaac0:amd641:1.28-dmo3
> ii  libx264-135:amd64 3:0.135.2345+gitf0c1c53-dmo1
> ii  libxvidcore4:amd643:1.3.2-dmo1

> > ? I was able to install right now libavutil52 aside libavutil51 on
> > a current testing/jessie installation, so if there is a conflict
> > it would be indirect.
> 
> Can you tell me which versions of those libraries you installed?

libavutil52 from experimental, of course.

> $ aptitude -s install libavutil52
> The following packages will be upgraded:
>   libavutil52{b}
> 1 packages upgraded, 0 newly installed, 0 to remove and 1 not
> upgraded. Need to get 102 kB of archives. After unpacking 16.4 kB
> will be used. The following packages have unmet dependencies:
>  libavutil52 : Conflicts: libavutil-extra-51 which is a virtual
> package.

This conflict exists *only* in the libavutil52 provided in
deb-multimedia.

If you really want deb-multimedia in your repositories (which I do not
recommend), then you should better use apt's pinning to give to the
suites of this repository priorities lower than the ones for the main
archive (this implies also raising the priority for experimental to
more than 100, if you use it).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


Re: Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Diederik de Haas
On Friday 19 July 2013 12:18:19 Pino Toscano wrote:
> Ok then; just to tule out any other deb-multimedia issue, could you 
> please check the output of
> $ dpkg -l '*' | grep ^ii | grep -- -dmo

$ dpkg -l '*' | grep ^ii | grep -- -dmo
ii  handbrake-cli 0.9.9-dmo3amd64   
 
ii  handbrake-gtk 0.9.9-dmo3amd64   
 
ii  lame  1:3.99.5-dmo2 amd64   
 
ii  libdvdcss2:amd64  1.2.13-dmo1   amd64   
 
ii  libfaac0:amd641:1.28-dmo3   amd64   
 
ii  libmp3lame0:amd64 1:3.99.5-dmo2 amd64   
 
ii  libtag1-vanilla:amd64 1.8-dmo1  amd64   
 
ii  libtag1c2a:amd64  1.8-dmo1  amd64   
 
ii  libx264-135:amd64 3:0.135.2345+gitf0c1c53-dmo1  amd64   
 
ii  libxvidcore4:amd643:1.3.2-dmo1  amd64   
 
ii  mencoder  3:1.1.1-dmo4  amd64   
 


> ? I was able to install right now libavutil52 aside libavutil51 on a 
> current testing/jessie installation, so if there is a conflict it would 
> be indirect.

Can you tell me which versions of those libraries you installed?

$ aptitude versions libavutil52
Package libavutil52:
i A 6:9.7-1100 
p A 6:9.8-1  experimental  101 
p A 9:1.2.1-dmo6 unstable  101

$ aptitude versions libavutil51
Package libavutil51:
i A 6:0.8.7-1testing,unstable  500 
p A 8:1.0.7-dmo1 unstable  101

$ aptitude -s install libavutil52
The following packages will be upgraded: 
  libavutil52{b} 
1 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 102 kB of archives. After unpacking 16.4 kB will be used.
The following packages have unmet dependencies:
 libavutil52 : Conflicts: libavutil-extra-51 which is a virtual package.

libavutil-extra-51 is provided by libavutil51

-- 
GPG: 0x138E41915C7EFED6

signature.asc
Description: This is a digitally signed message part.


Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Pino Toscano
Alle venerdì 19 luglio 2013, Diederik de Haas ha scritto:
> On Friday 19 July 2013 11:41:52 Pino Toscano wrote:
> > libavutil52 exists only in experimental... and in deb-multimedia,
> > and also vlc does. This means you are using vlc from
> > deb-multimedia,
> 
> No, I'm not using vlc from deb-multimedia (I do have other programs
> like handbrake from deb-multimedia though).

Ok then; just to tule out any other deb-multimedia issue, could you 
please check the output of
$ dpkg -l '*' | grep ^ii | grep -- -dmo
? I was able to install right now libavutil52 aside libavutil51 on a 
current testing/jessie installation, so if there is a conflict it would 
be indirect.

> I would be happy to remove all vlc packages from my system, but
> phonon-backend-vlc needs it. For video I use SMPlayer and for audio
> Amarok, so I have no need for vlc.

No need to.

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


Re: Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Diederik de Haas
On Friday 19 July 2013 11:41:52 Pino Toscano wrote:
> libavutil52 exists only in experimental... and in deb-multimedia, and 
> also vlc does. This means you are using vlc from deb-multimedia, 

No, I'm not using vlc from deb-multimedia (I do have other programs like 
handbrake from deb-multimedia though).

$ aptitude versions ~ivlc
Package libvlc5:  
i   2.0.7-3  testing,unstable 500 
  
Package libvlccore5:
i   2.0.7-3  testing,unstable 500 

Package phonon-backend-vlc:
i   0.6.2-2  testing,unstable 500 

Package vlc-data:
i   2.0.7-3  testing,unstable 500 

Package vlc-nox:
i   2.0.7-3  testing,unstable 500


I would be happy to remove all vlc packages from my system, but phonon-
backend-vlc needs it. For video I use SMPlayer and for audio Amarok, so I have 
no need for vlc.

-- 
GPG: 0x138E41915C7EFED6

signature.asc
Description: This is a digitally signed message part.


Re: nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Pino Toscano
Hi,

Alle venerdì 19 luglio 2013, Diederik de Haas ha scritto:
> For about a week now, the upgrade of libavutil52 and libswscale2 is
> held back because the latest version of libavutil52 conflicts with
> libavutil51, which is required by nepomuk-core-runtime. The
> libavutil52 library is needed by vlc- nox, which is needed by
> phonon-backend-vlc.

libavutil52 exists only in experimental... and in deb-multimedia, and 
also vlc does. This means you are using vlc from deb-multimedia, meaning 
your phonon-backend-vlc could break anytime because of that (it did 
various times in the past), or that you get dependencies issues like 
this.

You are strongly recommended to *not* use deb-multimedia for this kind 
of packages (libav, vlc), since they are more harmful than useful (as 
Marillat does not care about being compatibile with Debian's archive).

-- 
Pino Toscano


signature.asc
Description: This is a digitally signed message part.


nepomuk-core-runtime 'prevents' upgrade of libavutil52 to versions 9.8-1

2013-07-19 Thread Diederik de Haas
Hi,

For about a week now, the upgrade of libavutil52 and libswscale2 is held back 
because the latest version of libavutil52 conflicts with libavutil51, which is 
required by nepomuk-core-runtime. The libavutil52 library is needed by vlc-
nox, which is needed by phonon-backend-vlc.
The resolution aptitude is offering is basically installing all KDE packages, 
which is of course not what I want.

I *think* that changing the dependency of nepomuk-core-runtime to "libavutil51 
| libavutil52" would solve this dependency issue, but I don't know if 
libavutil52 is 'compatible' (or sth like that) with nepomuk-core-runtime.

It's not a critical issue or sth and running sid/experimental these things are 
expected to happen from time to time, but I guess reporting it (to the ML) 
wouldn't hurt ;-)

Cheers,
  Diederik

-- 
GPG: 0x138E41915C7EFED6

signature.asc
Description: This is a digitally signed message part.


Re: How does Konqueror detect flash versions?

2011-01-20 Thread David Goodenough
On Thursday 20 January 2011, Kevin Krammer wrote:
> On Thursday, 2011-01-20, David Goodenough wrote:
> > I am having endless problems running flash (in particular BBC IPlayer).
> > I have the normal flashplayer-plugin installed from sid (from a few weeks
> > ago) and as I recall that installed flash player 10 (.? I do not
> > remember).
> > 
> > The IPlayer page I hit this morning gave some more information, it said:-
> > 
> > This content requires Flash Player version 9 (installed version: 7.0.25)
> > 
> > which made me think that perhaps I have an old version installed
> > somewhere, and it is finding the wrong one.  Any idea how I might track
> > down the 7.0.25 that it is finding so that I can terminate it with
> > extreme prejudice.
> 
> Settings -> Configure Konqueror -> Plugins
> second tab shows a list of paths searched for plugins and below that the
> ones it found.
> 
> Cheers,
> Kevin
thanks that enabled me to find it and kill the miscreant.  Now IPlayer works
as expected.

David


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201101201238.18123.david.goodeno...@btconnect.com



Re: How does Konqueror detect flash versions?

2011-01-20 Thread Kevin Krammer
On Thursday, 2011-01-20, David Goodenough wrote:
> I am having endless problems running flash (in particular BBC IPlayer).
> I have the normal flashplayer-plugin installed from sid (from a few weeks
> ago) and as I recall that installed flash player 10 (.? I do not remember).
> 
> The IPlayer page I hit this morning gave some more information, it said:-
> 
> This content requires Flash Player version 9 (installed version: 7.0.25)
> 
> which made me think that perhaps I have an old version installed
> somewhere, and it is finding the wrong one.  Any idea how I might track
> down the 7.0.25 that it is finding so that I can terminate it with
> extreme prejudice.

Settings -> Configure Konqueror -> Plugins
second tab shows a list of paths searched for plugins and below that the ones 
it found.

Cheers,
Kevin


signature.asc
Description: This is a digitally signed message part.


How does Konqueror detect flash versions?

2011-01-20 Thread David Goodenough
I am having endless problems running flash (in particular BBC IPlayer).
I have the normal flashplayer-plugin installed from sid (from a few weeks
ago) and as I recall that installed flash player 10 (.? I do not remember).

The IPlayer page I hit this morning gave some more information, it said:-

This content requires Flash Player version 9 (installed version: 7.0.25)

which made me think that perhaps I have an old version installed 
somewhere, and it is finding the wrong one.  Any idea how I might track
down the 7.0.25 that it is finding so that I can terminate it with 
extreme prejudice.  

This is machine that I have been running for some years, and it might
have picked up manner of cruft over the years.

David


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201101201126.16276.david.goodeno...@btconnect.com



Re: Development Versions of KDE 4.3 and Friends?

2009-07-02 Thread Jonathan Yu
Sune:

Thanks, yeah, I am just trying my best to avoid building from source.
It looks like I have no choice though :(

Cheers,

Jonathan

On Thu, Jul 2, 2009 at 7:27 PM, Sune Vuorela wrote:
> On 2009-07-02, Jonathan Yu  wrote:
>> Hi all:
>>
>> I'm working on a summer project for Debian which involves KDE4.3 and
>> its bindings. Right now because of Sune Vuorela's projected release
>> schedule, I'm looking at compiling the necessary stuff from source.
>> But, especially looking at how long the buildds are taking to compile
>> previous KDE versions (4+ hours!) I was wondering if anyone might have
>> a repository containing experimental KDE4.3-related packages.
>
> Also for the sake of your project, you need to compile smoke yourself.
> You can probably even just compile qt smoke by passing the right
> arguments to cmake.
>
> /Sune
>
>
> --
> To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Development Versions of KDE 4.3 and Friends?

2009-07-02 Thread Sune Vuorela
On 2009-07-02, Jonathan Yu  wrote:
> Hi all:
>
> I'm working on a summer project for Debian which involves KDE4.3 and
> its bindings. Right now because of Sune Vuorela's projected release
> schedule, I'm looking at compiling the necessary stuff from source.
> But, especially looking at how long the buildds are taking to compile
> previous KDE versions (4+ hours!) I was wondering if anyone might have
> a repository containing experimental KDE4.3-related packages.

Also for the sake of your project, you need to compile smoke yourself.
You can probably even just compile qt smoke by passing the right
arguments to cmake.

/Sune


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Development Versions of KDE 4.3 and Friends?

2009-07-02 Thread Modestas Vainius
Hello,

On 2009 m. July 2 d., Thursday 23:52:48 anna wrote:
> http://www.kubuntu.org/
>
> KDE 4.3 RC 1 Available
> Submitted on Thu, 2009-07-02
>
> from a ppa though ...

Please keep kubuntu and especially ppa stuff out of this list. Gives wrong 
impression that it is installable/usable on Debian. It isn't.

-- 
Modestas Vainius 


signature.asc
Description: This is a digitally signed message part.


Re: Development Versions of KDE 4.3 and Friends?

2009-07-02 Thread anna

http://www.kubuntu.org/

KDE 4.3 RC 1 Available
Submitted on Thu, 2009-07-02

from a ppa though ...

> Hi all:
>
> I'm working on a summer project for Debian which involves KDE4.3 and
> its bindings. Right now because of Sune Vuorela's projected release
> schedule, I'm looking at compiling the necessary stuff from source.
> But, especially looking at how long the buildds are taking to compile
> previous KDE versions (4+ hours!) I was wondering if anyone might have
> a repository containing experimental KDE4.3-related packages.
>
> In particular, the project I'm working on doesn't have a Debian
> package yet either, so I need to compile from source. It builds
> properly on Ubuntu, but not Debian, because the version of
> libsmokeqt4-2 in Debian is too old.
>
> Thanks in advance!
>
> Cheers,
>
> Jonathan


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Development Versions of KDE 4.3 and Friends?

2009-07-02 Thread Jonathan Yu
Hi all:

I'm working on a summer project for Debian which involves KDE4.3 and
its bindings. Right now because of Sune Vuorela's projected release
schedule, I'm looking at compiling the necessary stuff from source.
But, especially looking at how long the buildds are taking to compile
previous KDE versions (4+ hours!) I was wondering if anyone might have
a repository containing experimental KDE4.3-related packages.

In particular, the project I'm working on doesn't have a Debian
package yet either, so I need to compile from source. It builds
properly on Ubuntu, but not Debian, because the version of
libsmokeqt4-2 in Debian is too old.

Thanks in advance!

Cheers,

Jonathan


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Info about KDE versions in unstable, testing...

2009-05-22 Thread Ana Guerrero
On Thu, May 21, 2009 at 01:37:32PM +0200, Tadeas Moravec wrote:
...

> I imagine it like this.
> There will be a message - in the FAQ section for example or on the main page 
> on
> http://pkg-kde.alioth.debian.org/ in which something like this will be:
> "We are currently working on getting XYZ version to get into unstable. It's
> almost ready, we are just waiting for package ABC to be packaged and bug DEF 
> to
> be solved. It will probably happen tomorrow in the evening, so you can look
> forward to having KDE version XYZ in unstable the day after tomorrow or the 
> day
> after that.
> The current version BLAH in unstable is waiting for bugs 1,2,3,4 and 5 to be
> solved. One of them is solved in experimental and more two are solved 
> upstream,
> so we need just to get these fixes to unstable first. After this will happen,
> version BLAH will migrate to testing."


That would be possible if we usually have a clear plan of how (and when) are 
going to be things done, but that is almost never that way. Some stuff does 
not depend on us and even about of the stuff that depends on our work can not
be scheduled. You can plan doing foo in some evening but then you get 
something better to do. You do not have this not even in companies were you
pay

And no, we are not going to twitter or something like that, if you are so 
interested in the development, you will have to follow the development as it 
happens (mailing lists, IRC, commit messages), the developers are not going 
to follow you.

Ana


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Info about KDE versions in unstable, testing...

2009-05-21 Thread Tadeas Moravec
Hello,
thank for the reply.

I probably didn't express myself correctly. I wasn't inquiring about  the actual
versions nor about what's preventing new from getting to Debian at the moment,
but I suggest putting this info on the web. Yes, we can ask here or on IRC, but
there's probably a lot of people who don't use IRC nor write to this mailing
list - who would like to know too. Moreover personally I'm eager to get 4.2.3 to
unstable because of some fixes - but I really don't want to bother others on IRC
or here every day inquiring about what's holding 4.2.3 from unstable, so it
would be great if this updated info was on the web.

I agree about the point of 4.2.4 - but if this was already settled on, why don't
we write it somewhere everybody can read it?

I imagine it like this.
There will be a message - in the FAQ section for example or on the main page on
http://pkg-kde.alioth.debian.org/ in which something like this will be:
"We are currently working on getting XYZ version to get into unstable. It's
almost ready, we are just waiting for package ABC to be packaged and bug DEF to
be solved. It will probably happen tomorrow in the evening, so you can look
forward to having KDE version XYZ in unstable the day after tomorrow or the day
after that.
The current version BLAH in unstable is waiting for bugs 1,2,3,4 and 5 to be
solved. One of them is solved in experimental and more two are solved upstream,
so we need just to get these fixes to unstable first. After this will happen,
version BLAH will migrate to testing."
# >  Původní zpráva 
# > Od: Modestas Vainius 
# > Předmět: Re: Info about KDE versions in unstable, testing...
# > Datum: 21.5.2009 12:31:09
# > 
# > Hello,
# >
# > On 2009 m. May 21 d., Thursday 13:12:49 Tadeas Moravec wrote:
# > > important, some info about when a new version will come, what must be done
# > > before say 4.3 beta will be in experimental
# > It must be packaged (MUCH (really) work, somewhat low interest recently).
# >
# > > or 4.2.3 in unstable and so? I
# > 4.2.4 is coming in a bit more than a week. 4.2.3 is not much better than 
4.2.2
#
# > so skipping 4.2.3 does not seem to be a very bad idea.
# >
# > > mean some information about the process of getting a new version to
# > > unstable or experimental and also some information about the current 
status
# > > of the version in unstable - what prevents it from getting to testing.
# > 4.2.2 is in testing.
# >
# > > What do you think? Would that be too much additional work for the
# > > developers?
# > When you want more info about the process, you just ask here or hang in the
# > respective IRC channels.
# >
# > --
# > Modestas Vainius 
# >
# >
# >
#


--
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Info about KDE versions in unstable, testing...

2009-05-21 Thread jedd
On Thursday 21 May 2009, Modestas Vainius wrote:
> It must be packaged (MUCH (really) work, somewhat low interest
> recently).

 Yeah, the downside of a large distro trying to support so many
 platforms, and KDE being pretty mammoth. Everything I've
 said elsewhere about the quality of the KDE4 suite per se
 aside, the work that goes into this is known to be huge, and
 is very much appreciated.

> 4.2.4 is coming in a bit more than a week. 4.2.3 is not much better
> than 4.2.2 so skipping 4.2.3 does not seem to be a very bad idea.

 I think the KDE dot releases are meant to be every month, was that 
 right?  I think I'd be happy with jumping every second release like
 that - as much as I'd love to get bug fixes and new (well, recover
 the 3.5) features as fast as possible.

 Do you expect that a two monthly, or every second dot release, is
 about the pace that will be settled on?

 Jedd.



-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: Info about KDE versions in unstable, testing...

2009-05-21 Thread Modestas Vainius
Hello,

On 2009 m. May 21 d., Thursday 13:12:49 Tadeas Moravec wrote:
> important, some info about when a new version will come, what must be done
> before say 4.3 beta will be in experimental
It must be packaged (MUCH (really) work, somewhat low interest recently).

> or 4.2.3 in unstable and so? I
4.2.4 is coming in a bit more than a week. 4.2.3 is not much better than 4.2.2 
so skipping 4.2.3 does not seem to be a very bad idea.

> mean some information about the process of getting a new version to
> unstable or experimental and also some information about the current status
> of the version in unstable - what prevents it from getting to testing.
4.2.2 is in testing.

> What do you think? Would that be too much additional work for the
> developers?
When you want more info about the process, you just ask here or hang in the 
respective IRC channels.

-- 
Modestas Vainius 


signature.asc
Description: This is a digitally signed message part.


Info about KDE versions in unstable, testing...

2009-05-21 Thread Tadeas Moravec
Hello,
this is just an idea. 
What about to put some info about KDE versions in different Debian versions on 
KDE maintainers website (currently there is no information whether is 4.2.0, 
4.2.1, 4.2.2 or 4.2.3 in testing and unstable) and what's more important, some 
info about when a new version will come, what must be done before say 4.3 beta 
will be in experimental or 4.2.3 in unstable and so? I mean some information 
about the process of getting a new version to unstable or experimental and also 
some information about the current status of the version in unstable - what 
prevents it from getting to testing.

What do you think? Would that be too much additional work for the developers?


-- 
To UNSUBSCRIBE, email to debian-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Fixing problems with conflicting package versions (was: Re: kde error (here is the output)

2007-09-07 Thread Martin Steigerwald
Am Freitag 07 September 2007 schrieb George Adamides:
> Hello again and thank you for the propmt reply! Here's the output

Hello George!

Two things first:

1) Please reply to my message instead of opening a new thread by writing a 
new mail.

2) Please use proper quoting: http://learn.to/quote

> george:~#cat /etc/debian_version
> 3.1

You have Debian Sarge. Well at least the base files of it, no guarentee 
that all packages are from Debian Sarge tough...

> #cat /etc/apt/sources.list
> #deb file:///cdrom/ sarge main
> deb http://ftp.fi.debian.org/debian/ stable main
> deb-src http://ftp.fi.debian.org/debian/ stable main
> deb http://security.debian.org/ stable/updates main
> deb http://dotdeb.pimpmylinux.org/ stable all
> deb-src http://dotdeb.pimpmylinux.org/ stable all

But since quite some months Etch has been released as stable - thus your 
sources.list entries with "stable" do not refer to "sarge", but now 
to "etch"! Did you update your system in the meanwhile? Then you may have 
a mixture between Sarge and Etch! While it is possible to mix different 
versions of Debian, I would not recommend it to a novice.

I recommend explicetily putting sarge or etch into /etc/apt/sources.list, 
cause stable will point to a new Debian versions once it gets released. 
The next one is lenny.

But see below for detailed suggestions on how to fix your conflicting 
package versions.

> george:~# apt-cache policy kdat
> kdat:
>   Installed: 4:3.5.7-1
>   Candidate: 4:3.5.7-1
>   Version Table:
>  *** 4:3.5.7-1 0
> 100 /var/lib/dpkg/status
>  4:3.5.5-4 0
> 500 http://ftp.fi.debian.org stable/main Packages
>
> I hope this helps.

Ok, lets try to make a plan to get it fixed:

1) aptitude purge kdat or if aptitude wants to remove other packages that 
you think shouldn't be removed apt-get purge kdat instead

2) You seem to have basefiles of Debian Sarge at least, so replace any 
occurence of "stable" in your /etc/apt/sources.list by "sarge" for now.

3) Lets find out whether you have some packages that are newer than sarge. 
Install apt-show-versions

aptitude install apt-show-versions

And post the output of:

apt-show-versions | grep "/sarge" | wc -l
apt-show-versions | grep "/etch" | wc -l
apt-show-versions | grep "/lenny" | wc-l
apt-show-versions | grep "/sid" | wc -l

It will show the numbers of installed packages from the different Debian 
versions. For a pure Debian Sarge it should be lots of packages for 
Sarge, but none for Etch, Lenny or Sid. Then you use "sarge" 
in /etc/apt/sources.list. You may upgrade to Etch later - I recommend 
this, especially since KDE 3.5.5 is quite an improvement over KDE 
3.3.2 ;-). But for now it is enough to use Sarge to get kdat running.

If you already have lots of packages for Etch, I would consider upgrading 
to Etch completely to have consistent package versions again. Then you 
would use "etch" or "stable" in /etc/apt/sources.list. I recommend Etch, 
cause stable will change to Lenny silently, once it is released. You 
would need to do an upgrade with aptitude / apt-get upgrade / 
dist-upgrade, but read the Debian upgrade notes and be careful if you are 
novice with Debian package management. Always check whether the output of 
aptitude or apt-get makes sense to you before letting it go.

If you only have a few packages for Etch, you may try to downgrade them.

Well if that mixture of packages work for you, you can even go on with 
that, but for a beginning I recommend to you not to run packages from 
different Debian versions together.

4) Once you have a Debian system consistent package versions, you can 
install KDE, X, kdat as explained before.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


signature.asc
Description: This is a digitally signed message part.


Konqueror and ACLs: difference between SuSE and Debian, between 3.5.x versions?

2006-07-25 Thread Adrian von Bidder
Yodel!

[cc:s appreciated]

We're facing a problem here with konquerors acl behaviour:

changing from SuSE's 3.4.something to Debian backport 3.5.0 or also 
http://deb.stosberg.net/'s 3.5.3 backports, acl behaviour on file copying 
has annoyingly changed to also copy the acl.  Old (and "correct" - at least 
for our use) behaviour was that the target file would get the default acl 
of the target directory.

Anybody knows where that was changed?  Can I influence this, if possible 
without recompiling KDE?

As a data point, note that interestingly enough the 3.5.x pakages from SuSE 
10.1 retained the old behaviour, so this is either a change which came in a 
KDE point release, or is a Debian or SuSE specific modification.

(Rationale: we use some directories as mailboxes: people would copy their 
files into these directories to publish them for some other people.  
Educating people that they need to copy the files, not move them, was 
possible.  Educating them to set the correct acl is IME not possible - 
users just want to work, they don't want and need to know about how the ACL 
system works.)

thanks in advance
-- vbi

-- 
Sterility is inherited. If your parents never had kids, odds are you
wont either.
-- William R. James in news.admin.net-abuse.email


pgpUQxjznuaSA.pgp
Description: PGP signature


Re: List of available KDE3 Debian packages with versions

2002-09-24 Thread Ralf Nolden
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Dienstag, 24. September 2002 21:48, Tamas Nagy wrote:

Hi,

thanks for the list !! We were already searching for available debs and for 
apps where we want to make debs for.  The idea is to upload them to 
ftp://upload.kde.org so they can be sorted into the list of apps and provide 
a deb source for people having KDE, so only one sources.list line would last 
to retrieve everything that's available for debian (which makes it *much* 
easier to look up a program in the end, and the KDE mirrors and traffic is 
there anyway).

If you like to participate, just upload your deb and the according source to 
ftp://upload.kde.org.

Thanks,

Ralf


> http://mypage.bluewin.ch/kde3-debian/3.0.3/packages.html
> http://mypage.bluewin.ch/kde3-debian/3.1/packages.html (beta1)
>
> Since we have a bunch of active packagers and apt-sources, many people
> might be confused about the latest/actual/working versions of
> KDE3.0.3/3.1beta1 packages available for Debian.
>
> Recently I compiled a -not complete- list, but enough for an average
> user. This list could be handy to answer these type of questions, and
> prevent others like, "Is xyz package available for KDE3.x.y?"
>
> Again, if you know any other existing package, I will gladly update this
> list...
>
> Enjoy,
> Tamas
>
> PS: I plan to update another script, to help to mirror these packages
> locally, allow people in local communities to distribute the packages,
> and reduce the traffic on original sites...

- -- 
We're not a company, we just produce better code at less costs.
- 
Ralf Nolden
[EMAIL PROTECTED]

The K Desktop Environment   The KDevelop Project
http://www.kde.org  http://www.kdevelop.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9kNVCu0nKi+w1Ky8RAh4qAJ42Jv4niji/pfCdL0qXdNEbEjtFMgCgopYI
oVxwNOd/Np1VvN5FlMbTz+A=
=DN9W
-END PGP SIGNATURE-




List of available KDE3 Debian packages with versions

2002-09-24 Thread Tamas Nagy
http://mypage.bluewin.ch/kde3-debian/3.0.3/packages.html
http://mypage.bluewin.ch/kde3-debian/3.1/packages.html (beta1)

Since we have a bunch of active packagers and apt-sources, many people
might be confused about the latest/actual/working versions of
KDE3.0.3/3.1beta1 packages available for Debian.

Recently I compiled a -not complete- list, but enough for an average
user. This list could be handy to answer these type of questions, and
prevent others like, "Is xyz package available for KDE3.x.y?"

Again, if you know any other existing package, I will gladly update this
list...

Enjoy,
Tamas

PS: I plan to update another script, to help to mirror these packages
locally, allow people in local communities to distribute the packages,
and reduce the traffic on original sites...




Re: versions

2002-01-29 Thread Hendrik Naumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

> > Is it possible to run KDE with Potoato (2.2 r0)? If so, where
> > should I go for information?

Yes. KDE 2.1.2

Have a look at
http://kde.debian.net/

I currently use the mirror

deb ftp://ftp.wh9.tu-dresden.de/pub/linux/debian-stuff/KDE2 potato\ 
main crypto optional


> There are some REALLY outdated packages that Ivan compiled for
> Potato at kde.debian.net, but they are far from official.. so your
> milage may vary. If you can, I would suggest upgrading to Woody or
> Sid.

They run verry good and stable. 

Hendrik
- -- 
PGP ID 21F0AC0265C92061
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Vrh5IfCsAmXJIGERAnwiAJ0XS/Us1wBa1d/WoUg/o4GPWjhBTACfclal
b23DaeTw/6eq7Fiy5V6TbDA=
=6KZ3
-END PGP SIGNATURE-




Re: versions

2002-01-29 Thread Kamil Kisiel
On Tue, Jan 29, 2002 at 05:44:44PM +1100, Ray Wells <[EMAIL PROTECTED]> wrote:
> Hi All,
> 
> Just new to the sig so hope this is not out of place.
> 
> Since subscribing I've noticed lots of mail re KDE with Woody and Sid but no 
> mention of Potato, the version of 
> Debian I run here for my amateur radio BBS.
> 
> Is it possible to run KDE with Potoato (2.2 r0)? If so, where should I go for 
> information?
> 
> The aim is to attempt to run LinkT which requires KDE.
> 
> TIA
> 
> Ray Wells VK2TV
> 

There are some REALLY outdated packages that Ivan compiled for Potato at
kde.debian.net, but they are far from official.. so your milage may
vary. If you can, I would suggest upgrading to Woody or Sid.




versions

2002-01-29 Thread Ray Wells
Hi All,

Just new to the sig so hope this is not out of place.

Since subscribing I've noticed lots of mail re KDE with Woody and Sid but no 
mention of Potato, the version of 
Debian I run here for my amateur radio BBS.

Is it possible to run KDE with Potoato (2.2 r0)? If so, where should I go for 
information?

The aim is to attempt to run LinkT which requires KDE.

TIA

Ray Wells VK2TV






SOLVED: Re: Packages with multiple versions in kde.tdyc.com?

2001-02-10 Thread Rogerio Brito
On Feb 10 2001, Ivan E. Moore II wrote:
> u
> 
> there is only 1 copy of noatun in the beta section on kde.tdyc.com. And as
> far as I can tell there are no duplicates...my Package builder would warn
> me about dups.

I went on to read my local mirroring scripts after reading
your message and I found a bug: the script that takes care of
the beta section (which I'm mirroring with rsync) didn't have
the "--delete" option.

Thank you very much for the hint, Ivan.


[]s, Roger...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




Re: Packages with multiple versions in kde.tdyc.com?

2001-02-10 Thread Ivan E. Moore II
>   I'd like to make a request. I've noticed that the mirror of
>   KDE that I'm maintaining locally has many packages with
>   multiple versions and I'm more or less limited in space. For
>   instance, in the beta section of the mirror, some packages are
>   even present with 4 versions (one such example is noatun).
> 
>   So, I'd like to ask Ivan or the people responsible for the
>   kde.tdyc.com repository if it would be possible to remove
>   these files during the next update of the server.

u

there is only 1 copy of noatun in the beta section on kde.tdyc.com. And as
far as I can tell there are no duplicates...my Package builder would warn
me about dups.

Ivan

-- 

Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD




Packages with multiple versions in kde.tdyc.com?

2001-02-10 Thread Rogerio Brito

Hi there.

I'd like to make a request. I've noticed that the mirror of
KDE that I'm maintaining locally has many packages with
    multiple versions and I'm more or less limited in space. For
instance, in the beta section of the mirror, some packages are
even present with 4 versions (one such example is noatun).

So, I'd like to ask Ivan or the people responsible for the
kde.tdyc.com repository if it would be possible to remove
these files during the next update of the server.


Thank you very much for your attention, Roger...

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=




Re: Packages from different versions at the same time

2000-12-15 Thread Ivan E. Moore II
>  I have been updating a couple of machines at my work from kde 1.1.2 to kde 
> 2.0.1 in potato this morning. I find that some packages which should conflict 
> among them appear twice resulting in different size icons o duplicate icons 
> in the desktop and K menu.
> 
>  For example the system has 
> 
> kdetoys 4:1.1.2 and task-kdetoys 4:2.0.1 at the same time

task-kdetoys is empty and doesn't contain anything...

> and this happens for kdeadmin kdeutils kdegraphics kdemultimedia kdelibs2g

these are taken care of by replaces...

for example...   kview replaces kdegraphics...

> Maybe has to do with your intention to eliminate all task-kde except 
> task-kde and task-kde-dev ?

no..there really should be conflicts in there which would cause the old
empty package to be removed...but I haven't done that yet.  

Ivan

-- 

Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD




Re: Packages from different versions at the same time

2000-12-15 Thread Thibaut Cousin
Le Vendredi 15 Décembre 2000 14:15, Pablo de Vicente a écrit :
>  I have been updating a couple of machines at my work from kde 1.1.2 to kde
> 2.0.1 in potato this morning. I find that some packages which should
> conflict among them appear twice resulting in different size icons o
> duplicate icons in the desktop and K menu.
>
>  For example the system has
>
> kdetoys 4:1.1.2 and task-kdetoys 4:2.0.1 at the same time
>
> and this happens for kdeadmin kdeutils kdegraphics kdemultimedia kdelibs2g
>
> Maybe has to do with your intention to eliminate all task-kde except
> task-kde and task-kde-dev ?

  I had the same kind of problem. You'd better remove KDE1 completely (just 
remove qt1g*, kdelibs2* and kdesupport0g*, apt-get will do the rest for you) 
before installing KDE2. I noticed that if you just upgrade KDE some icons and 
applnk entries from KDE1 remain.
  At the same time, try to rename the old .kde, .kderc and Desktop files in 
each home folder. Even though KDE2 is able to handle files from KDE1, it does 
not do a great job of it.

-- 
Thibaut Cousin
email : [EMAIL PROTECTED]
web   : http://clrwww.in2p3.fr
---
Teach me passion for I fear it`s gone. Show me love, hold the lorn.
So much more I wanted to give to the ones who love me. I`m sorry.
Time will tell (this bitter farewell)
I live no more to shame nor me nor you
And you... I wish I didn`t feel for you anymore...

Nightwish(http://www.nightwish.com)




Packages from different versions at the same time

2000-12-15 Thread Pablo de Vicente
Ivan

 I have been updating a couple of machines at my work from kde 1.1.2 to kde 
2.0.1 in potato this morning. I find that some packages which should conflict 
among them appear twice resulting in different size icons o duplicate icons 
in the desktop and K menu.

 For example the system has 

kdetoys 4:1.1.2 and task-kdetoys 4:2.0.1 at the same time

and this happens for kdeadmin kdeutils kdegraphics kdemultimedia kdelibs2g

Maybe has to do with your intention to eliminate all task-kde except 
task-kde and task-kde-dev ?


Pablo.
_
Pablo de Vicente ([EMAIL PROTECTED]) http://www.oan.es  (Spain




Re: libqt2.2 versions

2000-12-10 Thread Tormod Ravnanger Landet
> If you want to use woody then do it.  KDE 2.x is part of woody.  If you
> don't want to use woody then don't and use the potato KDE 2.x debs up on
> kde.tdyc.com

I think I will be upgrading to woody then, potato is getting old ;-)
286 packages to upgrade ...

-- 
-- 
Tormod Ravnanger Landet




Re: libqt2.2 versions

2000-12-10 Thread Ivan E. Moore II
On Sun, Dec 10, 2000 at 04:07:10PM +0100, Tormod Ravnanger Landet wrote:
> > progeny is a woody based system...that's the problem.  woodies version
> > numbers are higher on purpose.
> >
> > I'm not sure what's causing the crashes (haven't dug too much into the
> > version's yet to find out tho)...
> 
> Does this mean I can use woody's sources.list lines to get kde2 with no 
> problems?

no..it means that progeny is based on woody.  

If you want to use woody then do it.  KDE 2.x is part of woody.  If you don't
want to use woody then don't and use the potato KDE 2.x debs up on kde.tdyc.com

Ivan


-- 

Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD




Re: libqt2.2 versions

2000-12-10 Thread Tormod Ravnanger Landet
> progeny is a woody based system...that's the problem.  woodies version
> numbers are higher on purpose.
>
> I'm not sure what's causing the crashes (haven't dug too much into the
> version's yet to find out tho)...

Does this mean I can use woody's sources.list lines to get kde2 with no 
problems?

Thanks for answering

-- 
Tormod Ravnanger Landet




Re: libqt2.2 versions

2000-12-09 Thread Ivan E. Moore II
> Today, when I did my daily dist-upgrade, I noticed that I was downloading a 
> new libqt2.2. This is normally good, even more bugs cleaned out, but that was 
> not the case today. I saw that the package was coming from progeny. It made 
> konqueror crash, and crash, and crash...
> 
> I found out that this was a older package with a higher version number. What 
> should I do? My world was falling into pieces (well, I might be exaggerating 
> a small bit) I had to manually download the right deb and "downgrade", then I 
> put libqt2.2 on hold.
> 
> What I am wondering is, is there a better way to do this? I could of course 
> hack together a script that changes the sources.list, unholds, updates, 
> upgrades, holds libqt2.2, changes the list back, updates and upgrades, but 
> I'd rather not do this. I could also, of course, do it all manually, but that 
> wouldn't be so much fun :-)
> 
> I guess what I'm trying to say is that progeny has hijacked libqt2.2 and that 
> maybe someone would like to know this and ask them to use version numbers 
> lower than tdyc's, or in some other mysterious way make the problem go away 
> (or tell me how).
> 

progeny is a woody based system...that's the problem.  woodies version numbers
are higher on purpose.  

I'm not sure what's causing the crashes (haven't dug too much into the
version's yet to find out tho)...

Ivan

-- 

Ivan E. Moore II
[EMAIL PROTECTED]
http://snowcrash.tdyc.com
GPG KeyID=90BCE0DD
GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD




libqt2.2 versions

2000-12-09 Thread Tormod Ravnanger Landet
I have for a while had both kde.tdyc.com and archives.progeny.com in my (ever 
growing) sources.list. This has not been a problem until today. I have got 
up-to-date debs of X Windows (4.0.1) and the latest kde2 builds while 
maintaining potato's stability (well almost :-)

Today, when I did my daily dist-upgrade, I noticed that I was downloading a 
new libqt2.2. This is normally good, even more bugs cleaned out, but that was 
not the case today. I saw that the package was coming from progeny. It made 
konqueror crash, and crash, and crash...

I found out that this was a older package with a higher version number. What 
should I do? My world was falling into pieces (well, I might be exaggerating 
a small bit) I had to manually download the right deb and "downgrade", then I 
put libqt2.2 on hold.

What I am wondering is, is there a better way to do this? I could of course 
hack together a script that changes the sources.list, unholds, updates, 
upgrades, holds libqt2.2, changes the list back, updates and upgrades, but 
I'd rather not do this. I could also, of course, do it all manually, but that 
wouldn't be so much fun :-)

I guess what I'm trying to say is that progeny has hijacked libqt2.2 and that 
maybe someone would like to know this and ask them to use version numbers 
lower than tdyc's, or in some other mysterious way make the problem go away 
(or tell me how).

Here is some relevant info

Package: libqt2.2
Version: 2:2.2.2-6
Priority: optional
Section: libs
Maintainer: Ivan E. Moore II <[EMAIL PROTECTED]>
Pre-Depends: dpkg (>= 1.6.8)
Depends: libc6 (>= 2.1.97), libgl1, libjpeg62, libmng, 
libstdc++2.10-glibc2.2, xlibs (>= 4.0.1-1), zlib1g (>= 1:1.1.3)
Provides: libqt2
Replaces: qt2, libqt2, libqt2.1
Architecture: i386
Filename: dists/progeny/main/binary-i386/libs/libqt2.2_2.2.2-6.deb
Size: 1920196
MD5sum: cb1dfddf6b389e0cfc5dfc86c30b38db
Description: Qt GUI Library (runtime version).
 This package contains the files necessary for running applications that use
 Qt.
source: qt2.2
installed-size: 4868

Package: libqt2.2
Version: 2:2.2.2-0.potato.10
Priority: optional
Section: libs
Maintainer: Ivan E. Moore II <[EMAIL PROTECTED]>
Pre-Depends: dpkg (>= 1.6.8)
Depends: libc6 (>= 2.1.2), libjpeg62, libmng (>= 0.9.3-0), libstdc++2.10, 
libz1, xlib6g (>= 3.3.6-4)
Conflicts: libqt2.2-gl
Provides: libqt2
Replaces: qt2, libqt2, libqt2.1, libqt2.2-gl
Architecture: i386
Filename: 
dists/potato/main/binary-i386/libs/libqt2.2_2.2.2-0.potato.10_i386.deb
Size: 1908266
MD5sum: 7f5d818f3d639bade16f09bfa3fc5b60
Description: Qt GUI Library (runtime version).
 This package contains the files necessary for running applications that use
 Qt.
 .
 This package was compiled without OPENGL support.
installed-size: 4844
source: qt2.2

-- 
Tormod Ravnanger Landet
Happy Debian/kde2 user