On Thu, Dec 19, 2013 at 07:54:41PM +0100, Roger Pau Monne wrote:
> ---
> sys/amd64/amd64/machdep.c | 45 +
> sys/amd64/include/sysarch.h | 12 +
> sys/conf/files.amd64|1 +
This looks fine for me.
pgpKHSZIJtBoR.pgp
Description: PGP signature
Guys,
Id like to work a bit on this issue in my free time, I have 2 weeks
holiday
after Xmass.
First an update on lagg for the case you boot with wired coupled:
1. I previously said lagg0 switches correctly when I unplug the wired
interface, but it is not so. It appeared so because I used "if
I have a faulty pool with an ambiguous label and I tried to resolve
that problem. ZFS is at the moment highly active copying data from
several volumes to another.
Operating system:
11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET
2013 amd64
In one terminal I exported the po
On 2013-12-20 05:55, O. Hartmann wrote:
> I have a faulty pool with an ambiguous label and I tried to resolve
> that problem. ZFS is at the moment highly active copying data from
> several volumes to another.
>
> Operating system:
>
> 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:1
On 12/19/2013 06:54 PM, Roger Pau Monne wrote:
Add the PV/PVH entry point and the low level functions for PVH
initialization.
---
sys/amd64/amd64/locore.S | 53 +++
sys/amd64/amd64/machdep.c| 72 ++
sys/amd64/in
Hi!
On 20 December 2013 01:52, dan_partelly wrote:
> Guys,
>
>
> Id like to work a bit on this issue in my free time, I have 2 weeks
> holiday
> after Xmass.
>
> First an update on lagg for the case you boot with wired coupled:
>
> 1. I previously said lagg0 switches correctly when I unplug the w
On 2013-12-20 01:44, Mikhail T. wrote:
> It would appear, neither nor are any longer available
> on
> FreeBSD current and 10.x
>
> This breaks the devel/tcl-trf port, which I maintain... Could someone, please,
> comment? Should I patch-up the port to disable the functionality? Or?..
>
> Thank
On Fri, Dec 20, 2013 at 3:55 AM, O. Hartmann
wrote:
>
> I have a faulty pool with an ambiguous label and I tried to resolve
> that problem. ZFS is at the moment highly active copying data from
> several volumes to another.
>
> Operating system:
>
> 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue
On 2013-12-20 19:04, Mikhail T. wrote:
> On 20.12.2013 12:52, olli hauer wrote:
>> Hm the config script tests for md2 and sha1 ...
>> What happens if md2 support is removed from the code?
> Yes, the md2 can be removed from the set of digests made available by the port
> -- that's not a problem.
>
On 20.12.2013 12:52, olli hauer wrote:
> Hm the config script tests for md2 and sha1 ...
> What happens if md2 support is removed from the code?
Yes, the md2 can be removed from the set of digests made available by the port
-- that's not a problem.
What I wanted to know, was why? Maybe, the header
ping !
___
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"
On Fri, 20 Dec 2013 11:23:25 -0700
Alan Somers wrote:
> On Fri, Dec 20, 2013 at 3:55 AM, O. Hartmann
> wrote:
> >
> > I have a faulty pool with an ambiguous label and I tried to resolve
> > that problem. ZFS is at the moment highly active copying data from
> > several volumes to another.
> >
> >
When using 'WITHOUT_CAPSICUM=YES', 'WITHOUT_CASPER=YES' my nanobsd builds in
a Virtualbox VM (i386, march=geode, GENERIC without debug+Witness et. al.)
fail buildworld for any revision from at least r259518-r259661; like so
(this example is r259661):
" ...
===> lib/clang/libllvmsupport (obj,de
Index: addrtoname.c
===
--- addrtoname.c (revision 259658)
+++ addrtoname.c (working copy)
@@ -33,9 +33,11 @@
#endif
#ifdef __FreeBSD__
+#ifdef HAVE_LIBCAPSICUM
#include
#include
#endif
+#endif
#include
#ifdef USE_ETHER
Hi,
Please file a PR and then ask the developer (pjd@) very nicely to take
a look at it.
Thanks,
-adrian
On 20 December 2013 12:45, Stefan Hegnauer wrote:
> When using 'WITHOUT_CAPSICUM=YES', 'WITHOUT_CASPER=YES' my nanobsd builds in
> a Virtualbox VM (i386, march=geode, GENERIC without debu
Thinking more about the MD2, I'd say, FreeBSD should not have removed the
algorithm.
Although no longer deemed sufficiently secure, it is still in use and people
using it on FreeBSD-8.x and 9.x today may wish to continue doing so after
upgrading to 10.x
In the old "Mechanism vs. Policy" debate
<
Hi there,
thanks for your support. PR 185052 is filed and should be visible soon -
please let me know if I can help in any way (more info, testing, whatever).
Thanks again
Stefan
> From: adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] On Behalf
> Of Adrian Chadd
> Sent: Friday, December
17 matches
Mail list logo
