Re: Streamline pkgsrc issues: DragonFly developer gained NetBSD commit privilege
On Sun, Sep 11, 2011 at 09:21:58PM -0400, Justin Sherrill wrote: From what I've seen in the Problem Report system, there's a 'dfly-pkg-people' alias that DragonFly issues get placed with; if you are in that group, you'll probably catch things directly. The pkgsrc people are usually very quick to act. The only exception I've found is this dfly-pkg-people@ alias Once a PR is assigned to it, you can abandon all hope it will be fixed. It would be best to remove this alias IMHO. -- Francois Tigeot
Re: Streamline pkgsrc issues: DragonFly developer gained NetBSD commit privilege
On 9/12/2011 9:22 AM, Francois Tigeot wrote: On Sun, Sep 11, 2011 at 09:21:58PM -0400, Justin Sherrill wrote: From what I've seen in the Problem Report system, there's a 'dfly-pkg-people' alias that DragonFly issues get placed with; if you are in that group, you'll probably catch things directly. The pkgsrc people are usually very quick to act. The only exception I've found is this dfly-pkg-people@ alias Once a PR is assigned to it, you can abandon all hope it will be fixed. It would be best to remove this alias IMHO. I don't know if I'd use the word usually. Like most things in life, it likely depends on who is involved. If you have already dealt with a specific maintainer who reacts quickly, then it's appropriate to keep working through him. However it can take a while for a PR to even get assigned, and then the maintainer may sit on it indefinitely without any communication. If it's just a simple patch, and especially if it's highly-used package, it might be more efficient to ping me instead. I think the dfly-pkg-people idea was probably okay in theory, but it doesn't sound like it's been too successful so far. John
Re: powernow not working on AMD Athlon XP Mobile
On Sun, Sep 11, 2011 at 6:46 PM, Maurizio Lombardi m.lombard...@gmail.com wrote: Under most of the cases, powernow kernel module is outdated, you should use acpi p-states if possible. It looks like acpi p-states do exist, but lacking CPU driver. Could you post the dmesg? dmesg attached, thanks for your quick answer. Try following patch: http://leaf.dragonflybsd.org/~sephe/pstate_machdep.c.diff See whether following sysctl appears: hw.acpi.cpu.px_dom0.select -- Maurizio Lombardi -- Tomorrow Will Never Die
