Re: ports and PBIs
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: sorry for the cross-post.. Last night at the Bay Area FreeBSD Users Group meeting we had a discussion about ports, and what is good about them and what is bad about them. This has been a topic of discussion quite a bit recently and we were looking for a solution that would allow us to keep the good parts of the current ports system but would allow us to give a better user experience for non guru users. The scheme we came up with involves a merging of the ports tree and the PBI system, developed for PC-BSD. Basically, the addition of a makepbi keyword in the .mk files to allow the automatic generation of PBIs for 'simple' ports such as 'cowsay' (the canonical simple app). More complicated apps would need manual work in Makefile or in a separate pbi-recipe file, but once the support was done we could proceed one port at a time. Not all ports make sense in a PBI format. (e.g. libraries etc. may not) I for one support this Idea, and at a BoF FreeBSD Desktop session at BSDCan 2008 one of my suggestions was to have FreeBSD bless PBI's I think this is good For PC-BSD. and in return it is GREAT for FreeBSD, as it will widen the user base and hopefully attract a few more good developers. keep this discussion going, because there isn't mush of a downside so far as I can see. Sam Fourman Jr. One issue that was raised is the increase of storage overhead when using PBI packages as they include a copy of all required libraries and resources, which means that one would very quickly get duplicate copies of things. Our suggestions include the ability of the PBI management software to resolve and (using hard links) eliminate duplicate items. This is not as easy as it sounds but can be achieved using a special variant of 'objcopy' (at least that is our theory). The aim is to make all apps installed on a system much more resilient to dependency problems. In addition there was discussion on how builds need to be doable as non-root uids sometimes, and that users on a system should be able to install packages (PBIs) as thie selves to get local versions of apps for themselves. Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Julian ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc/powerpc
TB --- 2010-04-10 04:56:51 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-04-10 04:56:51 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-04-10 04:56:51 - cleaning the object tree
TB --- 2010-04-10 04:57:04 - cvsupping the source tree
TB --- 2010-04-10 04:57:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-04-10 05:15:24 - building world
TB --- 2010-04-10 05:15:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 05:15:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 05:15:24 - TARGET=powerpc
TB --- 2010-04-10 05:15:24 - TARGET_ARCH=powerpc
TB --- 2010-04-10 05:15:24 - TZ=UTC
TB --- 2010-04-10 05:15:24 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 05:15:24 - cd /src
TB --- 2010-04-10 05:15:24 - /usr/bin/make -B buildworld
World build started on Sat Apr 10 05:15:24 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
World build completed on Sat Apr 10 06:15:46 UTC 2010
TB --- 2010-04-10 06:15:46 - generating LINT kernel config
TB --- 2010-04-10 06:15:46 - cd /src/sys/powerpc/conf
TB --- 2010-04-10 06:15:46 - /usr/bin/make -B LINT
TB --- 2010-04-10 06:15:46 - building LINT kernel
TB --- 2010-04-10 06:15:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 06:15:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 06:15:46 - TARGET=powerpc
TB --- 2010-04-10 06:15:46 - TARGET_ARCH=powerpc
TB --- 2010-04-10 06:15:46 - TZ=UTC
TB --- 2010-04-10 06:15:46 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 06:15:46 - cd /src
TB --- 2010-04-10 06:15:46 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Apr 10 06:15:46 UTC 2010
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=15000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin
-msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding
-fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c
-O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=15000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin
-msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding
-fstack-protector -Werror eisa_if.c
cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=15000 --param
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin
-msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding
-fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000
/src/sys/dev/e1000/if_em.c:4396: error: expected identifier or '(' before
'struct'
/src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '(' token
/src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '-' token
/src/sys/dev/e1000/if_em.c:4396: error: expected ')' before '-' token
/src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}'
token
*** Error code 1
Stop in /obj/powerpc/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-04-10 06:20:12 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-04-10 06:20:12 - ERROR: failed to build lint kernel
TB --- 2010-04-10 06:20:12 - 2958.63 user 590.91 system 5001.45 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sparc64
TB --- 2010-04-10 05:21:18 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-04-10 05:21:18 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-04-10 05:21:18 - cleaning the object tree
TB --- 2010-04-10 05:21:37 - cvsupping the source tree
TB --- 2010-04-10 05:21:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2010-04-10 05:24:23 - building world
TB --- 2010-04-10 05:24:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 05:24:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 05:24:23 - TARGET=sparc64
TB --- 2010-04-10 05:24:23 - TARGET_ARCH=sparc64
TB --- 2010-04-10 05:24:23 - TZ=UTC
TB --- 2010-04-10 05:24:23 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 05:24:23 - cd /src
TB --- 2010-04-10 05:24:23 - /usr/bin/make -B buildworld
World build started on Sat Apr 10 05:24:23 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
World build completed on Sat Apr 10 06:21:59 UTC 2010
TB --- 2010-04-10 06:21:59 - generating LINT kernel config
TB --- 2010-04-10 06:21:59 - cd /src/sys/sparc64/conf
TB --- 2010-04-10 06:21:59 - /usr/bin/make -B LINT
TB --- 2010-04-10 06:21:59 - building LINT kernel
TB --- 2010-04-10 06:21:59 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 06:21:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 06:21:59 - TARGET=sparc64
TB --- 2010-04-10 06:21:59 - TARGET_ARCH=sparc64
TB --- 2010-04-10 06:21:59 - TZ=UTC
TB --- 2010-04-10 06:21:59 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 06:21:59 - cd /src
TB --- 2010-04-10 06:21:59 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Apr 10 06:21:59 UTC 2010
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
[...]
/src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or
'...' before 'ims_mask'
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or
storage class
/src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration
of 'bus_space_write_4'
/src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype
/src/sys/dev/e1000/if_em.c:4396: error: conflicting types for
'bus_space_write_4'
./machine/bus.h:295: error: previous definition of 'bus_space_write_4' was here
/src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}'
token
*** Error code 1
Stop in /obj/sparc64/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-04-10 06:26:07 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-04-10 06:26:07 - ERROR: failed to build lint kernel
TB --- 2010-04-10 06:26:07 - 2805.06 user 584.35 system 3889.18 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More amvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Sam Fourman Jr. Fourman Networks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2010-04-10 04:41:04 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-04-10 04:41:04 - starting HEAD tinderbox run for ia64/ia64
TB --- 2010-04-10 04:41:04 - cleaning the object tree
TB --- 2010-04-10 04:41:22 - cvsupping the source tree
TB --- 2010-04-10 04:41:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/ia64/ia64/supfile
TB --- 2010-04-10 05:15:24 - building world
TB --- 2010-04-10 05:15:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 05:15:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 05:15:24 - TARGET=ia64
TB --- 2010-04-10 05:15:24 - TARGET_ARCH=ia64
TB --- 2010-04-10 05:15:24 - TZ=UTC
TB --- 2010-04-10 05:15:24 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 05:15:24 - cd /src
TB --- 2010-04-10 05:15:24 - /usr/bin/make -B buildworld
World build started on Sat Apr 10 05:15:24 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
World build completed on Sat Apr 10 06:30:51 UTC 2010
TB --- 2010-04-10 06:30:51 - generating LINT kernel config
TB --- 2010-04-10 06:30:51 - cd /src/sys/ia64/conf
TB --- 2010-04-10 06:30:51 - /usr/bin/make -B LINT
TB --- 2010-04-10 06:30:51 - building LINT kernel
TB --- 2010-04-10 06:30:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 06:30:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 06:30:51 - TARGET=ia64
TB --- 2010-04-10 06:30:51 - TARGET_ARCH=ia64
TB --- 2010-04-10 06:30:51 - TZ=UTC
TB --- 2010-04-10 06:30:51 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 06:30:51 - cd /src
TB --- 2010-04-10 06:30:51 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Apr 10 06:30:51 UTC 2010
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
[...]
/src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or
'...' before 'ims_mask'
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or
storage class
/src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration
of 'bus_space_write_4'
/src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype
/src/sys/dev/e1000/if_em.c:4396: error: conflicting types for
'bus_space_write_4'
./machine/bus.h:274: error: previous definition of 'bus_space_write_4' was here
/src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}'
token
*** Error code 1
Stop in /obj/ia64/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-04-10 06:36:05 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-04-10 06:36:05 - ERROR: failed to build lint kernel
TB --- 2010-04-10 06:36:05 - 3944.74 user 620.29 system 6900.22 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-04-10 06:04:15 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-04-10 06:04:15 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-04-10 06:04:15 - cleaning the object tree
TB --- 2010-04-10 06:04:27 - cvsupping the source tree
TB --- 2010-04-10 06:04:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca
/tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2010-04-10 06:07:13 - building world
TB --- 2010-04-10 06:07:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 06:07:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 06:07:13 - TARGET=sun4v
TB --- 2010-04-10 06:07:13 - TARGET_ARCH=sparc64
TB --- 2010-04-10 06:07:13 - TZ=UTC
TB --- 2010-04-10 06:07:13 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 06:07:13 - cd /src
TB --- 2010-04-10 06:07:13 - /usr/bin/make -B buildworld
World build started on Sat Apr 10 06:07:13 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
World build completed on Sat Apr 10 07:00:54 UTC 2010
TB --- 2010-04-10 07:00:54 - generating LINT kernel config
TB --- 2010-04-10 07:00:54 - cd /src/sys/sun4v/conf
TB --- 2010-04-10 07:00:54 - /usr/bin/make -B LINT
TB --- 2010-04-10 07:00:54 - building LINT kernel
TB --- 2010-04-10 07:00:54 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-04-10 07:00:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-04-10 07:00:54 - TARGET=sun4v
TB --- 2010-04-10 07:00:54 - TARGET_ARCH=sparc64
TB --- 2010-04-10 07:00:54 - TZ=UTC
TB --- 2010-04-10 07:00:54 - __MAKE_CONF=/dev/null
TB --- 2010-04-10 07:00:54 - cd /src
TB --- 2010-04-10 07:00:54 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Apr 10 07:00:54 UTC 2010
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
[...]
/src/sys/dev/e1000/if_em.c:4396: error: expected declaration specifiers or
'...' before 'ims_mask'
cc1: warnings being treated as errors
/src/sys/dev/e1000/if_em.c:4396: warning: data definition has no type or
storage class
/src/sys/dev/e1000/if_em.c:4396: warning: type defaults to 'int' in declaration
of 'bus_space_write_4'
/src/sys/dev/e1000/if_em.c:4396: warning: function declaration isn't a prototype
/src/sys/dev/e1000/if_em.c:4396: error: conflicting types for
'bus_space_write_4'
./machine/bus.h:295: error: previous definition of 'bus_space_write_4' was here
/src/sys/dev/e1000/if_em.c:4397: error: expected identifier or '(' before '}'
token
*** Error code 1
Stop in /obj/sun4v/src/sys/LINT.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-04-10 07:04:59 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-04-10 07:04:59 - ERROR: failed to build lint kernel
TB --- 2010-04-10 07:04:59 - 2824.87 user 547.76 system 3644.30 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Trivial PR, fix shutdown of rc services started with onestart
This morning I took a look at my outstanding PRs. There is a PR I consider old and trivial: This one proposes a change that always treats rc script execution of active services as if service_enable=YES was set. This ensures, among other things, a clean shutdown procedure for services started with onestart: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/130414 Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More amvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at size difference. Here's just one sample: $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by
Re: ports and PBIs
On Sat, Apr 10, 2010 at 2:20 AM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More amvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer jul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). I wasn't suggesting that the current way Gentoo did Masking was the correct way, in fact you have valid points that I agree with and I used Gentoo last Week :) What I like is that, most of the portage development in done in tree, maybe the real solution is, to just have a development and release ports tree? right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. Again, I agree with you, I just want a easier way to test these large ports. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. pkg_add does work, I have done it several times, upon learning about PBI's a few years back I wondered to myself, why not just use packages,and make some sort of GUI to add a icon to the whole ordeal. but now I get the Idea of dependencies,it pleges evey Open source OS, even ubuntu breaks every now and again. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at size difference. Here's just one sample: $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of
Re: ports and PBIs
On 4/10/10 12:20 AM, Garrett Cooper wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande Moreamvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischerjul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a
Re: ports and PBIs
On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer jul...@elischer.org wrote: On 4/10/10 12:20 AM, Garrett Cooper wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande Moreamvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischerjul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE,
Re: ports and PBIs
On 04/10/10 02:31, Julian Elischer wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Please do. Someone has to do something about deployment. For what it's worth, I've tripped over the garden rake on the ground, that is 'unsatisfied dependency' one too many times in commercial work. If PBIs can address this, even for FreeBSD's embedded and server use cases, they will likely be well recieved. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px
On Sat 10/04/10 3:35 AM , Garrett Cooper wrote:
[...]
yes but there are still dependency problems if you want to install
a single
package and you installed all the previous ones a year ago.
With PBIs each package is self standing, so you can install one
and not worry if it requires a different version of some library
to what you installed last year.
If I'm understanding you correctly you're saying it's an issue when I
do:
pkg_add A B C
# 1 year passes
pkg_add D
# D depends on A, B, C, of different revisions. pkg_add barfs because
it can't find the applications, etc.
This is something that's been hashed over a number of times (a few of
which I've participated in in #bsdports). There needs to be a simple
update command which will handle the action of upgrading packages,
because there isn't a proper command that will do so today.
Unless PBIs are self-contained entities which have their own sets of
dependent utilities and libraries, etc (which you weren't suggesting
in the sentence above), or install into a common location with
versioned directories (which is a pain in the ass and involves a lot
of hardcoded pains dealing with libtool files, libraries, etc -- been
there, done that with Gentoo Linux -- there are hack scripts written
to work around several possible hardcoded version issue, and there
are
a handful), AFAIK there's nothing positive and new that PBIs can
bring
to the table in this regard that can't be implemented in pkg_install
as-is, other than the point-click-install user-friendly interface.
Incorrect. The difference is in complexity at install-time. Even if
you improve the package manager
to better resolve and upgrade all related dependencies as a result of
doing a firefox upgrade, the fact
still remains that just to update one package, you may have to also
update a TON of various packages
/ libraries, any of which may be critical to other applications on
your system. If just a single one of those
things fails, you can end up breaking a lot of applications on your
system or even your entire desktop.
PBI system simplifies this process. Updating firefox, since its
self-contained, does NOT run the risk
of borking anything else on the system. You don't need to work about
libpng, libjpeg, or some other seemingly
trivial library (to the end user) causing a huge breakage for xorg,
or KDE/Gnome, etc.
This in my opinion is the fatal flaw of pretty much every open-source
system out there right now. Something both
windows mac have recognized and dealt with. We instead try to write
more and more complex package resolvers,
while failing to address the main issue, that with such a complex
chain of dependencies for something as simple
as upgrading firefox, it increases the chances exponentially that
something will break and ruin your day / weekend.
PBIs only comprise a small set of packages in FreeBSD; if my
understanding is correct based on a mirror referenced in
pbidir.com,
the number is currently under 500~750 PBIs -- this is drastically
smaller than the number of binary packages produced by ports on a
regular basis for FreeBSD.
solution? well let all the developers develop working ports in
progress in one place, give users like me a way to track these
changes
and install and test them... I think FreeBSD becomes a better
place for
it.
Packages are more of the answer IMO, not PBIs. PBIs are merely a
different set of contents and different means of delivering those
contents, and while I like the idea of point - click - install,
I'm
not ready to create unnecessary complexity by having libraries
rev'ed
according to what the maintainer A believes are correct, even
though
maintainer B set it differently, and I'm not interested in
sacrificing
disk space for this reason. If I wanted to use a packaging scheme
like
this, I should be using Mac OSX as my primary operating system.
well no-one is going to make you use PBIs
Yes, but if I now have to waste more bandwidth and disk space
installing packages, why shouldn't I go to another operating system?
Switching over to PBIs will reel in more desktop and entry-level
sysadmins, etc, but I fear that it will isolate folks in the embedded
market as well as several more seasoned users because of the
implications involved with the extra bandwidth requirement and
footprint.
This gave me a bit of a chuckle. PBI would not be intended as a
replacement for ports,
rather a utilizing of ports in such a way that we can start building
self-contained, stand-alone
binaries for end-users and those of us who value their time more than
a few MB of disk space.
Considering at every BSD conference it seems that the majority of
developers are running Mac
laptops, it would seem that even some developers agree with the
principle, they
Re: LOR on em in HEAD ( was Re: em driver regression
At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup odule pci/rl failed to register: 17 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2666.65-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x2810NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 2577711104 (2458 MB) ACPI APIC Table: INTEL S3420GPC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: INTEL S3420GPC on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 5.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0x2000-0x20ff mem 0xb000-0xbfff,0xc1a0-0xc1a0 irq 16 at device 0.0 on pci1 pci1: multimedia, HDA at device 0.1 (no driver attached) pci0: base peripheral at device 8.0 (no driver attached) pci0: base peripheral at device 8.1 (no driver attached) pci0: base peripheral at device 8.2 (no driver attached) pci0: base peripheral at device 8.3 (no driver attached) pci0: base peripheral at device 16.0 (no driver attached) pci0: base peripheral at device 16.1 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x3040-0x305f mem 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 ehci0: Intel PCH USB 2.0 controller USB-B mem 0xc1b22000-0xc1b223ff irq 21 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: Intel PCH USB 2.0 controller USB-B on ehci0 pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci3: ACPI PCI bus on pcib3 em1: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x1000-0x101f mem 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 pcib4: ACPI PCI-PCI bridge irq 18 at device 28.6 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0 pci5: ACPI PCI bus on pcib5 ehci1: Intel PCH USB 2.0 controller USB-A mem 0xc1b21000-0xc1b213ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: Intel PCH USB 2.0 controller USB-A on ehci1 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 ahci0: Intel PCH AHCI SATA controller port 0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f mem 0xc1b2-0xc1b207ff irq 18 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: AHCI channel at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: AHCI channel at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: AHCI channel at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: AHCI channel at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: AHCI channel at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: AHCI channel at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_button0: Sleep Button on acpi0 acpi_button0: enable wake failed atrtc0: AT realtime clock port 0x70-0x71,0x74-0x77 irq 8 on acpi0 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (115200,n,8,1) uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xd3000-0xd3fff,0xd4000-0xd4fff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ata0 at port
Re: LOR on em in HEAD ( was Re: em driver regression
On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup ... Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Rewriting sade(8)
Garrett Cooper yanef...@gmail.com writes: Now you're making a dangerous assumption that /inst isn't being used by the end-user for any predefined purpose. No, I'm making the entirely reasonable assumption that *during the installation process* sysinstall can mount whatever the hell it wants wherever the hell it wants. Why is this so hard to understand? If the user wants to create an /inst filesystem *during installation* it will be mounted as /inst/inst. If the user runs sade *at a later time* and creates an /inst filesystem, it will be mounted as /inst. Ok. Or maybe since `we're here' sade needs to be populating $DESTDIR/etc/fstab, not sysinstall ? At that time (when sysinstall invokes sade) there is no $DESTDIR/etc - sysinstall hasn't yet started extracting the base distribution. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On 4/10/10 7:18 AM, Bruce Simpson wrote: On 04/10/10 02:31, Julian Elischer wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Please do. Someone has to do something about deployment. For what it's worth, I've tripped over the garden rake on the ground, that is 'unsatisfied dependency' one too many times in commercial work. If PBIs can address this, even for FreeBSD's embedded and server use cases, they will likely be well recieved. though the embedded people would be EXACTLY the people who would NOT use this new feature. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On 4/10/10 10:36 AM, Sam Fourman Jr. wrote: I do have a question, assuming PBI's were merged officially into the FreeBSD ports tree, say I had PostgreSQL Server installed, via PBI. then I wanted to tweak a setting so I: cd /usr/ports/databases/postgresql84-server/ make deinstall clean would the PBI at this point be removed? or no because it is self contained? to some extent that depends on what we do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on em in HEAD ( was Re: em driver regression
Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net wrote: On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup ... Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On 4/10/10 3:35 AM, Garrett Cooper wrote: On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischerjul...@elischer.org wrote: On 4/10/10 12:20 AM, Garrett Cooper wrote: On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.sfour...@gmail.com wrote: On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande Moreamvandem...@gmail.com wrote: On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischerjul...@elischer.org wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. Let me start by saying FreeBSD ports is by far the best system I have used to date. but as good as it is, there is room for improvement. Being a FreeBSD user now for many years, one thing I think would be nice is: being able to have easier access to development ports( Masked ports kinda like Gentoo). Masking ports and packages in general introduces all sorts of fun new complexity for end users as well as maintainers. The last time I used Gentoo (which was only a matter of months ago), a lot portage packages were still masked even though they've been stable for months, years, etc. This is very annoying for me as an end-user because bug blah could be fixed in a later release but in order to unmask the pieces for version blah, I had to unmask 10~15 other `unstable packages', which greatly increased the chance of instability on my system (this was particularly the case back several years ago, but Gentoo has become more conservative over the years, and appears to be approaching some level of equilibrium with Fedora, Ubuntu, etc in terms of releases and package versioning). right now is a GREAT example, currently there are new Gnome ,KDE and Xorg. these are all MAJOR ports,dependencies run deeper and deeper with every release. there can never be enough testing...but they all exist in random subversion servers around the web... ports isn't going to solve this. Post the Xorg modularization (which needed to occur anyhow because Xorg and Xfree86 before that was were monolithic beasts), I personally don't see that change in the amount of flux on a quarterly cycle, and the number of packages I install today isn't that much greater than back 6 years ago when I started using FreeBSD. So, while there might be some claim here to note, I think it's mostly exaggerated. I would very much like to help test these Major ports, but installing them is a pain. there should be some sort of overlay system in place, so I can just build the development ports after agreeing to a few well placed warnings of course. and Well if I hose my system all to hell.. well then I could just click on a bunch of PBI's and I am back in business... Ok, apart from the interface (click a PBI, and magically you have packages installed)... how is this really different from binary packages? Have you tried installing binary packages lately via pkg_add? If not, I'd give it a shot instead of installing from ports. yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. If you can do this
Re: ports and PBIs
On Sat, Apr 10, 2010 at 8:18 AM, k...@pcbsd.org wrote: On Sat 10/04/10 3:35 AM , Garrett Cooper yanef...@gmail.com wrote: [...] yes but there are still dependency problems if you want to install a single package and you installed all the previous ones a year ago. With PBIs each package is self standing, so you can install one and not worry if it requires a different version of some library to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. Incorrect. The difference is in complexity at install-time. Even if you improve the package manager to better resolve and upgrade all related dependencies as a result of doing a firefox upgrade, the fact still remains that just to update one package, you may have to also update a TON of various packages / libraries, any of which may be critical to other applications on your system. If just a single one of those things fails, you can end up breaking a lot of applications on your system or even your entire desktop. PBI system simplifies this process. Updating firefox, since its self-contained, does NOT run the risk of borking anything else on the system. You don't need to work about libpng, libjpeg, or some other seemingly trivial library (to the end user) causing a huge breakage for xorg, or KDE/Gnome, etc. This in my opinion is the fatal flaw of pretty much every open-source system out there right now. Something both windows mac have recognized and dealt with. We instead try to write more and more complex package resolvers, while failing to address the main issue, that with such a complex chain of dependencies for something as simple as upgrading firefox, it increases the chances exponentially that something will break and ruin your day / weekend. PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing packages, why shouldn't I go to another operating system? Switching over to PBIs will reel in more desktop and entry-level sysadmins, etc, but I fear that it will isolate folks in the embedded market as well as several more seasoned users because of the implications involved with the extra bandwidth requirement and footprint. This gave me a bit of a chuckle. PBI would not be intended as a replacement for ports, rather a utilizing of ports in such a way that we can start building self-contained, stand-alone binaries for end-users and those of us who value their time more than a few MB of disk space. Considering at every BSD conference it seems that the majority of developers are running Mac laptops, it would seem that even some developers agree with the principle, they just aren't doing it on FreeBSD. :) I also, noticed this, and a
Re: ports and PBIs
Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: code.google - Xpra (anyone planning to port it ?)
Wilkinson, Alex wrote: Howdy people, This looks like a very nice app, has anyone got it working on FreeBSD yet ? http://code.google.com/p/partiwm/wiki/xpra -Alex Well, and what about http://code.google.com/p/neatx/ ? That would be useful! :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On 4/10/10 12:07 PM, Tim Kientzle wrote: Garrett Cooper wrote: If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. I'm not convinced that the simple update command you mention is actually feasible, much less desirable. (If I want to try out the new Firefox, why does that imply that my year-old Gimp has to be upgraded?) As for feasibility, here's the easy problem: A2.7 requires B3.6 ... one year passes ... A4.8 now requires B7.2 But A4.8 is incompatible with B3.6 and A2.7 is incompatible with B7.2. So neither A nor B can be updated separately without breaking the system. Here's the hard problem: A2.7 requires B3.6 ... one year passes ... I want to install C1.0 which requires B7.2 but there hasn't been a new release of A that works with B7.2. So I now simply cannot have both C1.0 and A2.7 installed at the same time because they require different versions of B. PBI avoids both of these problems. It may be unsuitable for embedded systems[1], but I see no reason we should not extend the existing ports/packages system with additional tools that target certain use cases, and PBI seems a good fit for the desktop case. Tim [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. It's even easy to handle at install time: * Installer writes libfoo-2.8.7.so to /Package/Shared/libfoo-2.8.7.so-temp-PID of installer * Installer computes hash of file as it's written * Installer renames file (delete if rename fails with EEXIST) * Installer writes symlink or hardlink into /Package/Bar yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. It's also to handle the cases where library A wants library B. you don't want library A in the shared place looking for B back in the original PBI directory so there may need to be some patching up. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on em in HEAD ( was Re: em driver regression
At 03:29 PM 4/10/2010, Jack Vogel wrote: Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Looks good for me now. BTW, I thought the multi-queue was supposed to be disabled on the em nic ? em0: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x3040-0x305f mem 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 em1: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x1000-0x101f mem 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 0(i5b)% vmstat -i interrupt total rate irq4: uart0 6285 13 irq21: ehci0 728 1 irq23: ehci11078 2 cpu0: timer 924321 1992 irq256: em0 9375 20 irq257: em1 127 0 irq258: em17 0 irq261: em12 0 irq262: ahci0 69 0 cpu3: timer 923686 1990 cpu1: timer 923651 1990 cpu2: timer 923597 1990 Total3712926 8001 0(i5b)% e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb mailto:bzeeb-li...@lists.zabbadoz.netbzeeb-li...@lists.zabbadoz.net wrote: On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup ... Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.htmlhttp://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
Julian Elischer wrote: On 4/10/10 12:07 PM, Tim Kientzle wrote: [1] Actually, PBI might work just fine even for embedded if we address the disk bloat issue. One approach would be to make /Package/Bar/libfoo-2.8.7.so a symlink or hardlink to /Package/Shared/libfoo-2.8.7.so-MD5-hash This gives easy sharing of identical files. yeah that's more or less what we were thinking.. hardlinks allow you to garbage collect when the last pbi that needs something is replaced/removed. The point of /Package/Shared in this design is basically that it provides a list of all of the files that can be shared, so you avoid doing a full disk search to identify other places that might have this file. You could accomplish the same goal by building and storing a database of sharable files somewhere, of course. (Curiously, no one has mentioned filesystem-level deduping yet as the big hammer solution... ;-) The LD_LIBRARY_PATH issue is the most interesting problem here. I don't immediately see a solution that doesn't include teaching ld-elf.so.1 about some form of per-application library path. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
Sam Fourman Jr. wrote: I do have a question, assuming PBI's were merged officially into the FreeBSD ports tree, say I had PostgreSQL Server installed, via PBI. then I wanted to tweak a setting so I: cd /usr/ports/databases/postgresql84-server/ make deinstall clean would the PBI at this point be removed? or no because it is self contained? Basically, I believe the proposal here is to add: * make pbi to the ports build system to create a PBI from a port and possibly add * make installpbi * make deinstallpbi to install/deinstall just the resulting PBI. In particular, I don't think anyone is suggesting removing or changing any existing ports/package capability. People who are happy with the existing ports/package system could continue using it exactly as-is. This would imply that you might build Postgres and install it both as a port/package and simultaneously as a PBI. I'm not sure what that would mean, though. The big question, of course: what impact would the addition of make pbi have on existing port/package support efforts? Is this creating extra work for existing maintainers? Should it be optional (enabled per-port) or somehow default? I suspect the next step is for someone to put forward a proposed implementation of make pbi so those interested can start trying it out and see what the impacts are. (If only the GSoC proposal deadline hadn't already passed. ;-) Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
not to be a troll but ... ... for those that want the ease-of-use of PBIs, why not just use PC-BSD in the first place? They seem to have their own QA process in place in terms of keeping the various large applications at a sane level. Kernel development could (just like it is on the Macs) be done in some kind of virtualization context. My own experience with helping people who try to run FreeBSD-CURRENT with an up-to-date ports tree is that there are far too many moving parts for it to be dependable. (For more on how often ports get broken by changes in -CURRENT, see http://wiki.freebsd.org/PortsBrokenOnCurrent. Note that that list is not complete.) mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LOR on em in HEAD ( was Re: em driver regression
What's disabled is the drbr stuff in the stack, that will not keep the 82574 from initializing MSIX and multiple internal queues, if you have that adapter I would suggest you #define EM_MULTIQUEUE somewhere (Makefile, if_em.h or if_em.c) since I believe its the one place where you will benefit. At least try it and see. Jack On Sat, Apr 10, 2010 at 3:07 PM, Mike Tancsa m...@sentex.net wrote: At 03:29 PM 4/10/2010, Jack Vogel wrote: Added the missing locks around calls to rxeof and checked it in a minute ago. Sorry guys! Looks good for me now. BTW, I thought the multi-queue was supposed to be disabled on the em nic ? em0: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x3040-0x305f mem 0xc1b0-0xc1b1,0xc1b25000-0xc1b25fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:15:17:c8:4b:99 em1: Intel(R) PRO/1000 Network Connection 7.0.4 port 0x1000-0x101f mem 0xc190-0xc191,0xc192-0xc1923fff irq 16 at device 0.0 on pci3 em1: Using MSIX interrupts with 5 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:c8:4b:98 0(i5b)% vmstat -i interrupt total rate irq4: uart0 6285 13 irq21: ehci0 728 1 irq23: ehci11078 2 cpu0: timer 924321 1992 irq256: em0 9375 20 irq257: em1 127 0 irq258: em17 0 irq261: em12 0 irq262: ahci0 69 0 cpu3: timer 923686 1990 cpu1: timer 923651 1990 cpu2: timer 923597 1990 Total3712926 8001 0(i5b)% e...@pci0:0:25:0:class=0x02 card=0x34ec8086 chip=0x10ef8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 13[e0] = PCI Advanced Features: FLR TP e...@pci0:3:0:0: class=0x02 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled Jack On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb mailto: bzeeb-li...@lists.zabbadoz.netbzeeb-li...@lists.zabbadoz.net wrote: On Sat, 10 Apr 2010, Mike Tancsa wrote: Hi Mike, At 05:11 PM 4/9/2010, Jack Vogel wrote: Don't know, but I would just ignore it, I think its a false warning anyway. OK. I updated to HEAD as of this AM, but now I get a panic at bootup ... Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ panic: mutex em0:rx(0) not owned at /usr/HEAD/src/sys/modules/em/../../dev/e1000/if_em.c:4093 cpuid = 3 KDB: enter: panic [ thread pid 0 tid 100032 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 0 tid 100032 td 0xc5f5bb40 kdb_enter(c0cb0e9d,c0cb0e9d,c0caf56e,c5b2ac28,3,...) at kdb_enter+0x3a panic(c0caf56e,c6002024,c11a0357,ffd,c5b2ac7c,...) at panic+0x136 _mtx_assert(c6002010,4,c11a0357,ffd,64,...) at _mtx_assert+0x87 em_rxeof(246,c5ff7d98,c5b2aca8,c088e194,c5ff7d98,...) at em_rxeof+0x3b em_handle_que(c6006000,1,c0cb5c9c,4f,c5ff7d98,...) at em_handle_que+0x38 taskqueue_run(c5ff7d80,c5ff7d98,c0ca6410,0,c0caf5f6,...) at taskqueue_run+0x103 taskqueue_thread_loop(c600a520,c5b2ad38,c0cac192,343,c0e0ce20,...) at taskqueue_thread_loop+0x68 fork_exit(c08dcde0,c600a520,c5b2ad38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc5b2ad70, ebp = 0 --- db This is a bug that seems to only happen in the Kitchener area as I hit it with a machine there just a few minutes ago as well. This one has fixed it for me: http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016249.html /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___
SIGSEGV in dc, at bcode.c:277 (function reset_bmachine())
As these things go, this probably isn't as critical as most thinsg
disussed on this list, but I happened to notice it today, built a
debugging world and at least cornered the annoying little varmint.
Sorry; no patch at this time. :-(
Here's how to reproduce it: while running CURRENT, invoke dc(1)
using the command-line expression-soecification (-e ...), thus:
freebeast(9.0-C)[2] dc -e 6 2/p
Segmentation fault (core dumped)
freebeast(9.0-C)[3]
This was running:
FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206447:
Sat Apr 10 14:49:56 PDT 2010
r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC i386
It's been a while since I did much with gdb, so the attempt at
post-mortem dump analysis wasn't very useful.
However, I did try re-running the test under gdb, which demonstrated
that on (initial) entry to reset_bmachine(), init_bmachine() has
not (yet?) been called; as as result, there is no storage allocated
to bmachine.readstack[].
This is an issue because reset_bmachine() tries to place data in
that array, thus:
270
271 /* Reset the things needed before processing a (new) file */
272 void
273 reset_bmachine(struct source *src)
274 {
275
276 bmachine.readsp = 0;
277 bmachine.readstack[0] = *src;
278 }
279
Now, I've not had occasion to prowl around and become familiar with
the internals of dc(1), so I don't know whether invoking reset_bmachine()
without having invoked init_bmachine() beforehand is just bogus, or if
perhaps reset_bmachine() should check to see if init_bmachine() has been
called (and if not, call it), or
But I think it's fairly clear that there's a bit of a logic error here.
[In case anyone was wondering why someone might try to use that form
of invocation: I was doing arithmetic in a shell script, and wanted
to be able to control rounding, rather than necessarily performing so-
called integer arithmetic.]
I can file a PR if it would help the tracking getting the bug fixed.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpxtNsKJuE9X.pgp
Description: PGP signature
Re: ports and PBIs
On Sat, Apr 10, 2010 at 7:47 PM, Mark Linimon lini...@lonesome.com wrote: not to be a troll but ... ... for those that want the ease-of-use of PBIs, why not just use PC-BSD in the first place? They seem to have their own QA process in place in terms of keeping the various large applications at a sane level. Kernel development could (just like it is on the Macs) be done in some kind of virtualization context. My own experience with helping people who try to run FreeBSD-CURRENT with an up-to-date ports tree is that there are far too many moving parts for it to be dependable. (For more on how often ports get broken by changes in -CURRENT, see http://wiki.freebsd.org/PortsBrokenOnCurrent. Note that that list is not complete.) mcl I have tried PC-BSD . I think it has an important draw back : Its theme is changing its colour cyclically . Any person having chronic illness Vertigo can not endure such continuous colour change . I could not find any place to stop that colour cycling other than to remove PC-BSD and install another operating systems onto its hard disk . In FreeBSD ports system , for me , problem is not the current port system . My idea is to have additional information about ports . For example , when a package is desired to be added by pkg_add , it is downloading the requested package , decompressing it , and saying that it is already installed , and it is not necessary to install it . Instead of this , the following structure ( a more proper one may be suggested , this is only an idea ) may be useful : In the ports , instead of using short names , use after a certain character a signature name of the port : As an example : kde4.version.signature.tbz . In installed systems , always install in directories having that name with signature . When an install is attempted , again use pkg_add kde4 for easiness , not its long name , or kde4.version to select a specified version . pkg_add should compute the signature of the installed port kde4, and check its value to installed signature name . If they are different , the port is destroyed ( install it unconditionally ) , otherwise proper . pkg_add should check port kde4... in ports . If their signatures are the same , it is not necessary to download and install it . For the dependencies , with a port kde4.tbz , maintain a kde4.xml listing all the dependencies , in which they may be inspected recursively ( Such lists are displayed in ports related web pages in www.freebsd.org ) . By checking all the related xml files and installed ports in a system , it will be possible to decide installation possibility of a port attempted to be installed without downloading actual port files . In a directory in the system , maintain a subdirectory of ports : Failed_Builds . Into this directory , store names of the packages which failed during building . When a package is attempted to be build , for itself and its dependencies , check that Failed_Builds directory for matching names . If there exists any one of them , do not start to build , because it will not be successfully completed . ( Entries from that directory may be deleted manually to allow build tries , and successful build may check this directory to remove matching entries if it is present . ) This Failed_Builds list is important , because when that information is not used , the same failed build is attempted many times for an install of some packages . Personally , I am not against an additionally available PBI directory in ports tree . Some users may prefer to use them although some packages will be repeatedly stored in different PBI packages and will be downloaded for each of them . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
boot process gets weirdly interrupted when using scroll lock
During the boot process, when rc scripts (or whatever) are printing messages, I turn on the scroll lock. As a result, I stop hearing my hard drive seeking, indicating that the system isn't loading. However, when I turn off the scroll lock, the boot process doesn't continue. It just hangs at the message that was last printed before I turned on the scroll lock. This happens when I turn on the scroll lock some time after Creating and/or trimming log files is printed, but before the vty login prompts show up. At this point I can't use the vtys (login, switch). CTRL+ALT+DEL seems to properly restart the system. But if I wait for 30 seconds, a login prompt finally shows up. The things to note is that (1) the text from the scripts never got printed, and (2) the system should have been loaded in 2 seconds, not 30. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On Sat, 2010-04-10 at 15:18 +0100, Bruce Simpson wrote: On 04/10/10 02:31, Julian Elischer wrote: Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some others and I, felt that these ideas seemed to make some sense and so I put them here for comment. Please do. Someone has to do something about deployment. For what it's worth, I've tripped over the garden rake on the ground, that is 'unsatisfied dependency' one too many times in commercial work. If PBIs can address this, even for FreeBSD's embedded and server use cases, they will likely be well recieved. If I understood the PBI construct correctly... How is this really that different than just producing static binaries? I mean, as I understood it, your bundling the binary and all of it's required libraries into a private directory tree and then playing linker games. robert. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports and PBIs
On Sat, Apr 10, 2010 at 10:03 AM, Julian Elischer jul...@elischer.org wrote: On 4/10/10 3:35 AM, Garrett Cooper wrote: [...] If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. It's more than just diskspace though. Consider the fact that now you're going to lose a lot of the memory sharing between shared libs and what-not, and now you'd have to be running N number of daemons . Take PCBSD for instance -- do they really revision packages with unshared dependencies, or are all of the dependencies updated at once? This becomes a big issue as you can't have dissimilar applications like dbus, gamin, openssh, etc running on the same system at one time. How does the PBI layout plan to deal with this kind of conflict -- apart from jails, which would greatly increase the required footprint...? If you can do this with package code, Maybe you will supply the packages.. Not quite sure what you meant here. better still, make the development ports a PBI, I am just thinking out loud here,but that may work, toughts? one could say I could use merge scripts like marcusmerge for example, or use Virtualbox... but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut it yet... thinks like Nvidia Video cards, multiple monitors, USB devices, and whatnot do not work on virtual box.. PBI's for development ports, with all the dependencies, wrapped in one package. Ok, well here's the thing. Instead of having N shared dependencies and libraries in /usr/local/lib, you'd have N**2 shared dependencies and libraries in each and every package. Now, let's look at $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 gcooper gcooper 6856203 Apr 10 00:05 /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi -rw-r--r-- 1 root wheel 517442 Apr 10 00:07 irssi-0.8.14_1.tbz The .tbz file is a file created with pkg_create -b, and the other file is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 . Big difference in size (13.25 fold difference). Yes but that is a worst case thing. We are talking about making a system where the PBIs contain all the libraries needed but that only some of them are installed, when there is not already the same one (i.e. identical) installed by a previous PBI. so if you installed, say, 20 PBI from the same 'set' you woudl only be installing one copy of the libraries that See above comment. PBIs only comprise a small set of packages in FreeBSD; if my understanding is correct based on a mirror referenced in pbidir.com, the number is currently under 500~750 PBIs -- this is drastically smaller than the number of binary packages produced by ports on a regular basis for FreeBSD. solution? well let all the developers develop working ports in progress in one place, give users like me a way to track these changes and install and test them... I think FreeBSD becomes a better place for it. Packages are more of the answer IMO, not PBIs. PBIs are merely a different set of contents and different means of delivering those contents, and while I like the idea of point - click - install, I'm not ready to create unnecessary complexity by having libraries rev'ed according to what the maintainer A believes are correct, even though maintainer B set it differently, and I'm not interested in sacrificing disk space for this reason. If I wanted to use a packaging scheme like this, I should be using Mac OSX as my primary operating system. well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing
