Re: reccomendation for a building architecture schematic diagram editor ?
On Thu, May 03, 2018 at 02:54:46PM +0200, Julian H. Stacey wrote: > CC pruned, & 1 added as som thread commonality below *** > > Miroslav Lachman wrote: > > The cad/freecad port has PORTNAME= FreeCAD in the Makefile, so the > > package name is FreeCAD-0.17.13509.txz > > > > Miroslav Lachman > > Thanks. > As these fail: > pkg search cad | grep -i free > pkg search CAD | grep -i free > pkg install FreeCAD-0.17.13509.txz > pkg install FreeCAD-0.17.13509 > pkg install FreeCAD-0.17 > pkg install FreeCAD-0 > pkg install FreeCAD For me the obvious things work: # pkg search cad |grep -i free FreeCAD-0.17.13509 General purpose 3D CAD modeller # pkg search CAD | grep -i free FreeCAD-0.17.13509 General purpose 3D CAD modeller # This on 10.4-STABLE from 23 March. -- gregory byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)
On Tue, Dec 05, 2017 at 05:25:13PM -0500, Baho Utot wrote: > Thank you for taking a perfectly good system and breaking it as well as > making it unusable, unstable. You just don't know of all the countless > hours spent after running an update and taking a week to get it working > again. Though I am only a user, I will add that, while the old system may have been "perfectly good" for some use cases, the absence of 'flvors' (or something similar) made the ports system at least very difficult to use (if not, perhaps, completely "unusable") for others. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Chicken/egg problem with pkg
On Fri, Mar 10, 2017 at 02:57:32PM +0100, Jan Bramkamp wrote: > On 10/03/2017 14:47, Guido Falsi wrote: > > On 03/10/17 14:26, Hans de Hartog wrote: > >> I have an old web server (10.1-RELEASE-p9) which is running for years > >> without any upgrades. Now I want to install a simple port (trafshow, to > >> see what's going on). > >> > >> It first want to upgrade pkg from 1.5.1 to 1.10.0_2 but that doesn't > >> work: > >> > >> [1/1] Upgrading pkg from 1.5.1 to 1.10.0_2... > >> [1/1] Extracting pkg-1.10.0_2: 100% > >> /usr/local/lib/libpkg.so.4: Undefined symbol "openat" > >> > >> Anything I try to do with pkg now gives me this error-message. > >> > >> /var/log/messages says: pkg: pkg upgraded: 1.5.1 -> 1.10.0_2 > >> > >> How do I proceed from here (without upgrading everything, please)? > > > > Have you tried using the "pkg-static" command? It's the same as pkg, but > > statically linked, should sidestep your issue. > > The old pkg-static might work, but it would wreck his system because he > uses a repo with an ABI unsupported by his base + kernel system. He is > lucky he immediately triggered the incompatibility. Will pkg-static install an old version of pkg? One option might be to check if the old version of pkg is in /var/cache/pkg, then maybe pkg-static could be used to reinstall the old version. Alternatively, if ports are installed, one could rebuild the old version of pkg from the port. Or even download the appropriate old ports tree to be able to build the old pkg. That would also enable building an old(?) version of trafshow. But I agree with others that the right answer is to upgrade the system. Running old systems facing the Internet is a bad idea. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Mumble in pkg
On Mon, Jan 23, 2017 at 09:05:19PM +0100, Jimmy Renner wrote: > >>> On 2017/01/23 15:26, Jimmy Renner wrote: > >>>> I might be totally off (and in the wrong forum) but I'm having problems > >>>> running the mumble version fetched by pkg, if I try to build the same > >>>> version in ports everything works fine. The failing one complains about > >>>> "unable to allocate SSL_CTX". The big difference I see is that the pkg > >>>> version is using /usr/lib/lbssl.so.8 and /lib/libcrypto.so.8 and the > >>>> ports version is using /usr/local/lib/libcrypto.so.9 and > >>>> /usr/local/lib/libssl.so.9. The odd thing is that both binaries are > >>>> reporting to be version OpenSSL 1.0.2j though the one depending on the > >>>> libs in /usr/lib says OpenSSL 1.0.2j-freebsd. > Ok, openssl-1.0.2j_1,1 is installed, from pkg. Ok, so I think what's going on here is that: The pkg version of mumble uses the default system OpenSSL, but you've installed the OpenSSL port (via the package). This means that the port builds fine - using the non-system OpenSSL that you've installed. But the pkg conflicts, because it wants the system OpenSSL -- and /usr/local/lib/* is found first. There are probably other ways to fix this, but the easiest is to either a) remove the OpenSSL pkg, or b) build mumble as a port. [Corrections welcome if I have something wrong.] -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: misc/jive deleted
On Mon, Oct 24, 2016 at 09:54:56AM +0200, Torsten Zuehlsdorff wrote: > On 24.10.2016 09:16, Greg Byshenk wrote: > > On Mon, Oct 24, 2016 at 01:05:52AM +0200, Julian H. Stacey wrote: > > > >> "Common decency" is disputable even in within USA; Europe is less > >> infested with USA style prissy "political correctness", & other > >> places less than Europe. Censorship of Global FreeBSD to USA norms > >> is Offensive. > > > > Point of information: I can't speak knowledgeably about the > > rest of the world, but Europe tends to have -more- stringent > > restrictions on abusive speech than does the USA. > > Just at a side note - this statement is far to general. It depends very > heavenly on the country. There are around 50 different countries in > Europe which differs quite a lot - some have more restrictions and some > less than the USA. Its quite surprising. Yes, it is overly general, but it was in response to an equally overly-general statement. To my knowledge, it also is -generally- (though not univerally) true. (And, of course, the nature of such restrictions is highly variable from one state to another.) -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: misc/jive deleted
On Mon, Oct 24, 2016 at 01:05:52AM +0200, Julian H. Stacey wrote: > Mark Linimon wrote: > > It's not delusions of moral superiority. It's common decency. > "Common decency" is disputable even in within USA; Europe is less > infested with USA style prissy "political correctness", & other > places less than Europe. Censorship of Global FreeBSD to USA norms > is Offensive. Point of information: I can't speak knowledgeably about the rest of the world, but Europe tends to have -more- stringent restrictions on abusive speech than does the USA. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: old ports/packages
On Wed, May 04, 2016 at 01:44:29PM +0800, Julian Elischer wrote: > On 3/05/2016 2:31 PM, Mathieu Arnold wrote: > > +--On 3 mai 2016 12:02:13 +0800 Julian Elischer <jul...@freebsd.org> wrote: > > | On 2/05/2016 8:39 PM, Mathieu Arnold wrote: > > |> There is a tag, https://svnweb.freebsd.org/ports/tags/PKG_INSTALL_EOL/ > > |> that gives you the last version to support pkg_install. Anything after > > |> that will not work with it. At all. > > | I'm not looking to produce old packages of the ports tree.. I know the > > | ports crew would hate me for that. > > | > > | What I object to is not having the tools needed to generate MY OWN > > | PACKAGES in ports. > > You can generate your own packages from the ports tree, just not with > > pkg_install, it was deprecated three or four years ago, and remove 19 > > months ago. > Of course I can create NEW packages.. I want to generate OLD style > packages.. > > what's so hard to understand about that? if a company has old > packages build into it's infrastructure > > and has to create old style packages of "proprietary stuff" to send > out to appliances out in the field then you are breaking them. I'm not a developer, so anyone feel free to correct me if I'm wrong in any of this, but... Julian, you -can- create old-style packages (eg: of proprietary internal software); you just have to do it based on an old-style ports tree (which you can checkout, if you need it, as noted above). What you cannot do is create old-style packages from a new ports tree. This is because the ports infrastructure has been changing since pkg_install was deprecated, and pkg_install simply will not work with the current ports tree (and, as I understand it, cannot practically be modified in order to work with it). But again, you -can- still build old-style packages if that is required: just check out a ports tree that works with old-style packages and use that to package your "proprietary stuff". -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: emulators/virtualbox-ose: compilation on CURRENT fails due to: tstVMStructRC: 1: Syntax error: ( unexpected
On Mon, Oct 27, 2014 at 09:25:00AM +0100, O. Hartmann wrote: Compiling emulators/virtualbox-ose on a freshly installed CURRENT (FreeBSD 11.0-CURRENT #0 r273719: Mon Oct 27 07:59:12 CET 2014 amd64) results in the below shown error. I also tried to install the package on CURRENT via pkg install, but this results in a 32-Bit VirtualBox only - which is inacceptable. I have running emulators/virtualbox-ose on several other CURRENT machines, but most of those boxes are grown, that means, they got CURRENT months ago and are maintained as usual (buildworld/portmaster). This box has been installed a couple of weeks ago and is successfully rejecting compilation of port emulators/virtualbox-ose, although I already updated the ports tree and did successfully a portmaster -R -fd /emulators/virtualbox-ose. Since I use some non-standard optimization flags in /etc/src.conf and /etc/make.conf (-O3 and CPUTYPE=native instead of plain -O and outdated architectural compatibilities), I switched back to the FreeBSD vanilla standard - but still the same. I can not imagine that the CPU of that specific box could be the culprit: dmesg output: CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3192.82-MHz K8-class CPU) Origin=GenuineIntel Id=0x306a9 Family=0x6 Model=0x3a Stepping=9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x7fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF Structured Extended Features=0x281FSGSBASE,SMEP,ERMS XSAVE Features=0x1XSAVEOPT VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 9107931136 (8686 MB) avail memory = 8147902464 (7770 MB) The error is: [...] kBuild: Generating tstVMStructSize - /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/bin/tstVMStructRC: 1: Syntax error: ( unexpected kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h] Error 2 kmk: *** Deleting file `/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VMM/tstVMStructRC.h' kmk: *** Waiting for unfinished jobs filesplitter: Out of 144 files: 144 rewritten, 0 unchanged. (/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include) kmk_builtin_append /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.18/out/freebsd.amd64/release/obj/VirtualBox/include/COMWrappers kmk: *** Exiting with status 2 *** Error code 2 I am unsure if it is related or not, but I have what seems to be a similar problem compiling virtualbox-ose-additions on 10-STABLE or 10.1RC3. I don't have a useful error, as in my case the result is that during the compilation, the VM itself crashes. This is the case with both 10-STABLE as of Friday, 24 October, and also a fresh install of 10.1RC3. -- greg byshenk - gbysh...@byshenk.net - Portland, OR USA ___ 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: print/cups-base web interface broken unable to print
] [Client 13] con-uri=/cups.css, con-best=0x803c1a4c0(/) d [16/Aug/2014:14:10:46 -0700] [Client 13] Authorization= D [16/Aug/2014:14:10:46 -0700] [Client 13] No authentication data provided. d [16/Aug/2014:14:10:46 -0700] cupsdIsAuthorized: con-uri=/cups.css, con-best=0x803c1a4c0(/) d [16/Aug/2014:14:10:46 -0700] cupsdIsAuthorized: level=CUPSD_AUTH_ANON, type=None, satisfy=CUPSD_AUTH_SATISFY_ALL, num_names=0 d [16/Aug/2014:14:10:46 -0700] cupsdIsAuthorized: auth=CUPSD_AUTH_ALLOW... d [16/Aug/2014:14:10:46 -0700] [Client 13] get_file filestats=0x7fff08d0, filename=0x7fff1950, len=1024, returning (null). d [16/Aug/2014:14:10:46 -0700] [Client 13] cupsdSendError code=404, auth_type=0 D [16/Aug/2014:14:10:46 -0700] [Client 13] Closing because Keep-Alive disabled D [16/Aug/2014:14:10:46 -0700] [Client 13] Closing connection. D [16/Aug/2014:14:10:46 -0700] cupsdSetBusyState: newbusy=Not busy, busy=Active clients d [16/Aug/2014:14:10:46 -0700] cupsdRemoveSelect(fd=13) d [16/Aug/2014:14:10:46 -0700] select_timeout: JobHistoryUpdate=0 d [16/Aug/2014:14:10:47 -0700] select_timeout: JobHistoryUpdate=0 d [16/Aug/2014:14:10:47 -0700] select_timeout(0): 86400 seconds to do nothing -- greg byshenk - gbysh...@byshenk.net - Portland, OR USA ___ 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: libfreetype.so.9 errors
On Sun, Apr 20, 2014 at 10:18:21AM -0700, Beeblebrox wrote: Latest compiled ports result in below message for several binaries: Shared object libfreetype.so.9 not found, required by chrome So far the ports I have seen this are www/midori, www/chromium, editors/libreoffice; but I have not tested all ports installed on the system. I have read UPDATING, and it does not apply to my situation since I do a full poudriere run of all ports on the system before each # pkg upgrade -r myrepo. Recent freetype update (20140416) should therefore not cause any issue for me. Is this a problem with the specific ports listed, or a libfreetype error? I'd like to know before I add a libfreetype.so.9 entry to /etc/libmap.conf. In /usr/local/lib: libfreetype.a / libfreetype.so / libfreetype.so.6.11.2 / libfreetype.la / libfreetype.so.6 I may be wrong in this, but I suspect that the UPDATING entry from 20140416 -does- apply. It seems print/freetype2 has changed the version of libfreetype it installs from lib/libfreetype.so.9 to lib/libfreetype.so.6.11.2. This will mean (I think) that any port depending on libfreetype will need to be rebuilt, linking against the new (but lower-numbered) library. If not, then they will be looking for the old library, and failing when they don't find it. -- greg byshenk - gbysh...@byshenk.net - Portland, OR USA ___ 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: Strange problem with portmaster
On Wed, Aug 07, 2013 at 11:06:52AM -0500, Paul Schmehl wrote: I recently upgraded all the ports on a server, so I decided to run portmaster -r perl to make sure all the perl ports were up to date. I used portmaster -rfd perl and got the following error: /var/db/pkg/fd does not exist I googled a bit and found nothing. Then I thought, that's strange, fd was the second and third commands. So I ran: portmaster -r -f -d perl and I got /var/db/pkg/f does not exist Then I tried portmaster -rf -d perl and got /var/db/pkg/d does not exist I finally just ran portmaster -r perl, which worked of course. Apparently the -r switch doesn't want to see anything after except the port that's being recursively built? I didn't try portmaster -fd -r perl. Maybe I should have? Yes, you should have, at least if you wanted the '-fd' flags. It may not be highlighted in the man page, but it does say -r name/glob of port directory in /var/db/pkg, and I've found that the '-r' flag does require that the port follow immediately. -- greg byshenk - gbysh...@byshenk.net - Portland, OR USA ___ 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: Opera vulnerability, marked forbidden instead of update?
On Fri, 23 Nov 2012 09:00:59 + Matthew Seaman matt...@freebsd.org wrote: On 23/11/2012 08:26, Matthieu Volat wrote: I've noticed that www/opera was marked FORBIDDEN because of a security hole: http://www.freebsd.org/cgi/getmsg.cgi?fetch=614275+0+current/svn-ports-head The opera software compagny advisory indeed mark this bug as high severity, and mention that there is an update to fix it. I am not familiar with the security process in ports, but would not it be better to update the version? Marking it FORBIDDEN do not do much for the userbase that does already have it installed. I've bumped the versions in the Makefile OPERA_VER?= 12.11 OPERA_BUILD?= 1661 and made a `make makesum reinstall`, there was no apparent problem. Marking a port 'FORBIDDEN' is a quick response measure that can be done without having to worry about time consuming testing the of port and so forth. It's an interim measure taken to ensure that users do not unwittingly install software with known vulnerabilities. Yes, updating the port to a non-vulnerable version is the ideal response, but that may not be possible to do straight away. You've sketched out the first couple of steps a port maintainer would take, but that 'there was no apparent problem' statement would need to be backed up by some more rigorous testing before a maintainer would feel confident in committing the update. Just a comment that, for any USERS who would like to take a chance with updating their Opera (rather than taking a chance running the vulnerable version), just modifying the Makefile as described above works to provide the update. I've updated www/opera and www/opera-linuxplugins, and my new Opera is running fine: About Opera Version information Version 12.11 Build 1661 PlatformFreeBSD System amd64, 8.3-STABLE -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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: libxul
On Wed, Aug 15, 2012 at 05:37:28AM -0500, ajtiM wrote: I wish to uninstall libxul but pkg_info -R libxul-1.9.2.28_1 Information for libxul-1.9.2.28_1: Required by: vlc-1.1.13_12,3 phonon-vlc-0.5.0_1 Is it safe to uninstall anywhere, please? You might need to rebuild vlc. It looks like libxul is pulled in to vlc if you select the Mozilla Plugin option. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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: libxul
On Wed, Aug 15, 2012 at 10:09:16AM -0500, Franci Nabalanci wrote: Yes, I selected the Mozilla Plugin which I want to have. Then it looks like you need to keep libxul, since that plugin introduces the libxul dependency. On Wed, Aug 15, 2012 at 7:13 AM, Greg Byshenk free...@byshenk.net wrote: On Wed, Aug 15, 2012 at 05:37:28AM -0500, ajtiM wrote: I wish to uninstall libxul but pkg_info -R libxul-1.9.2.28_1 Information for libxul-1.9.2.28_1: Required by: vlc-1.1.13_12,3 phonon-vlc-0.5.0_1 Is it safe to uninstall anywhere, please? You might need to rebuild vlc. It looks like libxul is pulled in to vlc if you select the Mozilla Plugin option. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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: pkg version -Xs foo shows all ports, not just foo
On Tue, Apr 10, 2012 at 08:55:41PM +0100, Anton Shterenlikht wrote: BUZI pkg version -Xs Image CalculiX-2.4 = GraphicsMagick-1.1.15_3,1 = ImageMagick-6.7.5.10 = ORBit2-2.14.19 = OpenEXR-1.6.1_3= R-2.14.2 = ^C BUZI The man page seems to indicate that the above options should only show ImageMagick. What am I doing wrong? I'm not sure if it's a bug or a feature, but pkg_version seems to want the arguments separately. $ pkg_version -X -s Image ImageMagick = $ Although in this particular case, 'pkg_version -s Image' (without the '-X') seems to do just fine, as well. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL - Portland, OR USA ___ 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: sysutils/cfs
On Fri, Sep 09, 2011 at 07:27:51AM +0200, Erik Trulsson wrote: On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote: Am 08.09.2011 13:52, schrieb Matt Burke: Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? That wouldn't happen anyways because the package is actively maintained, unlike many of the ports the discussion is about. You (and others) place *far* too much emphasis on a piece of software being maintained What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. The port isn't perfectly usable (because that would mean it's usable in all circumstances for all advertised purposes, which is explicitly not the case in the light of known vulnerabilities). In which case just about no port is 'perfectly usable' since almost all non-trivial software contains bugs - at least some of which are not documented, meaning that it isn't usable in *all* circumstances for *all* advertised purposes. I can't necessarily speak for everyone, but I suspect that this is why 'being maintained' is seen as important. All software has bugs; what is important is that they are fixed as they are discovered, rather than being left to rot. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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-system priorities rant (Re: sysutils/cfs)
On Wed, Sep 07, 2011 at 08:15:04PM -0400, Mikhail T. wrote: On -10.01.-28163 14:59, Doug Barton wrote: Non sequitur. The large number of ports that we support IS a feature. However, it's also a pretty big maintenance burden. Especially when you consider the number of those ports that are either actually or effectively unmaintained. Support? What support? Can I call someone and have a solution to a problem? Some PRs remain open for years and any attempts to escalate are met with patches welcome -- I've been on both sides myself :-) We do not offer support, make no promises of such and offer neither guarantees nor SLAs. What we do offer is: THERE IS A PORT OF IT. If there is a piece of software out there, chances are, it is ported to FreeBSD. Even if the existing port is imperfect, it is a starting point for somebody, who needs that software on their system. With every port removed, that promise wears thinner and thinner... I'm not a developer, but it strikes me that the above hits at the core of the disagreement. For many people, what THERE IS A PORT OF IT actually -means- is that the user can go to ports and install a -working- version of the software, not merley that there is something called 'IT' somewhere in the ports tree that may or may not work. And, if I'm not mistaken, this is also what 'support' means in the context of ports. No, of course there is no helpdesk you can call. But just as with the 'supported hardware' list, 'supported' means that the team will do its best to ensure that things actually work. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: problem with INDEX-5
On Thu, Jun 02, 2011 at 07:08:38AM +0200, DLF Sp. z o.o. - Sebastian Turzy?ski wrote: I have a problem that when I run make fetchindex there is an error: fetch: http://www.FreeBSD.org/ports/INDEX-5.bz2: Not Found I have 5.5-RELEASE-p13. If I'm not mistaken, FreeBSD-5 (with 5.5 as its last member) was End of Life and stopped being supported three years ago. Even FreeBSD-6 was EoL last year. I think everyone would very strongly recommend that you update to a more recent (and supported!) version, either 7 or 8. Should you really need something from 5.5, you can probably find it in the archives, in: ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ The index for 5.5-RELEASE appears to be at: ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/ports/i386/packages-5.5-release/INDEX But updating to something more recent -- and supported -- would be a very good idea. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: PR's not being picked up (Was Re: becoming a port committor)
On Mon, Nov 22, 2010 at 07:58:56PM +0100, Torfinn Ingolfsen wrote: On Mon, Nov 22, 2010 at 2:19 PM, RW rwmailli...@googlemail.com wrote: Actually it does discuss the wording of the synopsis for both new and updated ports which gives the impression that that that section covers both. Furthermore the update chapter is at the opposite end of the index under the single misleading word Upgrading. There's no mention of submitting which is what people will be looking for. IMO chapter 10 should either be 3.7 or be merged into 3.6. If anything deserves to be under Quick Porting it's this. So then we will see your PR for an update of that chapter in the Porter's Handbook in the next few days perhaps? The trouble is that even when people do read handbooks from beginning to end there are always sections that that they are likely to skip until they need them, and this is one of them. The Porter's Handbook is not going to be improved unless the people who read it and have ideas for improvement do something about it. HTH, HAND. -- Regards, Torfinn Ingolfsen I'm not a porter, but how about the below...? HTH -greg --- begin diff --- --- porting-submitting.html 2007-09-11 01:11:07.0 +0200 +++ porting-submitting.html 2010-11-22 20:14:54.0 +0100 @@ -69,6 +69,14 @@ /blockquote /div +div class=NOTE +blockquote class=NOTE +pbNote2:/b The instructions above are for creating a i class=EMPHASISnew/i +port. Port i class=EMPHASISupdates/i should be diff files instead of shar files, +as described in a href=port-upgrading.htmlUpgrading/a./p +/blockquote +/div + pOne more time, span class=emphasisi class=EMPHASISdo not include the original source distfile, the tt class=FILENAMEwork/tt directory, or the package you built with tt class=COMMANDmake package/tt/i/span./p --- end diff --- -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: opennms port
-repo (http://maven.opennms.org/content/groups/opennms.org-release), central (http://repo1.maven.org/maven2), maven-repo (http://repo1.maven.org/maven2), opennms-snapshots (http://maven.opennms.org/content/groups/opennms.org-snapshot) for project org.apache.maven.plugins:maven-eclipse-plugin at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:286) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1539) ... 15 more Caused by: org.apache.maven.project.ProjectBuildingException: POM 'org.apache.maven.plugins:maven-eclipse-plugin' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-eclipse-plugin:pom:2.5.1 from the specified remote repositories: opennms-repo (http://maven.opennms.org/content/groups/opennms.org-release), central (http://repo1.maven.org/maven2), maven-repo (http://repo1.maven.org/maven2), opennms-snapshots (http://maven.opennms.org/content/groups/opennms.org-snapshot) for project org.apache.maven.plugins:maven-eclipse-plugin at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:270) ... 18 more Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to download the artifact from any repository org.apache.maven.plugins:maven-eclipse-plugin:pom:2.5.1 from the specified remote repositories: opennms-repo (http://maven.opennms.org/content/groups/opennms.org-release), central (http://repo1.maven.org/maven2), maven-repo (http://repo1.maven.org/maven2), opennms-snapshots (http://maven.opennms.org/content/groups/opennms.org-snapshot) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:228) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558) ... 20 more Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to download the artifact from any repository at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:349) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) ... 22 more [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Tue Nov 02 15:28:36 CET 2010 [INFO] Final Memory: 25M/61M [INFO] *** Error code 1 Stop in /usr/ports/net-mgmt/opennms. === I seem to be able to reach http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plugin/2.5.1/maven-eclipse-plugin-2.5.1.pom ... but I get an .xml page instead of the .pom. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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/net/isc-dhcp*] Don't stop DHCP related daemons
On Wed, Sep 15, 2010 at 11:31:51AM -0700, Doug Barton wrote: On 9/15/2010 1:18 AM, Greg Byshenk wrote: On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: I can think of at least one more scenario off the top of my head. You want to run the new version of the service the next time the box is restarted for whatever reason, but the update is not so critical that it justifies restarting the system immediately. Do 'you' (generic) -really- want to do this? Once again, it's an area where the intelligence of the admin is expected to be applied. :) If you're thinking in terms of one machine, you're right, this probably isn't a good idea. However if you're thinking of a server farm with 1,000's of identical systems, a good QA process (so it's a known-good change), and monitoring in place to detect a failed reboot and take that box out of the pool; not only is what I described reasonable, it's commonplace. I don't want to belabor this too much, and -- of course -- the intelligence of the sysadmin is expected to be applied, but part of the point here is reasonable expectations of default behaviour. It may be that my view of this is incomplete, but it really does seem to me that the reasonable expectation is that an admin (of however many machines) is updating service X because s/he wants to be -running- the new version of service X. And that the most reasonable time to change the running service from version a to version a+1 is during the maintenance period in which the new service is installed. And this is not dependent upon the distinction between working with a single server or a pool of hundreds or thousands. After all, if the server is in its maintenance window, then stopping/restarting the service won't make any difference at that time, while it may at some other time. That said, I can imagine cases in which one might wish to roll out a new version but wait until some later time to activate it -- but it seems to me (at least) that these are the non-standard, 'special' caes, and also the cases in which the admins can be expected to know how to disable automatic updates/restarts. Note: because of that last paragraph, I do think that any automated restart of services should have the option to disable that restart. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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/net/isc-dhcp*] Don't stop DHCP related daemons
On Tue, Sep 14, 2010 at 06:22:24PM -0700, Doug Barton wrote: [...] I can think of at least one more scenario off the top of my head. You want to run the new version of the service the next time the box is restarted for whatever reason, but the update is not so critical that it justifies restarting the system immediately. Do 'you' (generic) -really- want to do this? 'This', in this case being making a change without testing what will happen when the machine or service is next restarted? One of the things I've learned is that things aren't always perfect, and, if I change service X in some way, then I want to test that .../rc.d/X actually does what I want/expect next time it runs. As I noted before, if by chance something is wrong, I want to know -now-, while the server/service is being maintained, not at some random later date. I am not coming down on either side of the 'automation' issue, as I think that I can see points on both sides; I'm just suggesting that this argument is not a good one. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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/net/isc-dhcp*] Don't stop DHCP related daemons
On Sun, Sep 12, 2010 at 09:46:02AM +0300, Ion-Mihai Tetcu wrote: On Sun, 12 Sep 2010 06:45:47 +0800 Denny Lin dennyli...@hs.ntnu.edu.tw wrote: On Sat, Sep 11, 2010 at 11:35:43PM +0200, Torfinn Ingolfsen wrote: On Sat, Sep 11, 2010 at 4:33 PM, Ion-Mihai Tetcu ite...@freebsd.org wrote: This 'stop the service before we install' seems to be a new fashion, usually unneeded/disruptive. IMO this should only happen when it's really needed, and with some big warning printed. And perhaps with a restart service attempt afterwards? (maybe interactive as in do you want me to restart the service y/n?) Just my 0.02 euros. How about knobs like WITH_STOP_SERVICE and WITH_START_SERVICE for users who wish to avoid the y/n questions? We have a standard policy of not auto-starting anything. We really don't want a service to be stated automatically after install (think: I installed this today, I'll configure it how I need it tomorrow, then start the service). And you can't really know if it's a new install or an upgrade. Is this really a problem? It seems to me that the presence of 'dhcpd_enable=YES' in /etc/rc.conf (or whatever similar entry is used for a given service) should answer the question of whether some service should be started after an upgrade. I always restart any services after an upgrade. The reason being, if by chance something does go wrong, I want to know about it at that time, while the server is maintenance (when I can be reasonably sure of the cause), not at some random time in the future (when someone will have to troubleshoot the problem -- on a server that is supposed to be live). -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: is upgrade of devel/lib{tool, tldl}15 to devel/lib{tool, tldl}22 worth it?
On Tue, Aug 04, 2009 at 06:56:06PM +0400, Dmitry Marakasov wrote:
* Scott Bennett (benn...@cs.niu.edu) wrote:
Has anyone done this new upgrade and survived yet?
I had no problems. There are not really many ports which depend on
libltdl anyway.
I've just done it ('portupgrade -o devel/libtool22 libtool-1.5\*')
without any problems -- but it was on a machine with only a small
number ( 100 ) ports installed.
--
greg byshenk - gbysh...@byshenk.net - Leiden, NL
___
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: [Call For Testing] VirtualBox for FreeBSD!
On Sat, May 16, 2009 at 07:16:13PM +0200, Benoit Calvez wrote: On Thu, May 14, 2009 at 11:49 PM, Benoit Calvez benoit.cal...@gmail.comwrote: On Thu, May 14, 2009 at 9:12 PM, Martin Wilke m...@freebsd.org wrote: After the announcement from Alexander Eichner about Virtualbox on FreeBSD, we started the work on a port for FreeBSD. Now we think that we solved the most problems and are ready for the first Call for Testing. Some notes before you can test the port: Make sure you are using RELENG_7 or higher. You have to use a fresh portstree with uptodate ports!! Please read carefully the pkg-messages. Some known issues / Troubleshooting: Sometimes the kernel on HEAD coredumps when loading or unloading the kernel module. A small workaround to prevent the crash is to not start X, mount proc, then load the kernel module and start X from the console. That helped me and some testers, maybe you too. :P AMD64 should be work in general, it builds and start. But not right tested at the moment. We want here also some feedback. Some Thanks: First of all we'd like to say many thanks to _ALL_ vbox developers. Next people are Bernhard Froehlich (aka decke), Beat Gaetzi (beat@), Dennis Herrmann (dhn@), Pietro Cerutti (gahr@), myself (*gg*), and _ALL_ who helped and provided feedback. Happy Testing :-) Download: http://people.freebsd.org/~miwi/vbox/vboxport.tgzhttp://people.freebsd.org/%7Emiwi/vbox/vboxport.tgz Wiki Page: http://wiki.freebsd.org/VirtualBox - Martin I'm trying to build from amd64, but got the following error. Sorry but I didn't look, and it's a fresh paste: [...] I just tryed with the last tarball ( http://people.freebsd.org/~miwi/vbox/virtualbox_1.tgz) and it compiles fine. the kernel module loads, and I'll try to boot an opensolaris in a few moments. I've just tried with virtualbox_1.tgz, and it builds without a problem, the module installs without a problem, but attempting to start VirtualBox fails. I get no error at all, VirtualBox just hangs. If I attempt to run 'truss VirtualBox', I get the error: Effective UID is not root (euid=1001 egid=1001 uid=1001 gid=1001) (rc=-10) It may help to reinstall VirtualBox. But checking shows that VirtualBox is SUID root: $ ls -l /usr/local/lib/virtualbox/VirtualBox -r-s--x--x 1 root vboxusers 21016 May 17 10:21 /usr/local/lib/virtualbox/VirtualBox It seems that I can create a vm: $ VBoxManage createvm --name test VirtualBox Command Line Management Interface Version 2.2.51_OSE (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Virtual machine 'test' is created. UUID: 9be28271-55c2-4299-b69a-266c58716db7 Settings file: '/home/gbyshenk/.VirtualBox/Machines/test/test.xml' $ VirtualBox $ ls -l /home/gbyshenk/.VirtualBox/Machines/test/test.xml -rw--- 1 gbyshenk gbyshenk 2302 May 17 10:37 /home/gbyshenk/.VirtualBox/Machines/test/test.xml But VirtualBox itself fails to start -- even if I run as root. System is amd64, 7-STABLE as of 26-04-2009. Does it need to be more recent...? -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: [Call For Testing] VirtualBox for FreeBSD! take2
On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: We rolled a new tarball with the patch from Juergen Lock [1] with a posible fix for AMD64 users, tested on 3 machines which now works without problems. Many Thanks to him for his nice work! http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz I've just updated my system (to 7-STABLE amd64 as of today) and installed the new version. It runs for me now. Tomorrow I will try to create virtual machine. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: [Call For Testing] VirtualBox for FreeBSD! take2
On Mon, May 18, 2009 at 02:25:28AM +0200, Greg Byshenk wrote: On Sun, May 17, 2009 at 08:09:20PM +0200, Martin Wilke wrote: We rolled a new tarball with the patch from Juergen Lock [1] with a posible fix for AMD64 users, tested on 3 machines which now works without problems. Many Thanks to him for his nice work! http://people.freebsd.org/~miwi/vbox/virtualbox_2.tgz I've just updated my system (to 7-STABLE amd64 as of today) and installed the new version. It runs for me now. Tomorrow I will try to create virtual machine. As a followup, the 'virtualbox_2.tgz' version appears to work for me, at least minimally. I've just installed NetBSD4.1 virtual machine, and it appears to be working (even though NetBSD isn't listed as a supported guest -- I just happened to have the NetBSD install iso sitting on my hard drive). -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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: how remove old lib in portupgrade -fr libxcb
On Sun, Feb 01, 2009 at 09:02:17PM +0100, Sebastien Chassot wrote: On Sat, 2009-01-31 at 16:55 -0600, Scot Hetzel wrote: Sounds like several of the libraries that your applications require are still linked to the old libxcb.so.1. Use this to find all libraries that are still depending on libxcb.so.1 (for i in /usr/local/lib/lib*.so ; do echo -n $i: ; ldd $i | grep libxcb.so.1 ; echo ; done) | grep libxcb libxcb.log Then rebuild all ports that contain these libraries. I did another try portupgrade -frP libxcb and I stop it after few hours. I maybe shouldn't but I did cos everything seems still linked to libxcb.so.1 (?) ... I'm really lost... ;( nothing work anymore and I don't know what to do. Just an idea: your command is 'portupgrade -frP', so what packages are you installing? Is it possible that some of your packages are built against the old libxcb? If that is the case, then reinstalling them will not change their link to the old version. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ 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
rsync with acls
I am experiencing a problem attempting to use rsync on systems with extended ACLs enabled. The ACLs flag works, but when it is used, the mtime of the files on on the receiving system are set to the current time. This is a bit annoying in itself, but creates a larger problem because any later rsync actions on the same files see the files as _different_, meaning that _all_ the files are recopied -- which more or less defeats the purpose of using rsync. Yes, I understand that setting ACLs on a file changes the mtime of the file. But, as rsync is able to (re)set mtimes I would think that this shouldn't should be an issue when using rsync. Is this a bug or a feature? -- greg byshenk - [EMAIL PROTECTED] - Leiden, NL ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
