WICD is a powerful tool for wired and wireless network manager This is an ebuild for install the version 1.3.1, the software is writen in python and don't need to be compiled. Reproducible: Always
Created attachment 135341 [details] new ebuild
Created attachment 135559 [details] ebuild corrected added a dependecy from dbus-python
(In reply to comment #2) > Created an attachment (id=135559) [edit] > ebuild corrected > > added a dependecy from dbus-python > it could be a good idea to commit your ebuild to sunrise overlay , for infos : http://www.gentoo.org/proj/en/sunrise/
Thanks for the wicd ebuild! It seems more stable than NetworkManager on my Macbook Pro. I support the suggestion to submit it to the sunrise overlay at least.
Also, when will we have a wicd-1.3.4 ebuild? (ok, should be trivial to patch, but...)
Created attachment 137514 [details] Cleaned-up, more generic ebuild I've attached a cleaned-up version of the ebuild for WICD 1.3.4. It now uses SourceForge mirrors and does not contain a hard-coded version number anymore, but gets it from the ebuild filename. So for future versions, you should be able to just rename the file and run "ebuild <filename> digest && emerge -uv wicd" to install the most recent version.
wicd doesn't seem to work with dhcpcd (calls dhclient hardcoded in the daemon-scripts) just emerged dhcp and everything was sweet, so ihmo wicd should depend on net-misc/dhcp as well
Created attachment 138397 [details] Correct net-misc/dhcp dependency Thanks Jasper for correction
Comment on attachment 135559 [details] ebuild corrected miss dependency
Created attachment 138608 [details] update ebuild to 1.3.8, add ethtool dependency also needs sys-apps/ethtool to work with wired interfaces
Created attachment 140183 [details] wicd initscript include dependency to "dbus" in start-script uses runscript instead of simple bash script place this under /files/, using the wicd-1.3.8-r1 ebuild
Created attachment 140184 [details] new ebuild using the new init.d script use this together with the init.d script above
1.4.1 is listed as stable on official site
A thought for the ebuild: http://users.zenwalk.org/user-accounts/gapan/wicd/ZENBUILD The above link is a Zenwalk build script for Wicd. This includes the lines: "# Replace dhclient with dhcpcd and ip with route sed -i -e "s/dhclient /dhcpcd /g" /opt/wicd/networking.py sed -i -e "s/ip route flush dev/route del dev/g" /opt/wicd/networking.py" Would it be worth adding this to the src_install() section of the ebuild? This would make Wicd more suitable for Gentoo, although I have no idea whether this is/would/could be supported upstream. In any case, I've tested the latest ebuild (1.3.8-r1) with this 'modification' and it works.
(In reply to comment #14) > A thought for the ebuild: > http://users.zenwalk.org/user-accounts/gapan/wicd/ZENBUILD > The above link is a Zenwalk build script for Wicd. This includes the lines: > > "# Replace dhclient with dhcpcd and ip with route > sed -i -e "s/dhclient /dhcpcd /g" /opt/wicd/networking.py > sed -i -e "s/ip route flush dev/route del dev/g" /opt/wicd/networking.py" > > Would it be worth adding this to the src_install() section of the ebuild? This > would make Wicd more suitable for Gentoo, although I have no idea whether this > is/would/could be supported upstream. In any case, I've tested the latest > ebuild (1.3.8-r1) with this 'modification' and it works. > While the hardcoded dhclient commands are a problem, your solution isn't any better; it's just hardcoding a different dhcp client. There are at least 3 or 4 dhcp clients in Portage last I checked, so we shouldn't make any assumptions that the user has one of them installed. USE flags don't seem to be the best way to do this, either, as those are supposed to be for compile-time switches. Neither is looking at the live filesystem and seeing what's installed on the user's machine. Hmm.
(In reply to comment #14) I filed a bug upstream on making wicd a little more permissive of other dhcp clients: https://bugs.launchpad.net/wicd/+bug/191091
Created attachment 144165 [details] wicd-1.4.2.ebuild Latest stable is 1.4.2. I cleaned up the ebuild; removed the unnecessary dependency on ethtool (the package actually needs net-tools, which is already in the system set), added a virtual/dhcpc RDEP, as well as proper RDEPs for wpa_supplicant and wireless-tools. I also fixed the required gtk+ version. Yes, pygtk already depends on gtk+...just not the minimum required version. Note that wicd-1.5.0, when it's finally packaged, will be the first version to not depend on a particular dhcp client; this new ebuild is forward thinking in that regard (the virtual RDEP). In the meantime, you'll need the SVN version if you want to use your own dhcp client such as pump, dhcpcd, etc.
Created attachment 144718 [details] wicd-1.4.2.ebuild Much improved ebuild. Fixed dependencies; re-added ethtool since it is required for 1.4.2 at least. This ebuild continues to use the provided initscript. In the future, 1.5 and above won't require net-misc/dhcp (only virtual/dhcpc), and I requested that upstream remove the hardcoded ethtool commands, too (in favor of net-tools or adding another check method). TODO: 1. Figure out how to ensure that ntp-client and other services that need "net" will run after wicd has been started. 2. Provide more information in the ebuild on what to change in e.g. /etc/conf.d/rc to have networking work at boot.
The init script doesn't work very well in a Gentoo environment. It doesn't provide net, launch via runscript.sh, etc. Do you plan on adding support for these issues? Thanks!
(In reply to comment #19) > The init script doesn't work very well in a Gentoo environment. It doesn't > provide net, launch via runscript.sh, etc. Do you plan on adding support for > these issues? Thanks! > Unfortunately, I have no idea how to provide those things at the moment. Hell, I can't even get it to work anymore on my laptop, so I've stopped using it for now. I really, really *want* to use it, but it just doesn't seem workable in Gentoo. It won't come up at boot, and it's still hardcoded to use (crappy) dhcp clients and (crappy) network utilities. As you said, it's also more or less completely unworkable with our initsystem, too. For the providing net stuff, taking a look at NetworkManager might be useful. I know that for the longest time, perhaps even now, NM had the same problem; it couldn't provide net, so things like ntp-client wouldn't start on their own. Maybe that's fixed; NM seems more stable than wicd.
Created attachment 145616 [details] /etc/dbus-1/system.d/wicd.conf double check /opt/wicd/data/wicd.log to see if you are having the same error I had with wicd 1.4.2, "dbus.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.12" is not allowed to own the service "org.wicd.daemon" due to security policies in the configuration file" The attached /etc/dbus-1/system.d/wicd.conf works for me to resolve that error. (I'm getting a connection, still investigating what is needed to provide the virtual net service.)
(In reply to comment #21) You need to report and send this upstream at the wicd bugtracker, https://launchpad.net/wicd, not here. Gentoo can't do anything about this; only upstream can get it fixed.
(In reply to comment #22) The distribution copy of the file works without changes in Ubuntu/Debian (the coding targets). I posted here since you reported a problem having wicd work on your laptop and verifying that it was a distribution change rather than just my system would have been good before bumping the report upstream. Net services are starting at boot for me with a change to the depend section of the init script: depend() { need dbus after net.lo provide net } I did edit /etc/conf.d/rc so hotplug would not start the net.<iface> scripts automatically during boot (so wicd could control them). RC_PLUG_SERVICES="!net.*" Good luck with getting wicd into portage.
wicd is in the Sunrise overlay now, available at http://overlays.gentoo.org/svn/proj/sunrise/reviewed/net-misc/wicd/
(In reply to comment #24) > wicd is in the Sunrise overlay now, available at > http://overlays.gentoo.org/svn/proj/sunrise/reviewed/net-misc/wicd/ > This did not originally work for my network, and it turned out that it was because it was WPA2. Following the advice at http://wicd.sourceforge.net/phpbb/viewtopic.php?f=3&t=178 (second post down), I added support for WPA2. I also followed the advice of comment #23 here and added a couple lines to depend() in the initscript in order to provide net services. (I haven't rebooted yet, so I'm not sure how well that is working.) Now everything seems to be working quite well for me, and a heck of a lot better than NetworkManager was (I was getting frequent disconnections from my access point). Here is a patch to apply immediately before installation (I think... I'm not too familiar with patching). Perhaps these changes could be incorporated into the Sunrise repository? (I'm not too familiar with how that works, either, so forgive me if I'm out of place here.) ((Sorry for all the parenthetical remarks :-)))
Created attachment 155137 [details] patch mentioned in comment #25
For me, "provide net" was not actually causing wicd to provide net. During shutdown, I see the message Cannot add provide "net", as a service with the same name exists For some reason, the message does not show up in /var/log/messages or anywhere that I could find. I verified that the only net.* service in /etc/init.d is net.lo, and I grepped the init files for "provide net" to no avail, so if anyone has any ideas what service might be erroneously providing net, I would happily accept the advice. The result, at any rate, was that wicd was not being started before network services, as I wanted it to be. The workaround for me was to use "before net" instead of "provide net". Of course, if there was nothing providing net in the first place, using "before" would make no sense. At any rate, the workaround is currently solving the problem and causing wicd to correctly be started before any services require net. One more suggestion is to add "&& sleep n" to the end of start-stop-daemon in start(), where "n" is the approximate amount of time it takes wicd to startup and associate with your network(s). This ensures that you will actually be connected to a network (if available) before net services are initiated. (Note that you want n to be as small as possible since it will delay boot). It was mentioned in comment #20 that NetworkManager also does not provide net, but this is because it is not capable of doing so. NetworkManager (at least for me) doesn't seem to connect until nm-applet is started by my desktop session. Wicd is different in that tray.py is just a convenient way to gain access to wicd itself, which initiates the connection as soon as it starts up. For this reason, along with the fact that I have had no disconnection issues as of yet (they were quite frequent with NM), I must say that I feel wicd is far superior to NetworkManager, and I would love to see it added to portage.
Created attachment 155203 [details] My /etc/init.d/wicd file (works for me) See comment #27 for explanation
Hello! Does anyone have the wicd-1.5.0-rc1 ebuild file? Today the latest version has been relased. Regards, Flavio
(In reply to comment #29) > Hello! > > Does anyone have the wicd-1.5.0-rc1 ebuild file? > Today the latest version has been relased. > > Regards, > > Flavio > The only modify to the previous ebuild is SRC_URI="http://kent.dl.sourceforge.net/sourceforge/wicd/wicd-1.5.0-rc1.tar.bz2" at the moment, but I don't know if it's correct. The compilation has gone ok. Let me do some tests.
(In reply to comment #30) > (In reply to comment #29) > > Hello! > > > > Does anyone have the wicd-1.5.0-rc1 ebuild file? > > Today the latest version has been relased. > > > > Regards, > > > > Flavio > > > The only modify to the previous ebuild is > SRC_URI="http://kent.dl.sourceforge.net/sourceforge/wicd/wicd-1.5.0-rc1.tar.bz2" > at the moment, but I don't know if it's correct. > The compilation has gone ok. Let me do some tests. > After emerging the wicd package version 1.5.0-rc1 some script, (e.g. tray.py, gui.py, ecc.) are not present.
there is an other version, 1.5.0rc5 Can we do an overlay with it ? https://sourceforge.net/project/showfiles.php?group_id=194573&package_id=233390&release_id=610998
(In reply to comment #32) > there is an other version, 1.5.0rc5 > > Can we do an overlay with it ? > > https://sourceforge.net/project/showfiles.php?group_id=194573&package_id=233390&release_id=610998 > Try this handcraft ebuild an let me know. http://rafb.net/p/8RxtLC97.html Flavio
I tried the last version using that ebuild but, as for the previous one (rc1 release) the gui is not longer present. Do you know why?
I just submitted an ebuild and init-script to sunrise for wicd-1.5.0rc5
(In reply to comment #35) > I just submitted an ebuild and init-script to sunrise for wicd-1.5.0rc5 > Is it available somewhere?
It hasn't been commited to the 'reviewed' section yet, probably within the next day or two? If you don't want to grab the files by hand, i wrote a script that will download whole packages from http://overlays.gentoo.org/proj/sunrise/browser/sunrise/ : http://rafb.net/p/tnXOcE94.html
(In reply to comment #33) > (In reply to comment #32) > > there is an other version, 1.5.0rc5 > > > > Can we do an overlay with it ? > > > > https://sourceforge.net/project/showfiles.php?group_id=194573&package_id=233390&release_id=610998 > > > > Try this handcraft ebuild an let me know. > http://rafb.net/p/8RxtLC97.html > > Flavio > rafb.net has deleted the ebuild I posted before. Here's again: # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION="A wired and wireless network manager for Linux" HOMEPAGE="http://wicd.sourceforge.net/" MY_P="${PN}_${PV}" SRC_URI="http://dfn.dl.sourceforge.net/sourceforge/wicd/wicd-1.5.0rc5.tar.gz" #SRC_URI="mirror://sourceforge/${PN}/${MY_P}.tar.bz2" LICENSE="GPL" IUSE="" KEYWORDS="~x86 ~amd64" SLOT="0" DEPEND="" RDEPEND="sys-apps/dbus dev-python/dbus-python dev-python/pygtk sys-apps/ethtool >=x11-libs/gtk+-2" src_install() { cd ${WORKDIR} && cp -a * ../image newinitd ${FILESDIR}/${P}-init.d wicd insinto / } pkg_postinst() { einfo einfo "Start the WICD GUI using:" einfo " /opt/wicd/gui.py" einfo } Anybody was able to use the wicd GUI in the last release?? It seems to be not present! It's strange, isn't it?
(In reply to comment #38) > Anybody was able to use the wicd GUI in the last release?? it is because the gui is now in /usr/bin/wicd-client . I'm using last wicd from sunrise : 1.5.0_rc5
(In reply to comment #39) > (In reply to comment #38) > > > Anybody was able to use the wicd GUI in the last release?? > > it is because the gui is now in /usr/bin/wicd-client . I'm using last wicd from > sunrise : 1.5.0_rc5 > Thank you so much. It works very well for me too. What about the tray icon?
(In reply to comment #40) > What about the tray icon? > I found it in /etc/xdg/autostart but, it's a .desktop file. What do you do to start it automatically each time you enter in the window manager?
(In reply to comment #41) > (In reply to comment #40) > > > What about the tray icon? > > > > I found it in /etc/xdg/autostart but, it's a .desktop file. > What do you do to start it automatically each time you enter in the window > manager? > For me , I use gnome, I didn't need to do anything, the tray comes up on each login . Since that .desktop file is in /etc/xdg/autostart/ , each window manager that suites freedesktop.org standards should add this program to "autostart" applications. I think that also KDE for example will also support this standard. Which WM do you use ?
(In reply to comment #42) > (In reply to comment #41) > > (In reply to comment #40) > > > > > What about the tray icon? > > > > > > > I found it in /etc/xdg/autostart but, it's a .desktop file. > > What do you do to start it automatically each time you enter in the window > > manager? > > > > For me , I use gnome, I didn't need to do anything, the tray comes up on each > login . Since that .desktop file is in /etc/xdg/autostart/ , each window > manager that suites freedesktop.org standards should add this program to > "autostart" applications. I think that also KDE for example will also support > this standard. > Which WM do you use ? > I use KDE, but it doesn't work with it. I don't know why. Maybe I should emerge some package to get it working?
wicd-1.5 merged the tray and client script into one application, 'wicd-client'. Just add that to your startup script by hand if the .desktop file doesn't work for you automatically. I had to do this for my fluxbox, for instance -- i added 'wicd-client &' to ~/.fluxbox/startup. The WICD documentation has more information on how to do this, or check the documentation for your window manager / desktop environment.
On a more gentoo-ish note, anyone know the best way to merge / combine this application into gentoo for handling the network config? I noticed earlier in this bug people are disabling all of their net scripts, for instance. Is this the best way to go? I'm leaving all of my net scripts intact and enabled, and starting wicd after all my net scripts are up (using it to configure on the fly as I need), but I don't know if that's a good idea or not, and as I do get some undefined behaviour from my wireless settings (which could be related to conflicts maybe?) i'm wondering.. I don't think wicd should simply "provide net", because wicd is started and running before the net links are; however, maybe the net.whatever init scripts should be disabled and then called by wicd after the network has been associated? (..some sort of modules=("wicd") setting in conf.d/net could specify this?..)
Instructions for installing on gentoo are now added to the WICD downloads page. :) http://wicd.sourceforge.net/download.php
nice app, I really like it. I'll be maintaining this in the portage tree now. TODO: -fix init scripts -add back the x86 keyword, soon. Just have to test it quick. -monitor the quick development of the 1.5 branch. I see I am already outdated. dang. all: Thanks alot for the work on this, please stay active in bugzilla. I need your help ;) Maybe we can convince upstream to 'officially support' us too. AFAIK, there target platform is Ubuntu.
(In reply to comment #47) > nice app, I really like it. > > I'll be maintaining this in the portage tree now. > > TODO: > -fix init scripts > -add back the x86 keyword, soon. Just have to test it quick. > -monitor the quick development of the 1.5 branch. I see I am already outdated. > dang. > > all: Thanks alot for the work on this, please stay active in bugzilla. I need > your help ;) Maybe we can convince upstream to 'officially support' us too. > AFAIK, there target platform is Ubuntu. > wicd is very useful but I still have a lot of trouble to associate to hidden access points. I need to attempt connection many time before associating.
Created attachment 162001 [details] wicd-1.4.2 ebuild using doins and dosym instead of mv I've modified the wicd-1.4.2 ebuild. The attached version uses doins and dosym macros instead of mv.
(In reply to comment #49) > Created an attachment (id=162001) [edit] > wicd-1.4.2 ebuild using doins and dosym instead of mv > > I've modified the wicd-1.4.2 ebuild. The attached version uses doins and dosym > macros instead of mv. > After thinking about it some more, I might just drop 1.4.2, would that cause headaches for anyone? The 1.5 branch is working well for me and the upstream development is responsive to my requests. If I get a large response here, I will keep 1.4.2 and pay more attention to it.
Hmm, why is the version in portage only with amd64? This works on x86 as well, does it not? (Works for me on x86)
(In reply to comment #51) > Hmm, why is the version in portage only with amd64? This works on x86 as well, > does it not? (Works for me on x86) Did you not bother to read comment #47? @darkside, I recommend skipping 1.4.2 entirely; it really is quite a mess, with a few too many dependencies. Upstream planned for 1.5 to not hard-dep on things like ethtool or dhcp/pump and a couple of other things; 1.4.2 was hardcoded to them, and this introduced some crap dependencies that most Gentoo users don't have installed. The 1.5 ebuild you have now seems to take this into account, though I think I recall there's some sort of virtual/dhcp that could be used instead? Also, you typoed the DESCRIPTION in the 1.5_rc11 ebuild -- "s/lightwieght/lightweight/g". :) Last issue -- does this initscript actually work with Gentoo? Last I checked, it's never worked, not for 1.4, and not for 1.5. Judging from the progress of the bug, some users had to delete all networking initscripts from every runlevel and implement other hackery to get wicd "working". If 1.5 works with the existing net system, providing net for services like ntp-client, then I'll start using it again on my laptop. :)
(In reply to comment #52) > (In reply to comment #51) > > Hmm, why is the version in portage only with amd64? This works on x86 as well, > > does it not? (Works for me on x86) > > Did you not bother to read comment #47? ~x86 kw is now added. Verified that it works. > > @darkside, > > I recommend skipping 1.4.2 entirely; it really is quite a mess, with a few too > many dependencies. Upstream planned for 1.5 to not hard-dep on things like > ethtool or dhcp/pump and a couple of other things; 1.4.2 was hardcoded to them, > and this introduced some crap dependencies that most Gentoo users don't have > installed. The 1.5 ebuild you have now seems to take this into account, though > I think I recall there's some sort of virtual/dhcp that could be used instead? > 1.4.2 is dropped because upstream has now released 1.5.0 final. I don't want to worry about 1.4.2, I feel like it is a lost cause to support that in Gentoo. > Also, you typoed the DESCRIPTION in the 1.5_rc11 ebuild -- > "s/lightwieght/lightweight/g". :) done. thx > > Last issue -- does this initscript actually work with Gentoo? Last I checked, > it's never worked, not for 1.4, and not for 1.5. Judging from the progress of > the bug, some users had to delete all networking initscripts from every > runlevel and implement other hackery to get wicd "working". If 1.5 works with > the existing net system, providing net for services like ntp-client, then I'll > start using it again on my laptop. :) Is removing net.* from runlevels hackery? I decided to leave the init scripts as is until I hear of a better solution for it. I took the "network manager" approach to its init script within Gentoo and it worked fine for me. That is, remove net.* from runlevels, block udev from loading net.*, and add wicd to a runlevel. Everything started fine for me, sshd, net.lo, ntpd, etc. If that is acceptable for network manager, then it is acceptable for wicd, IMO. Suggestions welcome. thanks for input, all. 1.5.0 final is released and now in the tree, please use that ;) Please open new bugs if needed, I don't want this one to live on any longer.
(In reply to comment #52) > (In reply to comment #51) > > Hmm, why is the version in portage only with amd64? This works on x86 as well, > > does it not? (Works for me on x86) > > Did you not bother to read comment #47? Read it and then forgot it when I posted. Happens when you are too eager. :)
> > Last issue -- does this initscript actually work with Gentoo? Last I checked, > > it's never worked, not for 1.4, and not for 1.5. Judging from the progress of > > the bug, some users had to delete all networking initscripts from every > > runlevel and implement other hackery to get wicd "working". If 1.5 works with > > the existing net system, providing net for services like ntp-client, then I'll > > start using it again on my laptop. :) > > Is removing net.* from runlevels hackery? I decided to leave the init scripts > as is until I hear of a better solution for it. I took the "network manager" > approach to its init script within Gentoo and it worked fine for me. That is, > remove net.* from runlevels, block udev from loading net.*, and add wicd to a > runlevel. Everything started fine for me, sshd, net.lo, ntpd, etc. If that is > acceptable for network manager, then it is acceptable for wicd, IMO. > Suggestions welcome. Just a last comment. The initscript did not work with 1.4 but with 1.5 it is working. I am using baselayout-2 and openRC. Moreover, I am using ifplugd on my net connections and wicd starts as expected and the tray icon is also there as expected without adding anything in the autostarted applications in the session options.
(In reply to comment #55) > The initscript did not work with 1.4 but with 1.5 it is > working. I am using baselayout-2 and openRC. What I had to do was to make wicd start via /etc/init.d/local. For some mystical reasons this was the only way to make it start at boot on my Eee PC. Baselayout-2, OpenRC-0.4.2, and Wicd-1.5.8. With this it of course does not provide net, but I don´t care. All I need is to be able to use it via the tray icon. Here is my /etc/conf.d/local: local_start() { /usr/sbin/wicd &>/dev/null return 0 } local_stop() { pkill wicd return 0 } I wonder if something can be wrong with this way to start wicd..
(In reply to comment #56) > (In reply to comment #55) > > > The initscript did not work with 1.4 but with 1.5 it is > > working. I am using baselayout-2 and openRC. > > What I had to do was to make wicd start via /etc/init.d/local. For some > mystical reasons this was the only way to make it start at boot on my Eee PC. > Baselayout-2, OpenRC-0.4.2, and Wicd-1.5.8. With this it of course does not > provide net, but I don´t care. All I need is to be able to use it via the tray > icon. > > Here is my /etc/conf.d/local: > > local_start() { > /usr/sbin/wicd &>/dev/null > return 0 > } > > local_stop() { > pkill wicd > return 0 > } > > I wonder if something can be wrong with this way to start wicd.. > Don't add comments to 6 month old bugs. Open new ones. Your problem doesn't make any sense because that is what the current init script does now. Perhaps you didn't read the info at the end of the merge that provides direction. (I won't be responding to this bug anymore - I don't think all the people in the CC want to be spammed over a old bug that isn't relevant anymore)
