kcpuload ftbfs - xsl errors??
Hi,
My package, kcpuload, has failed to build on mips, mipsel, powerpc and sparc [1]
giving a bunch of errors that look like this:
compilation error: file /usr/share/apps/ksgmltools2/docbook/xsl/VERSION line 8
element param
xsl:param : could not compile select expression
'string(document('')//fm:Version[1])'
XPath error : Undefined namespace prefix
($local.l10n.xml//l:i18n/l:[EMAIL PROTECTED]/l:[EMAIL PROTECTED])
It originally failed similarly on ia64 and s390, but when the package was
requeued, the problem had gone away somehow.
I'd like to work out what the problem is before asking (a second time) for the
package to be requeued on the other architectures. Has anyone else seen this
problem and do you know what the solution is?
Thanks,
Helen
1. http://people.debian.org/~igloo/status.php?email=&packages=kcpuload&arches=
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323747: kdelibs-data: upgrading from 4:3.3.2-6.1 to 4:3.4.2-1 broke kicker & konqueror & more
Adeodato Simó wrote:
> severity 323747 serious thanks
>
> * Alejandro Exojo [Thu, 18 Aug 2005 11:00:25 +0200]:
>
>
>> El Jueves, 18 de Agosto de 2005 09:13, Helen Faulkner escribió:
>>
>>> I upgraded my version of kdelibs-data today, and when I rebooted, I found
>>> that a number of things were broken:
>
>
>> To which version of kdelibs-data you upgraded? Yesterday entered kdelibs
>> 3.4.2, and as Adeodato explained:
>
>
>> http://lists.debian.org/debian-kde/2005/08/msg00089.html
>
>
>> ...you can't upgrade KDE, until all packages depending on kdelibs are
>> recompiled. If you upgraded only kdelibs-data, you had a mixture of KDE 3.4
>> and 3.3.
>
>
> Helen and I talked on IRC, and I asked her to file this bug. While upgrading
> the kdelibs4 package to kdelibs4c2 ensures that incompatible stuff gets
> removed, this is not the case with kdelibs-data. IOW, if upgrading
> kdelibs-data alone causes trouble (and it does), then we have to introduce
> the appropriate package relationships to ensure this does not happen.
>
> On other news, Helen, I just realized this is the same bug as #311958, which
> is solved in sid but not in etch nor sarge. IOW, once kdelibs4c2 is
> installed, it'll always go with an appropriate version of kdelibs-data, but
> KDE versions << 3.4 are still affected. The same fix can't be applied to
> those KDE versions, since it does not constitute a suitable upload for
> testing-proposed-updates, let alone stable-p-u. I guess we're stuck with a
> versioned << conflicts. :/ Oh, oh, wait: Conflicts: kdelibs4 should be
> enough, yay C++ transition!
>
> * * *
>
> Christopher: I just realized that our fix for #311958 leaves the kdelibs
> package in a state in which it can't be binNMUed, which is bad. Since dpkg
> lacks (at least for now) a smart = ${Source-Version} check, I guess we have
> to stick with:
>
> kdelibs4c2 Depends: kdelibs-data (>> 3.X), kdelibs-data (<< 3.X+1)
>
> Or perhaps: kdelibs-data (<< 3.X.50), in case alphas or betas are packaged.
>
> Or we may want to discuss:
>
> Depends: kdelibs-data (>> 3.X.Y), kdelibs-data (<< 3.X.Y+1).
Just to clarify, if anyone is still wondering. I upgraded 4:3.3.2-6.1 to
4:3.4.2-1 by literally running synaptic, updating the apt sources and telling
synaptic to upgrade everything that could be upgraded (I have forgotten the
direct apt-get command for that). I think this would be a fairly common thing
to do and as Adeodato has pointed out, I was allowed to upgrade to the "wrong"
version of kdelibs-data without realising it would cause problems. I suspect
there could be many other people in this situation, if others are in the habit
of assuming that if synaptic lets them upgrade something it will be ok to
upgrade it.
Thanks for replying to quickly to this :)
Helen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#323747: kdelibs-data: upgrading from 4:3.3.2-6.1 to 4:3.4.2-1 broke kicker & konqueror & more
Package: kdelibs-data Version: 4:3.3.2-6.1 Severity: important Hi, I upgraded my version of kdelibs-data today, and when I rebooted, I found that a number of things were broken: - The k-menu had no application entries at all (I tried running update-menus and kbuildsycoca to fix this, but that made no difference) - The quicklauncher in kicker had lost it's buttons for the applications that I usually have there. - When I ran konqueror, the part on the left, which can show the directory structure, the bookmarks, the services, etc, was gone. - When I tried to "configure konqueror" from the settings menu nothing happened. - When I tried to run kcontrol, I got the kcontrol window with nothing in it - ie the background picture on the right was there, listing my kde version, username etc. However, there were no entries listed on the left in any of the tabs for index/search/help I reckon that there were probably more things wrong than these that I didn't happen to find. Downgrading kdelibs-data to the previous version solved all of these problems. Thanks, Helen -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages kdelibs-data depends on: ii hicolor-icon-theme0.8-1 default fallback theme for FreeDes kdelibs-data recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is lintian warning about .desktop location correct for kicker applets?
Alejandro Exojo wrote: Read the bug report again. ;-) :) There are at least two obsolete directories (the ones GNOME and KDE were using in the past), and the new one, the one that FreeDesktop standarized. But this place is __only__ for menus (and desktop files have other purposes, as your .desktop in kaquarium for registering a kicker applet, or the ones used for service menus, kparts, etc.). OK, I wasn't sure that this was the correct (best) way to register a kicker applet. But I guess my package is actually doing the right thing already, then, and lintian is wrong. Thanks very much for clarifying that to me :) Helen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is lintian warning about .desktop location correct for kicker applets?
(please CC replies to me) Alejandro Exojo wrote: El Jueves, 13 de Enero de 2005 13:57, Helen Faulkner escribió: I'm maintaining kaquarium, which is a kicker applet. I was just packaging a new Debian revision (will close #287090), and I am getting what seems to be a new lintian warning about the location of the kaquarium.desktop file. Please, see Bug#289773: http://bugs.debian.org/289773 I actually saw that one just after I posted to this list (thanks for suggesting it though). The bug suggests that there are some obselete directories (eg /usr/share/applnk) and some good ones, but it doesn't say whether /usr/share/apps/kicker/applets is obselete or good.I've looked for documentation on this in the Debian pages and the KDE pages, but not found anything that answers that question for me. Can I assume from your reply that /usr/share/apps/kicker/applets is infact a good location for a .desktop file for a panel applet, and that therefore the lintian warning is wrong in this particular case? Thanks, Helen.
is lintian warning about .desktop location correct for kicker applets?
Hello, Please CC any replies to me, because I'm not on this list. I'm maintaining kaquarium, which is a kicker applet. I was just packaging a new Debian revision (will close #287090), and I am getting what seems to be a new lintian warning about the location of the kaquarium.desktop file. At present, kaquarium, puts its .desktop file in /usr/share/apps/kicker/applets It seems that moving the file to /usr/share/applications/kde gets rid of the lintian warning, but also means that kicker doesn't realise that there is a kaquarium applet. So: 1) you can't right-click on kicker, choose Add->Applet->KAquarium, and 2) KAquarium shows up in the kde menu, under lost&found, which is a problem because at present it isn't meant to be in the menu, so it doesn't get sorted to an appropriate location, and there isn't a menu icon or anything. So, I am wondering whether that lintian warning is correct for kde panel applets, and if it is correct, whether there is another way to tell kicker that the kaquarium applet exists. If the lintian warning is incorrect, is that a bug for lintian? Can anyone make a suggestion as to how I should best handle this? Thanks, Helen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#281402: kate: kwrite segfaults on shutdown
Package: kate Version: 4:3.3.1-2 Severity: minor Hello, If I have kwrite still running when I shut down my computer, I get a segfault message for kwrite as KDE closes. However kwrite starts again perfectly well when I next log in. (I haven't tested what it does when the file I have been editing isn't saved yet.) I don't get the segfault when I close kwrite normally or when I kill the kwrite process without shutting the computer down. It has only been doing this recently, so I guess this may be a bug in kate. I can't get the segfault backtrace to add to this bug report, because it only flashes up for a couple of seconds before the computer continues to shut down everything. Thanks, Helen -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kate depends on: ii kdelibs4 4:3.3.1-1 KDE core libraries ii libart-2.0-2 2.3.16-6 Library of functions for 2D graphi ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6client library to control the FAM ii libgcc1 1:3.4.2-3 GCC support library ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library ii libidn11 0.5.2-3GNU libidn library, implementation ii libpng12-01.2.7-1PNG library - runtime ii libqt3c102-mt 3:3.3.3-5 Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-8 X Window System Session Management ii libstdc++51:3.3.5-2 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-8 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxrender1 0.8.3-7X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii zlib1g1:1.2.2-3 compression library - runtime -- no debconf information
Bug#277326: kwalletmanager: Please clearly document behaviour for logging onto websites
Package: kwalletmanager Version: 4:3.3.0-1 Severity: wishlist It would be good if the documentation for kwalletmanager in the KDE help centre explained clearly what the behaviour will be when you log onto a website with konqueror. I have used a kwallet for some time as a "place" to store passwords, for my own convenience. I didn't realise that it would be called by another program (eg konqueror) when a password was required (eg logging onto a banking website). When it popped up a request to open a wallet I was suprised and worried enough to submit a bug report (#277300). Re-reading the documentation in the KDE helpcentre, I realised that it is not documented that this will be the behaviour of kwalletmanager, though it is hinted that it will be accessible to other applications in some way. I suggest adding something like the following to the second paragraph of the Introduction page of the help manual: "KWallet can be automatically called by other applications, such as konqueror. For example, if you are entering a password into a webpage, KWallet can automatically open the wallet containing the password for that webpage and fill in the form for you." If this is not the exact behaviour, please alter that description to explain what kwallet actually does - I haven't used it in this fashion, only seen the dialog to open a wallet come up when I was logging onto a website. Thanks, Helen. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages kwalletmanager depends on: ii kdelibs4 4:3.3.0-2 KDE core libraries ii libart-2.0-2 2.3.16-6 Library of functions for 2D graphi ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5client library to control the FAM ii libgcc1 1:3.4.2-3 GCC support library ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library ii libidn11 0.5.2-3GNU libidn library, implementation ii libpng12-01.2.5.0-8 PNG library - runtime ii libqt3c102-mt 3:3.3.3-4.1Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-8 X Window System Session Management ii libstdc++51:3.3.5-1 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-8 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxrender1 0.8.3-7X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii zlib1g1:1.2.2-1 compression library - runtime -- no debconf information
Bug#277300: Acknowledgement (kwallet: internet banking site incorrectly requests opening of wallet)
I realise that I didn't state clearly that I am using konqueror to access the hsbc website when this kwallet problem occurs. I haven't tried it with other browsers because I can't get the other browsers' identification to spout something that the bank will accept as being either IE or Netscape 4.x. Thanks again, Helen
Bug#277300: kwallet: internet banking site incorrectly requests opening of wallet
Package: kwalletmanager Version: 4:3.3.0-1 Severity: minor When I access the internet backing site for HSBC Australia, the logon process does something that triggers kwallet to open my wallet. To reproduce this, you have to have konqueror identifying as something that the bank will accept. I havemy browser identification as Internet Explorer, Version 6, for this website. (Yes I have written to them asking them to accept konqueror or mozilla or anything that isn't IE - they seem disinclined to do so at present.) 1) Go to: http://www.hsbc.com.au/ 2) Click on Internet Banking 3) Enter a 10 digit number for the Personal Banking Number and a 6 digit number for the pin. 4) Click on Logon. I get a dialog for opening a kwallet at that point, with the following message: "KDE Wallet Service - KDE Daemon The application 'konqueror' has requested to open the wallet 'MyWallet'. Please enter the password for this wallet below." Now, I think this may well be the bank's fault. It's been happening for months at least. But seeing as it hasn't gone away, it seems sufficiently wierd to me that I thought it should be reported as a bug. Thanks, Helen Faulkner -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C Versions of packages kwalletmanager depends on: ii kdelibs4 4:3.3.0-2 KDE core libraries ii libart-2.0-2 2.3.16-6 Library of functions for 2D graphi ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-5client library to control the FAM ii libgcc1 1:3.4.2-3 GCC support library ii libice6 4.3.0.dfsg.1-8 Inter-Client Exchange library ii libidn11 0.5.2-3GNU libidn library, implementation ii libpng12-01.2.5.0-8 PNG library - runtime ii libqt3c102-mt 3:3.3.3-4.1Qt GUI Library (Threaded runtime v ii libsm64.3.0.dfsg.1-8 X Window System Session Management ii libstdc++51:3.3.5-1 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-8 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-8 X Window System miscellaneous exte ii libxrender1 0.8.3-7X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-8 X Window System client libraries m ii zlib1g1:1.2.2-1 compression library - runtime -- no debconf information
Bug#265835: juk segfaults on start with kde3.3
Adeodato Simó wrote: * Helen Faulkner [Sun, 15 Aug 2004 10:06:46 +0100]: I (possibly foolishly) upgraded to kdelibs Version: 4:3.3.0-1, and now juk segfaults when I try to start it. as Nick points out, juk 3.3 seems not to work with gstreamer anymore. I experienced the same crash and solved it by running "gst-register-0.6". after that, juk started but didn't play any files. had to change "Output to" from GStreamer to aRts. I don't think I'm using gstreamer (have always used arts before) but I tried what you suggested here, and it didn't seem to make any difference. I've also tried reinstalling juk (more than once), to no avail. When I try to start juk it still segfaults. I get the same backtrace as before. Helen.
Bug#265835: juk segfaults on start with kde3.3
Package: juk Version: 4:3.3.0-1 Severity: important Hello, I (possibly foolishly) upgraded to kdelibs Version: 4:3.3.0-1, and now juk segfaults when I try to start it. The backtrace is attached: Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1113034112 (LWP 3907)] [KCrash handler] #3 0x40174d96 in KAudioManagerPlay::KAudioManagerPlay () from /usr/lib/libartskde.so.1 #4 0x0806c348 in QWidget::setWFlags () #5 0x0806c541 in QWidget::setWFlags () #6 0x0806b3a8 in QWidget::setWFlags () #7 0x08088eba in QValueListPrivate::QValueListPrivate () #8 0x0808a7f1 in QValueListPrivate::QValueListPrivate () #9 0x0808a38d in QValueListPrivate::QValueListPrivate () #10 0x080891a4 in QValueListPrivate::QValueListPrivate () #11 0x080afd2f in QHBox::metaObject () #12 0x08081e64 in KDialogBase::metaObject () #13 0x08080699 in KDialogBase::metaObject () #14 0x08086f7d in QValueListPrivate::QValueListPrivate () #15 0x41a697f8 in __libc_start_main () from /lib/tls/libc.so.6 #16 0x41b8bedc in ?? () from /lib/tls/libc.so.6 Thanks, Helen.
Bug#252571: konqueror doesn't end process, so CD won't unmount
Package: konqueror Version: 4:3.2.2-1 I think konqueror is locking up my CD drive because it doesn't end a process properly when it should. I get this when I do the following: 1) I have a link to my cd drive on my kde desktop 2) I have a CD in the drive 3) right-click on the desktop link, choose "open" (this will mount /cdrom and then open konqeror showing the contents of the CD) 4) close that konqeror session 5) try to unmount /cdrom (I use the right-click -> unmount on the desktop link again) 6) it won't unmount because the device is busy. 7) it won't unmount forever until you reboot the computer What took me awhile to figure is that if I open kde system guard there's still a konqueror process running even though I closed that konq window that was looking at the cd contents. If I kill that process I can then unmount the CD. presumably that process is locking the drive. I don't think that process should still be there - it should go when you close that window. Thanks, Helen.
Bug#239049: kgpg editor doesn't appear
Package: kgpg Version: 4:3.2.1-1 The documentation for kgpg mentions an editor that should appear when you right-click on the system tray icon and choose "open editor". That doesn't work for me. If there's an different way to access the editor I can't see that either. When I run kgpg I can get the key management window, and that is all. This may not be relevant to the problem, but running kgpg from konsole gets me these messages as well as the system tray icon appearing in the panel: helen:~> kgpg kdecore (KAccel): WARNING: KKeySequence::init( seq ): key[0] is null. kdecore (KAccel): WARNING: KKeySequence::init( seq ): key[0] is null. QMetaObject::findSignal:KeyView: Conflict with QListView::doubleClicked(QListViewItem*,const QPoint&,int) QObject::connect: No such slot listKeys::slotOpenEditor() QObject::connect: (sender name: 'kgpg_editor') QObject::connect: (receiver name: 'key_manager') Thanks, Helen.
Bug#238417: kfind freezes when searching /usr
Package: kfind Version: 4:3.2.1-1 I am trying to use kfind to seach /usr which, at 1.7GB, is one of the larger directories in my filesystem. I have "include subfolders" checked. It seems to work alright for most directories, but when I ask it to search a large one, it appears to hang. I have tried leaving it for a long time (at least half an hour), incase it was just being slow. But it looks like it's actually died. I am sure kfind used to work OK searching in /usr, though I haven't used it to do that very recently. I am not certain that the size is the actual problem - it's just my best guess. Helen Faulkner.
