Re: [arch-dev-public] nano -w (was: Re: [signoff] nano 2.0.8-1)

> On Mon, Sep 29, 2008 at 7:23 PM, Andreas Radke <a.radke <at> arcor.de> wrote:
>> woohoo. such a small editor making so much noise with only one option.
>>
>> i prefer to not touch the upstream nanorc we install. after many
>> requests i followed Fedora and many other major distributions and
>> disabled the line wrapping completely via configure.
>>
>> i don't know any good situation when line wrapping is useful expect in
>> writing mails. but who is using nano for that task? (i guess alpine
>> users go with pico).
>>
>> so why do some people want that wrapping back?
>>
>> i think a small note about no line wrapping in our installer when it
>> shows the choise for vi/nano is much more than needed.
>>
>> -Andy
>>
>
> Hi,
>
> I just wanted to note that I often use line wrapping as it's more
> convenient than doing it manually. I do however enable it using key
> commands, and use nowrap in nanorc (since wrapping is so frustrating
> when it comes to configuration etc).
>
> I'd prefer if nano -w was used in the installer, or nowrap in the
> default nanorc. Better than disabling a feature completely.
>

initscripts-splash and fbsplash

Hello all,

I've reworked the initscripts-splash patch by hand into the latest
version of initscripts. I've also updated the fbsplash package to the
latest version of splashutils. 

So far, I've been using it for about a week now with my laptop, and
have encounted no problems at all. Splash even works on hibernate with
uswsusp-splash from the AUR. (Haven't tried tuxonice because I don't
use it)

Here's links to the updated PKGBUILD tarballs.

http://www.fallendusk.org/arch/initscripts-splash.tar.gz
http://www.fallendusk.org/arch/fbsplash.tar.gz

I'm using my own custom kernel with the fbcondecor patch (makes splash
load as soon as kernel does) but from what I understand fbsplash should
work without, just not until after init loads.

I would be more than glad to maintain either of these packages if the
current maintainers would like to hand them off. :)

--Greg

Re: initscripts-splash and fbsplash

About Turkish Mirrors

Hey There All Arch'ers,

I'm one of the Arch Linux Turkish Community members and want to remind
all of you that we have 2 (and counting) official mirrors in Turkey.

I write this e-mail to kindly request an update for pacman mirrorlist
and wiki pages like this one [1]..

ftp.linux.org.tr belongs to LKD (Turkish Linux Community Foundation) and
you can reach the team from: ftp at linux.org.tr

Thanks for all your great software and support!

Cheers!

[1] http://wiki.archlinux.org/index.php/Mirror

--

-- 
Alper KANAT
http://raptiye.org

Re: About Turkish Mirrors

Am Donnerstag 02 Oktober 2008 02:47:53 schrieb Alper KANAT:
> I write this e-mail to kindly request an update for pacman mirrorlist

You should file a request at our bug tracker.

--

-- 

Pierre Schmitz

Clemens-August-Straße 76
53115 Bonn

Telefon		0228 9716608
Mobil		0160 95269831
Jabber		pierre <at> jabber.archlinux.de
WWW		http://www.archlinux.de

Re: initscripts-splash and fbsplash

On Wed, 1 Oct 2008 23:08:23 +0200
Charly Ghislain <charlyghislain <at> gmail.com> wrote:

> Hi,
> 
> thank you for work, ill test these packages soon;
> 
> On Wednesday 01 October 2008 16:21:15 Gregory T Helton wrote:
> > I'm using my own custom kernel with the fbcondecor patch (makes
> > splash load as soon as kernel does) but from what I understand
> > fbsplash should work without, just not until after init loads.
> 
> Shouldn't you be able to make your splash screen loads in the
> initcpio/initrd ; avoiding the need to patch kernel or to wait until
> init started?
> 
> Ragards,
> 
> Charly
> 
> 
> 

fbsplash actually does load from the initcpio, but it depends on the
fbcondecor kernel patch to use splash early in the boot process. This
is just how it was designed.

I'm currently researching and trying to come up with a way to remove
the dependency on a custom initscripts package to get splash to work.

Plan for python upgrade [was in arch-dev-public]

Eric Belanger wrote 
> IMO, Plan 1 is the way to go as this is how we managed the qt3/qt upgrade.

there was a qt package and a qt4 during a certain amount of time before the 
switch to qt3/qt

> Does anyone has an idea on how many packages in the repo currently works 
> with or need python3.0? If that number is zero or very small, 
i don't know but as python 3 is not yet out it should be pretty close to zero.

> we could update python to 2.6 and wait until that number increases before 
proceeding with 
> Plan 1.  That will reduce the number of rebuilds because we will be 
> replacing rebuilds by package update that eventually would need to 
> be done anyway.

yes and no. because the number will grow very slowly and there is no such big 
beast like kde to force the switch. (is there ?)

why not wait until python 3.1 ?

i really fear that a great number of software will break because they will try 
to use /usr/bin/python and except a python 2 to be there. 
What about the package in unsupported that will not be upgraded asap as the 
others in extra or core or community.

Fwd: [arch-dev-public] [signoff] atl2-2.0.5

Hi guys,
please signoff both arches,

greetings
tpowa
--

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa <at> archlinux.org

Fwd: [arch-dev-public] [signoff] dmraid 1.0.rc15-1

Hi guys,
please signoff both arches,

greetings
tpowa
--

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa <at> archlinux.org

Fwd: [arch-dev-public] [signoff] linux-atm 2.5.0

Hi guys,
please signoff both arches,

greetings
tpowa
--

-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa <at> archlinux.org