Re: cron(8) improvement
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
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
--- /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 @@ "\017" "\020LWP"/* Lightweight Profiling */ "\021FMA4"/* 4-operand FMA instructions */ -"\022" +"\022TCE"/* Translation Cache Extension */ "\023" "\024NodeId"/* NodeId MSR support */ "\025" "\026TBM"/* Trailing Bit Manipulation */ "\027Topology"/* Topology Extensions */ -"\030" -"\031" +"\030PCXC"/* Core performance counter extensions */ +"\031PNXC"/* NB performance counter extensions */ "\032" "\033" "\034" ___ 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
--- /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
--- /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
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
On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff 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 >: > 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
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
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
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 BethkeFon +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
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
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 @@ > "\017" > "\020LWP"/* Lightweight Profiling */ > "\021FMA4"/* 4-operand FMA instructions */ > -"\022" > +"\022TCE"/* Translation Cache Extension */ > "\023" > "\024NodeId"/* NodeId MSR support */ > "\025" > "\026TBM"/* Trailing Bit Manipulation */ > "\027Topology"/* Topology Extensions */ > -"\030" > -"\031" > +"\030PCXC"/* Core performance counter extensions */ > +"\031PNXC"/* NB performance counter extensions */ > "\032" > "\033" > "\034" 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
On Wed, Nov 6, 2013 at 3:59 PM, Erwin Lansing wrote: > > > On 06/11/2013, at 14.22, George Kontostanos > wrote: > > On Mon, Nov 4, 2013 at 6:34 PM, Gleb Smirnoff 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
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
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
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
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 @@ > "\017" > "\020LWP"/* Lightweight Profiling */ > "\021FMA4"/* 4-operand FMA instructions */ > -"\022" > +"\022TCE"/* Translation Cache Extension */ > "\023" > "\024NodeId"/* NodeId MSR support */ > "\025" > "\026TBM"/* Trailing Bit Manipulation */ > "\027Topology"/* Topology Extensions */ > -"\030" > -"\031" > +"\030PCXC"/* Core performance counter extensions */ > +"\031PNXC"/* NB performance counter extensions */ > "\032" > "\033" > "\034" 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
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
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
.. 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 , 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
On Wed, Nov 6, 2013 at 9:12 AM, O. Hartmann 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
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
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
On Nov 5, 2013, at 7:54 PM, Craig Rodrigues wrote: > > > > On Sat, Nov 2, 2013 at 10:59 AM, Teske, Devin > 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
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
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
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
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
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
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
On Tue, Oct 29, 2013 at 2:13 PM, hiren panchasara wrote: > On Tue, Oct 29, 2013 at 8:00 AM, Mark Felder wrote: >> >> 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
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
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
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
On Nov 5, 2013, at 9:31 AM, 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. 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
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
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 rec
Re: [Review] bsdconfig pkgng integration
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
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
> 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
On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: > > On Nov 5, 2013, at 9:31 AM, 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. > > 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
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
Re: dhclient failure with Realtek 8111E Ethernet on new MSI motherboard
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
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 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
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
On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude 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 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
On 2013-11-06 22:49, Kimmo Paasiala wrote: > On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude 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 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
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala 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
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::' 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
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::' 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"
