Re: [gobolinux-devel] Kernel Compilation Problem
I had similar results compiling the kernel. Switching to Union sandbox helped some. Make sure you have the following section in /System/Cettings/Scripts/Directories.conf: unionImplementations=( "unionfs" "unionfs-fuse" Funionfs" ) This will attempt to use the unionfs patch in the kernel first, then try the two fuse implementations. Depending on how the Scripts package is updated it might be missing. I haven't tried it my self but you can also try ChrootCompile and if successful you can install a package. This is probably the safest method of compiling the kernel (you won't get left with a machine with no modules in the kernel). Rehan From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Robert Dayton Sent: 09 July 2009 02:01 To: gobolinux-devel@lists.gobolinux.org Subject: Re: [gobolinux-devel] Kernel Compilation Problem Sorry, I made a mistake, I had used Compile to build kernel 2.6.29.1-r1 <http://recipes.gobolinux.org/r/?list=Linux&ver=2.6.29.1-r1&file=Recipe> but it failed to update the modules.conf or build them at all, simply leaving the old (now incompatible) module directory active. Manual compilation and installation of 2.6.30.1 went well, but again, no modules. On Wed, Jul 8, 2009 at 1:02 PM, Lucas C. Villa Real wrote: On Wed, Jul 8, 2009 at 2:42 PM, Robert Dayton wrote: > Hi, I'm having some slight difficulty installing the modules to a new > kernel, namely 2.6.30.1. Compile gives no errors, but the new module > directory and links aren't created automatically. Which kernel module are you trying to compile? Is there a recipe for it? -- Lucas "If you're looking for a reason I've a reason to give: pleasure, little treasure" ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
[gobolinux-devel] Bootstrap issues
Hi,
I've been playing around with the Bootstrap v1.1 and come across some
issues, some of which I have 'fixed' and some not.
I am initially trying to get it to do a native build just to get a feel
for it. I'll run through the issues as I remember them.
1) The cross-native.conf config file was missing from the svn Compile
version I am running. I found a copy of this file by taking pot shots at
older svn versions so that seems to be fixed (but may be wrong)
2) Next was the function Get_System_Paths function in
/Programs/Scripts/Functions/GoboLinux. BootStrap was error-ing on this
but continuing on. This was fixed by re-writing the function, as
suggested by detsch on irc, to :
Function Get_System_Paths () {
Parameters "$1" programpath
find "${programpath}" -mindepth 2 | while read path
do
Programs_To_System_Path "${path}"
done
I'm not sure if this has implications for other scripts?
3) Bootstrap throws out a bunch of signedness warnings while it is
compiling the menu but the menu works ok. It might be an idea to have
menuconfig respond to esc esc to go back similar to the kernel
menuconfig.
4) There were a couple of errors in the package config.in files (IIRC
the BC config.in and one other, I forget now) which was fixed by adding
the required first two lines deduced from looking at other packages
config.in's.
This got me to the point where there were no errors from bootstrap and
it was doing things consistently the same way on each invocation. I am
at the point where it now downloads the chroot environment (this was
failing I guess due to 2 above) and attempts to chrootcompile the first
package. It seems that this gets stuck somehow and then goes into an
endless loop of trying and re-trying the chrootcompile. There aren't any
useful error messages that I can see, in fact chrootcompile seems to
think it is doing ok and carries on.
Anyone have any suggestions on how can I proceed from here?
Thanks in advance
Rehan
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Bootstrap issues
-Original Message-
From: gobolinux-devel-boun...@lists.gobolinux.org
[mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Lucas
C. Villa Real
Sent: 19 July 2009 09:31
To: gobolinux-devel@lists.gobolinux.org
Subject: Re: [gobolinux-devel] Bootstrap issues
On Wed, Jul 15, 2009 at 6:23 PM, Rehan wrote:
> Hi,
Hi there,
>> I've been playing around with the Bootstrap v1.1 and come across some
>> issues, some of which I have 'fixed' and some not.
>>
>> I am initially trying to get it to do a native build just to get a
feel for
>> it. I'll run through the issues as I remember them.
>Ok. Bootstrap development happens mainly in Subversion. The release
>version isn't really indicated if you intend to generate a native
>build; it's been used almost exclusively for cross compiling packages
>to different architectures.
I'll give that a try.
>> 1) The cross-native.conf config file was missing from the svn Compile
>> version I am running. I found a copy of this file by taking pot shots
at
>> older svn versions so that seems to be fixed (but may be wrong)
>That file was removed from Compile because we don't really need it. It
>was more of a hack to rollback from Cross mode into Native mode again,
>but no applications should depend on it nowadays.
Ok. At the time I was working through error messages being displayed by
bootstrap and mitigating each one as it came up and it was looking for
cross-native.conf.
>> 2) Next was the function Get_System_Paths function in
>> /Programs/Scripts/Functions/GoboLinux. BootStrap was error-ing on
this but
>> continuing on. This was fixed by re-writing the function, as
suggested by
>> detsch on irc, to :
>>
>> Function Get_System_Paths () {
>>Parameters "$1" programpath
>>find "${programpath}" -mindepth 2 | while read path
>>do
>> Programs_To_System_Path "${path}"
>>done
>>
>> I'm not sure if this has implications for other scripts?
>At which point you noticed the Get_System_Paths error? Starting a new
>FS with the Subversion snapshot seems to be ok.
Again the 1.1 version was choking on the process substitution used in
that function (very early on, can't remember exactly, sorry ). The
documentation for process substitution says that it's not entirely
portable between shells so the above might be a better way to construct
that function for improved compatibility..
>> 4) There were a couple of errors in the package config.in files (IIRC
the BC
>> config.in and one other, I forget now) which was fixed by adding the
>> required first two lines deduced from looking at other packages
config.in's.
>Could you please provide patches for that against the SVN snapshot?
>> This got me to the point where there were no errors from bootstrap
and it
>> was doing things consistently the same way on each invocation. I am
at the
>> point where it now downloads the chroot environment (this was failing
I
>> guess due to 2 above) and attempts to chrootcompile the first
package. It
>> seems that this gets stuck somehow and then goes into an endless loop
of
>> trying and re-trying the chrootcompile. There aren't any useful error
>> messages that I can see, in fact chrootcompile seems to think it is
doing ok
>> and carries on.
>>
>> Anyone have any suggestions on how can I proceed from here?
>I'd like to suggest you to try the SVN version. Bootstrap was created
>with cross compiling in mind and only later I started to add support
>for a Native build. I created only one Native port (for a Mac PPC),
>bootstrapped from Ubuntu for that same hardware, so it's really likely
>that you will step on some eventual bugs.
>
> can launch a script to build a minimal Native system to see what
>happens, too. I'll do that and will keep an eye open to see how far it
>goes.
I'll certainly provide the patches when I try the svn version.
Unfortunately, I wiped that machine so I'll have to reconstruct the
scenario.
Actually, I am looking into Firmware Linux at the moment.
(http://impactlinux.com/fwl/) and trying to build gobolinux from that
(the goal being to create a base system that can be extended to be a
media player/router/voip box). I have a feeling that firmware linux and
gobolinux's bootstrap system/chrootcompiling might be a very good fit
with some hackage/modification as the approaches are divergent but
ultimately have the same goal. Particularly interesting is that with
firmware linux builds are 'native' all the time after the initial
environment is created and can
Re: [gobolinux-devel] Paper for linux.conf.au 2010
The Aliens idea is really interesting and I was not aware of it previously. I'm not sure how possible this is with Aliens (and the time available) but another example that might have a more wide ranging scope of interest for the audience could be Eclipse (Eclipse.org) as it incorporates it's own software installation system updating itself and it's own addons. I believe there is a recipe in the recipe database. Regards Rehan -Original Message- From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Michael Homer Sent: 19 July 2009 06:16 To: gobolinux-devel@lists.gobolinux.org Subject: Re: [gobolinux-devel] Paper for linux.conf.au 2010 On Friday 03 July 2009 05:24:55 Hisham wrote: > On Thu, Jul 2, 2009 at 4:51 AM, Michael Homer wrote: > > Hi all, > > Since linux.conf.au[1] falls on my doorstep next year I really don't have > > any excuse not to go, so I'm considering submitting a paper on GoboLinux. > > It'd be nice to drum up some exposure around here, and also to expand > > that "Academic Publications" section on the site. > > > > I've talked it over a little with Jonas already. I'm thinking the paper > > is best written as a collaboration, and then I will do the presentation > > in January. My concept at this point is a general overview of the system, > > how it works, and what it helps with, and I'd also like to cover > > /System/Aliens (which will hopefully be in a tools release by then) > > because it's just so very cool and unique. That could goose the odds of > > being accepted too. I'm open to other suggested content as well, but the > > presentation slot is only 45 minutes. > > > > The call for papers[2] closes 5pm July 24 my time[3]. We'd need to get > > together a title and abstract at least by then, though more always helps. > > Acceptances should come back some time in September, and the conference > > itself is 18-24 January next year. > > > > As well, anyone who's vaguely in the area and might be interested in > > making a trip I do encourage. The summer is great, and the conference > > ought to be interesting too. > > > > Let me know what you think. > > I think it's an excellent idea! > > A while ago I've talked to Lucas about trying to submit something > abroad (Freenix, perhaps) but we never got around to do it (first > because we were too involved doing actual work on Gobo, later because > we were too little involved, I guess...) but I think something like > this is a great way to get both exposure and some clear goals to the > project, as well (a number of GoboLinux releases were strongly > influenced by the FISL deadlines). Count on me to help any way I can. The abstract is due this coming Friday, though I intend to submit it a few days before. Here's a draft(-ish) for that, and also for the paper itself if it's accepted. It needs some cleaning up still. It will need a lot of fleshing out to be the paper, and a lot of trimming down to be the abstract (it's about twice as long as it should be for that now), but I'd like some feedback that, firstly, I'm on the right track in everything I describe there, and secondly on which parts you think should be kept or cut for the abstract. I've tried to include at least a mention of everything that would appear in the paper, but much of it is either too detailed for or probably doesn't belong at all in the abstract. So please do give that feedback. Include anything you think I've missed out too. There is a hacky proof-of-concept patch for LuaRocks integration in dependency resolution at http://mwh.geek.nz/files/gobo/aliens-poc.patch - against trunk, from a week ago but should still apply. Background GoboLinux is a distribution using an alternative filesystem hierarchy intended to provide a more logical layout for programs and data. Each program is installed into its own separate, versioned directory, which also represents the package database - "the filesystem is the package manager". An automatically-maintained tree of symbolic links keeps the program contents accessible without overhead, while another set of fixed links maintains compatibility with the standard FHS. This set-up has three major implications: firstly, that the origin of any file in the system can be found simply by reading the link to discover its location - which mkpasswd will give /Programs/Whois/4.7.33/bin/mkpasswd, revealing it to be a part of Whois and the version thereof. In fact, any package management operation can be performed using only the standard POSIX tools
[gobolinux-devel] BuildLiveCD problem
Hi I'm trying to build an updated 0.14 LiveCD. I'm following these instructions: http://www.gobolinux.org/index.php?page=livecd The UpdateEnvironment script is looking for files on gobo.calica.com which is throwing up 404 errors. Also the fetching remote packages stage fails with a connection refused. It also seems that it is setup for the 0.15 cd. Is there any way to backtrack to the 0.14 livecd? Cheers Rehan ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] Patch for Compile/bin/RecipeLint; Issue with zero-padded version numbers (Bash 4.1.002)
I wonder if it might be a better approach to parse the version for each recipe of a particular software package and internally pad up to the max digits found for each decimal position thus making the output correct. There are a number of packages of the format a.b.c where c is a number starting at 1 and rising into the teens. I have seen this a few times. This might also explain some of failures (which would be false positives as this is the numbering chosen by upstream which we can do little about). So some software that might start versioning at (for example) 2.4.1 rising to 2.4.15 would internally be represented as 2.4.01 and 2.4.15. This would correct the output of GetAvailable. > -Original Message- > From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel- > boun...@lists.gobolinux.org] On Behalf Of Baffo 32 > Sent: 22 April 2010 16:16 > To: gobolinux-devel@lists.gobolinux.org > Subject: [gobolinux-devel] Patch for Compile/bin/RecipeLint;Issue with > zero-padded version numbers (Bash 4.1.002) > > The recipe store currently contains two conflicting copies of Bash: > 4.1.002 (from me) and 4.1.2 (from Jonas Karlsson). 4.1.2 works fine, > but 4.1.002 will not compile due to extraneous patches. > > Unfortunately, GetRecipe (and hence Compile) will arbitrarily select > the broken recipe, if and only if no local recipe is found. It is > selected because the two are numerically equal and "GetAvailable > --type=recipe" lists 4.1.002 earlier in its output. > > The attached patch adds a check to RecipeLint to ensure a conflict > like this does not happen again, by rejecting version numbers with > prefixed zeros. There are currently 208 recipes in the store failing > this check. > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.730 / Virus Database: 271.1.1/2827 - Release Date: 04/21/10 > 19:31:00 ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
Re: [gobolinux-devel] UnionFS Implemented?
I have found that on a vanilla install of 014, updating Compile does not update the settings file which has the configuration for union filesystem (I believe I selected 'use new' but could be wrong). You can copy the latest settings from the /Programs/Compile directory to the compile settings directory (/System/Settings/Compile? I don't have a gobo install to hand, sry) overwriting the existing (and updating your user submission info) to fix the problem. IIRC the gobo kernel has (or had) the unionfs kernel patch so in the settings make sure UnionFS is the first in the list and 'it should just work'. Let me know if this works for you and I'll add some info to the afterboot wiki page. R From: gobolinux-devel-boun...@lists.gobolinux.org [mailto:gobolinux-devel-boun...@lists.gobolinux.org] On Behalf Of Eugene Yang Sent: 25 April 2010 21:30 To: gobolinux-devel@lists.gobolinux.org Subject: [gobolinux-devel] UnionFS Implemented? Just out of curiosity - is the UnionFS Sandbox actually implemented? With the latest update of Compile, it seems to check for the availability of unionfs when installing packages.. Will release 15 come with unionfs support? -- "Friends come and go but enemies accumulate." No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2850 - Release Date: 05/03/10 07:27:00 ___ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
