From ratler at lunar-linux.org Sat Sep 6 09:34:49 2008 From: ratler at lunar-linux.org (Stefan Wold) Date: Sat, 06 Sep 2008 09:34:49 +0200 Subject: Overdue update of bash 3.2 Message-ID: <1220686489.29610.25.camel@localhost> Hey, I just bumped bash to 3.2 (patchlevel 39) and bash_static to 3.2. Please give them some testing. I'd like to push them out as soon as possible, 3 years since last bash bump ;) Pull it from git://foo-projects.org/ratler/moonbase.git -- Sincerely Stefan Wold Lunar Linux developer - PGP public key 6E810F05 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://foo-projects.org/pipermail/lunar-dev/attachments/20080906/5ebf3071/attachment.bin From dennisveatch at bellsouth.net Sat Sep 6 13:23:32 2008 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sat, 6 Sep 2008 07:23:32 -0400 Subject: Overdue update of bash 3.2 In-Reply-To: <1220686489.29610.25.camel@localhost> References: <1220686489.29610.25.camel@localhost> Message-ID: <200809060723.32276.dennisveatch@bellsouth.net> On Saturday 06 September 2008 03:34:49 Stefan Wold wrote: > Hey, > > I just bumped bash to 3.2 (patchlevel 39) and bash_static to 3.2. Please > give them some testing. I'd like to push them out as soon as possible, 3 > years since last bash bump ;) > > Pull it from git://foo-projects.org/ratler/moonbase.git Not found an issue with it as yet. I have lin -rc a bunch of things, kde3, git, and some others. But not looked at the changelog to see if there are any show stoppers. Haven't dealt with bash_static. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From sofar at foo-projects.org Mon Sep 8 19:58:57 2008 From: sofar at foo-projects.org (Kok, Auke) Date: Mon, 08 Sep 2008 10:58:57 -0700 Subject: Foo-projects.org DNS change this week - possible downtime issues Message-ID: <48C567E1.3070205@foo-projects.org> All, This week the main DNS server for lunar-linux.org, xfce.org and foo-projects.org will change IP addresses. This will have a severe impact on all services hosted either on doppio or mocha: - Mail delivery might be intermittent - websites may appear to be offline This can last for up to 48 hours until we finalize the DNS changes which will require to be done over the course of this week. If you see any problems feel free to join us on irc in #lunar or #xfce on irc.freenode.net or mail me off-server at auke at linux.intel.com. Regards, Auke From zbiggy at o2.pl Wed Sep 10 19:59:16 2008 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Wed, 10 Sep 2008 19:59:16 +0200 Subject: Overdue update of bash 3.2 In-Reply-To: <1220686489.29610.25.camel@localhost> References: <1220686489.29610.25.camel@localhost> Message-ID: <200809101959.16913.zbiggy@o2.pl> Saturday 06 of September 2008 09:34:49 Stefan Wold wrote: > Hey, > > I just bumped bash to 3.2 (patchlevel 39) and bash_static to 3.2. Please > give them some testing. I'd like to push them out as soon as possible, 3 > years since last bash bump ;) > > Pull it from git://foo-projects.org/ratler/moonbase.git Works very well for me. Thanks! zbiggy From dennisveatch at bellsouth.net Mon Sep 15 02:14:04 2008 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 14 Sep 2008 20:14:04 -0400 Subject: lunar-1.6.4-alpha3-x86_64.iso issues Message-ID: <200809142014.05125.dennisveatch@bellsouth.net> Ratler, that is some mighty fine work, and well appreciated. Though I have two issues with this ISO. First. For the longest time the ISO has had reiserfs, XFS and/or JFS built into the kernel. The reason for the "and/or" on the last two items, I am not sure if one or both were built in. AFAICR, at least two of those were, and I am puzzled why they have been moved a module, and forcing a kernel recompile on the install to use them. I would really appreciate at least reiserfs returned to a built-in. I only bark about this because I have been using reiserfs for that past 4 years or so with lunar. Along that same topic. I think to force a kernel rebuild to get them, lessens the ability to use the ISO as a recovery tool. But that is just my opinion. Now to the main issue. At the partitioning phase, not knowing reiserfs would require a kernel rebuild, I had to go back and choose ext3. Well, I could go through the motions of selecting the partition, choosing ext3, and all appeared normal. Until it got to the installing part. None of the partitions were mounted and the install failed. There is one other thing. When you first arrive at the partitioning menu, it shows you the current filesystem of the partitions. Right now, after choosing the partition, making it / (as an example), and choosing the new filesystem you want it to be. When you arrive back to the partitioning menu, you are shown the device, that it will be /, and the size. It would be great if the menu also showed you the filesystem you have selected. Oh, and one other item. The iwl3945 needs the ipw3945-ucode. Though I am not for sure if we can include that on the ISO. But at a guess, our lead developer might be able to work out that issue for us. Still, it is some fine work, and thanks. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From ratler at lunar-linux.org Mon Sep 15 07:24:37 2008 From: ratler at lunar-linux.org (Stefan Wold) Date: Mon, 15 Sep 2008 07:24:37 +0200 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] Message-ID: <1221456277.3916.10.camel@localhost> Bah to early in the morning, didn't notice the to for lunar-dev so I never did reply to all ;) /Stefan -------- Forwarded Message -------- From: Stefan Wold To: Dennis Veatch Subject: Re: lunar-1.6.4-alpha3-x86_64.iso issues Date: Mon, 15 Sep 2008 07:19:36 +0200 On Sun, 2008-09-14 at 20:14 -0400, Dennis Veatch wrote: > Ratler, > > that is some mighty fine work, and well appreciated. Though I have two issues > with this ISO. Thank you. > First. For the longest time the ISO has had reiserfs, XFS and/or JFS built > into the kernel. The reason for the "and/or" on the last two items, I am not > sure if one or both were built in. AFAICR, at least two of those were, and I > am puzzled why they have been moved a module, and forcing a kernel recompile > on the install to use them. I would really appreciate at least reiserfs > returned to a built-in. I only bark about this because I have been using > reiserfs for that past 4 years or so with lunar. This is probably a misstake from my side, I'll fix this for the next release that should be a beta. > Along that same topic. I think to force a kernel rebuild to get them, lessens > the ability to use the ISO as a recovery tool. But that is just my opinion. Recovery should however work fine even the filesystem drivers are compiled as modules. > > Now to the main issue. At the partitioning phase, not knowing reiserfs would > require a kernel rebuild, I had to go back and choose ext3. Well, I could go > through the motions of selecting the partition, choosing ext3, and all > appeared normal. Until it got to the installing part. None of the partitions > were mounted and the install failed. Hmm this seems odd, do you mean that re-assigning a partition cause it to not show up in /etc/fstab after first boot? But the installation still succeed? > > There is one other thing. When you first arrive at the partitioning menu, it > shows you the current filesystem of the partitions. Right now, after choosing > the partition, making it / (as an example), and choosing the new filesystem > you want it to be. When you arrive back to the partitioning menu, you are > shown the device, that it will be /, and the size. It would be great if the > menu also showed you the filesystem you have selected. Good feedback, I think that should be easily fixed. > > Oh, and one other item. The iwl3945 needs the ipw3945-ucode. Though I am not > for sure if we can include that on the ISO. But at a guess, our lead developer > might be able to work out that issue for us. The source for iwl-3945-ucode and iwl-4965-ucode should be on the iso, so even without network you should be able to run lin iwl-xxxx-ucode. -- Sincerely Stefan Wold Lunar Linux developer - PGP public key 6E810F05 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://foo-projects.org/pipermail/lunar-dev/attachments/20080915/6e480bb0/attachment.bin From me at v4hn.de Mon Sep 15 08:22:04 2008 From: me at v4hn.de (v4hn) Date: Mon, 15 Sep 2008 08:22:04 +0200 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <1221456277.3916.10.camel@localhost> References: <1221456277.3916.10.camel@localhost> Message-ID: <20080915062204.GA3255@kuebelreiter> ev'ning, On Mon, Sep 15, 2008 at 07:24:37AM +0200, Stefan Wold wrote: >-------- Forwarded Message -------- >From: Stefan Wold >To: Dennis Veatch >Subject: Re: lunar-1.6.4-alpha3-x86_64.iso issues >Date: Mon, 15 Sep 2008 07:19:36 +0200 > >[...] >On Sun, 2008-09-14 at 20:14 -0400, Dennis Veatch wrote: >>First. For the longest time the ISO has had reiserfs, XFS and/or JFS built >>into the kernel. The reason for the "and/or" on the last two items, I am not >>sure if one or both were built in. AFAICR, at least two of those were, and I >>am puzzled why they have been moved a module, and forcing a kernel recompile >>on the install to use them. I would really appreciate at least reiserfs >>returned to a built-in. I only bark about this because I have been using >>reiserfs for that past 4 years or so with lunar. > >This is probably a misstake from my side, I'll fix this for the next >release that should be a beta. Some time ago there was a discussion in #lunar whether or not reiserfs should be build in the kernel, when sofar played around with the kernel-config of the iso. Well, he stated no one should use reiserfs anyway because ext3 is much more appreciated, more stable, ... Quite a lot of people disagreed, but well... sofar had spoken ;) so it was left out until now. v4hn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://foo-projects.org/pipermail/lunar-dev/attachments/20080915/9efe7a23/attachment.bin From dennisveatch at bellsouth.net Mon Sep 15 15:13:14 2008 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 15 Sep 2008 09:13:14 -0400 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <1221456277.3916.10.camel@localhost> References: <1221456277.3916.10.camel@localhost> Message-ID: <200809150913.15068.dennisveatch@bellsouth.net> On Monday 15 September 2008 01:24:37 Stefan Wold wrote: > Bah to early in the morning, didn't notice the to for lunar-dev so I > never did reply to all ;) > > /Stefan > > -------- Forwarded Message -------- > From: Stefan Wold > To: Dennis Veatch > Subject: Re: lunar-1.6.4-alpha3-x86_64.iso issues > Date: Mon, 15 Sep 2008 07:19:36 +0200 > > On Sun, 2008-09-14 at 20:14 -0400, Dennis Veatch wrote: > > Ratler, > > > > that is some mighty fine work, and well appreciated. Though I have two > > issues with this ISO. > > Thank you. > > > First. For the longest time the ISO has had reiserfs, XFS and/or JFS > > built into the kernel. The reason for the "and/or" on the last two items, > > I am not sure if one or both were built in. AFAICR, at least two of those > > were, and I am puzzled why they have been moved a module, and forcing a > > kernel recompile on the install to use them. I would really appreciate at > > least reiserfs returned to a built-in. I only bark about this because I > > have been using reiserfs for that past 4 years or so with lunar. > > This is probably a misstake from my side, I'll fix this for the next > release that should be a beta. > Ok, that would be great. > > Along that same topic. I think to force a kernel rebuild to get them, > > lessens the ability to use the ISO as a recovery tool. But that is just > > my opinion. > > Recovery should however work fine even the filesystem drivers are > compiled as modules. > > > Now to the main issue. At the partitioning phase, not knowing reiserfs > > would require a kernel rebuild, I had to go back and choose ext3. Well, I > > could go through the motions of selecting the partition, choosing ext3, > > and all appeared normal. Until it got to the installing part. None of the > > partitions were mounted and the install failed. > > Hmm this seems odd, do you mean that re-assigning a partition cause it > to not show up in /etc/fstab after first boot? But the installation > still succeed? No, the installation failed. I mean after choosing reiserfs, then realizing I would need to do a kernel recompile during the install to make them built in. I stayed in the partitioning menu, unassigned them, chose ext3, but they did not get mounted, so the install failed since it had no place to put the files. The tree under /mnt does not get mounted, to be precise. It works fine if you do not decide to change filesystem type one selected. > > > There is one other thing. When you first arrive at the partitioning menu, > > it shows you the current filesystem of the partitions. Right now, after > > choosing the partition, making it / (as an example), and choosing the new > > filesystem you want it to be. When you arrive back to the partitioning > > menu, you are shown the device, that it will be /, and the size. It would > > be great if the menu also showed you the filesystem you have selected. > > Good feedback, I think that should be easily fixed. > > > Oh, and one other item. The iwl3945 needs the ipw3945-ucode. Though I am > > not for sure if we can include that on the ISO. But at a guess, our lead > > developer might be able to work out that issue for us. > > The source for iwl-3945-ucode and iwl-4965-ucode should be on the iso, > so even without network you should be able to run lin iwl-xxxx-ucode. Ah, I see now. They are in /var/spool/lunar and just need a lin. Probably should make note of that in lfirsttime. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From duncan.gibson at xs4all.nl Mon Sep 15 15:53:10 2008 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Mon, 15 Sep 2008 15:53:10 +0200 (CEST) Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] Message-ID: <23246.195.169.141.54.1221486790.squirrel@webmail.xs4all.nl> >> Hmm this seems odd, do you mean that re-assigning a partition cause it >> to not show up in /etc/fstab after first boot? But the installation >> still succeed? > No, the installation failed. I mean after choosing reiserfs, then > realizing I would need to do a kernel recompile during the install to > make them built in. I stayed in the partitioning menu, unassigned them, > chose ext3, but they did not get mounted, so the install failed since > it had no place to put the files. IIRC, when I installed 1.6.4.alpha2, the step where you associate file systems with partitions was very sensitive to the order in which I did it. If I went back to a partition I had previously assigned to check or correct it, the other partition names were lost. Or something like that. I remember that I couldn't proceed until I had corrected it and I could only correct it by redoing all of the assignments in the correct order without any mistakes. So it may be that there is some general screwiness in that part of the installer. Or it may be the PEBCAK effect. D. From dennisveatch at bellsouth.net Mon Sep 15 16:04:59 2008 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 15 Sep 2008 10:04:59 -0400 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <23246.195.169.141.54.1221486790.squirrel@webmail.xs4all.nl> References: <23246.195.169.141.54.1221486790.squirrel@webmail.xs4all.nl> Message-ID: <200809151004.59449.dennisveatch@bellsouth.net> On Monday 15 September 2008 09:53:10 Duncan Gibson wrote: > >> Hmm this seems odd, do you mean that re-assigning a partition cause it > >> to not show up in /etc/fstab after first boot? But the installation > >> still succeed? > > > > No, the installation failed. I mean after choosing reiserfs, then > > realizing I would need to do a kernel recompile during the install to > > make them built in. I stayed in the partitioning menu, unassigned them, > > chose ext3, but they did not get mounted, so the install failed since > > it had no place to put the files. > > IIRC, when I installed 1.6.4.alpha2, the step where you associate file > systems with partitions was very sensitive to the order in which I did > it. If I went back to a partition I had previously assigned to check or > correct it, the other partition names were lost. Or something like that. > I remember that I couldn't proceed until I had corrected it and I could > only correct it by redoing all of the assignments in the correct order > without any mistakes. So it may be that there is some general screwiness > in that part of the installer. Or it may be the PEBCAK effect. > > D. > > _______________________________________________ Naw, I don't think it is PEBCAK. Once the choices have been made AND do not alter them by reassigning a different filesystem, the partitions will get mounted. It is only when changing them does things get hosed. It isn't you. The logic should be able to account for alterations once the initial choices have been made. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From ratler at lunar-linux.org Tue Sep 16 07:28:18 2008 From: ratler at lunar-linux.org (Stefan Wold) Date: Tue, 16 Sep 2008 07:28:18 +0200 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <200809151004.59449.dennisveatch@bellsouth.net> References: <23246.195.169.141.54.1221486790.squirrel@webmail.xs4all.nl> <200809151004.59449.dennisveatch@bellsouth.net> Message-ID: <1221542898.22968.3.camel@localhost> On Mon, 2008-09-15 at 10:04 -0400, Dennis Veatch wrote: > On Monday 15 September 2008 09:53:10 Duncan Gibson wrote: > > >> Hmm this seems odd, do you mean that re-assigning a partition cause it > > >> to not show up in /etc/fstab after first boot? But the installation > > >> still succeed? > > > > > > No, the installation failed. I mean after choosing reiserfs, then > > > realizing I would need to do a kernel recompile during the install to > > > make them built in. I stayed in the partitioning menu, unassigned them, > > > chose ext3, but they did not get mounted, so the install failed since > > > it had no place to put the files. > > > > IIRC, when I installed 1.6.4.alpha2, the step where you associate file > > systems with partitions was very sensitive to the order in which I did > > it. If I went back to a partition I had previously assigned to check or > > correct it, the other partition names were lost. Or something like that. > > I remember that I couldn't proceed until I had corrected it and I could > > only correct it by redoing all of the assignments in the correct order > > without any mistakes. So it may be that there is some general screwiness > > in that part of the installer. Or it may be the PEBCAK effect. > > > > D. > > > > _______________________________________________ > > Naw, I don't think it is PEBCAK. Once the choices have been made AND do not > alter them by reassigning a different filesystem, the partitions will get > mounted. It is only when changing them does things get hosed. It isn't you. > The logic should be able to account for alterations once the initial choices > have been made. I can confirm something is buggy with the partition selector. It's not possible to reproduce it every time (seem to depend on the steps you take) but I managed to get to a point where it wasn't possible to assign ANY partition at all. I'll dig into the problem though. -- Sincerely Stefan Wold Lunar Linux developer - PGP public key 6E810F05 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://foo-projects.org/pipermail/lunar-dev/attachments/20080916/275fb925/attachment.bin From sofar at foo-projects.org Tue Sep 16 23:29:49 2008 From: sofar at foo-projects.org (Kok, Auke) Date: Tue, 16 Sep 2008 14:29:49 -0700 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <20080915062204.GA3255@kuebelreiter> References: <1221456277.3916.10.camel@localhost> <20080915062204.GA3255@kuebelreiter> Message-ID: <48D0254D.8010608@foo-projects.org> v4hn wrote: > ev'ning, > > On Mon, Sep 15, 2008 at 07:24:37AM +0200, Stefan Wold wrote: >> -------- Forwarded Message -------- >> From: Stefan Wold >> To: Dennis Veatch >> Subject: Re: lunar-1.6.4-alpha3-x86_64.iso issues >> Date: Mon, 15 Sep 2008 07:19:36 +0200 >> >> [...] >> On Sun, 2008-09-14 at 20:14 -0400, Dennis Veatch wrote: >>> First. For the longest time the ISO has had reiserfs, XFS and/or JFS built >>> into the kernel. The reason for the "and/or" on the last two items, I am not >>> sure if one or both were built in. AFAICR, at least two of those were, and I >>> am puzzled why they have been moved a module, and forcing a kernel recompile >>> on the install to use them. I would really appreciate at least reiserfs >>> returned to a built-in. I only bark about this because I have been using >>> reiserfs for that past 4 years or so with lunar. >> This is probably a misstake from my side, I'll fix this for the next >> release that should be a beta. > > Some time ago there was a discussion in #lunar whether or not reiserfs should > be build in the kernel, when sofar played around with the kernel-config of the > iso. Well, he stated no one should use reiserfs anyway because ext3 is much > more appreciated, more stable, ... > Quite a lot of people disagreed, but well... sofar had spoken ;) > so it was left out until now. there will always be discussions about this, but give the following facts a good throught: 1) SuSE dropped reiserfs support a long time ago completely and went back to ext3 2) all major distros ship ext3 as default filesystem 3) all netbooks currently being sold (10s of millions this year!) use ext3 I do not see a compelling reason to provide a kernel for NEW installs that BY DEFAULT supports a filesystem that 99% of new users (my personal estimate) will use. Those frostbitten dead-cold corpses with their tongues stuck to reiserfs (sorry, I can't resist) can still rebuild the kernel and install fine. I even added a warning to the ISO install code to warn them that they should do so (before you get to the kernel option even), so that problem is also clearly addressed. If that warning does not work then we should fix that. Stop saying that 'a lot of people disagreed'. That is nonsense. You don't hear the 200+ million (wild guess) happy ext3 users complain. Now _that_ is a lot of people. Auke From samuel.verstraete at gmail.com Wed Sep 17 07:40:26 2008 From: samuel.verstraete at gmail.com (samuel) Date: Wed, 17 Sep 2008 07:40:26 +0200 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <48D0254D.8010608@foo-projects.org> References: <1221456277.3916.10.camel@localhost> <20080915062204.GA3255@kuebelreiter> <48D0254D.8010608@foo-projects.org> Message-ID: On Tue, Sep 16, 2008 at 11:29 PM, Kok, Auke wrote: > v4hn wrote: >> ev'ning, >> >> On Mon, Sep 15, 2008 at 07:24:37AM +0200, Stefan Wold wrote: >>> -------- Forwarded Message -------- >>> From: Stefan Wold >>> To: Dennis Veatch >>> Subject: Re: lunar-1.6.4-alpha3-x86_64.iso issues >>> Date: Mon, 15 Sep 2008 07:19:36 +0200 >>> >>> [...] >>> On Sun, 2008-09-14 at 20:14 -0400, Dennis Veatch wrote: >>>> First. For the longest time the ISO has had reiserfs, XFS and/or JFS built >>>> into the kernel. The reason for the "and/or" on the last two items, I am not >>>> sure if one or both were built in. AFAICR, at least two of those were, and I >>>> am puzzled why they have been moved a module, and forcing a kernel recompile >>>> on the install to use them. I would really appreciate at least reiserfs >>>> returned to a built-in. I only bark about this because I have been using >>>> reiserfs for that past 4 years or so with lunar. >>> This is probably a misstake from my side, I'll fix this for the next >>> release that should be a beta. >> >> Some time ago there was a discussion in #lunar whether or not reiserfs should >> be build in the kernel, when sofar played around with the kernel-config of the >> iso. Well, he stated no one should use reiserfs anyway because ext3 is much >> more appreciated, more stable, ... >> Quite a lot of people disagreed, but well... sofar had spoken ;) >> so it was left out until now. > > there will always be discussions about this, but give the following facts a good > throught: > > 1) SuSE dropped reiserfs support a long time ago completely and went back to ext3 > 2) all major distros ship ext3 as default filesystem > 3) all netbooks currently being sold (10s of millions this year!) use ext3 > > I do not see a compelling reason to provide a kernel for NEW installs that BY > DEFAULT supports a filesystem that 99% of new users (my personal estimate) will use. > > Those frostbitten dead-cold corpses with their tongues stuck to reiserfs (sorry, I > can't resist) can still rebuild the kernel and install fine. I even added a > warning to the ISO install code to warn them that they should do so (before you > get to the kernel option even), so that problem is also clearly addressed. If that > warning does not work then we should fix that. > > Stop saying that 'a lot of people disagreed'. That is nonsense. You don't hear the > 200+ million (wild guess) happy ext3 users complain. Now _that_ is a lot of people. > > Auke not that i necessarily disagree.... but what about the 6billion ppl using ntfs ? > _______________________________________________ > Lunar-dev mailing list > Lunar-dev at lunar-linux.org > http://foo-projects.org/mailman/listinfo/lunar-dev > From samuel.verstraete at gmail.com Sun Sep 21 19:57:25 2008 From: samuel.verstraete at gmail.com (samuel) Date: Sun, 21 Sep 2008 19:57:25 +0200 Subject: [Lunar-commits] XOrg 7.4 + Mesa 7.2 In-Reply-To: References: Message-ID: i'm already working on this update... no need to submit anything considering xorg... just pull my xorg git branch On Sun, Sep 21, 2008 at 7:32 PM, ????? ???? <0lvin at ukr.net> wrote: > Hello. > > Update for xorg to last version may be it needed someone. > > I submit this to moonbase, but I think this take some time. > > Please test this. On my computer this work. > > Best regards, Denis. > ---------- > --- > module: libdrm > id: f3db39754fd41c9a304967aa90c4c1dd > lvu submit: libdrm > lvu: 41d0769d8e06ad7650af26bc6cb1dfef - > uname -r: 2.6.26.5 > kernel headers: > gcc: 4.2.4 > glibc: 2.7 > > --- > xorg7/extra/libdrm/DETAILS | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > --- > diff a/xorg7/extra/libdrm b/xorg7/extra/libdrm > --- a/xorg7/extra/libdrm/DETAILS 2008-09-21 08:28:47.000000000 +0000 > +++ b/xorg7/extra/libdrm/DETAILS 2008-09-21 18:31:14.000000000 +0000 > @@ -1,12 +1,12 @@ > MODULE=libdrm > - VERSION=2.3.0 > + VERSION=2.3.1 > SOURCE=$MODULE-$VERSION.tar.bz2 > SOURCE_URL=http://dri.freedesktop.org/libdrm/ > - SOURCE_VFY=sha1:af2e8d6e3ad6b906b4d6f1b2ada2d523188c28ea > + SOURCE_VFY=sha1:775dc69fcabb324552b0b9fe3a67eceb324be194 > MODULE_PREFIX=${X11R7_PREFIX:-/usr} > WEB_SITE=http://www.freedesktop.org/ > ENTERED=20061017 > - UPDATED=20061201 > + UPDATED=20080921 > SHORT="the userspace interface to kernel DRM services" > > cat << EOF > @@ -16,3 +16,4 @@ > (DRI). The DRI is currently used on Linux to provide hardware- > accelerated OpenGL drivers. > EOF > ------------ > --- > module: mesa-lib > id: f3db39754fd41c9a304967aa90c4c1dd > lvu submit: mesa-lib > lvu: 41d0769d8e06ad7650af26bc6cb1dfef - > uname -r: 2.6.26.5 > kernel headers: > gcc: 4.2.4 > glibc: 2.7 > > --- > xorg7/mesa-lib/BUILD | 22 ++-------------------- > xorg7/mesa-lib/DETAILS | 10 +++++----- > 2 files changed, 7 insertions(+), 25 deletions(-) > > --- > diff a/xorg7/mesa-lib b/xorg7/mesa-lib > --- a/xorg7/mesa-lib/BUILD 2008-09-21 08:28:47.000000000 +0000 > +++ b/xorg7/mesa-lib/BUILD 2008-09-21 19:00:36.000000000 +0000 > @@ -1,25 +1,7 @@ > ( > - > - sedit 's,/usr/X11R6/lib/modules,/usr/lib,' configs/default && > - sedit 's,/usr/X11R6,/usr,g' configs/linux* configs/default && > - sedit 's,lib64,lib,g' configs/linux* configs/default && > - sedit 's,usr/local,usr,g' configs/linux* configs/default && > - sedit 's,lib/modules,lib,g' src/glx/x11/dri_glx.c && > - sedit 's,[-]g,,g' configs/default configs/linux-dri-x86 > configs/linux-dri-x86-64 configs/linux-dri && > - > - case `arch` in > - x86_64) CONF=linux-dri-x86-64 ;; > - i?86) CONF=linux-dri ;; > - *) exit 1 ;; > - esac && > - > - make $CONF && > + default_build > make -C progs/xdemos PROGS='glxinfo glxgears' && > - > - prepare_install && > - > - make install && > install -v -m644 include/GLView.h /usr/include/ && > install -v -m755 progs/xdemos/glxinfo progs/xdemos/glxgears /usr/bin > - > ) > $C_FIFO 2>&1 > + > --- a/xorg7/mesa-lib/DETAILS 2008-09-21 08:28:47.000000000 +0000 > +++ b/xorg7/mesa-lib/DETAILS 2008-09-21 18:34:03.000000000 +0000 > @@ -1,5 +1,5 @@ > MODULE=mesa-lib > - VERSION=7.0.4 > + VERSION=7.2 > SOURCE=MesaLib-$VERSION.tar.bz2 > SOURCE2=MesaDemos-$VERSION.tar.bz2 > SOURCE3=MesaGLUT-$VERSION.tar.bz2 > @@ -7,12 +7,12 @@ > SOURCE_URL=$SFORGE_URL/mesa3d/ > SOURCE2_URL=$SFORGE_URL/mesa3d/ > SOURCE3_URL=$SFORGE_URL/mesa3d/ > - SOURCE_VFY=sha1:7e2ecbe89d245510d2681d04e959aee6adc205c5 > - SOURCE2_VFY=sha1:1adb2010d6d3103bd57c08f228e2bbed38178e14 > - SOURCE3_VFY=sha1:488a9e39f5ec4ad6b7fa84dd9bc91844337462d5 > + SOURCE_VFY=sha1:a6dce814cc56a562890ab79cf4e205f62459a29c > + SOURCE2_VFY=sha1:3d7b9b3ee84ed3637849f7598faf3d60c5a2a9fd > + SOURCE3_VFY=sha1:2d969fc8214622b93bcc594c36e56bb573678d05 > WEB_SITE=http://www.mesa3d.org > ENTERED=20060215 > - UPDATED=20080818 > + UPDATED=20080920 > PSAFE="no" > SHORT="Mesa 3D library" > > -------------------- > --- > module: xf86driproto > id: f3db39754fd41c9a304967aa90c4c1dd > lvu submit: xf86driproto > lvu: 41d0769d8e06ad7650af26bc6cb1dfef - > uname -r: 2.6.26.5 > kernel headers: > gcc: 4.2.4 > glibc: 2.7 > > --- > xorg7/proto/xf86driproto/DETAILS | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > --- > diff a/xorg7/proto/xf86driproto b/xorg7/proto/xf86driproto > --- a/xorg7/proto/xf86driproto/DETAILS 2008-09-21 08:28:47.000000000 > +0000 > +++ b/xorg7/proto/xf86driproto/DETAILS 2008-09-21 18:30:57.000000000 > +0000 > @@ -1,12 +1,12 @@ > MODULE=xf86driproto > - VERSION=2.0.3 > + VERSION=2.0.4 > SOURCE=$MODULE-$VERSION.tar.bz2 > SOURCE_URL=$XORG_URL/individual/proto/ > - SOURCE_VFY=sha1:7ec544426fd33239ae7b0a293baa41a82eb2cbf4 > + SOURCE_VFY=sha1:bba018443dad831b328e7353cf034522401e2e6b > MODULE_PREFIX=${X11R7_PREFIX:-/usr} > WEB_SITE=http://www.x.org/ > ENTERED=20060120 > - UPDATED=20060120 > + UPDATED=20080921 > SHORT="the X.Org XFree86-DRI protocol headers" > > cat << EOF > @@ -15,3 +15,4 @@ > clients. > EOF > > + > --------------------- > module: xorg-server > id: f3db39754fd41c9a304967aa90c4c1dd > lvu submit: xorg-server > lvu: 41d0769d8e06ad7650af26bc6cb1dfef - > uname -r: 2.6.26.5 > kernel headers: > gcc: 4.2.4 > glibc: 2.7 > > --- > xorg7/xorg-server/DEPENDS | 2 ++ > xorg7/xorg-server/DETAILS | 11 ++++++----- > 2 files changed, 8 insertions(+), 5 deletions(-) > > --- > diff a/xorg7/xorg-server b/xorg7/xorg-server > --- a/xorg7/xorg-server/DEPENDS 2008-09-21 08:28:47.000000000 +0000 > +++ b/xorg7/xorg-server/DEPENDS 2008-09-21 18:30:26.000000000 +0000 > @@ -28,6 +28,8 @@ > depends pixman > depends dbus-glib > depends hal > +depends libpciaccess > depends xkeyboard-config > > optional_depends "acpid" "" "" "for ACPI support through xorg-server" > + > --- a/xorg7/xorg-server/DETAILS 2008-09-21 08:28:47.000000000 +0000 > +++ b/xorg7/xorg-server/DETAILS 2008-09-21 18:30:36.000000000 +0000 > @@ -1,16 +1,16 @@ > MODULE=xorg-server > - VERSION=1.4.2 > - MESA_VERSION=7.0.4 > + VERSION=1.5.0 > + MESA_VERSION=7.2 > SOURCE=$MODULE-$VERSION.tar.bz2 > SOURCE2=MesaLib-${MESA_VERSION}.tar.bz2 > SOURCE_URL=$XORG_URL/individual/xserver > SOURCE2_URL=$SFORGE_URL/mesa3d > - SOURCE_VFY=sha1:385348721ecb6da4bc51a2b7ee5784de6be0a8b6 > - SOURCE2_VFY=sha1:7e2ecbe89d245510d2681d04e959aee6adc205c5 > + SOURCE_VFY=sha1:b9554f3996ae18fdce109f475d745dc05d6a5970 > + SOURCE2_VFY=sha1:a6dce814cc56a562890ab79cf4e205f62459a29c > MODULE_PREFIX=${X11R7_PREFIX:-/usr} > WEB_SITE=http://www.x.org > ENTERED=20060120 > - UPDATED=20080816 > + UPDATED=20080920 > MAINTAINER=elangelo at lunar-linux.org > SHORT="The X.Org X11R7 server for the X Window System" > > @@ -18,3 +18,4 @@ > The XOrg foundation's open sourced public implemetation of X11 (the XOrg > Server) is the offical reference implementation of the X Window System. > EOF > + > _______________________________________________ > Lunar-commits mailing list > Lunar-commits at lunar-linux.org > http://foo-projects.org/mailman/listinfo/lunar-commits > > From sofar at foo-projects.org Mon Sep 22 20:02:28 2008 From: sofar at foo-projects.org (Kok, Auke) Date: Mon, 22 Sep 2008 11:02:28 -0700 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: References: <1221456277.3916.10.camel@localhost> <20080915062204.GA3255@kuebelreiter> <48D0254D.8010608@foo-projects.org> Message-ID: <48D7DDB4.9010807@foo-projects.org> samuel wrote: >> Stop saying that 'a lot of people disagreed'. That is nonsense. You don't hear the >> 200+ million (wild guess) happy ext3 users complain. Now _that_ is a lot of people. >> >> Auke > > not that i necessarily disagree.... but what about the 6billion ppl using ntfs ? what are their alternatives? From dagbrown at lart.ca Mon Sep 22 22:16:45 2008 From: dagbrown at lart.ca (Dave Brown) Date: Tue, 23 Sep 2008 05:16:45 +0900 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <48D7DDB4.9010807@foo-projects.org> References: <1221456277.3916.10.camel@localhost> <20080915062204.GA3255@kuebelreiter> <48D0254D.8010608@foo-projects.org> <48D7DDB4.9010807@foo-projects.org> Message-ID: <20080922201645.GA29899@phb> On Mon, Sep 22, 2008 at 11:02:28AM -0700, Kok, Auke wrote: > samuel wrote: > > not that i necessarily disagree.... but what about the 6billion ppl > > using ntfs ? > > what are their alternatives? FAT? --Dave From sofar at foo-projects.org Mon Sep 22 22:24:56 2008 From: sofar at foo-projects.org (Kok, Auke) Date: Mon, 22 Sep 2008 13:24:56 -0700 Subject: [Fwd: Re: lunar-1.6.4-alpha3-x86_64.iso issues] In-Reply-To: <20080922201645.GA29899@phb> References: <1221456277.3916.10.camel@localhost> <20080915062204.GA3255@kuebelreiter> <48D0254D.8010608@foo-projects.org> <48D7DDB4.9010807@foo-projects.org> <20080922201645.GA29899@phb> Message-ID: <48D7FF18.5070703@foo-projects.org> Dave Brown wrote: > On Mon, Sep 22, 2008 at 11:02:28AM -0700, Kok, Auke wrote: >> samuel wrote: >>> not that i necessarily disagree.... but what about the 6billion ppl >>> using ntfs ? >> what are their alternatives? > > FAT? exactly, there is no real alternative journalling filesystem on windows. From zmcgrew at gmail.com Thu Sep 25 11:41:57 2008 From: zmcgrew at gmail.com (Zachary McGrew) Date: Thu, 25 Sep 2008 02:41:57 -0700 Subject: Gnome 2.24 Message-ID: <4b1a641e0809250241t50656846p378cd2baea07f61a@mail.gmail.com> Message to all brave/adventurous souls: Gnome 2.24 is in my gnome224 branch on doppio. So far yelp (gnome-help browser) doesn't work and opal (part of ekiga) won't build with firewire camera support. Everything else seems to be working. Oh, and it's using a ton of unstable libs, like cairo 1.7.6 because that's what Gnome has decided to require. If your fonts look ugly it's because I didn't use the cairo patch we've been using. Ideally I'd like to get that working again, but didn't play with it. Despite the unstable libs, I haven't had anything crash yet. This isn't all of Gnome 2.24. It's lacking the fun new modules, namely empathy (new im client) and vinagre (remote desktop client). Pretty much everything else is updated, minus evolution, which I'll let tchan do. Evolution-data-server is however updated. -- Zachary McGrew Web: http://zmcgrew.no-ip.com