Re: cron(8) improvement

2013-11-06 Thread Volodymyr Kostyrko

05.11.2013 20:21, Mark Felder wrote:



On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote:

On 11/05/13 12:31, Allan Jude wrote:

This came up in discussion on IRC and I thought I should throw it at the
list so I don't forget.

A user was asking how to do what linux cron does, where there is a
directory /etc/cron.d/ that packages and add files to to create crontabs.

Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
/usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
useful feature, especially for pkg(8) as it makes it easy and safe to
programatically add and remove crontabs as part of a package.




Shouldn't we encourage packages to use periodic(8) when possible?



Yes but our default periodic configuration in /etc/crontab is only
configured to be as granular as daily. If this is something that should
run hourly or at very strange intervals then cron is a better choice.


So why we shouldn't add something like:

0 * * * * root periodic hourly
@reboot root periodic reboot

I already do this on some machines to take hourly and boot snapshots 
with zfSnap. And I think periodic is much better place for such tasks.


--
Sphinx of black quartz, judge my vow.
___
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: [CFT] Kernel-Selection Enhancemnt to Boot Menu

2013-11-06 Thread Lars Engels

Am 05.11.2013 18:06, schrieb Kurt Lidl:



Well, I'd probably be in support of this change - it sure beats having
to interrupt the normal boot sequence and typing:
   unload
   load /boot/kernel.old/kernel
   load /boot/kernel.old/opensolaris.ko
   load /boot/kernel.old/zfs.ko
   boot


To load an older kernel I always just type

boot kernel.old


Doesn't that unload the currently loaded kernel automatically?
___
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


Add description for some cpuid bits

2013-11-06 Thread Dmitry Luhtionov
--- /usr/src/sys/amd64//amd64/identcpu.c.orig2013-11-01
14:43:15.0 +0200
+++ /usr/src/sys/amd64//amd64/identcpu.c2013-11-04 12:06:06.0
+0200
@@ -366,14 +366,14 @@
 \017b14
 \020LWP/* Lightweight Profiling */
 \021FMA4/* 4-operand FMA instructions */
-\022b17
+\022TCE/* Translation Cache Extension */
 \023b18
 \024NodeId/* NodeId MSR support */
 \025b20
 \026TBM/* Trailing Bit Manipulation */
 \027Topology/* Topology Extensions */
-\030b23
-\031b24
+\030PCXC/* Core performance counter extensions */
+\031PNXC/* NB performance counter extensions */
 \032b25
 \033b26
 \034b27
___
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


Add some non-standart usb device id's

2013-11-06 Thread Dmitry Luhtionov
--- /usr/src/sys/dev/usb/usbdevs.orig2013-11-01 14:44:43.0 +0200
+++ /usr/src/sys/dev/usb/usbdevs2013-11-04 13:56:17.0 +0200
@@ -2327,6 +2327,8 @@
 product INTEL TESTBOARD0x989082930 test board
 product INTEL2 IRMH0x0020Integrated Rate Matching Hub
 product INTEL2 IRMH20x0024Integrated Rate Matching Hub
+product INTEL2 IRMH30x8000Integrated Rate Matching Hub
+product INTEL2 IRMH40x8008Integrated Rate Matching Hub

 /* Interbiometric products */
 product INTERBIOMETRICS IOBOARD0x1002FTDI compatible adapter
___
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


Add support for Intel AMT technology on Intel Lynx Point chipset

2013-11-06 Thread Dmitry Luhtionov
--- /usr/src/sys/dev/uart/uart_bus_pci.c.orig2013-11-01
14:45:23.0 +0200
+++ /usr/src/sys/dev/uart/uart_bus_pci.c2013-11-04 11:15:54.0
+0200
@@ -122,6 +122,7 @@
 { 0x8086, 0x8812, 0x, 0, Intel EG20T Serial Port 1, 0x10 },
 { 0x8086, 0x8813, 0x, 0, Intel EG20T Serial Port 2, 0x10 },
 { 0x8086, 0x8814, 0x, 0, Intel EG20T Serial Port 3, 0x10 },
+{ 0x8086, 0x8c3d, 0x, 0, Intel Lynx Point KT Controller, 0x10 },
 { 0x9710, 0x9820, 0x1000, 1, NetMos NM9820 Serial Port, 0x10 },
 { 0x9710, 0x9835, 0x1000, 1, NetMos NM9835 Serial Port, 0x10 },
 { 0x9710, 0x9865, 0xa000, 0x1000, NetMos NM9865 Serial Port, 0x10 },
___
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: cron(8) improvement

2013-11-06 Thread Mark Felder
On Wed, Nov 6, 2013, at 2:57, Volodymyr Kostyrko wrote:
 05.11.2013 20:21, Mark Felder wrote:
 
 
  On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote:
  On 11/05/13 12:31, Allan Jude wrote:
  This came up in discussion on IRC and I thought I should throw it at the
  list so I don't forget.
 
  A user was asking how to do what linux cron does, where there is a
  directory /etc/cron.d/ that packages and add files to to create crontabs.
 
  Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
  /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
  useful feature, especially for pkg(8) as it makes it easy and safe to
  programatically add and remove crontabs as part of a package.
 
 
 
  Shouldn't we encourage packages to use periodic(8) when possible?
 
 
  Yes but our default periodic configuration in /etc/crontab is only
  configured to be as granular as daily. If this is something that should
  run hourly or at very strange intervals then cron is a better choice.
 
 So why we shouldn't add something like:
 
 0 * * * * root periodic hourly
 @reboot root periodic reboot
 
 I already do this on some machines to take hourly and boot snapshots 
 with zfSnap. And I think periodic is much better place for such tasks.
 

Submit a PR and a patch and maybe it can slip in to 10.0-RELEASE.
___
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 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

2013-11-06 Thread George Kontostanos
On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff gleb...@freebsd.org wrote:

 On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote:
 E  On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
 E  G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff gleb...@freebsd.org
 :
 E  G 
 E  G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 E  G   Ö Altough bind removed from FreeBSD 10 distribution,
 /etc/rc.d/named
 E  G  script
 E  G   Ö still exists.
 E  G   Ö and this script depends on /etc/mtree/BIND.chroot.dist
 file but
 E  G  there is
 E  G   Ö no such file in source tree.
 E  G   Ö I think this file was forgotten to be removed.
 E  G   Ö
 E  G   Ö And also, named_* definitions still exists in
 /etc/defaults/rc.conf
 E  G  file.
 E  G  
 E  G   Please review attached file that removes named from /etc.
 E  G 
 E  G  It would be great if the port would learn to install its own
 script etc.
 E  G  in time for that change. (Unless it’s already there, and I’m
 just too blind
 E  G  to see it.)
 E  G
 E  G No you are not blind. Installing bind from ports still relies on
 the
 E  G /etc/rc.d/named script.
 E 
 E  Erwin, can you please handle that?
 E
 E Things are much worse that this, the ports are completely written under
 the assumption that there is a Bind in base, which of course would already
 break with WITHOUT_BIND before Bind was completely removed.  It will be
 hard to fix without breaking the installed base of 8 and 9.  Sigh.
 E
 E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.


Suggestion. An option to install the rc script would solve that problem.



 What should we do with src?

 IMO, we should proceed with removal of remnants of bind in src. In the
 worst case,
 if you can't handle it this week, the situation will be the following:

 1) 8.x, 9.x users are okay
 2) 10+.x users w/o bind are okay
 3) 10+.x users with bind have problems

 If we skip updating src, then situation would be:

 1) 8.x, 9.x users are okay
 2) 10+.x users w/o bind have problems
 3) 10+.x users with bind are okay

 I think, there are less 10.x users with bind, than 10.x without it.


Please warn about this in UPDATING. I am personally use 12 FreeBSD servers
as dedicated DNS servers only.


 --
 Totus tuus, Glebius.




-- 
George Kontostanos
---
http://www.aisecure.net
___
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 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

2013-11-06 Thread Gleb Smirnoff
On Wed, Nov 06, 2013 at 03:22:03PM +0200, George Kontostanos wrote:
G  IMO, we should proceed with removal of remnants of bind in src. In the
G  worst case,
G  if you can't handle it this week, the situation will be the following:
G 
G  1) 8.x, 9.x users are okay
G  2) 10+.x users w/o bind are okay
G  3) 10+.x users with bind have problems
G 
G  If we skip updating src, then situation would be:
G 
G  1) 8.x, 9.x users are okay
G  2) 10+.x users w/o bind have problems
G  3) 10+.x users with bind are okay
G 
G  I think, there are less 10.x users with bind, than 10.x without it.
G 
G Please warn about this in UPDATING. I am personally use 12 FreeBSD servers
G as dedicated DNS servers only.

Erwin is now working on fixing the ports. Ports will be fixed soon.

Actually ports were not correct even for older branches, because relying
on a script from /etc/rc.d for a port is incorrect behavior.

-- 
Totus tuus, Glebius.
___
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: [CFT] Kernel-Selection Enhancemnt to Boot Menu

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 1:18 AM, Lars Engels wrote:

 Am 05.11.2013 18:06, schrieb Kurt Lidl:
 
 Well, I'd probably be in support of this change - it sure beats having
 to interrupt the normal boot sequence and typing:
   unload
   load /boot/kernel.old/kernel
   load /boot/kernel.old/opensolaris.ko
   load /boot/kernel.old/zfs.ko
   boot
 
 To load an older kernel I always just type
 
 boot kernel.old
 
 
 Doesn't that unload the currently loaded kernel automatically?

Actually... it does.

Thanks for pointing that out (forgot about that).

I think we still want the loader_delay feature added by the last
patch I shared on-list.

Yeah? I think it's still a good (optional) value-add.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

2013-11-06 Thread Stefan Bethke
Am 06.11.2013 um 14:59 schrieb Erwin Lansing:

 Suggestion. An option to install the rc script would solve that problem.  
 
 If only it was that simple, it would have been done a long time ago.  As Gleb 
 points out, the ports are broken by design.  The rc script needs a complete 
 rewrite, and that's only after fixing all configuration files, setting up 
 chroot, etc etc and all that while not breaking the installed base on 8 and 
 9.  I spent most of yesterday on this and if I'm lucky, I'm halfway through.

I'm very grateful for all that work going into making sure that people are not 
left stranded without working DNS after an upgrade.

Thank you Erwin!


Stefan

-- 
Stefan Bethke s...@lassitu.de   Fon +49 151 14070811

___
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


in-kernel zfs and cryptodev

2013-11-06 Thread Bruno Lauzé
I am compiling zfs in-kernel and it's working pretty well. However to succeed 
building a kernel
with :

options zfs
device  crypto
device  cryptodev


a patch is needed to rename sys/opencrypto/deflate.c which enter in conflict 
with deflate.c from zfs

After renaming sys/opencrypto/deflate.c to sys/opencrypto/cryptodeflate.c and 
changing the filename in sys/conf/files everything works perfectly.

Any opinions on this? 
___
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: Add description for some cpuid bits

2013-11-06 Thread Konstantin Belousov
On Wed, Nov 06, 2013 at 11:12:24AM +0200, Dmitry Luhtionov wrote:
 --- /usr/src/sys/amd64//amd64/identcpu.c.orig2013-11-01
 14:43:15.0 +0200
 +++ /usr/src/sys/amd64//amd64/identcpu.c2013-11-04 12:06:06.0
 +0200
 @@ -366,14 +366,14 @@
  \017b14
  \020LWP/* Lightweight Profiling */
  \021FMA4/* 4-operand FMA instructions */
 -\022b17
 +\022TCE/* Translation Cache Extension */
  \023b18
  \024NodeId/* NodeId MSR support */
  \025b20
  \026TBM/* Trailing Bit Manipulation */
  \027Topology/* Topology Extensions */
 -\030b23
 -\031b24
 +\030PCXC/* Core performance counter extensions */
 +\031PNXC/* NB performance counter extensions */
  \032b25
  \033b26
  \034b27

The patch should also change sys/i386/i386/identcpu.c.

Can you, please, provide a reference for the information about the bits ?
Latest CPUID document 25481, available on the AMD site, is from Sep 2010,
rev. 2.34, and it does not list the bits you added.


pgpmf3hqlvU90.pgp
Description: PGP signature


Re: FreeBSD 10 Beta2 /etc/rc.d/named script and /etc/defaults/rc.conf

2013-11-06 Thread George Kontostanos
On Wed, Nov 6, 2013 at 3:59 PM, Erwin Lansing er...@lansing.dk wrote:



 On 06/11/2013, at 14.22, George Kontostanos gkontos.m...@gmail.com
 wrote:

 On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff gleb...@freebsd.org wrote:

 On Mon, Nov 04, 2013 at 12:11:02PM +0100, Erwin Lansing wrote:
 E  On Mon, Nov 04, 2013 at 01:41:01AM +0200, George Kontostanos wrote:
 E  G  Am 03.11.2013 um 23:06 schrieb Gleb Smirnoff 
 gleb...@freebsd.org:
 E  G 
 E  G   On Sun, Nov 03, 2013 at 10:05:02PM +0200, Özkan KIRIK wrote:
 E  G   Ö Altough bind removed from FreeBSD 10 distribution,
 /etc/rc.d/named
 E  G  script
 E  G   Ö still exists.
 E  G   Ö and this script depends on /etc/mtree/BIND.chroot.dist
 file but
 E  G  there is
 E  G   Ö no such file in source tree.
 E  G   Ö I think this file was forgotten to be removed.
 E  G   Ö
 E  G   Ö And also, named_* definitions still exists in
 /etc/defaults/rc.conf
 E  G  file.
 E  G  
 E  G   Please review attached file that removes named from /etc.
 E  G 
 E  G  It would be great if the port would learn to install its own
 script etc.
 E  G  in time for that change. (Unless it’s already there, and I’m
 just too blind
 E  G  to see it.)
 E  G
 E  G No you are not blind. Installing bind from ports still relies on
 the
 E  G /etc/rc.d/named script.
 E 
 E  Erwin, can you please handle that?
 E
 E Things are much worse that this, the ports are completely written
 under the assumption that there is a Bind in base, which of course would
 already break with WITHOUT_BIND before Bind was completely removed.  It
 will be hard to fix without breaking the installed base of 8 and 9.  Sigh.
 E
 E I'll try to work on it this week, but unfortunately have a full
 schedule of meetings and travel as well.


 Suggestion. An option to install the rc script would solve that problem.



 If only it was that simple, it would have been done a long time ago.  As
 Gleb points out, the ports are broken by design.  The rc script needs a
 complete rewrite, and that's only after fixing all configuration files,
 setting up chroot, etc etc and all that while not breaking the installed
 base on 8 and 9.  I spent most of yesterday on this and if I'm lucky, I'm
 halfway through.

 Erwin, sent from a phone at the train station


Thank you all for your effort!

-- 
George Kontostanos
---
http://www.aisecure.net
___
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


11.0-CURRENT: 708.295633 netmap_reset [3011] interface not in netmap mode

2013-11-06 Thread O. Hartmann
Since a couple of days now in 11.0-CURRENT, I see this message

708.295633 netmap_reset [3011] interface not in netmap mode


several times in the console logs.

What does that mean?

oh


signature.asc
Description: PGP signature


[Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin
Subject says it all.

I need a review on the attached patch.

Come on, you know you want to...
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
Index: http.subr
===
--- http.subr   (revision 256550)
+++ http.subr   (working copy)
@@ -79,6 +79,7 @@ f_dialog_menu_media_http()
local menu_list=
'$msg_main_site'  'ftp.freebsd.org'
'URL' '$msg_specify_some_other_http_site'
+   'pkg $msg_main_site'  'pkg.freebsd.org'
 # END-QUOTE
local hline=$msg_select_a_site_thats_close
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [CFT] Kernel-Selection Enhancemnt to Boot Menu

2013-11-06 Thread John Baldwin
On Wednesday, November 06, 2013 10:22:44 am Teske, Devin wrote:
 
 On Nov 6, 2013, at 1:18 AM, Lars Engels wrote:
 
  Am 05.11.2013 18:06, schrieb Kurt Lidl:
  
  Well, I'd probably be in support of this change - it sure beats having
  to interrupt the normal boot sequence and typing:
unload
load /boot/kernel.old/kernel
load /boot/kernel.old/opensolaris.ko
load /boot/kernel.old/zfs.ko
boot
  
  To load an older kernel I always just type
  
  boot kernel.old
  
  
  Doesn't that unload the currently loaded kernel automatically?
 
 Actually... it does.
 
 Thanks for pointing that out (forgot about that).

The only thing that it doesn't do which I wish it did was fixup
module_path.  Right now if you break into the loader prompt and
do 'boot foo', you end up with module_path containing
/boot/kernel;/boot/modules;/boot/foo.  What I would like is to
be able to use 'boot foo' and get a proper module_path.

-- 
John Baldwin
___
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: Add description for some cpuid bits

2013-11-06 Thread John Baldwin
On Wednesday, November 06, 2013 4:12:24 am Dmitry Luhtionov wrote:
 --- /usr/src/sys/amd64//amd64/identcpu.c.orig2013-11-01
 14:43:15.0 +0200
 +++ /usr/src/sys/amd64//amd64/identcpu.c2013-11-04 12:06:06.0
 +0200
 @@ -366,14 +366,14 @@
  \017b14
  \020LWP/* Lightweight Profiling */
  \021FMA4/* 4-operand FMA instructions */
 -\022b17
 +\022TCE/* Translation Cache Extension */
  \023b18
  \024NodeId/* NodeId MSR support */
  \025b20
  \026TBM/* Trailing Bit Manipulation */
  \027Topology/* Topology Extensions */
 -\030b23
 -\031b24
 +\030PCXC/* Core performance counter extensions */
 +\031PNXC/* NB performance counter extensions */
  \032b25
  \033b26
  \034b27

It would be best to also add flags for these in specialreg.h as well.  The 
i386 identcpu.c might also need updating.

-- 
John Baldwin
___
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-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer

2013-11-06 Thread John Baldwin
On Tuesday, November 05, 2013 3:14:22 pm Oliver Pinter wrote:
 hmm, and seems like, the bottleneck are not in geom or cam, but in em
 driver or in networking stack
 
 the scenario is:
 
 A machine: dd if=/dev/ada1 bs=1M | nc -l 
 B machine: nc IP  | dd of=/dev/null bs=1M
 
 hmm, when dd-ing from /dev/zero and switch back to idletick to 0, then
 the performance of network dropped from 113MByte/s to 70+/-15 MByte/s
 
 machdep.idle_mwait=1/0 has no effect
 machdep.idle=htl has no effect

machdep.idle=hlt is the same thing as only using C1 (C1 is just
the 'hlt' instruction).  Try machdep.idle=spin perhaps?

-- 
John Baldwin
___
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-BETA3 now available

2013-11-06 Thread Glen Barber
On Tue, Nov 05, 2013 at 12:05:13PM -0500, Glen Barber wrote:
 The third BETA build of the 10.0-RELEASE release cycle is now available
 on the FTP servers for the amd64, i386, ia64, powerpc, powerpc64 and
 sparc64 architectures.
 
 [...]

 Important note to freebsd-update(8) users:  Please be sure to follow the
 instructions in the EN-13:04.freebsd-update errata notice here before
 upgrading the system to 10.0-BETA3:
 
   
 http://www.freebsd.org/security/advisories/FreeBSD-EN-13:04.freebsd-update.asc

Additional note to freebsd-update(8) users:

It has been reported that /var/empty is removed from the system as part
of updating the system with freebsd-update(8).  Specifically, the
directory is removed after running 'freebsd-update install' to install
the userland updates (after the kernel updates are installed and
freebsd-update(8) prompts to reboot and run 'freebsd-update install'
a second time).

The cause is still not clear, but we are actively looking into the
cause.

One of the symptoms of this behavior is that daemons using /var/empty as
the home directory will not start after the userland updates are
installed.

A temporary workaround for this is to create /var/empty after the
userland updates have completed, but before the system is rebooted the
second time, for example:

# freebsd-update -r 10.0-BETA3 upgrade
# freebsd-update install
# shutdown -r now
# freebsd-update install
# mkdir /var/empty
# chflags schg /var/empty
# shutdown -r now

Apologies for the inconvenience this has caused for anyone running into
this.

Glen



pgpta29Efhkrb.pgp
Description: PGP signature


Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer

2013-11-06 Thread Adrian Chadd
.. the main reason to use machdep.idle=hlt is that it is a different code path.

But to ensure you're always going via the hlt codepath, you _first_
have to disable mwait.

The idle code first decides whether to run mwait or idle, then if it
doesn't choose mwait, it chooses machdep.idle. That's why you first
have to disable idle_wait.



-adrian
___
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: 11.0-CURRENT: 708.295633 netmap_reset [3011] interface not in netmap mode

2013-11-06 Thread Luigi Rizzo
On Wed, Nov 6, 2013 at 9:12 AM, O. Hartmann ohart...@web.de wrote:

 Since a couple of days now in 11.0-CURRENT, I see this message

 708.295633 netmap_reset [3011] interface not in netmap mode


 several times in the console logs.

 What does that mean?


it is a leftover debugging message.
i have removed it now.

thanks
luigi

___
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: [Review] bsdconfig pkgng integration

2013-11-06 Thread Allan Jude
On 2013-11-06 13:32, Teske, Devin wrote:
 Subject says it all.

 I need a review on the attached patch.

 Come on, you know you want to...

I think you missed something, you attached a 1 line diff

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 3:02 PM, Allan Jude wrote:

 On 2013-11-06 13:32, Teske, Devin wrote:
 Subject says it all.
 
 I need a review on the attached patch.
 
 Come on, you know you want to...
 
 I think you missed something, you attached a 1 line diff
 

Oh I see... too much to review.

Hey, don't all review it at once now...

Seriously... come on...

I'm asking for some feedback on the most important part of the patchset...

The user-facing element.

The least everyone can do is chime in with their favorite mirrors.

So... please...

Tell me if the mirror list is incomplete (I *know* there are more mirrors
than that, and I *know* we want pkg.eu and pkg.us-* ... but I don't actually
know what people want to see ... so please... feedback!)
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [CFT] bsdinstall and zfsboot enhancements

2013-11-06 Thread Teske, Devin

On Nov 5, 2013, at 7:54 PM, Craig Rodrigues wrote:

 
 
 
 On Sat, Nov 2, 2013 at 10:59 AM, Teske, Devin devin.te...@fisglobal.com 
 wrote:
 
 + Update bsdinstall's config script to adjust ttyu* entries in
 /etc/ttys when it is determined that we are in-fact doing an install
 over serial (e.g. bhyve).
 
 I think this is useful.  In earlier versions of BHyve, the default was to use 
 console over a PCI serial device. 
 With this commit from Neel Natu: 
 http://lists.freebsd.org/pipermail/svn-src-all/2013-October/076027.html
 it is now possible to specify a different device for the console, such as 
 COM1.
 

Unfortunately, that's getting the axe.

I agree with Nathan... the installer shouldn't make this assumption.

I think init should be fixed instead.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Allan Jude
On 2013-11-06 18:15, Teske, Devin wrote:
 On Nov 6, 2013, at 3:02 PM, Allan Jude wrote:

 On 2013-11-06 13:32, Teske, Devin wrote:
 Subject says it all.

 I need a review on the attached patch.

 Come on, you know you want to...

 I think you missed something, you attached a 1 line diff

 Oh I see... too much to review.

 Hey, don't all review it at once now...

 Seriously... come on...

 I'm asking for some feedback on the most important part of the patchset...

 The user-facing element.

 The least everyone can do is chime in with their favorite mirrors.

 So... please...

 Tell me if the mirror list is incomplete (I *know* there are more mirrors
 than that, and I *know* we want pkg.eu and pkg.us-* ... but I don't actually
 know what people want to see ... so please... feedback!)
pkg.freebsd.org is a SVR record that lists the mirrors, and pkg
automatically picks the correct one, so it is best to list only that 1
mirror.

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 3:19 PM, Allan Jude wrote:

 On 2013-11-06 18:15, Teske, Devin wrote:
 On Nov 6, 2013, at 3:02 PM, Allan Jude wrote:
 
 On 2013-11-06 13:32, Teske, Devin wrote:
 Subject says it all.
 
 I need a review on the attached patch.
 
 Come on, you know you want to...
 
 I think you missed something, you attached a 1 line diff
 
 Oh I see... too much to review.
 
 Hey, don't all review it at once now...
 
 Seriously... come on...
 
 I'm asking for some feedback on the most important part of the patchset...
 
 The user-facing element.
 
 The least everyone can do is chime in with their favorite mirrors.
 
 So... please...
 
 Tell me if the mirror list is incomplete (I *know* there are more mirrors
 than that, and I *know* we want pkg.eu and pkg.us-* ... but I don't actually
 know what people want to see ... so please... feedback!)
 pkg.freebsd.org is a SVR record

This matters not... see SVN r257755


 that lists the mirrors,

We do not ever want to display the contents of the SVR record in the list.
There are multiple pkg*.freebsd.org SVR zones.


 and pkg
 automatically picks the correct one,

pkg does no such thing. It picks the first one that works.

The decisioning for which order and what content gets returned from the SVR 
query
is on the back-end, not on the pkg-end; pkg just takes the first one that works.

For example, host -t SVR _http._tcp.pkg.freebsd.org (for me at least)
returns 3 entries. pkg goes after the first one.

I'd be shocked if you told me that pkg was doing geo-mapping with the 3 names it
returns and determining which was was closest.

Rather, pkg just does a DNS query and goes through the list of hosts.



 so it is best to list only that 1
 mirror.
 

No. You're thinking that I'm talking about the contents of the SVR query.
I'm not. I'm instead talking about...

*actual* and *real* multiple names that you can query SVR data from.

pkg.freebsd.org is only one

There are multiples, and I believe that we should add them.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Glen Barber
On Wed, Nov 06, 2013 at 11:28:25PM +, Teske, Devin wrote:
 We do not ever want to display the contents of the SVR record in the list.
 There are multiple pkg*.freebsd.org SVR zones.
 

You do not need to show any servers except pkg.FreeBSD.org.  In fact,
you can use that by default, and not show any servers at all.  Do not
add more complexity to this than there needs to be.  By adding explicit
listing of servers here, you are putting a dependency on clusteradm that
is not necessary at all.

Glen



pgpov93NkmbuZ.pgp
Description: PGP signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 3:32 PM, Glen Barber wrote:

 On Wed, Nov 06, 2013 at 11:28:25PM +, Teske, Devin wrote:
 We do not ever want to display the contents of the SVR record in the list.
 There are multiple pkg*.freebsd.org SVR zones.
 
 
 You do not need to show any servers except pkg.FreeBSD.org.

Bapt *just* got finished telling me in IRC that we should also list:

pkg.eu
pkg.us-*

Which I assume to be the same make/model of pkg.f.o (does not
return an A or  but only SVR).

If that is the case (that pkg.eu.f.o is just like pkg.f.o -- and it just
happens to be a name that returns SVR names for servers local
to Europe), then I don't see why we would want to omit this.

I'm not the only one you have to convince...

bapt was the one that brought up the existence of the other names.



  In fact,
 you can use that by default, and not show any servers at all.  Do not
 add more complexity to this than there needs to be.  By adding explicit
 listing of servers here, you are putting a dependency on clusteradm that
 is not necessary at all.
 

I want to get some confusion out of the way...

I do not want to add even one single name that resolves to an A or .

I want *only* names that resolve to SVR.

I've just heard from bapt that pkg.f.o is not the only such name, that there
are other such names that similarly do not return A or .

I don't see the increase in complexity or maintenance.

I'm asking for locale-specific CDN names.

The user ought to be able to choose the master CDN or a locale-specific
CDN. This is not rocket science.
-- 
Devin




 Glen
 

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Glen Barber
On Wed, Nov 06, 2013 at 11:37:43PM +, Teske, Devin wrote:
  You do not need to show any servers except pkg.FreeBSD.org.
 
 Bapt *just* got finished telling me in IRC that we should also list:
 
 pkg.eu
 pkg.us-*
 

Why?

 Which I assume to be the same make/model of pkg.f.o (does not
 return an A or  but only SVR).
 

And if we need to change something with the infrastructure, we now have
to tell people that this was done.  You are putting hard-coded
limitations on us.  Don't.

With a single entry (pkg.FreeBSD.org), we do not have to worry about
what is broken if (when) we need to change something.

Glen



pgp78e6rrcJzB.pgp
Description: PGP signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 3:44 PM, Glen Barber wrote:

 On Wed, Nov 06, 2013 at 11:37:43PM +, Teske, Devin wrote:
 You do not need to show any servers except pkg.FreeBSD.org.
 
 Bapt *just* got finished telling me in IRC that we should also list:
 
 pkg.eu
 pkg.us-*
 
 
 Why?
 
 Which I assume to be the same make/model of pkg.f.o (does not
 return an A or  but only SVR).
 
 
 And if we need to change something with the infrastructure, we now have
 to tell people that this was done.  You are putting hard-coded
 limitations on us.  Don't.
 

I disagree.

You're making the argument for what if a CDN goes away.

Well... people stop using that entry because it's broken and in the next release
you remove it.

What sounds like a maintenance issue will actually save you support events.
And for whatever hours that this proposed maintenance actually cost you, you'll
more than make up that in prevented support events.

I'm talking about saving time (because we're all volunteers, right?)

Let me be very explicit...



 With a single entry (pkg.FreeBSD.org), we do not have to worry about
 what is broken if (when) we need to change something.
 

Let's say that the one entry doesn't do what you want (which requires trusting
the CDN maintenance on the back-end)...

You're telling me that it's more efficient to immediately defer every single 
user
to the support forums the moment there's a single hiccup in the ONE and ONLY
CDN name that we're providing?

Ok... but let's look at one alternative...

If we listed more than one CDN, and one breaks... the wise and tenacious user
simply ... tries another?

But if there are no other choices... then you'll be headed strait to the forums 
or
mailing lists and generating what I call a support event.

I'm sorry, but I don't agree that listing only one single entry is going to be 
beneficial
to the end-user; only to the person that thinks having a single CDN to maintain 
is
going to actually save them work (which may only be true if they are not the 
ones
that have to manage support events).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: hwpstate0: set freq failed patch

2013-11-06 Thread hiren panchasara
On Tue, Oct 29, 2013 at 2:13 PM, hiren panchasara hi...@freebsd.org wrote:
 On Tue, Oct 29, 2013 at 8:00 AM, Mark Felder f...@freebsd.org wrote:
skip

 PR in question:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=167018

 CCing hiren@ and avg@

 I will try to get back on this soon.

sbruno@ committed the fix:

http://svnweb.freebsd.org/changeset/base/257769

cheers,
Hiren
___
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: [Review] bsdconfig pkgng integration

2013-11-06 Thread Glen Barber
On Wed, Nov 06, 2013 at 11:53:28PM +, Teske, Devin wrote:
  And if we need to change something with the infrastructure, we now have
  to tell people that this was done.  You are putting hard-coded
  limitations on us.  Don't.
  
 
 I disagree.
 
 You're making the argument for what if a CDN goes away.
 

No, you are thinking about it backwards.

If a node goes down (there is no CDN), we take it out of DNS.
A single entry, removed from the pkg.FreeBSD.org SRV record.  We do not
have to redirect anything, we do not have to update various
configuration files in various places in the tree.

Glen



pgpukwIArTYKc.pgp
Description: PGP signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 3:53 PM, Teske, Devin wrote:

 
 On Nov 6, 2013, at 3:44 PM, Glen Barber wrote:
 
 On Wed, Nov 06, 2013 at 11:37:43PM +, Teske, Devin wrote:
 You do not need to show any servers except pkg.FreeBSD.org.
 
 Bapt *just* got finished telling me in IRC that we should also list:
 
 pkg.eu
 pkg.us-*
 
 
 Why?
 
 Which I assume to be the same make/model of pkg.f.o (does not
 return an A or  but only SVR).
 
 
 And if we need to change something with the infrastructure, we now have
 to tell people that this was done.  You are putting hard-coded
 limitations on us.  Don't.
 
 
 I disagree.
 
 You're making the argument for what if a CDN goes away.
 
 Well... people stop using that entry because it's broken and in the next 
 release
 you remove it.
 
 What sounds like a maintenance issue will actually save you support events.
 And for whatever hours that this proposed maintenance actually cost you, 
 you'll
 more than make up that in prevented support events.
 
 I'm talking about saving time (because we're all volunteers, right?)
 
 Let me be very explicit...
 
 
 
 With a single entry (pkg.FreeBSD.org), we do not have to worry about
 what is broken if (when) we need to change something.
 
 
 Let's say that the one entry doesn't do what you want (which requires trusting
 the CDN maintenance on the back-end)...
 
 You're telling me that it's more efficient to immediately defer every single 
 user
 to the support forums the moment there's a single hiccup in the ONE and ONLY
 CDN name that we're providing?
 
 Ok... but let's look at one alternative...
 
 If we listed more than one CDN, and one breaks... the wise and tenacious user
 simply ... tries another?
 
 But if there are no other choices... then you'll be headed strait to the 
 forums or
 mailing lists and generating what I call a support event.
 
 I'm sorry, but I don't agree that listing only one single entry is going to 
 be beneficial
 to the end-user; only to the person that thinks having a single CDN to 
 maintain is
 going to actually save them work (which may only be true if they are not the 
 ones
 that have to manage support events).

I think there's a lot of misunderstanding going on because of the way that 
clusteradm
has set up our CDN.

It is true that right now, pkg.f.o returns SRV records for all known mirrors.

It is also true that previously mentioned pkg.eu.f.o returns the one and only 
SRV record
for the one mirror in Europe.

However, I am planning for a day when our CDN is administered in a more 
traditional
fashion. That is...

I envisage pkg.f.o not returning all known mirrors (because there will be too 
many as
the CDN grows), but instead pkg.f.o would return only the 3 closest mirrors.

Meanwhile, pkg.eu.f.o would grow to return records for the top-3 closest 
servers in Europe.

Just because the amount of machines that we have available for our CDN is 
small, doesn't
mean that it will be small forever.

Eventually (as is the plan), the list of servers should far exceed the number 
of SRV records
you will want to return. And when we get to that point, I highly recommend that 
we allow the
user to choose the CDN specific to their country (at the very least).
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 4:01 PM, Glen Barber wrote:

 On Wed, Nov 06, 2013 at 11:53:28PM +, Teske, Devin wrote:
 And if we need to change something with the infrastructure, we now have
 to tell people that this was done.  You are putting hard-coded
 limitations on us.  Don't.
 
 
 I disagree.
 
 You're making the argument for what if a CDN goes away.
 
 
 No, you are thinking about it backwards.
 
 If a node goes down (there is no CDN), we take it out of DNS.
 A single entry, removed from the pkg.FreeBSD.org SRV record.  We do not
 have to redirect anything, we do not have to update various
 configuration files in various places in the tree.
 

Please help me to understand why on Earth you think:

[I am] putting hard-coded limitations on [you]

The facts:

1. The DNS names I am talking about:
1.a. pkg.f.o
1.b. pkg.eu.f.o
2. Do not resolve to an A or  record

So what hard-coding are you talking about?

You talk about how if a node goes down we take it out of DNS
but that has absolutely nothing to do with me because I'm not
putting A/-resolving names in the menu.

You do realize don't you that pkg.eu.f.o is a locale-specific name
that will eventually hold potentially many-more European server
names, right?

You do realize that the actual European server is *NOT* pkg.eu,
right?

You do realize that while the name pkg.f.o may wholly encompass
all the mirrors, that this will not always be true, right?

I have no idea what you're talking about with the updating of config
files.

The only reason you would ever have to update a config file is if
pkg.eu.f.o went away, but ...

Now I will repeat...

pkg.eu.f.o is NOT A REAL SERVER

It is a name, that resolves to the SRV record of the European server.

That being said... that name should not go away unless we no longer
have even one single server in Europe.

Oh, and by the way...

The name pkg.f.o does *NOT* resolve to pkg.eu... pkg.eu is a sibling
name that is disassociated -- it was actually *designed* to be used for
this.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: cron(8) improvement

2013-11-06 Thread Tim Kientzle

On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:

 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.
 
 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.
 
 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.

This is a good idea.  We should do it.

How and if this facility gets used is a separate question.

Tools, not policy.

Support for a cron.d directory is a tool that can be
used in many ways.  The policy of how it should be
used is a separate discussion.  (For example, whether
or not ports or packages should install crontab files into
/usr/local/etc/cron.d/ can be richly debated after that
directory exists.)

Tim

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


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Glen Barber
On Thu, Nov 07, 2013 at 12:13:49AM +, Teske, Devin wrote:
 So what hard-coding are you talking about?
 

You are trying to hard-code hostnames for a service in the FreeBSD
src/ tree, when it is *absolutely* unnecessary.

 You talk about how if a node goes down we take it out of DNS
 but that has absolutely nothing to do with me because I'm not
 putting A/-resolving names in the menu.
 

I did not once say anything about A or  records.

 You do realize don't you that pkg.eu.f.o is a locale-specific name
 that will eventually hold potentially many-more European server
 names, right?
 

So?

 You do realize that the actual European server is *NOT* pkg.eu,
 right?
 

*Sigh*...

 You do realize that while the name pkg.f.o may wholly encompass
 all the mirrors, that this will not always be true, right?
 

No, you are wrong.

 I have no idea what you're talking about with the updating of config
 files.
 

Clearly.  If you hard-code anything other than pkg.FreeBSD.org in
bsdconfig, now clusteradm has to become aware of it, and make sure that
record *always* exists, no matter what the endpoint is.

This nonsense happened with sysinstall, and anything else that used the
FTP mirror list.  And when a node disappears, for whatever reason, it is
an absolute nightmare to sort out.

For the last time, you do not need to have *any* host entries other than
'pkg.FreeBSD.org'.  Period.

 That being said... that name should not go away unless we no longer
 have even one single server in Europe.
 

This has nothing to do with bsdconfig.  Try to see my larger point.

 Oh, and by the way...
 
 The name pkg.f.o does *NOT* resolve to pkg.eu... pkg.eu is a sibling
 name that is disassociated -- it was actually *designed* to be used for
 this.

So was pkg.FreeBSD.org.  It is why I do *NOT* want you to hard-code
anything other than that.

Glen



pgpIrm4IqoZND.pgp
Description: PGP signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 4:22 PM, Glen Barber wrote:

 On Thu, Nov 07, 2013 at 12:13:49AM +, Teske, Devin wrote:
 So what hard-coding are you talking about?
 
 
 You are trying to hard-code hostnames for a service in the FreeBSD
 src/ tree, when it is *absolutely* unnecessary.
 

Not all hostnames are equal.

As you know, pkg.freebsd.org is one that you would never deny.

So just as pkg.freebsd.org is different from a normal hostname,
pkg.eu.freebsd.org and pkg.us-east.freebsd.org and
pkg.us-west.freebsd.org are similarly different (in the same way).

I'm not trying to hard-code any ol' hostnames...

I'm trying to hardcode the hostnames which can be administered
to point to one or more grouped servers.

You talk about how pkg.freebsd.org is unique because we can
simply change where it points...

I'm talking about doing the same thing for the other 3 names we
have which were designed for the same thing.

I think that you're thinking that:

pkg.eu.freebsd.org
pkg.us-east.freebsd.org
pkg.us-west.freebsd.org

Will somehow change?

The only way they would change is in the same way that you
would change pkg.freebsd.org -- I don't know how much clearer
I can make this.



 You talk about how if a node goes down we take it out of DNS
 but that has absolutely nothing to do with me because I'm not
 putting A/-resolving names in the menu.
 
 
 I did not once say anything about A or  records.
 

You talked about a node going down.
A node has a A or quad-A record.
The name for that node is served via the SRV record.

Read the above paragraph again carefully.

I said A/-resolving names
That is equivalent to node name
and you were talking about what if a node goes down.

And my answer to that was...
I don't care if a node goes down, because I'm not using
node names in the menu.




 You do realize don't you that pkg.eu.f.o is a locale-specific name
 that will eventually hold potentially many-more European server
 names, right?
 
 
 So?
 

So, the name pkg.eu is never going to change. It, like pkg.freebsd.org
will just have modified SRV records to track the European nodes.



 You do realize that the actual European server is *NOT* pkg.eu,
 right?
 
 
 *Sigh*...
 

Your sign leads me to be concerned that there is a false
assumption that the DNS name that serves the SRV records should
be a one-to-one mapping.

There's absolutely no reason whatsoever to dedicate an entire locale
specific domain to one SRV record. That's silly. As we grow, this domain
-- which is decidedly locale-specific by way of its actual name -- should
be used for what it was intended... a locale abstraction of many-to-one.


 You do realize that while the name pkg.f.o may wholly encompass
 all the mirrors, that this will not always be true, right?
 
 
 No, you are wrong.
 

I surely hope I am not.

You're saying that:

+ We'll never have more than one server in Europe.
+ We'll never have more than one server in the West Coast of the USA.
+ We'll never have more than one server in the East Coast of the USA.

That makes me very sad. Very sad indeed.

I envisaged a growth that would have had dozens upon dozens of
servers all throughout, and the locale-specific domains would then
return geographically based SRV records (of which we administer on
the back-end).



 I have no idea what you're talking about with the updating of config
 files.
 
 
 Clearly.  If you hard-code anything other than pkg.FreeBSD.org in
 bsdconfig, now clusteradm has to become aware of it, and make sure that
 record *always* exists, no matter what the endpoint is.
 

http://lists.freebsd.org/pipermail/freebsd-pkg/2013-October/000107.html

According to that mail, clusteradm *should* already be away of the
three I mentioned... pkg.eu, pkg.us-east, and pkg.us-west




 This nonsense happened with sysinstall, and anything else that used the
 FTP mirror list.  And when a node disappears, for whatever reason, it is
 an absolute nightmare to sort out.
 

I have to continue to beat the drum...

You had to do that in sysinstall, because the names that were used there
were A/quad-A resolving names (node names).

Just as pkg.freebsd.org is not one of those names... pkg.eu and pkg.us-*
are not like the names used in sysinstall.

So please... tell me again, how or why you would *ever* have to modify
pkg.eu or pkg.us-* ???


 For the last time, you do not need to have *any* host entries other than
 'pkg.FreeBSD.org'.  Period.
 

Until you acknowledge that pkg.eu and pkg.us-* are of the same pedigree
as pkg.f.o, I assume that you are still confusing this list of names with a
traditional list of names like sysinstall had.


 That being said... that name should not go away unless we no longer
 have even one single server in Europe.
 
 
 This has nothing to do with bsdconfig.  Try to see my larger point.
 

Oh, I agree...

I'm looking forward to the big picture when pkg.eu returns more than one
SRV record. I'm looking forward to the day that pkg.us-east and pkg.us-west
return more than one 

Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Glen Barber
On Thu, Nov 07, 2013 at 12:48:02AM +, Teske, Devin wrote:
 I think that you're thinking that:
 
 pkg.eu.freebsd.org
 pkg.us-east.freebsd.org
 pkg.us-west.freebsd.org
 
 Will somehow change?

I think you're thinking they *won't* change.  Don't assume.

Glen



pgpYvjMEXknes.pgp
Description: PGP signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 5:02 PM, Glen Barber wrote:

 On Thu, Nov 07, 2013 at 12:48:02AM +, Teske, Devin wrote:
 I think that you're thinking that:
 
 pkg.eu.freebsd.org
 pkg.us-east.freebsd.org
 pkg.us-west.freebsd.org
 
 Will somehow change?
 
 I think you're thinking they *won't* change.  Don't assume.
 

Well, what *kind* of change?

Changes to what they serve should be no problem...

but what I was assuming that wouldn't change was
their actual names. (e.g. pkg.eu stays pkg.eu).

Couldn't care about any other change, because that
would percolate at runtime off the DNS servers.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: cron(8) improvement

2013-11-06 Thread Lyndon Nerenberg
 Support for a cron.d directory is a tool that can be
 used in many ways.

I have used cron.d on other UNIXen, and for package-installed cron jobs I find 
it significantly friendlier, in that it makes these jobs easily identifiable to 
the sysadmin.

As we do it now, the per-user crontabs are quite opaque.  It's easy to get a 
list of the 'logins' that have them, but the best you can do is cat the files 
and hope the entries are well documented or obvious from context.  And editing 
a single file from an installer script is always subject to failure: it's hard 
to guard from failure if somebody comes along and, in the course of manually 
editing the file, upsets the markers the [un]installer scripts are looking for.

Allowing a package to add/rm a self-contained file avoids these accidental 
editing muckups.  And with a simple standardized naming convention, the mapping 
from cron files to packages can be both unique and obvious.  This is a big win 
for the sysadmin trying to track down a mystery run-away cron job.

Some attention must be given to setting things the uid/gid to run under, and it 
might be useful to allow specification of things like the login class, and 
perhaps capsicum capabilities.  Actually, the latter two features are useful in 
the general case.  Regardless, the core idea is both sound and useful.

--lyndon

___
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: cron(8) improvement

2013-11-06 Thread Mark Felder


On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
 
 On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:
 
  This came up in discussion on IRC and I thought I should throw it at the
  list so I don't forget.
  
  A user was asking how to do what linux cron does, where there is a
  directory /etc/cron.d/ that packages and add files to to create crontabs.
  
  Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
  /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
  useful feature, especially for pkg(8) as it makes it easy and safe to
  programatically add and remove crontabs as part of a package.
 
 This is a good idea.  We should do it.
 
 How and if this facility gets used is a separate question.
 
 Tools, not policy.
 
 Support for a cron.d directory is a tool that can be
 used in many ways.  The policy of how it should be
 used is a separate discussion.  (For example, whether
 or not ports or packages should install crontab files into
 /usr/local/etc/cron.d/ can be richly debated after that
 directory exists.)
 

Ok, so we create that directory. Now nobody can use it in a port until
FreeBSD 8.4 is EoL -- approximately June 30, 2015.

We should be using the existing cron tabs directory *now*. We can't
easily force older versions of FreeBSD to update their cron software or
configuration to support that new directory.

I'm not saying we shouldn't create it, just that we can't effectively
use it for 2 years.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[head tinderbox] failure on mips/mips

2013-11-06 Thread FreeBSD Tinderbox
TB --- 2013-11-07 00:17:49 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2013-11-07 00:17:49 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-11-07 00:17:49 - starting HEAD tinderbox run for mips/mips
TB --- 2013-11-07 00:17:49 - cleaning the object tree
TB --- 2013-11-07 00:17:49 - /usr/local/bin/svn stat /src
TB --- 2013-11-07 00:18:09 - At svn revision 257753
TB --- 2013-11-07 00:18:10 - building world
TB --- 2013-11-07 00:18:10 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 00:18:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 00:18:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 00:18:10 - SRCCONF=/dev/null
TB --- 2013-11-07 00:18:10 - TARGET=mips
TB --- 2013-11-07 00:18:10 - TARGET_ARCH=mips
TB --- 2013-11-07 00:18:10 - TZ=UTC
TB --- 2013-11-07 00:18:10 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 00:18:10 - cd /src
TB --- 2013-11-07 00:18:10 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Thu Nov  7 00:18:18 UTC 2013
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 World build completed on Thu Nov  7 01:20:56 UTC 2013
TB --- 2013-11-07 01:20:56 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:20:56 - /usr/sbin/config -m ADM5120
TB --- 2013-11-07 01:20:56 - skipping ADM5120 kernel
TB --- 2013-11-07 01:20:56 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:20:56 - /usr/sbin/config -m ALCHEMY
TB --- 2013-11-07 01:20:56 - skipping ALCHEMY kernel
TB --- 2013-11-07 01:20:56 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:20:56 - /usr/sbin/config -m ALFA_HORNET_UB
TB --- 2013-11-07 01:20:56 - building ALFA_HORNET_UB kernel
TB --- 2013-11-07 01:20:56 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 01:20:56 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 01:20:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 01:20:56 - SRCCONF=/dev/null
TB --- 2013-11-07 01:20:56 - TARGET=mips
TB --- 2013-11-07 01:20:56 - TARGET_ARCH=mips
TB --- 2013-11-07 01:20:56 - TZ=UTC
TB --- 2013-11-07 01:20:56 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 01:20:56 - cd /src
TB --- 2013-11-07 01:20:56 - /usr/bin/make -B buildkernel 
KERNCONF=ALFA_HORNET_UB
 Kernel build for ALFA_HORNET_UB started on Thu Nov  7 01:20:56 UTC 2013
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for ALFA_HORNET_UB completed on Thu Nov  7 01:24:03 UTC 2013
TB --- 2013-11-07 01:24:03 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:24:03 - /usr/sbin/config -m AP121
TB --- 2013-11-07 01:24:03 - building AP121 kernel
TB --- 2013-11-07 01:24:03 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 01:24:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 01:24:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 01:24:03 - SRCCONF=/dev/null
TB --- 2013-11-07 01:24:03 - TARGET=mips
TB --- 2013-11-07 01:24:03 - TARGET_ARCH=mips
TB --- 2013-11-07 01:24:03 - TZ=UTC
TB --- 2013-11-07 01:24:03 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 01:24:03 - cd /src
TB --- 2013-11-07 01:24:03 - /usr/bin/make -B buildkernel KERNCONF=AP121
 Kernel build for AP121 started on Thu Nov  7 01:24:03 UTC 2013
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for AP121 completed on Thu Nov  7 01:26:59 UTC 2013
TB --- 2013-11-07 01:26:59 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:26:59 - /usr/sbin/config -m AP91
TB --- 2013-11-07 01:26:59 - building AP91 kernel
TB --- 2013-11-07 01:26:59 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 01:26:59 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 01:26:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 01:26:59 - SRCCONF=/dev/null
TB --- 2013-11-07 01:26:59 - TARGET=mips
TB --- 2013-11-07 01:26:59 - TARGET_ARCH=mips
TB --- 2013-11-07 01:26:59 - TZ=UTC
TB --- 2013-11-07 01:26:59 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 01:26:59 - cd /src
TB --- 2013-11-07 01:26:59 - /usr/bin/make -B buildkernel KERNCONF=AP91
 Kernel build for AP91 started on Thu Nov  7 01:27:00 UTC 2013
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for AP91 completed on Thu Nov  7 01:31:00 UTC 2013
TB --- 2013-11-07 01:31:00 - cd /src/sys/mips/conf
TB --- 2013-11-07 01:31:00 - /usr/sbin/config -m AP93
TB --- 2013-11-07 

Re: dhclient failure with Realtek 8111E Ethernet on new MSI motherboard

2013-11-06 Thread Thomas Mueller
I tried the patch on 9.2-STABLE, rebuilt the kernel and modules, installed to 
the correct place on USB stick, 
/media/zip0/boot/kernelre
USB stick was mounted on /media/zip0 when I did this.

Then I umounted, took the USB stick to new computer with MSI Z77 MPOWER 
motherboard.

I booted that USB stick, escaped to loader prompt, unload and
boot /boot/kernelre/kernel

got the same error when running dhclient re0.

Now I also have to update NetBSD-current and then build a Linux installation.

Linux may offer a better chance of configuring wireless adapters.

I was hoping a fix to the re(4) bug could make it for FreeBSD 10.0-RELEASE but 
am not betting on it.


Tom

___
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: cron(8) improvement

2013-11-06 Thread Allan Jude
On 2013-11-06 20:49, Mark Felder wrote:

 On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
 On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:

 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.

 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.

 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.
 This is a good idea.  We should do it.

 How and if this facility gets used is a separate question.

 Tools, not policy.

 Support for a cron.d directory is a tool that can be
 used in many ways.  The policy of how it should be
 used is a separate discussion.  (For example, whether
 or not ports or packages should install crontab files into
 /usr/local/etc/cron.d/ can be richly debated after that
 directory exists.)

 Ok, so we create that directory. Now nobody can use it in a port until
 FreeBSD 8.4 is EoL -- approximately June 30, 2015.

 We should be using the existing cron tabs directory *now*. We can't
 easily force older versions of FreeBSD to update their cron software or
 configuration to support that new directory.

 I'm not saying we shouldn't create it, just that we can't effectively
 use it for 2 years.
 ___
 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
My use case is less about packages, and more about puppet, ansible etc.
Puppet relies on these hideously large markers in the crontab files to
programmatically add/remove crons, whereas a cron.d directory could be
done nice and clean

And in that case, the fact that it is not supported on 8.x does not
bother me.

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature


Re: [Review] bsdconfig pkgng integration

2013-11-06 Thread Teske, Devin

On Nov 6, 2013, at 5:13 PM, Teske, Devin wrote:

 
 On Nov 6, 2013, at 5:02 PM, Glen Barber wrote:
 
 On Thu, Nov 07, 2013 at 12:48:02AM +, Teske, Devin wrote:
 I think that you're thinking that:
 
 pkg.eu.freebsd.org
 pkg.us-east.freebsd.org
 pkg.us-west.freebsd.org
 
 Will somehow change?
 
 I think you're thinking they *won't* change.  Don't assume.
 
 
 Well, what *kind* of change?
 
 Changes to what they serve should be no problem...
 
 but what I was assuming that wouldn't change was
 their actual names. (e.g. pkg.eu stays pkg.eu).
 
 Couldn't care about any other change, because that
 would percolate at runtime off the DNS servers.

We concluded that despite the fact that pkg.* are officially
supported names, a POLA issue has been brought to the
top of the discussion.

That is to say, that the concern is that someone may choose
pkg.eu or pkg.us-* and then become astonished if/when
that name mirror is down (precisely because we do not yet
have geodns and because the pkg.{eu,us-*} names are
currently one-to-one mappings).

So in that spirit, we move forward with only the pkg.f.o entry.
-- 
Devin

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: cron(8) improvement

2013-11-06 Thread Kimmo Paasiala
On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude free...@allanjude.com wrote:
 On 2013-11-06 20:49, Mark Felder wrote:

 On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
 On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:

 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.

 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.

 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.
 This is a good idea.  We should do it.

 How and if this facility gets used is a separate question.

 Tools, not policy.

 Support for a cron.d directory is a tool that can be
 used in many ways.  The policy of how it should be
 used is a separate discussion.  (For example, whether
 or not ports or packages should install crontab files into
 /usr/local/etc/cron.d/ can be richly debated after that
 directory exists.)

 Ok, so we create that directory. Now nobody can use it in a port until
 FreeBSD 8.4 is EoL -- approximately June 30, 2015.

 We should be using the existing cron tabs directory *now*. We can't
 easily force older versions of FreeBSD to update their cron software or
 configuration to support that new directory.

 I'm not saying we shouldn't create it, just that we can't effectively
 use it for 2 years.
 ___
 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
 My use case is less about packages, and more about puppet, ansible etc.
 Puppet relies on these hideously large markers in the crontab files to
 programmatically add/remove crons, whereas a cron.d directory could be
 done nice and clean

 And in that case, the fact that it is not supported on 8.x does not
 bother me.

 --
 Allan Jude



What's wrong with using the existing tools for achieving the same
effect? Periodic can be adapted to do exactly what you're describing
as noted above by adding an hourly (even minutely? :D ) periodic run.
Also periodic already has support for ports installing their own jobs
under /usr/local/etc/periodic.d that can be enabled/disabled in
periodic.conf.

-Kimmo
___
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: cron(8) improvement

2013-11-06 Thread Allan Jude
On 2013-11-06 22:49, Kimmo Paasiala wrote:
 On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude free...@allanjude.com wrote:
 On 2013-11-06 20:49, Mark Felder wrote:
 On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote:
 On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote:

 This came up in discussion on IRC and I thought I should throw it at the
 list so I don't forget.

 A user was asking how to do what linux cron does, where there is a
 directory /etc/cron.d/ that packages and add files to to create crontabs.

 Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
 /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
 useful feature, especially for pkg(8) as it makes it easy and safe to
 programatically add and remove crontabs as part of a package.
 This is a good idea.  We should do it.

 How and if this facility gets used is a separate question.

 Tools, not policy.

 Support for a cron.d directory is a tool that can be
 used in many ways.  The policy of how it should be
 used is a separate discussion.  (For example, whether
 or not ports or packages should install crontab files into
 /usr/local/etc/cron.d/ can be richly debated after that
 directory exists.)

 Ok, so we create that directory. Now nobody can use it in a port until
 FreeBSD 8.4 is EoL -- approximately June 30, 2015.

 We should be using the existing cron tabs directory *now*. We can't
 easily force older versions of FreeBSD to update their cron software or
 configuration to support that new directory.

 I'm not saying we shouldn't create it, just that we can't effectively
 use it for 2 years.
 ___
 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
 My use case is less about packages, and more about puppet, ansible etc.
 Puppet relies on these hideously large markers in the crontab files to
 programmatically add/remove crons, whereas a cron.d directory could be
 done nice and clean

 And in that case, the fact that it is not supported on 8.x does not
 bother me.

 --
 Allan Jude


 What's wrong with using the existing tools for achieving the same
 effect? Periodic can be adapted to do exactly what you're describing
 as noted above by adding an hourly (even minutely? :D ) periodic run.
 Also periodic already has support for ports installing their own jobs
 under /usr/local/etc/periodic.d that can be enabled/disabled in
 periodic.conf.

 -Kimmo
Programmatically installing a cron that runs at odd intervals (our use
case, on minutes 9,24,39,54 of each hour, manually staggered across
groups of hosts). To enable a new periodic run, you have to edit the
/etc/crontab file. I could add my cronjobs there directly, or via the
crontab command (how puppet does it now), but i'd rather drop files in a
directory, so they can be more easily removed or updated.

From a management perspective, when dealing with 100s of machines, it is
just a much nicer way to do it.

-- 
Allan Jude




signature.asc
Description: OpenPGP digital signature


Re: cron(8) improvement

2013-11-06 Thread Lyndon Nerenberg

On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com wrote:

 What's wrong with using the existing tools for achieving the same
 effect? Periodic can be adapted to do exactly what you're describing
 as noted above by adding an hourly (even minutely? :D ) periodic run.

Periodic is geared towards periodic system maintenance tasks.  Once per day, 
once per week, once per month.  It doesn't deal with tasks that need to be 
fired off at arbitrary intervals.

As you say, it could be adapted to run things with per-minute granularity, but 
it wouldn't scale well.  For per-minute granularity you would have to fire off 
a periodic run every minute.  That's five times the rate that atrun(8) kicks 
off at.  That's a lot of overhead for small, embedded, or power constrained 
systems.  And to get the time-granularity cron has, you would have to 
re-implement cron(8)s dispatch control as a set of shell functions.  That's 
just silly.


--lyndon


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


[head tinderbox] failure on arm/arm

2013-11-06 Thread FreeBSD Tinderbox
TB --- 2013-11-07 05:30:18 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2013-11-07 05:30:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-11-07 05:30:18 - starting HEAD tinderbox run for arm/arm
TB --- 2013-11-07 05:30:18 - cleaning the object tree
TB --- 2013-11-07 05:30:18 - /usr/local/bin/svn stat /src
TB --- 2013-11-07 05:30:23 - At svn revision 257778
TB --- 2013-11-07 05:30:24 - building world
TB --- 2013-11-07 05:30:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 05:30:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 05:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 05:30:24 - SRCCONF=/dev/null
TB --- 2013-11-07 05:30:24 - TARGET=arm
TB --- 2013-11-07 05:30:24 - TARGET_ARCH=arm
TB --- 2013-11-07 05:30:24 - TZ=UTC
TB --- 2013-11-07 05:30:24 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 05:30:24 - cd /src
TB --- 2013-11-07 05:30:24 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Thu Nov  7 05:30:30 UTC 2013
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
[...]
  ^
/src/lib/msun/src/s_roundl.c:45:2: error: no member named 'expsign' in 'struct 
IEEEl2bits::anonymous at /src/lib/msun/../libc/arm/_fpmath.h:37:2'
GET_LDBL_EXPSIGN(hx, x);
^~~
/src/lib/msun/src/math_private.h:224:20: note: expanded from macro 
'GET_LDBL_EXPSIGN'
  (i) = ge_u.xbits.expsign; \
~~ ^
2 errors generated.
*** Error code 1

Stop.
bmake[3]: stopped in /src/lib/msun
*** Error code 1

Stop.
bmake[2]: stopped in /src
*** Error code 1

Stop.
bmake[1]: stopped in /src
*** Error code 1

Stop.
bmake: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-11-07 06:55:40 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-11-07 06:55:40 - ERROR: failed to build world
TB --- 2013-11-07 06:55:40 - 4190.69 user 723.15 system 5121.65 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[head tinderbox] failure on armv6/arm

2013-11-06 Thread FreeBSD Tinderbox
TB --- 2013-11-07 05:30:18 - tinderbox 2.20 running on freebsd-current.sentex.ca
TB --- 2013-11-07 05:30:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-11-07 05:30:18 - starting HEAD tinderbox run for armv6/arm
TB --- 2013-11-07 05:30:18 - cleaning the object tree
TB --- 2013-11-07 05:30:18 - /usr/local/bin/svn stat /src
TB --- 2013-11-07 05:30:23 - At svn revision 257778
TB --- 2013-11-07 05:30:24 - building world
TB --- 2013-11-07 05:30:24 - CROSS_BUILD_TESTING=YES
TB --- 2013-11-07 05:30:24 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-11-07 05:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-11-07 05:30:24 - SRCCONF=/dev/null
TB --- 2013-11-07 05:30:24 - TARGET=arm
TB --- 2013-11-07 05:30:24 - TARGET_ARCH=armv6
TB --- 2013-11-07 05:30:24 - TZ=UTC
TB --- 2013-11-07 05:30:24 - __MAKE_CONF=/dev/null
TB --- 2013-11-07 05:30:24 - cd /src
TB --- 2013-11-07 05:30:24 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Thu Nov  7 05:30:30 UTC 2013
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
[...]
  ^
/src/lib/msun/src/s_roundl.c:45:2: error: no member named 'expsign' in 'struct 
IEEEl2bits::anonymous at /src/lib/msun/../libc/arm/_fpmath.h:37:2'
GET_LDBL_EXPSIGN(hx, x);
^~~
/src/lib/msun/src/math_private.h:224:20: note: expanded from macro 
'GET_LDBL_EXPSIGN'
  (i) = ge_u.xbits.expsign; \
~~ ^
2 errors generated.
*** Error code 1

Stop.
bmake[3]: stopped in /src/lib/msun
*** Error code 1

Stop.
bmake[2]: stopped in /src
*** Error code 1

Stop.
bmake[1]: stopped in /src
*** Error code 1

Stop.
bmake: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-11-07 06:55:42 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-11-07 06:55:42 - ERROR: failed to build world
TB --- 2013-11-07 06:55:42 - 4192.94 user 722.34 system 5124.06 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-armv6-arm.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org