From zbiggy at o2.pl  Sat May  8 18:30:39 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 8 May 2010 18:30:39 +0200
Subject: installed uudeview may break some build with strange errors
Message-ID: <201005081830.39863.zbiggy@o2.pl>

Hello,

I have noticed that since I have uudeview installed some builds broke with strange error.
This happens because in my case uudecode does not decode uue files and return 0 which means correct result.
For configure script of db module this means uudecode is present, works ok but Test.class is not decoded from uue format.
That is why configure script fails saying that Java class can not be found suggesting that Java installation is broken.
This suggestion is wrong. Java installation is ok. Just uudecode did not decode Test.class which is used for testing Java installation.

This is fix for db I commited today:
# The uudecode from uudeview module does not work.
# It returs 0 meaning errorless execution but actually does nothing:
# it does not decode uue encoded files. That is why configure breaks
# if uudeview module is installed.
  if module_installed uudeview; then
     sedit 's/uudecode/nouudecode/g' dist/configure
  fi &&

The db module compiles fine now.

If you encounter module which breaks when uudeview is installed make sure the strange error displayed is not connected to uudecode.

have a nice day,
Zbigniew Luszpinski

From auke at foo-projects.org  Mon May 10 00:49:33 2010
From: auke at foo-projects.org (Auke Kok)
Date: Sun, 09 May 2010 15:49:33 -0700
Subject: [Lunar-commits] <moonbase> udev: Proper kernel configuration
	detection
In-Reply-To: <20100325063535.40263F5A9D@doppio.foo-projects.org>
References: <20100325063535.40263F5A9D@doppio.foo-projects.org>
Message-ID: <4BE73BFD.7050207@foo-projects.org>

Stefan Wold wrote:
> commit 3177c3a652551e46ba70cc1124d043e88119e08e
> Author: Stefan Wold <ratler at lunar-linux.org>
> Date:   Thu Mar 25 07:35:31 2010 +0100
> 
>     udev: Proper kernel configuration detection
> ---

I think this is wrong

> +if kernel_option_present CONFIG_SYSFS_DEPRECATED || \

why does having (more) deprecated sysfs files prevent udev from working? 
that doesn't make sense, it just ADDS old nodes in sysfs, but doesn't 
affect the non-deprecated ones.

> +   ! kernel_option_present CONFIG_INOTIFY || \
> +   ! kernel_option_present CONFIG_INOTIFY_USER; then

these are OK

From zbiggy at o2.pl  Mon May 10 02:26:44 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Mon, 10 May 2010 02:26:44 +0200
Subject: [Lunar-commits] <moonbase> udev: Proper kernel configuration
	detection
In-Reply-To: <4BE73BFD.7050207@foo-projects.org>
References: <20100325063535.40263F5A9D@doppio.foo-projects.org>
	<4BE73BFD.7050207@foo-projects.org>
Message-ID: <201005100226.44369.zbiggy@o2.pl>

> Stefan Wold wrote:
> > commit 3177c3a652551e46ba70cc1124d043e88119e08e
> > Author: Stefan Wold <ratler at lunar-linux.org>
> > Date:   Thu Mar 25 07:35:31 2010 +0100
> > 
> >     udev: Proper kernel configuration detection
> > ---
> 
> I think this is wrong
> 
> > +if kernel_option_present CONFIG_SYSFS_DEPRECATED || \
> 
> why does having (more) deprecated sysfs files prevent udev from working? 
> that doesn't make sense, it just ADDS old nodes in sysfs, but doesn't 
> affect the non-deprecated ones.

CONFIG_SYSFS_DEPRECATED does not prevent udev from working AFAIR but can make you stop working when you encounter weird situation and will start to investigate the issue instead of doing planned job. The reason for blocking CONFIG_SYSFS_DEPRECATED is to keep Lunar running always inside supported code. This way we can better support the users and have less problems with support. Another reason is to avoid udev nag text with 15 secs pause at boot telling that SYSFS is deprecated and why it is important to turn it off.

Here is the more technical answer than mine more user oriented:
http://article.gmane.org/gmane.linux.hotplug.devel/13141
Pay attention to this part at the end of response:
"So it's not strictly a udev requirement, it's that system services
will increasingly depend on new features udev offers, which will fail
in in subtle ways with older kernels or the deprecated sysfs layout."
I do not like fixing and supporting subtle failures because they are usually subtle to find and fix :)

Do you have any problems (like LVM not booting) when CONFIG_SYSFS_DEPRECATED is turned off or just only wanted to know why?

have a nice day,
Zbigniew Luszpinski

From ratler at lunar-linux.org  Thu May 13 12:06:26 2010
From: ratler at lunar-linux.org (Stefan Wold)
Date: Thu, 13 May 2010 12:06:26 +0200
Subject: Developer call to arms! Join the effort to get our dev-wiki up to
	speed!
Message-ID: <1273745186.22568.11.camel@localhost>

Hello fellow developers,

As most of you probably already are aware of we now have a developer
wiki. This wiki need YOU to be successful. The purpose of it is to have
a collaboration area where we can gather and discuss our ideas for the
future of Lunar Linux.

It will only take a few minutes of your time to fill in your information
and what ideas you have in store for Lunar, so why wait? Come on and
join the rest of us!

For more information on how to get access to the wiki, please contact
wdp on  wdp _at_ lunar-linux.org or on irc.

-- 
Sincerely
Stefan Wold
Lunar Linux developer - PGP public key 6E810F05

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100513/05ebe91b/attachment.bin>

From jean.bruenn at ip-minds.de  Fri May 14 12:31:20 2010
From: jean.bruenn at ip-minds.de (Jean-Michel Bruenn)
Date: Fri, 14 May 2010 12:31:20 +0200
Subject: lcer - lunar compile error report (simplifying support)
Message-ID: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>

Hello Developers,

recently i came up with the idea of making "lcer", which is fetching
additional information about a lunar-linux installation like
optimizations and similar things - We could use lcer implemented within
lin and lunar (so that people could use it optionally - en/dis-abling
in lunar features). Everytime a compile fails a user could
be asked whether he wants to submit the data of this failed compile -
as a result he would get an address which he could post at #lunar or on
the maillinglist. Instead of spending a lot of time by explaining a
user how to obtain the compile log and other information we would see
all needed information at that url. A user could also run the script
manually like ./lcer modulename

Additional Information about this feature are available on the
developer WIKI (look at the section "Tasks") - A running example is
available here: http://84.201.38.2/lcer.php Click for example on "ntp"
to see which information are collected. The Bash Script which is
collecting and submitting the data is available in the wiki, too - or
by pm'ing or mailing to me.

However, before i spend any more work into this:
	- How do other developers think about this feature?
	- Who would like to help by implementing it into lin and the
lunar features dialog (And, do we want to implement it?)
	- I could colour some parts of the output on the page to see
whether a user is using "safe" optimizations or not - Something like
that useful? I'm also happy if someone wants to make another layout for
that page.
	- Any other Information about a failed compile which you would
like to have on that page?

Please note, that this is currently only an example; i hope if all
other developers agree to place it onto dopio, soon.

Download of the Bash Script lcer which is submitting this data is
possible by either looking into the dev-wiki or pm'ing me on IRC (Or
well, write me an email)

Happily awaiting your feedback.

-- 
Jean-Michel Bruenn <jean.bruenn at ip-minds.de>

From duncan.gibson at xs4all.nl  Sat May 15 15:56:30 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sat, 15 May 2010 15:56:30 +0200
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
Message-ID: <15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>

> [...snip...]
> However, before i spend any more work into this:
> 	- How do other developers think about this feature?
> 	- Who would like to help by implementing it into lin and the
>         lunar features dialog (And, do we want to implement it?)

I think that it could be useful, with the following caveats:

1. most users who get to #lunar usually only need a hint to get going,
   there aren't that many who are asked for compile logs, etc.
   lcer.sh is still a good idea to be able to get the information.

2. Why does it have to be part of lunar/theedge? Can't it be a module
   on its own? The user asks on #lunar, someone says 'lin lcer' and
   then run 'lver module' and we'll have a look.

3. Bearing in mind that the current Bug Tracker needs a good clean out,
   who maintains the lcer reports page?

It's a bit like sofar's module submission queue and review system. It's
a good idea, but really needs more people to use it...

Cheers
D.


From ratler at lunar-linux.org  Sat May 15 17:08:56 2010
From: ratler at lunar-linux.org (Stefan Wold)
Date: Sat, 15 May 2010 17:08:56 +0200
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
	<15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
Message-ID: <1273936136.22568.20.camel@localhost>

On Sat, 2010-05-15 at 15:56 +0200, Duncan Gibson wrote:
> > [...snip...]
> > However, before i spend any more work into this:
> > 	- How do other developers think about this feature?
> > 	- Who would like to help by implementing it into lin and the
> >         lunar features dialog (And, do we want to implement it?)
> 
> I think that it could be useful, with the following caveats:
> 
> 1. most users who get to #lunar usually only need a hint to get going,
>    there aren't that many who are asked for compile logs, etc.
>    lcer.sh is still a good idea to be able to get the information.

On the contrary, I often find it necessary to ask for the compile log,
or at least the last 100 rows or so. I like the idea anyway.

> 
> 2. Why does it have to be part of lunar/theedge? Can't it be a module
>    on its own? The user asks on #lunar, someone says 'lin lcer' and
>    then run 'lver module' and we'll have a look.
> 

I think it would fit even better into lunar-tools.


> 3. Bearing in mind that the current Bug Tracker needs a good clean out,
>    who maintains the lcer reports page?
> 

The system could be self cleaning, logs older than X months get nuked.
Least effort from devs is the way to go, if it can be automated it
should :)


> It's a bit like sofar's module submission queue and review system. It's
> a good idea, but really needs more people to use it...

Sofars idea is great, it's just the implementation from the developers
side that should be easier. Right now it's to much of an effort to work
through the queue, but that's in my opinion. That's why there are so few
of the developers using it. I for one love the fact that we let the
users assist us. If we make it even more simple I'm sure most devs would
come to love it.

-- 
Sincerely
Stefan Wold
Lunar Linux developer - PGP public key 6E810F05

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100515/ca7b7f68/attachment.bin>

From dennisveatch at bellsouth.net  Sat May 15 17:12:53 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 15 May 2010 11:12:53 -0400
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <1273936136.22568.20.camel@localhost>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
	<15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
	<1273936136.22568.20.camel@localhost>
Message-ID: <201005151112.53938.dennisveatch@bellsouth.net>

On Saturday, May 15, 2010 11:08:56 am Stefan Wold wrote:
> On Sat, 2010-05-15 at 15:56 +0200, Duncan Gibson wrote:
> > > [...snip...]
> > > 
> > > However, before i spend any more work into this:
> > > 	- How do other developers think about this feature?
> > > 	- Who would like to help by implementing it into lin and the
> > > 	
> > >         lunar features dialog (And, do we want to implement it?)
> > 
> > I think that it could be useful, with the following caveats:
> > 
> > 1. most users who get to #lunar usually only need a hint to get going,
> > 
> >    there aren't that many who are asked for compile logs, etc.
> >    lcer.sh is still a good idea to be able to get the information.
> 
> On the contrary, I often find it necessary to ask for the compile log,
> or at least the last 100 rows or so. I like the idea anyway.
> 
> > 2. Why does it have to be part of lunar/theedge? Can't it be a module
> > 
> >    on its own? The user asks on #lunar, someone says 'lin lcer' and
> >    then run 'lver module' and we'll have a look.
> 
> I think it would fit even better into lunar-tools.
> 

Agreed.

> > 3. Bearing in mind that the current Bug Tracker needs a good clean out,
> > 
> >    who maintains the lcer reports page?
> 
> The system could be self cleaning, logs older than X months get nuked.
> Least effort from devs is the way to go, if it can be automated it
> should :)
>
> > It's a bit like sofar's module submission queue and review system. It's
> > a good idea, but really needs more people to use it...
> 
> Sofars idea is great, it's just the implementation from the developers
> side that should be easier. Right now it's to much of an effort to work
> through the queue, but that's in my opinion. That's why there are so few
> of the developers using it. I for one love the fact that we let the
> users assist us. If we make it even more simple I'm sure most devs would
> come to love it.

You have clearly defined why I do not fiddle with the submission queue.

-- 
Dennis Veatch

From jean.bruenn at ip-minds.de  Sat May 15 18:08:54 2010
From: jean.bruenn at ip-minds.de (Jean-Michel Bruenn)
Date: Sat, 15 May 2010 18:08:54 +0200
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <201005151112.53938.dennisveatch@bellsouth.net>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
	<15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
	<1273936136.22568.20.camel@localhost>
	<201005151112.53938.dennisveatch@bellsouth.net>
Message-ID: <20100515180854.dbcbd032.jean.bruenn@ip-minds.de>

Hello,

first of all, i like that some devs like the idea. I have still some
questions about what to implement, what data to collect, etc. So if
someone wanna drop in on irc, pm me and discuss a bit with me about
whats useful and whats not .. I'd be glad :)

Now let me answer some things:

> Duncan
> 2. Why does it have to be part of lunar/theedge? Can't it be a module
>    on its own? The user asks on #lunar, someone says 'lin lcer' and
>    then run 'lver module' and we'll have a look.

It doesn't have to, but it would bring some advantages, for example we
could track problems "automatically" (at least if a user whishes to
enable this feature, not all users will enable it because of security
issues, they don't like their name and the versions of the kernel
displayed on websites) however - if 20 users enable this feature, and
we see after 2 days (right after we updated application xyz) that 10 of
those 20 users had the same issue compiling it, we know we have done
something wrong.. (Yes, this shouldn't happen.)

> Duncan
> 3. Bearing in mind that the current Bug Tracker needs a good clean out,
>    who maintains the lcer reports page?

We have two options here. A "solutions" part is integrated, this means
a developer (option 1) could answer a problem report with a "solution",
or even a user (option 2) if we open the solution/message part to
everyone. I don't know which is better. The good thing about lcer is,
that it merges equal problems, so there's no need to make posts like
"this is a copy of bug report xyz" which is the case in most available
bug trackers. I might be able to link username and passwords of
developers with some help of striker with the lunar page to simplify
login. A few things can be done automatically by the system, for
example if someone uses unsupported optimizations, the system could
print out "Sorry, you're using not-safe-optimizations, we aren't
supporting this."

> Stefan
> On the contrary, I often find it necessary to ask for the compile log,
> or at least the last 100 rows or so. I like the idea anyway.

This leads to the question: Should i fetch the whole compile log, or
only the last 100/200 lines?

> Stefan
> The system could be self cleaning, logs older than X months get nuked.
> Least effort from devs is the way to go, if it can be automated it
> should :)

Yes, we could let's say close problems after 1 or 2 months, and display
them as closed/solved and after another 2-3 months we could nuke them
(delete). For that i need some good values from you :) (how many months
for what or no delete at all, just "close")

Another Question is: Should a user be able to post additional
information? Or will this just end in confusion? (the less to read, the
easier to help)


From duncan.gibson at xs4all.nl  Sat May 15 19:02:29 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sat, 15 May 2010 19:02:29 +0200
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <1273936136.22568.20.camel@localhost>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
	<15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
	<1273936136.22568.20.camel@localhost>
Message-ID: <56bae9baa8554090f1ffeaebb04ebebb.squirrel@webmail.xs4all.nl>

Duncan:
>> 1. most users who get to #lunar usually only need a hint to get going,
>>    there aren't that many who are asked for compile logs, etc.
>>    lcer.sh is still a good idea to be able to get the information.

Ratler:
> On the contrary, I often find it necessary to ask for the compile log,
> or at least the last 100 rows or so. I like the idea anyway.

I bow to your greater experience and wisdom :-)

Duncan:
>> 2. Why does it have to be part of lunar/theedge? Can't it be a module
>>    on its own? The user asks on #lunar, someone says 'lin lcer' and
>>    then run 'lver module' and we'll have a look.

Ratler:
> I think it would fit even better into lunar-tools.

Ah! I didn't explain myself well enough. I meant, "why does it have to
be part of lunar/theedge *NOW* while it is being developed?" lcer could
start out as a standalone module while it was being debugged, which would
avoid any problems integrating it into lunar/theedge, or needing someone
to wave the dead goat on sofar's behalf. In the long term I agree that
it should be part of the lunar tools.

Duncan:
>> It's a bit like sofar's module submission queue and review system. It's
>> a good idea, but really needs more people to use it...

Ratler:
> Sofars idea is great, it's just the implementation from the developers
> side that should be easier. Right now it's to much of an effort to work
> through the queue, but that's in my opinion. That's why there are so few
> of the developers using it. I for one love the fact that we let the
> users assist us. If we make it even more simple I'm sure most devs would
> come to love it.

I like sofar's module submission system and queue page. It's much better
than user contributions going past on the mailing list and then getting
forgotten about. However, it's unfortunate that a developer has to login
to doppio to be able to run the review script, when most of the submissions
probably require testing on a local desktop first. From my experience, it
makes for a bit of a weird workflow, but I can't see how to improve it:
http://wiki.lunar-linux.org/index.php/Module_Submission_for_developers

Cheers
Duncan


From auke at foo-projects.org  Sat May 15 22:35:13 2010
From: auke at foo-projects.org (Auke Kok)
Date: Sat, 15 May 2010 13:35:13 -0700
Subject: lcer - lunar compile error report (simplifying support)
In-Reply-To: <56bae9baa8554090f1ffeaebb04ebebb.squirrel@webmail.xs4all.nl>
References: <20100514123120.d7b77131.jean.bruenn@ip-minds.de>
	<15c70df08fe4a9d6f0034fdfba1f37ae.squirrel@webmail.xs4all.nl>
	<1273936136.22568.20.camel@localhost>
	<56bae9baa8554090f1ffeaebb04ebebb.squirrel@webmail.xs4all.nl>
Message-ID: <4BEF0581.9030809@foo-projects.org>

Duncan Gibson wrote:
> Duncan:
>>> 1. most users who get to #lunar usually only need a hint to get going,
>>>    there aren't that many who are asked for compile logs, etc.
>>>    lcer.sh is still a good idea to be able to get the information.
> 
> Ratler:
>> On the contrary, I often find it necessary to ask for the compile log,
>> or at least the last 100 rows or so. I like the idea anyway.
> 
> I bow to your greater experience and wisdom :-)
> 
> Duncan:
>>> 2. Why does it have to be part of lunar/theedge? Can't it be a module
>>>    on its own? The user asks on #lunar, someone says 'lin lcer' and
>>>    then run 'lver module' and we'll have a look.
> 
> Ratler:
>> I think it would fit even better into lunar-tools.
> 
> Ah! I didn't explain myself well enough. I meant, "why does it have to
> be part of lunar/theedge *NOW* while it is being developed?" lcer could
> start out as a standalone module while it was being debugged, which would
> avoid any problems integrating it into lunar/theedge, or needing someone
> to wave the dead goat on sofar's behalf. In the long term I agree that
> it should be part of the lunar tools.

there are several clean solutions to this problem:

- design a 'crash' feedback tool as a lunar plugin

- keep the plugin outside of lunar/lunar-tools for now (so devs can 
test/evaluate it). Later when it's stable and easy to understand, merge 
the plugin in to lunar-tools.

- have the plugin submit all compile failures, download failures 
automatically (or not) based on a user setting


> 
> Duncan:
>>> It's a bit like sofar's module submission queue and review system. It's
>>> a good idea, but really needs more people to use it...
> 
> Ratler:
>> Sofars idea is great, it's just the implementation from the developers
>> side that should be easier. Right now it's to much of an effort to work
>> through the queue, but that's in my opinion. That's why there are so few
>> of the developers using it. I for one love the fact that we let the
>> users assist us. If we make it even more simple I'm sure most devs would
>> come to love it.
> 
> I like sofar's module submission system and queue page. It's much better
> than user contributions going past on the mailing list and then getting
> forgotten about. However, it's unfortunate that a developer has to login
> to doppio to be able to run the review script, when most of the submissions
> probably require testing on a local desktop first. From my experience, it
> makes for a bit of a weird workflow, but I can't see how to improve it:
> http://wiki.lunar-linux.org/index.php/Module_Submission_for_developers

I wonder if we can have the submissions entered in to a git-managed 
queue. This way developers can pull/push in that queue remotely.

this is a bit different than a crash-report system, which should just be 
a 'dump' of reports, nothing more. Kinda like kerneloops.org.


Auke

From striker at lunar-linux.org  Tue May 18 14:56:21 2010
From: striker at lunar-linux.org (Jon South)
Date: Tue, 18 May 2010 14:56:21 +0200 (CEST)
Subject: Developer (and user/fan) IRC Cloaks on Freenode
Message-ID: <20100518125621.D5B379B221@doppio.foo-projects.org>

Just an FYI to anyone that frequents the #lunar channel on Freenode:

If you'd like a custom lunar-related cloak, such as lunar-linux/developer/user (devs only) or lunar-linux/user/user (any non-dev), email me your request or reply here and I'll try to get them set up.

Thanks!

From striker at lunar-linux.org  Tue May 18 16:23:19 2010
From: striker at lunar-linux.org (Jon South)
Date: Tue, 18 May 2010 09:23:19 -0500
Subject: Developer (and user/fan) IRC Cloaks on Freenode
In-Reply-To: <20100518125621.D5B379B221@doppio.foo-projects.org>
References: <20100518125621.D5B379B221@doppio.foo-projects.org>
Message-ID: <4BF2A2D7.9070207@lunar-linux.org>

On 2010.05.18 07:56:21, Jon South wrote:
> Just an FYI to anyone that frequents the #lunar channel on Freenode:
>
> If you'd like a custom lunar-related cloak, such as lunar-linux/developer/user (devs only) or lunar-linux/user/user (any non-dev), email me your request or reply here and I'll try to get them set up.
>
> Thanks!

I also should have noted that you must include your *account name* for 
services... not just your nick (unless it's the same). Don't know it? 
Just '/msg nickserv info' while identified.

Danke.

From striker at lunar-linux.org  Tue May 18 16:36:01 2010
From: striker at lunar-linux.org (Jon South)
Date: Tue, 18 May 2010 09:36:01 -0500
Subject: Developer (and user/fan) IRC Cloaks on Freenode
In-Reply-To: <AANLkTiltQxNGcfsX-Ccxs_UB1ehmIB0lyVp6C5giqJ8Q@mail.gmail.com>
References: <20100518125621.D5B379B221@doppio.foo-projects.org>
	<AANLkTiltQxNGcfsX-Ccxs_UB1ehmIB0lyVp6C5giqJ8Q@mail.gmail.com>
Message-ID: <4BF2A5D1.4010807@lunar-linux.org>

On 2010.05.18 09:11:06, samuel wrote:
...snip...
> I still have a cloak of xfce as well.. prefer to keep that one somehow as
> well

Unpossible ;)

Can't have 2 cloaks on a single IRC client.

From striker at lunar-linux.org  Tue May 18 16:39:23 2010
From: striker at lunar-linux.org (Jon South)
Date: Tue, 18 May 2010 09:39:23 -0500
Subject: Developer (and user/fan) IRC Cloaks on Freenode
In-Reply-To: <AANLkTikntI9XWOZW1g9Q8RL0ZCs3hc0ua9FSVH1NxZbK@mail.gmail.com>
References: <20100518125621.D5B379B221@doppio.foo-projects.org>	
	<4BF2A2D7.9070207@lunar-linux.org>
	<AANLkTikntI9XWOZW1g9Q8RL0ZCs3hc0ua9FSVH1NxZbK@mail.gmail.com>
Message-ID: <4BF2A69B.4080901@lunar-linux.org>

On 2010.05.18 09:36:22, Drew Kelling wrote:
> Dont know if your last email applied to me or not but here is the output
> from nickserv info

Only this is needed:

> [10:33] [Notice] -NickServ- Information on Pacmanlives (account Pacmanlives
> ):

Keep the rest private for yourself ;)

From engelsman at lunar-linux.org  Sat May 29 10:53:06 2010
From: engelsman at lunar-linux.org (engelsman at lunar-linux.org)
Date: Sat, 29 May 2010 10:53:06 +0200
Subject: submission ZopeInterface.patch was rejected
Message-ID: <20100529090433.8632F9B21A@doppio.foo-projects.org>

Hi,

I've rejected your patch for 2 reasons:

1. the original version built for me without your change

2. the UPDATED field should not have been updated because the patch
   did not involve a new version, or a required bug-fix, so everyone
   would have rebuilt it during an update even if there was no need

I don't run any local web servers on this box, so I don't know whether
your patch really addressed a run-time rather than a build problem.

On a vaguely related note, the Zope module itself does not build for
Python-2.6.5. Are you using Zope too? If so, can you check it out?

I found that changing the sedit in BUILD to insert 2.6.5 does not
allow immediate install. Changing the sedit to '/TARGET=/s:2.4.3:2.6.5:'
shows assert errors during the build, but Zope does install.
However, as I can't test that it works, I didn't make this change.

Thank you for submitting updates to us!


From duncan.gibson at xs4all.nl  Sun May 30 14:36:12 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sun, 30 May 2010 14:36:12 +0200
Subject: setuptools for Python modules
Message-ID: <b7068732478a45808e7ce1c7a929154e.squirrel@webmail.xs4all.nl>

I just investigated a submission for a new module, simplejson.
This is a Python module that uses  Python setup for installation.
Cool. There's already a setuptools module, but simplejson did
not have a dependency on it, and I didn't have it installed.

But when I installed simplejson, something was clever enough
to first install the Python setup tools directly, bypassing the
setuptools module completely. So the setuptools module still
appears as a "not installed" module.

Question: is it worthwhile to:
(a) add "depends setuptools" to the new simplejson module,
    and potentially a lot of other python based modules, or
(b) just let modules auto-install it if needed outside of the
    lunar package management system and hence untracked, or
(c) somehow add setuptools as a post-install to Python itself?

Cheers
Duncan