Re: [gobolinux-devel] USE flags & Xorg

[hisham . hm]

On 4/29/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> Hi,
> I know this has come up before, multiple times, and it never goes
> anywhere.

And here we go again! :) Just kidding. I'm fully convinced we need USE
flags or something equivalent (and have been for a while by now).

> I have a more specific proposal, though, and I think that
> implementing it would give genuine benefits, while making actual flags
> possible on the way.
>
> As Tom pointed out on -users a few days ago, performing an Xorg
> compile takes an age, and a huge amount of it is completely
> unnecessary: I don't have a Cirrus video card, so compiling
> XF86-Video-Cirrus is pretty pointless. I would like to have something
> like VIDEO_CARDS in Gentoo, that would enable compiling just the ones
> I have. That was the point of modular X, after all.

(Minor nit: I suspect it was more for developer convenience than user
convenience. The recent boost in X development seems to reflect this.
But I digress.)

> It would also obviate the need to recompile the entire thing for
> updates to only a small part of it. That would also require being able
> to tell which parts were already compiled and at what version, which
> probably means splitting the package out and installing them all into
> their own /Programs directory. I don't know whether there's a
> practical problem doing that (library searching?) or whether it's not
> done just to avoid cluttering /Programs with many XF86-* entries.
> There would be much less of a problem with clutter under this scheme,
> since most people would only have four or so of XF86-Video-* and
> XF86-Input-* installed, rather than all 68.

Yeah, I don't know how well Xorg works with its parts separated in
/Programs -- there might be path issues to fix. Maybe an intermediate
approach could be used; if my memory serves me well, we used to have
Xorg metas such as Xorg-Libs, Xorg-Apps, etc. Drivers could be kept
isolated but things like libs could be kept together to reduce clutter
on /Programs.

> All this would mean a change to the structure of meta-recipes, or
> possibly dropping Xorg as a meta-recipe altogether. The changes
> involved in making this happen would also allow for other sorts of
> conditional dependencies and similar, which is another benefit. The
> main practical and pragmatic reason for bringing this up right now
> though is X, and I think it is a tangible benefit. The flow-on effects
> are a bonus.
>
> It would be a fairly big change, and so it'd have to wait until at
> least the next release cycle, but it's something worth keeping in
> mind. The specifics of how to implement it I've deliberately left up
> in the air, but I do have a few ideas for how it could work. I'm
> interested in what comments other people have to make.

My main comment is to reiterate that USE flags are welcome. I have an
abstract sentiment that part of it could be automated with optional
dependencies (ie, "don't build the GTK+ interface if I don't have GTK+
installed") but I don't have a concrete image of how everything would
fit together implementation-wise.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] USE flags & Xorg

[hisham . hm]

On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 5/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Yeah, I don't know how well Xorg works with its parts separated in
> > /Programs -- there might be path issues to fix. Maybe an intermediate
> > approach could be used; if my memory serves me well, we used to have
> > Xorg metas such as Xorg-Libs, Xorg-Apps, etc. Drivers could be kept
> > isolated but things like libs could be kept together to reduce clutter
> > on /Programs.
> I have tried it with a few drivers - it seems to work ok. It's
> possible some of the core libraries need to go together, I guess, I
> didn't examine them. Joining the core and libraries together isn't
> such a bad idea all the same, although it will prevent updating single
> components on their own. I don't know how often that occurs, but it's
> not that uncommon for the drivers.

Good to know.

> > > All this would mean a change to the structure of meta-recipes, or
> > > possibly dropping Xorg as a meta-recipe altogether. The changes
> > > involved in making this happen would also allow for other sorts of
> > > conditional dependencies and similar, which is another benefit. The
> > > main practical and pragmatic reason for bringing this up right now
> > > though is X, and I think it is a tangible benefit. The flow-on effects
> > > are a bonus.
> > >
> > > It would be a fairly big change, and so it'd have to wait until at
> > > least the next release cycle, but it's something worth keeping in
> > > mind. The specifics of how to implement it I've deliberately left up
> > > in the air, but I do have a few ideas for how it could work. I'm
> > > interested in what comments other people have to make.
> >
> > My main comment is to reiterate that USE flags are welcome. I have an
> > abstract sentiment that part of it could be automated with optional
> > dependencies (ie, "don't build the GTK+ interface if I don't have GTK+
> > installed") but I don't have a concrete image of how everything would
> > fit together implementation-wise.
> That would be useful too - but it doesn't help for hardware-required
> programs (unless you examine /proc/config.gz really closely, and
> that's likely to be difficult to do flawlessly).

I didn't think about going this far; I agree it's probably not worth the effort.

> One component of my original idea was to have installed programs
> automatically become enabled flags, which would have that effect.

That's basically what I had in mind too.

> There would still need to be another, parallel system to deal with the
> other situations, and a way to disable the flags created this way. I
> don't know whether that would be more trouble than it's worth; it
> might be confusing to have behaviour changes because of an unrelated
> install.

Right.

> It might also be necessary to allow per-program flags (as in, "enable
> the GTK+ interface to Foo, but don't build the Qt one, even thought I
> have both installed"). I don't know how would be best to go about

A flag to compile overriding the system useflags? As in
Compile foobar --with gtk --without qt
where --with and --without are lists of useflags.

> that. Gentoo uses text files; we might prefer a filesystem-based
> approach. I would quite like to have some way to find out which
> programs were compiled with which flags, in both directions. That

The set of used flags at the time of compilation could be stored in a
Resources/ file.
But what do you mean by both directions?

> could be symlinks, I'm not sure whether it'd ever actually be useful
> to traverse a tree like that.
>
> Post-014 I would like to put some work into getting something like
> this up and running; the specifics of which method would be best I
> don't know. My original idea had dependency files like `Flag_On i810
> && require XF86-Video-i810 1.7.4`, and similar functions for adding
> configure parameters in the recipes, but I think that might get a
> little ugly for something complicated. It's probably necessary on the
> recipes' side, since things could get arbitrarily complicated there.

A number of proposed implementations floated around in the list over
the years (IIRC, one from Carlo, one from Andreas Koehler, and even
one mine if I'm not mistaken) and they were all variations on this
basic theme. Right now I think for Compile the cleanest would be to
have "sections" (actually shell functions) like this:

using_gtk() {
   add_flag configure_options "--with-gtk"
   something_else="foo"
}
not_using_ssl() {
   add_flag configure_options "--without-ssl"
}

We could have smart functions to cover common cases such as "when
using gtk, add --with-gtk, but remove it otherwise":

when_using_gtk configure_options "--with-gtk"

> I also don't know how this would interplay with binary packages. So

I think we should go the simple route there: for binary packages,
define a fixed set of use flags, and use them consistently in all
packages from the repository. If people want to tweak their syste

Re: [gobolinux-devel] USE flags & Xorg

[hisham . hm]

Wow, that was a huge email to reply, lot's of stuff going on, but I
gave my best. Here it goes:

On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> On Sat, 05 May 2007 01:40:48 +0200, Michael Homer
> > On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> >> On Fri, 04 May 2007 21:42:14 +0200, Hisham Muhammad
> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> >> >> On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> >> >> > > > My main comment is to reiterate that USE flags are welcome. I
> >> have an
> >> >> > > > abstract sentiment that part of it could be automated with
> >> optional
> >> >> > > > dependencies (ie, "don't build the GTK+ interface if I don't
> >> have GTK+
> >> >> > > > installed") but I don't have a concrete image of how
> >> everything would
> >> >> > > > fit together implementation-wise.
> >> >> > > That would be useful too - but it doesn't help for
> >> hardware-required
> >> >> > > programs (unless you examine /proc/config.gz really closely, and
> >> >> > > that's likely to be difficult to do flawlessly).
> >> >> >
> >> >> > I didn't think about going this far; I agree it's probably not
> >> worth the effort.
> >> >> >
> >> >> > > One component of my original idea was to have installed programs
> >> >> > > automatically become enabled flags, which would have that effect.
> >> >> >
> >> >> > That's basically what I had in mind too.
> >> >> >
> >> I can see the use of this, but I don't agree. This should not be flags,
> >> but automatic settings. If an application optionally depend on say
> >> gtk+ to
> >> be built with gui and I choose not to install it when Compile ask me,
> >> this
> >> setting should be passed to configure.
> >>
> >> Flags should be more generic and be of value to the user. For example a
> >> '--with-gtk' flag would automatically install gtk+ for me (if I didn't
> >> have it installed) in the example above. The gui setting for the
> >> application I want to install has little to do with flags. It's just a
> >> "symptom".

I didn't understand what you said, I think there was a mix up here.
What we meant by "flags" there were "use flags", as in "global
variables set somewhere that enable a 'flag' to be used by
Compile/dependencies", but not command-line flags as in '--with-gtk'.

> >> I don't think the problem lies in if I want to build with gui or not,
> >> but
> >> to me the issue is if I want to have gtk+ installed or not, hence the
> >> flag
> >> should be about that, not the configure options.
> > The flag would be "GTK", not "GUI", since one program could have
> > several different GUI options. So it would be basically like you
> > describe, I imagine.
> >
> Ok, but my main point was that controlling wether an application is built
> with or without GTK+ interface isn't what use flags should be used for.

I disagree. I'd like to, for example, be able to build Vim with or
without the GTK+ GUI using the same recipe; same for MPlayer...
without having, for each app, to get the app's configure script, check
its --help and figure out what flags I should pass to
--configure-options (not to mention not all uses of USE flags would
involve ./configure options only; some need to change makefile
targets, pass extra variables, etc.)

> There should be a mechanism like this, but it should only make decissions
> on what applications (dependencies) that are installed. Our "use" flags
> should only control which dependencies that should be isntalled
> automatically.
>
> > It would still be necessary to have a way of setting independent flags
> > to cover the original case I brought up: there's no "i810" or "Cyrus"
> > program to look for to see whether to compile support for the
> > appropriate video card.
> >
> Still automatic prosess - no "use" flags.
>
> >> >> > > There would still need to be another, parallel system to deal
> >> with the
> >> >> > > other situations, and a way to disable the flags created this
> >> way. I
> >> >> > > don't know whether that would be more trouble than it's worth; it
> >> >> > > might be confusing to have behaviour changes because of an
> >> unrelated
> >> >> > > install.
> >> >> >
> >> >> > Right.
> >> >> >
> >> Flags shouldn't be about configure options, therefore this isn't needed.
> >> In the example above, is it really important to be able to specify if I
> >> want to build with gui or not, if I already have gtk+ installed? And if
> >> we
> >> design this right, we don't have to use these micro controlling
> >> mechanisms.
> > I think it is, yes. Especially when there are multiple options.
>
> Are you trying to say that choosing wether GTK+ interface is built for an
> application, even if GTK+ is already installed, is important? Why?

Yes, because I don't want gmplayer or gaumix in my system, but I have
GTK+ for using Gimp.

> > Ideally as much of it as possible would happen by magic for the common
> > case, so you wouldn't actually have to do anything.
>

Re: [gobolinux-devel] What is the preferred location for Lua's modules?

[hisham . hm]

On 5/5/07, mpb <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm working on recipes for Lua and several of Lua's modules.
>
> There are two types of Lua modules:
> * modules written in Lua
> * modules written in C
>
> My question is, should modules be installed in the Lua-default locatons:
>
> $target/share/lua/5.1(for Lua modules)
> $target/lib/lua/5.1(for C modules)
>
> Or should Lua (and every module) be patched to install both types of
> modules in the 'lib' directory, as follows:
>
> $target/lib/lua/lmod/5.1(for Lua modules)
> $target/lib/lua/cmod/5.1(for C modules)
>
> Currently, Lua itself uses the patched locations, but the 2 Lua
> modules for which there are recipes use the Lua-default locations.
>
> So, my question is, which set of locations is preferred?  The default?
>  Or the patched?

The default. I thought the recipe for Lua had been fixed, actually.
(Also, the recipe should set LUA_PATH and LUA_CPATH accordingly.)

> My inclination is to go with the default, as that means less patching.
> As I am going to be adding recipes for additional Lua modules, I'd
> like to synchronize the locations that are used.

Please do so, that would be great.

Thanks,
-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] What is the preferred location for Lua's modules?

[hisham . hm]

On 5/6/07, mpb <[EMAIL PROTECTED]> wrote:
> On 5/6/07, Aitor Pérez Iturri <[EMAIL PROTECTED]> wrote:
>
> > Another question about modules, i add a module_name.lua to all my
> > recipes like this:
> >
> > +local
> >
> SOPATH="@%Compile_target%@/lib/lua/@%Compile_luaversion%@/@[EMAIL PROTECTED]"
> > +local OPENFUNC="[EMAIL PROTECTED]@"
> > +
> >  local function so(x)
> > -   local SOPATH= os.getenv"LUA_SOPATH" or "./"
> > -   assert(loadlib(SOPATH.."l"..x..".so","luaopen_"..x))()
> > +   local version=string.sub(_VERSION,5,5)..string.sub(_VERSION,7,7)
> > +   local loadlib
> > +   if version >= "51" then
> > +   loadlib=package.loadlib
> > +   end
> > +   return assert(loadlib(SOPATH,OPENFUNC))()
> >  end
> >
> > -so"posix"
> > +so()
> > +module("@%Compile_luamodule%@")
> >
> > Should we add the lua files? or let then without it?.

Better not add things like these, they may add support headaches later
on. Also, are you sure you're not breaking anything by not adding
package.seeall to the module() declaration?

> Are you using Lua 5.0 or 5.1?
>
> I believe that in Lua 5.1, modules do not require .lua wrappers - the
> .so files can be directly required.
>
> Do we want to support both Lua 5.1 and 5.0, or just 5.1?
>
> Supporting both may be more complex.

I think modules should be packaged for the Lua version they were
written for, with the version listed as dependencies (ie, "Lua >= 5.0,
< 5.1" for Lua 5.0 modules, "Lua >= 5.1" for Lua 5.1, "Lua >= 5.0" if
it works in both). Module authors usually document what versions of
Lua they support. For some (LuaSocket?) it's a compile-time option;
I'd say in those cases recipes should build for Lua 5.1.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] USE flags & Xorg

[hisham . hm]

Ok, I think we are converging:

On 5/6/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> On Sun, 06 May 2007 00:39:54 +0200, <[EMAIL PROTECTED]> wrote:
> > On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> >> On Sat, 05 May 2007 01:40:48 +0200, Michael Homer
> >> > On 5/5/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> >> >> On Fri, 04 May 2007 21:42:14 +0200, Hisham Muhammad
> >> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> >> >> >> On 5/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >> >> >> > On 5/3/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> >> >> I don't think the problem lies in if I want to build with gui or not,
> but
> >> >> to me the issue is if I want to have gtk+ installed or not, hence the
> flag
> >> >> should be about that, not the configure options.
> >> > The flag would be "GTK", not "GUI", since one program could have
> >> > several different GUI options. So it would be basically like you
> >> > describe, I imagine.
> >> >
> >> Ok, but my main point was that controlling wether an application is built
> >> with or without GTK+ interface isn't what use flags should be used for.
> >
> > I disagree. I'd like to, for example, be able to build Vim with or
> > without the GTK+ GUI using the same recipe; same for MPlayer...
> > without having, for each app, to get the app's configure script, check
> > its --help and figure out what flags I should pass to
> > --configure-options (not to mention not all uses of USE flags would
> > involve ./configure options only; some need to change makefile
> > targets, pass extra variables, etc.)
> >
> Ok, what I meant with per-application-basis I meant that I don't see the
> point (well I do see a point, but I think it's too complicated) to have
> specific use flags for each appliction. Then one would have to look up the
> use flags in the recipe, instead of, like in your example, check configure's
> --help output, so it will have the same level of complexity to me. Then I
> don't see the gain - instead of looking up configure options I have to look
> up use flags.
>
> You should still be able to change how an application is compiled by
> changing the use flags before compilation, like our (favourite) example set
> without_gtk to have mplayer build without gtk interface. {with,without}_gtk
> is too me a "good" use flag - it can be applied to every application that
> use that library. What I'm afraid of is that the use flags will be too
> application specific, like "without_gmplayer" and "without_gaumix" to
> disable those interfaces in those applications, intead of just
> "without_gtk".

Yes, we don't want flags to be too app-specific. "with_gtk" is good,
"without_gmplayer" is bad.

> >> >> Flags shouldn't be about configure options, therefore this isn't
> needed.
> >> >> In the example above, is it really important to be able to specify if
> I
> >> >> want to build with gui or not, if I already have gtk+ installed? And
> if we
> >> >> design this right, we don't have to use these micro controlling
> mechanisms.
> >> > I think it is, yes. Especially when there are multiple options.
> >>
> >> Are you trying to say that choosing wether GTK+ interface is built for an
> >> application, even if GTK+ is already installed, is important? Why?
> >
> > Yes, because I don't want gmplayer or gaumix in my system, but I have
> > GTK+ for using Gimp.
> >
> You have to explain this view to me as I can't really see the problem with
> having gmplayer, as well as the "normal" mplayer, present on a system at the
> same time. Does something break if gmplayer is installed as well, or is it
> just you that don't want it?

Often it's just because we don't want it, sometimes things break. The
binary for MC compiled with X11 support refuses to load on systems
where X11 is not installed.

> > We should build the GTK+ interface if the "gtk" use-flag is set in the
> > system or passed by the user to Compile as a one-off setting from the
> > command-line. This will add GTK+ as a dependency to the app (which
> > will cause it to install GTK+ if absent). Occasionally (for mplayer or
> > aumix) I may want to disable my global "gtk" setting from the
> > command-line.
> >
> My idea is to do it the other way around, build the GTK+ interface if GTK+
> is available and 'without_gtk' is unset, that is if we can build the
> interface and the user hasn't explicity turned it off we will build it.

In the end they're equivalent, assuming that installing GTK+ enables
the "gtk" flag by default.

> What I meant is that we can't create use flags for every possible
> permutation of all the configure options and all other variables we can set
> to make the recipe behave a special way. Instead we have to let the user
> have another way of configuring the application the way he/she wants.
>
> In my example I tried to show how an application could be configured with
> "global" use flags intead of application specific. I don't like the idea of
> having specific flags for one application,

Re: [gobolinux-devel] [gobolinux-commits] tools/BootScripts/Themes AppleII

[hisham . hm]

On 5/29/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 5/29/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 May 2007 21:52:12 +0200, Lucas C. Villa Real
> <[EMAIL PROTECTED]> wrote:
> >
> > > On 5/29/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> > >> CVSROOT:/sources/goboscripts
> > >> Module name:tools
> > >> Changes by: Jonas Karlsson 07/05/29 16:46:27
> > >>
> > >> Modified files:
> > >> BootScripts/Themes: AppleII
> > >>
> > >> Log message:
> > >> /dev/tty2 isn't available, using /dev/console instead
> > >
> > > I think the idea is exactly to redirect console output to somewhere
> > > else where the user doesn't see them.
> > >
> > Then why wasn't /dev/null used? Something in the script doesn't work with
> /dev/tty2, i.e. the bootprocess halts to a stop, with the error message that
> the filesystem is read-only.
>
> I don't know, that was only a wild guess. Hisham is probably the best
> person to answer this, as he's the theme author. Hisham?

This was written in pre-udev days, when either static dev or
devfs-mounted-before-init was used, so tty2 was available from the get
go. In udevlandia, that seems not to be the case, so that's why tty2
is missing. I used tty2 back then because I wanted the programs'
output to be available if needed but didn't want them to mess with the
"aesthetics" of the theme. This theme is more of a
novelty/proof-of-concept than an actual theme, so if people are having
trouble with it, I don't mind if it goes away.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/BootScripts/Themes AppleII

[hisham . hm]

On 5/30/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> On Wed, 30 May 2007 03:44:03 +0200, <[EMAIL PROTECTED]> wrote:
> > On 5/29/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> >> On 5/29/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> >> > On Tue, 29 May 2007 21:52:12 +0200, Lucas C. Villa Real
> >> <[EMAIL PROTECTED]> wrote:
> >> > > On 5/29/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> >> > >> /dev/tty2 isn't available, using /dev/console instead
> >> > > I think the idea is exactly to redirect console output to somewhere
> >> > > else where the user doesn't see them.
> >> > Then why wasn't /dev/null used? Something in the script doesn't work
> with
> >> /dev/tty2, i.e. the bootprocess halts to a stop, with the error message
> that
> >> the filesystem is read-only.
> >> I don't know, that was only a wild guess. Hisham is probably the best
> >> person to answer this, as he's the theme author. Hisham?
> > This was written in pre-udev days, when either static dev or
> > devfs-mounted-before-init was used, so tty2 was available from the get
> > go. In udevlandia, that seems not to be the case, so that's why tty2
> > is missing. I used tty2 back then because I wanted the programs'
> > output to be available if needed but didn't want them to mess with the
> > "aesthetics" of the theme. This theme is more of a
> > novelty/proof-of-concept than an actual theme, so if people are having
> > trouble with it, I don't mind if it goes away.
> >
> I think we should keep the theme, but to make it usable I made it use
> /dev/null,
> so the output can't be reached, but instead the theme is usable.

Cool, thanks. Now, if only we could make the system boot in 40x25... :)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] "Defragmenting" the LiveCD

[hisham . hm]

On 6/16/07, MLA-Gobo <[EMAIL PROTECTED]> wrote:
> I was wondering if the Gobo LiveCD is fully optimized; I remember being
> surprised at how slower it was than other LiveCDs I've tried. (I can't check
> it now, since I deleted the .iso file once I successfully installed it as a
> virtual image.) I came across openlog
> (http://fourmanoit.awardspace.info/?openlog), which makes the kernel log all
> successfully opened files, which can then be used to create a sort file for
> mksquashfs.

I don't have any evidence to support this, but the fact that we're
using several squashfs files may be the cause of the slowness --
accessing several squashfs files means the drive has to seek back and
forth on the disk to compose a directory out of several files.

> Any word on when 014RC2 is coming?

I don'
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] "Defragmenting" the LiveCD

[hisham . hm]

On 6/16/07, MLA-Gobo <[EMAIL PROTECTED]> wrote:
> I was wondering if the Gobo LiveCD is fully optimized; I remember being
> surprised at how slower it was than other LiveCDs I've tried. (I can't check
> it now, since I deleted the .iso file once I successfully installed it as a
> virtual image.) I came across openlog
> (http://fourmanoit.awardspace.info/?openlog), which makes the kernel log all
> successfully opened files, which can then be used to create a sort file for
> mksquashfs.

I don't have any evidence to support this, but the fact that we're
using several squashfs files may be the cause of the slowness --
accessing several squashfs files means the drive has to seek back and
forth on the disk to compose a directory out of several files.

> Any word on when 014RC2 is coming?

I don't know for sure, but I'd say within a few days. RC1 really
wasn't meant to be called "RC1", it was more a beta release, but RC2
will be hopefully something much more like a release candidate. There
are still things to tweak, from figuring out the default wallpaper
(the thread on that got a bit messy, with votes mixed with suggestions
on how voting should take place, etc) to possibly doing further tweaks
on the kernel (given Lucas' latest post on the important fixes applied
to UnionFS). WRT packages, however, I think Lucas is ready to ship.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] USE-flags vs. Flavored Dependencies

[hisham . hm]

On 7/1/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 7/2/07, mpb <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > There was talk back in May of adding USE-flag style functionality to
> > Compile:
> >
> > http://www.wotfun.com/pipermail/gobolinux-devel/2007-April/002570.html
> > http://www.wotfun.com/pipermail/gobolinux-devel/2007-May/002580.html
> 
> >
> > You might, for example, want to Compile against Optional-Installed
> > dependencies, but at the same time to Skip Optional-Absent
> > dependencies.
> Everything above this point sounds fine to me. It would be nice to
> have more general flags than just dependencies, I think, but I haven't
> come up with an example of why yet. I just have a niggling feeling
> that enabling "GTK" might do more than just compiling against GTK.
> Maybe more on that later if I can think of it.

If you think about "enabling GNOME" then I believe it gets easier to
conclude that it's more than just compiling against one or other
library. You'd probably want it to change dependencies and configure
(as in "settings files") things in different ways.

> What about cases where one flag affects another? Dependencies could be
> mutually-exclusive, in fairly complex ways, or one could require
> another, or one could require a disjunction of others (to enable
> feature X you need Sun-JRE OR Sun-JDK OR Blackdown-JRE OR ...).
>
> That brings something else to mind: Gentoo has "virtual" packages to
> cover cases where there are multiple implementations of the same
> thing: virtual/ghostscript, virtual/x11, virtual/jre, virtual/emacs,
> and others. Ebuilds are said to "provide virtual/ghostscript". That
> sort of solution would remove a lot of the complexity, but probably
> not all of it, and it might make a bit of a mess of /Programs.
> Although symlinks /Programs/JDK->/Programs/Sun-JDK might not be so
> bad.

I think the same. Probably something to be added as a next step
afterwards though (in other words, a good idea but not essential to
the core of things).

> I like the different levels of necessity. I am a little wary of how
> recommended/discouraged is going to be determined, but I doubt it
> would really be a problem. I also like the control there is at
> different levels of detail.

I am very wary about how this would be determined (thinking about
community/social/flamewar implications, rather than technical issues).
I'd rather avoid this can of worms and stick to something that can be
unequivocally determined, reducing the spectrum to "required",
"optional" and (the eventually phased-out) "unlabeled". Even then,
there is always the issue of app-specific flags and whether they will
be enabled or disabled by default (where being enabled by default
amounts to being "recommended" and disabled by default to being
"discouraged", I understand.) So, yes, to some degree it is an
unavoidable problem (unless you want to shy away and ask the user
everything). But its an unsolvable problem in the global sense, as
it's impossible to make _everyone_ happy with the chosen defaults, but
then that's why they're just "defaults" and not hardcoded behavior.
(All right, I'm just rambling, throwing ideas to the table. I haven't
made up my mind on this issue.)

> > 2) Dependency Flavors would not handle the case of Compiling only a
> > specific Xorg video driver.  I believe "USE-flags"/Flavors should be
> > used for cross-recipe configuration, not intra-recipe configuration.
> > I'm not opposed to intra-recipe configuration mechanisms, but I think
> > intra-recipe configuration is a separate (and much simpler) problem,
> > and should be solved separately and without cluttering up the global
> > "USE-flag" namespace.
> It is cross-recipe. The recipe "Xorg" depends on the recipe
> "XF86-Video-I810".

I think solving intra-recipe and cross-recipe issues with the same
mechanism would be better. Being pragmatic, I don't think cluttering
up the "USE-flag" namespace is that big of a deal. Two things should
help: one is avoiding to fall into the trap of trying to map every
available configure flag; another is to define some namespace rules
such as "if a flag is used in only one program, it must be prefixed by
the program name".

> > 3) In the case of PHP and other highly configurable and ever changing
> > Programs where users are likely to have exacting needs, I feel better
> > served by a simple recipe that allows me to pass args thru to
> > ./configure.  Gentoo's complicated (and often-masked) php .ebuilds
> > regularly frustrated me.  As a result, back in the days when I used
> > Gentoo I usually ended up compiling PHP by hand.  With GoboRootless, I
> > simply store store my PHP configure args in a Makefile that calls
> > Compile, which is a much nicer solution.
> I would still like to have the options be available where they exist
> anyway, even if they aren't actual dependencies. In the case of PHP,
> it bundles a lot of libraries that it uses internally, but the
> extensions can still be enabled or disabled (

Re: [gobolinux-devel] Tracking dependencies

[hisham . hm]

On 7/2/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote:
> Thanks, I was convinced this (link based) approach is perfect for
> gobo...but the lack of response was worrying me :) ...I will document
> the details on the wiki and send out a link...then if everyone is in
> agreement we can work out a plan of introducing it into gobo scripts.

I can surely be wrong, but my understanding of this proposal is that
it is, in essence, equivalent to what Jan Molič presented here:

http://lists.gobolinux.org/pipermail/gobolinux-users/2007-June/005906.html

except that links are grouped under /System/Links/Dependencies rather
than stored inside each /Programs entry as UsedBy. (Except of course
for technicalities such as naming and the use of ranges.)

My concerns about it are the same as the ones I presented here:

http://lists.gobolinux.org/pipermail/gobolinux-users/2007-June/005911.html

It has to do mainly with the order of installations. Following the
thread linked above, a conclusion was that perhaps global checking is
not that expensive, and has advantages such as avoiding duplication of
information and ensuring consistency. (But note the "perhaps").

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Tracking dependencies

[hisham . hm]

On 7/2/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote:
> Hisham,
>  Did you disagree with the alternate location for the Dependency files
> and Links as well as he has described?

My first impression was that his suggestions added to what you
proposed, combining the best aspects of your and Jan's proposal.

> In general, I'm pushing the links
> idea for dependencies for the simple reason(s) below:
>
> ...file system as package manager
> ...any decent package manager needs a way of tracking forward and
> reverse dependencies
> ...parsing through the text files which are distributed with the recipes
> is not *really* tracking dependencies...its calculating them everytime!
> ...not to mention that the elegance of broken links which currently show
> u what's wrong where...

>From what I understood in your proposal, one would see in a directory
a list of links pointing to programs that depended on a given lib.
This wouldn't show broken links for missing dependencies, or am I
missing something?

> although the Compile, Symlink, RemoveProgram scripts will need
> enhancement to support this...it'll essentially tell the user (and
> RemoveProgram) in a quick look, which library's old version is
> outdatedwhich is pretty hard to do right now
>
> --with the symbolic links its easy to view/browse the dependencies also
> using just the FS...
> however, the parsing scripts will make the solution more Gentoo like
> (magic script, working on files, dependencies inaccessible to user
> easily other than the script)... :(

I understand the conceptual motivations, but pragmatically I still
feel unconvinced. Perhaps you might want to try a prototype
implementation? Seeing things in practice can go a long way to get a
point across.

-- Hisham

> Hisham Muhammad wrote:
> > On 7/2/07, Andy Feldman <[EMAIL PROTECTED]> wrote:
> >
> >> I think this proposal is coming too close to "reimplementing a
> >> database in a filesystem." The point of using the filesystem should be
> >> to *avoid* having a special central construct just for tracking
> >> dependencies (or whatever). Ideally, there should just be one method
> >> of storing the dependencies for each program, and it should lend
> >> itself to whatever purpose we need it to serve.
> >>
> >> The /System/Links hierarchy is not a "central" database because it
> >> simply helps find the scattered files of the appropriate type
> >> efficiently. The structure itself doesn't add any additional
> >> semantics... all information is contained within the /Programs
> >> entries. In this proposal for dependencies, the information seems to
> >> be contained within the central structure. This means there are two
> >> pieces that need to be held in sync by the system scripts, rather than
> >> the folders in /S/L/* simply being collections of /Programs/*/*/*
> >> entries.
> >>
> >> >From a simplicity standpoint, I like Carlo's suggestion of a fancy
> >> grep over /Programs/*/*/Resources/Dependencies, with the possible
> >> optimization of linking the dependency files into /S/L/Dependencies
> >> and grepping that folder instead. However, the elegance and
> >> user-friendliness of checking what depends on each version of LibA by
> >> issuing `ls /System/Links/Dependecies/LibA/*` got me thinking about
> >> ways to get the advantages of that by leveraging existing concepts
> >> (and without adding significant complexity to the Scripts, which would
> >> make it harder to administer by hand).
> >>
> >> If each program's dependencies are stored as folders within its
> >> /Programs tree entry, they can be symlinked together in exactly the
> >> same way as the lib/ directories get symlinked together to form
> >> /S/L/L. Having zero-size files like this...
> >>
> >> /Programs/ProgramB/1.1/Resources/Dependencies/LibA/>=3.0/ProgramB--1.1
> >>
> >> ...and symlinking /P/*/*/Dependencies into /S/L/Dependenices generates
> >> the hierarchy Anshuman suggested without requiring any additional
> >> complexity in SymlinkProgram. This could potentially replace the
> >> Dependencies file, since it stores the same information in the same
> >> place but in a way that's much more convenient for reverse lookup and
> >> not much harder to create or change manually. (If the current
> >> Dependencies file is kept, the folder name would of course have to be
> >> different than 'Dependencies' to avoid the conflict.)
> >>
> >> Like Anshuman's original proposal, this avoids the "order of
> >> installation" problem by not putting files into other programs'
> >> /Programs entries, and it avoids the performance hit of system-wide
> >> dependency scan. In addition, assuming this is used instead of
> >> Dependency files, it avoid the unnecessary duplication of information
> >> that I didn't like about the earlier proposals. Even if the original
> >> flat dependency files are kept, duplicating that information within
> >> each /Programs/*/*/Resources directory seems cleaner and more
> >> maintainable than any standalone central inf

Re: [gobolinux-devel] USE-flags vs. Flavored Dependencies

[hisham . hm]

On 7/2/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I am very wary about how this would be determined (thinking about
> > community/social/flamewar implications, rather than technical issues).
> > I'd rather avoid this can of worms and stick to something that can be
> > unequivocally determined, reducing the spectrum to "required",
> > "optional" and (the eventually phased-out) "unlabeled". Even then,
> > there is always the issue of app-specific flags and whether they will
> > be enabled or disabled by default (where being enabled by default
> > amounts to being "recommended" and disabled by default to being
> > "discouraged", I understand.) So, yes, to some degree it is an
> > unavoidable problem (unless you want to shy away and ask the user
> > everything). But its an unsolvable problem in the global sense, as
> > it's impossible to make _everyone_ happy with the chosen defaults, but
> > then that's why they're just "defaults" and not hardcoded behavior.
> > (All right, I'm just rambling, throwing ideas to the table. I haven't
> > made up my mind on this issue.)
> That's the same wariness I have. But there are going to be things that
> default to on without being mandatory, so it's going to come up no
> matter what. What goes into the binary packages has much the same
> issue, and it hasn't been a problem, so it would probably be ok.
>
> However, after some thought I'm not sure how much "recommended" would
> be used, at least as I saw it. I was thinking of "it is recommended
> that you enable SSL support for security reasons" as an example. I'm
> less keen on "it is recommended that you enable GTK+".
>
> So it might be an area best avoided. The profiles idea Isaac suggested
> could help. I think that has many of the same problems, though, and
> the combining part looks a little confusing. If there are going to be
> different profiles anyway, as has come up from time to time, I think
> it'd be a good way to do them.

Agreed. It's an unavoidable problem (as choices have to be made at the
very least for binary packages) and I agree that Isaac's idea of
taking the decisions of what's recommended and what's not out of the
recipes and into profiles is a good one. (And I also found the
profiles part confusing :) )

> Wearing my Freshen hat for a moment, I'm actually not that fond of
> anything that requires prompting the user and isn't avoidable. So I
> would prefer that asking never happen, and that there be some way to
> determine if there's a conflict and just die right at the beginning.

What I'd love to have is a list of "stable versions" that Freshen
could download and use, listing versions for all recipes so that "for
the programs you have, if you have _these_ versions-revisions
installed, they'll all work". Maintaining that list, though, is the
trick for having a stable distro.

> > > > 2) Dependency Flavors would not handle the case of Compiling only a
> > > > specific Xorg video driver.  I believe "USE-flags"/Flavors should be
> > > > used for cross-recipe configuration, not intra-recipe configuration.
> > > > I'm not opposed to intra-recipe configuration mechanisms, but I think
> > > > intra-recipe configuration is a separate (and much simpler) problem,
> > > > and should be solved separately and without cluttering up the global
> > > > "USE-flag" namespace.
> > > It is cross-recipe. The recipe "Xorg" depends on the recipe
> > > "XF86-Video-I810".
> >
> > I think solving intra-recipe and cross-recipe issues with the same
> > mechanism would be better. Being pragmatic, I don't think cluttering
> > up the "USE-flag" namespace is that big of a deal. Two things should
> > help: one is avoiding to fall into the trap of trying to map every
> > available configure flag; another is to define some namespace rules
> > such as "if a flag is used in only one program, it must be prefixed by
> > the program name".
> I'd like to be careful about doing that, since it ties us down in case
> something new comes along later. We don't want our flag called
> "xorg-video-i810" only to find out later that Xine has direct support
> for the card too (not an artificial example, it really does). So
> prefixing should only be in the cases that are genuinely specific to
> one program, semantically.

I was thinking along the lines of expanding the namespace in an
as-needed basis. A flag could start as "xorg-video-i810" and then when
we realize we can use it on other package we'd add a "video-i810" flag
and make the old flag an alias to the new one.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Tracking dependencies

[hisham . hm]

On 7/4/07, Anshuman Aggarwal <[EMAIL PROTECTED]> wrote:
> Great idea, I'm going to put the prototype implementation together
> since the prototype might be just as involved as the logic needed in
> Compile,RemoveProgram...
>
> The solution which includes all ideas discussed below, will show broken
> links for missing dependencies as well ...
>
> I will start working off the latest Compile/RemoveProgram based
> scripts...Hisham, who is presently maintaining these so I should work
> with that person?

Now that we're nearing a release, there hasn't been much new
development on Compile and Scripts. All of us are applying bugfixes
but nobody currently has "main maintainer" status for them, where code
is concerned. Different parts of the implementation are mostly taken
care by their original authors though (for example, package/recipe
fetching by Detsch, actual compilation process by myself). Where
design is concerned however, I'm still taking care of things (recipes
API, tree structure) -- we always discuss things to reach a consensus,
but when one isn't reached I'm often the tie-breaker, to maintain a
certain consistency of vision and avoid the pitfalls of "design by
committee".

So, feel free to work on the scripts as you'd like; they should remain
stable. You can then post your proposed changes here on the list and
we'll have a go at them.

Happy hacking :)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham . hm]

On 7/15/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
>
> New versions of Happy and Alex require Cabal (The Haskell Cabal: Common
> Architecture for Building Applications and Libraries,
> ) instead of 'configure'-type build. (and I
> need those new versions in order to develop GHC HEAD)  More applications
> written in Haskell are likely to use this in the future.  That's not so
> bad if we can just make a new recipe type.

Yes, it would be good to have.

> Common Haskell libraries are being split up into separate pieces and
> less offered installed with newer releases of the GHC compiler.  We
> don't want to flood the /Programs namespace with all different little
> Haskell libraries; and each Cabal-based program-or-library declares
> which packages/modules/libraries it depends on, in a standard .cabal
> file.  We shouldn't try to manually keep intra-Haskell dependency
> listings in sync with these, either, as they are likely to change
> frequently.  Given how GHC normally works, it puts these in a system
> shared directory named by the GHC version (since e.g. GHC 6.6 and GHC
> 6.6.1 -generated binaries are incompatible with each other).  So if an
> installed /Programs/GHC/6.6.1/ is used, should the libraries be
> installed somewhere inside /Programs/GHC/6.6.1/ perhaps?  I'm thinking
> Perl modules may be a similar existing issue; are they handled well, and
> if so, how? (I'm afraid it may be that they are handled poorly, from
> what I am hearing recently with Pidgin Unmanaged files, HAL failing to
> Compile... but I don't know.  Any information is better than none.)

There have been problems in the past with the configuration of Perl,
but I think things are now mostly settled on how to put Perl modules
in the GoboLinux tree. Cabal has been mentioned here before, but a
practical problem was that it maintains a database file that needs to
be edited globally (ie, outside its own /Programs entry).

But having their own package management schemes this is a route that
all scripting languages are going for with their modules: Perl with
CPAN, Ruby with RubyGems, Python with Python Eggs, Lua with LuaRocks.
I'm CCing gobolinux-devel on this, as I think it's a worthwhile
discussion to see on which way we're going. It may be better to just
leave all those modules managed by their languages' managers, off the
main /Programs tree. I understand some people already do this for
RubyGems.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Status of 014?

[hisham . hm]

On 7/15/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> Also, some fixes were made to the installer, basically fixing
> internationalization support and GRUB's menu.lst generation. Hisham
> and Guilherme Bedin have fixed the Udev issues, but I don't know if
> they've managed to upload the new recipes -- Hisham?

I don't have access to the files right now (with Guilherme out of the
country) but the problem was that the syntax of the Udev settings
files are wrong in the recipe. _Some_ of the "=" signs should now be
changed to "==".

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Status of 014?

[hisham . hm]

On 7/15/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 7/15/07, MLA-Gobo <[EMAIL PROTECTED]> wrote:
> > It's been pretty quiet on the release front. I was just looking over
> the
> > past thread (toward the bottom of "Defragmenting the LiveCD", and noticed
> > that there seems to be some confusion over who is the release manager.
> Hisham
> > is presuming that Lucas is, but Carlo also said that he would be willing
> to
> > do so. Would the real release manager please stand up? :)
>
> Hehe, quite true. It should have be already finished, but the last
> weeks before moving from Brazil were were almost fulfilled with
> personal life stuff. I think it's fine to have Carlo doing the
> management of the next release(s), but as I've been working a lot in
> 014 I'm probably going to give him the title after 014 is out.

For the record, I think that's a good decision. Coming to think of it,
I think things will work better and more transparently if coordinated
by someone outside the original group of devs.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham . hm]

On 7/16/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 7/17/07, Carlo Calica <[EMAIL PROTECTED]> wrote:
> > On 7/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > There have been problems in the past with the configuration of Perl,
> > > but I think things are now mostly settled on how to put Perl modules
> > > in the GoboLinux tree. Cabal has been mentioned here before, but a
> > > practical problem was that it maintains a database file that needs to
> > > be edited globally (ie, outside its own /Programs entry).
> > >
> > > But having their own package management schemes this is a route that
> > > all scripting languages are going for with their modules: Perl with
> > > CPAN, Ruby with RubyGems, Python with Python Eggs, Lua with LuaRocks.
> > > I'm CCing gobolinux-devel on this, as I think it's a worthwhile
> > > discussion to see on which way we're going. It may be better to just
> > > leave all those modules managed by their languages' managers, off the
> > > main /Programs tree. I understand some people already do this for
> > > RubyGems.
> > >
> >
> > I definitely agree that using the language module manager is the way
> > to go.  Installing into the main /Programs tree (ie /Programs/Ruby)
> > has the big negative of losing modules when you upgrade the language.
> > Workaround is installing in a 3rd location (/Files/RubyGems) but that
> > requires extra configuration and some modules may not be
> > relocatable(hopefully rare).
> So long as they don't install into /P/Ruby, I think it'd be ok, but I
> would really like not to do an end-run around the dependencies system
> if we can help it. If something depends on (say) Ruby-GTK, we want to
> be able to list that and make sure it's fulfilled when it's installed.

Theoretically, the language managers would take care of dependencies
in their world. I know that LuaRocks does, at least. :-)

> Maybe create new recipe types that wrap the individual package
> managers? type=rubygem, type=cpan, type=pear, etc? That would mean you
> couldn't just use `gem install ...`, though.

This is sort of what we do now with Perl at least, don't we? It
doesn't actually uses CPAN as a service, but recipe_type=perl assumes
the CPAN structure.

> Alternatively, how about wrappers around the package managers
> themselves? `gem install ...` would pass off to the regular installer
> and intercept install/uninstall to create /Programs directories.

Sounds like a lot of work, and having to replicate the languages'
module trees in our recipe tree, including their dependencies info,
feels like unnecessary work, if we can make RubyGems, LuaRocks, etc.,
take care of their own little worlds.

> I really don't like the idea of having to juggle multiple package
> managers when there could be interdependencies between them all.

I see. But coercing RubyGems, Haskell Cabal, etc., to fit into our
/Programs tree wouldn't help a lot. Removing a gem with "rm -rf" would
drive the rubygems db crazy. They would be like
"/Programs-entries-but-not-really".

A very vague thought: maybe what we need is a way to "talk" to other
package managers, to have a bridge between our management/dependency
system, and theirs. Perhaps implemented as a plugin-like system.
Thinking out loud:

If a dependency in the Dependencies file is named something like:
RubyGems-rubyqt then it means it will be handled by the RubyGems
plugin. The plugin script will respond to some minimal set of
operations such as "is_installed", "install", "remove". Plugins would
be written for those external managers. There wouldn't be recipes for
each gem, or for each rock. A dependency like "LuaRocks-luasocket >=
2.0" would just call the LuaRocks plugin and the plugin would
query/install LuaSocket using LuaRocks. We would need standard
locations for these separate trees; I'm at a blank wrt this
(/Files/LuaRocks/ would be the cowardly escape). A directory for ROX
appdirs could fit into this scheme as well. Again, it is all still
very vague in my head.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] KDE/QT related compiles failing

[hisham . hm]

On 7/16/07, Carlo Calica <[EMAIL PROTECTED]> wrote:
> On 7/16/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> > On 7/16/07, Carlo Calica <[EMAIL PROTECTED]> wrote:
> > >
> > > Do you mean from "make install" or PostInstall?  I would argue that
> > > "make install" shouldn't alter passwd/shadow/group.  The makefile
> > > should be patched and PostInstall used instead.
> >
> > Either will fail with chroot compile. Our PostInstall script needs
> > adjustments badly -- one cannot write outside $target from inside
> > PostInstall. Jonas had some suggestions on how to allow that in a
> > similar fashion that's used to allow unmanaged files to be touched,
> > but that would bring some more script files.
> >
> > In my opinion, PostInstall could be swept away.. I don't remember
> > having seen any package or recipe using it (just in case there is
> > some, its Resources/FileHash is probably getting broken after the
> > script is run...)
>
> Isn't OpenSSH using it to generate keys?  Running PostInstall outside
> the sandbox might be ok.  The sandbox was a neat idea but I don't know
> if its actually helpful.  Allowing the package to define the holes in
> the sandbox effectively removes the sandbox.  Unmanaged_files makes
> sense for recipes because we're fighting upstreams "make install" but
> PostInstall is entirely ours.
>
> In order to keep R/FileHash clean, PostInstall should only modify
> Settings.  If we remove the sandbox, anywhere but $target.

Or rather, anywhere but any /Programs///.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Bug? Compile GCC-Java Depends on bash/zsh/...?

[hisham . hm]

On 7/16/07, MJ Ray <[EMAIL PROTECTED]> wrote:
> I just tried to Compile GCC-Java from my rc shell and it failed with
> an error like "export: not found" (apologies for not recording the
> exact error).  Rebuilding from bash seems to cure it.
>
> Is there any way to note a Compile dependency like that?
> Should the recipe be changed to force a Bourne-like shell?

I'm wondering here if the implicit Bourne-dependency happened in the
recipe, in gcj or in Compile. Is the 'export' written somewhere in the
recipe, its resource files, patches?

If it's in gcj, I think you may be able to do the following in the recipe:

environment=(
   SHELL=/bin/sh
)

If it's in Compile, then it's a Compile bug and we should make it
explicit, I guess.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] Call for volunteers: would you like to be a recipe committer?

[hisham . hm]

On 7/17/07, MJ Ray <[EMAIL PROTECTED]> wrote:
> "Hisham Muhammad" <[EMAIL PROTECTED]> wrote:
> > It's been a while now that GoboLinux recipes are being maintained in a
> > Subversion server instead of being just a directory in a web server
> > where someone (Lucas for the last few years) uploaded tarballs to.
>
> I don't do Subversion (I can only remember how to drive three or four
> version control systems before I start making big mistakes and if I
> make mistakes on a shared project like gobolinux, that will get
> messy), so is there a CVS, git or other automated gateway to it, please?

You don't need to use Subversion explicitly. Our PutRecipe script
handles the whole process of committing to trunk, incrementing recipe
revision numbers and committing a revision. Here's more info:
http://gobo.kundor.org/wiki/How_to_commit_recipes

Right now it requires one to download the entire svn tree the first
time (PutRecipe does that automatically too) which is a bit annoying
(read: slow), but I hope we can fix that now that the actual
generation of the recipe-store dir is done at the server.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham . hm]

On 7/17/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > A very vague thought: maybe what we need is a way to "talk" to other
> > package managers, to have a bridge between our management/dependency
> > system, and theirs. Perhaps implemented as a plugin-like system.
> > Thinking out loud:
> >
> > If a dependency in the Dependencies file is named something like:
> > RubyGems-rubyqt then it means it will be handled by the RubyGems
> > plugin. The plugin script will respond to some minimal set of
> > operations such as "is_installed", "install", "remove". Plugins would
> > be written for those external managers. There wouldn't be recipes for
> > each gem, or for each rock. A dependency like "LuaRocks-luasocket >=
> > 2.0" would just call the LuaRocks plugin and the plugin would
> > query/install LuaSocket using LuaRocks. We would need standard
> > locations for these separate trees; I'm at a blank wrt this
> > (/Files/LuaRocks/ would be the cowardly escape). A directory for ROX
> > appdirs could fit into this scheme as well. Again, it is all still
> > very vague in my head.
> That works for me. I like it a lot, in fact. It's flexible and it's

Yeah, I feel quite good about it too (and I loved Carlo's suggestion
of /System/Aliens/ :) ).

> integrated with the rest of the system. Would it create /Programs
> directories for each one? I'm assuming no, since `gem install ...`
> could install more than one gem, and catching that would be hard.

No, it wouldn't.

> It wouldn't make Freshen's life too hard either. It would mean that it
> couldn't do a full system update, unless there were some way to get a
> list of all installed and available gems/rocks/modules (which I think
> might be a bit of a stretch). I think that's probably an acceptable
> trade-off.

Obtaining a list of all installed modules doesn't sound hard, I think
all managers provide a direct way to get this, but a list of available
versions may be more problematic, and the interactions between the two
worlds could be hard to work out. If Freshen limits itself to keep the
/Programs tree updated and talk to the alien dependency system to make
sure that they're providing any alien depenencies required by programs
in /Programs, that would already be great.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham . hm]

On 7/17/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On 7/17/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> >> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> A very vague thought: maybe what we need is a way to "talk" to other
> >>> package managers, to have a bridge between our management/dependency
> >>> system, and theirs. Perhaps implemented as a plugin-like system.
> >>> Thinking out loud:
> >>>
> >>> If a dependency in the Dependencies file is named something like:
> >>> RubyGems-rubyqt then it means it will be handled by the RubyGems
> >>> plugin. The plugin script will respond to some minimal set of
> >>> operations such as "is_installed", "install", "remove". Plugins would
> >>> be written for those external managers. There wouldn't be recipes for
> >>> each gem, or for each rock. A dependency like "LuaRocks-luasocket >=
> >>> 2.0" would just call the LuaRocks plugin and the plugin would
> >>> query/install LuaSocket using LuaRocks. We would need standard
> >>> locations for these separate trees; I'm at a blank wrt this
> >>> (/Files/LuaRocks/ would be the cowardly escape). A directory for ROX
> >>> appdirs could fit into this scheme as well. Again, it is all still
> >>> very vague in my head.
> >> That works for me. I like it a lot, in fact. It's flexible and it's
> >
> > Yeah, I feel quite good about it too (and I loved Carlo's suggestion
> > of /System/Aliens/ :) ).
>
> I don't want to lose versioning for them totally. (inventing things)
> Suppose we have /System/Aliens/LuaRocks and I want to try out some new
> "LuaRocks 2.0" reimplementation.  Or suppose I want to maintain multiple
> sets of debian packages for different debian versions.  Hmm, these
> aren't very compelling examples - maybe it's not necessary.

I understand the need. LuaRocks in particular does versioning by
default -- the recommended path for a home-based repository for
example, is ~/.luarocks/5.1/. There was just too much suffering in the
transition from Lua 5.0 to Lua 5.1; lesson learned. So it would
naturally become /System/Aliens/LuaRocks/5.1/. Versioning could be
used on an as-needed basis, without having to put versions on things
that don't have or need (I believe RubyGems work with multiple
versions of Ruby; If a totally new gems tree appeared, it could be
installed as /System/Aliens/RubyGems-2/ in the future, but that's
unlikely, so no reason to add /System/Aliens/RubyGems/1/ now just
because.)

> I guess we
> would want to make each subsystem as a whole 'rm -rf'-able anyway,
> deleting all the packages it contained as well as any centralized
> database of them required by the system.
>
> The naming scheme... "RubyGems-rubyqt" would look like any other program
> name, should there be some more distinctive punctuation like
> "RubyGems:rubyqt" (... _is_ that more distinctive?)?  Also I think we

The colon looks good, analog to an URL protocol.

Michael wrote:
> Isaac wrote:
> > The naming scheme... "RubyGems-rubyqt" would look like any other program
> > name, should there be some more distinctive punctuation like
> > "RubyGems:rubyqt" (... _is_ that more distinctive?)?  Also I think we
> > will have to provide partial dependency files when a system package is
> > required (e.g. I'm assuming rubyqt requires some version of Qt to be
> > installed), since the ruby "gems" system can't know what we call our
> > _packages_ even if it knows it requires a file like /usr/include/qt.h
> > (or a .so file, etc.).
> That's a very good question.

Yeah, you brought a very important point.

> How is that going to work? Catching it
> for "gem install rubyqt" probably won't be possible, but something
> depending on RubyGems:rubyqt (I like that syntax, too) shouldn't fail
> to compile. We could just list Qt in the dependencies of everything
> requiring the Ruby bindings, but that's a little messy and seems like
> unnecessary duplication.
>
> It would also introduce the need to order dependencies for non-meta
> recipes which I don't like so much from the perspective of trying to
> resolve a valid order amongst many programs. [Explanatory sidebar: I
> don't want to have to make Freshen order things as they're listed in
> the recipe Dependencies, because most of the time it doesn't matter
> and is arbitrary (alphabetical). If order matters, resolving among
> multiple programs becomes impossible when one orders Qt before another
> package and another puts it after, creating a loop. There's no real
> way to decide which one should be followed.]
>
> Maybe a compatibility layer? A file of the format "RubyGems:rubyqt Qt
> >=3.0, <=4.0" that will make Compile do the right thing? I don't
> really like that solution, since we can't possibly keep up with every
> package in every packaging system.

Sounds like an acceptable compromise. We can't keep up with every
package in every packaging system, but we could keep up with the alien
packages that are referenced in GoboLinux recipes.

If the user installs r

Re: [gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham . hm]

On 7/17/07, Luis Lavena <[EMAIL PROTECTED]> wrote:
> On 7/17/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > > On 7/17/07, Michael Homer <[EMAIL PROTECTED]> wrote:
> > >> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >>> A very vague thought: maybe what we need is a way to "talk" to other
> > >>> package managers, to have a bridge between our management/dependency
> > >>> system, and theirs. Perhaps implemented as a plugin-like system.
> > >>> Thinking out loud:
> > >>>
> > >>> If a dependency in the Dependencies file is named something like:
> > >>> RubyGems-rubyqt then it means it will be handled by the RubyGems
> > >>> plugin. The plugin script will respond to some minimal set of
> > >>> operations such as "is_installed", "install", "remove". Plugins would
> > >>> be written for those external managers. There wouldn't be recipes for
> > >>> each gem, or for each rock. A dependency like "LuaRocks-luasocket >=
> > >>> 2.0" would just call the LuaRocks plugin and the plugin would
> > >>> query/install LuaSocket using LuaRocks. We would need standard
> > >>> locations for these separate trees; I'm at a blank wrt this
> > >>> (/Files/LuaRocks/ would be the cowardly escape). A directory for ROX
> > >>> appdirs could fit into this scheme as well. Again, it is all still
> > >>> very vague in my head.
> > >> That works for me. I like it a lot, in fact. It's flexible and it's
> > >
> > > Yeah, I feel quite good about it too (and I loved Carlo's suggestion
> > > of /System/Aliens/ :) ).
> >
> > I don't want to lose versioning for them totally. (inventing things)
> > Suppose we have /System/Aliens/LuaRocks and I want to try out some new
> > "LuaRocks 2.0" reimplementation.  Or suppose I want to maintain multiple
> > sets of debian packages for different debian versions.  Hmm, these
> > aren't very compelling examples - maybe it's not necessary.  I guess we
> > would want to make each subsystem as a whole 'rm -rf'-able anyway,
> > deleting all the packages it contained as well as any centralized
> > database of them required by the system.
> >
> > The naming scheme... "RubyGems-rubyqt" would look like any other program
> > name, should there be some more distinctive punctuation like
> > "RubyGems:rubyqt" (... _is_ that more distinctive?)?  Also I think we
> > will have to provide partial dependency files when a system package is
> > required (e.g. I'm assuming rubyqt requires some version of Qt to be
> > installed), since the ruby "gems" system can't know what we call our
> > _packages_ even if it knows it requires a file like /usr/include/qt.h
> > (or a .so file, etc.).
> >
> >
>
> I'm coming late to this thread, but what we are talking about is
> repackage another packager (rubygems)... something like Debian, which
> makes life too difficult to everyone, even maintainers.
>
> Will be simpler if you check the documentation of a gem, and see the
> requirements there (eg. readme).
>
> Repackage gems as "programs" of Gobo raises other issues, like loading
> path for Rubygems (the require overwrite)...
>
> I'll prefer stay simple instead. Like I commented a few months back,
> set Rubygems to install gems globally (Env GEM_PATH to /Files/Gems or
> something)
>
> if not, we will fall in the maintenance hell that debian packages suffer.
>
> Just my 2 cents :)

Yes, the whole project of alien packages is to avoid that problem. We
don't want to repackage stuff; we're designing a protocol of sorts to
make the two managers talk. The plan is to set GEM_PATH to
/System/Aliens/RubyGems and to make some scripts that will provide a
bridge allowing GoboLinux recipes to request gems to be installed via
rubygems when they're dependencies to a application.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] minor Scripts issues

[hisham . hm]

On 7/20/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 7/18/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> > Bad things I noticed while reading through some gobo scripts :)  (the
> > versions from CVS.) I could make patches for these (probably). (of
> > course I might be mistaken about some of them, so I just send this :)
> >
> > DevelScripts/bin/PutRecipe
> > It sets compile_version to 1.8.2 even if a _later_ version was specified
> > in the recipe! I don't know how to scriptedly compare version strings
> > that look like this, though...
>
> Ah, that's my fault. The idea was to always keep that version up to
> date with Compile releases, but sometimes I just forget about doing
> that. Please feel free to update it to the last one or, if you have a
> better suggestion on how to keep that synchronized, just let me know.

No, it shouldn't force the latest Compile version every time there!
Ideally this should contain the lowest version of Compile needed for a
recipe to work. Since it's impractical to verify that number, the
number used by the recipe author is the "lowest verified number" and
must be respected.

I see you've been tweaking recipes in PutRecipe to change their
syntax, but that shouldn't be necessary anymore (all recipes in the
store use the new format, and even then your tweaks of compile_version
should use the lowest possible number and never clobber the recipe's
number if it's higher).

> > Bypass_Superuser should very probably use "$@", not $*.
>
> Did you run into some problem with $*?

This kind of change should be triple-checked for correctness. It's
dangerous to apply the "$@" rule of thumb in every case. Unless you
run into a real problem, don't change it. I don't remember exactly
where, but there are locations in Scripts where $* is really the right
pattern to use.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/DevelScripts/bin UpdateLocalStore

[hisham . hm]

On 7/25/07, André Detsch <[EMAIL PROTECTED]> wrote:
> > +echo `date` Finished >> ~/cronlog.txt
>
> Was this trace code intentionally left in the code?

Yes, it's a simple diagnostics tool for quickly logging into
gobolinux.org and seeing if the job is running as it should.

Thanks for the code review. :)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/Scripts/src List.c Makefile

[hisham . hm]

On 7/26/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 7/24/07, Hisham Muhammad <[EMAIL PROTECTED]> wrote:
> > +   echo $(shell uname -m)
> > +   echo $(STATIC)
>
> Can I remove this, or do you pretend to keep the echoes for some other
> reason?

Ouch, sure, sorry. Guess that's what happens when I break my personal
rule of "no commits after 3am" :)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/DevelScripts/bin ImportRecipe PublishRevi...

[hisham . hm]

On 7/25/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 7/25/07, Hisham Muhammad <[EMAIL PROTECTED]> wrote:
> > CVSROOT:/sources/goboscripts
> > Module name:tools
> > Changes by: Hisham Muhammad 07/07/25 09:30:19
> >
> > Modified files:
> > DevelScripts/bin: ImportRecipe PublishRevision
> >
> > Log message:
> > Don't download the entire trunk and revisions tree!
>
> I was going to ask you yesterday, but I forgot: what do you think
> about creating tarballs from the svn tree and just download/uncompress
> it instead? The tarball creation could be put together with the cron
> job.
>
> Sorry for suggesting this after your modification to the scripts :)

That would improve it relative to how it was before, but the way I did
it now transfers way less data, as only the relevant subset of the
tree is ever used (I actually committed recipes from dialup!). The
only drawback is that it doesn't check for recipe capitalization
errors anymore, but I think this could be done using FindPackage.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] future plans

[hisham . hm]

On 7/30/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 7/29/07, mpb <[EMAIL PROTECTED]> wrote:
> > So write a "UseProgram" tool to manage PATH for you.
> >
> > >  * It uses the binary path directly, whereas GoboLinux seems to be
> promoting
> > > the notion of the Program as a whole, which is a good idea in my
> opinion.
> > > If possible, the average user shouldn't need to know too much about the
> > > inside of a Program (meaning program directory) in order to add it to
> the
> > > path.
> >
> > "UseProgram GCC 4.1.2" versus "MountProgram GCC 4.1.2".
> >
> > Both are just as easy to remember and use.  "UseProgram" saves you the
> > bother of having to mess with chroots.
>
> Also, that should involve the evaluation Resources/Environment, as
> well as LD_LIBRARY_PATH. The interesting thing about MountProgram,
> though, is that one could specify a wide range of programs so that a
> completely isolated environment could be created, composed *only* by
> the desired applications -- that's not possible with an approach based
> on UseProgram.

This is exactly the same as setting up a ChrootCompile environment and
running a shell inside it instead of Compile.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/DevelScripts/bin UpdateLocalStore

[hisham . hm]

On 7/31/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> 2007/7/25, Hisham Muhammad <[EMAIL PROTECTED]>:
> > --- UpdateLocalStore25 Jul 2007 08:28:52 -  1.3
> > +++ UpdateLocalStore25 Jul 2007 09:27:05 -  1.4
> > @@ -1,4 +1,5 @@
> >  #!/bin/sh
> > +export HOME=/home/gobolinux
> >
> >  ### Imports
> ###
> >
> > @@ -22,33 +22,40 @@
> >
> >
> ###
> >
> > +remove_slash() {
> > +   sed 's,/$,,'
> > +}
> > +
> > +compileLocalRepoRevisions="file:///home/gobolinux/svn/recipes/revisions"
> > +
> >  mkdir -p $compileLocalStore
> >
> These references to /home/gobolinux, is it forgotten code?

No, it's really hardcoded to the gobolinux.org server. This script in
its current incarnation is designed to be used there only. BTW, this
reminds me I need to sync CVS with the version running there; I fixed
the last missing quirks to make the store auto-update from svn.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] tools/Compile/bin PackRecipe

[hisham . hm]

On 7/31/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> 2007/7/31, Jonas Karlsson <[EMAIL PROTECTED]>:
> > On Tue, 31 Jul 2007 07:01:51 +0200, Lucas C. Villa Real
> <[EMAIL PROTECTED]> wrote:
> >
> > > CVSROOT:  /sources/goboscripts
> > > Module name:  tools
> > > Changes by:   Lucas C. Villa Real07/07/31 05:01:51
> > >
> > > Modified files:
> > >   Compile/bin: PackRecipe
> > >
> > > Log message:
> > >   Stay backwards compatible with other versions of xargs.
> > >
> > > CVSWeb URLs:
> > >
> http://cvs.savannah.gnu.org/viewcvs/tools/Compile/bin/PackRecipe?cvsroot=goboscripts&r1=1.7&r2=1.8
> > >
> > [...]
> > >#remove backups
> > > -  find "$name/$version" | grep -E '~$' | xargs -i rm -f {}
> > > +  find "$name/$version" | grep -E '~$' | xargs rm -f {}
> >
> > I don't know for other versions but xargs from GNU find-utils need
> '-i/--replace' to
> > replace {} with the content from stdin. After the change this will be
> equivilent to
> > 'xargs rm -f', i.e. without argument. That wouldn't work.
> >
> My bad. I was confused by the {} were kept. Afaik those could be
> removed as well.

No, you're right. The {} must be removed as well. Committed.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] recipe svn permission errors?

[hisham . hm]

On 8/12/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> sometime...yesterday? when trying to use PutRecipe I started getting all
> errors like
>
> svn: PROPFIND request failed on '/recipes/revisions'
> svn: PROPFIND of '/recipes/revisions': 403 Forbidden
> (http://svn.gobolinux.org)
>
> from svn. This appears to mean I can't commit recipes currently. Anyone
> know why?

No clue. AFAIK no configurations were changed on the server side. So
it was working before and just stopped working? Weird.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] wiki spam

[hisham . hm]

Hi,

Just to add another minor data point to the discussion, looking at the
wiki users list it seems to me that there's a lot of random-looking
accounts there that look spambot-generated.

http://gobo.kundor.org/wiki/Special:Listusers

-- Hisham

On 8/13/07, MJ Ray <[EMAIL PROTECTED]> wrote:
> "Nick Matteo" <[EMAIL PROTECTED]> wrote:
> > On 8/12/07, MLA-Gobo <[EMAIL PROTECTED]> wrote:
> > > Having just edited several pages with spam, it seems as though every
> one
> > > is just a massive collection of links. That seems pretty easy to test
> for.
> >
> > There is already a system in place to block edits containing specified
> > regular expressions.  I am adding some more to it, but am not sure
> > about blocking external links entirely.  Suggestions for more regexes
> > would be welcome.
>
> What sort of regexes are they?  Can we block edits adding more than a
> number of links at one time, say 5?  In perl, I think that's
> (http://.*){6,} - If we can combine this with a sleep(20) in the save
> routine, that would make it slower for spammers, which makes their
> spamming less worthwhile.
>
> Some other wiki spam-defeaters are listed at
> http://www.hants.lug.org.uk/cgi-bin/wiki.pl?AntiSpam
>
> Hope that helps,
> --
> MJ Ray - see/vidu http://mjr.towers.org.uk/email.html
> Experienced webmaster-developers for hire http://www.ttllp.co.uk/
> Also: statistician, sysadmin, online shop builder, workers co-op.
> Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
> ___
> 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

Re: [gobolinux-devel] default Settings files that need certain permissions

[hisham . hm]

On 8/13/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> (as far as I know this is a problem with all our Sudo recipes and I
> haven't found a way to fix it in the recipe)
>
> "sudoers" normally must be mode 0440 as well as user 0:group 0.  In the
> recipe, Resources/Defaults/Settings/sudoers appears with mode 0440,
> which is wrong because it means it can't be normally edited _while_ in
> the recipe, and which _also_ (with Scripts 1.8.5) doesn't affect the
> mode of the installed Resources/Defaults/Settings/sudoers nor
> /Programs/Sudo/Settings/sudoers.  I don't know what mode I think the
> installed Resources/Defaults/Settings/sudoers should be (non-sensitive
> 644 or sensitive, 440  - depends if it can/should be customized locally).

The copy in Defaults should never be edited, so I think it should stay
with the stricter permissions.

> However UpdateSettings (I think that's the relevant script) needs a way
> to know what permissions to give to the installed settings-file.  Is
> there a way already, that I haven't discovered? Something in the Recipe
> file?  Or do we need to add such a mechanism somehow?

I don't know if UpdateSettings honors the permissions in the Default
copies. I believe it should. Then it's a matter of keeping things with
the right permissions under Defaults.

> (Are there _any_
> other Settings files than sudoers, that need particular permissions? I
> recall on non-Gobo linuxes, seeing various other non-world-readable
> files and directories in /etc. Looking in Gobo, "shadow-" is mode 600,
> but the rest of "shadow", "passwd-", ... are world-readable; not sure
> what mode they're supposed to be.)

I'm far from being an expert in these matters, all help on this is
welcome. We should figure out what the correct permissions are and
make sure the recipes create them that way.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] default Settings files that need certain permissions

[hisham . hm]

On 8/13/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The copy in Defaults should never be edited, so I think it should stay
> > with the stricter permissions.
>
> Hmm.. when I found it, it referred to user "gobo", so it must have been
> modified sometime (?); and then I modified it some more so that it
> didn't refer to any particular super-user name.  What's the intended
> practice for what goes in programs' Resources/Defaults/Settings?

Ah, you mean inside the file. I was thinking about the actual file
permissions. Yes, ideally there should be no references to specific
user names inside files in Defaults. Not sure if that's fully
possible, though.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] recipe svn permission errors?

[hisham . hm]

On 8/13/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> On Mon, 13 Aug 2007 07:21:34 +0200, <[EMAIL PROTECTED]> wrote:
>
> > On 8/12/07, Isaac Dupree <[EMAIL PROTECTED]> wrote:
> >> sometime...yesterday? when trying to use PutRecipe I started getting all
> >> errors like
> >>
> >> svn: PROPFIND request failed on '/recipes/revisions'
> >> svn: PROPFIND of '/recipes/revisions': 403 Forbidden
> >> (http://svn.gobolinux.org)
> >>
> >> from svn. This appears to mean I can't commit recipes currently. Anyone
> >> know why?
> >
> > No clue. AFAIK no configurations were changed on the server side. So
> > it was working before and just stopped working? Weird.
> >
> Now it's working again. Anyone changed something to make it work?

Yes, I edited svn permissions through Dreamhost's interface just to
see if it will refresh it back to a valid state. I was going to send
an email about it, but I forgot. Good to know it's working again.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Handling of old dependencies format

[hisham . hm]

On 8/15/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> An old issue that I just encountered, is that depencencies in the old format
> "Foo x.y" is interpreted as just "Foo" while it really should be interpreted
> as "Foo >= x.y" imo. In my case it was the GnuPG recipe that listed
> "LibAssuan 1.0.2", while I had 1.0.0, which made configure die when it
> didn't find a version of that library that matched the prerequisite. We
> still have some hundred recipes in the store, which have the old dependency
> format and I cannot guess how many of those that are broken because of not
> using the version given as a lower limit.

This has been discussed in the past (offlist, perhaps) and André
decided for the current behavior. IIRC his rationale was that the ">="
behavior would force too many unnecessary upgrades as the recipe
writer is usually beyond the lower bound of the recipe. And every
upgrade is an additional chance for something to break, so we went the
conservative path there. If the new app you're installing fails to
build, that's a lesser problem than breaking something that was
working before because of a dependency (I know, in an ideal world
recipes would be perfect and things wouldn't break, but you know what
I mean). I prefer keeping the current behavior and fixing recipes that
prove themselves buggy, like GnuPG.

> For recipes some fuzz with regard to version is ok, so using the version as
> least possible would probably be better than just removing it. For binary
> packages that still have their dependencies in the Dependencies file and
> does not have a BuildInformation file (does such packages still exist) the
> version should be interpreted as required, i.e. '='.

I think it is. Either "=" or ">=", I'm not sure, he can confirm. But I
remember André talking about using different meanings for the old
syntax in recipes and packages.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Dangerous changes in UpdateRecipeStore

[hisham . hm]

On 8/16/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> I don't know what happened (well I do, but I'm still pretty chocked), but I
> nearly had a wipeout with PutRecipe! Luckily I was looking with half an eye
> when I saw lots of "normal" files, text files, documents, images, logs etc,
> scroll by and once in a while intermixed with a message that said "rm:
> cannot remove `foo': Is a directory". Can anyone guess how frenetically I
> started to press ctrl-c? :D
>
> It was the section below, from UpdateRecipeStore, that was responsible:
>
> # Loop 2: remove revision tarballs which doesn't exist anymore in the svn.
> cd $compileLocalStore
> for i in *
> do
>  svn_dir=$compileLocalRevisions/`echo $i | sed
> 's,\(.*\)--\(.*\)--recipe.tar.bz2,\1/\2,g'`
>  [ -d "$svn_dir" ] || { echo $i; rm $i; };
> done
>
> $compileLocalStore is defined in DevelScripts/CompileSubversion.conf but
> that isn't applied unless one has run 'UpdateSettings DevelScripts' after
> updated from the cvs repo. Just how often do _you_ run UpdateSettings after
> having done a 'cvs up' on any tools? Changes like these should either come
> with a *big* warning or have a fallback if some variable is undefined. Now
> '*' in the for loop expanded to everything in that users home directory, as
> 'cd' without arguments goes there. Fortunatly I never user my superuser
> account for anything useful and superuser is the only one that can commit
> recipes, due to permission bugs. So nothing important was lost, but I still
> count this as a close call.

Ouch. Actually, now that the server is maintaining the recipe store
from svn all by itself, we no longer need to/should run
UpdateRecipeStore to do the explicit remote push. I'm removing it from
CVS and adding some default fallback values in PutRecipe. I should
have done this as soon as the new scheme got stable, sorry about the
mess.

> PS. Remember to run UpdateSettings if you track cvs!

Seconded -- this is good advice.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Ghostscript again

[hisham . hm]

On 8/17/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> Was looking at updating the (Artofcode-)Ghostscript recipe to the latest
> release,
> 8.60 which also includes the merging of ESP-Ghostscript. I also noted that
> it's
> not Artofcode that's responsible for the releases anymore, but Artifex
> Software
> Inc. So the question is if this warrants a change of name (again) and if so,
> to
> what? I did some brief research and foudn that Ubuntu and Fedora goes with
> just
> 'Ghostscript' and as I guess this will be our major package, as it also
> includes
> ESP-Ghostscript I guess that would be ok. Views?

I'm fine with it.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [Gobolinux-recipes] Multiple commit messages in recipes commit

[hisham . hm]

On 8/21/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> Trying to make post-commit to update the recipe store automatically, instead
> of running UpdateLocalStore every two hours, I accidently made a recursive
> post-commit rule. Sorry about that.

I actually think the two-hour delay is a good way of allowing one to
undo quick mistakes to the svn tree without having it propagated right
away to the recipe store.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Readding syntax check for Dependencies to RecipeLint

[hisham . hm]

On 8/26/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> While talking about dependencies and such, I'd like to readd this patch to
> RecipeLint.

Ok, but here are some suggestions/comments:

> --- RecipeLint18 Nov 2006 15:15:00 -  1.30
> +++ RecipeLint20 Nov 2006 20:21:55 -  1.31
> @@ -683,15 +683,6 @@
> grep -q "^# \*Warning\*" $depfile && {
>ERROR "Dependencies file contains unmatched library
> dependencies."
> }
> +  while read line
> +  do
> + bad_dep=`echo $line | sed -r -e '/.*\ [><=]?\ .*/d' -e '/^#.*/d'
> -e '/^\s*$/d'`
> + if [ ! -z "$bad_dep" ]
> + then
> +WARN "Old style dependency/Bad line in Dependensies: $bad_dep"

Old-style should be a WARN, bad-line should be an ERROR. (And there's
a typo in Dependencies".) In the old-style note, maybe add an
informative message such as "Old style dependency 'Foo 1.0' in
Resources/Dependencies. You may want to change this to something like
'Foo >= 1.0' " (Yeah, it's a bit extra work, but I'm hoping it will
encourage users to fix them.)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Dependencies rework

[hisham . hm]

On 8/27/07, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On 8/25/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> > On Sat, 25 Aug 2007 03:43:44 +0200, Michael Homer
> <[EMAIL PROTECTED]> wrote:
> >
> > > On 8/25/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> > >> Having submitted several binary packages and had some chats on IRC with
> users
> > >> trying to install the same packages I came to the conclusion that we
> need to
> > >> rework the dependency scheme a lot.
> > >>
> > >> First I'd like to change dependencies to be none recursive.
> > > I agree. It's not really necessary (now), and it'd be clearer if they
> > > weren't all listed.
> >
> > Ok. I've thought about it and I can't see nothing against this and even if
> there
> > were, I think the pros will weight out the cons, also those that have
> commented
> > on this was positive, so I commited the changes. As in my commit message,
> for
> > example toolkits, e.g. GTK+, can be compiled agains any X server and
> applications
> > using that toolkit doesn't have to know. CheckDependencies takes care of
> the
> > recursion.
> >
> > I still want comments and ideas on the new scheme. :)
>
> Just to make it official, as we've already talked about this before:
> yes, this seems to be a sane approach to handle dependencies.
> BuildDependencies, however, should be left untouched, as it's a good
> source for hints when something goes wrong.

Did you mean BuildInformation, perchance?

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] FFTW float or double?

[hisham . hm]

On 8/30/07, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote:
> Lucas C. Villa Real wrote:
> > On 8/30/07, Jonatan Liljedahl <[EMAIL PROTECTED]> wrote:
> >> The FFTW library is a little stupid, since it can be compiled with float
> >> (libfftw3f.a) or double (libfftw3f.a) precision, and also as static (.a)
> >> or shared (.so). The default is double and static, but some apps wants
> >> float, and I think I came across some app that wanted it shared but I'm
> >> not sure which one now...
> >> Anyhow, we need to be able to have both installed at the same time, so I
> >> suggest we call one FFTW and the other one FFTWf (with --enable-float
> >> config option).
> >
> > Can't we just tweak the configure file and let it ship/compile both by
> > default? Seems more reasonable to me.
>
> That would be the best, but I don't know how to do that kind of tricks
> with autotools (which is, I guess, compiling same files with different
> DEFINES). I guess the easiest way to solve it is having two wrapper .c
> files, one for double and one for float precision, and in them do the
> define and include the real .c file, but this should be done by FFTW and
> not by us.
>
> But if you find a way to solve it by tweaking their autotools files, or
> perhaps with a hackish recipe, please go ahead. :)

I think the simplest way would be the recipe which just compiles FFTW
twice. I suggest a metarecipe FFTW which includes two recipes,
FFTW-double and FFTW-float. I don't know if any app *needs* FFTW to be
linked statically; I'm guessing just building both libraries as shared
would be okay (if there's no configure flag set to tell it to compile
both at once).

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Development meeting reminder

[hisham . hm]

On 1/17/08, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On Jan 16, 2008 1:20 PM, Jonas Karlsson <[EMAIL PROTECTED]> wrote:
> > Here's a reminder of the developer meeting on IRC this saturday (sunday
> > for michael).
> >
> > Dates and times:
> > Saturday 19, 11am - US west coast (GMT-8)
> > Saturday 19, 5pm - Brazil (GMT-2)
> > Saturday 19, 8pm - Central Europe (GMT+1)
> > Sunday 20, 8am - New Zealand (GMT+13)
> >
> > As usual I have created a presumptive agenda on the wiki,
> > http://gobo.kundor.org/wiki/015_Roadmap to which everyone is free to
> > add items. As you can see the topic will be GoboLinux 015, unless that
> > will make people scream violently, as I feel it is important to get
> > some structure on that, so we know where we're heading. A requirement
> > for this topic is that Carlo can participate.
> >
> > An alternative agenda is "development of our tools, what should we do"
> > and can be found at http://gobo.kundor.org/wiki/Tools_development
>
> I'll be out of town tomorrow and I'm not sure if I'll have access to
> the internet over the weekend. Please make a log of the conversation
> again so that I can read it later. I didn't see acks from other devs,
> so I believe everyone else will be there, right?

I'll do my best to be there.

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] 014.b grub enumeration.

[hisham . hm]

On 3/19/08, Carlo Calica <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Just tried to install on real hardware. Sorta a pathological case and
> grub isn't installed correctly. This is with recent snapshots of
> Installer and ConfigTools.
>
> My hd setup:
> /dev/hda
> /dev/hdb
> /dev/sda (SATA SI 3114 chipset, PCI card)
> /dev/sdb (SATA SI 3114 chipset, PCI card)
> /dev/sdc (SATA SI 3114 chipset, PCI card)
> /dev/sdd (USB flash, Booting from here, LiveFlash)
>
> DVD is /dev/hdc. I don't believe the SATA 3114 card is bootable.
>
> I'm booting with a CD/Flash mix. The CD contains isolinux, kernel,
> initrd, and NO squashfs images. The initrd won't find any squashfs
> images and will fallback to the usb flash.
>
> Any idea what's wrong? What can I test?

I didn't get exactly what failed. Wasn't the behavior of falling back
to the USB flash in the absence of squashfs images in the CD expected?

> Also, Installer isn't asking about my netconfig??

Try to run StartTask Network after boot. May be a delay issue, in
which the bootscripts tried to bring the net up before eth/udev/etc.
was ready for it.

> Also, I get an error, "ln: creating symbolic link
> '/Mount/GoboLinux/srv' -> '': No such file or directory"

Is this during the CD boot? At what point?

> Just tried a pure CD not SATA install. Installer did ask about my
> netconfig. Still compalins about src symlink. grub installs ok.

Change in net behavior tends to confirm it's a delay issue. We may
need to add a loop there to wait until it's ready (which would slow
down boot up to a timeout in non-networked systems... other ideas
welcome).

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] Name of GoboLinux 014 bugfix release

[hisham . hm]

On Thu, Mar 20, 2008 at 3:45 AM, Carlo Calica <[EMAIL PROTECTED]> wrote:
> On 3/19/08, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> >
> > Right. I'm ok with 014.1. Or maybe 014.01, then 014.10 and then
> > 014.11. No more than 3 bug fix releases would be allowed in this case
> > ;-)
> >
>
> I like this.

It's cute, but 014.01 vs. 014.10 is another a source of confusion. The leading 
0 in "01" makes it look like a decimal fraction, by which logic the trailing 
zero in "10" could be cut, and then there would be people saying "fourteen dot 
one" when they mean "014.10". If there has to be an "unconventional" numbering 
system of some sort, let's just stick with octal, like Paul Dann suggested. 
Given that dots in version numbers are not usually fractional separators, 
numbering could also go like this: 014.01, 014.02, ... 014.07, 014,010. (The 
014.01 vs. 014.010 confusion is unlikely to happen as we're not supposed to 
have this many releases.)

-- Hisham


-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] r3332 - trunk/ChrootCompile/bin

[hisham . hm]

On 5/12/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Don't get fooled by GuessProgramCase. Only use it if the recipe could not be
> found in the first attempt.

GuessProgramCase uses the entries you have in /Programs. When those
don't match, it means you have an inconsistency somewhere. Isn't it
better to stop in those cases and have it fixed than to go on with the
program? (Especially in ChrootCompile, which aims to be pedantic on
the cleanliness of packages.)

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel

Re: [gobolinux-devel] [gobolinux-commits] r3332 - trunk/ChrootCompile/bin

[hisham . hm]

On 5/20/08, Lucas C. Villa Real <[EMAIL PROTECTED]> wrote:
> On Tue, May 20, 2008 at 4:59 PM,  <[EMAIL PROTECTED]> wrote:
>> GuessProgramCase uses the entries you have in /Programs. When those
>> don't match, it means you have an inconsistency somewhere. Isn't it
>> better to stop in those cases and have it fixed than to go on with the
>> program? (Especially in ChrootCompile, which aims to be pedantic on
>> the cleanliness of packages.)
>
> ChrootCompile shouldn't consider programs from the host system, unless
> when invoked with --local-programs. Program names should be taken from
> Dependencies files instead.

Fair point.

> I wonder what happens when one runs
> GuessProgramCase in a case-insensitive filesystem, too.

We probably don't need to worry about that; I think we never claimed
to support  case-insensitive filesystems (there are things in Linux
that are known to break if you use those to store your system in,
IIRC; that's why things like umsdos were created back then).

-- Hisham
___
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel