Hello archers, I just want to let you know that the french hosting service OVH now provide Arch among many others distro. Reference : http://www.ovh.com/fr/items/distributions/archlinux.xml?sort=gnu Here is a (attempt at) translation : « Arch Linux distribution, lightweight and fast, which purpose is to keep it simple. No service (except SSH) is provided in order to allow everyone to customize his server to taste. Request confirmed administration skills. » They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) It runs on dedicated server, I don't know if it's planned to be supported on a virtualized one. -- radio ianux - http://ianux.fr/

On Wed, 13 Jan 2010 08:00 -0500, "Daenyth Blank" wrote:

On Wed, Jan 13, 2010 at 07:51, ianux wrote:

...

They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?

In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version. I build my own kernels, not via PKGBUILDs/pacman. They work fine and it's tidy too. Kernels keep to their own directories with the kernel itself a single file in /boot and modules in /lib/modules. James

On Wed, 13 Jan 2010 14:38:45 +0100 Thomas Bächler wrote:

Am 13.01.2010 14:31, schrieb James Rayner:

...

...

...

They provide ArchLinux 2009.08 in both 32 and 64 bit with their own kernel with grsecurity (2.6.31.5-grs) How well does this integrate? Arch doesn't have any officially-endorsed grsecurity kernel. Does it require userspace modifications? Have they submitted their package to Arch so the devs can look at it and check for flaws?

In general, kernel's don't need to integrate with anything, and no changes whatsoever should be necessary in userspace. The exception is when the kernel is too old to be compatible with our udev version.

[...]

That isn't entirely the point. IIRC SELinux requires lots of support in userspace, this might be the same for grsecurity. I don't know for sure what needs modification though.

As far as skimming their (rather old) quick install guide can tell me, grsec doesn't do much out of the box. If sysctl is enabled, *all* options have to be enabled manually. In normal unconfigured operation you probably only get some memory address randomization and the same for network ports. Some programs may not work with the memory protections and get killed instantly. the 'chpax' utility (available in aur) can circumvent this. For everything else you need the 'gradm' tool (also available in aur) which manages policies, etc. This seems to be the whole extent of required userspace support. Greetings, jinks --

2010/2/4, ianux :

Hi archers,

I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6.

Hi ianux, Stellarium 0.10.3 in [testing] has been built against qt 4.6 -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it

On 02/05/2010 12:41 AM, ianux wrote:

Le 04/02/10, Giovanni Scafora a écrit :

...

2010/2/4, ianux:

...

Hi archers,

I'm maintening stellarium-svn in AUR and I saw Stellarium 0.10.3 in [testing]. It shows qt>=4.5.1 in dependencies but this version (which doesn't seem to be very stable - several bugs with QT and GLSL - according to the mailing list) depends on qt 4.6.

Hi ianux,

Stellarium 0.10.3 in [testing] has been built against qt 4.6

yes indeed, it's mandatory to use - and compile - stellarium 0.10.3 with qt 4.6 but packages from testing requires qt>=4.5.1, so enabling [testing] in pacman.conf and doing pacman -S stellarium doesn't upgrade qt since qt 4.5.3 (>=4.5.1) is already in extra, which leads to broken binary. I'm just saying that stellarium PKGBUILD from [testing] MUST mention qt>=4.6

but still the only supported way is to fully update from testing and not cherry picking. -- Ionut

On Sat, Jan 02, 2010 at 09:25:33PM +0200, arch@nezmer.info wrote:

On Sat, Jan 02, 2010 at 11:38:33AM -0700, Steve Holmes wrote:

...

When I installed grub2 a short while back, I was using the kernel 2.6.31.6 and I enjoyed a full screen of 1024.768 32K color depth. I followed the steps outlined here http://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution to the letter and all was great.

But when the kernel26 package upgraded to 2.6.32.2, This functionality broke. I ended up having to remove the video related stuff from my grub line to get my system to boot. When I say this didn't work anymore, basically my system wouldn't boot and I end up with a blank screen showing.

When I experimented by removing the insmod statement and using vga=790 by itself, the best I get is a 30 line display with 80 columns width.

Anyone know what changed? It would appear that we may need to update the wiki page with new info for grub2 and video resolution.

KMS conflicts with vga,video. What GPU do you have ? I meant vga,vesa.