sysutils/diskcheckd needs fixing and a maintainer
Hi all, I'm trying to clear some PRs from freebsd-ports-bugs, and I've found that sysutils/diskcheckd is in need of some attention. It doesn't appear to have been developed (or maintained) since 2001, and has a PR associated with it that looks a little tricky (koitsu@ has attempted to investigate a similar of these a while ago). I've set it DEPRECATED to expire in two months, after which I'm going to remove it if it's not fixed... Chris --- PRs --- http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 --- cvsweb --- http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/diskcheckd/ -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
net-snmp startup errors
I recently updated the net-snmp port and now when I start it up I get the following error. I'm not even using sendmail, the system is using postfix. Anyone know how/where to fix this? Starting snmpd. mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st" Error 2 (No such file or directory) could not get the assoclist ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
Hi, Reference: > From: Chris Rees > Date: Wed, 17 Aug 2011 12:18:05 +0100 > Message-id: > Chris Rees wrote: > Hi all, > > I'm trying to clear some PRs from freebsd-ports-bugs, and I've found > that sysutils/diskcheckd is in need of some attention. > > It doesn't appear to have been developed (or maintained) since 2001, > and has a PR associated with it that looks a little tricky (koitsu@ > has attempted to investigate a similar of these a while ago). > > I've set it DEPRECATED to expire in two months, after which I'm going > to remove it if it's not fixed... I browsed the 2 URLs. It seems extreme to remove a port, just to close those send-prs. Better to leave the port marked as having some run errors in some circumstances, that we dont have manpower for, but leave port in tree. Many are not accustomed to look in Attic. If its still in tree others may find it, & port any newer version. At least it compiles. If removed, some people who look for such a tool might not know it exists & already ported. Fixing a tool that has already been easily found & built, is easier than finding, porting & fixing. Those who have been helped by a pre-existant ports/ Makefile are more likely to contribute a replacement upgrade. Those that have to do their own finding & porting are less likely to contribute their upgrade. If you'r trying to force find/ blackmail ;-) a MAINTAINER, you could also ask: freebsd...@freebsd.org + those who filed the 2 x send-pr Jeremy Chadwick Vincent Poy I guess you already notified creator David W. Chapman Jr. (dw...@freebsd.org) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
On 17 August 2011 15:36, Julian H. Stacey wrote: > Hi, > Reference: >> From: Chris Rees >> Date: Wed, 17 Aug 2011 12:18:05 +0100 >> Message-id: >> > > Chris Rees wrote: >> Hi all, >> >> I'm trying to clear some PRs from freebsd-ports-bugs, and I've found >> that sysutils/diskcheckd is in need of some attention. >> >> It doesn't appear to have been developed (or maintained) since 2001, >> and has a PR associated with it that looks a little tricky (koitsu@ >> has attempted to investigate a similar of these a while ago). >> >> I've set it DEPRECATED to expire in two months, after which I'm going >> to remove it if it's not fixed... > > I browsed the 2 URLs. > It seems extreme to remove a port, just to close those send-prs. > Better to leave the port marked as having some run errors in some > circumstances, that we dont have manpower for, but leave port in > tree. We don't want to provide broken software. > Many are not accustomed to look in Attic. If its still in tree > others may find it, & port any newer version. The only sources for the port are in the tree-- upstream is whoever picks it up to maintain. > At least it compiles. If removed, some people who look for such a > tool might not know it exists & already ported. Fixing a tool that > has already been easily found & built, is easier than > finding, porting & fixing. No, see above. We don't provide broken software. > Those who have been helped by a pre-existant ports/ Makefile are > more likely to contribute a replacement upgrade. Those that have > to do their own finding & porting are less likely to contribute > their upgrade. Not sure what you're talking about here. > If you'r trying to force find/ blackmail ;-) a MAINTAINER, you could also ask: > freebsd...@freebsd.org > + those who filed the 2 x send-pr > Jeremy Chadwick Doubt it -- he left us a while ago. > Vincent Poy The PR he sent was left 18 months with no reply -- since he hasn't provided a patch I don't want to bug him for one. I have updated the PR however which he will receive notice of. > I guess you already notified creator > David W. Chapman Jr. (dw...@freebsd.org) dwcjr moved the program from src to ports, he's not the creator. I copied ben and phk in because they were involved in the original -- I certainly don't want to bother the guy who wanted to remove it in the first place. I'm not trying to force find / blackmail anyone, I'm saying 'This software is broken, if you want FreeBSD to continue to support/provide it someone needs to fix it.' Chris -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
On Wed, Aug 17, 2011 at 04:36:23PM +0200, Julian H. Stacey wrote: > Better to leave the port marked as having some run errors in some > circumstances, that we dont have manpower for, but leave port in > tree. Then we have the situation of a user spends the time to install it only to figure out it's obsolete, broken, junk. This is not desirable. > At least it compiles. If removed, some people who look for such a > tool might not know it exists & is already ported. But doesn't work. As for contacting: > Jeremy Chadwick no longer involved with the project (since 2008). > David W. Chapman Jr. (dw...@freebsd.org) no longer involved with the project (since 2001). While FreeBSD can't make the statement "all ports in our Ports Collection are useful and secure", we can at least make the attempt to weed out obviously obsolete and/or broken and/or abandoned ports, so that prospective users of them don't waste their time. That's what this whole deprecation and cleanup work is for: to get rid of the bitrot. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
On Wed, Aug 17, 2011 at 11:15:54AM -0500, Mark Linimon wrote: > > Jeremy Chadwick > > no longer involved with the project (since 2008). Actually this statement is false. He's involved with project, but not as a committer since 2008. My apologies. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fwd: Re: Some concerns about our postgresql and plpython ports
I'm sorry, Mark, but your mailserver still dislikes me, so i can't reply to to you directly: """ : host mail.soaustin.net[66.135.54.68] said: 553 5.7.1 : Sender address rejected: Refused yandex.ru: Blocked due to mail abuse: go away spamming scum (in reply to RCPT TO command) """ Исходное сообщение Тема: Re: Some concerns about our postgresql and plpython ports Дата: Wed, 17 Aug 2011 20:50:26 +0400 От: Ruslan Mahmatkhanov Кому: Mark Linimon Mark Linimon wrote on 17.08.2011 20:26: have you emailed the individual port maintainers? No. plpython is unmantained, postgresql ports are belongs to girgen@, that (by looking at commit's history) is not there, since all the recent changes was committed with "maintainer timeout" message. fwiw, I usually recommend send-pr for large fixes (OTOH dividing it up with one PR for postgresql and one for plpython would make life a little easier for us.) mcl Ok, i'll do right now. But you should take into account that plpython can't be fixed without touching postgresqlXX-server ports. I can split this up to python pkg-plist fix, postgresql9x-client build fix, and the very plpython unbreak. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Re: Some concerns about our postgresql and plpython ports
On 17 August 2011 17:56, Ruslan Mahmatkhanov wrote: > I'm sorry, Mark, but your mailserver still dislikes me, so i can't reply to > to you directly: > > """ > : host mail.soaustin.net[66.135.54.68] said: 553 5.7.1 > : Sender address rejected: Refused yandex.ru: Blocked due > to mail abuse: go away spamming scum (in reply to RCPT TO command) > """ > > Исходное сообщение > Тема: Re: Some concerns about our postgresql and plpython ports > Дата: Wed, 17 Aug 2011 20:50:26 +0400 > От: Ruslan Mahmatkhanov > Кому: Mark Linimon > > Mark Linimon wrote on 17.08.2011 20:26: >> >> have you emailed the individual port maintainers? > > No. plpython is unmantained, postgresql ports are belongs to girgen@, > that (by looking at commit's history) is not there, since all the recent > changes was committed with "maintainer timeout" message. >> >> fwiw, I usually recommend send-pr for large fixes (OTOH dividing it up >> with one PR for postgresql and one for plpython would make life a little >> easier for us.) >> >> mcl > > Ok, i'll do right now. But you should take into account that plpython > can't be fixed without touching postgresqlXX-server ports. I can split > this up to python pkg-plist fix, postgresql9x-client build fix, and the > very plpython unbreak. Careful; those timeout commits were only mine from the USERS change (unfortunately I had to revert them too... I wouldn't go so far as to say he's inactive-- in fact I had spoken to him recently IIRC. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Some concerns about our postgresql and plpython ports
Chris Rees wrote on 17.08.2011 21:23: On 17 August 2011 17:56, Ruslan Mahmatkhanov wrote: I'm sorry, Mark, but your mailserver still dislikes me, so i can't reply to to you directly: """ : host mail.soaustin.net[66.135.54.68] said: 553 5.7.1 : Sender address rejected: Refused yandex.ru: Blocked due to mail abuse: go away spamming scum (in reply to RCPT TO command) """ Исходное сообщение Тема: Re: Some concerns about our postgresql and plpython ports Дата: Wed, 17 Aug 2011 20:50:26 +0400 От: Ruslan Mahmatkhanov Кому: Mark Linimon Mark Linimon wrote on 17.08.2011 20:26: have you emailed the individual port maintainers? No. plpython is unmantained, postgresql ports are belongs to girgen@, that (by looking at commit's history) is not there, since all the recent changes was committed with "maintainer timeout" message. fwiw, I usually recommend send-pr for large fixes (OTOH dividing it up with one PR for postgresql and one for plpython would make life a little easier for us.) mcl Ok, i'll do right now. But you should take into account that plpython can't be fixed without touching postgresqlXX-server ports. I can split this up to python pkg-plist fix, postgresql9x-client build fix, and the very plpython unbreak. Careful; those timeout commits were only mine from the USERS change (unfortunately I had to revert them too... I wouldn't go so far as to say he's inactive-- in fact I had spoken to him recently IIRC. Chris Ok, this is mean i was wrong. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Some concerns about our postgresql and plpython ports
So i split this up to three pr's as was suggested by Mark: 1. Python pkg-plist fix for WITHOUT_THREADS case: http://www.freebsd.org/cgi/query-pr.cgi?pr=159842 2. postgresql-plpython unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159843 3. postgresql9x-client unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 Palle (maintainer of postgresql ports) cc'ed. Thanks in advance for handling this. PS. I just found that the similar plist fix was submitted for python26 a year ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148406 Ruslan Mahmatkhanov wrote on 16.08.2011 19:20: Hi there. We have databases/postgresql-plpython, that is marked as broken with this message: "Does not configure without threaded Python", but this is totally wrong - it actually does. I checked the internets and found this: [1] and [2]. People are actually had problems when building it WITH threaded python (that is built with threads support by default). Rebuilding python w/o threads support do the trick actually. But if you will try to build this port with threads-aware python, you'll get this error message: """ checking whether Python is compiled with thread support... yes configure: error: threaded Python not supported on this platform """ But the funny thing that it actually builds and works fine with threaded python too :). We just need to apply this patch to postgresqlXX-server's configure: - openbsd*|freebsd*) + openbsd*) And then there is no error: """ checking whether Python is compiled with thread support... yes checking for main in -lm... yes """ So what i did - i have tested the build and runtime of 8.4, 9.0, 9.1b3. both with threads-aware python and threadless python (version 2.7.2, runtime is tested only on 9-CURRENT, but with all the three PostgreSQL versions). And all of this configurations works well. For testing i'm used sample function (pymax.sql) from PosgreSQL manual and simple script (plpython.sh), that adds/removes and runs the function: """ [mrk@smeshariki2 plpython]> cat pymax.sql CREATE FUNCTION pymax (a integer, b integer) RETURNS integer AS $$ if a > b: return a return b $$ LANGUAGE plpythonu; """ """ [mrk@smeshariki2 plpython]> cat plpython.sh #!/bin/sh createlang -U pgsql plpythonu test psql -U pgsql test -f pymax.sql psql -U pgsql test -c "select pymax(1,2)" psql -U pgsql test -c "drop function pymax(a integer, b integer)" droplang -U pgsql plpythonu test """ To build databases/postgresql-plpython with PostgreSQL 9.1b3 i've used patch from [4] by Martin Neubauer , it is also included into my patch [3]. Updated regexp also working fine with 8.4 and 9.0. plpython module for 9.0 and 9.1 was renamed to plpython2.so, but there is also plpython.so symlink in 9.0 that points to plpython2.so. 9.1 also installs some extension files, so i fixed pkg-plists accordingly. Since 9.0 PostgreSQL guys use docbook for building all the documentation, including man-pages. They ever listed all the dependencies needed on FreeBSD to make it build. See [5]. But because our postgresql-client ports didn't include needed dependencies, their build are broken. In particular: postgresql91-client is broken on FreeBSD-8.2 postgresql90-client is broken on FreeBSD-7.4 postgresql91-client is broken on FreeBSD-7.4 So i have fixed this too by adding this deps to the ports. And i'm not see another solution. We need man-pages for postgresql9x-client, and man-pages needs all that docbook stuff. To make lang/python27 build without threads under tinderbox, i was forced to fix it's plist. Please see patch [6]. Probably similar patch should be applied against other python versions. The plpython port is unmantained, so please commit this anybody. Below are build logs of various configurations. Threads-aware python: - 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-8.4.8_1.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.0.4_1.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.1.b3_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-8.4.8_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-client-9.0.4_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-9.1.b3_1.log Threadless python: -- 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-8.4.8_1-wo-threads.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.0.4_1-wo-threads.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.1.b3_1-wo-threads.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-8.4.8_1-wo-threads.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-9.0.4_1-wo-threads.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-9.1.b3_1-wo-threads.log To sum up what is included into patch [3]: - databases/postgresql-plpython no more marked as broken, since it builds both with threaded and threaless python on all
mencoder / p5-Unicode-Map8
Hi everyone, I just tried to build mencoder from ports (ports tree is up to date). I had to remove libass subtitle support from the configuration because p5-Unicode-Map8 failed to build: cp Map8/maps/IBM278.bin blib/lib/Unicode/Map8/maps/IBM278.bin /usr/local/bin/perl5.10.1 /usr/local/lib/perl5/site_perl/5.10.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.10.1/ExtUtils/typemap -typemap typemap Map8.xs > Map8.xsc && mv Map8.xsc Map8.c Could not find a typemap for C type 'U16*' in Map8.xs, line 229 *** Error code 1 Stop in /usr/ports/converters/p5-Unicode-Map8/work/Unicode-Map8-0.13. *** Error code 1 Regards, Frank ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
> software is broken, if you want FreeBSD to continue to support/provide > it someone needs to fix it.' Thanks for the reply Chris. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
Hi Mark, > On Wed, Aug 17, 2011 at 04:36:23PM +0200, Julian H. Stacey wrote: > > Better to leave the port marked as having some run errors in some > > circumstances, that we dont have manpower for, but leave port in > > tree. > > Then we have the situation of a user spends the time to install it only > to figure out it's obsolete, broken, junk. This is not desirable. > > > At least it compiles. If removed, some people who look for such a > > tool might not know it exists & is already ported. > > But doesn't work. As for contacting: > > > Jeremy Chadwick > > no longer involved with the project (since 2008). > > > David W. Chapman Jr. (dw...@freebsd.org) > > no longer involved with the project (since 2001). > > While FreeBSD can't make the statement "all ports in our Ports Collection > are useful and secure", we can at least make the attempt to weed out > obviously obsolete and/or broken and/or abandoned ports, so that prospective > users of them don't waste their time. > That's what this whole deprecation and cleanup work is for: to get rid of > the bitrot. I can live with whatever Chris, you & ports team decide on this port, But .. I'd question _why_ valuable people like you & Chris would allow your time to be distracted merely to try to get repair run time capability of a port. Run time performance should be beyond priority remit of central ports team, There's more important work for their rare skills. As Vadim Goncharov just wrote to arch@ Wed, 17 Aug 2011 23:10:19 + (UTC) on another thread: "we often have not enough \n time/resources" Only a limited number of people are skilled in ports/ variables & arcane macros etc, many shy away. A great deal more normal *Unix* generic people are perfectly capable of fixing many normal post build problems, eg the run time problems of this port. Ports team members with rare understanding of arcane ports make variables & macros, should be concentrating on that, to enhance the general automatic build capability, so less ports fight with each other & break at build time. Colliding & breaking ports has been The most serious problem of ports for years. far more serious than bit rot in odd old obscure ports, eg run time errors. So, after repeating I can live with whatever Chris, you & ports team decide on this port, I'd suggest ports team spend minimal time on this port & other similar bit rot ports. Don't try to fix run time performance/errors. Don't lose time on merit or de-merit of deleting a port that builds, to allow 2 send-pr to be deleted. Instead invent & apply new variable[s] eg INSTALL_OR_RUN_DEPRECATED="summary of 2 send-prs" aka eg RUN_DEPENDS BUILD_DEPENDS etc Consider that sufficient to allow a closure of send-pr after copying send-prs to a README dir in the port. Leave it & other easy ports runtime problems for less [ports]skilled users to fix. & conserve your valuable time for the hard stuff, eg More compatability automation between competing ports. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
Chris Rees wrote: > We don't want to provide broken software. Mark Linimon wrote: > ... it's obsolete, broken, junk ... Unless there is more to this than is reported in those two PRs, I'd call it a considerable exaggeration to describe diskcheckd as "broken". * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 is shown as "closed", so presumably is no longer a problem. * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566 says "... diskcheckd runs fine when gmirror is not involved ..." and then goes on to describe a problem _when diskcheckd is run on a component of a gmirror_. How anyone got from "in some way incompatible with gmirror" to "broken" escapes me. One could as well claim that gmirror is "broken" because it is incompatible with diskcheckd >:-> I'm currently running diskcheckd on an 8.1 gmirrored system with config file /dev/ad0 * * 8192 -- which should be using about 1/6 of that disk's bandwidth -- and will see what happens when it reaches the end of the disk (sometime tomorrow). So far I have not seen any issues. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: sysutils/diskcheckd needs fixing and a maintainer
On 18 August 2011 09:03, wrote: > Chris Rees wrote: > >> We don't want to provide broken software. > > Mark Linimon wrote: > >> ... it's obsolete, broken, junk ... > > Unless there is more to this than is reported in those two PRs, > I'd call it a considerable exaggeration to describe diskcheckd > as "broken". > > * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 > is shown as "closed", so presumably is no longer a problem. Wow, would it have been too difficult to actually READ the closing message from Jeremy? I suggest you look again -- I've pasted it here so you can see it. "The problem here is that the code does not do what the manpage says (or vice-versa). The 3rd column does not specify frequency of checking, but rather, over what duration of time to spread a single disk scan over. Thus, 7 days would mean "spread the entire disk check at X rate over the course of 7 days". There is still a bug in the code where large disks will cause problems resulting in updateproctitle() never getting called, and so on, but that's unrelated to this PR. I'm closing the PR because trying to fix all of this should really be ben@'s responsibility. (Sorry for sounding harsh.)" How does that indicate it's fixed? It's an 'abandoned' PR. > * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143566 > says "... diskcheckd runs fine when gmirror is not involved ..." > and then goes on to describe a problem _when diskcheckd is run > on a component of a gmirror_. > > How anyone got from "in some way incompatible with gmirror" to > "broken" escapes me. One could as well claim that gmirror is > "broken" because it is incompatible with diskcheckd >:-> No. It's broken because there's no logical reason -- it will probably break with other things. > I'm currently running diskcheckd on an 8.1 gmirrored system with > config file > > /dev/ad0 * * 8192 > > -- which should be using about 1/6 of that disk's bandwidth -- and > will see what happens when it reaches the end of the disk (sometime > tomorrow). So far I have not seen any issues. Thank you for testing and investigating, this is what the port has needed, and two days of being deprecated has achieved more than 18 months of a PR being open. Chris -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
