Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-11 14:27:27 +0200, Helge Oldach wrote: >Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 (CEST): >> Following the SVN to GIT migration, portsnap is now the only practical >> way to use ports on a low-memory system. I've done some experiments >> and standard git has a 2GB working set to checkout a ports tree. > >However checking out is a one-time action with ports as there is only >one branch (switching frequently between main and quarterly is probably >not very sensible on a limited machine). git pull is significantly more >lightweight, I've just seen some 200M RSS. That should work well even on >a 512M machine. Probably much better than gitup in constrained memory? Except that git will arbitrarily and randomly decide that it needs to run "gc" - which is similarly extravagant in memory usage. Last time I found one running, it thrashed that poor VM for 3 days. Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes, though it looks like the working set size might only be ~350MB. -- Peter Jeremy signature.asc Description: PGP signature
gitup issues [was Re: No update for a day on ports?]
On 2021-Apr-01 22:36:02 +1100, Trev wrote: >> I just tried gitup and was told tha I had no permissions for >> /var/db/gitup. "sudo chown $USER /var/db/gitup" fixes that. >I just tried gitup and it was killed after apparently exhausting my >swap space. I had no such problem with portsnap :-( gitup walks the destination tree (ie /usr/ports), hashing every file it finds (by reading the complete file into memory). Whilst the default gitup configuration ignores /usr/ports/packages and /usr/ports/distfiles, it reads and hashes all the files down both paths before ignoring them. One consequence is that gitup is unusable on small memory environments - in my case, I saw peak memory usage hit 5GB (though the largest file I have is 1.8GB, so I'm not sure why it's eating so much memory). >My system (Vultr VPS) has 512K memory and 1.5G swap. git is barely usable on such a system (it's peak memory usage is about 2GB whilst processing a ports tree). gitup is unusable unless you either delete all packages and distfiles, or symlink them out of the way. > > Can I not run gitup as a normal user? > >I don't believe so. Well, git or gitup need write access to the working directory and the associated metadata directory. -- Peter Jeremy signature.asc Description: PGP signature
Re: Deprecation of portsnap (was: Proposed ports git transition schedule)
On 2021-Apr-01 12:19:08 +0200, Felix Palmen wrote: >* Christoph Moench-Tegeder [20210326 19:45]: >> ## Felix Palmen (fe...@palmen-it.de): >> >> > I'd assume (someone may correct me) that portsnap will still be >> > supported, >> >> https://lists.freebsd.org/pipermail/freebsd-ports/2020-August/119098.html > >Is this finally decided, and is there a timeline? Right now, it seems >portsnap is still built by default on releng/13.0. Following the SVN to GIT migration, portsnap is now the only practical way to use ports on a low-memory system. I've done some experiments and standard git has a 2GB working set to checkout a ports tree. gitup reached a 5GB working set size before I gave up. Typical small VPSs are around the 1GB RAM size and moving to something that can support 2GB or 5GB processes is a big price jump. -- Peter Jeremy signature.asc Description: PGP signature
Re: ports/devel/xtensa-esp32-elf version
On 2020-Jun-03 15:14:46 -0700, Craig Leres wrote: >I worked up a version of the port that uses the esp-2020r1 release of >https://github.com/espressif/crosstool-NG but I had not planned on >upgrading to this until the project I wrote the port for has upgraded to >esp-idf v4.X (this is in progress). ... >The two options I see are (a) I can provide you a copy of what I current >have working or (b) if there's enough interest I could create a new >devel/xtensa-esp32-elf-devel port using esp-2020r1 or esp-2020r2. It's not especially urgent for me. I was looking at updating esp-idf and discovered that doing so would also require updating the toolchain. If you would like to share what you currently have, I'll offer feedback of any issues I run into. One potential problem is that esp-idf requires a specific toolchain version - toolchain_versions.mk contains a single SUPPORTED_TOOLCHAIN_COMMIT_DESC so release/v4.0 and release/v4.1 require esp-2019r2, whilst release/v4.2 and master currently require esp-2020r1. I'm not sure that there's any solution other than you providing a toolchain to suit your personal needs. >(I received both copies, maybe the bounce was from the ports@freebsd >mailing list?) I'll respond privately. -- Peter Jeremy signature.asc Description: PGP signature
ports/devel/xtensa-esp32-elf version
Hi Craig, I notice that the Espressif ESP32 toolchain port is currently at version 1.22.0.g20171219 (which uses gcc 5.2.0), though the current stable version of esp-idf (v4.0.1) requires toolchain esp-2019r2 and gcc-8.2.0. Do you have any plans to update the port? -- Peter Jeremy signature.asc Description: PGP signature
Re: xterm-353
On 2020-Feb-02 12:38:45 -0500, ajtiM via freebsd-ports wrote: >On Sun, 2 Feb 2020 12:11:18 -0500 >ajtiM via freebsd-ports wrote: > >I did solve the problem with download file from the xterm web site. >compile and it works. The tgz file which automatically download from >mirror site is not good. This is what the ports checksums are intended to protect against. If you are inclined, you could compare the contents of both files and report the differences upstream - particularly if there has been a malicious change. -- Peter Jeremy signature.asc Description: PGP signature
Re: [HEADSUP] Re: Is IPV6 option still necessary?
On 2019-Oct-09 16:30:48 +0200, Baptiste Daroussin wrote: >so if we want to proceed further in removing the option to build with or >without >ipv6 for the ports side. Last time I checked, XDMCP differs enough between IPv4 and IPv6 that xdm used a compile-time option to pick which to support. -- Peter Jeremy signature.asc Description: PGP signature
devel/xtensa-esp32-elf build breaks if lang/guile2 installed
I've discovered that if lang/guile2 in installed, building
devel/xtensa-esp32-elf breaks as follows:
[INFO ] =
[INFO ] Installing final gcc compiler
[INFO ] Installing final gcc compiler: done in 345.00s (at 15:06)
[INFO ] =
[INFO ] Installing cross-gdb
[ERROR]
/tank/obj/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/.build/src/gdb-7.10/gdb/guile/scm-ports.c:231:47:
error: dereferencing pointer to incomplete type 'scm_t_port {aka struct
scm_t_port}'
[ERROR]
/tank/obj/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/.build/src/gdb-7.10/gdb/guile/scm-ports.c:681:19:
error: 'SCM_PORT_NEITHER' undeclared (first use in this function); did you
mean 'SCM_PORT_TYPE'?
[ERROR]
/tank/obj/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/.build/src/gdb-7.10/gdb/guile/scm-ports.c:711:19:
error: 'SCM_PORT_NEITHER' undeclared (first use in this function); did you
mean 'SCM_PORT_TYPE'?
[ERROR]
/tank/obj/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/.build/src/gdb-7.10/gdb/guile/scm-ports.c:790:24:
error: 'SCM_PORT_WRITE' undeclared (first use in this function); did you mean
'SCM_PORT_TYPE'?
[ERROR]
/tank/obj/usr/ports/devel/xtensa-esp32-elf/work/crosstool-NG-1.22.0-80-g6c4433a5/.build/src/gdb-7.10/gdb/guile/scm-ports.c:816:29:
error: 'SCM_PORT_READ' undeclared (first use in this function); did you mean
'SCM_PORT_WRITE'?
[ERROR]gmake[4]: *** [Makefile:2469: scm-ports.o] Error 1
[ERROR]gmake[3]: *** [Makefile:8755: all-gdb] Error 2
[ERROR]gmake[2]: *** [Makefile:845: all] Error 2
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step 'Installing cross-gdb'
[ERROR] >>called in step '(top-level)'
Uninstalling guile2 fixes the problem.
I presume this is another case of autotools-induced breakage but it's
not clear how to fix it since in's presumable the autotools embedded
in the cross-gdb build that's broken.
--
Peter Jeremy
signature.asc
Description: PGP signature
ports r500205 generates extraneous "make describe"
Doing a "make describe" (part of "make index") in /usr/ports/science/ALPSCore now generates extraneous output as below. Could you please look into this. server% make describe sh: /usr/local/mpi/openmpi2/bin/mpicc: not found make: "/usr/ports/Mk/Uses/compiler.mk" line 78: warning: "/usr/local/mpi/openmpi2/bin/mpicc --version" returned non-zero status make: "/usr/ports/Mk/Uses/compiler.mk" line 133: warning: "/usr/local/mpi/openmpi2/bin/mpicxx -### /dev/null 2>&1" returned non-zero status ALPSCore-2.2.0_7|/usr/ports/science/ALPSCore|/usr/local|Generic algorithms and utilities for condensed matter physics|/usr/ports/science/ALPSCore/pkg-descr|po...@freebsd.org|science/usr/ports/devel/boost-libs /usr/ports/devel/cmake /usr/ports/devel/ninja /usr/ports/math/eigen3 /usr/ports/net/openmpi2 /usr/ports/science/hdf5 /usr/ports/science/szip|/usr/ports/devel/boost-libs /usr/ports/net/openmpi2 /usr/ports/science/hdf5 /usr/ports/science/szip|https://github.com/ALPSCore/ALPSCore -- Peter Jeremy signature.asc Description: PGP signature
[devel/arduino18] Adding a new board description.
I'm trying to use devel/arduino18 with a non-standard board - which requires installing a new board description. According to the board documentation, the process is to enter the URL for the new board description in the Preferences, then go to Tools -> Board -> Boards Manager to actually install the definitions. My difficulty is that the above option doesn't exist because the patches included with ports r438914 delete all the relevant code. I haven't found any discussion as to why the boards manager was removed or what the alternatives are for installing new board descriptions. Can anyone advise the process for adding new board descriptions? -- Peter Jeremy signature.asc Description: PGP signature
Ports r494062 has a broken Makefile
The @sleep has leading spaces instead of a leading tab. -- Peter Jeremy signature.asc Description: PGP signature
Re: [flint2] feature request - linking with ntl
On 2019-Feb-12 20:47:15 +, Dima Pasechnik wrote: >Flint2 can be linked with ntl, providing more capabilities. Apart from being a prerequisite for sagemath, what additional capabilities does flint2 gain from being linked with ntl? >Is this a reasonable request to ask for flint2 to be linked with ntl >and available in such a configuration by default? IMO, ntl should be an optional dependency. Whether it should default to being "on" depends on the benefits gained from including it. -- Peter Jeremy signature.asc Description: PGP signature
Ports r459270 upsets "make index"
r459270 created hard references to clang38 and clang++38 in misc/sword/Makefile and, as a result, "make index" is reporting warnings: --- describe.misc --- sh: clang38: not found make[5]: "/usr/ports/Mk/Uses/compiler.mk" line 69: warning: "clang38 --version" +returned non-zero status make[5]: "/usr/ports/Mk/Uses/compiler.mk" line 112: warning: "clang++38 -### +/dev/null 2>&1" returned non-zero status Is there a cleaner way to define the required compiler? -- Peter Jeremy signature.asc Description: PGP signature
Re: FreeBSD Palemoon branding violation
On 2018-Feb-06 22:32:46 -0800, "Dan Mahoney (Gushi)" <free...@gushi.org> wrote: >My $dayjob is with a company that makes open-source software which we >redistribute under the MPL. I've shared that link with our team as an >example of the absolute wrong way to go about engaging with the community. Most definitely. I notice that Palemoon claims to be "free software" and links to https://www.gnu.org/philosophy/free-sw.html as a definition of "free software". One of the "four essential freedoms" listed on that page is "The freedom to distribute copies of your modified versions to others (freedom 3)" - and it is precisely the exercise of that "freedom" that Matt A. Tobin is objecting to. -- Peter Jeremy signature.asc Description: PGP signature
Re: security/libressl not API-compatible with OpenSSL, breaks www/apache24
On 2017-Jun-24 17:07:33 +0200, Walter Schwarzenfeld <w.schwarzenf...@utanet.at> wrote: >There is a working patch: >https://bz.apache.org/bugzilla/show_bug.cgi?id=61184 Thanks for that. It works nicely but is significantly more involved than I thought. -- Peter Jeremy signature.asc Description: PGP signature
security/libressl not API-compatible with OpenSSL, breaks www/apache24
In , libressl-2.5.4 specifies #define OPENSSL_VERSION_NUMBER 0x2000L but doesn't provide an API compatible with OpenSSL. In particular, it's missing (at least) SSL_CTX_set_max_proto_version() and SSL_CTX_set_min_proto_version(), which were added in OpenSSL 1.1.0. This breaks (at least) apache-2.4 which includes the code: #if OPENSSL_VERSION_NUMBER >= 0x1010L SSL_CTX_set_max_proto_version(ssl_ctx, max_prot); SSL_CTX_set_min_proto_version(ssl_ctx, min_prot); #endif Does anyone have a suggestion, other than switching from LibreSSL back to OpenSSL? -- Peter Jeremy signature.asc Description: PGP signature
Re: The future of portmaster
On 2017-Feb-17 19:03:31 +0100, Luca Pizzamiglio <luca.pizzamig...@gmail.com> wrote: >* dropping privileges is really a nice feature to add. The portstree >allow you to build everything as normal user, so portmaster can be >able to do it as well. I use portmaster as a normal user without problems so I'm not sure what the "new feature" bit would be, other than in conjunction with chroot/jail. >* show flags when build fails should be doable The non-trivial part of this is making it show the flags that are relevant to updating the ports specified in the remaining output. This will normally be different to the flags that portmaster was initially invoked with. >--packages-only|-PP : it looks redundant to me I used to use this, prior to pkgng, to let me build/upgrade packages on one system and then install/upgrade them on a second (much slower) system. I believe all this functionality is now subsumed into pkgng. >I'm also considering to remove, if nobody is using them: >* +IGNOREME support (a file saved in /var/db/pkg/ to force >ignore) This is a bit of a wart following the pkg_* to pkgng migration but I currently use this for two purposes: 1) On a slow system, it's a convenient way to postpone updating a large port without having to individually say yes/no to each port with -i. Having portmaster obey "locked" packages would remove this use but currently portmaster ignores "locked" flags and blows up. 2) I have some work-in-progress "ports" that are in my home directory, rather than under /usr/ports. Again, creating something like /usr/ports/local as a new SUBDIR would probably be a better approach. -- Peter Jeremy signature.asc Description: PGP signature
Re: lang/go 1.7.5 fails to install on Arm
On 2017-Feb-05 20:43:12 +0100, Julien Laffaye <jlaff...@freebsd.org> wrote: >go/pkg/%%opsys_ARCH%%/runtime/cgo.a > > >is in the plist, but for some reason it is not compiled on arm. >is it the only error ? If I comment that out of .PLIST.mktmp then Go installs without problem and there are no problems running a couple of relatively trivial Go programs. -- Peter Jeremy signature.asc Description: PGP signature
lang/go 1.7.5 fails to install on Arm
I'm trying to install lang/go on a RPi and it's failing because cgo.a is missing (see below). Looking through the sources it looks like it should exist but it's not built and there's no build error. Can anyone clarify whether the problem is the port or my build environment? (And, if the latter, does anyone have any suggestions what is wrong?) ===> Installing for go-1.7.5,1 ===> Checking if go already installed ===> Registering installation for go-1.7.5,1 pkg-static: Unable to access file /usr/obj/usr/ports/lang/go/work/stage/usr/local/go/pkg/freebsd_arm/runtime/cgo.a: No such file or directory *** Error code 74 Stop. make: stopped in /usr/ports/lang/go -- Peter Jeremy signature.asc Description: PGP signature
Re: GOOGLE_CODE has gone away?
On 2017-Jan-19 19:17:53 +0300, Pavel Timofeev <tim...@gmail.com> wrote: >I've found a port (http://www.freshports.org/net-mgmt/flow-tools-ng/) >which is marked as BROKEN. >The last commit says "GOOGLE_CODE has gone away.". That comment is true. >But at least this particular port is still available in a new place: >https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/flow-tools/flow-tools-0.68.5.1.tar.bz2 That is an archive of the last version of code available from Google Code. By definition it is unmaintained (and unmaintainable). There has been a long thread about this and the the outcome (which was not accepted by some) is that FreeBSD will not accept ports that are unmaintainable, therefore it will not use google-code-archive as a master site. Please refer to the FreeBSD-ports list archives for more details. -- Peter Jeremy signature.asc Description: PGP signature
Re: issues in several ports.
On 2016-Dec-21 04:01:50 +, Wyle Coyote via freebsd-ports <freebsd-ports@freebsd.org> wrote: >.I upgraded to 10.3 release installed via dvd "upgraded" how? Was this a fresh install or did you try to install 10.3 over the top of your 7.4 system? If the latter, it's quite likely that there are remnants of FreeBSD 7.4 (libraries, include files and/or ports) that are confusing the ports build system (GNU configure is really good at locating and incorrectly using leftover cruft). I strongly recommend you do a reinstall from scratch. If you can't, as a minimum, you should install a source tree and run "make delete-old delete-old-libs" as well as deleting all your installed ports (your entire /usr/local and /var/db/pkg). >in the uw-imap 2007f it will not compile under the port. In fact I am familiar >with imap and the client fairly well. I can get the program to build from >source, which I cannot in updated ports. I also added the -lcrypt >Tried just the c-client out of ports, same problem, no build. If the above doesn't fix your problem, can you please try a fresh build with "DISABLE_MAKE_JOBS=yes" and make the complete build log available somewhere. -- Peter Jeremy signature.asc Description: PGP signature
Re: The ports collection has some serious issues
On 2016-Dec-17 20:16:12 -0600, John Marino <freebsd.cont...@marino.st> wrote: >On 12/17/2016 19:35, Peter Jeremy wrote: >> $ cd /usr/ports/ports-mgmt/synth/ && make >> [ about an hour of grinding away elided ] >> ===> ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - >> not found >> ===> gcc6-aux-20160822 is only for amd64 i386, while you are running armv6. >> >> Overall, a total failure. >> >> OTOH, portmaster installs in a minute or so and runs perfectly well. I fail >> to see why you are so insistant on replacing it with something that doesn't >> work at all. >> > >Real smooth there, Slick. > >It's been mentioned several times in this thread alone that Ada is only >available for i386 and amd64. Not in this thread, no it hasn't. I went digging and found that it has been mentions in some of the other 7 separate "The ports collection has some serious issues" that you have started. > I think you already knew that Well, I pointed it out to you in February this year and after 10 months, nothing has changed, including your persistent desire to get rid of portmaster, despite the fact that synth is not a suitable replacement. >and thus >this is a pure troll. I insist that you retract that insult. In this thread, without any qualification, you stated that anyone who used portmaster or portupgrade should swap to synth, and gave a process which you know will only work on i386 and amd64. >Use poudriere for non-x86 platforms. armv6 packages are built with >poudriere + QEMU, but I suspect you already knew this as well. I haven't investigated because I haven't had the the need to. -- Peter Jeremy signature.asc Description: PGP signature
Re: The ports collection has some serious issues
Since you insist it's perfect, I thought I'd try synth... On 2016-Dec-16 09:06:30 -0600, John Marino <freebsd.cont...@marino.st> wrote: >Starting with a clean system: >1) install synth from binary package from official freebsd builder (a >single package) I don't understand why I need to install synth in order to build synth but anyway: $ sudo pkg install synth Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Updating database digests format: 100% pkg: No packages available to install matching 'synth' have been found in the repositories $ So I'll try to build it the old fashioned way, having downloaded nearly 100MB of sources I didn't already have: $ cd /usr/ports/ports-mgmt/synth/ && make [ about an hour of grinding away elided ] ===> ini_file_manager-03_2 depends on file: /usr/local/gcc6-aux/bin/ada - not found ===> gcc6-aux-20160822 is only for amd64 i386, while you are running armv6. Overall, a total failure. OTOH, portmaster installs in a minute or so and runs perfectly well. I fail to see why you are so insistant on replacing it with something that doesn't work at all. -- Peter Jeremy signature.asc Description: PGP signature
Re: The ports collection has some serious issues
On 2016-Dec-15 19:31:22 +0100, list-freebsd-po...@jyborn.se wrote: >On Thu, Dec 15, 2016 at 01:18:05PM -0500, George Mitchell wrote: >> On 12/15/16 09:40, Warren Block wrote: >> > On Thu, 8 Dec 2016, Matt Smith wrote: >> > >> >> On Dec 08 05:16, Daniil Berendeev wrote: >> >>> >> >>> Although portmaster is not releated to the FreeBSD project and is an >> >>> outside tool, there aren't any alternatives from the project itself. So >> >>> use it or die. Not a nice situation. >> >> >> >> People have been trying to get portmaster deprecated and removed from >> >> the handbook but have met with resistance. >> > >> > Well, yes. Because it works, has no dependencies, and there is no >> > equivalent replacement. [...] >> >> Warren, you have hit the nail on the head. -- George > >+1 > >I never have problems with portmaster. I don't know about never - I think I managed to get it into a dependency loop once - but I've never had any issues that I could not resolve or that would entice me to look at an alternative. >(But portupgrade could at times be an utter mess, >I never looked back after switching to portmaster >many years ago.) Likewise, portupgrade would explode and shower my system with bits of corrupt database to often for comfort. At least part of that was caused by portupgrade depending on quite a few other ports and getting confused when it updated things whilst it was using them. >And I'm not at all interested in running poudriere >or synth, thank you. Interestingly, the most vocal proponent of deleting portmaster and portupgrade is the author/maintainer of synch. -- Peter Jeremy signature.asc Description: PGP signature
Re: No port should need root for make fetch
On 2016-Dec-15 09:43:51 +0100, Mathieu Arnold <m...@freebsd.org> wrote: >Le 14/12/2016 à 06:17, Peter Jeremy a écrit : >> On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey" <j...@berklix.com> wrote: >>> IMO No port should need root for >>> cd /usr/ports; make -i fetch >> In a stock FreeBSD install, all ports require root to both fetch and build. >> You have customised your system in a non-standard way so you are getting >> non-standard behaviour which doesn't match you expectations. > >That is plain not true. By default, /usr/ports/distfiles is mode 0775 root:wheel and the only member of wheel is root. Fetching a port requires writing to /usr/ports/distfiles, hence root is the only user that can fetch distfiles. Likewise, by default, ports are built it /usr/ports/CATEGORY/NAME/work. /usr/ports/CATEGORY/NAME is only writable by root so only root can create the work directory in which to build ports. If you change the above defaults (which I suspect most people do) then you are correct that only a handful of ports need root to fetch or build (and I think that is still too many) - but I explicitly specified "stock install". -- Peter Jeremy signature.asc Description: PGP signature
Re: No port should need root for make fetch
On 2016-Dec-13 21:32:36 +0100, "Julian H. Stacey" <j...@berklix.com> wrote: >IMO No port should need root for > cd /usr/ports; make -i fetch In a stock FreeBSD install, all ports require root to both fetch and build. You have customised your system in a non-standard way so you are getting non-standard behaviour which doesn't match you expectations. IMO (which is equally valid to yours), no-one should need to run "cd /usr/ports; make -i fetch" so there's no problem to solve. -- Peter Jeremy signature.asc Description: PGP signature
Re: What sort of a hog is Ruby?
On 2016-Oct-07 17:35:10 +1100, Dave Horsfall <d...@horsfall.org> wrote: >Looks like I need to upgrade it for security issues; so I tried to compile >it from the ports area. > >First it blew out my disk space (the "work" sub-directory), so when I >rearranged a few things to make more room it blew out my swap space! My ruby22 work tree is 415MB. That's not small but it pales next to openjdk, firefox or mongodb. -- Peter Jeremy signature.asc Description: PGP signature
Re: Google Code as an upstream is gone
On 2016-Sep-29 16:33:12 -0700, Kevin Oberman <rkober...@gmail.com> wrote: >On Thu, Sep 29, 2016 at 9:57 AM, Christian Weisgerber <na...@mips.inka.de> >wrote: > >> Mathieu Arnold: >> >> > If the software has not been moved to some other place, (it takes about >> > 30 seconds to click the automatic migration to github thing, and it is >> > usually done within the hour,) since march 2015, it is most likely >> > abandoned and should not be kept in the ports tree. That seems a very reasonable policy. Unmaintained software is a danger to the Internet community as a whole and if, after 18 months, a "maintainer" hasn't bothered to take action to move the software to somewhere where it can be supported then it rates as "unmaintained". >> In the past, if the upstream was gone and the maintainer judged the >> software still useful (at their discretion, not based on a cut-off >> date), they would even fall back to providing the distfile at >> people.freebsd.org. The maintainer is still free to do so. "Maintainership" includes responding to changes within a reasonable period (hence "maintainer timeout"). >This was simply a terrible idea and I would hope that the ports team would >clearly so state and back out the "BROKEN" from those ports. As others are >pointing out, lot of very old and stable code has gone over a year without >updating. I think globally marking all ports that fetch from code.google.com as BROKEN is an excellent idea. There's a massive difference between "old and stable" and "unmaintained". The latter means that no-one cares if the code has security vulnerabilities. Just because code is "old and stable" doesn't mean the code is completely bug-free and a reasonable maintainer would take steps to ensure that the code could be updated if needed. >One case of import to me was mp4v2, a library for making MP4v2 formatted ... >source library for version 2 of the MP4 spec. Yet, because it had Google >Code as it's repo and had not been updated in just over a year, BROKEN. The last commit to mp4v2 in code.google.com was 2015-Jan-06 - nearly 21 months ago. >(That has now been fixed sue to several people yelling loudly about its >import. That is an issue you should take up with the port's maintainer. >I am sure that ports contains many old, buggy, insecure ports that should >go away, but a standard of "over year without a commit" should not be a >metric for determining what goes away. IMO, "over 18 months without a commit and not able to be updated if required" seems a quite reasonable metric for deeming code "abandonware". -- Peter Jeremy signature.asc Description: PGP signature
Re: Mosh regression between 10.x and 11-stable
On 2016-Aug-11 10:06:35 -0700, Ngie Cooper <yaneurab...@gmail.com> wrote: > >> On Aug 11, 2016, at 09:30, John Hood <cg...@glup.org> wrote: >> >> I still can't reproduce this on 3 different 11.0-BETA4 servers and a >> variety of clients and networks. Can you try and identify a more >> portable repro or at least figure out why it fails on your system? >> >> Please try applying this patch, too. It's a shot in the dark, though. > >Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)? I'm using ECDSA for both the host and user keys. -- Peter Jeremy signature.asc Description: PGP signature
Re: Mosh regression between 10.x and 11-stable
On 2016-Aug-11 12:30:23 -0400, John Hood <cg...@glup.org> wrote: >I still can't reproduce this on 3 different 11.0-BETA4 servers and a >variety of clients and networks. Can you try and identify a more >portable repro or at least figure out why it fails on your system? > >Please try applying this patch, too. It's a shot in the dark, though. That patch seems to fix the problem I'm seeing. Not waiting for output to drain is consistent with the symptoms I'm seeing, though I have no idea why only my Linux client is affected. -- Peter Jeremy signature.asc Description: PGP signature
Re: Mosh regression between 10.x and 11-stable
On 2016-Aug-10 14:32:15 -0400, john hood <cg...@glup.org> wrote: >On 8/10/16 4:18 AM, Peter Jeremy wrote: >> I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 >> r303811 and mosh to that host from my Linux laptop stopped working. All >> I get on the laptop is: >> $ mosh remotehost >> Connection to remotehost closed. >> /usr/bin/mosh: Did not find mosh server startup message. >> 1) the "MOSH CONNECT" message isn't making it out of the local ssh process. > >Do you know if the message is getting out of mosh-server? into sshd? >Do you know if mosh-server is actually running? (It will log utmp >entries on startup.) mosh-server is running - I can see it from another session and redirecting verbose output into a file, I get: mosh-server (mosh 1.2.5) [build mosh 1.2.5] Copyright 2012 Keith Winstein <mosh-de...@mit.edu> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [mosh-server detached, pid = 4202] Warning: termios IUTF8 flag not defined. Character-erase of multibyte character sequence probably does not work properly on this platform. I can't tell if it's actually writing into the remote ssh process. >> 2) it's racy because I can get it from "always fails" to "sometimes works". > >How do you get it there? - Add '-v' to the local ssh command. - ktrace the remote mosh-server process (this seems to make it consistently work). -- Peter Jeremy signature.asc Description: PGP signature
Mosh regression between 10.x and 11-stable
I recently updated one of my VPS hosts from 10.3-RELEASE-p5 to 11.0-BETA4 r303811 and mosh to that host from my Linux laptop stopped working. All I get on the laptop is: $ mosh remotehost Connection to remotehost closed. /usr/bin/mosh: Did not find mosh server startup message. I've tried rebuilding mosh (and all dependencies) on the host to no avail. This isn't the DSA change that's been discussed elsewhere: I can SSH from my laptop to the host without problem. I can also manually invoke mosh-client and mosh-server and it works. Unfortunately, mosh has no provision for debugging. I've tried hacking the mosh perl script to make it more verbose and that shows that: 1) the "MOSH CONNECT" message isn't making it out of the local ssh process. 2) it's racy because I can get it from "always fails" to "sometimes works". My suspicion is that something has changed in either sshd or TCP that is resulting in the connection going away before the stdout from the remote mosh-server makes it out from the local ssh process. I've looked at tcpdump's of both successful and failed SSH sessions but don't see anything obviously different (encryption makes it difficult to decode the session). Has anyone else seen this behaviour or have any ideas what might be causing it? -- Peter Jeremy signature.asc Description: PGP signature
databases/mariadb100-client fails to compile
I'm unable to get databases/mariadb100-client to compile on 10-stable/amd64. It fails as follows: Scanning dependencies of target mysqlclient gmake[4]: Leaving directory '/var/obj/usr/ports/databases/mariadb100-client/work/mariadb-10.0.25' gmake[4]: Entering directory '/var/obj/usr/ports/databases/mariadb100-client/work/mariadb-10.0.25' [ 92%] Building C object libmysql/CMakeFiles/mysqlclient.dir/mysqlclient_depends.c.o [ 92%] Linking CXX shared library libmysqlclient.so [ 93%] Linking C static library libmysqlclient.a /usr/bin/ld: /usr/lib/libssl.a(ssl_err.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/libssl.a: could not read symbols: Bad value c++: error: linker command failed with exit code 1 (use -v to see invocation) libmysql/CMakeFiles/libmysql.dir/build.make:110: recipe for target 'libmysql/libmysqlclient.so.18' failed gmake[4]: *** [libmysql/libmysqlclient.so.18] Error 1 gmake[4]: Leaving directory '/var/obj/usr/ports/databases/mariadb100-client/work/mariadb-10.0.25' Looking at the configuration output, it reports: -- OPENSSL_INCLUDE_DIR = /usr/include -- OPENSSL_LIBRARIES = /usr/lib/libssl.a -- CRYPTO_LIBRARY = /usr/lib/libcrypto.a -- OPENSSL_MAJOR_VERSION = -- SSL_LIBRARIES = /usr/lib/libssl.a;/usr/lib/libcrypto.a I'm not sure why it's picking the static versions of those libraries. -- Peter Jeremy signature.asc Description: PGP signature
Re: 'porting' AMD compiler suite
On 2016-Apr-10 17:09:04 -0453, "William A. Mahaffey III" <w...@hiwaay.net> wrote: >configure process completed OK, but created a Makefile w/ what seems to >be a bunch of linuxisms in conditionals to allow compilation for >different architectures, see attached orig-Makefile. Have you tried using gmake, rather than the base make? -- Peter Jeremy signature.asc Description: PGP signature
Re: Moving to synth (was: Removing documentation)
There are still issues moving to synth on non-Tier1 architectures: $ sudo pkg install synth-0.99_6 Updating FreeBSD repository catalogue... FreeBSD repository is up-to-date. All repositories are up-to-date. Updating database digests format: 100% pkg: No packages available to install matching 'synth-0.99_6' have been found in the repositories $ make ===> synth-0.99_6 depends on file: /usr/local/gcc6-aux/bin/ada - not found ===> gcc6-aux-20160124 is only for amd64 i386, while you are running armv6hf. *** Error code 1 Stop. make[1]: stopped in /usr/ports/lang/gcc6-aux *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/synth -- Peter Jeremy signature.asc Description: PGP signature
Re: maintaining portmaster ? was: Re: Removing documentation
On 2016-Feb-09 21:24:56 +0100, Kurt Jaeger <li...@opsec.eu> wrote: >Torsten wrote: > >> I did take a look. I could do both: maintaining the port and maintaining >> the software. What do you need? ;) > >Submit patches to the 12 PRs open for portmaster: > >https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=portmaster That is just being silly. I'd start by triaging those bugs. One is clearly a kernel bug, another maybe a bug in a different port and one is described as a feature request. The remaining 9 may or may not still be bugs in portmaster that are still relevant. Providing a patch for one of the bugs would probably be sufficient for demonstrating interest and ability. -- Peter Jeremy signature.asc Description: PGP signature
Re: Removing documentation
On 2016-Feb-08 01:53:06 +0100, John Marino <freebs...@marino.st> wrote: >hmm? The fact that it builds on a dirty host system is a liability; its >a major flaw. The typical Synth build environment is the host base >system minus the installed packages, so that's clearly superior. There's nothing in that statement that makes Synth "clearly superior" to portmaster. It suggests that Synth might be an alternative to poudriere. How does Synth handle ports that depend on themselves (Modula, Java and Go, off the top of my head)? Does this mean that if I already have a JDK installed, Synth is going to download one of the JDK packages anyway, just so it can build a new JDK in a "clean" environment? And there are also a number of cases where a port's dependency can be fulfilled by a number of unrelated ports - eg graphics/jpeg and graphics/jpeg-turbo can both fulfil a dependency on libjpeg.so. How does Synth decide which to use? -- Peter Jeremy signature.asc Description: PGP signature
Re: Removing documentation (was: [Bug 206922] Handbook: Chapter 4.5+ changes)
On 2016-Feb-07 15:28:56 +0100, John Marino <freebs...@marino.st> wrote: >Please do an honest "fly-off" between ports-mgmt/portmaster and >ports-mgmt/synth. I would love to hear what signficant thing portmaster >can do that Synth can't. (honestly) Off the top of my head: Has no other ports dependencies: portmaster - tick synth - bzzt fail. As far as I'm concerned that makes it an immediate non-starter. I have been bitten too many times by portupgrade updating one of its myriad dependencies, then exploding and requiring manual repairs. -- Peter Jeremy signature.asc Description: PGP signature
Re: jakarta-commos-httpclient
On 2015-Sep-25 05:29:43 -0400, Stari Karp <starik...@yandex.com> wrote: >[javac] /usr/ports/java/jakarta-commons-httpclient/work/commons-httpclient >-3.1/src/java/org/apache/commons/httpclient/HttpContentTooLargeException.java:6: > error: unmappable character for encoding UTF8 >[javac] * @author Ortwin Gl�ck >[javac] ^ >[javac] 1 error Quick and dirty solution is to build the port with LC_ALL=C -- Peter Jeremy signature.asc Description: PGP signature
Unable to upgrade go 1.4 to go 1.5
I have go-1.4.2,1 installed on a couple of machines and would like to upgrade to go1.5. Since go is now completely written in go, go1.5 requires go to bootstrap it. Unfortunately, the FreeBSD port requires that lang/go14 is installed in order to install lang/go - even if you already have go installed. And lang/go14 is currently forbidden due to security vulnerabilities. This is not a good situation. The various Java ports do a far better job by checking for the existence of potential bootstrap versions, rather than insisting on bootstrapping with a specific version. -- Peter Jeremy pgpOMDsDfiGlN.pgp Description: PGP signature
Re: Running ''portmaster ghostscript9-9.06_10'' takes a lot of time
On 2015-Aug-20 10:08:37 -0500, Matthew D. Fuller fulle...@over-yonder.net wrote: On Thu, Aug 20, 2015 at 08:32:07AM +0100 I heard the voice of Mathieu Arnold, and lo! it spake thus: I'm not exactly sure what you're all complaining about. The port just works fine, it does take a few seconds for make to iterate over all options, but it's because the port has way too many options. It's a pretty sizable difference... % svn co -r394572 [ Mk, print] % cd print/ghostscript9 % time make -V MAINTAINER doc...@freebsd.org 0.903u 0.023s 0:00.92 100.0%834+264k 82+0io 6pf+0w % ( cd ../../Mk svn up -r394573 ) Updating '.': Ubsd.options.mk Ubsd.port.mk Updated to revision 394573. % time make -V MAINTAINER doc...@freebsd.org 81.908u 0.070s 1:21.99 99.9%848+264k 82+0io 5pf+0w On my E3-1230v2 system (not a slouch), the difference is 1s to 110s - which is in line with Matthew's results. A two-orders-of-magnitude slowdown in make startup is unreasonable and I formally request r394573 be backed out. I can see the benefits of the functionality but the current cost is too high. -- Peter Jeremy pgpl7TlEjyf80.pgp Description: PGP signature
Re: damage to pkg's sqlite data base
On 2015-May-13 18:12:44 +1000, andrew clarke m...@ozzmosis.com wrote: You can reinstall just those ports. Check /var/log/messages, eg. $ grep pkg /var/log/messages May 12 14:34:38 blizzard pkg: poudriere upgraded: 3.1.4 - 3.1.6 May 12 14:38:08 blizzard pkg: git-lite-2.4.0 installed May 13 08:29:04 blizzard pkg: sqlite3 upgraded: 3.8.9_1 - 3.8.10.1 May 13 08:29:05 blizzard pkg: spamassassin reinstalled: 3.4.1_1 - 3.4.1_1 May 13 08:29:05 blizzard pkg: ca_root_nss upgraded: 3.18.1 - 3.19 That assumes you have syslog messages back to when you started using pkg. syslog was never intended to provide an audit trail. You can't rebuild it. You couldn't rebuild it in the years before pkgng existed, either. Depending on exactly what went wrong, plain text files are generally easier to manually fix up. The trick is to revert to a known-good backup of the pkg database that's generated daily by /usr/local/etc/periodic/daily/411.pkg-backup in /var/backups/ : -rw-r--r-- 1 root wheel 2207320 2015-05-13 04:20:30 pkg.sql.xz -rw-r--r-- 1 root wheel 2196088 2015-05-12 04:21:24 pkg.sql.xz.2 Assuming that they aren't corrupt. But that's better than nothing. Note that the backup is taken every day, whether or not there has been any change to the pkg database, so you have 2 days of backups, not the last two revisions. On 2015-May-13 18:17:12 +1000, andrew clarke m...@ozzmosis.com wrote: Actually I was wrong about this. The pkg command has the sqlite3 interpreter built-in, accessed via pkg shell, that opens local.sqlite by default: Some experimenting suggests that none of the pragma commands work in pkg shell, so you probably will need to find a copy of sqlite3. -- Peter Jeremy ___ 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
r382777 has deleted a required backslash
My latest nightly make index died at:
--- describe.print ---
make[5]: /usr/ports/print/fontforge/Makefile line 61: Unassociated shell
command ftp://ftp.freetype.org/freetype/freetype2/:freetype;
make[5]: Fatal errors encountered -- cannot continue=== print/fontforge failed
*** [describe.print] Error code 1
Looking at the Makefile, the problem is that the ftp.sunet.se URL has lost
the backslash at the end of the line so make(1) thinks the next line is
executable.
.if ${PORT_OPTIONS:MFREETYPE}
MASTER_SITES+=
http://sunsite.cnlab-switch.ch/ftp/mirror/freetype/freetype2/:freetype \
http://www.funet.fi/pub/mirrors/ftp.freetype.org/freetype2/:freetype \
http://ftp.sunet.se/pub/text-processing/freetype/freetype2/:freetype
ftp://ftp.freetype.org/freetype/freetype2/:freetype
--
Peter Jeremy
pgpARdflWtakR.pgp
Description: PGP signature
Re: Running Squeak On FreeBSD 10
On 2014-Nov-27 04:11:39 +, B J quarterwaveverti...@gmail.com wrote: I recently made a clean installation of FreeBSD 10 on an external hard drive, using Mate as the desktop and Slim as the login manager. What version of FreeBSD 10? Are you running amd64 or i386? /usr/local/lib/squeak/4.10.2-2614/squeakvm /usr/local/lib/squeak/Squeak4.3.image I get: Illegal instruction (core dumped) If I try: /usr/local/bin/squeak/ /usr/local/lib/squeak/Squeak4.3.image I presume you mean /usr/local/bin/squeak /usr/local/lib/squeak/Squeak4.3.image the result is: CHECKING cogvm CHECKING squeakvm Illegal instruction (core dumped) I can't reproduce this after building squeak-4.10.2_2 from ports on a 5-month old FreeBSD 10-stable/amd64. Does squeak work if you compile it yourself? If you debug the corefile, what is the offending instruction, register contents and a backtrace? -- Peter Jeremy pgp4jM_i_FY98.pgp Description: PGP signature
Re: HEADS UP: Berkeley DB 4...4.7 port removals/upgrades may require manual preparation
On 2014-Aug-21 20:56:47 +0200, Matthias Andree mand...@freebsd.org wrote: The time has now come to remove these db4* ports, Berkeley DB versions 4.0 to 4.7, inclusively. Most of their dependent ports can cope with upgrades to db48, db5, or db6, most of the others could be patched to work. ... I have created a Wiki page that contains instructions, and points to SleepyCat's or Oracle's upgrading documentation, at https://wiki.freebsd.org/Ports/BerkeleyDBCleanup. This assumes that I know where and how BDB is being used. I've discovered that I have db41 installed on a couple of systems - it's required by textproc/redland, which in turn is required by editors/libreoffice. Whilst I can avoid using libreoffice whilst I upgrade, I have no idea how it uses BDB or where the database files might be. I suspect this scenario is true for the majority of people who have BDB installed. When, among the upgrade steps on the WIki, you have reached the point where it is safe to upgrade the Berkeley DB and applications, there is a helper script in Tools/scripts/BDB-upgrade-helper.sh uses portmaster or portupgrade to rebuild the applications to use a newer Berkeley DB, and then offer to delete the old Berkeley DB ports. Partial relative paths aren't especially helpful. This should either be an absolute path or specify a cwd (presumably /usr/ports in this case). And, for reasons I don't understand, when I run BDB-upgrade-helper.sh, portmaster wants to install both db48 and db5. -- Peter Jeremy pgpvr08lPih3L.pgp Description: PGP signature
Re: graphics/libjpeg-turbo in place of graphics/jpeg
On 2014-Feb-11 03:27:46 -0800, Jakub Lach jakub_l...@mailplus.pl wrote: Currently, I reckon that libjpeg-turbo is a drop in replacement for graphics/jpeg. Unfortunately, most ports have a direct dependency on graphics/jpeg and will complain if it is missing[1]. Is there any way to achieve that and keep pkng happy? At least for source builds, you can just install libjpeg-turbo and then later builds will see that libjpeg.so is present and not attempt to build graphics/jpeg. I haven't tried doing this using binary packages. -- Peter Jeremy pgpmS6J2zfoZR.pgp Description: PGP signature
Re: Solved - was: Problems with linking on FreeBSD-10
On 2014-Feb-04 21:38:42 +, Montgomery-Smith, Stephen step...@missouri.edu wrote: /usr/home/stephen/sage/work/sage-6.0/local/lib contained libreadline.so.6. But for ld to work, it also had to contain a link libreadline.so-libreadline.so.6. (Is this sort of behavior documented anywhere?) I think it's sort-of communal mind knowlegde rather than being specifically written down: If the loader sees '-lfoo', it looks for libfoo.so or libfoo.a in locations specified by -L. If it finds libfoo.so then it will read at internal name out of it (eg libfoo.so.5) and store that in the executable. The rtld will then look for libfoo.so.5 using -rpath locations. ISTR having to manually craft some libfoo.so - libfoo.so.N during my sage porting efforts. The sage build process knows far too much about toolchain innards. -- Peter Jeremy pgpSY8kvxqcxr.pgp Description: PGP signature
Re: libstdc++.so.6 in base 9.2 system collides with libstdc++.so.6 in gcc47
On 2014-Jan-19 23:07:50 +0100, John Marino freebsd.cont...@marino.st wrote: On 1/19/2014 23:03, Yuri wrote: After the ports update my qbittorrent fails due to this collision: $ qbittorrent /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/libtorrent-rasterbar.so.7 not found Yes, the non-base gcc's aren't built correctly. There are some hacks in Mk/bsd.gcc.mk that partially work around the problems for some ports. The gcc47 should be built with specs that automatically insert a runpath (-Wl,-rpath,) of /usr/local/gcc47/ so that every binary and library built by it knows where to look. See ports/142226 and ports/182468. -- Peter Jeremy pgpurVxRZEeJn.pgp Description: PGP signature
Re: Advice about /usr/ports/math/gmp
On 2014-Jan-07 03:11:28 +0100, John Marino freebsd.cont...@marino.st wrote: Yes, the criticism of well, what exactly is wrong? is valid, but the guy did write a couple of PRs, Well, he claims to have written a couple of PRs but has so far refused to divulge any details. Tijl found one but we have no information on the other one. On 2014-Jan-07 04:25:27 +0100, Matthew Rezny mre...@hexaneinc.com wrote: in my mind. Specifically this: I was about to fix it, but found that the license of the code in question was unacceptable to me. I only contribute to Free Software, not to Open Source code bearing a license analogous to a law system that permits people to sell themselves as slaves. I liked that wording and made a note that next time I wanted to send a bug report regarding some GPL'd code, I should state: I was about to fix it, but could not understand the license of the code in question. I only contribute to Free Software, not to possibly Open Source code bearing a license that requires a law degree to understand. From his email, he is simply unhelpful. Essentially just you're different from GNU/Linux so you're broken but I won't bother to say how. Great, so helpful. I agree. And, since he's posting from using a GMP Project address, I presume this is official GMP policy. I guess the approved mechanism for reporting bugs in GMP is to include a vague GMP is broken statement, with an ambiguous explanation, in the release notes of software that uses or is used by GMP. If pressed, you should state that you can't be bothered to do anything further. On 2014-Jan-07 04:37:02 +0100, John Marino freebsd.cont...@marino.st wrote: Yes, if that's an accurate quote, it doesn't reflect well on Torbjorn. It was. Okay, so let's say he's correct and FreeBSD's base m4 can't build the latest gmp. Even if he won't tell us what the problem is, at least he told us there is a problem which could be easily reproduced. That's one problem. The other problems he mentions are: : * This release will not work on FreeBSD/amd64 before version 10 using :the 32-bit ABI. The reason is broken limits.h and broken dynamic :linking. There's no indication of what will not work means. It's not clear whether he's talking about compiling (which wasn't supported before 10.x) or running GMP. : * This release will not work on FreeBSD/amd64 10.0 using the 32-bit :ABI. The reason is bugs in the compiler 'clang'. Again, there's no indication of what will not work means. :FreeBSD/i386 10.0 does not work for us under KVM or Xen.) That's hardly a recipe for reproducing a problem. -- Peter Jeremy pgpgSmbSLo5QW.pgp Description: PGP signature
Re: Advice about /usr/ports/math/gmp
On 2014-Jan-03 17:53:02 +0100, Torbjorn Granlund t...@gmplib.org wrote: We have been forced to add three FreeBSD-related items to the releases notes: Your use of work in the following notes is ambiguous. Are you referring to building gmp, another program linking against gmp or executing a program that links against gmp? * This release will not work on FreeBSD/amd64 7.x, 8.x or 9 series before 9.3 with a Haswell CPU or any other CPU which supports the BMI2 instructions. The reason is that the FreeBSD m4 command is not correctly implemented. (Workaround: Use an older GMP release, or install GNU m4 from /usr/ports and tell GMP to use it.) Does gmp use m4 other than during the build process? Using GNU m4 to build gmp is a relatively painless workaround. * This release will not work on FreeBSD/amd64 before version 10 using the 32-bit ABI. The reason is broken limits.h and broken dynamic linking. (Workaround: Use an older GMP release if using the 32-bit ABI on these FreeBSD releases is important.) Again, what exactly do you mean? Building code using the 32-bit ABI on FreeBSD/amd64 was not supported prior to FreeBSD 10 so it was only a lucky fluke if it previously worked. If you mean that a 32-bit program using gmp (ie one compiled on FreeBSD/i386) will not run on FreeBSD/amd64, please provide more details (ie the PR number). * This release will not work on FreeBSD/amd64 10.0 using the 32-bit ABI. The reason is bugs in the compiler 'clang'. (Workaround: Compiling gcc from /usr/ports might work, except that gcc depends on GMP; we have not been able to test that workaround since FreeBSD/i386 10.0 does not work for us under KVM or Xen.) Please clarify what you mean by work here. Since FreeBSD 10.0 is the first release where building i386 executables is supported, it is quite likely there are bugs in this area. Can you please provide more details (ie the PR numbers) on the problems you encountered with 32-bit gmp 5.2 on FreeBSD/amd64 10.0 as well as the problems you encountered using FreeBSD/i386 10 on KVM and Xen. On 2014-Jan-03 21:33:12 +0100, Torbjorn Granlund t...@gmplib.org wrote: This is not the right place for FreeBSD bug reports, and I did not indend to do so. Agreed. It _is_ expected that you would include references to the bug reports though. I was only trying to ease the maintenence of /usr/ports/math/gmp. Except that by providing vague and incomplete references to problems, you aren't doing anything to ease the ports maintenance. From the information you provided, it's impossible to determine if the port should have GNU m4 as a build and/or run dependency. I have reported two of these problems. (I have not reported the remaining two problems, and I do not intend to do that. Sorry. Again, I feel that I would abuse thios mailing list by discussing that here.) So, what you're saying is that gmp 5.2 has problems on FreeBSD but you aren't going to provide any details that would assist us to resolve them. This just wastes everyone's time. -- Peter Jeremy pgpzuA8drExwy.pgp Description: PGP signature
Re: NEED_ROOT
On 2013-Oct-04 16:45:34 -0500, Paul Schmehl pschmehl_li...@tx.rr.com wrote:
From my reading it appears that one of the goals of STAGE is to allow users
to build and install ports under their UID. Are the perms in /usr/ports
changing?
I hope not. There's nothing wrong with the current permissions.
In testing the port that I'm working on, I find that I do not have rights
to write to /usr/ports/distfiles and I do not have rights to write to
${WORKDIR}. That pretty much precludes building the port unless your root.
No surprise there since the files in /usr/ports are owned by root:wheel.
I've built ports as non-root, with a read-mostly /usr/ports for many
years. All you need to do is override the defaults:
WRKDIRPREFIX=/tmp
PACKAGES=/where/you/want/packages
DISTDIR=/where/you/want/distfiles
Alternatively, I chmod 1777 /usr/ports/distfiles to allow a common
ports tree to be shared amongst multiple systems. And you can also
use symlinks.
--
Peter Jeremy
pgpBxCwC_XcAn.pgp
Description: PGP signature
Re: [Call For Help] Clang + OpenJDK + head + amd64 == cocktail of death (for clusters)
On 2013-Jul-25 10:39:17 +0200, Baptiste Daroussin b...@freebsd.org wrote: After some investigation we discover that blacklisting openjdk6 allows the building process to go to completion again. ... It seems to happen only on head amd64, so far we think it is only happening when jdk is built with clang. This mail arrives at an opportune time. I've just discovered that if I build openjdk6 with clang (on head/amd64), the resultant jdk SEGV's if I again try to build openjdk6. If I build it with USE_GCC=any then the problem goes away. I have no time, neither skill to investigate that, I don't have the time to investigate further but forcing the use of gcc instead of clang is at least a workaround. -- Peter Jeremy pgprMpeYl514w.pgp Description: PGP signature
Re: non-destructive ports/packages update
On 2013-Apr-20 18:03:17 -0700, Perry Hutchison per...@pluto.rain.com wrote: The question is, what (if anything) else -- besides /usr/ports, /usr/local, /var/db/ports, and /var/db/pkg -- needs to be checkpointed? If you're running any Linux compatibility packages: /compat/linux BOINC packages: /var/db/boinc Unless you've moved to pkgng, $ grep @cwd /var/db/pkg/*/+CONTENTS | grep -v /usr/local will give you an overview of what unusual locations have been installed to. -- Peter Jeremy pgpGEqZBUhbw0.pgp Description: PGP signature
Re: Request olvwm
On 2013-Apr-08 13:32:05 +0200, Daniel Nebdal dneb...@gmail.com wrote: Looking at it, the first problem is that x11-toolkits/xview has ONLY_FOR_ARCHS= i386 . Adding amd64 to it failed early with compilation errors (in some hairy macro definitions, by the look of it). Setting USE_GCC=4.2+ still produced a lot of warnings, but actually compiled and installed. Back in olwm, it then failed with much the same compiler errors; USE_GCC=4.2+ got past that again (I guess it's from the same header files as xview). It then compiled and installed. On trying to start it, it segfaulted. Recompiling with CFLAGS+=-g and starting it in gdb, I get this: Without looking at the code, my initial guess is that the code assumes it can store a pointer in an int. There is probably a good reason xview is marked as i386 - only. I guess I could recompile it with -g as well to see if I can find out what goes wrong, but ... I do have other things to do, and I know nothing about X or xview or olvwm. Maybe later? As a first step, I'd add '-Wall -Wmissing-declarations' and work through all the warnings, particularly any that suggest truncation. -- Peter Jeremy pgp9ldLonpOfr.pgp Description: PGP signature
Re: Warnings from make index
On 2013-Mar-10 21:20:00 +, Chris Rees cr...@freebsd.org wrote: www/vtiger includes bsd.port.pre.mk AND bsd.port.mk; I've fixed that. Thanks for that. -- Peter Jeremy pgpv_TiGhwBCg.pgp Description: PGP signature
Warnings from make index
For the past several days, I've been getting the following. I haven't yet tracked down the commit that caused it. Generating INDEX-8 - please wait../usr/ports/Mk/bsd.pbi.mk, line 20: warning: duplicate script for target check-pbimanager ignored /usr/ports/Mk/bsd.pbi.mk, line 45: warning: duplicate script for target pbi-generate ignored /usr/ports/Mk/bsd.pbi.mk, line 46: warning: duplicate script for target pbi-generate ignored /usr/ports/Mk/bsd.pbi.mk, line 47: warning: duplicate script for target pbi-generate ignored /usr/ports/Mk/bsd.pbi.mk, line 50: warning: duplicate script for target clean-pbi ignored /usr/ports/Mk/bsd.pbi.mk, line 51: warning: duplicate script for target clean-pbi ignored -- Peter Jeremy pgpg1Zj0hykh0.pgp Description: PGP signature
Re: Firefox 19.0,1 crashes at startup
On 2013-Feb-21 20:45:08 +0100, Florian Smeets f...@smeets.im wrote: On 21.02.13 20:34, Frank Seltzer wrote: I am getting this on 2 machines, both at 9.1-STABLE FreeBSD 9.1-STABLE #0 r247001. Both have GENERIC kernel, no edits. Both have the linux module loaded if that matters. Can you apply this patch http://svnweb.freebsd.org/base?view=revisionrevision=246858 to your stable/9 checkout, rebuild/install world and try to rebuild firefox? I was seeing the same problem on FreeBSD-8.3/i386. I had clang-3.2 installed as a LibreOffice dependency and (for some reason) Firefox was using clang instead of the base gcc. After applying the patch in base r246858 to both devel/llvm lang/clang [I'm not sure which it's relevant to] and rebuilding all 3, firefox also works for me. -- Peter Jeremy pgpXcQVL7zrxz.pgp Description: PGP signature
Re: libreoffice
On 2013-Feb-18 12:46:17 +0100, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: I found loading a document taking milliseconds only when other document is already loaded, while otherwise it is few seconds. Once you start LibreOffice it opens additional documents within the same process - which is much faster than starting LibreOffice. other question - where are printers defined in libreoffice? System wide printer: /usr/local/lib/libreoffice/share/psprint/psprint.conf /usr/local/lib/libreoffice/share/psprint/driver You can manage printers with /usr/local/lib/libreoffice/program/spadmin (including setting up per-user printers) -- Peter Jeremy pgph0I2tU6bLT.pgp Description: PGP signature
Re: portsnap and the imminent demise of svn-cvs ports tree export
On 2013-Jan-22 22:45:24 -0500, Thomas Mueller mueller6...@bellsouth.net wrote: Your date is ahead of what the headers of your message say: From owner-freebsd-po...@freebsd.org Mon Jan 21 09:53:34 2013 Received: from pop.att.yahoo.com (pop2.sbc.mail.vip.ne1.yahoo.com [98.138.197.207]) by mueller6722.bellsouth.net (mpop-1.0.23) with POP3 for arlene; Mon, 21 Jan 2013 09:53:34 + X-Apparently-To: mueller6...@bellsouth.net via 98.139.172.126; Sun, 20 Jan 2013 17:01:32 -0800 ... Date: Mon, 21 Jan 2013 12:01:05 +1100 How do you work that out? None of the headers you've included show any problem. John sent his mail at 010105UT on 21st, and your headers say you received it at 095334UT on 21st - nearly 9 hours later. The X-Apparently-To header is 010132UT on the 21st (about 3s after FreeBSD forwarded it to me, se quite realistic). -- Peter Jeremy pgpQhDRnUR4Hv.pgp Description: PGP signature
Re: Removal of Portmanager
On 2013-Jan-13 19:25:42 +, RW rwmailli...@googlemail.com wrote: Aside from pkgng what changes do do you think it needs? Without pkgng support, how will portmanager interrogate the system to determine what ports are installed and/or need updating? How long is it since anyone did any development on awk? Is that going to go because nobody cares. The base awk is actively maintained both upstream (by its author) and within FreeBSD - the 20121220 version of awk was imported on 2013-Jan-03. -- Peter Jeremy pgpYNebptCJ5i.pgp Description: PGP signature
Re: postfix-current broken on amd64 platform
Resurrecting an old thread because I've just run into this problem...
[postfix dies with a Protocol not supported when built in a jail
without an IPv6 address]
On 2011-Nov-17 15:41:12 -0500, Wietse Venema wie...@porcupine.org wrote:
A more proactive workaround would be to treat protocol not supported
as a non-fatal error, just like address family not supported is.
Please let me know if this works in the build cluster. It will log
a warning but that should be justfied, because the system does have
an abnormal configuration.
Wietse
*** src/util/inet_proto.c- Tue Jan 8 15:36:13 2008
--- src/util/inet_proto.c Thu Nov 17 08:49:31 2011
***
*** 219,225
pf-dns_atype_list = make_unsigned_vector(3, T_A, T_, 0);
pf-sa_family_list = make_uchar_vector(3, AF_INET, AF_INET6, 0);
break;
! } else if (errno == EAFNOSUPPORT) {
msg_warn(%s: IPv6 support is disabled: %m, context);
msg_warn(%s: configuring for IPv4 support only, context);
/* FALLTHROUGH */
--- 219,225
pf-dns_atype_list = make_unsigned_vector(3, T_A, T_, 0);
pf-sa_family_list = make_uchar_vector(3, AF_INET, AF_INET6, 0);
break;
! } else if (errno == EAFNOSUPPORT || errno == EPROTONOSUPPORT) {
msg_warn(%s: IPv6 support is disabled: %m, context);
msg_warn(%s: configuring for IPv4 support only, context);
/* FALLTHROUGH */
I've just bumped into this exact situation with mail/postfix28 and
suspect that earlier postfix ports have the same issue. The above fix
works on postfix28 and I would request that it be added to that port's
patch list. Since this is a workaround for a FreeBSD-specific issue,
I don't believe it's reasonable to expect Wietse to patch old postfix
variants to work around it.
--
Peter Jeremy
pgpDuvvvy2IWG.pgp
Description: PGP signature
Re: Firefox and Adobe® Flash™ Plugin
On 2012-Nov-16 11:25:01 +0100, Leslie Jensen les...@eskk.nu wrote: === linuxulator is not (kld)loaded Have you tried kldload linux? -- Peter Jeremy pgp4IiyGWxMZW.pgp Description: PGP signature
Re: Audacity Upgrade 1.x - 2.x Craps Out
On 2012-Oct-28 21:00:30 -0500, Joseph a Nagy Jr jnagyjr1...@gmail.com wrote: I am trying an upgrade to audacity (1.x to 2.x) but it has crapped out; nothing in updating about audacity issues. http://pastebin.com/WxPvgKXf I have no trouble building audio/audacity on 8.3/amd64 with: _OPTIONS_READ=audacity-2.0.2 _FILE_COMPLETE_OPTIONS_LIST=DOCS FFMPEG FLAC ID3TAG JACK LADSPA MAD NYQUIST PORTMIXER SAMPLERATE SBSMS SOUNDTOUCH TAGLIB TWOLAME VAMP VORBIS OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=FFMPEG OPTIONS_FILE_SET+=FLAC OPTIONS_FILE_UNSET+=ID3TAG OPTIONS_FILE_UNSET+=JACK OPTIONS_FILE_UNSET+=LADSPA OPTIONS_FILE_SET+=MAD OPTIONS_FILE_SET+=NYQUIST OPTIONS_FILE_UNSET+=PORTMIXER OPTIONS_FILE_UNSET+=SAMPLERATE OPTIONS_FILE_UNSET+=SBSMS OPTIONS_FILE_UNSET+=SOUNDTOUCH OPTIONS_FILE_UNSET+=TAGLIB OPTIONS_FILE_UNSET+=TWOLAME OPTIONS_FILE_UNSET+=VAMP OPTIONS_FILE_SET+=VORBIS I realise your options are different - could you please provide some more detail about your options and FreeBSD version. The other thing I notice about your log is that it doesn't seem to be building in the correct dependency order. Can you check that your portmaster is up to date and all your ports work directories are emtpy. -- Peter Jeremy pgp4RzwPIrCoh.pgp Description: PGP signature
Re: simh-3.9.0 is busy looping
On 2012-Oct-14 12:53:49 +0300, Jukka A. Ukkonen j...@iki.fi wrote: It seems that simh-3.9.0 is busy looping and as a result also hogs one CPU to the max and prevents the system lowering the CPU clock frequency when there is actually nothing to do. I haven't tried VAX but have used the PDP-11 simulator in simh for quite a while. On the PDP-11, simh originally used busy waits but more recent versions can use blocking waits (at least in some configurations). I doubt that the issue is related to the FreeBSD port and suggest you check the simh documentation and/or raise an issue with simh. -- Peter Jeremy pgpC4UAq6mmAQ.pgp Description: PGP signature
Re: The xpdf binary is MIA with xpdf-3.03_2
On 2012-Oct-13 15:18:48 -0500, Bob Willcox b...@immure.com wrote: When building the xpdf port the xpdf executable is no longer being built or installed into /usr/lib/libexec/xpdf. I suspect that this happened as the result of a change that was made on 10/12/2012 with version xpdf-3.03_2. Yes, that update is broken. Is anyone else seeing this (I have it failing on two of my recently ports tree updated systems here)? ports r305766 breaks the with-X11 case. If you want xpdf+X11, the easiest solution is to just revert that change (none of it is correct). -- Peter Jeremy pgpYViod7fYEW.pgp Description: PGP signature
Re: Building with WITH_DEBUG (-g) in make.conf
On 2012-Sep-04 23:50:35 +0200, Dimitry Andric d...@freebsd.org wrote: There's a difference between just using '-g', which should never change the behaviour of the program at runtime, and adding -DDEBUG or similar flags on the command line, which may or may not enable extra code, or even cause totally different code paths. In theory, gcc should generate identical code with and without '-g' but, last time I looked, adding '-g' causes non-trivial changes in the gcc code paths so it's quite possible that different code is emitted. What is not different, is that both -g and other debugging options will generally cause compiling and linking to take longer, since these stages will have to process the additional debug information. As well as being much larger - several times larger is not uncommon. This further slows things down due to the additional I/O and reduced cache effectiveness. -- Peter Jeremy pgphfUYAq2ZgX.pgp Description: PGP signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 2012-Aug-26 12:27:41 -0700, Doug Barton do...@freebsd.org wrote:
On 08/26/2012 12:08, Ian Lepore wrote:
Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of
replacing itself, so that you could re-bootstrap your way out of a
problem later.
That's certainly creative thinking, but I'm still queasy about 2
commands with the same name that do 2 different things. And having it
rename itself adds to the confusion down the road.
I also like the idea of a pkg-bootstrap command. Possibly a symlink
from pkg to pkg-bootstrap, that gets removed as part of the bootstrap
process, would help - but it should just tell you how to run
pkg-bootstrap. I don't like the idea of pkg{-bootstrap} autonomously
installing something I didn't ask for. And I don't like the idea that
all pkg commands get bounced through a /usr/sbin/pkg once it has been
bootstrapped.
Having a simple pkg bootstrapping tool in the base is a good idea. But
the functionality needs to be extremely limited so that we don't
increase the security exposure; and so that we don't end up in a
situation where a bug fix for something in the base limits our ability
to innovate with pkg in the ports tree.
Agreed. BTW, one thing that needs to be considered is how to recover
from the embedded public key needing to be invalidated (eg due to the
private key being exposed).
--
Peter Jeremy
pgpvdn7KHnqSv.pgp
Description: PGP signature
gcc-4.6 build failures
I'm seeing identical build failures for lang/gcc and lang/gcc46 on sparc64 FreeBSD 10.0-CURRENT (sb1500) #9 r238864M: Tue Jul 31 20:08:11 EST 2012 Can anyone suggest a fix? The lang/gcc failure is: checking for iconv... no, consider installing GNU libiconv configure: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depdir commands mkdir .deps gmake[3]: Entering directory `/var/obj/usr/ports/lang/gcc/work/build/libcpp' /var/obj/usr/ports/lang/gcc/work/build/./prev-gcc/xgcc -B/var/obj/usr/ports/lang/gcc/work/build/./prev-gcc/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/bin/ -B/usr/local/sparc64-portbld-freebsd10.0/lib/ -isystem /usr/local/sparc64-portbld-freebsd10.0/include -isystem /usr/local/sparc64-portbld-freebsd10.0/sys-include -I.././../gcc-4.6.3/libcpp -I. -I.././../gcc-4.6.3/libcpp/../include -I.././../gcc-4.6.3/libcpp/include -g -O2 -gtoggle -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I.././../gcc-4.6.3/libcpp -I. -I.././../gcc-4.6.3/libcpp/../include -I.././../gcc-4.6.3/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo .././../gcc-4.6.3/libcpp/charset.c In file included from .././../gcc-4.6.3/libcpp/system.h:30:0, from .././../gcc-4.6.3/libcpp/charset.c:22: /var/obj/usr/ports/lang/gcc/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types in declaration specifiers gmake[3]: *** [charset.o] Error 1 gmake[3]: Leaving directory `/var/obj/usr/ports/lang/gcc/work/build/libcpp' gmake[2]: *** [all-stage2-libcpp] Error 2 gmake[2]: Leaving directory `/var/obj/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/var/obj/usr/ports/lang/gcc/work/build' gmake: *** [bootstrap-lean] Error 2 *** [do-build] Error code 1 -- Peter Jeremy pgp6iOXnnAEmJ.pgp Description: PGP signature
Re: [HEADS-UP] CVS commit mails from ports
Thank you for your efforts in migrating the ports repository. On 2012-Jul-16 15:22:13 +0200, Beat Gaetzi b...@freebsd.org wrote: The ports tree switched to Subversion this weekend. CVS commit mails will be turned off soon. If you like to receive the ports commit mails from Subversion please subscribe to svn-ports-all@ or svn-ports-head@. I think this could have been handled a bit better. By turned off soon, I would have expected a couple of days to allow people to read this mail and take some action. Instead, the mails were disabled by simon@ 7 hours after this mail. IMHO, the src list migration was handled more cleanly - peter@ just copied the cvs-all and cvs-src list members over to svn-src-all and shortly after, created a cvs-src-old to allow people time to convert any scripts that processed CVS commits. See http://lists.freebsd.org/pipermail/cvs-all/2008-October/273101.html http://lists.freebsd.org/pipermail/cvs-all/2008-October/273112.html -- Peter Jeremy pgp2Gl1QtOjhV.pgp Description: PGP signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 2012-Jul-16 07:18:05 +0100, Matthew Seaman matt...@freebsd.org wrote: No. Parallel installs will not work -- the first to start will lock the DB, and the second won't be able to proceed. Good - it was the locking I was mostly concerned about. As long as the install is locked, it's safe to run multiple port installs on different terminalls without them treading on each other. (Next step, outside pkgng, in to allow paralles builds). Thank you for all the answers. -- Peter Jeremy pgpsZEGPsgtuN.pgp Description: PGP signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 2012-Jul-16 08:44:56 +0200, n j nin...@gmail.com wrote: Would it be possible to start an FAQ page somewhere on pkgng wiki? There's already one at https://github.com/pkgng/pkgng/blob/master/FAQ.md I think it might be useful to expand it a bit. -- Peter Jeremy pgpRfkCIQFaXr.pgp Description: PGP signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 2012-Jul-12 10:01:10 +, Baptiste Daroussin b...@freebsd.org wrote: What is pkg --- pkg is a new package manager for FreeBSD. It is designed as a replacement for the pkg_* tools, and as a full featured binary package manager. A couple of specific questions that I haven't seen answered during this thread or in the wiki: - Can pkgng cope with parallel installs? What happpens if I simultaneously (attempt to) install conflicting packages? - If I use pkg delete -f, what happens to packages that depended on the forcibly-deleted package? - What happens if I delete a package where I've modified one of the files managed by the package? - What facilities does it have for auditing and repairing the package database? (ie checking for inconsistencies between installed files and the content of the package database) - How does it handle the situation where I install a package that depends on foo version 1.2.3 but have foo version 1.2.4 (or 1.2.2) installed? What about if I have bar version 1.3, which is ABI- compatible with foo version 1.2.3, installed? - Will it detect that a package install would overwrite an existing file? What does it do in this case? - I gather it handles update package more intelligently than uninstall old package, install new package. Will it avoid replacing an old file with an identical one in the new package? If so, what happens to the file metadata (particularly uid, gid and mtime)? - Can it track user-edited configuration files that are associated with packages? - Can it do 2- or 3-way merges of package configuration files? - The README states Directory leftovers are automatically removed if they are not in the MTREE. How does this work for directories that are shared between multiple packages? Does this mean that if I add a file to a directory that was created by a package, that file will be deleted automatically if I delete the package? -- Peter Jeremy pgpK7OwievgBZ.pgp Description: PGP signature
Re: make failed for editors/libreoffice
On 2012-Jul-03 14:19:21 +0200, Dimitry Andric d...@freebsd.org wrote: On 2012-07-02 10:23, Leslie Jensen wrote: ... Assertion failed: (EST != EST_Delayed EST != EST_Uninstantiated), function isNothrow, file /usr/ports/lang/clang/work/llvm-3.1.src/tools/clang/lib/CodeGen/../../include/clang/AST/Type.h, line 2873. ... clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/null_canvascustomsprite-TmaoHV.ii clang: note: diagnostic msg: /tmp/null_canvascustomsprite-TmaoHV.sh ... clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/null_canvasbitmap-m0BlpL.ii clang: note: diagnostic msg: /tmp/null_canvasbitmap-m0BlpL.sh Can you please mail me the .ii and .sh files that are mentioned above? E.g. these files: /tmp/null_canvascustomsprite-TmaoHV.ii /tmp/null_canvascustomsprite-TmaoHV.sh /tmp/null_canvasbitmap-m0BlpL.ii /tmp/null_canvasbitmap-m0BlpL.sh Did you get any further in diagnosing this problem? I am seeing a very similar failure on 8-stable/amd64 (though only affecting null_canvasbitmap). -- Peter Jeremy pgpvoFgLx87cW.pgp Description: PGP signature
Re: Port system problems
On 2012-Jun-26 14:41:32 -0700, Freddie Cash fjwc...@gmail.com wrote: On Tue, Jun 26, 2012 at 1:56 PM, Peter Jeremy pe...@rulingia.com wrote: but I hope the ports build system will not be thrown out as part of the pkgng migration. Where do you think packages would come from, if not built by the ports tree? ;) As long as it's still available to users. Presumably most packages-only Linux distros have some sort of build mechanism as well but it's not readily accessible by ordinary users. I would hope FreeBSD doesn't go down this path. -- Peter Jeremy pgp7jlXJJhutj.pgp Description: PGP signature
Re: Port system problems
On 2012-Jun-26 17:40:08 +0100, Chris Rees cr...@freebsd.org wrote: Also, with pkgng the emphasis is more on binary upgrades. We really shouldn't still be compiling from source for everything in this day and age-- we're one of only two major projects that still do this as the main upgrade solution. One of the big benefits of the FreeBSD ports system is that I can customise ports to suit my needs. I don't have choice forced upon me by a ports maintainer - who may have totally different requirements. I agree the current _package_ system has some rough edges (lack of synchronisation/serialisation to cope with parallel installs and poor overall performance) but I hope the ports build system will not be thrown out as part of the pkgng migration. -- Peter Jeremy pgpK4gPJGeALt.pgp Description: PGP signature
Re: Port system problems
On 2012-Jun-26 20:50:48 +0200, Marcus von Appen m...@freebsd.org wrote: Archlinux does provide complete packages, which makes perfect sense for me. I still do not see any reason or argument on why we would need sub-packages. The most obvious reasons are the compiler ports. If I compile something (eg mplayer - which really wants gcc46) with gcc46 then the resultant executable has dependencies on support libraries supplied by gcc46 (eg lib/gcc46/libgcc_s.so.1). Currently, if I make a package of mplayer and try to install it on another system, then in order to satisfy the (~420KB) dependency on lib/gcc46/libgcc_s.so.1, it pulls is gcc46, which pulls in devel/binutils, math/gmp, math/mpfr and math/mpc - about 120MB. And if I'd selected gcj when I built gcc46 then the total would be about 300MB. This _is_ an issue when I'm installing into the fairly small SSD on my netbook. -- Peter Jeremy pgpuuezoeChnx.pgp Description: PGP signature
Re: using i386 ports on amd64
On 2012-Jun-02 03:47:43 -0500, Lars Eighner portsu...@larseighner.com wrote: I was a little bewildered to discover my machine was amd64 when it had two Celeron processors.* An amd64 CPU can run either FreeBSD/i386 or FreeBSD/amd64. It's up to you which variant to run. You can run i386 code on FreeBSD/amd64 but there are some tricks to get it to work if you need non-base libraries. works on the corporate level, but that left a number of things I use stranded as ONLY_FOR_ARCHS= i386 among them graphics/zgv. Normally ONLY_FOR_ARCHS implies that the port relies on a binary blob or includes CPU-specific code so it won't (can't) build on any other architecture. In the case of graphics/zgv, there's no reason given. It's possible that's an error on the part of the original submitter. Because I am a life-on-the-edge I have discovered that some of them actually will compile and run on this machine, and in particular that once I subverted the ONLY_FOR_ARCHS= graphics/zgv got recompiled and reinstalled during the PNG bump which we are all having fun with right now. So have I armed a ticking time bomb that will somehow blow up an orphanage somewhere down the road? That depends why it was marked ONLY_FOR_ARCHS but if it builds and runs then it'll probably be OK. -- Peter Jeremy pgpkxN3iLFIJ0.pgp Description: PGP signature
Re: Build ports in chroot for i386 when booted with amd64 kernel?
On 2012-May-24 06:47:48 -0400, Thomas Mueller muelle...@insightbb.com wrote: Is it feasible to chroot into an i386 environment when booted to FreeBSD amd64 for the purpose of building and installing ports for i386? Yes. I have built i386 code (both world ports) using both chroot and jail. The only caveat is that the i386 world should be no newer than the host kernel. Assuming /tank/m3 has an i386 world installed: On the host: # mount -r -t nullfs /usr/src /tank/m3/usr/src # mount -r -t nullfs /usr/ports /tank/m3/usr/ports # mount -t devfs devfs /tank/m3/dev # chroot /tank/m3 bin/sh Inside the chroot: # export MACHINE=i386 UNAME_p=i386 UNAME_m=i386 # cd /usr/src make buildworld # cd /usr/ports/.../... make install etc So far, I've only had this fail when building MPIR (which isn't a port and seems to have broken CPU detection code). -- Peter Jeremy pgp4q7u76rNf5.pgp Description: PGP signature
Re: autodetecting dependencies
On 2012-Apr-09 21:02:01 -0500, Stephen Montgomery-Smith step...@missouri.edu wrote: So suppose we are building port A. It turns out that the configure in port A autodetects whether package B is present or not. It will build either way. But if built with package B, it will not operate without it. ... What are the accepted ways of handling this? 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. Preference order is 3, 2, 1. 1 is the least desirable because the resultant packages may include implicit dependencies without explicit dependencies. It can also cause subtle problems when port B is updated without updating port A. -- Peter Jeremy pgp1NNUjL0Lt3.pgp Description: PGP signature
Re: FAQ on PORTREVISION bump?
On 2012-Mar-28 20:52:13 +, Philip M. Gollucci pgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users This is completely backwards. The Project exists for end-users and end users need a way to determine when there's been a change to a port that needs them to re-install that port. Pointyhat provides automated testing facilities as a way to improve the quality of FreeBSD because not all committers are sufficiently careful. If PORTREVISION cannot adequately serve both end users pointyhat, then the ports system needs an additional, new flag to trigger pointyhat. -- Peter Jeremy pgpobIsv3V907.pgp Description: PGP signature
Re: giflib in graphics/gdal
On 2012-Feb-21 14:51:50 -0500, Steve Wills swi...@freebsd.org wrote: Is it correct to use portmaster -o graphics/giflib graphics/libungif Looks OK to me. And then rebuild all ports that used libungif. And thew next question is I have in /var/db/pgs bot giflib and libingif. How can I find whic one is installed, please? Or are both? They install files to the same place, overwriting each other. So whichever one was installed last would be the one that's really installed. It's not quite that simple. Both install include/gif_lib.h but the associated libraries have different names. If you have both installed, the most most recently installed will select which include/gif_lib.h is used but the library used will depend on the whims of the port's configuration tools. is they're very similar, so it didn't cause problems. Nevertheless, it's still a bad idea for them both to be installed, hence the addition of the conflict between them. It's very unfortunate that the ports depending on libungif weren't all cleaned up before the conflict was added. The current situation is a mess and, for many people, requires manual intervention to make the ports system work. -- Peter Jeremy pgpEnRSvwJ7MB.pgp Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2012-Feb-21 17:00:53 -0500, Diane Bruce d...@db.net wrote: Or is this another problem? -rpath is added in /usr/ports/Mk This may help for applications built wihin the ports framework but doesn't help if you want to use gcc46 as a general purpose compiler. On 2012-Feb-21 23:03:27 -0500, Benjamin Kaduk ka...@mit.edu wrote: How would things break if we made everything in the base system specify -rpath of /lib and /usr/lib as appropriate, and then put the ports versions first in the default search path? I have a nasty feeling this would break i386 emulation on amd64 - if the i386 executable has an embedded rpath pointing to /lib, it will fail to find the shared libraries in /lib32. On 2012-Feb-21 20:16:12 -0500, Alexander Kabaev kab...@gmail.com wrote: Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. I agree this is the way to go. I tried suggesting this in ports/142226 but it got closed without actually fixing the problem. (IMO, the whole -rpath approach is backwards - in virtually all cases, if you link against a library at a specific path, you are going want to run against that library as well so the default should be to look there, with something like -rpath only used in the few cases where that isn't correct). Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. One of the big advantages of FreeBSD is that it can recompile itself. Having to install ports to do this would be a massive step backwards and wouldn't actually solve the underlying problem unless you were restricted to having no more than one installed toolchain (which has other problems). -- Peter Jeremy pgp9kJoRtSEVa.pgp Description: PGP signature
Re: mhonarc deprecated use of defined()
On 2012-Jan-17 14:16:56 -0800, Rickie Kerndt kern...@kerndt.com wrote: Mhonarc when run with perl 10.14.2 complains about its deprecated use of defined(%a_hash). I've replaced these defined() where used (not many) as shown in the attached patch files. Is there any interest in updating the mhonarc port to fix this issue? MAINTAINER=po...@freebsd.org means no-one is maintaining that port. If you are interested in maintaining it, I suggest you submit a PR containing those patches and changing the maintainer to yourself. -- Peter Jeremy pgp0Ni90rbeiA.pgp Description: PGP signature
www/firefox not MAKE_JOBS_SAFE?
/firefox/work/mozilla-release' gmake[1]: *** [tier_platform] Error 2 gmake[1]: Leaving directory `/tank/obj/usr/ports/www/firefox/work/mozilla-release' gmake: *** [default] Error 2 *** Error code 1 Stop in /usr/ports/www/firefox. *** Error code 1 Stop in /usr/ports/www/firefox. === make failed for www/firefox -- Peter Jeremy pgpFl2dQzOPl9.pgp Description: PGP signature
Unable to build www/mediawiki
When I try to build www/mediawiki with built-in TeX rendering (WITH_TEXVC)
on, I get:
server% make
=== License check disabled, port has not defined LICENSE
=== Found saved configuration for mediawiki-1.18.0
=== Extracting for mediawiki-1.18.0
= SHA256 Checksum OK for mediawiki-1.18.0.tar.gz.
=== Patching for mediawiki-1.18.0
=== mediawiki-1.18.0 depends on executable: ocaml - found
=== mediawiki-1.18.0 depends on executable: gmake - found
=== mediawiki-1.18.0 depends on shared library: mysqlclient.16 - found
=== Configuring for mediawiki-1.18.0
=== Building for mediawiki-1.18.0
cd: can't cd to /tank/obj/usr/ports/www/mediawiki/work/mediawiki-1.18.0/math
*** Error code 2
Stop in /usr/ports/www/mediawiki.
*** Error code 1
Stop in /usr/ports/www/mediawiki.
server%
The cd fails because that directory doesn't exist (though the parent does).
This appears to be caused by:
# $FreeBSD: ports/www/mediawiki/Makefile,v 1.72 2011/12/08 01:56:00 wen Exp $
...
do-build:
.if defined(WITH_TEXVC)
@(cd ${WRKSRC}/math ${GMAKE})
.endif
Could you please look into this.
--
Peter Jeremy
pgpIPjZbf0zVb.pgp
Description: PGP signature
Re: epson r2400/2880 printers on freebsd8.2 amd64
On 2011-Nov-19 01:53:59 -0800, David Southwell da...@vizion2000.net wrote: Anyone up to date on how to do high quality printing with epson inkjet printers (in my case r2400 and r2880) on freebsd8.2 amd64 systems. print/pips* reports they require 386 and do not compile on amd64. At least some of the pips distfiles include binary blobs (intended for Linux/i386). One approach might be to usee a cut-down i386 jail. -- Peter Jeremy pgpdK0qyPuD54.pgp Description: PGP signature
Re: Recent ports removal
On 2011-Nov-11 12:40:12 -0800, Stanislav Sedov s...@deglitch.com wrote: Because portmgr@ is using it? There're numerous cases when unmaintained, buggy, vulnerable and plainly dangerous stuff stays in tree because someone in portmgr gang likes it when other applications not used by them being removed without prior discussion notice. Because your opinion doesn't matter. Neither is mine. I am getting heartily tired of your continuous tirade against the portmgr@ community. Please provide evidence to backup your accusations or retract them. As for the removal of obsolete ports - it has been made perfectly clear on many occasions that a MAINTAINER of ports@ means that port is _not_ maintained. If it's a port you use, feel free to take over maintainership. Otherwise that port is subject to removal if any problems with it crop up. -- Peter Jeremy pgpsPMP9x6Stn.pgp Description: PGP signature
Re: upgrading to mutt-1.4.2.3_6 with linker error
On 2011-Nov-05 10:59:46 -0500, Troy t...@twisted.net wrote: I'm trying to upgrade Mutt from mutt-1.4.2.3_5 to 1.4.2.3_6 and am running into this error. Any ideas? ... /usr/lib/libhx509.so: undefined reference to `MD2_Init' /usr/lib/libhx509.so: undefined reference to `MD2_Final' /usr/lib/libhx509.so: undefined reference to `MD2_Update' *** Error code 1 This is a known problem - see bin/147175 In your particular case, unless you need GSSAPI, I suggest you turn it off. -- Peter Jeremy pgpHphb0NVrA2.pgp Description: PGP signature
Radeon KMS [was Re: KWin no longer compositing?]
On 2011-Oct-29 12:34:11 +0300, Kostik Belousov kostik...@gmail.com wrote: I think 3-4 months is the reasonable estimation for bringing up both TTM/execution and KMS for radeons. The KMS infrastructure is already ported. If somebody is interested in doing the Radeon driver proper, I may port TTM. I'm also interested in this. Can you give some indication as to what is involved? -- Peter Jeremy pgpQ8zu9OSA2o.pgp Description: PGP signature
Re: [UPDATE] Re: Update on ports on 10.0
[trimming cc list] On 2011-Oct-17 13:51:30 -0700, Stanislav Sedov s...@freebsd.org wrote: ones (like GCC). So why not commit that patch as a KNOB to bsd.port.mk like it was initially proposed and let people use it in individual ports makefiles to fix them (and portmgr@ can commit the initial bunch of these knobs)? This is the easiest thing you can do now, and you will be able to abandon it when the better solution is available (which is unlikely). Once hackish work-arounds get committed, it is extremely difficult to root them out. The last time the project included a temporary hack to assist with a similar problem (the aout to ELF migration in FreeBSD 3), it took more than a decade to get the hack out of base and after 13 years, there are still 71 ports (by my count) with local work-arounds. WRT your submit upstream comment, personanlly, I'd argue against this: Ports are never going to get fixed unless we advise the upstream maintainer that there is a problem. this is not the upstream maintainer's problem, it the buggy tools they use Unfortunately, we are unlikely to convince many people that GNU autocr*p is broken by design. But it _is_ the upstream maintainer's problem that they chose to use buggy/broken tools. to generate the configure scripts, so until the fixed version of libtool is available in all major distributions and widely installed, they're not going to replace it or patch locally. A reasonable approach would be to come up with fixes to libtool and the rest of autocr*p and get them applied to the master versions. Then go to the upstream maintainers with something along the lines of your foobar-1.2.3 will not work on FreeBSD 10 due to bugs in libtool and/or autocr*p. This has been in version X of those tools. If you are unable te update, could you please apply the following patch locally. Of course, this only applies to the latest version, old versions are going to need to be patched in the ports tree. Given the debian/ubuntu release schedule, this is not going to happen earlier that 1-2 years from now, and Based on the objformat mess, whatever is done will hang around in the tree for at least a decade so we are far better off spending some time now to come up with the best solution, rather than quickly committing a work-around that we spend the next decade regretting. Whatever action we take will your patches/requests sent could potentially cause them to abandon FreeBSD support altogether requiring a lot of work to maintain which will be totally understandable. I don't see how this follows. It's no different to upstreaming any other FreeBSD-specific change. -- Peter Jeremy pgplPPw6zkySi.pgp Description: PGP signature
Re: Instafix for FreeBSD ports brokenness on 10.0?
On 2011-Sep-30 17:10:20 -0400, Jim Trigg jtr...@spamcop.net wrote: I have to admit that my reaction is not so much Why won't you fix ports for 10.0 as Why was 9.0 dropped out of CURRENT and 10.0 introduced before 9.0 went STABLE? FreeBSD releases are from CVS/SVN branches, rather than the main trunk. Thus, before 9.0 can be released, the 9.x branch (RELENG_9) must be created. Once the 9.x branch has been created, the main trunk needs to be renamed to distinguish it - hence 10-CURRENT. And note that 9.0 isn't STABLE, it is BETA3, on it's way to 9.0-RELEASE. Once 9.0-RELEASE has been released (or, possibly, shortly before), the 9.x branch will become STABLE. See http://www.freebsd.org/releases/9.0R/schedule.html for more details (though the dates are wrong). -- Peter Jeremy pgpce8Y83pxkV.pgp Description: PGP signature
astro/boinc-milkyway errors
Hi Pav, I've just discovered that astro/boinc-milkyway has been returning Validate error to me for some time (it looks like several months). I've had a look at a couple of other people in the FreeBSD team[0] and there's only one person with a functional FreeBSD client[1] and it's not clear how his system is different. Could you please have a look and see what the problem is. [0] http://milkyway.cs.rpi.edu/milkyway/team_members.php?teamid=581offset=0sort_by=expavg_credit [1] http://milkyway.cs.rpi.edu/milkyway/show_host_detail.php?hostid=289084 -- Peter Jeremy pgpOKudusndpX.pgp Description: PGP signature
Re: sysutils/cfs
On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org wrote: What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? This might be reasonable for broken ports but ports with known vulnerabilities should either be fixed or removed promptly. Personally, I'd also love to see people deprecating ports provide a clear reasoning for deprecation in the commit message (not just deprecated some old ports etc), so one won't need to guess if he would like to fix/resurrect the port in the feature? This is a reasonable requirement. On 2011-Sep-07 01:35:54 -0600, Chad Perrin c...@apotheon.net wrote: One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. Any VCS worthy of the name will retain history for objects that no longer exist because you might want to look at the state as it was at some point in the past when that object still existed. CVS stores the RCS masters for these deleted files is a subdirectory 'Attic' under the original directory. The data is only accessible via CVS - either using a local repository or via CVSweb. As an example, look at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=0 I would think that the porter's handbook, at least, should mention it (perhaps with a brief explanation of why and how one might make use of it). Again, it comes down to someone with the knowledge, motivation and time to write the content. On 2011-Sep-07 10:02:42 -0700, per...@pluto.rain.com wrote: Reread the first paragraph. Provided the port is still in the tree, when they try to build it the ports mechanism reports the FORBIDDEN/BROKEN/whatever which describes the problem, and the expiration date a month or two out. ... In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. This last statement isn't true - when a port is moved or removed, a one-line reason for the change is added to /usr/ports/MOVED The package management tools are generally aware of this file. It's only going to be removed if no one fixes it. The whole point is that release users don't continuously monitor their ports -- they only upgrade when they become aware that they need to (e.g. when a newer release becomes available). This isn't necessarily a wise approach. The proposal is to increase the liklihood that, come upgrade time, a release user gets a specific, actionable description of any problems that have arisen, rather than having a port that they have been using mysteriously disappear. Again, ports don't mysteriously disappear - there will be a record of why it was removed in the MOVED file. Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. Cleaning out the cruft will still leave a very large number of ports. And a better selling point is having a large number of functional ports - having a ports tree full of ports that are broken doesn't benefit anyone. So define a variable along the lines of NEXT_PORT_PURGE_DATE in one of the /usr/share/mk/bsd.port*.mk files, which (being part of the base) _are_ branched, and when a situation of the kind under discussion arises set the port's EXPIRATION_DATE to NEXT_PORT_PURGE_DATE. Two issues: 1) Since the ports tree isn't branched and a port either exists or it doesn't exist, there needs to be a single expiration date. 2) There still needs to be a minimum expiration duration so you need a way to handle the case where a port is marked to be purged immediately before the NEXT_PORT_PURGE_DATE. -- Peter Jeremy pgpRs3WpUoaIF.pgp Description: PGP signature
Re: Problems building devel/gobject-introspection
On 2011-Aug-29 13:45:34 +0400, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Peter Jeremy wrote on 29.08.2011 07:29: Turns out that my python was dodgy. ... And did you realize what python option had triggered that? I'm curious since i'm wasn't able to reproduce it here. For me it looks like upstream bug dealing with unicode() vs str() output, since errors like that you provide in original message may be fixed by `setenv LANG C` in most of cases. I've done some experiments but have not been able to reproduce the problem - which is annoying. I agree it looks locale-related but I don't have any locale-related variables set. -- Peter Jeremy pgp5C4GiQcKwS.pgp Description: PGP signature
Re: Problems building devel/gobject-introspection
On 2011-Aug-26 15:05:35 +1000, Peter Jeremy pe...@server.vk2pj.dyndns.org wrote: I am having problems building devel/gobject-introspection on one 9.0-BETA1 host. I can build it without problems on 8.2 and another 9.0-BETA1 box. In all cases, I'm using gcc and amd64. The failure is: ... Since this only happens on one box, it's presumably something I've done but I'm not sure what. Google hasn't helped. Does anyone have any ideas on where to start looking? Turns out that my python was dodgy. Deleting /var/db/ports/python27/options and rebuilding with default options fixed it. I thought I was using the defaults before but forgot to check the contents before deleting it. Thanks to Ruslan Mahmatkhanov cvs-...@yandex.ru for his suggestions. -- Peter Jeremy pgpsq3onpJaA3.pgp Description: PGP signature
Problems building devel/gobject-introspection
I am having problems building devel/gobject-introspection on one
9.0-BETA1 host. I can build it without problems on 8.2 and another
9.0-BETA1 box. In all cases, I'm using gcc and amd64. The failure
is:
GISCAN GLib-2.0.gir
g-ir-scanner: GLib: warning: 484 warnings suppressed (use --warn-all to see
them)
Traceback (most recent call last):
File ./g-ir-scanner, line 43, in module
sys.exit(scanner_main(sys.argv))
File ./giscanner/scannermain.py, line 427, in scanner_main
exported_packages, options.c_includes)
File ./giscanner/girwriter.py, line 40, in __init__
c_includes)
File ./giscanner/girwriter.py, line 64, in _write_repository
self._write_namespace(namespace, shlibs)
File ./giscanner/girwriter.py, line 100, in _write_namespace
self._write_node(node)
File ./giscanner/girwriter.py, line 125, in _write_node
self._write_constant(node)
File ./giscanner/girwriter.py, line 350, in _write_constant
with self.tagcontext('constant', attrs):
File /usr/local/lib/python2.7/contextlib.py, line 17, in __enter__
return self.gen.next()
File ./giscanner/xmlwriter.py, line 165, in tagcontext
self.push_tag(tag_name, attributes)
File ./giscanner/xmlwriter.py, line 153, in push_tag
self._open_tag(tag_name, attributes)
File ./giscanner/xmlwriter.py, line 97, in _open_tag
len(tag_name) + 2)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x93 in position 39: invalid
start byte
gmake[2]: *** [GLib-2.0.gir] Error 1
gmake[2]: Leaving directory
`/tmp/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/tmp/usr/ports/devel/gobject-introspection/work/gobject-introspection-0.10.8'
gmake: *** [all] Error 2
*** Error code 1
Stop in /usr/ports/devel/gobject-introspection.
Note that if I go to the work directory and run gmake, the error
changes to:
UnicodeDecodeError: 'utf8' codec can't decode byte 0x81 in position 74: invalid
start byte
Since this only happens on one box, it's presumably something I've done
but I'm not sure what. Google hasn't helped. Does anyone have any
ideas on where to start looking?
--
Peter Jeremy
pgpJsAmfRItdk.pgp
Description: PGP signature
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
On 2011-Aug-23 07:45:04 +0100, Chris Rees utis...@gmail.com wrote: On 22 Aug 2011 22:49, Peter Jeremy peterjer...@acm.org wrote: On 2011-Aug-21 08:30:13 +0200, lini...@freebsd.org wrote: portname: cad/tkgate I have no problem fetching this port from the mastersite. I'll take a look. Thanks for undeprecating this. portname: sysutils/cpuburn Actually, the mastersite has been discontinued by the ISP. It looks like it's still available elsewhere but I can't find a replacement mastersite. So this one is correct??? It seems to be - which is unfortunate. -- Peter Jeremy pgpF7dXMgyo6I.pgp Description: PGP signature
Re: FreeBSD unmaintained ports which are currently scheduled for deletion
On 2011-Aug-21 08:30:13 +0200, lini...@freebsd.org wrote: portname: cad/tkgate description:A Tcl/Tk based digital circuit editor and simulator maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=tkgate I have no problem fetching this port from the mastersite. portname: sysutils/cpuburn description:CPU/memory stress testing utilities maintainer: po...@freebsd.org deprecated because: No more public distfiles expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=cpuburn Actually, the mastersite has been discontinued by the ISP. It looks like it's still available elsewhere but I can't find a replacement mastersite. -- Peter Jeremy pgp92rokiqI78.pgp Description: PGP signature
Re: UPDATING 20110730
On 2011-Aug-01 19:21:21 +0200, Michel Talon ta...@lpthe.jussieu.fr wrote: This is unfortunately impossible because the ports system is organized around a make logic and the relevant dependency variables are only obtained through running make on each ports Makefile *in the context* of the gigantic makefiles (bsd.port.mk, etc) which are included. We've had this discussion before but there is plenty of scope for someone with copious free time to optimise this. Options include a new tool that handles the easy cases without needing to fully parse all of bsd.*.mk (and knows to punt the cases it can't handle to make) and/or pre-precessing bsd.*.mk to speed up their loading. Note that about 1/3 of bsd.*.mk is comments. On 2011-Aug-02 22:12:48 +0300, Andriy Gapon a...@freebsd.org wrote: I will repeat myself: currently portmaster's performance relies on the fact that certain often used data originating from disk is actually cached in memory by the OS. Typically performance-conscious applications explicitly pull such data into an application cache. An alternative viewpoint is that this is wasteful because data is then double-buffered. An alternative view is that the default ZFS configuration is sub-optimal and should be fixed - rather than insisting that every tool that accesses more than a handful of files should do its own caching. (And, reading zfs-discuss, avg@ is far from the only person to have been bitten by the ZFS metadata limit). -- Peter Jeremy pgp4AvKy1tNvA.pgp Description: PGP signature
Re: Which to bump for distfile location change?
On 2011-Jul-26 17:03:24 -0400, Wesley Shields w...@atarininja.org wrote: On Tue, Jul 26, 2011 at 09:08:13PM +0100, Chris Rees wrote: No default package change, no portrevision bump. Leave it as is. Chris is right but I don't want to give people the impression that is the only time to bump PORTREVISION. Another way of looking at it is: Should a user who has the port successfully installed rebuild the port, even though the distfile version hasn't changed. -- Peter Jeremy pgpdoZpZTL7sJ.pgp Description: PGP signature
