From sofar at foo-projects.org Thu Sep 3 05:06:09 2009 From: sofar at foo-projects.org (Auke Kok) Date: Wed, 02 Sep 2009 20:06:09 -0700 Subject: Multilib lunar In-Reply-To: References: Message-ID: <4A9F32A1.6010608@foo-projects.org> Peter de Ridder wrote: > Hi, > > A while back I did some research in making lunar into a multilib system. > After a few attempts I was able to make a new lunar install by hand > into a multilib system. > Later I was able to convert a x86_64 system into a multilib system. > I wrote a howto for this at > http://member.lycos.nl/pcridder/extern/lunar unfortunately this isn't > accessible anymore. > If someone knows/has a place to host this let me know. > > To really be able to benefit from a multilib system some things should > be added to the moonbase and lunar tools. > That gets me to the purpose of this mail. > I want to put some more effort into it to get the multilib usable. > But I got stuck on the moonbase for now, and I would like some help to > get to a solution. > > The question: > How should the multilib modules be integrated into the moonbase? > > Currently the moonbase uses configurations based on the processor > type, which is either a 32-bit or 64-bit processor. > For multilib both of these configurations should be combined. > > Possible solutions: > 1) Separate moonbase repository/branch. > 2) Separate configuration type (like x86_64) for multilib. > 3) Packages with -32 postfix for 32-bit multilib version. > 4) Some intelligent lunar scripts to create multilib configuration > from 32-bit and 64-bit configurations. > > Pros and cons: > 1) Separate moonbase must be kept up-to-date separately. > But it is not limited in possibilities. > 2) Another configuration to maintain. > If multilib is not required for a certain module it can use the > 64-bit configuration. > 3) How to solve the installed files conflicts between the -32 and the > 64-bit module. > Multilib versions are only installed if the multilib version is required. > 4) Nearly impossible to create I guess. > Least maintenance. > > Follow-ups: > 1) For this solution the question remains fairly the same. > - Which of the other solutions is used in this moonbase. > 2) How is the configuration maintained? > - Is it stored in a .x86_64_multilib file postfix or > - Does a .x86_64 config file check for some special multilib option. > 3) How to solve the installed files conflicts between the -32 and the > 64-bit module? > 4) How would this be possible? this is all fascinating, but I can't stop thinking about your motives. Q: Why does anyone want a multilib system? A: To run applications that are not available on (32|64) bit systems that won't run on my (64|32) bit system Q: What applications are that? A: Only binary only proprietary software Q: Why would we make moonbase unworkable for just these modules? A: We don't. At least, this is how I see the issue. The only benefit multilib gives is a barely marginal one. Desktop systems should just be 32-bit, since everything works and latency is much better (64 bits comes as a cost), and nobody needs the memory features anyway (in this decade). So, most likely your efforts will be wasted since there is little support from other lunar devs to make all this work. It's been proposed before in other forms, but it pretty much comes down to the same conclusion: it's just not worth most developer's time. if you could make it work without impacting any module in moonbase (e.g. lunar's BUILD code would be smart enough) then I'd be much more interested in it... for now I think it's a pipe dream. Cheers, Auke From peter at xfce.org Thu Sep 3 12:13:16 2009 From: peter at xfce.org (Peter de Ridder) Date: Thu, 3 Sep 2009 12:13:16 +0200 Subject: Multilib lunar In-Reply-To: <4A9F32A1.6010608@foo-projects.org> References: <4A9F32A1.6010608@foo-projects.org> Message-ID: On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok wrote: > Peter de Ridder wrote: >> >> Hi, >> >> A while back I did some research in making lunar into a multilib system. >> After a few attempts I was able to make a new lunar install by hand >> into a multilib system. >> Later I was able to convert a x86_64 system into a multilib system. >> I wrote a howto for this at >> http://member.lycos.nl/pcridder/extern/lunar unfortunately this isn't >> accessible anymore. >> If someone knows/has a place to host this let me know. >> >> To really be able to benefit from a multilib system some things should >> be added to the moonbase and lunar tools. >> That gets me to the purpose of this mail. >> I want to put some more effort into it to get the multilib usable. >> But I got stuck on the moonbase for now, and I would like some help to >> get to a solution. >> >> The question: >> How should the multilib modules be integrated into the moonbase? >> >> Currently the moonbase uses configurations based on the processor >> type, which is either a 32-bit or 64-bit processor. >> For multilib both of these configurations should be combined. >> >> Possible solutions: >> 1) Separate moonbase repository/branch. >> 2) Separate configuration type (like x86_64) for multilib. >> 3) Packages with -32 postfix for 32-bit multilib version. >> 4) Some intelligent lunar scripts to create multilib configuration >> from 32-bit and 64-bit configurations. >> >> Pros and cons: >> 1) Separate moonbase must be kept up-to-date separately. >> But it is not limited in possibilities. >> 2) Another configuration to maintain. >> If multilib is not required for a certain module it can use the >> 64-bit configuration. >> 3) How to solve the installed files conflicts between the -32 and the >> 64-bit module. >> Multilib versions are only installed if the multilib version is >> required. >> 4) Nearly impossible to create I guess. >> Least maintenance. >> >> Follow-ups: >> 1) For this solution the question remains fairly the same. >> - Which of the other solutions is used in this moonbase. >> 2) How is the configuration maintained? >> - Is it stored in a .x86_64_multilib file postfix or >> - Does a .x86_64 config file check for some special multilib option. >> 3) How to solve the installed files conflicts between the -32 and the >> 64-bit module? >> 4) How would this be possible? > > this is all fascinating, but I can't stop thinking about your motives. > My motives are that some programs I want to use don't come in a 32-bit version and more important I like to do it as a hobby project. So for me it wouldn't be waste time, but spend time. I know there are other solutions like chroot. > Q: Why does anyone want a multilib system? > A: To run applications that are not available on (32|64) bit systems that > won't run on my (64|32) bit system > > Q: What applications are that? > A: Only binary only proprietary software > Grub for example and wine. wine isn't such a strong point, since it already is a separate environment so a chroot wouldn't change much. > Q: Why would we make moonbase unworkable for just these modules? > A: We don't. > > At least, this is how I see the issue. The only benefit multilib gives is a > barely marginal one. Desktop systems should just be 32-bit, since everything > works and latency is much better (64 bits comes as a cost), and nobody needs > the memory features anyway (in this decade). > > So, most likely your efforts will be wasted since there is little support > from other lunar devs to make all this work. It's been proposed before in > other forms, but it pretty much comes down to the same conclusion: it's just > not worth most developer's time. > I can understand other developers don't want to spend time on this, since in there opinion it is useless. I like to work on it for a bit, but need some help figuring thing. But if none wants/can help me, that is ok, just to bad for me ;). > if you could make it work without impacting any module in moonbase (e.g. > lunar's BUILD code would be smart enough) then I'd be much more interested > in it... for now I think it's a pipe dream. > This is the reason for this mail, to find some way how the moonbase would still be maintainable. Regards, Peter From dennisveatch at bellsouth.net Thu Sep 3 12:36:25 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Thu, 3 Sep 2009 06:36:25 -0400 Subject: Multilib lunar In-Reply-To: References: <4A9F32A1.6010608@foo-projects.org> Message-ID: <200909030636.25101.dennisveatch@bellsouth.net> On Thursday 03 September 2009 6:13:16 am Peter de Ridder wrote: > On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok wrote: > > Peter de Ridder wrote: > >> Hi, > >> > > My motives are that some programs I want to use don't come in a 32-bit > version and more important I like to do it as a hobby project. So for > me it wouldn't be waste time, but spend time. > I know there are other solutions like chroot. > Aside from those noted in this thread, would you mind listing the applications that makes this an important feature of lunar? > > Q: Why does anyone want a multilib system? > > A: To run applications that are not available on (32|64) bit systems that > > won't run on my (64|32) bit system > > > > Q: What applications are that? > > A: Only binary only proprietary software > > Grub for example and wine. wine isn't such a strong point, since it > already is a separate environment so a chroot wouldn't change much. > > > Q: Why would we make moonbase unworkable for just these modules? > > A: We don't. > > > > At least, this is how I see the issue. The only benefit multilib gives is > > a barely marginal one. Desktop systems should just be 32-bit, since > > everything works and latency is much better (64 bits comes as a cost), > > and nobody needs the memory features anyway (in this decade). > > > > So, most likely your efforts will be wasted since there is little support > > from other lunar devs to make all this work. It's been proposed before in > > other forms, but it pretty much comes down to the same conclusion: it's > > just not worth most developer's time. > > I can understand other developers don't want to spend time on this, > since in there opinion it is useless. I like to work on it for a bit, > but need some help figuring thing. But if none wants/can help me, that > is ok, just to bad for me ;). > "Useless" is perhaps the wrong description. Its more like the few perceived modules that are 32 bit only versus the number of modules we have. Besides grub, wine and virtualbox, I cannot think of anything in moonbase that has this limitation, there may be a few others but none come to mind. So I think it goes back the the 32 bit apps you want to use but haven't specified what those are. > > if you could make it work without impacting any module in moonbase (e.g. > > lunar's BUILD code would be smart enough) then I'd be much more > > interested in it... for now I think it's a pipe dream. > > This is the reason for this mail, to find some way how the moonbase > would still be maintainable. > > Regards, > Peter > _______________________________________________ -- Dennis You can tuna piano, but you can't tune a fish. From peter at xfce.org Thu Sep 3 14:02:49 2009 From: peter at xfce.org (Peter de Ridder) Date: Thu, 3 Sep 2009 14:02:49 +0200 Subject: Multilib lunar In-Reply-To: <200909030636.25101.dennisveatch@bellsouth.net> References: <4A9F32A1.6010608@foo-projects.org> <200909030636.25101.dennisveatch@bellsouth.net> Message-ID: On Thu, Sep 3, 2009 at 12:36 PM, Dennis Veatch wrote: > On Thursday 03 September 2009 6:13:16 am Peter de Ridder wrote: >> On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok wrote: >> > Peter de Ridder wrote: >> >> Hi, >> >> >> >> My motives are that some programs I want to use don't come in a 32-bit >> version and more important I like to do it as a hobby project. So for >> me it wouldn't be waste time, but spend time. >> I know there are other solutions like chroot. >> > > Aside from those noted in this thread, would you mind listing the applications > that makes this an important feature of lunar? It is about the modules you noted later on. grub, wine and maybe some other emulators. (I don't know all the modules, for me it is mostly grub and wine). It is not my goal to make all modules in 64-bit and 32-bit. Just to support those that really need 32-bit. What is know of that needs 32-bit. grub: not many or no dependencies. wine: this would mean alot of X libraries need to have 32-bit. virtualbox: the website claims to work on 64-bit too. Phun: this is a binary package which also has a 64-bit version, it is not my intention to support the 32-bit version of this. (Added as an example). I hope this clarifies my intentions. > "Useless" is perhaps the wrong description. Its more like the few perceived > modules that are 32 bit only versus the number of modules we have. Besides > grub, wine and virtualbox, I cannot think of anything in moonbase that has > this limitation, there may be a few others but none come to mind. So I think > it goes back the the 32 bit apps you want to use but haven't specified what > those are. Regards, Peter From dennisveatch at bellsouth.net Thu Sep 3 14:51:14 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Thu, 3 Sep 2009 08:51:14 -0400 Subject: Multilib lunar In-Reply-To: References: <200909030636.25101.dennisveatch@bellsouth.net> Message-ID: <200909030851.14809.dennisveatch@bellsouth.net> On Thursday 03 September 2009 8:02:49 am Peter de Ridder wrote: > On Thu, Sep 3, 2009 at 12:36 PM, Dennis > > Veatch wrote: > > On Thursday 03 September 2009 6:13:16 am Peter de Ridder wrote: > >> On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok wrote: > >> > Peter de Ridder wrote: > >> >> Hi, > >> > >> My motives are that some programs I want to use don't come in a 32-bit > >> version and more important I like to do it as a hobby project. So for > >> me it wouldn't be waste time, but spend time. > >> I know there are other solutions like chroot. > > > > Aside from those noted in this thread, would you mind listing the > > applications that makes this an important feature of lunar? > > It is about the modules you noted later on. grub, wine and maybe some > other emulators. (I don't know all the modules, for me it is mostly > grub and wine). It is not my goal to make all modules in 64-bit and > 32-bit. Just to support those that really need 32-bit. > What is know of that needs 32-bit. > grub: not many or no dependencies. I think grub is more of an up stream issue than anything else. If the developers would just finish grub2 it would be a non-issue. qemu/kqemu compile fine on x86_64 but have not tried any others. At one point I had virtualbox nearly compiling on x86_64. The make failed on some assembly stuff and anything I might have known about it has long since been forgotten. > wine: this would mean alot of X libraries need to have 32-bit. > virtualbox: the website claims to work on 64-bit too. > Phun: this is a binary package which also has a 64-bit version, it is > not my intention to support the 32-bit version of this. (Added as an > example). > > I hope this clarifies my intentions. > > > "Useless" is perhaps the wrong description. Its more like the few > > perceived modules that are 32 bit only versus the number of modules we > > have. Besides grub, wine and virtualbox, I cannot think of anything in > > moonbase that has this limitation, there may be a few others but none > > come to mind. So I think it goes back the the 32 bit apps you want to use > > but haven't specified what those are. > > Regards, > Peter > -- Dennis You can tuna piano, but you can't tune a fish. From sofar at foo-projects.org Thu Sep 3 18:26:42 2009 From: sofar at foo-projects.org (Auke Kok) Date: Thu, 03 Sep 2009 09:26:42 -0700 Subject: Multilib lunar In-Reply-To: <200909030851.14809.dennisveatch@bellsouth.net> References: <200909030636.25101.dennisveatch@bellsouth.net> <200909030851.14809.dennisveatch@bellsouth.net> Message-ID: <4A9FEE42.8080907@foo-projects.org> Dennis Veatch wrote: > On Thursday 03 September 2009 8:02:49 am Peter de Ridder wrote: >> On Thu, Sep 3, 2009 at 12:36 PM, Dennis >> >> Veatch wrote: >>> On Thursday 03 September 2009 6:13:16 am Peter de Ridder wrote: >>>> On Thu, Sep 3, 2009 at 5:06 AM, Auke Kok wrote: >>>>> Peter de Ridder wrote: >>>>>> Hi, >>>> My motives are that some programs I want to use don't come in a 32-bit >>>> version and more important I like to do it as a hobby project. So for >>>> me it wouldn't be waste time, but spend time. >>>> I know there are other solutions like chroot. >>> Aside from those noted in this thread, would you mind listing the >>> applications that makes this an important feature of lunar? >> It is about the modules you noted later on. grub, wine and maybe some >> other emulators. (I don't know all the modules, for me it is mostly >> grub and wine). It is not my goal to make all modules in 64-bit and >> 32-bit. Just to support those that really need 32-bit. >> What is know of that needs 32-bit. >> grub: not many or no dependencies. > > I think grub is more of an up stream issue than anything else. If the > developers would just finish grub2 it would be a non-issue. qemu/kqemu compile > fine on x86_64 but have not tried any others. grub2 will be DOA and nobody will use it. better put your bets on grub(1) for now. grub2 is a giant train wreck From duncan.gibson at xs4all.nl Fri Sep 4 09:23:32 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Fri, 4 Sep 2009 09:23:32 +0200 Subject: Multilib lunar In-Reply-To: References: Message-ID: > A while back I did some research in making lunar into a multilib system. > After a few attempts I was able to make a new lunar install by hand > into a multilib system. The comments section of this week's DistroWatch Weekly has a link to an interview with Eric Harmerleer about porting SlackWare to 64-bit: http://www.linux-mag.com/cache/7502/1.html The interview contains a link to a wiki page about a multilib version: http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib Thought you might find it interesting. Cheers Duncan / engelsman From peter at xfce.org Fri Sep 4 10:23:03 2009 From: peter at xfce.org (Peter de Ridder) Date: Fri, 4 Sep 2009 10:23:03 +0200 Subject: Multilib lunar In-Reply-To: References: Message-ID: On Fri, Sep 4, 2009 at 9:23 AM, Duncan Gibson wrote: >> A while back I did some research in making lunar into a multilib system. >> After a few attempts I was able to make a new lunar install by hand >> into a multilib system. > > The comments section of this week's DistroWatch Weekly has a link to an > interview with Eric Harmerleer about porting SlackWare to 64-bit: > http://www.linux-mag.com/cache/7502/1.html > > The interview contains a link to a wiki page about a multilib version: > http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib > > Thought you might find it interesting. The last link is indeed interesting. The massconvert32 script is what should be done to convert a 32-bit install into a multilib 32-bit package. Only the question remains. How could this be integrated in moonbase. Regards, Peter From duncan.gibson at xs4all.nl Tue Sep 15 23:20:31 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Tue, 15 Sep 2009 23:20:31 +0200 Subject: [Lunar-commits] ve: updated to version 1.4.0 (intermediate) In-Reply-To: <20090915211325.18083F3442@doppio.foo-projects.org> References: <20090915211325.18083F3442@doppio.foo-projects.org> Message-ID: I've been a very naughty boy and committed a module that doesn't build. It didn't even download before, so at least that's an improvement. Can anyone tell me why it won't unpack into /usr/src/eclipse when the emf-xsd and gef modules do? I've been staring at this for 2 days! And because it doesn't unpack there, I get the error from the BUILD: root at wired ~ # lin -rc ve Checking dependencies for ve Building ve version 1.4.0 cp: cannot stat `*': No such file or directory Creating /var/log/lunar/compile/ve-1.4.0.bz2 ! Problem detected during BUILD Cheers Duncan > commit 28ea0df0fc9f410fc49e96d1a75be93ae66788ed > Author: Duncan Gibson > Date: Tue Sep 15 23:05:59 2009 +0200 > > ve: updated to version 1.4.0 (intermediate) > > previous version failed to download during an 'lget -a' sweep. > > This version is an intermediate version of 1.4.0, and is > therefore likely to change, but currently downloads OK, > so that's an improvement on the previous version > > BUT... I can't get the damn thing to unpack properly even > though it follows the same pattern as emf-xsd and gef - engelsman :-( > --- > eclipse/ve/DEPENDS | 2 +- > eclipse/ve/DETAILS | 15 +++++++++------ > 2 files changed, 10 insertions(+), 7 deletions(-) > > diff --git a/eclipse/ve/DEPENDS b/eclipse/ve/DEPENDS > index 6b3dd9c..4e95bb0 100644 > --- a/eclipse/ve/DEPENDS > +++ b/eclipse/ve/DEPENDS > @@ -1,2 +1,2 @@ > -depends emf-sdo-xsd && > +depends emf-xsd > depends gef > diff --git a/eclipse/ve/DETAILS b/eclipse/ve/DETAILS > index c224f34..56201b0 100644 > --- a/eclipse/ve/DETAILS > +++ b/eclipse/ve/DETAILS > @@ -1,14 +1,17 @@ > MODULE=ve > - VERSION=1.2 > - EXTRA=200606280938 > - SOURCE=VE-SDK-$VERSION.zip > + VERSION=1.4.0 > + EXTRA=I200908111513 > + SOURCE=VE-Update-$EXTRA.zip > SOURCE_DIRECTORY=$BUILD_DIRECTORY/eclipse > - > SOURCE_URL=ftp://mirror.switch.ch/mirror/eclipse/tools/ve/downloads/drops/R-$VERSION-$EXTRA/ > - SOURCE_VFY=sha1:2bf7b8e2941b00694491a88a555f29123f413e95 > + > SOURCE_URL=ftp://mirror.switch.ch/mirror/eclipse/tools/ve/downloads/drops/$VERSION/$EXTRA/ > + SOURCE_VFY=sha1:faf18ab46330315a7e42d36f2783f5f74700bb72 > WEB_SITE=http://eclipse.org/vep/ > ENTERED=20040728 > - UPDATED=20070701 > + UPDATED=20090915 > SHORT="framework for creating GUI for Eclipse." > cat << EOF > The Eclipse Visual Editor is a framework for creating GUI for Eclipse. > + > +Note: this is an integration build rather than a fixed release, > +so the exact version and build number could change frequently! > 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 Wed Sep 16 08:10:42 2009 From: sofar at foo-projects.org (Auke Kok) Date: Tue, 15 Sep 2009 23:10:42 -0700 Subject: [Lunar-commits] ve: updated to version 1.4.0 (intermediate) In-Reply-To: References: <20090915211325.18083F3442@doppio.foo-projects.org> Message-ID: <4AB08162.4010400@foo-projects.org> Duncan Gibson wrote: > I've been a very naughty boy and committed a module that doesn't build. > It didn't even download before, so at least that's an improvement. > Can anyone tell me why it won't unpack into /usr/src/eclipse when > the emf-xsd and gef modules do? I've been staring at this for 2 days! what's in the tarball? tar tvf ....? Auke From duncan.gibson at xs4all.nl Wed Sep 16 08:58:08 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 16 Sep 2009 08:58:08 +0200 Subject: [Lunar-commits] ve: updated to version 1.4.0 (intermediate) In-Reply-To: <4AB08162.4010400@foo-projects.org> References: <20090915211325.18083F3442@doppio.foo-projects.org> <4AB08162.4010400@foo-projects.org> Message-ID: >> I've been a very naughty boy and committed a module that doesn't build. >> It didn't even download before, so at least that's an improvement. >> Can anyone tell me why it won't unpack into /usr/src/eclipse when >> the emf-xsd and gef modules do? I've been staring at this for 2 days! > what's in the tarball? tar tvf ....? It's a zip file, VE-Update-I200908111513.zip, and it's downloaded OK. I can unzip it manually into /usr/src/eclipse, but lin somehow doesn't. If I add an 'unzip $SOURCE' to BUILD, lin then complains that it can't unpack the zip, and the zip.zip and another variation. I'm at work and not sitting at my lunar box, so can't give the exact text right now. As far as I can see, there's no difference in process between this module, and the emf-xsd and gef modules, which I've just updated too. There's no compilation needed. Just a question of unpacking some jar and xml files into /usr/src/eclipse and copying to /opt/lunar/eclipse I have the feeling that it's something so obvious that I can't see it. Cheers Duncan From samuel.verstraete at gmail.com Wed Sep 16 20:34:09 2009 From: samuel.verstraete at gmail.com (samuel) Date: Wed, 16 Sep 2009 20:34:09 +0200 Subject: [Lunar-commits] iptables: version bumped to 1.4.5. In-Reply-To: <20090916122105.A86F59B1F1@doppio.foo-projects.org> References: <20090916122105.A86F59B1F1@doppio.foo-projects.org> Message-ID: if you update to this /etc/config.d/iptables gets overwritten... fix it! On Wed, Sep 16, 2009 at 2:20 PM, Florin Braescu wrote: > commit bac77347d03b3b76a435917d4bd54234101de254 > Author: Florin Braescu > Date: ? Wed Sep 16 15:20:31 2009 +0300 > > ? ?iptables: version bumped to 1.4.5. > > ? ?This release includes updates for new features in kernel 2.6.31, bugfixes, > ? ?and documentation updates. > --- > ?security/iptables/DETAILS | ? ?6 +++--- > ?1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/security/iptables/DETAILS b/security/iptables/DETAILS > index 2286b5c..5ac2894 100644 > --- a/security/iptables/DETAILS > +++ b/security/iptables/DETAILS > @@ -1,11 +1,11 @@ > ? ? ? ? ? MODULE=iptables > - ? ? ? ? VERSION=1.4.4 > + ? ? ? ? VERSION=1.4.5 > ? ? ? ? ? SOURCE=$MODULE-$VERSION.tar.bz2 > ? ? ? SOURCE_URL=ftp://ftp.netfilter.org/pub/$MODULE > - ? ? ?SOURCE_VFY=sha1:309b22eeb89a6a6abb3c46e03be84de52348f6f7 > + ? ? ?SOURCE_VFY=sha1:d1354584a901ffc1bf6c3b3b55a1d0dcee778d21 > ? ? ? ? WEB_SITE=http://www.netfilter.org > ? ? ? ? ?ENTERED=20010922 > - ? ? ? ? UPDATED=20090617 > + ? ? ? ? UPDATED=200909016 > ? ? ? ? ? ?SHORT="Tool to create netfilter rules" > ? ? ? ? ? ?PSAFE=no > > _______________________________________________ > Lunar-commits mailing list > Lunar-commits at lunar-linux.org > http://foo-projects.org/mailman/listinfo/lunar-commits > From duncan.gibson at xs4all.nl Wed Sep 16 21:06:29 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 16 Sep 2009 21:06:29 +0200 Subject: [Lunar-commits] ve: updated to version 1.4.0 (intermediate) In-Reply-To: References: <20090915211325.18083F3442@doppio.foo-projects.org> <4AB08162.4010400@foo-projects.org> Message-ID: >>> I've been a very naughty boy and committed a module that doesn't build. >>> It didn't even download before, so at least that's an improvement. >>> Can anyone tell me why it won't unpack into /usr/src/eclipse when >>> the emf-xsd and gef modules do? I've been staring at this for 2 days! > As far as I can see, there's no difference in process between this > module, and the emf-xsd and gef modules, which I've just updated too. > There's no compilation needed. Just a question of unpacking some jar > and xml files into /usr/src/eclipse and copying to /opt/lunar/eclipse > > I have the feeling that it's something so obvious that I can't see it. Yup, finally found it. There's none so blind as cannot see. The emf-xsd and gef zip files contained the top level 'eclipse' directory as well, but the ve zip file doesn't. So all this time I've been unpacking the contents directly into /usr/src and the /usr/src/eclipse directory has remained empty. Adding a PRE_BUILD to create the directory if needed, cd into it, and unpack there looks like it might do the trick... Cheers Duncan From brebs at sent.com Wed Sep 16 21:08:27 2009 From: brebs at sent.com (Paul Bredbury) Date: Thu, 17 Sep 2009 02:08:27 +0700 Subject: [Lunar-commits] iptables: version bumped to 1.4.5. In-Reply-To: References: <20090916122105.A86F59B1F1@doppio.foo-projects.org> Message-ID: <1253128107.29490.3.camel@localhost> On Wed, 2009-09-16 at 20:34 +0200, samuel wrote: > if you update to this > /etc/config.d/iptables gets overwritten Only by the usual iptables-save command in /etc/init.d/iptables, as far as I see from a quick glance - what's the problem? From dennisveatch at bellsouth.net Sun Sep 20 13:39:57 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 20 Sep 2009 07:39:57 -0400 Subject: It must be time for new kernel headers. Message-ID: <200909200739.57924.dennisveatch@bellsouth.net> Was having a problem with gst-plugins-good failing the make when libv4l was installed. Long story short; our kernel headers are getting out of date. Used the create_headers module from crater using 2.6.31, and it fixed that problem. I have copied the new x86_headers to $MIRROR_URL, recompiled glibc, gcc, binutils, and coreutils with no issues. But I do not have an x86 box available. So if someone would gen those up, send them to $MIRROR_URL; I will bump both DETAILS. Thanks Dennis -- You can tuna piano, but you can't tune a fish. From dennisveatch at bellsouth.net Sun Sep 20 14:34:06 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 20 Sep 2009 08:34:06 -0400 Subject: It must be time for new kernel headers. In-Reply-To: <200909200739.57924.dennisveatch@bellsouth.net> References: <200909200739.57924.dennisveatch@bellsouth.net> Message-ID: <200909200834.06733.dennisveatch@bellsouth.net> On Sunday 20 September 2009 7:39:57 am Dennis Veatch wrote: > Was having a problem with gst-plugins-good failing the make when libv4l was > installed. Long story short; our kernel headers are getting out of date. > Used the create_headers module from crater using 2.6.31, and it fixed that > problem. > > I have copied the new x86_headers to $MIRROR_URL, recompiled glibc, gcc, > binutils, and coreutils with no issues. But I do not have an x86 box > available. So if someone would gen those up, send them to $MIRROR_URL; I > will bump both DETAILS. > > Thanks > Dennis > There is one thing I have found. There is a conflict with: + Running sanity checks for module "libdrm" /usr/include/drm/drm_mode.h of libdrm has wrong md5sum. /usr/include/drm/i915_drm.h of libdrm has wrong md5sum. /usr/include/drm/mga_drm.h of libdrm has wrong md5sum. /usr/include/drm/r128_drm.h of libdrm has wrong md5sum. /usr/include/drm/radeon_drm.h of libdrm has wrong md5sum. /usr/include/drm/savage_drm.h of libdrm has wrong md5sum. /usr/include/drm/via_drm.h of libdrm has wrong md5sum. -- You can tuna piano, but you can't tune a fish. From dennisveatch at bellsouth.net Sun Sep 20 15:01:24 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 20 Sep 2009 09:01:24 -0400 Subject: [Lunar-commits] libvdpau: wrapper for VDPAU In-Reply-To: <20090919223324.D3C469B1C1@doppio.foo-projects.org> References: <20090919223324.D3C469B1C1@doppio.foo-projects.org> Message-ID: <200909200901.24097.dennisveatch@bellsouth.net> On Saturday 19 September 2009 4:25:34 pm Zbigniew Luszpinski wrote: > commit 33a9bc6acbe27c1dcc9fb076bf0d5f3cecc79a3d > Author: Zbigniew Luszpinski > Date: Sat Sep 19 22:25:34 2009 +0200 > > libvdpau: wrapper for VDPAU > --- > @@ -0,0 +1,53 @@ > + MODULE=libvdpau > + VERSION=0.2 > + SOURCE=$MODULE-$VERSION.tar.bz2 > + SOURCE_URL=http://cgit.freedesktop.org/~aplattner/$MODULE/snapshot > + SOURCE_VFY=sha1:03aed8e3f13c3040d0161ef3e685a65bb364489d > + WEB_SITE=http://cgit.freedesktop.org/~aplattner/$MODULE > + ENTERED=20090919 > + UPDATED=20090919 > + SHORT="VDPAU wrapper library" > + > libvdpau over writes /usr/include/vdpau/vdpau.h from NVIDIA-beta. How is this conflict to be handled? -- You can tuna piano, but you can't tune a fish. From zbiggy at o2.pl Sun Sep 20 18:07:56 2009 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Sun, 20 Sep 2009 18:07:56 +0200 Subject: [Lunar-commits] libvdpau: wrapper for VDPAU In-Reply-To: <200909200901.24097.dennisveatch@bellsouth.net> References: <20090919223324.D3C469B1C1@doppio.foo-projects.org> <200909200901.24097.dennisveatch@bellsouth.net> Message-ID: <200909201807.56281.zbiggy@o2.pl> > On Saturday 19 September 2009 4:25:34 pm Zbigniew Luszpinski wrote: > > commit 33a9bc6acbe27c1dcc9fb076bf0d5f3cecc79a3d > > Author: Zbigniew Luszpinski > > Date: Sat Sep 19 22:25:34 2009 +0200 > > > > libvdpau: wrapper for VDPAU > > --- > > > @@ -0,0 +1,53 @@ > > + MODULE=libvdpau > > + VERSION=0.2 > > + SOURCE=$MODULE-$VERSION.tar.bz2 > > + SOURCE_URL=http://cgit.freedesktop.org/~aplattner/$MODULE/snapshot > > + SOURCE_VFY=sha1:03aed8e3f13c3040d0161ef3e685a65bb364489d > > + WEB_SITE=http://cgit.freedesktop.org/~aplattner/$MODULE > > + ENTERED=20090919 > > + UPDATED=20090919 > > + SHORT="VDPAU wrapper library" > > + > > > libvdpau over writes /usr/include/vdpau/vdpau.h from NVIDIA-beta. How is this > conflict to be handled? > > libvdpau is fully open source, vendor independent, license free library plus headers. Nvidia pulls out VDPAU from driver package to external source package on X website to encourage Intel and ATI/AMD to use it in their products. (S3 already uses VDPAU in Chrome 500 series chipset driver). As soon as distro packagers will package libvdpau as separate package VDPAU libraries and headers will be removed from Nvidia driver package. Because current libvdpau package is equal to 190.32 driver libvdpau to resolve file conflict I modified NVIDIA-beta installer (not commited yet - have bugs) to depend on libvdpau. Future NVIDIA-beta will not install the following files/dir anymore: /usr/lib/libvdpau.so* /usr/lib/libvdpau_trace.so* /usr/include/vdpau because they are replaced by open source libvdpau with equally the same code. Another file not vdpau connected also will be removed if module_installed is not XOrg6: /usr/lib/modules/libnvidia-wfb.so* because this is hacked generic library for xorg who has not libwfb.so library (we have). Another feature of future NVIDIA-beta module will be removal of binary, precompiled files: rm -f nvidia-installer rm -f usr/bin/mkprecompiled && rm -f usr/share/man/man1/nvidia-installer.1.gz && rm -f usr/bin/nvidia-settings && rm -f usr/share/man/man1/nvidia-settings.1.gz && rm -f usr/bin/nvidia-xconfig && rm -f usr/share/man/man1/nvidia-xconfig.1.gz && rm -f usr/bin/nvidia-settings/nvidia-settings && rm -f usr/X11R6/lib/modules/libnvidia-wfb.so* && rm -f usr/lib/libvdpau.so.190.32 && rm -f usr/lib/libvdpau_trace.so.190.32 && rm -rf usr/include/vdpau && and to replace them with the same files but compiled from source packages. Nvidia provided open source packages so we will have the same files but compiled on Lunar and for Lunar. Especially I'm happy about nvidia-installer - thanks to this installation process of Nvidia module (and *-legacy, *-old) will be under our control :) BTW I have xine-vdpau and mplayer-vdpau modules in zlocal. xine is almost ready, mplayer needs some work. They will be added soon to moonbase (mplayer a little bit later). have a nice day, Zbigniew Luszpinski From duncan.gibson at xs4all.nl Wed Sep 30 22:58:03 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 30 Sep 2009 22:58:03 +0200 Subject: 1.6.4 ISO installation and update Message-ID: <077e6ac33ead8006dfafb8e225299bac.squirrel@webmail.xs4all.nl> The current 1.6.4 ISO is a little outdated, and after all this time it requires a little extra care and attention to install correctly. This article should provide the extra instructions you will need to install Lunar Linux while you wait for the next ISO release. The Lunar Linux 1.6.4 ISO was released around Christmas 2008. As Lunar is a rolling distro, anyone who downloaded and installed then will have been able to keep their system up-to-date with the latest versions of the major packages by running "lunar update" regularly. Such incremental updates usually only involve a handful of packages at a time, and Lunar's package management system is able to update the packages in the right order, and rebuild others that depend on them as required. However, in the nine months since that release, and in preparation for the next release, a large number of key packages on that ISO have also seen major releases, most notably gcc, glibc, readline and udev. If you were to install the 1.6.4 ISO now, and follow the usual update instructions given in "man lfirsttime", your "big bang" update will probably fail due to version mismatches between tools. If you want to install and update the 1.6.4 ISO successfully, you will need to follow the additional steps described below. To save extra rework, please read all of the instructions before you start. 1. Install the 1.6.4 ISO as usual, with a pre-compiled kernel. 2. Reboot the system, and set up your network as described in "man lfirsttime", but do not follow its update instructions. 3. DO NOT "lin moonbase" or anything else yet! 4. Run "lunar hold coreutils" to stop coreutils being rebuilt until the rest of the system is up-to-date, otherwise you risk breaking key tools, and the installation will fail. 5. Run "lin -rc gcc" to rebuild the version from the ISO 6. Run "lin -rc glibc" to rebuild the version from the ISO 7. Run "lin -rc pcre" to rebuild the version from the ISO 8. Run "lin moonbase" to get the latest package information 9. Run "lin -rc gcc" to build the latest version to replace the version from the ISO. This will also rebuild gmp and mfpr. 10. Run "lunar", select "Option/Optimize Architecture/GCC_4_4", set this compiler as the default, and then select your bopt, cpu, and cc_opt settings. If in doubt, check the "GCC_4_2" settings if available. 11. Run "lin -rc gcc glibc gcc bash tar wget" 12. Run "lin -rc e2fsprogs" to get an updated blkid 13. Run "lin -rc util-linux" to fix the e2fsprogs breakage 14. Run "lunar nofix" here to check the previous two steps! 15. Run "lin -rc libusb" to get an updated libusb to build hal 16. Run "lin -rc hal" to avoid subsequent udev failure 17. Run "lin -rc udev" 18. Run "lin -rc linux-2.6" to rebuild your kernel 19. Run "lunar nofix" and if all is well, reboot to new kernel. 20. Run "lunar update" AND EDIT THE UPDATE LIST !!! Remove "kernel-headers-2.6" and "readline" from the update list! You can let the update run [overnight] and it will eventually pause towards the end when "vim" prompts for the %X alias. 21. Run "lunar renew" and this time don't edit the update list, which should only consist of "kernel-headers-2.6", "readline" and possibly "lvm2" if step 20 ran unattended. 22. Run "lunar unhold coreutils" to allow them to be rebuilt 23. Run "lin -rc coreutils" 24. CONGRATULATIONS! Your base system is now up-to-date and ready for you to begin your customisations for server or desktop use. Note that you can run "lunar nofix" after each step to check for breakage if you want, and that the instructions below were correct at the time of writing, but may need updating as new versions of some of the packages become available. From duncan.gibson at xs4all.nl Wed Sep 30 23:15:42 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 30 Sep 2009 23:15:42 +0200 Subject: 1.6.4 ISO installation and update In-Reply-To: <077e6ac33ead8006dfafb8e225299bac.squirrel@webmail.xs4all.nl> References: <077e6ac33ead8006dfafb8e225299bac.squirrel@webmail.xs4all.nl> Message-ID: > The current 1.6.4 ISO is a little outdated, and after all this time > it requires a little extra care and attention to install correctly. > This article should provide the extra instructions you will need > to install Lunar Linux while you wait for the next ISO release. > ... I wanted to post the article to the News section on the LL home page, but couldn't see where to submit it. If it's good enough, could someone with access post it there for me? Thanks Duncan / engelsman