Re: freebsd-update(8) without an echo of "You must be root to run this."

[Chris Rees]

Hey,

On 16 February 2021 08:53:29 GMT, Graham Perrin  wrote:
>
>
>         echo "You must be root to run this."
>
>Below: is this my PEBKAM, or (with a system that is preconfigured to 
>deny login as root) _should_ there be an echo of the requirement to run
>
>as root?
>
>
>
>mowa219-gjp4-vm-hellosystem-eol-freebsd% su -
>Password:
>su: Sorry
>mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED 
>/etc/master.passwd
>root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh
>mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r

Sudo means that you are root.  *LOCKED* just disables the root password.

Chris
___
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: bug with special bracket expressions in regular expressions

[Chris Rees]

On 02/09/2013 16:09, Damian Weber wrote:


On Mon, 2 Sep 2013, Andriy Gapon wrote:


re_format(7) says:
  There are two special cases? of bracket expressions: the bracket expres?
  sions ?[[::]]? and ?[[::]]? match the null string at the beginning and
  end of a word respectively.  A word is defined as a sequence of word
  characters which is neither preceded nor followed by word characters.  A
  word character is an alnum character (as defined by ctype(3)) or an
  underscore.  This is an extension, compatible with but not specified by
  IEEE Std 1003.2 (?POSIX.2?), and should be used with caution in software
  intended to be portable to other systems.

However I observe the following:
$ echo cd0 cd1 xx | sed 's/cd[0-9][^ ]* *//g'
xx
$ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9][^ ]* *//g'
cd1 xx

In my opinion '[[::]]' should not affect how the pattern is matched in this 
case.

Any thoughts, suggestions?

there are two simpler expressions, whose difference I don't understand either
(tested on 8.4-PRERELEASE)

$ echo cd0 cd1 xx | sed 's/cd[0-9] //g'
xx
$ echo cd0 cd1 xx | sed 's/[[::]]cd[0-9] //g'
cd1 xx


Well, I agree with your analysis, and I think it's certainly a bug.

Do you think that the BUGS line in regex(3) should perhaps be extended 
to never works properly?:


Word-boundary matching does not work properly in multibyte locales.

[[::]] can be replaced by \b in a pcre, which works perfectly fine (of 
course)


echo this word word should be deleted | perl -pe 's,\bword ,,g' this 
should be deleted


Chris

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: [HEADSUP] No more pkg_install on HEAD by default

[Chris Rees]

On 14 Jul 2013, at 08:29, Teske, Devin wrote:
 
 To give you an idea as to just how helpful this is...
 
 Imagine the following hierarchy:
 
 src/pkgbase/depend/mystuff/script1
 src/pkgbase/depend/mystuff/textfile1
 src/pkgbase/depend/mystuff/sourcefile.c
 src/pkgbase/depend/mystuff/Makefile
 
 You are a developer. You want to ship a package that contains script1, 
 textfile1, and binary1 (which is compiled by saying make to turn 
 sourcefile.c into binary1)
 
 You want to ship 8 types of packages:
 
 FreeBSD-4.11
 FreeBSD-8.1 (i386)
 FreeBSD-8.1 (amd64)
 RedHat EL 4
 RedHat EL 6 (i386)
 RedHat EL 6 (x86_64)
 Debian Wheezy
 Debian Wheezy 64-bit
 
 This is where my framework comes in-handy...
 
 cd ~/src/pkgbase/freebsd/RELENG_4/category/mystuff
 make
 # it pulled the necessary bits from src/pkgbase/depend/mystuff and built 
 the .tgz
 
 cd ~/src/pkgbase/freebsd/RELENG_8/category/mystuff
 make
 # it pulled the necessary bits from the depend dir and built .tbz
 
 cd ~/src/pkgbase/redhat/rhel4/category/sub-category/mystuff
 make
 # pulled in depend and made .rpm
 
 cd ~/src/pkgbase/redhat/rhel6/category/sub-category/mystuff
 make
 # pulled in depend and made .rpm
 
 etc.
 
 Of course, *any* time the depend tree has binaries in it... you have to first 
 do a make in there on the platform you want to ship the binary for, and then 
 do make depend in the platform-specific tree to pull in the binaries. Once 
 you've done that, you don't have to muck with the depend tree again unless 
 there are changes there.
 
 So, I assume that your prejudice remarks are because you haven't either seen 
 (a) such a platform or (b) such a need for said platform.
 
 Yeah, I could rewrite the freebsd-specific logic to use pkg create, but let 
 me tell you...
 
 When you have to touch a file that needs to get shipped out to multiple 
 platforms...
 
 It's damned nice to be able to build the FreeBSD packages under RedHat 
 *BECAUSE* the redhat RPMs can't be built under anything else (building an RPM 
 on FreeBSD and attempting to install it on RedHat results in an error message 
 similar to this is an rpm for FreeBSD; go away).
 
 Whereas FreeBSD will never balk about a package built on another platform.
 
 It's a huge time-saving measure... not having to jump over to each/every 
 unique platform to package things up *IF/WHEN* you know that there are no 
 binaries in the package *or* you've already checked the pre-compiled binaries 
 into the arch-specific hierarchy.
 
 
 
 
 Or you
 can maintain the old cruft for your business -- just don't expect
 anyone else to use it, or even want to.
 
 
 
 I have no intention of making old-world packages... but I also have no 
 intention of using pkg create.

You still haven't really explained at all why you can't use libpkg.  If it 
doesn't run on Debian (not tried), it's got to be easier to port it than 
rewrite a hacked version, hasn't it???  At least then you'll also be 
contributing back.

Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: swapon(8) vnode-backed md and gbde/geli encryption support

[Chris Rees]

On 27 Jun 2013, at 09:06, Hiroki Sato wrote:

 Hiroki Sato h...@freebsd.org wrote
  in 20130623.035356.644417021040610458@allbsd.org:
 
 hr Hi,
 hr
 hr  I created a patchset to add support of automatic generation of
 hr  vnode-backed md(4) devices and gbde/geli geom providers to swapon(8)
 hr  via /etc/fstab.  We already have equivalent functionality by using
 hr  rc.d scripts.  This simplifies rc.d scripts and fixes a race between
 hr  mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab.
 
 A slightly revised patch is attached.  I will commit this today.
 
 -- Hiroki
 - Add vnode-backed swap space specification support.  This is enabled when
  device names md or md[0-9]* and a file option are specified in
  /etc/fstab like this:
 
  mdnoneswapsw,file=/swap.bin   0   0
 
 - Add GBDE/GELI encrypted swap space specification support, which
  rc.d/encswap supported.  The /etc/fstab lines are like the following:
 
  /dev/ada1p1.bde   noneswapsw  0   0
  /dev/ada1p2.eli   noneswapsw  0   0
 
  .eli devices accepts aalgo, ealgo, keylen, and sectorsize as options.
 
  swapctl(8) can understand an encrypted device in the command line
  like this:
 
  # swapctl -a /dev/ada2p1.bde
 
 - -L flag is added to support late option to defer swapon until
  rc.d/mountlate runs.
 
 - rc.d script change:
 
rc.d/encswap - removed
rc.d/addswap - just display a warning message if  is defined.
rc.d/swap1 - renamed to rc.d/swap
rc.d/swaplate - newly added to support late option
 
 These changes alleviate a race condition between device creation/removal
 and swapon/swapoff.
 
 MFC after:  1 week

Looks fantastic-- better than hacking around in shell scripts I suppose :)

Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: BSD sleep

[Chris Rees]

On 29 May 2013 07:13, Matthew Seaman matt...@freebsd.org wrote:

 On 29/05/2013 05:59, Michael Sierchio wrote:
  On Tue, May 28, 2013 at 4:45 PM, Joshua Isom jri...@gmail.com wrote:
 
 
  You think it's trivial until you read this:
 
  http://infiniteundo.com/post/**25326999628/falsehoods-**
  programmers-believe-about-time
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

 
 
  Some days have 86400 seconds, some have 86401.  There is a provision for
  two leap seconds to be applied at once, but that hasn't ever happened.
   Still, a truly correct clock, set to UTC, might someday read
 
  23:59:59
  23:59:60
  23:59:61
  00:00:00
 
  How many seconds did that hour have?

 Right.  The fact that on very rare occasions a minute may not have 60
 seconds in it plus many other corner cases in calculating the current
 wall-clock time is an amusing irrelevance.

 First of all, sleep deals in local elapsed time, which is a well defined
 property even if the displayed wall-clock time would be all over the
 place due to DST changes or relativistic effects or whatever.

 In this case, I'd be pretty surprised if GNU sleep's algorithm was
 anything more complicated than to convert the stated time into seconds
 and then sleep that number of seconds.  And to do that conversion, it
 wwould just define one minute as 60 seconds, one hour as 60 minutes, one
 day as 24 hours, one week as 7 days, perhaps one month as 30 days, one
 year as 365 days[*].  Sure, it's simplistic and unsophisticated, but as
 an engineering solution it's good enough for the vast majority of
 purposes.

OK, but is this really something the OS should handle?  I'm sure sleep
`expr 3600 \* 2` will suffice and is perfectly readable, including being
more portable.

Why should we keep putting these weird extensions in?  At some point it
just becomes fiddling, and yet another source of error when porting

Chris
___
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: ipfilter(4) needs maintainer

[Chris Rees]

On 19 Apr 2013 10:46, David Demelier demelier.da...@gmail.com wrote:

 2013/4/14 Gary Palmer gpal...@freebsd.org:
  On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote:
  Is it possible to move ipfilter into a port?
 
  That may work short term, but the ENOMAINTAINER problem will quickly
creep
  up again as kernel APIs change.  If the author has lost interest in
  maintaining the FreeBSD port of ipfilter then unless someone steps
forward
  to carry on the work, I don't see much of a future for ipfilter in
  FreeBSD
 
  Do we honestly need three packet filters?
 

 No, for me only one should be present. I completely understand that
 some users still use IPFilter and IPFW but why providing three packet
 filters?

 The answer should be: use one and document only one. If at the
 beginning we started documenting only one all users should have used
 the only one present. Now we really need to remove the ancestral
 ipfilter and tell people switching to pf(4).

 Everything in life change, if we need to maintain all code from the
 past we will have a lot of compat code that pollute the full source
 tree and we will never improve the code just because of old bits

These so called old bits are both maintained, and have different
strengths.

Removing dead unmaintained code yes, but having choice makes transition
easier from other OSes; the fewer parts to change at a time, the better.

Chris
___
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: ipfilter(4) needs maintainer

[Chris Rees]

On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote:
 2013/04/13 16:01、Scott Long scott4l...@yahoo.com のメッセージ:

 Maybe something else, but whatever it is, it should be done.  If you and 
 Gleb don't want to do this, I will.

 I already started writing a guide. See here for a very incomplete version:

 http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html

If you're really serious about deprecating ipf, we absolutely have to
remove instructions for it from the Handbook as soon as possible;
every time a new user comes across instructions you're going to have
yet another annoyed party.

http://www.bayofrum.net/~crees/patches/remove-ipf.diff

Chris
___
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: ipfilter(4) needs maintainer

[Chris Rees]

On 14 April 2013 16:48, Warren Block wbl...@wonkity.com wrote:
 On Sun, 14 Apr 2013, Chris Rees wrote:

 On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote:

 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??:


 Maybe something else, but whatever it is, it should be done.  If you and
 Gleb don't want to do this, I will.


 I already started writing a guide. See here for a very incomplete
 version:

 http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html


 If you're really serious about deprecating ipf, we absolutely have to
 remove instructions for it from the Handbook as soon as possible;
 every time a new user comes across instructions you're going to have
 yet another annoyed party.

 http://www.bayofrum.net/~crees/patches/remove-ipf.diff


 This should probably be done like we did for CVS for ports.  Mark it as
 deprecated, then remove the Handbook section once the code is removed.

 Is it possible to move ipfilter into a port?

There isn't really a point in moving it to a port, because it still
needs the same level of commitment to make it work; many kernel/net
changes cause it to break, and Rui has already pointed out that no-one
knows if it even works at all on HEAD.

Moving kernel stuff like this to ports isn't really an option :/

Chris
___
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: Kernel is broken (at least for i386) from r246916

[Chris Rees]

On 19 Feb 2013 16:45, Lev Serebryakov l...@freebsd.org wrote:

 Hello, freebsd-current.


 cc -c -O2 -pipe -fno-strict-aliasing -march=geode -std=c99  -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option   -nostdinc  -I. -I/data/src/sys
-I/data/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS
-include opt_global.h -fno-common -finline-limit=8000 --param
inline-unit-growth=100 --param large-function-growth=1000
 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse
-msoft-float -ffreestanding -fstack-protector -Werror
 /data/src/sys/x86/isa/clock.c
 cc1: warnings being treated as errors
 /data/src/sys/x86/isa/clock.c: In function 'set_i8254_freq':
 /data/src/sys/x86/isa/clock.c:409: warning: 'new_mode' may be used
uninitialized in this function
 *** [clock.o] Error code 1

I believe this is fixed in r247000.

Chris
___
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: Is there an easy way to find out which port loads which library?

[Chris Rees]

On 18 Feb 2013 18:42, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:



 --- On Mon, 2/18/13, Chris Rees utis...@gmail.com wrote:


 From: Chris Rees utis...@gmail.com

 Subject: Re: Is there an easy way to find out which port loads which library?
 To: Jeffrey Bouquet jeffreybouq...@yahoo.com
 Cc: FreeBSD Mailing List freebsd-po...@freebsd.org
 Date: Monday, February 18, 2013, 1:01 AM

 On 18 Feb 2013 05:35, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:
 
 
 
 
  Subject: Re: Is there an easy way to find out which port loads which
 library?
 
  Bernard Higonnet wrote:
 
   Is there a simple, direct, complete, and unequivocal way to find out
   which port(s) install which libraries?
 
  Something like this perhaps?
  # grep libfoobar.so /usr/ports/*/*/pkg-plist
 
  AvW
 
  None of these replies mention
  pkg which /usr/local/lib/libfoobar.so
  pkg_which /usr/local/lib/libfoobar.so
  ...
  I typically use one or both (still using /var/db/pkg after running pkg2ng
 once a
  long time ago...)

 Why???

 Chris

 Unsure of the question.

 Why did I run pkg2ng?  I was uncognizant of all the immediate consequences.
 Why did I revert?  Not ready to make /var/db/pkg disappear until I've seen
 guides explaining the new usages which fit the present workflow here...

 Why do not I implement it at this time?  I've still too much to do in the 
 short term
 on a daily basis vs. implement anything new until I am one of the *last* to 
 do so, so I would do it in the quickest and most expedient manner.


 pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19  pkg_add 
 rubygem-mime-types-1.21.tbz.
 I don't have to know the 1.19 (the shell does).  I do not recall anyone 
 mentioning how the
 equivalent would work in a pkg system.  They may have, but if it was a 
 reply, I
 archived it somewhere, as I would prefer to switch all the machines I use 
 weekly
 all at once, and prefer to wait as long as expedient.

You can use pkg delete -x rubygem-mime-types, or pkg update  pkg
upgrade is really what you need there.

 That works on legacy laptops as well as modern 4-core CPU, aided by the 
 shell doing expansion, and I can type it without thinking, aided by the 
 shell.
 The subdirectory is directly available to grep, awk, less... without an .so.
 I've not yet had time to implement a /var/db/pkg/ on  a machine running pkg
 (by script maybe) so that it could continue.

Man pkg-query, but see below.

 I've posted several times why the progress of /pkg/ has not been shown to 
 [1] not slow down the workflow to which I am accustomed to upgrade multiple 
 machines has not been reliably demonstrated... and edge cases in which the 
 legacy method is
 preferable.  Unfortunately, I ran out of time a long time ago to respond 
 more in
 depth; my views on the matter are scattered in the lists archives and forum 
 archives
 [further content redacted so as to not waste anyone's time.]

Shell autocomplete should be pretty easy to implement should you
choose, but given that many of the steps you describe are automated
anyway, it's hard to see any real advantage to manually manipulating
the data!

Rather than describing your current methods, you may be better off (in
a new thread) describing the *outcomes* that you would like, and we
can help you achieve them.

Chris
___
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: Zpool surgery

[Chris Rees]

On 27 Jan 2013 14:31, Steven Hartland kill...@multiplay.co.uk wrote:

 - Original Message - From: Ulrich Spörlein u...@freebsd.org


 I have a slight problem with transplanting a zpool, maybe this is not
 possible the way I like to do it, maybe I need to fuzz some
 identifiers...

 I want to transplant my old zpool tank from a 1TB drive to a new 2TB
 drive, but *not* use dd(1) or any other cloning mechanism, as the pool
 was very full very often and is surely severely fragmented.


 Cant you just drop the disk in the original machine, set it as a mirror
 then once the mirror process has completed break the mirror and remove
 the 1TB disk.

 If this is a boot disk don't forget to set the boot block as well.

I managed to replace a drive this way without even rebooting.  I believe
it's the same as a zpool replace.

Chris
___
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: LLVM 3.2: official stable port is still LLVM 3.1. Basesystem missing important LLVM pieces!

[Chris Rees]

On 6 Jan 2013 14:57, Dimitry Andric d...@freebsd.org wrote:

 On 2013-01-06 15:16, Erik Cederstrand wrote:
 ...

 I think the real problem is that LLVM and the related tools are build in
one go, so you can't easily build llvm-config and others for the base
version of LLVM.


 Well, it would be easy enough to build llvm-config, but what should its
 output be?  We do not install llvm/clang headers or libraries into the
 system, so llvm-config would not give any meaningful -I or -L flags. :)



 llvm-config needs shared libraries that are not installed in base
because they supposedly require a prohibitive amount of build time.


 Again, build time is not the problem.  The libraries are already built,
 but in static form; making them dynamic would not be that difficult, but
 installing them would add another maintenance and compatibility burden.



 The LLVM port could be split up instead. There could be a
devel/llvm-libs port that installed the shared libs for the base LLVM, and
then a devel/llvm-config, devel/scan-build or devel/mclinker port that
depends on the former port.


 Yes, this seems to be the proper approach.  But, as far as I understand,
 the ports system cannot yet do one work tree build, and package that up
 in different packages, such as -libs, -devel, and so on.

No, but it can be done if the parts are compiled separately, à la
postgresql-* ports.

Is this definitely impossible?  It's crudely but effectively done with
pgsql by only running make in certain directories...

Chris
___
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: Auditdistd user question

[Chris Rees]

On 2 January 2013 14:04, Alexander Yerenkow yeren...@gmail.com wrote:
 Hello there and please excuse my harshness.

 I just installed 9.1, and I tried to set up poudriere with 9/stable.
 It took a lot of time compiling kernel and world, and after this it all
 failed with message about missing auditdistd user.
 I just can't find words.
 Why this user presence not checked during buildworld at least? Or by just
 invoking updated Makefile? If there any need to build world without install
 it, wouldn't be better make some conditional flag,
 like BUILD_WITHOUT_AUDITDISTD, instead of silent building and failing after
 that at install stage.
 Of course, in current way just buildworld not broken, but buildworld
 installworld is.
 This looks like like carefully hidden trap, from someone with specific
 sense of humor.
 Or am I missing something, and this is not terribly wrong?

While I agree with you in principle, I must point out that you mustn't
try to run package builds on a newer jail than your host.  This causes
weird kernel/world synchronisation issues.

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/169659 [for an example]

As far as I know there are no problems with running older jails on
newer hosts (thankfully).

Chris
___
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/shells/bash upgrade to patch level 39

[Chris Rees]

On 21 Dec 2012 20:50, Garrett Cooper yaneg...@gmail.com wrote:

 On Dec 21, 2012, at 9:09 AM, Michael Zoon wrote:

  Hi,
  I did update the make and distinfo file for a upgrade of bash 4.2.37 to
  4.2.39
  It is attached in this message.

 Could you please submit a PR for this and CC the maintainer?

Ccing maintainers on PRs is a waste of everyone's time, and I really wish
people wouldn't do it.  The gnats-aa does a far better job of handling them.

Also, please don't send ports issues to -current.

Chris
___
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: HEADS UP: FreeBSD git mirrors demoted to beta status, need your help

[Chris Rees]

On 15 December 2012 13:22, Ulrich Spörlein u...@freebsd.org wrote:
 Bad news everyone,

 tl;dr The git mirror of the source repository needs to be re-rolled to
 make the conversion deterministically repeatable, this will change
 pretty much all git commit hashes.

 The re-roll will be done January 15, 2013.

 Not affected are the ports and doc repositories, nor is the svn_head
 (for use with git-svn) affected.


 Background

 The converter (svn2git) was handing commits and objects to git's
 fast-import in arbitrary order, this makes merge commits have an
 arbitrary order of their parent commits and thus these merge commits
 have changing commit hashes for each converter run.

 This has been fixed, but requires us to move all the branches over to
 this deterministic scheme, which will change all their commit hashes.
 None of the contents of these commits change, so rebasing/remerging your
 work into these branches is possible without running into any merge
 conflicts.


 We need your help

 A goal of these conversions is to have them repeatable by you (yes,
 you!), so the correctness of the conversion can be verified. There are
 also no backups of the conversion runs, as they should be repeatable
 anyway.

 We need 2-3 volunteers to run these conversions themselves and verify
 that the produced commit hashes match the published ones. The necessary
 steps to do this are documented on the Wiki under

http://wiki.freebsd.org/GitWorkflow#History

 Please send me your output of git show-ref in a private mail, thanks.

Hey,

http://www.bayofrum.net/~crees/scratch/git-show-ref.txt

I hope it's what you were hoping for :)

My local svn mirror is synchronised at midnight GMT (UTC).

Need anything else?

Chris
___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

[Chris Rees]

On 2 Dec 2012 15:34, Ryan Stone ryst...@gmail.com wrote:

 On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson rwat...@freebsd.org wrote:

 
  Just to follow up on this thread, since the question has come up a
number
  of times.  mergemaser -p should be run prior to installworld always,
but
  most of the time will do very little.  One of its responsibilities is to
  add any necessary accounts and groups depended on by base system
components
  -- e.g., that will be referenced during installworld as part of setting
  file ownership and groups.
 
 
 I often use make installworld installkernel distribution DESTDIR=... to
 create bootable images (e.g. for a USB stick).  What's the recommendation
 for that case?  Manually create the auditdistd user on the build host?

You could run mergemaster -p; it doesn't do anything that would hurt your
running system; just adds important users etc.

Chris
___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

[Chris Rees]

On 1 Dec 2012 21:51, Andreas Tobler andreast-l...@fgznet.ch wrote:

 On 01.12.12 16:15, Robert Watson wrote:
 
  Dear all:
 
  I've now committed the build glue required to install the recently
merged
  Audit Distribution Daemon (auditdistd) contributed by the Pawel
Dawidek, and
  sponsored by the FreeBSD Foundation.  This allows individual hosts
generating
  audit trails to submit trails to a central audit server for review and
safe
  keeping.  Part of the goal is to ensure that a host submitting trail
data
  can't later modify the trails.  Pawel uses a variety of useful
security- and
  resilience-related features such as TLS, Capsicum, etc, in auditdistd.
 As the
  recent security incident in the FreeBSD.org cluster illustrated, having
  reliable and detailed audit trails makes a big difference in forensic
work,
  and hopefully this will allow the FreeBSD Project (and our users) to do
that
  better in the future.

 Aehm, hope it is ok to 'complain' here.

 Happens when installing world.

 cd /export/devel/fbsd/head/src;
 /usr/obj/export/devel/fbsd/head/src/make.amd64/make -f Makefile.inc1
 LOCAL_MTREE= hierarchy
 cd /export/devel/fbsd/head/src/etc;
 /usr/obj/export/devel/fbsd/head/src/make.amd64/make distrib-dirs
 mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.root.dist -p /
 mtree -eU  -f /export/devel/fbsd/head/src/etc/mtree/BSD.var.dist -p /var
 mtree: line 22: unknown user auditdistd
 *** [distrib-dirs] Error code 1

Does mergemaster -p help?

Chris
___
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: [HEADSUP] current switched by default to pkgng

[Chris Rees]

On 19 October 2012 16:16, Alex Keda ad...@lissyara.su wrote:
 On 19.10.2012 19:10, Vincent Hoffman wrote:
 On 19/10/2012 15:39, Alex Keda wrote:
 On 10.10.2012 17:44, Baptiste Daroussin wrote:
 Hi all,

 If you are using the ports tree on a FreeBSD current setup, then you are
 concerned by the announce.

 As nvidia-drivers has been fixed and is now properly working with pkgng, 
 the
 ports tree as been switch by default to use pkgng on FreeBSD Current based 
 on
 version = 117 which was the version when we tested the switch code.

 Make sure to read UPDATING (from ports) to correctly migrate your system 
 or find
 instruction to make your system still running with legacy pkg_install 
 tools.

 regards,
 Bapt

 pkg command does not have key for list options - no autocompletions

 for example, for service command, I use
 complete service'n/*/`service -l`/'
 in .cshrc

 what I can use for pkg command?

 horrible but working example
 pkg help 21 | sed -e '1,/Commands supported:/d ; /For more information
 on the different commands/,$d; s/^   *// ; s/  .*.*$// ;/^$/d'

 There's bound to be better ways, I was just bored enough to knock this up.
 note s/^*//   is a tab, while s/  .*.*$// is 2 spaces
 dont think our sed has any other way to express tab other than an actual
 tab (ctrl-v then tab on the command line)

 it's crazy =)
 may be add -l options?

For Bourne-style shell:
`pkg help 21 | sed -nE 's,^  +(.*),\1,p'`

For csh-style shell:
`pkg help |  sed -nE 's,^ +(.*),\1,p'`

where the bit between ^ and + is a tab character.  You can type the
tab character on a command prompt by using Ctrl+V then tab, or just
type it normally in the script.

Hope that helps in the meantime.

Chris
___
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: Clang as default compiler November 4th

[Chris Rees]

On 11 Sep 2012 13:22, Konstantin Belousov kostik...@gmail.com wrote:

 On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
tl;dr: Clang will become the default compiler for x86 architectures
on 2012-11-04
  
   There was a chorus of voices talking about ports already. My POV
   is that suggesting to 'fix remaining ports to work with clang' is
   just a nonsense. You are proposing to fork the development of all the
   programs which do not compile with clang. Often, upstream developers
   do not care about clang at all since it not being default compiler in
   Debian/Fedora/Whatever Linux. The project simply do not have resources
   to maintain the fork of 20K programs.
 
  We currently dont compile 4680 ports (out of 23857). Top 10 ports that
prevent
  the most other ports from compiling together prevent  ports from
  compilation. So if we fixed those 10 ports we could be at around 2500
ports
  not compiling. Thats quite far from your claim of forking 20k programs.
 Sorry, I cannot buy the argument. How many patches there are already
 in the ports tree to cope with clang incompatibility with gcc ? You may
 declare that all of them are application bugs, but it completely misses
 the point.

 
   Looking from less amiable angle, you propose to knowingly break
significant
   and important piece of the project work. My belief is that switch
cannot
   be done before ports switch to the port-provided compiler.
 
  I believe majority of the broken ports is broken because their
maintainer
  never saw them being broken with clang just because it's not the default
  compiler. Thus by making it the default majority of the problems would
just
  go away.
 Can you, please, read what I wrote ? Fixing _ports_ to compile with
 clang is plain wrong. Upstream developers use gcc almost always for
 development and testing. Establishing another constant cost on the
 porting work puts burden on the ports submitters, maintainers and even
 ports users.

 I do strongly oppose the attempt to drain the freebsd resources by
 forcing porters to port third-party code to other compiler.

I definitely see your point, but upstream should also be writing
correct/portable code.  Whenever a patch to fix a port is made, it is
actually mandatory to report it to upstream, and nag them to hell until
it's committed!  Most are very happy for this to happen; we've been
removing GNUisms from build scripts etc for years now (and I could link to
a Thank you email for all the build fixes I've sent upstream).

Sometimes, like the common bashism if [ a == b ] we bite the bullet and add
the extensions ourselves; sometimes upstream has an education on writing
portable code!

If we were all the same, would there be much point in being different?

Chris
___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Chris Rees]

On 31 Aug 2012 13:15, John Baldwin j...@freebsd.org wrote:

 On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
  On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
   On 08/30/2012 07:32 AM, John Baldwin wrote:
On Thursday, August 30, 2012 1:10:24 pm Chris Rees wrote:
On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote:
   
  
   I agree with John on all counts here. Further, the idea of a
   self-installing package, at least for the pkg stuff itself, addresses
   the issue that someone else brought up about how to handle installation
   of pkg by the installer for a new system.
 
  I like the idea of also providing a self-installing package, and it seems 
  really
  easy to do, so I'll try to see what I can do in this area I'll wrote a PoC 
  in 5
  minutes which looks pretty good, this could also be a very simple and easy 
  way
  to integrate into bsdinstaller.
 
  I'll do work in that direction.
 
  Still it doesn't solve the problem of boostrapping pkgng in a fresh new box,
  because the user may not know where to download the pkg-setup.sh.

 I do think that is something bsdinstall should be able to handle, and I would
 certainly want bsdinstall to include a dialog that says do you want to 
 install
 the package manager?

Putting aside my previous emotional red herring, this is a great idea;
I don't see how it's different from a base binary, but OK.

I don't see the need to be prompted-- it's not like the base system
doesn't have other larger amounts of software that is useless to many.
 Can't it just go in?

Chris
___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Chris Rees]

On 31 August 2012 16:47, Tijl Coosemans t...@coosemans.org wrote:
 On 31-08-2012 14:22, Baptiste Daroussin wrote:
 On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote:
 On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
 On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
 I agree with John on all counts here. Further, the idea of a
 self-installing package, at least for the pkg stuff itself, addresses
 the issue that someone else brought up about how to handle installation
 of pkg by the installer for a new system.

 I like the idea of also providing a self-installing package, and it seems 
 really
 easy to do, so I'll try to see what I can do in this area I'll wrote a PoC 
 in 5
 minutes which looks pretty good, this could also be a very simple and easy 
 way
 to integrate into bsdinstaller.

 I'll do work in that direction.

 Still it doesn't solve the problem of boostrapping pkgng in a fresh new 
 box,
 because the user may not know where to download the pkg-setup.sh.

 I do think that is something bsdinstall should be able to handle, and I 
 would
 certainly want bsdinstall to include a dialog that says do you want to 
 install
 the package manager?

 Of course this is being worked on by dteske@ on his bsdconfig scripts, so 
 yes in
 anycase the bsdinstaller will end up with a boostrap dialog to install pkgng.

 ...using a mechanism that will be supported for the lifetime of the release.

 My concern is that the problem with the pkg tools was never that they were
 tied to FreeBSD releases. If that were true then you cannot accept the
 bootstrap solution above because it has exactly the same problems.

 The problem in my opinion was simply that the source code lived in src where
 ports developers didn't have good access to it. And the solution for that is
 to turn pkg development into a third party project and import that into base
 from time to time. There can also be a port for it so people can use more
 recent versions if they want to. That's the situation for several third
 party tools in base.

 Given that the ports tree is currently supporting both the old and new pkg
 tools I don't think it would be a problem for them to support older versions
 of pkgng when the time comes, especially since the database used by pkgng is
 much more flexible and you can execute any sql query on it.

Absolutely not.  This is close to the top reason pkg has been moved to
ports-- it should not be in base, because then we're stuck with
supporting that version for a very long time.

Chris
___
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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

[Chris Rees]

On 30 Aug 2012 18:03, John Baldwin j...@freebsd.org wrote:

 On Thursday, August 30, 2012 10:39:17 am Tijl Coosemans wrote:
  On 27-08-2012 18:24, John Baldwin wrote:
   On Sunday, August 26, 2012 4:37:53 pm Doug Barton wrote:
   The problem is that we don't really support the idea of things in the
   base magically deleting themselves.
  
   As I have said in previous messages, the bootstrapping problem is
being
   overblown by several orders of magnitude. For newly installed systems
   where pkg is the default, /usr/local/bin/pkg will be installed. So
there
   is no bootstrapping problem.
  
   For already-installed systems who wish to switch to pkg, they can
   install from /usr/ports, or use the pkg bootstrap tool in the base.
   Given that they will be intentionally making this change, and there
will
   be instructions written up on how to do this which include the
   bootstrapping step, once again this is a non-issue.
  
   The whole idea of having every call to /usr/local/sbin/pkg pass
through
   /usr/sbin/pkg in order to help a tiny minority of users with a
one-time
   bootstrapping issue is just plain ludicrous.
  
   I agree.  Even if we keep /usr/sbin/pkg, we will presumably want to
remove
   it from the base in a year or so via 'make delete-old', etc.  Given
that,
   I'm not sure we need it there in the first place.
 
  What if you pkg_delete \* or rm -rf /usr/local? Do you have to reboot
  pkg then?

 Yes, if we've decided it (pkgng) should not be part of the base.  This
 doesn't strike me as that weird.  It seems similar to how one has to
 bootstrap, say, MacPorts.

Difference is, MacPorts isn't the official Mac distribution centre.

Leaving out pkg-bootstrap (or whatever) is marginalising ports as a
non-integral part of the OS.

How useful is base on its own, really?

Chris
___
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: pkgng default release schedule (contd...)

[Chris Rees]

On 24 Aug 2012 11:08, Jeffrey Bouquet jeffreybouq...@yahoo.com wrote:

 A few more reasons (unless I have not seen some relevant documentation to
the contrary) to not mandate pkgng as the default...

Why don't you phrase this as How can one ... so you sound less negative?

 Nowadays, one can save time by installing two ports which officially or
unofficially conflict, and have /var/db/pkg entries for both, and even
 local workarounds (for instance, moving the duplicate binary elsewhere
before the second install) (Perchance removing the line in the Makefile).

Currently you can still do this, at least until STAGEDIR.

 A failed make install (register), one can check the /var/db/pkg/
directory(ies) to double check visually to what extent it did NOT fail.
 Similarly for a failed make deinstall (unregister)...

The error messages are perfectly clear.

 pkgdb -F to fixup stale dependencies and resolve dependency information.

Unnecessary with pkgng.

 A proven method in the portmaster manpage to reinstall all ports.

You want to talk to the portmaster author about that.

Chris
___
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: pkgng default schedule... registering a few reasons for rethinking the final implementation...

[Chris Rees]

On 23 Aug 2012 17:50, Kris Moore k...@pcbsd.org wrote:

 On 08/23/2012 12:26, Jeffrey Bouquet wrote:
  I am following with dread the planned implementation of the deprecation
of /var/db/pkg as a package registry... I use each /var/db/pkg directory as
a database into the port installation/status, using
sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff.
 For instance, an upgrade py26  py27.
  cd /var/db/pkg
  ls -lac | grep py26
  ls -lac | grep python
  as the more simple example.
  
  With due respect to its developers and the persons who agree that
  the package tools could be upgraded, the mandatory
  usage of a front-end database to a file directory one
  is here viewd as mutt-only-mbox, registry-and-bsod rather
  than /etc/local/rc files, deprecation of
sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade
the ports that are registered;
  ...
  I see concurrently too few tests on lower-end p2, p3 as to whether
  pkg can run with lesser memory machines (routers...) (pfsense)
  ...
  I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd,
  pfsense..) due to less-reliability, more-possibility of bugs..
 

 This is of some concern to me as well. A number of our utilities /
 scripts rely on checking /var/db/pkg as a means to test if a particular
 package is installed. This is often much faster than running the pkg_*
 commands, especially when we may be checking thousands of packages in a
 single run. It will be some work to adjust our utilities to using the
 various pkg commands now, but it can be done. What worries me is
 performance. If this is significantly slower, it may cause some issues
 on our end.

The migration should be no surprise to anyone, since it's been discussed on
this very list for a while now.

If you have concerns about performance, have you tested them for speed?  My
instinct is that an sqlite query will be much faster than hundreds of file
accesses.

Chris
___
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: pkgng default schedule... registering a few reasons for rethinking the final implementation...

[Chris Rees]

On 23 August 2012 20:50, Kris Moore k...@pcbsd.org wrote:
 On 08/23/2012 13:10, Jeremy Messenger wrote:
 On Thu, Aug 23, 2012 at 11:49 AM, Kris Moore k...@pcbsd.org wrote:
 On 08/23/2012 12:26, Jeffrey Bouquet wrote:
 I am following with dread the planned implementation of the deprecation of 
 /var/db/pkg as a package registry... I use each /var/db/pkg directory as a 
 database into the port installation/status, using 
 sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix 
 stuff.  For instance, an upgrade py26  py27.
 cd /var/db/pkg
 ls -lac | grep py26
 ls -lac | grep python
 as the more simple example.
 
 With due respect to its developers and the persons who agree that
 the package tools could be upgraded, the mandatory
 usage of a front-end database to a file directory one
 is here viewd as mutt-only-mbox, registry-and-bsod rather
 than /etc/local/rc files, deprecation of 
 sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade 
 the ports that are registered;
 ...
 I see concurrently too few tests on lower-end p2, p3 as to whether
 pkg can run with lesser memory machines (routers...) (pfsense)
 ...
 I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd,
 pfsense..) due to less-reliability, more-possibility of bugs..

 This is of some concern to me as well. A number of our utilities /
 scripts rely on checking /var/db/pkg as a means to test if a particular
 package is installed. This is often much faster than running the pkg_*
 commands, especially when we may be checking thousands of packages in a
 single run. It will be some work to adjust our utilities to using the
 various pkg commands now, but it can be done. What worries me is
 performance. If this is significantly slower, it may cause some issues
 on our end.
 Guys, please test it before you say anything. Otherwise it's going to
 be moved forward without you.



 Well, it was about time I got to doing a benchmark of this anyway :)

 I did quick benchmark of how one of our utilities parses through a list
 of 1k packages on a newer i5 system:

 First test, using /var/db/pkg/pkg check we have been doing:

 0.178s 0:00.31 54.8%
 0.123s 0:00.26 61.5%
 0.099s 0:00.15 60.0%

 Second test, using pkg info pkg:

 5.347s 0:11.41 91.7%
 5.444s 0:11.52 91.3%
 5.878s 0:11.32 91.4%

 The pkg info command is quite a bit slower in this case, but 5 seconds
 isn't horrible.

 Now I ran the same benchmark on a slower 1.66gz Atom system, checking
 about 1200~ packages:

 First test, using /var/db/pkg/pkg check we have been doing:

 0.604s 0:00.76 86.8%
 0.622s 0:00.77 84.4%
 0.614s 0:00.73 90.4%

 Second test, using pkg info pkg:

 28.507s 0:54.80 99.1%
 28.282s 0:54.60 99.4%
 28.302s 0:54.52 99.4%

 Now this is what concerns me a bit. It took closer to 30 seconds, which
 is quite a while to wait, especially if a utility like ours has to run
 these checks when it starts up, to show the user whats installed / not
 installed on the system.

 The only way around It I've found is to do a quick pkg info on the
 entire DB, dump that to a list, then begin to grep through that list for
 each item, but it still takes 10~ seconds on the atom. That may be what
 I end up having to do, but it still stinks to go from a half a second
 startup, to 10 seconds each time. Any other ideas on how to do this
 faster with the new pkgng?

Perhaps refactor your method a little;

# Get sample list of packages

[crees@pegasus]~% pkg info -qa  pkglist
[crees@pegasus]~% wc -l pkglist
 712 pkglist

# Call pkg info once for each package

[crees@pegasus]~% time pkglist xargs -n 1 pkg info  /dev/null
xargs -n 1 pkg info  pkglist  /dev/null  2.18s user 2.32s system 98%
cpu 4.544 total

# Call pkg info once for all packages

[crees@pegasus]~% time pkg info $(cat pkglist)  /dev/null
pkg info $(cat pkglist)  /dev/null  0.37s user 0.02s system 98% cpu 0.400 total

Summary; pkgng is awesomely fast... but don't call it lots of times
since it has a higher startup time.

I presume your code is something like;

list_of_packages_to_test=$@;

for pkg in ${list_of_packages_to_test}
do  [ -d /var/db/pkg/${pkg} ]  echo Success! Package installed!
done

?  I don't know exactly what you're testing and how, so I can't offer
too much specific advice.

Chris
___
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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.

[Chris Rees]

On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
 On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann 
 ohart...@zedat.fu-berlin.de wrote:

 Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
 recompiling the VBox kernel module:

 ===   Cleaning for virtualbox-ose-kmod-4.1.18_1
 ===   virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile
 on FreeBSD  8.2.
 *** [all] Error code 1

 Stop in /usr/ports/emulators/virtualbox-ose-kmod.

 The port compiled prior to the updates of today.

 oh

 What is the question? We have deprecated  8.2 almost five months ago 
 because of the memobj r0 rewrite. You're the first who complains about this 
 so I'm pretty sure it was the correct decision to move forward. Please also 
 keep in mind that 8.1 is already EOL.


 I do not understand your complains about my mail to the list. For your
 information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
 know, considered not to be deprecated by now. If I'm wrong in that, sorry.

Can you give us the output of make -C
/usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?

I think your version of sys/param.h could be out of date.

Chris
___
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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.

[Chris Rees]

On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:
 On 08/22/12 15:05, Chris Rees wrote:
 On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
 On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann 
 ohart...@zedat.fu-berlin.de wrote:

 Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
 recompiling the VBox kernel module:

 ===   Cleaning for virtualbox-ose-kmod-4.1.18_1
 ===   virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile
 on FreeBSD  8.2.
 *** [all] Error code 1

 Stop in /usr/ports/emulators/virtualbox-ose-kmod.

 The port compiled prior to the updates of today.

 oh

 What is the question? We have deprecated  8.2 almost five months ago 
 because of the memobj r0 rewrite. You're the first who complains about 
 this so I'm pretty sure it was the correct decision to move forward. 
 Please also keep in mind that 8.1 is already EOL.


 I do not understand your complains about my mail to the list. For your
 information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
 know, considered not to be deprecated by now. If I'm wrong in that, sorry.

 Can you give us the output of make -C
 /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?

 117


 I think your version of sys/param.h could be out of date.

 Chris



 As soon as I'm sitting in front of the machine again. But I doubt that
 the sys/param.h is out of date, since that box has been recompiling
 FreeBSD 10.0-CURRENT now for almost every day.

Hm, does that mean that the output you gave me earlier was not from
the same machine?

 When the problem occured, the change to CLANG 3.2-Beta has just been
 introduced, installed with make buildworld installkernel. This
 procedere also triggers (via /etc/src.conf)

 PORTS_MODULES=  x11/nvidia-driver
 PORTS_MODULES+= emulators/virtualbox-ose-kmod

Please remove the quotes! [1]

 the build of the modules for the nvidia GPU and Vbox kernel module.

 Thanks for your response,

Something really weird is happening here.  All that is happening is
that the Makefile is testing against OSVERSION;

.if ${OSVERSION}  802000
BROKEN= Does not compile on FreeBSD  8.2
.endif

Since the result from make -VOSVERSION shows that your OSVERSION is
indeed above 802000, I am completely at a loss as to what's going on
:(

Chris

[1] http://www.bayofrum.net/~crees/scripts/dont-quote.mk
___
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: FreeBSD 10.0-CURRENT r239477 doesn't compile: virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not compile on FreeBSD 8.2.

[Chris Rees]

On 22 Aug 2012 19:38, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 Am 08/22/12 16:02, schrieb Chris Rees:
  On 22 August 2012 14:32, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:
  On 08/22/12 15:05, Chris Rees wrote:
  On 22 August 2012 08:18, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
  Am 08/21/12 22:53, schrieb Bernhard Fröhlich:
  On Di., 21. Aug. 2012 13:56:02 CEST, O. Hartmann 
ohart...@zedat.fu-berlin.de wrote:
 
  Today I ran into a problem with FreeBSD 10.0-CURRENT #0 r239477
  recompiling the VBox kernel module:
 
  ===   Cleaning for virtualbox-ose-kmod-4.1.18_1
  ===   virtualbox-ose-kmod-4.1.18_1 is marked as broken: Does not
compile
  on FreeBSD  8.2.
  *** [all] Error code 1
 
  Stop in /usr/ports/emulators/virtualbox-ose-kmod.
 
  The port compiled prior to the updates of today.
 
  oh
 
  What is the question? We have deprecated  8.2 almost five months
ago because of the memobj r0 rewrite. You're the first who complains about
this so I'm pretty sure it was the correct decision to move forward. Please
also keep in mind that 8.1 is already EOL.
 
 
  I do not understand your complains about my mail to the list. For
your
  information: I'm on FreeBSD 10.0-CURRENT and this seems, as far as I
  know, considered not to be deprecated by now. If I'm wrong in that,
sorry.
 
  Can you give us the output of make -C
  /usr/ports/emulators/virtualbox-ose-kmod -VOSVERSION please?
 
  117
 
 
  I think your version of sys/param.h could be out of date.
 
  Chris
 
 
 
  As soon as I'm sitting in front of the machine again. But I doubt that
  the sys/param.h is out of date, since that box has been recompiling
  FreeBSD 10.0-CURRENT now for almost every day.
 
  Hm, does that mean that the output you gave me earlier was not from
  the same machine?

 No, it is the same box. I tried another FBSD 10.0-CURRENT box today at
 my lab and had success ... but see below ...

 
  When the problem occured, the change to CLANG 3.2-Beta has just been
  introduced, installed with make buildworld installkernel. This
  procedere also triggers (via /etc/src.conf)
 
  PORTS_MODULES=  x11/nvidia-driver
  PORTS_MODULES+= emulators/virtualbox-ose-kmod
 
  Please remove the quotes! [1]

 Better that way?
 PORTS_MODULES=  emulators/virtualbox-ose-kmod x11/nvidia-driver

Much :)

 
  the build of the modules for the nvidia GPU and Vbox kernel module.
 
  Thanks for your response,
 
  Something really weird is happening here.  All that is happening is
  that the Makefile is testing against OSVERSION;

 I guess this is the result of my unpatience! Usually, I install a new
 kernel, reboot it into single user mode, install world and do the
 mergemaster stuff.

 This time, I still ran the old kernel (but even FreeBSD 10.0-CURRENT)
 and made a installworld. The musterius error occured, when the kernel
 mod for VBox was about to be compiled.

 I updated today my lab's box and since this machine also sucked in the
 new CLANG 3.2 stuff, I was really careful about what would happen. I
 compiled the system, installed the kernel, booted into single user mode
 and did the installworld with all mounted filesystems (and service
 ldconfig start issued) - and had no problems!

 I did the same today on the faulty box, also no problems after the new
 compiled system was properly installed.

 I guess I made a conceptional bad mistake and maybe something got
 inconsistent due to the new compiler/LLVM stuff? A naiv suggestion.

 I guess it is a waste of time to investigate this further - except there
 is a hidden issue ...

Hm, it does seem weird.  If it doesn't bother you any more it's probably
not worth chasing; it's enough work to support supported processes if you
get what I mean ;)

 
  .if ${OSVERSION}  802000
  BROKEN= Does not compile on FreeBSD  8.2
  .endif
 
  Since the result from make -VOSVERSION shows that your OSVERSION is
  indeed above 802000, I am completely at a loss as to what's going on
  :(
 
  Chris
 
  [1] http://www.bayofrum.net/~crees/scripts/dont-quote.mk

 Thanks for the patience,

No problem.

Chris
___
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: pkg and portmaster: Downgrading ports? Why? portmaster messes up ...

[Chris Rees]

On 7 Aug 2012 15:50, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote:

 On 08/07/12 15:39, Bryan Drewery wrote:
  On 8/7/2012 4:31 AM, O. Hartmann wrote:
  ports-mgmt/portmaster installs still the old fashioned style folders of
  ports in /var/db/pkg. I thought ith the new scheme of pkg, everything
is
  going into a file based SQLite3 DB?
 
  Also ensure WITH_PKGNG=yes is in your /etc/make.conf. My last comment
  still stands though, portmaster will store distifile information in
  /var/db/pkg.
 

 WITH_PKGNG=yes is set in /etc/make.conf.

Also in your portmasterrc?

Chris
___
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: portmaster and pkgng

[Chris Rees]

On 23 Jul 2012 09:44, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:

 Hello.

 I'd like to try pkgng with portmaster. I see that pkg2ng is involving
 the directory /var/db/pkg, so this implies that there may implications
 also for usage with ports-mgmt/portmaster. portmaster is supposed to be
 the tool completely dependend on system's toolsets, isn't it?

 I know that pkg is supposed to be more for binary maintainance of the
 system, but I'd like to be stuck with compiling my ports. Is there an
 issue with that?

 Thanks inadvance and sorry for the (naive) noise.

Of course you can stay with compiling your ports directly, but I think
you'll be so amazed with how easy it is to make binary package sets
yourself and use them that you'll use them instead :). You still have all
the advantages of compiling from source.

http://blog.etoilebsd.net/post/Home_made_pkgng_repo

Chris
___
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: [HEADSUP CFT] pkg 1.0rc1 and schedule

[Chris Rees]

On 13 July 2012 17:02, Bryan Drewery br...@shatow.net wrote:
 On 7/13/2012 10:36 AM, Doug Barton wrote:
 On 07/13/2012 05:26 AM, John Baldwin wrote:
 On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote:
 On 07/12/2012 02:11 PM, Craig Rodrigues wrote:
 You might want to view Baptiste's pkgng presentation at BSDCan:

 http://www.youtube.com/watch?v=4Hxq7AHZ27I

 Sure, the next time I have an hour to spare.

 I don't think what I'm asking for is unreasonable. One could even
 conclude that answering those 3 questions should have been a
 prerequisite for starting down this road in the first place.

 One could also assume that other people in the Project aren't morons and do
 actually put thought into the things they do for starters

 I certainly *want* to believe that. But considering the giant mess that
 portmgr + Baptiste made of the changes to the OPTIONS framework, that
 only touches a fraction of the ports, my willingness to have faith in
 them to do it right is near zero.

 There's a *major* difference in the testing effort and community
 involvement in these 2 projects. OPTIONSng had maybe a handful of
 testers over a shorter period of time.

 PKGNG has had 40+ contributors and has been in development since 2010.
 It's been presented and discussed at multiple conferences and dev
 summits. Many people have been building their own packages with PKGNG
 for months now, greatly raising the testing coverage on the ports tree.


 Not to mention that I've been asking for a project plan for pkg since
 long before it even hit the ports tree in beta. What I'm asking for
 should have been done already considering that this change will affect
 *every* port, and *every* user. So either it hasn't actually been done,
 or the PTB are refusing to provide it.

 http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html

 I find bapt's research in that post to be evident that a lot of thought
 and time did go into planning this.


 Also, please keep in mind that I was criticized for *not* speaking up
 about the OPTIONS changes, now I'm being criticized *for* speaking up
 prior to pkg going live. In spite of the fact that I'm doing my best to
 (repeatedly) be clear that I'm not against the project, I just want to
 know more about it.

 Also, when other
 people have taken time to explain an large decision because you are too lazy
 to invest the time doesn't really help your case).

 Um, I'm too lazy? I've read everything that's been written on pkg to
 date. Have you? 90% of it is how to type stuff that doesn't address
 what we need. The other 10% is so vague and general as to be useless as
 a project plan.

 Have you watched the BSDCan presentation video yet? It is very
 compelling and exciting.


 You're an experienced project manager John. If someone who worked for
 you came to you with a plan this vague (modern foo, decent bar), for
 a critical system, how would you respond? (And yes, I realize that no
 one around here works for me, that isn't my point at all.)

 In terms of the first feature (binary upgrades), the truth is that if you 
 have
 more than 5 machines to manage, our current pkg tools completely suck.  
 There
 is no automated upgrade mechanism.  If you want one you have to write your 
 own
 set of infrastructure to do the right collection of pkg_delete/pkg_adds.
 Certainly there is no support in the current package tools for doing batch
 upgrades (i.e. upgrading from one completely package set to another).  pkgng
 adds that feature, and I find it a must for supporting large installations 
 of
 machines that need automated management.

 And as I wrote previously, I've been there and done that, so yes, I'm
 interested in the feature. But I'd like to know more about the plans for
 it so that those of us who *do* have experience in this topic can share
 that, and we can avoid having to reinvent the wheel. Or worse, putting
 out something half-assed that uses up a lot of developer cycles and
 doesn't get the job done.

 So get involved! Come help. Contribute.


And PLEASE get that portmaster patch integrated.

Chris
___
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: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice:

[Chris Rees]

On Jul 3, 2012 10:00 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:

 On 07/02/12 08:09, Sayetsky Anton wrote:
  I will test libreoffice build on 8.3-RELEASE today or tomorrow.
  I have both gstreamer and boost installed now.
 


 We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64).

 devel/boost-lib gets reeled in now by editors/libreoffice by default, so
 it doesn't need to be installed explicitely.

 I saw a patch flushed in yesterday, submitted by bapt@. This patch also
 installs LLVM/CLANG from the ports - with ASSERTS deactivated.

 I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard
 backend compiler, I guess this version has the suspected ASSERTS
activated.

 Why another LLVM port? We already have LLVM/CLANG in the base system (9
 and 19). If the ASSERTS proble is the cause for breaks reported on the
 list and elsewhere on the net, why isn't the maintainer still stuck on
 the old version?

 I just managed it to install the prior version on broken systems and was
 really lucky having LibreOffice working again. But the other day I was
 bothered by the next non-working version and now I have lots of
 notebooks remaining with NO LibreOffice on FBSD 9-STABLE.

 This is not what I expect from quality securing! It is simply a mess and
 definitely another reason and point for the thread Why NOT using
FreeBSD.

For anyone struggling with the new version of libreoffice, I made a package
for 9/amd64.

http://www.bayofrum.net/tb/packages/9-local/All/libreoffice-3.5.4.tbz

Setting up a Tinderbox is easy, and will fix the problems you are having.

Please heed advice before shouting and blaming about problems.

Chris
___
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: sysctl filesystem ?

[Chris Rees]

On Jun 26, 2012 7:07 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl
wrote:

 as well as we don't depend of /proc for normal operation we shouldn't for
say /proc/sysctl

 improvements are welcome, better documentation is welcome, changes to
what is OK - isn't.

/proc/sysctl might be useful.  Just because Linux uses it doesn't make it a
bad idea.

Chris
___
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: Why Are You NOT Using FreeBSD ?

[Chris Rees]

On 10 June 2012 11:12, Martin Sugioarto mar...@sugioarto.com wrote:
 Am Sat, 09 Jun 2012 21:09:09 +0700
 schrieb Adam Strohl adams-free...@ateamsystems.com:

 I get the feeling people are updating their ports tree and then
 recompiling/reinstalling everything just because and then are
 complaining when one thing breaks (its the only thing I can think of).

 Hi.

 But it does not need to break. Sometimes it would be enough just to
 test if the port compiles before committing it (I'm talking about
 libreoffice here which is broken). Some people rely on some essential
 ports. I can understand that porters are not Gods and make errors, but
 they should be fixed within hours, when they have been found on
 important ports.

 I mean, ports collection is sure great and this is one of the aspects
 why I am using FreeBSD, but at the moment FreeBSD is losing strength
 here, in my opinion.

Er... people always test their commits.  Sometimes edge cases will
creep in, such as the libreoffice failure which was due to different
configurations, but to suggest that the commit wasn't tested is quite
frankly insulting-- it built on a clean system perfectly well.

Chris
___
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: Why Are You NOT Using FreeBSD ?

[Chris Rees]

On 10 June 2012 11:51, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On 06/10/12 12:37, Chris Rees wrote:
 On 10 June 2012 11:12, Martin Sugioarto mar...@sugioarto.com wrote:
 Am Sat, 09 Jun 2012 21:09:09 +0700
 schrieb Adam Strohl adams-free...@ateamsystems.com:

 I get the feeling people are updating their ports tree and then
 recompiling/reinstalling everything just because and then are
 complaining when one thing breaks (its the only thing I can think of).

 Hi.

 But it does not need to break. Sometimes it would be enough just to
 test if the port compiles before committing it (I'm talking about
 libreoffice here which is broken). Some people rely on some essential
 ports. I can understand that porters are not Gods and make errors, but
 they should be fixed within hours, when they have been found on
 important ports.

 I mean, ports collection is sure great and this is one of the aspects
 why I am using FreeBSD, but at the moment FreeBSD is losing strength
 here, in my opinion.

 Er... people always test their commits.  Sometimes edge cases will
 creep in, such as the libreoffice failure which was due to different
 configurations, but to suggest that the commit wasn't tested is quite
 frankly insulting-- it built on a clean system perfectly well.

 Chris

 In do not see any insulting statement! Why those exaggerations?

 Sometimes it would be enough just to
 test if the port compiles before committing it (I'm talking about
 libreoffice here which is broken)
___
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: WAS: Re: Why Are You NOT Using FreeBSD ? New: port annoyance LibreOffice

[Chris Rees]

On 10 June 2012 18:10, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On 06/10/12 17:43, John Merryweather Cooper wrote:
 On 06/10/12 09:54, Martin Sugioarto wrote:
 Am Sun, 10 Jun 2012 11:37:09 +0100
 schrieb Chris Reescr...@freebsd.org:

 Er... people always test their commits.  Sometimes edge cases will
 creep in, such as the libreoffice failure which was due to different
 configurations, but to suggest that the commit wasn't tested is quite
 frankly insulting-- it built on a clean system perfectly well.
 Hi,

 I don't mean to insult anyone. As I have already told, I am really
 thankful that people invest their precious time into updating the ports
 collection.

 Whatever clean system means. It is surely not the default case that
 someone has got a freshly installed set of ports.

 Among all the default problems with ports, libreoffice[1] adds to the
 group of annoyances[2] at the moment. I don't know when I have seen
 portmaster -ad run through successfully last time. I need more and
 more -x options to exclude ports which fail to build.

 [1] german/libreoffice and libreoffice fails all the time in
 (LOCALIZED_LANG is set to de):

 Module 'lingucomponent' delivered successfully. 12 files copied, 2
 files unchanged

 ---
          Oh dear - something failed during the build - sorry !
    For more help with debugging build errors, please see the section in:
              http://wiki.documentfoundation.org/Development

    internal build errors:

 ERROR: error 65280 occurred while
 making
 /usr/workdir-ports/usr/ports/editors/libreoffice/work/libreoffice-core-3.5.2.2/vcl/prj


   it seems that the error is inside 'vcl', please re-run build
   inside this module to isolate the error and/or test your fix:
 ---


 Whatever this tries to tell me. I don't get it. This is a completely
 useless error message for me.

 Not even in german/libreoffice. i try to build the standard version and
 I receive the same error.

 I can fix this by doing what the buildsystem suggests, but then I have a
 stop in sfx2 and others and it ends up in some module called tail_,
 where the build never ends when performing the repair as suggested. I
 had once a box running all the night looping building in this folder.


 [2] The default annoyances are for example:

 - After updating perl, php or whatever, it makes sense to enforce
    updating the modules that belong to these ports. I've seen 100x the
    same message that p5-XML-Parser does not work and know what it means,
    but this should be resolved by the port system. I mean, when you
    update perl, the perl modules won't work anymore. This is totally
    clear and it makes sense to update them first before going on.

 I can confirm that. I fixed that for me by portmaster p5- in case
 p5-SAX-XXX failed.

There's an UPDATING message written for that very purpose.


 - When specifying WITHOUT_X11 the ports should respect this and not try
    to pull in the X11 variants of ports. I regularly see some ports
    pulling ImageMagick instead of the already installed
    ImageMagick-nox11. I still do not fully understand what is going on
    with WITHOUT_GNOME, but I'll try to figure it out later. But I am
    quite sure that some ports pull in unneeded Gnome dependencies.

 - Ports are being marked as interactive and stop the update process. The
    idea behind portmaster was (earlier) to avoid interactive building of
    ports and ask all the needed questions, before the builds start. I
    mean, earlier, I could get out and enjoy some coffee outdoors, now I
    have to sit at the keyboard. This is unacceptable! ;)

 portmaster does even more damage. Sometimed a port reels in some newly
 updates, a port gets deleted. if on of the to be updated prerquisits
 fail, the port in question isn't there anymore.

 portmaster fails quite often in oberwriting remnant files. If a port
 gets corrupted by accident, like graphics/netpbm, One need to delete all
 binaries manually from /usr/local/bin, otherwise the installation fails.

 Somehow I wish to have a brute force knob to overwrite everything in a
 brutal way.

FORCE_PKG_REGISTER.


 - It would be nice to have a mechanism that tells you that your perl,
    mysql or whatever is not the default version anymore and you should
    consider updating to the default (and recommended) port.


 Martin

 From /etc/defaults/periodic.conf:

 # 400.status-pkg
 weekly_status_pkg_enable=YES                # Find out-of-date pkgs
 pkg_version=pkg_version                           # Use this program
 pkg_version_index=/usr/ports/INDEX-9      # Use this index file

 There's an override script in ports-mgmt/portupgrade that uses it's
 database, also.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send 

Re: PORTS_MODULES fix

[Chris Rees]

On 9 June 2012 18:15, Doug Barton do...@freebsd.org wrote:
 I have recently tried the PORTS_MODULES knob, and found a problem. The
 ports tree searches for some dependencies by finding a binary in PATH,
 and that fails since by default /usr/local/ isn't there. The attached
 patch fixes that problem.

 It would be more robust to use PREFIX there instead of /usr/local
 explicitly, but I'm not sure how to unravel the mk maze to get that
 value. If anyone has a suggestion for that, I'd be happy to include it.

As you mention, PREFIX is only defined in ports/Mk, and it'd
definitely be undesirable to be including any of those files :)

The most robust (but unpleasant) solution would be one of the following:

PREFIX?=/usr/local
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin

or the equivalent (and perhaps cleaner, not leaving PREFIX defined)

.if !defined(PREFIX)
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:/usr/local/bin:/usr/local/sbin
.else
PORTSMODULESENV=SYSDIR=${SYSDIR} PATH=${PATH}:${PREFIX}/bin:${PREFIX}/sbin
.endif

Both of these will respect make.conf's setting of PREFIX.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On Jun 6, 2012 3:38 AM, Erich erichfreebsdl...@ovitrap.com wrote:

 Hi,

 On 05 June 2012 7:13:47 Mark Linimon wrote:
  On Tue, Jun 05, 2012 at 03:23:01PM +0700, Erich wrote:
   But is this true for apache only or for the whole ports tree?
 
  Entire tree.

 my problem with this is that the documentation states something very
different:

 From the handbook at the location where beginners will look for it:

 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html

 'Which version(s) of them do you want?

 With CVSup, you can receive virtually any version of the sources that
ever existed. That is possible because the cvsupd server works directly
from the CVS repository, which contains all of the versions. You specify
which one of them you want using the tag= and date= value fields.

 Warning: Be very careful to specify any tag= fields correctly. Some tags
are valid only for certain collections of files. If you specify an
incorrect or misspelled tag, CVSup will delete files which you probably do
not want deleted. In particular, use only tag=. for the ports-*
collections.'

 I think that this states very clearly that there are no tags.


No it doesn't. It states clearly that you shouldn't use tags unless you
know what you are doing, as several of us have explained more than once.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On 6 June 2012 14:48, Erich Dollansky er...@alogreentechnologies.com wrote:
 Hi,

 On 06 June 2012 9:21:22 Sean Cavanaugh wrote:

 Overall I see it as packages are flat stable at the cost of being out of
 date, and ports are current but not guaranteed to compile without
 intervention. The Maintainers do give a very good shot to make them stable
 but sometimes one person cannot maintain millions of lines of code and not
 make a glitch occasionally, or make it out on time when a dependency
 changes.

 isn't the date of the packages the date of the last release of the branch? 
 Aren't the chances high then to get a working ports tree?

 You can follow the discussion about this subject for at least 10 years back. 
 The result is always the same.

 In parallel is the discussion why so little people are using FreeBSD.

 Do you understand what I want to say?

I do understand it, but you don't seem to understand that we *do*
understand what you're saying.

- Tagged ports trees contain out of date software.

- Security fixes cannot be backported to tagged trees- we *do* *not*
*have* *resources* for this.

- Occasionally you may see minor issues when following the latest
branch of ports.  This is the price you pay for being up to date, with
the very latest of software.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On 6 June 2012 14:12, Erich erichfreebsdl...@ovitrap.com wrote:
 Hi,

 On 06 June 2012 8:48:10 Chris Rees wrote:
 On Jun 6, 2012 3:38 AM, Erich erichfreebsdl...@ovitrap.com wrote:
 

 No it doesn't. It states clearly that you shouldn't use tags unless you
 know what you are doing, as several of us have explained more than once.

 is my English really this bad?

 From the handbook:

 '. In particular, use only tag=. for the ports-* collections.'

Your English is fine, but being told to use tag=. != tag=. is the
only tag that exists.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On Jun 5, 2012 3:07 AM, Erich erichfreebsdl...@ovitrap.com wrote:

 Hi,

 On 05 June 2012 11:24:25 Mark Andrews wrote:
 

  Version tagging is just a convient way to get a snapshot at a
  particular point in time unless you create branches that are them

 we do not ask for more. There should be only one difference to a
snapshot. As snapshot has a date. No matter in what state the ports tree
was, it is in that state in the ports tree. If user - especially the one
not so fit in this aspect - want to use a snapshot, it will be difficult to
impossible to figure out which one they need.

 If version numbers would be introduced, it would be ok to use the version
number of the FreeBSD and have only version available which reflect the
release version of the ports tree.

 People here want to make always a perfect system. People like me want to
have some small things in there available with a click.

 As the ports trees are there anyway, only the direct link to the snapshot
of that day or a version number in the ports tree would be needed to make
this available for people who just want to use FreeBSD.

 Please note, I do not want any extra work spend here to make this
perfect. I only want a simple way to fall back to a big net which is not
that old from which the user can restart.


I and most others will purposely refuse to document this in any official
capacity, but I'll give you a hint.

Look for the date tag in man csup.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On 5 June 2012 09:25, Erich erichfreebsdl...@ovitrap.com wrote:
 Hi,

 On 05 June 2012 3:08:17 b. f. wrote:
  On 05 June 2012 15:33:16 Mark Andrews wrote:
  
   In message 2490439.EC638TI0j3 at x220.ovitrap.com, Erich writes:
Hi,
   
  All of these, with the exception of HEAD (which is always a valid tag), 
  only apply to the src/ tree. The ports/, doc/, and www/ trees are not 
  branched.
 
  I understand this that I can use these tags on the FreeBSD sources but not 
  on the ports.
 
  I never tried this on the ports.

 I sent a long reply to your earlier message on freebsd-ports
 explaining exactly this -- how each Ports tree snapshot has a version
 number: the date spec.  Also, how a few special snapshots also have a
 second version number: the release tag.  I also explained how to find
 and use these, with and without cvs.  Am I wasting my time by trying
 to answer your questions, E.?

 I think that you missed my point. The point is that this has to be made 
 available for beginners. As long as the handbook states that this does not 
 apply to the ports tree, at least beginners will stop there.

Beginners should be using packages anyway.

It is absolutely a bad idea for beginners to be using tagged/dated
ports trees-- they are not supported and will lead to many complaints
about problems that were solved since the tag.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On 3 June 2012 21:55, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On 06/03/12 15:29, Erich wrote:
 Hi,

 On 03 June 2012 PM 5:14:10 Adam Strohl wrote:
 On 6/3/2012 11:14, Erich wrote:
 What I really do not understand in this whole discussion is very simple. 
 Is it just a few people who run into problems like this or is this simply 
 ignored by the people who set the strategy for FreeBSD?

 I mention since yeares here that putting version numbers onto the port 
 tree would solve many of these problems. All I get as an answer is that it 
 is not possible.

 I think that this should be easily possible with the limitation that older 
 versions do not have security fixes. Yes, but of what help is a security 
 fix if there is no running port for the fix?

 I feel like I'm missing something.  Why would you ever want to go back
 to an old version of the ports tree?  You're ignoring tons of security
 issues!

 ... I think the PNG update isn't a security issue. And for not being a
 security issue, it triggered an inadequate  mess!


 And if a port build is broken then the maintainer needs to fix it, that
 is the solution.

 Look at the comment of the maintainer of LibreOffice ...

 I must be missing something else here, it just seems like the underlying
 need for this is misguided (and dangerous from a security perspective).

 yes, you miss a very simple thing. Updated this morning your ports tree. 
 Your client asks for something for Monday morning for which you need now a 
 program which needs some kind of PNG but you did not install it.

 ... I spent now two complete days watching my boxes updating their
 ports. Several ports do not compile anymore (inkscape, libreoffice,
 libxul, to name some of the very hurting ones!).


 Do you have a machine that is fast enough to upgrade all your ports and 
 still finish what your client needs Monday morning?

 Even my fastest box, a brand new 6 core Sandy-Bridge-E, wasn't capable
 of compiling all the ports in due time. Several ports requested
 attendance, several, as mentioned, didn't compile out of the blue.


 The ports tree is not broken as such. Only the installation gets broken in 
 some sense. Have a version number there would allow people to go back to the 
 last known working ports tree, install the software - or whatever has to be 
 done - with a working system.

 Of course, the next step will be an upgrade. But only after the work which 
 brings in the money is done.

 You do not face this problem on Windows. You can run a 10 year old 'kernel' 
 and still install modern software.

 Erich

 I like having a very modern system with the most recent software. But in
 some cases, like these days with the PNG, FreeBSD's ports becomes again
 a problem. There is no convenient way to downgrade or allow the
 user/admin managing how to deal with the load of updates.

You can't have both.  As has been repeatedly explained to you, you
should not expect an easy life with the very latest of software.

Either stick to releases, or put up with lots of compiling etc-- you
should not complain because of self-inflicted problems.

Please remember that we do compile packages for release, or if more up
to date packages are required you can use the stable package sets
which are rarely over five days or so.

Chris
___
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: Why Are You NOT Using FreeBSD?

[Chris Rees]

On Jun 2, 2012 3:19 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 On 06/02/12 14:47, Daniel Kalchev wrote:
 
 
  On 02.06.12 15:32, Erich wrote:
  I know that the ports tree is a moving target. But it stops moving
  during the release period. This could be used to give a fall back
  solution.
 
  Or do I see this really too simple?
 
  The ports tree is a moving target during release periods still, although
  there are efforts to make movements smaller. This is why, after a
  release it suddenly moves more :)
 
  Daniel

 Even IF the ports tree IS a moving target, updating of UPDATING, for
 instance, follows most times AFTER the critical ports has been
 changed/updated and folks started updating their ports without realizing
 that they have shot themselfs into the foot!


Not reading UPDATING until there are problems is not the fault of the ports
tree; it should be checked every time you update.

Of course, many of us forget, but that still doesn't make it anyone else's
problem when we do!

Chris
___
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: OpenLDAP 2.4.31 on FreeBSD 10.0-CURRENT/amd64 broken!

[Chris Rees]

On 5 May 2012 16:55, Hartmann, O. ohart...@zedat.fu-berlin.de wrote:

 Hello lists.

 Since Friday, I have on all of our FreeBSD 10.0-CURRENT/amd64 boxes
 massive trouble with net/openldap24-server (SASL enabled, so it is
 openldap-sasl-server).

 Last time OpenLDAP worked was Thursday last week, when obviously a
 problematic update to the OS was made - it is a wild guess, since I did
 daily make world and by the end of the day after the last make world
 things went worse. I'm sorry having no SVN release tag handy.

 Well, here some facts.

 1) The update of net/openldap24-server has been performed earlier this
 month and has been run successfully (2.4.31).

 2) It doesn't matter whether OpenLDAP is compiled with CLANG 3.1 or
 legacy GCC 4.2.1, compiled with CLANG, slapd(8C)  coredumps immediately,
 compiled with gcc, it starts, but when slapd(8C) gets accessed, it
 coredumps immediately. A simple id ohartmann is enough.

 3) I recompiled OpenLDAP 2.4.31 client and server and it requisites via
 portmaster -f net/openldap24-server|client. No effect/success. I also
 recompiled every port used with OpenLDAP: security/pam_ldap and
 net/nss_ldap.

 4) OpenLDAP server uses DB5 based backend.

 5) The very same configuration (copied slap.d folder's .ldif files)
 works fine on FreeBSD 9.0-STABLE/amd64, even compiled with CLANG. This
 makes me believe this is a FreeBSD 10.0-CURRENT specific bug.

 6) Following is a truss output of the following comand issued:

 /usr/local/libexec/slapd -d32 -o ldap -g ldap -F
 /usr/local/etc/openldap/slapd.d :

 [...]
 connect(8,{ AF_INET 192.168.0.128:389 },16)  ERR#61 'Connection
refused'
 shutdown(8,SHUT_RDWR)ERR#54 'Connection
 reset by pee
 r'
 close(8) = 0 (0x0)
 clock_gettime(13,{1336231852.0 })= 0 (0x0)
 getpid() = 84297 (0x14949)
 sendto(3,163May  5 17:30:52 slapd[84297...,97,0x0,NULL,0x0) = 97
(0x61)

sigprocmask(SIG_SETMASK,SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGF

PE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|

SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH
 |SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
 sigaction(SIGPIPE,{ SIG_DFL SA_RESTART ss_t },{ SIG_IGN 0x0 ss_t }) = 0
 (0x0)
 sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
 4fa547ac ldif_read_file: checksum error on
 /usr/local/etc/openldap/slapd.d//cn=
 config/olcDatabase={1}hdb.ldif
 4fa547ac hdb_db_open: database dc=walstatt,dc=dyndns,dc=org: unclean
 shutdown
 detected; attempting recovery.
 4fa547ad hdb_db_open: database cn=accesslog: unclean shutdown
 detected; attemp
 ting recovery.
 4fa547ad slapd starting
 SIGNAL 11 (SIGSEGV)
 setgroups(0x1,0x802c7a000,0x802c7c001,0x,0x0,0x0) ERR#4
 'Interrupted sys
 tem call'
 process exit, rval = 0


 7) Desperately, I tried nearly every variation of the configurable
 overlays, even those my configuration doesn't use. But this seems
 nonesense since OpenLDAP worked before.

 I'm floating like a dead man in the water and I was wondering if someone
 else doesn't face this problem. FreeBSD is said to be run in large
 environments, so at least one should have OpenLDAP as user backend
 running ...

 I need some help in this case.


Why are you running -CURRENT in production?

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 28 Apr 2012 19:04, Luke Dean lu...@pobox.com wrote:



 On Fri, 30 Mar 2012, Chris Rees wrote:

 On 30 Mar 2012 14:26, sth...@nethelp.no wrote:


 However, if you always want to use tmpfs instead of stable storage,

 please do not.  Some people expect /tmp to be persistent.  This is why
 /etc/defaults/rc.conf has clear_tmp_enable=NO.  Changing this would

 break

 the POLA.


 This is a mistake.

 The default should be clear_tmp_enable=YES
 if only to uncover those broken configurations that expect /tmp to be
 persistent.


 If you want to break POLA and make a lot of people angry, sure.
 Otherwise no.


 I would very much like an example of where /tmp is expected to persist.

 Chris


 Yes, I'm a month behind on my mailing list reading and this conversation
is probably over, but I do have a personal example.

 In my periodic.conf, I have:
 daily_clean_tmps_enable=YES
 daily_clean_tmps_days=30

 I tend to have many distractions and work on many projects at the same
 time.  I don't always know when I'm finished.  Sometimes I just lose
 interest.  I often don't remember to clean up after myself.

 These settings in periodic.conf allow me to set up temporary workspaces
in /tmp.  If I keep working on a project, my files remain.  If I forget
about it for a month, periodic will clean up my mess.

 If someday the default behavior were changed to make /tmp a
memory-mounted filesystem or to clean it out on every reboot, I think I
could set daily_clean_tmps_dirs to another directory and move my sandbox
someplace else.  I would very much appreciate some warning, but this would
not be a problem for me.

You should use /var/tmp for that, or another custom directory if you want
your files safe.

Chris
___
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] Un-staticise the toolchain

[Chris Rees]

Oops, just replied privately before:
On Apr 26, 2012 12:39 PM, Chris Rees utis...@gmail.com wrote:


 On Apr 26, 2012 10:36 AM, Konstantin Belousov kostik...@gmail.com
 wrote:
 
  I think it is time to stop building the toolchain static. I was told that
  original reasoning for static linking was the fear of loosing the ability
  to recompile if some problem appears with rtld and any required dynamic
  library. Apparently, current dependencies are much more spread, e.g.
 /bin/sh
  is dynamically linked, and statically linked make does not solve
 anything.
 
  Patch below makes the dynamically linked toolchain a default, adding an
  WITHOUT_SHARED_TOOLCHAIN build-time option for real conservators.

 Nice idea, but sh etc al are built statically as /rescue/sh.  Will we see
 /rescue/ar  etc?

 Chris

___
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] Un-staticise the toolchain

[Chris Rees]

On Apr 26, 2012 2:42 PM, Ruslan Ermilov r...@freebsd.org wrote:

 On Thu, Apr 26, 2012 at 12:35:48PM +0300, Konstantin Belousov wrote:
  I think it is time to stop building the toolchain static. I was told
that
  original reasoning for static linking was the fear of loosing the
ability
  to recompile if some problem appears with rtld and any required dynamic
  library. Apparently, current dependencies are much more spread, e.g.
/bin/sh
  is dynamically linked, and statically linked make does not solve
anything.

 
 r76801 | sobomax | 2001-05-18 13:05:56 +0400 (Fri, 18 May 2001) | 6 lines

 By default build make(1) as a static binary. It costs only 100k of
additional
 disk space, buf provides measureable speed increase for make-intensive
 operations, such as pkg_version(1), `make world' and so on.

 MFC after:  1 week

 

 Have things changed enough that the above is not true anymore?
Well, the most make(1)-intensive test I can think of is make index, so some
results from a quick test:

hydra# uname -a
FreeBSD hydra.bayofrum.net 9.0-RELEASE FreeBSD 9.0-RELEASE #7: Sun Apr 22
21:02:48 BST 2012 r...@hydra.bayofrum.net:/usr/obj/usr/src/sys/HYDRA
amd64

hydra# cd /usr/src/usr.bin/make  make NO_SHARED=yes  cp make
~/bin/make-static  /dev/null

hydra# rm make  make NO_SHARED=no  cp make ~/bin/make-dynamic 
/dev/null

hydra# file ~/bin/make-*
/home/chris/bin/make-dynamic: ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.0 (900044),
not stripped
/home/chris/bin/make-static:  ELF 64-bit LSB executable, x86-64, version 1
(FreeBSD), statically linked, for FreeBSD 9.0 (900044), not stripped

hydra# cd /usr/ports  time make MAKE=~crees/bin/make-static index

Generating INDEX-9 - please wait.. Done.
729.770u 120.841s 7:45.10 182.8%920+2676k 5251+116484io 7750pf+0w

hydra# time make MAKE=~crees/bin/make-dynamic index

Generating INDEX-9 - please wait.. Done.
771.320u 133.540s 8:07.83 185.4%609+2918k 474+116484io 570pf+0w

We have a 10% slowdown (or 11% speedup, depending on your figures) when
using a dynamically loaded make.

Chris
___
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] Un-staticise the toolchain

[Chris Rees]

On 26 April 2012 20:15, Matthew Seaman m.sea...@infracaninophile.co.uk wrote:
 On 26/04/2012 20:01, Chris Rees wrote:
 hydra# cd /usr/ports  time make MAKE=~crees/bin/make-static index

 Generating INDEX-9 - please wait.. Done.
 729.770u 120.841s 7:45.10 182.8%        920+2676k 5251+116484io 7750pf+0w

 hydra# time make MAKE=~crees/bin/make-dynamic index

 Generating INDEX-9 - please wait.. Done.
 771.320u 133.540s 8:07.83 185.4%        609+2918k 474+116484io 570pf+0w

 We have a 10% slowdown (or 11% speedup, depending on your figures) when
 using a dynamically loaded make.

 I don't think you can validly conclude much from just one sample of each
 type.  Try repeating those tests enough that you can do some decent
 statistics.

 Oh, and you should probably either discard the first few results, or
 else take pains to flush[*] the buffer cache between each run, so you
 end up measuring the same thing repeatably.

Had I done the tests the other way around, I may agree with you, but
the second test should benefit from any buffering, and it is *still*
slower.

Look, I know it's not a perfect benchmark, it was just some food for
thought-- a difference of 10% is pretty significant, and I don't think
you can blame that on a solar flare.

Chris
___
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: xdm failing to start on FBSD 10.0 r2340030 erratically

[Chris Rees]

On 9 Apr 2012 11:00, O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 Am 04/09/12 11:15, schrieb Anton Shterenlikht:
  On Mon, Apr 09, 2012 at 10:54:07AM +0200, O. Hartmann wrote:
  Am 04/08/12 17:29, schrieb David Wolfskill:
  On Sun, Apr 08, 2012 at 01:29:36PM +0200, O. Hartmann wrote:
  I loose hair ...
  Since yesterady's make world (last make world: the day before
  yesterday), getting FreeBSD 10.0-CURRENT/amd64 to r234000 or so, the
X11
  system on all of our FreeBSD 10.0-CUR/amd64 boxes start rejecting the
  start of xdm display manager. xdm is started from /etc/ttys on ttyv7.
  This worked before flawless.
 
  At this very moment, I do have X11 started via xdm - but this is a
  erratic and non-reproduceable process!
 
  This morning, I update world and kernel to r234030. I recompiled many
  ports via portmaster -f xorg xdm, hoping the new kernel/world could
  affect the ports, but this isn't.
 
  Starting Xorg X11 server works fine. xdm fails. The log in
  /var/log/xdm.log looks like:
 
  Build Date: 07 April 2012  04:51:08PM
  ...
 
 
  I feel a bit helpless around here since I can not get close to what
is
  happening. The erratic behaviour of starting xdm is frightening.
  Starting xdm via /etc/ttys doesn't work at all, but sometimes, with a
  bit luck, xdm starts when started from the console.
  
 
  I am not having trouble starting xdm via /etc/ttys; my environment is
  known to differ from yours in the following ways:
 
  * My ports (save for x11/nvidia-driver and misc/compat8x) are built
under stable/8.  (I track stable/8, stable/9, and head on a daily
basis, and have a common /usr/local among them.  I also update
any installed ports that have updates available daily.)
 
  * I am running FreeBSD/i386, vs. FreeBSD/amd64.
 
  * My last 2 updates were r233994 (yesterday) and r234031 (today).
 
  * I have a mildly hacked-up startup script for xdm.  I doubt this is
an
issue -- I've been doing this since 2006/03/05 19:04:03 (according
to
the RCS log), though I have modified the script a few times
since its inception.  But the point here is that I'm not directly
invoking the xdm executable from /etc/ttys.
 
  When I start xdm via console, it starts up, but only with a Xservers
  file that contains nothing but comments. If there are the lines
 
  localhost
  127.0.0.1
  192.168.0.128
  !*
 
  it will will probably start not. Since xdm does not show this behaviour
  in a reproducible manner I susepct a bug.
 
 
  * I don't know that this is different, but it may well be:  my
xorg.conf
includes a stanza:
 
Section ServerFlags
Option AutoAddDevices False
EndSection
 
  I should go with this and try. But as far as I know, since I have USB
  devices (mouse, keyboard), unpluggin and pluggin them is then, without
  hal and dbus, not recognized anymore, isn't it?
 
  There was a discussion once going one for this subject.
 
 
  Either way, at this very moment I do not know whether the OS or the X11
  is faulty and I'd like to report this as a bug.
 
 
because my experiences with hald  dbus were so unpleasant.  I don't
use them; I don't even try to start them.
 
  Peace,
  david
 
  Regards,
  Oliver
 
 
  I see the same (or similar) behavior on r231158M amd64
  Compaq 6715s laptop.
 
  I've:
 
  BUZI pkg info xdm
  xdm-1.1.11: X.Org X display manager
  BUZI

 pkohartmann@thor: [~] g_info |grep xdm
 xdm-1.1.11  X.Org X display manager

 
  Starting xdm from /etc/ttys:
 
  BUZI grep bin/xdm /etc/ttys
  ttyv8   /usr/local/bin/xdm -nodaemon  xterm   on  secure
  BUZI

 ohartmann@thor: [~] grep bin/xdm /etc/ttys
 ttyv7   /usr/local/bin/xdm -nodaemon  xterm   on  insecure

Hm, you know setting insecure on xdm still lets root login?

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 2 Apr 2012 16:47, jb jb.1234a...@gmail.com wrote:

 jb jb.1234abcd at gmail.com writes:

  ...

 Chuck Burns brea...@gmail.com

 1:01 AM (16 hours ago)

 My experiences with using tmpfs as /tmp
 --
 It works fine. until it doesn't.

 I've had mountpoints run out of space, checked df and the mountpoint had
been
 reduced to something like 2 MiB TOTAL, with nothing free.. on a machine
with
 8GiB RAM.. however, rebooting restores the mount to around 2GiB.. but
then after
 some heavy usage, the mountpoint once again starts shrinking in size.

 I've noticed this behavior in multiple versions of FreeBSD, and switched
to
 using md instead, with no more issues.

 I'm not willing to use tmpfs until it's proven to be more stable than it
was
 when I was using it.

 ---

 Chuck,
 plz check your posting to the list (I received it, which I reposted here).
 jb



This is a known issue with ZFS.  Is that your case?

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 30 Mar 2012 14:26, sth...@nethelp.no wrote:

   However, if you always want to use tmpfs instead of stable storage,
  please do not.  Some people expect /tmp to be persistent.  This is why
  /etc/defaults/rc.conf has clear_tmp_enable=NO.  Changing this would
break
  the POLA.
  
  This is a mistake.
 
  The default should be clear_tmp_enable=YES
  if only to uncover those broken configurations that expect /tmp to be
  persistent.

 If you want to break POLA and make a lot of people angry, sure.
 Otherwise no.


I would very much like an example of where /tmp is expected to persist.

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
 On Fri, Mar 30, 2012 at 3:18 PM,  sth...@nethelp.no wrote:
  However, if you always want to use tmpfs instead of stable storage,
 please do not.  Some people expect /tmp to be persistent.  This is why
 /etc/defaults/rc.conf has clear_tmp_enable=NO.  Changing this would break
 the POLA.
 
 This is a mistake.

 The default should be clear_tmp_enable=YES
 if only to uncover those broken configurations that expect /tmp to be
 persistent.

 If you want to break POLA and make a lot of people angry, sure.
 Otherwise no.

 I couldn't agree more. Not clearing /tmp on reboot has been
 the norm for way too long and it is too late to change now.
 It's not just POLA, it also involves deleting data of unaware
 users, and that should be avoided.

 Anyone willing to change policy w.r.t. /tmp can do so on their
 own machines. Nothing is preventing them from doing so.
 But by changing defaults, one should err on the side of
 caution and remain conservative, IMHO.

From man hier:

/tmp/  temporary files that are not guaranteed to persist across
system reboots

This assumption that people often make 'People will be astonished by
this'-- I would like to have someone speak up and actually say Yes, I
use *temporary* directories for long-term storage rather than the
assumption that they are around.

Software that assumes this should be fixed, and it won't be until the
bug is exposed (I'll look at eaccelerator-- it probably should store
its cache in /var/db).

Maintaining the status quo because of some hypothetical scenario isn't
really productive.

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 30 March 2012 19:36, Adrian Chadd adr...@freebsd.org wrote:

 On 30 March 2012 10:56, Chris Rees cr...@freebsd.org wrote:
 On 30 March 2012 17:31, C. P. Ghost cpgh...@cordula.ws wrote:
 On Fri, Mar 30, 2012 at 3:18 PM,  sth...@nethelp.no wrote:
  However, if you always want to use tmpfs instead of stable storage,
 please do not.  Some people expect /tmp to be persistent.  This is why
 /etc/defaults/rc.conf has clear_tmp_enable=NO.  Changing this would 
 break
 the POLA.
 
 This is a mistake.

 The default should be clear_tmp_enable=YES
 if only to uncover those broken configurations that expect /tmp to be
 persistent.

 If you want to break POLA and make a lot of people angry, sure.
 Otherwise no.

 I couldn't agree more. Not clearing /tmp on reboot has been
 the norm for way too long and it is too late to change now.
 It's not just POLA, it also involves deleting data of unaware
 users, and that should be avoided.

 Anyone willing to change policy w.r.t. /tmp can do so on their
 own machines. Nothing is preventing them from doing so.
 But by changing defaults, one should err on the side of
 caution and remain conservative, IMHO.

 From man hier:

 /tmp/      temporary files that are not guaranteed to persist across
 system reboots

 This assumption that people often make 'People will be astonished by
 this'-- I would like to have someone speak up and actually say Yes, I
 use *temporary* directories for long-term storage rather than the
 assumption that they are around.

 Software that assumes this should be fixed, and it won't be until the
 bug is exposed (I'll look at eaccelerator-- it probably should store
 its cache in /var/db).

 Maintaining the status quo because of some hypothetical scenario isn't
 really productive.

 Let me tell you a story.

 Someone decided that ext4 could have a decent speed up if it
 implemented the posix standard for not flushing files on close().
 After all, if you needed it to be guaranteed to be written to disk,
 you would call a flush routine first, before you called close().

 So they did this.

 Then people testing out ext4 discovered that upon crash, their
 kde/gnome profiles were corrupted.

 Why? Because KDE/Gnome authors hadn't ever called flush before
 close(), and they weren't the only ones. They didn't read the
 standard, they only used the system and fixed bugs whenever their
 system behaved against their expectations. They didn't notice that the
 system was being different from the standard.

 Guess what ext4 did? :)

 Don't mis-estimate POLA.

Well, having thought about what this conversation was *really* about,
I may have unintentionally derailed it a little.

My original intention was to say to Oliver, please, don't be
discouraged from using tmpfs for /tmp, and make sure you send PRs to
the upstream of any programs that misbehave as such.

Let's not make judgement on people who treat /tmp as persistent quite yet ;)

Chris
___
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: Using TMPFS for /tmp and /var/run?

[Chris Rees]

On 29 Mar 2012 16:49, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:

 I was wondering if there are some objections using TMPFS for /tmp and
 /var/run.
 I figured out some problems with some rc.d scripts when using TMPFS for
 /var/run, samba and OpenLDAP do store some informations like PID in a
 subfolder of their own in /var/run, but the rc.d scripts are not
 checking properly the existence of the appropritae folder (unlike dbus
 and hald, they check properly!).

 I already submitted two PRs, but for SAMBA, my hack is trivial and
 obviously to clumsy, so it should be check properly.

 My question is whether there are objections using TMPFS for bot /tmp/
 and /var/run/ at this stage on FreeBSD 10.0-CURRENT/amd64?

Any rc script that complains about an empty /var/run is buggy- it should be
assumed that it will be emptied on boot.

In short, tmpfs for those two dirs should be fine.

Chris
___
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: hi-- looking for some help

[Chris Rees]

On 19 March 2012 23:21, Iurie iur...@gmail.com wrote:
 hi
 i saw your email inthe following link:
 http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026412.html

 im studying in portugal and in have acourse about pc networking.
 there i have propossed to implement exactly the same thing as you have
 described in your email.
 i would like to know if ou can give me the source code of it to take some
 inspiration.
 if not can you at least tell me briefly how that is done?
 or at least from where i must begin to have any idea about how that is done?
 or at least where i can look at some code to have some clues on how that is
 done?

 i need it to be done in c for linux

 i thnk you in advance for your answer

All of the source for FreeBSD is available by svn or cvsup.

http://svnweb.freebsd.org/base/head/

and can be checked out using:

svn co http://svn.freebsd.org/base/head/

Chris
___
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: rm -rf / fanclub

[Chris Rees]

On 6 March 2012 20:38,  deeptec...@gmail.com wrote:
 Peter Maloney wrote:
 On Thu, Feb 23, 2012 at 11:41 PM, deeptech71 at gmail.com
 deeptech71 at gmail.com wrote:
  X11R6 should be a symlink to local or ./local.

 Did you test this, by removing the link and creating it
 relative to see if there are any stupid side effects?

 No apparent side effects. And I can't even see why there would be any. In
 both cases (X11R6 points to /usr/local vs X11R6 points to local)
 - /usr/X11R6 resolves to the symlink, although
    different symlink texts can be extracted;
 - /usr/X11R6/ resolves to the local directory in /usr;
 - /usr/X11R6/file123 resolves to /usr/local/file123.

 TODO: Test whether purely removing X11R6 has any side effects.

Not hugely helpful, but I've discovered a few subtle bugs that
miraculously disappear when X11R6 symlink was removed.

I still miss it though, in a weird way...

Chris
___
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: /sys/conf/kmod.mk, line 111: Malformed conditional (${MK_CLANG_IS_CC}

[Chris Rees]

On 3 March 2012 11:48, O. Hartmann ohart...@zedat.fu-berlin.de wrote:
 On one of my FreeBSD 10.0-CURRENT boxes I receive this morning this
 error message as shown below.

 I need to add, that I compiled the shown nvidia-driver hours ago on all
 FreeBSD 9.0-STABLE boxes with the same settings and I compiled the
 driver just two days before the same way I tried it this morning. What's
 wrong?

 Some unexpected breakage? Then this is my shout to the community.

 Message below.

 Regards and thanks in advance,
 Oliver

 ===  Vulnerability check disabled, database not found
 ===  License NVIDIA accepted by the user
 ===  Found saved configuration for nvidia-driver-295.20
 ===  Extracting for nvidia-driver-295.20
 = SHA256 Checksum OK for NVIDIA-FreeBSD-x86_64-295.20.tar.gz.
 ===  Patching for nvidia-driver-295.20
 ===   nvidia-driver-295.20 depends on file:
 /usr/local/libdata/pkgconfig/xorg-server.pc - found
 ===   nvidia-driver-295.20 depends on shared library: GL.1 - found
 ===  Configuring for nvidia-driver-295.20
 ===  Building for nvidia-driver-295.20
 === src (all)
 /sys/conf/kmod.mk, line 111: Malformed conditional (${MK_CLANG_IS_CC}
 == no  ${CC:T:Mclang} != clang)
 /sys/conf/kmod.mk, line 115: if-less endif
 /sys/conf/kern.mk, line 18: Malformed conditional (${MK_CLANG_IS_CC}
 != no || ${CC:T:Mclang} == clang)
 /sys/conf/kern.mk, line 31: if-less endif
 /sys/conf/kern.mk, line 101: Malformed conditional (${MK_CLANG_IS_CC}
 == no  ${CC:T:Mclang} != clang)
 /sys/conf/kern.mk, line 109: if-less endif
 make: fatal errors encountered -- cannot continue
 *** [all] Error code 1


Please post your make.conf and src.conf.

Chris
___
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: src.conf ignored; phantom named

[Chris Rees]

On 2 March 2012 23:09, Yuri Pankov yuri.pan...@gmail.com wrote:
 On Fri, 2 Mar 2012 17:41:28 -0500, Rotate 13 wrote:

 I set WITHOUT_BIND=yes in /etc/src.conf, and built/installed world.
 Not only does /usr/sbin/named exist - named is actually started!
 Several other WITHOUT_* variables also were apparently ignored, as
 evidenced by stuff installed on running system.

 My main question is - how do I debug this?  I have been combing over
 makefiles under /usr/src (not to mention, going through /etc/rc.d/
 trying to figure out what actually started named).  As far as I
 ascertain, _WITHOUT_SRCCONF is *not* set anywhere for world building;
 named_enable=no in relevant rc.conf files; rpcbind and ntpd are not
 running either.  Since named daemonized, it's not easy to tell who
 started it - and grepping everything in sight, I can't figure out how
 it got built in the first place.

 uname -a:
 FreeBSD xyz.example.com 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 29
 10:28:17 CST 2012    r...@xyz.example.com:/usr/obj/usr/src/sys/CUSTOM
 amd64

 I focused substantial attention on /usr/src/share/bsd.own.mk and
 worked outward; but did not find anything obvious.

 Advice on where to poke for the right information, much appreciated.


 src.conf controls what is (not) built. To actually remove the bits marked as
 WITHOUT_ from the system, try running `make delete-old` in /usr/src.

Has the behaviour of make delete-old changed?  As far as I can
remember, it doesn't remove stuff marked as WITHOUT_ --it's there to
deal with updates.

Chris
___
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: PEBKAC

[Chris Rees]

On 26 February 2012 05:38, Super Bisquit superbisq...@gmail.com wrote:
 Both standard-supfile and kernel-supfile were edited to use the .
 tag along with the CVS server being cvsup.FreeBSDS.org; but, I'm still
 getting the version error for config(8).  It seems to me that my
 problem may be the base system is out of sync with the source- I'm
 using Whitehorn's 2010  snapshot because the recent versions won't
 load on my machine. Not too sure about compiling config from
 usr.sbin since doing this the recent time caused errors. So, I'm
 thinking that either I need to keep make buildkernel from checking
 config version- which I don't know how to do- or wgetting version
 600010 of config(8)- of which I don't know which server has that
 version.

Have you tried just removing your entire src tree and re-csupping?
Looks like it might be polluted somewhere...

Chris
___
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: print/ghostscript9: ./base/sjpx_openjpeg.c:169: error: too many arguments to function

[Chris Rees]

On 13 Feb 2012 11:14, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:

 This arise today when updating  ghostscript9-9.04 to ghostscript9-9.05:


 cc  -DHAVE_MKSTEMP   -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE
 -DHAVE_SSE2 -DHAVE_DBUS   -O2 -pipe -O2 -fno-strict-aliasing -pipe
 -march=native -fPIC -DUPD_SIGNAL=0 -I.
 -I/usr/ports/print/ghostscript9/work/ghostscript-9.05/lcms/include
 -I/usr/local/include/libpng  -I/usr/local/include
 -I/usr/local/include/freetype2  -Wall -Wstrict-prototypes -Wundef
 -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings
 -Wno-strict-aliasing -Wdeclaration-after-statement -fno-builtin
 -fno-common -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1
 -DGX_COLOR_INDEX_TYPE=unsigned long int -O2 -pipe -O2
 -fno-strict-aliasing -pipe -march=native -DUSE_LIBICONV_GNU
 -DUSE_LIBPAPER -I/usr/local/include   -DGS_DEVS_SHARED
 -DGS_DEVS_SHARED_DIR=\/usr/local/lib/ghostscript/9.05\
 -Iopenjpeg/libopenjpeg/.. -Iopenjpeg/libopenjpeg -I./soobj -I./base
 -DUSE_OPENJPEG_JP2 -ffast-math -DOPJ_STATIC -std=c99  -o
 ./soobj/sjpx_openjpeg.o \
-c -DOPJ_STATIC ./base/sjpx_openjpeg.c
 ./base/sjpx_openjpeg.c: In function 'decode_image':
 ./base/sjpx_openjpeg.c:169: error: too many arguments to function
 'opj_decode'
 ./base/sjpx_openjpeg.c:205: error: 'opj_image_comp_t' has no member
 named 'typ'
 ./base/sjpx_openjpeg.c:205: error: 'CTYPE_COLOR' undeclared (first use
 in this function)
 ./base/sjpx_openjpeg.c:205: error: (Each undeclared identifier is
 reported only once
 ./base/sjpx_openjpeg.c:205: error: for each function it appears in.)
 ./base/sjpx_openjpeg.c:207: error: 'opj_image_comp_t' has no member
 named 'typ'
 ./base/sjpx_openjpeg.c:207: error: 'CTYPE_OPACITY' undeclared (first use
 in this function)
 ./base/sjpx_openjpeg.c:217: error: 'CLRSPC_CMYK' undeclared (first use
 in this function)
 ./base/sjpx_openjpeg.c:250: error: 'opj_image_t' has no member named
 'has_palette'
 ./base/sjpx_openjpeg.c:257: error: 'CLRSPC_EYCC' undeclared (first use
 in this function)
 gmake[2]: *** [soobj/sjpx_openjpeg.o] Error 1
 gmake[2]: Leaving directory
 `/usr/ports/print/ghostscript9/work/ghostscript-9.05'
 gmake[1]: *** [so-subtarget] Error 2
 gmake[1]: Leaving directory
 `/usr/ports/print/ghostscript9/work/ghostscript-9.05'
 gmake: *** [so] Error 2
 *** Error code 1

 Stop in /usr/ports/print/ghostscript9.
 *** Error code 1

 Stop in /usr/ports/print/ghostscript9.

 === make failed for print/ghostscript9
 === Aborting update

 Terminated

 === You can restart from the point of failure with this command line:
   portmaster flags print/ghostscript9


This has already been discussed on ports@, please don't cross-post.

Chris
___
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: Enhancing the user experience with tcsh

[Chris Rees]

On 12 Feb 2012 17:11, Chuck Swiger cswi...@mac.com wrote:

 On Feb 11, 2012, at 11:05 PM, Gonzalo Nemmi wrote:
  Joel, with all due respect, do you really think that 99.9% of all
  users will not find the _non_intrusive_ additions below useful?
 
  bindkey \e[1~ beginning-of-line #make Home key work;
  bindkey \e[2~ overwrite-mode #make Ins key work;
  bindkey \e[3~ delete-char #make Delete key work;
  bindkey \e[4~ end-of-line #make End key work;

 Yes, I do not find the additions mentioned right here useful.

 Much of the time, I'm using a laptop which does not have dedicated
Home/INS/Delete/End keys.  And even when I am using a full 10x-key
keyboard, I would not use them since I prefer using editmode=emacs and
Cntl-A / E.

So do I, but would these hurt you?

I think it's insane that by default the standard keys don't work.

Chris
___
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: Enhancing the user experience with tcsh

[Chris Rees]

On 12 Feb 2012 18:22, Chuck Swiger cswi...@mac.com wrote:

 On Feb 12, 2012, at 9:16 AM, Chris Rees wrote:
  So do I, but would these hurt you?

 At the present time, no.  (At one point, I was using a keyboard
 where the arrow keys generated ESC-[ 1 ~ through 4,
 IIRC, but I haven't been on console on it in some time.)

  I think it's insane that by default the standard keys don't work.

 What standard keys would those be?

 Folks, assuming that everyone uses IBM-AT derived American QUERTY
 layout keyboard is faulty.  Our German friends are more likely to use
 a QUERTZ layout, French/Benelux tend to use AZERTY, and non ISO-Latin-1
 languages like Russian and the asian languages have still other layouts.

 On the non-laptop keyboard I use most, which does have a QUERTY layout,
 but it does not have an Insert key; that key is the function key:

  http://en.wikipedia.org/wiki/File:Apple_iMac_Keyboard_A1243.png  [1]

 On other non-American keyboards, the Insert key is labelled Help,
 and generated 0xF5 (F1 + Meta/set-high-bit?).

 Regards,
 --
 -Chuck

 [1]: Which is decent, but not perfect.  I'd swap ESC and `~, and
 caps-lock with control, and that would IMO be the perfect layout.

 For obvious reasons, I don't recall ever using or needing to use the
 function key.  Even when on a Windows box, I wouldn't typically use
 the middle-upper 6-key Ins/DEL/etc block; I touch-type and my hands
 don't like to leave home row.  (On the other hand, I do change volume
 and screen brightness daily, and even eject audio CDs more than I need Fn.
 I'm just as happy to not need to do these things via two key-presses...)

 PS: Folks, all of the above discussion, which includes my preferences, is
 aside from my main point, which is that proposed changes should first
 land as examples.  Far too much of what people consider obvious
improvements
 not only do not apply everywhere, they sometimes *don't* *work* and break
 things.

Right... not once however have you referenced the Home/End/Delete keys,
which is what I was talking about (I'll give you Insert) :)

The scan codes for those three keys are the same on (almost)
all,keyboards.  Jilles is right about fixing the tcsh source however.

Chris
___
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: Enhancing the user experience with tcsh

[Chris Rees]

On 10 Feb 2012 14:58, Erich Dollansky erichfreebsdl...@ovitrap.com
wrote:

 Hi Eitan,

 On Friday 10 February 2012 21:03:52 Eitan Adler wrote:
  Picking a random person to reply to.
 
  There are a lot of good suggestions in this thread, but can we please
  remember a few things:
 
  - Users can always add their own ~/.cshrc
  - Many users will get annoyed by what is someone else's amazing setup

 sorry for going a bit far off your route.
 
  The changes I proposed were designed to add value while continuing to
  be non-annoying to the vast majority of users. I'd like feedback about
  the specific patch I proposed. We can also create a wiki page for
  more awesome tcsh examples.
 
  For the record this is the current version of the patch I'd like to
  commit: Note that it slightly changed from the original (I removed the
  duplicate prompt setup and reorganized where the edits are made to
  make the diff look nicer).
 
  commit 3ea4ea3a59d14cb060244618dd89d7dd0170bee1
  diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc
  --- a/etc/root/dot.cshrc
  +++ b/etc/root/dot.cshrc
  @@ -7,9 +7,10 @@
 
   alias h  history 25
   alias j  jobs -l
  -alias la ls -a
  +alias la ls -aF

 ok, makes sense.

   alias lf ls -FA
  -alias ll ls -lA
  +alias ll ls -lAF
  +alias ls ls -F
 
 ok, makes sense.

   # A righteous umask
   umask 22
  @@ -17,15 +18,19 @@ umask 22
   set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin
  /usr/local/bin $HOME/bin)

 I use the $HOME/bin on my machines but I am not so sure to make this a
general thing.

 
   setenv   EDITOR  vi
  -setenv   PAGER   more
  +setenv   PAGER   less
   setenv   BLOCKSIZE   K

 ok, makes sense.

 
   if ($?prompt) then
# An interactive shell -- set some stuff up
  - set prompt = `/bin/hostname -s`# 
  + set prompt = [%n@%m]%c04%# 
  + set promptchars = %#

 I would add a

set ellipsis

 here. It makes the prompt shorter when needed.


Hence the %c04 modification to the path :)

Chris
___
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: Enhancing the user experience with tcsh

[Chris Rees]

On 10 Feb 2012 19:41, Alex Keda ad...@lissyara.su wrote:

 On 10.02.2012 21:07, Chuck Burns wrote:

 set prompt = [%n@%m]%c04%# 

 it's not needed

 need some as
 alias ll ls -lAhG
 alias ls ls -G

Lscolors are an abomination.  -F or nothing at all is better; remember some
people will use white xterms etc.

Chris

 set autolist = TAB
 bindkey \e[3~ delete-char
 
 and other _really_ necessary settings


  complete chown  'p/1/u/'
  complete man'C/*/c/'
  complete service'n/*/`service -l`/'
 need as example. may be in include file, may be in .cshrc

 ___
 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: [HEADSUP][CFT] pkgng beta1 is out

[Chris Rees]

2012/2/5 Radio młodych bandytów radiomlodychbandy...@o2.pl:
 I wonder if I'm the only one thinking about a decentralised package
 management
 First, a decentralised transport layer. Torrents are faster and more
 reliable than servers.
 Second, decentralised management when anybody can upload a port directly
 into the system.

You're not, but no-one has written one for FreeBSD yet

/hint

Chris
___
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: HEADS UP: set_rcvar() removed from rc.subr

[Chris Rees]

On 15 January 2012 08:11, Conrad J. Sabatier conr...@cox.net wrote:
 On Sat, 14 Jan 2012 15:30:15 +
 Chris Rees cr...@freebsd.org wrote:

 On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
  On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:
 
  Howdy,
 
  Per discussion in freebsd-rc@, I have removed set_rcvar() from
  rc.subr. The concept of set_rcvar() was nice in theory, but the
  forks it creates are a drag on the startup process, which is
  especially noticeable on slower systems, such as embedded ones.
 
  I have no plans to MFC this change, so it should only affect users
  who are actually on 10-current. If you have scripts
  in /usr/local/etc/rc.d (which if you have ports installed you
  almost certainly do) ...
 
  to make the change by hand, change this:
 
  name=foo
  rcvar=`set_rcvar`
 
  to:
 
  name=foo
  rcvar=foo_enable
 
  I didn't bump PORTREVISIONs because the change only applies to
  HEAD. But all of the ports are updated, so if you can't figure out
  how to make the change, just reinstall it.
 
 
  Doug
 
 
  Seems that ports-mgmt/tinderbox needs an update like this:
 
  files/patch-etc__rc.d__tinderd
 
  --- etc/rc.d/tinderd.orig       2011-11-20 07:01:09.0 +0100
  +++ etc/rc.d/tinderd    2012-01-14 16:07:38.0 +0100
  @@ -16,7 +16,7 @@
   . /etc/rc.subr
 
   name=tinderd
  -rcvar=`set_rcvar`
  +rcvar=tinderd_enable
 
   # read settings, set default values
   load_rc_config ${name}
 

 I'm in the process of fixing this upstream.

 Chris

 Chris, if you're working on fixing ports' rc files, here are a few
 potential gotchas to be aware of:

 I did a little quick-and-dirty sed substitution on all of my files
 under /usr/local/etc/rc.d, plugging in $filename_enable in place of
 `set_rcvar`.  This works just fine for all but a few.

 Filenames containing hyphens must have underscores substituted (e.g.,
 avahi-daemon, etc.).

 In a few cases, the rcvar is different from the filename in other
 ways.  The only ones I came across in my local installation were
 sa-spamd (spamd_enable) and mysql-server (mysql_enable).  There are
 bound to be others like this in ports.

 Overall, though, it was a simple matter to fix up the scripts I had
 installed already.  If I can be of any assistance in tidying up the
 ports tree, let me know.

Don't thank me!

http://lists.freebsd.org/pipermail/cvs-ports/2012-January/233843.html

The only ones that will cause trouble are the ones provided by
upstream, but a quick sed like the one in ports-mgmt/tinderbox will do
the trick until upstream has finished.

Chris
___
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: HEADS UP: set_rcvar() removed from rc.subr

[Chris Rees]

On 14 January 2012 11:11, Denny Lin dennyli...@hs.ntnu.edu.tw wrote:
 On Sat, Jan 14, 2012 at 01:05:59AM -0800, Doug Barton wrote:
 to make the change by hand, change this:

 name=foo
 rcvar=`set_rcvar`

 to:

 name=foo
 rcvar=foo_enable

 The scripts installed by net/avahi-app still use set_rcvar() because
 they are included in the source.

I imagine we'll see a few of these, but they'll get fixed quickly enough.

Chris
___
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: HEADS UP: set_rcvar() removed from rc.subr

[Chris Rees]

On 14 January 2012 15:16, Rainer Hurling rhur...@gwdg.de wrote:
 On 14.01.2012 10:05 (UTC+1), Doug Barton wrote:

 Howdy,

 Per discussion in freebsd-rc@, I have removed set_rcvar() from rc.subr.
 The concept of set_rcvar() was nice in theory, but the forks it creates
 are a drag on the startup process, which is especially noticeable on
 slower systems, such as embedded ones.

 I have no plans to MFC this change, so it should only affect users who
 are actually on 10-current. If you have scripts in /usr/local/etc/rc.d
 (which if you have ports installed you almost certainly do) ...

 to make the change by hand, change this:

 name=foo
 rcvar=`set_rcvar`

 to:

 name=foo
 rcvar=foo_enable

 I didn't bump PORTREVISIONs because the change only applies to HEAD. But
 all of the ports are updated, so if you can't figure out how to make the
 change, just reinstall it.


 Doug


 Seems that ports-mgmt/tinderbox needs an update like this:

 files/patch-etc__rc.d__tinderd

 --- etc/rc.d/tinderd.orig       2011-11-20 07:01:09.0 +0100
 +++ etc/rc.d/tinderd    2012-01-14 16:07:38.0 +0100
 @@ -16,7 +16,7 @@
  . /etc/rc.subr

  name=tinderd
 -rcvar=`set_rcvar`
 +rcvar=tinderd_enable

  # read settings, set default values
  load_rc_config ${name}


I'm in the process of fixing this upstream.

Chris
___
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: stable/9 still looking for packages at 9-current

[Chris Rees]

On 9 January 2012 18:16, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Mon, Jan 9, 2012 at 9:37 AM, Mark Linimon lini...@lonesome.com wrote:
 On 9. Jan 2012, at 01:04 , Arnaud Lacombe wrote:
 So you are saying that FreeBSD is currently providing on
 ftp://ftp.freebsd.org/pub images tagged as being 9.0 RELEASE (with
 checksum provided), in a `releases' directory, which are not actually
 release images per-se ?

 Excellent!  You've shown the ability to understand flat, declarative,
 sentences that have no qualifying phrases.

 FWIW, this was more a sarcastic sentence pointing out that FreeBSD is
 currently officially distributing non-released build in a directory
 which might leads users to consider this is the official release, thus
 misleading them.

So, a pointless email.

 9.0 will be *released* when and only when the official, signed, email
 goes out.  Everything up until that point is preparation.

 ok, I'm a stupid lazy user (obviously)... While browsing the ftp, I
 see 9.0 ISOs in a `releases' directory. Do you expect me to consult
 freebsd-announce@, verify the signature of the announce, the hash of
 the ISOs, etc. to consider that 9.0 has been released ? No, I see 9.0
 ISOs in a `releases' directory, I assume it has been released,
 whatever your spreading process is.

 Btw, none of the CHECKSUMS files are signed on the FTP.

Have you checked the website? The latest supported release is clearly
specified, right in the middle of the home page.

Please don't tell me you'd look in ftp before checking the website.  I
think you're just looking to nitpick.

Chris
___
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: stable/9 still looking for packages at 9-current

[Chris Rees]

On 9 January 2012 21:06, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Mon, Jan 9, 2012 at 1:27 PM, Chris Rees utis...@gmail.com wrote:
 On 9 January 2012 18:16, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Mon, Jan 9, 2012 at 9:37 AM, Mark Linimon lini...@lonesome.com wrote:
 On 9. Jan 2012, at 01:04 , Arnaud Lacombe wrote:
 So you are saying that FreeBSD is currently providing on
 ftp://ftp.freebsd.org/pub images tagged as being 9.0 RELEASE (with
 checksum provided), in a `releases' directory, which are not actually
 release images per-se ?

 Excellent!  You've shown the ability to understand flat, declarative,
 sentences that have no qualifying phrases.

 FWIW, this was more a sarcastic sentence pointing out that FreeBSD is
 currently officially distributing non-released build in a directory
 which might leads users to consider this is the official release, thus
 misleading them.

 So, a pointless email.

 as is linimon@'s.

 9.0 will be *released* when and only when the official, signed, email
 goes out.  Everything up until that point is preparation.

 ok, I'm a stupid lazy user (obviously)... While browsing the ftp, I
 see 9.0 ISOs in a `releases' directory. Do you expect me to consult
 freebsd-announce@, verify the signature of the announce, the hash of
 the ISOs, etc. to consider that 9.0 has been released ? No, I see 9.0
 ISOs in a `releases' directory, I assume it has been released,
 whatever your spreading process is.

 Btw, none of the CHECKSUMS files are signed on the FTP.

 Have you checked the website? The latest supported release is clearly
 specified, right in the middle of the home page.

 Please don't tell me you'd look in ftp before checking the website.  I
 think you're just looking to nitpick.

 I did look the ftp before the website. It is an irrelevant source of
 information as I assume none of that stuff to be up-to-date. re@ has
 an unimpressive track record about information update.

Ridiculous assumption.

I don't know who in re@ upset you so much, but you seriously need to
get over it and stop trying to prove they're idiots.

Constructive feedback is welcome, deliberately finding fault with
strange things is not.

Chris
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Chris Rees]

On 23 Dec 2011 12:25, O. Hartmann ohart...@mail.zedat.fu-berlin.de
wrote:

 Look at Steve Kargls problem. He investigated a SCHED_ULE problem in a
 way that is far beyond enough! He gave tests, insights of his setup, bad
 performance compared to SCHED_4BSD and what happend? We are still stuck
 with this problem and more and more people realise, that FreeBSD does
 have somewhere a problem and this seems to be a nasty problem not easy
 to find or investigate. But look at how Steve has been silenced in the
 past ...
 Benchmarks, especially published ones, reveal those pits and soemone
 could look into it.
 Another problem is this very elite-feeling closed club. Once you managed
 it getting into the club of committers or core team members, you'll
 probably fight for your seat ...

You are aware that Steve is part of the 'elite club', right?

Many of us rarely use our @FreeBSD.org addresses; you'd probably be
surprised at the names in the Developers list.

Just being a committer gives your opinions very little weight; everyone has
to make their case in the same way. There's really, really no eliteism here!

Chris
___
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: Removal of sysinstall from HEAD and lack of a post-install configuration tool

[Chris Rees]

On 29 December 2011 18:23, Pedro Giffuni p...@freebsd.org wrote:
 --- Gio 29/12/11, Nathan Whitehorn nwhiteh...@freebsd.org ha scritto:

 I'd appreciate any specific comments you might have, and
 especially
 specific suggestions for improvements. Except from people
 who are old
 hands at sysinstall, I've received almost universally
 positive comments
 on the user experience. Patches would be even more
 appreciated, since
 real life has intervened to steal most of my FreeBSD time.
 -Nathan


 FWIW;

 I have practically given up on installing FreeBSD lately
 and I mostly use PC-BSD. I mainly see two big issues:

 -X.Org has become very difficult to install. Setting up
 hald and friends, not to mention that you have to choose
 carefully your hardware previously. It's a nightmare.

I've not found that... installing xorg-drivers with the correct
options is hassle-free... have you posted these problems to -x11@?

 - I am OK with sysinstall disappearing: however it was
 nice to have all the setup tools in one place. How am
 I supposed to install prebuilt packages (and the myriad
 of dependencies) from now on? Ports are cool but having
 to wait to rebuild gcc to be able to use scilab is a
 nonsense.

Use packages, we do do them!

Chris

 PC-BSD is not without problems though. In my system
 it wants to use latam kbd which doesn't even
 exist AFAICT.

 Just my $0.02, I know writing a replacement for the
 full blown sysinstall is a rather heroic thing to do.

 Regards,

 Pedro.
___
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: Removal of sysinstall from HEAD and lack of a post-install configuration tool

[Chris Rees]

On 29 December 2011 21:25, Pedro Giffuni p...@freebsd.org wrote:
 --- Gio 29/12/11, Chris Rees cr...@freebsd.org ha scritto:

  FWIW;
 
  I have practically given up on installing FreeBSD
 lately
  and I mostly use PC-BSD. I mainly see two big issues:
 
  -X.Org has become very difficult to install. Setting
 up
  hald and friends, not to mention that you have to
  choose carefully your hardware previously. It's a
  nightmare.

 I've not found that... installing xorg-drivers with the
 correct options is hassle-free... have you posted these
 problems to -x11@?


 Hmm.. I think it was 8.2 and X.org -configure didn't
 give me a working screen, and then I discovered I had to
 be using hald, it was painful and I starting keeping a
 copy of my working configuration in a USB mem. TBH the
 -x11 guys were really doing their own homework keeping up
 with linux and I was able to find out the information on
 the net.

 I use the nvidia driver, no idea what people with ATI
 cards do.

I'm sorry to hear you're having trouble with that, if you ever want to
try again and you can't work it out get me off list ;)

  - I am OK with sysinstall disappearing: however it
 was
  nice to have all the setup tools in one place. How am
  I supposed to install prebuilt packages (and the
 myriad
  of dependencies) from now on? Ports are cool but
 having
  to wait to rebuild gcc to be able to use scilab is a
  nonsense.

 Use packages, we do do them!


 Of course, but no idea how to use them without
 sysinstall's post-install configuration screen: it
 was just too easy.

 I hope I don't have to start downloading manually all
 the prepackaged dependencies (I still do that with
 Java and it's not nice).

Nah, pkg_add -r works and grabs anything you need. Try it with
something monstrous (like gcc...)

Chris
___
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: Removal of sysinstall from HEAD and lack of a post-install configuration tool

[Chris Rees]

On 29 Dec 2011 21:36, Bruce Cran br...@cran.org.uk wrote:

 On 29/12/2011 21:30, Chris Rees wrote:

 Nah, pkg_add -r works and grabs anything you need. Try it with something
monstrous (like gcc...)


 But then you have to know the exact name of the package, which isn't
always obvious.

If an educated guess doesn't work...

make -C /usr/ports/category/name -V PKGNAME will get you the package name.

Chris
___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[Chris Rees]

On 15 Dec 2011 21:25, Kevin Oberman kob6...@gmail.com wrote:

 On Thu, Dec 15, 2011 at 10:46 AM, Chris Rees cr...@freebsd.org wrote:
  On 15 December 2011 17:58, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
  Since ZFS in Linux can only be achieved via FUSE (ad far as I know), it
  is legitimate to compare ZFS and ext4. It would be much more
competetive
  to compare Linux BTRFS and FreeBSD ZFS.
 
 
 
  Er... does ext4 guarantee data integrity?
 
  You're not comparing like with like; please do some research on the
  point of ZFS before asserting that they're fair comparisons.
 
  A fair(er) comparison could be ext4 with UFS+soft-updates.

 Wouldn't UFS+SUJ be the closest atch?

Yup. Thanks.

Chris
___
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: CVS removal from the base

[Chris Rees]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 11/12/2011 14:30, Julian H. Stacey wrote:
 On Sat, Dec 3, 2011 at 8:03 PM, sth...@nethelp.no wrote:

 I use CVS (or rather csup) to keep the base system up to date.
 I would be perfectly okay with using a different utility -
 however, I would strongly prefer that this utility was included
 in the base system.

 CVS != csup.

 I wonder how many people will express their sentiments about CVS
 when they really mean cvsup/csup.

 Max

 I use CVS I've used sup, (maybe csup can't rememeber, not used
 cvsup really) I avoid reliance on a net connection just to do a
 checkout. I use ctm to [push] feed my local CVS tree. ctm deltas of
 cvs src  ports are generated [by cvsup, pulling from freebsd.org]
 elsewhere, ctm-us...@freebsd.org led by Stephen M recently
 included: Subject: ctm for svn

csup will work fine with a local cvs tree and is much (much much)
faster than cvs for a sparse checkout.

Just run cvsupd locally (does require net/cvsup installed).

Chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJO5OY2AAoJELCEktHh68rEfMYIALDLqMQna7Vkphzk7qVoAIy9
N7iSNoSjS2mrXs841G1k5bxlfyEUN/whAuO3N7PxqXVZ5zTaoNycSSZUsGRNUK+p
oFOvy1R7Zsf791++eHUpGk7VYVZeGr5vGwMrM7MyrfLbDawRxp9DGVMJpElGyqBH
iMZxq2jZ/HsRxPi8wtuDHuewQX6f+MZg8yODsuio+aReGjwmjPZMTcStt14DfoEi
AajHbbdLqMoVEa02N46JcPjDlgWkQ9x0g9cbIxzMoLGIRI7PAmq2sEVNlNIIZYxA
vgNQq+qF7D10pg03WpwA54EglWaFhZDk3kYuk57oW94Iayr79PRdKst8wEQVe+4=
=ZGlO
-END PGP SIGNATURE-

___
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: WITHOUT_PROFILE=yes by default

[Chris Rees]

On 2 Dec 2011 15:57, Lyndon Nerenberg lyn...@orthanc.ca wrote:

 Max, I think a reasonable default is to continue building and shipping
profiled libraries.  This keeps FreeBSD consistent with every other UNIX
variant released in the last (at least) 30 years.

 If you personally find profiled library builds slow you down too much, a
one line addition to your /etc/src.conf solves the problem for you.

 Personally, I find building kernel modules to be intolerably slow, since
I tend to run static linked kernels.  I dealt with my preference by adding
one line to my /etc/src.conf, not by submitting a patch request to disable
the functionality in the builds.

 If you choose not to profile your code, that's entirely your choice.
Breaking this functionality for everyone else who *does* make the effort to
profile their code is a non-starter.

Nothing is being broken here, just a default being changed.

Users make up a greater proportion of our userbase than developers, so
sensible defaults for them are more appropriate, right?

Chris
___
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: WITHOUT_PROFILE=yes by default

[Chris Rees]

On 2 Dec 2011 16:54, Lyndon Nerenberg lyn...@orthanc.ca wrote:

 Using profiled libs and gprof to profile your code has been obsolete
 in FreeBSD on i386 and amd64 for over six years now.


 Funny, it still seems to work on my systems.



I wonder if you're either not reading these emails properly or deliberately
misrepresenting what people have said.

Obsolete does not mean it doesn't work.

Chris
___
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: WITHOUT_PROFILE=yes by default

[Chris Rees]

On 2 Dec 2011 17:07, Lyndon Nerenberg lyn...@orthanc.ca wrote:

 Obsolete does not mean it doesn't work.


 No, these days 'obsolete' seems to mean 'it does not have a sexy
Flash-driven web GUI.'

Straw man argument.  This is irrelevant.

 Profiling is a simple basic tool that makes it easy to quickly find code
execution hot-spots.  It's not dtrace, or any other plethora of tools that
do a more extensive job of profiling.  But it's also a tool that is
universally available to developers.  Or was ...

Still is if you choose it.

 If you don't like it, don't use it.  But don't turn that into an excuse
to remove the functionality from the rest of us.

Straw man argument.  Nothing has been removed.

 If you really think profiling is truly useless in this day and age, the
proposal should be to eradicate it from the system entirely.

Isn't this about user choice, and making sensible defaults?

No-one is removing anything.  Please stick to facts.

Chris
___
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: Adding disk firmware programming capability to camcontrol

[Chris Rees]

On 29 Oct 2011 00:38, Pegasus Mc Cleaft k...@mthelicon.com wrote:

  The linux hdparm program is so paranoid about this that you have to use
  extra arguments like --yes-really-destroy-my-disk-drive to do this.
 
 I concur. Loudly.  The ability to brick your hardware is just too
 large to not make people go through the I tell you three times
 dance.  It's not like people will do this often enough that the
 pain will be fatal.  And if it is, they ought to be bright enough to
 know how to automate the process.
 
 --lyndon

 Hi Lyndon and group,

I tend to disagree that there should be such argument antics
 employed to protect an operation such as this. Being root should be the
only
 protection needed (of course, that's only my opinion). I don’t want to
have
 to look up in a man page what magic token I need to add to prove to the
 utility that I understand the consequences of what I am about to do. I
 personally wouldn't mind a simple Are you sure? if the magic token is
not
 added on the command line, however.

To me, the only difference between borking a drive because of bad
 firmware and typing rm -rf * from root is about £40.  You still lose at
 least a day rebuilding/restoring everything.


You clearly haven't bought a hard drive recently.

Chris
___
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: Adding disk firmware programming capability to camcontrol

[Chris Rees]

On 4 Nov 2011 16:33, Pegasus Mc Cleaft k...@mthelicon.com wrote:

 
 To me, the only difference between borking a drive because of
  bad firmware and typing rm -rf * from root is about £40.  You still
  lose at least a day rebuilding/restoring everything.
 
 
 You clearly haven't bought a hard drive recently.
 
 Chris

 Laughs!

Yea, trust karma to insert my foot into my mouth when I open it to
 speak 8-)


Never mind ;)

I do take issue with this viewpoint however; in documentation this is the
difference between Caution (you may lose data) and Warning (you may break
your hardware).

Why should the software be inconsistent with the hardware? I think an
option *specifically for this task* would be useful as confirmation.

I'm really sorry for bikeshedding; the code and idea is excellent, but I
feel this issue is important!

Chris
___
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: 10.0-CUR r226986 ports (general)

[Chris Rees]

On 3 Nov 2011 06:11, Matthias Apitz g...@unixarea.de wrote:

 El día Wednesday, November 02, 2011 a las 08:36:07PM +0100, Matthias
Apitz escribió:

 
  Hello,
 
  I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November
  1st;
 
  The ports/audio/jack seems installing fine, but the shared lib
  libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it
  is mentioned in the list -L of the package; later ports/audio/arts and
  ports/x11/kde3 are missing the shared lib;

 It turns out that the problem is more general! A lot of ./configure
 scripts are detecting in 10-CUR that they can't or should not build
 shared libs; the problem is that the OS is detected now as

 host_os: freebsd10.0

 and the ./configure scripts have tests like this:

 ports/audio/jack/work/jack-audio-connection-kit-0.121.3:

 case $host_os in
 ...
 freebsd1*)
  dynamic_linker=no
;;
 ...

 And now? I'm cluesless now how we could solve this :-(


Searching the archives of both these lists would help you ;)

Chris
___
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 on 10.0-CURRENT: r226027 is incorrect fix

[Chris Rees]

On 8 Oct 2011 00:45, Stanislav Sedov s...@freebsd.org wrote:

 On Sat, 8 Oct 2011 02:03:37 +0300
 Mykola Dzham i...@levsha.me mentioned:

  Hi!
  r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
  incorrect: this commit breaks metaports building:
 
  # cd /usr/ports/print/teTeX  sudo make clean all
  ===  Cleaning for teTeX-3.0_5
  ===  License check disabled, port has not defined LICENSE
  ===  Found saved configuration for teTeX-3.0_2
  ===  Extracting for teTeX-3.0_5
  ===  Patching for teTeX-3.0_5
  ===  Configuring for teTeX-3.0_5
  find /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0 -type f \( -name
config.libpath -o  -name config.rpath -o -name configure -o -name libtool.m4
\)  -exec sed -i '' -e 's/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/'  -e
's/freebsd\[123\]\*)/SHOULDNOTMATCHANYTHING2)/' {} +
  find: /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0: No such file or
directory
  *** Error code 1
 
  Stop in /usr/ports/print/teTeX.
  *** Error code 1
 
  Stop in /usr/ports/print/teTeX.
 
  I think this commit should be reverted. Using UNAME_r is less
destructive work around
 

 Hi!

 I just committed the fix that checks if the ${WRKSRC} directory exists
firts.



Last I heard, portmgr explicitly disapproved of this fix-- have I missed
something??? Erwin specifically said not to do it.

Since when can anyone just commit stuff to bsd.port.mk, regardless of its
location?

This is a bad solution, please revert it or I will when I get back. We're
going to end up being asked to support it on ports@ otherwise.

Chris
___
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 on 10.0-CURRENT: r226027 is incorrect fix

[Chris Rees]

On 8 Oct 2011 00:45, Stanislav Sedov s...@freebsd.org wrote:

 On Sat, 8 Oct 2011 02:03:37 +0300
 Mykola Dzham i...@levsha.me mentioned:

  Hi!
  r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
  incorrect: this commit breaks metaports building:
 
  # cd /usr/ports/print/teTeX  sudo make clean all
  ===  Cleaning for teTeX-3.0_5
  ===  License check disabled, port has not defined LICENSE
  ===  Found saved configuration for teTeX-3.0_2
  ===  Extracting for teTeX-3.0_5
  ===  Patching for teTeX-3.0_5
  ===  Configuring for teTeX-3.0_5
  find /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0 -type f \( -name
config.libpath -o  -name config.rpath -o -name configure -o -name libtool.m4
\)  -exec sed -i '' -e 's/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/'  -e
's/freebsd\[123\]\*)/SHOULDNOTMATCHANYTHING2)/' {} +
  find: /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0: No such file or
directory
  *** Error code 1
 
  Stop in /usr/ports/print/teTeX.
  *** Error code 1
 
  Stop in /usr/ports/print/teTeX.
 
  I think this commit should be reverted. Using UNAME_r is less
destructive work around
 

 Hi!

 I just committed the fix that checks if the ${WRKSRC} directory exists
firts.



Last I heard, portmgr explicitly disapproved of this fix-- have I missed
something??? Erwin specifically said not to do it.

Since when can anyone just commit stuff to bsd.port.mk, regardless of its
location?

This is a bad solution, please revert it or I will when I get back. We're
going to end up being asked to support it on ports@ otherwise.

Chris
___
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: cvs commit: ports/security/cyrus-sasl2 Makefile ports/security/cyrus-sasl2/files patch-plugins::gssapi.c

[Chris Rees]

On 8 Oct 2011 20:34, Michael Butler i...@protected-networks.net wrote:

 On 10/07/11 19:48, Doug Barton wrote:

 In case anyone wants to take this on, this port fails to install on 10.0
 because it uses its own version of libtool. I took a quick look but
 there wasn't a solution obvious enough for me. :)


 This appears to have been fixed by the (reversion of a) change to
bsd.port.mk in SVN r226162 - I still used the UNAME_r kludge, however,


r226162 has been reverted for now, so your fix is still relevant.

Chris
___
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: FreeBSD 9.0-BETA3 Available...

[Chris Rees]

What is your Wiki name?
On 4 Oct 2011 16:26, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Mon, Oct 3, 2011 at 7:50 PM, Arnaud Lacombe lacom...@gmail.com wrote:
 Hi,

 On Wed, Sep 28, 2011 at 9:42 PM, Ken Smith kensm...@buffalo.edu wrote:

 The third BETA build of the 9.0-RELEASE release cycle is now
 available.  Since this is the first release of a brand new branch
 I cross-post the announcements on both -current and -stable.  But
 just so you know most of the developers active in head pay more
 attention to the -current mailing list.  If you notice problems you
 can report them through the normal Gnats PR system or on the -current
 mailing list.

 The 9.0-RELEASE cycle will be tracked here:

http://wiki.freebsd.org/Releng/9.0TODO

 could you please update that page ? It's wayy out of date...

 The page is immutable, so I guess a lambda user cannot edit it.

 Could you please give me the credential to update it ?

 Providing an out-of-date status update page in a release is really
 amateurish; the only real use of that page being during the release
 process...

 Thanks,
 - Arnaud
 ___
 freebsd-sta...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-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: HEADS UP: ports/ and 10.0-CURRENT

[Chris Rees]

On 27 September 2011 10:18, Anton Shterenlikht me...@bristol.ac.uk wrote:
 On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote:
 On 09/27/11 08:35, h h wrote:
 Kevin Obermankob6...@gmail.com  writes:
 
 On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovetta...@freebsd.org  wrote:
 
 With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be
 expected, ports/ is going to be essentially unusable for a while.
 
 The issue stems from configure scripts (to choose something completely
 at random) assuming that FreeBSD would never jump to a double-digit
 major version number, and as such, various regexps for freebsd1* (ie:
 FreeBSD 1.1.x) are now matching freebsd10.
 [...]
 
 aDe,
 
 Could an entry to this effect be added to UPDATING (with a matching
 entry when ports/ is unbroken).
 
 Also mention a workaround, e.g.
 
    $ export UNAME_r='9.9-BLAH'


 Now I understand why some OS vendors have choosen the latin 10 'X' for
 their tenth version of their operating system ...

 At least there will be a long rest after
 the move to 10 is complete.. until FreeBSD 100.



I'm afraid not;

freebsd2*)

We'll be just as screwed at 20.

Hopefully we can fix that at the same time.

Chris
___
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: 9.0 beta2 the new bsdinstaller

[Chris Rees]

On 25 September 2011 14:01, Fbsd8 fb...@a1poweruser.com wrote:
 deeptec...@gmail.com wrote:

 Fbsd8 wrote:

 6. At the Complete screen when the reboot option is selected the
 cd/dvd drive should automatically open so the install media can be
 removed just like sysinstall does. If disc1.iso or dvd.iso was installed
 to memstick and used to boot from to install the system, then a message
 screen should pop out saying the memstick has to be removed now before
 the reboot starts. Don't let the reboot occur until the memstick is
 removed.

 Do NOT alter! More often than not,
 (1) you keep floppies, optical discs, and memory sticks in your
 computer without intending to boot from them, and
 (2) you'll want to use your BIOS's boot-once functionality (press a
 specific keyboard button to bring up the media choser menu for that
 boot; otherwise boot from the hard drives) whenever you do want to
 boot from floppies, optical discs, or memory sticks.



 You have missed the subject completely of what #6 is addressing. This has
 nothing to do with telling the pc hardware which media to boot from at power
 up time like you suggest in your post.

 This has to do with the logic of the new bsdinstall process and the
 differences between bsdinstall and sysinstall in the way the install media
 is removed from the pc before it reboots as part of the normal install
 process.



Surely a reminder rather than an obstinate refusal to continue is appropriate?

Example:

Please remove your install media so that it is not loaded on reboot,
and press any key to continue

Chris
___
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: 9.0 bata2 keymap

[Chris Rees]

On 17 September 2011 22:42, Fbsd8 fb...@a1poweruser.com wrote:
 Chris Rees wrote:

 On 17 Sep 2011 17:25, Fbsd8 fb...@a1poweruser.com wrote:

 Nathan Whitehorn wrote:

 On 09/15/11 14:57, Fbsd8 wrote:
 Out of the 9 USA maps only us.iso.acc.kbd worked somewhat.
 The keyboard 9 key block above the arrow keys don't function.
 Issuing the man cmd_name command doe's display the man page,
 but the {Page up, Page down keys } don't work.
 Also when using the ee edit command the {delete, Page up, Page down
 keys } don't work. This does not happen in any of the previous

 releases.

 Further more, localization of the keyboard should not be forced on
 the
 user during the install process. This BSDinstall option should be
 disabled or removed.

 You can press Cancel there, which will cancel keymap selection and

 keep the default. The utility being invoked is just kbdmap(1), and any
 changes to it need to go there.

 -Nathan


 .. maybe name that button skip then?

 The button is provided by kbdmap, as is the entire screen. We could add

 an installer mode to kbdmap that names it skip instead of cancel, of
 course. I'm traveling for another 2 weeks and won't have time to do
 that,

 however.

 -Nathan

 Nathan

 Its good to be talking directly with the bsdinstall author.

 Changing the cancel button in the kbdmap command to skip, does not
 address

 the problem, which is the lack of knowledge of the standard bsdinstall
 user.
 I've been using Freebsd since 4.0 and never used the kbdmap command or for
 that matter even knew it existed.

 Wait, are you suggesting that everyone on Earth can make do with the
 standard keyboard layout until they learn rc.conf syntax?

 I would strongly object if localisation of the keyboard were not forced
 on
 the user; we don't all use pc105-us, and the ability to use the keyboard
 properly early on is kinda helpful.

 Chris


 You would help yourself a great deal if you read the complete post before
 jumping in. The rest of the post (ie: the part you neglected to include in
 your post) clearly describes what I am suggesting.


I had read the rest of your post, and found it rather difficult to
follow. The fact remains that every other installer I have ever used
gives the user the choice of keymap, so I don't really understand your
problem.

If you're not suggesting removing localisation from bsdinstall, then
please accept my apologies.

Chris
___
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: Very imprecise watchdogd(8) timeout

[Chris Rees]

On 18 Sep 2011 20:31, Arnaud Lacombe lacom...@gmail.com wrote:

 Hi,

 On Sat, Sep 17, 2011 at 2:17 AM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:
  In message 
cacqu3mvf5mwqec+s9vkk4mljenmos9q_bjwkbyefzabfjo6...@mail.gmail.com
  , Arnaud Lacombe writes:
 
 I do not really care actually, but the manpage is wrong, and the code
 needlessly complicated.
 
  As I said: Feel free to improve.
 
 How can I expect anything to get through, when I cannot even get an
 obvious use-after-free in the ipfw code fixed after months ? Or when
 I've been waiting to play with Warner's external compiler support
 patch for months ? Or when I can not get a build fix for 7-STABLE to
 get committed ? [and the list goes on...]

 ?

Hey Arnaud,

I'm sorry to hear you're having trouble getting your fixes included. If you
provide some PR numbers I'll gladly try to get them in as quickly as
possible.

Chris
___
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: cvsup broken on amd64?

[Chris Rees]

On 9 September 2011 06:33, Oliver Lehmann lehm...@ans-netz.de wrote:

 Mike Tancsa m...@sentex.net wrote:

 Just curious as to why you need cvsup and not instead use csup that is
 in the base ?

 I got used to it in the past 12 years? But this is not realy the question.
 If it is BROKEN it should be marked as BROKEN or there should be a
 statement that it will not work with FreeBSD 9 on at least amd64 or we
 will have other users complaining about the same at least when
 9.0 RELEASE is out - right?

The cvsup port is normally used now only for cvsupd, for which there
is no csupd analog. As far as I know, and perhaps mux (CC'd) could
confirm every feature present in cvsup is present in csup-- and it's a
fair amount faster too.

Of course, cvsup could probably do with fixing, but for now csup is
literally a drop-in replacement; it'll read all your supfiles too.

Chris
___
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: http://www.freebsd.org/marketing/os-comparison.html

[Chris Rees]

On 27 August 2011 20:32, Garrett Cooper yaneg...@gmail.com wrote:
 On Sat, Aug 27, 2011 at 12:13 PM, Hartmann, O.
 ohart...@zedat.fu-berlin.de wrote:
 This website should be brushed up or taken offline!
 It seems full of vintage stuff from glory days.

 http://www.freebsd.org/marketing/os-comparison.html

 Agreed. Things have changed quite a bit in the last decade.

It reads rather FUD-like too.

Chris
___
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: http://www.freebsd.org/marketing/os-comparison.html

[Chris Rees]

On 28 August 2011 19:47, Matthias Apitz g...@unixarea.de wrote:
 El día Sunday, August 28, 2011 a las 07:27:49PM +0100, Chris Rees escribió:

 On 27 August 2011 20:32, Garrett Cooper yaneg...@gmail.com wrote:
  On Sat, Aug 27, 2011 at 12:13 PM, Hartmann, O.
  ohart...@zedat.fu-berlin.de wrote:
  This website should be brushed up or taken offline!
  It seems full of vintage stuff from glory days.
 
  http://www.freebsd.org/marketing/os-comparison.html
 
  Agreed. Things have changed quite a bit in the last decade.

 It reads rather FUD-like too.

 It's a pitty that the comments until now are only general like full of
 vintage stuff, agreed, rather FUD, but without concrete critics or
 proposals of changes of wrong data.


No, it's just hopelessly out of date and needs removal/total
rewriting. I find it embarassing to have it there to be honest with
its current tone.

Chris
___
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: For about a week I've been trying to build a release that breaks at docproj. Just low priority break information.

[Chris Rees]

On 13 August 2011 16:37, eculp ec...@encontacto.net wrote:
 I've been building a release about once a week on current.  The last
 successful build was on august 8 but don't know when this started but in the
 last few days.

 I am building on
 # uname -a
 FreeBSD Home.EnContacto.net 9.0-BETA1 FreeBSD 9.0-BETA1 #16: Sat Aug 13
 05:09:17 CDT 2011
 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  amd64

 All builds include ports kernel updated ports, etc.  I build it with
 generate-release.sh script below.

 sh generate-release.sh head /local3/release

 The results that I get follow:

 ===   Generating temporary packing list
 ===  Checking if textproc/docproj already installed
 ===   docproj-1.17_4 is already installed
      You may wish to ``make deinstall'' and install this port again
      by ``make reinstall'' to upgrade it properly.
      If you really wish to overwrite the old port of textproc/docproj
      without deleting it first, set the variable FORCE_PKG_REGISTER
      in your environment or the make install command line.
 *** Error code 1

 Stop in /usr/ports/textproc/docproj.
 Home.EnContacto.net
 /usr/src/release #
 Home.EnContacto.net
 /usr/src/release # portmaster textproc/docproj

 === Port directory: /usr/ports/textproc/docproj

        === This port is marked IGNORE
        === user must set WITH_JADETEX variable to 'yes' or 'no'
  ^

You need to set WITH_JADETEX in /etc/make.conf.

Chris
___
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] replacing /boot/kernel.old with a unique directory name

[Chris Rees]

On 13 August 2011 20:51, Alexander Best arun...@freebsd.org wrote:
 hi there,

 i just had the following idea: how about instead of copying the current kernel
 to /boot/kernel.old and then installing the new one under /boot/kernel as the
 results of target installkernel, we create a unique directory name for the old
 kernel?

 something like /boot/kernel-r${revision}-${/dev/random}?

 that would let people not only boot the previous kernel, but all kernels that
 have been replaced by target installkernel. this would make tracking issues,
 which have been introduced by a certain commit much easier, imho.

 i don't think implementing this logic would be that difficult. the only 
 problem
 i see is with ${/dev/random} in the case where people are running a kernel
 without /dev/{u}random support.

 cheers.
 alex

mktemp?

Chris
___
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: [clang] OpenOffice does not work with clang-compiled libgcc_s.so.1

[Chris Rees]

On 27 July 2011 19:12, Dimitry Andric d...@freebsd.org wrote:
 On 2011-07-27 12:19, Alexey Shuvaev wrote:
 ...

 So, if I compile the whole world (and kernel) with clang, soffice.bin
 dumps core. If I recompile the world with gcc and replace
 /lib/libgcc_s.so.1
 with the new one, OpenOffice works fine again.

 Hmm, OpenOffice is a rather unwieldy testcase, not in the least because
 it takes ages and many gigabytes to build. :(  Did you or anyone else
 ever find a smaller testcase?

CCing office@, maintainers -- could be interested and may give answers.

FWIW, LibreOffice is probably a better target for clang -- seems to be
The Future.

Chris
___
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: [clang] OpenOffice does not work with clang-compiled libgcc_s.so.1

[Chris Rees]

On 27 July 2011 19:18, Chris Rees cr...@freebsd.org wrote:
 On 27 July 2011 19:12, Dimitry Andric d...@freebsd.org wrote:
 On 2011-07-27 12:19, Alexey Shuvaev wrote:
 ...

 So, if I compile the whole world (and kernel) with clang, soffice.bin
 dumps core. If I recompile the world with gcc and replace
 /lib/libgcc_s.so.1
 with the new one, OpenOffice works fine again.

 Hmm, OpenOffice is a rather unwieldy testcase, not in the least because
 it takes ages and many gigabytes to build. :(  Did you or anyone else
 ever find a smaller testcase?

 CCing office@, maintainers -- could be interested and may give answers.

 FWIW, LibreOffice is probably a better target for clang -- seems to be
 The Future.

By the way, I didn't mean that OOo is 'deprecated' at all; maho is
still working on it.

Chris
___
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/158179: some packages do not fully honor -P dir option in pkg_add(1)

[Chris Rees]

On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
wrote:

 On 07/16/2011 04:26 AM, Stefan Bethke wrote:

 Am 16.07.2011 um 04:43 schrieb Stephen Montgomery-Smith:

 I was looking through the source code of pkg_add.  Personally I don't
see how the -P or -p option could be made to work with pkg_add. Many of
the installation commands involve scripts which have ${PREFIX} hard coded
into them.  ${PREFIX} is often hard coded when trhe package is created by
the port.  In my opinion, the options -p and -P should be removed from
pkg_add.

 Either that, or provide the port a way to access @cwd in any scripts
it installs.  But this would require a major overhaul of the whole ports
system, and probably much of the software it installs as well.

 Am I missing something?


 Yes.  Not honoring the prefix is a bug in the port.  If you do need to do
prefix-specific things during install, use pkg-install, see
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html

 I suspect that many ports are not well tested outside of /usr/local,
but the infrastructure is there and available.


 You are correct, this needs to be done on a port by port basis.  In some
ports this is going to be a big job, because in some cases the /usr/local
is hard coded into certain binaries.

 For example, suppose the C source code contains something like:
 char applications_dir = /usr/local/share/applications;
 and this is filled in by the ./configure script.

 How is that handled?


It's not.

Remember what a package is, literally the files from the plist tarred with
some magic +FILEs and the pkg-*install files- if paths are hardcoded in
objects that's how it'll be installed.

Don't touch the -p option! It's only useful for um someone help
here?

Chris
___
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/158179: some packages do not fully honor -P dir option in pkg_add(1)

[Chris Rees]

On 16 Jul 2011 17:04, Stephen Montgomery-Smith step...@missouri.edu
wrote:

 On 07/16/2011 10:53 AM, Chris Rees wrote:


 On 16 Jul 2011 16:38, Stephen Montgomery-Smith step...@missouri.edu
 mailto:step...@missouri.edu wrote:
   For example, suppose the C source code contains something like:
   char applications_dir = /usr/local/share/applications;
   and this is filled in by the ./configure script.
  
   How is that handled?
  

 It's not.

 Remember what a package is, literally the files from the plist tarred
 with some magic +FILEs and the pkg-*install files- if paths are
 hardcoded in objects that's how it'll be installed.


 What if some of the installation programs are binaries, and /usr/local
is hard coded into installation binaries or scripts provided by the software
itself.

Sorry, poor wording on my part.

If it was compiled as prefix=/usr/local, that's how it'll be installed,
regardless of your -p argument.

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