Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Fri, Oct 26, 2012 at 09:34:20AM -0700, David O'Brien wrote: (there are no pre-build packages for 10-CURRENT). Please see the first two entries on: http://pkgbeta.freebsd.org/ mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
On Tue, Jul 17, 2012 at 01:56:33PM -0700, Dave Hayes wrote: I've been using FreeBSD since the 90s. My perception (over many years of observation) is that the FreeBSD people most able to document what exists and how to use it seem to also have the greatest resistance to writing any documentation. I'll just note that over the past ~6 months, the documentation team has seen a lot of new contributors and new energy. So from my view, the situation is improving. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote: That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. You seem to be missing a couple of principles here, the most important of which is first, do no harm. FreeBSD has as one of its underlying principles not to violate POLA (Principle Of Least Astonishment.) The corollary is that we don't replace code unless we're convinced (not just told) that the replacement is a better solution. If this makes FreeBSD more conservative than the way other OSes do things, so be it. I'm not trying to be harsh here. What I'm saying is that the burden of proof is on the person making the claims it's better to demonstrate that it's so. Otherwise, there are a zillion PRs with patches already in the database for committers to pick up and work on. I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. Then I expect the situation to remain unchanged. fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 04:17:52PM +0300, Vitaly Magerya wrote: The last time concurrent rc patches where proposed I measured boot time on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from power on to login prompt, 20-25 where spent in rc, and parallel execution of it shaved off 7 seconds from boot time. OK, I stand corrected. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 10:16:30AM +0200, Damien Fleuriot wrote: I'm thinking we might jump straight from 8.x to 10 when the time comes, I'm really looking forward to Gleb's work on CARP and PF ;) I don't know why you might think one .0 release would be more mature than another .0 release. Maybe I'm misunderstanding. There are not many boxes I could try 9.0 on, because they're in production with pfsync to conserve client sessions and I'm loath to take risks with most of our firewalls. This is where having one or more systems for development is key. Installations like yours are in a far better situation to test FreeBSD under realistic loads than are all but a few of the FreeBSD developers. I would urge testing long before the leadup to a .0 release, not afterwards. Apologies if I'm just repeating myself here, but FreeBSD does not have a dedicated QA department. We are reliant on our users to test in real- world conditions. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 06:50:34AM +0200, Wojciech Puchar wrote: does it matter. cvsup RELENG_8 and you see updates are done constantly. just sometime somebody decide to change number :) The difference is the freeze-and-test work that goes between random date and release time. This requires a nontrivial time committment from both developers and users. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Thu, Jun 14, 2012 at 10:29:22AM +0200, Damien Fleuriot wrote: Whoever said STABLE is no good for production ? I used to make us stick to 8.2-RELEASE here at work, but some bugfixes are just too important to skip (we're running firewalls and had a problem with a CARP bug). In theory we try our best to keep -STABLE, well, stable in behavior and not just the API, but in practice any given snapshot of -stable may or may not have uncaught regressions in it. I reiterate, the major difference between -stable and -release is a more thorough QA process for the latter :-) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: usertime stale at about 371k seconds
On Wed, Jun 13, 2012 at 12:30:08AM +0400, Andrey Zonov wrote: No, I didn't. I want to fix the problem not just file a PR and wait for years. I do understand your frustration, but we have some new people interested in picking up and handling src-related PRs, so I see the situation as improving a bit. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Tue, Jun 12, 2012 at 07:08:08PM -0400, Jerry McAllister wrote: You sound like the people who can't decide to get something because a new version is going to come out sometime before they die. That may be how it seems to end-users, but as we have heard multiple times from people who use FreeBSD to help run their businesses, information about scheduling and support of releases is key to their decisions on when to upgrade, or even whether to use FreeBSD in the first place. To them, your characterization is going to sound quite unfair. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Mon, Jun 11, 2012 at 03:38:56PM -0700, John Kozubik wrote: I am looking at the upcoming release schedule, and I only see 9.1 listed - can anyone confirm or deny 8.4 ? Although I am not on re@, AFAIK the only schedule that is on the table is the one for 9.1. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 09:45:47PM +1000, Da Rock wrote: 1. Incidentally, what exactly does constitute a major release? That point in time where we guarantee that we break a certain degree of backwards compatibility. (Well, that's the key component. Feature- additions ride on top of that.) 2. Is there a reason to update the numbers so quickly? Yes, so that we don't have to keep supporting backwards compatibility for as long a period (see 1) -- it's a significant burden to maintain. It's necessary to do these as we rework things like network layers for higher performance, rework wireless to work with modern devices, and other high-demand items. 3. Could a higher bar be set to reach a major release than simply temporal objectives? Yes. We did that with 5.x, and blew it big-time. The goal of rewrite the entire system to support SMP in a scalable, reliable fashion was simply too aggressive. It led to ~5 years between major releases, and by that time the system had changed very dramatically (SMP, suspend/resume, IIRC GEOM, and too many other things to list). It was a huge jump and the learning curve for upgrading was way too large. We lost userbase. Also, keeping 5 years between major releases led to very high developer frustration. Why work on something when it will take 4+ years to even see the light of day? This is why we moved to the time-based releases. 18 months was seen as a compromise between all the various demands. Even so, we are almost exactly at 24 months in practice; see the graphs I updated last month as a result of all the recent discussion: http://people.freebsd.org/~linimon/schedule/ My own view is that 5 years between major releases is not going to happen, due to how painful the 5.x experience was for all concerned. But as I'm not a src committer, I'm not one of the people who will be picking the interval for our major-branch timeline. I just try to graph it as it goes by. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 10:23:43PM +, Mark Blackman wrote: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/release-proc.html New releases of FreeBSD are released from the -STABLE branch at approximately four month intervals. That was our intention at one point. Obviously we've not stuck to that. (IMHO doing releases quite that frequently is probably beyond what we can do with volunteer staffing, but I'm not on re@ so take it as you will.) In any case, various people within the project have now absorbed the lesson that 10 months between releases is too long, and are trying to figure out what to do about it. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 26, 2012 at 10:52:44PM +, Mark Blackman wrote: I suspect poor old RE is putting too much work into BETAs and RCs for point releases. The counter-argument is that we have a lot more leeway to make mistakes on a .0 release. We're not going to be cut any slack at all for shipping a badly regressed point release. Some minor regressions are inevitable in software, but they do indeed need to be minor. For how we're doing with regressions in general, see: http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html Now, it's true that many of the recent PRs are against 9.0, and many of the ones that aren't may be stale (certainly most of the pre-2010 ones), but these are the types of things that users really notice and become unhappy about. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
I might just be also interested to review/comment code, discuss regressions, and architecture, for a change ;-) Unfortunately, such threads rarely ever happen. Most of the time, the only food provided is a really indigestible +5000/-3000 patch, where all the thinking, architectural design and code has been done behind closed door of a limited few committers, research lab or company. That's odd. What the src committers usually tell me, when I have my bugmeister-advocate hat on, is that they post patches and then no one comments until after they check them in, at which time they complain. This discourages them from going through this the next time. You will also note that some of the large commits say MFp4 or MF: projectname. That means that either our Perforce repository, or SVN project/ directory, were used as staging areas. It's possible to subscribe to these email messages. (Exactly how is left as an exercise for the reader; the hour is getting late.) As for the research lab/company commits, I'm sure you'd complain equally if the code that these groups develop in-house and then release when it's in some kind of stable state, instead didn't get released at all. But, of course, I'm wasting my time trying to give you reasoned arguments about why FreeBSD does one thing or another. AFAICT you're only interested in spreading FUD about what we do, how we do it, and what we say about it before, during, and afterwards. You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Whatever patches or review you've contributed to date, to my mind, are like the last tiny little bits of onion that are left over after one peels off all the outer layers. There may be something to it, but the effort to get down to that point is so painful that it's not worth it. tl;dr: your drama outweighs your contributions. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 25, 2012 at 03:58:41AM -0500, Arnaud Lacombe wrote: You seem to be obsessed by picking over semantics and finding shortcomings to be aggreived over. Semantics and proper, independent, API are crucial. I'm talking about the semantics of the non-technical part: the wording of things that people post in email. viz: the time-wasting nonsense about oh, it seems to be released already, has anyone noticed? from a few weeks ago. It was 100% FUD, which apparently you knew perfectly well at the time, and thus AFAICT only posted it to draw attention to yourself. That's the drama I'm talking about. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On 24 January 2012 18:36, Arnaud Lacombe lacom...@gmail.com wrote: It is less a problem of having the tools than having the will to do everything publicly. From experience, committers loves to do all kind of things privately/secretly. Perhaps it's human nature because of all the increasingly nit-picky, passive- agressive, whiny, sarcastic, and generally asinine postings such as yours. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 24, 2012 at 12:24:22PM +0100, vermaden wrote: It would also be good to have some wiki.freebsd.org page that would describe what information is needed to fill a good PR See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/ . Your suggestion to include things like dmidecode is a good one, and we should add those. I still was (or at least felt) that was a FreeBSD newbie that time, so I did not knew if my 'handbook part' was just rubbish, or stupid, or ... whatever, no one responded, so I assumed that its not needed/useless and moved along. I'm hoping that the forums are a better place for new users to ask questions these days, than the high-volume mailing lists. In theory it should be a more appropriate venue. (Having said that, I don't participate in the forums due to lack of time, but I understand there is a community of moderators and seasoned users on it.) It would be also good to have a wiki.freebsd.org page describing what is needed and in what format a user should send the documentation changes Perhaps there should be a docs analogue to the following: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ doc folks, any takers? I have now filled these PR's here: http://www.freebsd.org/cgi/query-pr.cgi?pr=164431 http://www.freebsd.org/cgi/query-pr.cgi?pr=164432 Thanks. This makes these issues visible. So its time for another article/page on wiki.freebsd.org, how to become a committer and help to solve PRs' See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ http://wiki.freebsd.org/BecomingACommitter how to add your mirror to FreeBSD project See: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/hubs/index.html So, let me add in conclusion, I'm willing to give a hearing to constructive criticism such as this posting. There are some good, concrete, suggestions here. If I've given the impression in my earlier response that I'm not, I'm sorry. OTOH I see a lot of non-constructive criticism go by and you'll have to excuse me for being rude to those posters. After the Nth posting like that it's simply too much for my patience. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Thu, Jan 19, 2012 at 08:07:43AM +0100, vermaden wrote: I submit PRs and try to help test them as some developer/committer will pick up the PR, submit a patch to test, but it was MANY times that the response from developer/committer was way too long that I even DID NOT HAVE THE HARDWARE anymore ... I don't have a magic wand to solve this problem. I've spent a lot of time thinking about it and it's just a hard problem to solve in general. There are several aspects: - so many computers are very broken (specifically, horrible BIOS bugs). - most committers only have one or two computers that they work with. - most committers have their own tasklist, and support users is something they never have time to get around to. support users is, in general, something Open Source OSes do not do very well (at least without a paid support staff, as is the case in some of the Linux distros.) But what's discouraging for the people that try to clean up the stale PRs is that they get yelled at when they try to do so. Thus, they tend to get demotivated as well. Support/bug triage is hard and unrewarding work. People can tend to feel that they're being blamed for bugs that they had nothing to do with creating, and burn out. Here is one of the messages that I sent by then to the mailing lists: http://lists.freebsd.org/pipermail/freebsd-doc/2007-May/012507.html ... and NOTHING HAPPENED, no one told me what to do next, should I sent a SGML version or anything ... or just GTFO. I'm sorry that nothing happened, but unfortunately that's common. Submitters sometimes have to be persistent, and maybe even catch new committers when they sign up. Our documentation is certainly in need of updating. What I have done about these 'Ports issues'? I contacted these ports maintainers and said that both RC script and AIO support for samba should be enabled by default by linking to several threads at FreeBSD Forums that the problem is known and exists ... and I did not get ANY RESPONSE till this very day, not even a GTFO (which would probably be better then nothing). When you don't get a response from a maintainer, your best bet is to file a PR against the port. If the maintainer doesn't respond, then after 2 weeks any FreeBSD ports committer is free to work on the PR and, if they agree with you, commit it via maintainer-timeout. We don't have a way to track emails that various users send to individual maintainers. With a PR open, we have a way to do that. We also track maintainer-timeouts, and these can eventually lead to a maintainer reset. I got these maintainers email addresses from http://freshports.org page, are they up-to-date there? They should be, but looking on cvsweb will tell you for certain. IIRC on each freshports page there is a link to cvsweb for the port. It's not that people does not try to help, a lot tried (and I am still trying), but its VERY unpleasant to have awareness, that you dedicated your time, tried to help as much as possible, made some steps to achieve that ... and no one even cares about that. I think it's not don't care, I think it's that unable to cope with number of incoming PRs and other requests for changes and support. As I type this, there are 1122 ports PRs (6272 total PRs). On most days, around 40 come in. It would take a few dozen more volunteers to be able to keep up with them all. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, Jan 18, 2012 at 02:18:50PM +0200, Andriy Gapon wrote: So software can already send the reminders, but the real problem is to assign the PRs in the first place. Currently most assignment are self- assignments. My experience has been that assigning PRs to people who have not specifically requested that PRs related to that subject be assigned to them, almost always results in the PRs languishing. This is why I (with bugmeister hat on) discourage the bugbusters from doing so. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Sun, Jan 22, 2012 at 11:15:09PM +1000, Da Rock wrote: Scroll up and count the serious and critical bugs too :) I didn't realise it broke the numbers into the sections. Yeah. The problem is that, over time, the values in those fields has become meaningless. Some of us try to triage what should and should not be 'critical', but other than that, the whole concept has become useless. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 02:43:21AM +, Igor Mozolevsky wrote: To be realistic, I think any serious developer should expect to spend 70% of their development time on maintenance s/developer/paid developer/ and you've got a correct model of how commercial software companies work. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, Jan 17, 2012 at 06:45:17PM -0500, Daniel Eischen wrote: The problem I have with ports is that there is not a -stable branch that tracks with -stable core. We've been working for 18 months to try to get the hardware infrastructure in place to be able to consider such approaches. It doesn't even have to be every port, just the commonly used ports. That's easy in theory, but extremely difficult in practice. The infra- sturcture is far more heavyweight (because of demand for features) than most people give it credit for. There's no concept of subset of ports tree. Go examine the hierarchy and it will become apparent why. Even a server-only concept doesn't get you as far as you might think. Again, the general problem is hard. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Giant lock gone? (was: Re: ...focus, longevity, and lifecycle)
(sorry to reply to Doug but not Dieter, but I have already deleted the prior email) On 01/18/2012 16:58, Dieter BSD wrote: So you are saying that the Giant lock was completely removed in 7.0? It was completely removed from the network stack. That was the missing qualifier in his sentence. So, to a first approximation, it had been removed from all the places that were true performance-killers. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Recommended amount of swap
On Mon, Sep 05, 2011 at 02:48:57PM -0500, Dan Nelson wrote: I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used I see you don't do mass package builds :-) Or, even build openoffice or some of the math packages. and if it is used, you're just going to thrash your swap device. That's us! :-) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: A style proposal for referring to upper-level directories in Makefiles
To me, it just makes things less readable. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] __FreeBSD_kernel__
On Sun, Jul 03, 2011 at 05:47:02PM +0200, Robert Millan wrote: isn't it enough if support is present in the FreeBSD version of these compilers (for production and development releases of FreeBSD), plus the latest release of the upstream version of each of those compilers? You may find the gcc team very uninterested in changing things around to support FreeBSD. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: E-Mail if updates available? [SEC=UNCLASSIFIED]
On Wed, Mar 30, 2011 at 02:05:32PM +0800, Wilkinson, Alex wrote: 0n Wed, Mar 30, 2011 at 07:31:27AM +0200, Jo Galara wrote: on Debian I'm using apticron which sends me an email if there are updates available for installed packages. Is there a similar program for FreeBSD? subscribe to: http://www.freshports.org/ That covers ports, but not packages. We don't have anything like that in place right now. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [patch] small fix to stop gcc warning for lib/libstand/assert.c
On Sun, Mar 14, 2010 at 01:12:14PM +0100, Alexander Best wrote: ah ok. thanks for the hint. just wanted to spare linimon from dealing with such minor prs. ;) It's much more efficient for the project to have them in GNATS. I tend to triage PRs with the TV on, so it's not like the trivial ones are a great burden. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: package building failure irritation
fwiw, the canonical way to find out if a port will package up in a clean environment (choort, with dependencies all loaded via package) is on http://pointyhat.freebsd.org/errorlogs/ , e.g., http://pointyhat.freebsd.org/errorlogs/i386-8-full/ . http://portsmon.freebsd.org gives you lots of cross-references into it and the PR database. Ignore the 'connection failed' message, it is transient and I need to fix it RSN. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Weekend PR smashing
On Thu, Feb 04, 2010 at 04:09:48AM -0600, Mark Linimon wrote: Reports that are duplicates indicate that various users are being affected by one underlying problem. At one point I was trying to gather them all into a page. I was hoping more people would do the analysis and send me additions for it. However, it looks as though the script that generates that page has rotted. I'll re-add it to my list of things-to-do ... http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html This report is now fixed. We have more kern/ PRs than any other category. This category is overloaded to mean both kernel, libraries, networking, and device drivers. http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html makes this much more tractable. I forgot to mention the 2-level hierarchy that I have set up, where you can look at PRs starting with e.g. disk/driver and then drill down to a page that references all the related PRs by manpage. It may have been just as well, since the report had also gotten stale. However, it is once again up-to-date: http://people.freebsd.org/~linimon/studies/prs/prs_for_all_groups.html There would also a slightly different way of looking at things, the ones with '[panic]' in the Synopsis. Hmm, I thought there was such a page, but it doesn't seem so. I'll put it on my list to create one. Now created: http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_panic.html Finally, I have fixed other problems, such as broken links, in other various pages under http://people.freebsd.org/~linimon/studies/prs/ mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Weekend PR smashing
[adding freebsd-bugbusters@ to the Cc:] I'm sorry I didn't respond to your earlier message. I am currently way behind on tasks that I've already promised people. The KDE howto that you cited (http://quality.kde.org/develop/howto/howtobugs.php) is quite a good one. Our pr-guidelines document isn't as thorough. Part of the problem is that we don't have enough metadata in GNATS to capture some of the things that we would like bugbusters to do, e.g., as they suggest: - attempting to reproduce an 'unconfirmed' bug and change it to 'new' The closest that we have is the 'analyzed' state, which we have used in the past to indicate 'confirmed'. If you can indeed reproduce a bug, it's fair enough to let bugmeister@ know and we can change the state. Alternatively, you can submit a followup and suggest that. Several of the folks on the bugbusting team (e.g. people who have GNATS access) monitor the mailing lists and try to track followups. (I personally track bugs@, ports-bugs@, and a few of the others, but not some of the specialty ones like n...@.) - check if a report is a duplicate Reports that are duplicates indicate that various users are being affected by one underlying problem. At one point I was trying to gather them all into a page. I was hoping more people would do the analysis and send me additions for it. However, it looks as though the script that generates that page has rotted. I'll re-add it to my list of things-to-do ... http://people.freebsd.org/~linimon/studies/prs/well_known_prs.html At this point it may be easier to look at the template that I grind up to produce that page: http://people.freebsd.org/~linimon/wellknown.prs It's clearly over a year stale, and could thus use a new set of eyes. - add '(regression)' to the title if indicated I think we've done a fairly good job of getting '[regression]' (our styling of the same idea) into the existing ones, and keeping up with new ones as they come in. Similarly, we've done pretty well with '[patch]' AFAIK. That's my reaction to some specifics on the the KDE page. Now for some more general comments. We have more kern/ PRs than any other category. This category is overloaded to mean both kernel, libraries, networking, and device drivers. http://people.freebsd.org/~linimon/studies/prs/pr_tag_index.html makes this much more tractable. (I have other ideas about how to do much better, but see below.) Whether or not existing PRs are still relevant seems to vary a bit by sub-category. There would also a slightly different way of looking at things, the ones with '[panic]' in the Synopsis. Hmm, I thought there was such a page, but it doesn't seem so. I'll put it on my list to create one. As for the bin/ PRs, you'd be surprised at how many of them are still relevant, even after several years. I've resisted the suggestion that others have made in the past just to close them for this reason. (In the past I have made an effort to contact submitters and ask them if they are still experiencing the problem, but portmgr duties have kept me away from that for a long time. This is something else where we need help.) The i386 and amd64 PRs are more likely to be can't install/run on a particular piece of hardware, and generally require the most interaction with users to isolate the problem (e.g. to ACPI interacting badly with a buggy BIOS; irq problems; devices not being supported by our current drivers; and so forth.) To work with these people need to have a bit of experience with low-level debuggers and how to examine stack traces. one of the things that concerns me is the sheer number of PRs with patches that either have been committed without the PRs being updated Well, that's a task that needs more people working on. You can start by looking at: http://people.freebsd.org/~linimon/studies/prs/prs_possibly_committed.html which is PRs that have had followups appended to their Audit-Trail by the checkin scripts. If these changes have already been merged to all the relevant -stable branches, they should be closed; otherwise, if they are not already set to 'patched', then they should be, and assigned to the committer who made the change. or the patches are simply sitting idly in PRs. There are certainly a large number of these. IWBNI we could get more of them into the 'analyzed' state to claim 'we think this patch might solve the problem'. The list by the bugbusters waiting for committers to check them out is pretty huge as well: Yes, I'm well aware of that, since I set it up :-) This goes to the more general problem that it's more fun to add new things than it is to fix existing things. FreeBSD has traditionally done much better at adding new features than in the more mundane maintenance work. This is a problem not just with FreeBSD or even open source projects in general, but all software. What's interesting is that this situation is slowly changing (again IMHO). Over the past year we have seen several
Re: HAMMER FS port (status ?)
On Thu, Sep 24, 2009 at 01:35:21PM -0300, Leandro Quibem Magnabosco wrote: I think that one questions pops into the minds of a lot of people right now: Why not just use DragonFly BSD? Feel free, but take it off-list, please. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: genuine cpu I386_CPU kernel support
On Wed, Sep 23, 2009 at 05:54:34PM +0200, Julian H. Stacey wrote: 4.11 fell out of security support some while back, but http://www.freebsd.org/security/index.html only lists what's still in, not what fell out when. Then see http://people.freebsd.org/~linimon/schedule/milestones.html. (Yes, I know the data for 7.2 and 8.0 are stale.) 4.11 support was extended again and again but ended 01/31/2007. Towards the end it was consuming a lot of people's time to support it, since everything newer had changed dramatically. Free/ Net/ Open/ Dragon etc all derive from Bill Jollitz port of BSD to 386. Would be nice if we could still keep that first platform walking, even if speed can't be called running ;-) The same comment applies. Everything has changed dramatically. Maybe I'll get time to chase down all that came before http://svn.freebsd.org/viewvc/base?view=revisionrevision=137784 I honestly can't see why you would want to waste your time like this, but it's yours to waste I suppose. (Even a notorious packrat like me has gotten rid of hardware from that era.) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD jobs
On Fri, May 15, 2009 at 06:54:53PM +0200, Julian Stacey wrote: - Those that pushed to censor jobs@ some years ago ( succesors?) are not worth having, j...@freebsd would be better without them. In your opinion. Not in mine. - Where better than hackers@ to look for support to liberate j...@freebsd from censors ? c...@. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: x11 status
On Tue, Feb 24, 2009 at 10:24:29PM -0500, Chuck Robey wrote: Why is that? Is XFree86 not getting any fixes? We didn't have anyone that wanted to support it after we switched the default to xorg. (We actually need more people willing to support xorg, as well). mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fw: request responsibility timeout
On Mon, Feb 02, 2009 at 05:17:38PM +0100, Dominic Fandrey wrote: I want to request a responsibility timeout for bin/120784 (with bugmeister hat) AFAIK no one else other than rodrigc has been doing work on the mount utilities, so I don't know who else to assign it to. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sun4v arch
On Sat, Aug 23, 2008 at 06:52:07PM -0700, Maxim Sobolev wrote: There is a better interpretation, which is that the only critical issue is lack of real users for this port, not lack of serial port support :). My understanding is the the port is in a pre-alpha state due to unfinished work in the kernel, so expecting there to be any userbase is premature. All of our 'new' architectures which are in this state have so few non- developer users that there is hardly any reason to submit PRs. AFAICT the active developers already know what's missing :-) Our implementation of GNATS barely serves us as a problem report system; it fails almost completely as a system for listing missing features. We would need to have something like that to track the status of the non- Tier-1 ports. (I used to maintain a table of how feature-complete the various ports are, but it is now way out of date.) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD hacker 101
On Fri, Jan 25, 2008 at 01:58:51PM +0800, william wong wrote: That brings me to another ponder: why juniper and cisco are using FreeBSD and not Linux even Linux performs better in an UP environment? Other posters have mentioned that there is a mix of Linux and BSD at Cisco. I don't work there, so I can't comment. However, if you're shipping a product where you don't necessarily wish to publish whatever code enhancements you've created, the BSD license is most likely a better choice. What was discussed at the last BSDCan was the fact that the companies that use BSD-licensed components are evolving towards contributing back improvements that they make to the system that they do not feel are their differentiators, and keeping to themselves the intellectual property that they feel puts them at a competitive advantage in their market. So it comes down to a legal and philosophical difference -- one that has been argued incessantly in the BSD vs. GPL camps. It can quickly become a religious argument and one that can only be resolved by agreeing to disagree -- if that. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Coverity problems?
On Fri, Jan 11, 2008 at 09:12:27PM +0100, Ivan Voras wrote: These numbers seem strange and out of proportion. I know there has been prior cooperation with Coverity - is this just old data? IIRC Coverity is not tracking our use of their software, at least in those statistics. Someone was telling me yesterday that was because we have our own copy of the Coverity server which we use, rather than accessing the one on their site that generates the statistics. Someone, please correct me if I'm wrong. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memset bugs.
On Tue, Aug 14, 2007 at 03:49:50PM -0400, Dave Jones wrote: I'm unfamiliar with how patch submission works in FreeBSD, but hopefully someone can eyeball this for correctness and get it committed, or forward it on to the right people. The way to make sure your patch doesn't just get lost in the mailing list noise is to send a Problem Report (PR). There's no guarantee that it will be handled promptly, however, as we have a large backlog (more people willing to report bugs than to do some of the dirty work :-/ Many of the developers are already stretched thin.) The documentation is available at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/. If anything is unclear, you can email [EMAIL PROTECTED] and we'll try to clarify things. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 with PAE or AMD64 on PowerEdge with 4G RAM
On Mon, Jun 18, 2007 at 02:35:59PM -0400, Mike Meyer wrote: While both FreeBSD and darwin ports (where I do development) have all the appropriate bits except oracle, the Linux distros don't have any of them in their packaging systems. It might be nice to point that out to Oracle, as a way to try to sell FreeBSD as a platform. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index
On Mon, May 28, 2007 at 12:15:28AM +0200, Michel Talon wrote: To gain some performance, a first idea would be to simplify bsd.ports.mk. I am convinced that a substantial part of the 4000 lines are historical crap which serve no useful purpose. 11272 of LOC in bsd.*.mk, but who's counting. There are tons of variables who have probably purely anecdotical interest. There are targets which could be happily suppressed. Please let us know which functionality you think is extra. You should use the individual port Makefiles as well as ports/Makefile to figure out what is unused. For extra credit, please include ports/Tools/portbuild/scripts so the build cluster will continue to work. Please don't think I am picking on you specifically; however, about every 6 months or so someone decides that the ports framework is too complicated without saying exactly what needs to be removed. Since I look at all the portmgr PRs as they come in, and participate in rejecting in some of the (by our determination) more marginal features, I can assure you that not every single new proposal makes it in there, nor has in the past. Every- thing that's in there is because there was some specific justification for it (at least at the time). Given that we had no install base, a significant rewrite would not be a burden, but that's not the case. Please note, I've agreed for several years that a great deal of the code could be factored out into some kind of C library for speed and reduction of code duplication. Some work is going towards that in the Summer of Code. But the hard part is making it work, in a backwards compatible fashion, and doing the exhaustive regression testing to prove that it solves more problems that it creates. (portmgr spends a _lot_ of time on regression testing, behind the scenes.) In summary, the ports infrastructure is really complicated because it's trying to deal with all kinds of constraints and conditions. I challenge anyone who thinks things can be removed to roll up their sleeves and make a good case for it. I'd be happy to have something easier to read. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Status Report Third Quarter 2005
When I initially wrote the Ports Status report I included information about a project that Edwin Groothuis created. At that time I neglected to get his approval for that text, and that was an oversight and a mistake on my part and I apologize. I did not intend for anyone to get the impression that anyone other than himself should get the credit for this project. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: My project wish-list for the next 12 months
On Wed, 1 Dec 2004, Scott Long wrote: 2. New installer. [... sysinstall] is fairly good at the simple task that it does [ ... ] I'll put my bugmeister-hat on and simply say that query-pr suggests otherwise. I have not spent sufficient time examining each of the PRs to figure out what the breakdown is between 'bugs within sysinstall'/ 'unable to boot FreeBSD on hardware'/'user error' but IMHO the first group contains more than a handful of PRs. (the total # is 142.) This is not to say we should abandon the KISS principle and try to come up with some all-singing/all-dancing thing; in fact, the opposite. I'd rather we spent time on making something small and solid which would contain enough of its own documentation to prevent people from tearing their hair out while trying to use it. Unlike much of the rest of the system where we assume users have at least some familiarity with FreeBSD (and a working browser), we have to engineer an installer that assumes that both of those are false. Unfortunately for me I probably will never be able to work on this unless someone wants to pay me to work on FreeBSD full-time; too many other things are ahead of it in my personal FreeBSD queue ... mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
I forgot to mention on rather important factor in this equation: Er, this is the *only* important factor. IMHO, it made most of the previous conversation be completely off-the-rails. If nothing happens, vinum is going to break even more very soon. No ... if you do a commit that changes the code assumptions upon which vinum was built, vinum will break. vinum is not going to magically break by itself. This gets back to a problem with the FreeBSD development model: people who commit changes that break things in other parts of the system do not automatically get assigned the responsibility to fix them. Now, there's no way to impose something like that requirement on a cooperative anarchy, so I am not playing the let's reorganize card -- I think most of us would agree that that dog won't hunt as we say down around these parts. But, in the real world of software engineering, He Who Breaketh It, Must Fixeth It. Your mileage may vary. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
If vinum means a lot to you, you should do something to get it above that threshold: start debugging/coding, learn to code if need be, donate money so somebody else can code if you can't do anything else. I don't use vinum so I have no stake in this. OTOH I'm not announcing changes which will affect it, either, so the burden is not on me. I have stated my opinion as well as I can, and will now go back to working on things that I have a reasonable understanding of and chance to fix. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Where is FreeBSD going?
The only thing any of the committers cares about is what they think. Got a problem? Submit a patch. Don't like the way things are done? Submit a patch. Don't like how such-and-such a util works? Submit a patch. Please suggest an alternative, given that almost all the labor is volunteer labor. There are hundreds of PRs still to be processed that do have patches -- in fact, on most days the backlog is getting bigger, not smaller. IMHO it's reasonable to prioritize concrete suggestions over wish-list items. What else should we be doing? Except, when Matt Dillon did submit, he was told to back out his changes This had more to do with personalities than technology. Other people have had patches rejected, backouts requested, and in some cases, backouts forced upon them. Many of those people are still with the project. In a cooperative anarchy, things are never going to be perfect; further, I think it's unfair to generalize this one situation to saying this or that contribution doesn't count. This was the culminating incident of a long-standing clash between strong personalities. It's too bad that it worked out the way it did, but I think other than that it's not useful to make generalizations from this one controversy. In short, you can put all the effort you want in, but -core and many with a commit bit will resent you for it, because you're just a user. What you may be interpreting as resentment may actually just be frustration at being once again in the middle of being told things are broken without concrete suggestions about how it can be fixed. Please come up with some kind of definite proposal that you think would alleviate your, and others', concerns; and post it and let us discuss it. Keep in mind that as you do so it's a volunteer project, and you have to address the interests of the current volunteers too. Perhaps you can suggest a way to bring more volunteers in without losing any of the existing ones. I certainly don't have any answers to these kinds of questions; let me take a look at yours. mcl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
