Re: [setup] no floppies FreeBSD 8 ?
I am not sure whether we dropped floppy support. But I can imagine that the release candidates do not have floppies. On Oct 4, 2009, at 1:54 PM, luca wrote: hi, I'm looking for the floppies images to install FreeBSD 8 on a PC which can't boot from CDROM ; but the images are not available (i.e. no floppies directory) Do FreeBSD 8 dropped floppy install ? Regards, Luca ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- /\ Best regards,| re...@freebsd.org \ / Remko Lodder | re...@efnet Xhttp://www.evilcoder.org/| / \ ASCII Ribbon Campaign| Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [releng_7 tinderbox] failure on i386/i386
Fixed! On Mon, February 11, 2008 9:46 am, FreeBSD Tinderbox wrote: TB --- 2008-02-11 08:10:55 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-02-11 08:10:55 - starting RELENG_7 tinderbox run for i386/i386 TB --- 2008-02-11 08:10:55 - cleaning the object tree TB --- 2008-02-11 08:11:18 - cvsupping the source tree TB --- 2008-02-11 08:11:18 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/i386/supfile TB --- 2008-02-11 08:11:26 - building world (CFLAGS=-O2 -pipe) TB --- 2008-02-11 08:11:26 - cd /src TB --- 2008-02-11 08:11:26 - /usr/bin/make -B buildworld World build started on Mon Feb 11 08:11:27 UTC 2008 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 [...] building profiled archive library ranlib libarchive_p.a gzip -cn /src/lib/libarchive/archive_entry.3 archive_entry.3.gz gzip -cn /src/lib/libarchive/archive_read.3 archive_read.3.gz gzip -cn /src/lib/libarchive/archive_util.3 archive_util.3.gz gzip -cn /src/lib/libarchive/archive_write.3 archive_write.3.gz gzip -cn /src/lib/libarchive/archive_write_disk.3 archive_write_disk.3.gz make: don't know how to make cpio.5. Stop *** Error code 2 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2008-02-11 08:46:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2008-02-11 08:46:52 - ERROR: failed to build world TB --- 2008-02-11 08:46:52 - tinderbox aborted TB --- 1679.28 user 218.31 system 2156.87 real http://tinderbox.des.no/tinderbox-releng_7-RELENG_7-i386-i386.full ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-i386 To unsubscribe, send any mail to [EMAIL PROTECTED] -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PR backlog
Hello Warner et all, On Wed, December 26, 2007 7:42 pm, M. Warner Losh wrote: Mark and Henrik make a number of good points here. Rather than reply to the details, I'm going to make a couple of quick observations. As a project we're not leveraging the community sufficiently when it comes to contributions. The current system of patch review and submission is very hap-hazard. If you happen to get the attention of the right person at the right time, then it goes in. If not, patches can languish a long time in the PR system. Indeed, I am one of the persons trying to find these relatively easy things which I can do along side my other projects and things, but I dont see them all (eventhough I try to keep track of them as much as possible); but what will happen is that I learn more and more about the system and at some point in time I will stop working on these easy PR's and seeking more difficult ones to fix, at that point someone else has to step up to fill in the gap that gets created; this might be a problematic part :-) Though for everyone having simple fixes, please send them to me so that I can evaluate them and (together with Warner in this case (As my mentor)) I will try to get them in as correctly and quickly as possible :-) (keeping up with the high standards of FreeBSD ofcourse). The PR system is also the wrong tool for the job. While Mark touches on the cultural issues in play, they are exacerbated by the misapplication of a problem system to be a patch submission and tracking system. Maybe we need to adopt a practice from the Linux community. At least for arm kernel patches, there is a two step process: submit it to a mailing list for review and refinement, with the second step being submitting it into a queue. I'm not sure the details we need to be successful in the FreeBSD project. Many of the USB patches in the PR system I left alone because I didn't have the time and/or knowledge to evaluate them for inclusion, or I saw something obviously wrong in the patch. When I was trying to just get through the obviously trivial patches. Warner Some things that I think need to be done by the bugbuster/bugmeister team and additional people is a constant effort to keep track of the incoming tickets; Mark does a great job at that, and I try to helpout as much as possible there, but we are all busy every now and then and then a backlog on processing the incoming tickets gets created and we loose the battle :-) This is where you (the reader) can get in and try to help us with that, so that we can properly assign the tickets, and try to keep track of them so that they can get resolved as soon as possible. Though, some complains are that we are not fast enough etc, I think we need to make sure that everyone keeps understanding that we are a Voluntary project, and that we have resources at unknown times and dates, a committer can be active the one day, and remain inactive the rest of the week; that's a side effect on the project being based on volunteers; we did a good job so far with that, but every now and then something slips in between. What we should do at that point is not ranting around as I see happen sometimes, but instead try to get the bugbusters / bugmeister team involved so that we can see what other options are available, sometimes we can succeed in and sometimes we cannot; but dont keep the problem to yourself and the assigned person because that might not work :-) Just my E 0,02 :-) -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATCH: FreeBSD-7-BETA4 'bge' ether for Dell T105 server
Mark Andrews wrote: Thanks to Max Laier's help, the ether device is now working with the 'bge' driver. Here is a patch that makes it work. I just recompiled the kernel afterwards and it comes up. PS: the T105 is now $399 but includes 1GB RAM and 2x160GB disk, in addition to the dual-core 1.8GHz Opteron and DVD reader. (Is there a better way to do this? sorry for the CC's, wasn't sure which was appropriate for getting this into the tree.) send-pr is the appropriate command for submitting these sorts of fixes. Indeed, nevertheless I just committed the information you send (Chris) and hopefully I can get this in soon, thanks for reporting this though! Cheers remko -- /\ Best regards, | [EMAIL PROTECTED] \ / Remko Lodder | [EMAIL PROTECTED] Xhttp://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NZ Daylight Savings changes.
Edwin Groothuis wrote: On Wed, Aug 22, 2007 at 10:30:57AM +1000, Mark Andrews wrote: On Wed, Aug 22, 2007 at 11:38:21AM +1200, Jonathan Chen wrote: Would it be possible for a committer to take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=115697 There's only about a month or so before the new daylight savings rule becomes effective, and it would be nice if -STABLE had the changes committed before then. The port misc/zoneinfo has been updated with the 2007g version of the zoneinfo files, I'm going to see if I can get approval of re@ to commit this. Which really needs to be properly integrated into the base system with a NO_something to prevent the database being clobbered when the system is rebuilt. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/104713 I've poked remko@ in this email to ask him the status about the MFC. He said he didn't want me to do the MFC, so it's on his plate. I saw at http://www.freebsd.org/cgi/cvsweb.cgi/src/share/zoneinfo/australasia that the 2007f is also not MFCed. Edwin Indeed, I want to do my own MFC's, the implementation in -current is different for older branches because the new logic is not in place for older versions. That said with or without the NO/WITHOUT_ZONEINFO stuff in the tree, you can update the zoneinfo part so do not point at me for that. -- Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NZ Daylight Savings changes.
Edwin Groothuis wrote: On Wed, Aug 22, 2007 at 12:30:59PM +0200, Remko Lodder wrote: Edwin Groothuis wrote: On Wed, Aug 22, 2007 at 10:30:57AM +1000, Mark Andrews wrote: On Wed, Aug 22, 2007 at 11:38:21AM +1200, Jonathan Chen wrote: Would it be possible for a committer to take a look at: http://www.freebsd.org/cgi/query-pr.cgi?pr=115697 There's only about a month or so before the new daylight savings rule becomes effective, and it would be nice if -STABLE had the changes committed before then. The port misc/zoneinfo has been updated with the 2007g version of the zoneinfo files, I'm going to see if I can get approval of re@ to commit this. Which really needs to be properly integrated into the base system with a NO_something to prevent the database being clobbered when the system is rebuilt. http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/104713 I've poked remko@ in this email to ask him the status about the MFC. He said he didn't want me to do the MFC, so it's on his plate. I saw at http://www.freebsd.org/cgi/cvsweb.cgi/src/share/zoneinfo/australasia that the 2007f is also not MFCed. Edwin Indeed, I want to do my own MFC's, the implementation in -current is different for older branches because the new logic is not in place for older versions. That said with or without the NO/WITHOUT_ZONEINFO stuff in the tree, you can update the zoneinfo part so do not point at me for that. It might be different between -current and the older branches, but it fits in with the code used in the patch given by Mark which you had to modify two months ago to fit in with the new logic. Edwin Not everyone is as great as you Edwin, sorry there are lesser people around in the world. I would prefer it if you stop behaving like this (You did that recently in another group, in private and now on public lists). It does not suit you being this kind of person, perhaps you can have a walk on the outside or something. If you do and you see the more subtle and kind Edwin, please ask him to take place at the helm. Thanks. -- Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default dns config change causing major poolpah
Doug Barton wrote: Replying en masse to bring related thoughts together. It was already posted, but a more complete treatment of my reasoning is found at: http://lists.oarci.net/pipermail/dns-operations/2007-August/001856.html Skip Ford wrote: Randy Bush wrote: the undiscussed and unannounced change to the default dns config to cause local transfer of the root and arpa zone files has raised major discussing in the dns operational community. (see the mailing list [EMAIL PROTECTED]). did i miss the discussion here? No. There was none. i have spent some hours turning off the default bind and going custom on a dozen or so machines around the planet. i am not happy. Randy, You might make your life a little easier by checking out src.conf(1) in 7-current and make.conf(1) in 6-stable which both document the various NO_BIND_* knobs that are available. What you probably want is NO_BIND_ETC. I don't have an axe to grind. I don't run the default config on any of my 2 dozen name servers (not all of which run bind anyway) so I wasn't really affected by the change. However, I thought it was a really, really, terrible idea, You're entitled to your opinion. If you take a look at the thread on the dns-operations list you'll see that there are a lot of really smart people lined up on both sides of this argument. and a rather rude act considering it relies on the charity of others to not break. The same can be said of the root server network in general. There is no requirement that FreeBSD users be permitted to slave the roots. Everyone who uses the default config can have their setups broken the day after installation. The root server operators do not make changes in this kind of abrupt fashion. We never asked permission to use the resources of others in this way, and they're not required to allow us to do so. Once again, the same is true of resolution from the root servers as well. The original commit message for the change indicated it was done to bring us in line with current best practices but that commit message is the only place I have ever seen anyone say that slaving the roots is current best practice. The BCP comment you're referring to was in regards to the default localhost zone generation which is not in any way related. Please see: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/namedb/named.conf Heiko Wundram (Beenic) wrote: Am Mittwoch 01 August 2007 13:07:27 schrieb Skip Ford: snip You might want to check the thread starting with: [EMAIL PROTECTED] (Problems with named default configuration in 6-STABLE) Easier for most folks to access this by: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=207558+0+archive/2007/freebsd-stable/20070722.freebsd-stable That thread involved an issue of resolving local zones that could not be resolved because of a combination of slaving the root zone and the new default empty reverse zones for RFC 1918 space; and how that interacted with the forwarders clause that user had in his config. Dag-Erling Smørgrav wrote: This is about on par with unnamed network equipment manufacturer selling SOHO routers that synchronize their clocks using stratum-1 NTP servers. I don't really think that analogy holds up, given that those who run public stratum-1 NTP servers specifically request that individual hosts not sync from them. The root server operators have a choice of whether to enable AXFR or not. Also, that configuration could not be changed, but named.conf can be changed easily. If there is a consensus based on solid technical reasons (not emotion or FUD) to back the root zone slaving change out, I'll be glad to do so. I think it would be very useful at this point if those who _like_ the change would speak up publicly as well. Regards, Doug I like the change! -- Kind regards, Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Kip Macy wrote: On Wed, 18 Oct 2006, Jack Vogel wrote: I'm a bit confused from the way you worded this, do you have watchdogs with em, or you use em to avoid them? I have watchdogs with the current (post vendor update) em driver, but not with an older (pre vendor update) version of it. Same here! Didn't had the problem prior to the update, after the update it started doing watchdog timeouts, occassionaly the interface goes up/down after the watchdog error. I did not spot this on my other servers yet, but the traffic passing the if_em interface is not that much (just normal webtraffic, mail traffic etc). cheers, remko -- Kind regards, Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Jack Vogel wrote: On 10/19/06, Remko Lodder [EMAIL PROTECTED] wrote: Kip Macy wrote: On Wed, 18 Oct 2006, Jack Vogel wrote: I'm a bit confused from the way you worded this, do you have watchdogs with em, or you use em to avoid them? I have watchdogs with the current (post vendor update) em driver, but not with an older (pre vendor update) version of it. Same here! Didn't had the problem prior to the update, after the update it started doing watchdog timeouts, occassionaly the interface goes up/down after the watchdog error. I did not spot this on my other servers yet, but the traffic passing the if_em interface is not that much (just normal webtraffic, mail traffic etc). cheers, remko LOL, you arent helping, i need to know WHAT CVS deltas work vs dont, in other words, which delta in the REL_ENG_6 stream broke things?? If you quantify what 'the update' means that might help me, was this the 6.2 BETA or what? Thanks, Jack It wasn't 6.2-BETA it was after the new driver import, around 2 months ago if I remember correctly. It appears to be only on machines with some data traffic. I updated to the 6-STABLE when the new intel driver was imported, after that the problems started , so my best guess is that it has something to do with that driver update. Hope this helps some more (see pciconf for more details about my cards) pciconf: [EMAIL PROTECTED]:9:0: class=0x02 card=0x11138086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' class= network subclass = ethernet [EMAIL PROTECTED]:10:0: class=0x02 card=0x11138086 chip=0x10768086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' class= network subclass = ethernet -- Kind regards, Remko Lodder ** [EMAIL PROTECTED] FreeBSD** [EMAIL PROTECTED] /* Quis custodiet ipsos custodes */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
