[arch-general] cpufrequtils in [core]
Hi, Cpufrequtils 008 in [core] has long been orphaned and, as you know, actually deprecated upstream since linux 3.1 (http://kernelnewbies.org/Linux_3.1). Instead, there is cpupower (aka cpufrequtils 009) included in linux/tools and available in [community], which is stable at least in my experience. Is there anything preventing it from replacing core/cpufrequtils? Thanks. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up. Cheers, Manolo
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
On 04/17/2012 05:13 PM, Karol Blazewicz wrote:
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
And it will be reverted to the end of the week. -- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/
2012/4/17 Bartłomiej Piotrowski <b@bpiotrowski.pl>:
On 04/17/2012 05:13 PM, Karol Blazewicz wrote:
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
And it will be reverted to the end of the week.
If so, please write a note about the issues either in git or in the bugtracker https://bugs.archlinux.org/task/28370
On 04/17/12 at 05:17pm, Karol Blazewicz wrote:
2012/4/17 Bartłomiej Piotrowski <b@bpiotrowski.pl>:
On 04/17/2012 05:13 PM, Karol Blazewicz wrote:
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
And it will be reverted to the end of the week.
If so, please write a note about the issues either in git or in the bugtracker https://bugs.archlinux.org/task/28370
Sorry, I thought I understood that the patch would be reverted? M--
On 04/17/2012 05:17 PM, Karol Blazewicz wrote:
2012/4/17 Bartłomiej Piotrowski <b@bpiotrowski.pl>:
On 04/17/2012 05:13 PM, Karol Blazewicz wrote:
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
And it will be reverted to the end of the week.
If so, please write a note about the issues either in git or in the bugtracker https://bugs.archlinux.org/task/28370
It's generally against Arch ideology about maintaining vanilla packages. Apparently patches from project page have been submitted by users and I'm afraid that I can't call them official. -- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/
On 04/17/12 at 05:14pm, Bartłomiej Piotrowski wrote:
On 04/17/2012 05:13 PM, Karol Blazewicz wrote:
On Tue, Apr 17, 2012 at 5:08 PM, Manolo Martínez <manolo@austrohungaro.com> wrote:
After updating dmenu to 4.5 yesterday, it does not honour my choices of font and size. I haven't had the time to look into it yet, just wanted to give the heads up.
dmenu 4.5-2 uses the xft patch https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dmenu&id=b51cf164641b8ea4bd1c7d788ff5ab40bb2d22a5
And it will be reverted to the end of the week.
-- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/
Thanks Karol and Bartlomiej for the info. I'll wait, then. Manolo --
Am 08.04.2012 18:08, schrieb Leonid Isaev:
Hi,
Cpufrequtils 008 in [core] has long been orphaned and, as you know, actually deprecated upstream since linux 3.1 (http://kernelnewbies.org/Linux_3.1). Instead, there is cpupower (aka cpufrequtils 009) included in linux/tools and available in [community], which is stable at least in my experience. Is there anything preventing it from replacing core/cpufrequtils?
Thanks.
Probably just lazyness. Forwarding to arch-dev-public, so other devs see this, too.
On Apr 18, 2012 10:41 AM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 08.04.2012 18:08, schrieb Leonid Isaev:
Hi,
Cpufrequtils 008 in [core] has long been orphaned and, as you
know,
actually deprecated upstream since linux 3.1 (http://kernelnewbies.org/Linux_3.1). Instead, there is cpupower (aka cpufrequtils 009) included in linux/tools and available in [community], which is stable at least in my experience. Is there anything preventing it from replacing core/cpufrequtils?
Thanks.
Probably just lazyness. Forwarding to arch-dev-public, so other devs see this, too.
I adopted this with the intention of killing it. Let me know if there are objections. As far as I'm concerned the replacement can stay in community, but if anyone feel otherwise I'd be ok with moving and adopting it. Tom
On Wed, Apr 18, 2012 at 11:56 AM, Tom Gundersen <teg@jklm.no> wrote:
On Apr 18, 2012 10:41 AM, "Thomas Bächler" <thomas@archlinux.org> wrote:
Am 08.04.2012 18:08, schrieb Leonid Isaev:
Hi,
Cpufrequtils 008 in [core] has long been orphaned and, as you
know,
actually deprecated upstream since linux 3.1 (http://kernelnewbies.org/Linux_3.1). Instead, there is cpupower (aka cpufrequtils 009) included in linux/tools and available in [community], which is stable at least in my experience. Is there anything preventing it from replacing core/cpufrequtils?
Thanks.
Probably just lazyness. Forwarding to arch-dev-public, so other devs see this, too.
I adopted this with the intention of killing it. Let me know if there are objections.
As far as I'm concerned the replacement can stay in community, but if anyone feel otherwise I'd be ok with moving and adopting it.
If you move linux-tools source package into core/extra it make sense to merge it with linux package. Cheers, -- Sébastien Luttringer www.seblu.net
Am Thu, 19 Apr 2012 01:21:46 +0200 schrieb Seblu <seblu@seblu.net>:
If you move linux-tools source package into core/extra it make sense to merge it with linux package.
What sense does this make? The package linux is the kernel, the package linux-tools are kernel tools which are not necessary to be able to use the kernel. So both packages shouldn't be merged. But I agree that linux-tools should be moved to [core]. Heiko
On Apr 19, 2012 1:47 AM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Thu, 19 Apr 2012 01:21:46 +0200 schrieb Seblu <seblu@seblu.net>:
If you move linux-tools source package into core/extra it make sense to merge it with linux package.
What sense does this make? The package linux is the kernel, the package linux-tools are kernel tools which are not necessary to be able to use the kernel. So both packages shouldn't be merged. But I agree that linux-tools should be moved to [core].
I agree it would make sense to make it a split package with the kernel as the source is shipped with the kernel (afaiu). I'll leave that up to Thomas/Tobias to decide. t
Am Thu, 19 Apr 2012 01:58:09 +0200 schrieb Tom Gundersen <teg@jklm.no>:
I agree it would make sense to make it a split package with the kernel as the source is shipped with the kernel (afaiu).
I missed that Seblu meant this. This would, indeed, make sense. Heiko
Am 19.04.2012 01:21, schrieb Seblu:
As far as I'm concerned the replacement can stay in community, but if anyone feel otherwise I'd be ok with moving and adopting it.
If you move linux-tools source package into core/extra it make sense to merge it with linux package.
This would force moving these utilities to core instead of extra, and would unnecessarily bind the kernel and some userspace tools together (for example, every rebuild of the kernel would force a rebuild of these tools, regardless if they changed or not). These PKGBUILDs should definitely stay separated.
On Thu, Apr 19, 2012 at 10:34 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 19.04.2012 01:21, schrieb Seblu:
As far as I'm concerned the replacement can stay in community, but if anyone feel otherwise I'd be ok with moving and adopting it.
If you move linux-tools source package into core/extra it make sense to merge it with linux package.
This would force moving these utilities to core instead of extra, and would unnecessarily bind the kernel and some userspace tools together (for example, every rebuild of the kernel would force a rebuild of these tools, regardless if they changed or not). These PKGBUILDs should definitely stay separated.
Currently i removed the last kernel version dot in linux-tools to avoid user confusion between stable kernel number and linux-tools version. I manually check if stable release embed fix for cpupower and perf to avoid user to update when not needed. As a side note, Kernel dev have choosen to ship with kernel source tree those tools. They had the choice of moving them into linux-util or others source tree. My suggestion was to avoid work to be done twice for us. It's done on other distro like debian. -- Sébastien Luttringer www.seblu.net
Am Thu, 19 Apr 2012 13:23:40 +0200 schrieb Seblu <seblu@seblu.net>:
Currently i removed the last kernel version dot in linux-tools to avoid user confusion between stable kernel number and linux-tools version. I manually check if stable release embed fix for cpupower and perf to avoid user to update when not needed.
As a side note, Kernel dev have choosen to ship with kernel source tree those tools. They had the choice of moving them into linux-util or others source tree. My suggestion was to avoid work to be done twice for us. It's done on other distro like debian.
There's another problem with merging linux-tools into linux, that just came to my mind: customized kernels, which are based on linux from [core]. They would probably always need to build those tools even if it's not necessary to building them for every single customized kernel. Otherwise the package maintainers had a lot more work to remove all the building commands from the PKGBUILD if possible. Heiko
On Wed, Apr 18, 2012 at 11:56 AM Tom Gundersen <teg@jklm.no> wrote:
[...]
I adopted this with the intention of killing it. Let me know if there are objections.
As far as I'm concerned the replacement can stay in community, but if anyone feel otherwise I'd be ok with moving and adopting it.
Is it because "ondemand" is the default governor now? In this case I agree, there is no need for cpupower in core: it should stay in community or move to extra at best. Thanks for looking into this, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (8)
-
Bartłomiej Piotrowski
-
Heiko Baums
-
Karol Blazewicz
-
Leonid Isaev
-
Manolo Martínez
-
Seblu
-
Thomas Bächler
-
Tom Gundersen