Just wondering if anyone else has the same problem. I am running Debian unstable, and I just (2005-08-17) ran a aptitude update / upgrade. Now nothing appears in the KMenu, and none of the categories exist in the KControl. Has anyone else run into this problem? Is there anyway to fix it besides waiting on aptitude to have the fixes?
Just a rant here, but is it just me or is Debian Unstable way too unstable? It's not like the packages that are being upgraded are bleeding edge. Nearly all the major Linux distros already run a later version of the kernel, KDE, gcc, etc and they don't seem to have these kinds of problems. I can't use the KMenu, I can't change anything in KControl, KMail still doesn't work, good grief what's next.
Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
KMenu and KControl doesn't work
8-|
It is really boring... I am not able to find where does it come from....
The thing is, if i log with twm, the menu is ok.... So the update-menus still works but there is no method for kmenu in /etc/menu-methods/ and i do not know if there was one before (but it should have one....)
I am still searching which package the bug is coming from before sending a bug report cause it may comes from kde or menu package....
If you have any ideas or had the same problem in the past......
Thanx.
The thing is, if i log with twm, the menu is ok.... So the update-menus still works but there is no method for kmenu in /etc/menu-methods/ and i do not know if there was one before (but it should have one....)
I am still searching which package the bug is coming from before sending a bug report cause it may comes from kde or menu package....
If you have any ideas or had the same problem in the past......
Thanx.
-
Guest
Harold, I know that line is pretty silly. 
However, it feels like Debian has no repository that provides a reasonable desktop experience, the closest repository is unstable, and that has become too unstable for daily use. Maybe that's the key though, Debian's not a desktop distro. I love apt, and the way Debian is organized, perhaps it's time to give Kubuntu a try. I dunno.
However, it feels like Debian has no repository that provides a reasonable desktop experience, the closest repository is unstable, and that has become too unstable for daily use. Maybe that's the key though, Debian's not a desktop distro. I love apt, and the way Debian is organized, perhaps it's time to give Kubuntu a try. I dunno.Have you tried testing?Harold, I know that line is pretty silly. Smile However, it feels like Debian has no repository that provides a reasonable desktop experience, the closest repository is unstable, and that has become too unstable for daily use. Maybe that's the key though, Debian's not a desktop distro. I love apt, and the way Debian is organized, perhaps it's time to give Kubuntu a try. I dunno.
brojnev
PostPosted: 2005-08-18 17:46
Here is same problem and if you read the whole thread you can also find some kind of solution.
http://lists.debian.org/debian-kde/2005 ... 00177.html
http://lists.debian.org/debian-kde/2005 ... 00177.html
nice
thank u for the link .petteri wrote:Here is same problem and if you read the whole thread you can also find some kind of solution.
http://lists.debian.org/debian-kde/2005 ... 00177.html
The World According to Harold
mount /dev/soapbox
My belief is that the Debian philosophy of developing a distro for installation on a multitude of platforms has to make Debian developers' jobs exceptionally frustrating. I'm not a programmer, and I might be totally off-track. But is seems to me that Debian's requirement of developing (meaning "debugging") each and every package for Alpha, ARM, HP PA-RISC, Intel 32-bit, Intel 64-bit, Motorola 68k, MIPS, MIPS (DEC), PowerPC, IBM S/390 and SPARC has to irk some developers who know that most or all installs of their packages are onto Intel 32-bit platforms. (Warning, I have nothing to support that last sentence, it's purely gut feel, and obviously results vary from package to package.)
I think the *BSD people have the right idea. FreeBSD concentrates on Intel-32 bit platform availability. NetBSD concentrates on multi-platform availability, OpenBSD concentrates on security, and the three groups share code amongst themselves. What a wonderful structure!
Now back to Debian and its increasing difficulty in making timely transitions from Testing to Stable... Is the problem that developers' efforts are being diluted by the support-every-CPU-on-the-planet policy, or that the Debian community is a demarchy, or both? My opinion: both.
In The World According to Harold, the Debian community should, as quickly as possible, identify the date on which Etch will transition to stable. 6 June 2006 would be a fine day to do this. On that day, Etch would transition to Stable, whatever RC bugs were still in the code would be carried along into Stable, and would be corrected ASAP(1). Testing would move forward immediately(2).
1. Is it a problem carrying RC bugs into Stable for a short(?) time? My sources.list has pointed to Testing for three years now. If there have been that many RC bugs in Testing for all this time, how come I have had so few problems? (more on this two paragraphs from now) "RC" must mean something different to programmers than it does to this Linux "user."
2. If developers knew well ahead of time the date on which the transition would occur, they could (and would) plan around it, easing not only the transition to Stable, but also renewal of progress in Testing. Under the current mantra of "It's ready when it's ready," Testing was repeatedly frozen, thawed, chilled, defrosted and reheated between July 2002 and June 2005. No doubt there was some freezer burn in there also.
Following the release of Sarge, Debian developers are embarked upon major transitions to GCC-4.0, X-Org, and packages that alter the fundemental structure of the distro, and downstream developers can only wait whilst upstream dependencies are resolved. Currently about 2,000 packages are stalled in the transition from Unstable into Testing, and half of those are waiting, directly or indirectly, upon glibc.
To be perfectly honest, it wouldn't bother me in the least if Stable simply ceased to exist. My experience is that Testing is stable. The very few problems I've had were dpkg script problems, and the package manager invariably made corrections within 24-48 hours. If I didn't do apt-get update/upgrade every day, I would never have experienced those problems. How many sysops do apt-get update/upgrade on their servers every day? (Nope, I don't know a single one either.)
Harold's suggestions:
1. Do Testing-to-Stable transitions at fixed intervals on well-established dates. (Maybe once per year?)
2. Re-evaluate the value of having packages simultaneously developed for all available CPUs. This can be done on the whole or on a package-by-package basis.
Now if you guys will excuse me, it's getting late and I have to go outside and herd the cats...
umount /dev/soapbox
My belief is that the Debian philosophy of developing a distro for installation on a multitude of platforms has to make Debian developers' jobs exceptionally frustrating. I'm not a programmer, and I might be totally off-track. But is seems to me that Debian's requirement of developing (meaning "debugging") each and every package for Alpha, ARM, HP PA-RISC, Intel 32-bit, Intel 64-bit, Motorola 68k, MIPS, MIPS (DEC), PowerPC, IBM S/390 and SPARC has to irk some developers who know that most or all installs of their packages are onto Intel 32-bit platforms. (Warning, I have nothing to support that last sentence, it's purely gut feel, and obviously results vary from package to package.)
I think the *BSD people have the right idea. FreeBSD concentrates on Intel-32 bit platform availability. NetBSD concentrates on multi-platform availability, OpenBSD concentrates on security, and the three groups share code amongst themselves. What a wonderful structure!
Now back to Debian and its increasing difficulty in making timely transitions from Testing to Stable... Is the problem that developers' efforts are being diluted by the support-every-CPU-on-the-planet policy, or that the Debian community is a demarchy, or both? My opinion: both.
In The World According to Harold, the Debian community should, as quickly as possible, identify the date on which Etch will transition to stable. 6 June 2006 would be a fine day to do this. On that day, Etch would transition to Stable, whatever RC bugs were still in the code would be carried along into Stable, and would be corrected ASAP(1). Testing would move forward immediately(2).
1. Is it a problem carrying RC bugs into Stable for a short(?) time? My sources.list has pointed to Testing for three years now. If there have been that many RC bugs in Testing for all this time, how come I have had so few problems? (more on this two paragraphs from now) "RC" must mean something different to programmers than it does to this Linux "user."
2. If developers knew well ahead of time the date on which the transition would occur, they could (and would) plan around it, easing not only the transition to Stable, but also renewal of progress in Testing. Under the current mantra of "It's ready when it's ready," Testing was repeatedly frozen, thawed, chilled, defrosted and reheated between July 2002 and June 2005. No doubt there was some freezer burn in there also.
Following the release of Sarge, Debian developers are embarked upon major transitions to GCC-4.0, X-Org, and packages that alter the fundemental structure of the distro, and downstream developers can only wait whilst upstream dependencies are resolved. Currently about 2,000 packages are stalled in the transition from Unstable into Testing, and half of those are waiting, directly or indirectly, upon glibc.
To be perfectly honest, it wouldn't bother me in the least if Stable simply ceased to exist. My experience is that Testing is stable. The very few problems I've had were dpkg script problems, and the package manager invariably made corrections within 24-48 hours. If I didn't do apt-get update/upgrade every day, I would never have experienced those problems. How many sysops do apt-get update/upgrade on their servers every day? (Nope, I don't know a single one either.)
Harold's suggestions:
1. Do Testing-to-Stable transitions at fixed intervals on well-established dates. (Maybe once per year?)
2. Re-evaluate the value of having packages simultaneously developed for all available CPUs. This can be done on the whole or on a package-by-package basis.
Now if you guys will excuse me, it's getting late and I have to go outside and herd the cats...
umount /dev/soapbox
-
pmartinez
KDE Menu lost
So is there a solution for the lost Programs in KDE-Menu .
I have the same problem. After I downgraded to stable the Programs disapeared from KDE-Menu and there is no way to get them back because KDE-Control Menu is not working.
Any ideas?
pe
I have the same problem. After I downgraded to stable the Programs disapeared from KDE-Menu and there is no way to get them back because KDE-Control Menu is not working.
Any ideas?
pe