Bug#303309: kcmshell kgamma opens empty dialog (only ok, cancel etc at the bottom)
Package: kgamma Version: 4:3.4.0-0pre1 Severity: normal Not sure if this is the right way. But move & edit the desktop file made the dialog useful again: --- /usr/share/applications/kde/kgamma.desktop 2005-02-03 23:44:58.0 +0100 +++ /usr/share/services/kgamma.desktop 2005-04-06 00:59:15.891926154 +0200 @@ -92,11 +92,14 @@ Keywords[wa]=KGamma, kgamma, Gama, gama Keywords[xx]=xxKGamma, kgamma, Gamma, gammaxx Keywords[zh_CN]=KGamma, kgamma, Gamma, gamma,äç -Type=Application -X-KDE-Init=kgamma + +#Type=Application +Type=Service +ServiceTypes=KCModule +#X-KDE-Init=kgamma X-KDE-FactoryName=kgamma X-KDE-Library=kgamma X-KDE-ModuleType=Library X-KDE-Test-Module=true -NoDisplay=true +#NoDisplay=true Encoding=UTF-8 Achim -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kgamma depends on: ii kdelibs4 4:3.4.0-0pre2 core libraries for all KDE applica ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.3-8 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information
Re: New font defaults for new users - feedback wanted!
On Friday 08 April 2005 17:22, Bastian Venthur wrote: > Pierre Habouzit wrote: > > > afaik, when using kdm, dpi is guessed by X. > > my dpi was read on my both screens (the physical ones) and resulted in > > x-dpi and y-dpi (I mean the horiz and vertical dpi weren't the same). > > > > maybe then if fallbacks to 75dpi if no information is found on the > > hardware ... > > > > Personnaly I *manually* force the dpi in kdmrc, and I run startx with > > -- -dpi 75 Uh, why? > > Thats exactly the reason why i thought, that kde is "optimized" for 75dpi, > because on it looks best on my 14''laptop-display as well as on my 19'' > deskop-display with 75dpi. Some times back kdm Xservers file forced 100 dpi. AFAIR never 75 dpi. All this looks best cheating with dpi was a somehow usefuls hack with CRT monitors and in limited available sizes of bitmap fonts. With scalable fonts and TFTs dpi tweaking is stupid (IMO or course). > > Calculating the dpi for both displays would give me some values about > 92-96dpi but I think 75dpi looks kind of better. No. Wrong approach. Choose another font size (in pt). > > Personaly I find "dpi" as it pretty useless for monitor-description, since > we have already all data needed: 1280x1024 (19'') for example. But i > admint, that i may have not fully understood this hole "graphics-thingy". dpi much more accurate that the 1'' steps used in monitor descriptions (and only there ;) Ever seen a 14.31'' monitor? I'm looking right now at one ;) Further dpi in x and dpi in y are often not identical and then the dimension of the diagonal is to less information. I've 14'' TFT with 75 dpi, 98 dpi, 125 dpi and a 15'' with 133 dpi. On all of them I use 10pt font settings and on all monitors the font have identical size. Windows (almost) identical size. Restored or copied setting look almost identical. Great. If I would force 75 dpi, without changing font size. The fonts would be on the 133 dpi almost half the size as on the old TFT with 75 dpi. Same for windows sizes. PDL documentation tell you A4 but it looks like A5. Argl! Recalibration size with gimp for every monitor, what fun. > > BTW as far as i remember XP has only two settings for dpi 96(default) and > some-other-but-not-75 (don't remember the exact value). yeah, brain dead windows has only std 2 font sizes. And brain dead MS programmer hard code pixel size of buttons so that only one font works well. That's worser than the unix situation year ago. And MS solution? scale up everything on hires monitor. Lose all the sharpness one can expect from a hires monitor. HAA brilliant! > > > I don't know how startx work anyway. > > Me too ;) > > I wish someone at kde.org could implement some inside-kde-solution for > setting the dpi, so we finaly have a common basis for things like setting > the default fontsize. KDE has the solution some years already. They specify fonts size in pt (72pt == 1 inch) not pixels. Then there no need at all to even know about dpi as long as the Xserver gets the right value from the hardware. In the old days monitor had ~ 75 dpi. So 1 px ~ 1 pt = 1 dot. People are used to font size of 10. They always think this are pixels but are really used to 10 pt fonts. Achim > > > Nice Weekend > > Bastian > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New font defaults for new users - feedback wanted!
On Friday 08 April 2005 22:28, Pierre Habouzit wrote: > > With scalable fonts and TFTs dpi tweaking is stupid (IMO or course). > the point is I use bitmap fonts for monospace fonts in my terminals, and > I can assure you the dpi is quite important then ;) > > give me a nice looking monospaced font ... and I'll see. but it does not Heh, use custom font set to to a TTF like, e.g., 'Courier New' and be done ;) [AFAIR SuSE also has a usable TTF font in konsole.] E.g. on IRC I suggested: cat > /etc/kde3/konsolerc < exists (antialiasing is a pain for monospace fonts in my vim IMHO) konsole and antialiasing isn't a goot idea I fully agree. Achim > -- > ÂOÂ Pierre Habouzit > ÂÂO > OOOhttp://www.madism.org > -- 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]
Re: KDE 3.4: packages that require libc6 (>= 2.3.2.ds1-21)
On Friday 22 April 2005 13:16, Pierre Habouzit wrote: > > Is that intentional? This would exclude Debian Sarge users from > > testing KDE 3.4. I can update to newer libc but would loose X related > > development packages. > > kde 3.4 won't be shipped with sarge. kde 3.3.2 will. if you want to use > kde 3.4 atm, you have to use unstable, or wait until sarge is out, and > the kde 3.4 migration into etch. Or if libc is the only dependency problem (re)build it yourself Martin. It's not complicated. Achim > > -- > ÂOÂ Pierre Habouzit > ÂÂO > OOOhttp://www.madism.org > -- 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]
Re: Bug#306144: kitchensync: Kitchensync headers missing
On Sunday 24 April 2005 15:49, Thomas Claveirole wrote: > Package: kitchensync > Version: 4:3.3.2-3 kdebluetooth sync stuff needs features from kde 3.4. In KDE 3.4 the headers are in kdepim-dev. You can try the deb from http://fred.hexbox.de/debian/. For kdebluetooth problems contact <[EMAIL PROTECTED]> Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kde.mk misses shared lib dependencies in /usr/lib/kde3
Hi,
I just realized that one of my pkgs suffers the same problem
vorlon pointed out in debian-release, that pkgs depend on
kdelibs4 but not libqt-mt. I assume this is due to the fact
that the only 'binaries' are $DESTDIR/usr/lib/kde3. Would be
nice if the new KDE.mk takes care of this. Does this make
sense?
I have not looked into dh_{makeshlibs,shlibdeps} yet. Any hint
appreciated. I post my solution when I've found it ;)
allee(0) ~/src/knemo/0.3.1 $ dpkg --contents knemo_0.3.1-2_i386.deb | grep lib
drwxr-xr-x root/root 0 2005-04-27 01:55:54 ./usr/lib/
drwxr-xr-x root/root 0 2005-04-27 01:55:56 ./usr/lib/kde3/
-rw-r--r-- root/root138664 2005-04-27 01:55:56 ./usr/lib/kde3/kcm_knemo.so
-rw-r--r-- root/root 1052 2005-04-27 01:55:13 ./usr/lib/kde3/kcm_knemo.la
-rw-r--r-- root/root213880 2005-04-27 01:55:56 ./usr/lib/kde3/kded_knemod.so
-rw-r--r-- root/root 1183 2005-04-27 01:55:53 ./usr/lib/kde3/kded_knemod.la
allee(0) ~/src/knemo/0.3.1 $ dpkg --info knemo_0.3.1-2_i386.deb | grep Depends
Depends: kdelibs-bin, kicker, net-tools, kdelibs4 (>= 4:3.3.2-4.0.2), libc6
(>= 2.3.2.ds1-21), libgcc1 (>= 1:3.4.1-3), libstdc++5 (>= 1:3.3.4-1)
allee(0) ~/src/knemo/0.3.1 $ ldd /usr/lib/kde3/kded_knemod.so | grep libqt
libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb6ce5000)
Achim
--
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]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde.mk misses shared lib dependencies in /usr/lib/kde3
On Wednesday 27 April 2005 03:36, Adeodato Simó wrote: > * Achim Bohnet [Wed, 27 Apr 2005 03:24:32 +0200]: > > allee(0) ~/src/knemo/0.3.1 $ ldd /usr/lib/kde3/kded_knemod.so | grep libqt > > libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0xb6ce5000) > > Don't trust ldd for this. Use objdump: > > $ objdump -p /file | grep NEEDEd > > If libqt isn't there, it needn't (musn't) be listed as a Dependency. Thx. You made me aware that I looked at the problem from the wrong side. Better: Don't trust or ldd and objdump -p for this ;) knemo source code is full of qt includes and code. So code 'needs' libqt-whatever. But the Makefile.am does not link againt QTLIB, therefore libtool des not use QTLIB for linking That's okay because shared code is loaded into kcontrol and kicker and libqt in loaded/resolved there already. Assuming that the dlopening app has already all required libs preloaded a dlopen-shared-code needs to link against nothing ;) Somehow I doubt that this is a good thing for dh_shlibs try to automaticly get library dependencies right. For sure rdepends is rendered somewhat useless. Achim > > -- > Adeodato Simó > EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 > > A dream is an answer to a question that we don't know how to ask. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- 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]
Re: Bug#313472: Viewing the kdepasswd manpage displays errors
Same for 3.4.1. In the manpage one '-' in '--option' is lost. Manpage looks like it was once created with kdemangan without further additions. Therefore I suggest to remove this manpage as was done with several others before until something better is available. Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315533: kdebase-kio-plugins: missing audiocd.docbook
On Thursday 23 June 2005 11:52, Andrew Schulman wrote: > Package: kdebase-kio-plugins > Version: 4:3.4.1-1 > Severity: normal > Tags: experimental > > The Info Center help page for audiocd:/ is missing. I see that > usr/share/doc/kde/HTML/en/kioslave/audiocd.docbook isn't present in > this package, as it was in 3.3.4. Thanks, Andrew. Hi Andrew, the audio cd lib _and_ doc are in kdemultimedia-kio-plugins: $ dlocate -L kdemultimedia-kio-plugins | grep kio_audiocd /usr/share/doc/kde/HTML/en/kio_audiocd /usr/share/doc/kde/HTML/en/kio_audiocd/audiocd.docbook /usr/lib/kde3/kio_audiocd.la /usr/lib/kde3/kio_audiocd.so> Nevertheless something is wrong: 1) Assumed that audiocd is expeted to be a standalone docu now, the installed files needed are kio_audiocd/index.docbook kio_audiocd/index.cache.bz2 (maybe even strip op kio_ prefix so help:/audiocd works) See http://lists.kde.org/?l=kde-i18n-doc&m=111933784315601&w=2 2) Assumed audiocd should be merged into the other ioslave one needs kioslave/audiocd.docbook but here we have the problem that the audiocd.docbook file is not in index.cache.bz because this file is from kdebase-kio-plugins. Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#238770: In /etc/kde3/kdm/Xservers no -dpi Option is set
On Wednesday 09 November 2005 17:55, Erik Moeller wrote: > I experienced the same problem again after updating to KDE 3.4 on > testing. It turned out that a change in the syntax of the kdmrc file was > the cause: /etc/kde3/kdm/kdmrc now directly specifies the X server > parameters, rather than using the Xservers file to look them up. The > default there is, again, to use no dpi setting (which I find problematic > since figuring out the correct DisplaySize setting in xorg.conf is much > harder for a newbie). Changing ServerArgsLocal to Well, do you think figuring out the correct dpi value for ServerArgsLocal is easier for a newbie than adding DisplaySize 284 213 # width and height in mm of the display to the Monitor section? And anyone asking what I mean with 'correct dpi' value has already proven that I'm right ;) Note: Both DisplaySize or -dpi settings is only necessary if the gfx driver and monitor can't exchange the DisplaySize information automaticly. [Works here already in correctly in 2/3 of the used hardware . Hopefully more with next xorg release. > > ServerArgsLocal=-nolisten tcp -dpi 100 That's is almost always wrong ;) Are you sure that your monitor has 100 dpi? If your fonts are too small _and_ dpi is right. the right thing is to use bigger fonts that to fake dpi value. Remember dpi == dot per inch and what an inch and a dot is, is well defined. I really prefer that A4 or letter printout have exactly the same size as the paper. > > solved the problem for me. It's wrong. DisplaySize is the right thing (tm). I vote for wontfix Achim > > HTH, > > Erik -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#343214: Manpages for lisa and reslisa
On Tuesday 13 December 2005 18:49, François Wendling wrote: > Package: lisa > Version: 3.3.2-5 > Tags: patch > > > Manpages for lisa and reslisa were missing. I join them. Hi François, great! You're using the GFDL for the manpages. This license is considered non-free by The Debian Free Software Guidelines (DFSG). http://www.de.debian.org/social_contract.en.html#guidelines It would be really great if you change the license to, e.g. GPL. Otherwise our manpages have to notadded/removed or go into the non-free section before the next debian release. Mhmm you used resLISa and LISa. Way upstream likes it or typo? Thx for your contribution, Achim > > Regards > > François. > > > -- 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#343214: Manpages for lisa and reslisa
On Tuesday 13 December 2005 20:39, François Wendling wrote: > Achim Bohnet wrote: > > > You're using the GFDL for the manpages. This license is considered > > non-free by The Debian Free Software Guidelines (DFSG). > > http://www.de.debian.org/social_contract.en.html#guidelines > > It would be really great if you change the license to, e.g. GPL. > > Otherwise our manpages have to notadded/removed or go into the > > non-free section before the next debian release. > > Modified versions are joined...lisa is licensed under the terms of the GPL, > the associated manpages should be too :) Thx a lot. > > > Mhmm you used resLISa and LISa. Way upstream likes it or typo? > > Upstream, resLISa and LISa are used, but reslisa and lisa too. Some lines > from > the README.gz, written by the author : > > "LISa is intended to provide a kind of "network neighbourhood" but only [...]" > > "lisa and reslisa are distributed under the GNU General Public License." > > IMHO, "lisa" stands for the program, and LISa for the concept. Fine. Thx for the info. Achim > > > François. > > > -- 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]
Re: branches/KDE/3.5/kdebase
On Thursday 22 December 2005 13:49, Script Kiddy wrote: > SVN commit 490585 by scripty: > > Fix FSF address (mainly old address and s/Cambridge/Boston/ ) > (goutte) > > > M +2 -2 debian/local/kdm.options.5 Hi, Is there a reason why branches/KDE/3.5/kdebase/debian is still in KDE svn? Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346310: kmail: Open file as new message for sending, including headers
[...] > It would be nice to be able to use KMail with reportbug, but KMail doesn't > support opening a file as an entire message for sending. It has --msg and > --body, but neither of those reads the headers from the file and sets them > accordingly (e.g. the from, to, and subject headers). It would be really > nice if KMail has an option for it. You are not the first one ;) Bug/wish is reported upstream. Please vote for http://bugs.kde.org/show_bug.cgi?id=89882 Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extragear/multimedia/kmplayer/debian
On Sunday 08 January 2006 18:14, Koos Vriezen wrote:
> SVN commit 495689 by vriezen:
>
> A working shlib would be nice indeed ..
What's breaks when you use
Depends: ${shlibs:Depends}
?
>
>
> M +1 -1 control
>
>
> --- trunk/extragear/multimedia/kmplayer/debian/control #495688:495689
> @@ -14,7 +14,7 @@
> Package: kmplayer-lib
> Architecture: any
> Section: sound
> -Depends: kdelibs4 (>= 4:3.1.0-1) | kdelibs4c2 (>= 4:3.4.0-1), libxine1 |
> libxine1c2, libgstreamer0.8-0, libgstreamer-plugins0.8-0
> +Depends: kdelibs4 (>= 4:3.1.0-1) | kdelibs4c2a (>= 4:3.4.0-1), libxine1 |
> libxine1c2, libgstreamer0.8-0, libgstreamer-plugins0.8-0
That's cheating ;) The same deb can't work in a environment
compiled with g++ < g++ 3.4 _and_ and an environment compiled
with > g++ 4.0.
^^
and at least this should then be libxine1c2a too.
Achim
--
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]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extragear/multimedia/kmplayer/debian
On Sunday 08 January 2006 20:45, Koos Vriezen wrote:
> On Sun, Jan 08, 2006 at 07:56:39PM +0100, Achim Bohnet wrote:
> > On Sunday 08 January 2006 18:14, Koos Vriezen wrote:
> > > SVN commit 495689 by vriezen:
> > >
> > > A working shlib would be nice indeed ..
> >
> > What's breaks when you use
> >
> > Depends: ${shlibs:Depends}
> >
> > ?
>
> I tried that some time ago, and the dependency was empty. Strangly
> enough now trying it again, I do get the dependency:
>
> Depends: kdelibs4c2a (>= 4:3.4.3-1), libaudio2, libc6 (>= 2.3.5-1),
> libfontconfig1 (>= 2.3.0), libfreetype6 (>= 2.1.5-1), libgcc1 (>=
> 1:4.0.2), libglib2.0-0 (>= 2.8.0), libgstreamer-plugins0.8-0 (>= 0.8.0),
> libgstreamer0.8-0 (>= 0.8.11), libice6, libjpeg62, libpng12-0 (>=
> 1.2.8rel), libpopt0 (>= 1.7), libqt3-mt (>= 3:3.3.5), libsm6, libstdc++6
> (>= 4.0.2-4), libx11-6, libxcursor1 (>> 1.1.2), libxext6, libxft2 (>>
> 2.1.1), libxi6, libxine1 (>= 1.0.1), libxinerama1, libxml2 (>= 2.6.21),
> libxrandr2, libxrender1 (>= 1:0.9.0.2), libxt6, zlib1g (>= 1:1.2.1)
Hi Koos,
Great.
>
> I guess I made a mistake back then.
>
> Thanks for reminding,
>
> Koos
>
> Btw. is there anyone that would like to adopt kmplayer for debian
> inclusion. At least for the plugin there is no real alternative. It
> would require a small patch to set xine as default backend (instead of
> mplayer), and maybe a 'powered by debian' intro animation if the
> application would go in as well.
I checked and it looks like noone is working on a debian inclusion.
For ubuntu Tonio_ started polishing it for inclusion but ran out
of time: http://revu.tauware.de/details.py?upid=287
When I asked him for his plan, jpatrick offered to take over.
I'll keep an eye on it.
When kubuntu is pleased with the packaging, I can ask some of the
kubuntu devels that are debian developers too if they are
interested to upload it to debian. If not I contact you again.
Achim
--
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]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bad install defaults for KDElibs
On Friday 12 December 2003 13:31, Thomas Zander wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > in the package kdelibs-data the /etc/kderc file is present (its a > symlink), this is not very nice since that means it becomes impossible to > have another version of KDE running on the same machine. Right. I usualy delete the file. dpkg-divert did not work (tried long ago). > KDE allows multiple versions by using the KDEDIR env-var to be set before > calling startkde. Unfortunately the new (own-compiled) version will then KDEDIR is no solution for Debian because debian follows the fhs and can't install everything under a common root KDEDIR. Next environment var are fragile and error prone. > find the paths to the /usr/bin and /usr/lib and start using that, getting > a nice mix of versions on my desktop. > > I recommend to use KDEDIR and friends instead of the kderc file. No need for KDEDIR(S): KDE std dir lookup includes a) /etc/kderc # used by all KDE installations b) $kdeconf_dir/system.kdeglobals # aka /etc/kde3/ on Debian c) hardcoded stuff in kstandarddirs.cpp(.in) As a) points to b), a) is just a duplicate but at the same time confuses other parallel KDE installations. AFAIR remember most (if not all) vars in system.kdeglobals are identical to compiled in values in kstandarddirs.cpp(.in). All derived from debian/debiandirs file. Summary: get rid of /etc/kderc, Debians KDE will not notice. Achim > > See also: > http://bugs.kde.org/show_bug.cgi?id=70208 > > - -- > Thomas Zander > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQE/2bUVCojCW6H2z/QRAj3fAKCwsoTUqn3a6Hfu00ooi8H4yKHIJQCfSMad > GVbzYuNbQwsKSIo8R8pyXts= > =s6cU > -END PGP SIGNATURE- -- 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]
Re: Bad install defaults for KDElibs
On Friday 12 December 2003 20:29, Chris Cheney wrote:
> On Fri, Dec 12, 2003 at 03:03:40PM +0100, Achim Bohnet wrote:
> > On Friday 12 December 2003 13:31, Thomas Zander wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > Hi,
> > >
> > > in the package kdelibs-data the /etc/kderc file is present (its a
> > > symlink), this is not very nice since that means it becomes impossible to
> > > have another version of KDE running on the same machine.
> >
> > Right. I usualy delete the file. dpkg-divert did not work (tried long
> > ago).
>
> I don't understand why deletion is actually needed as mentioned below,
> but ymmv.
Hi Chris,
yes, mmdv ;) /etc/kderc settings affect all KDE installation on host.
/usr/share/config/system.kdeglobals (aka /etc/kde3/system.kdeglobals)
affects only those with $prefix=/usr, e.g., not the private kde cvs
install of a user.
>
> > > KDE allows multiple versions by using the KDEDIR env-var to be set before
> > > calling startkde. Unfortunately the new (own-compiled) version will then
> >
> > KDEDIR is no solution for Debian because debian follows the fhs and can't
> > install everything under a common root KDEDIR. Next environment var are
> > fragile and error prone.
>
> Indeed, I don't even think if Debian tried to use KDEDIR it would work
> for the reason mentioned below about how kde_confdir works.
>
> > > find the paths to the /usr/bin and /usr/lib and start using that, getting
> > > a nice mix of versions on my desktop.
> > >
> > > I recommend to use KDEDIR and friends instead of the kderc file.
> >
> > No need for KDEDIR(S): KDE std dir lookup includes
> >
> > a) /etc/kderc # used by all KDE installations
> > b) $kdeconf_dir/system.kdeglobals # aka /etc/kde3/ on Debian
> > c) hardcoded stuff in kstandarddirs.cpp(.in)
> >
> > As a) points to b), a) is just a duplicate but at the same time
> > confuses other parallel KDE
> > installations. AFAIR remember most (if not all) vars in system.kdeglobals
> > are identical to compiled in values in kstandarddirs.cpp(.in). All derived
> > from
> > debian/debiandirs file.
>
> If you don't use /etc/kderc and don't store configs in
> $prefix/share/config (iow use /etc/kde3) then KDE will not know where
But Debian stores config in $prefix/share/config -> /etc/kde3, right?
Therefore system.kdeglobals is found and there's no need for /etc/kderc.
> to locate other files since it forces everything to be located under the
> $prefix it was installed in. IOW $kdeconf_dir = $prefix/share/config
> which is hardcoded into the library itself, yes its a f*cking nasty
> hack (KDE is filled with them), but I don't know how to patch around
> it cleanly so I just use the /etc/kderc to override it. Also the KDE
> lookup looks in KDEDIR before /etc/kderc or did the last time I checked.
>
> For example:
>
> /home/ccheney/.kde/bin/:/usr/local/bin/:/usr/bin/
>
> with KDEDIR=/opt/kde3 it should show as:
>
> /home/ccheney/.kde/bin/:/opt/kde3/bin:/usr/local/bin/:/usr/bin/
>
> Am I missing something?
>
> BTW the only things I have listed in system.kdeglobals now are things
> that differ from upstream KDE since I realized the others weren't really
> needed.
>
> > Summary: get rid of /etc/kderc, Debians KDE will not notice.
>
> For reasons noted above KDE definitely would notice...
Not here. Try, with /usr/share/config -> /etc/kde3:
for d in `kde-config --types | awk '{print $1}'`; do kde-config --path $d; done
once with and once without the /etc/kderc -> kde3/system.kdeglobals links
I've never found a difference here.
Achim
>
> Chris
>
--
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]
kde deb pkg questions
Hi, While packaging some kde apps for woody and I run into some annoying problems: o Some Makefile.am use KDE 3.2 xdg_appsdir and destop files end up in /usr/share/applications/kde also for kde 3.1.4. My current workaround is to use in rules make install xdg_appsdir=/usr/share/applnk/Graphics ... Is there an better way? E.g., Makefile.am changes or starting automake with some magic so kde 3.1.4 install in applnk and kde 3.2 installs into applications? o upstream tar balls comes with po/*/*.gmo files. Those are updated during make but not removed by distclean. So a second debuild fails due to binary changes compared to .orig.tar. What's the right way handle this? remove *.gmo files for orig.tar touch gmo files so there are not rebuild modify distclean ? Thx for any advise, Achim -- 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]
Re: Struggling with dpkg-buildpackage with kdebase (latest CVS)
On Sunday 28 December 2003 11:06, Alan Chandler wrote: > I am trying to build myself some up to date debs (in a sid chroot inside my > existing debian system) > > The apidocs part is failing - thus. > > Error: tag HTML_HEADER: header file `../apidocs/common/header.html' does not > exist > make[3]: *** [apidox-am-yes] Error 1 > > In checking up, it appears that ../apidocs/common is a unsatisfied link to > /usr/share/doc/HTML/en/common (the HTML directory does not yet exist in my Hi Alan, Normally KDE docs are installed into /usr/share/doc/kde/HTML (note additional kde/ subdir). HTML dir is one of the dirs where KDEs 'everything below one prefix' does not match FHS with prefix set to /usr. > chroot - despite having installed kdelibs from the freshly built debs) > > The relevent piece of makefile in kdebase/admin/Doxyfile.am seems to be the > following. > > >if test ! -x $(top_builddir)/apidocs/common; then \ > if test -d $(top_srcdir)/doc/common; then \ >common_dir=`cd $(top_srcdir)/doc/common && pwd` ;\ > else \ >common_dir=$(kde_libs_htmldir)/en/common ;\ > fi ;\ > $(LN_S) $$common_dir $(top_builddir)/apidocs/common; \ > fi ;\ > > Which sort of makes me think that $(kde_libs_htmldir) is being set to the > final target rather than the obj-i386-linux build directory during the > building of the debs. I presume in most peoples case they will have > established the /usr/share/docs/HTML hierarchy from previous builds so not > noticed the problem. I had a look at one of my debiandirs files and found only export kde_htmldir=/usr/share/doc/kde/HTML ... configkdevelop=...--with-kdelibsdoc-dir=/usr/share/doc/kdelibs3-doc/html... So kde_libs_htmldir is not set/exported and not defined for configkde. I've not installed kdelibs3-doc so can't check where it's docs are installed. Please check where kdelibs3-doc installs it's docu and add do configkde --with-kdelibsdoc-dir=/usr/share/doc/kdelibs?/html. I guess exporting additionaly kde_libs_htmldir in debiandirs does not hurt. Does this fix the problem? If yes, kde-common/admin/debianrules needs to be updated. > I've scouted around the KDE CVS repository looking for recent relevent > changes > around this area and I can't find any - normally an indication that I am way > off beam with my thinking. Since I am new to this area and on a steep > learnign curve, can anyone shortcut this for me and help me understand why it > is like the way it is (and what needs to change). The KDEs 'everything below' prefix and the quirks used in debian to follow FHS, do not play well together. Untils we find/agree on an algorithm how to handle a KDE installations distrubuted accross a) FHS (easy ;) b) /usr/local c) somewhere else (e.g. /opt or /home/joeUsers/ etc) via KDEDIR(s) and patch kstandarddirs.*.in accordingly the KDE dir layout versus FHS layout issue will catch us again and again. Achim > > -- > Alan Chandler > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#267834: kcontrol: ignored?
On Friday 01 October 2004 11:24, Hendrik Sattler wrote: [...] > being able to with the context menu of a file does not seem to be important > since nobody even answered on this bug report :-(( Hi Hendrik, well, ... I hope you feel better now ;) Please give us all more free time ... > > Updating to KDE-3.3 is not an option. Please consider at least to include sarge-proposed-updates: deb http://ftp.de.debian.org/debian sarge-proposed-updates main contrib non-free Konqueror is there 3.2.3-1.sarge.2 and I can't reproduce the problem. Whenever the buildd on 'excotic' ;) architecutures catch up they'll find their way into sarge. Achim -- 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]
Re: Leaving Debian
On Monday 04 October 2004 09:37, Dominique Devriese wrote: Hi Dominique, it's a pity that you leave! Neverhteless I wish you all the best!! Achim -- 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#275955: kdm/kde shows everything in black/white usually black, and unusable - not an X problem
Hi, what happens when you open the remote login on a host with a xfree 4.3 server? Is it all black there too? (I'll assume you restarted kdm already, right?) As soon as autobuilder work for testing-proposed-updates most of the packages waiting in deb http://ftp.de.debian.org/debian sarge-proposed-updates main contrib non-free will enter sarge. Maybe you can install them the kde debs from t-p-u and check if the kdm problem is already fixed? I tried to remote login window from a host running kde from s-p-u (kdm = 3.2.3-1.sarge.2) and the remote login window looks fine. But I only had radeon X-server to test the remote login window. Achim -- 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#275951: Please split kdmrc into multiple files for ease of maintenance
On Monday 11 October 2004 10:14, Andras Korn wrote: > Package: kdm > Version: 4:3.3.0a-1 > Severity: wishlist > [...] > The split-out configfiles could be merged via an update-kdmrc script. An > even more sophisticated and only slightly more complex approach would be to > have three groups of configfiles: upstream, debian and local, and merge > these so that any options present in a later file override the ones in > earlier files (some grepping can do this). This would really make upgrades a > snap. > > 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 ;) Achim > > Best regards, > > 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]
Bug#275951: Please split kdmrc into multiple files for ease of maintenance
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]
Bug#275951: Please split kdmrc into multiple files for ease of maintenance
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 > <http://chardonnay.math.bme.hu/~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]
Re: RFS(3): kdiff3 - compares and merges 2 or 3 files or directories
On Tuesday 13 January 2004 01:44, Eike \ wrote: > Hello! > > I'm still(*) looking for someone to test and upload the following package. Hi, I've rebuild kdiff3 on woody and had a quick look and test merge. Only strange thing that I could spot is why there are: drwxr-xr-x root/root 0 2004-01-12 02:15:47 ./usr/share/doc/kde/HTML/en/ drwxr-xr-x root/root 0 2004-01-12 02:15:48 ./usr/share/doc/kde/HTML/en/kdiff3/ -rw-r--r-- root/root 21727 2004-01-12 02:13:44 ./usr/share/doc/kde/HTML/en/kdiff3/index.cache.bz2 -rw-r--r-- root/root 70907 2004-01-12 02:11:51 ./usr/share/doc/kde/HTML/en/kdiff3/index.docbook -rw-r--r-- root/root 7856 2003-12-22 09:01:09 ./usr/share/doc/kde/HTML/en/kdiff3/index.html Dupicates of those files + html output + manpage(!) are also in /usr/share/doc/HTML/en/kdiff3 > The diff file has become even smaller because upstream has accepted my > man page in his new version. Well, removing some duplicate docs will make the deb smaller too ;) Nice pkgs, nice app! Achim > kdiff3 is a graphical diff. I think the most useful difference to many > other diff programs is that the difference is shown by character, > not by line. Additionally, it integrates well into KDE. > > Package name: kdiff3 > Version : 0.9.81 > URL : http://kdiff3.sourceforge.net > License : GPL > Description: compares and merges 2 or 3 files or directories > KDiff3 compares two or three input files and shows the differences > line by line and character by character. It provides an automatic > merge facility and an integrated editor for comfortable solving of > merge conflicts. KDiff3 allows recursive directory comparison and > merging as well. > > The package lintian and linda clean. It can be found at: > http://user.cs.tu-berlin.de/~eikes/debian/kdiff3/ > > Ciao, > Eike > > PS: Posted separately to *.mentors and *.qt-kde. > How can I crosspost with gmane? > > (*) My former sponsor seems to be MIA (Rene, are you out there?). > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
simplifying & enhancing kde manpages
Hi,
looking at the kde man pages I note that the qt and kde standrd options
are more or less listed and described. Often they hide the actual
funtionality of the program. There's a good reason for --help-{qt,kde,all}
and not just --help listing everything ;)
My idea now was now to create a
kde-options(?) manpage^Wsgml that describes the generic kde and
qt options (later maybe in more detail). From all other manpages
just use a reference to this manpage.If possible one could
even create templates in kdelibs-dev that are included and allow to
change these generic parts of each kde manpage at a central
place.
Does this sound reasonable?
Anyone knows a kde manpage that has a complete or maybe more
in depth description of the standard options? Otherwise I would
use kde-config.sgml as a start for kde-options.
Btw. is there a script that generates from a --help ouput an sgml
manpage skeleton?
Achim
--
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]
Re: simplifying & enhancing kde manpages
On Tuesday 27 January 2004 23:03, Dominique Devriese wrote: > Achim Bohnet writes: > > > My idea now was now to create a kde-options(?) manpage^Wsgml that > > describes the generic kde and qt options (later maybe in more > > detail). From all other manpages just use a reference to this > > manpage. If possible one could even create templates in kdelibs-dev > > that are included and allow to change these generic parts of each > > kde manpage at a central place. > > > Does this sound reasonable? > > It does to me. It's great that you are going to work on the KDE > program manpages. Especially for command line utilities like dcop*, > this would be really useful. Thx, Ben, Chris, Dominique for the encouraging answers. I've started last night and created kde-options from kde-config, augmenting (well cut and paste) it with descriptions from the qt and kdelibs docs. Then realized, that kdelibs is LGPL and and I'm not sure if QT GPL is compatible with the '...with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.' addition Chris used in his manpages. So it looks like I have to wait a bit and use my own words. Maybe I also ask some KDE developers for an okay to an LGPL -> GPL transition when I find much useful material in the kdelibs docs. Or Chris, in this case would you give your okay to put kde-config under the LGPL? I'm definitly not an good english writer and modifying c&p gives certainly a better result that me formulating the text. > > > Btw. is there a script that generates from a --help ouput an sgml > > manpage skeleton? > > I wrote a script that generates nroff manpage code directly once. > It's currently in kdesdk/scripts/kdemangen.pl. Ah, thx for the info. I'll look into it, if it's easy to change to create sgml, when I'll add manpages to kdebluetooth pkg (currently fighting with --enable-final ;). Achim > > cheers > domi -- 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]
sarge: kde 3.1.5 -> 3.2 (people.debian.org)
Hi,
during update from sarge + sid KDE 3.1.5 + KO 1.3 to Chris&Ben 3.2
the following conflicts occur ('cause pkgs are not in debian
yet I thought I report here). It's just FYI, I'm not complaining.
Thx for working on 3.2 pkgs!!
Achim
Preparing to replace kdelibs-bin 4:3.1.5-1 (using
.../kdelibs-bin_4%3a3.1.95-1_i386.deb) ...
Unpacking replacement kdelibs-bin ...
dpkg: error processing
/var/cache/apt/archives/kdelibs-bin_4%3a3.1.95-1_i386.deb (--unpack):
trying to overwrite `/usr/bin/kfmexec', which is also in package konqueror
Preparing to replace kdelibs-data 4:3.1.5-1 (using
.../kdelibs-data_4%3a3.1.95-1_all.deb) ...
Unpacking replacement kdelibs-data ...
dpkg: error processing
/var/cache/apt/archives/kdelibs-data_4%3a3.1.95-1_all.deb (--unpack):
trying to overwrite `/usr/share/mimelnk/application/mathml+xml.desktop', which
is also in package koffice-data
Unpacking libkdepim1 (from .../libkdepim1_4%3a3.1.95-1_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libkdepim1_4%3a3.1.95-1_i386.deb
(--unpack):
trying to overwrite `/usr/lib/libkdepim.so.1.0.0', which is also in package
kdepim-libs
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Unpacking libkcal2 (from .../libkcal2_4%3a3.1.95-1_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libkcal2_4%3a3.1.95-1_i386.deb
(--unpack):
trying to overwrite `/usr/lib/libkcal.so.2.0.0', which is also in package
kdepim-libs
Preparing to replace libkdenetwork2 4:3.1.5-1 (using
.../libkdenetwork2_4%3a3.1.95-1_i386.deb) ...
Unpacking replacement libkdenetwork2 ...
dpkg: error processing
/var/cache/apt/archives/libkdenetwork2_4%3a3.1.95-1_i386.deb (--unpack):
trying to overwrite
`/usr/share/apps/kconf_update/kpgp-3.1-upgrade-address-data.pl', which is also
in package kgpgcertmanager
Unpacking replacement kdebase-data ...
dpkg: warning - unable to delete old file `/usr/share/applnk/Graphics':
Directory not empty
dpkg: warning - unable to delete old file `/usr/share/applnk/Games': Directory
not empty
dpkg: warning - unable to delete old file `/usr/share/applnk/Development':
Directory not empty
Unpacking konsolekalendar (from .../konsolekalendar_4%3a3.1.95-1_i386.deb) ...
dpkg: error processing
/var/cache/apt/archives/konsolekalendar_4%3a3.1.95-1_i386.deb (--unpack):
trying to overwrite `/usr/bin/konsolekalendar', which is also in package
korganizer
Unpacking libkgantt0 (from .../libkgantt0_4%3a3.1.95-1_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/libkgantt0_4%3a3.1.95-1_i386.deb
(--unpack):
trying to overwrite `/usr/lib/libkgantt.so.0.0.2', which is also in package
kdepim-libs
Unpacking libkpimexchange1 (from .../libkpimexchange1_4%3a3.1.95-1_i386.deb) ...
dpkg: error processing
/var/cache/apt/archives/libkpimexchange1_4%3a3.1.95-1_i386.deb (--unpack):
trying to overwrite `/usr/lib/libkpimexchange.so.1.0.0', which is also in
package kdepim-libs
Preparing to replace ksmserver 4:3.1.5-2 (using
.../ksmserver_4%3a3.1.95-1_i386.deb) ...
Unpacking replacement ksmserver ...
dpkg: error processing /var/cache/apt/archives/ksmserver_4%3a3.1.95-1_i386.deb
(--unpack):
trying to overwrite `/etc/gdm/Sessions/KDE', which is also in package kwin
Preparing to replace kwin 4:3.1.5-2 (using .../kwin_4%3a3.1.95-1_i386.deb) ...
Unpacking replacement kwin ...
dpkg: warning - unable to delete old file `/etc/kde3/debian': Directory not
empty
dpkg: warning - unable to delete old file `/etc/gdm/Sessions': Directory not
empty
dpkg: warning - unable to delete old file `/etc/gdm': Directory not empty
--
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]
ro svn checkout of svn.debian.org/svn/pkg-kde/
Hi, what's the method to check out a ro copy of svn pkg-kde repository at svn.debian.org/svn/pkg-kde/ o http: and https: always return 405 Method Not Allowed (okay webdav disabled as mention on the home page ;) o svn claims no repository found o svn+ssh://[EMAIL PROTECTED] does not accept my alioth account o svn manual does not help any more :( What do I wrong? Btw. what's the status/usage of debian/ in KDE's cvs and pkg-kde at alioth? Chris pkgs: KDE 3.2 for woody in kde cvs KDE 3.2 for sid in pkg-kde Ben everything in kde-cvs Right? Achim -- 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]
Re: ro svn checkout of svn.debian.org/svn/pkg-kde/
On Thursday 12 February 2004 04:59, Chris Cheney wrote: > On Wed, Feb 11, 2004 at 11:42:13PM +0100, Achim Bohnet wrote: > > Hi, > > > > what's the method to check out a ro copy of svn pkg-kde repository > > at svn.debian.org/svn/pkg-kde/ > > o http: and https: always return 405 Method Not Allowed > > (okay webdav disabled as mention on the home page ;) > > o svn claims no repository found > > o svn+ssh://[EMAIL PROTECTED] does not accept my alioth account > > o svn manual does not help any more :( > > What do I wrong? > > http is disabled as mentioned on the svn.debian.org main page. If I > remember correctly to check out anonymously you need to do something > like: > > svn co svn://svn.debian.org/pkg-kde/trunk Ahhh, http: URL on svn.debian.org had an additonal /svn in the path that has to be removed in the svn: URL. Thx!! > to do a regular checkout you need to do: > > svn co svn+ssh://svn.debian.org/svn/pkg-kde/trunk > > you can't put your username in the URL, you can either setup the special > svn way (I forgot what its called) or you add something like the > following to your .ssh/config file: > > Host svn.debian.org > User ccheney > > The other svn way is explained in the svnbook. Neither the .ssh/config, user@ nor --username does work with svn+ssh: (always the same error msg). So I assume that svn+ssh: mean rw access and that's of course denied (no problem for me). > > > Btw. what's the status/usage of debian/ in KDE's cvs and pkg-kde > > at alioth? > > > > Chris pkgs: > > KDE 3.2 for woody in kde cvs > > KDE 3.2 for sid in pkg-kde > > I will probably remove the debian dirs from my packages at kde.org soon > unless there is a pressing reason for it to be there. Ralf? Achim > > > Ben > > everything in kde-cvs > > Right? > > Yes at this time. > > > Chris > -- 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]
Re: pkg-kde: commit - rev 33 - people/jd/scripts
On Friday 13 February 2004 12:35, David Pashley wrote: > On Feb 12, 2004 at 23:15, Chris Cheney praised the llamas by saying: > > On Thu, Feb 12, 2004 at 05:53:52PM +0100, David Pashley wrote: > > > Author: jd-guest > > > Date: 2004-02-12 17:53:52 +0100 (Thu, 12 Feb 2004) > > > New Revision: 33 > > > > > > Added: > > >people/jd/scripts/check-replaces > > > Removed: > > >people/jd/scripts/check-conflicts.pl > > > Log: > > > It has come to my attention that I want to use Replaces, not Conflicts. > > > script renamed and altered to read Replaces. The concept that a package > > > conflicts with another package if they contain the same file is kept. [..] > > Also, as domi said when you use svn you should move the file not > > add/remove so that changes can be tracked. :) > > > I did an svn move check-conflicts.pl check-replaces. that is what it > did. Not sure if it kept the history. I was curious: yes history is kept. svn -v svn also list that A comes from a rename r33 | jd-guest | 2004-02-12 17:53:52 +0100 (Thu, 12 Feb 2004) | 4 lines Changed paths: D /people/jd/scripts/check-conflicts.pl A /people/jd/scripts/check-replaces (from /people/jd/scripts/check-conflicts.pl:31) It has come to my attention that I want to use Replaces, not Conflicts. script renamed and altered to read Replaces. The concept that a package conflicts with another package if they contain the same file is kept. ... Can't be svn -v log -r used for the commit mails (without ^---)? Or is the transaction not commited at this time? Achim > > > Chris > > > > -- > David Pashley > [EMAIL PROTECTED] > Nihil curo de ista tua stulta superstitione. > -- 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]
debiandir
Hi, I've seen Chris updating debianrules CVS and wondered how to handle this in other kde pkgs. I had a look that svn trunk: debiandirs is ... o is not in svn o created and removed by rules o -included'ed in rules file. What confused me is that for the first run -include debian/debiandirs can't succeed because it not there. The debian/debiandir rule that creates the file does not fail (to force another build run). Now configure would be called with an empty config_kde. So shouldn't the debiandir rules read: debian/debiandirs: admin/debianrules perl -w admin/debianrules echodirs > debian/debiandirs false to force another debuild run with an existing debian/debiandirs? Achim -- 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]
enable-final
Hi, new debianrules does not set --enable-final. Any special reason why it's no longer the default? Achim -- 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]
kdeextragear-3/kdebluetooth/debian
CVS commit by ach: Fix rules so debuild works in extragear environment M +18 -7 rules 1.5 --- kdeextragear-3/kdebluetooth/debian/rules #1.4:1.5 @@ -12,10 +12,20 @@ DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +ifeq "$(wildcard ./admin)" "" +# Builds in kdeextragear-3 +CVS_BUILD=true +deb_cfg_dir=.. +deb_src_dir=. +else +# ./admin exists -> build outside kdeextragear-3 +deb_cfg_dir=. +deb_src_dir=kdebluetooth +endif + -include debian/debiandirs -debian/debiandirs: admin/debianrules -perl -w admin/debianrules echodirs > debian/debiandirs +debian/debiandirs: $(deb_cfg_dir)/admin/debianrules +perl -w $(deb_cfg_dir)/admin/debianrules echodirs > debian/debiandirs -CVS_BUILD=true ifneq (, $(findstring true,$(CVS_BUILD))) configkde += --enable-debug=full @@ -38,5 +48,5 @@ # # # run configure with build tree $(objdir) -./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) $(configkde) +cd $(deb_cfg_dir) && ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) $(configkde) touch configure-stamp @@ -61,12 +71,13 @@ dh_testroot rm -f build-stamp configure-stamp +rm -f debian/debianrules # Add here commands to clean up after the build process. -$(MAKE) distclean ifneq "$(wildcard /usr/share/misc/config.sub)" "" -cp -f /usr/share/misc/config.sub config.sub +cp -f /usr/share/misc/config.sub $(deb_cfg_dir)/config.sub endif ifneq "$(wildcard /usr/share/misc/config.guess)" "" -cp -f /usr/share/misc/config.guess config.guess +cp -f /usr/share/misc/config.guess $(deb_cfg_dir)/config.guess endif @@ -92,5 +103,5 @@ dh_testdir dh_testroot -dh_installchangelogs ChangeLog +dh_installchangelogs $(deb_src_dir)/ChangeLog dh_installdocs dh_installexamples
Re: debiandir
On Tuesday 17 February 2004 02:29, Ben Burton wrote: > > > I'm no expert in makefiles but doesn't the include cause the > > debian/debiandirs call to be made? > > This is the way it has always worked for me. > > (i.e., the include calls the file to be made and then included in the > same "make" run). O, right hand side of include is generated if missing (file:/usr/share/doc/make-doc/make_3.html#SEC16). And it looks like variable expansion is done later. allee(0) ~ $ cat mm -include mm.inc mm.inc: /bin/echo /bin/echo bla="hello " > mm.inc all: echo $(bla)world allee(0) ~ $ rm mm.inc ; make -f mm all /bin/echo bla="hello " > mm.inc echo hello world hello world allee(0) ~ $ So everything should be fine. Achim > > Ben. -- 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]
Re: kdeextragear, and kdenonbeta
On Wednesday 18 February 2004 16:40, Alejandro Exojo wrote: > Hi. > > I know that kdeextragear* and kdenonbeta are not official KDE modules, but > some applications are packaged for Debian, but some interesting others > (kimdaba, amarok, ...) are not. Well there are no official pkgs, but ;) I've announced woody/sid kimdaba KDE 3.2 pkg on the kimdaba list. And I've on my system a amorak pkg. AFAIR I've found them on the amarok home page. I hope that kalyxo.org will sometime in the future provide a pool of all those non-official kde pkgs for woody and sarge (when sarge is called stable) ;) Achim > I'm packaging konserve [*], which is in kdenonbeta, and upstream will release > a new version next monday. I realized that working without a SVN/CVS > repository is a bit tricky, so I considered different options: > > a) Use a local repository in my machine. Problem: it doesn't allows others to > check my sources. > b) Open an alioth project, as many others, just for konserve. Problem: I plan > to package others in the future, as soon as my skills improve, and I don't > want to create a project for each. > c) Use KDE's CVS repository. > d) Ask Qt/KDE mantainers what's their opinion. Maybe someday my package moves > to an official module, and it's interesting to keep history. I don't know > possible benefits or possible problems of this option, so that's the reason > I'm asking to you ;-). > > Any suggestions? > Thanks in advance. > > > [*] It isn't in Debian yet because my sponsor is at Malaga's conference, and > he has been a bit busy this days, but a lot of initial minor fixes had been > done. If you are curious: > > deb http://darkshines.net/debian unstable konserve > deb-src http://darkshines.net/debian unstable konserve > > -- > Alex > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#233775: kdm stores/uses config files in /usr/share/config/kdm
Package: kdm Version: 4:3.2.0-0pre1v1 Severity: normal kdm 3.2.0 from people repo installs config files in /usr/share/config/kdm. The files in this this have additional hardcoded path to the same dir. Unfortunately /usr/share/config is _not_ a link to /etc/kde3 but a real dir. Strange is that kdm ignores the /etc/kde3/kdm/kdmrc despite the fact that kde-config --path config lists: /root/.kde/share/config/:/etc/kde3/:/usr/share/config/ Proposed solution: Continue to not install /etc/kderc and make /usr/share/config a link to /etc/kde3. Additionally the patch in kdm/* should be adjusted to use /etc/kde3/... paths and not /usr/share/config. Achim -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux allee 2.4.22-20030830-marlow #1 l�r aug 30 21:17:29 CEST 2003 i686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages kdm depends on: ii debconf 1.3.22 Debian configuration management sy ii kdelibs4 4:3.2.0-0pre1v1 KDE core libraries ii libart-2.0-2 2.3.16-1Library of functions for 2D graphi ii libc62.3.2.ds1-11GNU C Library: Shared libraries an ii libfam0c102 2.6.10-6client library to control the FAM ii libgcc1 1:3.3.3-0pre3 GCC support library ii libpam0g 0.76-15 Pluggable Authentication Modules l ii libpng12-0 1.2.5.0-4 PNG library - runtime ii libqt3c102-mt3:3.2.3-2 Qt GUI Library (Threaded runtime v ii libstdc++5 1:3.3.3-0pre3 The GNU Standard C++ Library v3 ii libxrender1 0.8.3-5 X Rendering Extension client libra ii xbase-clients4.2.1-12.1 miscellaneous X clients ii xlibs4.2.1-12.1 X Window System client libraries ii zlib1g 1:1.2.1-3 compression library - runtime -- debconf information excluded -- 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#233775: kdm stores/uses config files in /usr/share/config/kdm
On Thursday 19 February 2004 23:53, Chris Cheney wrote: > On Thu, Feb 19, 2004 at 11:08:50PM +0100, Achim Bohnet wrote: > > Package: kdm > > Version: 4:3.2.0-0pre1v1 > > Severity: normal > > > > > > kdm 3.2.0 from people repo installs config files in /usr/share/config/kdm. > > The files in this this have additional hardcoded path to the same dir. > > Unfortunately /usr/share/config is _not_ a link to /etc/kde3 but a real > > dir. > > > > Strange is that kdm ignores the /etc/kde3/kdm/kdmrc despite the fact > > that kde-config --path config lists: > > /root/.kde/share/config/:/etc/kde3/:/usr/share/config/ > > > > Proposed solution: Continue to not install /etc/kderc and make > > /usr/share/config > > a link to /etc/kde3. Additionally the patch in kdm/* should be > > adjusted to use /etc/kde3/... paths and not /usr/share/config. > > Installing directly into /etc/kde3 is not a good solution for the > upstream "config" files since dpkg at various times decides not to > install the config files at all, which completely breaks KDE. This has > been the source of problems with KDE in Debian for a long time. However, > I will bug upstream about the problem with respect to it not looking in > kde-config --path config. Unfortunately that's no solution (IMHO). First time KDE users would have an empty /etc/kde3 and therefore even installing, e.g., and Xservers file in /etc/kde3/kdm does not help because kdmrc explicitely refers to Xservers in /usr/share/config/kdm. Second: to customize things one would have to do a cp /usr/share/config/ /etc/kde3/ and the edit it. Aren't we here in trouble with policy?! AFAIU only reason for dpkg not to install a config file is when the old and new pkg had the config file but the config file does not exist when a pkg was updated. But then the apps did also not work before the update. So either dpkg has a not yet reported RC bug or KDE upgrade is broken. Anyone recall another reason dpkg does not install a config file beside the one I described above? Achim > > Chris > -- 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]
Re: admin/debianrules kde_configdir issue
On Wednesday 25 February 2004 11:01, Chris Cheney wrote: > I am trying to decide whether I should revert the move of kde_configdir > from /etc/kde3 to /usr/share/config that was changed in experimental. It > has caused at least one noticable problem, kdm doesn't use the normal > kde path lookup like everything else so you can't override its config > files in /etc/kde3. It also is probably a policy violation to have config > files in /usr/share even though they can be overriden in /etc/kde3. Also > since the config files disappeared from /etc/kde3 upgrades from earlier > kde 3.x releases will keep their old config files in /etc/kde3 and use > them instead of the newer ones in /usr/share/config. > > If I revert back to /etc/kde3 I think I will need to make a symlink from > /usr/share/config -> /etc/kde3 so that I still won't need /etc/kderc and > /etc/kde3/system.kdeglobals. I will probably also need to check and > remove any existing /etc/kderc /etc/kde3/system.kdeglobals files... > > Any comments? Hi Chris, I still think that /etc/kde3 & /usr/share/config symlink & ... is the right thing (tm) to do. I'll agree with Ben that migration can be a bit tricky. Are packages in experimental required to provide a smooth upgrade path too? Btw: is Xfree86 4.3 a release goal for sarge? Some of the experimental kde 3.2 pkgs depend already on 4.3. Achim > > Thanks, > Chris -- 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]
Re: Bug#236045: kdeprint: kprinter locks up when print is pressed
On Thursday 04 March 2004 00:34, Mark Hymers wrote: > Package: kdeprint > Version: 4:3.1.5-2 > Severity: normal > > > When I attempt to print anything from kprinter, the program > locks up when I press the print button. I've tried printing > a .ps file which prints fine using lp from cups, printing from > kate and kjots. I've tried printing to my printer and printing > to a PDF file. Once print is pressed, the window stops responding > and doesn't update itself (e.g. if you minimise then restore it). > There are no error messages displayed (when run from the command line). > > Any suggestions about how to go about fixing this problem? How did you start kprinter? If kprinter thinks it should read stdin, kprinter hangs after pressing 'Print'. Using ^D in the shell window, kicks kprinter back to life. Achim > > Thanks > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: i386 (i686) > Kernel: Linux 2.6.3-1-k7 > Locale: LANG=C, LC_CTYPE=C > > Versions of packages kdeprint depends on: > ii enscript1.6.4-3 Converts ASCII text to > Postscript, > ii gv 1:3.5.8-31 A PostScript and PDF viewer for > X > ii kdelibs44:3.1.5-1KDE core libraries > ii libart-2.0-22.3.16-1 Library of functions for 2D > graphi > ii libaudio2 1.6c-1 The Network Audio System (NAS). > (s > ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5 client library to control the > FAM > ii libfontconfig1 2.2.1-16 generic font configuration > library > ii libfreetype62.1.7-2 FreeType 2 font engine, shared > lib > ii libgcc1 1:3.3.3-1GCC support library > ii libpng12-0 1.2.5.0-5PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime > v > ii libstdc++5 1:3.3.3-1The GNU Standard C++ Library v3 > ii libxcursor1 1.0.2-4 X Cursor management library > ii libxft2 2.1.2-5 FreeType-based font drawing > librar > ii libxrender1 0.8.3-5 X Rendering Extension client > libra > ii poster 20020830-2 Create large posters out of > PostSc > ii psutils 1.17-17 A collection of PostScript > documen > ii xlibmesa-gl [libgl1]4.3.0-3 Mesa 3D graphics library > [XFree86] > ii xlibs 4.3.0-3 X Window System client libraries > m > ii zlib1g 1:1.2.1-4compression library - runtime > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
Re: KDE_3_2_BRANCH: kdegraphics/kpdf
On Friday 12 March 2004 17:37, Stephan Kulow wrote: > CVS commit by coolo: > > try to find /etc/kpdfrc > > > M +6 -1 configure.in.in 1.5.2.1 > > > --- kdegraphics/kpdf/configure.in.in #1.5:1.5.2.1 > @@ -37,4 +37,9 @@ > AC_SUBST(LIBPAPER_LIBS) > > - > AC_CHECK_FUNCS(fseek64 mkstemp mkstemps popen) > + > +AC_FIND_FILE(xpdfrc, [/etc /usr/local/etc], xpdfrc) Care to add /etc/xpdf/? Debian stores xpdfrc there. Achim > +if test "$xpdfrc" != NO; then > + AC_DEFINE_UNQUOTED(SYSTEM_XPDFRC, "$xpdfrc/xpdfrc", [Define the location > your xpdfrc]) > +fi > + > > > > -- 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#238135: keyboard shortcuts ctrl+[ and ctrl+] don't work when konqueror started from the menu
On Monday 15 March 2004 15:27, Amit Shah wrote: > Package: konqueror > Version: 4:3.2.1-1 > Severity: normal > > A very queer bug: Ctrl+[ and Ctrl+] don't work when konqueror is started > from the K menu. When konqueror is started from the run command dialog > (Alt+F2), the keyboard shortcuts work fine. Crtl-[ and Crtl-] work as expected here (testing + KDE 3.2.1 + xf 4.3 from unstable) when started from k-menu or kicker and command line. I created the second tab with ctrl-shift-n and with file-> new tab. Achim > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.3-mm3 > Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 > > Versions of packages konqueror depends on: > ii kcontrol4:3.2.1-1KDE Control Center > ii kdebase-kio-plugins 4:3.2.1-1KDE I/O Slaves > ii kdelibs44:3.2.1-1KDE core libraries > ii kdesktop4:3.2.1-1KDE Desktop > ii kfind 4:3.2.1-1KDE File Find Utility > ii libart-2.0-22.3.16-1 Library of functions for 2D > graphi > ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5 client library to control the > FAM > ii libgcc1 1:3.3.3-2GCC support library > ii libice6 4.3.0-5 Inter-Client Exchange library > ii libjpeg62 6b-9 The Independent JPEG Group's > JPEG > ii libkonq44:3.2.1-1Core libraries for KDE's file > mana > ii libpcre34.5-1.1 Perl 5 Compatible Regular > Expressi > ii libpng12-0 1.2.5.0-5PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime > v > ii libsm6 4.3.0-5 X Window System Session > Management > ii libstdc++5 1:3.3.3-2The GNU Standard C++ Library v3 > ii libx11-64.3.0-5 X Window System protocol client > li > ii libxext64.3.0-5 X Window System miscellaneous > exte > ii libxrender1 0.8.3-7 X Rendering Extension client > libra > ii xlibs 4.3.0-5 X Window System client libraries > m > ii zlib1g 1:1.2.1-5compression library - runtime > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#237026: Please support a kind of polling for xdms
On Tuesday 09 March 2004 13:12, Torsten Knodt wrote: > Package: kdm > Severity: wishlist > Tags: sid > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > first, as far as I understood, kdm is a fork of xdm. Thats why I filed this > wish against kdm. If not, please reassign to xdm. > It would be nice, if there would be a way to poll for other xdms, which cant > be reached by broadcasts. Polling xdms? If you mean getting a chooser or login window from another host, that's not the task of kdm but of the xserver. Or > According to the xaccess help, there is only one entry matching. As a change > of minimal impact, I suggest to extend the CHOOSER syntax in a way, that > BROADCAST isnt an alternate to the host list, but a reserved word in the > list. If you mean that the chooser is provided by the local kdm, search for ChooserHosts in /etc/kde3/kdm/kdmrc and you'll find your wish already implemented. Let us know if this fixes you wishlist. Achim > > With kind regards > Torsten > > - -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (990, 'unstable') > Architecture: ? (i586) > Kernel: Linux 2.6.3 > Locale: LANG=C, LC_CTYPE=C > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFATbSpX1/CjdwsodIRAv3cAJ4mH6IVc24ckipvHje6Il9ZeyMe/QCbB15t > 1bSM7Ql7RElUcQzGBqiStSA= > =dLE7 > -END PGP SIGNATURE- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
Re: Bug#240288: KDE 3.2.1 -> Debian Testing?
On Wednesday 31 March 2004 17:51, Dominique Devriese wrote: > > CC'ing the kdelibs and kdebase maintainer to hear his opinion on the > issue. Please keep the CC to #240288. > > Clemens Brunner writes: > > > Hi Dominique! I've been waiting for KDE 3.2.1 to move into Debian > > Testing for weeks now, and it finally seemed to happen - until you > > filed your fake bug, saying that you thought it was probably not a > > good idea to move kdelibs into Testing. > > Yes, I'm sorry, I should have provided more info in the report, but I > had little time when I was writing it. > > > Could you explain why you filed that bug? > > kdebase is not yet ready for testing, and it's not a good idea for > sarge to have a different kdebase than kdelibs version, for various > reasons. I just want to avoid the sarge release hitting us at a point > where kdelibs is at 3.2, and kdebase at 3.1. If kdebase is ready, I > have no problem with both propagating to testing. How about the combination arts 1.2 from KDE3.2.1 release + KDE* 3.1.5 I've just seen on debian-release: snip- On Sun, Mar 28, 2004 at 10:42:50PM -0500, Nathanael Nerode wrote: > These should both work right now. > easy mono/0.30.2-1 mcs/0.30.2-1 > easy arts/1.2.1-2 xmms-arts/0.7.1-1 Added. -- Steve Langasek postmodern programmer snap- AFAIU this means arts from 3.2.1 enters testing in two days according to http://packages.qa.debian.org/a/arts.html. Does this make sense without kde* 3.2.1? Achim -- 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]
Re: pkg-kde: commit - rev 93 - in trunk/packages/kdelibs/debian: . dh-make
On Tuesday 06 April 2004 01:18, Dominique Devriese wrote: > Author: domi-guest > Date: 2004-04-05 17:17:58 -0600 (Mon, 05 Apr 2004) > New Revision: 93 > > Modified: >trunk/packages/kdelibs/debian/Packaging.txt >trunk/packages/kdelibs/debian/changelog >trunk/packages/kdelibs/debian/dh-make/menu.ex > Log: > debian/Packaging.txt, debian/dh-make/menu.ex: Added quotes to the menu > file examples. Hi Dominique, Chris, care to update the build-depend examples from kde 2.1.1 to 3.2.2? So it looks uptodate and not out of date. Achim > > > > Modified: trunk/packages/kdelibs/debian/Packaging.txt > === > --- trunk/packages/kdelibs/debian/Packaging.txt 2004-04-05 21:09:53 UTC > (rev 92) > +++ trunk/packages/kdelibs/debian/Packaging.txt 2004-04-05 23:17:58 UTC > (rev 93) > @@ -35,8 +35,8 @@ > With that said a typical menu file would look like this: > > ?package(konqueror):\ > -needs=x11\ > -section=Apps/Net\ > +needs="x11"\ > +section="Apps/Net"\ > hints="KDE,Web browsers"\ > title="Konqueror"\ > command="kfmclient openProfile webbrowsing" > > Modified: trunk/packages/kdelibs/debian/changelog > === > --- trunk/packages/kdelibs/debian/changelog 2004-04-05 21:09:53 UTC (rev 92) > +++ trunk/packages/kdelibs/debian/changelog 2004-04-05 23:17:58 UTC (rev 93) > @@ -1,7 +1,9 @@ > kdelibs (4:3.2.1-2) unstable; urgency=low > > - * Removed references to the obsolete kderemove menu tag in kdelibs' > -documentation. > + * debian/Packaging.txt, debian/dh-make/menu.ex: Removed references to > +the obsolete kderemove menu tag in kdelibs' documentation. > + * debian/Packaging.txt, debian/dh-make/menu.ex: Added quotes to the menu > +file examples. > > -- > > > Modified: trunk/packages/kdelibs/debian/dh-make/menu.ex > === > --- trunk/packages/kdelibs/debian/dh-make/menu.ex 2004-04-05 21:09:53 UTC > (rev 92) > +++ trunk/packages/kdelibs/debian/dh-make/menu.ex 2004-04-05 23:17:58 UTC > (rev 93) > @@ -1,2 +1,2 @@ > -?package(#PACKAGE#):needs=X11|text|vc|wm section=Apps/see-menu-manual\ > +?package(#PACKAGE#):needs="X11|text|vc|wm" section="Apps/see-menu-manual"\ >title="#PACKAGE#" hints="KDE" command="/usr/bin/#PACKAGE#" > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
Re: pkg-kde: commit - rev 90 - in trunk/packages/kdelibs/debian: . dh-make
On Tuesday 06 April 2004 02:32, Christopher Martin wrote: > On April 5, 2004 08:05 pm, Ben Burton wrote: > > IMO it's still worth encouraging it in Packaging.txt - even KDE users > > encouter the missing icons nowadays in the Debian menu, where all the > > KDE apps are duplicated (AIUI). And for people who don't use KDE (or > > GNOME?), unless we supply icons in the debian menu files, they won't > > have any icons for these KDE apps at all. > > > > Even if you're not adding icons to kdebase right now, it's still worth > > encouraging packagers of new apps to do it properly. :) > > While we're on the subject of good practice, I've also noticed that > the .desktop files that constitute the KDE menu are spread > between /usr/share/applications/kde and /usr/share/applnk. Both locations > seem to work, but is there a preferred standard? I've always used applnk, > but with 3.2 applications/kde seems to have become more popular. If there > is a preferred place, then this might be worth mentioning in > Packaging.txt as well. .desktop files in /usr/share/applications and /usr/share/applnk are not identical. So there is only one 'right' location depending if it follows 'old' kde desktop files rules or new 'xdg' rules. Of course the prefered way (tm) are now xdg compliant desktop files. That has the advantage that at least in gnome all kde apps should have an icon without adding 84 times xpm them in debian specific .menu files ;) (A kde desktop files has normally also much translations) Achim Achim > > Thanks, > Christopher Martin > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
Re: RFS: Need a sponsor for my konversation package
On Tuesday 06 April 2004 17:05, Dominique Devriese wrote: [...] > > and AFAICT, the kde.mk class in cdbs contains more up-to-date > > best-packaging-practices. Hi Nathaniel Maybe you can write a small paragraph for inclusion in Packages.txt about CDBS replacement of the dh_make rules file? > > Oh, I see, I didn't notice that you were using CDBS... Never mind > then :) Achim -- 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]
Re: pkg-kde: commit - rev 90 - in trunk/packages/kdelibs/debian: . dh-make
On Tuesday 06 April 2004 19:18, Dominique Devriese wrote: > > calc, scroll to the bottom :) > > Christopher Martin writes: > > >> > If there is a preferred place, then this might be worth > >> > mentioning in Packaging.txt as well. > >> > >> AIUI, Packaging.txt is about packaging a normal, well-behaving kde > >> app. These use the kde build system, and as such, should > >> automatically choose the right location, no ? > > > Hmmm, I've built packages (3rd party/extragear stuff) that, by > > default, use either. oKle - applnk. Gwenview - > > applications/kde. Those using applnk may be in need of an update, > > either upstream or in the packaging, certainly, but for whatever > > reason plenty of apps still do use applnk (K3b and kopete, for > > instance), and may not bother to change since everything still > > appears to be working fine. > > The Kopete developers consciously decided to not use the new dir, > because they still support KDE 3.1. I'm not sure about the rest. In > any case, if you encounter a package that uses applnk, that didn't > consciously decide to do so, then it's most probably a bug in the > Makefile.am. For example, in August, someone committed this change to > kdeedu/kig/kig/Makefile.am: > diff -u -r1.23 -r1.24 > --- Makefile.am 27 Jun 2003 12:26:56 - 1.23 > +++ Makefile.am 29 Aug 2003 19:59:44 - 1.24 > @@ -27,8 +27,7 @@ > kig_LDADD = $(LIB_KPARTS) > > # this is where the desktop file will go > -shelldesktopdir = $(kde_appsdir)/Edutainment/Mathematics > -shelldesktop_DATA = kig.desktop > +xdg_apps_DATA = kig.desktop > > # this is where the shell's XML-GUI resource file goes > shellrcdir = $(kde_datadir)/kig > The upstream authors should do something similar ( and make sure they > have a recent admin/ dir, so that xdg_appsdir is defined, of course ). .. and make sure the desktop file has a Categories= entry. Because that whats used AFAIU to put the app in a (sub)menu. http://www.freedesktop.org/standards/menu-spec/menu-spec-0.8.html http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html Achim > > > Thus a small mention in Packaging.txt might help to nudge packagers > > (especially new packagers) towards the correct location, in case > > their sources still default to applnk, for whatever reason. > > Agreed, care to write the patch, perhaps ? > > > Perhaps also the /u/s/doc/kdelibs4-dev/dh-make/debiandirs should add > > the following: > > export kde_appsdir=/usr/share/applications/kde > > No, this would be wrong. > > > The only problem with this is that apps that had hitherto created a > > subdirectory in /u/s/applnk (like Multimedia, or Graphics) would now > > do the same in /u/s/applications/kde... > > Indeed. > > > One final thing. Packaging.txt currently contains an elaborate > > description of how to take the kdelibs4-dev "debianrules" script, > > place it in MYPACKAGE_SRCDIR/debian/ and convert it, using perl, > > into the debian/debiandirs file which then sets crucial > > variables. However, kdelibs4-dev doesn't provide debianrules > > anymore, but debiandirs directly (in the dh-make directory), so > > unless I'm mistaken there's no need for any perl kung-fu. > > > All I've been doing is copying the > > /u/s/doc/kdelibs4-dev/dh-make/debiandirs file into > > MYPACKAGE_SRCDIR/debian/ and then adding: > > > -include debian/debiandirs > > > in debian/rules before any targets are defined, and it works > > well. > > > Am I doing something wrong, or can the Packaging.txt > > instructions be simplified? > > Well, I agree with you that either debianrules should be installed > instead of debiandirs, or Packaging.txt should be adapted. I'm not > certain what calc wanted to do, but installing debianrules instead of > debiandirs seems like the best solution to me personally. Anyway, > calc, please shed some light on this ! > > cheers > domi > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#242520: kmail: temporary solution
On Wednesday 07 April 2004 18:00, Gal Ben-Haim wrote: > a temporary solution is to set the environment variable > KDE_UTF8_FILENAMES=true, and to run kmail with: env LANG=he_IL kmail > appearntly this fixes the problem + another problem that outgoing > messages are by default encoded with UTF-8, which is not widely used > with hebrew messages and needed to be changed on each outgoing message > to either ISO8859-8-I or to CP1255, I guess that a pernament solution > will be to have config options for default locale, like in Hmm, doesn't this do what you want for outgoing mails?: Settings -> Configure kmail ... -> Composer -> Charset Just add ISO8859-8-I and CP1255 before utf. Achim > mozilla-thunderbird where you can set the default incoming and outgoing > locales.. > > > -- System Information: > Debian Release: testing/unstable > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.4-1-686 > Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 > > Versions of packages kmail depends on: > ii kdebase-kio-plugins 4:3.2.1-1KDE I/O Slaves > ii kdelibs44:3.2.1-1KDE core libraries > ii ktnef 4:3.2.1-1KDE TNEF viewer > ii libart-2.0-22.3.16-3 Library of functions for 2D > graphi > ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5 client library to control the > FAM > ii libgcc1 1:3.3.3-6GCC support library > ii libice6 4.3.0-7 Inter-Client Exchange library > ii libjpeg62 6b-9 The Independent JPEG Group's > JPEG > ii libkcal24:3.2.1-1KDE calendaring library > ii libkdenetwork2 4:3.2.1-1KDE Network library > ii libkdepim1 4:3.2.1-1KDE PIM library > ii libksieve0 4:3.2.1-1KDE mail/news message filtering > li > ii libmimelib1 4:3.2.1-1KDE mime library > ii libpcre34.5-1.1 Perl 5 Compatible Regular > Expressi > ii libpng12-0 1.2.5.0-5PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime > v > ii libsm6 4.3.0-7 X Window System Session > Management > ii libstdc++5 1:3.3.3-6The GNU Standard C++ Library v3 > ii libx11-64.3.0-7 X Window System protocol client > li > ii libxext64.3.0-7 X Window System miscellaneous > exte > ii libxrender1 0.8.3-7 X Rendering Extension client > libra > ii xlibs 4.3.0-7 X Window System client libraries > m > ii zlib1g 1:1.2.1-5compression library - runtime > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#242614: kppp: Customizable Device List
On Wednesday 07 April 2004 19:54, Benoit Panizzon wrote: > Package: kppp > Version: 4:3.1.5-1 > Severity: wishlist > > > Yo kppp Maintainer. > > I use a System with IRDA, Bluetooth and an Lucent Winmodem (Linmodem) > Those serial Devices are called > > /dev/ircomm0 > /dev/rfcomm0 > /dev/LTmodem fixed-upstream! In kppp of KDE 3.2.1 ircomm and rfcomm are included by default. And it's possible to add more (e.g., I added /dev/ttySHSF0). Achim > > and are not included in kppp's device list. > The easy solution is just to add a softlink from /dev/modem to the wanted > device. > But as I use all three connections quite often, I get a bit annoyed to change > that symlink every time I want to use > another device. > > As I read, the device list displayed by kppp is hardcoded in the headers > depending on the os kppp is compiled on. > > Would it be possible for further releases to add a user expandable device > list that would be saved in kppprc? > > -Benoit- > > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (500, 'testing') > Architecture: i386 (i686) > Kernel: Linux 2.6.5 > Locale: LANG=de_CH, LC_CTYPE=de_CH > > Versions of packages kppp depends on: > ii kdelibs44:3.1.5-1KDE core libraries > ii libart-2.0-22.3.16-3 Library of functions for 2D > graphi > ii libaudio2 1.6c-3 The Network Audio System (NAS). > (s > ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5 client library to control the > FAM > ii libfontconfig1 2.2.2-1 generic font configuration > library > ii libfreetype62.1.7-2 FreeType 2 font engine, shared > lib > ii libgcc1 1:3.3.3-5GCC support library > ii libpng12-0 1.2.5.0-5PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime > v > ii libstdc++5 1:3.3.3-5The GNU Standard C++ Library v3 > ii libxcursor1 1.0.2-5 X Cursor management library > ii libxft2 2.1.2-6 FreeType-based font drawing > librar > ii libxrender1 0.8.3-7 X Rendering Extension client > libra > ii xlibmesa3-gl [libgl1] 4.2.1-12.1 Mesa 3D graphics library > [XFree86] > ii xlibs 4.3.0-7 X Window System client libraries > m > ii zlib1g 1:1.2.1-5compression library - runtime > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#242520: kmail: the encoding settings doesn't affect the message's subject
On Wednesday 07 April 2004 08:53, Gal Ben-Haim wrote: FYI: Gal Ben-Haim reported it upstream: http://bugs.kde.org/show_bug.cgi?id=79254 Please vote ;) Achim
Bug#243611: crash: i broke the page selector
On Wednesday 14 April 2004 02:43, Zack Cerza wrote: > Package: kpdf > Version: 4:3.2.1-1 > Severity: normal > Tags: sid > > Open a PDF with multiple pages. In the listbox on the left, "1" > should be selected. Click on "1", just to give the listbox focus. > Now press the down arrow on your keyboard a few times, and hit PgUp. > Normally, this would just bring you to the previous page. Instead, it > will probably get a SIGGSEGV. > > Doh! FWIW: Same with kpdf from 3.2.2-1. Achim -- 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]
Re: simplifying & enhancing kde manpages
On Thursday 15 April 2004 17:42, Nathaniel W. Turner wrote: > On Tue, 27 Jan 2004 22:17:34 +0100 Achim Bohnet wrote: > > My idea now was now to create a kde-options(?) manpage^Wsgml that describes > > the generic kde and qt options (later maybe in more detail). From all > > other manpages just use a reference to this manpage. > > Have you made any progress on this? > > This really does seem like the Right Way to document these options -- after > all, they are not provided by the applications themselves, but by kdelibs and > qt; it makes sense therefor, to put the documentation in the libs packages as > well. If KDE adds (or worse, removes) an option to the common KDE options, > do we really want to have to update every individual application's manpage? > Would the individual app maintainers even notice something this subtle? > > Anyway, nobody seemed to think this was a bad idea, so I guess I don't need > to > try so hard to convince you. =) > > I'm willing to help with this, but of course I don't want to duplicate any > effort. Hi Nathaniel, Sorry for the late responce. I've not done much. Got sidetracked by docbook2man UTF-8 brain damage, sgml, license problem ... :( I'm MIA most of the time this year :( Please feel free to take over. I've attached 2 manpages Karolina send to me and a modified copy of one of Chris's manpages with some additions from qt3/doc/html/debug.html and kdecore/html/classKCmdLineArgs.html I'm not sure if it's okay to c&p qts debug.html in a (L)GPL manpage. Achim > > Cheers, > nate -- 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] --- Begin Message --- tisdagen den 27 januari 2004 22.17 you wrote: > My idea now was now to create a > kde-options(?) manpage^Wsgml that describes the generic kde and > qt options (later maybe in more detail). From all other manpages > just use a reference to this manpage.If possible one could > even create templates in kdelibs-dev that are included and allow to > change these generic parts of each kde manpage at a central > place. I once did this and man-pages to almost all KDE binaries in debian for KDE 3.1 Attached is my version, if it can be of any help. Karolina kdelibs.kdeenviron Description: Troff document kdelibs.kdeqtoptions Description: Troff document --- End Message --- --- Begin Message --- torsdagen den 29 januari 2004 15.21 you wrote: > Hi Karolina, > > great, especially the environment manpage!! This was too only wish/todo > list. IGood, that I updated to sarge last night instead of working on the > manpages ;) 'll convert them to sgml and merge with stuff I already have. > Btw. there's not copyright notice. Is LGPL okay? That's ok. Karolina --- End Message --- manpage.1'. You may view the manual page with: `docbook-to-man manpage.sgml | nroff -man | less'. A typical entry in a Makefile or Makefile.am is: manpage.1: manpage.sgml docbook-to-man $< > $@ The docbook-to-man binary is found in the docbook-to-man package. Please remember that if you create the nroff version in one of the debian/rules file targets (such as build), you will need to include docbook-to-man in your Build-Depends control field. --> Chris"> Cheney"> January 28, 2004"> 1"> [EMAIL PROTECTED]"> KDE-OPTIONS"> Debian"> GNU"> ]> &dhemail; &dhfirstname; &dhsurname; 2002 &dhusername; &dhdate; &dhucpackage; &dhsection; &dhpackage; standard command line options supported by almost every kde application DESCRIPTION Describes the standard options supported by almost every KDE application. The command line options of KDE programs follow the usual GNU command line syntax, with long options starting with two dashes (`-'). The list of standard command line options is included below. GENERIC OPTIONS --author Show author information. --help Show help about options. --help-all Show all options. --help-kde Show KDE specific options. --help-qt Show Qt specific options. --license Show license information.
Bug#126406: kppp: Alternative for using noauth as suggested by README
Hi, FWIW here's my alternative: to avoid setting noauth in /etc/peer/options I use allee[0] ~ # cat /etc/ppp/peers/kppp-options noauth and added 'call kppp-options' to kppps 'Customize pppd arguments' option. I assume that it would not be compilicated to patch kppp to add 'call kppp-options' as default for new connections and include the simple /etc/ppp/peers/kppp-option to the kppp pkg. Achim -- 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#245149: kdelibs4: preinst script removes conffile system.kdeglobal
Package: kdelibs4 Version: 4:3.2.2-1 Severity: serious Justification: Policy 10.7.3 kdelibs4.preinst has rm /etc/kde3/system.kdeglobals >& /dev/null || true This was formerly a conffile and we used it here to redefine default fonts, etc. Because KDE does not save a config option in $KDEHOME if the systemwide option has the same value, all users suddenly got debian default font (helvatica is ugly here). As a fix I suggest to add dummy system.kdeglobals file: # Note: Debian KDE pkg > 3.2.1 DO NOT need the # dir_* entries in [Directory] and TerminalApplication # in [General] anymore. Please delete them! If system.kdeglobals was not touched people will not be bothered and if the modified it the diff tells them what's the right thing (tm) to do ;) Achim P.S curious: why not the simple rm -f? AFIAK it does the same: $ rm -f does-not-exists-here $ echo $? 0 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (100, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.3-laptop-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages kdelibs4 depends on: ii kdelibs-bin4:3.2.2-1 KDE core binaries ii kdelibs-data 4:3.2.2-1 KDE core shared data ii libart-2.0-2 2.3.16-3 Library of functions for 2D graphi ii libarts1 1.2.2-1 aRts Sound system ii libasound2 1.0.4-1 Advanced Linux Sound Architecture ii libaudio2 1.6c-3The Network Audio System (NAS). (s ii libaudiofile0 0.2.6-3 Open-source version of SGI's audio ii libbz2-1.0 1.0.2-1 A high-quality block-sorting file ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an ii libcupsys2 1.1.20final+cvs20040330-1 Common UNIX Printing System(tm) - ii libesd-alsa0 [ 0.2.29-1 Enlightened Sound Daemon (ALSA) - ii libfam0c1022.7.0-5 client library to control the FAM ii libgcc11:3.3.3-6 GCC support library ii libgcrypt1 1.1.12-4 LGPL Crypto library - runtime libr ii libglib2.0-0 2.2.3-1 The GLib library of C routines ii libgnutls7 0.8.12-5 GNU TLS library - runtime library ii libice64.3.0-7 Inter-Client Exchange library ii libjpeg62 6b-9 The Independent JPEG Group's JPEG ii libmad00.15.0b-3 MPEG audio decoder library ii libogg01.1.0-1 Ogg Bitstream Library ii libpcre3 4.5-1.1 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.5.0-5 PNG library - runtime ii libqt3c102-mt 3:3.2.3-2 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0-7 X Window System Session Management ii libstdc++5 1:3.3.3-6 The GNU Standard C++ Library v3 ii libtasn1-0 0.1.2-1 Manage ASN.1 structures (runtime) ii libtiff3g 3.5.7-2 Tag Image File Format library ii libvorbis0a1.0.1-1 The Vorbis General Audio Compressi ii libvorbisfile3 1.0.1-1 The Vorbis General Audio Compressi ii libx11-6 4.3.0-7 X Window System protocol client li ii libxext6 4.3.0-7 X Window System miscellaneous exte ii libxml22.6.8-1 GNOME XML library ii libxrender10.8.3-7 X Rendering Extension client libra ii libxslt1.1 1.1.5-1 XSLT processing library - runtime ii libxt6 4.3.0-7 X Toolkit Intrinsics ii xbase-clients 4.3.0-7 miscellaneous X clients ii xlibs 4.3.0-7 X Window System client libraries m ii zlib1g 1:1.2.1-5 compression library - runtime -- no debconf information -- 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#237491: KDE applications select wrong font
On Wednesday 21 April 2004 17:42, Andreas Tille wrote: > Josh, thanks for your hints and sorry for my late answer. [...] > Now I leave it to you to find out which setting would care for the > font as a reasonable default if somebody works like me and does > not call kpersonalizer but instead run KDE appllications from > Gnome or any other WM. ;-) Ah, today is systemwide defaultfont day ;) We use since kde 3.0.x /etc/kde3/kdesktoprc [FMSettings] StandardFont=Arial,10,-1,5,50,0,0,0,0,0 /etc/kde3/system.kdeglobals ... [General] ... StandardFont=Arial,10,-1,5,50,0,0,0,0,0 activeFont=Arial,10,-1,5,75,0,0,0,0,0 fixed=Courier New,10,-1,5,25,0,0,0,0,0 font=Arial,10,-1,5,50,0,0,0,0,0 menuFont=Arial,10,-1,5,50,0,0,0,0,0 toolBarFont=Arial,10,-1,5,50,0,0,0,0,0 /etc/kde3/konsolerc [Desktop Entry] defaultfont=Courier,10,-1,5,50,0,0,0,0,0 font=8 ... Substitute the fonts,size with your favorites. Please note that upgrade to KDE 3.2.2-1 removes /etc/kde3/system.kdeglobals (see #245149) Achim > Please tell me whether you need any further hints to debug the > problem. > > Kind regards and thanks for your help > > Andreas. > > PS: Feel free to downgrade severity from important to normal because > I think if this problem is documented in this bug report the > severity can be lowered. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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#126406: kppp: Alternative for using noauth as suggested by README
On Thursday 22 April 2004 07:36, Ernst Kloppenburg wrote:
> On Wed, Apr 21, 2004 at 00:29:54 +0200, Achim Bohnet wrote:
> >
> > FWIW here's my alternative:
> > to avoid setting noauth in /etc/peer/options I use
> >
> > allee[0] ~ # cat /etc/ppp/peers/kppp-options
> > noauth
> >
> > and added 'call kppp-options' to kppps 'Customize pppd arguments'
> > option.
> >
> > I assume that it would not be compilicated to patch kppp to
> > add 'call kppp-options' as default for new connections and
> > include the simple /etc/ppp/peers/kppp-option to the kppp pkg.
> >
>
> yes, this seems to be the real solution. Better than any advice in a
> README. Who would make the change?
Well, pkgs maintainer always get a copy if one CC <[EMAIL PROTECTED]> ;)
I got a laptop with a working modem card working on linux to fix some
problems. And realized
o noauth is already the default additional pppd option
o only possibility (I found) to get kpp to work with
pap/chap is to suid it to root because kppp writes
stuff to /etc/ppp/{pap,chap}-secrets (cp,modify,rename AFIAR)
(looks like worth another bug report)
I don't have access to the laptop anymore. So could you please try if
'noauth' instead of 'call kppp-options' works if you do
dpkg-statoverride --force --add root 4754 root dip /usr/sbin/kppp #
permanent
or
chmod 4754 /usr/sbin/kppp # until next kppp upgrade
?
At least here in Germany all ISP require either PAP or CHAP
authentification (guess somewhere else too) and this makes
kppp unusable as it is now (kppp in 2.* was setuid root AFAIR
and 2.* was done by Ivan who also wrote the README. Hmm..., aaahhh
http://lists.debian.org/debian-kde/2003/debian-kde-200303/msg00339.html
http://lists.debian.org/debian-kde/2003/debian-kde-200303/msg00316.html
http://lists.debian.org/debian-kde/2003/debian-kde-200310/msg00076.html
;)
I really suspect now that noauth okay but suid bit is missing.
If I miss the trick to the get PAP and/or CHAP working with
only sgid dip, please let me know.
Achim
P.S. When suid root is the route to go I would vote to keep
'noauth' instead of my 'call kppp-options' because it more secure.
>
> E. Kloppenburg
>
> --
> Ernst Kloppenburg
> Stuttgart, Germany
>
>
>
--
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#246110: konqueror: Fails to install with fresh install of sarge. Conflicting file /usr/bin/kfmexec
On Tuesday 27 April 2004 11:30, Nick Hill wrote: > Package: konqueror > Version: 4:3.1.5-2 > Severity: normal > > This system has only testing in the sources.list pointing to a local > apt-cache server. The files on a hard drive have been written freshly > using debootstrap. This is a fresh sarge install. > The system has been booted with Knoppix. i have then chrooted into the > fresh install to set up packages. > > I run > apt-get install kde > > The installation process halts with the following: > installed.)Unpacking konqueror (from > .../konqueror_4%3a3.1.5-2_i386.deb) ...dpkg: error processing > /var/cache/apt/archives/konqueror_4%3a3.1.5-2_i386.deb > (--unpack): trying to overwrite `/usr/bin/kfmexec', which is also > in package kdelibs-bindpkg-deb: subprocess paste killed by signal > (Broken pipe)Errors were encountered while processing: > /var/cache/apt/archives/konqueror_4%3a3.1.5-2_i386.debE: > Sub-process /usr/bin/dpkg returned an error code (1) will be fixed when konqueror 3.2.2 enters testing. $ dpkg -L konqueror | grep kfmexec $ dpkg -l konqueror Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii konqueror3.2.2-1 KDE's advanced File Manager, Web Browser and Document Vi Achim -- 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#247196: kdm: clarify documentation
On Monday 03 May 2004 21:35, Ross Boylan wrote: > Package: kdm > Version: 4:3.2.2-1 > Severity: wishlist Hi Ross, > > 1) The current documentation makes several references to the xdm > manpage, but users may not have xdm installed. For this and other > reasons, a kdm manpage would be good (see also bug #193527). Agreed. Care to write (parts) of it? That would be great. > > 2) README.Debian does indicate it is for xdm, but it would be helpful > to have a few lines explaining how this translates to kdm. Among the > interpretations that occurred to me were > * kdm uses the same files > * kdm uses files of the same name but in /etc/kde3 (seems to be the > case) > * kdm uses its own files with different names (e.g., starting with a > k) > README.gz did allow me to infer it was the second, but that's a bit > obscure. Perhaps README.Debian could be removed? I had a look at README.Debian and I agree to that the file is more confusing that helpful and should be removed. The only debian specific infos worth to note IMHO would be how and where debian select what x display manager gets used, because that really Debian specific. Hmm, because default entries in Xserver use -tcp nolisten one can also mention that 'Remote Session' in the kdm greeter menu will not work. > 3) README.Debian includes confusions and redundancies. It refers to > "The above three files", but there only seemed to be one file > (xdm-config) that had been mentioned (Xresources is a directory, > though perhaps not outside of Debian. Even so, that's only two > files). The phrase "See the X(1) manual page for more information > about X resources" occurs twice, and the surrounding discussion is a > bit repetitive in other ways. > > 4) README.gz has a discussion headed "The command FiFos" which doesn't s/command/Command/ in README.gz so source string matches target string (for tools with case sensitive search). > quite indicate, from a user perspective, how to use them. I tried > echo commands to the relevant files, and that seemed to work. While > the cogniscenti may know that already, saying it explicitly would > be useful. Care to provide better description? > The discussion seems to imply that the low level interface doesn't > matter because there are higher level tools: ksmserver and kdesktop. > I tried starting the former and it messed up my session so badly I had > to kill it. I assume the latter is always running; I looked on my > menus but didn't see anything that seemed related to this. with reserve lines in Xservers your k-menu and kscreensaver should have 'Start new session' menu entries and buttons, respectively. Works fine here. > I was specifically looking for how to start up a session that had been > specified in Xservers with the "reserve" word. There seem to be other > problems with that, which I reported in a previous bug. The point > here is that while some of the functionality is accessible from the > desktop (e.g., shutdown and restart), reserve and other functionality > does not seem to be. No. 'Start new session' exposes reserve command on the gui. Achim > > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (990, 'testing'), (50, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.4.24advncdfs > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 > > Versions of packages kdm depends on: > ii debconf 1.4.22 Debian configuration management > sy > ii kdebase-bin 4:3.2.2-1KDE Base (binaries) > ii kdelibs44:3.2.2-2KDE core libraries > ii libart-2.0-22.3.16-5 Library of functions for 2D > graphi > ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5 client library to control the > FAM > ii libgcc1 1:3.3.3-6GCC support library > ii libice6 4.3.0-7 Inter-Client Exchange library > ii libpam-runtime 0.76-19 Runtime support for the PAM > librar > ii libpam0g0.76-19 Pluggable Authentication Modules > l > ii libpng12-0 1.2.5.0-5PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime > v > ii libsm6 4.3.0-7 X Window System Session > Management > ii libstdc++5 1:3.3.3-6The GNU Standard C++ Library v3 > ii libx11-64.3.0-7 X Window System protocol client > li > ii libxext64.3.0-7 X Window System miscellaneous > exte > ii libxrender1 0.8.3-7 X Rendering Extension client > libra > ii libxtst64.3.0-7 X Window System event recording > an > ii xbase-clients 4.3.0-7 miscellaneous X clients > ii xlibs 4.3.0-7 X Wind
Bug#247193: kdm: reserve doesn't seem to work
On Monday 03 May 2004 21:18, Ross Boylan wrote:
> Package: kdm
> Version: 4:3.2.2-1
> Severity: normal
>
> I uncommented the first commented display line in /etc/kde3/kdm/Xservers:
> :1 [EMAIL PROTECTED] reserve /usr/X11R6/bin/X -nolisten tcp :1 vt8
> and did
> invoke-rc.d kdm restart
>
> Despite this /var/run/xdmctl/ only showed xdmctl and xdmctl-:0.
Reserve is working fine here (can start other parallel session
with k-menu -> 'Start new session'. Nevertheless I only have
xdmctl and xdmctl-:0 too. When I start the first new session
xdmctl-:1 is created. So xdmctl-:? are only created when really
used and not when defined in Xservers.
>
> As I understand it, there should have been an xdmctl-:1 to which I
> could direct
>echo reserve
> to start up the second login screen.
From my tests it looks like you miss understood something ;)
>
> I also tried restarting my X server on vt7. This didn't help.
>
> I have xfree86-common version 4.3.0-7, and am in a mostly testing
> system.
>
> I may not have understood how this is supposed to work, but this is
> what I got from the docs.
I had a look at the /usr/share/doc/kdm/README.gz and
echo reserve > /var/run/xdmctl/xdmctl-$DISPLAY
works fine here (as user log in on $DISPLAY). You should send
the reserve command to the xdmctl file responsible for your display.
I guess you get confused by the assumption that xdmctl
file should exist for every reserve setting in Xservers.
If you've some suggestion how to enhance kdms README please
send a patch. Otherwise I suggest to close the bug report.
Achim
P.S. The word 'seem' in the subject is an indication that
the report is better first send to debian-kde list to make
sure it's a bug ;)
>
> -- System Information:
> Debian Release: testing/unstable
> APT prefers testing
> APT policy: (990, 'testing'), (50, 'unstable')
> Architecture: i386 (i686)
> Kernel: Linux 2.4.24advncdfs
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
>
> Versions of packages kdm depends on:
> ii debconf 1.4.22 Debian configuration management
> sy
> ii kdebase-bin 4:3.2.2-1KDE Base (binaries)
> ii kdelibs44:3.2.2-2KDE core libraries
> ii libart-2.0-22.3.16-5 Library of functions for 2D
> graphi
> ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries
> an
> ii libfam0c102 2.7.0-5 client library to control the
> FAM
> ii libgcc1 1:3.3.3-6GCC support library
> ii libice6 4.3.0-7 Inter-Client Exchange library
> ii libpam-runtime 0.76-19 Runtime support for the PAM
> librar
> ii libpam0g0.76-19 Pluggable Authentication Modules
> l
> ii libpng12-0 1.2.5.0-5PNG library - runtime
> ii libqt3c102-mt 3:3.2.3-2Qt GUI Library (Threaded runtime
> v
> ii libsm6 4.3.0-7 X Window System Session
> Management
> ii libstdc++5 1:3.3.3-6The GNU Standard C++ Library v3
> ii libx11-64.3.0-7 X Window System protocol client
> li
> ii libxext64.3.0-7 X Window System miscellaneous
> exte
> ii libxrender1 0.8.3-7 X Rendering Extension client
> libra
> ii libxtst64.3.0-7 X Window System event recording
> an
> ii xbase-clients 4.3.0-7 miscellaneous X clients
> ii xlibs 4.3.0-7 X Window System client libraries
> m
> ii zlib1g 1:1.2.1-5compression library - runtime
>
> -- debconf information:
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
> LANGUAGE = (unset),
> LC_ALL = (unset),
> LANG = "en_US.UTF-8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> kdm/stop_running_server_with_children: false
> * kdm/default_servers_nolisten_tcp:
> * kdm/default_servers_100dpi:
> * kdm/kdmrc:
> shared/default-x-display-manager: kdm
> * kdm/default_nolisten_udp:
> kdm/daemon_name: /usr/bin/kdm
> kdm/oldconfig:
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>
>
--
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#247193: kdm: reserve doesn't seem to work
On Wednesday 05 May 2004 07:25, you wrote: > On Tue, May 04, 2004 at 11:50:54AM +0200, Achim Bohnet wrote: > > On Monday 03 May 2004 21:18, Ross Boylan wrote: > > > Package: kdm > > > Version: 4:3.2.2-1 > > > Severity: normal > > > > > > I uncommented the first commented display line in /etc/kde3/kdm/Xservers: > > > :1 [EMAIL PROTECTED] reserve /usr/X11R6/bin/X -nolisten tcp :1 vt8 > > > and did > > > invoke-rc.d kdm restart > > > > > > Despite this /var/run/xdmctl/ only showed xdmctl and xdmctl-:0. > > > > Reserve is working fine here (can start other parallel session > > with k-menu -> 'Start new session'. Nevertheless I only have > > I don't see that option anywhere on my K-menu, either top level or > further down in any likely spot (system, utilities, control center). > I think I remember seeing it somewhere (on the kdm greeter?) and > wondering what it did. > > Oh... maybe this only appears if you have a reserve session possible. > I may have seen it when I had one, and now it's gone because I removed > the reserve word since I couldn't make it work. > > > xdmctl and xdmctl-:0 too. When I start the first new session > > xdmctl-:1 is created. So xdmctl-:? are only created when really > > used and not when defined in Xservers. > > > > > > As I understand it, there should have been an xdmctl-:1 to which I > > > could direct > > >echo reserve > > > to start up the second login screen. > > > > From my tests it looks like you miss understood something ;) > > > > > > I also tried restarting my X server on vt7. This didn't help. > > > > > > I have xfree86-common version 4.3.0-7, and am in a mostly testing > > > system. > > > > > > I may not have understood how this is supposed to work, but this is > > > what I got from the docs. > > > > I had a look at the /usr/share/doc/kdm/README.gz and > > > > echo reserve > /var/run/xdmctl/xdmctl-$DISPLAY > > > > works fine here (as user log in on $DISPLAY). You should send > > the reserve command to the xdmctl file responsible for your display. > > But there is no such file. Or are you saying that to start session 1 > I should send this to xdmctl-:0? Yes. To start another session from a session running on DISPLAY :0 echo reserve to xdmctl-:0. > > > > > > > I guess you get confused by the assumption that xdmctl > > file should exist for every reserve setting in Xservers. > > > Correct. Since, as written, it appears you must send the "reserve" > command to the corresponding FIFO. Yeah, to the corresponding FIFO of 'your' display, because it's your communitation line to kdm. Assume that a second session is already running. echo reserve to xdmtcl-:0 will create a third session. > > If you've some suggestion how to enhance kdms README please > > send a patch. Otherwise I suggest to close the bug report. > > The fact that a bug report does not include a fix does not mean there > is no bug. Short of a patch, I suggest the document should explain > how to make reserve work. okay, but then subject change:'reserve doesn't seem to work' to 'reserve docu misleading' ;) > > This would involve several elements: > 1. How to get the "start a session" to appear on your menu. I don't > know how. o Uncomment one or more of the 'reserve' line in /etc/kde3/kdm/Xservers. o logout from kde o restart kdm (??or is reload enough??) > 2. Stating that to activate a reserve session you should invoke start > a session and then send the "reserve" command to the corresponding > FIFO (I'm assuming that's the correct method). to the fifo of __your__ display. xdmctl-:0 if you are on DISPLAY=:0 and want to start a second (or third) session on :1 (or :2). > 3. (Optional) Explain a pure FIFO way to achieve the effect of start a > sessio without getting the GUI involved. (I suspect there is such a > method, but I don't know it.) echo reserve> /var/.../xdmctl-$DISPLAY > > At any rate, the missing piece of the puzzle for me seems to be how to > invoke the "start session" function, or how to get it on my menu. > > > > > Achim > > P.S. The word 'seem' in the subject is an indication that > > the report is better first send to debian-kde list to make > > sure it's a bug ;) > > 'seem' referred to the fact there might be some way to make it work, > as there seems to be. But even if there
Bug#126406: KPPP fixes, derived from #126406
On Wednesday 05 May 2004 19:59, Christopher Martin wrote: > Hello, > > To deal with the problems users are having configuring KPPP, I've put > together some small patches (based on the ideas, not my own, discussed in > Bug #126406) that should resolve these issues. The patches are attached > to the e-mail I sent to [EMAIL PROTECTED], which for some reason > hasn't been CCed to debian-qt-kde. Great! Thx Christopher. FWIW I had a look at the patches and AFAICS it looks okay. Just one security note (sorry, no modem access to test): AFAIR you can use pppd with several call options. pppd call x call y ... This means everyone in dip group can now add noauth via call kppp-options to pppd. So in principle a bad member of the dip group could start a listening pppd daemon that allows dialup access without authorization (without noauth one needs edit pap,chap-secrets or add noauth in options or peers/* That can only be done by root. So it weakens security. If this scenario is not too paranoid I would say ship kppp-options with noauth commented out and document in README how to enable it (or maybe even add a dialog to kppp to warn about it). Grmbl, I really hope it's not necessary ;) Maybe one should ask/cc/fwd pppd maintainer before applying to kdenetwork pkgs? Achim > There are two distinct problems. KPPP must be SUID root, in order for PAP > and/or CHAP authentication to work, given the way KPPP operates. This is > unavoidable (it creates and moves files around in /etc/ppp). I've set > kppp to be 4754 root.dip (the same permissions as pppd), so membership in > the dip group is still needed to execute kppp. > > Even when SUID, however, the custom pppd argument "noauth" doesn't > actually seem to have an effect, for some odd reason, and setting > "noauth" is necessary. Since having users edit /etc/ppp/options is bad > and cumbersome, I've added a work-around, /etc/ppp/peers/kppp-options, > which contains the string "noauth", and which is used by giving kppp the > default custom pppd argument "call kppp-options". When done this way, the > noauth option actually takes effect. > > Also, I've elevated ppp from a Recommends to a dependency, since many > (most? all?) dial-up connections will need it, and this keeps things easy > and simple for users. Finally, I've removed the segment of documentation > which instructed users to modify /etc/ppp/options. > > With these changes, KPPP should "just work" without any mucking around > whatsoever, except for configuration of the modem itself (symlinks, dev > node creation if necessary, etc.). > > Christopher Martin -- 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]
Re: Bug#247821: kdm exits after one run
On Friday 07 May 2004 13:22, Patrick Cornelißen wrote: > Anton Ivanov wrote: > > Package: kdm > > Version: 4:3.2.2-1 > > Severity: grave > > > > It will exit after the user logs out and has to be started again > > manually. This appeared after upgrade from 3.1 to 3.2 and is > > reproducible. > Additional Info: > I had this problem on our systems too. I solved it by removing the ldap > checks in /etc/pam.d > For authentication nsswitch was enough. Just the per Host acces > restriction doesn't work this way :-( Try grep kdm /var/log/*.log > kdm.before .. start kdm and login/logout and after kdm exits grep kdm /var/log/*.log > kdm.after diff -u kdm.before kdm.after and send the diff output. Maybe there are additional hints what kdm did not like. Achim > > -- > Bye, > Patrick Cornelissen > http://www.p-c-software.de > ICQ:15885533 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
kdeextragear-3/kdebluetooth/debian
CVS commit by ach: build also with bluez-utils 2.6 from experimental. Alternative libsdp2-dev build-dep can be removed when bluez-utils 2.6 enters unstable in the next days. M +1 -1 control 1.5 --- kdeextragear-3/kdebluetooth/debian/control #1.4:1.5 @@ -3,5 +3,5 @@ Priority: optional Maintainer: Fred Schaettgen <[EMAIL PROTECTED]> -Build-Depends: debhelper (>> 4.0.0), kdelibs4-dev (>= 3.1.4), libbluetooth1-dev (>= 2.5), +Build-Depends: debhelper (>> 4.0.0), kdelibs4-dev (>= 3.1.4), libbluetooth1-dev (>= 2.6) | libsdp2-dev (>= 1.5), xmms-dev (>= 1.2.7) Standards-Version: 3.5.9
Bug#252366: konsole: fds not closed before execing shell
On Thursday 03 June 2004 00:47, Cesar Eduardo Barros wrote: > Package: konsole > Version: 4:3.2.2-1 > Severity: normal > > [EMAIL PROTECTED]:~[0]$ ls -l /proc/self/fd > total 5 > lrwx--1 cesarb cesarb 64 Jun 2 19:38 0 -> /dev/pts/70 > lrwx--1 cesarb cesarb 64 Jun 2 19:38 1 -> /dev/pts/70 > lrwx--1 cesarb cesarb 64 Jun 2 19:38 2 -> /dev/pts/70 > lr-x--1 cesarb cesarb 64 Jun 2 19:38 3 -> /proc/12024/fd > lrwx--1 cesarb cesarb 64 Jun 2 19:38 4 -> /dev/dri/card0 > > This happens within konsole. Looks like it forgot to close all file > descriptors before execing the shell (/dev/dri/card0 should not be > open on the shell). Hi Cesar, that's interesting and made me curious ;) When one starts from konsole and tries ls -l /proc/$$/fd: xterm --> card0 still open xterm -ls --> card0 closed konsole -ls --> card0 closed konsole --> card0 open on fd 4 and(!) 5 I'm using testing with xfree and arts from unstable. Achim > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable') > Architecture: i386 (i686) > Kernel: Linux 2.6.6-flower > Locale: LANG=C, LC_CTYPE=en_US.UTF-8 > > Versions of packages konsole depends on: > ii kdelibs4 4:3.2.2-2 KDE core libraries > ii libart-2.0-2 2.3.16-5 Library of functions for 2D > graphi > ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries > an > ii libfam0c102 2.7.0-5client library to control the > FAM > ii libgcc1 1:3.3.3-9 GCC support library > ii libice6 4.3.0.dfsg.1-1 Inter-Client Exchange library > ii libpng12-01.2.5.0-6 PNG library - runtime > ii libqt3c102-mt 3:3.2.3-2 Qt GUI Library (Threaded runtime > v > ii libsm64.3.0.dfsg.1-1 X Window System Session > Management > ii libstdc++51:3.3.3-9 The GNU Standard C++ Library v3 > ii libx11-6 4.3.0.dfsg.1-1 X Window System protocol client > li > ii libxext6 4.3.0.dfsg.1-1 X Window System miscellaneous > exte > ii libxrender1 0.8.3-7X Rendering Extension client > libra > ii libxtst6 4.3.0.dfsg.1-1 X Window System event recording > an > ii xlibs 4.3.0.dfsg.1-1 X Window System client libraries > m > ii zlib1g1:1.2.1.1-3compression library - runtime > > -- no debconf information > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- 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]
'Best' way to develop debs of kdeextragear* apps inside KDE CVS
Hi, I'm working on debs for keg modules libexif, libkipi, kipi-plugins and digikam (as test app) to ease preparation by a DD or ITP them later myself when they will be released (maybe end of august??) Untils the upstream release: I find it quite inconvinient to create a tar ball and then follow the std procedure again and again (I've to copy every change back to kde cvs. Has anyone some tips, URLs, how to best 'prepare' a deb pkg inside kdeextragear cvs? What I would like to do is to cvs up make -f Makefile.cvs cd while ! happy; do whats-necessary; debuild; dpkg -i ../xxx; test; test; test done Appended are my current work arounds. I hope someone found something better, to deal with the problem. Any hint & tip appreciated! After the upstream release: Has anyone a script that makes it simpler to incorporate changes between the .orig.tar.gz and a (stable) branch into debian/patches/*? Ditto vice versa possible changes in src tree back into kde cvs tree? Achim P.S. here my kde cvs workaround For the kdebluetooth rules I use hacks like ifeq "$(wildcard ./admin)" "" # okay uppacked tar ball else # in keg*/ fi and for libkexif/kipi kipi-plugins,digican (with cdbs) stuff like: cat //configure #!/bin/bash cd .. && ./configure "$@" works for all but kipi-plugins where I also have to add ln -s . obj-i386-linux still to investigate why cdbs created where a obj-i386-linux build dir and not in the other cases. Achim -- -> . 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#270429: KDM doesn't display the login window anymore
On Tuesday 07 September 2004 12:59, Didier Verna wrote: > > Package: kdm > Version: 4:2.2.2-14.7 > Distribution: unstable Hi, uh? kdm in unstable is 4:3.3.0-1. kdm 2.2.2 sounds like your using woody. Assuming your using unstable: Please make sure that you're pkgs are up to date 'apt-get -u dist-upgrade' then send us the output of 'reportbug --template kdm'. Achim > > Hi ! > > As of my upgrade this morning (but it's been 14 days since my last X > shutdown), KDM doesn't display the login window anymore: it only displays the > background image. I can't enter my username and password. > > Thanks ! > > -- > Didier Verna, [EMAIL PROTECTED], http://www.lrde.epita.fr/~didier > > EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85 > 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 [EMAIL PROTECTED] > > > -- 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#270429: KDM doesn't display the login window anymore
On Tuesday 07 September 2004 17:49, Didier Verna wrote: > Achim Bohnet <[EMAIL PROTECTED]> wrote: > > > On Tuesday 07 September 2004 12:59, Didier Verna wrote: > >> > >> Package: kdm > >> Version: 4:2.2.2-14.7 > >> Distribution: unstable > > > > Hi, > > > > uh? kdm in unstable is 4:3.3.0-1. kdm 2.2.2 sounds like your using woody. > > Hmmm. 2.2.2-14.7 was the contents of the Version line from "apt-cache > show". The version displayed by dpkg -l kdm is 3.3.0-1. Well, if you insist in using apt-cache then better use apt-cache policy kdm ;) > > > > Assuming your using unstable: Please make sure that you're pkgs are up to > > date 'apt-get -u dist-upgrade' then send us the output of 'reportbug > > --template kdm'. > > I'd like to, but reportbug --template kdm outputs nothing ... :-/ Eh? I'm using sarge $ reportbug --template kdm | wc -l 52 $ reportbug --version reportbug 2.63 Okay, back to topic ;) Did you try /etc/init.d/kdm restart maybe some share libs stuff broke kdm. Does grep kdm /var/log/daemon.log show any strange messages? Did you try to search if others had already the problem? I know there were several problems related to kdm 3.3 but because I'm using sarge I did not follow closely. Try o reportbug kdm# and check the contents of related bug o search kde-debian mailing list archive Achim > -- > Didier Verna, [EMAIL PROTECTED], http://www.lrde.epita.fr/~didier > > EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85 > 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 [EMAIL PROTECTED] -- 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#269265: patch for startkde
Hi,
[sorry if this sounds harsh. Not my day, I'm in a hurry
and need some sleep :( All my fault]
why copy complete $KDEHOME, when only one file should be modified?
There's also the need to take customized $KDEHOME, $KDEDIR and $KDEDIRS
into consideration. A general substitution rule without taking the relevant
group into account makes me also a bit nervous (but AFAIU this could be
fixed with a more sed magic ;)
For all KDE path stuff I would recommend
to use kde-config. echo "only perl can parse perl" | sed s/perl/KDE/g
;). Some useful examples in your case:
kde-config --localprefix
kde-config --path config
kde-config --expand --install xdgdata-apps
kde-config --path apps
...
Nevertheless I would suggest to first have a look at kdeconf_update.
It's the kde way to port incompatible changes in config files.
There are also kdereadconfig and kdewriteconfig, but if you use it
for kickerrc manipulations make sure kicker depends on kdebase-bin.
$ dpkg -S /usr/bin/{kde-config,kwriteconfig,kreadconfig,kconf_update,startkde}
kdelibs-bin: /usr/bin/kde-config
kdebase-bin: /usr/bin/kwriteconfig
kdebase-bin: /usr/bin/kreadconfig
kdelibs-bin: /usr/bin/kconf_update
ksmserver: /usr/bin/startkde
Keep up the good work!
Achim
--
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#271893: kwrite: KWrite doesn't show a status line.
Hi, wild guess: did you check that "Settings" -> "Show statusbar" is activated? If not try to activate it. Fixed this 'bug' here ;) Achim
Bug#283339: Forward upstream, please?
On Monday 13 December 2004 21:24, Riku Voipio wrote: > Achim, can you forward this issue upstream? After reading this [...] Hi Riku, as Renchi mentioned on digikam-devel, the bug is already reported upstream: http://bugs.kde.org/show_bug.cgi?id=93359 Achim > > > -- 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]
Re: Bug#320212: /usr/bin/kfontview: /usr/lib/libkfontinst.so.0: undefined symbol: FTC_SBit_Cache_New
On Wednesday 27 July 2005 18:49, Tom Epperly wrote: > Package: kcontrol > Version: 4:3.3.2-1 > Severity: normal > File: /usr/bin/kfontview Short story for unstable users: unstable is currently borked due to the C++ transition. Wait until kde 3.4.? enters sid and the error will go way. Longer story for sarge (and curious sid) users: > > When I try to run kfontview, it fails to start up. > > [EMAIL PROTECTED]>kfontview /usr/share/fonts/truetype/freefont/FreeSans.ttf > QPixmap: Cannot create a QPixmap when no GUI is being used > QPixmap: Cannot create a QPixmap when no GUI is being used > QPixmap: Cannot create a QPixmap when no GUI is being used > QPixmap: Cannot create a QPixmap when no GUI is being used > kbuildsycoca running... I get those too if I start kfontview in a slogin [EMAIL PROTECTED] shell, not when started in a KDE session (via KDM). I.e, the msg come from the KDE daemons that are started. Nothing to worry about. > kfontview: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file > kfontviewui.rc This file is wasn't available/was forgotten in KDE 3.3 upstream. It was added in KDE 3.4: $ svn ls --recursive svn://anonsvn.kde.org/home/kde/branches/KDE/3.3/kdebase/kcontrol/kfontinst | fgrep .rc viewpart/kfontviewpart.rc $ svn ls --recursive svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase/kcontrol/kfontinst | fgrep .rc viewpart/kfontviewpart.rc viewpart/kfontviewui.rc svn log svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase/kcontrol/kfontinst/viewpart/kfontviewui.rc ... r370422 | dfaure | 2004-12-13 20:41:56 +0100 (Mon, 13 Dec 2004) | 4 lines Fixed runtime warning kfontview: WARNING: KXMLGUIClient::setXMLFile: cannot find .rc file kfontviewui.rc It's quite unusual to have no .rc file, so I'd rather not hide the warning. To fix it: svn cat svn://anonsvn.kde.org/home/kde/branches/KDE/3.4/kdebase/kcontrol/kfontinst/viewpart/kfontviewui.rc > kfontviewui.rc and copy this file as root to /usr/share/apps/kfontinst/ > kfontview: relocation error: /usr/lib/libkfontinst.so.0: undefined symbol: > FTC_SBit_Cache_New > [EMAIL PROTECTED]>Mutex destroy failure: Device or resource busy that's a temporary sid/unstable problem. Does not happen with sarge. > which kfontview > /usr/bin/kfontview > [EMAIL PROTECTED]>ICE default IO error handler doing an exit(), pid = 29019, > errno = 0 Happen only for slogin -X [EMAIL PROTECTED], not for KDE session (maybe at logout) nothing to worry about IMHO. Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: extragear/multimedia/kmplayer
On Saturday 06 August 2005 14:05, Koos Vriezen wrote: > SVN commit 443468 by vriezen: > > Update for 0.9.0b > Don't install application/x-mplayer2.desktop with debian, conflicts with > kaffeine 0.6 If someone does not have kaffeine installed, there's no x-mplayer2.desktop file? Isn't it better to move this file to mplayer or kdelibs and remove from kaffeine too? If this goes in kdelibs before the kdelibs C++ trans kaffeine and kmplayer can silently rely on it's availabilty without require a given version ;) [...] > --- trunk/extragear/multimedia/kmplayer/debian/changelog #443467:443468 > @@ -1,3 +1,9 @@ > +kmplayer (0.9.0.2-1) unstable; urgency=low > + > + * 0.9.0b release a note about the x-mplayer2.desktop change can't hurt > + > + -- Koos Vriezen <[EMAIL PROTECTED]> Sat, 06 Aug 2005 12:08:47 +0200 > + > kmplayer (0.9.0.1-1) unstable; urgency=low > >* 0.9.0a release > --- trunk/extragear/multimedia/kmplayer/debian/kmplayer-lib.install > #443467:443468 > @@ -6,7 +6,6 @@ > debian/tmp/usr/share/apps/kmplayer/bookmarks.xml > debian/tmp/usr/share/apps/kmplayer/noise.gif > debian/tmp/usr/share/mimelnk/application/x-kmplayer.desktop > -debian/tmp/usr/share/mimelnk/application/x-mplayer2.desktop > debian/tmp/usr/share/mimelnk/video/x-ms-wmp.desktop Another x-ms-wmp.desktop: another candidate? Maybe it's a bloody stupid idea (low gain/work ration): add a check to cdbs kde.mk (or lintian if mimelnk are used/ planed by freedesktop) to check for mimelnk files and complain/warn if there is one. ignoring x-.desktop by default). Collecting them in it's own pkg, with a small footprint. Achim -- 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
