Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8?
On Wed, Jan 18, 2012 at 5:55 AM, Fabio Erculiani lx...@sabayon.org wrote: I would really like to bump xorg-server to 1.11, but as stated in my previous post here, nvidia legacy drivers would stop working. Should we really hold the version bump due to that? I say no. Dump your opinion here, I'll take the final decision this weekend (sooner or later it's going to happen anyway, and NVIDIA doesn't seem very reactive in updating their legacy stuff). -- Fabio Erculiani I vote go for it, we are bleeding edge and time to move on. -- KJS ~wolfden~
Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8?
I'd agree with Wolfden, but be sure to have a good disclaimer warning for possible failure with legacy nvidia cards, otherwise n00bs could think we are the problem... 2012/1/18 Wolfden wolf...@gmail.com On Wed, Jan 18, 2012 at 5:55 AM, Fabio Erculiani lx...@sabayon.orgwrote: I would really like to bump xorg-server to 1.11, but as stated in my previous post here, nvidia legacy drivers would stop working. Should we really hold the version bump due to that? I say no. Dump your opinion here, I'll take the final decision this weekend (sooner or later it's going to happen anyway, and NVIDIA doesn't seem very reactive in updating their legacy stuff). -- Fabio Erculiani I vote go for it, we are bleeding edge and time to move on. -- KJS ~wolfden~
[sabayon-dev] Daily Jan 15th amd64 Gnome
Someone want to confirm that gnome edition is not booting to Cinnamon but to default Gnome 3 instead? I logged out, changed session to Cinnamon and than back into default gnome, but if I log back out and than just click on login without changing anything I load into Cinnamon. The session setting seems to get switched to gnome for some reason. -- Kelly Schwartz ~wolfden~
[sabayon-dev] New Git-based Btrfs-Progs Ebuild
I've commited an updated ebuild for sys-fs/btrfs-progs-0.19_p111201 based on a discrete commit (using the EGIT_COMMIT=... variable) from the upstream git repository at http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I wanted to document to the Sabayon development team why I've moved to a git based ebuild so you'll understand why it's there and when it makes sense to change back. First off, the movement towards an official 0.20 release is moving at a glacial pace. But there are many very important updates that have been published to the git repositories in the mean time. In the latest version, I've included the first generation of recovery tools to assist users in retrieving data from btrfs partitions that have been corrupted. Although a read/write btrfsck that can fix corruptions is not yet available, this is an important interim tool (I've heard it quipped that mkfs is the fsck for btrfs :) ) Also, since the hacking of the kernel.org servers in August/September of 2011, the official btrfs-progs-0.19 sources are no longer available. The sources are widely available on mirrors and in other distro's repositories, so that is only of minor relevance. As progress slowly moves towards the 0.20 version, I anticipate an extended period where all the update work will be scattered across various git repositories. So it will facilitate us in keeping up with updated features to structure the btrfs-progs ebuild from git sources until development settles down to a discrete release schedule.
Re: [sabayon-dev] New Git-based Btrfs-Progs Ebuild
I generally advise against using got for this kind of thing. It is not the recommend way to handle this scenario, you should create a snapshot ebuild using a source checkout tarball [1] 1. http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html On 18 January 2012 16:51, Mitch Harder mitch.hardermitch.har...@sabayonlinux.org @ mitch.har...@sabayonlinux.orgsabayonlinux.orgmitch.har...@sabayonlinux.org wrote: I've commited an updated ebuild for sys-fs/btrfs-progs-0.19_p111201 based on a discrete commit (using the EGIT_COMMIT=... variable) from the upstream git repository at http:// http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git git.kernel.orghttp://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git /?p= http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.gitlinuxhttp://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git /kernel/ http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git git http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git/mason/http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git btrfs http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git-http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git progs.git http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I wanted to document to the Sabayon development team why I've moved to a git based ebuild so you'll understand why it's there and when it makes sense to change back. First off, the movement towards an official 0.20 release is moving at a glacial pace. But there are many very important updates that have been published to the git repositories in the mean time. In the latest version, I've included the first generation of recovery tools to assist users in retrieving data from btrfs partitions that have been corrupted. Although a read/write btrfsck that can fix corruptions is not yet available, this is an important interim tool (I've heard it quipped that mkfs is the fsck for btrfs :) ) Also, since the hacking of the kernel.org servers in August/September of 2011, the official btrfs-progs-0.19 sources are no longer available. The sources are widely available on mirrors and in other distro's repositories, so that is only of minor relevance. As progress slowly moves towards the 0.20 version, I anticipate an extended period where all the update work will be scattered across various git repositories. So it will facilitate us in keeping up with updated features to structure the btrfs-progs ebuild from git sources until development settles down to a discrete release schedule. -- Ian Whyman v00d00.net
Re: [sabayon-dev] New Git-based Btrfs-Progs Ebuild
I agree regarding an aversion to basing an ebuild off a VCS commit. My motive is to tag this ebuild as an outlier that eventually needs to change back, rather than to justify the practice in general. For this particular package, I fear things will get more confusing before they get clearer. They've adopted a practice of committing features in the kernel, but allowing the userland tools to implement these features to remain spread out across several independent user/developer git repos. For the time being, basing the package off git will facilitate assembling the disparate pieces until the project settles down. On a side note, I prefer this method of identifying a specific commit and assigning a discrete release number to the practice of making - packages. On Wed, Jan 18, 2012 at 11:14 AM, Ian Whyman v00...@v00d00.net wrote: I generally advise against using got for this kind of thing. It is not the recommend way to handle this scenario, you should create a snapshot ebuild using a source checkout tarball [1] 1. http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html On 18 January 2012 16:51, Mitch Harder mitch.har...@sabayonlinux.org wrote: I've commited an updated ebuild for sys-fs/btrfs-progs-0.19_p111201 based on a discrete commit (using the EGIT_COMMIT=... variable) from the upstream git repository at http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I wanted to document to the Sabayon development team why I've moved to a git based ebuild so you'll understand why it's there and when it makes sense to change back. First off, the movement towards an official 0.20 release is moving at a glacial pace. But there are many very important updates that have been published to the git repositories in the mean time. In the latest version, I've included the first generation of recovery tools to assist users in retrieving data from btrfs partitions that have been corrupted. Although a read/write btrfsck that can fix corruptions is not yet available, this is an important interim tool (I've heard it quipped that mkfs is the fsck for btrfs :) ) Also, since the hacking of the kernel.org servers in August/September of 2011, the official btrfs-progs-0.19 sources are no longer available. The sources are widely available on mirrors and in other distro's repositories, so that is only of minor relevance. As progress slowly moves towards the 0.20 version, I anticipate an extended period where all the update work will be scattered across various git repositories. So it will facilitate us in keeping up with updated features to structure the btrfs-progs ebuild from git sources until development settles down to a discrete release schedule. -- Ian Whyman v00d00.net
Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8?
just do it Joe
Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8?
I''ve heard people say nouveau is a good enough alternative for legacy NVIDIA cards. Either way I'd go for it. On Wed, Jan 18, 2012 at 2:31 PM, Josef Odenthal joe.odent...@gmail.com wrote: just do it Joe
Re: [sabayon-dev] Daily Jan 15th amd64 Gnome
Just downloaded (amd64) and burnt to rw dvd Started in gnome logged out (just sat there at splash screen with busy cursor for more than 10 minutes) Changed to command line restarted x system went straight in to gnome by passing login so I couldn't even select Cinnamon Just noticed Wed Jan 18 11:10:10 CET 2012 is available, will download and report back Joe
Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8?
I have recompiled xorg-server-11.3 and all that it needed to be compiled. I can confirm, on my Nvidia 9650M GT 1 gigs integrated and running proprietary drivers that xorg-server-1.11.3 works like a charm. No corruption/error. And compiled with march=native, vomit-frame-pointer and graphite. Green light on my lappy :) From: miciam...@hotmail.it To: devel@lists.sabayon.org Date: Wed, 18 Jan 2012 23:51:31 +0100 Subject: Re: [sabayon-dev] xorg-server-1.11 in Sabayon 8? I don't have any legacy Nvidia hardware, but I still think compatibility should be a big concern for serious and reliable OS, so my vote is negative on this. Bleeding edge disregarding compatibility and lacking any good motivation (and version X version Y isn't enough) is no good to me. If this is such mandatory decision and there are good reasons to do this, I would go on dropping an email to Nvidia to see if they are actually interested in updating their legacy drivers for newer xorg, if they aren't (or don't respond) the least we should do is providing an automatic way to switch to nouveau for those cards. Il giorno mer, 18/01/2012 alle 13.16 +0100, Michele ha scritto: On 18/01/2012 13:01, Andre Parhan wrote: I'd agree with Wolfden, but be sure to have a good disclaimer warning for possible failure with legacy nvidia cards, otherwise n00bs could think we are the problem... 2012/1/18 Wolfden wolf...@gmail.com mailto:wolf...@gmail.com On Wed, Jan 18, 2012 at 5:55 AM, Fabio Erculiani lx...@sabayon.org mailto:lx...@sabayon.org wrote: I would really like to bump xorg-server to 1.11, but as stated in my previous post here, nvidia legacy drivers would stop working. Should we really hold the version bump due to that? I say no. Dump your opinion here, I'll take the final decision this weekend (sooner or later it's going to happen anyway, and NVIDIA doesn't seem very reactive in updating their legacy stuff). -- Fabio Erculiani I vote go for it, we are bleeding edge and time to move on. -- KJS ~wolfden~ I would rather pick another distro if I needed to run Linux on an older machine, and probably most people would do the same (Puppy or some Ubuntu spinoff), so I say let's get the latest version. Anyways the oldest video card I have is two years old, so for me it's ok :) mic -- Lorenzo Cogotti
Re: [sabayon-dev] Daily Jan 15th amd64 Gnome
Cinnamon working as default with build date Wed Jan 18 11:10:10 CET 2012 Looks good, Installing to hard drive On Thu, Jan 19, 2012 at 10:16 AM, Josef Odenthal joe.odent...@gmail.comwrote: Just downloaded (amd64) and burnt to rw dvd Just noticed Wed Jan 18 11:10:10 CET 2012 is available, will download and report back Joe
