From duncan.gibson at xs4all.nl Wed Mar 4 01:04:17 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 4 Mar 2009 01:04:17 +0100 (CET) Subject: Module submission queue status Message-ID: <16293.82.93.24.95.1236125057.squirrel@webmail.xs4all.nl> OK guys [and gals?], I've worked my way through the submissions queue as far as I can, and what is left over is: a) gnome related because I don't want to have to install half of gnome to test a module, s I leave them to zmcgrew; b) X related, so I leave them to El_Angelo; c) xfce4 related, so I leave them to JPohlmann? d) 64-bit, as I can't test it; e) ruby related, so I leave it to dagbrown f) fox, so I leave to MAINTAINER=ratler g) otherwise outside my expertise Cheers Duncan From jean.bruenn at ip-minds.de Wed Mar 4 01:06:01 2009 From: jean.bruenn at ip-minds.de (Jean-Michel Bruenn) Date: Wed, 04 Mar 2009 01:06:01 +0100 Subject: Module submission queue status In-Reply-To: <16293.82.93.24.95.1236125057.squirrel@webmail.xs4all.nl> References: <16293.82.93.24.95.1236125057.squirrel@webmail.xs4all.nl> Message-ID: <49ADC5E9.2050507@ip-minds.de> Hi Duncan, i could test the 64-Bit stuff. Where's the submission queue and whom should i report if tested? Cheers Jean Duncan Gibson wrote: > OK guys [and gals?], > > I've worked my way through the submissions queue as far as I can, > and what is left over is: > a) gnome related because I don't want to have to install half > of gnome to test a module, s I leave them to zmcgrew; > b) X related, so I leave them to El_Angelo; > c) xfce4 related, so I leave them to JPohlmann? > d) 64-bit, as I can't test it; > e) ruby related, so I leave it to dagbrown > f) fox, so I leave to MAINTAINER=ratler > g) otherwise outside my expertise > > Cheers > Duncan > > _______________________________________________ > Lunar-dev mailing list > Lunar-dev at lunar-linux.org > http://foo-projects.org/mailman/listinfo/lunar-dev > From ratler at lunar-linux.org Wed Mar 4 07:10:55 2009 From: ratler at lunar-linux.org (Stefan Wold) Date: Wed, 04 Mar 2009 07:10:55 +0100 Subject: Module submission queue status In-Reply-To: <16293.82.93.24.95.1236125057.squirrel@webmail.xs4all.nl> References: <16293.82.93.24.95.1236125057.squirrel@webmail.xs4all.nl> Message-ID: <1236147055.27874.4.camel@localhost> On Wed, 2009-03-04 at 01:04 +0100, Duncan Gibson wrote: > OK guys [and gals?], > > I've worked my way through the submissions queue as far as I can, > and what is left over is: Great work :) > d) 64-bit, as I can't test it; I can test 64-bit stuff if needed. > f) fox, so I leave to MAINTAINER=ratler I'll take care of this one. -- Sincerely Stefan Wold Lunar Linux developer - PGP public key 6E810F05 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From engelsman at lunar-linux.org Sat Mar 7 10:41:08 2009 From: engelsman at lunar-linux.org (engelsman at lunar-linux.org) Date: Sat, 07 Mar 2009 10:41:08 +0100 Subject: thank you for the conky.patch submission Message-ID: <20090307095143.3194BF31DC@doppio.foo-projects.org> Hi, I've just accepted your patch for "conky" because it builds, installs and runs OK, but I installed it without bmpx support. I notice that the summary shown at the end of the configure stage and the screenshots on the conky web page suggest that it should be possible to enable support for other music players. Would you be interested in looking at this and re-submitting? Cheers engelsman From engelsman at lunar-linux.org Sat Mar 7 13:46:51 2009 From: engelsman at lunar-linux.org (engelsman at lunar-linux.org) Date: Sat, 07 Mar 2009 13:46:51 +0100 Subject: submission galculator.patch was rejected Message-ID: <20090307125438.ED157F4100@doppio.foo-projects.org> Hi, This is to notify you that your submission "galculator.patch" was rejected Most likely this is because: Although the patch applied cleanly, and then downloaded, built and installed without obvious problem, it failed to run here. It is quite likely that some module is missing on my machine, so could you please check that the DEPENDS list is complete? The error message I get is: duncan at wired /tmp $ galculator [galculator] configuration file: couldn't open configuration file \ /home/duncan/.galculator for reading. Nothing to worry about if \ you are starting galculator for the first time. Using defaults. (galculator:26494): GLib-GObject-CRITICAL **: g_object_ref: \ assertion `G_IS_OBJECT (object)' failed Segmentation fault duncan at wired /tmp $ Thank you for submitting updates to us! From dennisveatch at bellsouth.net Mon Mar 9 03:16:27 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 8 Mar 2009 22:16:27 -0400 Subject: [Lunar-commits] recordmydesktop: New module added (version 0.3.8.1). In-Reply-To: <20090309015453.6D5F49B1C5@doppio.foo-projects.org> References: <20090309015453.6D5F49B1C5@doppio.foo-projects.org> Message-ID: <200903082216.27686.dennisveatch@bellsouth.net> On Sunday 08 March 2009 10:53:39 pm Jannis Pohlmann wrote: > commit 0bae958ee314bb6d3ddf1116643f72b5d620011e > Author: Jannis Pohlmann > Date: Mon Mar 9 03:53:39 2009 +0100 > > recordmydesktop: New module added (version 0.3.8.1). > > This is a pretty neat command line application to record your desktop > session. It produces OGG Theora videos and supports sound capturing. > --- > x11-utils/recordmydesktop/DEPENDS | 7 +++++++ > x11-utils/recordmydesktop/DETAILS | 18 ++++++++++++++++++ > 2 files changed, 25 insertions(+), 0 deletions(-) > > diff --git a/x11-utils/recordmydesktop/DEPENDS > b/x11-utils/recordmydesktop/DEPENDS new file mode 100644 > index 0000000..8922bd5 > --- /dev/null > +++ b/x11-utils/recordmydesktop/DEPENDS > @@ -0,0 +1,7 @@ > +depends alsa-lib > +depends libXext > +depends libXfixes > +depends libXdamage > +depends libvorbis > +depends libogg > +depends libtheora > diff --git a/x11-utils/recordmydesktop/DETAILS > b/x11-utils/recordmydesktop/DETAILS new file mode 100644 > index 0000000..e1b5fc4 > --- /dev/null > +++ b/x11-utils/recordmydesktop/DETAILS > @@ -0,0 +1,18 @@ > + MODULE=recordmydesktop > + VERSION=0.3.8.1 > + SOURCE=$MODULE-$VERSION.tar.gz > + SOURCE_URL=$SFORGE_URL/$MODULE > + SOURCE_VFY=sha1:4be18baa70da88a7f228591057f2e7ff51b31de4 > + WEB_SITE=http://recordmydesktop.sf.net > + ENTERED=20090309 > + UPDATED=20090309 > + SHORT="Command-line desktop session recorder" > + MAINTAINER=jannis at lunar-linux.org > + > +cat << EOF > +recordMyDesktop is a desktop session recorder for GNU/Linux that > +attempts to be easy to use, yet also effective at it's primary task. > +As such, the program is separated in two parts; a simple command line > +tool that performs the basic tasks of capturing and encoding and an > +interface that exposes the program functionality in a usable way. > +EOF > _______________________________________________ That module already exists in moonbase/video/recordmydesktop :) Though your DEPENDS is more complete than the existing one. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From samuel.verstraete at gmail.com Tue Mar 10 13:14:21 2009 From: samuel.verstraete at gmail.com (samuel) Date: Tue, 10 Mar 2009 13:14:21 +0100 Subject: wicd Message-ID: Hi i have a module for wicd (a wireless connection manager that actually works and does not require half of gnome) It needs to start a service (wicd) for which i created a init.d directory in the module directory and a "wicd" script in there Adding the script with chkconfig --add wicd works like a charm, and it is listed with chkconfig --list. But i had to manually put the script in /etc/init.d... any ideas? You can find the module at: http://foo-projects.org/git/?p=elangelo/moonbase.git;a=tree;f=wifi/wicd;h=56ad84e199ee92ba017af6107831076de1550ce7;hb=refs/heads/elangelo gr,EA From samuel.verstraete at gmail.com Tue Mar 10 14:18:13 2009 From: samuel.verstraete at gmail.com (samuel) Date: Tue, 10 Mar 2009 14:18:13 +0100 Subject: wicd In-Reply-To: References: Message-ID: git pull git://lunar-linux.org/lunar/moonbase.git moonbase.git cd moonbase.git git branch elangelo git pull git://lunar-linux.org/lunar/moonbase.git elangelo it will error out with some errors but you can just copy whatever is in moonbase.git/wifi/wicd to your home dir and then move it to your moonbase On Tue, Mar 10, 2009 at 1:14 PM, samuel wrote: > Hi i have a module for wicd (a wireless connection manager that > actually works and does not require half of gnome) > > It needs to start a service (wicd) for which i created a init.d > directory in the module directory and a "wicd" script in there > > Adding the script with chkconfig --add wicd works like a charm, and it > is listed with chkconfig --list. But i had to manually put the script > in /etc/init.d... any ideas? > > You can find the module at: > http://foo-projects.org/git/?p=elangelo/moonbase.git;a=tree;f=wifi/wicd;h=56ad84e199ee92ba017af6107831076de1550ce7;hb=refs/heads/elangelo > > gr,EA > From samuel.verstraete at gmail.com Tue Mar 10 15:17:36 2009 From: samuel.verstraete at gmail.com (samuel) Date: Tue, 10 Mar 2009 15:17:36 +0100 Subject: wicd In-Reply-To: References: Message-ID: Jannis was able to figure out why this didn't work. Seems like our initd.plugin doesn't allow tabs as seperator. As i just copied this init script from wicd itself it does contain tabs. As chkconfig just works correctly with the init script with tabs it seems that initd.plugin should be patched to allow tabs. hence the patch of Jannis: http://lunar-linux.org/~jannis/initd-plugin.patch gr,S. (kudos++ for Jannis for finding this one so quickly) On Tue, Mar 10, 2009 at 2:18 PM, samuel wrote: > git pull git://lunar-linux.org/lunar/moonbase.git moonbase.git > cd moonbase.git > git branch elangelo > git pull git://lunar-linux.org/lunar/moonbase.git elangelo > > it will error out with some errors but you can just copy whatever is > in moonbase.git/wifi/wicd to your home dir and then move it to your > moonbase > > > > On Tue, Mar 10, 2009 at 1:14 PM, samuel wrote: >> Hi i have a module for wicd (a wireless connection manager that >> actually works and does not require half of gnome) >> >> It needs to start a service (wicd) for which i created a init.d >> directory in the module directory and a "wicd" script in there >> >> Adding the script with chkconfig --add wicd works like a charm, and it >> is listed with chkconfig --list. But i had to manually put the script >> in /etc/init.d... any ideas? >> >> You can find the module at: >> http://foo-projects.org/git/?p=elangelo/moonbase.git;a=tree;f=wifi/wicd;h=56ad84e199ee92ba017af6107831076de1550ce7;hb=refs/heads/elangelo >> >> gr,EA >> > From samuel.verstraete at gmail.com Tue Mar 10 15:18:12 2009 From: samuel.verstraete at gmail.com (samuel) Date: Tue, 10 Mar 2009 15:18:12 +0100 Subject: wicd In-Reply-To: References: Message-ID: On Tue, Mar 10, 2009 at 3:17 PM, samuel wrote: > Jannis was able to figure out why this didn't work. > Seems like our initd.plugin doesn't allow tabs as seperator. As i just > copied this init script from wicd itself it does contain tabs. As > chkconfig just works correctly with the init script with tabs it seems > that initd.plugin should be patched to allow tabs. > > hence the patch of Jannis: > http://lunar-linux.org/~jannis/initd-plugin.patch > forgot to add... I have no write rights on the lunar tools so could one of you that has write rights include this? > gr,S. > (kudos++ for Jannis for finding this one so quickly) > > On Tue, Mar 10, 2009 at 2:18 PM, samuel wrote: >> git pull git://lunar-linux.org/lunar/moonbase.git moonbase.git >> cd moonbase.git >> git branch elangelo >> git pull git://lunar-linux.org/lunar/moonbase.git elangelo >> >> it will error out with some errors but you can just copy whatever is >> in moonbase.git/wifi/wicd to your home dir and then move it to your >> moonbase >> >> >> >> On Tue, Mar 10, 2009 at 1:14 PM, samuel wrote: >>> Hi i have a module for wicd (a wireless connection manager that >>> actually works and does not require half of gnome) >>> >>> It needs to start a service (wicd) for which i created a init.d >>> directory in the module directory and a "wicd" script in there >>> >>> Adding the script with chkconfig --add wicd works like a charm, and it >>> is listed with chkconfig --list. But i had to manually put the script >>> in /etc/init.d... any ideas? >>> >>> You can find the module at: >>> http://foo-projects.org/git/?p=elangelo/moonbase.git;a=tree;f=wifi/wicd;h=56ad84e199ee92ba017af6107831076de1550ce7;hb=refs/heads/elangelo >>> >>> gr,EA >>> >> > From zbiggy at o2.pl Wed Mar 11 22:51:00 2009 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Wed, 11 Mar 2009 22:51:00 +0100 Subject: udev 138 present in zbiggy-WIP In-Reply-To: <200902232002.27585.dennisveatch@bellsouth.net> References: <200902240051.18673.zbiggy@o2.pl> <200902232002.27585.dennisveatch@bellsouth.net> Message-ID: <200903112251.00687.zbiggy@o2.pl> Tuesday 24 February 2009 02:02:27 Dennis Veatch wrote: > One only curious thing > I noticed in /var/log/messages. There was only one instance of udev > starting and that was for 128, even though the box had been rebooted > several times, and I had just barely gotten past the lunar rebuild part, > recompile kernel, etc. I was expecting to see more than one. I mention that > because a grep on messages after installing 138 and a reboot, there were no > messages about udev 138 starting. > A udev stop/start produced one. > > On a side note after starting udev, dmesg showed this; > > udev: starting version 138 > udev: deprecated sysfs layout; update the kernel or disable > CONFIG_SYSFS_DEPRECATED; some udev features will not work correctly > > Right now your looking pretty good. You should lrm old udev or make uninstall if you compiled manualy. Also lin lunar-init as it contains new mount script. CONFIG_SYSFS_DEPRECATED should be disabled in kernel - this everyone should apply. > Again just a minor thing with udev starting up, obviously 138 is working > but not throwing that into /var/log/messages. Not big deal, but it would > warm my fuzzies if a notification was given some where. I have just added udev version info to udev daemon script and to mount script. run_with_msg in mount script can be replaced with echo if your log writer does not catch it to file. > Oh, and you will want to do a `lunar fix hal`. How do you think: Is it worth to add this to post_install of udev or leave it to user as it is now. I never did it on any udev 13x and everything works for me. have a nice day, Zbigniew 'zbiggy' Luszpinski From auke at foo-projects.org Thu Mar 12 17:47:45 2009 From: auke at foo-projects.org (Auke Kok) Date: Thu, 12 Mar 2009 09:47:45 -0700 Subject: [Lunar-commits] MPlayer: eep. Don't think we want that rolling. In-Reply-To: <20090312120536.B70A79B1B3@doppio.foo-projects.org> References: <20090312120536.B70A79B1B3@doppio.foo-projects.org> Message-ID: <49B93CB1.2080108@foo-projects.org> Dennis 'stumbles' Veatch wrote: > commit 15a700d88ea77973b2f88d54a6ff18ad87755133 > Author: Dennis 'stumbles' Veatch > Date: Thu Mar 12 08:05:06 2009 -0400 > > MPlayer: eep. Don't think we want that rolling. > --- > video/MPlayer/DETAILS | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/video/MPlayer/DETAILS b/video/MPlayer/DETAILS > index ac33ed5..7f446f1 100644 > --- a/video/MPlayer/DETAILS > +++ b/video/MPlayer/DETAILS > @@ -7,7 +7,7 @@ > SOURCE5=font-arial-iso-8859-7.tar.bz2 > SOURCE6=Blue-1.7.tar.bz2 > SOURCE_DIRECTORY=$BUILD_DIRECTORY/mplayer-checkout-2009-03-11 > - SOURCE_URL[0]=http://www.mplayerhq.hu/MPlayer/releases/ > + SOURCE_URL[0]=$MIRROR_URL this is wrong for sure.... very wrong... Auke From auke at foo-projects.org Thu Mar 12 17:47:04 2009 From: auke at foo-projects.org (Auke Kok) Date: Thu, 12 Mar 2009 09:47:04 -0700 Subject: [Lunar-commits] MPlayer: erm, here is the optional_depends for live555 In-Reply-To: <20090312004310.6F0FEF431E@doppio.foo-projects.org> References: <20090312004310.6F0FEF431E@doppio.foo-projects.org> Message-ID: <49B93C88.6090503@foo-projects.org> Dennis 'stumbles' Veatch wrote: > commit d2438ea187e4b90402eac44ed66cf7dbd85fd098 > Author: Dennis 'stumbles' Veatch > Date: Wed Mar 11 20:42:24 2009 -0400 > > MPlayer: erm, here is the optional_depends for live555 > --- > video/MPlayer/DEPENDS | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/video/MPlayer/DEPENDS b/video/MPlayer/DEPENDS > index 91e7ae9..8b3c7c7 100644 > --- a/video/MPlayer/DEPENDS > +++ b/video/MPlayer/DEPENDS > @@ -17,5 +17,6 @@ optional_depends libggi "--enable-ggi" "--disable-ggi" "General Gr > optional_depends libggiwmh "--enable-ggiwmh" "--disable-ggiwmh" "GGI extension support" > optional_depends amrnb "" "--disable-libamr_nb" "AMR narrowband support" > optional_depends amrwb "" "--disable-libamr_wb" "AMR wideband support" > -optional_depends mpeg2dec "" "" "for mpeg-1 and mpeg-2 support" > -optional_depends x264-snapshot "" "" "for H264/AVC video stream support" > +optional_depends mpeg2dec "" "" "for mpeg-1 and mpeg-2 support" > +optional_depends x264-snapshot "" "" "for H264/AVC video stream support" > +optional_depends "live555" "" "" "for RTP/RTCP, RTSP, SIP support" without --with-feature and --without-feature arguments these are really useless... please try to fill in these fields, especially the "--without-feature" field is important... Auke From jannis at lunar-linux.org Sun Mar 15 17:28:57 2009 From: jannis at lunar-linux.org (Jannis Pohlmann) Date: Sun, 15 Mar 2009 17:28:57 +0100 Subject: default_python_build and initrd detection patches Message-ID: <20090315172857.2c0ec87d@lunar-linux.org> Hey guys, I don't know exactly who has commit access for http://svn.foo-projects.org/svn/lunar/lunar/, but here are two patches for you to consider. 1. lunar-default_python_build.patch -- We have a lot of python modules which all share the same build instructions: python setup.py config && prepare_install && python setup.py install The attached patch introduces default_python_build(). If there is an executable ./configure script or no setup.py, it falls back to default_build. Otherwise it runs python setup.py build && prepare_install && python setup.py install It uses "setup.py build" instead of "setup.py config" because the config command doesn't always seem to be available. 2. lunar-initd-detection.patch -- This is a patch for the initd.plugin. It currently uses the expression '# chkconfig: ' to detect init scripts. However, there is no need to use spaces in the expression, especially not after the 'chkconfig:'. Perl-style regular expressions in grep are a POSIX extension, so '\t' won't work here. Thus, the patch changes '# chkconfig: ' to '^# chkconfig:' which improves things a bit. Cheers, Jannis -------------- next part -------------- A non-text attachment was scrubbed... Name: lunar-default-python-build.patch Type: text/x-patch Size: 627 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lunar-initd-detection.patch Type: text/x-patch Size: 1516 bytes Desc: not available URL: From engelsman at lunar-linux.org Sat Mar 21 21:21:27 2009 From: engelsman at lunar-linux.org (engelsman at lunar-linux.org) Date: Sat, 21 Mar 2009 21:21:27 +0100 Subject: submission audacious.patch was rejected Message-ID: <20090321203117.5D39C9B1D6@doppio.foo-projects.org> Hi, This mail is to notify you that your submission "audacious.patch" was rejected after the following discussion on #lunar: engelsman | what's the feeling on brebs' audacious submission with all of the debian patches? Striker | depends on the nature of the patches Striker | does it require them? engelsman | haven't tried it yet but wondered whether it fitted with the Lunar idea of staying as close to the original source as possible Ratler | Imo any patch that actually do improve things should be added Striker | debian is not known for improving things Striker | they're known for backporting for the sake of backporting Ratler | hehe that's true, but at least take a look at the patches and see what they do. If it is cruft, just skip em Striker | it's disturbing that they're debian/patches/XXX Striker | i'd actually reject it Striker | the patches need to be explained what they do Ratler | Yea, and the part where he depend on their repo to download the source is just plain wrong too Striker | using a ton of patches simply because one or two contain bugfixes? dumb indeed Striker | plus, bugfixes should go upstream Striker | he even REMOVED the original source Striker | and replaced it with ubuntu's Striker | no, this needs to be rejected Ratler | yup i agree Thank you for submitting updates to us! From dennisveatch at bellsouth.net Sun Mar 22 13:30:35 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 22 Mar 2009 08:30:35 -0400 Subject: default_cmake Message-ID: <200903220830.35828.dennisveatch@bellsouth.net> Been playing around with a new default_cmake function for build.lunar. There isn't all that much to it really. Just using the the cmake entries in the kde4 BUILD modules and poking that into default_cmake. It will work for those cmake+modules that use " cmake ." and "cmake $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, avidemux, telepathy-qt, and others. If you want to give it a spin here it is. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.patch Type: text/x-patch Size: 570 bytes Desc: not available URL: From dennisveatch at bellsouth.net Mon Mar 23 04:01:05 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sun, 22 Mar 2009 23:01:05 -0400 Subject: default_cmake In-Reply-To: <200903220830.35828.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> Message-ID: <200903222301.05504.dennisveatch@bellsouth.net> On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote: > Been playing around with a new default_cmake function for build.lunar. > There isn't all that much to it really. Just using the the cmake entries in > the kde4 BUILD modules and poking that into default_cmake. It will work for > those cmake+modules that use " cmake ." and "cmake $SOURCE_DIRECTORY". > I have tried with; kdelibs4, kdebindings4, avidemux, telepathy-qt, and > others. If you want to give it a spin here it is. Here is a slight change to the last patch. All it does is add a default_cmake_build to include default_make. Have not found a cmake dependent module that has failed to build. One thing I would like to incorporate is the ability of build.lunar (or appropriate script) to, in a sane way, detect if it should use default_build or default_cmake_build. Any thoughts about about how to do that is appreciated. One thought was to do something like PSAFE such as CMAKE=yes. Not real fond of that idea, nor looked at the logic to make it happen. Another thought. Alter the run_build function starting on line 396. The idea here is to test for the presence of CMakeLists.txt, if there, then default_cmake_build, else default_build. AFAICT from the cmake documentation, any project using cmake, will at the minimum have CMakeLists.txt in its top level directory. Anyway, that's about as far as the gray matter has gotten. So feel free to critique on any level. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.patch Type: text/x-patch Size: 858 bytes Desc: not available URL: From dennisveatch at bellsouth.net Mon Mar 23 13:39:32 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 23 Mar 2009 08:39:32 -0400 Subject: default_cmake In-Reply-To: <200903222301.05504.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903222301.05504.dennisveatch@bellsouth.net> Message-ID: <200903230839.32834.dennisveatch@bellsouth.net> On Sunday 22 March 2009 11:01:05 pm Dennis Veatch wrote: > On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote: > > Been playing around with a new default_cmake function for build.lunar. > > There isn't all that much to it really. Just using the the cmake entries > > in the kde4 BUILD modules and poking that into default_cmake. It will > > work for those cmake+modules that use " cmake ." and "cmake > > $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, avidemux, > > telepathy-qt, and others. If you want to give it a spin here it is. > > Here is a slight change to the last patch. All it does is add a > default_cmake_build to include default_make. Have not found a cmake > dependent module that has failed to build. > > One thing I would like to incorporate is the ability of build.lunar (or > appropriate script) to, in a sane way, detect if it should use > default_build or default_cmake_build. > > Any thoughts about about how to do that is appreciated. One thought was to > do something like PSAFE such as CMAKE=yes. Not real fond of that idea, nor > looked at the logic to make it happen. > > Another thought. Alter the run_build function starting on line 396. The > idea here is to test for the presence of CMakeLists.txt, if there, then > default_cmake_build, else default_build. AFAICT from the cmake > documentation, any project using cmake, will at the minimum have > CMakeLists.txt in its top level directory. > > Anyway, that's about as far as the gray matter has gotten. So feel free to > critique on any level. Here is a third installment. Just a simple elif test for CMakeLists.txt, if ! then default_build. It works with a number of modules that do not have a BUILD, and those with BUILD+cmake. Not seen any issues as yet. Anyway, here it is. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.patch Type: text/x-patch Size: 1916 bytes Desc: not available URL: From dennisveatch at bellsouth.net Mon Mar 23 14:40:38 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 23 Mar 2009 09:40:38 -0400 Subject: default_cmake In-Reply-To: <200903230839.32834.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903222301.05504.dennisveatch@bellsouth.net> <200903230839.32834.dennisveatch@bellsouth.net> Message-ID: <200903230940.38137.dennisveatch@bellsouth.net> On Monday 23 March 2009 8:39:32 am Dennis Veatch wrote: > On Sunday 22 March 2009 11:01:05 pm Dennis Veatch wrote: > > On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote: > > > Been playing around with a new default_cmake function for build.lunar. > > > There isn't all that much to it really. Just using the the cmake > > > entries in the kde4 BUILD modules and poking that into default_cmake. > > > It will work for those cmake+modules that use " cmake ." and "cmake > > > $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, > > > avidemux, telepathy-qt, and others. If you want to give it a spin here > > > it is. > > > > Here is a slight change to the last patch. All it does is add a > > default_cmake_build to include default_make. Have not found a cmake > > dependent module that has failed to build. > > > > One thing I would like to incorporate is the ability of build.lunar (or > > appropriate script) to, in a sane way, detect if it should use > > default_build or default_cmake_build. > > > > Any thoughts about about how to do that is appreciated. One thought was > > to do something like PSAFE such as CMAKE=yes. Not real fond of that idea, > > nor looked at the logic to make it happen. > > > > Another thought. Alter the run_build function starting on line 396. The > > idea here is to test for the presence of CMakeLists.txt, if there, then > > default_cmake_build, else default_build. AFAICT from the cmake > > documentation, any project using cmake, will at the minimum have > > CMakeLists.txt in its top level directory. > > > > Anyway, that's about as far as the gray matter has gotten. So feel free > > to critique on any level. > > Here is a third installment. Just a simple elif test for CMakeLists.txt, if > ! then default_build. It works with a number of modules that do not have a > BUILD, and those with BUILD+cmake. Not seen any issues as yet. Anyway, > here it is. Ignore that last patch, use this one. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.ver-4.patch Type: text/x-patch Size: 1072 bytes Desc: not available URL: From auke at foo-projects.org Mon Mar 23 16:07:06 2009 From: auke at foo-projects.org (Auke Kok) Date: Mon, 23 Mar 2009 08:07:06 -0700 Subject: default_cmake In-Reply-To: <200903230940.38137.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903222301.05504.dennisveatch@bellsouth.net> <200903230839.32834.dennisveatch@bellsouth.net> <200903230940.38137.dennisveatch@bellsouth.net> Message-ID: <49C7A59A.7010700@foo-projects.org> Dennis Veatch wrote: > On Monday 23 March 2009 8:39:32 am Dennis Veatch wrote: >> On Sunday 22 March 2009 11:01:05 pm Dennis Veatch wrote: >>> On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote: >>>> Been playing around with a new default_cmake function for build.lunar. >>>> There isn't all that much to it really. Just using the the cmake >>>> entries in the kde4 BUILD modules and poking that into default_cmake. >>>> It will work for those cmake+modules that use " cmake ." and "cmake >>>> $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, >>>> avidemux, telepathy-qt, and others. If you want to give it a spin here >>>> it is. >>> Here is a slight change to the last patch. All it does is add a >>> default_cmake_build to include default_make. Have not found a cmake >>> dependent module that has failed to build. >>> >>> One thing I would like to incorporate is the ability of build.lunar (or >>> appropriate script) to, in a sane way, detect if it should use >>> default_build or default_cmake_build. >>> >>> Any thoughts about about how to do that is appreciated. One thought was >>> to do something like PSAFE such as CMAKE=yes. Not real fond of that idea, >>> nor looked at the logic to make it happen. >>> >>> Another thought. Alter the run_build function starting on line 396. The >>> idea here is to test for the presence of CMakeLists.txt, if there, then >>> default_cmake_build, else default_build. AFAICT from the cmake >>> documentation, any project using cmake, will at the minimum have >>> CMakeLists.txt in its top level directory. >>> >>> Anyway, that's about as far as the gray matter has gotten. So feel free >>> to critique on any level. >> Here is a third installment. Just a simple elif test for CMakeLists.txt, if >> ! then default_build. It works with a number of modules that do not have a >> BUILD, and those with BUILD+cmake. Not seen any issues as yet. Anyway, >> here it is. > > Ignore that last patch, use this one. > don't like this patch - it will try to do a cmake build before a GNU make build, which I would prefer to try first. From dennisveatch at bellsouth.net Mon Mar 23 16:56:13 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 23 Mar 2009 11:56:13 -0400 Subject: default_cmake In-Reply-To: <49C7A59A.7010700@foo-projects.org> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903230940.38137.dennisveatch@bellsouth.net> <49C7A59A.7010700@foo-projects.org> Message-ID: <200903231156.13120.dennisveatch@bellsouth.net> On Monday 23 March 2009 11:07:06 am Auke Kok wrote: > Dennis Veatch wrote: > > On Monday 23 March 2009 8:39:32 am Dennis Veatch wrote: > >> On Sunday 22 March 2009 11:01:05 pm Dennis Veatch wrote: > >>> On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote: > >>>> Been playing around with a new default_cmake function for build.lunar. > >>>> There isn't all that much to it really. Just using the the cmake > >>>> entries in the kde4 BUILD modules and poking that into default_cmake. > >>>> It will work for those cmake+modules that use " cmake ." and "cmake > >>>> $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, > >>>> avidemux, telepathy-qt, and others. If you want to give it a spin here > >>>> it is. > >>> > >>> Here is a slight change to the last patch. All it does is add a > >>> default_cmake_build to include default_make. Have not found a cmake > >>> dependent module that has failed to build. > >>> > >>> One thing I would like to incorporate is the ability of build.lunar (or > >>> appropriate script) to, in a sane way, detect if it should use > >>> default_build or default_cmake_build. > >>> > >>> Any thoughts about about how to do that is appreciated. One thought was > >>> to do something like PSAFE such as CMAKE=yes. Not real fond of that > >>> idea, nor looked at the logic to make it happen. > >>> > >>> Another thought. Alter the run_build function starting on line 396. The > >>> idea here is to test for the presence of CMakeLists.txt, if there, then > >>> default_cmake_build, else default_build. AFAICT from the cmake > >>> documentation, any project using cmake, will at the minimum have > >>> CMakeLists.txt in its top level directory. > >>> > >>> Anyway, that's about as far as the gray matter has gotten. So feel free > >>> to critique on any level. > >> > >> Here is a third installment. Just a simple elif test for CMakeLists.txt, > >> if ! then default_build. It works with a number of modules that do not > >> have a BUILD, and those with BUILD+cmake. Not seen any issues as yet. > >> Anyway, here it is. > > > > Ignore that last patch, use this one. > > don't like this patch - it will try to do a cmake build before a GNU > make build, which I would prefer to try first. > > I take it you refer to the change in the run_build function. You are right, only if there is a CMakeLists.txt file. That seemed the simplest way to determine which default build to run. ATM, I don't see another way to determine how to detect when either default build should be run. I am trying to keep this on a kiss level, so If you have something clever in mind please point me in that direction. Unless you are referring to the default_cmake_build function, where it runs the default_cmake function. Maybe that really should be called default_cmake_config, since it is doing a similar thing the default_config does. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From auke at foo-projects.org Mon Mar 23 20:21:09 2009 From: auke at foo-projects.org (Auke Kok) Date: Mon, 23 Mar 2009 12:21:09 -0700 Subject: default_cmake In-Reply-To: <200903231156.13120.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903230940.38137.dennisveatch@bellsouth.net> <49C7A59A.7010700@foo-projects.org> <200903231156.13120.dennisveatch@bellsouth.net> Message-ID: <49C7E125.6020407@foo-projects.org> Dennis Veatch wrote: > I take it you refer to the change in the run_build function. You are right, > only if there is a CMakeLists.txt file. That seemed the simplest way to > determine which default build to run. ATM, I don't see another way to > determine how to detect when either default build should be run. I am trying > to keep this on a kiss level, so If you have something clever in mind please > point me in that direction. > > Unless you are referring to the default_cmake_build function, where it runs > the default_cmake function. Maybe that really should be called > default_cmake_config, since it is doing a similar thing the default_config > does. > just change the order around: attempt to do a default_build first, and if that fails (configure/Makefile are missing) scan for CMake junk... Auke From dennisveatch at bellsouth.net Tue Mar 24 00:27:14 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 23 Mar 2009 19:27:14 -0400 Subject: default_cmake In-Reply-To: <49C7E125.6020407@foo-projects.org> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903231156.13120.dennisveatch@bellsouth.net> <49C7E125.6020407@foo-projects.org> Message-ID: <200903231927.14161.dennisveatch@bellsouth.net> On Monday 23 March 2009 3:21:09 pm Auke Kok wrote: > Dennis Veatch wrote: > > I take it you refer to the change in the run_build function. You are > > right, only if there is a CMakeLists.txt file. That seemed the simplest > > way to determine which default build to run. ATM, I don't see another way > > to determine how to detect when either default build should be run. I am > > trying to keep this on a kiss level, so If you have something clever in > > mind please point me in that direction. > > > > Unless you are referring to the default_cmake_build function, where it > > runs the default_cmake function. Maybe that really should be called > > default_cmake_config, since it is doing a similar thing the > > default_config does. > > just change the order around: attempt to do a default_build first, and > if that fails (configure/Makefile are missing) scan for CMake junk... > > Auke > _______________________________________________ Here is the patch with things reversed, looks for default_build then the cmake "junk" :) Tested with units and physfs. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.ver-5.patch Type: text/x-patch Size: 1089 bytes Desc: not available URL: From jannis at lunar-linux.org Tue Mar 24 00:35:06 2009 From: jannis at lunar-linux.org (Jannis Pohlmann) Date: Tue, 24 Mar 2009 00:35:06 +0100 Subject: default_cmake In-Reply-To: <200903231927.14161.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903231156.13120.dennisveatch@bellsouth.net> <49C7E125.6020407@foo-projects.org> <200903231927.14161.dennisveatch@bellsouth.net> Message-ID: <20090324003506.485aa5c3@lunar-linux.org> Hey guys, I don't want to go off-topic here, but could anyone please comment on the default_python_build and init.d detection patches I sent to this list a bit more than a week ago? Thanks, Jannis From dennisveatch at bellsouth.net Tue Mar 24 00:49:27 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 23 Mar 2009 19:49:27 -0400 Subject: default_python_build and initrd detection patches In-Reply-To: <20090315172857.2c0ec87d@lunar-linux.org> References: <20090315172857.2c0ec87d@lunar-linux.org> Message-ID: <200903231949.27569.dennisveatch@bellsouth.net> On Sunday 15 March 2009 12:28:57 pm Jannis Pohlmann wrote: > Hey guys, > > I don't know exactly who has commit access for > http://svn.foo-projects.org/svn/lunar/lunar/, but here are two patches > for you to consider. > > 1. lunar-default_python_build.patch -- We have a lot of python modules > which all share the same build instructions: > > python setup.py config && > prepare_install && > python setup.py install > > The attached patch introduces default_python_build(). If there is an > executable ./configure script or no setup.py, it falls back to > default_build. Otherwise it runs > > python setup.py build && > prepare_install && > python setup.py install > > It uses "setup.py build" instead of "setup.py config" because the > config command doesn't always seem to be available. > > 2. lunar-initd-detection.patch -- This is a patch for the initd.plugin. > It currently uses the expression '# chkconfig: ' to detect init > scripts. However, there is no need to use spaces in the expression, > especially not after the 'chkconfig:'. Perl-style regular expressions > in grep are a POSIX extension, so '\t' won't work here. Thus, the > patch changes '# chkconfig: ' to '^# chkconfig:' which improves > things a bit. > > Cheers, > Jannis You would want add the default_python_build function name to the run_build function. That will allow for the removal of a BUILD. Tis the reason I wanted the default_cmake_build there. I don't know enough about the python stuff to comment about the "build" versus "config" aspect. Nothing jumps out at me linuar-initd-detection patch. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From auke at foo-projects.org Tue Mar 24 03:55:53 2009 From: auke at foo-projects.org (Auke Kok) Date: Mon, 23 Mar 2009 19:55:53 -0700 Subject: default_cmake In-Reply-To: <20090324003506.485aa5c3@lunar-linux.org> References: <200903220830.35828.dennisveatch@bellsouth.net> <200903231156.13120.dennisveatch@bellsouth.net> <49C7E125.6020407@foo-projects.org> <200903231927.14161.dennisveatch@bellsouth.net> <20090324003506.485aa5c3@lunar-linux.org> Message-ID: <49C84BB9.3090103@foo-projects.org> Jannis Pohlmann wrote: > Hey guys, > > I don't want to go off-topic here, but could anyone please comment on > the default_python_build and init.d detection patches I sent to this > list a bit more than a week ago? in principle all those patches are ok, but like the cmake one, we have to maintain some basic rules for these: 1 - clear difference between "configure" and "build" phases, and run prepare_install in between 2 - prefer GNU make over other build systems by default (IOW, if 'Makefile' exists use it, instead of attempting a CMake build just because 'configure' did not exist). I haven't looked too closely in all the examples flying by, but I can see about merging them in theedge and taking a close look myself to make sure we don't break any modules expecting above behaviour. Auke From dennisveatch at bellsouth.net Tue Mar 24 12:29:43 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Tue, 24 Mar 2009 07:29:43 -0400 Subject: default_cmake In-Reply-To: <49C84BB9.3090103@foo-projects.org> References: <200903220830.35828.dennisveatch@bellsouth.net> <20090324003506.485aa5c3@lunar-linux.org> <49C84BB9.3090103@foo-projects.org> Message-ID: <200903240729.43147.dennisveatch@bellsouth.net> On Monday 23 March 2009 10:55:53 pm Auke Kok wrote: > Jannis Pohlmann wrote: > > Hey guys, > > > > I don't want to go off-topic here, but could anyone please comment on > > the default_python_build and init.d detection patches I sent to this > > list a bit more than a week ago? > > in principle all those patches are ok, but like the cmake one, we have > to maintain some basic rules for these: > > 1 - clear difference between "configure" and "build" phases, and run > prepare_install in between > I think the proposed cmake stuff adheres to that. > 2 - prefer GNU make over other build systems by default (IOW, if > 'Makefile' exists use it, instead of attempting a CMake build just > because 'configure' did not exist). > I don't know of any module that has only a Makefile and does not have a BUILD. So it will be a given a BUILD will exist. Which will cause; if has_module_file $MODULE BUILD ; then run_module_file $MODULE BUILD in the run_build function to kick in before it even thinks about going on to default_build, default_cmake_build, or default_python_build. So I don't atm see that as being a problem. > I haven't looked too closely in all the examples flying by, but I can > see about merging them in theedge and taking a close look myself to make > sure we don't break any modules expecting above behaviour. > > Auke > _______________________________________________ -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From dennisveatch at bellsouth.net Wed Mar 25 17:38:26 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Wed, 25 Mar 2009 12:38:26 -0400 Subject: default_cmake In-Reply-To: <200903240729.43147.dennisveatch@bellsouth.net> References: <200903220830.35828.dennisveatch@bellsouth.net> <49C84BB9.3090103@foo-projects.org> <200903240729.43147.dennisveatch@bellsouth.net> Message-ID: <200903251238.26779.dennisveatch@bellsouth.net> On Tuesday 24 March 2009 7:29:43 am Dennis Veatch wrote: > On Monday 23 March 2009 10:55:53 pm Auke Kok wrote: > > Jannis Pohlmann wrote: > > > Hey guys, > > > > > > I don't want to go off-topic here, but could anyone please comment on > > > the default_python_build and init.d detection patches I sent to this > > > list a bit more than a week ago? > > > > in principle all those patches are ok, but like the cmake one, we have > > to maintain some basic rules for these: > > > > 1 - clear difference between "configure" and "build" phases, and run > > prepare_install in between > > I think the proposed cmake stuff adheres to that. > > > 2 - prefer GNU make over other build systems by default (IOW, if > > 'Makefile' exists use it, instead of attempting a CMake build just > > because 'configure' did not exist). > > I don't know of any module that has only a Makefile and does not have a > BUILD. So it will be a given a BUILD will exist. Which will cause; > > if has_module_file $MODULE BUILD ; then > run_module_file $MODULE BUILD > > in the run_build function to kick in before it even thinks about going on > to default_build, default_cmake_build, or default_python_build. So I don't > atm see that as being a problem. > > > I haven't looked too closely in all the examples flying by, but I can > > see about merging them in theedge and taking a close look myself to make > > sure we don't break any modules expecting above behaviour. > > > > Auke > > _______________________________________________ Here is a slight change. It renames default_cmake to default_cmake_config to accurately reflect its function. Also added to this function the out of place build -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. -------------- next part -------------- A non-text attachment was scrubbed... Name: default.cmake.function.ver-6.patch Type: text/x-patch Size: 1204 bytes Desc: not available URL: From engelsman at lunar-linux.org Sun Mar 29 17:48:19 2009 From: engelsman at lunar-linux.org (engelsman at lunar-linux.org) Date: Sun, 29 Mar 2009 17:48:19 +0200 Subject: submission exalt-svn.patch was rejected Message-ID: <20090329155704.B67829B1AD@doppio.foo-projects.org> Hi, This is to notify you that your submission "exalt-svn.patch" was rejected This is because: (a) the exalt-svn module fails during configure with: ... checking pkg-config is at least version 0.9.0... yes checking for EXALT... configure: error: Package requirements ( ecore >= 0.9.9.037, eet >= 0.9.9.038, ecore-file >= 0.9.9, ehal >= 0.1.0.002, edbus >= 0.1.0.002, dbus-1 >= 0.1, evas >= 0.9 elementary >= 0.1 ) were not met: No package 'ehal' found No package 'edbus' found (b) you updated DEPENDS to include 'depends wpa_supplicant' but are you sure this is correct? Should it be 'optional_depends' ? What happens if a user does not have a wireless connection? One exalt web page says wpa_supplicant will be used *if found*. Thank you for submitting updates to us!