Re: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)
On Wed, Dec 6, 2017 at 6:01 AM, Johan Hendriks
wrote:
>
>
> Op 06/12/2017 om 10:53 schreef Mathieu Arnold:
> > Le 05/12/2017 à 23:25, Baho Utot a écrit :
> >>
> >> On 12/05/17 17:09, Mathieu Arnold wrote:
> >>> Le 05/12/2017 à 10:53, Aryeh Friedman a écrit :
> >>>> TL;DR;
> >>>> Flavors 'ed up ports and there are no good ways/alternates
> >>>> for how
> >>>> to use the ports collection for normal everyday users/maintainers
> >>>
> >>> Thank you for supporting all the hard work and countless hours that so
> >>> many volunteers put in making the ports tree better.
> >>>
> >>> It really helps motivate all of us continue bringing the ports tree
> >>> forward when we get emails with so much joy and positive attitude.
> >>>
> >>>
> >> Thank you for taking a perfectly good system and breaking it as well
> >> as making it unusable, unstable. You just don't know of all the
> >> countless hours spent after running an update and taking a week to get
> >> it working again.
> >>
> >> It really helps motivate all of us users to continue to have to fix
> >> broken systems due to broken ports system and then be told how great
> >> things are, brings us so much joy and keeps our attitude positive.
> > For the users using binary packages, poudriere, or the ports tree
> > directly nothing changed.
> >
> > For users of third party abandonware, well, they were warned that it was
> > bound to happen at one point, and guess what, it happened. I don't
> > really understand why you continue spending all this time complaining
> > whereas switching to, say, poudriere, would have taken you about 5
> minutes.
>
Abandonware that until flavors *JUST WORKED* out of the box (no weird
configs/etc.)
Why was there not an Latest news item that the ports tree is going to
> receive flavour support in X days and that allmost all port tools will
> not work anymore, Why is there not an item that the ports tree is
> flavoured at this point?
>
This is the real problem for someone (like me) who just svn update and
portmaster -ad (after glancing through UPDATING to make sure there are no
weird issues) the note in UPDATING was the *FIRST TIME* I had ever heard of
flavors and it contained absolutely no info on how to migrate to it besides
a totally useless:
" Ports using Python via USES=python are now flavored. All the py3-* ports
have been removed and folded into their py-* master ports.
People using Poudriere 3.2+ and binary packages do not have to do
anything.
For other people, to build the Python 3.6 version of, for example,
databases/py-gdbm, you need to run:
# make FLAVOR=py36 install"
Says nothing at all about what flavors are, how they effect anything but
py-* and/or that they are a fundimental architural change.No pointers
to learn more. It reeks of the opening sequence of the Outer Limits ("we
control the vertical, we control the horizontal,...") or something from
Orwell or Trump.
BTW I am slightly more then a casual user of FreeBSD (see interview in Fen.
2017 BSD Magazine) and I found it confusing.
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: Flavors *COMPLETELY* break the port system (synth and poudriere are useless)
On Tue, Dec 5, 2017 at 1:22 PM, Jonathan Chen wrote: > On 5 December 2017 at 22:53, Aryeh Friedman > wrote: > [...] > > 2. I installed synth (2.00) and *ATTEMPTED* to do a upgrade-system with > the > > following results (still not a successful run): > > > > a. Hard freezes the machine (not even a kernel panic) 4 times in a > row > > synth runs parallel builds using multi-workers, and it can trash the > hard disk pretty hard as it uses swap for tmpfs. Reduce the number of > workers and/or jobs if you intend using the box during a build. > > 2 of the hard freezes came after reducing the number of workers to 1 (from 3) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
Flavors *COMPLETELY* break the port system (synth and poudriere are useless)
First some background (my typical use cases for ports):
0. FreeBSD lilith 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321664: Fri Jul 28
23:35:18 EDT 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64
1. Daily routine (current):
cd /usr/src
svn update (from 11.1-RELEASE)
[make -DESTDIR=/ world kernel&&etcupdate&&reboot as needed]
cd /usr/ports
svn update (from HEAD)
portmaster -ad
[reboot if any Xorg/xfce or stuff in rc.d got modified]
2. I maintain devel/aegis (which as per Bug 219284 does not compile with
anything greater then GCC 5 [I don't have time to figure out how to patch
it is make it work {the upstream maintainer died a few years ago}]).
So what happens when I see UPDATING 20171130:
1. I decide to try poudriere since it seems to what people are raving
about. What a 'ing confusing mess it is use After deciding it
is over kill I go to option 2
2. I installed synth (2.00) and *ATTEMPTED* to do a upgrade-system with the
following results (still not a successful run):
a. Hard freezes the machine (not even a kernel panic) 4 times in a row
b. Skips devel/aegis recompile because it can't understand the makefile
or something (see above). *BUT* gives no clues as to why and gives me
nothing actionable on how to repair the port
3. The suggestion of using plainly old make install on each port is
unworkable because it is fundamentally error prone with my daily use case.
TL;DR;
Flavors 'ed up ports and there are no good ways/alternates for how
to use the ports collection for normal everyday users/maintainers
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
How to suppress boot up messages from sysutils/automount
When I boot I get a lot of junk messages (hints about how to configure it)
form sysutils/automount while I want to keep automount in the startup I
want to suppress these messages -- how?
Note without both settings below it does not automount my flash drive
(da4)... also coping /usr/local/etc/automount.conf.sample to
/usr/local/automount.conf (with appropriate edits) doesn't make the
messages go away:
I have the following in my rc.conf:
autofs_enable="YES"
and the following in devd.conf:
# Discard autofs caches, useful for the -media special map.
notify 100 {
match "system" "GEOM";
match "subsystem" "DEV";
action "/usr/local/sbin/automount -c";
};
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
best way to handle GCC version detection
I have port I maintain that compiles fine under GCC 5 (or lower) but barfs on GCC 6. A small modification will make it compile under 6 but the very same modification makes it incompatible with 5. What is the best way to handle this and still allow USE_GCC=any ? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: pkgconfig fails to configure on 12-CURRENT
Six hours slow but the right date: aryehl@rain:/home/aryehl% date Sun Feb 26 00:55:11 EST 2017 Here is the date from a machine I know to be accurate: aryehl@lilith:/home/aryehl/Desktop% date Sun Feb 26 06:04:32 EST 2017 On Sun, Feb 26, 2017 at 5:32 AM, Baptiste Daroussin wrote: > On Sat, Feb 25, 2017 at 08:08:28PM -0500, Aryeh Friedman wrote: > > FreeBSD rain 12.0-CURRENT FreeBSD 12.0-CURRENT #93 r314227: Fri Feb 24 > > 13:51:55 EST 2017 root@rain:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > ===> Fetching all distfiles required by pkgconf-1.3.0 for building > > ===> Extracting for pkgconf-1.3.0 > > => SHA256 Checksum OK for pkgconf-1.3.0.tar.xz. > > ===> Patching for pkgconf-1.3.0 > > ===> Configuring for pkgconf-1.3.0 > > configure: loading site script /usr/ports/Templates/config.site > > checking for gcc... cc > > checking whether the C compiler works... yes > > checking for C compiler default output file name... a.out > > checking for suffix of executables... > > checking whether we are cross compiling... no > > checking for suffix of object files... o > > checking whether we are using the GNU C compiler... yes > > checking whether cc accepts -g... yes > > checking for cc option to accept ISO C89... none needed > > checking whether cc understands -c and -o together... yes > > checking for strlcpy... (cached) yes > > checking for strlcat... (cached) yes > > checking for strndup... (cached) yes > > checking for cygwin_conv_path... no > > checking how to run the C preprocessor... cpp > > checking for grep that handles long lines and -e... (cached) > /usr/bin/grep > > checking for egrep... (cached) /usr/bin/egrep > > checking for ANSI C header files... (cached) yes > > checking for sys/types.h... (cached) yes > > checking for sys/stat.h... (cached) yes > > checking for stdlib.h... (cached) yes > > checking for string.h... (cached) yes > > checking for memory.h... (cached) yes > > checking for strings.h... (cached) yes > > checking for inttypes.h... (cached) yes > > checking for stdint.h... (cached) yes > > checking for unistd.h... (cached) yes > > checking for sys/stat.h... (cached) yes > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether build environment is sane... configure: error: newly > > created file is older than distributed files! > > Check your system clock > > The message here is telling you to check your clock have you checked it? > > This is a regular test from autotools which ensure that produced binaries > are > newer that the timestamp of the sources which appears to not be the case > in your > system. > > Best regards, > Bapt > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
pkgconfig fails to configure on 12-CURRENT
FreeBSD rain 12.0-CURRENT FreeBSD 12.0-CURRENT #93 r314227: Fri Feb 24 13:51:55 EST 2017 root@rain:/usr/obj/usr/src/sys/GENERIC amd64 ===> Fetching all distfiles required by pkgconf-1.3.0 for building ===> Extracting for pkgconf-1.3.0 => SHA256 Checksum OK for pkgconf-1.3.0.tar.xz. ===> Patching for pkgconf-1.3.0 ===> Configuring for pkgconf-1.3.0 configure: loading site script /usr/ports/Templates/config.site checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking whether cc understands -c and -o together... yes checking for strlcpy... (cached) yes checking for strlcat... (cached) yes checking for strndup... (cached) yes checking for cygwin_conv_path... no checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... (cached) /usr/bin/egrep checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking for sys/stat.h... (cached) yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... configure: error: newly created file is older than distributed files! Check your system clock ===> Script "configure" failed unexpectedly. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: problems building vim:
On Sun, Feb 12, 2017 at 9:04 AM, Jochen Neumeister wrote: > There is an open PR for this Problem: https://bugs.freebsd.org/bugzi > lla/show_bug.cgi?id=217024 > > An interesting hint is it built and installed correctly on a an other machine with the same updates but does not have xorg installed. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
problems building vim:
root@lilith:/usr/ports/editors/vim # freebsd-version && uname -a 11.0-STABLE FreeBSD lilith 11.0-STABLE FreeBSD 11.0-STABLE #43 r313632: Sat Feb 11 03:42:05 EST 2017 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64 root@lilith:/usr/ports/editors/vim # make distclean clean deinstall root@lilith:/usr/ports/editors/vim # make install ===> Installing for vim-8.0.0325 ===> Checking if vim already installed ===> Registering installation for vim-8.0.0325 pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/bin/gvimtutor: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/gvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/gvimdiff.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/rgview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr/man1/rgvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/gvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/gvimdiff.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/rgview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.ISO8859-1/man1/rgvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/gvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/gvimdiff.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/rgview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/fr.UTF-8/man1/rgvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/gvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/gvimdiff.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/rgview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it/man1/rgvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/gvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/gvimdiff.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/rgview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.ISO8859-1/man1/rgvim.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.UTF-8/man1/eview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.UTF-8/man1/gview.1.gz: No such file or directory pkg-static: Unable to access file /usr/ports/editors/vim/work/stage/usr/local/man/it.UTF-8/man1/gvim.1.gz: No such file or directory pkg
Re: upgrade to devel/dbus breaks xfce4
On Wed, Nov 30, 2016 at 3:28 PM, Kevin Oberman wrote: > On Wed, Nov 30, 2016 at 11:42 AM, Aryeh Friedman > wrote: > >> On Wed, Nov 30, 2016 at 9:11 AM, Raphael Kubo da Costa < >> rak...@freebsd.org> >> wrote: >> >> > Aryeh Friedman writes: >> > >> > > After upgrading deval/dbus to dbus-1.10.12 xfce4 fails to start as a >> > > non-root user due to being unable to open/write to /etc/machine-id. I >> > > made a tempurary fix by touching /etc/machine-id and chmod'ing it to >> > > 777. >> > >> > If the /etc/machine-id message you're getting looks like >> > >> > D-Bus library appears to be incorrectly set up; failed to read >> > machine uuid: Failed to open "/etc/machine-id": No such file or >> > directory >> > >> > it may be misleading as /etc/machine-id is a fallback if other files >> > were not found before (see bug 213540, for example). >> > >> > Is dbus running when you try to launch XFCE? >> > >> >> That is the message I got... it was immediately after boot and dbus was >> not >> running (it asked for a onestart when I attempted to manually start it). >> My .xinitrc is as follows: >> >> xfce4-session >> >> >> >> -- >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >> > > To ask a dumb question, do you have 'dbus_enable="YES"' in /etc/rc.conf? > It looks like the dbus daemon is not running and, when it tries to run from > xfce, it lacks the privs needed. Perhaps the protections were adjusted in > the new version of dbus. > I am using what ever the defaults are but I suspect since I had to use onestart it was not enabled (before the update this was not needed). > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: upgrade to devel/dbus breaks xfce4
On Wed, Nov 30, 2016 at 9:11 AM, Raphael Kubo da Costa wrote: > Aryeh Friedman writes: > > > After upgrading deval/dbus to dbus-1.10.12 xfce4 fails to start as a > > non-root user due to being unable to open/write to /etc/machine-id. I > > made a tempurary fix by touching /etc/machine-id and chmod'ing it to > > 777. > > If the /etc/machine-id message you're getting looks like > > D-Bus library appears to be incorrectly set up; failed to read > machine uuid: Failed to open "/etc/machine-id": No such file or > directory > > it may be misleading as /etc/machine-id is a fallback if other files > were not found before (see bug 213540, for example). > > Is dbus running when you try to launch XFCE? > That is the message I got... it was immediately after boot and dbus was not running (it asked for a onestart when I attempted to manually start it). My .xinitrc is as follows: xfce4-session -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
upgrade to devel/dbus breaks xfce4
After upgrading deval/dbus to dbus-1.10.12 xfce4 fails to start as a non-root user due to being unable to open/write to /etc/machine-id. I made a tempurary fix by touching /etc/machine-id and chmod'ing it to 777. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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"
port collection severally broken on 11-STABLE (it also breaks make world)
On FreeBSD lilith 10.3-STABLE FreeBSD 10.3-STABLE #0 r307694: Fri Oct 21 00:10:20 EDT 2016 root@lilith:/usr/obj/usr/src/sys/GENERIC amd64 In order to install java/openjdk8 and devel/subversion I had to install the following as packages instead of compiling it from source also make world also is broken (not before) the attempt to install openjdk8 (see below package listing for makeworld output): gettext db5 boehm-gc pcre gmp binutils jsoncpp cmake ninja llvm37 libclc gnutls cups openjdk openjdk8 root@lilith:/usr/src # make DESTDIR=/ world kernel -- >>> make world started on Fri Oct 21 02:27:38 EDT 2016 -- -- >>> World build started on Fri Oct 21 02:27:39 EDT 2016 -- -- >>> Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp/legacy/usr/include rm -f /usr/obj/usr/src/usr.bin/kdump/ioctl.c rm -f /usr/obj/usr/src/usr.bin/kdump/kdump_subr.c rm -f /usr/obj/usr/src/usr.bin/truss/ioctl.c mkdir -p /usr/obj/usr/src/tmp/lib mkdir -p /usr/obj/usr/src/tmp/usr mkdir -p /usr/obj/usr/src/tmp/legacy/bin mkdir -p /usr/obj/usr/src/tmp/legacy/usr mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.groff.dist -p /usr/obj/usr/src/tmp/legacy/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/obj/usr/src/tmp/usr >/dev/null mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/tmp/usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/tmp -- >>> stage 1.1: legacy release compatibility shims -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.3-STABLE amd64 1003509" MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" COMPILER_TYPE=clang make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1003509 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED _BOOTSTRAP_MAKEINFO=yes -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD -DNO_TESTS legacy ===> tools/build (obj,includes,depend,all,install) set -e; cd /usr/src/tools/build; make buildincludes; make installincludes cc -O2 -pipe -I/usr/src/tools/build/../../contrib/libc-pwcache -I/usr/src/tools/build/../../lib/libc/include -std=gnu99 -I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/tools/build/../../contrib/libc-pwcache/pwcache.c -o pwcache.o building static egacy library ranlib -D libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/tmp/legacy/usr/lib -- >>> stage 1.2: bootstrap tools -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/tmp VERSION="FreeBSD 10.3-STABLE amd64 1003509" MAKEFLAGS="-m /usr/src/tools/build/mk -m /usr/src/share/mk" COMPILER_TYPE=clang make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1003509 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DNO_PROFILE -DNO_SHARED _BOOTSTRAP_MAKEINFO=yes -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD -DNO_TESTS bootstrap-tools ===> lib/clang/libllvmsupport (obj,depend,all,install) c++ -O2 -pipe -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.3\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.3\" -DDEFAULT_SYSROOT=\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp -o APFloat.o In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: In file included from /usr/src/lib/clang/libllvmsupport/../.
best way to add www to wheel
I have the following line in my pkg-install: pw groupmod wheel -m www The reason is I have files that are created by a user account that also gets made but are modified using it or tomcat... these particular files are shell scripts that must run as root (they are for controlling bhyve and other hyperv's as well as other rootly things like setting up and tarring down nic's) keep in mind also since almost all user level commands (including those that trigger rootly actions) are run via the web and that the data (except actual web content) should not be owned by www My gut says that the above while it works is almost certainly not the right way to do it. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
Sorry was just putting why I used the mentioned ports in context (I believe in real life examples instead of made up ones for that)... any other mention of it in the thread was only because it was a convenient example that didn't violate an nda or something else. On Mon, Jan 27, 2014 at 11:29 AM, Lars Engels wrote: > Am 2014-01-25 05:30, schrieb Aryeh Friedman: > > On Fri, Jan 24, 2014 at 11:16 PM, 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.) >>> >> >> >> Nice to be able to plug something other then petitecloud as a possible >> solution to this... namely as far I can tell from previous discussions and >> such that the port system is nothing more then a very large DAG (directed >> acyc. graph) the author of devel/cook (and devel/aegis) wrote an >> incredible >> paper showing why Make (in any form) will never be upto the task ( >> http://aegis.sourceforge.net/auug97.pdf )... there are several solutions >> that use this paper as their foundation in the ports system (devel/cook, >> devel/cons, devel/scons)... don't get me wrong the actual building of >> each >> port should be delegated to whatever build scripts it uses the idea is >> only >> that the entire port system be considered as a single graph... side note >> we >> use devel/cook and devel/aegis to maintain and build petitecloud on. >> > > Aryeh, > > would you please stop spamming about petitecloud in _every single_ mail > you're > sending to some list? > > Thank you. > > Lars > > ___ > 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" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Mon, Jan 27, 2014 at 1:59 AM, Alfred Perlstein wrote: > > On 1/26/14, 10:56 PM, Aryeh Friedman wrote: > > > On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein wrote: > >> >> 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". >> > > 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! > Again not 100% correct. it does require you to have githup-like functionality (githup or a clone of it) if you want to do any sort of distributed repos... aegis does not (all of its distributions are in normal formats like tar.gz and patches [these are automatically generated on demand])... and more importantly your solution seems to revolve around requiring the use of a tool over the model that it enforces (which can be done by many different tools) have you ever heard of making your requirements technology neutral and *THEN* seeing what techs (if any) fit the bill... this is how we found aegis in the first place... in some cases we may find (and I think the current port system may be one of these cases) that no new tools are needed; all that is needed is the reorganizing of existing manual procedures (which can then later be automated if desired). >* 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! > I at least took the time to check what GitHub could do and what it and what it couldn't... this is just common sense when criticizing something -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Mon, Jan 27, 2014 at 12:40 AM, Alfred Perlstein wrote: > > 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". > 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). * 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." -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Sun, Jan 26, 2014 at 10:00 PM, Alfred Perlstein wrote: > > 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. > I don't hate everything that's popular. For example, I use various popular applications such as Open Office and xfce, and I use Java. What I hate is stuff that doesn't work as advertised, no matter how popular. If popularity and hordes of "code monkeys" (as you insultingly call them) are so important to you, then why are you using FreeBSD instead of Windows? Better yet, if you like newness, how about Windows 8? > What I am interested in is: > > 1) leveraging the hordes of people that can submit changes to the project > because they know git. > This is a non-issue because, even if the ports team uses aegis and cook, the average port maintainer can still use svn and makefiles or whatever build tools they like. So the only important question here is whether aegis and cook can save a lot of time and trouble for the ports team specifically. > 2) leveraging the existing tooling that's available for FREE!!! for us to > use. (instead of rewriting wheels). > Perhaps you missed this, but aegis and cook are both free and open source (GPL). 3) reducing the overhead of contribution to our project by using existing > solutions and not requiring accounts to be made. > Even more reason NOT to go with something that is relatively new and largely untested in mission critical applications. Aegis, though not popular, is used in not just mission-critical but life-critical applications, i.e. things that absolutely must work the first time and every time. For example, one aegis user is St. Jude Medical. Have you actually installed and tested aegis are you just bad mouthing it? The reason for asking is it was designed on purpose to be a plug-gable architecture... namely all aegis does except for enforcing the dev/review/integrate cycle is act as a glue for *EXISTING* tools (see the manual for a full list of ones supported out the box and the requirements new ones must meet [note cook is used not make only because make is not powerful enough to take full advantage of aegis] > So what would using this aegis system buy us? > See http://osdir.com/ml/version-control.aegis.user/2005-05/msg1.htmlfor a discussion of using it in linux kernel development > 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. > Why does an internal version control system need any kind of web hosting at all? Be that as it may, aegis does have a web front end -- including RSS feed and other XML output -- as well as its command line interface. > It's not about NEW THINGS, although NEW THINGS tend to lead to better > systems... it's more about leveraging users and existing facilities. > ?!?!?!?!? How the does forcing everyone to learn something new every 6 months lead to the ability to leverage existing users and facilities... maybe my logic is faulty but isn't this almost a guarantee that no one will know what they are talking about because stuff moves too fast for them to keep up? I would rather see a list (even if a small list) of solid users who all use the system for mission critical apps (like hospitals). > Anyhow, it's not important, you want your toy, even though no one uses it. > Enjoy it. :) > For a list of some aegis users (every single one uses it for mission critical systems) see http://aegis.sourceforge.net/propaganda/sites.html > > 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 Aegis itself does not require scripts, although it can be used to encapsulate scripts. Every routine action (including distribution of baselines) is already encapsulated into a single command that typically requires only one or two arguments, in contrast to the much more complicated command lines associated with github's api (via cURL). For example, we use the following command line to create a new release of petitecloud: aeb cook-blank/deploy-remote and a normal everyday build requires just: aeb 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. > If having a million "code monkeys" is the mark of a good system, does this mean you regard healthcare.gov as a supreme master piece of softw
Re: What is the problem with ports PR reaction delays?
) > > > 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? -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
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) On Sun, Jan 26, 2014 at 1:31 PM, Aryeh Friedman 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 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 >> >wrote: >>> >>>On 1/26/14 5:25 AM, Big Lebowski wrote: >>>> >>>> >>>> >>>> >>>> On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein 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 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
Re: What is the problem with ports PR reaction delays?
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 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 > >wrote: >> >>On 1/26/14 5:25 AM, Big Lebowski wrote: >>> >>> >>> >>> >>> On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein 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 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. >>>> >>&
Re: What is the problem with ports PR reaction delays?
just do us a favor and do not assume newer means better... On Sun, Jan 26, 2014 at 1:18 PM, Alfred Perlstein wrote: > On 1/26/14 5:25 AM, Big Lebowski wrote: > > > > > On Sun, Jan 26, 2014 at 4:20 AM, Jim Ohlstein 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 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
Re: What is the problem with ports PR reaction delays?
> > 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. > The reason for the whole tangent was the observation that large number of the pending PR's are likely to fail one or more *BASIC* tests and setting stuff up to run those tests is trivial (like I said I voluneteer to do it)... the other main thread there was that some of the *IDEAS* of SCM can borrowed and incorporated into manual procedures (such as requiring a successful build before a human will look at it) the other one is a more formalized workflow such as the one that aegis enforces if just the first is done I think half the PR's can be cleared out immediately and if both then 80% can be cleared out within a few weeks -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
I never said our selves it is outsourced to the developer/maintainer with
> 100% automated stuff... once I am doing with the next small version of
> petitecloud I will post the 6 line script we use to test the port
> (including cranking up a few vm's)... have fun doing that anywhere else
>
>
Got bored here is the non-cleaned up version (it is for devel/cook and not
the shell):
cook-blank/deploy-remoteinstall: cook-blank/scrap-all
{
echo Remote install;
remoteIp=aryeh@10.0.10.30;
ssh [remoteIp] sudo rm -rf '"*"';
scp scrap/predeploy/port-[realversion]-[user].tar.gz
[remoteIp]':'port.tar.gz;
scp scrap/predeploy/src-[fullproject].tar.gz
[remoteIp]':'src-[fullproject].tar.gz;
ssh [remoteIp] sudo mv src-[fullproject].tar.gz
/usr/ports/distfiles;
ssh [remoteIp] sudo rm -rf /usr/ports/emulators/petitecloud;
ssh [remoteIp] sudo tar fvx port.tar.gz;
ssh [remoteIp] sudo make deinstall clean install;
}
Doesn't that look a lot easier then what you where talking about?
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Sat, Jan 25, 2014 at 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 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. > I am sorry your the one who does not get it.. not everything is either testable remotely or should be... how do you propose to test device drivers for example? > Why? Because then we offload the problem to another org. > With a hybrid cloud with most of the work being done on the commiters/developers machine where is the overhead? > > The FreeBSD project should be about innovation in OS design, platform and > software. Ops work is bunk and just slows us down. > Sorry to tell you but the ability to handle a complex automated system is one of the key things a OS must do... what better test then to build it self? > > The more we can outsource the better we'll be. (and what if that service > blows up? well we move on! it's simple!) > What a total cop out if the service blows up fix it... or should we end up with some of the real atrocities of linux like I/O times that are impossible (claiming it takes less then a second to copy 10GB for example)... note the above timing issue it makes resource scheduling next to impossible in a distributed environment if you get different timings for the same operation... bottom line writing and maintain a OS *IS* about operations and nothing else. > 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 never said our selves it is outsourced to the developer/maintainer with 100% automated stuff... once I am doing with the next small version of petitecloud I will post the 6 line script we use to test the port (including cranking up a few vm's)... have fun doing that anywhere else > > -Alfred > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Sat, Jan 25, 2014 at 6: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. > Git hup (or *ANY* remote service for that matter) is a no go IMO > > 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. > That's why I keep suggesting devel/aegis it does *EVERYTHING* git/git hub does but all locally and has the added benefit that you can not change the change set (aka port submission) until it has passed all 3 of the following (you can turn all but the last two off at runtime and the first only needs to build to pass at a min): 1. Develop change (To leave development it must build and pass *NEW* tests, this is where the automation should go) 2. Review (this is where human eyes come in once all the automated tests are passed) 3. Intergration make sure it plays well with others -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Sat, Jan 25, 2014 at 5:28 PM, Yuri wrote: > On 01/25/2014 05:43, Bernhard Fröhlich wrote: > >> With the scripts it should be possible to fetch the patch of a PR, apply >> and commit it to your redports repository and do additional changes until >> you are okay with it. What is still missing is a script that helps >> committing the changes to the FreeBSD tree but it's really not that >> complicated to write that. >> > > This sounds like a very manual process again. Today it is already manual. > This only automates the patching step. > > > be more specific and name the problem, if you mentioned it? >> >> The raised concerns were that automatic build testing might result in less >> testing on committer side. I agree that this might happen and automatic >> build testing is only one part of what committers need to do. A huge >> backlog and no response for months is definitely nothing we want. >> > > But what exactly do committers test that can't be automated? Automatic > system could install the port with dependencies into the blank > installation, check syntax correctness, run 'lint' on it, verify that it > installs/uninstalls cleanly and doesn't leave residue, etc etc. What is > beyond that? > I am trying to understand, what would the general ports expert without the > intimate knowledge of this particular package catch, that automated system > won't be able to catch? > 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 > > Yuri > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fwd: What is the problem with ports PR reaction delays?
-- Forwarded message -- From: Aryeh Friedman Date: Sat, Jan 25, 2014 at 12:34 PM Subject: Re: What is the problem with ports PR reaction delays? To: John Marino > You are solving the wrong problem. > And nobody is "reinventing" anything, which is weird to say because > GNATS is far older than git and github. The tool set, archaic or not, > is not presenting any kind of bottleneck. > It should be trivial to see if a port at least builds and that can be automated I am willing to bet 80% of new ports will not pass this test on the first try and thus 80% of the back log can eliminated right away > > 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" > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
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. > devel/tailor was designed specifically for this case (the actual case it does is aegis <---> svn) but same basic idea -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
> By the way, this wasn't about switching to git (although that would be > nice), this is about leveraging existing tools. > > One can very easily use git-svn bridge to push git changes into > subversion. Or you can try to re-implement a patch queue based system > yourself using a bunch of duct tape and bailing wire and likely get > frustrated and either never complete it OR complete it and it's just not > even half as good as git as a patch manager. > > Use the existing tools. > > I implore you to explore the idea of using existing tools to solve the > problem, or at least solve a part of the problem, instead of trying to > reinvent functionality that already exists devel/tailor (which I maintain but never used) is designed to automatic convert repos from one scm to an other this might be the best solution... also I think the devel/aegis model of develop-->test-->review-->integrate (which is built in by default but can be turned of or configured) might help here (no need for changing tools unless we want to since most of this is procedural) the basic model is: 1. One person develops 2. An other reviews 3. Yet an other intergates I think the first 2 is what we need to focus on. Namely when a new port comes it is assigned a perm reviewer/integrator (aka comitter) and all changes to that port from hence forth have that person as the assigned comitter -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fwd: What is the problem with ports PR reaction delays?
On Sat, Jan 25, 2014 at 3: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. This creates a "n+1" problem (something that jails are not advanced enough to completely solve but cloud computing can) just for definitional shake a n+1 problem is based on the observation for all computer professionals (and hobbyists) always need at least one more "machine" then they currently have (this plus some techincal issues with OpenStack [Grizzly don't know if Havana fixes them]) is/was the primary motivator behind petitecloud in the first place... to that end any such system would need to set up and tare down VM's quickly as well keep a large number of them off line but for ready running... as far as testing goes the general method suggested in the paper I gave and eleberated in the Aegis user guide is a good starting place (it is especially good about making sure bugs stay fixed). -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Fri, Jan 24, 2014 at 11:16 PM, 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.) Nice to be able to plug something other then petitecloud as a possible solution to this... namely as far I can tell from previous discussions and such that the port system is nothing more then a very large DAG (directed acyc. graph) the author of devel/cook (and devel/aegis) wrote an incredible paper showing why Make (in any form) will never be upto the task ( http://aegis.sourceforge.net/auug97.pdf )... there are several solutions that use this paper as their foundation in the ports system (devel/cook, devel/cons, devel/scons)... don't get me wrong the actual building of each port should be delegated to whatever build scripts it uses the idea is only that the entire port system be considered as a single graph... side note we use devel/cook and devel/aegis to maintain and build petitecloud on. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
I would be willing to help write some scripts to start/stop the VM's (PetiteCloud does a command line that will be better documented and such in the next version or two) On Fri, Jan 24, 2014 at 6:58 PM, Big Lebowski wrote: > > > > On Sat, Jan 25, 2014 at 12:45 AM, Aryeh Friedman > wrote: > >> >> >> >> On Fri, Jan 24, 2014 at 6:30 PM, Big Lebowski wrote: >> >>> Hi everyone, >>> >>> I wanted to ask about the growing time of reaction to ports PR's - what >>> is >>> the problem? It seems to me, as a ports contributor, that this time is >>> only >>> growing, not shrinking, and there's no formal/automated procedures that >>> would help in managing the issue. >>> >>> Today I found myself fighting with ezjail only to discover it has issues >>> working on FreeBSD 10.0-R. Great, I thought, there must be something >>> else, >>> so I went to make the research. It appears there isnt much more, and the >>> alternatives are qjail that seems to be quite dated and zjails, that's >>> not >>> in ports. Not long after looking into zjails, what seems to be a great >>> tool, I found its port submission sits there since... September 2013. >>> Now, >>> given the fact the Docker is on mouth of everyone, and containers are >>> getting a lot of attention, FreeBSD looks really bad with no tools to >>> manage such great technology like Jails, especially when ezjail, >>> unofficial >>> industry standard to manage jails, is now broken and zjails waits to be >>> accepted (or even rejected) for so much time. >>> >>> >> Why not test on a VM instead of a jail it seems this is a even more >> accurate test because you can run bare metal installs (I have run to some >> ports [including some of my own]) that worked with jail/tinderbox but >> failed a full bare metal install. Take a look at -virtualization@ for >> ideas, the proposed handbook entry on virtualization ( >> http://www.petitecloud.org) or just use a front end like petitecloud >> (yes yet an other port waiting for comitting [one this one there are some >> bugs though]) >> >> What is the problem? Isnt there enought commiters? Isnt there a automated >>> PR handling procedure reminding commiters with relevant access about such >>> submissions? Can we help? I hope to spark some discussion. >>> >> >> I have made a couple of scripts for automated this for specific ports but >> not for all (the VM test method)... if you want I can post them (they are >> high;y specific to installing the petitecloud port though) >> > >> -- >> Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org >> > > I think you've got me wrong - I am following freebsd-virtualization list > very closely, and the matter I've touched here is not my doubt on which > technology I should use, but rather a complaint on the state of jails > related tools directly leading to the delays in handling of ports related > PR's. I know the technology alternatives, I am decided to jails for a > reason, and I also know your work on the web interface focusing on bhyve, > but its not about it. > > B. > -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
> > I think you've got me wrong - I am following freebsd-virtualization list > very closely, and the matter I've touched here is not my doubt on which > technology I should use, but rather a complaint on the state of jails > related tools directly leading to the delays in handling of ports related > PR's. I know the technology alternatives, I am decided to jails for a > reason, and I also know your work on the web interface focusing on bhyve, > but its not about it. > My point is writing scripts for VM's is easier (nothing more then copy the master and then do a normal make install/portmaster on the port of you choice [better to run them one at a time I have found). When I get into port testing I usually have 3 VM's on the host working on compiling and 1 for development. I have yet to find a good way to have 4 jails running as independentlu. -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: What is the problem with ports PR reaction delays?
On Fri, Jan 24, 2014 at 6:30 PM, Big Lebowski wrote: > Hi everyone, > > I wanted to ask about the growing time of reaction to ports PR's - what is > the problem? It seems to me, as a ports contributor, that this time is only > growing, not shrinking, and there's no formal/automated procedures that > would help in managing the issue. > > Today I found myself fighting with ezjail only to discover it has issues > working on FreeBSD 10.0-R. Great, I thought, there must be something else, > so I went to make the research. It appears there isnt much more, and the > alternatives are qjail that seems to be quite dated and zjails, that's not > in ports. Not long after looking into zjails, what seems to be a great > tool, I found its port submission sits there since... September 2013. Now, > given the fact the Docker is on mouth of everyone, and containers are > getting a lot of attention, FreeBSD looks really bad with no tools to > manage such great technology like Jails, especially when ezjail, unofficial > industry standard to manage jails, is now broken and zjails waits to be > accepted (or even rejected) for so much time. > > Why not test on a VM instead of a jail it seems this is a even more accurate test because you can run bare metal installs (I have run to some ports [including some of my own]) that worked with jail/tinderbox but failed a full bare metal install. Take a look at -virtualization@ for ideas, the proposed handbook entry on virtualization ( http://www.petitecloud.org) or just use a front end like petitecloud (yes yet an other port waiting for comitting [one this one there are some bugs though]) What is the problem? Isnt there enought commiters? Isnt there a automated > PR handling procedure reminding commiters with relevant access about such > submissions? Can we help? I hope to spark some discussion. > I have made a couple of scripts for automated this for specific ports but not for all (the VM test method)... if you want I can post them (they are high;y specific to installing the petitecloud port though) -- Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.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: why are new ports taking so long to commit
Only in that a earlier version I submitted last fall (which needed to be reworked) got looked at in 2 days... On Mon, Jan 13, 2014 at 5:18 PM, John Marino wrote: > On 1/13/2014 23:05, Aryeh Friedman wrote: > > I submitted ports/185362 and ports/185361 over a week ago and I have > heard > > nothing but automated replies so far. > > > > There are 180 Open PRs just with the words "new port" in the title: > > http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports&severity=&priority=&class=&state=&sort=none&text=new+port&responsible=&multitext=&originator=&release= > > Most of them have 2013 opening dates. Do you still think that it's > strange that you haven't heard anything in a week? (a week following a > major holiday btw) > > 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" > ___ 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"
why are new ports taking so long to commit
I submitted ports/185362 and ports/185361 over a week ago and I have heard nothing but automated replies so far. ___ 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: Staging break user account modification in post-install
On Sun, Nov 10, 2013 at 2:59 PM, olli hauer wrote: > On 2013-11-10 20:40, Aryeh Friedman wrote: > > post-install is now called *BEFORE* users are created (before staging was > > added it was after)... looking at bsd.port.mk there seems no reasonable > > target that replaces post-install for this purpose. Namely I need to > lock > > the user account that was created and assign a default password to it. > > This is what I had that used to work: > > > > post-install: > > echo password|pw usermod user -h 0 2>/dev/null > > pw lock user > > Is the account always locked? > No it is locked/unlocked by a WebUI when ever the user needs to perform some task that is requires streaming stdio (i.e. the WebUI will say "To complete task X do the following in a terminal 'ssh user@localhost' and the WebUI will do what ever juggling is needed to make it so X is performed on the next login into user [including unlocking the account] when tsak X completes it locks the account [in reality we do it before] again). > If yes what is the difference to create a user without any password and > assigning '/usr/sbin/nologin' as shell? > > What happens to the account without staging if installed from a package? > Right now we are doing remote testing (different machine then the development one) via the port and thus have disabled pkg creation and thus need to do it before this. ___ 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"
Staging break user account modification in post-install
post-install is now called *BEFORE* users are created (before staging was added it was after)... looking at bsd.port.mk there seems no reasonable target that replaces post-install for this purpose. Namely I need to lock the user account that was created and assign a default password to it. This is what I had that used to work: post-install: echo password|pw usermod user -h 0 2>/dev/null pw lock user ___ 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: full documentation for all @'s in pkg-plist
What has replaced it and where is it documented? (our port is for 10+ [requires bhyve]) On Sun, Nov 10, 2013 at 6:48 AM, Tijl Coosemans wrote: > On Sun, 10 Nov 2013 01:05:15 +0100 Julien Laffaye wrote: > > On 11/10/2013 12:47 AM, Aryeh Friedman wrote: > >> Where would I find a complete list of @'s allowed in pkg-plist and > >> hopefully an explination of each one? (the porter's handbook is > incomplete) > > > > In the manpage pkg_create(1). > > It has been removed in FreeBSD 10 though, so it would be nice to have > the info in the handbook as well. Same for all the %D, %B, etc. > ___ 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"
proper place to lock user account in port
right now I have: post-install: pw lock user under staging this is now called before the user is made what target should I move this to? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: how to tell pkg-list not to deinstall/overwrite certain files
Thanks the stuff worked there but it is not clear how to handle user dirs (don't nuke dirs withi user data for example we create /usr/local/vms and it should not be erased on deinstall) On Fri, Nov 8, 2013 at 6:13 AM, Tijl Coosemans wrote: > On Fri, 8 Nov 2013 05:23:47 -0500 Aryeh Friedman wrote: > > Forgot to mention the solution should if at all possible be 100% > pkg-plist > > based because our internal build system is not make > > > > On Fri, Nov 8, 2013 at 5:21 AM, Aryeh Friedman >wrote: > >> I am doing a lot of inter-machine testing of a private port (will be > >> released soon as a actual port) but need to tell "make deinstall" not to > >> delete a certain file... how do we do this?... background one thing we > are > >> testing is the ability to upgrade the port (privately) and it must not > nuke > >> our settings file on the test machines because the default config > provided > >> by our port is inappropriate for how we have things configured (it is > >> correct for 99.9% of everyone else though). > >> > >> Namely we need: > >> > >> 1. Do not delete /usr/local/etc/petitecloud/settings on deinstall > >> 2. Do not overwrite it with a new version on install (if present else > >> install it) > > Basically you have to install the file as settings.sample and add some > pkg-plist magic. It's explained in more detail here: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/plist-config.html > > Note that with staging you don't need the post-install part, only the > pkg-plist part. > ___ 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"
full documentation for all @'s in pkg-plist
Where would I find a complete list of @'s allowed in pkg-plist and hopefully an explination of each one? (the porter's handbook is incomplete) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: how to tell pkg-list not to deinstall/overwrite certain files
Forgot to mention the solution should if at all possible be 100% pkg-plist based because our internal build system is not make On Fri, Nov 8, 2013 at 5:21 AM, Aryeh Friedman wrote: > I am doing a lot of inter-machine testing of a private port (will be > released soon as a actual port) but need to tell "make deinstall" not to > delete a certain file... how do we do this?... background one thing we are > testing is the ability to upgrade the port (privately) and it must not nuke > our settings file on the test machines because the default config provided > by our port is inappropriate for how we have things configured (it is > correct for 99.9% of everyone else though). > > Namely we need: > > 1. Do not delete /usr/local/etc/petitecloud/settings on deinstall > 2. Do not overwrite it with a new version on install (if present else > install it) > ___ 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"
how to tell pkg-list not to deinstall/overwrite certain files
I am doing a lot of inter-machine testing of a private port (will be released soon as a actual port) but need to tell "make deinstall" not to delete a certain file... how do we do this?... background one thing we are testing is the ability to upgrade the port (privately) and it must not nuke our settings file on the test machines because the default config provided by our port is inappropriate for how we have things configured (it is correct for 99.9% of everyone else though). Namely we need: 1. Do not delete /usr/local/etc/petitecloud/settings on deinstall 2. Do not overwrite it with a new version on install (if present else install it) ___ 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: Staging and directory modes/ownerships
On Sun, Nov 3, 2013 at 5:41 PM, Eitan Adler wrote: > Please do not top post: it makes it impossible to follow a conversation. > > On Sun, Nov 3, 2013 at 5:30 PM, Aryeh Friedman > wrote: > > Where is this documented? (I am making a port that needs do similar stuff > > but want to understand all the possible directives) > > It is documented in > http://www.freebsd.org/doc/en/books/porters-handbook/book.html section > 5.15.1 > I meant the @xxx's ___ 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: Staging and directory modes/ownerships
Where is this documented? (I am making a port that needs do similar stuff
but want to understand all the possible directives)
On Sun, Nov 3, 2013 at 5:09 PM, Tijl Coosemans wrote:
> On Sun, 3 Nov 2013 22:22:24 +0100 (CET) Melvyn Sopacua wrote:
> > On Sun, 3 Nov 2013, Tijl Coosemans wrote:
> >> On Sun, 3 Nov 2013 14:47:00 +0100 (CET) Melvyn Sopacua wrote:
> >>> I'm trying to upgrade www/magento and in the process make it use the
> >>> stage. Aside from having to package a fixed plist again to set modes
> and
> >>> ownerships, I can no longer find a way to set these properties on
> >>> directory trees.
> >>>
> >>> For now I'll go with adding @exec commands to ${TMPPLIST}, I suppose.
> >>
> >> Would this work:
> >>
> >> @owner www
> >> @group www
> >> www/magento/media/foo/bar
> >
> > If bar is a directory, I expect to see errors from the package tools
> > here, but I haven't tried it. If bar is a file, then it doesn't change
> > owner of media/foo (tested). Further more, it would be rather hard to do
> > so, since in this case, www/magento should be left untouched.
>
> bar is a file. Only files can be listed like this. Directories always
> have @dirrm. @owner, @group and @mode apply to all the following entries,
> so the directories listed below are also owned by www. This works at
> least with pkg. I don't know if it works with the old pkg_install tools.
>
> >> @mode 0777
> >> @dirrm www/magento/media/foo
> >
> > This directive is processed on deinstallation. I don't think it will
> > work but I have not tested it.
> >
> > Thanks for answering.
> ___
> 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: what on earth and how do I fix:
Doing this disables the user creation part of the port On Sat, Oct 5, 2013 at 2:59 AM, Boris Samorodov wrote: > 05.10.2013 08:29, Aryeh Friedman пишет: > > > I maintain a port (not officially a part of the ports collection yet) > that > > compiled just fine before "staging" support was added now I get: > > > > chown -R www:www /usr/local/etc/petitecloud > > > Compressing man pages > > ===> Correct pkg-plist sequence to create group(s) and user(s) > > ===> Installing for petitecloud-0.1.9 > > ===> Registering installation for petitecloud-0.1.9 > > pkg-static: > > > lstat(/usr/ports/emulators/petitecloud/work/stage/usr/local/apache-tomcat-7.0/webapps/petitecloud-0.1.9-aryeh.war): > > No such file or directory > > > > How do I fix this? > > Either add NO_STAGE=yes to Makefile or convert to STAGE support > (preferable). > > -- > WBR, Boris Samorodov (bsam) > FreeBSD Committer, http://www.FreeBSD.org The Power To Serve > ___ > 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"
what on earth and how do I fix:
I maintain a port (not officially a part of the ports collection yet) that compiled just fine before "staging" support was added now I get: chown -R www:www /usr/local/etc/petitecloud > Compressing man pages ===> Correct pkg-plist sequence to create group(s) and user(s) ===> Installing for petitecloud-0.1.9 ===> Registering installation for petitecloud-0.1.9 pkg-static: lstat(/usr/ports/emulators/petitecloud/work/stage/usr/local/apache-tomcat-7.0/webapps/petitecloud-0.1.9-aryeh.war): No such file or directory How do I fix this? ___ 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"
how to force upgrade
I have a port that has a very serious security flaw (no password required for super user level privileges) and in the fix I want to force the uninstalling of all previously installed versions (for obvious reasons)... how do I go about doing this... please note I am also the author of the ported software so can make any changes also needed there ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/182056: [NEW PORT] emulators/petitecloud -- thin frontend for bhve and in future versions other hyper-v's
I accidentally left a copyright notice in the Makefile of ports/182056 how
do I make a followup to it to fix the problem? A side question the PR has
been sitting for over a week with no one assigned to it?
On Fri, Sep 13, 2013 at 2:05 AM, Aryeh M. Friedman wrote:
>
> >Number: 182056
> >Category: ports
> >Synopsis: [NEW PORT] emulators/petitecloud -- thin frontend for
> bhve and in future versions other hyper-v's
> >Confidential: no
> >Severity: non-critical
> >Priority: low
> >Responsible:freebsd-ports-bugs
> >State: open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class: change-request
> >Submitter-Id: current-users
> >Arrival-Date: Fri Sep 13 06:10:00 UTC 2013
> >Closed-Date:
> >Last-Modified:
> >Originator: Aryeh M. Friedman
> >Release:
> >Organization:
> >Environment:
> >Description:
> --- ../petitecloud.old/Makefile 2013-09-13 01:27:14.0 -0400
> +++ Makefile2013-09-13 01:23:04.0 -0400
> @@ -0,0 +1,24 @@
> +#
> +# Copyright (C) 2013 Friedman-Nixon-Wong Enterprises, LLC
> +#
> +
> +CATEGORIES=emulators
> +PORTNAME= petitecloud
> +PORTVERSION=0.1
> +MASTER_SITES= ftp://ftp.petitecloud.org/petitecloud/aryeh/0.1/
> +COMMENT= Thin frontend to bhve
> +
> +USERS= petitecloud
> +GROUPS= petitecloud
> +
> +BUILD_DEPENDS= ${LOCALBASE}/openjdk7/bin/java:${PORTSDIR}/java/openjdk7 \
> +${LOCALBASE}/bin/cook:${PORTSDIR}/devel/cook \
> + ${LOCALBASE}/bin/sudo:${PORTSDIR}/security/sudo \
> +${LOCALBASE}/apache-tomcat-7.0/bin/catalina.sh:${PORTSDIR}/www/tomcat7
> +
> +post-install:
> + echo petitecloud | pw usermod petitecloud -h 0 2>&1
> + chmod 6755 /usr/local/sbin/petitecloud-install
> + chown -R www:www /usr/local/etc/petitecloud
> +
> +.include
> --- ../petitecloud.old/distinfo 2013-09-13 01:27:14.0 -0400
> +++ distinfo2013-09-13 01:23:04.0 -0400
> @@ -0,0 +1,2 @@
> +SIZE (petitecloud-0.1.tar.gz) = 266752
> +SHA256 (petitecloud-0.1.tar.gz) =
> 5894bbd9053a0d0a30103a604fc6ef2cb3bd680a36dc0516865da23c41448536
> --- ../petitecloud.old/pkg-descr2013-09-13 01:27:14.0 -0400
> +++ pkg-descr 2013-09-12 06:47:23.0 -0400
> @@ -0,0 +1,3 @@
> +A thin front end to bhyve and in future versions other Hyper-V's
> +
> +WWW: http://www.petitecloud.org
> --- ../petitecloud.old/pkg-message 2013-09-13 01:27:14.0 -0400
> +++ pkg-message 2013-09-12 06:47:23.0 -0400
> @@ -0,0 +1,15 @@
> +You need to have vmm.ko, if_bridge.ko and if_tun.ko loaded:
> +
> +kldload vmm
> +kldload if_bridge
> +kldload if_tap
> +
> +You also need the bridge configured to be connected to bridge0 and to the
> NIC that goes to the public internet.
> +For example:
> +
> +ifconfig bridge0 create
> +ifconfig bridge0 addm em0 up
> +
> +You also need www/tomcat7 running:
> +
> +/usr/local/etc/rc.d/tomcat7 onestart
> --- ../petitecloud.old/pkg-plist2013-09-13 01:27:14.0 -0400
> +++ pkg-plist 2013-09-13 01:23:04.0 -0400
> @@ -0,0 +1,4 @@
> +/usr/local/apache-tomcat-7.0/webapps/petitecloud-0.1-aryeh.war
> +/usr/local/share/java/classes/petitecloud-0.1-aryeh.jar
> +/usr/local/sbin/petitecloud-install
> +/usr/local/etc/rc.d/petitecloud
> --- /usr/ports/UIDs.old 2013-09-13 01:28:45.0 -0400
> +++ /usr/ports/UIDs 2013-09-05 23:46:06.0 -0400
> @@ -267,4 +267,5 @@
> shibd:*:971:971::0:0:Shibboleth SAML daemon:/nonexistent:/usr/sbin/nologin
> plex:*:972:972::0:0:Plex Media Server:/nonexistent:/usr/sbin/nologin
> boinc:*:973:973::0:0:BOINC user:/var/db/boinc:/usr/sbin/nologin
> +petitecloud:*:974:974::0:0:Petitecloud Admin
> Acct:/home/petitecloud:/usr/sbin/petitecloud-install
> nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin
> 262a263
> > petitecloud:*:974:
>
> >How-To-Repeat:
>
> >Fix:
>
>
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> ___
> freebsd-ports-b...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs
> To unsubscribe, send any mail to "
> freebsd-ports-bugs-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: setting the password of a automatically created account
Sorry not possible due to who the target audience is (no competent admin available)... I found a better solution last night a quick and dirty suid wrapper that calls the right program On Fri, Sep 6, 2013 at 1:00 PM, Darren Pilgrim < list_free...@bluerosetech.com> wrote: > On 9/5/2013 9:00 PM, Aryeh Friedman wrote: > >> related questions: >> >> 1. How do I add the user to wheel (has it's own group but needs to be in >> wheel for reason number #2)? >> 2. How do I modify (in the safest possible way) an other port's installed >> config file(s) (namely I need to in the case of this port modify >> /usr/local/etc/sudoers to allow the no password option for wheel members)? >> > > The answer to both is you don't. Include documentation telling the admin > exactly what needs special access or elevated priveleges and let the admin > make that happen. If you think something needs root because it needs to > open something in /dev, tell the admin it needs to do something with > /dev/foo. Devd and other mechanisms can provide that without root access. > The same idea applies to almost all of what people typically think > requires root access. > ___ 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: setting the password of a automatically created account
related questions: 1. How do I add the user to wheel (has it's own group but needs to be in wheel for reason number #2)? 2. How do I modify (in the safest possible way) an other port's installed config file(s) (namely I need to in the case of this port modify /usr/local/etc/sudoers to allow the no password option for wheel members)? Since the account's shell that is created is a custom shell for the port there is no security wholes we know about.. even so what kind of (if any) security warnings should we put on the port? On Thu, Sep 5, 2013 at 11:00 PM, Perry Hutchison wrote: > Aryeh Friedman wrote: > > > I have a port that needs to create a a user of a given name and a > > given default password... I found in the porters guide how to make > > the account but not set the password > > This is one of the canonical uses of lang/expect. > ___ 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"
setting the password of a automatically created account
I have a port that needs to create a a user of a given name and a given default password... I found in the porters guide how to make the account but not set the password ___ 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"
submitting multiple ports at once
What is the best way to submit 4 or 5 ports at once (I have all the port files themselves stored on the same site that the distfiles are on and contain the same general pattern of ftp:://site.com/XXX/port-0.1.tar.gz)... so I do it one PR per port with the standard subject for a new port or a single PR for all of them with a ptr to the dist. site? ___ 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"
name of a port that builds on 10-CURRENT but not 9?
I am making a port and need to see a good working example of how to make it so it will not compile on less then 10-CURRENT ___ 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: help with making a port
On Sun, Jul 7, 2013 at 3:51 PM, Jason Helfman wrote: > pkg which /path/to/file > or > pkg_info -W /path/to/file > > Odd though that you checked there, and it wasn't recorded aryeh@dev:/home/aryeh% pkg_info -W /usr/local/share/foo/foo.jar pkg_info: You appear to be using the newer pkg(1) tool on this system for package management, rather than the legacy package management tools (pkg_*). The legacy tools should no longer be used on this system. pkg_info: /var/db/pkg/aegis-4.24.3/+CONTENTS: No such file or directory aryeh@dev:/home/aryeh% pkg_info which /usr/local/share/foo/foo.jar pkg_info: You appear to be using the newer pkg(1) tool on this system for package management, rather than the legacy package management tools (pkg_*). The legacy tools should no longer be used on this system. pkg_info: can't find package 'which' installed or in a file! tar: +*: Not found in archive tar: Error exit delayed from previous errors. pkg_info: tar extract of /usr/local/share/foo/foo.jar failed! pkg_info: error during unpacking, no info for '/usr/local/share/foo/foo.jar' available ___ 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: help with making a port
Looking in /var/db/pkg and /var/db/ports I see nothing... anywhere else to look? ___ 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: help with making a port
oops forgot the pkg-plist: share/foo/foo.jar etc/rc.d/foo etc/foo/instances apache-tomcat-7.0/webapps/foo.war On Sun, Jul 7, 2013 at 1:42 PM, Aryeh Friedman wrote: > It uses a non-standard build system (devel/cook) but here is the > Makefile for the port itself (not the program). Also note for legal > reasons (we are still in the process of getting a trademark on the > name) I have changed the actual port name, category and comment [the > real values are known to one of the 10-CURRENT developers we are > working with though]. Also note I have not added any of the depends > stuff yet: > > > # $FreeBSD$ > > PORTNAME= foo > PORTVERSION= 0.1 > CATEGORIES= bar > MASTER_SITES= ftp://foo.org/foo/ > MAINTAINER= supp...@foo.org > COMMENT= A foobar platform > > .include > > > > On Sun, Jul 7, 2013 at 1:36 PM, Jason Helfman wrote: >> On Sun, Jul 7, 2013 at 10:12 AM, Aryeh Friedman >> wrote: >>> >>> I am attempting to put together a port for a new program and I am >>> getting a very odd error message (i.e. it says the port conflicts with >>> itself!?!?!?!): >>> >>> pkg-static: foo-0.1 conflicts with foo-0.1 (installs files into the >>> same place). Problematic file: /usr/local/share/foo/foo.jar >>> >>> What causes this and how do I fix the make file? >> >> >> Posting your port code can only help in assisting. >> >> Thanks. >> >> -jgh >> >> -- >> Jason Helfman | FreeBSD Committer >> j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve ___ 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: help with making a port
It uses a non-standard build system (devel/cook) but here is the Makefile for the port itself (not the program). Also note for legal reasons (we are still in the process of getting a trademark on the name) I have changed the actual port name, category and comment [the real values are known to one of the 10-CURRENT developers we are working with though]. Also note I have not added any of the depends stuff yet: # $FreeBSD$ PORTNAME= foo PORTVERSION= 0.1 CATEGORIES= bar MASTER_SITES= ftp://foo.org/foo/ MAINTAINER= supp...@foo.org COMMENT= A foobar platform .include On Sun, Jul 7, 2013 at 1:36 PM, Jason Helfman wrote: > On Sun, Jul 7, 2013 at 10:12 AM, Aryeh Friedman > wrote: >> >> I am attempting to put together a port for a new program and I am >> getting a very odd error message (i.e. it says the port conflicts with >> itself!?!?!?!): >> >> pkg-static: foo-0.1 conflicts with foo-0.1 (installs files into the >> same place). Problematic file: /usr/local/share/foo/foo.jar >> >> What causes this and how do I fix the make file? > > > Posting your port code can only help in assisting. > > Thanks. > > -jgh > > -- > Jason Helfman | FreeBSD Committer > j...@freebsd.org | http://people.freebsd.org/~jgh | The Power to Serve ___ 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: help with making a port
GMail is being weird this is a 3rd try at reposting -- Forwarded message -- From: Aryeh Friedman Date: Sun, Jul 7, 2013 at 1:12 PM Subject: help with making a port To: FreeBSD Ports ML I am attempting to put together a port for a new program and I am getting a very odd error message (i.e. it says the port conflicts with itself!?!?!?!): pkg-static: foo-0.1 conflicts with foo-0.1 (installs files into the same place). Problematic file: /usr/local/share/foo/foo.jar What causes this and how do I fix the make file? ___ 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: help with making a port
-- Forwarded message -- From: Aryeh Friedman Date: Sun, Jul 7, 2013 at 1:12 PM Subject: help with making a port To: FreeBSD Ports ML I am attempting to put together a port for a new program and I am getting a very odd error message (i.e. it says the port conflicts with itself!?!?!?!): pkg-static: foo-0.1 conflicts with foo-0.1 (installs files into the same place). Problematic file: /usr/local/share/foo/foo.jar What causes this and how do I fix the make file? ___ 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"
help with making a port
I am attempting to put together a port for a new program and I am getting a very odd error message (i.e. it says the port conflicts with itself!?!?!?!): pkg-static: foo-0.1 conflicts with foo-0.1 (installs files into the same place). Problematic file: /usr/local/share/foo/foo.jar What causes this and how do I fix the make file? ___ 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"
A maintainers question: how to create a user?
See subject for the main question... the details: I am the maintainer of
devel/aegis and the final installation step typically (linux RPM's for
example) is to create a user to hold the baselines (in svn/cvs/csup speak
the project's repo) of the varioous projects managed by aegis... customerly
this is MUST be a non-logginable (you MUST [requirements document meaning
of upper case MUST/SHOULD/MAY {NOT}) but allow for su from either root or
via sudo a member of "wheel")... it is a standard account in all other
respects for example I typically set it to tcsh but the port might want to
make that an make time option... what is the best way of setting this all
up (both the no options and the options based versions)
___
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: A maintainers question: how to create a user?
On Thu, Dec 15, 2011 at 7:16 PM, Aryeh Friedman wrote:
> See subject for the main question... the details: I am the maintainer of
> devel/aegis and the final installation step typically (linux RPM's for
> example) is to create a user to hold the baselines (in svn/cvs/csup speak
> the project's repo) of the varioous projects managed by aegis... customerly
> this is MUST be a non-logginable (you MUST [requirements document meaning
> of upper case MUST/SHOULD/MAY {NOT}) but allow for su from either root or
> via sudo a member of "wheel")... it is a standard account in all other
> respects for example I typically set it to tcsh but the port might want to
> make that an make time option... what is the best way of setting this all
> up (both the no options and the options based versions)
>
for example:
# grep aegis /etc/passwd
aegis:*:1002:1002:Aegis Baselines:/home/aegis:/bin/tcsh
# grep aegis /etc/group
wheel:*:0:root,aryeh,aegis
aegis:*:1002:
___
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"
taking maintainership
If all I am doing is taking maintainership of devel/aegis and the list of ports that need maintainers says it should the newest version 4.24.3 and the make file has 4.24 in it and the second is the correct version number and the one in the listing is wrong do I just send in the new makefile that has me as the maintainer and nothing else? ___ 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: 8-STABLE /usr/include/utmp.h and tmpx
No will do even though I don't think I have a complete enough list of ports to make a proper report (if in fact it is a per port solution vs. fixing base) On Fri, Jun 3, 2011 at 9:09 PM, Garrett Cooper wrote: > On Fri, Jun 3, 2011 at 5:02 PM, Aryeh Friedman > wrote: >> Some time in the last 2 weeks (I am sure when) a commit caused many >> ports that assume a "standard" utmp/utmp.x to break for example >> x11-toolkits/vte produces: >> >> gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add' >> discards qualifiers from pointer target type >> mv -f .deps/gnome-pty-helper.Tpo .deps/gnome-pty-helper.Po >> cc -DHAVE_CONFIG_H -I. -I/usr/local/include -O2 -pipe >> -march=prescott -fno-strict-aliasing -MT gnome-utmp.o -MD -MP -MF >> .deps/gnome-utmp.Tpo -c -o gnome-utmp.o gnome-utmp.c >> gnome-utmp.c: In function 'write_login_record': >> gnome-utmp.c:367: warning: passing argument 1 of 'login' from >> incompatible pointer type >> gnome-utmp.c:374: error: 'struct utmpx' has no member named 'ut_name' >> >> >> This is not the only port that has the issue but it is the only one I >> remember off the top of my head (I manually fixed a few others) > > Compiles just fine on CURRENT. Did you open a PR for this item? > Thanks, > -Garrett > ___ 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"
8-STABLE /usr/include/utmp.h and tmpx
Some time in the last 2 weeks (I am sure when) a commit caused many ports that assume a "standard" utmp/utmp.x to break for example x11-toolkits/vte produces: gnome-pty-helper.c:497: warning: passing argument 4 of 'pty_add' discards qualifiers from pointer target type mv -f .deps/gnome-pty-helper.Tpo .deps/gnome-pty-helper.Po cc -DHAVE_CONFIG_H -I. -I/usr/local/include -O2 -pipe -march=prescott -fno-strict-aliasing -MT gnome-utmp.o -MD -MP -MF .deps/gnome-utmp.Tpo -c -o gnome-utmp.o gnome-utmp.c gnome-utmp.c: In function 'write_login_record': gnome-utmp.c:367: warning: passing argument 1 of 'login' from incompatible pointer type gnome-utmp.c:374: error: 'struct utmpx' has no member named 'ut_name' This is not the only port that has the issue but it is the only one I remember off the top of my head (I manually fixed a few others) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/dolly breaks cvs
On Fri, Mar 11, 2011 at 12:11 PM, Wesley Shields wrote: > On Fri, Mar 11, 2011 at 11:35:02AM -0500, Aryeh Friedman wrote: >> This is from a repo that was updated 15 mins ago: >> >> flosoft-stable# cvs co ports/sysutils/dolly |& more >> cvs checkout: Updating ports/sysutils/dolly >> cvs checkout: Updating ports/sysutils/dolly/files >> cvs checkout: Updating ports/sysutils/dolly/files/ >> cvs checkout: Updating ports/sysutils/dolly/files// >> cvs checkout: Updating ports/sysutils/dolly/files/// >> cvs checkout: Updating ports/sysutils/dolly/files >> cvs checkout: Updating ports/sysutils/dolly/files/ > > Please don't top-post. > > You have something weird going on. There has not been a commit there in > years. This is most likely a local problem. Can you find a way to force > your repo to update that again? Ok this now truely weird I have a infinite recursive directory rooted on /home/ncvs/ports/sysutils/dolly/files that contains one dir per level whose name is a single control-N when I try to rm/unlink them I get: flosoft-stable# pwd /repo/ports/sysutils/dolly/files flosoft-stable# rm -rf * rm: /: Operation not permitted rm: : Invalid argument If I know the inode how can I force the inode to be cleared even if the filename is illegal? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/dolly breaks cvs
This is from a repo that was updated 15 mins ago: flosoft-stable# cvs co ports/sysutils/dolly |& more cvs checkout: Updating ports/sysutils/dolly cvs checkout: Updating ports/sysutils/dolly/files cvs checkout: Updating ports/sysutils/dolly/files/ cvs checkout: Updating ports/sysutils/dolly/files// cvs checkout: Updating ports/sysutils/dolly/files/// cvs checkout: Updating ports/sysutils/dolly/files cvs checkout: Updating ports/sysutils/dolly/files/ On Fri, Mar 11, 2011 at 11:30 AM, Yuri Pankov wrote: > On Fri, Mar 11, 2011 at 11:22:38AM -0500, Aryeh Friedman wrote: >> cvs update: cannot create read lock in repository >> `/home/ncvs/ports/sysutils/dolly/files//': >> File name too long > > It doesn't here: > $ echo $CVSROOT > anon...@anoncvs1.freebsd.org:/home/ncvs > $ cvs co ports/sysutils/dolly > cvs checkout: Updating ports/sysutils/dolly > U ports/sysutils/dolly/Makefile > U ports/sysutils/dolly/distinfo > U ports/sysutils/dolly/pkg-descr > cvs checkout: Updating ports/sysutils/dolly/files > U ports/sysutils/dolly/files/extra-bzip2-patch-dolly.c > > > Yuri > ___ > 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"
sysutils/dolly breaks cvs
cvs update: cannot create read lock in repository `/home/ncvs/ports/sysutils/dolly/files//': File name too long ___ 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: xfce 4.8 upgrade errors.
I had to reinstall all my ports from scratch to fix this... for how to do this safely see the last example of the man page for portmaster On Fri, Mar 4, 2011 at 9:07 PM, Scott T. Hildreth wrote: > I updated my server to 8.2 and then all my ports. When compiling orage > or trying to it failed with libical errors, > > In file included from ical-archive.c:56: > /usr/local/include/libical/icalss.h:38:27: error: icalcomponent.h: No such > file or directory > /usr/local/include/libical/icalss.h:111:23: error: icalgauge.h: No such file > or directory > /usr/local/include/libical/icalss.h:282:21: error: icalset.h: No such file or > directory > /usr/local/include/libical/icalss.h:342:25: error: icalcluster.h: No such > file or directory > > > ...I cannot find a solution for this, is anyone else seeing this error. When > they compile orage? > > Another problem is that I cannot see any icons. if I open eog and try to to > view an image I get > an unrecognized image file format error. I think something went wrong with > my upgrade, I just > not sure how to fix this issue. > > How do I create a app menu, I'm getting an error when trying to load the menu > "menus/applications.menu" > not found. > > > Thanks, > Scott > > ___ > 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: xfce4.8 icons/menus/panel
A few minor icons on panel 2 are missing but everuthing else is there On Fri, Mar 4, 2011 at 5:28 PM, Torfinn Ingolfsen wrote: > Hello hello, > > On Fri, Mar 4, 2011 at 11:20 PM, Aryeh Friedman > wrote: >> All I know is once I copied it to .xsession it worked fine from xdm > > Well, perhaps that is the key then: perhaps the menus only work > properly if started from xdm, and not if started from startxfce4? > I use startxfce4; I have no icons in panel and Thunar, and menus don't work. > > How does things work (or fail) for people who use xdm? > -- > Regards, > Torfinn Ingolfsen > ___ > 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: xfce4.8 icons/menus/panel
All I know is once I copied it to .xsession it worked fine from xdm On Fri, Mar 4, 2011 at 5:18 PM, Torfinn Ingolfsen wrote: > On Fri, Mar 4, 2011 at 11:14 PM, Aryeh Friedman > wrote: >> you copy it $HOME/.xsession or $HOME/.xinitrc depending if you start >> from xdm or command line > > If you read the startxfce4 script, you will find out that it will use > $HOME/.config/xfce4/xinitrc, if that one exists. Like this: > root@kg-v7# ps ax | grep xinit > 46596 v1 S+ 0:00.00 xinit /home/tingo/.config/xfce4//xinitrc > 46600 v1 S 0:00.00 sh /home/tingo/.config/xfce4//xinitrc > 46647 0 S+ 0:00.00 grep xinit > root@kg-v7# > > HTH > -- > Regards, > Torfinn Ingolfsen > ___ > 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: xfce4.8 icons/menus/panel
you copy it $HOME/.xsession or $HOME/.xinitrc depending if you start from xdm or command line On Fri, Mar 4, 2011 at 5:11 PM, Torfinn Ingolfsen wrote: > Hello, > > On Fri, Mar 4, 2011 at 10:50 PM, Aryeh Friedman > wrote: >> Using the xinitrc that Oliver listed fixed the menus but not the icons for me > > Well, copying /usr/local/etc/xdg/xfce4/xinitrc to $HOME/.config/xfce4 > didn't change anything for me. > The menus still fail to load. > > HTH > -- > Regards, > Torfinn Ingolfsen > ___ > 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"
Problem with xfce-4.8
Oliver -- There have been a number of reports from various people of xfce-4.8 being broken... the main issues seem to be: 1. Icon's are missing 2. Application menu is not available 3. Terminal does not do any short of ANSI colors Some lesser issues: ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Problem with xfce-4.8
On Fri, Mar 4, 2011 at 4:34 PM, Aryeh Friedman wrote: > Oliver -- > > There have been a number of reports from various people of > xfce-4.8 being broken... the main issues seem to be: > > 1. Icon's are missing > 2. Application menu is not available > 3. Terminal does not do any short of ANSI colors > > > Some lesser issues: > oops here are the lesser issues: 1. Some of the desktop background images seem to be missing 2. Settings doesn't work ___ 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: xfce4.8 icons/menus/panel
Using the xinitrc that Oliver listed fixed the menus but not the icons for me On Fri, Mar 4, 2011 at 4:45 PM, Torfinn Ingolfsen wrote: > Hello, > > On Fri, Mar 4, 2011 at 10:30 PM, Olivier Duchateau > wrote: >> Myself I copy xinitrc file taken from sysutils/xfce4-utils ( find >> /usr/local/etc -type f -regex 'xinitrc' -print) and create symbolic >> link for .xsession. > > I start using the 'startxfce4' command directly. > I just tried renaming the ~/.config directory, and then 'startxfce4' > to start with a default configuration. > Still no icons in the panel. > Also, I get this error when clicking on the "Applications Menu" in panel 1: > File "menus/xfce-applications.menu" not found > > HTH > -- > Regards, > Torfinn Ingolfsen > ___ > 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: xfce4.8 icons/menus/panel
Menus are not appearing either On Fri, Mar 4, 2011 at 3:11 PM, Warren Block wrote: > On Fri, 4 Mar 2011, Olivier Duchateau wrote: > >>> % pkg_info -Ix hicolor >>> hicolor-icon-theme-0.12 A high-color icon theme shell from the >>> FreeDesktop >>> project >> >> Are you installed x11-themes/icons-tango (and >> x11-themes/icons-tango-extras) ? > > % pkg_info -Ix icons > icons-tango-0.8.90_1 A basic set of icons for the most common usage > icons-tango-extras-0.1.0_4 A extra set of icons from the Tango project > >> If not, be careful, you must add SVG support in graphics/ImageMagick, >> otherwise icons will be awful (black borders instead of transparent). > >> You can also install misc/gnome-icon-theme. > > SVG was not enabled on graphics/ImageMagick, enabled and reinstalled. Also > reinstalled misc/gnome-icon-theme, but no change. > >> How do you run your Xfce session ? Could you post (somewhere) you >> ~/.xsession-errors (if it exists). > > xfce is started from .xinitrc, with exec /usr/local/bin/startxfce4. > .xsession-errors is short: > > /usr/local/bin/startxfce4: X server already running on display :0 > xrdb: "Xft.hinting" on line 9 overrides entry on line 6 > xrdb: "Xft.hintstyle" on line 11 overrides entry on line 7 > Agent pid 1169 > got eof > > ** (xfwm4:1184): CRITICAL **: getBoolValue: assertion > `G_VALUE_TYPE(rc[i].value) == G_TYPE_BOOLEAN' failed > > (xfce4-panel:1189): xfce4-panel-WARNING **: xfce4-panel is not running > xfdesktop[1190]: starting up > > ** (devilspie:1161): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL' > failed > > ** (devilspie:1161): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL' > failed > > ** (devilspie:1161): CRITICAL **: e_sexp_eval: assertion `f->tree != NULL' > failed > unsetenv: not found > unsetenv: not found > Agent pid 1169 killed > devilspie: Fatal IO error 35 (Resource temporarily unavailable) on X server > :0.0. > xfsettingsd: Fatal IO error 35 (Resource temporarily unavailable) on X > server :0.0. > > ___ > 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: xfce4.8 icons/menus/panel
Just to confirm same issue after upgrading attempted to fix by pkg_delete -a and then rebuilding all ports and still nothing On Fri, Mar 4, 2011 at 3:29 PM, George Liaskos wrote: > I have the same problems after upgrading xfce, no icons and no > "menus/xfce-applications.menu". > ___ > 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: What if a port uses build systems not supported by ports
Create a port for the build system and when you submit the update for the new port also submit the one for the build system On Fri, Nov 21, 2008 at 5:42 PM, matt donovan <[EMAIL PROTECTED]> wrote: > Since I come across a few applications that don't use imake, gmake, or a > configure script. How do I make these third party build systems work for the > port system. For example one port I been playing around with is jam which is > used to build a certain application. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Thunderbird, enigmail, and GCC 3.4
I can confirm on 8-CURRENT no combination of GCC/enigmail/thinderbird works... don't know about 7 On Tue, Apr 22, 2008 at 2:15 AM, Alex Dupre <[EMAIL PROTECTED]> wrote: > Xin LI wrote: > > Finally I caught the issue for thunderbird. It was due to the > > difference between our floating point handling and Linux's counterpart. > > ~ The patch attached would fix the problem at thunderbird part. > > Thanks Xin. > > > > Unfortunately enigmail plugin compiled with gcc 4.x as shipped with > > FreeBSD 7.0+ would still crash with Signal 11, but with gcc 3.4 it would > > work fine. I have not yet figured out why this would happen... > > So you confirm me that the only broken combination is FreeBSD 7 + amd64 > and the fix is to compile only enigmail with gcc 3.4, right? > > -- > Alex Dupre > > > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: determining what ports directly depend on X
On 1/3/08, Frank J. Laszlo <[EMAIL PROTECTED]> wrote:
> Aryeh Friedman wrote:
> > On 1/3/08, Frank J. Laszlo <[EMAIL PROTECTED]> wrote:
> >
> >> Aryeh Friedman wrote:
> >>
> >>> I need to determine which ports depend directly (i.e. they have it
> >>> listed as a B/RDEPS). The specfic task I am working on right now
> >>> (but this will need to be more general later) is attempting to find
> >>> all the direct childern of libtool15
> >>>
> >>>
> >> A quick hack would be
> >>
> >> grep libtool-1.5 /usr/ports/INDEX-6| awk -F"|" {'print $2'}
> >>
> >
> >
> > Doesn't quite work because it appears index is equiv to "make missing"
> > which includes indirect parents. For example x11-wm/compwiz does not
> > reference libool-1.5 except in a USE= line.
> >
>
> Most ports should be setup to use "USE_AUTOTOOLS", but obviously there
> are a few strays.
>
> Anything that uses USE_AUTOTOOLS should have LIBTOOL_DEPENDS defined.
> You could check this. to collect the strays, grepping through for
> ^.*DEPENDS=.*libtool15" should pick them up.
Completely useless... it catchs stuff I know for a fact has no direct
dependancy on libtool15... for example I am the author (but not the
maintainer but I helped in the port creation) of devel/thistest and
the *ONLY* direct dependancy it has is java/jdk16 it still lists
libtool-1.5 as a depend in INDEX-8
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: determining what ports directly depend on X
On 1/3/08, Frank J. Laszlo <[EMAIL PROTECTED]> wrote:
> Aryeh Friedman wrote:
> > On 1/3/08, Frank J. Laszlo <[EMAIL PROTECTED]> wrote:
> >
> >> Aryeh Friedman wrote:
> >>
> >>> I need to determine which ports depend directly (i.e. they have it
> >>> listed as a B/RDEPS). The specfic task I am working on right now
> >>> (but this will need to be more general later) is attempting to find
> >>> all the direct childern of libtool15
> >>>
> >>>
> >> A quick hack would be
> >>
> >> grep libtool-1.5 /usr/ports/INDEX-6| awk -F"|" {'print $2'}
> >>
> >
> >
> > Doesn't quite work because it appears index is equiv to "make missing"
> > which includes indirect parents. For example x11-wm/compwiz does not
> > reference libool-1.5 except in a USE= line.
> >
>
> Most ports should be setup to use "USE_AUTOTOOLS", but obviously there
> are a few strays.
>
> Anything that uses USE_AUTOTOOLS should have LIBTOOL_DEPENDS defined.
> You could check this. to collect the strays, grepping through for
> ^.*DEPENDS=.*libtool15" should pick them up.
>
> Hope this helps.
For various reasons I deleted /usr/ports (in prep to repopulate it
from a local cvs repo) so can't test this right now... but the orginal
question is due to a PR I will be filing as soon I have a working
browser on the machine in question... the PR is that if you install
libtool-1.5 under 8-current (amd64 only???) it will incorrectly ID the
installed OS and give errors about "freebsd-" not being defined as a
platform type... the hand fix is to find the line that has that and
add -elf to it but the root cause is something about 8-current makes
it so it is ID'ed wrong.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: determining what ports directly depend on X
On 1/3/08, Frank J. Laszlo <[EMAIL PROTECTED]> wrote:
> Aryeh Friedman wrote:
> > I need to determine which ports depend directly (i.e. they have it
> > listed as a B/RDEPS). The specfic task I am working on right now
> > (but this will need to be more general later) is attempting to find
> > all the direct childern of libtool15
> >
> A quick hack would be
>
> grep libtool-1.5 /usr/ports/INDEX-6| awk -F"|" {'print $2'}
Doesn't quite work because it appears index is equiv to "make missing"
which includes indirect parents. For example x11-wm/compwiz does not
reference libool-1.5 except in a USE= line.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
determining what ports directly depend on X
I need to determine which ports depend directly (i.e. they have it listed as a B/RDEPS). The specfic task I am working on right now (but this will need to be more general later) is attempting to find all the direct childern of libtool15 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
> > > Having said that dependencies often do depend on the order the leaves > are installed, because some ports will use alternate dependencies > according to what's already there. It makes things a lot easier to > maintain. > ___ btw xdm is not the worst offender for example if you install abiword after installing gnome it will not start but if you install it before hand then install gnome no issue ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: GNOME 2.20.1 available for FreeBSD
> > not sure why it reported an install issue (even after deinstalling gimp > and gimp-gnutlprint) both install fine after the deinstall portupgrade -a after the manual install fixed this one... all that is left is the lsof and mono problems above > > > -- > Aryeh M. Friedman > FloSoft Systems > Developer, not Business, Friendly > http://www.flosoft-systems.com > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
xorg 7.3/freebsd 7-current/nvidia cards on p35 chip sets update
The new vm code in the kernel (cvsup) seems to have helped some things in this combination. Neither nv or nvidia will recognize my 5200 GT; but vesa now gives me 24 depth and has noticeably better response time. For the people who are having problems with spontanous reboots some progress *MAY* have been made in that when testing a config with nv or nvidia on the above the screen cycles colors but does not crash the machine like it used to. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvidia-driver rebooting machine on X startup
On 9/24/07, Mel <[EMAIL PROTECTED]> wrote: > On Monday 24 September 2007 21:14:03 falz wrote: > > I came across this thread on freebsd-questions after some searching on > > google. I have the exact same issue as others here- if xorg is started > > with 'nvidia' as the driver, instant reboot. However, my machine is a > > 100% fresh install with things compiled from source this weekend. > > However, I did have to install some binary vncserver packages, but > > they have since been removed. > > > > I did the 'xorg' meta port which got me the current xorg-7.3_1. The > > machine I did the install on was running Debian Unstable for about a > > year without issue with the same hardware (two cards for 3 monitors): > > > > Sep 24 13:41:24 falz kernel: nvidia0: mem > > 0xdd00-0xddff,0xb000-0xbfff,0xde00-0xdeff irq > > 16 at device 0.0 on pci1 > > Sep 24 13:41:24 falz kernel: nvidia0: [GIANT-LOCKED] > > Sep 24 13:41:24 falz kernel: nvidia1: mem > > 0xdb00-0xdbff,0xc000-0xcfff irq 18 at device 2.0 on > > pci3 > > Sep 24 13:41:24 falz kernel: nvidia1: [GIANT-LOCKED] > > > > I forgot, but was there one person in the thread that has only 1 monitor > attached to 1 card? Cause you're the 3rd I see with multiple monitor issues. > Ironically, we have one system with CRT + TV-OUT through one card, with no > issues whatsoever (500GB HDD, DVDRW, rock on!). However I turned off Xinerama > support from the get go and use TwinView. > > With all the Xorg 7.3 issues, I have not gone that road nor plan to anytime > soon. > > I also think we've had all the different cards by now, a quatro, GeForce 5k, > 7k, 6k... > > Maybe someone can build a WITNESS/DDB kernel, since dumping seems to be > failing? I was the single monitor issue, on the single monitor it does not reboot unless you set probe_all_gpu's *BUT* it does fail to reconize all nVidia cards (so does nv)... as far I can tell neither drive understands 64bit io space and PCI/AGP... the clue is the addr conflicts that everyone seems to get... btw I think it might of fried my 8k but at least gives me vesa with no werid video probs on the 5200 GT I have now (1024x768 ;-()). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can the following license be used for ported programs?
I never claimed to be original... if you want to see the innovator/largest code base in the community look at jahia.com... the only claim I made was I wanted to have my stuff included in the ports collection and wanted to know if the legal aspects of my business model where sufficient... one of the first replies answered that... all other discussion was on the philosophical merits of SIW and I should of put a disclaimer on that I was no longer speaking (purely) as the owner of FloSoft Systems but as the VP of the Miai Foundation... specifically any defense arguments I made for the business model was as a member of the SIW community and not as a owner of a company that practices it. On 9/24/07, David Southwell <[EMAIL PROTECTED]> wrote: > On Sunday 23 September 2007 18:41:43 Aryeh Friedman wrote: > > On 9/24/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > > many people feel much differently, why not just a pure proprietary > > > license then, rather than proliferating Yet Another Silly License which > > > is not tempered by sound legal analysis. > > > > Not to be insulting but I don't think you read my 1st blog entry as I > > suggested (at least the first paragraph... specifically where I say > > both open and closed source are equally the wrong model). Now onto > > your actual points: > > > > The license has received legal review by an IP attorney. > > > > Again not to be insulting but I think most FOSS people slept through > > econ 101, especially the section on there is no such thing as a > > limitless resource. Even though you might consider this to be a > > conflict of interest; I have a family member who is a prof. of econ at > > UC Santa Cruz and has reviewed the economic aspects of both my > > specific work and the general concept of SIW (see second blog entry > > for definition). His general conclusion is while the model is untried > > on a large scale and there are some more minor things we can improve > > on (subject of debate within the SIW community) that we fix many of > > the economic flaws with both open and closed source models. He is > > currently in the process of writing a book on the matter and said he > > would have a full review after rewriting ch8 (which is on the economic > > issues raised by both models) in a few weeks. > > ___ > I have read both the blog and looked at the "product" references. Frankly the > intellectual and grammatical quality of the blog and the comparatively > trivial nature of the "products" referred to makes me feel that the original > contribution does not deserve the level of attention that its author seems to > crave. > > Might it not be better to spend more time on creating truly original > softaware than drawing attention to oneself by purporting to reinvent the > wheel of software licensing? > > David > > David > > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can the following license be used for ported programs?
you more then welcome to join in on the conversation... right now due to the dns issue sited in the original posting we are doing it via a manual mailing list (cc everyone else) [I think that should be partially fixed by tomorrow afternoon] given that if you send any mail to the SIW community it should be addressed to all of the following: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] So you don't sound too much like a newbie I recommend the following background articles and links: http://www.softdevelcoop.org/o.openMailingList.htm (Mailing list archives up to the start of Miai) http://www.softdevelcoop.org/ (precursor to Miai) http://www.sustainablesoftware.info/jahia/Jahia (Stephen's take on the software portion of sustainability) http://www.sustainablesoftware.info/jahia/page421.html (historical essay that got some of us interested in what became SIW [I came to it in a different route]) http://www.methodsandtools.com/PDF/mt200402.pdf (detailed theoretical examination of Jahia's business model) --Aryeh On 9/24/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > great, then why open the conversation up to plebs like me? > > Aryeh Friedman wrote: > On 9/24/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > > many people feel much differently, why not just a pure proprietary license > then, rather than proliferating Yet Another Silly License which is not > tempered by sound legal analysis. > > Not to be insulting but I don't think you read my 1st blog entry as I > suggested (at least the first paragraph... specifically where I say > both open and closed source are equally the wrong model). Now onto > your actual points: > > The license has received legal review by an IP attorney. > > Again not to be insulting but I think most FOSS people slept through > econ 101, especially the section on there is no such thing as a > limitless resource. Even though you might consider this to be a > conflict of interest; I have a family member who is a prof. of econ at > UC Santa Cruz and has reviewed the economic aspects of both my > specific work and the general concept of SIW (see second blog entry > for definition). His general conclusion is while the model is untried > on a large scale and there are some more minor things we can improve > on (subject of debate within the SIW community) that we fix many of > the economic flaws with both open and closed source models. He is > currently in the process of writing a book on the matter and said he > would have a full review after rewriting ch8 (which is on the economic > issues raised by both models) in a few weeks. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can the following license be used for ported programs?
On 9/24/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > many people feel much differently, why not just a pure proprietary license > then, rather than proliferating Yet Another Silly License which is not > tempered by sound legal analysis. Not to be insulting but I don't think you read my 1st blog entry as I suggested (at least the first paragraph... specifically where I say both open and closed source are equally the wrong model). Now onto your actual points: The license has received legal review by an IP attorney. Again not to be insulting but I think most FOSS people slept through econ 101, especially the section on there is no such thing as a limitless resource. Even though you might consider this to be a conflict of interest; I have a family member who is a prof. of econ at UC Santa Cruz and has reviewed the economic aspects of both my specific work and the general concept of SIW (see second blog entry for definition). His general conclusion is while the model is untried on a large scale and there are some more minor things we can improve on (subject of debate within the SIW community) that we fix many of the economic flaws with both open and closed source models. He is currently in the process of writing a book on the matter and said he would have a full review after rewriting ch8 (which is on the economic issues raised by both models) in a few weeks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can the following license be used for ported programs?
If you read the 1st blog entry and the FAQ for the certifying agency you will see why dual licenses are: 1. For the most part impossible to prevent the "free rider" issue 2. Is inherently unfair to contributors 3. Without the fee for execution (instead of just "commercial use") it is very hard to actually make a living from such an venture (see 1st blog entry and certification requirements on the Miai site) --Aryeh On 9/23/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > you gave enough information in the opening paragraph. I will wager that > every response you get will be negative. Why not just try the mysql dual > license model, it seems less "tricky-dicky" > > > Aryeh Friedman wrote: > Is that based on gut feeling or a study of the links offered? > > --Aryeh > > On 9/23/07, Michael Dean <[EMAIL PROTECTED]> wrote: > > > no matter how hard you try, you can't take your sow's ear and turn it > into a silk purse. > > Aryeh Friedman wrote: > > > My company develops software under a commercial "open source" (see > links for details) and I want to know if my license is close enough to > open source (see links for why it is not 100% OSD compliant [it is 95% > compliant]). Specifically does the business model as outlined in my > blog (the third installment should be out later today), my business > model page, the third party certifier and license allow for inclusion > in the ports collection. Keep in mind that the source is available > to anyone but execution is conditioned on attachment A of the license > and after the trial period (30 days) is paid for software. > > License: http://www.flosoft-systems.com/license.php > Official statement of my business model: > http://www.flosoft-systems.com/bmodel.php > Blog entries: > http://www.flosoft-systems.com/blogs/aryeh/FOSS.php > http://www.flosoft-systems.com/blogs/aryeh/SIW_Background.php > Third party group (due to DNS issues is currently hosted on my domain > but is not officially associated with my company): > http://www.flosoft-systems.com/miai/ > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > > > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Can the following license be used for ported programs?
My company develops software under a commercial "open source" (see links for details) and I want to know if my license is close enough to open source (see links for why it is not 100% OSD compliant [it is 95% compliant]). Specifically does the business model as outlined in my blog (the third installment should be out later today), my business model page, the third party certifier and license allow for inclusion in the ports collection. Keep in mind that the source is available to anyone but execution is conditioned on attachment A of the license and after the trial period (30 days) is paid for software. License: http://www.flosoft-systems.com/license.php Official statement of my business model: http://www.flosoft-systems.com/bmodel.php Blog entries: http://www.flosoft-systems.com/blogs/aryeh/FOSS.php http://www.flosoft-systems.com/blogs/aryeh/SIW_Background.php Third party group (due to DNS issues is currently hosted on my domain but is not officially associated with my company): http://www.flosoft-systems.com/miai/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
