Re: [WAS:libc build error] it is HALF solved bw-iw cycle
On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" wrote: > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrote: > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > > unistd > > > > > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function > > > body after function declarator > > > intexecl( . > > > 332:46: > > > same... > > > > > > stops libc > > > otherwise clang36 seems to be building so far, if it builds unsure about > > > installworld > > > ___ > > > freebsd-current@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > > > > The mailing list strips attachments. Can you upload it somewhere and > > provide a link > > > > -- > > Allan Jude > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > Well, it is now r298350 Wed Apr 20... > However several problems > > SINGLE-USER BOOT PROBLEMS > 1... usual boot fails, this is single-user adjusted, but I cannot add swap > (swapon? swapctl?) > 1a... the last time, it was fixed with using the old /kernel ... > > multi-user boot problems > > 2... the last usual boot dumped with vm_pager or something, verbose boot > times out with xpt_config not completing. > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet updated > (which it now is ) for the latter > case I have yet to reboot to test > 2b... Reboot to test takes longer, /rescue/mount each filesystem > individually... > > > As one might surmise, I'd rather see buildworld made more foolproof than > other recent improvements > (pkg, zfs, ...) >From backup, I have r288246 kernel and nvidia.ko (v11) from source, I have world and all except those TWO files at r298350 )(v11), nvidia (newer) won't load with older kernel A few at-boot scripts no longer work as expected... but no other major problems (swap is present again) (multi-user boot works) Best practice maybe to update the kernel? It is a custom one from way back in 2004 initially without sound drivers and without debug symbols... and many esoteric lines added which I cobbled together at first then changed per diffs of GENERIC over the years... Thanks for any known methods J. Bouquet ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[WAS:libc build error] installworld result not satisfactory yet...
On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude wrote: > On 2016-04-20 12:06, Jeffrey Bouquet wrote: > > unistd > > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function > > body after function declarator > > intexecl( . > > 332:46: > > same... > > > > stops libc > > otherwise clang36 seems to be building so far, if it builds unsure about > > installworld > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > The mailing list strips attachments. Can you upload it somewhere and > provide a link > > -- > Allan Jude > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Well, it is now r298350 Wed Apr 20... However several problems SINGLE-USER BOOT PROBLEMS 1... usual boot fails, this is single-user adjusted, but I cannot add swap (swapon? swapctl?) 1a... the last time, it was fixed with using the old /kernel ... multi-user boot problems 2... the last usual boot dumped with vm_pager or something, verbose boot times out with xpt_config not completing. 2a could be a wrong setting is loader.conf, the nvidia.ko not yet updated (which it now is ) for the latter case I have yet to reboot to test 2b... Reboot to test takes longer, /rescue/mount each filesystem individually... As one might surmise, I'd rather see buildworld made more foolproof than other recent improvements (pkg, zfs, ...) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: qsort() documentation
On 2016-Apr-20 08:45:00 +0200, Hans Petter Selasky wrote: >There is something which I don't understand. Why is quicksort falling >back to insertion sort which is an O(N**2) algorithm, when there exist a >O(log(N)*log(N)*N) algorithms, which I propose as a solution to the >"bad" characteristics of qsort. O() notation just describes the (normally, worst case) ratio of input size to runtime for a given algorithm: Increasing the input size by (say) 100× means an insertion sort will take about 1× as long to run, whilst the "best" algorithms would take about 2000× as long. It says nothing about how fast sorting (say) 1000 items takes with either sort or how they behave on "typical" inputs. In general, the fancier algorithms might have better worst-case O() numbers but they have higher overheads and may not perform any better on typical inputs - so, for small inputs, insertion sort or bubble sort may be faster. IMO: - If you're only sorting a small number of items and/or doing it infrequently, the sort performance doesn't really matter and you can use any algorithm. - If you're sorting lots of items and sort performance is a real issue, you need to examine the performance of a variety of algorithms on your input data and may need to roll your own implementation. As long as qsort() behaves reasonably and its behaviour is documented sufficiently well that someone can decide whether or not to rule it out for their specific application, that is (IMHO) sufficient. -- Peter Jeremy signature.asc Description: PGP signature
FreeBSD_HEAD_i386 - Build #2909 - Failure
FreeBSD_HEAD_i386 - Build #2909 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2909/console Change summaries: 298361 by emaste: elfcopy: map all !alnum characters to '_' in binary input symbol names This matches bfd and gold. Obtained from: ELF Tool Chain r3445 Sponsored by: The FreeBSD Foundation 298360 by avos: net80211 (trivial, noop): remove duplicate check from hostap_recv_mgmt() Differential Revision: https://reviews.freebsd.org/D5483 298359 by avos: net80211: replace internal LE_READ_*/LE_WRITE_* macro with system le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by:adrian Differential Revision: https://reviews.freebsd.org/D6030 298358 by wma: Fix KGDB backtrace on ARM Modify trapframe decoding to properly analyze trapframe. Provide method for fixup_pc. It happens, that in some kernel functions, the GDB stack frame decoder cannot determine both func name and frame size. This is because these functions either contain invalid instruction, or their format does not match standard schema. Detect that scenarios and move PC accordingly to jump into known function schema, which GDB is able to parse. Obtained from: Semihalf Sponsored by: Juniper Networks Reviewed by: kib, zbb Differential Revision: https://reviews.freebsd.org/D5976 298357 by wma: Fix MFS symbol redefinition with clang 3.8.0 Newest CLANG objcpy uses different name parsing. Modify regexp to match (i.e. avoid substitution of "/" or "-" with "_"). Obtained from: Semihalf Sponsored by: Juniper Networks Reviewed by: hselasky, zbb Differential Revision: https://reviews.freebsd.org/D5873 298356 by kib: Arm and arm64 both have fueword() implemented for some time. Correct the comment. Sponsored by: The FreeBSD Foundation The end of the build log: [...truncated 89252 lines...] --- all_subdir_lib --- --- h_snprintf.full --- cc -O2 -pipe -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o h_snprintf.full h_snprintf.o --- h_snprintf.debug --- objcopy --only-keep-debug h_snprintf.full h_snprintf.debug --- all_subdir_gnu --- --- trgt.o --- --- all_subdir_lib --- --- h_snprintf --- --- all_subdir_gnu --- cc -O2 -pipe -DHAVE_CONFIG_H -DRL_NO_COMPAT -DMI_OUT=1 -DTUI=1 -DDEBUGDIR=\"/usr/lib/debug\" -I. -I/usr/src/gnu/usr.bin/gdb/kgdb/../arch/i386 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd -I/usr/src/gnu/usr.bin/gdb/kgdb/../../binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/gdb/config -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/gdb/include -I/usr/src/gnu/usr.bin/gdb/kgdb/../../../../contrib/binutils/bfd -I/usr/obj/usr/src/gnu/usr.bin/gdb/kgdb/../../../lib/libreadline/readline/.. -g -MD -MP -MF.depend.trgt.o -MTtrgt.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wn o-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/gnu/usr.bin/gdb/kgdb/trgt.c -o trgt.o --- all_subdir_lib --- objcopy --strip-debug --add-gnu-debuglink=h_snprintf.debug h_snprintf.full h_snprintf --- h_sprintf --- (cd /usr/src/lib/libc/tests/ssp && DEPENDFILE=.depend.h_sprintf NO_SUBDIR=1 make -f /usr/src/lib/libc/tests/ssp/Makefile _RECURSING_PROGS=t PROG=h_sprintf ) --- .depend.h_sprintf --- echo h_sprintf.full: /usr/obj/usr/src/tmp/usr/lib/libc.a >> .depend.h_sprintf --- h_sprintf.o --- cc -O2 -pipe -g -MD -MP -MF.depend.h_sprintf.h_sprintf.o -MTh_sprintf.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-pa
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Sylvain Garrigues changed: What|Removed |Added Attachment #169494|0 |1 is obsolete|| --- Comment #1 from Sylvain Garrigues --- Created attachment 169500 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=169500&action=edit Preserve spaces and tabs between quotes in /usr/sbin/config Correct patch attached -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error: stack underflow
> On Apr 20, 2016, at 1:24 AM, Andriy Gapon wrote: > > > I see this message "Error: stack underflow" when a loader menu is presented. > It seems that it comes from ficl. This is on a quite recent (< 2 weeks) head. > How can I debug this problem? > > I have one local modification to forth files, but I'm not sure if the problem > is > caused by it or by something in my boot configuration files. > > diff --git a/sys/boot/forth/menu-commands.4th > b/sys/boot/forth/menu-commands.4th > index 9adf30a46b661..813cbf12e9655 100644 > --- a/sys/boot/forth/menu-commands.4th > +++ b/sys/boot/forth/menu-commands.4th > @@ -243,6 +243,21 @@ also menu-namespace also menu-command-helpers > TRUE \ loop menu again > ; > > +: toggle_gui ( N -- N TRUE ) > + toggle_menuitem > + menu-redraw > + > + \ Now we're going to make the change effective > + > + dup toggle_stateN @ 0= if > + s" inhibit_gui" unsetenv > + else > + s" set inhibit_gui=1" evaluate > + then > + > + TRUE \ loop menu again > +; > + > \ > \ Escape to Prompt > \ > diff --git a/sys/boot/forth/menu.rc b/sys/boot/forth/menu.rc > index 3c7de7138b8ad..ddeccc9679fea 100644 > --- a/sys/boot/forth/menu.rc > +++ b/sys/boot/forth/menu.rc > @@ -126,6 +126,13 @@ set optionsmenu_keycode[6]=118 > set optionsansi_caption[6]="^[1mV^[merbose. ^[34;1mOff^[m" > set optionstoggled_ansi[6]="^[1mV^[merbose. ^[32;7mOn^[m" > > +set optionsmenu_caption[7]="Inhibit [G]UI. off" > +set optionstoggled_text[7]="Inhibit [G]UI. On" > +set optionsmenu_command[7]="toggle_gui" > +set optionsmenu_keycode[7]=103 > +set optionsansi_caption[7]="Inhibit [1mG[37mUI. [34;1mOff[37m" > +set optionstoggled_ansi[7]="Inhibit [1mG[37mUI. [32;7mOn[0;37m" > + > \ > \ BOOT ENVIRONMENT MENU > \ > I'll look into this. Thanks for bring it to our/my attention. -- Cheers, Devin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 11:57:47AM -0400, Paul Mather wrote:
> On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote:
>
> >> A packaged base is just another way of describing the state of the
> >> system. People on mailing lists will still be able to help people
> >> fix their problems, but they'll just use different information to
> >> pinpoint the precise components affected.
> >
> > How identify this systems? By 800-line lists of package versions?
>
>
> In my experience, troubleshooting usually proceeds from the
> description of the symptoms. So, if someone says, "I just updated
> and Sendmail has stopped sending e-mails," or "I just updated and I
> can no longer SSH into my system," then the logical question is to
> ask what versions of the packages they're running that pertain to
> those binaries. In other words, you start at the symptom and work
> outwards from there. In my experience, it's not necessary to have
> an exact inventory of a system to be able to solve a problem with
> it.
I see you point. Now try this, for some example, semi-hypothetical.
Some time ago we have troubles with sshd, fetchmail and other software
after r296462. pkg don't show any useful for versions of
sshd/fetchmail/etc because root cause will be breakin ABI in
libcrypto. For useful information pkg need to show version of quering
package and version of all depened packages. Is this allow now by
simple command?
Also, how to naming individual packages?
For port software we have released version, for STABLE -- rollover
release. Currently used naming is useless, using svn revision of
top-level dir usefull only for two-package case.
Using svn revision of individual dirs need addtional patches and
addtional rules:
/usr/src/sys/modules/aio # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn0.eu.freebsd.org/base/stable/10/sys/modules/aio
Relative URL: ^/stable/10/sys/modules/aio
Repository Root: svn://svn0.eu.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 295564
Node Kind: directory
Schedule: normal
Last Changed Author: jhb
Last Changed Rev: 185878
Last Changed Date: 2008-12-10 23:56:19 +0300 (Wed, 10 Dec 2008)
/usr/src/sys/modules/aio # less Makefile
# $FreeBSD: stable/10/sys/modules/aio/Makefile 185878 2008-12-10 20:56:19Z jhb $
.PATH: ${.CURDIR}/../../kern
KMOD= aio
SRCS= vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h
EXPORT_SYMS= aio_init_aioinfo aio_aqueue
.include
i.e. actual revision is max(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h) or
even
max(deps(vfs_aio.c opt_vfs_aio.h vnode_if.h opt_compat.h))
Is this posible?
> A tool like pkg makes it easy to know which package is associated
> with a given file and also which packages that package depends upon
> and which are dependencies of it. So, pkg makes it relatively
> painless to zoom in or out from a given symptom (i.e., binary or
> library that might have changed). I don't believe this is possible
> in the current FreeBSD setup. This is a huge gain in functionality.
You are lost may point. I am not against of pkg, I am just try more planing
before implementation. Changing in distribution scheme is very expensive.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: jpg attached, unsure if will go though... libc build error, svn of today
On 2016-04-20 12:06, Jeffrey Bouquet wrote: > unistd > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function > body after function declarator > intexecl( . > 332:46: > same... > > stops libc > otherwise clang36 seems to be building so far, if it builds unsure about > installworld > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > The mailing list strips attachments. Can you upload it somewhere and provide a link -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
jpg attached, unsure if will go though... libc build error, svn of today
unistd /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function body after function declarator intexecl( . 332:46: same... stops libc otherwise clang36 seems to be building so far, if it builds unsure about installworld ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Sylvain Garrigues changed: What|Removed |Added CC||freebsd-current@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Sylvain Garrigues changed: What|Removed |Added Version|10.3-RELEASE|11.0-CURRENT -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Apr 20, 2016, at 10:54 AM, Slawa Olhovchenkov wrote: >> A packaged base is just another way of describing the state of the >> system. People on mailing lists will still be able to help people >> fix their problems, but they'll just use different information to >> pinpoint the precise components affected. > > How identify this systems? By 800-line lists of package versions? In my experience, troubleshooting usually proceeds from the description of the symptoms. So, if someone says, "I just updated and Sendmail has stopped sending e-mails," or "I just updated and I can no longer SSH into my system," then the logical question is to ask what versions of the packages they're running that pertain to those binaries. In other words, you start at the symptom and work outwards from there. In my experience, it's not necessary to have an exact inventory of a system to be able to solve a problem with it. A tool like pkg makes it easy to know which package is associated with a given file and also which packages that package depends upon and which are dependencies of it. So, pkg makes it relatively painless to zoom in or out from a given symptom (i.e., binary or library that might have changed). I don't believe this is possible in the current FreeBSD setup. This is a huge gain in functionality. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OCZ ssdpx-1rvd0120 REVODRIVE support
17 апр. 2016 г. 13:44 пользователь "Rainer Duffner" написал: > > > > Am 17.04.2016 um 11:05 schrieb Pavel Timofeev : > > > > HI! I've recently got a SSD device. Yes, not a disk, but a device. > > It's called, i. e. one of the first REVODRIVEs. > > It's a PCI-express card with two embedded ssd disks about ~ 55GB size. > > And it's a raid card. Fake software raid. You can set it up as a > > RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured > > or set it as JBOD or something else. > > You just won't be able to boot from this device in that case. > > > > > > It says „Linux support planned“… > > on the product page. FreeBSD is not Linux =) Anyway I managed to install Ubuntu on it. Not on all of the configurations though. > > Tried loading the nvme(4) driver at the countdown? > > https://www.freebsd.org/cgi/man.cgi?query=nvme&sektion=4 > > It's included into GENERIC. But no /dev/nv* devices are found. > I’d suspect the Intel SSD 750 series would be a better choice… > Well, if I had a choise I wouldn't try to ask someone to help me ;) I'm not a developer, but it seemed to me not a really hard work to add full support of this device to FreeBSD, because it already work partyally and detects by graid. > > > Rainer Probably it's better to attach graid list/status output? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up
On Wed, Apr 20, 2016 at 1:10 AM, Johan Hendriks wrote: > Op 15/04/16 om 19:30 schreef Warner Losh: > > > Also a horrible name. It's a generic I/O scheduler. It can do lots of > > things. I keep saying that, and categorically refuse to name the more > > expansive scheduler anything that's so limiting. > > > > Warner > Thanks for all the work on this. > > One question? > > If the scheduler can do a lot of things what are the defaults set to? > Are they set to the Netflix load or more like the behauvier of a > standard FreeBSD before this patch. > Mostly neutral. You have to turn on the different steering engines. However, it does favor reads over writes, which may be a problem for write intensive work loads. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20 Apr 2016, at 15:53, Paul Mather wrote: > > Arguably, a packaged base will make it easier to help people, because it > makes more explicit the dependencies of different parts of the system. It's > been my experience that the interactions and impact of the various > /etc/src.conf settings are not entirely well known, at least to end-users. In particular, with libxo output from pkg, we can get a machine-readable detailed dump of all of the base system packages installed and provide a single ‘system dump’ command that includes this, relevant information from dmesg, and so on for bug triaging. David smime.p7s Description: S/MIME cryptographic signature
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 10:43:08AM -0400, Paul Mather wrote: > > > Message: 20 > > Date: Wed, 20 Apr 2016 12:48:06 +0300 > > From: Slawa Olhovchenkov > > To: Dan Partelly > > Cc: David Chisnall , Julian Elischer > > , Nathan Whitehorn , > > freebsd-current@freebsd.org > > Subject: Re: [CFT] packaging the base system with pkg(8) > > Message-ID: <20160420094806.gj6...@zxy.spb.ru> > > Content-Type: text/plain; charset=utf-8 > > > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > > > >> IMO, the number of packages per-se is not a problem as long as you > >> can manage them without arcane commands, aliases, pipe - filters, > >> or scripts. (they all have their place, but less , the better) My > >> point is that I don't really want to keep on my head a Unix hacker > >> hat. I (and presumably many other humans ) like simple things,which > >> allow me to type a short command (preferably the whole system should > >> be simple enough to be explained in one-two pages in handbook) , > >> wait for completion, and get on with my life. > > > > Yes and no. > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > Superficially, it does, but in reality it doesn't. I can grab the > source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* > settings in /etc/src.conf and build a kernel and world and end up > with a system that is missing a lot of functionality that is > ordinarily present with an empty /etc/src.conf. That missing > functionality could be the reason for a problem I am having with my > "10.3-RELEASE" system. Identification of custom builds is another problem and now we do this by contens of src.conf, make.conf options and kernel config file. This is enough and I am don't see necessity for change. > That is the reality of FreeBSD *now* and I still am able to get help on > FreeBSD mailing lists when I have problems. > > The case of a moving target is truer of those who choose to run > -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months > from now, what version of the code base am I actually running? > Sure, now we have the SVN revision number to help pinpoint the > version of the code being run (setting aside the effects of > /etc/src.conf), but back in the days when FreeBSD was in CVS we > didn't have that nicety and yet people were still able to get help > with problems running -STABLE or -CURRENT on the mailing lists. With CVS we use timestamp (as for csup). > A packaged base is just another way of describing the state of the > system. People on mailing lists will still be able to help people > fix their problems, but they'll just use different information to > pinpoint the precise components affected. How identify this systems? By 800-line lists of package versions? > Arguably, a packaged base will make it easier to help people, > because it makes more explicit the dependencies of different parts > of the system. It's been my experience that the interactions and > impact of the various /etc/src.conf settings are not entirely well > known, at least to end-users. Some /etc/src.conf settings is compile-time options and can't be done by packages. Kerberos, for example. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
> Message: 20 > Date: Wed, 20 Apr 2016 12:48:06 +0300 > From: Slawa Olhovchenkov > To: Dan Partelly > Cc: David Chisnall , Julian Elischer > , Nathan Whitehorn , > freebsd-current@freebsd.org > Subject: Re: [CFT] packaging the base system with pkg(8) > Message-ID: <20160420094806.gj6...@zxy.spb.ru> > Content-Type: text/plain; charset=utf-8 > > On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > >> IMO, the number of packages per-se is not a problem as long as you >> can manage them without arcane commands, aliases, pipe - filters, >> or scripts. (they all have their place, but less , the better) My >> point is that I don't really want to keep on my head a Unix hacker >> hat. I (and presumably many other humans ) like simple things,which >> allow me to type a short command (preferably the whole system should >> be simple enough to be explained in one-two pages in handbook) , >> wait for completion, and get on with my life. > > Yes and no. > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. Superficially, it does, but in reality it doesn't. I can grab the source for 10.3-RELEASE and then add a lot of WITH_* and WITHOUT_* settings in /etc/src.conf and build a kernel and world and end up with a system that is missing a lot of functionality that is ordinarily present with an empty /etc/src.conf. That missing functionality could be the reason for a problem I am having with my "10.3-RELEASE" system. That is the reality of FreeBSD *now* and I still am able to get help on FreeBSD mailing lists when I have problems. The case of a moving target is truer of those who choose to run -STABLE or -CURRENT. If I say I'm running 10.3-STABLE three months from now, what version of the code base am I actually running? Sure, now we have the SVN revision number to help pinpoint the version of the code being run (setting aside the effects of /etc/src.conf), but back in the days when FreeBSD was in CVS we didn't have that nicety and yet people were still able to get help with problems running -STABLE or -CURRENT on the mailing lists. A packaged base is just another way of describing the state of the system. People on mailing lists will still be able to help people fix their problems, but they'll just use different information to pinpoint the precise components affected. Arguably, a packaged base will make it easier to help people, because it makes more explicit the dependencies of different parts of the system. It's been my experience that the interactions and impact of the various /etc/src.conf settings are not entirely well known, at least to end-users. Cheers, Paul. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 2016.04.20 07:58, Lev Serebryakov wrote: It is very worrying to see such reports without any reaction from developers in one month before release. If there is one year till release, it is nothing. But in one month we will have code slush, and after that — release, which should be supported for several years! Also, suggested (and totally ignored in discussion) mechanisms with overlay packages is not UI, it is underlying mechanism which could be very useful. Again, I have nothing against good package management for base. But what I see now is scary, if you take one-month-before-release in account! You mention code slush, but keep saying one month before release. Code slush means *new features* are *discouraged*, not "freeze everything and let it sit for months without addressing any issues". Release is not planned until *September*, and if it is not ready in September, then the release will be delayed. In fact, releases are very frequently delayed since the dates are always estimates and never deadlines. Yes, we are getting somewhat close to release, but there is still time. Also, packaged base work was supposed to be complete enough for wide testing much earlier, but development was stalled for a while. Also, how much response do you expect in ~17 hours? Developers need time to sleep, do their day jobs, and formulate a detailed response to a detailed email. There are certainly issues, but this is not something that is going to be rushed into a release in a month to meet a hard deadline as you imply. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20.04.2016 11:12, David Chisnall wrote: > all of the complaints in this thread have been about the UI, not about the > underlying mechanism. Nope. And there are (small) thread in other mailing list with very big concerns about underlying mechanisms, which doesn't have any attention: https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-April/000183.html It is very worrying to see such reports without any reaction from developers in one month before release. If there is one year till release, it is nothing. But in one month we will have code slush, and after that — release, which should be supported for several years! Also, suggested (and totally ignored in discussion) mechanisms with overlay packages is not UI, it is underlying mechanism which could be very useful. Again, I have nothing against good package management for base. But what I see now is scary, if you take one-month-before-release in account! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
> If these informations were more public I think there will be less > annoyed posts in mailinglist and more constructive critics / ideas / > patches. > And there other issues arising from the lack of communication: How exactly bugs / incomplete features are treated in FreeBSD ? Many times the public gets the impression that save for the show-stopper bugs, or bugs which affect the employers of FreeBSD developers, they don't get too much priority. If any. I talked before about VIMAGE and the bugs surrounding it. Some of those bugs are there for years. Yes VIMAGE was good enough, and as was told before in this thread a success. I am not contesting that. Yet not even today all those bugs and memory leaks are fixed. Patches for some bugs floated around, some where collected some not, only god knows. I heard that now for FreeBSD 11 the FreeBSD foundation forked some money to get it done. I hope they will. Another example is the autofs mounter. The prject was marked as complete by FreeBSD foundation in 2014. Last I tried it to autmount removable devices, it left directory after directory in the autofs managed directory. This is known behavior. It also did not worked as it should ??? (show it manage removable media correctly ) changing CD/DVD media disks. Presumably In could have somehow manage it to work by making yet another scaffolding of scripts as a questionable glue between devd and automounters. That if devd receives media change notifications. I dont know. If not I could patch the kernel, yeah. But it is just much to simple to not bother at all and use OSx. DRM drivers ? Done, but more or less in the same state by years. At least not important in server space. outlining those issues should not make anyone feel criticized. Things are what they are, maybe its better to think what are the root causes of issues like those outlined before. Does the project lacks manpower ? If it does maybe the developers should do something to attract and nurse more and more potential people. Are those issues you dont want to work on or you dont have an agenda to make them bug free and work orthogonal? No problem, make a statement and say .. we wont ever do this , or it will take 6 years ... or whatever. It is not helpful to complain that people do not appreciate your hard work, becuae ppl do. Also not helpful to complain about tones which should be toned down by 2 orders of magnitude, peasants and castles. It is also not helpful to complain that people oppose progress when you are pointed some issues.It couldn't be further removed from truth, at least in my case. But I think most ppl on this list want progress. At least this is my impression. Too much of Unix is badly stuck in the past. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 11:43:00AM +0100, Matthew Seaman wrote: > On 04/20/16 10:48, Slawa Olhovchenkov wrote: > > > While number of packages don't see outside internal -- this is > > irrelevant. > > After possibility of update individual package -- nuber of packages is > > impotant. > > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > > 11.0? 11.1-RC3? How you name it? How identify it for take support on > > forum or mail list? > > > > How name system, updated all w/o compiler? or only some services? > > Currently we have simple naming: > > > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > > This is shortly and clearly identify system to anyone. > > > > How do this with many packages? > > Hmmm Good point. > > At release time, a set of packages will be generated. These will all > have the version number of the release eg. 11.0. That's simple and > unambiguous. > > Subsequently adding patches will add a patch level to the version, so > 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel > will cause the output of uname(1) to show the new patch level, but > updates to user land should be reflected in the output of > freebsd-version(1). That's exactly the same as now, and assuming you, > as an end user, install the default set of FreeBSD packages and apply > all the patches as they come out, then there should be no problem. > > This implies that /every/ patchset will include an update to the package > containing freebsd-version. > > What packaging base does do is allow you to be selective in the patches > you apply. So, for instance if patch -p1 was not relevant to you, you > might not install it. So you could end up with a system where you > hadn't installed patches -p1 -- -p9 but you did install patch -p10. The > freebsd-version(1) output would presumably show the system as 11.0-p10 > -- but that's certainly not the same as a system with all of those > patches -p1 to -p9 applied. Or you could just install the updated > freebsd-version(1) package and have your system blatantly lie about its > patching status. This is about RELENG, what about STABLE and CURRENT? > So, yes, this does change the meaning of the version number string. > It's morally equivalent to tracking the releng/11.0 branch in SVN but > compiling your system with various WITH_FOO or WITHOUT_BAR flags, and > possible local modifications to the code base to back out certain > commits. It's still 11.0-SOMETHING but it's not clear exactly what that > something should be. Hopefully people that do such things will be > sufficiently technically sophisticated to be able to characterize their > problems based on the versions of any relevant FreeBSD packages. > > On the release of 11.1 there would be a complete new set of system > packages generated, and the upgrade process would install the new > versions of those packages all round, even if the content of an > individual package was identical to the one in 11.0. There's probably a > handy optimization where we compare the before and after checksums for > package files and don't overwrite on disk what is identical between > package versions, but do update all of the bookkeeping in the pkgdb. New numbering scheme is very hard problem... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
Matthew Seaman wrote on 04/20/2016 12:43: On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. This will be a really nice feature which can save a lot of bandwidth and storage for backups after upgrade. (but I don't know how many files are usually unchanged between upgrades) Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. I really like FreeBSD, I am using it for more than 15 years on daily basis. FreeBSD had good and bad times (releases / changes) but one thing stays always the same - still bad communication about new features, work in progress etc. I think it is not too hard to publish papers about new base packages. Proposals, current state, ToDo to better inform users about upcoming changes. I think these informations already exist in some private form between developers. If these informations were more public I think there will be less annoyed posts in mailinglist and more constructive critics / ideas / patches. I did a guick search and found only one closely related page about packaged base: https://wiki.freebsd.org/FreeBSD-ng last edited 2014-03-11 Even this old page has "Known problems" mentioning the situation what we have now in this thread (fed-up people on both sides). So I think this was expected and people involved in this project could have do communication better. I had some concerns about it and some of them were explained and canceled after reading more than 100 posts in this thread. (some concerns remain). I believe if it was written in FreeBSD Wiki, there were not be so much dissapointed posts. I don't want to offend anybody on this list or FreeBSD team. I just think that things like this can and should be communicated better next time. Sysadmins and sysdevelopers have different point of view to a lot of things and it is better to talk about it before things are done and cannot be undone. Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: qsort() documentation
Quoting Warren Block : On Tue, 19 Apr 2016, Aleksander Alekseev wrote: Why Wikipedia, specifically? There are a lot of places that describe quicksort. How about just Note: This implementation of qsort() is designed to avoid the worst-case complexity of N**2 that is often seen with standard versions. I would say that this statement is just false. Worst-case complexity is still N**2. How about something like: """ This implementation of qsort() has worst case complexity of N**2. However measures were taken that make it very unlikely that for some random input N**2 swaps will be made. It's still possible to generate such an input on purpose though. See code below for more details. """ Okay: The quicksort algorithm worst-case is O(N**2), but this implementation has been designed to avoid that for most real data. Keep in mind that there is no requirement whatsoever that the qsort() function uses the quicksort algorithm, even if that is a common way to implement qsort() Also, worst-case is worst-case, no matter how unlikely. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 04/20/16 10:48, Slawa Olhovchenkov wrote: > While number of packages don't see outside internal -- this is > irrelevant. > After possibility of update individual package -- nuber of packages is > impotant. > Take fresh 11.0. Before 11.1 update only kernel. What you system have? > 11.0? 11.1-RC3? How you name it? How identify it for take support on > forum or mail list? > > How name system, updated all w/o compiler? or only some services? > Currently we have simple naming: > > 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. > This is shortly and clearly identify system to anyone. > > How do this with many packages? Hmmm Good point. At release time, a set of packages will be generated. These will all have the version number of the release eg. 11.0. That's simple and unambiguous. Subsequently adding patches will add a patch level to the version, so 11.0-p1, 11.0-p2 exactly as now. Only patches that affect the kernel will cause the output of uname(1) to show the new patch level, but updates to user land should be reflected in the output of freebsd-version(1). That's exactly the same as now, and assuming you, as an end user, install the default set of FreeBSD packages and apply all the patches as they come out, then there should be no problem. This implies that /every/ patchset will include an update to the package containing freebsd-version. What packaging base does do is allow you to be selective in the patches you apply. So, for instance if patch -p1 was not relevant to you, you might not install it. So you could end up with a system where you hadn't installed patches -p1 -- -p9 but you did install patch -p10. The freebsd-version(1) output would presumably show the system as 11.0-p10 -- but that's certainly not the same as a system with all of those patches -p1 to -p9 applied. Or you could just install the updated freebsd-version(1) package and have your system blatantly lie about its patching status. So, yes, this does change the meaning of the version number string. It's morally equivalent to tracking the releng/11.0 branch in SVN but compiling your system with various WITH_FOO or WITHOUT_BAR flags, and possible local modifications to the code base to back out certain commits. It's still 11.0-SOMETHING but it's not clear exactly what that something should be. Hopefully people that do such things will be sufficiently technically sophisticated to be able to characterize their problems based on the versions of any relevant FreeBSD packages. On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: [CFT] packaging the base system with pkg(8)
On Wed, Apr 20, 2016 at 12:00:36PM +0300, Dan Partelly wrote: > IMO, the number of packages per-se is not a problem as long as you > can manage them without arcane commands, aliases, pipe - filters, > or scripts. (they all have their place, but less , the better) My > point is that I don't really want to keep on my head a Unix hacker > hat. I (and presumably many other humans ) like simple things,which > allow me to type a short command (preferably the whole system should > be simple enough to be explained in one-two pages in handbook) , > wait for completion, and get on with my life. Yes and no. While number of packages don't see outside internal -- this is irrelevant. After possibility of update individual package -- nuber of packages is impotant. Take fresh 11.0. Before 11.1 update only kernel. What you system have? 11.0? 11.1-RC3? How you name it? How identify it for take support on forum or mail list? How name system, updated all w/o compiler? or only some services? Currently we have simple naming: 10.3-RC1, 10.3-RELEASE, 10.3-p7, 10.3-STABLE r123456. This is shortly and clearly identify system to anyone. How do this with many packages? I am describe in -pkgbase expirence of updating system. How I am can naming this (my) system? Solaris don't ship new version often and don't have rollover updates. I think, first step may be split to only two package (kernel and world) and resolve many other issuses: distinc base packages from port packages, beadm compatibility, /etc and config updates (/etc/rc.d is not config but currently allowed to editing, this is distinct from plain ports configs) and others. After expirence with this next step will be more clear. > When I said people should pay more attention to Redmond and Cupertino, this > is what I meant. UIs are important. Easy service management, fault reporting > and so on should be automated. We shouldn't waste our time doing what the > computer should do in the first place. Most people want to get the job > done, so they can proceed with what is important for them. I am very sorry > if this is so offensive to some people that they feel attacked, but > unfortunately there aint much I can do to alleviate this. > > > > > 1) The number of packages that the base system has. > > 2) The user interface by which the packages are presented. > > > > I believe (and, please, correct me if I’m wrong), that all of the > > complaints in this thread have been about the UI, not about the underlying > > mechanism. That’s not to say that they’re unimportant (quite the reverse), > > but that they can be solved concurrently with the task of preparing the > > base system for distribution in packaged form. > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 11.0-RELEASE pkg base & base.txz file
> On Apr 20, 2016, at 03:54, krad wrote: > > will it still be buildable though from source? Yes -- Renato Botelho ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
IMO, the number of packages per-se is not a problem as long as you can manage them without arcane commands, aliases, pipe - filters, or scripts. (they all have their place, but less , the better) My point is that I don't really want to keep on my head a Unix hacker hat. I (and presumably many other humans ) like simple things,which allow me to type a short command (preferably the whole system should be simple enough to be explained in one-two pages in handbook) , wait for completion, and get on with my life. When I said people should pay more attention to Redmond and Cupertino, this is what I meant. UIs are important. Easy service management, fault reporting and so on should be automated. We shouldn't waste our time doing what the computer should do in the first place. Most people want to get the job done, so they can proceed with what is important for them. I am very sorry if this is so offensive to some people that they feel attacked, but unfortunately there aint much I can do to alleviate this. > > 1) The number of packages that the base system has. > 2) The user interface by which the packages are presented. > > I believe (and, please, correct me if I’m wrong), that all of the complaints > in this thread have been about the UI, not about the underlying mechanism. > That’s not to say that they’re unimportant (quite the reverse), but that they > can be solved concurrently with the task of preparing the base system for > distribution in packaged form. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Error: stack underflow
I see this message "Error: stack underflow" when a loader menu is presented. It seems that it comes from ficl. This is on a quite recent (< 2 weeks) head. How can I debug this problem? I have one local modification to forth files, but I'm not sure if the problem is caused by it or by something in my boot configuration files. diff --git a/sys/boot/forth/menu-commands.4th b/sys/boot/forth/menu-commands.4th index 9adf30a46b661..813cbf12e9655 100644 --- a/sys/boot/forth/menu-commands.4th +++ b/sys/boot/forth/menu-commands.4th @@ -243,6 +243,21 @@ also menu-namespace also menu-command-helpers TRUE \ loop menu again ; +: toggle_gui ( N -- N TRUE ) + toggle_menuitem + menu-redraw + + \ Now we're going to make the change effective + + dup toggle_stateN @ 0= if + s" inhibit_gui" unsetenv + else + s" set inhibit_gui=1" evaluate + then + + TRUE \ loop menu again +; + \ \ Escape to Prompt \ diff --git a/sys/boot/forth/menu.rc b/sys/boot/forth/menu.rc index 3c7de7138b8ad..ddeccc9679fea 100644 --- a/sys/boot/forth/menu.rc +++ b/sys/boot/forth/menu.rc @@ -126,6 +126,13 @@ set optionsmenu_keycode[6]=118 set optionsansi_caption[6]="^[1mV^[merbose. ^[34;1mOff^[m" set optionstoggled_ansi[6]="^[1mV^[merbose. ^[32;7mOn^[m" +set optionsmenu_caption[7]="Inhibit [G]UI. off" +set optionstoggled_text[7]="Inhibit [G]UI. On" +set optionsmenu_command[7]="toggle_gui" +set optionsmenu_keycode[7]=103 +set optionsansi_caption[7]="Inhibit [1mG[37mUI. [34;1mOff[37m" +set optionstoggled_ansi[7]="Inhibit [1mG[37mUI. [32;7mOn[0;37m" + \ \ BOOT ENVIRONMENT MENU \ -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20 Apr 2016, at 06:06, Julian Elischer wrote: > > my problem with 400 packages is that is is hard to decide what you are > actually running.. or is it FreeBSD 11? is it FreeBSD 10.95342453? > you have no way to tell exactly what you have without comparing all the > packages to a known list. > uname doesn't mean much, nor does "__FreeBSD_version" if everything comes > with its own versions. I think that it’s very important, for the purpose of a constructive discussion, to separate the two concerns: 1) The number of packages that the base system has. 2) The user interface by which the packages are presented. I believe (and, please, correct me if I’m wrong), that all of the complaints in this thread have been about the UI, not about the underlying mechanism. That’s not to say that they’re unimportant (quite the reverse), but that they can be solved concurrently with the task of preparing the base system for distribution in packaged form. Having fine-grained packages makes a lot of things possible that are difficult otherwise, but we do need to fix the UI. > the 'leaf' concept in pkg helps with this a bit, but we've always considered > FreeBSD bas as a sort of monalithic entity that moves forward together. > > you are running 10.1p8 pr 10.2p1 that tells you all you need to know. > If you now need to take into account 400 different dimensions you have a much > harder way to describe what you have.. > > I mentioned this before but I think hte answer is to make a change on the > way that "meta packages" are displayed by default in pkg. Part of the problem is that we don’t actually have metapackages. A metapackage is a package that *contains* other packages. What we actually have is empty packages that *depend on* other packages. The package tool has no way of distinguishing a package that you install for the sole purpose of installing its dependencies from one that you install because you want it (though having no files inside it might serve as an heuristic that would work). > If I install the meta package, I really don't want to see all the sub > packages tat are unchanged unless I add '-v'. On the other hand if I upgrade > a sub package I want to see that in the context of the metapackage. Similarly > if I uninstall of the subpackages. Doing this properly also requires the notion of optional default and non-default subpackages. I should be prevented from uninstalling (at least, without a lot of -f) non-optional subpackages. For example, on a small system where I’m not using zfs, I might uninstall the libzfs subpackage from freebsd-libs, but if I try to uninstall the libc package then the system should shout at me. > > so something like this would remove most of my objections: > > # pkg info > = system packages > FreeBSD-networking-11.0.2_1FreeBSD networking subsystem and > commands > - ipfw-11.0.2-1 ipfw tools (uninstalled) > - fbsd-tcpdump-11.0.2-1 Built in tcpdump tools (uninstalled) > * openssl-11.0.2-2Openssl support (upgraded CVE-123456 > FreeBSD-base-base-11.0.2-1 The absolute minimum booting base > system > [...] > external packages == > apache22-2.2.31Version 2.2.x of Apache web server with > prefork MPM. > apr-1.5.2.1.5.4Apache Portability Library > autoconf-2.69 Automatically configure source code on many > Un*x platforms > autoconf-wrapper-20131203 Wrapper script for GNU autoconf > [...] > > > Maybe I uninstalled ipfw because I use pf and I install the ports tcpdump so > I can remove the built in one. > I have installed a new openssl due to a bugfix.. > > This gives me a real instant feel for what I'm running.. > if I add -v then I see all 400 packages, but I really don't want to see them > 99.99% of the time > > I believe the "leaf" method gives close to this but if we could get the above > I'd have absolutely no objections. Thank you for this suggestion. I think that this is the sort of UI that makes a lot of sense (though having subpackage support would also be useful for ports). It’s also the kind of thing that I think we could persuade the Foundation to fund if there is not enough volunteer time to implement it. David smime.p7s Description: S/MIME cryptographic signature
Re: [CFT] packaging the base system with pkg(8)
On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber wrote: > On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote: >> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote: >> > >> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755 >> > packages?! WHY?! What are reasons and goals to split base in such >> > enormous number of packages? >> >> Just a guess, having done the same thing myself: it means that updates can >> be >> more targeted. >> > > This is exactly the reason, which has been answered numerous times. I don't know what the "ideal" number of packages is. 755 does seem large. However, I see it being like KSE. In hindsight KSE was overly complicated and M:N threading wasn't the way to go. However, Julian's work brought native threading to FreeBSD. Something it sorely needed. Similarly, the packaging of base FreeBSD is something that has been desperately needed for a long time but the work to get there was simply overwhelming. Initially there will very likely be painful problems, but I'm comfortable that all those involved will course correct and converge on something that most people will be content with. I'm sure there are those with well articulated criteria for a different decomposition of base, with specifics on how and why. Those select individuals can contribute meaningfully to this discussion. Everyone else should just applaud their hard work and get back to work. There are plenty of bugs that could have been fixed in the time it would have taken to digest this whole thread. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up
Op 15/04/16 om 19:30 schreef Warner Losh: > Also a horrible name. It's a generic I/O scheduler. It can do lots of > things. I keep saying that, and categorically refuse to name the more > expansive scheduler anything that's so limiting. > > Warner Thanks for all the work on this. One question? If the scheduler can do a lot of things what are the defaults set to? Are they set to the Netflix load or more like the behauvier of a standard FreeBSD before this patch. regards Johan ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On 20/04/2016 06:12, Daniel Eischen wrote: > [And it really bothers me that FreeBSD 'pkg list' behaves > like 'pkg files' or similar should. It seems intuitive > that 'pkg list' should list the packages, not all the files > in all the packages.] 'pkg list' is one of the aliases defined in the default pkg.conf -- if you want to rename it to 'pkg files' that's trivially easy. If there's any sort of consensus that 'pkg files' would be preferable in general then I'm sure that the sample pkg.conf can be fixed in git. Cheers, Matthew signature.asc Description: OpenPGP digital signature
