Re: [HEADSUP] OpenSSL 1.0.1c merge in progress
On Thu, Jul 12, 2012 at 08:03:09PM -0400, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-12 14:04:58 -0400, Jung-uk Kim wrote: OpenSSL 1.0.1c will be merged to head today. There will be several important changes to note. - Several crypto/engine modules will be added or enabled by default to closely match OpenSSL default, e.g., Camellia (crypto), SEED (crypto), GOST (engine), etc. - MD2 will be removed because a) it is disabled by default and b) we removed it from libmd. - Optimized amd64 asm files will be added and enabled by default. - Optimized i386 asm files will be updated and new files will be added. - How did the asm files were generated (I am sure they are generated) ? opensslconf.h for amd64 and i386 will be merged. Unfortunately, library versions will be bumped, i.e., libcrypto.so.6 - libcrypto.so.7 libssl.so.6 - libssl.so.7 Therefore, all binaries depending on these need to be recompiled. Also, you may have to merge your /etc/ssl/openssl.conf changes. FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Cheers, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk//Zb0ACgkQmlay1b9qnVMDXACgxjHtAdhyLasffkaqX/Jl9hHX He0An2EjtcRoNsHfTX/ZwZ+iHz2VW2Iq =mHkt -END PGP SIGNATURE- ___ 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 pgpiTQSuyFstL.pgp Description: PGP signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
Am 13.07.12 01:10, schrieb Doug Barton: On 07/12/2012 03:02 PM, Baptiste Daroussin wrote: On Thu, Jul 12, 2012 at 11:48:41AM -0700, Doug Barton wrote: I do not mean this e-mail to be in any way critical. I was told after the new OPTIONS framework discussion that I should have asked questions before the change, so I'm asking these questions now; in a genuine attempt to get information. On 07/12/2012 03:01 AM, Baptiste Daroussin wrote: In the time that you have been working on this project I have asked numerous times for you(pl.) to answer the following questions: 1. What are the goals for pkg? The why part of this mail should reply this question, no? Well clearly not, because if it did I wouldn't keep asking the same questions over and over again. :) Anyway the goal is to have a decent package manager, providing modern features: repositories, decent dependency tracking, decent reverse dependency tracking, managing upgrade correctly (I'll explain this more later), provide a decent library for third party tools (desktop integration via PackageKit for example) I don't know what decent means. I don't know what modern features means (beyond the buzzwords that you've included). Providing easy package management for enterprise Having set up package management systems for enterprises before, *this* is actually a big-picture goal that I have a lot of sympathy for. But again, what's missing is *details* about here is what large enterprises need to make things work for them, here's why the existing tools don't meet those needs, and here is how pkg does meet them. (who never got problems managing packages on a large set of freebsd servers, and how complicated it is on FreeBSD to have automated reliable puppet,salt,chef,cfengine like tools) One of the proof of this problem is how fast people integrated pkgng in those tools. This gets to the heart of my biggest fear regarding this whole project. It's new, it's shiny, and it looks like forward progress is being made. Thus, it's attracted a lot of attention, input, time, etc. Heck, it may even BE forward progress, but I don't know how to measure that because I don't know what the goals of the project are. Thus, my fear is that without *details* about what the project is, and what it's trying to accomplish, we're going to put an exponentially larger volume of work into the transition and end up no closer to the goal of having a mature package management system. And just to be clear, I am *not* saying that pkg sucks or that it's bad, or wrong, or anything else. I'm saying that I don't know how to evaluate it, because you haven't given us a criteria by which to measure it. So what's the problem? We *desperately* need a better system for ports and packages. We only have so many person-hours we can devote to making that happen. If we spend all of them on pkg, and it ends up not helping us enough, we've burnt out our volunteers for no good reason. I am using pkg_* tools since '94 and I am using portmaster for ports/pkg maintainance for years: pkg_* tools are a pain in the ass in the view of an administrator. I use it only and partly on fresh installs and doing further security auditing with portaudit and upgrading with portmaster - most time upgrading from source. But only, because its simply not possible the same way with the pkg_* tools. Because I manage dozens of installation across Europe, buildind and updating from ports will be more and more time consuming. portmaster is really a great tool to take control of this lack of features in pkg_* tools , but I am running out of time more and more. I was also a bit concerned and reserved to pkgng. But I am also in contact with some local FreeBSD ports committers and one of them (decke) told me some stories about pkgng and poudriere. I saw the talk from Beat Gätzi (beat) at EU BSD Day 2012 about pkgng and was I see was really nice and made me courious. So I tried to setup a small build environment with poudriere and pkgng to evaluate an substitution for my traditional pkg/port security upgrading with portmaster. Finally I think, I can complete replace portmaster with pkgng, poudriere and an self build and maintained pkg repository. This will save a huge amount of time in future and allow to roll out security updates for packages really fast and easy. So pkgng is not designed as a replacement for portmaster, but now it allows me to work without it on most of my installations. I know almost any of the Linux Enterprise package management features, pkg_* tools a far away from this kind of functionality, even with the support of the great portmaster tool. Bug pkgng improves much more. Its a very complex problematic. Yes documentation is not so good as it could be. But I saw the talks from beat in live, saw the screencasts from bapt on Youtube and finally I tried it on my own. It was necessary to try it out and see it, feel it, smell and taste it. I think its good work from
Re: [HEADSUP] OpenSSL 1.0.1c merge in progress
Hello, Jung-uk. You wrote 13 июля 2012 г., 4:03:09: Therefore, all binaries depending on these need to be recompiled. Also, you may have to merge your /etc/ssl/openssl.conf changes. JuK FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you JuK have any problem. No ports with USE_OPENSSL=yes could be built now :( Ports system complains about not-installed base OpenSSL. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
Hello, Lev. You wrote 13 июля 2012 г., 12:29:03: JuK FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you JuK have any problem. LS No ports with USE_OPENSSL=yes could be built now :( Ports system LS complains about not-installed base OpenSSL. Sorry for noise, it is local problem. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
On 07/12/2012 05:03 PM, Jung-uk Kim wrote: FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Sorry if I missed it, but did you bump OSVERSION for this change? If not, could you? It would be helpful for dealing with ports stuff, especially USE_OPENSSL. Doug ___ 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: Use of C99 extra long double math functions after r236148
On 2012-Jul-11 15:32:47 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: I know an approach to implementing many of the missing functions. Are you willing to share this insight so someone else could do the work? When I do find some free time, I look at what is missing and start to put together a new function. At the moment, it seems that it takes 3+ years to get a new function written, tested, and committed. And, from what I can see, much of this is done quietly - which opens up the possibility that two people might both implement the same code or that people will avoid the area in fear of treading on someone else's toes. As I said previously, I believe the existing wiki page could be improved to form a central co-ordinating point to show what what activity is (or isn't) occurring. but most people seem to push the easy button and want to grab either cephes or netlib's libm. There are technical issues with this approach that I won't rehash again. Doing it properly requires significant effort by people with fairly specialised skills. Whilst the project has several people with the skills, it appears that none of them currently have the time. In the meantime, FreeBSD is taking free kicks from other FOSS groups that have gone down the quick-and-dirty path. AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). -- Peter Jeremy pgpPVXxJTjV0R.pgp Description: PGP signature
Re: [HEADSUP CFT] pkg 1.0rc1 and schedule
What I want to know is this new pkg system going to remove the requirement of having the complete ports tree on my system? What I am looking for in an port system, is to install a port and any files needed for the parent port and its dependents to automatically be downloaded. So in the end my system ports tree only contain the files used to install the ports I use and their dependents. ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
Am 13.07.12 14:14, schrieb Fbsd8: What I want to know is this new pkg system going to remove the requirement of having the complete ports tree on my system? What I am looking for in an port system, is to install a port and any files needed for the parent port and its dependents to automatically be downloaded. So in the end my system ports tree only contain the files used to install the ports I use and their dependents. The new pkg system is not a replacement for the ports tree. If you still like to compile software from ports, you will need the ports tree. But you can install a precompiled package with the new pkg system and it automatically downloads all necessary binary packages it depends on. So probably you dont need the ports any more. Regards Michael -- Mit freundlichen Grüßen Ing. Michael Ranner GSM: +43 676 4155044 Mail: mich...@ranner.eu WWW: http://www.azedo.at/ ___ 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: Use of C99 extra long double math functions after r236148
On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). I concur. However, are there any patches that we can commit now? It seems that there are some things that could go into the tree now that will certainly reduce the concerns of the R folk. -- 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: On 07/12/2012 02:11 PM, Craig Rodrigues wrote: You might want to view Baptiste's pkgng presentation at BSDCan: http://www.youtube.com/watch?v=4Hxq7AHZ27I Sure, the next time I have an hour to spare. I don't think what I'm asking for is unreasonable. One could even conclude that answering those 3 questions should have been a prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters (you do realize, btw, that that is how you come across, that even though you don't intend that, constantly questioning decisions made by other people in an accusatory fashion gives that impression? At least adjust your wording to start off with the assumption that other people _have_ put thought into things. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. -- 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 13/07/2012 13:14, Fbsd8 wrote: What I want to know is this new pkg system going to remove the requirement of having the complete ports tree on my system? What I am looking for in an port system, is to install a port and any files needed for the parent port and its dependents to automatically be downloaded. So in the end my system ports tree only contain the files used to install the ports I use and their dependents. Yes, you will be able to use pkgng without having a full ports tree installed on your system. You can pretty much do that already, although the central pkgng package repository is still only in beta. The only bit of pkgng that still requires the ports to be installed is 'pkg version' which is not critical for maintaining your system. Modifying 'pkg version' so that it doesn't need to use the ports tree is an open issue on github: https://github.com/pkgng/pkgng/issues/195 Patches / pull requests gratefully received. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Use of C99 extra long double math functions after r236148
On 13 Jul 2012, at 13:18, John Baldwin wrote: On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). I concur. As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. David P.S. Someone said earlier that our clang still lacks some C99 features. Please point me at the relevant clang PRs and I'll be happy to work on them. There are quite a few open issues for C11 support, but C99 is, as far as I know, done. ___ 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
Erratic USB mouse behaviour when wireless is down and USB hard disk connected
Hi, I know that this is not a very helpful information. I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that the USB mouse (a wireless Logitech Trackman) becomes unusable when the wireless (iwn) is not able to connect to the access point and a USB hard disk is plugged in. Even when no data are transferred the USB mouse is unusable. The built-in track-point behaves just normal. When I turn off the wireless network via the hardware switch, the system stays usable as expected even under heavy hard disk access. If it was not something else I have missed, the only difference was the access point which went down when I noticed the problem. Please understand this just as a hint to the developers of the sub-systems which could cause the problem. As this network here is not mine, I am not able to do any tests with it. If somebody has an idea what could be tested, tell me please. I will have access to 'my' network the coming week again. Erich ___ 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: Erratic USB mouse behaviour when wireless is down and USB hard disk connected
On Fri, Jul 13, 2012 at 2:04 PM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I know that this is not a very helpful information. I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that the USB mouse (a wireless Logitech Trackman) becomes unusable when the wireless (iwn) is not able to connect to the access point and a USB hard disk is plugged in. Even when no data are transferred the USB mouse is unusable. Which frequency is the mouse working on? something in the 2.4GHz region? I remember having lots of fun at $office with the mouse of colleague. It used channel 6 and the amount of traffic generating over wireless LAN had direct influence on the accuracy of his mouse activity ;) Anyways, if you have the chance to switch to another channel, give it a shot. -- Bernhard ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 7/13/2012 3:16 AM, Michael Ranner wrote: I was also a bit concerned and reserved to pkgng. But I am also in contact with some local FreeBSD ports committers and one of them (decke) told me some stories about pkgng and poudriere. I saw the talk from Beat Gätzi (beat) at EU BSD Day 2012 about pkgng and was I see was really nice and made me courious. So I tried to setup a small build environment with poudriere and pkgng to evaluate an substitution for my traditional pkg/port security upgrading with portmaster. This explains how you can setup your own repository and build your own packages with poudriere+pkgng: http://blog.etoilebsd.net/post/Home_made_pkgng_repo -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: Use of C99 extra long double math functions after r236148
On Fri, Jul 13, 2012 at 09:41:00PM +1000, Peter Jeremy wrote: On 2012-Jul-11 15:32:47 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: I know an approach to implementing many of the missing functions. Are you willing to share this insight so someone else could do the work? For the missing trig and hyperbolic functions of complex float and complex double arguments, one can follow the approach in msun/src/s_ccosh[f].c. For the missing hyperbolic functions of long double and complex long double argument, people will need to wait for expl() and expm1l() to show up in tree. I have a working expl() and almost working expm1l() for ld80 systems. Until a few months ago, I did not have access to a ld128 system, so I haven't wasted my time implementing ld128 version that I could not test. When I do find some free time, I look at what is missing and start to put together a new function. At the moment, it seems that it takes 3+ years to get a new function written, tested, and committed. And, from what I can see, much of this is done quietly - which opens up the possibility that two people might both implement the same code or that people will avoid the area in fear of treading on someone else's toes. As I said previously, I believe the existing wiki page could be improved to form a central co-ordinating point to show what what activity is (or isn't) occurring. Well, I've posted the code I've written to freebsd-standards mailinglist more than once, and have only ever received comments from exactly 2 people. but most people seem to push the easy button and want to grab either cephes or netlib's libm. There are technical issues with this approach that I won't rehash again. Doing it properly requires significant effort by people with fairly specialised skills. Whilst the project has several people with the skills, it appears that none of them currently have the time. In the meantime, FreeBSD is taking free kicks from other FOSS groups that have gone down the quick-and-dirty path. AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). Well, hopefully, the someone who takes the best available code also tests this code before it is committed. I suspect that some if not all of those codes that involve complex arguments will have problems with the requirements in n1256.pdf[1], because neither gcc in base nor clang do complex arithmetic correctly under certains conditions when an expression uses I from complex.h. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf -- Steve ___ 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: Use of C99 extra long double math functions after r236148
On Fri, Jul 13, 2012 at 01:53:39PM +0100, David Chisnall wrote: On 13 Jul 2012, at 13:18, John Baldwin wrote: On Friday, July 13, 2012 7:41:00 am Peter Jeremy wrote: AFAIK, none of the relevant standards (POSIX, IEEE754) have any precision requirements for functions other than +-*/ and sqrt() - all of which we have correctly implemented. I therefore believe that, for the remaining missing functions, the Project would be best served by committing the best code that is currently available under a suitable license and cleaning it up over time (as was done for the current libm). I concur. As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. I'd be curious how well the GPL functions in Linux compare to the NetBSD functions. I don't suppose we could grab some of the public domain routines in NetLib? David P.S. Someone said earlier that our clang still lacks some C99 features. Please point me at the relevant clang PRs and I'll be happy to work on them. There are quite a few open issues for C11 support, but C99 is, as far as I know, done. Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 07/13/2012 05:26 AM, John Baldwin wrote: On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: On 07/12/2012 02:11 PM, Craig Rodrigues wrote: You might want to view Baptiste's pkgng presentation at BSDCan: http://www.youtube.com/watch?v=4Hxq7AHZ27I Sure, the next time I have an hour to spare. I don't think what I'm asking for is unreasonable. One could even conclude that answering those 3 questions should have been a prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters I certainly *want* to believe that. But considering the giant mess that portmgr + Baptiste made of the changes to the OPTIONS framework, that only touches a fraction of the ports, my willingness to have faith in them to do it right is near zero. Not to mention that I've been asking for a project plan for pkg since long before it even hit the ports tree in beta. What I'm asking for should have been done already considering that this change will affect *every* port, and *every* user. So either it hasn't actually been done, or the PTB are refusing to provide it. Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is how to type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. You're an experienced project manager John. If someone who worked for you came to you with a plan this vague (modern foo, decent bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. Doug ___ 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-13 05:55:04 -0400, Doug Barton wrote: On 07/12/2012 05:03 PM, Jung-uk Kim wrote: FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Sorry if I missed it, but did you bump OSVERSION for this change? If not, could you? It would be helpful for dealing with ports stuff, especially USE_OPENSSL. Yes, it was bumped with the commit. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAREwACgkQmlay1b9qnVNpkgCffS1dK8lvKRBXpxeebRGcx/kE UYIAoMxzzJUcx2JvTY996Vm4eHHriXVt =NvEB -END PGP SIGNATURE- ___ 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: Use of C99 extra long double math functions after r236148
On Fri, Jul 13, 2012, David Chisnall wrote: As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. By the way, the trig and complex functions are areas where anyone with some calculus background could contribute. If anyone is interested in helping out, I'd be happy to coordinate things and review patches, although I will be unavailable for much of August. ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 7/13/2012 10:36 AM, Doug Barton wrote: On 07/13/2012 05:26 AM, John Baldwin wrote: On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: On 07/12/2012 02:11 PM, Craig Rodrigues wrote: You might want to view Baptiste's pkgng presentation at BSDCan: http://www.youtube.com/watch?v=4Hxq7AHZ27I Sure, the next time I have an hour to spare. I don't think what I'm asking for is unreasonable. One could even conclude that answering those 3 questions should have been a prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters I certainly *want* to believe that. But considering the giant mess that portmgr + Baptiste made of the changes to the OPTIONS framework, that only touches a fraction of the ports, my willingness to have faith in them to do it right is near zero. There's a *major* difference in the testing effort and community involvement in these 2 projects. OPTIONSng had maybe a handful of testers over a shorter period of time. PKGNG has had 40+ contributors and has been in development since 2010. It's been presented and discussed at multiple conferences and dev summits. Many people have been building their own packages with PKGNG for months now, greatly raising the testing coverage on the ports tree. Not to mention that I've been asking for a project plan for pkg since long before it even hit the ports tree in beta. What I'm asking for should have been done already considering that this change will affect *every* port, and *every* user. So either it hasn't actually been done, or the PTB are refusing to provide it. http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html I find bapt's research in that post to be evident that a lot of thought and time did go into planning this. Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is how to type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. Have you watched the BSDCan presentation video yet? It is very compelling and exciting. You're an experienced project manager John. If someone who worked for you came to you with a plan this vague (modern foo, decent bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. So get involved! Come help. Contribute. Doug -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On 13 July 2012 17:02, Bryan Drewery br...@shatow.net wrote: On 7/13/2012 10:36 AM, Doug Barton wrote: On 07/13/2012 05:26 AM, John Baldwin wrote: On Thursday, July 12, 2012 5:16:41 pm Doug Barton wrote: On 07/12/2012 02:11 PM, Craig Rodrigues wrote: You might want to view Baptiste's pkgng presentation at BSDCan: http://www.youtube.com/watch?v=4Hxq7AHZ27I Sure, the next time I have an hour to spare. I don't think what I'm asking for is unreasonable. One could even conclude that answering those 3 questions should have been a prerequisite for starting down this road in the first place. One could also assume that other people in the Project aren't morons and do actually put thought into the things they do for starters I certainly *want* to believe that. But considering the giant mess that portmgr + Baptiste made of the changes to the OPTIONS framework, that only touches a fraction of the ports, my willingness to have faith in them to do it right is near zero. There's a *major* difference in the testing effort and community involvement in these 2 projects. OPTIONSng had maybe a handful of testers over a shorter period of time. PKGNG has had 40+ contributors and has been in development since 2010. It's been presented and discussed at multiple conferences and dev summits. Many people have been building their own packages with PKGNG for months now, greatly raising the testing coverage on the ports tree. Not to mention that I've been asking for a project plan for pkg since long before it even hit the ports tree in beta. What I'm asking for should have been done already considering that this change will affect *every* port, and *every* user. So either it hasn't actually been done, or the PTB are refusing to provide it. http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031533.html I find bapt's research in that post to be evident that a lot of thought and time did go into planning this. Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is how to type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. Have you watched the BSDCan presentation video yet? It is very compelling and exciting. You're an experienced project manager John. If someone who worked for you came to you with a plan this vague (modern foo, decent bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. So get involved! Come help. Contribute. And PLEASE get that portmaster patch integrated. Chris ___ 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: Use of C99 extra long double math functions after r236148
On 07/13/12 10:58, David Schultz wrote: On Fri, Jul 13, 2012, David Chisnall wrote: As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. This sounds fantastic. By the way, the trig and complex functions are areas where anyone with some calculus background could contribute. If anyone is interested in helping out, I'd be happy to coordinate things and review patches, although I will be unavailable for much of August. I would be happy to help. Just give me a sense of direction of what I should try and work on, when and as you are ready. ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On Friday, July 13, 2012 11:36:11 am Doug Barton wrote: Also, please keep in mind that I was criticized for *not* speaking up about the OPTIONS changes, now I'm being criticized *for* speaking up prior to pkg going live. In spite of the fact that I'm doing my best to (repeatedly) be clear that I'm not against the project, I just want to know more about it. To clarify, you are not being criticized for speaking up, you are being criticized for the way in which you are speaking up (an accusatory tone) and for blowing off a pointer to a talk that would perhaps answer some of your questions. Also, when other people have taken time to explain an large decision because you are too lazy to invest the time doesn't really help your case). Um, I'm too lazy? I've read everything that's been written on pkg to date. Have you? 90% of it is how to type stuff that doesn't address what we need. The other 10% is so vague and general as to be useless as a project plan. Hmm, that is not my distinct impression. However, I do have the advantage of having been part of several in-person meetings and discussions (for example, the ports working group at the developer summit for BSDCan where a lot of discussion and planning took place about the future of packages). You're an experienced project manager John. If someone who worked for you came to you with a plan this vague (modern foo, decent bar), for a critical system, how would you respond? (And yes, I realize that no one around here works for me, that isn't my point at all.) My understanding of this plan is far less vague. In practice, pkgng hasn't really been happening under a rock. There have been multiple announcements and calls for testing and I know that many folks are testing it and working with it. Large projects such as this can be a bit bumpy in FreeBSD land, and I expect that there will be things that crop up that have to be fixed as a result of wider testing. (For example, I agree with you that the nvidia driver packages have to work correctly as that is a non-starter for me as well). However, I am confident that pkgng and the new packages model is aiming at the right target based on my own interactions with Erwin, Baptiste, and others, and I think we need to push this forward and gain wider testing to make progress, even if there are bumps in the road. In terms of the first feature (binary upgrades), the truth is that if you have more than 5 machines to manage, our current pkg tools completely suck. There is no automated upgrade mechanism. If you want one you have to write your own set of infrastructure to do the right collection of pkg_delete/pkg_adds. Certainly there is no support in the current package tools for doing batch upgrades (i.e. upgrading from one completely package set to another). pkgng adds that feature, and I find it a must for supporting large installations of machines that need automated management. And as I wrote previously, I've been there and done that, so yes, I'm interested in the feature. But I'd like to know more about the plans for it so that those of us who *do* have experience in this topic can share that, and we can avoid having to reinvent the wheel. Or worse, putting out something half-assed that uses up a lot of developer cycles and doesn't get the job done. Well, what I can tell you is that many of us who do have experience with that model have been discussing this in various fora, initially in e-mails, IRC discussions, informal discussions during the hallway track at conferences, etc. To build a broader consensus, portmgr@ has been holding larger, more formal discussions in the form of devsummit working groups, presentations at conferences, etc. I personally have been petitioning anyone's ear I could bend for package sets for example. I realize, btw, that not all of those discussions have occurred on public mailing lists. The fact is, there is a tradeoff between informal communication (such as in-person commucation) and mails to a mailing list. In-person communication especially offers far higher bandwidth and can be far more effective for reaching consensus and working through alternatives, but it has a more limited audience. Being a volunteer project distributed all over the globe, we are somewhat stuck with that tradeoff. We attempt to mitigate that tradeoff somewhat by making more of these informal discussions more formal (e.g. adding working groups at the devsummit which include wiki pages with summaries of the agenda and slide decks used to present the wg summary to the full complement of attendees so there is at least some information availble for folks who were not able to attend). However, it does mean that just because you were not personally involved in a discussion or did not see a long and tedious thread, you should not assume that no discussion has taken place at all. Back to my original e-mail: FreeBSD is a big project. I
Re: Use of C99 extra long double math functions after r236148
On 13 July 2012 09:07, Stephen Montgomery-Smith step...@missouri.edu wrote: On 07/13/12 10:58, David Schultz wrote: On Fri, Jul 13, 2012, David Chisnall wrote: As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. +1 If we do import Cephes the questionable functions should probably be explicitly marked somewhere so that if there is still $someone can still work on them though. -- Eitan Adler ___ 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: Use of C99 extra long double math functions after r236148
Just to jump back into the fray a bit, since this point hasn't been articulated well. On Jul 10, 2012, at 6:55 PM, Peter Jeremy wrote: On 2012-Jul-08 19:01:07 -0700, Steve Kargl s...@troutmask.apl.washington.edu wrote: Well, on the most popular hardware (that being i386/amd64), ld80 will use hardware fp instruction while ld128 must be done completely in software. The speed difference is significant. AFAIK, of the architectures that FreeBSD supports, only sparc64 defines ld128 in the architecture and I don't believe there are any SPARC chip implementations that implement ld128 math in hardware. We shouldn't be gating the new math on an issue that only affects sparc64 machines. If they have ld80 level of support for that architecture, then that is sufficient to get things into the tree. There's no real benefit from making numerics good on sparc64 for the project, since our support for the platform isn't stellar and the platform itself is getting a bit long in the tooth. That said, if people want to do it, be my guest. If it is important enough to catch someone's attention, then it is important enough to have. It just isn't important enough to be a gating factor if nobody has signed up for it yet. Warner ___ 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: Use of C99 extra long double math functions after r236148
On Friday, July 13, 2012 11:58:05 am David Schultz wrote: On Fri, Jul 13, 2012, David Chisnall wrote: As do I. I'd also point out that the ONLY requirement for long double according to the standard is that it has at least the same precision as double. Therefore, any implementation of these functions that is no worse that the double version is compliant. Once we have something meeting a minimum standard, then I'm very happy to see it improved, but having C99 functions missing now is just embarrassing while we're working on adding C11 features. There are several things wrong with this reasoning, but pragmatically the conclusion may be right: we do have a long list of users who would prefer a dubious implementation to none at all. I propose we set a timeframe for this, on the order of a few months. A rough outline might be something like: mid-August: expl logl log2l log10l -- just need to clean up Bruce and Steve's work; Steve recently sent me patches for expl, which I hope get committed soon mid-September: acoshl asinhl atanhl coshl sinhl tanhl -- easy once expl is in; others could probably help mid-October: powl expm1l mid-November: most complex.h functions If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. By the way, the trig and complex functions are areas where anyone with some calculus background could contribute. If anyone is interested in helping out, I'd be happy to coordinate things and review patches, although I will be unavailable for much of August. I think this sounds like an excellent plan, thanks! -- 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
On 07/13/2012 08:52 AM, Jung-uk Kim wrote: On 2012-07-13 05:55:04 -0400, Doug Barton wrote: On 07/12/2012 05:03 PM, Jung-uk Kim wrote: FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Sorry if I missed it, but did you bump OSVERSION for this change? If not, could you? It would be helpful for dealing with ports stuff, especially USE_OPENSSL. Yes, it was bumped with the commit. Thanks, and again, sorry I missed it. ___ 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: Adding support for WC (write-combining) memory to bus_dma
On Thursday, July 12, 2012 1:51:20 pm John Baldwin wrote:
On Thursday, July 12, 2012 12:37:13 pm Scott Long wrote:
Yup, this is a problem, and I like your fix; this kind of state is exactly
what
belongs in the map.
Why don't I break out the fix first as a separate patch.
Here is a patch to just fix this. I also mirrored the changes into powerpc
since it had copied the same code from x86 (albeit disabled). If you feel
the malloc stats via M_DEVBUF are important, I can restore those (probably
by adding a contigmalloc_attr() wrapper).
Index: powerpc/powerpc/busdma_machdep.c
===
--- powerpc/powerpc/busdma_machdep.c(revision 238365)
+++ powerpc/powerpc/busdma_machdep.c(working copy)
@@ -46,6 +46,8 @@
#include sys/sysctl.h
#include vm/vm.h
+#include vm/vm_extern.h
+#include vm/vm_kern.h
#include vm/vm_page.h
#include vm/vm_map.h
@@ -130,6 +132,7 @@
bus_dmamap_callback_t *callback;
void *callback_arg;
STAILQ_ENTRY(bus_dmamap) links;
+ intcontigalloc;
};
static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist;
@@ -489,6 +492,7 @@
bus_dmamem_alloc(bus_dma_tag_t dmat, void** vaddr, int flags,
bus_dmamap_t *mapp)
{
+ vm_memattr_t attr;
int mflags;
if (flags BUS_DMA_NOWAIT)
@@ -500,6 +504,12 @@
if (flags BUS_DMA_ZERO)
mflags |= M_ZERO;
+#ifdef NOTYET
+ if (flags BUS_DMA_NOCACHE)
+ attr = VM_MEMATTR_UNCACHEABLE;
+ else
+#endif
+ attr = VM_MEMATTR_DEFAULT;
/*
* XXX:
@@ -511,7 +521,8 @@
*/
if ((dmat-maxsize = PAGE_SIZE)
(dmat-alignment dmat-maxsize)
- dmat-lowaddr = ptoa((vm_paddr_t)Maxmem)) {
+ dmat-lowaddr = ptoa((vm_paddr_t)Maxmem)
+ attr == VM_MEMATTR_DEFAULT) {
*vaddr = malloc(dmat-maxsize, M_DEVBUF, mflags);
} else {
/*
@@ -520,9 +531,10 @@
* multi-seg allocations yet though.
* XXX Certain AGP hardware does.
*/
- *vaddr = contigmalloc(dmat-maxsize, M_DEVBUF, mflags,
- 0ul, dmat-lowaddr, dmat-alignment? dmat-alignment : 1ul,
- dmat-boundary);
+ *vaddr = (void *)kmem_alloc_contig(kernel_map, dmat-maxsize,
+ mflags, 0ul, dmat-lowaddr, dmat-alignment ?
+ dmat-alignment : 1ul, dmat-boundary, attr);
+ (*mapp)-contigalloc = 1;
}
if (*vaddr == NULL) {
CTR4(KTR_BUSDMA, %s: tag %p tag flags 0x%x error %d,
@@ -531,11 +543,6 @@
} else if (vtophys(*vaddr) (dmat-alignment - 1)) {
printf(bus_dmamem_alloc failed to align memory properly.\n);
}
-#ifdef NOTYET
- if (flags BUS_DMA_NOCACHE)
- pmap_change_attr((vm_offset_t)*vaddr, dmat-maxsize,
- VM_MEMATTR_UNCACHEABLE);
-#endif
CTR4(KTR_BUSDMA, %s: tag %p tag flags 0x%x error %d,
__func__, dmat, dmat-flags, 0);
return (0);
@@ -548,18 +555,12 @@
void
bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map)
{
- bus_dmamap_destroy(dmat, map);
-#ifdef NOTYET
- pmap_change_attr((vm_offset_t)vaddr, dmat-maxsize, VM_MEMATTR_DEFAULT);
-#endif
- if ((dmat-maxsize = PAGE_SIZE)
- (dmat-alignment dmat-maxsize)
- dmat-lowaddr = ptoa((vm_paddr_t)Maxmem))
+ if (!map-contigalloc)
free(vaddr, M_DEVBUF);
- else {
- contigfree(vaddr, dmat-maxsize, M_DEVBUF);
- }
+ else
+ kmem_free(kernel_map, (vm_offset_t)vaddr, dmat-maxsize);
+ bus_dmamap_destroy(dmat, map);
CTR3(KTR_BUSDMA, %s: tag %p flags 0x%x, __func__, dmat, dmat-flags);
}
Index: x86/x86/busdma_machdep.c
===
--- x86/x86/busdma_machdep.c(revision 238365)
+++ x86/x86/busdma_machdep.c(working copy)
@@ -42,6 +42,8 @@
#include sys/sysctl.h
#include vm/vm.h
+#include vm/vm_extern.h
+#include vm/vm_kern.h
#include vm/vm_page.h
#include vm/vm_map.h
@@ -131,7 +133,7 @@
static STAILQ_HEAD(, bus_dmamap) bounce_map_waitinglist;
static STAILQ_HEAD(, bus_dmamap) bounce_map_callbacklist;
-static struct bus_dmamap nobounce_dmamap;
+static struct bus_dmamap nobounce_dmamap, contig_dmamap;
static void init_bounce_pages(void *dummy);
static int alloc_bounce_zone(bus_dma_tag_t dmat);
@@ -465,7 +467,7 @@
int
bus_dmamap_destroy(bus_dma_tag_t dmat, bus_dmamap_t map)
{
- if (map != NULL map != nobounce_dmamap) {
+ if (map != NULL map != nobounce_dmamap map != contig_dmamap) {
if (STAILQ_FIRST(map-bpages) != NULL) {
CTR3(KTR_BUSDMA, %s: tag %p error %d,
__func__, dmat,
Re: newbus' ivar's limitation..
Hi, On Thu, Jul 12, 2012 at 1:20 AM, Warner Losh i...@bsdimp.com wrote: [..] Honestly, though, I think you'll be more pissed when you find out that the N:1 interface that you want is being done in the wrong domain. But I've been wrong before and look forward to seeing your replacement. I will just pass function pointers for now, if things should be done dirty, let's be explicit about it. Now, the hinted device attachment did work quite smoothly, however, I would have a few suggestion: 1) add a call to bus_enumerate_hinted_children() before the call DEVICE_IDENTIFY() call in bus_generic_driver_added() this is required to be able to support dynamic loading and attachment of hinted children. 2) have a generic bus_hinted_child method which would just add a new child to the bus. 3) have bus_enumerate_hinted_children() and bus_generic_attach() always ran on device attachment. There is current +100 explicit call to bus_generic_attach() in the sys/dev/ tree. This should be done always and implicitly. 4) have bus_generic_detach() always ran prior to device detachment If not already the case. There is still the same +100 direct call to bus_generic_detach is the tree. 5) have the bus_generic_* method be the default of their respective method 6) have device_delete_child() called upon device detachment. As a rule of thumb, when a kld is unloaded there should not be any remains of anything built previously. Without device_delete_child() or proper singleton implementation, multiple load/unload sequence of bus will attempt to attach multiple version of a child, even if the single child was added prior to the bus_generic_attach() call. Also, as a rule of thumb, if the same logic is implemented in more than a few buses, it should be made generic and implicit. I am lazy, I hate doing the same things over and over, not to say it raised the likelihood of bugs' introduction... - Arnaud ___ 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-07-13 04:00:14 -0400, Konstantin Belousov wrote:
How did the asm files were generated (I am sure they are generated)
?
Yes, they are all re-generated. Mostly, it is described in
FREEBSD-upgrade file:
http://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/FREEBSD-upgrade?view=markuppathrev=238384
Basically, it goes something like this:
cd ${SRCDIR}/secure/lib/libcrypto
make -f Makefile.asm all
mv *.[Ss] ${MACHINE_CPUARCH}
make -f Makefile.asm clean
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAAa2MACgkQmlay1b9qnVMBtACgoxxI+jmAmhcpLnbozW3y2LNd
/bUAnjeZ8f9K2ccwTDgicwLBLYUw+Mlp
=Gy0L
-END PGP SIGNATURE-
___
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: [HEADSUP] OpenSSL 1.0.1c merge in progress
Will port also be MFCed to 9-RELENG and 9.1-RELEASE? Do not want to have to go to -CURRENT to get latest OpenSSL. --Brett Glass ___ 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: [HEADSUP] OpenSSL 1.0.1c merge in progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-13 15:03:39 -0400, Brett Glass wrote: Will port also be MFCed to 9-RELENG and 9.1-RELEASE? Do not want to have to go to -CURRENT to get latest OpenSSL. Sorry, we have no plan to MFC this to stable branches because of API and feature changes. However, you may need OpenSSL from ports tree, which has the same version ATM. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAfowACgkQmlay1b9qnVO6FQCePL/lmITYUw5xmI4weIX+NOtE ASYAoJBeDaIxmj2wG4j7keczkhU62WAS =Ed5I -END PGP SIGNATURE- ___ 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: [HEADSUP CFT] pkg 1.0rc1 and schedule
On Fri, Jul 13, 2012 at 5:14 AM, Fbsd8 fb...@a1poweruser.com wrote: What I want to know is this new pkg system going to remove the requirement of having the complete ports tree on my system? What I am looking for in an port system, is to install a port and any files needed for the parent port and its dependents to automatically be downloaded. So in the end my system ports tree only contain the files used to install the ports I use and their dependents. That is precisely what pkgng is for. At the risk of over-simplifying: * Generally eliminate the need for having /usr/ports installed for end user consumers of freebsd if you have no desire to compile ports with custom options. * Generally eliminate the need for layers over the top of pkg* like portupgrade/portmaster/portmanager for those people. * Play nicely with people who *are* building some (or all) of their packages from /usr/ports. * Provide enough look and feel compatibility with the old pkg_* tools so people will feel enough at home. * Assimilate an existing pkg_* machine. * Store complete metadata so that going foward we have much better support for package sets - eg: package repositories with custom options that play nicely with official packages. * Be extensible so that we can add to it as we go forward. In the new world order, things like portupgrade and portmanager tend to be used to manage interactions between personally build ports from /usr/ports and external binary packages. If you continue to build from /usr/ports, the only thing that changes is bsd.port.mk uses a different command to register a package and you still use portupgrade/portmaster/whatever to orchestrate your personal package rebuilding. (Well, portmaster does if you apply the simple patch to it). pkg-1.0 is primarily an infrastructure change. Instead of metadata being stored in discrete +FOO and +BAR files in a .tgz file, it is stored in a structured, extensible file. Instead of an incomplete set of metadata being stored in /var/db/pkg/* and having to be augmented by reaching over to /usr/ports/*, a full set of data is stored in a .sqlite file. Instead of version numbers being baked into the package name as an ascii string, the package system uses version numbers as first class metadata. In reality, not much will change at the switch throwing, except that of having good reason to be afraid of pkg_add -r, you'll be able to reasonably expect it's replacement (pkg install) to work. And a bunch of people who have a /usr/ports tree will suddenly wonder why they even have it there at all. It becomes incredibly convenient and fast to use packages. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ 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
PAM passwdqc, strict aliasing, and WARNS
Someone who has yet to confess added -Werror to the global CFLAGS (via /etc/make.conf) for one of our systems at work. Before I figured out that this was the cause of builds failing, I hacked up pam_passwdc to resolve the problem. This gets the module to WARNS=2, but to go farther, the logically const issues with this code will need to be sorted out. Is this change worth committing? Is this the best way to resolve the strict aliasing issues in this code? Thanks, Justin pam_passwdqc.diff Description: Binary data ___ 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: Use of C99 extra long double math functions after r236148
On 2012-Jul-13 11:58:05 -0400, David Schultz d...@freebsd.org wrote: I propose we set a timeframe for this, on the order of a few months. ... If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. This sounds good to me as well and I'd be happy to help. -- Peter Jeremy pgpmY7CNvs676.pgp Description: PGP signature
Re: Use of C99 extra long double math functions after r236148
On Jul 13, 2012, at 4:38 PM, Peter Jeremy wrote: On 2012-Jul-13 11:58:05 -0400, David Schultz d...@freebsd.org wrote: I propose we set a timeframe for this, on the order of a few months. ... If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. This sounds good to me as well and I'd be happy to help. Also sounds good to me. If Peter gets busy, I'd be able to help as well with the back-stop proposal. Warner ___ 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: Erratic USB mouse behaviour when wireless is down and USB hard disk connected
Hi, On Friday, July 13, 2012 09:10:16 PM Bernhard Schmidt wrote: On Fri, Jul 13, 2012 at 2:04 PM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I know that this is not a very helpful information. I have an Lenovo X220 running 10 from some 2 weeks ago. I just noticed that the USB mouse (a wireless Logitech Trackman) becomes unusable when the wireless (iwn) is not able to connect to the access point and a USB hard disk is plugged in. Even when no data are transferred the USB mouse is unusable. Which frequency is the mouse working on? something in the 2.4GHz region? I remember having lots of fun at $office with the mouse of colleague. It used channel 6 and the amount of traffic generating over wireless LAN had direct influence on the accuracy of his mouse activity ;) Anyways, if you have the chance to switch to another channel, give it a shot. I have to check on this. As the channels of the network here are fixed, this only can happen when the network is down. As I said, I can test it next week. Erich ___ 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
[IMPORT] bsdconfig(8)
Hello -current, I'm [re-]announcing that (after much delay from the first announcement) that I am finally importing bsdconfig(8) into HEAD. Here's what to expect from the import: 1. The Makefile for usr.sbin will not automatically descend into the new usr.sbin/bsdconfig directory. 2. To add bsdconfig(8) to your system, define WITH_BSDCONFIG=YES (either on the make line with -D or in src.conf(5) for convenience). 3. After the import, not only is it possible but-encouraged to test the HEAD code on RELENG_9 (but no-lower than 9.0-R as this is the lowest compatible release and RELENG_9 is the lowest target MFC). 4. Aside from the following [tiny] patches, everything lives in usr.sbin/bsdconfig/ tools/build/options/WITH_BSDCONFIG share/mk/bsd.own.mk usr.sbin/Makefile Please report any problems, kudos, comments to me at-will. -- Cheers, 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. ___ 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: Use of C99 extra long double math functions after r236148
On Sat, Jul 14, 2012 at 08:38:08AM +1000, Peter Jeremy wrote: On 2012-Jul-13 11:58:05 -0400, David Schultz d...@freebsd.org wrote: I propose we set a timeframe for this, on the order of a few months. ... If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. This sounds good to me as well and I'd be happy to help. Perfect, all that is needed. I'd also be happy to help of course. -- Peter Jeremy Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db Nowadays tar can compress using yesterdays latest technologies! ___ 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: Use of C99 extra long double math functions after r236148
On 14/07/2012, at 2:35, Eitan Adler wrote: If the schedule can't be met, then we can just import Cephes as an interim solution without further ado. This provides Bruce and Steve an opportunity to commit what they have been working on, without forcing the rest of the FreeBSD community to wait indefinitely for the pie in the sky. +1 If we do import Cephes the questionable functions should probably be explicitly marked somewhere so that if there is still $someone can still work on them though. Perhaps the same way mktemp et al are marked.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: [HEADS-UP] Import of src/usr.sbin/bsdconfig from sysutils/bsdconfig (ports)
On Jul 2, 2012, at 6:24 PM, Devin Teske wrote: On Jun 30, 2012, at 3:47 PM, Bruce Cran wrote: On 28/06/2012 00:11, Devin Teske wrote: I'd like to announce that I intend to import bsdconfig(8) today. I haven't seen this get committed yet - was there a problem? No problems. A long weekend put the damper on the process but it has picked up again. By week's end there should be more info. Just committed! See SVN r238438 http://svnweb.FreeBSD.org/base?limit_changes=0view=revisionrevision=238438 In the additional time that was taken many people were spoken with. The only thing that has really changed is that phk recommended adding a WITH_BSDCONFIG hook, and so that was done. Happy Day! -- 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. ___ 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
fetch(1) fails with https:// - Authentication error
It seems recent OpenSSL update broke fetch(1) for me. $ diff -u $SRC_BASE/crypto/openssl/apps/openssl.cnf /etc/ssl/openssl.cnf $ fetch https://foo/bar fetch: https://foo/bar: Authentication error Same error as with the patch for 1.0.0d from a year ago and same workaround - s/SSLv23_client_method/SSLv3_client_method/. -- FreeBSD 10.0-CURRENT #0 r238415: Fri Jul 13 07:18:02 UTC 2012 foo@bar:/home/blah/.cache/a/freebsd/sys/a/misc/MODULAR amd64 world built with clang ___ 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 ia64/ia64
TB --- 2012-07-14 03:14:06 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 03:14:06 - 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 --- 2012-07-14 03:14:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2012-07-14 03:14:06 - cleaning the object tree TB --- 2012-07-14 03:14:06 - cvsupping the source tree TB --- 2012-07-14 03:14:06 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2012-07-14 03:15:13 - building world TB --- 2012-07-14 03:15:13 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 03:15:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 03:15:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 03:15:13 - SRCCONF=/dev/null TB --- 2012-07-14 03:15:13 - TARGET=ia64 TB --- 2012-07-14 03:15:13 - TARGET_ARCH=ia64 TB --- 2012-07-14 03:15:13 - TZ=UTC TB --- 2012-07-14 03:15:13 - __MAKE_CONF=/dev/null TB --- 2012-07-14 03:15:13 - cd /src TB --- 2012-07-14 03:15:13 - /usr/bin/make -B buildworld World build started on Sat Jul 14 03:15:14 UTC 2012 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 Sat Jul 14 04:50:54 UTC 2012 TB --- 2012-07-14 04:50:54 - generating LINT kernel config TB --- 2012-07-14 04:50:54 - cd /src/sys/ia64/conf TB --- 2012-07-14 04:50:54 - /usr/bin/make -B LINT TB --- 2012-07-14 04:50:55 - cd /src/sys/ia64/conf TB --- 2012-07-14 04:50:55 - /usr/sbin/config -m LINT TB --- 2012-07-14 04:50:55 - building LINT kernel TB --- 2012-07-14 04:50:55 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 04:50:55 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 04:50:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 04:50:55 - SRCCONF=/dev/null TB --- 2012-07-14 04:50:55 - TARGET=ia64 TB --- 2012-07-14 04:50:55 - TARGET_ARCH=ia64 TB --- 2012-07-14 04:50:55 - TZ=UTC TB --- 2012-07-14 04:50:55 - __MAKE_CONF=/dev/null TB --- 2012-07-14 04:50:55 - cd /src TB --- 2012-07-14 04:50:55 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 14 04:50:55 UTC 2012 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-serverworks.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-siliconimage.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-sis.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL
[head tinderbox] failure on mips/mips
TB --- 2012-07-14 04:10:08 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-07-14 04:10:08 - 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 --- 2012-07-14 04:10:08 - starting HEAD tinderbox run for mips/mips TB --- 2012-07-14 04:10:08 - cleaning the object tree TB --- 2012-07-14 04:10:08 - cvsupping the source tree TB --- 2012-07-14 04:10:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-07-14 04:10:59 - building world TB --- 2012-07-14 04:10:59 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 04:10:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 04:10:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 04:10:59 - SRCCONF=/dev/null TB --- 2012-07-14 04:10:59 - TARGET=mips TB --- 2012-07-14 04:10:59 - TARGET_ARCH=mips TB --- 2012-07-14 04:10:59 - TZ=UTC TB --- 2012-07-14 04:10:59 - __MAKE_CONF=/dev/null TB --- 2012-07-14 04:10:59 - cd /src TB --- 2012-07-14 04:10:59 - /usr/bin/make -B buildworld World build started on Sat Jul 14 04:11:00 UTC 2012 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 Sat Jul 14 05:14:47 UTC 2012 TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m ADM5120 TB --- 2012-07-14 05:14:47 - skipping ADM5120 kernel TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m ALCHEMY TB --- 2012-07-14 05:14:47 - skipping ALCHEMY kernel TB --- 2012-07-14 05:14:47 - cd /src/sys/mips/conf TB --- 2012-07-14 05:14:47 - /usr/sbin/config -m AP93 TB --- 2012-07-14 05:14:47 - building AP93 kernel TB --- 2012-07-14 05:14:47 - CROSS_BUILD_TESTING=YES TB --- 2012-07-14 05:14:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-07-14 05:14:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-07-14 05:14:47 - SRCCONF=/dev/null TB --- 2012-07-14 05:14:47 - TARGET=mips TB --- 2012-07-14 05:14:47 - TARGET_ARCH=mips TB --- 2012-07-14 05:14:47 - TZ=UTC TB --- 2012-07-14 05:14:47 - __MAKE_CONF=/dev/null TB --- 2012-07-14 05:14:47 - cd /src TB --- 2012-07-14 05:14:47 - /usr/bin/make -B buildkernel KERNCONF=AP93 Kernel build for AP93 started on Sat Jul 14 05:14:48 UTC 2012 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 [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_variables.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_watch.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/ddb/db_write_cmd.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
