Re: New Boot-Loader

[Mehmet Erol Sanliturk]

On Mon, Mar 28, 2011 at 1:22 AM, Devin Teske dte...@vicor.com wrote:


 On Mar 27, 2011, at 9:53 PM, Super Bisquit wrote:

  And what if I need to boot into single user mode?

 I'll forgive the top-post, and I'll even forgive that you missed the below
 NOTE: The final release will have a single-user mode option.

 Here it is with single-user mode option: twitpic.com/4e6gu1
 --
 Devin


 
  On Mon, Mar 28, 2011 at 12:48 AM, Devin Teske dte...@vicor.com wrote:
  Hi fellow hackers,
 
  I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel
 that the existing options in the boot-loader menu today can be whittled down
 significantly with a stateful menu system rather than a single-action item
 menu system.
 
  In designing the new menu, I'd like to get your opinions. From old:
 
 FreeBSD 8.1-RELEASE: twitpic.com/4e485w
 
  to new:
 
 Replacement Boot-Loader: twitpic.com/4e46ol
 
  NOTE: The final release will have a single-user mode option.
 
  The new menu allows for more flexibility as selecting options 2 (Boot
 Verbose) or 3 (ACPI Support) independently toggles the status, updates
 the menu item, and redisplays the menu -- ever-waiting until the user
 ultimately presses ENTER, 1, or escapes to the prompt and types boot.
 Thus, one could potentially launch single-user mode with verbosity on and
 ACPI disabled (if one so desired).
 


...

New menu is really good .

One feature ( which is important for response ability ) is to increase down
counter starting from at least 255 as default .

This will not change anything toward bad because a few seconds later a
prompt will appear and the computer will start to wait user response for
logging . If the user will use an automatic login , it is obvious that
he/she is knowing how to modify that counter to satisfy his/her needs .
Instead of considering exceptions , please consider generally less
experienced to modify that counter and/or having obstacles to respond
immediately .

Personally mostly I am becoming able to boot such menus after a few hard
resets of power of the computer .
My personal attitude toward this counter is a strong hate . After every
operating system install , the first task I  am doing is to disable that
counter completely or increase it to at least 1000 .

Default boot mode is not always the best and please assume that every one
will not be able to respond immediately due to so many possibilities of
reasons to cause a late response .


Thank you very much .

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

Re: New Boot-Loader

[Paul Schenkeveld]

On Sun, Mar 27, 2011 at 09:48:03PM -0700, Devin Teske wrote:
 Hi fellow hackers,
 
 I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel 
 that the existing options in the boot-loader menu today can be whittled down 
 significantly with a stateful menu system rather than a single-action item 
 menu system.
 
 In designing the new menu, I'd like to get your opinions. From old:
 
   FreeBSD 8.1-RELEASE: twitpic.com/4e485w
 
 to new:
 
   Replacement Boot-Loader: twitpic.com/4e46ol

Very nice!

Could you consider changing the number options to letters: v=verbose,
a=acpi, s=single ...

Having many (hundreds) of machines to manage it's confusing to need 6
for boot prompt on older versions and 5 on the newer where 6 on the
newer reboots.  Moving from digits to letters with digits resulting in
either a beep or a pause saves a lot of frustration for sysadmins
already annoyed by the ever increasing POST delay rapidly pressing
ENTER ENTER 6 when the boot0 menu appears.

Thanks for your work!

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

Re: New Boot-Loader

[Zhihao Yuan]

On Mon, Mar 28, 2011 at 2:55 AM, Paul Schenkeveld free...@psconsult.nl wrote:
 On Sun, Mar 27, 2011 at 09:48:03PM -0700, Devin Teske wrote:
 Hi fellow hackers,

 I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel 
 that the existing options in the boot-loader menu today can be whittled down 
 significantly with a stateful menu system rather than a single-action item 
 menu system.

 In designing the new menu, I'd like to get your opinions. From old:

       FreeBSD 8.1-RELEASE: twitpic.com/4e485w

 to new:

       Replacement Boot-Loader: twitpic.com/4e46ol

 Very nice!

 Could you consider changing the number options to letters: v=verbose,
 a=acpi, s=single ...

I agree. Vim-like actions make sense here.
And also, I want command completion...


 Having many (hundreds) of machines to manage it's confusing to need 6
 for boot prompt on older versions and 5 on the newer where 6 on the
 newer reboots.  Moving from digits to letters with digits resulting in
 either a beep or a pause saves a lot of frustration for sysadmins
 already annoyed by the ever increasing POST delay rapidly pressing
 ENTER ENTER 6 when the boot0 menu appears.

 Thanks for your work!

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


-- 
Zhihao Yuan
The best way to predict the future is to invent it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Unsigned wchar_t

[Andrew Turner]

On Sun, 27 Mar 2011 22:07:30 +0200
Stefan Farfeleder ste...@fafoe.narf.at wrote:

 On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote:
  Along with this WCHAR_MIN and WCHAR_MAX are defined both in
  wchar.h and machine/_stdint.h. I would like to remove the copy
  from wchar.h and add an include to machine/_stdint.h.
  
  Would there be any problems with either of these or is there a
  better place to put the __wchar_t typedef and define WCHAR_MIN and
  WCHAR_MAX?
 
 The C standard specifies that both wchar.h and stdint.h shall
 define WCHAR_MIN and WCHAR_MAX. You cannot simply include
 machine/_stdint.h from wchar.h because the former contains a lot
 of other macros.
I thought that might be the case. I could create machine/_wchar.h for
the defines unless there is a better place for them.

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

Re: New Boot-Loader

[Alexander Best]

On Sun Mar 27 11, Warner Losh wrote:
 
 
 On Mar 27, 2011, at 10:48 PM, Devin Teske wrote:
  Replacement Boot-Loader: twitpic.com/4e46ol
  
  NOTE: The final release will have a single-user mode option.
 
 This looks really cool.  Nice to see a fresh look for the boot loader...

sorry if we have different opinions on this matter, but i don't quite see
the fresh look.

imo a modern boot loader looks like this

http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png

or this

http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png

... and not something made out of ascii chars like it's 1981. ;)

 
  The new menu allows for more flexibility as selecting options 2 (Boot 
  Verbose) or 3 (ACPI Support) independently toggles the status, updates 
  the menu item, and redisplays the menu -- ever-waiting until the user 
  ultimately presses ENTER, 1, or escapes to the prompt and types boot. 
  Thus, one could potentially launch single-user mode with verbosity on and 
  ACPI disabled (if one so desired).
  
  In addition, I really tried to capture the essence of the new logo (spent 
  months off-and-on using different conversion programs with different 
  inputs). In the end, I found text-image.com produced the best result. I 
  used the official freebsd.org/logo.html Standard Logo (black and white), 
  cropped (to 122x123) and converted to jpeg with white background. I used an 
  Image Width of 45 in their Convert into ASCII program available here: 
  text-image.com/convert/ascii.html
 
 This looks cool...
 
  I would be distributing this as an installable package (perhaps in the 
  ports tree if it gains popularity).
 
 That would be nice...
 
 Warner
 
  -- 
  Cheers,
  Devin Teske
  
  
  - LEGAL DISCLAIMER -
  This message  contains confidential  and proprietary  information
  of the sender,  and is intended only for the person(s) to whom it
  is addressed. Any use, distribution, copying or disclosure by any
  other person  is strictly prohibited.  If you have  received this
  message in error,  please notify  the e-mail sender  immediately,
  and delete the original message without making a copy.
  
  - FUN STUFF -
  -BEGIN GEEK CODE BLOCK-
  Version 3.12
  GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ 
  E-
  W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ 
  DI+
  D+(++) G++ e h r+++ z+++
  --END GEEK CODE BLOCK--
  http://www.geekcode.com/
  
  - END TRANSMISSION -
  
  ___
  freebsd-hackers@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
  To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
  
  
 

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

Re: Prebind from OpenBSD

[Alexander Leidinger]

Quoting Jesse Smith jessefrgsm...@yahoo.ca (from Sun, 27 Mar 2011  
17:29:20 -0300):



Thanks very much for the reply. I had thought this was a project/port
that was in progress, rather than something waiting on research. Do you
know if that's also the case with other projects on the Ideas list? A
lot of them don't have many details or contact information associated
with them. I'm especially interested in the OpenBSD xlint port.


Here's what I told a student who wants to participate in the GSoC  
about the OpenBSD lint port entry:

---snip---
The project is about having a look at what OpenBSD did to their lint.
So first analyze what we have, then analyze what they have, and then
see if stuff they have but we haven't can be ported. This assumes that
there is a common ancestor to both lints, and that the code didn't
diverge too much so that we do not have an either this or that
situation.

IF the code diverged to much or if there is no common ancestor, there
is nothing to do regarding this specific project (it would be a new
project to improve our lint).

I do not know the code of both lints, so I do not know much
improvements there are which we don't have, and how much work it is to
port this over. In the worst case there is not enough or too much to do
this as a GSoC project. Should be easy to determine by reading the
history of lint on both version control systems to see if there is a
common starting point, and if yes to see how much they derived from
there.

Regarding the lint project itself... I (= personal opinion, not an
official word from FreeBSD) do not think this is a project which would
gain a lot of interest (= highly rated during the GSoC evaluation). If
you want to send in a proposal for this (after researching if it is
feasible, see above), I suggest to send in more than one proposal. This
should improve your change to be chosen. In the last GSoCs we had
students which send in several proposals, some of the proposals didn't
gain enough interest, but another one from the same person was chosen.
Seeing multiple proposals from the same person gave us a hint about his
technical knowledge (sane expectations in the proposals or not).
---snip---

Bye,
Alexander.

--
Snakes.  Why did it have to be snakes?

http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: New Boot-Loader

[Andriy Gapon]

on 28/03/2011 14:08 Alexander Best said the following:
 sorry if we have different opinions on this matter, but i don't quite see
 the fresh look.
 
 imo a modern boot loader looks like this
 
 http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png
 
 or this
 
 http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png
 
 ... and not something made out of ascii chars like it's 1981. ;)

There is/was a different project for that too:
http://wiki.freebsd.org/OliverFromme/BootLoader

Please note that graphical loaders are not very serial console friendly ;-)

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

Re: New Boot-Loader

[Andriy Gapon]

Would also be cool to have an option to boot something else (like e.g.
memtest86).  Maybe a special directory with loadable binaries and a special menu
entry to select one of them.

Probably even better to have a mechanism for pluggable menu entries like a 
special
directory that would have .4th files each of which would represent one extra 
menu
option.  So instead of hacking system .4th files, one could easily extend main
menu with custom entries.

Just a dream...
-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Keeping /etc/localtime up-to-date

[David Wolfskill]

On Sun, Mar 27, 2011 at 09:38:29PM -0400, Ed Maste wrote:
 On Sun, Mar 27, 2011 at 03:27:32PM -0700, David Wolfskill wrote:
 
  There are other ways to do it, of course -- e.g., the first time the
  utility is run, it could actually ask, but then cache the information in
  some place so it could look there first (and if it finds a cached
  answer, avoid asking again unless it's told to ignore the cache -- as
  might be reasonable if the machine is moved to a different time zone.
 
 That's what tzsetup does in HEAD - the name of the selected timezone file
 is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy in an
 updated file:
 
   -r  Reinstall the zoneinfo file installed last time. The
   name is obtained from /var/db/zoneinfo.
 
 It looks like this hasn't been MFC'd, although I'm not sure why.  The
 change came in from svn rev 198267 by edwin (CC'd).

Thanks for pointing that out -- I had failed to consider that the
behavior might have changed in head.

It does seem to me that an MFC would be useful and harmless, based only
on the above information.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpTOjYNMzeLM.pgp
Description: PGP signature

Re: New Boot-Loader

[John Baldwin]

On Monday, March 28, 2011 12:48:03 am Devin Teske wrote:
 Hi fellow hackers,
 
 I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel 
that the existing options in the boot-loader menu today can be whittled down 
significantly with a stateful menu system rather than a single-action item 
menu system.

Are you reimplementing loader from scratch or just hacking on the 4th scripts 
to display the menu, etc.?

 In designing the new menu, I'd like to get your opinions. From old:
 
   FreeBSD 8.1-RELEASE: twitpic.com/4e485w
 
 to new:
 
   Replacement Boot-Loader: twitpic.com/4e46ol
 
 NOTE: The final release will have a single-user mode option.
 
 The new menu allows for more flexibility as selecting options 2 (Boot 
Verbose) or 3 (ACPI Support) independently toggles the status, updates the 
menu item, and redisplays the menu -- ever-waiting until the user ultimately 
presses ENTER, 1, or escapes to the prompt and types boot. Thus, one could 
potentially launch single-user mode with verbosity on and ACPI disabled (if 
one so desired).

This is good.  I think DFly already does this and I had a low priority item on 
my todo list to eventually implement this in the current menu myself.

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

Re: New Boot-Loader

[Warner Losh]

On Mar 28, 2011, at 5:08 AM, Alexander Best wrote:

 On Sun Mar 27 11, Warner Losh wrote:
 
 
 On Mar 27, 2011, at 10:48 PM, Devin Teske wrote:
 Replacement Boot-Loader: twitpic.com/4e46ol
 
 NOTE: The final release will have a single-user mode option.
 
 This looks really cool.  Nice to see a fresh look for the boot loader...
 
 sorry if we have different opinions on this matter, but i don't quite see
 the fresh look.
 
 imo a modern boot loader looks like this
 
 http://www.dailycupoftech.com/wp-content/uploads/2006/08/ubuntu01.png
 
 or this
 
 http://images.linuxscreenshots.com/distro/opensuse/11.3/h400/01_boot_menu.png
 
 ... and not something made out of ascii chars like it's 1981. ;)

Fresh here means not looking exactly like it has since 1995...  Where we wind 
up might not be this prototype, but it should spur discussions.

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

Re: New Boot-Loader

[Devin Teske]

On Mar 28, 2011, at 7:03 AM, John Baldwin wrote:

 On Monday, March 28, 2011 12:48:03 am Devin Teske wrote:
 Hi fellow hackers,
 
 I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel
 that the existing options in the boot-loader menu today can be whittled down
 significantly with a stateful menu system rather than a single-action item
 menu system.
 
 Are you reimplementing loader from scratch or just hacking on the 4th scripts 
 to display the menu, etc.?

The menu is implemented as a series of 4th modules. Here's an earlier version 
of the code which I've been using on my LiveDistro boot disc:

druidbsd.cvs.sourceforge.net/viewvc/druidbsd/druidbsd/druidbsd/mdroot/boot/


 
 In designing the new menu, I'd like to get your opinions. From old:
 
  FreeBSD 8.1-RELEASE: twitpic.com/4e485w
 
 to new:
 
  Replacement Boot-Loader: twitpic.com/4e46ol
 
 NOTE: The final release will have a single-user mode option.
 
 The new menu allows for more flexibility as selecting options 2 (Boot 
 Verbose) or 3 (ACPI Support) independently toggles the status, updates the
 menu item, and redisplays the menu -- ever-waiting until the user ultimately
 presses ENTER, 1, or escapes to the prompt and types boot. Thus, one 
 could
 potentially launch single-user mode with verbosity on and ACPI disabled (if
 one so desired).
 
 This is good.  I think DFly already does this and I had a low priority item 
 on 
 my todo list to eventually implement this in the current menu myself.
 

I think you'll like the Forth code that I've written. I strived to keep it 
clean and modular. IMHO I feel that it's really easy to change/enhance/extend 
based on the menu mechanics as seen in menu.rc, and 
include/menu-commands.4th.


 -- 
 John Baldwin

-- 
Cheers,
Devin Teske


- LEGAL DISCLAIMER -
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

- FUN STUFF -
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E-
W+++ N? o? K? w@ O M++$ V- PS+++ PE@ Y+ PGP- t(+) 5? X(+) R(-) tv+ b+++ DI+
D+(++) G++ e h r+++ z+++
--END GEEK CODE BLOCK--
http://www.geekcode.com/

- END TRANSMISSION -

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

Re: New Boot-Loader

[Damien Fleuriot]

On 3/28/11 6:48 AM, Devin Teske wrote:
 Hi fellow hackers,
 
 I'm designing an open-sourced replacement boot-loader for FreeBSD. I feel 
 that the existing options in the boot-loader menu today can be whittled down 
 significantly with a stateful menu system rather than a single-action item 
 menu system.
 
 In designing the new menu, I'd like to get your opinions. From old:
 
   FreeBSD 8.1-RELEASE: twitpic.com/4e485w
 
 to new:
 
   Replacement Boot-Loader: twitpic.com/4e46ol
 
 NOTE: The final release will have a single-user mode option.
 
 The new menu allows for more flexibility as selecting options 2 (Boot 
 Verbose) or 3 (ACPI Support) independently toggles the status, updates the 
 menu item, and redisplays the menu -- ever-waiting until the user ultimately 
 presses ENTER, 1, or escapes to the prompt and types boot. Thus, one 
 could potentially launch single-user mode with verbosity on and ACPI disabled 
 (if one so desired).
 
 In addition, I really tried to capture the essence of the new logo (spent 
 months off-and-on using different conversion programs with different inputs). 
 In the end, I found text-image.com produced the best result. I used the 
 official freebsd.org/logo.html Standard Logo (black and white), cropped (to 
 122x123) and converted to jpeg with white background. I used an Image Width 
 of 45 in their Convert into ASCII program available here: 
 text-image.com/convert/ascii.html
 
 I would be distributing this as an installable package (perhaps in the ports 
 tree if it gains popularity).


I like the new looks, thanks for your efforts :)

I also like Paul's idea of tying the actions (single, verbose) to
letters instead of numbers.


As for the comment about this new look not being modern enough, to be
honest I for one could care less.
I'm using servers, when I see this loader this usually means there's a
problem or I'm anticipating one.
So it looking fancy isn't really my top priority, I'd rather it be
functional and well thought-out.

Thanks again for your work Devin :)


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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Andriy Gapon]

on 25/03/2011 12:11 Baptiste Daroussin said the following:
 Hi all,
 
 miwi@ launched the new thing called Experimental Call For Testing,
 it's our turn :)
 
 Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge
 contributor) have been working since the end of the last GSoC on a
 rewrite of pkg_install.
 
 pkgng is a binary package manager written from scratch for FreeBSD.
 
 After a long period of technology testing, (json, tinycdb, bdb, etc)
 and we now have achieved to implement the basic functionnality. We
 would greatly approciate to have some feedback, wider testing,
 patching, documenting etc, before implementing the higher level
 features.
 
 pkgng is built on top of a new libpkg, which allow to deal with the database 
 of
 installed packages, to deal with remote repositories, manage packages:
 creation, installation gathering informations, registering new ports.
 
 features supported are or will be :
 
 - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486)
 which allow  to have a bsd.port.mk which deal with both pkg_install
 and pkgng. (done in alpha)
 
 - the register command can analyse elf files when registering a new port to
 discover forgotten dependencies if necessary. (done in alpha using libelf)
 
 - the register command has two mode available : when dealing with old
 fashion ports it just registers the package, in new mode it does
 everything that would
 have been done by pkg add when installing the package : should display
 messages,  execute post-install, execute @exec etc. (old fashion done
 in the alpha)
 
 - pkg add supports two mode : the old fashion one (no real upgrade
 support) and  new one: upgrade scripts supported. (old fashion in the
 alpha)
 
 - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL,
 +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion
 scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't
 supported in the alpha)
 
 - new +MANIFEST (plist-like format) with new metadatas : options, arch, os
 version, etc. (done in the alpha)
 
 - pkgng supports checking arch of the package which means that users
 won't be able to install sparc64 binary package into amd64 machines.
 (not done yet)
 
 - a special architecture all allows to specify when a package can be used
 on every architecture. (not done yet)
 
 - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself
 which directory has to be removed. (done in the alpha but needs love
 :))
 
 - new repository (apt-like feature) (only the repository generation is done)
 
 - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the 
 alpha)
 
 - test unit (libcheck) on libpkg. (done in the alpha needs some more love)
 
 - many more

Perhaps I am too impatient :) but I would like to inquire about the following
features:

I. A provides/requires interface for packages.
Each package specified a list of files (and perhaps other entities) that it
provides and requires.  At the initial stage, without ports modifications, these
could be: (1) a list of all files installed by package for provides; (2) for
requires - an auto-generated list of dependencies based on required shared
libraries plus dependency specifications in ports.
I think that this kind of interface should help with using alternatives that
provide the same interface (e.g. like gamin vs fam).

II. Package signing.

III. Package naming that includes architecture, major OS version (for API/ABI),
maybe more.

IV. Convenient support for i386 packages on amd64.
Distinct installation directories, proper installation conflict
detection/avoidance between i386 and amd64 packages, proper library paths, etc.

And finally some exotic ideas - support for multiple package sources (when
different people build packages in different ways (e.g. with different options, 
or
different optimizations) from the same ports tree; support for multiple ports
sources.(when people maintain different ports tree (e.g. kde or gnome 
development
ports tree)).  Perhaps, with some compatibility/hierarchy support for packages 
and
ports sources.  But that's almost a pipe dream, so don't take it seriously :)

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

RE: New Boot-Loader

[Andrew Duane]

-Original Message-
From: owner-freebsd-hack...@freebsd.org 
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
Sent: Monday, March 28, 2011 8:00 AM
To: Alexander Best
Cc: FreeBSD Hackers
Subject: Re: New Boot-Loader

Please note that graphical loaders are not very serial console friendly ;-)

-- 
Andriy Gapon


Amen, and we have a whole lot of platforms that are only serial consoles (and 
9600 baud at that).
Also, I like the letters instead of numbers for boot options, for those of us 
that have known for years that s is single user mode, v is verbose, etc


 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 



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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Garrett Cooper]

On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote:
 on 25/03/2011 12:11 Baptiste Daroussin said the following:
 Hi all,

 miwi@ launched the new thing called Experimental Call For Testing,
 it's our turn :)

 Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge
 contributor) have been working since the end of the last GSoC on a
 rewrite of pkg_install.

 pkgng is a binary package manager written from scratch for FreeBSD.

 After a long period of technology testing, (json, tinycdb, bdb, etc)
 and we now have achieved to implement the basic functionnality. We
 would greatly approciate to have some feedback, wider testing,
 patching, documenting etc, before implementing the higher level
 features.

 pkgng is built on top of a new libpkg, which allow to deal with the database 
 of
 installed packages, to deal with remote repositories, manage packages:
 creation, installation gathering informations, registering new ports.

 features supported are or will be :

 - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486)
 which allow  to have a bsd.port.mk which deal with both pkg_install
 and pkgng. (done in alpha)

 - the register command can analyse elf files when registering a new port to
 discover forgotten dependencies if necessary. (done in alpha using libelf)

 - the register command has two mode available : when dealing with old
 fashion ports it just registers the package, in new mode it does
 everything that would
 have been done by pkg add when installing the package : should display
 messages,  execute post-install, execute @exec etc. (old fashion done
 in the alpha)

 - pkg add supports two mode : the old fashion one (no real upgrade
 support) and  new one: upgrade scripts supported. (old fashion in the
 alpha)

 - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL,
 +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion
 scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't
 supported in the alpha)

 - new +MANIFEST (plist-like format) with new metadatas : options, arch, os
 version, etc. (done in the alpha)

 - pkgng supports checking arch of the package which means that users
 won't be able to install sparc64 binary package into amd64 machines.
 (not done yet)

 - a special architecture all allows to specify when a package can be used
 on every architecture. (not done yet)

 - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself
 which directory has to be removed. (done in the alpha but needs love
 :))

 - new repository (apt-like feature) (only the repository generation is done)

 - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the 
 alpha)

 - test unit (libcheck) on libpkg. (done in the alpha needs some more love)

 - many more

 Perhaps I am too impatient :) but I would like to inquire about the following
 features:

 I. A provides/requires interface for packages.
 Each package specified a list of files (and perhaps other entities) that it
 provides and requires.  At the initial stage, without ports modifications, 
 these
 could be: (1) a list of all files installed by package for provides; (2) for
 requires - an auto-generated list of dependencies based on required shared
 libraries plus dependency specifications in ports.
 I think that this kind of interface should help with using alternatives that
 provide the same interface (e.g. like gamin vs fam).

 II. Package signing.

That would be really nice.

 III. Package naming that includes architecture, major OS version (for 
 API/ABI),
 maybe more.

This could be provided in the manifest. Doing it in the filename sort
of turns into a mess, as I've discovered working at Cisco :).

 IV. Convenient support for i386 packages on amd64.
 Distinct installation directories, proper installation conflict
 detection/avoidance between i386 and amd64 packages, proper library paths, 
 etc.

There are other architectures that would benefit from this as well,
like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc.

This involves more work than pkgng could provide IIRC as build
infrastructure would need to be fixed to look at and link against
usr/lib32 instead of usr/lib, unless you mean to rewrite the linker
stuff at install-time.

 And finally some exotic ideas - support for multiple package sources (when
 different people build packages in different ways (e.g. with different 
 options, or
 different optimizations) from the same ports tree; support for multiple ports
 sources.(when people maintain different ports tree (e.g. kde or gnome 
 development
 ports tree)).  Perhaps, with some compatibility/hierarchy support for 
 packages and
 ports sources.  But that's almost a pipe dream, so don't take it seriously :)

It would be nice. That's a request in the same general area that
Gentoo portage's overlay goes into, but I think that would require
rewriting certain bits of ports infrastructure to be extensible, not
extend pkgng in this 

Re: Keeping /etc/localtime up-to-date

[dieterbsd]

 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.

I have been running FreeBSD and NetBSD with /etc/localtime being
a symlink for years and have not seen any problems as a result.



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

Re: Keeping /etc/localtime up-to-date

[Garrett Cooper]

On Mon, Mar 28, 2011 at 10:57 AM,  dieter...@engineer.com wrote:
 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.

 I have been running FreeBSD and NetBSD with /etc/localtime being
 a symlink for years and have not seen any problems as a result.

+1. Many Linux distros do the same thing as well (Gentoo is just one example).
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: New Boot-Loader

[dieterbsd]

Please note that graphical loaders are not very serial console 

friendly ;-)

Yes!  Real computers have RS-232 consoles.  And please stick with
plain ASCII text.  The current bootloader is at best ugly and at
worst unusable on some terminals.  AFAIK the bootloader doesn't have
termcap/terminfo available.

The default needs to work everywhere.  A bootloader does not need to be 
pretty.
If you want a pretty bootloader, put it off to the side and those who 
both can

and want to run it can enable it once the basics are running.


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

multi-boot bootstrap?

[dieterbsd]

The discussion of a new bootloader reminded me of the
following problem:

What we need more than a new bootloader is a new bootstrap.
With MBR, NetBSD's boot selector MBR works reasonably well.
(About as well as can be expected given the limited space available.)
You get a menu of partitions (slices in FreeBSD-speak)
and can enter a number to select which one you want to boot.
If you don't enter anything it times out and boots the default.
You can boot a different disk by pressing F1, F2, F3 ...

example:
Fn: diskn
1: NBSD4.0
2: NB5.0.1
3: FBSD7.1
4: FBSD8.2

The menu labels are limited to 7 chars due to the limited space
available in the MBR.

But, disks larger than 2 GiB need to be GPT rather than MBR.
I haven't found a bootstrap with similar functionality for GPT.

GPT allows a larger bootstrap than MBR.  So the bootstrap can
be nicer.  Firmware disk numbering is completely insane on some
machines.  So spare the poor user from having to guess which
disk is which number today.  Go through all the disks and look
for bootable partitions.  Extract the GPT partition labels for
these partitions.  Present a menu of choices.

example:
Enter the menu number for the partition you wish to boot.
The default will automatically boot in 5 seconds.

1: FreeBSD 7.1
2: FreeBSD 8.2 (default)
3: NetBSD 4.0
4: NetBSD 5.0.1
5: OpenBSD
6: Plan 9
7: reboot back to firmware

Boot:

As with the boot loader, this needs to work on all machines,
and all terminals (without having termcap/terminfo), so just plain
ASCII text, no graphics.



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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Julien Laffaye]

On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote:
 On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote:
 on 25/03/2011 12:11 Baptiste Daroussin said the following:
 Hi all,

 miwi@ launched the new thing called Experimental Call For Testing,
 it's our turn :)

 Julien Laffaye (jlaffaye@) and I, helped by Philippe Pepiot (huge
 contributor) have been working since the end of the last GSoC on a
 rewrite of pkg_install.

 pkgng is a binary package manager written from scratch for FreeBSD.

 After a long period of technology testing, (json, tinycdb, bdb, etc)
 and we now have achieved to implement the basic functionnality. We
 would greatly approciate to have some feedback, wider testing,
 patching, documenting etc, before implementing the higher level
 features.

 pkgng is built on top of a new libpkg, which allow to deal with the 
 database of
 installed packages, to deal with remote repositories, manage packages:
 creation, installation gathering informations, registering new ports.

 features supported are or will be :

 - smooth integration with bsd.port.mk (including bsd.pkg.mk line 2486)
 which allow  to have a bsd.port.mk which deal with both pkg_install
 and pkgng. (done in alpha)

 - the register command can analyse elf files when registering a new port to
 discover forgotten dependencies if necessary. (done in alpha using libelf)

 - the register command has two mode available : when dealing with old
 fashion ports it just registers the package, in new mode it does
 everything that would
 have been done by pkg add when installing the package : should display
 messages,  execute post-install, execute @exec etc. (old fashion done
 in the alpha)

 - pkg add supports two mode : the old fashion one (no real upgrade
 support) and  new one: upgrade scripts supported. (old fashion in the
 alpha)

 - new scripts supported +PREINSTALL +POSTINSTALL, +PREDEINSTALL,
 +POSTDEINSTALL, +PREUPGRADE, +POSTUPGRADE as well as the old fashion
 scripts : +INSTALL +DEINSTALL +UPGRADE (all supported *UPGRADES aren't
 supported in the alpha)

 - new +MANIFEST (plist-like format) with new metadatas : options, arch, os
 version, etc. (done in the alpha)

 - pkgng supports checking arch of the package which means that users
 won't be able to install sparc64 binary package into amd64 machines.
 (not done yet)

 - a special architecture all allows to specify when a package can be used
 on every architecture. (not done yet)

 - @dirrm and @dirrmtry are now deprecated, pkgng can discover itself
 which directory has to be removed. (done in the alpha but needs love
 :))

 - new repository (apt-like feature) (only the repository generation is done)

 - real support for reverse dependency (no ugly +REQUIRED_BY) (done in the 
 alpha)

 - test unit (libcheck) on libpkg. (done in the alpha needs some more love)

 - many more

 Perhaps I am too impatient :) but I would like to inquire about the following
 features:

 I. A provides/requires interface for packages.
 Each package specified a list of files (and perhaps other entities) that it
 provides and requires.  At the initial stage, without ports modifications, 
 these
 could be: (1) a list of all files installed by package for provides; (2) for
 requires - an auto-generated list of dependencies based on required shared
 libraries plus dependency specifications in ports.
 I think that this kind of interface should help with using alternatives that
 provide the same interface (e.g. like gamin vs fam).

Adding require/provide support in pkgng is kind of trivial. But ports
have to support it first.


 II. Package signing.

 That would be really nice.

Right know we only planned to sign the repo database, so we can trust
the sah256 of the packages stored in the database. Then if the package
has the same sha256 as the one in the repo database it is considered
trusted.
If we want a per-package signing, we would have a tarball in a tarball.


 III. Package naming that includes architecture, major OS version (for 
 API/ABI),
 maybe more.

 This could be provided in the manifest. Doing it in the filename sort
 of turns into a mess, as I've discovered working at Cisco :).


Actually, it *is* in the +MANIFEST of pkgng packages archives :-)

 IV. Convenient support for i386 packages on amd64.
 Distinct installation directories, proper installation conflict
 detection/avoidance between i386 and amd64 packages, proper library paths, 
 etc.

 There are other architectures that would benefit from this as well,
 like powerpc 32-bit on 64-bit, MIPs 32-bit on n32, etc.

 This involves more work than pkgng could provide IIRC as build
 infrastructure would need to be fixed to look at and link against
 usr/lib32 instead of usr/lib, unless you mean to rewrite the linker
 stuff at install-time.

I dont think we are going that way right now...


 And finally some exotic ideas - support for multiple package sources (when
 different people build packages in different 

Re: Keeping /etc/localtime up-to-date

[Devin Teske]

Sent from my iPad

On Mar 28, 2011, at 10:57 AM, dieter...@engineer.com wrote:

 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.
 
 I have been running FreeBSD and NetBSD with /etc/localtime being
 a symlink for years and have not seen any problems as a result.
 

The one (and only) problem that I've seen from using a symlink for 
/etc/localtime is that -- since the /usr partition is not mounted early-on -- 
boot messages get logged in GMT offset until /usr is mounted.

However, some simply ignore this.
--
Devin

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

Re: Keeping /etc/localtime up-to-date

[Maxim Khitrov]

On Mon, Mar 28, 2011 at 2:10 PM, Garrett Cooper gcoo...@freebsd.org wrote:
 On Mon, Mar 28, 2011 at 10:57 AM,  dieter...@engineer.com wrote:
 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.

 I have been running FreeBSD and NetBSD with /etc/localtime being
 a symlink for years and have not seen any problems as a result.

 +1. Many Linux distros do the same thing as well (Gentoo is just one example).
 Thanks,
 -Garrett

Same here, though I'd be happy to change this habit if mergemaster
handled the updates for me.

If you do end up using /var/db/zoneinfo in mergemaster, keep two things in mind:

1. /var/db/zoneinfo may not exist because tzsetup was never used
(/etc/localtime may or may not exist).
2. /etc/localtime may be a symlink to /usr/share/zoneinfo/...

In the first case, you would need to ask the user which zoneinfo file
to use, or just run tzsetup for them. In the second case, you should
confirm that the user wants to replace the symlink with a copy. In
both cases, verify that /var/db/zoneinfo reflects current
configuration (create it, if necessary).

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

Re: Keeping /etc/localtime up-to-date

[Olivier Smedts]

2011/3/28  dieter...@engineer.com:
 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.

 I have been running FreeBSD and NetBSD with /etc/localtime being
 a symlink for years and have not seen any problems as a result.

The symlink's target is in /usr (/usr/share/zoneinfo/), which is
separated in the default partition layout.
But both /etc/rc.d/adjkerntz and /usr/src/UPDATING require mounting
filesystems before calling adjkerntz, so it should be ok.

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email  vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Keeping /etc/localtime up-to-date

[Brian Reichert]

On Mon, Mar 28, 2011 at 11:10:42AM -0700, Garrett Cooper wrote:
 On Mon, Mar 28, 2011 at 10:57 AM,  dieter...@engineer.com wrote:
  I have been running FreeBSD and NetBSD with /etc/localtime being
  a symlink for years and have not seen any problems as a result.
 
 +1. Many Linux distros do the same thing as well (Gentoo is just one example).

RedHat is a counter-example.

Parts of the kernel are not timezone aware, and seem to be hard-coded
to use whatever TZ the hardware clock is in.  The symptom I was
running into was that the kernel's timestamps were waffling
back-and-forth during the boot process.

I was making use of a symlink, but the timezone data was on a
different partition from the root parition.  RedHat's support
officially said don't use a symlink, as any process started before
the 'real' TZ files were available would reckon time differently
when printing timestamps.

Lots of people got bit by this:

  https://bugzilla.redhat.com/show_bug.cgi?id=91228

YMMV.

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

-- 
Brian Reichert  reich...@numachi.com
BSD admin/developer at large
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: multi-boot bootstrap?

[Super Bisquit]

Now, how are you going to multiboot OpenBSD and NetBSD on a PowerPC machine
from the same hard disk. From what I know, one or the other can only be as
the first entry and it then has to be set from the forth prompt.
So, you will need two disks to boot , saya: OpenBSD, NetBSD, FreeBSD, Linux,
and MacOSX or a combination of these.

On PPC boxes with OpenFirmware 3.x, you actually need to set the active
partition if you want to boot Linux and/or freebsd from the forth prompt if
both are on the same disk.

You would need to reprogram the OpenBoot prompt on the UltraSPARC boxes.
No one on the FreeBSD hacker list does any forth programming. If such was
true, I would have had a few questions answered long ago.


On Mon, Mar 28, 2011 at 2:04 PM, dieter...@engineer.com wrote:

 The discussion of a new bootloader reminded me of the
 following problem:

 What we need more than a new bootloader is a new bootstrap.
 With MBR, NetBSD's boot selector MBR works reasonably well.
 (About as well as can be expected given the limited space available.)
 You get a menu of partitions (slices in FreeBSD-speak)
 and can enter a number to select which one you want to boot.
 If you don't enter anything it times out and boots the default.
 You can boot a different disk by pressing F1, F2, F3 ...

 example:
Fn: diskn
1: NBSD4.0
2: NB5.0.1
3: FBSD7.1
4: FBSD8.2

 The menu labels are limited to 7 chars due to the limited space
 available in the MBR.

 But, disks larger than 2 GiB need to be GPT rather than MBR.
 I haven't found a bootstrap with similar functionality for GPT.

 GPT allows a larger bootstrap than MBR.  So the bootstrap can
 be nicer.  Firmware disk numbering is completely insane on some
 machines.  So spare the poor user from having to guess which
 disk is which number today.  Go through all the disks and look
 for bootable partitions.  Extract the GPT partition labels for
 these partitions.  Present a menu of choices.

 example:
Enter the menu number for the partition you wish to boot.
The default will automatically boot in 5 seconds.

1: FreeBSD 7.1
2: FreeBSD 8.2 (default)
3: NetBSD 4.0
4: NetBSD 5.0.1
5: OpenBSD
6: Plan 9
7: reboot back to firmware

Boot:

 As with the boot loader, this needs to work on all machines,
 and all terminals (without having termcap/terminfo), so just plain
 ASCII text, no graphics.



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

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

Re: Keeping /etc/localtime up-to-date

[Jason Helfman]

On Mon, Mar 28, 2011 at 02:22:01PM -0400, Maxim Khitrov thus spake:

Same here, though I'd be happy to change this habit if mergemaster
handled the updates for me.


This would be a good solution for source updates, but how would this work
for binary upgrades via freebsd-update, as mergemaster is not used for this
operation.

-jgh

--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD  4342 5E92 AD66 8C8C FBA5
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Super Bisquit]

Go through the mailing lists. You can only boot 64bit on 64bit and 32bit on
32bit for FreeBSD. Debian needs to boot a 64bit kernel for 64bit machines.

I made the reply because that is similar to the BTX bootloader.
Let Baptiste get a powerpc machine and try using that bootloader, it won't
work.
It won't work on sparc (64/ultra), and it won't work on arm.


On Mon, Mar 28, 2011 at 3:01 PM, Garrett Cooper gcoo...@freebsd.org wrote:

 On Mon, Mar 28, 2011 at 11:22 AM, Super Bisquit superbisq...@gmail.com
 wrote:
  The ppc 32bit series does not boot directly into the boot loader prompt.
 You
  have to:
  A) Hold logo+opt+o+f and then
 1) setenv boot-device hd#
 2) mac-boot
 3) Wait for the boot sequence to allow you to make interaction
 4) Hit the space bar and then type boot -s
  B)
  1) Hold down the option key.
  2) Wait,  and choose the icon of harddisk.
  3) Follow 3 and 4 above
  C) If you have more than one installation, set the current device you
 want
  to be   active  from the OF prompt and then:
 1) Follow 3 and 4 from A above.
 
  Unless he is going to write that script in forth, you can count out both
  PowerPC(32 and 64) and UltraSPARC boxes.
 
  If you can get the BTX loader to work on the architectures I just
 mentioned,
  let me know, because the rest of us can't.

 Huh? This seems way outside of what I was referring to.
The powerpc64 architecture does support 32-bit on 64-bit (biarch)
 support. Whether or not it's supported in FreeBSD I don't remember.
 Thanks,
 -Garrett

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

Re: Keeping /etc/localtime up-to-date

[Devin Teske]

On Mon, 2011-03-28 at 11:48 -0700, Jason Helfman wrote:

 On Mon, Mar 28, 2011 at 02:22:01PM -0400, Maxim Khitrov thus spake:
 Same here, though I'd be happy to change this habit if mergemaster
 handled the updates for me.
 
 This would be a good solution for source updates, but how would this work
 for binary upgrades via freebsd-update, as mergemaster is not used for this
 operation.


How we solved this back in 2006 when Congress altered the times that
Daylight Saving is observed, we pushed out an internal package that:

( Before Installation )

1a. If /etc/localtime is a symbolic link, proceed to installation (no
update needed).
1b. If /etc/localtime is a binary file,...
2. Compare /etc/localtime against each locale in /usr/share/zoneinfo
3. If you find a match, remember which timezone matched

( After Installation )

4. If /etc/localtime was binary and matched some locale
in /usr/share/zoneinfo, copy updated zoneinfo to /etc/localtime
(overwriting the current file).
-- 
Devin


 
 -jgh
 


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

Re: Keeping /etc/localtime up-to-date

[Matthias Andree]

Am 28.03.2011 19:57, schrieb dieter...@engineer.com:
 And while I (think I) recall that the equivalent of /etc/localtime
 was implemented in some version of SunOS many years ago as a symlink,
 I believe that approach could be problematic for FreeBSD, as it
 could impose some unintended requirements on some of the start-up
 scripts.
 
 I have been running FreeBSD and NetBSD with /etc/localtime being
 a symlink for years and have not seen any problems as a result.

In that case, /etc and /usr/share/timezone (or whatever) need to be in
the same physical file system.  Adds interesting software effects for
those file systems where a directory is a filesystem with its own dev
and thereabouts, such as AFS.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Keeping /etc/localtime up-to-date

[dieterbsd]

And while I (think I) recall that the equivalent of /etc/localtime
was implemented in some version of SunOS many years ago as a 

symlink,

I believe that approach could be problematic for FreeBSD, as it
could impose some unintended requirements on some of the start-up
scripts.


I have been running FreeBSD and NetBSD with /etc/localtime being
a symlink for years and have not seen any problems as a result.


The one (and only) problem that I've seen from using a symlink for
/etc/localtime is that -- since the /usr partition is not mounted
early-on -- boot messages get logged in GMT offset until /usr is 

mounted.


However, some simply ignore this.


What boot messages are these?

grep 2011 /var/run/dmesg.boot
Copyright (c) 1992-2011 The FreeBSD Project.
FreeBSD 8.2-RELEASE #9: Sun Mar  6 18:47:36 pst 2011



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

Re: multi-boot bootstrap?

[dieterbsd]

Now, how are you going to multiboot OpenBSD and NetBSD on a PowerPC 

machine

from the same hard disk.


I didn't say anything about a requirement for booting multiple OSes
from the same disk.  I said:


Go through all the disks and look
for bootable partitions.  Extract the GPT partition labels for
these partitions.  Present a menu of choices.


There can be multiple disks.  (Assuming the hardware supports that.)
I haven't worked with PowerPC machines and it has been a very long time
since I worked with Sparc.  I'm more familiar with Alpha, which would 
take
some hacking to boot more than one OS per disk, but some rocket 
scientist

decided to drop FreeBSD support for Alpha, so I suspect that no one here
cares about Alpha.


From what I know, one or the other can only be as
the first entry and it then has to be set from the forth prompt.
So, you will need two disks to boot , saya: OpenBSD, NetBSD, FreeBSD, 

Linux,

and MacOSX or a combination of these.

On PPC boxes with OpenFirmware 3.x, you actually need to set the 

active
partition if you want to boot Linux and/or freebsd from the forth 

prompt if

both are on the same disk.


Can these PPC boxes boot from GPT disks?  active partition sounds 
MBRish.

Perhaps they can use the protective MBR trick?



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

Re: Keeping /etc/localtime up-to-date

[Doug Barton]

On 03/27/2011 18:38, Ed Maste wrote:

That's what tzsetup does in HEAD - the name of the selected timezone file
is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy in an
updated file:

   -r  Reinstall the zoneinfo file installed last time. The
   name is obtained from /var/db/zoneinfo.

It looks like this hasn't been MFC'd, although I'm not sure why.  The
change came in from svn rev 198267 by edwin (CC'd).


Edwin,

Any reason not to MFC this?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: Prebind from OpenBSD

[Peter Jeremy]

On 2011-Mar-27 20:54:18 +0100, Robert Watson rwat...@freebsd.org wrote:
part of rc.d.  I'd also investigate large applications like Firefox, Chrome, 
KDE, Gnome, etc.  KDE already integrates prebinding tricks in its design, but 
I don't think the others do.

Improving startup time for large, infrequently started executables will
enhance the user experience but not do a great deal for overall system
performance.  (And note that things like OOo, emacs and browsers have
significant amounts of code in embedded scripting languages and it's
unlikely that pre-binding will help much there).

I suspect a bigger overall win would be gained by speeding up small
but very frequently started executables - /bin/sh is the most obvious
candidate here, though there are probably other candidates in /bin
and /usr/bin.  In this case, you need to measure how frequenctly it
is started as well as the per-startup savings.  For some of these
executables, it's easy to get a reasonably accurate estimate of the
potential pre-binding savings by comparing the speed of the existing
dynamically-linked executable in /bin with the same statically-linked
executable in /rescue.

One thing that I'm not sure if you've take into account is process-
initiated library loading (using dlopen(3) and friends).  Note that
even /bin/sh can do this through things like locale handling.

-- 
Peter Jeremy


pgpj6ptimMgB2.pgp
Description: PGP signature

Re: multi-boot bootstrap?

[Super Bisquit]

On Mon, Mar 28, 2011 at 4:59 PM, dieter...@engineer.com wrote:

 Now, how are you going to multiboot OpenBSD and NetBSD on a PowerPC

 machine

 from the same hard disk.


 I didn't say anything about a requirement for booting multiple OSes


from the same disk.  I said:

 Go through all the disks and look
 for bootable partitions.  Extract the GPT partition labels for
 these partitions.  Present a menu of choices.

   Not that easy.

 There can be multiple disks.  (Assuming the hardware supports that.)


Openfirmware isn't BIOS.

 I haven't worked with PowerPC machines and it has been a very long time
 since I worked with Sparc.

OpenFirmware is based on OpenBoot and both require forth programming. I had
to reference Gentoo documentation because none of the hackers knew or knows
how to change devices. By the way, SILO is the only Bootloader I know of
that can multiboot on a sparc box. Linux emulation for sparc doesn't exist
on freebsd, you'll be working on that yourself.



  I'm more familiar with Alpha, which would take
 some hacking to boot more than one OS per disk, but some rocket scientist
 decided to drop FreeBSD support for Alpha, so I suspect that no one here
 cares about Alpha.

FreeBSD alpha needs to follow debian alpha: become a self sustaining
project.



  From what I know, one or the other can only be as
 the first entry and it then has to be set from the forth prompt.
 So, you will need two disks to boot , saya: OpenBSD, NetBSD, FreeBSD,

 Linux,

 and MacOSX or a combination of these.

 On PPC boxes with OpenFirmware 3.x, you actually need to set the

 active

 partition if you want to boot Linux and/or freebsd from the forth

 prompt if

 both are on the same disk.


 Can these PPC boxes boot from GPT disks?  active partition sounds MBRish.
 Perhaps they can use the protective MBR trick?

Sorry, doesn't work like that. Linux does yaboot. FreeBSD does the
bootloader Whitehorn wrote for it. OpenBSD either takes up the whole disk or
you need to do a lot of hacking. NetBSD requires exact command lines to
boot.

Active partition on a ppc machine means that which you will boot from after
the kernel is loaded.

It boots from an hfs partition on which the bootloader has been dd'ed to.
If you have more than one installation, you need need to set which ufs
partiton is the active one by specifying on the command line.





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


You're setup will be as such for a ppc machine:

1) Your bootloader on an hfs partition has to be the very first entry on
each disk which is attached.
2) It will need to load Whitehorn's bootloader by using forth commands from
the console.
3) Whitehorn's bootloader will need to be set from your bootloader to choose
which ufs2 partition will load- in the event someone has more than one
install.
4) Whitehorn's bootloader will need to be paused to allow module loading,
single boot or an alternative kernel from the selected install.
5) This will need to be done for every boot.


There are no slices on a ppc machine. There are partitions only.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Using mergemaster to keep /etc/localtime updated

[Doug Barton]

I'm starting a new thread since while the previous one contained a lot 
of good information it was starting to get a big fragmented, and as 
someone pointed out mergemaster is not a general solution so I want to 
focus on the area that I'm actually responsible for. :)


Having read everything in the thread (and thanks to all who contributed, 
btw) my current plan is to add some code to the end (in the section that 
deals with things like running cap_mkdb if you update login.conf) to do 
the following. Please let me know if this sounds reasonable, or if I'm 
missing something:


1. If /var/db/zoneinfo exists, check to see if /etc/localtime is the 
same as /usr/share/`cat /var/db/zoneinfo` and if not, prompt the user to 
run tzsetup.
2. If /var/db/zoneinfo does not exist, check to see if kern.osreldate is 
after the date that the code was added, and if so, prompt the user to 
run tzsetup.
3. If /var/db/zoneinfo does not exist, and the new code has not been 
added yet, attempt to determine the right answer, and create a 
/var/db/zoneinfo file. (Note, I do not look forward to writing that bit.) :)



Sound reasonable?

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

src.conf(5) status/semantics

[Alexander Best]

hi there,

how hard would it be to change the *.mk code so the following semantics apply:

- make.conf(5) == applies system-wide
- src.conf(5) == applies only to /usr/src

right now certain settings will not be picked up from src.conf(5), like CC or
CXX. it seems src.conf(5)'s puspose atm is limited to setting WITHOUT_*
options.

as can be noticed in several questions on current@, toolchain@ and questions@,
the current behavior is non-intuitive. a lot of users don't understand why
certain settings inside /etc/src.conf don't get picked up when building a
target such as buildkernel or buildworld. expecially in connection with
switching to clang and clang++ confusion has been noticable more than once.

cheers.
alex

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

Re: Keeping /etc/localtime up-to-date

[Devin Teske]

On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
  And while I (think I) recall that the equivalent of /etc/localtime
  was implemented in some version of SunOS many years ago as a 
 symlink,
  I believe that approach could be problematic for FreeBSD, as it
  could impose some unintended requirements on some of the start-up
  scripts.
 
  I have been running FreeBSD and NetBSD with /etc/localtime being
  a symlink for years and have not seen any problems as a result.
 
  The one (and only) problem that I've seen from using a symlink for
  /etc/localtime is that -- since the /usr partition is not mounted
  early-on -- boot messages get logged in GMT offset until /usr is 
 mounted.
 
  However, some simply ignore this.
 
 What boot messages are these?

The messages generated during boot -- see /var/log/messages.


 grep 2011 /var/run/dmesg.boot

Those aren't the boot messages I'm referring to (and by convention, I
would call those the kernel boot messages as only the kernel messages
are found there).

 Copyright (c) 1992-2011 The FreeBSD Project.
 FreeBSD 8.2-RELEASE #9: Sun Mar  6 18:47:36 pst 2011

Huh? Please help me understand why you'd grep for 2011 in the context
of this topic (timezone differences).

Here's an impirical test:
1. Put your BIOS into GMT
2. Make /etc/localtime a symbolic link
to /usr/share/zoneinfo/America/Los_Angeles
3. Reboot

In our experience, the Regents of the University of California message
is logged to /var/log/messages in GMT and subsequent messages (produced
after /usr is mounted) are logged in the desired timezone.

NOTE: This assumes that / and /usr are separate partitions.
-- 
Devin

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

Re: multi-boot bootstrap?

[Nathan Whitehorn]

On 03/28/11 15:59, dieter...@engineer.com wrote:




From what I know, one or the other can only be as
the first entry and it then has to be set from the forth prompt.
So, you will need two disks to boot , saya: OpenBSD, NetBSD, FreeBSD, 

Linux,

and MacOSX or a combination of these.

On PPC boxes with OpenFirmware 3.x, you actually need to set the 

active
partition if you want to boot Linux and/or freebsd from the forth 

prompt if

both are on the same disk.


Can these PPC boxes boot from GPT disks?  active partition sounds 
MBRish.

Perhaps they can use the protective MBR trick?


No, they can only boot from APM (Apple Partition Map) disks, which don't 
have a concept of active partition. The current boot1 on PPC is 
hard-coded to boot from the first UFS partition on the disk, which could 
be changed, certainly, but is almost totally unrelated to this discussion.

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

Re: src.conf(5) status/semantics

[Freddie Cash]

On Mon, Mar 28, 2011 at 3:03 PM, Alexander Best arun...@freebsd.org wrote:
 how hard would it be to change the *.mk code so the following semantics apply:

 - make.conf(5) == applies system-wide
 - src.conf(5) == applies only to /usr/src

What would be really nice would be taking it to its logical conclusion:

/etc/make.conf   for system-wide make options (applies when make run anywhere)
/etc/src.confonly applies when make run under /usr/src
/etc/ports.confonly applies when make run under /usr/ports

-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: src.conf(5) status/semantics

[Alexander Best]

On Mon Mar 28 11, Freddie Cash wrote:
 On Mon, Mar 28, 2011 at 3:03 PM, Alexander Best arun...@freebsd.org wrote:
  how hard would it be to change the *.mk code so the following semantics 
  apply:
 
  - make.conf(5) == applies system-wide
  - src.conf(5) == applies only to /usr/src
 
 What would be really nice would be taking it to its logical conclusion:

defenately. however i think the src.conf case should be first fixed before
adding the ports.conf case. 

 
 /etc/make.conf   for system-wide make options (applies when make run anywhere)
 /etc/src.confonly applies when make run under /usr/src
 /etc/ports.confonly applies when make run under /usr/ports
 
 -- 
 Freddie Cash
 fjwc...@gmail.com

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

Re: Keeping /etc/localtime up-to-date

[Olivier Smedts]

2011/3/29 Devin Teske dte...@vicor.com:
 On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
  And while I (think I) recall that the equivalent of /etc/localtime
  was implemented in some version of SunOS many years ago as a
 symlink,
  I believe that approach could be problematic for FreeBSD, as it
  could impose some unintended requirements on some of the start-up
  scripts.
 
  I have been running FreeBSD and NetBSD with /etc/localtime being
  a symlink for years and have not seen any problems as a result.
 
  The one (and only) problem that I've seen from using a symlink for
  /etc/localtime is that -- since the /usr partition is not mounted
  early-on -- boot messages get logged in GMT offset until /usr is
 mounted.
 
  However, some simply ignore this.

 What boot messages are these?

 The messages generated during boot -- see /var/log/messages.


 grep 2011 /var/run/dmesg.boot

 Those aren't the boot messages I'm referring to (and by convention, I
 would call those the kernel boot messages as only the kernel messages
 are found there).

 Copyright (c) 1992-2011 The FreeBSD Project.
 FreeBSD 8.2-RELEASE #9: Sun Mar  6 18:47:36 pst 2011

 Huh? Please help me understand why you'd grep for 2011 in the context
 of this topic (timezone differences).

 Here's an impirical test:
 1. Put your BIOS into GMT
 2. Make /etc/localtime a symbolic link
 to /usr/share/zoneinfo/America/Los_Angeles
 3. Reboot

 In our experience, the Regents of the University of California message
 is logged to /var/log/messages in GMT and subsequent messages (produced
 after /usr is mounted) are logged in the desired timezone.

 NOTE: This assumes that / and /usr are separate partitions.

Not for me (BIOS clock set to UTC) :
% uname -a
FreeBSD q.gid0.org 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r220114: Mon Mar
28 23:42:11 CEST 2011 r...@q.gid0.org:/usr/obj/usr/src/sys/QUAD
amd64
% date
mar 29 mar 2011 00:41:41 CEST
% uptime
 0:41  up 30 mins, 3 users, load averages: 0,06 0,06 0,07
% ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  32 29 jui  2008 /etc/localtime@ -
/usr/share/zoneinfo/Europe/Paris
% mount
tank/freebsd on / (zfs, local, noatime, nfsv4acls)
[...]
tank/freebsd/usr on /usr (zfs, local, noatime, nfsv4acls)
[...]
% grep -i regents /var/log/messages
Mar 29 00:12:08 q kernel: The Regents of the University of California.
All rights reserved.
% tail -n 1 /var/log/messages
Mar 29 00:12:08 q kernel: kbd0 at ukbd0

I don't think this content is added to /var/log/messages during boot,
because the kernel doesn't have access to the log file (and if /usr is
not mounted, neither is /var). I thought the kernel messages were
saved in memory (system message buffer), and only after boot (and
filesystems mounted, and syslogd started) were they dumped to a file.


-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email  vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Using mergemaster to keep /etc/localtime updated

[Olivier Smedts]

2011/3/28 Doug Barton do...@freebsd.org:
 I'm starting a new thread since while the previous one contained a lot of
 good information it was starting to get a big fragmented, and as someone
 pointed out mergemaster is not a general solution so I want to focus on the
 area that I'm actually responsible for. :)

 Having read everything in the thread (and thanks to all who contributed,
 btw) my current plan is to add some code to the end (in the section that
 deals with things like running cap_mkdb if you update login.conf) to do the
 following. Please let me know if this sounds reasonable, or if I'm missing
 something:

 1. If /var/db/zoneinfo exists, check to see if /etc/localtime is the same as
 /usr/share/`cat /var/db/zoneinfo` and if not, prompt the user to run
 tzsetup.
 2. If /var/db/zoneinfo does not exist,

and /etc/localtime is not a symlink to a tz file ?

 check to see if kern.osreldate is
 after the date that the code was added, and if so, prompt the user to run
 tzsetup.

So how would mergemaster behave after a fresh make installworld
distribution in an empty DESTDIR ? Isn't it supposed to do nothing in
this case, because all should already be up-to-date ?

 3. If /var/db/zoneinfo does not exist, and the new code has not been added
 yet, attempt to determine the right answer, and create a /var/db/zoneinfo
 file. (Note, I do not look forward to writing that bit.) :)


 Sound reasonable?

 Doug

 --

        Nothin' ever doesn't change, but nothin' changes much.
                        -- OK Go

        Breadth of IT experience, and depth of knowledge in the DNS.
        Yours for the right price.  :)  http://SupersetSolutions.com/

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




-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: oliv...@gid0.org        - against HTML email  vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Using mergemaster to keep /etc/localtime updated

[Doug Barton]

On 03/28/2011 15:38, Olivier Smedts wrote:

2011/3/28 Doug Bartondo...@freebsd.org:

I'm starting a new thread since while the previous one contained a lot of
good information it was starting to get a big fragmented, and as someone
pointed out mergemaster is not a general solution so I want to focus on the
area that I'm actually responsible for. :)

Having read everything in the thread (and thanks to all who contributed,
btw) my current plan is to add some code to the end (in the section that
deals with things like running cap_mkdb if you update login.conf) to do the
following. Please let me know if this sounds reasonable, or if I'm missing
something:

1. If /var/db/zoneinfo exists, check to see if /etc/localtime is the same as
/usr/share/`cat /var/db/zoneinfo` and if not, prompt the user to run
tzsetup.
2. If /var/db/zoneinfo does not exist,


and /etc/localtime is not a symlink to a tz file ?


Good point, I forgot to include that. :)

I should point out that I also forgot to specifically enumerate the case 
where there is no /etc/localtime file (i.e., the time zone is UTC). In 
that case mergemaster should do nothing.



check to see if kern.osreldate is
after the date that the code was added, and if so, prompt the user to run
tzsetup.


So how would mergemaster behave after a fresh make installworld
distribution in an empty DESTDIR ?


If you've already installed stuff, I don't see how DESTDIR could be 
empty. Or am I missing something?



Isn't it supposed to do nothing in this case, because all should already be 
up-to-date ?


If there is no DESTDIR/etc/localtime, then yes, do nothing is the 
right answer, see above.



Thanks for the review,

Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: Keeping /etc/localtime up-to-date

[Devin Teske]

On Tue, 2011-03-29 at 00:51 +0200, Olivier Smedts wrote:

 2011/3/29 Devin Teske dte...@vicor.com:
  On Mon, 2011-03-28 at 16:52 -0400, dieter...@engineer.com wrote:
   And while I (think I) recall that the equivalent of /etc/localtime
   was implemented in some version of SunOS many years ago as a
  symlink,
   I believe that approach could be problematic for FreeBSD, as it
   could impose some unintended requirements on some of the start-up
   scripts.
  
   I have been running FreeBSD and NetBSD with /etc/localtime being
   a symlink for years and have not seen any problems as a result.
  
   The one (and only) problem that I've seen from using a symlink for
   /etc/localtime is that -- since the /usr partition is not mounted
   early-on -- boot messages get logged in GMT offset until /usr is
  mounted.
  
   However, some simply ignore this.
 
  What boot messages are these?
 
  The messages generated during boot -- see /var/log/messages.
 
 
  grep 2011 /var/run/dmesg.boot
 
  Those aren't the boot messages I'm referring to (and by convention, I
  would call those the kernel boot messages as only the kernel messages
  are found there).
 
  Copyright (c) 1992-2011 The FreeBSD Project.
  FreeBSD 8.2-RELEASE #9: Sun Mar  6 18:47:36 pst 2011
 
  Huh? Please help me understand why you'd grep for 2011 in the context
  of this topic (timezone differences).
 
  Here's an impirical test:
  1. Put your BIOS into GMT
  2. Make /etc/localtime a symbolic link
  to /usr/share/zoneinfo/America/Los_Angeles
  3. Reboot
 
  In our experience, the Regents of the University of California message
  is logged to /var/log/messages in GMT and subsequent messages (produced
  after /usr is mounted) are logged in the desired timezone.
 
  NOTE: This assumes that / and /usr are separate partitions.
 
 Not for me (BIOS clock set to UTC) :
 % uname -a
 FreeBSD q.gid0.org 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r220114: Mon Mar
 28 23:42:11 CEST 2011 r...@q.gid0.org:/usr/obj/usr/src/sys/QUAD
 amd64
 % date
 mar 29 mar 2011 00:41:41 CEST
 % uptime
  0:41  up 30 mins, 3 users, load averages: 0,06 0,06 0,07
 % ls -l /etc/localtime
 lrwxr-xr-x  1 root  wheel  32 29 jui  2008 /etc/localtime@ -
 /usr/share/zoneinfo/Europe/Paris
 % mount
 tank/freebsd on / (zfs, local, noatime, nfsv4acls)
 [...]
 tank/freebsd/usr on /usr (zfs, local, noatime, nfsv4acls)
 [...]
 % grep -i regents /var/log/messages
 Mar 29 00:12:08 q kernel: The Regents of the University of California.
 All rights reserved.
 % tail -n 1 /var/log/messages
 Mar 29 00:12:08 q kernel: kbd0 at ukbd0
 
 I don't think this content is added to /var/log/messages during boot,
 because the kernel doesn't have access to the log file (and if /usr is
 not mounted, neither is /var). I thought the kernel messages were
 saved in memory (system message buffer), and only after boot (and
 filesystems mounted, and syslogd started) were they dumped to a file.


I'm thinking that this must have changed from FreeBSD-4.8 onward. I
wasn't personally involved on this one, but did hear from my boss that
several sites reported this (but those sites were running FreeBSD 4.8
and 4.11). It's quite possible that the problem was fixed in later
releases.

In which case, I can jump up and down for joy and tell my boss that it's
once-again kosher to set /etc/localtime as a symbolic link.
--
Devin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Keeping /etc/localtime up-to-date

[Doug Barton]

On 03/28/2011 16:22, Devin Teske wrote:

In which case, I can jump up and down for joy and tell my boss that it's
once-again kosher to set /etc/localtime as a symbolic link.


It has always been true that the only safe way to make /etc/localtime 
a symlink is to have / and /usr on the same filesystem. This point has 
been repeated several times in this thread so far, hopefully this can be 
the last? :)



Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Benjamin Kaduk]

On Mon, 28 Mar 2011, Julien Laffaye wrote:


On Mon, Mar 28, 2011 at 6:59 PM, Garrett Cooper gcoo...@freebsd.org wrote:

On Mon, Mar 28, 2011 at 10:44 AM, Andriy Gapon a...@freebsd.org wrote:


II. Package signing.


That would be really nice.


Right know we only planned to sign the repo database, so we can trust
the sah256 of the packages stored in the database. Then if the package
has the same sha256 as the one in the repo database it is considered
trusted.
If we want a per-package signing, we would have a tarball in a tarball.


I really expected this to have been mentioned already, but this approach 
(tarball in a tarball) is taken by Debian packages, and I don't remember 
hearing of any issues related to it.  I don't think it's worth discounting 
from the start without giving some considerationg, but I will defer to the 
people actually doing the work.


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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Tim Kientzle]

 II. Package signing.
 
 That would be really nice.
 
 Right know we only planned to sign the repo database, so we can trust
 the sah256 of the packages stored in the database. Then if the package
 has the same sha256 as the one in the repo database it is considered
 trusted.
 If we want a per-package signing, we would have a tarball in a tarball.
 
 I really expected this to have been mentioned already, but this approach 
 (tarball in a tarball) is taken by Debian packages, and I don't remember 
 hearing of any issues related to it.  I don't think it's worth discounting 
 from the start without giving some considerationg, but I will defer to the 
 people actually doing the work.

If you use libarchive-style streaming, it's even
pretty straightforward to read and extract such
things without having to create a bunch of
temporary files.

You just need to be careful about compression.

Tim

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

Re: Keeping /etc/localtime up-to-date

[Edwin Groothuis]

Hello Doug,

I think it got lost in the busy/dark part of my life last year.
Feel free to do it, the code is not spectacular or dramatic.
If not done when I go home I will do it tonight on my way back from
work.

Edwin
 
 -- Edwin Groothuis ed...@mavetju.org 

- Original Message -
From: Doug Barton 
To:Ed Maste 
Cc:David Wolfskill , , 
Sent:Mon, 28 Mar 2011 14:11:42 -0700
Subject:Re: Keeping /etc/localtime up-to-date

 On 03/27/2011 18:38, Ed Maste wrote:
  That's what tzsetup does in HEAD - the name of the selected
timezone file
  is stored in /var/db/zoneinfo, and tzsetup -r can be used to copy
in an
  updated file:
 
  -r Reinstall the zoneinfo file installed last time. The
  name is obtained from /var/db/zoneinfo.
 
  It looks like this hasn't been MFC'd, although I'm not sure why.
The
  change came in from svn rev 198267 by edwin (CC'd).

 Edwin,

 Any reason not to MFC this?

 Doug

 -- 

 Nothin' ever doesn't change, but nothin' changes much.
 -- OK Go

 Breadth of IT experience, and depth of knowledge in the DNS.
 Yours for the right price. :) http://SupersetSolutions.com/ [1]



Links:
--
[1] http://SupersetSolutions.com/

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

Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

[Baptiste Daroussin]

2011/3/29 Tim Kientzle kient...@freebsd.org:
 II. Package signing.

 That would be really nice.

 Right know we only planned to sign the repo database, so we can trust
 the sah256 of the packages stored in the database. Then if the package
 has the same sha256 as the one in the repo database it is considered
 trusted.
 If we want a per-package signing, we would have a tarball in a tarball.

 I really expected this to have been mentioned already, but this approach 
 (tarball in a tarball) is taken by Debian packages, and I don't remember 
 hearing of any issues related to it.  I don't think it's worth discounting 
 from the start without giving some considerationg, but I will defer to the 
 people actually doing the work.

 If you use libarchive-style streaming, it's even
 pretty straightforward to read and extract such
 things without having to create a bunch of
 temporary files.

 You just need to be careful about compression.

 Tim



ok but what is the problem with signing only the repository then rely on digest?

I am not sure we need more that this.

second question howto sign? pgp? ssl?

First would be the easiest way to go but we don't have in base
anything to check signatures (maybe we should in that case
investigating to import netpgp), ssl why not? but which algorithm?
what security officer would prefer?

We are ok to investigate that part, but we need more information about
what is expected.

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