Re: MASTER_SITES= LOCAL/
In message <4ca824b01d94b9a964553...@atuin.in.mat.cc>, Mathieu Arnold writes: > +--On 22 avril 2016 21:30:31 -0700 Cy Schubert > wrote: > | Hi, > | > | I've noticed recently that a number of ports with MASTER_SITES= LOCAL/ > | have been marked BROKEN due to being unfetchable. Should local master > | sites on people.freebsd.org be defined differently? Has there been a > | change in policy? > > LOCAL/ is not really valid, it's supposed to be LOCAL/. > > Do you have a list of ports that are affected ? Now that I 1/4 better and thinking clearly, I see where the problem is. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: WANT_BDB_VER Ignored
Thanks, that resolves the issue. Is their a way to set the default DB version with make.conf? I tried using: DEFAULT_VERSIONS+=bdb=4.8 That didn't work. I have about 50+ custom ports (crypto currency wallets need DB 4.8) that use this option and rather than manually set the DB version for each one, I'd like to see if I can set it globally so when I'm ready to upgrade to DB 5.3, I don't have to go back and change them all. On 4/27/2016 5:04 AM, Mathieu Arnold wrote: +--On 26 avril 2016 22:24:34 -0400 Daniel Morante wrote: | I have the following in a port Makefile: | | USE_BDB=yes | WANT_BDB_VER=48 Mmm, WANT_BDB_VER is not supported any more, like the commit says, use USES=bdb:48. smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD Port: owncloud-9.0.1_1
On 28 avr. 2016, at 09:32, Miroslav Lachman wrote: > Kevin Lo wrote on 04/28/2016 09:06: >> >> I added a dependency on net/pecl-smbclient and it works fine for me when >> uploading files over smb. Please give it a spin, thanks. > > Then somebody should fix it's dependency. net/pecl-smbclient depends on > net/samba36 which is deprecated, expired 2016-04-01 and is waiting for > removal from the ports tree. Thanks Kevin, I'm going to give it a try. But as Miroslav points out, now we have a problem with pecl-smbclient :/ Not such a big deal for me right now, because I'm using samba-smbclient which comes only as separate pkg as version 3.6. I'm "deprecated" already ;) regards Patrick ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports with X11 options
Albert Shih wrote on 04/28/2016 16:49: Hi, Some ports got a option « WITH_X11 ». I would like to known what's that mean on a server ? Can I safely disable every WITH_X11 if those software is for a server. For example, php-gd need graphics/cairo. If I disable X11 can I got some issue with php-gd ? If you don't want to read / write images in some X11 format, you don't need this option enabled. I have this settings in make.conf for all our servers for many years OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS HAL No problems so far. Miroslav Lachman ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports with X11 options
On 04/28/16 15:49, Albert Shih wrote: > Some ports got a option « WITH_X11 ». I would like to > known what's that mean on a server ? Can I safely disable every WITH_X11 if > those software is for a server. > > For example, php-gd need graphics/cairo. If I disable X11 can I got some > issue with php-gd ? This depends very much on the port in question. Yes, for some ports WITH_X11 means the software is compiled so that it can make use of a graphical environment, and that is generally safe to turn off on a server. For other ports, like GD, these use bits of X Windows to generate images -- typically something like using X fonts to render text into the image. In these cases, turning off the X11 support will remove that functionality, which may or may not be what you want. It's also the case that some ports higher in the dependency tree sometimes expect their dependencies to have X support, but that isn't enforced through the ports. so turning off X in a dependency can break the build of some other ports. In general, X support for an application will need only the X client libraries, and those are not huge. Unless you're in a very constrained environment or you're a perfectionist[*], just leaving the server ports with X enabled is not going to cause you any terrible problems. Cheers, Matthew [*] Like me. I build packages for server deployment without X support as far as possible, and luckily it's not mandatory for pretty much anything we want to deploy. Except for Java stuff: JVMs always link against the X client libraries. But it took a few rounds of trial and error and fiddling with options under poudriere to get things building to my liking. signature.asc Description: OpenPGP digital signature
Ports with X11 options
Hi, Some ports got a option « WITH_X11 ». I would like to known what's that mean on a server ? Can I safely disable every WITH_X11 if those software is for a server. For example, php-gd need graphics/cairo. If I disable X11 can I got some issue with php-gd ? Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: j...@obspm.fr Heure local/Local time: jeu 28 avr 2016 16:44:27 CEST ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports tree gone unstable?
On Wed, 27 Apr 2016 23:48:43 -0700 (PDT) Don Lewis wrote: > I'd lose many hours of potential build time. Because of the > infrequent upgrades I would have to deal with all of the intervening > special cases in UPDATING that accumulated between upgrades, and the > portupgrade -fr and -a options didn't interoperate well, so I ended > up having to build some ports multiple times. If things crashed, > then I'd have to run portupgrade -rf again, rebuilding a lot of > things unnecessarily since there was no way of doing a restart. FWIW the portupgrade -fr entries in UPDATING only need be followed if you are doing a partial update. Any port affected by these gets its port revision bumped, so is rebuilt as part of a portupgrade -a. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Failure compiling java/openjdk8
On 04/28/16 07:01, Michael Jung wrote: > [...] > If you really want to try and build it on that system and have some free > disk > space you could always add a file instead of a partition as extra swap. > > Instuctions here: > > https://www.freebsd.org/doc/handbook/adding-swap-space.html > > --mikej > [...] I must warn you that using "swapon " (at least on FreeBSD 8 and earlier) was a guaranteed recipe for a panic for me. I've been afraid to try it any more recently. -- George ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Failure compiling java/openjdk8
On 2016-04-28 05:30, Willem Offermans wrote: Dear Matthias and FreeBSD friends, On Sun, Apr 24, 2016 at 10:48:16AM +0200, Matthias Andree wrote: Am 23.04.2016 um 12:02 schrieb Willem Offermans: > Dear FreeBSD friends, > > In my attempt to juvenile an old FreeBSD beast, I encountered another > hurdle: a failure compiling java/openjdk8 > > > gmake[4]: Leaving directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > gmake[4]: Entering directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > Compiling 9455 files for BUILD_JDK > Killed > gmake[4]: *** [/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86-normal-server-release/jdk/classes/_the.BUILD_JDK_batch] Error 137 That Error 137 is "signal 9 (SIGKILL)" and added 128 for "core dump requested". Typically an indication of a last-resort cleanup by the kernel. Has the machine run out of memory during the compile? Can you reduce the number of CPU cores used for the compile, in an attempt to reduce RAM usage? You were right about the memory usage during the compilation. The system is an old one and has only 512 MB RAM and one CPU core. During compilation of openjdk8 it run out of memory. The swap file, which is 512 MB as well, was completely used. Shortly after this state was reached, the above error message appeared, but the system __did not__ freeze. The bad part is that I cannot upgrade the old system totally. The good part is that all other programs could be updated without any problem. Many thnx to the good work of the FreeBSD community. I really appreciate this. I like to test some things on this rejuvenated beast and probably I don't need openjdk8 for that. So I can live with the situation. I only announced it, so that other people do not run into the same situation. But who is running a FreeBSD system with 512 MB RAM nowadays anyway? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Will * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" If you really want to try and build it on that system and have some free disk space you could always add a file instead of a partition as extra swap. Instuctions here: https://www.freebsd.org/doc/handbook/adding-swap-space.html --mikej ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Ports tree gone unstable?
Don Lewis wrote: On 28 Apr, Michelle Sullivan wrote: Don Lewis wrote: I'd thought that poudriere was using the host copy of pkg to do the final part of the respository build, but since poudriere doesn't list pkg as a dependency, that appears not to be the case. It looks like poudriere is running pkg (from the repository being constructed) in the jail for that. Yeah.. except something around the time went about "upgrading" the OS to use pkg as well... which screwed the OS... fortunately I caught the first VM it tried to do it to and was able to limit the damage just to that VM so the rebuild was minimum. How were you upgrading ports when this happened. I ask because the old pkg_* tools didn't have the equivalent of "pkg upgrade". I'm guessing that you probably used "portupgrade -P" or "portmaster -P" as a wrapper around the pkg_* tools, and I think that requires a copy of the ports tree on the client machines even though binary packages are being used. Actually no, I was 'pkg_delete -fa' followed by a list of pkg_add -r http:// ... on the build hosts... Puppet deals with the production servers and relies on the entire repo list being successfully built and then all the packages being successfully regression tested. If that's the situation, I think what probably happened is that when up updated to a version of the ports tree after support for old-style packages was turned off, poudriere rebuilt the repository with new-style packages. Then when you ran portupgrade or portmaster on the client with the same version of the ports tree, the framework then told portmaster/portupgrade to not look for WITH_PKGNG=yes in /etc/make.conf and just to go ahead and use pkg to upgrade the packages. Since the database of installed packages hadn't been upgraded with pkg2ng, chaos ensued. At the time of this transition, I was still using portupgrade to build everything from source. Before I switched to pkgNG, I was having problems with database corruption because the old package tools didn't really handle running out of disk space during an upgrade. I only upgraded packages infrequently because the process was so painful. It would take two or three days to do an upgrade on my desktop and I'd have to monitor it around the clock. If portupgrade ran into an error or stopped to ask a question just after I went to sleep, then I'd lose many hours of potential build time. Because of the infrequent upgrades I would have to deal with all of the intervening special cases in UPDATING that accumulated between upgrades, and the portupgrade -fr and -a options didn't interoperate well, so I ended up having to build some ports multiple times. If things crashed, then I'd have to run portupgrade -rf again, rebuilding a lot of things unnecessarily since there was no way of doing a restart. A classic cause of that would happen if portupgrade decided to rebuild gdm, in which case it would stop gdm before removing the the old version and restart it after installing the new version. Unfortunately, stopping gdm would kill Xorg and thus the terminal window where portupgrade was running. Eventually things got to the point that I could no longer tolerate the extended downtime of my primary desktop machine, so I started building binary packages using portupgrade -p on a faster headless machine. The builds still took a long time, but the final upgrade on my desktop using "pkg upgrade" was *much* faster. I went with pkg on one of my staging servers for the prod environment... the server had to be wiped and reinstalled from scratch... I haven't go with pkgng since and have nicknamed it 'pkg no good'.. figured I'd give it time to actually become stable before trying again (you know where you don't get an announcement that you have to upgrade past "this" version to make stuff work again).. however it's rapidly becoming apparent that the systems will no longer build without completely switching everything so its go with the unstable versions or drop NG support until I have time to fix what was broken... Health comes first, NG is officially dropped across the company as a whole it won't be happening now until/if I'm given the all clear. Building the packages with portupgrade was still flakey and eventually broke when the ports tree was converted to staging. At that point I bit the bullet and converted to poudriere and life was so much better. Not only did that eliminate a lot of manual intervention to build the packages, but the paralled builds sped things up a lot. Even though poudriere isn't especially efficient about deciding what needs to be rebuilt, the build times for my package set went from several days to under 12 hours, and the latter includes a number of huge ports that I never used to build. I used to patch by hand as needed. I switch to a load of headless VMs, jails, Jenkins, Puppet etc when there was the 'staging' push when I thought I could do my bit for the project.. little was I to kno
Re: Failure compiling java/openjdk8
Dear Matthias and FreeBSD friends, On Sun, Apr 24, 2016 at 10:48:16AM +0200, Matthias Andree wrote: > Am 23.04.2016 um 12:02 schrieb Willem Offermans: > > Dear FreeBSD friends, > > > > In my attempt to juvenile an old FreeBSD beast, I encountered another > > hurdle: a failure compiling java/openjdk8 > > > > > > gmake[4]: Leaving directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > > gmake[4]: Entering directory > > '/usr/ports/java/openjdk8/work/openjdk/jdk/make' > > Compiling 9455 files for BUILD_JDK > > Killed > > gmake[4]: *** > > [/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86-normal-server-release/jdk/classes/_the.BUILD_JDK_batch] > > Error 137 > > That Error 137 is "signal 9 (SIGKILL)" and added 128 for "core dump > requested". Typically an indication of a last-resort cleanup by the kernel. > > Has the machine run out of memory during the compile? > > Can you reduce the number of CPU cores used for the compile, in an > attempt to reduce RAM usage? You were right about the memory usage during the compilation. The system is an old one and has only 512 MB RAM and one CPU core. During compilation of openjdk8 it run out of memory. The swap file, which is 512 MB as well, was completely used. Shortly after this state was reached, the above error message appeared, but the system __did not__ freeze. The bad part is that I cannot upgrade the old system totally. The good part is that all other programs could be updated without any problem. Many thnx to the good work of the FreeBSD community. I really appreciate this. I like to test some things on this rejuvenated beast and probably I don't need openjdk8 for that. So I can live with the situation. I only announced it, so that other people do not run into the same situation. But who is running a FreeBSD system with 512 MB RAM nowadays anyway? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Will * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: owncloud-9.0.1_1
On Thu, 28 Apr 2016 10:45:48 +0300 a...@abinet.ru wrote: > > > Please, make this optional! I don't want samba on my server. +1 -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
FreeBSD Port: samba-virusfilter-0.1.3_1
There seems to be very little information on this port? I got it working with samba36 but it makes samba crash regularly. It doesn't appear to work with samba43 at all. Thanks, Jon. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: owncloud-9.0.1_1
Please, make this optional! I don't want samba on my server. Miroslav Lachman писал 2016-04-28 10:32: > Then somebody should fix it's dependency. net/pecl-smbclient depends on > net/samba36 which is deprecated, expired 2016-04-01 and is waiting for > removal from the ports tree. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: owncloud-9.0.1_1
Kevin Lo wrote on 04/28/2016 09:06:
On Wed, Apr 27, 2016 at 04:34:23PM +0200, pat...@patpro.net wrote:
Hello,
Hi Patrick,
I'm currently trying to setup Owncloud on FreeBSD 10.2.
I'm using the provided files_external app to give access to SMB shares, but it
fails when I try to upload files.
[...]
digging in the code shows things like:
preg_split('/\s+/', `ps -o pid --no-heading --ppid $ppid`);
(from apps/files_external/3rdparty/icewind/smb/src/RawConnection.php)
which will never work on FreeBSD because it requires a GNU ps...
Similarly, in apps/files_external/3rdparty/icewind/smb/src/Server.php and
apps/files_external/3rdparty/icewind/smb/src/Share.php some references to
/proc/self/fd exist that must be changed in /dev/fd.
Is there any plan to patch linux-only commands and paths in Owncloud
package/port?
I added a dependency on net/pecl-smbclient and it works fine for me when
uploading files over smb. Please give it a spin, thanks.
Then somebody should fix it's dependency. net/pecl-smbclient depends on
net/samba36 which is deprecated, expired 2016-04-01 and is waiting for
removal from the ports tree.
Miroslav Lachman
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD Port: owncloud-9.0.1_1
On Wed, Apr 27, 2016 at 04:34:23PM +0200, pat...@patpro.net wrote:
>
> Hello,
Hi Patrick,
> I'm currently trying to setup Owncloud on FreeBSD 10.2.
> I'm using the provided files_external app to give access to SMB shares, but
> it fails when I try to upload files.
>
> looking at apache's logs reveal many errors:
>
> net: not found
> net: not found
> ps: illegal option -- -
> usage: ps [-aCcdefHhjlmrSTuvwXxZ] [-O fmt | -o fmt] [-G gid[,gid...]]
> [-J jid[,jid...]] [-M core] [-N system]
> [-p pid[,pid...]] [-t tty[,tty...]] [-U user[,user...]]
> ps [-L]
> net: not found
> net: not found
> net: not found
>
> digging in the code shows things like:
>
> preg_split('/\s+/', `ps -o pid --no-heading --ppid $ppid`);
> (from apps/files_external/3rdparty/icewind/smb/src/RawConnection.php)
>
> which will never work on FreeBSD because it requires a GNU ps...
>
> Similarly, in apps/files_external/3rdparty/icewind/smb/src/Server.php and
> apps/files_external/3rdparty/icewind/smb/src/Share.php some references to
> /proc/self/fd exist that must be changed in /dev/fd.
>
> Is there any plan to patch linux-only commands and paths in Owncloud
> package/port?
I added a dependency on net/pecl-smbclient and it works fine for me when
uploading files over smb. Please give it a spin, thanks.
> thanks,
> Patrick
Kevin
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
