Hide Forgot
With the NM 0.7 snap in rawhide now, knetworkmanager no longer works. This breaks the KDE Live image.
*** Bug 298981 has been marked as a duplicate of this bug. ***
icky-poo, abi/api changes I assume?
Substantially so
Im on vacation right now and have very limited net access. I will try and dedicate some time to work on it. but dont let me hold anyone else back from working on it.
I'm going to publish a more recent snapshot next days, I just wait for a bug report from KDE bugzilla about a possible regression. I will also try to contact the maintainer of knetworkmanager if he has any idea about that topic.
fwiw, svn checkout as of today still doesn't support nm-0.7, filed RFE upstream: upstream: http://bugs.kde.org/show_bug.cgi?id=150064
Helmut Schaa has put some work into this so far, he's posted questions on the NM lists about 0.7 bits and appears to have some of it working. However, I can't find any of those bits in SVN anywhere...
FYI, Helmut Schaa has uploaded an NM 0.7 branch of knetworkmanager now: http://mail.gnome.org/archives/networkmanager-list/2007-September/msg00145.html http://websvn.kde.org/branches/work/knetworkmanager/ Any chance this can be imported soon? Can we get this into test3 or is that already frozen solid?
Well, knetworkmanager is effectively broken in its current state - at least we should remove it. The new version should be pushed to the repositories at least shortly after the release, in best case also for test 3. Can someone ask FESCO?
im working on getting the latest snapshot built that will work with 0.7 how well it will work is not yet known. But right now i am not going to recommend that we pull knetworkmanager. As someone on FESCo i would vote against pulling. It should not take too much work to have it working. hopefully before the end of the weekend we will have basic functionality restored.
FESCo is not the right group to ask to get this into test3 (nor to get it pulled, which I think is silly, we should get it fixed instead), Release Engineering is.
Ping? So what's the status here? * Was the definitive test3 cutoff already missed? Or is there still a way to get this into test3? * Dennis Gilmore, how's your work going? I'm not seeing anything in CVS. Does it fail to build?
It is currently failing to find some libraries that are installed in the build root. If it misses Test3 it will be available shortly after. Currently knetworkmanager is likely to only work with wired networks.
> If it misses Test3 it will be available shortly after. That won't be of much help for the test3 KDE-Live spin though. :-( But I guess that's life.
(In reply to comment #12) > * Was the definitive test3 cutoff already missed? Or is there still a way to > get this into test3? We're hoping to build the final test3 trees tomorrow. BUT, the live images are smaller and so we can probably stretch out the time for them until Tuesday if it helps. Dennis -- if you want some helping poking at it, let me know and I can prod it later tonight/tomorrow.
This doesn't look like it's in great shape after some looking... I wonder if we're going to be better off running the gnome nm-applet for test3, if not F8 in general :-/
yeah, I was starting to think the same thing... (gasp, using nm-applet)
So we'll need to add NetworkManager-gnome to the kde package list and then also set things up so that nm-applet gets auto-started, as well as gnome-keyring. For the purposes of test3, we should be able to do both of these just in the %post for the live config I think. I can try to take a look in a little bit if someone doesn't beat me to it.
(In reply to comment #18) > For the purposes of test3, we should be able to do both of these just in the > %post for the live config I think. I can try to take a look in a little bit if > someone doesn't beat me to it. For nm-applet it could go this was (without the wrap): %packages # ignore comps.xml and make sure these packages are included #knetworkmanager # include it nm-applet as a workaround for #298991 NetworkManager-Gnome gnome-keyring-daemon -knetworkmanager %post # adding some autostarted applications #cp /usr/share/applications/fedora-knetworkmanager.desktop /usr/share/autostart/ cp /usr/share/gnome/autostart/nm-applet.desktop /usr/share/autostart/ sed -i 's/OnlyShowIn=GNOME;XFCE;/OnlyShowIn=GNOME;XFCE;KDE;/' /usr/share/autostart/nm-applet.desktop I'm not sure how to start gnome-keyring-daemon.
(In reply to comment #19) > NetworkManager-Gnome > gnome-keyring-daemon Sry. These are the right package names: NetworkManager-gnome gnome-keyring
Test compose going that should add the keyring bits also based on some googling. Relevant excerpt +# and set up gnome-keyring to startup/shutdown in kde +mkdir -p /etc/skel/.kde/env /etc/skel/.kde/shutdown +cat > /etc/skel/.kde/env/start-custom.sh << EOF +#!/bin/sh +eval `gnome-keyring-daemon` +export GNOME_KEYRING_PID +export GNOME_KEYRING_SOCKET +EOF +chmod 755 /etc/skel/.kde/env/start-custom.sh + +cat > /etc/skel/.kde/shutdown/stop-custom.sh << EOF +#/bin/sh +if [-n "$GNOME_KEYRING_PID"];then +kill $GNOME_KEYRING_PID +fi +EOF +chmod 755 /etc/skel/.kde/shutdown/stop-custom.sh
*** Bug 330201 has been marked as a duplicate of this bug. ***
*** Bug 330571 has been marked as a duplicate of this bug. ***
My plan for knetworkmanage initially is to write a wrapper script that will call nm-applet and have knetworkmanager Requires the NetworkManager bits. this way when knetworkmanager is ported and useable with the new api we can push out an update that will return knetworkmanage to the distro. Does this make sense to all? It will most likely require mention in the release notes.
(In reply to comment #24) > My plan for knetworkmanage initially is to write a wrapper script that will > call nm-applet and have knetworkmanager Requires the NetworkManager bits. > this way when knetworkmanager is ported and useable with the new api we can > push out an update that will return knetworkmanage to the distro. > > Does this make sense to all? I think so. Fake knetworkmanager and working network is better than real not working knetworkmanager :-) > It will most likely require mention in the release notes. Sure, will save some questions and complaints :-)
(In reply to comment #24) > My plan for knetworkmanage initially is to write a wrapper script that will > call nm-applet and have knetworkmanager Requires the NetworkManager bits. > this way when knetworkmanager is ported and useable with the new api we can > push out an update that will return knetworkmanage to the distro. > > Does this make sense to all? > > It will most likely require mention in the release notes. > > Better do it quickly. I hope to have the golden package set by mid next week.
(In reply to comment #24) > My plan for knetworkmanage initially is to write a wrapper script that will > call nm-applet and have knetworkmanager Requires the NetworkManager bits. > this way when knetworkmanager is ported and useable with the new api we can > push out an update that will return knetworkmanage to the distro. > > Does this make sense to all? > > It will most likely require mention in the release notes. If your're doing so: Should we re-include knetworkmanager on the kde live images? (the package is removed for now).
The wrapper package is in Rawhide now. And yes, the idea is that you include the fake knetworkmanager package in the live CD so it can be updated to the real one once it works (see Dennis's comment #24).
(In reply to comment #28) > The wrapper package is in Rawhide now. The current package (knetworkmanager-0.2-0.5.svn20071022.fc8) is missing entries in /etc/skel/.kde/env/start-custom.sh and /etc/skel/.kde/shutdown/stop-custom.sh Is this corrected, yet? And just to get sure: The tag "f8-final" in koji means that it will be available in the official release (and so I can include it on the live images)? (Sorry for the question) > And yes, the idea is that you include the fake knetworkmanager package in the > live CD so it can be updated to the real one once it works (see Dennis's > comment #24). Ok. Just want to get sure about this.
> And just to get sure: The tag "f8-final" in koji means that it will be > available in the official release (and so I can include it on the live > images)? (Sorry for the question) Yes.
removing nm07tracker block, as this isn't considered a blocker anymore
> I think so. Fake knetworkmanager and working network is better than real not > working knetworkmanager :-) > I think you should downgrade the nm to one on knetworkmanager works btw with this nm wireless stops works. Because knetworkmanager rocks , and nm-applet is a great **** **** on kde
i can connect to everyone's network except my own thanks to this bug.
Paul: unlikely. knetworkmanager is only a frontend to NM and should not disturb the ability of NM in any kind. If you have a problem with NM, please fill a bug report against it.
*** Bug 426177 has been marked as a duplicate of this bug. ***
OpenSUSE is now shipping this in Factory: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/src/NetworkManager-kde-0.7r759902-5.src.rpm I think we should really be able to get this into Rawhide at least! We'll need the new DBus Qt 3 bindings (backported from the Qt 4 ones) though, i.e. these: http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/suse/src/libdbus-1-qt3-0-0.8-11.src.rpm Our dbus-qt bindings are the old version, so we need a new package with the new bindings. (The 2 bindings should be able to coexist, OpenSUSE is shipping them both.)
Created 434834 for F9.
*** Bug 434877 has been marked as a duplicate of this bug. ***
Hi Just to add. I got the following when I try to run knetworkmanger out of the terminal. I also had a hard time starting the networkmander and NetworkManagerDispatcher. This is my error [$$%%#$@localhost ~]$ knetworkmanager ** (nm-applet:5146): WARNING **: <WARN> applet_dbus_manager_start_service(): Could not acquire the NetworkManagerUserSettings service as it is already taken. Return: 3 (nm-applet:5146): GLib-CRITICAL **: g_hash_table_destroy: assertion `hash_table != NULL' failed (nm-applet:5146): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (nm-applet:5146): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed If this helps.. Chris
That means that your trying to start the gnome NetworkManager applet when it is already running. knetworkmanager is still just a script that calls nm-is already running. knetworkmanager is still just a script that calls nm-applet
Ok so if I stop the networkmanager and NetworkManagerDispatcher then run knetworkmanager it should start the service? Sorry it use to bring up a windows in 3.5 so I don't know if that changed. Cause when my service was not started it did the same thing.. Chris
No, knetworkmanager isn't in rawhide *at all* atm. Reminds me, I was going to try to get that tagged/building again to see if we could get it into f9-beta for wider testing. (Then I got sick last week, ugh).
o ok. so the one I got from the list does not work.. makes more sens to me.. I hope you feel better now. I was hoping to see if I can get this 3g, mobile internet tested. but don;t know where to start or how to get it going.. ;) Chris
fyi, we've EOL'd/dead.package'd knetworkmanager until upstream makes a release that resembles something usable.
Closing->Upstream (will continue to track there)