Re: ports/14489: commit references a PR
The following reply was made to PR ports/14489; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: ports/14489: commit references a PR
Date: Tue, 21 Dec 2010 09:13:31 + (UTC)
Author: bschmidt
Date: Tue Dec 21 09:13:24 2010
New Revision: 216608
URL: http://svn.freebsd.org/changeset/base/216608
Log:
Fix a panic while disabling the RF kill button, caller of the
wpi_rfkill_resume() function will take care of the lock.
PR: kern/14489
Approved by: re (kib)
Modified:
stable/8/sys/dev/wpi/if_wpi.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/amd64/include/xen/ (props changed)
stable/8/sys/cddl/contrib/opensolaris/ (props changed)
stable/8/sys/contrib/dev/acpica/ (props changed)
stable/8/sys/contrib/pf/ (props changed)
Modified: stable/8/sys/dev/wpi/if_wpi.c
==
--- stable/8/sys/dev/wpi/if_wpi.c Mon Dec 20 23:41:31 2010
(r216607)
+++ stable/8/sys/dev/wpi/if_wpi.c Tue Dec 21 09:13:24 2010
(r216608)
@@ -3004,14 +3004,12 @@ wpi_rfkill_resume(struct wpi_softc *sc)
if (ntries == 1000) {
device_printf(sc-sc_dev,
timeout waiting for thermal calibration\n);
- WPI_UNLOCK(sc);
return;
}
DPRINTFN(WPI_DEBUG_TEMP,(temperature %d\n, sc-temp));
if (wpi_config(sc) != 0) {
device_printf(sc-sc_dev, device config failed\n);
- WPI_UNLOCK(sc);
return;
}
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
___
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: Portmaster | exclude port update(s)
Freddie Cash: It's not 100% automated (as in always skip), but it works really well. I see; looks like I have to use portupgrade then (unattended excluding). Thanks for your reply Jos Chrispijn ___ 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
RFC: 'make makepatch' and alternatives
Greetings!
I had a dispute with Olli Hauer about the usage of the 'makepatch'
target for generating port patchfiles.
I am currently using patchfiles for my ports that are generated by the
version control systems and are grouped by-commit. But there is an old,
good makepatch target that creates per-file diffs based on all applied
patches.
Section 4.4 of Porters Handbook says that there should be no two patch
files that modify the single source file, so, in general, my approach is
a kind of herecy. As I understand, there are just two sound reasons to
use the makepatch:
- one has no need to worry about the patch order: hunks are
grouped by-file, so any patch order will go;
- one can simply invoke 'make makepatch' to produce all patchfiles
automatically after the virgin sources were patched and .orig
files were left in place.
There is the third reason from the Porters Handbook: To make fixes and
upgrades easier, you should avoid having more than one patch fix the
same file, but frankly, I don't quite understand its meaning, apart
from the reasoning in the point 1 raised above.
From the other hand, by-commit patchfiles have the good property that
they carry the vital metadata: the grouping of hunks and, in some
cases, the comments about the patch itself (Git patches are good example
of this). And, if the author of the patch makes a reasonable effort
to make single commits to be grouped by-topic (rather than squelching
multiple unrelated or loosely related modifications into a single
commit), such metadata is rather useful both for maintainer and persons
who will add/modify port patches. Here are my reasons:
- suppose, one is upgrading the port from version X to version Y
and he finds that the patch A doesn't apply; the most common reasons
for this are
a) upstream sources were changed in some non-trivial way, but
there is still a need to patch, but the original one should
be modified for the new version;
b) the patch was taken upstream (perhaps, with some modifications,
but there is no need to modify the original patch, since the
original problem was fixed, but, may be, in the different way);
In either case, by-commit grouping will permit the porter to immediately
identify the hunks that should be either thrown out or modified;
with the by-file approach, one will need to identify all hunks in
different patchfiles that are related to the said modification;
- suppose, the non-maintainer has to create new patch for the port
because he want to fix some problem, upgrade the port or for some
other reason; he looks into the files/ directory and sees a bunch
of patch files with a bunch of hunks inside each, but he can't
easily track their interrelations -- a time should be spent to
figure out what hunks serve what purpose. By-commit patchfiles
have no such problem -- the metadata is already here.
Olli said to me that by-file grouping makes it easier to understand
what files were patched. That's true, but it is not so hard to
get this information from the by-commit patchfiles: it is a trivial
scripting that can be added to the bsd.port.mk (I can provide it
if it is really needed).
And, transforming the by-commit patches into by-file is a loss of
data in a strict mathematical sense: transformation by-commit -
by-file has no single inverse function, there are multiple variants
how by-file hunks can be regrouped into by-commit ones.
There is a slight problem with the by-commit patches: their order
can matter, but if _PATCHFILES inside bsd.port.mk will be sorted
alphabetically, then a simple naming like 'patch-[abcd]-whatever'
will be sufficient: suppose there are already patches
{{{
patch-0001-fix-one
patch-0002-fix-two
patch-0003-fix-three
}}}
and we want to insert another patch between 2nd and 3rd. The name
like patch-0002a-fix-two-prime will do the trick.
I am obviously not trying to force anyone to move to the by-commit
patchfiles, but I just want to know
- if I am missing something with the generally-adopted scheme with
make makepatch
- if it seems reasonable to other people to employ the by-commit patch
grouping.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
___
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
bsd 6 index file
I have a couple of older boxes on freebsd 6 that are reporting ports succeeding index, even after a fresh index has been downloaded. e.g portupgrade-2.4.8_1,2succeeds index (index has 2.4.8,2) spamass-milter-0.3.1_11succeeds index (index has 0.3.1_10) i had figured something screwy with my index file until i saw on another 6.2 box. - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07534206249 e: p...@ifdnrg.com w: http://www.ifdnrg.com - IFDNRG 40 Maritime Street Edinburgh EH6 6SA - ___ 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: bsd 6 index file
On Dec 21, 2010, at 10:53 AM, Paul Macdonald wrote: I have a couple of older boxes on freebsd 6 that are reporting ports succeeding index, even after a fresh index has been downloaded. e.g portupgrade-2.4.8_1,2succeeds index (index has 2.4.8,2) spamass-milter-0.3.1_11succeeds index (index has 0.3.1_10) FreeBSD-6 is past it's end of life, and the ports tree no longer maintains a current index file for 6.x. You can do a make index yourself, but there are no guarantees that this will continue to work as time passes. Time to upgrade to FreeBSD 7 or 8... Regards, -- -Chuck ___ 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: bsd 6 index file
On 21/12/2010 19:29, Chuck Swiger wrote: On Dec 21, 2010, at 10:53 AM, Paul Macdonald wrote: I have a couple of older boxes on freebsd 6 that are reporting ports succeeding index, even after a fresh index has been downloaded. e.g portupgrade-2.4.8_1,2succeeds index (index has 2.4.8,2) spamass-milter-0.3.1_11succeeds index (index has 0.3.1_10) FreeBSD-6 is past it's end of life, and the ports tree no longer maintains a current index file for 6.x. You can do a make index yourself, but there are no guarantees that this will continue to work as time passes. Time to upgrade to FreeBSD 7 or 8... Regards, yup, yup, i know! these boxes are scheduled for upgrades once i get to the data center (freebsd-update works great, but it only takes one typo in the merged config files for a reboot to fail) INDEX-6 matched ports fine up till today however, which is why i posted. maybe today was the 'day'. ___ 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: ports/153364: [patch] games/robocode: reset maintainer
Synopsis: [patch] games/robocode: reset maintainer Responsible-Changed-From-To: gjb-freebsd-ports Responsible-Changed-By: gjb Responsible-Changed-When: Wed Dec 22 03:27:12 UTC 2010 Responsible-Changed-Why: Not a ports committer. http://www.freebsd.org/cgi/query-pr.cgi?pr=153364 ___ 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: ports/153364: [patch] games/robocode: reset maintainer
Synopsis: [patch] games/robocode: reset maintainer Responsible-Changed-From-To: freebsd-ports-freebsd-ports-bugs Responsible-Changed-By: gjb Responsible-Changed-When: Wed Dec 22 03:28:46 UTC 2010 Responsible-Changed-Why: Fix assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=153364 ___ 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: bsd 6 index file
On Tue, Dec 21, 2010 at 08:17:27PM +, Paul Macdonald wrote: On 21/12/2010 19:29, Chuck Swiger wrote: On Dec 21, 2010, at 10:53 AM, Paul Macdonald wrote: I have a couple of older boxes on freebsd 6 that are reporting ports succeeding index, even after a fresh index has been downloaded. e.g portupgrade-2.4.8_1,2succeeds index (index has 2.4.8,2) spamass-milter-0.3.1_11succeeds index (index has 0.3.1_10) FreeBSD-6 is past it's end of life, and the ports tree no longer maintains a current index file for 6.x. You can do a make index yourself, but there are no guarantees that this will continue to work as time passes. Time to upgrade to FreeBSD 7 or 8... Regards, yup, yup, i know! these boxes are scheduled for upgrades once i get to the data center (freebsd-update works great, but it only takes one typo in the merged config files for a reboot to fail) INDEX-6 matched ports fine up till today however, which is why i posted. maybe today was the 'day'. Probably depends on what ports you use, you may not have any installed that were changed since the update of INDEX-6 was stopped. As Chuck mentioned, building INDEX yourself will, probably, still work, but the one downloaded by fetchindex will be outdated. You can also check out the last known working portstree on 6 with the tag RELEASE_6_EOL. Best, -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpD58eFs8G0r.pgp Description: PGP signature
