Nouveau upgrade path was broken for me. It printed out to the screen
something like "module 'nouveau' not found" while building the new initrd.
It's not in the pacman.log.
I'm using early kms mode. This probably happens because the new nouveau
module is not yet present when the kernel is updat
Ionut Biru wrote:
On 11/27/2009 01:01 AM, Allan McRae wrote:
Ionut Biru wrote:
Hi all,
I just put up an internal TODO list for boot update for
extra/community. I want to do that after heimdal is moved in core.
What do you think about that?
Sounds fine. It is good to see that boost has sona
Paul Mattal wrote:
I should have another fast x86_64 build box at my disposal soon. My
laptop is still running i686, which I sometimes still need for some
things. Can I switch *just* to the x86_64 kernel but leave the rest
i686? Then I could use it to build both. This somehow seems like a bad
Allan McRae wrote:
Paul Mattal wrote:
Giovanni Scafora wrote:
2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg
to build
the package (providing the path to the chroot as an arguement).
Making a chroot for the opposite architecture is slightly more
2009/12/6, Eric Bélanger :
> I have an helper script to manage my many chroots (testing,
> non-testing, i686, x86_64). It's somewhat trivial but I could post it
> if someone's interested.
I'm interested, please post it!
--
Arch Linux Developer
http://www.archlinux.org
http://www.archlinux.it
On Sun, Dec 6, 2009 at 8:58 PM, Allan McRae wrote:
> Paul Mattal wrote:
>>
>> Giovanni Scafora wrote:
>>>
>>> 2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg to
build
the package (providing the path to the chroot as an arguement).
>>
Paul Mattal wrote:
Giovanni Scafora wrote:
2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg
to build
the package (providing the path to the chroot as an arguement).
Making a chroot for the opposite architecture is slightly more
difficult,
but I c
2009/12/6, Paul Mattal :
> Then I should decide-- if I have i686 and x86_64 boxes, is it better to do
> all my builds on 1 machine, or on separate boxes? Can I build i686 on
> x86_64? Can I build x86_64 on i686? If I'm going to set all this up, I'm
> probably going to set it up on several machines
Giovanni Scafora wrote:
2009/12/6, Allan McRae :
It is as simple as mkarchroot to make the chroot and makechrootpkg to build
the package (providing the path to the chroot as an arguement).
Making a chroot for the opposite architecture is slightly more difficult,
but I can provide patches if n
On Sun, Dec 6, 2009 at 19:18, Allan McRae wrote:
> Seriously? A chroot takes ~600MB. At build time, even for the most dep
> heavy application, I doubt you will go much beyond 1GB plus space for the
> build files. Say 1.5GB for most packages.
That's true, but I frequently don't have that much spa
2009/12/6, Allan McRae :
> It is as simple as mkarchroot to make the chroot and makechrootpkg to build
> the package (providing the path to the chroot as an arguement).
>
> Making a chroot for the opposite architecture is slightly more difficult,
> but I can provide patches if needed.
mkarchroot
Daenyth Blank wrote:
On Sun, Dec 6, 2009 at 17:53, Allan McRae wrote:
There is _no_ excuse not to use them.
I don't have enough hard drive space to create a build chroot. That
being said, I try to use namcap and also try to resolve any bug
reports within the same day it's assigned. Most of t
Paul Mattal wrote:
Allan McRae wrote:
The tools are very simple to use and are described in the wiki
(http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot).
There is _no_ excuse not to use them. The are minor changes needed
for doing i686 builds on x86_64 and vise ver
Allan McRae wrote:
The tools are very simple to use and are described in the wiki
(http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot).
There is _no_ excuse not to use them. The are minor changes needed for
doing i686 builds on x86_64 and vise versa, but there are pl
Andrea Scarpino wrote:
Don't start a flame against me cause I think I am one of the few
people which ever use ours development tools.
This was not directed at you only, which is why I never named you in the
original email. You just happened to be the latest example of many...
Allan
2009/12/7 Giovanni Scafora :
> I agree with Allan, all of us must always use ours development tools
> and we must building in a clean chroot.
I also am agree and I am peeved as you when I read avoidable (or
stupid) bug reports.
--
Andrea `bash` Scarpino
Arch Linux Developer
2009/12/6, Andrea Scarpino :
> Don't start a flame against me cause I think I am one of the few
> people which ever use ours development tools.
Please Andrea, don't get me wrong, this is not a flame against you.
I agree with Allan, all of us must always use ours development tools
and we must bui
On 07/12/2009, Giovanni Scafora wrote:
> 2009/12/6, Allan McRae :
>> So, we need a creative punishment for those that causes bugs by not
>> building in a clean chroot. It is too early in the morning for me to be
>> creative so I am struggling to come up with ideas besides beatings and
>> removal
On Sun, Dec 6, 2009 at 17:53, Allan McRae wrote:
> There is _no_ excuse not to use them.
I don't have enough hard drive space to create a build chroot. That
being said, I try to use namcap and also try to resolve any bug
reports within the same day it's assigned. Most of the time I don't
get any
2009/12/6, Allan McRae :
> So, we need a creative punishment for those that causes bugs by not
> building in a clean chroot. It is too early in the morning for me to be
> creative so I am struggling to come up with ideas besides beatings and
> removal of commit privileges. Any better ideas?
I n
On Sun, Dec 6, 2009 at 5:53 PM, Allan McRae wrote:
> Hi,
>
> We have been through this many times... you should always build in a clean
> chroot. But there are continuously bugs about packages linking to non-deps.
> We should never have such bugs.
>
> e.g. (FS#17409)
>
>> readelf -d /usr/bin/mp
Hi,
We have been through this many times... you should always build in a
clean chroot. But there are continuously bugs about packages linking to
non-deps. We should never have such bugs.
e.g. (FS#17409)
> readelf -d /usr/bin/mpd
...
0x0001 (NEEDED) Shared library:
Andreas Radke schrieb:
1) as posted some weeks ago: early KMS mode is broken for me.
mkinitcpio fails to load the firmware though the firmware hook is
enabled and is included in the image. last line I see is:
platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
Okay, mkinitcpio does a
1) as posted some weeks ago: early KMS mode is broken for me.
mkinitcpio fails to load the firmware though the firmware hook is
enabled and is included in the image. last line I see is:
platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
then it stops working. CTRL+ALT+DEL is working so
On Sun, Dec 6, 2009 at 13:28, Roman Kyrylych wrote:
> On Sun, Dec 6, 2009 at 07:24, Eric Bélanger wrote:
>> Please test and signoff gpm-1.20.6-5 in testing. The gpm.sh profile
>> now checks if gpm is running before running disable-paste.
>
> Sing off x86_64.
>
> However, the check is ineffective
On Sun, Dec 6, 2009 at 07:24, Eric Bélanger wrote:
> Please test and signoff gpm-1.20.6-5 in testing. The gpm.sh profile
> now checks if gpm is running before running disable-paste.
Sing off x86_64.
However, the check is ineffective: it is done per tty,
but it is enough to do this once and then
Eric Bélanger schrieb:
- changed intel kms enabled by default
I don't know if it's because the kms-enabled kernel or the new xorg
packages, but the intel drivers are working again on my i686 with
855GM Intel graphics. Xv support is not working but it's still much
better than the vesa drivers
27 matches
Mail list logo
