From zbiggy at o2.pl  Sat Aug  1 08:12:14 2009
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 1 Aug 2009 08:12:14 +0200
Subject: [Lunar-commits] <moonbase> ruby: rolling back to 1.8.7-p160
Message-ID: <200908010812.14824.zbiggy@o2.pl>

Dave Brown dagbrown from lunar - linux org on Fri, 31 Jul 2009 05:51:30 +0000 
(14:51 +0900) wrote:
>ruby: rolling back to 1.8.7-p160.
>Ruby 1.9.x is the *BETA* version.  It is not, and will never be, the
>stable version of Ruby.  The next stable major version of Ruby will be
>version 2.0.

Can you please show me the source of this piece of information telling that 
this is not stable and not recommended version?

Did you rolled it back just because you consider it beta or you encounter any 
issues with this release?

http://www.ruby-lang.org/en/downloads/
(...) Ruby 1.9.1-p129 (md5: c71f413514ee6341c627be2957023a5c) Stable Version 
(recommended) (...)

http://en.wikipedia.org/wiki/Ruby_language
(...)The official 1.9 branch uses YARV, as will 2.0 (development), and will 
eventually supersede the slower Ruby MRI.(...)

http://distrowatch.com/table.php?distribution=lunar
ruby (1.9.1-p243)
My comment: Distrowatch shows only latest official releases

have a nice day,
Zbigniew Luszpinski


From dennisveatch at bellsouth.net  Sat Aug  1 14:34:15 2009
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 1 Aug 2009 08:34:15 -0400
Subject: [Lunar-commits] <moonbase> ruby: rolling back to 1.8.7-p160
In-Reply-To: <200908010812.14824.zbiggy@o2.pl>
References: <200908010812.14824.zbiggy@o2.pl>
Message-ID: <200908010834.15381.dennisveatch@bellsouth.net>

On Saturday 01 August 2009 2:12:14 am Zbigniew Luszpinski wrote:
> Dave Brown dagbrown from lunar - linux org on Fri, 31 Jul 2009 05:51:30
> +0000
>
> (14:51 +0900) wrote:
> >ruby: rolling back to 1.8.7-p160.
> >Ruby 1.9.x is the *BETA* version.  It is not, and will never be, the
> >stable version of Ruby.  The next stable major version of Ruby will be
> >version 2.0.
>
> Can you please show me the source of this piece of information telling that
> this is not stable and not recommended version?
>
> Did you rolled it back just because you consider it beta or you encounter
> any issues with this release?
>

The only module I am aware of that remains croaked was obexftp (at latest 
version available). There might be others, don't know. rrdtool was another but 
a version bump fixed that.

> http://www.ruby-lang.org/en/downloads/
> (...) Ruby 1.9.1-p129 (md5: c71f413514ee6341c627be2957023a5c) Stable
> Version (recommended) (...)
>
> http://en.wikipedia.org/wiki/Ruby_language
> (...)The official 1.9 branch uses YARV, as will 2.0 (development), and will
> eventually supersede the slower Ruby MRI.(...)
>
> http://distrowatch.com/table.php?distribution=lunar
> ruby (1.9.1-p243)
> My comment: Distrowatch shows only latest official releases
>
> have a nice day,
> Zbigniew Luszpinski

-- 
You can tuna piano but you can't tune a fish.

From brebs at sent.com  Sat Aug  8 02:33:37 2009
From: brebs at sent.com (Paul Bredbury)
Date: Sat, 08 Aug 2009 07:33:37 +0700
Subject: tiff - security patching required
Message-ID: <1249691617.3255.16.camel@localhost>

Hi, tiff has several bugs (including security), which are all unpatched
in Lunar. Here's my fix, which is too big for
http://foo-projects.org/~sofar/queue.php?p=tiff to accept:

My rolled-up patch is at http://devnull.lunar-linux.org/p/917

New BUILD:

(

  # Apply all 6 patches from libtiff-3.8.2-15.fc12 -
http://koji.fedoraproject.org/koji/packageinfo?packageID=328
  # http://www.gentoo.org/security/en/glsa/glsa-200908-03.xml
  # Patch0: tiffsplit-overflow.patch
  # Patch1: libtiff-3.8.2-ormandy.patch
  # Patch2: libtiff-3.8.2-CVE-2006-2193.patch
  # Patch3: libtiff-3.8.2-mantypo.patch
  # Patch4: libtiff-3.8.2-lzw-bugs.patch
  # Patch5: libtiff-3.8.2-CVE-2009-2347.patch
  bzcat $SCRIPT_DIRECTORY/tiff-3.8.2-15fc12.patch.bz2 >
tiff-3.8.2-15fc12.patch &&
  patch_it tiff-3.8.2-15fc12.patch 1 &&

  default_build

) > $C_FIFO 2>&1


So, which Lunar dev wants to apply the security patches?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20090808/516275bd/attachment.html>

From sofar at foo-projects.org  Sat Aug  8 06:36:50 2009
From: sofar at foo-projects.org (Auke Kok)
Date: Fri, 07 Aug 2009 21:36:50 -0700
Subject: tiff - security patching required
In-Reply-To: <1249691617.3255.16.camel@localhost>
References: <1249691617.3255.16.camel@localhost>
Message-ID: <4A7D00E2.7050409@foo-projects.org>

Paul Bredbury wrote:
> Hi, tiff has several bugs (including security), which are all unpatched
> in Lunar. Here's my fix, which is too big for
> http://foo-projects.org/~sofar/queue.php?p=tiff to accept:
> 
> My rolled-up patch is at http://devnull.lunar-linux.org/p/917
> 
> New BUILD:
> 
> (
> 
>   # Apply all 6 patches from libtiff-3.8.2-15.fc12 -
> http://koji.fedoraproject.org/koji/packageinfo?packageID=328
>   # http://www.gentoo.org/security/en/glsa/glsa-200908-03.xml
>   # Patch0: tiffsplit-overflow.patch
>   # Patch1: libtiff-3.8.2-ormandy.patch
>   # Patch2: libtiff-3.8.2-CVE-2006-2193.patch
>   # Patch3: libtiff-3.8.2-mantypo.patch
>   # Patch4: libtiff-3.8.2-lzw-bugs.patch
>   # Patch5: libtiff-3.8.2-CVE-2009-2347.patch
>   bzcat $SCRIPT_DIRECTORY/tiff-3.8.2-15fc12.patch.bz2 >
> tiff-3.8.2-15fc12.patch &&
>   patch_it tiff-3.8.2-15fc12.patch 1 &&
> 
>   default_build
> 
> ) > $C_FIFO 2>&1
> 
> 
> So, which Lunar dev wants to apply the security patches?

are the patches downloadable from a certain location? please share that 
or send the patches to the list.

I can then put them in $PATCH_URL and you can include them in your 
module's DETAILS when you submit the update parts (so you can actually 
test that they download properly from the lunar patch location)

Auke

From brebs at sent.com  Sat Aug  8 07:02:53 2009
From: brebs at sent.com (Paul Bredbury)
Date: Sat, 08 Aug 2009 12:02:53 +0700
Subject: tiff - security patching required
In-Reply-To: <4A7D00E2.7050409@foo-projects.org>
References: <1249691617.3255.16.camel@localhost>
	<4A7D00E2.7050409@foo-projects.org>
Message-ID: <1249707773.3255.21.camel@localhost>

On Fri, 2009-08-07 at 21:36 -0700, Auke Kok wrote:
> are the patches downloadable from a certain location?

The patches are in:
http://kojipkgs.fedoraproject.org/packages/libtiff/3.8.2/15.fc12/src/libtiff-3.8.2-15.fc12.src.rpm

Which is findable from the historical list of Fedora's tiff packages
(currently at the top of the list):
http://koji.fedoraproject.org/koji/packageinfo?packageID=328


From auke at foo-projects.org  Sat Aug  8 07:20:02 2009
From: auke at foo-projects.org (Auke Kok)
Date: Fri, 07 Aug 2009 22:20:02 -0700
Subject: tiff - security patching required
In-Reply-To: <1249707773.3255.21.camel@localhost>
References: <1249691617.3255.16.camel@localhost>
	<4A7D00E2.7050409@foo-projects.org>
	<1249707773.3255.21.camel@localhost>
Message-ID: <4A7D0B02.1060401@foo-projects.org>

Paul Bredbury wrote:
> On Fri, 2009-08-07 at 21:36 -0700, Auke Kok wrote:
>> are the patches downloadable from a certain location?
> 
> The patches are in:
> http://kojipkgs.fedoraproject.org/packages/libtiff/3.8.2/15.fc12/src/libtiff-3.8.2-15.fc12.src.rpm
> 
> Which is findable from the historical list of Fedora's tiff packages
> (currently at the top of the list):
> http://koji.fedoraproject.org/koji/packageinfo?packageID=328

could you be so friendly as to send me the patches in a way that is 
usable for me? either a tarball or separate patch files (gzipped or not) 
would work best.

Thanks,

Auke

From duncan.gibson at xs4all.nl  Sun Aug  9 09:21:13 2009
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sun, 9 Aug 2009 09:21:13 +0200 (CEST)
Subject: [Lunar-commits] <lunar> Add sanity check: don't allow patch 
	files to be submitted
Message-ID: <22854.82.93.24.95.1249802473.squirrel@webmail.xs4all.nl>

> commit 2d143d693cda096776dd5f51e72bfc11058b0a4f
> Author: Auke Kok <sofar at foo-projects.org>
> Date:   Sat Aug 8 18:35:38 2009 -0700
> ...
> +    # sanity checks
> +    lvu diff $1 | diffstat -p0 -l | grep -e '.patch$' -e '.diff$' && (
> +      echo ""
> +      echo "Sanity check failed: patch files are not allowed inside
> moonbase"
> +      echo "Please submit your patch files to the lunar-dev mailinglist
> and"
> +      echo "Wait for one of the developers to upload them to
> \$PATCH_URL."
> +      echo "Once that is done you can resubmit using that URL for the
> patch(es)"
> +      exit 1

Once lvu has detected the patch files, wouldn't it be possible for it
to send the module submission  to the mailing list automatically?

Or has the old mail submission infrastructure been dismantled?

groetjes
D


From auke at foo-projects.org  Sun Aug  9 21:01:47 2009
From: auke at foo-projects.org (Auke Kok)
Date: Sun, 09 Aug 2009 12:01:47 -0700
Subject: [Lunar-commits] <lunar> Add sanity check: don't allow patch files
	to be submitted
In-Reply-To: <22854.82.93.24.95.1249802473.squirrel@webmail.xs4all.nl>
References: <22854.82.93.24.95.1249802473.squirrel@webmail.xs4all.nl>
Message-ID: <4A7F1D1B.7020904@foo-projects.org>

Duncan Gibson wrote:
>> commit 2d143d693cda096776dd5f51e72bfc11058b0a4f
>> Author: Auke Kok <sofar at foo-projects.org>
>> Date:   Sat Aug 8 18:35:38 2009 -0700
>> ...
>> +    # sanity checks
>> +    lvu diff $1 | diffstat -p0 -l | grep -e '.patch$' -e '.diff$' && (
>> +      echo ""
>> +      echo "Sanity check failed: patch files are not allowed inside
>> moonbase"
>> +      echo "Please submit your patch files to the lunar-dev mailinglist
>> and"
>> +      echo "Wait for one of the developers to upload them to
>> \$PATCH_URL."
>> +      echo "Once that is done you can resubmit using that URL for the
>> patch(es)"
>> +      exit 1
> 
> Once lvu has detected the patch files, wouldn't it be possible for it
> to send the module submission  to the mailing list automatically?

no, since it requires you to modify the submission, and I want people to 
test their modules before they are submitted

> Or has the old mail submission infrastructure been dismantled?

realistically, yes, those bits are dead

Auke

From zbiggy at o2.pl  Sun Aug  9 23:14:29 2009
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sun, 9 Aug 2009 23:14:29 +0200
Subject: udev-145 ready for testing at zbiggy-WIP
Message-ID: <200908092314.29299.zbiggy@o2.pl>

Hello,

at my zbiggy-WIP branch you will find udev 145 ready for testing.
I have fixed all compilation issues I encountered.
If you are brave enough you can give it a try.
http://foo-projects.org/git/?p=zbiggy/moonbase.git;a=shortlog;h=refs/heads/zbiggy-WIP
Works for me.

have a nice day,
Zbigniew Luszpinski

From brebs at sent.com  Mon Aug 10 06:02:15 2009
From: brebs at sent.com (Paul Bredbury)
Date: Mon, 10 Aug 2009 11:02:15 +0700
Subject: rott and iptraf patches for PATCH_URL
In-Reply-To: <1249791169.4582.16.camel@localhost>
References: <1249786095.4582.11.camel@localhost>
	<4A7E4660.1020701@foo-projects.org>
	<1249791169.4582.16.camel@localhost>
Message-ID: <1249876935.9066.14.camel@localhost>

Hi, please remove rott-1.1.1-hardcode-datapath.patch and
iptraf-3.0.1-compile.fix.patch from
http://download.lunar-linux.org/lunar/patches/ because they are
corrupted somehow. Presumably, it's a text issue.

Since "patch_it $SOURCE_CACHE/$SOURCE3 0 &&" works fine on a patch.bz2
file, might as well do that.

Enclosed are replacement files, for somebody to upload, to be used with:

http://foo-projects.org/~sofar/queue.php?p=rott
http://foo-projects.org/~sofar/queue.php?p=iptraf




On Sun, 2009-08-09 at 11:12 +0700, Paul Bredbury wrote:
> There's something bad about your upload of
> rott-1.1.1-hardcode-datapath.patch - the patch no longer applies, and
> sha1sum is different. Has your upload process changed tabs to spaces?
> 
> Should be:
> 
> $ sha1sum /home/brebs/temp/rott-1.1.1-hardcode-datapath.patch 
> 3e442ba61e23212496e23c191f9ac5dd3d756087
> 
> 
> On Sat, 2009-08-08 at 20:45 -0700, Auke Kok wrote: 
> > Paul Bredbury wrote:
> > > Hi, please put these 2 patches in PATCH_URL, so I can submit rott
> > > (new/old game) and an iptraf version bump.
> > > 
> > > 
> > 
> > 
> > done!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rott-1.1.1-hardcode-datapath.patch.bz2
Type: application/x-bzip
Size: 653 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20090810/9d2e0c1e/attachment.bz2>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iptraf-3.0.1-compile.fix.patch.bz2
Type: application/x-bzip
Size: 1252 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20090810/9d2e0c1e/attachment-0001.bz2>

From brebs at sent.com  Sat Aug 15 14:21:31 2009
From: brebs at sent.com (Paul Bredbury)
Date: Sat, 15 Aug 2009 19:21:31 +0700
Subject: libxml2 2.7.3 - DoS patch
Message-ID: <1250338891.4509.8.camel@localhost>

Hi, libxml2 2.7.3 has a security bug:
http://secunia.com/advisories/36207/

Enclosed is the patch from Fedora, to put in $PATCH_URL, and the module
patch is at http://foo-projects.org/~sofar/queue.php?p=libxml2

Who wants to make the change ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libxml2-2.7.3-ficora-parse.patch
Type: text/x-patch
Size: 6083 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20090815/3621ccbd/attachment.bin>

From auke at foo-projects.org  Sat Aug 15 21:43:34 2009
From: auke at foo-projects.org (Auke Kok)
Date: Sat, 15 Aug 2009 12:43:34 -0700
Subject: libxml2 2.7.3 - DoS patch
In-Reply-To: <1250338891.4509.8.camel@localhost>
References: <1250338891.4509.8.camel@localhost>
Message-ID: <4A870FE6.5000802@foo-projects.org>

Paul Bredbury wrote:
> Hi, libxml2 2.7.3 has a security bug:
> http://secunia.com/advisories/36207/
> 
> Enclosed is the patch from Fedora, to put in $PATCH_URL, and the module
> patch is at http://foo-projects.org/~sofar/queue.php?p=libxml2

merged, thanks

Auke

From brebs at sent.com  Tue Aug 18 14:16:38 2009
From: brebs at sent.com (Paul Bredbury)
Date: Tue, 18 Aug 2009 19:16:38 +0700
Subject: expat 2.0.1 - DoS patch
Message-ID: <1250597798.16125.2.camel@localhost>

Hi, expat 2.0.1 has a DoS bug:
http://mail.python.org/pipermail/expat-bugs/2009-January/002781.html

Enclosed is the patch from Gentoo, to put in $PATCH_URL, and the module
patch is at http://foo-projects.org/~sofar/queue.php?p=expat

Who wants to make the change ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: expat-2.0.1-fix_bug_1990430.patch.bz2
Type: application/x-bzip
Size: 363 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20090818/ea9828bf/attachment.bz2>

From lazyape at gmail.com  Tue Aug 18 21:33:35 2009
From: lazyape at gmail.com (lazyape)
Date: Tue, 18 Aug 2009 22:33:35 +0300
Subject: binutils build with shared libs
Message-ID: <20090818223335.c9e33108.lazyape@gmail.com>

i suggest changing the
- OPTS+=" --host=$BUILD"  &&
+ OPTS+=" --enable-shared --host=$BUILD" &&

in the BUILD script of binutils.

the reason is that some programs needs the shared version of the libbfd library.
by default binutils is built only with static libraries version.
if someone put binutils to zlocal and rebuilds it with --enable-shared then if 
he/she import a new module that use this shared library then it won't compile to
other boxes. My proposal is that we should change this behaviour of binutils.

i would like your opinions
thanks

-- 
lazyape <lazyape at gmail.com>

From engelsman at lunar-linux.org  Sat Aug 22 20:22:56 2009
From: engelsman at lunar-linux.org (engelsman at lunar-linux.org)
Date: Sat, 22 Aug 2009 20:22:56 +0200
Subject: submission NVIDIA-Cg-toolkit.patch was rejected
Message-ID: <20090822183239.E37C59B1F6@doppio.foo-projects.org>

Hi,

This is probably just a technicality, but I've just rejected
your "NVIDIA-Cg-toolkit.patch" submission because the other
NVIDIA modules are marked with LICENSE=proprietary.

Unless one of the other devs objects, if you resubmit after
checking and setting the appropriate licence, the module can
be accepted. It downloads and installs OK here, but I don't
have an NVIDIA card to test it against.

Thank you for submitting updates to us!


From zbiggy at o2.pl  Tue Aug 25 22:27:03 2009
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Tue, 25 Aug 2009 22:27:03 +0200
Subject: udev-146 ready for testing at zbiggy-WIP
In-Reply-To: <200908092314.29299.zbiggy@o2.pl>
References: <200908092314.29299.zbiggy@o2.pl>
Message-ID: <200908252227.03839.zbiggy@o2.pl>

Updated to 146 at zbiggy-WIP.

have a nice day,
Zbigniew Luszpinski

From peter at xfce.org  Mon Aug 31 23:00:46 2009
From: peter at xfce.org (Peter de Ridder)
Date: Mon, 31 Aug 2009 23:00:46 +0200
Subject: Multilib lunar
Message-ID: <d7c3a3890908311400t14f92a94l27a46b847db99403@mail.gmail.com>

Hi,

A while back I did some research in making lunar into a multilib system.
After a few attempts I was able to make a new lunar install by hand
into a multilib system.
Later I was able to convert a x86_64 system into a multilib system.
I wrote a howto for this at
http://member.lycos.nl/pcridder/extern/lunar unfortunately this isn't
accessible anymore.
If someone knows/has a place to host this let me know.

To really be able to benefit from a multilib system some things should
be added to the moonbase and lunar tools.
That gets me to the purpose of this mail.
I want to put some more effort into it to get the multilib usable.
But I got stuck on the moonbase for now, and I would like some help to
get to a solution.

The question:
How should the multilib modules be integrated into the moonbase?

Currently the moonbase uses configurations based on the processor
type, which is either a 32-bit or 64-bit processor.
For multilib both of these configurations should be combined.

Possible solutions:
 1) Separate moonbase repository/branch.
 2) Separate configuration type (like x86_64) for multilib.
 3) Packages with -32 postfix for 32-bit multilib version.
 4) Some intelligent lunar scripts to create multilib configuration
from 32-bit and 64-bit configurations.

Pros and cons:
 1) Separate moonbase must be kept up-to-date separately.
    But it is not limited in possibilities.
 2) Another configuration to maintain.
    If multilib is not required for a certain module it can use the
64-bit configuration.
 3) How to solve the installed files conflicts between the -32 and the
64-bit module.
    Multilib versions are only installed if the multilib version is required.
 4) Nearly impossible to create I guess.
    Least maintenance.

Follow-ups:
 1) For this solution the question remains fairly the same.
    - Which of the other solutions is used in this moonbase.
 2) How is the configuration maintained?
    - Is it stored in a .x86_64_multilib file postfix or
    - Does a .x86_64 config file check for some special multilib option.
 3) How to solve the installed files conflicts between the -32 and the
64-bit module?
 4) How would this be possible?

Regards,
Peter