Re: Port request
On 28 May 2010 22:19, Lars Engels lars.eng...@0x20.net wrote: On Fri, May 28, 2010 at 12:11:10PM +0200, David DEMELIER wrote: I agree, personally I would prefer a wpa_supplicant / dhclient graphical user interface instead of the sucky NetworkManager. For the moment there is sysutils/wifimgr iirc but it's a quite unstable. wpa_supplicant does everything, scanning for access points automatically even you don't have X running, all WPA means of associations, it's just perfect. Take a look at this: make -C /usr/ports quicksearch name=pcbsd- Port: pcbsd-netmanager-8.0_1 Path: /usr/ports/net/pcbsd-netmanager Info: PC-BSD Networking Utilities for KDE4 Or (still QT4-based, but doesn't depend on KDE libs) net/wpa_gui - not that I've actually tried it. I briefly had a look at what would be required to implement a basic PyGTK-based wpa_supplicant GUI. One annoying thing is that (arguably) the easiest way for an external app to communicate with wpa_supplicant is via dbus, but wpa_supplicant in FreeBSD is built without dbus support; another option would be to use something like http://projects.otaku42.de/browser/python-wpactrl. -James Butler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports and PBIs
On Sunday, April 11, 2010, Tim Kientzle kient...@freebsd.org wrote: Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim Genuine (possibly stupid) question -in PBI land, what happens if package B is, say, CUPS? Does one need versioned rc.d scripts to start one or the other? Which one gets to claim port 631? -James Butler [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports and PBIs
On 13/04/10 19:09, Lucas Holt wrote: On 4/10/2010 3:18 PM, k...@pcbsd.org wrote snip However for my more hard-core friends, nothing stopping you from running your own ports down the road, more power to ya! For doing something like embedded work or a server this makes total sense and I think it is a huge positive for FreeBSD, no reason to trash that or break it in any way. For the other 99.9% of society who want something that just works for day-to-day computing, something like PBI is very attractive. It would be great to have an OS that offers best of both worlds. -- Kris Moore There are only two possibilities with any package system. Either give the user self packaged binaries containing all shared libraries or make them update everything. Both have positives and negatives. We've been Only two possibilities? I remember reading about a third in a paper proposing an enhancement to pkgsrc, but now I can't find the paper :-( Basically this involves distributing and downloading separate packages as with pkg_add, but installing each one in an isolated directory so multiple conflicting versions can be present side-by-side. The package tools then arrange for each package to have symlinks to all the packages it depends on, in a private libdepends/ folder or something. So if I install package A1.1 which depends on B3.2, then I want to install C5.3 which depends on B4.0, I have a choice: to upgrade A to a version depending on B4.0 if one exists, or to install C5.3 with B4.0 alongside A1.1 and B3.2. I'll try to find the paper I'm recalling after work, until then I'll just have to wave my hands in the air. -James Butler working on a new package system in MidnightBSD for some time. When we weighed this issue, it was decided that letting users have old binaries sitting around was a bad idea. It encourages a user to sit on a package for a year and not install security updates. The larger package size also deters users from downloading updates in parts of the world which have slow Internet connections. Remember the GDI+ update to windows awhile back? There were many applications that had to be updated and Microsoft had to release a scanner to search the drive for uses. There side isn't always rosy. Obviously, there are also advantages to the larger PBI packages for users. PC-BSD is certainly easy to use. At the end of the day, I think creating packages more frequently during releases and pushing updates like many linux distros do makes more sense in terms of security. FreeBSD has ten times the number of ports to build than we do so obviously it's a problem to build packages that frequently. I don't want to butt in any more on this because it's not my place, but I just felt it was important to bring another perspective. Lucas ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports and PBIs
On Sunday, April 11, 2010, Tim Kientzle kient...@freebsd.org wrote: Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim Genuine (possibly stupid) question -in PBI land, what happens if package B is, say, CUPS? Does one need versioned rc.d scripts to start one or the other? Which one gets to claim port 631? -James Butler [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar ___ freebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Fwd: HEADS UP dockapp maintainers
2009/8/19 Guido Falsi m...@madpilot.net: On Tue, Aug 18, 2009 at 01:00:39PM -0700, Luke Dean wrote: I haven't moved on and was not aware that any window manager aside from Window Maker could make use of Window Maker Dockapps. Can you give some examples of window managers that I might be able to get dockapps to work with if I make this change? I'd like to try it out. fvwm2 in one I'm quite sure about. Openbox does natively, and Xfce can with a panel plugin. -James Butler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: python31-3.1_2
2009/7/24 Sahil Tandon sa...@tandon.net: On Thu, 23 Jul 2009, Adam Townsend wrote: I'm using the ports online (from the freebsd.org site) to get ports for my my computers running FreeBSD (running on dial-up). I found that the Python 3.1 source links are all broken. They all contain /ftp/python//Python-.tgz in the urls. I found that the correct path in the urls is /ftp/python/3.1/Python-3.1.tgz after looking at the other sources. I'm not really sure if this is the correct way to report this, but I figured I'd let you know. I cannot reproduce your problem here. % cd /usr/ports/lang/python31 make -V DISTFILES Python-3.1.tgz % cd /usr/ports/lang/python31 make fetch = Python-3.1.tgz doesn't seem to exist in /usr/ports/distfiles/python. = Attempting to fetch from http://www.python.org/ftp/python/3.1/. Python-3.1.tgz100% of 10 MB 952 kBps 00m00s I think OP means this: http://www.freebsd.org/cgi/pds.cgi?ports/lang/python31 -James ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
