FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 11-11-2010, 09:54 AM
Christopher Brannon
 
Default ?

It won't build against kernel 2.6.36. There hasn't been a release in a
long time. According to the homepage, the upstream author is no longer
actively supporting it. IMHO, it should move. I could make more of an
effort to patch it if someone is *really* interested.

-- Chris
 
Old 11-11-2010, 10:34 AM
Gergely Imreh
 
Default ?

On 11 November 2010 18:54, Christopher Brannon <chris@the-brannons.com> wrote:
> It won't build against kernel 2.6.36. *There hasn't been a release in a
> long time. *According to the homepage, the upstream author is no longer
> actively supporting it. *IMHO, it should move. *I could make more of an
> effort to patch it if someone is *really* interested.
>
> -- Chris
>

Doesn't acer-wmi solve the same problem?
http://www.kernel.org/doc/Documentation/laptops/acer-wmi.txt

I have an acer laptop at home working just fine (travelmate 4500), and
I don't think I have ever used acerhk.

Cheers,
Greg
 
Old 11-11-2010, 11:32 AM
Sven-Hendrik Haase
 
Default ?

On 11.11.2010 11:54, Christopher Brannon wrote:
> It won't build against kernel 2.6.36. There hasn't been a release in a
> long time. According to the homepage, the upstream author is no longer
> actively supporting it. IMHO, it should move. I could make more of an
> effort to patch it if someone is *really* interested.
>
> -- Chris
I'm using acerhk but I also have suspend trouble with it. It effectively
stops working after the first suspend/resume cycle and I manually have
to reload the module a few seconds after resuming.
I could do without it. If it doesn't work with kernel 2.6.36, don't make
the effort to patch it. Only rather old Acer laptops need it. Newer
models seem to work with the in-kernel modules.

I appreciate your effort for acerhk so far.

-- Sven-Hendrik
 
Old 11-11-2010, 12:56 PM
Ray Rashif
 
Default ?

On 11 November 2010 20:32, Sven-Hendrik Haase <sh@lutzhaase.com> wrote:
> On 11.11.2010 11:54, Christopher Brannon wrote:
>> It won't build against kernel 2.6.36. *There hasn't been a release in a
>> long time. *According to the homepage, the upstream author is no longer
>> actively supporting it. *IMHO, it should move. *I could make more of an
>> effort to patch it if someone is *really* interested.
>>
>> -- Chris
> I'm using acerhk but I also have suspend trouble with it. It effectively
> stops working after the first suspend/resume cycle and I manually have
> to reload the module a few seconds after resuming.
> I could do without it. If it doesn't work with kernel 2.6.36, don't make
> the effort to patch it. Only rather old Acer laptops need it. Newer
> models seem to work with the in-kernel modules.
>
> I appreciate your effort for acerhk so far.

+1 drop.

If only really old Acer laptops need it, then really a minority needs
it. In that case, AUR works best.
 
Old 11-12-2010, 07:37 PM
Christopher Brannon
 
Default ?

Sven-Hendrik Haase <sh@lutzhaase.com> writes:

> I'm using acerhk but I also have suspend trouble with it. It effectively
> stops working after the first suspend/resume cycle and I manually have
> to reload the module a few seconds after resuming.
> I could do without it. If it doesn't work with kernel 2.6.36, don't make
> the effort to patch it. Only rather old Acer laptops need it.

I appreciate your feedback. It is now in the AUR and orphaned.

-- Chris
 
Old 11-18-2010, 03:16 AM
"Allan McRae"
 
Default ?

Hi,

I was thinking of doing a fairly large rebuild of packages in [core] for
the following reasons:


- The toolchain is quite good at the moment and many packages have not
been built in a long time so could use a refresher build to take
advantage of what the newer toolchain offers (~15 packages are > 1 year
old). I expect a toolchain update to happen in the next few weeks so
this is a good time.


- Get as many packages to .xz format as possible. This will give us
more room to play on the install CD (important with dual arch ISO where
I believe space is tight)


- Get all packages into the package pool. It is nicer to have
packages in one place rather than across multiple folders. Once all
packages are in the pool directories, the clean-up script can be a lot
easier (of course that is a long term implication). It would also get
rid of the core/os/any folder.


- Give PKGBUILDs a refresher... package() functions, no "|| return
1", etc. Make sure packages build with an updated toolchain.


- Deal with the few [core] package issues on the Unimportant Rebuild
List
(https://wiki.archlinux.org/index.php/DeveloperWiki:Unimportant_Rebuild_List).



Given the goals mentioned there, it is obvious that regularly updated
packages do not need to be part of the rebuild. Looking at the
packages, there would be about 100 rebuilds all up. So it would result
in a bunch of signoff emails... But I would start with the oldest
packages and work through the list fairly slowly so this will hopefully
not be an issue.


Any objections/suggestions?

Allan
 
Old 11-18-2010, 04:52 AM
Andreas Radke
 
Default ?

Am Thu, 18 Nov 2010 14:16:34 +1000
schrieb "Allan McRae" <allan@archlinux.org>:

> Hi,
>
> I was thinking of doing a fairly large rebuild of packages in [core]
> for the following reasons:
>
> - The toolchain is quite good at the moment and many packages have
> not been built in a long time so could use a refresher build to take
> advantage of what the newer toolchain offers (~15 packages are > 1
> year old). I expect a toolchain update to happen in the next few
> weeks so this is a good time.

What update do you expect? Usually a rebuild is useful to catch
up latest major gcc improvements. Gcc4.6 is still in an early
stage. Maybe we should delay it until the gcc4.6 release.

The toolchain improvements over the last 2 years were of minor
advantages. So I don't expect major performance improvements.

Getting the packages into xz compression format and pkg pool would be
nice though.

One concern for a rebuild right now: most packagers allowed for
pushing packages into core haven't been much online lately. Not sure
if they can spend that much time. Sadly "makeworld" has died. But I
remember Daniel made such a rebuild script locally (was at gcc4.3
release?).

-Andy
 
Old 11-18-2010, 05:18 AM
"Allan McRae"
 
Default ?

On 18/11/10 15:52, Andreas Radke wrote:

Am Thu, 18 Nov 2010 14:16:34 +1000
schrieb "Allan McRae"<allan@archlinux.org>:


Hi,

I was thinking of doing a fairly large rebuild of packages in [core]
for the following reasons:

- The toolchain is quite good at the moment and many packages have
not been built in a long time so could use a refresher build to take
advantage of what the newer toolchain offers (~15 packages are> 1
year old). I expect a toolchain update to happen in the next few
weeks so this is a good time.


What update do you expect? Usually a rebuild is useful to catch
up latest major gcc improvements. Gcc4.6 is still in an early
stage. Maybe we should delay it until the gcc4.6 release.


I expect binutils in the next couple of weeks (they have branched) and
probably a glibc release given Fedora 14 is released with what is
usually considered an RC glibc release.


Gcc-4.6 is actually in stage 3 (bug fix only), but they still have a
large number of P1 bugs to get rid of before release. But given it took
a few months to sort out the toolchain issues after the initial gcc-4.5
release, I would much prefer doing this before gcc-4.6...



The toolchain improvements over the last 2 years were of minor
advantages. So I don't expect major performance improvements.

Getting the packages into xz compression format and pkg pool would be
nice though.

One concern for a rebuild right now: most packagers allowed for
pushing packages into core haven't been much online lately. Not sure
if they can spend that much time. Sadly "makeworld" has died. But I
remember Daniel made such a rebuild script locally (was at gcc4.3
release?).


Fair point. I was never expecting much help actually doing the rebuilds
as this is a very low priority task... and keeping [core] as pristine as
possible is probably not much of an obsession for people other than me!
Also, there is no real rush in getting this done. So I do not think
packaging manpower will be an issue as long as people can give signoffs
for the packages that are built.


Allan
 
Old 11-18-2010, 05:20 AM
Daniel Isenmann
 
Default ?

Am 18.11.2010 06:52, schrieb Andreas Radke:

Am Thu, 18 Nov 2010 14:16:34 +1000
schrieb "Allan McRae"<allan@archlinux.org>:


Hi,

I was thinking of doing a fairly large rebuild of packages in [core]
for the following reasons:

- The toolchain is quite good at the moment and many packages have
not been built in a long time so could use a refresher build to take
advantage of what the newer toolchain offers (~15 packages are> 1
year old). I expect a toolchain update to happen in the next few
weeks so this is a good time.

What update do you expect? Usually a rebuild is useful to catch
up latest major gcc improvements. Gcc4.6 is still in an early
stage. Maybe we should delay it until the gcc4.6 release.

The toolchain improvements over the last 2 years were of minor
advantages. So I don't expect major performance improvements.

Getting the packages into xz compression format and pkg pool would be
nice though.

One concern for a rebuild right now: most packagers allowed for
pushing packages into core haven't been much online lately. Not sure
if they can spend that much time. Sadly "makeworld" has died. But I
remember Daniel made such a rebuild script locally (was at gcc4.3
release?).


That's right, I made such a rebuild script. But I'm not really sure if I
have it any longer. Have to check it at home. It was a hackish bash
script which increased the pkgrel variable and rebuild the package,
that's all.


I'm not that close to the toolchain changes and its improvements, so if
you think it's time for that go ahead.


-Daniel
 
Old 11-18-2010, 06:24 AM
Andrea Scarpino
 
Default ?

On Thursday 18 November 2010 07:20:54 Daniel Isenmann wrote:
> That's right, I made such a rebuild script. But I'm not really sure if I
> have it any longer. Have to check it at home. It was a hackish bash
> script which increased the pkgrel variable and rebuild the package,
> that's all.
We have to use the package() function and to remove the ||return 1 stuff. I
don't think that do this job with a script is a good idea.

Anyway, count on me for this rebuild.

--
Andrea Scarpino
Arch Linux Developer
 

Thread Tools




All times are GMT. The time now is 07:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org