Fwd: FreeBSD ports you maintain which are out of date

[Alfred Perlstein]

How do I stop these emails?

I just retired my commit bit and stopped committing to ports after some 
folks yelled at me for committing to ports without signoff even though I 
was doing ports before the src/ports split.


thanks,

-Alfred



 Forwarded Message 
Subject:FreeBSD ports you maintain which are out of date
Date:   Thu, 14 Mar 2019 11:27:00 +
From:   portsc...@freebsd.org
To: alf...@freebsd.org



Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/alf...@freebsd.org.html


Port | Current version | New version
+-+
www/py-djangorestframework-filters | 0.10.2 | 0.11.0
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Thanks.

___
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"

is there a "make submit" target for ports?

[Alfred Perlstein]

Hello, looking through the guidebook I didn't see a target to make a PR 
submission with a port update.



Does one exist?


Example:

I bump the version number for some trivial python port.

Want to go through the PR process to get review.

Type "make submit"?  To submit this.


Is there some target or userland tool for this?  Or am I going to have 
to figure out if it's github, phabricator, bugzilla or something new?



Would there be interest in this being added?


thank you,

-Alfred (FreeBSD since ~1997, committer since ~1999)


___
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: manpath change for ports ?

[Alfred Perlstein]

On 3/6/17 3:56 PM, Baptiste Daroussin wrote:

Hi all,

I would like to propose a change in the localbase hier for ports

I think we should add /usr/local/share/man in the manpath along with at first
and maybe instead of in long term.

The reason is:
- /usr/local/share/man seems more consistent to me with base which have:
   /usr/share/man
- It will remove lots of patches from the ports tree where were we need to patch
   upstream build system to install in a non usual path.

My proposal is to add to the manpath /usr/local/share/man in default man(1)
command in FreeBSD 12 (MFCed to 11-STABLE)

and either provide an errata for 11.0/10.3 or a
/usr/local/etc/man.d/something.conf via a port or something like that for those
two, what do you think?

For the same reason I would like to allow porters to stop patching (with pathfix
or anything else) the path for pkgconfig files and allow
/usr/local/lib/pkgconfig along with the current
/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig

Which will also remove tons of hacks from the ports tree.

What do you think?

Best regards,
Bapt
Yes please.  Reducing the required changes to port software to FreeBSD 
is a good thing.


-Alfred
___
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: VirtualBox port not working with USB

[Alfred Perlstein]

Nice!

Sent from my iPhone

> On Jan 25, 2017, at 12:15 PM, Graham Menhennitt <gra...@menhennitt.com.au> 
> wrote:
> 
>> On 26/01/2017 06:41, Hans Petter Selasky wrote:
>>> On 01/25/17 10:00, Graham Menhennitt wrote:
>>>> On 25/01/2017 00:43, Hans Petter Selasky wrote:
>>>>> On 01/24/17 12:03, Graham Menhennitt wrote:
>>>>>> On 24/01/2017 04:19, Alfred Perlstein wrote:
>>>>>> Graham, can you follow what Hans is asking and report back please?
>>>>>> 
>>>>>> 
>>>>>>> On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky <h...@selasky.org>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> There hasn't been any big changes in the FreeBSD userspace interfaces
>>>>>>> used by virtualbox for a while. Maybe you can try to collect output
>>>>>>> from "usbdump -i usbusX -f Y -s 65536 > log.txt" where X and Y are
>>>>>>> the numbers after ugenX.Y for the device in question. I'll give
>>>>>>> virtualbox from FreeBSD ports a spin and see if there is something
>>>>>>> obvious broken.
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> Can you compile VirtualBox with full debugging enabled (make config
>>>> and add all debug flags before building) and capture the resulting
>>>> debug log(s) and send to me?
>>>> 
>>>> There are some debug prints in "USBProxyBackendFreeBSD.cpp" and
>>>> "USBProxyDevice-freebsd.cpp" which I need to see and you should see
>>>> them too when you add/remove USB devices.
>>> 
>>> Hans,
>>> 
>>> I think that this is what you're after. If not, I can have another go.
>>> But it dies pretty quickly so I'm not sure what more I can do.
>>> 
>>> Thanks,
>>>Graham
>>> 
>> 
>> Hi Graham,
>> 
>> Can you try to replace the two attached files in 
>> /usr/ports/...virtualbox-ose/files and re-build. Can someone here 
>> interacting with the VBOX team make sure these patches gets pushed upstream?
>> 
>> --HPS
>> 
> Thank you very much, Hans. Working for me now.
> 
> Thanks,
> 
>Graham
> 

___
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: VirtualBox port not working with USB

[Alfred Perlstein]

Thank you Hans!

Graham, can you follow what Hans is asking and report back please?

I'm going to step out now. Good luck!

Sent from my iPhone

> On Jan 23, 2017, at 8:14 AM, Hans Petter Selasky <h...@selasky.org> wrote:
> 
>> On 01/23/17 16:45, Alfred Perlstein wrote:
>> Hans,
>> 
>> You're the USB god, any ideas here?
>> 
>> thank you,
>> 
>> -Alfred
> 
> Hi Alfred,
> 
> There hasn't been any big changes in the FreeBSD userspace interfaces used by 
> virtualbox for a while. Maybe you can try to collect output from "usbdump -i 
> usbusX -f Y -s 65536 > log.txt" where X and Y are the numbers after ugenX.Y 
> for the device in question. I'll give virtualbox from FreeBSD ports a spin 
> and see if there is something obvious broken.
> 
> --HPS
> 

___
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: VirtualBox port not working with USB

[Alfred Perlstein]

Hans,

You're the USB god, any ideas here?

thank you,

-Alfred


On 1/21/17 4:37 PM, Graham Menhennitt wrote:

G'day all,

About 6 months ago, the FreeBSD port of VirtualBox was upgraded from 
version 5.0.26 to 5.1.4. The new version didn't work with USB devices 
whereas the old one did. I raised PR 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212845 at the time. 
Since then, the port has followed the releases of VirtualBox up to 
5.1.14 as of last week (thanks, jkim). However, the same USB problem 
has existed for all that time.


I'm having a go at trying to fix it. But I know almost nothing about 
the VirtualBox source code. So, I'd like some help please. Does 
anybody here have any experience with this. Or any clues as to where I 
should start looking.


At the moment I'm just trying to do diffs between the old and new 
versions, but it's a fairly daunting task. I'm also going to try 
building versions 5.0.32 and 5.1.0 (which never had FreeBSD ports) to 
see whether the breakage was in between them (I presume that it was).


Thanks for any help,

Graham

___
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-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: Is there possible run a MacOS X binary

[Alfred Perlstein]

On 12/7/16 10:57 AM, K. Macy wrote:




A MachO activator is indeed not useful without an OSX install.

But let's be honest, Mach IPC is a loadable kernel module requiring no real
kernel changes. It's not upstreamable because of a general poor
understanding of IPC by noisy commentators and a religious aversion to a
technology perceived as having failed in the marketplace of ideas.

I'd be happy to upstream it.  Are there diffs relative to -current?

-Alfred




On Wed, Dec 7, 2016 at 10:45 Warner Losh  wrote:


On Mon, Dec 5, 2016 at 12:31 PM, Kevin P. Neal 
wrote:


On Mon, Dec 05, 2016 at 02:49:07PM -0300, Nilton Jose Rizzo wrote:

  Sorry for cross posting (-current and -ports)
Is there any emulator like linuxator to run Mac OS X binaries, or
is ther any licensing problem?

It may be possible to make an emulator for Darwin (the OS that Mac OS

sits


on top of), but an emulator for Mac OS would probably require a legal

copy


of Mac OS.
So, no, there is no Mac OS emulator for FreeBSD. And I'd be surprised if
it ever happened.



NetBSD has (or had) a macho image activator, which is the first step

in this process. But Kevin is right that most of the functionality of

MacOS isn't in the kernel, and you'd need a copy of MacOS to run it in

emulation. Plus there's a lot of Mach code that MacOS depends on that

has no simple counterparts in FreeBSD, and that would be a lot of work

to make happen. It's one of the things that's a barrier to entry for a

simple, straight forward launchd port, for example.








___
freebsd-curr...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@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: harder and harder to avoid pkg

[Alfred Perlstein]

Has anyone actually looked/asked how other OS's solve this problem?

I too found "xxx-dev" vs "xxx-lib" annoying until I realized how clean 
it actually is.


We should definitely be surveying the landscape before rolling our own 
NIH solution.


-Alfred

On 10/14/16 8:30 AM, Julian Elischer wrote:

On 14/10/2016 4:27 AM, Matthieu Volat wrote:

On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier  wrote:


2016-10-14 11:22 GMT+02:00 Baptiste Daroussin :

It is imho doable in both sides.

We could imagine tagging the plist/manifest so pkg can allow a user 
to install
only the things tagged as runtime for exemple which would do the 
job. for what
Julian is asking for beside adding lots of complexity pkg(8) and 
adding a

nightmare in the solver.

That would "please" the people that want "hey keep the giant flat 
package as it
is better for dev given I don't have to install the -devel version 
something"

and the people wanting fine grain selection if they need to.

But on the ports side that would be a nightmare having to tag all 
the plist (and

this cannot be automated because there are to many corner cases.

IIRC, rpm builders have script that automate this by finding files in
standard directories. Probably by checking in the stage a include/
directory and "tag" it as the development part.
Unless things changed very recently, not quite : you have to pile 
subpackage declaration and files sections according to the 
subpackages you create. The only things it has to ease the burden is 
you can use wildcard patterns to select files.



It will be the most smart way of doing this but still require some
addition to pkg. Probably like:

- pkg install mylib
- pkg install -t dev mylib
- pkg install -t runtime mylib
- pkg install -t dev,runtime,doc mylib

Just thinking ;)
More options, then more options to `pkg info` to get what was 
installed when something cannot build, then more pkg search options 
and manpage because more "-t" flags will be added and we don't know 
what's needed?



I'm glad people are at least thinking about it...

I don't think there are so many categories.  Are we installing onto a 
development machine, user machine, or an appliance? appliances don't 
need man pages. User machines need man pages for programs but not for 
libraries and developer machines.. everything..



___
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-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: harder and harder to avoid pkg

[Alfred Perlstein]

I feel like creative use of run/build-depends would work but I'm a bit tired 
now. Well you probably don't want any or near zero deps down a library depends 
path. 

Sent from my iPhone

> On Oct 11, 2016, at 10:08 PM, Julian Elischer <jul...@freebsd.org> wrote:
> 
>> On 11/10/2016 5:34 PM, Alfred Perlstein wrote:
>> Make a slave port with an abbreviated pkg-plist bruh. ;)
> yeeess, good idea, but that won't satisfy the dependency requirements of 
> other packages... you need to fool other packages, and that's the hard part. 
> The way to do this is I think for pkg to have the ability to have two 
> manifests.
> 
> We are doing similar to what Roger says, but it's just so much work...
> 
>> 
>> -Alfred
>> 
>> 
>>> On 10/11/16 11:59 AM, Julian Elischer wrote:
>>> As the number of dependencies between packages get ever higher, it becomes 
>>> more and more difficult to compile packages and the dependence on binary 
>>> precompiled packages is increased. However binary packages are unsuitable 
>>> for some situations.  We really need to follow the lead of some of the 
>>> Linux groups and have -runtime and -devel versions of packages, OR  we what 
>>> woudlbe smarter, woudl be to have several "sub manifests" to allow 
>>> unpacking in different environments.
>>> 
>>> 
>>> A simple example:   libxml2
>>> 
>>> This package installs include files and libraries and dicumentation etc.
>>> 
>>> yet if I build an appliance , I want it to only install a singe file.
>>> 
>>> /usr/local/lib/libxml2.so.2
>>> 
>>> 
>>> The presence of this file will satisfy any runtime dependencies of packages 
>>> that require it.
>>> 
>>> Unfortunately there is no way to install just this file, and still report 
>>> that we have the package loaded, so
>>> 
>>> pkg will always try to reinstall it leading to a huge mess.
>>> 
>>> My current scheme is to unpack all packages into a larger staging area, and 
>>> *manually* (scripted) copy out only the files I need, and then copy the pkg 
>>> database, so that when run on the running appliance, pkg THINKS all the 
>>> packages are loaded on the appliance, even though only the runtime files 
>>> are installed. This is what we in the industry call "a hack"  :-) It is 
>>> also not robust in the face of changing pkg versions.
>>> 
>>> It would be a lot better it pkg knew it was being asked to install only the 
>>> runtime set, and coudl accurately  store this information in its database, 
>>> allowing it to satisfy the needs of other packages that need that 
>>> dependnency only in a runtime manner.
>>> 
>>> Is any of this possible at the moment?
>>> 
>>> suggestions from the ports/pkg community are appreciated..
>>> 
>>> Julian
>>> 
>>> 
>>> ___
>>> 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-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: harder and harder to avoid pkg

[Alfred Perlstein]

Make a slave port with an abbreviated pkg-plist bruh.  ;)

-Alfred


On 10/11/16 11:59 AM, Julian Elischer wrote:
As the number of dependencies between packages get ever higher, it 
becomes more and more difficult to compile packages and the dependence 
on binary precompiled packages is increased. However binary packages 
are unsuitable for some situations.  We really need to follow the lead 
of some of the Linux groups and have -runtime and -devel versions of 
packages, OR  we what woudlbe smarter, woudl be to have several "sub 
manifests" to allow unpacking in different environments.



A simple example:   libxml2

This package installs include files and libraries and dicumentation etc.

yet if I build an appliance , I want it to only install a singe file.

/usr/local/lib/libxml2.so.2


The presence of this file will satisfy any runtime dependencies of 
packages that require it.


Unfortunately there is no way to install just this file, and still 
report that we have the package loaded, so


pkg will always try to reinstall it leading to a huge mess.

My current scheme is to unpack all packages into a larger staging 
area, and *manually* (scripted) copy out only the files I need, and 
then copy the pkg database, so that when run on the running appliance, 
pkg THINKS all the packages are loaded on the appliance, even though 
only the runtime files are installed. This is what we in the industry 
call "a hack"  :-) It is also not robust in the face of changing pkg 
versions.


It would be a lot better it pkg knew it was being asked to install 
only the runtime set, and coudl accurately  store this information in 
its database, allowing it to satisfy the needs of other packages that 
need that dependnency only in a runtime manner.


Is any of this possible at the moment?

suggestions from the ports/pkg community are appreciated..

Julian


___
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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Is there a way to silence this warning? (Failed for virtualbox-ose...)

[Alfred Perlstein]

Hey folks,

I've been getting a bunch of these warnings (see below).  Would it make 
sense to either disable the build or mute warnings between major OS 
revisions for this?


I believe this is due to structure size changes between 10 and 11.  I 
tested building on a 11.x host and it's fine.


Ideas?

I can just ignore the emails as well.



 Forwarded Message 
Subject: 	[package - 101i386-default][emulators/virtualbox-ose-lite] 
Failed for virtualbox-ose-lite-4.3.38_1 in build

Date:   Thu, 21 Jul 2016 06:15:57 GMT
From:   pkg-fall...@freebsd.org
To: alf...@freebsd.org
CC: pkg-fall...@freebsd.org



You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: alf...@freebsd.org
Last committer: alf...@freebsd.org
Ident:  $FreeBSD: head/emulators/virtualbox-ose-lite/Makefile 418067 
2016-07-05 08:06:10Z alfred $
Log URL:
http://beefy5.nyi.freebsd.org/data/101i386-default/418859/logs/virtualbox-ose-lite-4.3.38_1.log
Build URL:  
http://beefy5.nyi.freebsd.org/build.html?mastername=101i386-default=418859
Log:

>> Building emulators/virtualbox-ose-lite
build started at Thu Jul 21 05:49:56 UTC 2016
port directory: /usr/ports/emulators/virtualbox-ose-lite
building for: FreeBSD 101i386-default-job-16 10.1-RELEASE-p36 FreeBSD 
10.1-RELEASE-p36 i386
maintained by: alf...@freebsd.org
Makefile ident:  $FreeBSD: head/emulators/virtualbox-ose-lite/Makefile 
418067 2016-07-05 08:06:10Z alfred $
Poudriere version: 3.1.14
Host OSVERSION: 1100116
Jail OSVERSION: 1001000

---Begin Environment---
SHELL=/bin/csh
UNAME_p=i386
UNAME_m=i386
UNAME_v=FreeBSD 10.1-RELEASE-p36
UNAME_r=10.1-RELEASE-p36
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
OPSYS=FreeBSD
ARCH=i386
LINUX_OSRELEASE=2.6.32
SAVED_TERM=
MASTERMNT=/usr/local/poudriere/data/.m/101i386-default/ref
UID=0
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=virtualbox-ose-lite-4.3.38_1
OSREL=10.1
_OSRELEASE=10.1-RELEASE-p36
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=24
PWD=/usr/local/poudriere/data/.m/101i386-default/ref/.p/pool
MASTERNAME=101i386-default
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=1001000
---End Environment---

---Begin OPTIONS List---
===> The following configuration options are available for 
virtualbox-ose-lite-4.3.38_1:
 DBUS=off: D-Bus IPC system support
 DEBUG=off: Debug symbols, additional logs and assertions
 GUESTADDITIONS=off: Build with Guest Additions
 MANUAL=off: Build with user manual
 NLS=off: Native Language Support
 PULSEAUDIO=off: PulseAudio sound server support
 PYTHON=off: Python bindings or support
 QT4=off: Build with QT4 Frontend
 R0LOGGING=off: Enable R0 logging
 UDPTUNNEL=on: Build with UDP tunnel support
 VDE=off: Build with VDE support
 VNC=on: Build with VNC support
 VPX=off: Use vpx for video capturing
 WEBSERVICE=off: Build Webservice
 X11=off: X11 (graphics) support
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--
--disable-java --passive-mesa --with-gcc="cc" --with-g++="c++" --disable-dbus 
--disable-docs --disable-pulse --disable-python --disable-qt4 --enable-vnc --disable-libvpx 
--build-headless
--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
PKG_CONFIG=pkgconf PYTHON="/usr/local/bin/python2.7" 
XDG_DATA_HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work  
XDG_CONFIG_HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work  
HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work TMPDIR="/tmp" SHELL=/bin/sh 
CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
OPENSSLBASE=/usr OPENSSLDIR=/etc/ssl OPENSSLINC=/usr/include OPENSSLLIB=/usr/lib XDG_DATA_HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work  XDG_CONFIG_HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work  
HOME=/wrkdirs/usr/ports/emulators/virtualbox-ose-lite/work TMPDIR="/tmp" NO_PIE=yes WITHOUT_DEBUG_FILES=yes WITHOUT_KERNEL_SYMBOLS=yes SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib" 
 CC="cc" CFLAGS="-O2 -pipe  -DLIBICONV_PLUG -DNO_IDEA -fstack-protector -fno-strict-aliasing"  CPP="cpp" CPPFLAGS="-DLIBICONV_PLUG"  LDFLAGS="  -fstack-protector" LIBS=""  
CXX="c++" CXXFLAGS="-O2 -pipe -DLIBICONV_PLUG -DNO_IDEA -fstack-protector -fno-strict-aliasing  -DLIBICONV_PLUG"  MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"  
BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m 555"  

Re: best way to tune ports to add a CLFAGS entry

[Alfred Perlstein]

On 6/28/16 9:52 AM, Julian Elischer wrote:
At work I am doing various cross compiles in order to make a product 
under freebsd that actually will run under a modified FreeBSD that 
runs on an appliance. We want to get away from hand rolling everything 
to leverage all teh work in getting ports working well on FreeBSD.


We have some extra syscalls and some structures have different sizes, 
so we need to compile/link agains an alternate set of 
includes/libraries and not those in /usr/include or /usr/lib.


Ideally I want to use the "--sysroot" and "-isystem" options to the 
compiler/linker or failing that, add a -I or -L entries to make it 
look at the correct includes and libraries, not those in the base system.



In many ports CFLAGS etc. are sent in via the arguments to ./configure 
or environment vars, but there are many other ports that have other 
ways to specify these.


Does the ports framework have any standard way to do this? 
LDEXTRA_ARGS or EXTRA_CFLAGS or similar?


I've looked around and can't really see anything.  Best would be a 
single file to which I could add these things but adding them to the 
environment would also work.


yours in ports ignorance..


Sounds like a decent idea to override includedirs, but I wouldn't trust 
it.  :)


Why not do what NANOBSD/FreeNAS do and compile inside a chroot (or even 
VM) with the proper includes and such installed?


It sounds like a big sledgehammer to use a chroot or a VM, but in 
reality it's MUCH safer than some port accidentally pulling something 
from the wrong /usr/include and then you spending hours, days, etc 
tracking it down.  Trust me, I've seen the fallout and it's NOT FUN!!!


For FreeNAS we made it so that you could run the FreeNAS OS (trueos) as 
the actual build server and that saved us a huge number of headaches.


If you're very, very against the idea of VM or chroot then you could 
just make /usr/include actually contain YOUR includes as you probably 
shouldn't need them otherwise on a build server.


-Alfred




-Alfred
___
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: thread-unsafety problems as spl*() ones are NOP

[Alfred Perlstein]

On 1/30/16 6:56 AM, mokhi wrote:

Hi.
in kbd.c there are many places spltty()/splx() used assuming it locks/unlocks.
though there is bug filed for this, and ive asked in #bsddev, Ive
preferred to ask and ensure it from here again.
As these functions are obsoleted now, this assumption is incorrect and
some places we have thread-unsafely which leads to security problems
(and/or for example double-free, etc)

can i use mutex/spin/lock/unlock under where assumed a lock/unlock by
using spltty()/splx() to patch it?

Thanks, Mokhi.

Sort of, you have to also make sure to understand any locks being held 
when entering the kbd.c as well as knowing how/when to drop locks using 
msleep() to make it safe.


My understanding is that kdb is locked by GIANT which is why have spls 
as nops is OK (my knowledge may be out of date), still taking out from 
under Giant would be nice as it would be one less place under Giant.


Have a go at it and post patches and let us know how it goes.

-Alfred
___
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: Anyone got RethinkDB working in FreeBSD?

[Alfred Perlstein]

On 9/12/15 2:01 AM, Kurt Jaeger wrote:

Hi!


Right now, I'm in the part where it tries to link the
build/external/v8_3.30.33.16/build/out
stuff and fails because the clang loader does not handle
liba files 8-(

The latest .shar is available at

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203043

together with a build-log at

https://opsec.eu/backup/rethinkdb-build

which shows that it fails to link the external v8. If anyone has an
idea on how to fix this ? (Bcc: to sunpoet who maintains lang/v8*).

Why do you want it to link against the external v8 port?  Seems like 
just introducing a dependency headache.


.a files work on -stable.  Did they get broken in -current?

~ % cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation:
.(02:43:28)(builder@build2)
~ % cat t.c

int
derp(int x)
{
return x*2;
}
.(02:43:37)(builder@build2)
~ % cat m.c
#include 

int derp(int);

int
main(void)
{

printf("%d\n", derp(2));

}
.(02:43:40)(builder@build2)
~ % cc -c t.c
.(02:43:48)(builder@build2)
~ % ar -r t.a t.o
.(02:43:53)(builder@build2)
~ % cc m.c t.a
.(02:43:58)(builder@build2)
~ % ./a.out
4
.(02:44:00)(builder@build2)
~ % uname -a
FreeBSD build2 10.1-BETA2 FreeBSD 10.1-BETA2 #0 df2cf31(HEAD): Tue Jul  
7 00:38:22 UTC 2015 root@build2:/usr/obj/usr/src/sys/GENERIC  amd64

.(02:44:25)(builder@build2)
~ %

___
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: USE_GITHUB and submodules

[Alfred Perlstein]

On 5/19/15 11:44 AM, Jonathan Anderson wrote:

Hi all,

Is there a mechanism for using the USE_GITHUB variable in a port that
depends on submodules? For instance, the Rust port requires an embedded
(and modified) version of LLVM, which it includes as a submodule. Right
now I'm attempting to add the following to a `post-extract` rule:

post-extract:
 cd ${WRKSRC}  \
 git init  \
 git remote add origin https://github.com/${GH_ACCOUNT}/${PORTNAME}  \
 git fetch  \
 git reset --hard ${PORTVERSION}  \
 git submodule init  \
 git submodule update --recursive

But this seems quite hackish! It would be great if submodules Just
Worked... but alternatively, is there a USE_GITHUB_URL or somesuch that
would check things out via Git instead of tarball to save me the `git
init` through `git reset` steps?



Hello,

Please just try adding an option for fetch target to do this:

post-extract:
cd ${WRKSRC}  \
git submodule update --init --recursive

You should not need all the other things such as:

post-extract:
cd ${WRKSRC}  \
git init  \
git remote add originhttps://github.com/${GH_ACCOUNT}/${PORTNAME}  \
git fetch  \
git reset --hard ${PORTVERSION}  \
git submodule init  \
git submodule update --recursive


Since submodules are based on git hashes, there should not be a security 
issue.


All that's needed is that the git ports hook for extracting needs an 
optional git submodule update --init --recursive  step added to it.


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Merging GitHub Pull Requests into Subversion using git-svn

[Alfred Perlstein]

[[ reply private ]]

On 4/25/15 12:30 AM, David Chisnall wrote:

On 23 Apr 2015, at 00:12, Craig Rodrigues rodr...@freebsd.org wrote:

While not as smooth as clicking a merge button in GitHub,
this is a valid way to accept patches submitted via GitHub pull requests,
and integrate them in our FreeBSD Subversion repo.

The merge button on GitHub does the wrong thing anyway (merges without 
fast-forward, so you end up with a tangled history), so (after the initial 
setup) the steps that I use for merging pull requests from GitHub projects are 
very similar (locally pull the branch with fast-fordward, test, push).
Not to bikeshed this, but you really almost never want a fast-forward 
commit.  The reason is that it becomes challenging to git-bisect things 
to sort out where a bad commit was.


In addition then the merge is actually one atomic commit.

Getting over viewing merge commits as messy was the final hurdle I 
faced going towards git-nirvana.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Merging GitHub Pull Requests into Subversion using git-svn

[Alfred Perlstein]

Very cool.  Glad it worked and thanks for the shout-out.

Hoping this can be automated some day.

On 4/22/15 4:12 PM, Craig Rodrigues wrote:

Hi,

Alfred Perlstein recently wrote this document for how to use
git-svn for interacting between the FreeBSD Subversion repo,
and the GitHub mirror of this repo:

https://wiki.freebsd.org/GitWorkflow/GitSvn

By following the steps in that article, step-by-step,
I was able to:

(1)  take these three GitHub pull requests from Steve Kiernan:

https://github.com/freebsd/freebsd/pull/26
https://github.com/freebsd/freebsd/pull/27
https://github.com/freebsd/freebsd/pull/28

(2)  Pull them into my own git checkout of the FreeBSD src tree

(3)  Modify the commit message slightly

(4)  Use git svn dcommit to push these changes directly from my Git tree
back to the
   FreeBSD svn repo:

https://svnweb.freebsd.org/changeset/base/281844
https://svnweb.freebsd.org/changeset/base/281845
https://svnweb.freebsd.org/changeset/base/281855

While there were multiple steps involved, I just followed the steps in the
wiki article, and it *just worked*!  Thanks for writing this article,
Alfred!

While not as smooth as clicking a merge button in GitHub,
this is a valid way to accept patches submitted via GitHub pull requests,
and integrate them in our FreeBSD Subversion repo.

--
Craig
___
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


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: BIND REPLACE_BASE option

[Alfred Perlstein]

On 1/9/15 5:42 AM, Mathieu Arnold wrote:

+--On 8 janvier 2015 19:44:09 -0800 Doug Barton do...@dougbarton.us wrote:
| Can you please explain why this option was removed? It's been in the
| ports for over 13 years, and lots of users utilized it.
|
| I realize that BIND is no longer in the base in 10.x, but that would
| be a reason to make the option conditional, to continue to support the
| substantial user base that is still on 8.x and 9.x.

I only removed it from bind99, it was never there in bind910.  I removed it
because it was a poor design idea to begin with, and it was making the port
harder to maintain.  Also, it was overwriting files in the base system,
which is a thing we do not want to do.

All you need to do is add:

named_program=/usr/local/sbin/named

to your rc.conf, like the message says when you install the port.

It was a bit like the /usr/bin/perl symlink, it was time for it to go.

And on the 8395th day the ports team looked at the OS and declared it 
clean, and it was without users and their cumbersome legacy requirements 
and they rejoiced for now they could do all they needed any wanted.


And it was implemented in shell, C, and make just like the first day and 
no one was bothered by change, except the users.


And there was some rejoicing (not too much as honestly most of the users 
left) and it was good.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: biber missing

[Alfred Perlstein]

On 1/11/15 3:39 AM, Marek Rudnicki wrote:

Hi,

I was trying to use Biber (BibTeX replacement for users of biblatex,
with full Unicode support), but I was unable to find it.

I was wandering, why is it not present in one of the texlive packages?
Or is it hidden somewhere and I'm not able to find it?


I have those packages installed:

texlive-base-20140525_5
texlive-docs-20140525
texlive-full-20140525_1
texlive-infra-34227_1
texlive-texmf-20140525_4


This subject line had me thinking something else entirely had happened.

Anyhow, this is all I could find:
~/git/ports_worktree/textproc % find .. -name pkg-plist | xargs grep -i 
'biber' | grep -v libiber

grep: ../ports-mgmt/pkg-plist: Is a directory
../print/texlive-docs/pkg-plist:%%TEXMFDISTDIR%%/doc/bibtex/biber/biber.pdf
../print/texlive-docs/pkg-plist:%%TEXMFDISTDIR%%/doc/latex/biblatex-juradiss/biber.conf
../print/texlive-docs/pkg-plist:%%TEXMFDISTDIR%%/doc/latex/dickimaw/src/thesis/pictures/bibertool.png
../print/texlive-docs/pkg-plist:%%TEXMFDISTDIR%%/doc/latex/logreq/examples/05-biblatex+biber.run.xml
../print/texlive-docs/pkg-plist:%%TEXMFDISTDIR%%/doc/latex/logreq/examples/05-biblatex+biber.tex
../print/texlive-texmf/pkg-plist:%%TEXMFDISTDIR%%/scripts/arara/rules/biber.yaml
../print/texlive-texmf-source/pkg-plist:%%TEXMFDISTDIR%%/source/bibtex/biber/Changes
../print/texlive-texmf-source/pkg-plist:%%TEXMFDISTDIR%%/source/bibtex/biber/biblatex-biber.tar.gz
../print/texlive-texmf-source/pkg-plist:%%TEXMFDISTDIR%%/source/bibtex/biber/utf8-macro-map.html

Probably not helpful, but hope it is!

-Alfred
___
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

poudriere: bulk.sh: cpdup: Permission denied

[Alfred Perlstein]

Hey folks, I'm trying to get started with poudriere.  I pulled from the 
latest version 3.1.1 (9f9e43d3).


However I'm getting the following error:


build2# env  ZPOOL=zroot ZROOTFS=/ports \
  GIT_URL=http://gitweb.norse-data.com/git/ports.git \
  ./src/bin/poudriere bulk \
  -f  test_pkg_list -j poudriere-appliance
[00:00:00]  Creating the reference jail... done
[00:00:01]  Mounting system devices for poudriere-appliance-default
[00:00:01]  Mounting ports/packages/distfiles
[00:00:01]  Using packages from previously failed build
[00:00:01]  Mounting packages from: 
/usr/local/poudriere/data/packages/poudriere-appliance-default
/etc/resolv.conf - 
/usr/local/poudriere/data/.m/poudriere-appliance-default/ref/etc/resolv.conf

[00:00:01]  Starting jail poudriere-appliance-default
/usr/home/alfred/poudriere/src/share/poudriere/bulk.sh: cpdup: 
Permission denied

[00:00:01]  Cleaning up
[00:00:01]  Umounting file systems
build2#

Is there a way to get line numbers or stack trace or any help debugging 
this issue?  grep -r for cpdup hasn't been helpful.


I guess I can truss(1)?  (set -x isn't very helpful)
Is there some magic I can put into PS4 so I can get file:line in the 
set -x output?  Or is shell just ... limited?


Other ideas on sorting out why this is happening?

JFYI: here are my notes so far (there are patches to use git(1) as a 
FreeBSD source tree):


env ZPOOL=zroot ZROOTFS=/ports ./src/bin/poudriere jail -j 
poudriere-appliance -m git+http -b master -U 
gitweb.norse-data.com/git/trueos.git -c -v TrueOS


# make a default ports tree, makes things go easier
env \
  ZPOOL=zroot ZROOTFS=/ports \
  GIT_URL=http://gitweb.norse-data.com/git/ports.git \
  ./src/bin/poudriere ports -c

# make the freebsd chroot for building using git, patches here 
https://github.com/splbio/poudriere/tree/3.1.1-git

env \
  ZPOOL=zroot ZROOTFS=/ports \
  GIT_URL=http://gitweb.norse-data.com/git/ports.git \
  ./src/bin/poudriere ports -c -p poudriere-appliance-ports -m git -B 
master


# start the jail with the ports tree now...
env ZPOOL=zroot ZROOTFS=/ports ./src/bin/poudriere jail -s -p 
poudriere-appliance-ports -j poudriere-appliance


# now build?
env \
  ZPOOL=zroot ZROOTFS=/ports \
  GIT_URL=http://gitweb.norse-data.com/git/ports.git \
  ./src/bin/poudriere bulk \
  -f  test_pkg_list -j poudriere-appliance



Thanks all,
-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: poudriere: bulk.sh: cpdup: Permission denied

[Alfred Perlstein]

Thanks Craig. 

Replies below. 

 On Dec 15, 2014, at 12:21 PM, Craig Rodrigues rodr...@freebsd.org wrote:
 
 
 
 On Mon, Dec 15, 2014 at 10:20 AM, Alfred Perlstein alf...@freebsd.org 
 wrote:
 Hey folks, I'm trying to get started with poudriere.  I pulled from the 
 latest version 3.1.1 (9f9e43d3).
 
  
 
 /usr/home/alfred/poudriere/src/share/poudriere/bulk.sh: cpdup: Permission 
 denied
 
 cpdup is a binary (not shell script) which gets installed as part of the 
 poudriere distribution.
 It looks like you haven't got it installed right in your setup.
 I advise you to install the poudriere-devel port instead of pulling poudriere 
 directly from git and building it.

That won't work as I'm doing development on poudriere. 

 
 The other thing I would recommend that you do is to check out the freebsd10 
 branch
 from https://github.com/freenas/freenas repository, and build it once.  Then 
 look at:'
 
 https://github.com/freenas/freenas/tree/freebsd10/build/ports
 https://github.com/freenas/freenas/blob/freebsd10/build/ports/build-ports.sh
 
 to see how poudriere is invoked to build the ports in FreeNAS.

Will do, thanks for the pointer. 
 
 
 If you want to enable tracing in poudriere, then use -x as the first flag 
 write after poudiere.  For example:
 
 poudriere -x bulk 

Yup, done that already.

Problem is that Bourne shell debugging is terrible. -x does not give line 
numbers, nor functions, nor files. 

Spent some time trying to do things using PS4 variable but it was for naught 
because $LINENO and $0 don't work properly in PS4 as far as I can tell in our 
version of Bourne shell. Bash on the other hand seems to have better support 
for expanding useful things into PS4, however it's still very poor as compared 
to the facilities of let's say Python or Ruby or probably even Javascript. 

I hear now that poudriere is being migrated to C of all things which IMO is a 
huge mistake. Almost as bad as having it in shell. 

As someone that would *like* to contribute to poudriere, (see my github which 
has patches already) I'm hoping the maintainers can look at using a high level 
language that offers debugging as well as built in string safety as opposed to 
going to an even more low level system. Moving to C would make that just more 
pain than it seems worth. 

-Alfred. 


 
 --
 Craig 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Fwd: [Differential] [Request, 172 lines] D1154: Support for git svn propset.

[Alfred Perlstein]

Would like to add support for svn propset to our git port.

Makes git-svn more usable for FreeBSD development.

https://reviews.freebsd.org/D1154

thank you,
-Alfred


 Original Message 
Subject: 	[Differential] [Request, 172 lines] D1154: Support for git svn 
propset.

Date:   Thu, 13 Nov 2014 09:18:02 +
From:   alfredperlstein (Alfred Perlstein) phabric-nore...@freebsd.org
To: alf...@freebsd.org



alfredperlstein created this revision.
alfredperlstein added reviewers: bapt, bdrewery.

REVISION SUMMARY
  From: https://github.com/splbio/git/tree/v2.1.2-git-svn-propset

BRANCH
  git_add_svnpropset

REVISION DETAIL
  https://reviews.freebsd.org/D1154

AFFECTED FILES
  devel/git/files/patch-git-svn.perl
  devel/git/files/patch-perl_Git_SVN_Editor.pm

To: alfredperlstein, bapt, bdrewery



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Reducing the size of the ports tree (brainstorm v2)

[Alfred Perlstein]

On 11/2/14, 10:50 AM, Tijl Coosemans wrote:

On Sun, 2 Nov 2014 18:16:23 + RW rwmailli...@googlemail.com wrote:

On Sat, 1 Nov 2014 00:07:23 +0100
Tijl Coosemans wrote:

On Fri, 31 Oct 2014 19:56:21 +0100 Baptiste Daroussin
b...@freebsd.org wrote:

tijl@ spotted an interesting point, distinfo and pkg-descr files
files convenient are taking a lot of space for free, we can
reduce the size of the while ports tree by a factor 2 by simply
merging them into one of the other files (Makefile and/or
pkg-plist) from my testing it really devides significantly the size
of the tree.

Problem is how to merge them if we want to.

What we do not want to loose:
- Easyness of parsing distinfo
- Easyness to get informations about the description

I think it's worth remembering that this saves an amount of storage
that can be had for around 1 penny/cent. The threshold for this being
more trouble than it's worth is pretty low.

The reason I looked into this is because many subversion operations
are slow on the ports tree.  For me it's about saving time there and
not so much about saving disk space.
Starting to think that we should think about making the ports into trees 
that are category based and then another directory for the .mk files.


Subversion supports externals, git supports submodules.

Maybe it's time to leverage those and have a top level project with 
svn externals or git submodules.


-Alfred


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Reducing the size of the ports tree (brainstorm v2)

[Alfred Perlstein]

On 10/31/14, 11:56 AM, Baptiste Daroussin wrote:

Hi all,

tijl@ spotted an interesting point, distinfo and pkg-descr files files
convenient are taking a lot of space for free, we can reduce the size of the
while ports tree by a factor 2 by simply merging them into one of the other
files (Makefile and/or pkg-plist) from my testing it really devides
significantly the size of the tree.

Problem is how to merge them if we want to.

What we do not want to loose:
- Easyness of parsing distinfo
- Easyness to get informations about the description

so far I have not been able to figure out a user friendly way

Ideas I got so far only concerns pkg-descr:
Adding an entry in the Makefile for the WWW:
WWW= bla
or an entry in the plist: @www http...

for the description the Makefile is not suitable as multi line entry in
Makefiles are painful
Maybe a new keyword:
@descr EOD
mydesc
in
multiline
EOD

which could easily be added to the plist parser in pkg. But I'm do not find that
very friendly in particular for make(1) to extract the data.

Concerning the distinfo I have no idea.

so this mail is a call of ideas :), if nothing nice ideas is found we will just
do nothing here :)

regards,
Bapt


Have you asked sjg about enhancing our make(1) to make HEREDOCs inside 
makefiles cleaner/nicer?


That would be best idea imo.  Then you could get rid of multiple files 
and merge into makefiles.  Maybe even eventually the patchfiles as well.


I had some basic thoughts on this, one trick would be to do like 
perl(1)'s DATA section of scripts.

http://stackoverflow.com/questions/13463509/the-data-syntax-in-perl

Other option is to make a separate shar(1)-like file to contain all meta 
data and add targets to deterministically create/delete this file, this 
file could include patches, description, plist and everything.  In fact 
it could contain the makefile itself...


Just some random thoughts that may/may-not find useful.

-Alfred
___
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

question about option files + graphics/cairo

[Alfred Perlstein]

Hey folks,

We are building ports via, I tried adding the build of cairo BOTH:

make WITHOUT+=X11 OPTIONS_FILE_UNSET+=X11

however that doesn't seem to work and it's still pulling in X11 it seems:

pkg: Missing dependency matching Origin: 'x11/libXext' Version: 
'1.3.2_2,1'
Failed to install the following 1 package(s): cairo-1.12.16_1,2.txz


Is there a way to fix this?  this is ports tree pulled as of October 21.

Would like to not require extra x11 libs if at all possible.

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [HEADSUP] The ports tree is now stage only

[Alfred Perlstein]

On 9/1/14 2:27 AM, Baptiste Daroussin wrote:

Hi all,

The ports tree is now fully staged (only 2% has been left unstaged, marked as
broken and will be removed from the ports tree if no PR to stage them are
pending in bugzilla).

I would like to thank every committer and maintainers for their work on staging!
It allowed us to convert more than 23k packages to support stage in only 11
months!

Staging is a very important state, it allows us to right now be able to run
quality testing scripts on the packages (which already allowed to fix tons of
hidden problems)


This is all so cool, but so very excited about this:

  and it allows use to be able to build packages as a regular
user!

yes yes yes!!  Huge step forward to freebsd adoption!



It also opens the gates to new features that users have been requesting for many
years:
- flavors
- multiple packages

Expect those features to happen in the near future.

Best regards,
Bapt on behalf of portmgr



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: I want to upgrade an old (8.3-RC2) FReeBSD installation, but can't install subversion

[Alfred Perlstein]

On 8/26/14 5:22 PM, Kevin Oberman wrote:

On Tue, Aug 26, 2014 at 2:19 PM, Michelle Sullivan miche...@sorbs.net
wrote:


And this is precisely why I think the killing of the old packaging
system on Sept 1, is the wrong thing to do.

If you don't have the new packaging system installed and setup by then,
you're screwed... royally...

Happened somewhere between 6.x and 7.x with the ports tree, pre 8.4...
the list goes on

FWIW Torfinn, get a amd64, 8.4 make binary (from the install disk) and
manually copy it over (just /usr/bin/make ) backing up the original first.

You'll find the ports tree will then work... well until Sept 1 when all
hell breaks loose if you use anything but the quarterly SVN tree...
and then you'll have 90 days more..

Michelle

Torfinn Ingolfsen wrote:

I have a machine which has an old installation of FreeBSD 8.3 on it:
root@kg-vm2# uname -a
FreeBSD kg-vm2 8.3-RC2 FreeBSD 8.3-RC2 #0: Sat Mar 24 16:15:47 UTC
2012 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64

and I want to update it. Since FreeBSD this old doesn't have svnlite
installed, I fetch a ports tree (no, this machine didn't have one
already) and try to install the subversion port:
root@kg-vm2# cd /usr/ports/devel/subversion
root@kg-vm2# make install
Unknown modifier 't'

/usr/ports/Mk/bsd.port.mk, line 1727: Malformed conditional
(defined(USE_RC_SUBR)  ${USE_RC_SUBR:tu} != YES)
Unknown modifier 't'

Unknown modifier 't'

Unknown modifier 't'

/usr/ports/Mk/bsd.sites.mk, line 956: Malformed conditional
(!empty(_PERL_CPAN_ID)  ${_PERL_CPAN_FLAG:tl} == cpan)
Unknown modifier 't'

Unknown modifier 't'

/usr/ports/Mk/bsd.port.mk, line 2858: Unclosed conditional/for loop
/usr/ports/Mk/bsd.port.mk, line 2858: Unexpected end of file in for

loop.

/usr/ports/Mk/bsd.port.mk, line 6574: Unclosed conditional/for loop
/usr/ports/Mk/bsd.port.mk, line 6574: Unexpected end of file in for

loop.

make: fatal errors encountered -- cannot continue

So I google a bit and find this[1] thread.
Hmm, ok let's try to install bmake then:
root@kg-vm2# cd /usr/ports/devel/bmake
root@kg-vm2# make install
Unknown modifier 't'

Unknown modifier 't'

Unknown modifier 't'

Unknown modifier 't'

Unknown modifier 't'

/usr/ports/Mk/bsd.sites.mk, line 956: Malformed conditional
(!empty(_PERL_CPAN_ID)  ${_PERL_CPAN_FLAG:tl} == cpan)
Unknown modifier 't'

Unknown modifier 't'

/usr/ports/Mk/bsd.port.mk, line 2858: Unclosed conditional/for loop
/usr/ports/Mk/bsd.port.mk, line 2858: Unexpected end of file in for

loop.

/usr/ports/Mk/bsd.port.mk, line 6574: Unclosed conditional/for loop
/usr/ports/Mk/bsd.port.mk, line 6574: Unexpected end of file in for

loop.

1 open conditional:
  at line 1167 (evaluated to true)
make: fatal errors encountered -- cannot continue

Now, can anyone explain to me how I am going to get an updated source
(/usr/src) onto this machine, without resorting to (to me, totally
unnecessary) unconventional steps?

AFAICT, there is nothing in /usr/ports/UPDATING about this.
So much for POLA.
Bah.

References:
1) https://forums.freebsd.org/viewtopic.php?f=5t=46291#p258936



--
Michelle Sullivan
http://www.mhix.org/



While I understandthe need to get rid of the old system, three needs ot be
a clear path for those wanting ot update old versions. I hit this yesterday
trying to upgrade a 9.0-RC2 system and it was a real pain.

Can't just do a checkout on an older machine and tar/rsync it over?

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Way to make settings in /etc/make.conf effective only for ports

[Alfred Perlstein]

On 6/22/14, 12:49 AM, Yasuhiro KIMURA wrote:

Hello.

Recently I found some of settings for ports in /etc/make.conf
interfere with other software project. So are there any way to make
settings in /etc/make.conf effective only for ports?

Best Regards.

I think you can use /usr/local/etc/ports.conf

I got that information from:

http://lists.freebsd.org/pipermail/freebsd-ports/2007-April/040338.html

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Way to make settings in /etc/make.conf effective only for ports

[Alfred Perlstein]

On 6/22/14, 2:20 AM, Melvyn Sopacua wrote:

Hi Yasuhiro,

On Sun, 22 Jun 2014, Yasuhiro KIMURA wrote:


Recently I found some of settings for ports in /etc/make.conf
interfere with other software project. So are there any way to make
settings in /etc/make.conf effective only for ports?


You can wrap those settings in .CURDIR check:
.if !empty(.CURDIR:M/usr/ports/*)
# port settings here
.endif


What about using a check for ../../Mk/bsd.ports.mk or ../Mk/bsd.ports.mk ?


Alternatively, you can make a different file, say /etc/make.ports.conf
and then build ports with the environment variable __MAKE_CONF set to
it.
--
Melvyn
___
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



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Who was the mental genius

[Alfred Perlstein]

On 6/5/14, 11:35 PM, John Marino wrote:

On 6/6/2014 05:37, Paul Schmehl wrote:

Something like that would have been more than adequate.  As I pointed
out, the warning you get about pkgng and the 9/1/2014 deadline is
perfect.  It's been there for a couple of months, and it pops up ever
time you do a port. If you miss that and don't convert, you don't have
anyone but yourself to blame.

Which is exactly the same case with you and the 8.3 EOL.
If your business relies involves server maintenance, it's entirely your
responsibility to track EOL.  How somebody with senior in their job
title is looking to blame everyone else for failing something so basic
is rich.

You say semantics isn't important?   You say 8.3 isn't old?  It may
not be old compared to a dog, but it reached its published end-of-life.
  Any expectation you have about support after EOL where probably forged
by watching Microsoft support XP.  That's not the model to expect.
Install some mirrors in your house.

Sure, but really a couple of lines to warn people and wave them towards 
next steps is probably advisable next time.


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Who was the mental genius

[Alfred Perlstein]

 On Jun 6, 2014, at 10:02 AM, Warren Block wbl...@wonkity.com wrote:
 
 On Fri, 6 Jun 2014, Paul Schmehl wrote:
 
 No offense was meant.  I deliberately chose the subject to stimulate 
 discussion, which it has obviously done.
 
 Stimulating discussion without insulting people generally gives better 
 results.
 
 Look, we are all doing the best we can with what we've got.  The ports people 
 have been trying to accomplish the equivalent of turning a cruise ship around 
 in a bathtub without rattling the silverware.  It's not possible to 
 anticipate every issue, particularly when there are so many.
 
 The way improvements are made is for interested people (that is, you) to
 get involved and help to improve it.
 
 The challenge you have created is to anticipate the next issue and report it, 
 preferably with a plan for a solution, before it happens.
 

Let's not overly tone police folks. If no one can constructively criticize then 
we don't get any feedback. 

Anyone's tone can be attacked I firmly believe that Paul's tone matches the way 
we east coasters chide each other to provoke debate. 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Who was the mental genius

[Alfred Perlstein]

On 6/6/14, 7:52 PM, Mark Linimon wrote:

On Fri, Jun 06, 2014 at 04:10:03PM -0400, Jim Ohlstein wrote:

Not to get too far off topic but as a life long east coaster (except
for a short sojourn in the flatlands of Kansas), and being old
enough to know better, that is not normal east coast chiding.
Maybe that's normal northeast talk, but here in the south people
have manners.

I was going to say something along these same lines ... but to me
this message, as well, comes off a bit harsh.

I understand Paul's point even if I found the initial tone abrasive.
But I know a lot of context is lost when conversations are down-converted
to keystrokes.

Perhaps Paul can understand why, for a native southerner, seeing that
kind of Subject: line can be demotivating, especially in the light of
how hard it has been in the past to make such large changes to the
infrastructure.

Please remember folks: one person's blowing off steam can lead to
another person's why do I bother trying to fix things anyways.



Agreed.

I would like to raise one other point.  For every brash new yorker (like 
myself) that blows off steam, there are likely very many people who just 
don't complain and remain silent on issues like usability.  It important 
to be able to take the feedback apart from the obvious frustration.  We 
are after all a software project, we want users.


Another point is that it's obvious that Paul is passionate about 
FreeBSD, he is a long long long time user.  In addition he took the time 
to let us know what broke, he took the time to comment on usability, and 
it's obvious he's a huge fan of FreeBSD and that it was personally 
upsetting that he saw a usability issue that he felt would hurt the OS.


It's very obvious that Paul has a lot of love for FreeBSD otherwise he 
would have just shrugged and installed $penguin_os.  I like Paul.


I also like Bapt, I hope both can be OK and the passion and love of the 
OS can come out of this as opposed to the negatives mentioned earlier in 
the thread.


-Alfred





___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Who was the mental genius

[Alfred Perlstein]

On 6/5/14, 7:32 PM, Paul Schmehl wrote:
--On June 5, 2014 at 11:50:38 PM +0200 Guido Falsi m...@madpilot.net 
wrote:



On 06/05/14 23:43, Paul Schmehl wrote:

--On June 5, 2014 at 11:18:31 PM +0200 A.J. 'Fonz' van Werven
free...@skysmurf.nl wrote:


Paul Schmehl wrote:


That decided it was a good idea to completely break ports to force
people to upgrade?  You couldn't come up with a warning system 
instead

of outright breaking ports?  The idiots are apparently running the
asylum.  {{sigh}}


It might help to know exactly what you're talking about... What is it
that
broke?



The change to make that causes this when you run pkg commands or try to
build ports:

Unknown modifier 't'

It was done deliberately to break ports so that people would be forced
to upgrade to a supported version.

https://forums.freebsd.org/viewtopic.php?f=5t=46291


No it was not done deliberately

Newer freebsd version moved to a newer make utility, and support for the
old one has been dropped after support for all old releases containing
it was ceased.



So they dropped the support accidentally?  Is this really the time to 
argue semantics?



Which releases are supported and for how long is well known, and
published in here when a new release is published:

http://www.freebsd.org/security/security.html#sup

The updates are free, as in no payment needed. What's keeping you from
performing a binary update of the base system every year or so?



I have two hosts on the internet for which the backup system failed.  
I didn't catch it right away, so now I'm several days behind on 
backups.  I need to install a new system, but it requires ports I 
don't yet have installed.  So now I have two options; upgrade with my 
fingers crossed and hope it works or scramble to find some way to 
backup before I upgrade just in case the upgrade fails.



Running such an old system as any of the unsupported releases is also
most probably exposing you to security vulnerabilities.



First of all, 8.3 is not an old system.  Secondly, you used to be able 
to run old systems for a long time after support was dropped without 
encountering issues like this.  Finally, I'm a port maintainer of a 
fair number of ports, so FreeBSD isn't free for me.  I put a lot of 
time into it.


When such a drastic change is made, it should be well advertised in 
advance (think the pkgng announcement you get every time you install a 
port) and not implemented in such a disruptive manner. It's clear from 
the forum announcement that I linked to that I was not the only one 
caught by surprise and that it didn't even work on supported versions 
when the change was first implemented.



Sometimes to change things you need to break compatibility, the project
did wait till it was coherent with what was promised before doing this.



What you call the project is made up of people.  SOMEONE should be 
thinking through the impact on end users and helping to plan such 
major transitions in a way that's least disruptive IF you want the 
system to remain viable.


Perhaps this is part of the reason adoption of FreeBSD has dropped so 
dramatically over the years.  I'm retiring in 18 months.  When I 
leave, the last FreeBSD system goes with me.  No one is even 
interested in learning it any more.  FreeBSD used to rule the web.  
Now it's Linux.  There's a lesson in there for those that are 
listening, but apparently the project is not. Which is sad, because 
FreeBSD, IMNSHO, is a very good OS.


There's no need to respond to this.  I'm just venting.  And clearly my 
opinion doesn't matter anyway.

I think your opinion matters.

I agree I would be rudely surprised by such a breakage myself.  That 
said we need to find a way to desupport things eventually.


Any ideas on what should have been done that can be done in a short 
amount of code as possible?  Perhaps there's some way to determine 
between the old and new makes and just add some kind of target like:


# psuedo make(1) code:
.ifndef THIS_IS_NEW_MAKE
.BEGIN:
   echo your system is running an unsupported version of FreeBSD the 
last version to support this is r232423
   echo please run svn update -r232423 to get a working ports tree as 
of that date or upgrade to a more recent
   echo freebsd release using freebsd-update [[insert link to 
freebsd-update]]

   exit 1
.endif

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla

[Alfred Perlstein]

 On Jun 4, 2014, at 6:51 AM, Ed Maste ema...@freebsd.org wrote:
 
 On 4 June 2014 06:34, Darren Pilgrim list_free...@bluerosetech.com wrote:
 
 Requiring oauth will literally guarantee me and a whole bunch of other
 people will never have bugzilla accounts.
 
 I don't think anyone's suggesting oauth would be required.  It would
 just be available as an alternate method for those who don't want to
 create a bugzilla-specific account.

Exactly. Thank you Ed. 

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla

[Alfred Perlstein]

On 6/4/14, 9:12 AM, Gary J. Hayers wrote:

On 04/06/2014 11:34, Darren Pilgrim wrote:

Requiring oauth will literally guarantee me and a whole bunch of other
people will never have bugzilla accounts.


I don't understand what the problem with logging in is? It surely is a 
small price to pay for a secure modern bug tracking system?



Some people just want to watch FreeBSD burn...

https://www.youtube.com/watch?v=efHCdKb5UWc

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla

[Alfred Perlstein]

On 6/3/14, 5:16 AM, David Chisnall wrote:

On 3 Jun 2014, at 13:09, Vitaly Magerya vmage...@gmail.com wrote:


It doesn't seem to be possible to post comments (or bugs) without creating an 
account and logging in.

That is correct.  The current leaning is towards not providing such 
functionality as:

- It makes spamming easy

- If someone can't be bothered to make an account, they are unlikely to provide 
the feedback required to correctly diagnose the bug.

I don't know that this decision is final, but it's certainly unlikely to be 
high up the priority list to implement it.  For FreeBSD 11, we'd like to have 
an HTTP-based send-pr replacement, which will not be able to enforce a valid 
email address, but which will at least request one.  Although, again, we'll 
have to be careful to prevent it from being used as a spam tool (send a pr 
claiming to be from a different email address with a spam message and that 
person gets notified) and so it will likely add the bug to a private queue 
where it can be checked for spam before appearing in the main db.  Volunteers 
to be spam filters welcome...
I think a bunch of this can be solved by using oauth or something like 
it.  aka: login via github or facebook/twitter.


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: [FreeBSD-Announce] FreeBSD bug tracking moves from GNATS to Bugzilla

[Alfred Perlstein]

 On Jun 3, 2014, at 8:23 AM, Michelle Sullivan miche...@sorbs.net wrote:
 
 Alfred Perlstein wrote:
 
 On 6/3/14, 5:16 AM, David Chisnall wrote:
 On 3 Jun 2014, at 13:09, Vitaly Magerya vmage...@gmail.com wrote:
 
 It doesn't seem to be possible to post comments (or bugs) without
 creating an account and logging in.
 That is correct.  The current leaning is towards not providing such
 functionality as:
 
 - It makes spamming easy
 
 - If someone can't be bothered to make an account, they are unlikely
 to provide the feedback required to correctly diagnose the bug.
 
 I don't know that this decision is final, but it's certainly unlikely
 to be high up the priority list to implement it.  For FreeBSD 11,
 we'd like to have an HTTP-based send-pr replacement, which will not
 be able to enforce a valid email address, but which will at least
 request one.  Although, again, we'll have to be careful to prevent it
 from being used as a spam tool (send a pr claiming to be from a
 different email address with a spam message and that person gets
 notified) and so it will likely add the bug to a private queue where
 it can be checked for spam before appearing in the main db. 
 Volunteers to be spam filters welcome...
 I think a bunch of this can be solved by using oauth or something like
 it.  aka: login via github or facebook/twitter.
 
 I for one would be highly opposed to it (facebook/twitter etc login) ...
 3-4 years ago I went through 7 facebook accounts because of a vindictive
 little psycho kept reporting all my posts and accounts as abusive
 specifically to cause Facebook to delete my account...  This then
 blocked the email address and telephone number from being used elsewhere
 and I lost several associated accounts as a result - including paid for
 services.  I will never use such again, even a court order didn't get
 the (original) account reinstated or compensated.
 
 As for spamming, there are solutions - some make it more difficult than
 creating an account and logging in.  That said I've had my fair share of
 spam through (verified email) logins... there is no easy solution, only
 less painful ones. :/
 
 A tool that resides in the base OS for sending bug reports would be a
 good idea - even better if the tool reports basic OS parameters (uname
 -a, and an OS unique token) and the connecting IP (as seen by the
 receiving server) so that spammers cannot abuse it or be easily blocked.
 
 Just my $0.02
 
 Michelle
 (from SORBS)
 
 -- 
 Michelle Sullivan
 http://www.mhix.org/
 

All of those parameters can easily be faked. Not sure how that would help. 

I still think using a form of oauth might help. 

Other options are email registration that results in an API key that those 
command line apps can use. That API key can be revoked by the bugzilla admins 
if needed.  
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: virtualbox-ose cannot compile

[Alfred Perlstein]

On 6/1/14 8:57 AM, Wojciech Puchar wrote:


kBuild: Compiling VBoxOGLhosterrorspu - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/GuestHost/OpenGL/e

rror/errorspu_init.c
kBuild: Compiling VBoxVNCMain - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNCMain.c

pp
kBuild: Compiling VBoxVNC - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNC.cpp
kBuild: Compiling VBoxRemPrimary - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/VBoxRecompiler.c

kmk: gcc: Command not found
kmk: *** 
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o] 
Error 127

The failing command:
@gcc -c -O2 -g -pipe -Wall -Wextra -Wno-missing-field-initializers 
-Wno-unused -Wno-trigraphs -fdiagnostics-show-option 
-Wno-unused-parameter -Wno-long-long -Wno-long-long 
-Werror-implicit-function-declaration -Wno-variadic-macros -O2 
-mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing 
-fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN 
-DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-sign-compare 
-Werror-implicit-function-declaration -m64 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun/crt 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/target-i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/fpu 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/VMM/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg/i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler 
-I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/dtrace 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release 
-DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_DEBUGGER 
-DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ 
-DVBOX_WITH_HARDENING 
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ 
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ 
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ 
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DIN_RING3 
-DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DPIC -DIN_REM_R3 
-DREM_INCLUDE_CPU_H -DNEED_CPU_H -DVBOX_WITH_RAW_MODE 
-DVBOX_WITH_RAW_RING1 -DLOG_USE_C99 -D_BSD -D__x86_64__ 
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o.dep 
-Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o 
-Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox



if gcc is needed, and is not specified in dependencies please tell me 
what gcc in /usr/ports/lang should i install


or maybe - how to install gcc from base system as it is no longer 
compiled by default with make buildworld


FreeBSD s1.3miasto.net.pl 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Tue 
Apr  8 14:01:53 CEST 2014 
r...@s1.3miasto.net.pl:/usr/src/sys/amd64/compile/s1  amd64




Please try adding:
USE_GCC=yes
to the Makefile for the port.

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: virtualbox-ose cannot compile

[Alfred Perlstein]

On 6/1/14, 11:00 AM, Wojciech Puchar wrote:

 [root@s1 /usr/ports/emulators/virtualbox-ose]# make USE_GCC=yes
===  virtualbox-ose-4.3.12_1 Unknown version of GCC specified 
(USE_GCC=yes).


more options needed?


Maybe try USE_GCC=any or something like USE_GCC=4.8+ is what I am 
seeing in other ports.






On Sun, 1 Jun 2014, Alfred Perlstein wrote:


On 6/1/14 8:57 AM, Wojciech Puchar wrote:


kBuild: Compiling VBoxOGLhosterrorspu - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/GuestHost/OpenGL/e

rror/errorspu_init.c
kBuild: Compiling VBoxVNCMain - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNCMain.c

pp
kBuild: Compiling VBoxVNC - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNC.cpp
kBuild: Compiling VBoxRemPrimary - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/VBoxRecompiler.c

kmk: gcc: Command not found
kmk: *** 
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o] 
Error 127

The failing command:
@gcc -c -O2 -g -pipe -Wall -Wextra -Wno-missing-field-initializers 
-Wno-unused -Wno-trigraphs -fdiagnostics-show-option 
-Wno-unused-parameter -Wno-long-long -Wno-long-long 
-Werror-implicit-function-declaration -Wno-variadic-macros -O2 
-mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing 
-fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN 
-DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-sign-compare 
-Werror-implicit-function-declaration -m64 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun/crt 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/target-i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/fpu 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/VMM/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg/i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler 
-I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/dtrace 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release 
-DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_DEBUGGER 
-DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ 
-DVBOX_WITH_HARDENING 
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ 
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ 
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ 
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DIN_RING3 
-DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DPIC -DIN_REM_R3 
-DREM_INCLUDE_CPU_H -DNEED_CPU_H -DVBOX_WITH_RAW_MODE 
-DVBOX_WITH_RAW_RING1 -DLOG_USE_C99 -D_BSD -D__x86_64__ 
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o.dep 
-Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o 
-Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox



if gcc is needed, and is not specified in dependencies please tell 
me what gcc in /usr/ports/lang should i install


or maybe - how to install gcc from base system as it is no longer 
compiled by default with make buildworld


FreeBSD s1.3miasto.net.pl 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Tue 
Apr  8 14:01:53 CEST 2014 
r...@s1.3miasto.net.pl:/usr/src/sys/amd64/compile/s1 amd64




Please try adding:
USE_GCC=yes
to the Makefile for the port.

-Alfred
___
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



___
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



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: virtualbox-ose cannot compile

[Alfred Perlstein]

This is beyond what I can figure out.  Very sorry.

On 6/1/14, 12:37 PM, Wojciech Puchar wrote:

installed gcc48 from ports
used USE_GCC=4.8

still failed

linked /usr/local/bin/gcc48  to /usr/local/bin/gcc

it compiled now.

but fails to run
VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: 
/usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required 
by /usr/local/lib/virtualbox/VBoxRT.so not found







On Sun, 1 Jun 2014, Alfred Perlstein wrote:



On 6/1/14, 11:00 AM, Wojciech Puchar wrote:

 [root@s1 /usr/ports/emulators/virtualbox-ose]# make USE_GCC=yes
===  virtualbox-ose-4.3.12_1 Unknown version of GCC specified 
(USE_GCC=yes).


more options needed?


Maybe try USE_GCC=any or something like USE_GCC=4.8+ is what I am 
seeing in other ports.






On Sun, 1 Jun 2014, Alfred Perlstein wrote:


On 6/1/14 8:57 AM, Wojciech Puchar wrote:


kBuild: Compiling VBoxOGLhosterrorspu - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/GuestHost/OpenGL/e

rror/errorspu_init.c
kBuild: Compiling VBoxVNCMain - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNCMain.c

pp
kBuild: Compiling VBoxVNC - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNC.cpp
kBuild: Compiling VBoxRemPrimary - 
/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/VBoxRecompiler.c

kmk: gcc: Command not found
kmk: *** 
[/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o] 
Error 127

The failing command:
@gcc -c -O2 -g -pipe -Wall -Wextra -Wno-missing-field-initializers 
-Wno-unused -Wno-trigraphs -fdiagnostics-show-option 
-Wno-unused-parameter -Wno-long-long -Wno-long-long 
-Werror-implicit-function-declaration -Wno-variadic-macros -O2 
-mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing 
-fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN 
-DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-sign-compare 
-Werror-implicit-function-declaration -m64 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun/crt 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/target-i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/fpu 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/VMM/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg/i386 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler 
-I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/dtrace 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release 
-DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_DEBUGGER 
-DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ 
-DVBOX_WITH_HARDENING 
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ 
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ 
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ 
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ 
-DIN_RING3 -DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DPIC -DIN_REM_R3 
-DREM_INCLUDE_CPU_H -DNEED_CPU_H -DVBOX_WITH_RAW_MODE 
-DVBOX_WITH_RAW_RING1 -DLOG_USE_C99 -D_BSD -D__x86_64__ 
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o.dep 
-Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o 
-Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox



if gcc is needed, and is not specified in dependencies please tell 
me what gcc in /usr/ports/lang should i install


or maybe - how to install gcc from base system as it is no longer 
compiled by default with make buildworld


FreeBSD s1.3miasto.net.pl 10.0-RELEASE FreeBSD 10.0-RELEASE #0: 
Tue Apr 8 14:01:53 CEST 2014 
r...@s1.3miasto.net.pl:/usr/src/sys/amd64/compile/s1 amd64




Please try adding:
USE_GCC=yes
to the Makefile for the port.

-Alfred
___
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




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to 
freebsd-ports-unsubscr...@freebsd.org

Re: virtualbox-ose cannot compile

[Alfred Perlstein]

By the way, can you not use pkg to install it? (This is what I do)

Sent from my iPhone

 On Jun 1, 2014, at 12:53 PM, Alfred Perlstein alf...@freebsd.org wrote:
 
 This is beyond what I can figure out.  Very sorry.
 
 On 6/1/14, 12:37 PM, Wojciech Puchar wrote:
 installed gcc48 from ports
 used USE_GCC=4.8
 
 still failed
 
 linked /usr/local/bin/gcc48  to /usr/local/bin/gcc
 
 it compiled now.
 
 but fails to run
 VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
 VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: 
 /usr/local/lib/compat/libstdc++.so.6: version GLIBCXX_3.4.15 required by 
 /usr/local/lib/virtualbox/VBoxRT.so not found
 
 
 
 
 
 
 On Sun, 1 Jun 2014, Alfred Perlstein wrote:
 
 
 On 6/1/14, 11:00 AM, Wojciech Puchar wrote:
 [root@s1 /usr/ports/emulators/virtualbox-ose]# make USE_GCC=yes
 ===  virtualbox-ose-4.3.12_1 Unknown version of GCC specified 
 (USE_GCC=yes).
 
 more options needed?
 
 Maybe try USE_GCC=any or something like USE_GCC=4.8+ is what I am 
 seeing in other ports.
 
 
 
 
 On Sun, 1 Jun 2014, Alfred Perlstein wrote:
 
 On 6/1/14 8:57 AM, Wojciech Puchar wrote:
 
 kBuild: Compiling VBoxOGLhosterrorspu - 
 /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/GuestHost/OpenGL/e
 rror/errorspu_init.c
 kBuild: Compiling VBoxVNCMain - 
 /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNCMain.c
 pp
 kBuild: Compiling VBoxVNC - 
 /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/VBox/ExtPacks/VNC/VBoxVNC.cpp
 kBuild: Compiling VBoxRemPrimary - 
 /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/VBoxRecompiler.c
 kmk: gcc: Command not found
 kmk: *** 
 [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o]
  Error 127
 The failing command:
 @gcc -c -O2 -g -pipe -Wall -Wextra -Wno-missing-field-initializers 
 -Wno-unused -Wno-trigraphs -fdiagnostics-show-option 
 -Wno-unused-parameter -Wno-long-long -Wno-long-long 
 -Werror-implicit-function-declaration -Wno-variadic-macros -O2 
 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing 
 -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN 
 -DRT_USE_VISIBILITY_DEFAULT -fPIC -Wno-sign-compare 
 -Werror-implicit-function-declaration -m64 
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun/crt
  
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/Sun
  
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/target-i386
  
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg
  
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/fpu
  
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary
  -I/usr/ports/emulators/virtualbox
 -ose/work/VirtualBox-4.3.12/src/VBox/VMM/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler/tcg/i386
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/src/recompiler 
-I/usr/include -I/usr/X11R6/include -I/usr/local/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/dtrace
 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/include 
-I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release
 -DVBOX -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_DEBUGGER 
-DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DVBOX_WITH_HARDENING 
-DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ 
-DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ 
-DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ 
-DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DIN_RING3 
-DHC_ARCH_BITS=64 -DGC_ARCH_BITS=64 -DPIC -DIN_REM_R3 -DREM_INCLUDE_CPU_H 
-DNEED_C
 PU_H -DVBOX_WITH_RAW_MODE -DVBOX_WITH_RAW_RING1 -DLOG_USE_C99 -D_BSD 
-D__x86_64__ 
-Wp,-MD,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o.dep
 
-Wp,-MT,/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.3.12/out/freebsd.amd64/release/obj/VBoxRemPrimary/VBoxRecompiler.o
 -Wp,-MP -o /usr/ports/emulators/virtualbox-ose/work/VirtualBox
 
 
 if gcc is needed, and is not specified in dependencies please tell me 
 what gcc in /usr/ports/lang should i install
 
 or maybe - how to install gcc from base system as it is no longer 
 compiled by default with make buildworld
 
 FreeBSD s1.3miasto.net.pl 10.0-RELEASE FreeBSD 10.0-RELEASE #0: Tue Apr 
 8 14:01:53 CEST 2014 
 r...@s1.3miasto.net.pl:/usr/src/sys/amd64/compile/s1 amd64
 
 
 Please try adding:
 USE_GCC=yes
 to the Makefile for the port.
 
 -Alfred
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr

Re: please revert graphics/xfig r354029

[Alfred Perlstein]

 On Jun 1, 2014, at 1:17 PM, Christian Weisgerber na...@mips.inka.de wrote:
 
 On 2014-05-31, Mark Linimon lini...@lonesome.com wrote:
 
 I forgot I had the DOCS option unset as it was unset ages ago
 and updates have always worked.  The question is why are changes
 to a port committed without proper testing?  Yes, proper
 testing should include testing of the effects of (un)setting
 individual Makefile options.
 
 The number of combinations is huge.
 
 It's just not feasible.
 
 Which is a good argument that options should be minimized.  Instead,
 ports policy appears to be to make as many options as possible. :-(

True. At least a subset should be marked as must work. 

Setting most options would be best. 



 
 -- 
 Christian naddy Weisgerber  na...@mips.inka.de
 ___
 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
 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Please some help with port options in the new world order.

[Alfred Perlstein]

Any chance a patch like the following can be added?

It basically makes the error message a tad more clear by saying which 
options conflict.


thank you Scot!

-Alfred



On 4/16/14, 11:00 PM, Scot Hetzel wrote:

On Wed, Apr 16, 2014 at 8:47 PM, Alfred Perlstein alf...@freebsd.org wrote:

Hey folks,

I'm having a heck of a time with the rsync port in our build system with
latest ports:
commit 08b15d01e41c418b5c5b35fb5b691f5e83d40a95
Author: wg w...@freebsd.org
Date:   Wed Apr 16 23:17:53 2014 +

 devel/py-hgsubversion: update to 1.6 and use auto plist


This is the error I am getting:
+ chroot /usr/home/alfred/freenas/os-base/amd64/_.w /bin/sh -exc 'env
TARGET=amd64TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1
make __MAKE_CONF=/usr/home/alfred/freenas/os-base/amd64/make.conf.build
SRC_BASE=/usr/srcWRKDIRPREFIX=/usr/workdir -C
/usr/ports_dir/net/rsync   clean all package install BATCH=yes
-DUSE_PACKAGE_DEPENDS   WITH+=ACL WITH+=ICONV -DFORCE_PACKAGE
-DFORCE_PKG_REGISTER'
+ env TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make
__MAKE_CONF=/usr/home/alfred/freenas/os-base/amd64/make.conf.build
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C /usr/ports_dir/net/rsync
clean all package install BATCH=yes -DUSE_PACKAGE_DEPENDS WITH+=ACL
WITH+=ICONV -DFORCE_PACKAGE -DFORCE_PKG_REGISTER
===  Cleaning for rsync-3.1.0_3
===  License GPLv3 accepted by the user
 You cannot select multiple options from the PTS radio
*** Error code 1


:
:

This USED to work back in an earlier ports tree from 2 months ago by doing
this:
add_port net/rsync OPTIONS_FILE_SET+=ACL OPTIONS_FILE_SET+=ICONV

However that gives the same error message now from the build ( You
cannot select multiple options from the PTS radio).

Any tips on getting around this?  It's very frustrating.


Try:

add_port net/rsync WITH+=ACL WITH+=ICONV WITHOUT+=FLAGS


What is really strange is that OUTSIDE of the nanobsd build doing a simple:
cd /usr/port/net/rsync  make WITH+=ACL WITH+=ICONV
seems to work.

Any idea why this is happening?


The last commit to the port enabled the FLAGS option by default.
Since FLAGS and ACL are listed in OPTIONS_RADIO_PTS, you can only
select one of them.

The reason it works outside the nanobsd build is that at some point
you had disabled the FLAGS option in a previous build of the port.
Check the OPTIONSFILE in /var/db/ports/ for this port.



diff --git a/Mk/bsd.port.mk b/Mk/bsd.port.mk
index c56f7e0..120957f 100644
--- a/Mk/bsd.port.mk
+++ b/Mk/bsd.port.mk
@@ -5911,17 +5911,34 @@ OPTIONS_WRONG_SINGLE+=  ${single}
 .endfor
 .undef single
 
+#
+# Iterate through each OPTIONS_RADIO
+# Check to see if there are multiple options specified in PORT_OPTIONS
+# for a single radio.
+#
+# If so, build up an error string noting the offending radio and options
+# to be emitted later.
+#
 .for radio in ${OPTIONS_RADIO}
 .  for opt in ${OPTIONS_RADIO_${radio}}
 .if !empty(PORT_OPTIONS:M${opt})
 .  if defined(OPTFOUND)
-OPTIONS_WRONG_RADIO+=  ${radio}
+.if !defined(SECONDOPT)
+OPTIONS_WRONG_RADIO:=  
${OPTIONS_WRONG_RADIO}${radio}(options:${OPTFOUND},${opt}
+SECONDOPT= true
+.else
+OPTIONS_WRONG_RADIO:=  ${OPTIONS_WRONG_RADIO},${opt}
+.endif
 .  else
-OPTFOUND=  true
+OPTFOUND:= ${opt}
 .  endif
 .endif
 .  endfor
+.  if defined(SECONDOPT)
+OPTIONS_WRONG_RADIO:=   ${OPTIONS_WRONG_RADIO})
+.  endif
 .  undef OPTFOUND
+.  undef SECONDOPT
 .endfor
 
 .for multi in ${OPTIONS_MULTI}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Synchronizing package defaults with Linuxes?

[Alfred Perlstein]

On 4/16/14, 9:00 AM, Francois Tigeot wrote:

On Wed, Apr 16, 2014 at 05:27:43PM +0200, John Marino wrote:

On 4/16/2014 15:53, Ivan Voras wrote:

What do you think of the idea of syncing versions in general, and this
example of PostgreSQL in particular?

The example of PostgreSQL isn't really good because people have been
asking for change in default for probably two years now.  I have no clue
as to why it hasn't changed but people do not want 9.0 as the default.

BTW, DPorts has had postgresql 9.2 as the default for 15 months now,
everything is fine, so there is no reason that I know of why FreeBSD
isn't at least at 9.2.


As for syncing with Linux -- I personally don't like the idea.  The
defaults should be picked deliberately, not because _ Linux is at
whatever version.

I tend to agree with John on both points.

Changing default software versions to be in line with whatever the Linux
distribution of the week is doing is futile.


He was talking about LTS (long term stability branches) not flavor of 
the week.




Changing default software versions to something reasonably stable and recent
makes sense.

Concerning Postgres, 9.3 is the latest stable version, brings JSON support
to the table and doesn't need SYSV shared memory sysctl tuning anymore.
Making it the new default is the logical choice.



Except that the pressure on the vm is much worse than using sysvshm.

-Alfred

___
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

Please some help with port options in the new world order.

[Alfred Perlstein]

Hey folks,

I'm having a heck of a time with the rsync port in our build system with 
latest ports:

commit 08b15d01e41c418b5c5b35fb5b691f5e83d40a95
Author: wg w...@freebsd.org
Date:   Wed Apr 16 23:17:53 2014 +

devel/py-hgsubversion: update to 1.6 and use auto plist


This is the error I am getting:
+ chroot /usr/home/alfred/freenas/os-base/amd64/_.w /bin/sh -exc 
'env   TARGET=amd64TARGET_ARCH=amd64 
NAS_PORTS_DIRECT=1 make 
__MAKE_CONF=/usr/home/alfred/freenas/os-base/amd64/make.conf.build 
SRC_BASE=/usr/srcWRKDIRPREFIX=/usr/workdir -C 
/usr/ports_dir/net/rsync   clean all package install BATCH=yes 
-DUSE_PACKAGE_DEPENDS   WITH+=ACL WITH+=ICONV -DFORCE_PACKAGE 
-DFORCE_PKG_REGISTER'
+ env TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make 
__MAKE_CONF=/usr/home/alfred/freenas/os-base/amd64/make.conf.build 
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C /usr/ports_dir/net/rsync 
clean all package install BATCH=yes -DUSE_PACKAGE_DEPENDS WITH+=ACL 
WITH+=ICONV -DFORCE_PACKAGE -DFORCE_PKG_REGISTER

===  Cleaning for rsync-3.1.0_3
===  License GPLv3 accepted by the user
 You cannot select multiple options from the PTS radio
*** Error code 1

The reason this is happening is because the nanobsd build (actually 
freenas-ish) has this code that looks like this:

add_port net/rsync WITH+=ACL WITH+=ICONV

The add_port is a shell function that takes its remaining args and 
passes them down into a closure made like so:

add_port() {

echo Package is not yet built: $port
eval 
add_port_${port} () {
do_add_port ${repo_path} ${port_path} $*
}
customize_cmd add_port_${port}


}

That means I can't pass an option such as: WITH=ACL ICONV
instead I find that I have to pass them individually which is why I am 
trying: WITH+=ACL WITH+=ICONV


Unfortunately this causes the port to freak out.

This USED to work back in an earlier ports tree from 2 months ago by 
doing this:

add_port net/rsync OPTIONS_FILE_SET+=ACL OPTIONS_FILE_SET+=ICONV

However that gives the same error message now from the build ( You 
cannot select multiple options from the PTS radio).


Any tips on getting around this?  It's very frustrating.

What is really strange is that OUTSIDE of the nanobsd build doing a simple:
cd /usr/port/net/rsync  make WITH+=ACL WITH+=ICONV
seems to work.

Any idea why this is happening?

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

On 3/22/14 11:12 AM, Randy Bush wrote:

from another team member, also a long time freebsd user of decades

 firefox build bombs because something has hardwired gcc47, which is
 not installed, so firefox's ./configure bombs testing hello world.

 Attempting to figure out what has hardwired gcc47 quickly leads down
 an entire separate /usr/ports/Mk/ file full of the usual garbage, none
 of which actually says gcc47.   Presumably it is somehow inheriting
 from /usr/ports/lang/gcc's version (as opposed to
 /usr/port/lang/gcc4[69] -- this machine happens to have gcc46
 installed).

 This is as far as I got before giving up in disgust.  Maybe they'll
 sort it out by the time I care.  Or maybe I'll wipe and Ubuntu.

essentially, from a user perspective, the ports have become kiddieville,
with no testing or seeming adult supervision.  if you're just trying to
get your work done, freebsd ports have become toxic.

randy


randy,

What about using pkg(1) and what version of FreeBSD are you on?

Finally, are you using portupgrade?


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

On 3/22/14 11:19 AM, Randy Bush wrote:

What about using pkg(1) and what version of FreeBSD are you on?

what about standing on my left foot and chewing gum?  you're down in the
kinky world where the customer has to spend serious time and energy to
get around brokenness in your product.  this is a well-known recipe for
losing customers.


Finally, are you using portupgrade?

and pkg.  it all sucks.  and it sucks the customer's time.


I'm nursing a touch of a foul mood too.  (The missus and I were out at a 
birthday party last night a little later than we should have.)


I'm going to gym to shake out the bad attitudes, what are you doing?

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

On 3/22/14 11:38 AM, Randy Bush wrote:

I'm nursing a touch of a foul mood too.  (The missus and I were out at
a birthday party last night a little later than we should have.)

sympathies.  don't drink, though freebsd ports causes me to reconsider


It might loosen you up!



I'm going to gym to shake out the bad attitudes, what are you doing?

going back to sleep and moving two more services to debian tomorrow.


Honest question, have you been building things from source under 
debian's ports or are you using their version of pkg?


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

On 3/22/14 11:49 AM, Randy Bush wrote:

Honest question, have you been building things from source under
debian's ports or are you using their version of pkg?

the latter


Ok then, well then you should be using pkg if you want to do a fair 
apples to apples comparison.


Otherwise you're comparing two different games #1 at easy mode vs #2 
at expert and complaining that game #2 is too hard.




and i have two 9 systems where i try to use freebsd-update.  also a
time-consuming rabbit hole leading nowhere pleasant.  e.g.

# freebsd-update upgrade -r 9.2-RELEASE-p3
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 9.2-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/doc world/games world/lib32

The following components of FreeBSD do not seem to be installed:

Does this look reasonable (y/n)? y

Fetching metadata signature for 9.2-RELEASE-p3 from update5.freebsd.org... 
failed.
Fetching metadata signature for 9.2-RELEASE-p3 from update2.freebsd.org... 
failed.
Fetching metadata signature for 9.2-RELEASE-p3 from update3.freebsd.org... 
failed.
Fetching metadata signature for 9.2-RELEASE-p3 from update4.freebsd.org... 
failed.
Fetching metadata signature for 9.2-RELEASE-p3 from update6.freebsd.org... 
failed.
No mirrors remaining, giving up.
That is quite annoying!  I don't happen to use FreeBSD update, but 
honestly posting a log of this as a fresh message to the lists (without 
the vitriol) might get you some attention.


I happened to have a huge problem with the installer, posted about it 
and no one did anything until I posted a pretty hilarious screencast of 
me trying to use it while it did everything in its power to do anything 
BUT partition disks.


-Alfred








randy



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

Ugh, that's a mess, I haven't seen that personally, but I just tend to 
pull from git, although that takes a long time.


Using git lets me keep local changes easily.

The other option that works is just using portsnap.  I think portsnap 
auto or portsnap alfred should work for getting your the sources.


The other option would be just try a fresh checkout against 
https://svn.freebsd.org/ instead of https://svn0.us-east.freebsd.org/.


bummer!

lastly, just using pkg(1) works really nicely, if you're tired of 
dealing with port updates via source, then just try using pkg(1), it's 
basically just as nice as using apt-get these days, pretty nice stuff.


-Alfred


On 3/18/14, 9:42 AM, Randy Bush wrote:

/usr/ports# svn up
Updating '.':
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
  - The certificate has an unknown error.
Certificate information:
  - Hostname: svnmir.ysv.FreeBSD.org
  - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
  - Issuer: clusteradm, FreeBSD.org, CA, US(cluster...@freebsd.org)
  - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject or accept (t)emporarily? t
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
  - The certificate has an unknown error.
Certificate information:
  - Hostname: svnmir.ysv.FreeBSD.org
  - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
  - Issuer: clusteradm, FreeBSD.org, CA, US(cluster...@freebsd.org)
  - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject or accept (t)emporarily? t
Error validating server certificate for 'https://svn0.us-east.freebsd.org:443':
  - The certificate has an unknown error.
Certificate information:
  - Hostname: svnmir.ysv.FreeBSD.org
  - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT
  - Issuer: clusteradm, FreeBSD.org, CA, US(cluster...@freebsd.org)
  - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61
(R)eject or accept (t)emporarily?
___
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



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: reason 23 why we've moved to linux

[Alfred Perlstein]

On 3/18/14, 9:56 AM, Randy Bush wrote:

Ugh, that's a mess, I haven't seen that personally, but I just tend to
pull from git, although that takes a long time.

Using git lets me keep local changes easily.

The other option that works is just using portsnap.  I think portsnap
auto or portsnap alfred should work for getting your the sources.

The other option would be just try a fresh checkout against
https://svn.freebsd.org/ instead of https://svn0.us-east.freebsd.org/.

bummer!

lastly, just using pkg(1) works really nicely, if you're tired of
dealing with port updates via source, then just try using pkg(1), it's
basically just as nice as using apt-get these days, pretty nice stuff.

alfred,

i know you mean well, but svn is legit and we have been using it until
the kiddies came over to freebsd from linux.  now that they left linux,
debian and ubuntu are quite usable, pretty stable, and the ports/package
system makes freebsd's look horrifying.  i am tired of dependency hell.
i am tired of package management du jour.  i have real work to do and
even an attempt at a real life.

i have been a bsd user since 4.whatever on the vax.  it is no longer
defensible in any situaion other than personal religion.  and it's the
ongoing ports disaster that has killed a really great system.  sad.

randy

I see what you're getting at, however I see a different picture with 
FreeBSD moving forward at a quick pace to close the gap in package 
management between itself and the Linux distros.


I myself was initially upset, however as the changes have kept coming I 
am more and more impressed and thrilled with the effort put in.  The 
changes by the ports+pkgng team have really come together to make a 
great product.


I think we can agree that the past 6 months have been interesting and 
challenging, however more importantly they have been necessary growing 
pains that we have just now passed.


If you want to vent, great, I hear you, but let's be honest about the 
state of things and not conflate with some weird transient issue with 
svn with the project coming apart at the seams, that would just be 
hyperbolic and not serve us any purpose.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: pkg-static segfaults when a port makes a package in chroot/nanobsd.

[Alfred Perlstein]

I have a ticket open in github for this, but I wanted to mail in and let 
people know that I figured the problem out somewhat:


https://github.com/freebsd/pkg/issues/729


OK I sort of figured it out.

Basically the build script that I have issues the following command:
TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make 
__MAKE_CONF=/vol/data/alfred/freenas/os-base/amd64/make.conf.build 
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C 
/usr/ports_dir/textproc/libxml2 clean all install package BATCH=yes 
-DUSE_PACKAGE_DEPENDS -DFORCE_PACKAGE -DFORCE_PKG_REGISTER


The after adding -d lx to the command for make(1) I saw that it 
looks like the install target will rm -rf the stage dir!


By switching around the order of targets from:
clean all install package
TO:
clean all package install

It stopped deleting the .metadir which in turn stopped it from 
segfaulting.


It looks like there's a bug in the port's Mk system as well as pkgng.

For now I think I may have a workaround.



Thanks everyone!  For what it's worth my ports tree's latest commit is this:

commit e6fcb0faa8aeb5905bad5c295f319917aafd21ff
Author: makc m...@freebsd.org
Date:   Thu Feb 13 14:25:26 2014 +

misc/py-qt4-demo:
- Use plist instead of PORTEXAMPLES, otherwise the package is bogus 
when

  NOPORTEXAMPLES is set
- Use compileall.py to byte-compile installed examples
- Use options helpers



On 2/15/14, 9:01 PM, Alfred Perlstein wrote:
Hey folks, I'm doing a build of nanobsd derivative and trying to get 
it to work on 10-stable with the tip of freebsd ports as of a couple 
of days ago.


I'm getting a segfault in pkg-static when trying to make package.

The stack trace is this:
(gdb) bt
#0  0x005a0bcc in ucl_obj_ref (obj=0x0) at ucl.h:743
#1  0x005a0b99 in ucl_parser_get_object (parser=0x801027880)
at 
/usr/workdir/usr/ports/ports-mgmt/pkg/work/pkg-1.2.6/libpkg/../external/libucl/src/ucl_util.c:230

#2  0x00564795 in pkg_parse_manifest_file (pkg=0x80104e1c0,
file=0x7fffb010 
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir/+MANIFEST, 
keys=0x8010282e0) at pkg_manifest.c:748

#3  0x0043d83d in pkg_create_staged (
outdir=0x7fffbc5d /usr/ports/packages/All, format=TXZ,
rootdir=0x7fffbba5 
/usr/workdir/usr/ports_dir/textproc/libxml2/work/stage,
md_dir=0x7fffbbdf 
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir,
plist=0x7fffbc1c 
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.PLIST.mktmp, 
old=false) at pkg_create.c:248

#4  0x00407e93 in exec_create (argc=1, argv=0x7fffb720)
at create.c:262
#5  0x0040bd47 in main (argc=10, argv=0x7fffb6d8) at 
main.c:774

(gdb)

The file 
/usr/workdir/usr/ports_dir/textproc/libxml2/work/.metadir/+MANIFEST 
doesn't seem to exist.



The command being run is this:
env TARGET=amd64 TARGET_ARCH=amd64 NAS_PORTS_DIRECT=1 make 
__MAKE_CONF=/vol/data/alfred/freenas/os-base/amd64/make.conf.build 
SRC_BASE=/usr/src WRKDIRPREFIX=/usr/workdir -C 
/usr/ports_dir/textproc/libxml2 clean all install package BATCH=yes 
-DUSE_PACKAGE_DEPENDS -DFORCE_PACKAGE -DFORCE_PKG_REGISTER



Any ideas?  There is a large env being set:

The environment looks like this, you can probably grep -v out the 
^NANO stuff to make this readable:

NANO_PYTHON_DEFAULT_VERSION=python2.7
SUDO_COMMAND=/usr/local/bin/zsh
NANO_SRC=/vol/data/alfred/freenas/FreeBSD/src
NANO_MODULES= cc/cc_cdg cc/cc_chd cc/cc_cubic cc/cc_hd cc/cc_htcp 
cc/cc_vegas cxgb cxgbe cyclic dtrace ext2fs fdescfs geom ipmi krpc 
libiconv libmchain lindev linprocfs linsysfs linux nfs_common 
nfsclient nfslock ispfw/ispfw opensolaris pf pflog smbfs tmpfs udf 
usb/xhci zfs ctl cxgbe/t4_firmware cxgbe/t5_firmware iscsi syscons

NANO_LABEL=DarkShield
NANO_MEDIASIZE=14450688
NANO_NEWFS=-b 4096 -f 512 -i 8192 -O1 -U
LOGNAME=root
NANO_TOOLS=/vol/data/alfred/freenas/build/nanobsd
NANO_MAKE_CONF_BUILD=/vol/data/alfred/freenas/os-base/amd64/make.conf.build
NAS_PORTS_DIRECT=1
NANO_BOOTLOADER=boot/boot0
MAKELEVEL=1
AVATAR_ROOT=/vol/data/alfred/freenas
NANO_XZ=pxz
MAKEOBJDIRPREFIX=/vol/data/alfred/freenas/os-base/amd64
FREEBSD_PACKAGE_MIRROR_32=http://mirror.exonetric.net/pub/pkgng/freebsd:9:x86:32/latest
NANO_PMAKE=make -j 9
SCRIPT=typescript
NANO_ARCH=amd64
FREEBSD_PKGCACHE_32=/freenas-build/freebsd-packages-32
MASTER_SITE_OVERRIDE=http://build/distcache/${DIST_SUBDIR}/
MAIL=/var/mail/root
NANO_LOCAL_DIRS= pbi-wrapper extract-tarball
NANO_CONFSIZE=2048
MAKEFLAGS= .MAKE.LEVEL.ENV=MAKELEVEL
NANO_HEADS=16
DISTCACHE=
MAKE_JOBS=9
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/alfred/bin
FREEBSD_DISTCACHE=/freenas-build/freebsd-distfiles
NANO_IMAGES=2
NANO_CFG_BASE=/vol/data/alfred/freenas/nanobsd
NANO_MAKE_CONF_INSTALL=/vol/data/alfred/freenas/os-base/amd64/make.conf.install
SUDO_GID=1001
OLDPWD=/vol/data/alfred/freenas/FreeBSD/ports/devel/py-fake-factory
.MAKE.LEVEL.ENV=MAKELEVEL
NANO_DATASIZE=4096000

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in 
mailto:j...@ohlste.in wrote:


Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@rawbw.com
mailto:y...@rawbw.com wrote:

On 01/25/2014 14:44, Aryeh Friedman wrote:

The key seems to be that no one has time to do the
stuff they really
want
to do (get new ports into the system)... to that
end automating
everything
that can be automated is sure help free up
comitter time so they can
look
at what is interesting

Yes. I just can't imagine any generic port tests that
can't be automated
and coded into the script once and for good.
Ideal system should be like github with the added
automated testing
between pull request submission and merge. It should
either fail and
notify
the submitter, or succeed and notify the committers.

Git hup (or *ANY* remote service for that matter) is a no
go IMO


You just don't get it.

Again, you just really, really, don't get it.

You WANT a gateway to a remote service that the project does
not have to
handle.

Why?  Because then we offload the problem to another org.

The FreeBSD project should be about innovation in OS design,
platform
and software.  Ops work is bunk and just slows us down.

The more we can outsource the better we'll be.  (and what if that
service blows up?  well we move on!  it's simple!)

Continuing to insist that we run the services ourselves it
just wasting
our limited resources.  Not only that but we get emotionally
attached to
technologies that are old, dying and dead when off the shelf
stuff works
just fine.


I've read all 60 or so messages in this thread and there really
are two related but distinct issues here.

The thread title is What is the problem with ports PR reaction
delays?. This has meandered into a philosophical debate about who
knows what and who knows squat about version control systems,
whether we need to maintain certain requirements, testing ports, etc.

I like the KISS approach myself. This can be boiled down to those
two issues, one of which is a symptom of the other. Arguing and
debating over a long term solution to the OP's question does
nothing to solve the problem in the short to intermediate term.
There are 1680 current ports related PR's at this moment.

As we all know, the committers are volunteers, mostly with real
jobs and real lives and they obviously cannot keep up with the
current load. The short to medium term solution for that is more
committers. I'll add my name to the list of those who are willing
to step in and help to clean up the mess. I'm certain that if a
request went out, there would be many who are more qualified than I.

At the same time, a group of interested individuals should offer
input to the folks who already are looking at changing the bug
reporting system away from gnats -
https://wiki.freebsd.org/Bugtracking/BugRelocationPlan. Doing it
in one fell swoop might make sense. It's ripping off the bandaid
but I'd rather do it only once myself.

What does *not* make sense is a new port for what might be a very
useful tool waiting since September for someone to look at it.
Arguing over git and subversion et alia does nothing to fix that.
As they say on the ESPN NFL pregame show, C'mon man!.


I can't agree more. I can see, understand and accept reasons why we 
cant move from SVN to GitHub/Git and I certainly dont think that it 
would be solution to current problems. It seems like this is not 
neccessary, it wont happen, so I think we can end that discussion 
here. However, we do have all the tools to automate this process, so I 
really dont understand why not to do this, especially it is perfectly 
doable with SVN, Redports are already doing so, and there are people 
willing to work on it.




Thanks Big Lebowski spankthes...@gmail.com!

I'm not sure if taking your word for it will be the be all and end all 
of progress on this issue.  I do have hope, after all as Max Plancksaid:


A new scientific truth does not triumph by convincing its opponents and 
making them see the light, but rather because its opponents eventually 
die, and a new generation grows up that is familiar with it.


I just have my fingers cross that we are not so insular, so heels dug

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 10:21 AM, Aryeh Friedman wrote:

just do us a favor and do not assume newer means better...


I've been using newer almost exclusively for the past several years and 
it is better.


Open your eyes, people have moved on.


-Alfred





On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein alf...@freebsd.orgwrote:


  On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein j...@ohlste.in wrote:


Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:


On 1/25/14 3:48 PM, Aryeh Friedman wrote:


On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@rawbw.com wrote:

  On 01/25/2014 14:44, Aryeh Friedman wrote:

  The key seems to be that no one has time to do the stuff they really

want
to do (get new ports into the system)... to that end automating
everything
that can be automated is sure help free up comitter time so they can
look
at what is interesting

  Yes. I just can't imagine any generic port tests that can't be

automated
and coded into the script once and for good.
Ideal system should be like github with the added automated testing
between pull request submission and merge. It should either fail and
notify
the submitter, or succeed and notify the committers.

  Git hup (or *ANY* remote service for that matter) is a no go IMO

You just don't get it.

Again, you just really, really, don't get it.

You WANT a gateway to a remote service that the project does not have to
handle.

Why?  Because then we offload the problem to another org.

The FreeBSD project should be about innovation in OS design, platform
and software.  Ops work is bunk and just slows us down.

The more we can outsource the better we'll be.  (and what if that
service blows up?  well we move on!  it's simple!)

Continuing to insist that we run the services ourselves it just wasting
our limited resources.  Not only that but we get emotionally attached to
technologies that are old, dying and dead when off the shelf stuff works
just fine.


  I've read all 60 or so messages in this thread and there really are two
related but distinct issues here.

The thread title is What is the problem with ports PR reaction delays?.
This has meandered into a philosophical debate about who knows what and who
knows squat about version control systems, whether we need to maintain
certain requirements, testing ports, etc.

I like the KISS approach myself. This can be boiled down to those two
issues, one of which is a symptom of the other. Arguing and debating over a
long term solution to the OP's question does nothing to solve the problem
in the short to intermediate term. There are 1680 current ports related
PR's at this moment.

As we all know, the committers are volunteers, mostly with real jobs and
real lives and they obviously cannot keep up with the current load. The
short to medium term solution for that is more committers. I'll add my name
to the list of those who are willing to step in and help to clean up the
mess. I'm certain that if a request went out, there would be many who are
more qualified than I.

At the same time, a group of interested individuals should offer input to
the folks who already are looking at changing the bug reporting system away
from gnats - https://wiki.freebsd.org/Bugtracking/BugRelocationPlan.
Doing it in one fell swoop might make sense. It's ripping off the bandaid
but I'd rather do it only once myself.

What does *not* make sense is a new port for what might be a very useful
tool waiting since September for someone to look at it. Arguing over git
and subversion et alia does nothing to fix that. As they say on the ESPN
NFL pregame show, C'mon man!.


  I can't agree more. I can see, understand and accept reasons why we cant
move from SVN to GitHub/Git and I certainly dont think that it would be
solution to current problems. It seems like this is not neccessary, it wont
happen, so I think we can end that discussion here. However, we do have all
the tools to automate this process, so I really dont understand why not to
do this, especially it is perfectly doable with SVN, Redports are already
doing so, and there are people willing to work on it.


Thanks Big Lebowski spankthes...@gmail.com spankthes...@gmail.com!

I'm not sure if taking your word for it will be the be all and end all of
progress on this issue.  I do have hope, after all as Max Planck said:

A new scientific truth does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually die,
and a new generation grows up that is familiar with it.

I just have my fingers cross that we are not so insular, so heels dug deep
in the dirt, and so curmudgeonly that we drive away anyone interested in
new technology.

I mean, if we're all so firm in our beliefs there are dozens of other open
source projects that encourage new things that people will flock to.


-Alfred







___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 10:32 AM, Aryeh Friedman wrote:
Forgot to mention and aegis in almost every case implements the very 
same features in a much smoother way (no stupid http bs or anything)




If aegis is so much better then we should use it.  Or everyone should 
use it... but why isn't everyone using it?


Can you explain?

Seriously, if it's so much better then please do tell!

-Alfred






On Sun, Jan 26, 2014 at 1:31 PM, Aryeh Friedman 
aryeh.fried...@gmail.com mailto:aryeh.fried...@gmail.com wrote:


If it is so new then why when I looked into git and git hub for
the first time about 2 years ago it didn't have a *SINGLE* feature
that aegis didn't have in the mid-90's... all it is a bunch or
pretty pictures to make those who are addicted to newness be able
to claim they are actually making progress with their newness
when in fact they are reinvinting the wheel for the 15th time


On Sun, Jan 26, 2014 at 1:26 PM, Alfred Perlstein
alf...@freebsd.org mailto:alf...@freebsd.org wrote:

On 1/26/14 10:21 AM, Aryeh Friedman wrote:

just do us a favor and do not assume newer means better...


I've been using newer almost exclusively for the past several
years and it is better.

Open your eyes, people have moved on.


-Alfred




On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein
alf...@freebsd.org mailto:alf...@freebsd.orgwrote:

  On 1/26/14 5:25 AM, Big Lebowski wrote:




On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein
j...@ohlste.in mailto:j...@ohlste.in wrote:

Hello,


On 1/25/14, 9:04 PM, Alfred Perlstein wrote:

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri
y...@rawbw.com mailto:y...@rawbw.com
wrote:

  On 01/25/2014 14:44, Aryeh Friedman wrote:

  The key seems to be that no one has
time to do the stuff they really

want
to do (get new ports into the
system)... to that end automating
everything
that can be automated is sure help
free up comitter time so they can
look
at what is interesting

  Yes. I just can't imagine any
generic port tests that can't be

automated
and coded into the script once and for
good.
Ideal system should be like github
with the added automated testing
between pull request submission and
merge. It should either fail and
notify
the submitter, or succeed and notify
the committers.

  Git hup (or *ANY* remote service for
that matter) is a no go IMO

You just don't get it.

Again, you just really, really, don't get it.

You WANT a gateway to a remote service that
the project does not have to
handle.

Why?  Because then we offload the problem to
another org.

The FreeBSD project should be about innovation
in OS design, platform
and software.  Ops work is bunk and just slows
us down.

The more we can outsource the better we'll be.
 (and what if that
service blows up?  well we move on!  it's simple!)

Continuing to insist that we run the services
ourselves it just wasting
our limited resources.  Not only that but we
get emotionally attached to
technologies that are old, dying and dead when
off the shelf stuff works
just fine.

  I've read all 60 or so messages in this thread
and there really are two
related but distinct issues here.

The thread title is What is the problem with
ports PR reaction delays?.
This has meandered

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14, 6:43 PM, Aryeh Friedman wrote:

)



If aegis is so much better then we should use it.  Or everyone should use
it... but why isn't everyone using it?


Simple reason Peter Miller (the author of aegis/cook) for whatever reason
*NEVER* tried to market his stuff while GIT made a specific effort of
attempting to get outside users.   Peter (like most FOSS authors) wrote it
first and formost for himself and never say any need for others to use it
per se.   It would take too long to summarize all the differences (I have
already stated the major ones in the thread though).  If your really
interested take a look at the material at aegis.sf.net.



Can you explain?

Seriously, if it's so much better then please do tell!


The #1 reason (above all else IMO) is it doesn't rely (directly or
indirectly) on any third party for it's basic operation (which github does
unless the foundation wanted to duplicate which is a waste of time).  The
other main reason it works with existing tools where from what you describe
GitHub requires you install something (by working I mean you can look at
the baseline without any special tools)

Finally since your addicted to newness you will not get the most important
difference aegis has been in production for over 20 years where git hub 5
or 6?
I'm not addicted to newness.  I think you just hate anything that is 
popular and you're butthurt that something that's may have been ahead of 
it's time was missed out on.  This is no reason to dig your heels in and 
complain as that accomplishes nothing.


What I am interested in is:

1) leveraging the hordes of people that can submit changes to the 
project because they know git.
2) leveraging the existing tooling that's available for FREE!!! for us 
to use. (instead of rewriting wheels).
3) reducing the overhead of contribution to our project by using 
existing solutions and not requiring accounts to be made.


So what would using this aegis system buy us?

1) Supposedly DVCS.

Now that is interesting!!!

In my list there is no mention of DVCS!  There is just the resulting 
benefits that Aegis doesn't have.


Aegis
1) doesn't have hordes of people that know how to use it.
2) doesn't have a free hosting solution for it which provides tooling we 
need for free.



It's not about NEW THINGS, although NEW THINGS tend to lead to better 
systems... it's more about leveraging users and existing facilities.


Anyhow, it's not important, you want your toy, even though no one uses 
it.  Enjoy it. :)


If you want to be part of an exclusive club that only uses esoteric 
tools and home-built Rube Goldberg scripts to accomplish what people are 
doing with modern tools in less than half the time and in the same 
conversation be annoyed that there's a lack of people signing up to work 
under those conditions then you need to take a deep breath and look in 
the mirror.


When your toy has a huge community that fulfills the requirements that I 
have I'll check it out.  When switching to Aegis gets FreeBSD the same 
benefits of the github community and millions of code monkeys I'll be 
cheering for it.


But right now here's what I think of a better tool that no one uses:  
http://www.youtube.com/watch?v=uuyUA-8toJk#t=27


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14 9:02 PM, Aryeh Friedman wrote:




On Sun, Jan 26, 2014 at 10:00 PM, Alfred Perlstein alf...@freebsd.org 
mailto:alf...@freebsd.org wrote:


When your toy has a huge community that fulfills the requirements
that I have I'll check it out.  When switching to Aegis gets
FreeBSD the same benefits of the github community and millions of
code monkeys I'll be cheering for it.


If having a million code monkeys is the mark of a good system, does 
this mean you regard healthcare.gov http://healthcare.gov as a 
supreme master piece of software engineering?  After all it has 500 
million lines from god knows how many contributors... therefore it 
must be better?




I'm not sure, I'm going to go load up healthcare.gov to see if I can 
order myself some free aspirin after this discussion.


I skimmed the rest of your message and nothing really stuck out as 
something worth perusing.  I guess I have to say is that I hope you 
enjoy Agis so much that you and the 10 other people using it are able to 
proselytize it to the success that git and github have had. You 
certainly seem passionate about it!


-Alfred



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/26/14, 10:56 PM, Aryeh Friedman wrote:


On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein alf...@freebsd.org 
mailto:alf...@freebsd.org wrote:



I'm not sure, I'm going to go load up healthcare.gov
http://healthcare.gov to see if I can order myself some free
aspirin after this discussion.


At least my build system has never caused me to need an aspirin 
(normal debugging is bad enough).  Sarcasm aside, to bring this thread 
back on track, the important issues are:


  * The development model used by aegis is likely the cleanest 
development cycle I have seen (main reason for this is Peter Miller is 
one of the few SCM and build management theorists [vs. just hacking 
something til it works]).   The model is namely (repeat as needed) 
develop-test-review-integrate... note that test comes before review 
for the simple reason to even get to review you must build correctly 
and pass all your own tests (isn't this the main goal of automating 
the port system anyways)... also keep in mind we can use this model 
without necessarily switching to aegis per se.  With or without aegis, 
it would save the ports team a lot of time to be able to build and 
test a port automatically before they spend any time reviewing the 
code.  Aegis, by default, enforces this model.


  * GitHub *REQUIRES* all developers (including all port maintainers 
-- not just the committers) to switch to GitHub.  On the other hand, 
if the ports team were to use aegis and/or cook, this would NOT 
require any changes at all from the POV of maintainers.  Even on the 
ports team, most members would need to learn nothing more than 6 new 
basic commands... (portmgr@ would need to learn a lot more though 
depending on what kind of non-standard processing needs to be done in 
integration).
Using git doesn't require switching to github.  I'm not sure what you're 
smoking that's leading you to believe that, maybe you should also try to 
log onto healthcare.gov to figure out what's causing your level of 
confusion!





  * If there are modifications to the overall port system, switching 
to aegis and/or cook would not require changes to individual ports 
like GitHub seems to



I skimmed the rest of your message and nothing really stuck out as
something worth perusing.  I guess I have to say is that I hope
you enjoy Agis so much that you and the 10 other people using it
are able to proselytize it to the success that git and github have
had.  You certainly seem passionate about it!


It would be nice if you could refrain from commenting on stuff you 
can't be bothered to peruse.


Likewise!

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/24/14, 11:45 PM, John Marino wrote:

On 1/25/2014 05:16, Alfred Perlstein wrote:

Thus, are you volunteering for this role?  It's not my call, but if you
really want to do clean out and triage the all PRs on an ongoing basis,
my guess is that would be very welcome and we'd figure out a way to set
that up.  It would definitely help, especially for those maintainer that
approve patches but the PRs never get opened (or set to a better state
than open).

At some point we'll have a new PR system, that fact might be having an
impact on current PRs as well...

To me it would speak of tooling as opposed to anything.
Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

The SCM part of the ports process is not the bottleneck.


Could ports take PRs in the form of pull requests on github?
Wouldn't that just turn the number of updates into a few minor clicks?

This makes a fatal and untrue assumption: That was is submitted just
needs to be committed.  In my brief experience, I can tell you that's
simply not true.  If a submission can be taken without a single change,
that is truly an exception.  It's not even the submitters fault often,
sometimes the infrastructure changes but the submitter didn't know or
account for it, or the PR came before the infrastructure change.

One can RARELY take a submission as-is.  Thus, pull requests turn into
merge conflict exercises and cause more work, not less IMO.
Your opinion is completely incorrect.  It is trivial for someone to take 
a pull request and resolve the differences and it is MUCH easier (orders 
of magnitude) to collab using git/github than it is to mail around 
patches over and over.  I really believe you don't understand how 
git/github works.






(also wouldn't it make it easier for ports submitters)?

personally I don't really think so, plus I don't see the current or
future PR system as the barrier for port submitters.


(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

I would like to see something where the submission gets tested in
Redports automatically, and automatically annotates if the port passes
on all platforms or not.  Then the submitter gets notice it needs fixing
immediately and FreeBSD folks don't have to take the PR, test it, reject
it, and state why.  That iteration can take a few cycles and automated
testing could cut that process time tremendously.
That would be interesting.  If you could get it to work with github 
you'd find a lot more people active and willing to participate.


Basically, if my workflow was:

start:
 git pull request - creates redport submission - then
   either:
 1) submission compiles and works - promotes to qualified pull 
request - either auto merged or given to maintainer to merge in 1 click.
 2) submission fails, then either I fix and resubmit the pull 
request, or I collab with the submitter to get it to work and then 
resubmit GOTO start.


That would be pretty awesome.  *A* problem (notice: not the problem) 
is that the cycle is too slow and cumbersome.  Hook this into a DVCS 
that works well and suddenly you'll see productivity take off as well as 
people willing and wanting to submit patches.


In fact it will free up time from the people that qualify the code in 
order to quality and approve more code.


That said, you'll have to be up for learning new tools, and that doesn't 
leave me very optimistic of this ever happening.


-Alfred


John




___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:
(maybe there is some great ports system that I'm not aware of that 
makes this all as easy github, but I somehow doubt that.)


github itself is closed source, but 95% of its functionality is based 
on git which is open. One only needs to invoke 3-4 git operations to 
support what it does on the website side. Register on the site, fork 
the project under user's login, submit a pull request, merge a fork's 
branch to the main branch. All these are basically git commands. 
Without the glossiness of github, this is not that large of a project. 
Submitters will do the rest through git.


I think, instead of tediously going through the PRs by hand, it is 
wiser to set up some system like this.



Agreed.   +1000

Although if we go down the rabbit hole of building something like 
github that might take a while.  For now prototyping using the github 
pull methods might be a good proof of concept.  I may look into doing a 
github pull request - GNATS (src) PR gateway if time allows.


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14, 1:14 AM, John Marino wrote:

On 1/25/2014 09:55, Alfred Perlstein wrote:

On 1/24/14, 11:45 PM, John Marino wrote:

On 1/25/2014 05:16, Alfred Perlstein wrote:

Thus, are you volunteering for this role?  It's not my call, but if you
really want to do clean out and triage the all PRs on an ongoing basis,
my guess is that would be very welcome and we'd figure out a way to set
that up.  It would definitely help, especially for those maintainer
that
approve patches but the PRs never get opened (or set to a better
state
than open).

At some point we'll have a new PR system, that fact might be having an
impact on current PRs as well...

To me it would speak of tooling as opposed to anything.
Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

The SCM part of the ports process is not the bottleneck.


Could ports take PRs in the form of pull requests on github?
Wouldn't that just turn the number of updates into a few minor clicks?

This makes a fatal and untrue assumption: That was is submitted just
needs to be committed.  In my brief experience, I can tell you that's
simply not true.  If a submission can be taken without a single change,
that is truly an exception.  It's not even the submitters fault often,
sometimes the infrastructure changes but the submitter didn't know or
account for it, or the PR came before the infrastructure change.

One can RARELY take a submission as-is.  Thus, pull requests turn into
merge conflict exercises and cause more work, not less IMO.

Your opinion is completely incorrect.  It is trivial for someone to take
a pull request and resolve the differences and it is MUCH easier (orders
of magnitude) to collab using git/github than it is to mail around
patches over and over.  I really believe you don't understand how
git/github works.

First, that's presumptuous.  I have a github account that I use.  DPorts
and DeltaPorts are both hosted on GitHub, and based on git.  I know how
what it can do.

Secondly, ports is SVN, not git, and it's not going to be based on git.
  So it's a moot discussion.


Still missing the point.  Git can sit on top of svn.


Thirdly, we don't mail patches around.  You just pull the patch from
GNATS.  Applying patches is not hard.  I personally prefer rejected
hunks than editing merge conflicts.  Sure I can do both.  I find
rejected hunks easier to deal with than yours/his/merged/common etc.


Basically we don't carry floppies from computer to computer!!!  we use 
zip disks!! mlaaah.


OK, got it!

From what I'm reading you may know how to use git casually, but not in 
any other fashion than it's like svn, but I have to commit twice.



Lastly: you are skipping steps.  There's review and testing to be done.
  You don't just merge and commit.  Using pull requests (even if it were
possible on SVN) doesn't significantly change anything.


I'm not skipping steps if you read the rest of my mail.


(also wouldn't it make it easier for ports submitters)?

personally I don't really think so, plus I don't see the current or
future PR system as the barrier for port submitters.


(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

I would like to see something where the submission gets tested in
Redports automatically, and automatically annotates if the port passes
on all platforms or not.  Then the submitter gets notice it needs fixing
immediately and FreeBSD folks don't have to take the PR, test it, reject
it, and state why.  That iteration can take a few cycles and automated
testing could cut that process time tremendously.

That would be interesting.  If you could get it to work with github
you'd find a lot more people active and willing to participate.

Basically, if my workflow was:

start:
  git pull request - creates redport submission - then
either:
  1) submission compiles and works - promotes to qualified pull
request - either auto merged or given to maintainer to merge in 1 click.
  2) submission fails, then either I fix and resubmit the pull
request, or I collab with the submitter to get it to work and then
resubmit GOTO start.

Well, that's not what I said above.  That gets freebsd committers
involved before the patch is verified to build.  I was trying to get
freebsd committers not to see patches that don't even build and make
sure they get fixed before committers spend any time on it.


That said, you'll have to be up for learning new tools, and that doesn't
leave me very optimistic of this ever happening.

IIUC, you are trying to start a git migration from subversion
discussion.
No you do not IIUC.  The point here is to encourage the use of 
existing tooling to solve a problem or enhance a process.



While I am happy with either one (given that DragonFly
Ports and sources is hosted on git), I don't see the acceptance by
others.
Yes, because change can never happen because some people don't like 
change.  Sad

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.

I encourage you to educate yourself then and then review the suggestions 
I gave.


Continuing the discussion at this point would prove worthless.

Here are some links to get yourself started:

git-svn:
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion
http://viget.com/extend/effectively-using-git-with-subversion

gerrit: a tool for review and automation of code submission:
http://code.google.com/p/gerrit/

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 9:48 AM, Baptiste Daroussin wrote:

On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:


To me it would speak of tooling as opposed to anything.

Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

Could ports take PRs in the form of pull requests on github?

Wouldn't that just turn the number of updates into a few minor clicks?

(also wouldn't it make it easier for ports submitters)?

(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

That would imho be a total disaster, as less and less people will really take
care of reviewing the actual patch (lots of commits are already directly from Pr
patches without applying some necessary diff for consistency, correctness, Q/A
and cosmetic.)



You are not serious.

You are saying that because the process would be too streamlined that 
quality would be impacted?


That is pretty entertaining.  I've seen such positions, but only at very 
large and derpy companies coming from people invested in broken tooling.



btw we already have tons of tools available to just merge patches directly from
gnats.

Are any of these tools available on the other side?

Ie, for port submitters?

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 9:51 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:

On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:

(maybe there is some great ports system that I'm not aware of that
makes this all as easy github, but I somehow doubt that.)

github itself is closed source, but 95% of its functionality is based
on git which is open. One only needs to invoke 3-4 git operations to
support what it does on the website side. Register on the site, fork
the project under user's login, submit a pull request, merge a fork's
branch to the main branch. All these are basically git commands.
Without the glossiness of github, this is not that large of a project.
Submitters will do the rest through git.

I think, instead of tediously going through the PRs by hand, it is
wiser to set up some system like this.


Agreed.   +1000

Although if we go down the rabbit hole of building something like
github that might take a while.  For now prototyping using the github
pull methods might be a good proof of concept.  I may look into doing a
github pull request - GNATS (src) PR gateway if time allows.

Once again github pull request is the worst way of merging patches that exists.

We already have problem with ugly and inaccurate logs, such pull request will
make it even worse.

Making proper merge from github pull request it not that easy, you will need to
fetch pull request as custom branches and cherry-pick them. That is really not
convenient.

Probably a dozen lines of shell.

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.


Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 10:32 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.

Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred

There is not only $Freebsd$ but also other props.


mergeinfo?

I'm wondering because there's huge projects out there not tied down to 
svn.  It seems to be a problem of our own invention.


Having managed the FreeNAS project for a year and exclusively using git 
we found ZERO use for any svn props.  We just used git and put all the 
cruft behind us.


And we were glad for it!

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 10:30 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:25:07AM -0800, Alfred Perlstein wrote:

On 1/25/14 9:48 AM, Baptiste Daroussin wrote:

On Fri, Jan 24, 2014 at 08:16:39PM -0800, Alfred Perlstein wrote:

To me it would speak of tooling as opposed to anything.

Does the ports system have a 1 or 2 click interface for merging PRs like
for instance github?

Could ports take PRs in the form of pull requests on github?

Wouldn't that just turn the number of updates into a few minor clicks?

(also wouldn't it make it easier for ports submitters)?

(maybe there is some great ports system that I'm not aware of that makes
this all as easy github, but I somehow doubt that.)

That would imho be a total disaster, as less and less people will really take
care of reviewing the actual patch (lots of commits are already directly from Pr
patches without applying some necessary diff for consistency, correctness, Q/A
and cosmetic.)



You are not serious.

You are saying that because the process would be too streamlined that
quality would be impacted?

That is pretty entertaining.  I've seen such positions, but only at very
large and derpy companies coming from people invested in broken tooling.

I m saying that such tools as they are, are giving awful result, if we are ever
going to that can of direction, we will need to really take time to work on the
workflow and the tools, to make sure this is done a proper way, and no githun is
not doing such things a proper way, I did learn that the hardway with pkgng
developememt which is on github, I do not use anymorr at all their web tools to
do any merge.

btw we already have tons of tools available to just merge patches directly from
gnats.

Are any of these tools available on the other side?

Ie, for port submitters?

yes porttools for example, or some scripts inside Tools/scripts

regards,
Bapt

Is there a primer on using these tools?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 10:59 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:41:22AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:32 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:27:21AM -0800, Alfred Perlstein wrote:

On 1/25/14 10:04 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 09:36:00AM -0800, Alfred Perlstein wrote:

On 1/25/14, 9:28 AM, John Marino wrote:

On 1/25/2014 18:11, Alfred Perlstein wrote:

Still missing the point.  Git can sit on top of svn.


Other than converting SVN to Git, I don't know anything about that.  It
would never be done in an official capacity.  Git is not an official
tool of FreeBSD.


I encourage you to educate yourself then and then review the suggestions
I gave.

I encourage you to give a shot at what you are suggesting. git-svn is broken for
committers as long as it doesn't properly handle properties.

Or maybe our requirement for props is broken?

Is $FreeBSD$ *that* important?

-Alfred

There is not only $Freebsd$ but also other props.

mergeinfo?

I'm wondering because there's huge projects out there not tied down to
svn.  It seems to be a problem of our own invention.

Having managed the FreeNAS project for a year and exclusively using git
we found ZERO use for any svn props.  We just used git and put all the
cruft behind us.

And we were glad for it!

-Alfred

svn props are used by and for svn, sure if you are not in a svn world you do not
need the props, see the autoprops set on the repo for more details,

honnestly I do not care the vcs we use, right now it is svn so what ever is
going to be use on top of it it should be svn compliant and svn needs and uses
the properties.

regards,
Bapt

Or you just rip the band aid off and flag day your way into the future.

-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 11:52 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 10:26:30AM -0800, Alfred Perlstein wrote:

On 1/25/14 9:51 AM, Baptiste Daroussin wrote:

On Sat, Jan 25, 2014 at 12:57:21AM -0800, Alfred Perlstein wrote:

On 1/25/14, 12:11 AM, Yuri wrote:

On 01/24/2014 20:16, Alfred Perlstein wrote:

(maybe there is some great ports system that I'm not aware of that
makes this all as easy github, but I somehow doubt that.)

github itself is closed source, but 95% of its functionality is based
on git which is open. One only needs to invoke 3-4 git operations to
support what it does on the website side. Register on the site, fork
the project under user's login, submit a pull request, merge a fork's
branch to the main branch. All these are basically git commands.
Without the glossiness of github, this is not that large of a project.
Submitters will do the rest through git.

I think, instead of tediously going through the PRs by hand, it is
wiser to set up some system like this.


Agreed.   +1000

Although if we go down the rabbit hole of building something like
github that might take a while.  For now prototyping using the github
pull methods might be a good proof of concept.  I may look into doing a
github pull request - GNATS (src) PR gateway if time allows.

Once again github pull request is the worst way of merging patches that exists.

We already have problem with ugly and inaccurate logs, such pull request will
make it even worse.

Making proper merge from github pull request it not that easy, you will need to
fetch pull request as custom branches and cherry-pick them. That is really not
convenient.

Probably a dozen lines of shell.


Actually no: add this to your git config file

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then all the pull request will be seen as branches you can safely cherry-pick.


Yes I know that...

-Alfred


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 4:05 PM, Yuri wrote:

On 01/25/2014 15:48, Aryeh Friedman wrote:

Git hup (or*ANY*  remote service for that matter) is a no go IMO


But both Debian and Fedora do this with automated remote testing, and 
they don't seem to complain.

How is our ports different in this respect?


I don't get this either.

--
Alfred Perlstein

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 3:41 PM, Yuri wrote:

On 01/25/2014 14:44, Aryeh Friedman wrote:
The key seems to be that no one has time to do the stuff they really 
want
to do (get new ports into the system)... to that end automating 
everything
that can be automated is sure help free up comitter time so they can 
look

at what is interesting


Yes. I just can't imagine any generic port tests that can't be 
automated and coded into the script once and for good.
Ideal system should be like github with the added automated testing 
between pull request submission and merge. It should either fail and 
notify the submitter, or succeed and notify the committers.


Today all committers do for ports is running some generic tests by 
hand, like 'lint' with various flags. Install/uninstall/etc. No wonder 
this isn't very a rewarding activity, and committers probably perceive 
it as a necessary evil. The way how it is, it causes a waste of their 
time.



100% agree.

-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/25/14 3:48 PM, Aryeh Friedman wrote:

On Sat, Jan 25, 2014 at 6:41 PM, Yuri y...@rawbw.com wrote:


On 01/25/2014 14:44, Aryeh Friedman wrote:


The key seems to be that no one has time to do the stuff they really want
to do (get new ports into the system)... to that end automating everything
that can be automated is sure help free up comitter time so they can look
at what is interesting


Yes. I just can't imagine any generic port tests that can't be automated
and coded into the script once and for good.
Ideal system should be like github with the added automated testing
between pull request submission and merge. It should either fail and notify
the submitter, or succeed and notify the committers.


Git hup (or *ANY* remote service for that matter) is a no go IMO


You just don't get it.

Again, you just really, really, don't get it.

You WANT a gateway to a remote service that the project does not have to 
handle.


Why?  Because then we offload the problem to another org.

The FreeBSD project should be about innovation in OS design, platform 
and software.  Ops work is bunk and just slows us down.


The more we can outsource the better we'll be.  (and what if that 
service blows up?  well we move on!  it's simple!)


Continuing to insist that we run the services ourselves it just wasting 
our limited resources.  Not only that but we get emotionally attached to 
technologies that are old, dying and dead when off the shelf stuff works 
just fine.


-Alfred
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: What is the problem with ports PR reaction delays?

[Alfred Perlstein]

On 1/24/14, 4:47 PM, John Marino wrote:

On 1/25/2014 01:36, Big Lebowski wrote:

I was hoping to get some discussion revealing how the work is organized
around ports PR, perhaps some ideas on improving them and I hoped that
people who can make decisions and changes would notice it and consider
them, since as they say, the squeeky wheel gets the grease, that's all. At
no point I insisted on forcing anyone to anything, and I dont think that's
neither only nor a viable solution.

It seems obvious that current process doesnt work very well, then I'd aim
at reorganizing that process - it appears that there is no roles specified,
so the responsibility is blurred, and when everyone is responsible for one
thing, in practice no one is. Perhaps role assignment could be of any help?

I'm not trying to be a jerk, but surely I'm coming off that way.
Again, nobody is obligated to accept any assignment.  They have to
volunteer to do it.  The only person that The Big Lebowski can influence
here is himself.

Thus, are you volunteering for this role?  It's not my call, but if you
really want to do clean out and triage the all PRs on an ongoing basis,
my guess is that would be very welcome and we'd figure out a way to set
that up.  It would definitely help, especially for those maintainer that
approve patches but the PRs never get opened (or set to a better state
than open).

At some point we'll have a new PR system, that fact might be having an
impact on current PRs as well...


To me it would speak of tooling as opposed to anything.

Does the ports system have a 1 or 2 click interface for merging PRs like 
for instance github?


Could ports take PRs in the form of pull requests on github?

Wouldn't that just turn the number of updates into a few minor clicks?

(also wouldn't it make it easier for ports submitters)?

(maybe there is some great ports system that I'm not aware of that makes 
this all as easy github, but I somehow doubt that.)


-Alfred

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: Official FreeBSD Binary Packages now available for pkgng

[Alfred Perlstein]

On 10/31/13 1:10 AM, Thomas Steen Rasmussen wrote:

On 31-10-2013 09:05, Beeblebrox wrote:

Brian:
Please make sure your message gets posted on 
http://forums.freebsd.org/ as a

general announcement.
Also, the DNS records for http://pkg.FreeBSD.org/ does not seem to have
flushed-through yet (not working as of 08:00 GMT)


Quoting from Brians excellent email:

Note that pkg.FreeBSD.org does not have a browsable web page on it 
and does not have a DNS A record. This is intended as it is an SRV 
host. pkg(8) knows how to properly use it.




That seems to raise the bar for people trying to check connectivity to 
it via ping/telnet.   Is that intentional?


-Alfred

___
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

update for print/cups-bjnp

[Alfred Perlstein]

Patch attached, confirmed to work on PCBSD 9.1.


Sorry if you get two of these, but I'm not sure if the send-pr web 
interface works.


--
Alfred Perlstein
VP Software Engineering, iXsystems

diff --git a/print/cups-bjnp/Makefile b/print/cups-bjnp/Makefile
index ae80739..9c25c5a 100644
--- a/print/cups-bjnp/Makefile
+++ b/print/cups-bjnp/Makefile
@@ -2,11 +2,11 @@
 # Date created:15 May 2009
 # Whom:sh...@sasktel.net
 #
-# $FreeBSD$
+# $FreeBSD: ports/print/cups-bjnp/Makefile,v 1.10 2012/11/17 06:00:48 svnexp 
Exp $
 #
 
 PORTNAME=  cups-bjnp
-PORTVERSION=   0.5.3
+PORTVERSION=   0.5.5
 PORTREVISION=  4
 CATEGORIES=print
 MASTER_SITES=  SF
diff --git a/print/cups-bjnp/distinfo b/print/cups-bjnp/distinfo
index 5892a5c..a39212d 100644
--- a/print/cups-bjnp/distinfo
+++ b/print/cups-bjnp/distinfo
@@ -1,2 +1,2 @@
-SHA256 (cups-bjnp-0.5.3.tar.gz) = 
9d369d6c561b81d91006675c4ad3c209548dc7aca63b39be3ffe7756b70dce04
-SIZE (cups-bjnp-0.5.3.tar.gz) = 117082
+SHA256 (cups-bjnp-0.5.5.tar.gz) = 
84373d666a73de462e7edaee605d6ec2569f15505cdb060cf8931c37b2020407
+SIZE (cups-bjnp-0.5.5.tar.gz) = 122011
___
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