Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On Wed, Jun 15, 2016 at 10:15 PM, Marcelo Araujo wrote: > No worries Nikolai! If one day I will do it, will be on 12-RELEASE. > > Br, > > 2016-06-15 20:03 GMT+08:00 Nikolai Lifanov : > > > On 06/14/2016 21:05, Marcelo Araujo wrote: > > >

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

No worries Nikolai! If one day I will do it, will be on 12-RELEASE. Br, 2016-06-15 20:03 GMT+08:00 Nikolai Lifanov : > On 06/14/2016 21:05, Marcelo Araujo wrote: > > 2016-06-15 8:17 GMT+08:00 Chris H : > > > >> On Thu, 9 Jun 2016 17:55:58 +0800

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 06/14/2016 21:05, Marcelo Araujo wrote: > 2016-06-15 8:17 GMT+08:00 Chris H : > >> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo >> wrote >> >>> Hey, >>> >>> Thanks for the CFT Craig. >>> >>> 2016-06-09 14:41 GMT+08:00 Xin Li

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

> On 15 Jun 2016, at 04:22, David Wolfskill wrote: > > On Tue, Jun 14, 2016 at 05:17:19PM -0700, Chris H wrote: >> ... >> Honestly, I think the best way to motivate people to do the right thing(tm) >> Would be to remove Yellow Pages from the tree, entirely. :-) >> It's

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On Tue, Jun 14, 2016 at 05:17:19PM -0700, Chris H wrote: > ... > Honestly, I think the best way to motivate people to do the right thing(tm) > Would be to remove Yellow Pages from the tree, entirely. :-) > It's been dead for *years*, and as you say, isn't safe, anyway.. > "Safe" for what,

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

2016-06-15 8:17 GMT+08:00 Chris H : > On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo > wrote > > > Hey, > > > > Thanks for the CFT Craig. > > > > 2016-06-09 14:41 GMT+08:00 Xin Li : > > > > > > > > > > > On 6/8/16 23:10,

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo wrote > Hey, > > Thanks for the CFT Craig. > > 2016-06-09 14:41 GMT+08:00 Xin Li : > > > > > > > On 6/8/16 23:10, Craig Rodrigues wrote: > > > Hi, > > > > > > I have worked with Marcelo Araujo to

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 06/ 9/16 05:49 PM, Matthew Seaman wrote: > On 09/06/2016 18:34, Craig Rodrigues wrote: >> There is still value to ypldap as it is now, and getting feedback from >> users (especially Active Directory) would be very useful. >> If someone could document a configuration which uses IPSEC or OpenSSH

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 10/06/16 16:29, Peter Wemm wrote: On 6/9/16 6:49 PM, Matthew Seaman wrote: On 09/06/2016 18:34, Craig Rodrigues wrote: There is still value to ypldap as it is now, and getting feedback from users (especially Active Directory) would be very useful. If someone could document a configuration

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 6/9/16 6:49 PM, Matthew Seaman wrote: On 09/06/2016 18:34, Craig Rodrigues wrote: There is still value to ypldap as it is now, and getting feedback from users (especially Active Directory) would be very useful. If someone could document a configuration which uses IPSEC or OpenSSH forwarding,

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 09/06/2016 18:34, Craig Rodrigues wrote: > There is still value to ypldap as it is now, and getting feedback from > users (especially Active Directory) would be very useful. > If someone could document a configuration which uses IPSEC or OpenSSH > forwarding, that would be nice. > > In future,

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On Wed, Jun 8, 2016 at 11:41 PM, Xin Li wrote: > > (I think the current implementation > would do everything with plaintext protocol over wire, so while it > You are correct. This document http://puffysecurity.com/wiki/ypldap.html#2 states: # # ypldap cant use SSL

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

Hey, Thanks for the CFT Craig. 2016-06-09 14:41 GMT+08:00 Xin Li : > > > On 6/8/16 23:10, Craig Rodrigues wrote: > > Hi, > > > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD > > current. > > > > In latest current, it should be possible to put in

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

On 6/8/16 23:10, Craig Rodrigues wrote: > Hi, > > I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD > current. > > In latest current, it should be possible to put in /etc/rc.conf: > > nis_ypldap_enable="YES" > to activate the ypldap daemon. > > When set up properly, it

[CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

Hi, I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD current. In latest current, it should be possible to put in /etc/rc.conf: nis_ypldap_enable="YES" to activate the ypldap daemon. When set up properly, it should be possible to log into FreeBSD, and have the backend

[belated] call for testing: replacement ath3k firmware upload tool

hiya, I wrote a replacement ath3k bluetooth firmware upload tool, based on the ath3k driver in linux. all the driver does is inject the "right" firmware / config combination into the bluetooth chips. https://github.com/erikarn/ath3k I'd like to land this in -HEAD before 11, as it enables all of

[belated] call for testing: replacement ath3k firmware upload tool

hiya, I wrote a replacement ath3k bluetooth firmware upload tool, based on the ath3k driver in linux. all the driver does is inject the "right" firmware / config combination into the bluetooth chips. https://github.com/erikarn/ath3k I'd like to land this in -HEAD before 11, as it enables all of

Testing an importing OF PCI implementations patch

be tested on these platforms using this code to check if it does not break them. This is very essential patch for me, because it is blocking my other pending commits and I would be very grateful for testing it. Review of this code is here: https://reviews.freebsd.org/D4879 Any comments and feedback a

Re: Call for testing: Using ELF Tool Chain elfcopy as objcopy

this the default for 11.0, but first would like to ask for broader testing with the setting enabled. I'm particularly interested in hearing from anyone using the base system objcopy in unusual cases (e.g., converting ELF files to ROM images). Note that some lesser-used objcopy options (like --reverse

Re: Call for testing: Using ELF Tool Chain elfcopy as objcopy

* Ed Maste (ema...@freebsd.org) wrote: JFYI, I've just updated my desktop to 295763 with WITH_ELFCOPY_AS_OBJCOPY=yes, and rebuilt all ~800 installed ports, no problems so far. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber:

Call for testing: Using ELF Tool Chain elfcopy as objcopy

like to ask for broader testing with the setting enabled. I'm particularly interested in hearing from anyone using the base system objcopy in unusual cases (e.g., converting ELF files to ROM images). Note that some lesser-used objcopy options (like --reverse-bytes or --interleave-width

Re: Request for testing bus_get_bus_tag() nexus method

hi, you can run mips and powerpc inside qemu emulators. There's no reason to not test it! -adrian On 5 February 2016 at 08:11, Marcin Mazurek wrote: > Hello, > > I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some > platforms nexus that return per

Request for testing bus_get_bus_tag() nexus method

Hello, I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some platforms nexus that return per platform specific default tag. It works fine on arm, but I do not have any powerpc or mips hardware to test it on, so I would like it if this could be tested on these platforms using

Re: Request for testing bus_get_bus_tag() nexus method

On Friday, February 05, 2016 05:11:19 PM Marcin Mazurek wrote: > Hello, > > I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some > platforms nexus that return per platform specific default tag. > > It works fine on arm, but I do not have any powerpc or mips hardware to >

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

On Thu, Jun 04, 2015 at 09:21:06PM +0300, Gleb Smirnoff wrote: I've uploaded updated patch that should fix this issue. Please try it and report once you have time. With this version of the patch everything is working as expected again, thanks for your efforts. Regards -- Michael Moll

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

On Wed, Jun 03, 2015 at 09:51:56PM +0200, Michael Moll wrote: M All working well, the only thing I'm seeing is that a shutdown or reboot M is hanging, tracing via kdb shows: I've uploaded updated patch that should fix this issue. Please try it and report once you have time. Thanks a lot! --

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

On Wed, Jun 03, 2015 at 09:51:56PM +0200, Michael Moll wrote: M All working well, the only thing I'm seeing is that a shutdown or reboot M is hanging, tracing via kdb shows: M M Tracing command wpa_supplicant pid 293 tid 100075 td 0xc81b7960 M sched_switch(c81b7960,0,104,0,0,...) at

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

Hi, On Wed, Jun 03, 2015 at 01:42:22PM +0300, Gleb Smirnoff wrote: M This already is resulting in a working connection. I'll test more M extensively tomorrow and report back. Thanks a lot. Please check that 'netstat -hI wlan0 1' reports sane data about packets and bytes. All working well,

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

On Wed, Jun 03, 2015 at 09:51:56PM +0200, Michael Moll wrote: M On Wed, Jun 03, 2015 at 01:42:22PM +0300, Gleb Smirnoff wrote: M M This already is resulting in a working connection. I'll test more M M extensively tomorrow and report back. M M Thanks a lot. Please check that 'netstat -hI wlan0

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

Michael, On Wed, Jun 03, 2015 at 01:35:01AM +0200, Michael Moll wrote: M I have fixed the bug in head, and updated the phab revision. The current M phab revision will apply only to the fresh head. M M Please retry! And thanks a lot for your efforts. :) M M This already is resulting in a

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

Hi, On Wed, Jun 03, 2015 at 01:48:06AM +0300, Gleb Smirnoff wrote: On Tue, Jun 02, 2015 at 11:47:36PM +0200, Michael Moll wrote: M On Tue, Jun 02, 2015 at 07:20:21PM +0300, Gleb Smirnoff wrote: M I've converted iwi(4) and refreshed the D2655. I will appreciate M if you test it. Please

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

Oliver, On Mon, Jun 01, 2015 at 10:46:33PM +0200, Oliver Pinter wrote: O In ath case I got some LOR during boot and during kismet, see the O attached dmesgs. I've fixed the first one. But I believe the second LOR happens on unmodified head as well. Thanks a lot for your help. -- Totus tuus,

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

Hi, On Tue, Jun 02, 2015 at 07:20:21PM +0300, Gleb Smirnoff wrote: I've converted iwi(4) and refreshed the D2655. I will appreciate if you test it. Please report if there are any problems. Thanks! Some seconds after bringing it up I'm getting: kernel trap 12 with interrupts disabled Fatal

Re: converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

On Tue, Jun 02, 2015 at 11:47:36PM +0200, Michael Moll wrote: M On Tue, Jun 02, 2015 at 07:20:21PM +0300, Gleb Smirnoff wrote: M I've converted iwi(4) and refreshed the D2655. I will appreciate M if you test it. Please report if there are any problems. Thanks! M M Some seconds after bringing it

converted iwi(4) for testing Was: [Testers needed!] WiFi drivers changes

Michael, I've converted iwi(4) and refreshed the D2655. I will appreciate if you test it. Please report if there are any problems. Thanks! https://reviews.freebsd.org/D2655 -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list

converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

Hi! I've converted the ath(4), probably the most complex ieee80211 driver. The updated diff is uploaded to https://reviews.freebsd.org/D2655. Pretty sure it will panic or fail on first try :) Nevertheless, asking for your help. Please try to run it and report any problems to me. -- Totus

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote: Hi! I've converted the ath(4), probably the most complex ieee80211 driver. The updated diff is uploaded to https://reviews.freebsd.org/D2655. Pretty sure it will panic or fail on first try :) Nevertheless, asking

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Mon, Jun 1, 2015 at 9:55 PM, Oliver Pinter oliver.pin...@hardenedbsd.org wrote: On Mon, Jun 1, 2015 at 9:47 PM, Oliver Pinter oliver.pin...@hardenedbsd.org wrote: On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote: Hi! I've converted the ath(4), probably the most

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01.06.2015 18:37, Gleb Smirnoff wrote: I've converted the ath(4), probably the most complex ieee80211 driver. The updated diff is uploaded to https://reviews.freebsd.org/D2655. Pretty sure it will panic or fail on first try :)

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Mon, Jun 1, 2015 at 9:47 PM, Oliver Pinter oliver.pin...@hardenedbsd.org wrote: On Mon, Jun 1, 2015 at 5:37 PM, Gleb Smirnoff gleb...@freebsd.org wrote: Hi! I've converted the ath(4), probably the most complex ieee80211 driver. The updated diff is uploaded to

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01.06.2015 22:55, Oliver Pinter wrote: Do you have compile tested the code? I got this build error: also, here are bunch of things like this: DPRINTF(sc, ATH_DEBUG_ANY, %s: if_flags %x\n, __func__, ifp-if_flags); - -- // Lev

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01.06.2015 23:46, Oliver Pinter wrote: One confusing thing, that the underlaying devices (ath0 and iwn0) has gone from ifconfig, and that's a little confusing, when you have multiple pci card and try to create multiple VAP to specific

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Tue, Jun 02, 2015 at 12:00:46AM +0300, Lev Serebryakov wrote: L One confusing thing, that the underlaying devices (ath0 and iwn0) L has gone from ifconfig, and that's a little confusing, when you L have multiple pci card and try to create multiple VAP to specific L device. L I think, it is

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02.06.2015 00:20, Gleb Smirnoff wrote: On Tue, Jun 02, 2015 at 12:00:46AM +0300, Lev Serebryakov wrote: L One confusing thing, that the underlaying devices (ath0 and iwn0) L has gone from ifconfig, and that's a little confusing, when you L

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Mon, Jun 01, 2015 at 10:46:33PM +0200, Oliver Pinter wrote: O And the same test against my atheros seems like working fine, both the O secondary VAP creation and destruction. I'm able to run kismet without O panic, and that seems too working fine. Thanks a lot! O In ath case I got some LOR

Re: converted ath(4) for testing Was: [Testers needed!] WiFi drivers changes

On Tue, Jun 02, 2015 at 12:33:13AM +0300, Lev Serebryakov wrote: L On Tue, Jun 02, 2015 at 12:00:46AM +0300, Lev Serebryakov wrote: L L One confusing thing, that the underlaying devices (ath0 and L iwn0) L has gone from ifconfig, and that's a little confusing, L when you L have multiple pci

Re: [CFT] Call for testing pkg 1.5.0

On 2015-03-31 20:24, Sergei Vyshenski wrote: Hi, On Tue, Mar 31, 2015 at 9:23 PM, Baptiste Daroussin b...@freebsd.org wrote: Add WITH_PKG=devel in your build make.conf then pkg upgrade will want you to upgrade to 1.4.99.16 (which is pkg 1.5.0 beta1) This does not work for me. #

Re: [CFT] Call for testing pkg 1.5.0

On Fri, Apr 03, 2015 at 02:35:43PM +0100, Big Lebowski wrote: Please test and report as much bugs as you can! We could be very grateful if regressions tests could be provided along with the bug reports :) Mine just did something like that: foobar# uname -a FreeBSD foobar.org

Re: [CFT] Call for testing pkg 1.5.0

I just wanted to take the time to thank you for all the work you've put into this. Thanks! Thanks much appreciated, I want to share that with vsevolod@ and az@ who also spent a lot of time working on it! Indeed, HUGE THANKS for what you guys are doing with pkg - I cant wait to see that OS

Re: [CFT] Call for testing pkg 1.5.0

Please test and report as much bugs as you can! We could be very grateful if regressions tests could be provided along with the bug reports :) Mine just did something like that: foobar# uname -a FreeBSD foobar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280994M: Thu Apr 2 20:16:53 CEST

Re: [CFT] Call for testing pkg 1.5.0

On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin b...@freebsd.org wrote Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), .. Please test and report as much bugs as you can! We could be very grateful if regressions tests could be provided along with the bug reports

Re: [CFT] Call for testing pkg 1.5.0

On Thu, Apr 02, 2015 at 07:21:19AM -0700, Chris H wrote: On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin b...@freebsd.org wrote Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), .. Please test and report as much bugs as you can! We could be very grateful

Re: [CFT] Call for testing pkg 1.5.0

On Wed, Apr 01, 2015 at 11:48:27AM +, Thomas Mueller wrote: Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is

Re: [CFT] Call for testing pkg 1.5.0

Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is such a plan in the works? EdjeBSD should be EdgeBSD. A little

Re: [CFT] Call for testing pkg 1.5.0

On Mar 31, 2015, at 17:24, Sergei Vyshenski svysh.f...@gmail.com wrote: Instead, the following succeded: # cd /usr/ports/ports-mgmt/pkg-devel # make reinstall ... # pkg -v 1.4.99.16 That is expected. WITH_PKG=devel is a make(1) option that only affects ports (non-binary pkgs). -- Rui

Re: [CFT] Call for testing pkg 1.5.0

) and there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the stable version. This is how I've been testing pkg-devel for a while. Is there a different recommended way? David ___ freebsd-current

Re: [CFT] Call for testing pkg 1.5.0

never build ports manually (and don't even have a ports tree installed) and there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the stable version. This is how I've been testing pkg-devel for a while. Is there a different recommended

Re: [CFT] Call for testing pkg 1.5.0

Hi, On Tue, Mar 31, 2015 at 9:23 PM, Baptiste Daroussin b...@freebsd.org wrote: Add WITH_PKG=devel in your build make.conf then pkg upgrade will want you to upgrade to 1.4.99.16 (which is pkg 1.5.0 beta1) This does not work for me. # cat /etc/make.conf |grep PKG WITH_PKGNG=yes

[CFT] Call for testing pkg 1.5.0

Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Here is what happened since pkg 1.4.0: - pkg has grown with an initial support for provides/requires: this is a naive version but good enough to at least make major upgrade of php safer as well as making pear/pecl

Re: [CFT] Call for testing pkg 1.5.0

On Tue, Mar 31, 2015 at 03:19:15PM -0400, Shawn Webb wrote: On Tue, 2015-03-31 at 21:03 +0200, Baptiste Daroussin wrote: Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Hey Baptiste, Great work to you and all those involved in this project! I'm grateful to have

Re: [CFT] Call for testing pkg 1.5.0

On Tue, 2015-03-31 at 21:03 +0200, Baptiste Daroussin wrote: Hi all, We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel), Hey Baptiste, Great work to you and all those involved in this project! I'm grateful to have such an awesome tool. For those of us who run our own package repos

Re: Request for testing an alternate branch

? However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper

Re: Request for testing an alternate branch

machine will get ability to sleep under the FreeBSD now? However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

Hi, I finally fired this up on an older Intel to test. this is patch 8 from your website: vgapci0@pci0:0:2:0: class=0x03 card=0x20e417aa chip=0x2a428086 rev=0x07 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 4 Series Chipset Integrated Graphics Controller'

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

Nope, spoke too soon: Unread portion of the kernel message buffer: panic: In GPU write domain cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper(c09d59ce,0,c09ad9fe,205,f1ce2938,...) at db_trace_self_wrapper+0x2d/frame 0xf1ce2908 kdb_backtrace(c0a10b67,1,c82fb835,f1ce29f8,f1ce2998,...) at

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a

Re: RFT: Please help testing the llvm/clang 3.5.0 import

Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 6:34 AM, owner-freebsd-...@freebsd.org wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target

Re: RFT: Please help testing the llvm/clang 3.5.0 import

with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 6:02 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 7:44 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a

Call for testing: elftoolchain tools

* size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64

Re: Call for testing: elftoolchain tools

and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed

Re: Call for testing: elftoolchain tools

FWIW, A nice testing procedure, or even a pet project if generalized, would be to test the tools with a fuzzer like security/afl. Apparently the GNU binutils and Fedora elfutils developers having doing that [1]. Regards, Pedro. [1] https://lists.fedorahosted.org/pipermail/elfutils-devel

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6

Re: RFT: Please help testing the llvm/clang 3.5.0 import

the same toolchain N times internally when building the system and your upstream revision of FreeBSD doesn’t change is like testing your sanity — not much changes with the bootstrap compiler/toolchain then! Thanks for the reply :)! signature.asc Description: Message signed with OpenPGP using GPGMail

Re: Call for testing: elftoolchain tools

On 18 December 2014 at 11:53, Pedro Giffuni p...@freebsd.org wrote: test the tools with a fuzzer like security/afl Yes, a very good idea, especially for strings(1) given the way it is often used. I've already found a strings crash with afl. ___

Re: Call for testing: elftoolchain tools

On 2014-12-18 15:02, Ed Maste wrote: On 18 December 2014 at 11:53, Pedro Giffuni p...@freebsd.org wrote: test the tools with a fuzzer like security/afl Yes, a very good idea, especially for strings(1) given the way it is often used. I've already found a strings crash with afl.

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Dec 18, 2014, at 2:17 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target

Re: RFT: Please help testing the llvm/clang 3.5.0 import

to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able

Re: RFT: Please help testing the llvm/clang 3.5.0 import

Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: Hi, ... Hi Dimitry, As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world

Re: RFT: Please help testing the llvm/clang 3.5.0 import

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/16/2014 14:36, Dimitry Andric wrote: * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 30 Nov 2014, at 19:57, Dmitry Marakasov amd...@amdmi3.ru wrote: * Dimitry Andric (d...@freebsd.org) wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. Well, of 4 error logs from exp-run

Re: RFT: Please help testing the llvm/clang 3.5.0 import

* Dimitry Andric (d...@freebsd.org) wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. Well, of 4 error logs from exp-run I've checked (one my port and 3 unmaintained ports) two had

Re: RFT: Please help testing the llvm/clang 3.5.0 import

On 01 Dec 2014, at 18:54, Dmitry Marakasov amd...@amdmi3.ru wrote: * Dimitry Andric (d...@freebsd.org) wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. Well, of 4 error logs from exp-run

Re: RFT: Please help testing the llvm/clang 3.5.0 import

* Dimitry Andric (d...@freebsd.org) wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. Well, of 4 error logs from exp-run I've checked (one my port and 3 unmaintained ports) two had basically

RFT: Please help testing the llvm/clang 3.5.0 import

Hi, We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On Mon, Oct 27, 2014 at 12:02:11AM +0300, Chagin Dmitry wrote: On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: Use

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

This is Haswell, right? Didn't Kib say not interested in haswell testing yet ? -adrian On 26 October 2014 14:02, Chagin Dmitry dcha...@freebsd.org wrote: On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote: On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On Fri, Oct 24, 2014 at 3:03 AM, Konstantin Belousov kostik...@gmail.com wrote: Due to my mistake during the patch generation, i915.5.patch is just a garbage. Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

Hi, I can confirm v6 of the patch works for me with a r273559 kernel on a i5-3320M notebook as well. Only interesting new output to messages: Oct 25 23:11:19 kernel: error: [drm:pid1159:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 0007, was

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote: On 10/22/2014 08:26, Konstantin Belousov wrote: On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote: On 10/08/2014 13:05, Konstantin Belousov wrote: There are more occurences of the bug I fixed once in patch version

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On 10/23/2014 15:03, Konstantin Belousov wrote: Use https://www.kib.kiev.ua/kib/drm/i915.6.patch. I already have one private report of the patch worked from person who got the same panic in iicbb. Yes, this one works (does not panic) and X works! I kldloaded it after boot as I usually do.

Re: Ver 2 of the patch [was: Re: i915 driver update testing]

On Wed, Oct 08, 2014 at 03:12:08PM -0400, Adam McDougall wrote: On 10/08/2014 13:05, Konstantin Belousov wrote: There are more occurences of the bug I fixed once in patch version 2. Also, since pmap changes were committed in modified form, please try the updated patch at

<    1   2   3   4   5   6   7   8   9   10   >