KDE_3_3_BRANCH: kdeartwork/debian

[Ben Burton]

CVS commit by benb: 

More manpage updates for 3.3.


  M +3 -2  kswarm.kss.1   1.6.2.1
  M +3 -2  kxsconfig.1   1.5.4.1


--- kdeartwork/debian/kswarm.kss.1  #1.6:1.6.2.1
@@ -3,5 +3,5 @@
 .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
 .\" other parameters are allowed: see man(7), man(1)
-.TH KSWARM.KSS 1 "January 30, 2004"
+.TH KSWARM.KSS 1 "October 13, 2004"
 .\" Please adjust this date whenever revising the manpage.
 .\"
@@ -46,5 +46,6 @@
 .BR kxsrun (1).
 .SH AUTHOR
-This screen saver was written by Patrick J. Naughton, Emanuel Pirker,
+This screen saver was written by Patrick J. Naughton,
+Emanuel Pirker <[EMAIL PROTECTED]>,
 Jeff Butterworth <[EMAIL PROTECTED]> and Mario Weilguni <[EMAIL PROTECTED]>.
 .br

--- kdeartwork/debian/kxsconfig.1  #1.5:1.5.4.1
@@ -3,5 +3,5 @@
 .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
 .\" other parameters are allowed: see man(7), man(1)
-.TH KXSCONFIG 1 "May 12, 2003"
+.TH KXSCONFIG 1 "October 13, 2004"
 .\" Please adjust this date whenever revising the manpage.
 .\"
@@ -44,5 +44,6 @@
 .BR kxsrun (1).
 .SH AUTHOR
-This tool was written by Martin R. Jones <[EMAIL PROTECTED]>.
+This tool was written by Martin R. Jones <[EMAIL PROTECTED]>.  It also
+makes use of xscreensaver code written by Jamie Zawinski <[EMAIL PROTECTED]>.
 .br
 This manual page was prepared by Ben Burton <[EMAIL PROTECTED]>

KDE_3_3_BRANCH: kdeartwork/debian

[Ben Burton]

CVS commit by benb: 

Manpages for new screensavers.


  Akfiresaver.kss.1   1.1.2.1
  Akpendulum.kss.1   1.1.2.1
  Akrotation.kss.1   1.1.2.1
  M +4 -4  changelog   1.31.2.1
  M +3 -0  kscreensaver.manpages   1.4.2.1


--- kdeartwork/debian/changelog  #1.31:1.31.2.1
@@ -1,11 +1,11 @@
-kdeartwork (4:3.2.92-1) experimental; urgency=low
+kdeartwork (4:3.3.0-1) experimental; urgency=low
 
   * New upstream release.
-  * Versioned libqt3-mt-dev build-depends is no longer necessary since
-kdelibs4-dev already forces Qt 3.3.
+  * The previous versioned libqt3-mt-dev build-depends is no longer
+necessary, since kdelibs4-dev already forces Qt 3.3.
   * Build-depends on both xscreensaver and xscreensaver-gl, which are
 required for the corresponding .desktop files to be installed.
 
- -- Ben Burton <[EMAIL PROTECTED]>  Sun,  1 Aug 2004 18:41:10 +1000
+ -- Ben Burton <[EMAIL PROTECTED]>  Sun, 22 Aug 2004 18:41:10 +1000
 
 kdeartwork (4:3.2.3-1) unstable; urgency=low

--- kdeartwork/debian/kscreensaver.manpages  #1.4:1.4.2.1
@@ -3,4 +3,5 @@
 debian/kclock.kss.1
 debian/keuphoria.kss.1
+debian/kfiresaver.kss.1
 debian/kflux.kss.1
 debian/kfountain.kss.1
@@ -9,5 +10,7 @@
 debian/klorenz.kss.1
 debian/kpartsaver.kss.1
+debian/kpendulum.kss.1
 debian/kpolygon.kss.1
+debian/krotation.kss.1
 debian/kscience.kss.1
 debian/kslideshow.kss.1

KDE_3_3_BRANCH: kdeaddons/debian

[Ben Burton]

CVS commit by benb: 

Remove kontact-plugins, update *.install.


  M +2 -1  changelog   1.30.2.2
  M +4 -19 control   1.35.2.1
  M +1 -0  kate-plugins.install   1.6.2.1
  M +3 -0  kdeaddons-kfile-plugins.install   1.4.2.1
  M +1 -0  kicker-applets.install   1.5.4.1
  M +19 -0 konq-plugins.install   1.6.2.1

KDE_3_3_BRANCH: kdewebdev/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  source.lintian-overrides   1.1.2.1


--- kdewebdev/debian/source.lintian-overrides  #1.1:1.1.2.1
@@ -1,2 +1,2 @@
-quanta source: cvsignore-file-in-source
-quanta source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

KDE_3_3_BRANCH: kdetoys/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  source.lintian-overrides   1.2.2.1


--- kdetoys/debian/source.lintian-overrides  #1.2:1.2.2.1
@@ -1,2 +1,2 @@
-kdetoys source: cvsignore-file-in-source
-kdetoys source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

KDE_3_3_BRANCH: kdesdk/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  source.lintian-overrides   1.2.2.1


--- kdesdk/debian/source.lintian-overrides  #1.2:1.2.2.1
@@ -1,2 +1,2 @@
-kdesdk source: cvsignore-file-in-source
-kdesdk source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

KDE_3_3_BRANCH: kdeedu/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  source.lintian-overrides   1.2.2.1


--- kdeedu/debian/source.lintian-overrides  #1.2:1.2.2.1
@@ -1,2 +1,2 @@
-kdeedu source: cvsignore-file-in-source
-kdeedu source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

KDE_3_3_BRANCH: kdeartwork/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  source.lintian-overrides   1.2.2.1


--- kdeartwork/debian/source.lintian-overrides  #1.2:1.2.2.1
@@ -1,2 +1,2 @@
-kdeartwork source: cvsignore-file-in-source
-kdeartwork source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

KDE_3_3_BRANCH: kdeaddons/debian

[Ben Burton]

CVS commit by benb: 

Fix source overrides (see #261435).


  M +2 -2  changelog   1.30.2.1
  M +2 -2  source.lintian-overrides   1.2.2.1


--- kdeaddons/debian/changelog  #1.30:1.30.2.1
@@ -1,7 +1,7 @@
-kdeaddons (4:3.2.92-1) experimental; urgency=low
+kdeaddons (4:3.3.0-1) experimental; urgency=low
 
   * New upstream release.
 
- -- Ben Burton <[EMAIL PROTECTED]>  Sun,  1 Aug 2004 18:41:10 +1000
+ -- Ben Burton <[EMAIL PROTECTED]> Sun,  22 Aug 2004 18:41:10 +1000
 
 kdeaddons (4:3.2.3-2) unstable; urgency=low

--- kdeaddons/debian/source.lintian-overrides  #1.2:1.2.2.1
@@ -1,2 +1,2 @@
-kdeaddons source: cvsignore-file-in-source
-kdeaddons source: source-contains-CVS-dir
+cvsignore-file-in-source
+source-contains-CVS-dir

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Josh Metzler]

On Monday 11 October 2004 04:14 am, Andras Korn wrote:
> Package: kdm
> Version: 4:3.3.0a-1
> Severity: wishlist
>
> Hi,
>
> Currently, upgrading kdm is a mess if kdmrc has been edited by hand. Even
> the diff output is barely usable because there are many comments in the
> file that often also change across versions.
>
> It'd be nice if kdmrc could be split into several small files, each of
> which would contain related settings and (almost) no comments. The
> comments, being very verbose, belong in /usr/share/doc/kdm/examples/.

I think this in itself would be a solution to this bug.  The main problem I 
see is that the kdm kcontrol module completely rearranges the options from 
the default config, and it strips all comments.  Because of this, the new 
upstream version is completely different from the version on the harddrive 
even if you have only made a small change.

So, I think a solution would be to 1) put the current default config, with 
all examples in /usr/share/doc/kdm/examples/ and 2) open the current 
default config in the kdm kcontrol module and save it (thus getting the 
options in the order the kcontrol module writes them out and stripping all 
comments) before shipping it.

If this were done, only those lines that the user actually changed would 
show up in the diff.

Josh

Bug#275171: konqueror: Please include "kecko" Gecko layout engine

[ivan-debian]

On Tue, Oct 12, 2004 at 10:51:15PM +0200, Bellegarde C?dric wrote:
> Le Mardi 12 Octobre 2004 11:10, [EMAIL PROTECTED] a ?crit?:
> > The unreleased state of the product does not mean a wishlist bug is not
> > appropriate.
> 
> It make your bug invalid.
> 
> Mozilla Qt is in mozilla CVS but it is totally unusable!
> There is no kpart for now!

No, the unreleased state of the product or unusability does not make the 
wishlist bug invalid.  :)  We've been through this already.

My impression was that the kpart would be in KDE upstream, like the old 
one from the 2.x days.

However, if the kpart really will live in Mozilla upstream rather than
KDE upstream, the bug could certainly be retitled to an RFP and
reassigned to wnpp, or reassigned to the appropriate Mozilla package.  I
believe I mentioned this previously.

> And, it's a mozilla related package! 
> You will have mozilla-qt and mozilla-kpart , i think.

-- 
_ivan

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Andras Korn]

On Tue, Oct 12, 2004 at 07:04:19PM +0200, Achim Bohnet wrote:

> > 1. generate kdmrc as it would look without kcm changes
> > 
> > 2. diff with existing version; assume changes were made by kcm
> > 
> > 3. propagate changes to kdmrc_kcm (a fourth config that takes precedence
> > over user, debian and upstream)
> 
> So a special case just for kdmrc?

Uh, well, yes. This whole bug is just about alleviating the pain of tracking
upstream (and Debian) changes to kdmrc.

Of course, it may be possible to extend my proposed approach to other
configs.

> There is also the problem that kde config tried to minimize
> changes: if a user and system config file contain the same setting
> it's removed from the user file.

User file? For kdm? Doesn't that only have things like previous session and
language and stuff? How does that enter the picture here?

> I've not thought about it how
> this could influence the four config file case.  KDE config stuff
> is already complex enough for me >;-/

You can say that again...

> > The problem is _when_ to do this. The kdm initscript seems like a reasonable
> > place.
> AFAIK kdm reload config if modified before starting each chooser/login
> window.

I don't see how that is a problem. kdmrc would always contain the most up to
date config.

> > What do you think?
> 
> I still have the feeling that it's too much effort.

I agree it's a lot more complex than I originally thought. However, thinking
of the frustration of merging kdmrc changes, I'm still not sure of the 'too
much' bit. :)

> My first try would be UCF but I done no experiments with it yet (UCF usage
> is still on TODO for my pkgs).  So it may not help much in your case.

Well, if ucf can do a reasonable job of this, I'm sure we'll all be happy.
When do you think you'll be able to find out? Maybe someone with a better
understanding of ucf than either of us can provide advice?

Andras

-- 
 Andras Korn 
  QOTD:
Quantum Mechanics: The dreams stuff is made of.

Bug#275171: konqueror: Please include "kecko" Gecko layout engine

[Bellegarde Cédric]

Le Mardi 12 Octobre 2004 11:10, [EMAIL PROTECTED] a écrit :
> The unreleased state of the product does not mean a wishlist bug is not
> appropriate.

It make your bug invalid.

Mozilla Qt is in mozilla CVS but it is totally unusable!
There is no kpart for now!

And, it's a mozilla related package! 
You will have mozilla-qt and mozilla-kpart , i think.

Bug#276013: all kde apps segfault on startup on alpha

[Andrew Lenharth]

On Tue, 2004-10-12 at 12:15, Adeodato Simó wrote:
>   there is a kdelibs4 package in testing-proposed-updates (3.2.3-3.sarge.2),
>   which has already been compiled for alpha. could you please upgrade to
>   that and check again?

doesn't help.  Below is the last section of strace when run on juk

open("/usr/lib/libvorbisenc.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0&\220\1\0\0\0\220t\1"...,
640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=1727432, ...}) = 0
mmap(NULL, 1821176, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x20002cba000
mprotect(0x20002cd6000, 1706488, PROT_NONE) = 0
mmap(0x20002cda000, 1662976, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x20002cda000
mmap(0x20002e7, 27128, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20002e7
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2000101a000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2000101c000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2000101e000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


And on konsole:

open("/usr/lib/libexpat.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0&\220\1\0\0\0\340I\0"...,
640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=170528, ...}) = 0
mmap(NULL, 234280, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x200021c2000
mprotect(0x200021e8000, 78632, PROT_NONE) = 0
mmap(0x200021f2000, 40960, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x2) = 0x200021f2000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x2ff8000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


So as far as I can tell, very early in the execution after the shared
libs are loaded.

Andrew

Bug#276013: all kde apps segfault on startup on alpha

[Adeodato Simó]

* Andrew Lenharth [Tue, 12 Oct 2004 11:36:59 -0500]:
> >   which exact versions of these applications? and against what kdelibs4
> >   version?

> kdelibs4: 3.2.3-2
> juk: 3.2.2-1
> konsole: 3.2.2-1

> This is a standard up-to-date (well within 5 days certainly) testing
> system.

  there is a kdelibs4 package in testing-proposed-updates (3.2.3-3.sarge.2),
  which has already been compiled for alpha. could you please upgrade to
  that and check again?

  thanks,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Loan-department manager:  "There isn't any fine print.  At these
interest rates, we don't need it."

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Achim Bohnet]

On Tuesday 12 October 2004 16:50, you wrote:
> On Tue, Oct 12, 2004 at 03:54:50PM +0200, Achim Bohnet wrote:
> 
> > > I've seen ucf in action, and I don't see how it can be readily applied 
> > > here,
> > > or what its advantages over the proposed script would be. Do you have any
> > > specific approach in mind?
> > 
> > AFAIU your goal is to make merging of upstream changes in kdmrc easier.
> > 
> > Currently kdmrc is a conffile and admin see all changes, regardless if the
> > sys admin did them or it's an upstream change. Ucf AFIAU offers such
> > merging.  So visual clutter can be reduced.
> 
> In my experience, not by much; but maybe the other packages that use ucf
> don't use it optimally.
> 
> > Your proposed solution with a splitted kdmrc and a update-* tool
> > does not work easily because kdmrc can also manipulated by a kontrol
> > center modules.
> 
> You're right. Too bad...
> 
> >  So without modifying kdm & kcm_kdm you also have to
> > ensure that changes via kcm module in kdmrc are 'backported' to the
> > several little config files.  IMHO not worth all the trouble.
> 
> Yes, it does look ugly at first sight; however, the backporting isn't so
> difficult in itself:

Oh, Maybe kiosk tool may also modify kdm settings (not checked).
There is also the problem that kde config tried to minimize
changes: if a user and system config file contain the same setting
it's removed from the user file.  I've not thought about it
> 
> 1. generate kdmrc as it would look without kcm changes
> 
> 2. diff with existing version; assume changes were made by kcm
> 
> 3. propagate changes to kdmrc_kcm (a fourth config that takes precedence
> over user, debian and upstream)

So a special case just for kdmrc?

There is also the problem that kde config tried to minimize
changes: if a user and system config file contain the same setting
it's removed from the user file.  I've not thought about it how
this could influence the four config file case.  KDE config stuff
is already complex enough for me >;-/


> 
> The problem is _when_ to do this. The kdm initscript seems like a reasonable
> place.

AFAIK kdm reload config if modified before starting each chooser/login
window.

> What do you think?

I still have the feeling that it's too much effort.
My first try would be UCF but I done no experiments with it
yet (UCF usage is still on TODO for my pkgs).  So it 
may not help much in your case.

Achim
> 
> Andras
> 
> -- 
>  Andras Korn 
>   QOTD:
> Never accept a drink from a urologist.
> 
> 
> 

-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- [EMAIL PROTECTED]

Bug#276013: all kde apps segfault on startup on alpha

[Andrew Lenharth]

>   which exact versions of these applications? and against what kdelibs4
>   version?

kdelibs4: 3.2.3-2
juk: 3.2.2-1
konsole: 3.2.2-1

This is a standard up-to-date (well within 5 days certainly) testing
system.

Andrew

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Andras Korn]

On Tue, Oct 12, 2004 at 03:54:50PM +0200, Achim Bohnet wrote:

> > I've seen ucf in action, and I don't see how it can be readily applied here,
> > or what its advantages over the proposed script would be. Do you have any
> > specific approach in mind?
> 
> AFAIU your goal is to make merging of upstream changes in kdmrc easier.
> 
> Currently kdmrc is a conffile and admin see all changes, regardless if the
> sys admin did them or it's an upstream change. Ucf AFIAU offers such
> merging.  So visual clutter can be reduced.

In my experience, not by much; but maybe the other packages that use ucf
don't use it optimally.

> Your proposed solution with a splitted kdmrc and a update-* tool
> does not work easily because kdmrc can also manipulated by a kontrol
> center modules.

You're right. Too bad...

>  So without modifying kdm & kcm_kdm you also have to
> ensure that changes via kcm module in kdmrc are 'backported' to the
> several little config files.  IMHO not worth all the trouble.

Yes, it does look ugly at first sight; however, the backporting isn't so
difficult in itself:

1. generate kdmrc as it would look without kcm changes

2. diff with existing version; assume changes were made by kcm

3. propagate changes to kdmrc_kcm (a fourth config that takes precedence
over user, debian and upstream)

The problem is _when_ to do this. The kdm initscript seems like a reasonable
place.

What do you think?

Andras

-- 
 Andras Korn 
  QOTD:
Never accept a drink from a urologist.

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Achim Bohnet]

On Tuesday 12 October 2004 09:14, Andras Korn wrote:
> On Mon, Oct 11, 2004 at 10:59:19PM +0200, Achim Bohnet wrote:
> 
> > > I'm willing, I guess, to implement the last proposal with the three groups
> > > of files as a shell script; would you accept it?
> > Good idea!  Before implementing such a script have a look at
> > the ucf pkg ;)
> 
> I've seen ucf in action, and I don't see how it can be readily applied here,
> or what its advantages over the proposed script would be. Do you have any
> specific approach in mind?

AFAIU your goal is to make merging of upstream changes in kdmrc easier.

Currently kdmrc is a conffile and admin see all changes, regardless if the
sys admin did them or it's an upstream change. Ucf AFIAU offers such
merging.  So visual clutter can be reduced.

Your proposed solution with a splitted kdmrc and a update-* tool
does not work easily because kdmrc can also manipulated by a kontrol
center modules.  So without modifying kdm & kcm_kdm you also have to
ensure that changes via kcm module in kdmrc are 'backported' to the
several little config files.  IMHO not worth all the trouble.

Achim
> 
> Andras
-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- [EMAIL PROTECTED]

FriBidi dependency

[Baruch Even]

Hello,

You receive this since your package depends on libfribidi0.

I have updated the fribidi package to generate a proper shlib file so
that the proper dependency will be set in dependent packages, this is as
a replacement for the so versions that the upstream authors don't use.

The library itself and its interface weren't changed so the only thing
needed to avail of this update to fribidi is to rebuild the package. If
you want to make sure that you (and the buildds) use the proper package
you can modify your Build-Depends: from 'libfribidi-dev' to
'libfribidi-dev (>= 0.10.4-4)'.

Thanks,
Baruch

Bug#275171: konqueror: Please include "kecko" Gecko layout engine

[ivan-debian]

On Mon, Oct 11, 2004 at 05:16:59PM +0200, Alejandro Exojo wrote:
> El Mi?rcoles, 6 de Octubre de 2004 22:12, [EMAIL PROTECTED] escribi?:
> > On Wed, Oct 06, 2004 at 09:31:49PM +0200, Alejandro Exojo wrote:
> > Again, the unreleased status of the software does NOT mean the wishlist
> > bug should be closed.  It is a reasonable wishlist bug, and the current
> > state or release status of the implementation is NOT RELEVANT and NOT
> > justification to close the bug.
> 
> The unreleased state of the project, means a lot if you can't put the 
> necessary information in the copyright file.

The unreleased state of the product does not mean a wishlist bug is not
appropriate.  When there is code, there will be the necessary
information to put in the copyright file.  If there is a license
problem, it will have to be resolved, but that does not invalidate a
wishlist bug for the functionality.

> > > and that doesn't have any relation with kdebase.
> >
> > My impression was that kecko was to be an alternate rendering engine for
> > the konqueror browser that could be built alongside or as an alternative
> > to the KTHML engine from KDE source.  How does that have no relation to
> > kdebase?
> 
> Because the port is code related to mozilla, not tot KDE. Konqueror has the 
> feature of embedding plugins (java, flash, etc.) but asking its mantainers to 
> package those plugins, doesn't makes sense.

As you note below, the port *is* code related to KDE, specifically a
KPart that will eventually be available from the same source.  This
wishlist bug is for the inclusion of said code in the konqueror package,
or another KDE package alongside it, enabling me to use the konqueror
browser with the Gecko rendering engine in addition to KHTML.

> > My impression is that it would be an option when compiling KDE, not a
> > standalone package.  Hence I filed the bug against the relevant KDE
> > component (to me as a user, anyway) rather than as an RFP.
> >
> > If kecko will be _separate_ source package that isn't built from KDE
> > source, then reassigning to wnpp and retitling as RFP would be
> > appropriate - but as I said my impression was that it would be a part of
> > the KDE source (albeit one that depended on Gecko).
> 
> It needs two components: a KPart, and the Qt port, as the new you posted 
> explained.

[snip]

> Anyway, latest news:
> 
> http://www.kdedevelopers.org/node/view/666
> 
> So _today_ (not Wed, 6 Oct 2004 05:21:47 -0700, when you first reported the 
> bug), it seems that there is the first code available. I checked it out, and 
> at least now we can say that there is a license and copyright holder(s), but 
> it is a combination of MPL/GPL/LGPL, so it can be complex. But again, as I 
> said, it's code unrelated to KDE.
> 
> Still there is no code for the KPart needed. It's very probable, that it will 
> be commited to the kdenonbeta module, and, when it fits the KDE release 
> schedule, will be moved to kdebase.
> 
> Then, at that moment, but not before, if the packages of that version of 
> konqueror in Debian, doesn't include support for embedding gecko, a wishlist 
> will make sense.

No.  At that moment may make sense to think about *implementing* the
feature in Debian.  The wishlist bug is appropriate at any time.

> This is my point, and I hope you understood it.

I can sympathize, but you should not impose your opinion on Debian in 
conflict with our practices.

> Anyway, I'm not the mantainer 
> of this package, neither a Debian developer, so if have more information to 
> add, don't reply to me, do it to the bugreport only, please.

I am a Debian developer, and I have never heard nor seen documented the
conditions you state are necessary for a wishlist bug.  On the contrary,
wishlist bugs are commonly used to request features in _any_ state of
completion, even those for which there is no code or even an idea before
the wishlist bug itself.  The BTS developer documentation at
http://www.debian.org/Bugs/Developer#severities states that wishlist
bugs are appropriate "for any feature request", not "requests for
features already released upstream".

-- 
_ivan

Bug#275951: Please split kdmrc into multiple files for ease of maintenance

[Andras Korn]

On Mon, Oct 11, 2004 at 10:59:19PM +0200, Achim Bohnet wrote:

> > I'm willing, I guess, to implement the last proposal with the three groups
> > of files as a shell script; would you accept it?
> Good idea!  Before implementing such a script have a look at
> the ucf pkg ;)

I've seen ucf in action, and I don't see how it can be readily applied here,
or what its advantages over the proposed script would be. Do you have any
specific approach in mind?

Andras

-- 
 Andras Korn 
  QOTD:
 Minds are like parachutes; they only work when open.