Need some hand holding with upgrading xserver

[droste]

Sorry no idea what is happening there; I never heard of such phenomenom.
You could still try a newer X version (1.15 or 1.16).

[Sonadow]

Sorry no idea what is happening there; I never heard of such phenomenom.
You could still try a newer X version (1.15 or 1.16).

well, I loathe to tear down and frankenstein too much of the core X stack. Even xserver 1.14 is complaining about too many core dependencies which are too old, like my Mesa 8, libdrm, pixman and glproto.

So i guess i'm stuck with 1.13.2.902 (which is, for all intents and purposes, 1.14 RC2). It's just so odd that performing startx as root does not seems to trigger leaks. I'd have to try again the next day to see if root suddenly causes xserver memory leaks.

[droste]

Mesa 8? Wow that's almost ancient At this point I would advise to simply full upgrade to a recent release of any distro

[Sonadow]

Mesa 8? Wow that's almost ancient At this point I would advise to simply full upgrade to a recent release of any distro

Left the computer running for 6 hours after a cold boot with the default runlevel instead of going down to runlvl 3 and performing startx. No leaks detected as of now; in fact X's consumption is low enough that it is not even displayed in the page of the processes list anymore.

Still going to try it out over the next week to see how it turns out.

[olifre]

If i know how to succesfully upgrade the required components, i can immediately make my OS compatible with the intended hardware, as opposed to waiting for a next distribution release. If you get what i mean.

Sounds like the best solution for you would be a rolling release distribution where you can decide to upgrade packages when you want without always performing a full "distribution upgrade" and also get security updates "forever" without entering any EOL situation. Compiling packages yourself and overwriting what the package manager did is rarely a good idea if you want to keep a system running for a longer period of time (of course it's a nice experiment, I agree, but then sandboxing / using btrfs-snapshots would have made your life much easier).

[grndzro]

Why dont you just reinstall with a newer distro?
Transfering settings and data between distro's is fairly trivial.

[nanonyme]

Why dont you just reinstall with a newer distro?
Transfering settings and data between distro's is fairly trivial.

I guess you didn't read the beginning of the thread

[grndzro]

I guess you didn't read the beginning of the thread

Sorry I guess some people are just sadists. IMO breaking the system is much more of a headache than a planned exodus.

[Sonadow]

Sounds like the best solution for you would be a rolling release distribution where you can decide to upgrade packages when you want without always performing a full "distribution upgrade" and also get security updates "forever" without entering any EOL situation. Compiling packages yourself and overwriting what the package manager did is rarely a good idea if you want to keep a system running for a longer period of time (of course it's a nice experiment, I agree, but then sandboxing / using btrfs-snapshots would have made your life much easier).

Rolling releases do not work for me for the following reasons:

• I need the package repository to be version frozen (i.e.: look at the core / main repository of any discreet-release distribution; the packages there stay at a fixed version of the entirely of the release's life)
• I need the updates repository to be disabled to further achieve version lock / freeze on all packages. Can't do that on a rolling release

Unless a rolling-release allows me to lock the package repository to a certain specific point of time for 2 years without removing the old packages, i'm never going to even consider using rolling.

[shirish]

Hi all,
I have an ancient system but still have a recent version of Xserver :-

$ X -version

X.Org X Server 1.16.2.901 (1.16.3 RC 1)
Release Date: 2014-12-09
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-4-amd64 x86_64 Debian
Current Operating System: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=87d82d2b-dc1a-4f01-8ba4-c68290598b23 ro systemd.log_target=kmsg systemd.log_level=debug systemd.debug-shell ipv6.disable=1 init=/lib/systemd/systemd
Build Date: 09 December 2014  10:15:28PM
xorg-server 2:1.16.2.901-1 (http://www.debian.org/support) 
Current version of pixman: 0.32.6
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.

Running Debian Testing (soon to be stable).

As far as your other question goes, even packages which are marked 'stable' are improved upon during its lifecyle by updates which are essentially bug-fixes. Having them fixed on some version would open you to buggy state as well as a hole in the security apparatus . Just my 2 paise.