From zbiggy at o2.pl Mon Feb 1 00:46:30 2010 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Mon, 1 Feb 2010 00:46:30 +0100 Subject: udev updated to current 151 release on zbiggy-WIP Message-ID: <201002010046.30590.zbiggy@o2.pl> Hello, I have updated udev to current 151 release on zbiggy-WIP http://foo-projects.org/git/?p=zbiggy/moonbase.git;a=shortlog;h=refs/heads/zbiggy-WIP This release is just bugfix to previous 150 one. If previous udev releases forget to create /dev/cdrom /dev/dvd /dev/cdrw /dev/dvdrw or other symlinks making life easier, this release remembers to do that :) In Lunar however are some other changes: +Added udev rule for /dev/radio devices so you do not have to be root to listen to the radio :) +New rule patch created so patch applies without fuzzy lines. have a nice day, Zbigniew Luszpinski From dennisveatch at bellsouth.net Mon Feb 1 15:43:53 2010 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Mon, 1 Feb 2010 09:43:53 -0500 Subject: udev updated to current 151 release on zbiggy-WIP In-Reply-To: <201002010046.30590.zbiggy@o2.pl> References: <201002010046.30590.zbiggy@o2.pl> Message-ID: <201002010943.53625.dennisveatch@bellsouth.net> On Sunday 31 January 2010 6:46:30 pm Zbigniew Luszpinski wrote: > Hello, > > I have updated udev to current 151 release on zbiggy-WIP > http://foo-projects.org/git/?p=zbiggy/moonbase.git;a=shortlog;h=refs/heads/ > zbiggy-WIP > > This release is just bugfix to previous 150 one. > > If previous udev releases forget to create /dev/cdrom /dev/dvd /dev/cdrw > /dev/dvdrw or other symlinks making life easier, this release remembers to > do that :) > > In Lunar however are some other changes: > +Added udev rule for /dev/radio devices so you do not have to be root to > listen to the radio :) +New rule patch created so patch applies without > fuzzy lines. > > have a nice day, > Zbigniew Luszpinski I think you need to add gobject-introspection to the DEPENDS. When I tried flroin's udev-150 a while back it wanted that. I am not sure if it should be a depends or an optional_depends. Dennis From duncan.gibson at xs4all.nl Sun Feb 14 17:45:37 2010 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Sun, 14 Feb 2010 17:45:37 +0100 Subject: GNOMEXYZ_PREFIX ? Message-ID: <147d712757553b58de2448057fcdd5f7.squirrel@webmail.xs4all.nl> Looking through gnome2 modules, I see that many have BUILD files that allow 'configure --prefix' and other options to be set using: ./configure --prefix=${GNOMEXYZ_PREFIX:-/usr} where XYZ can be 210, 26, 28 or even 2280. Is there any reason why these can't all be reduced down to just GNOME2_PREFIX or even GNOME_PREFIX? Cheers Duncan / engelsman From zmcgrew at gmail.com Mon Feb 15 02:24:16 2010 From: zmcgrew at gmail.com (Zachary McGrew) Date: Sun, 14 Feb 2010 17:24:16 -0800 Subject: GNOMEXYZ_PREFIX ? In-Reply-To: <147d712757553b58de2448057fcdd5f7.squirrel@webmail.xs4all.nl> References: <147d712757553b58de2448057fcdd5f7.squirrel@webmail.xs4all.nl> Message-ID: <4b1a641e1002141724q11b07ed4r33d84f587d501f9c@mail.gmail.com> On Sun, Feb 14, 2010 at 8:45 AM, Duncan Gibson wrote: > Looking through gnome2 modules, I see that many have BUILD files > that allow 'configure --prefix' and other options to be set using: > > ?./configure ?--prefix=${GNOMEXYZ_PREFIX:-/usr} > > where XYZ can be 210, 26, 28 or even 2280. > > Is there any reason why these can't all be reduced down to just > GNOME2_PREFIX or even GNOME_PREFIX? Sounds like an excellent plan. It's got my vote. > Cheers > Duncan / engelsman > > _______________________________________________ > Lunar-dev mailing list > Lunar-dev at lunar-linux.org > http://foo-projects.org/mailman/listinfo/lunar-dev > -- Zachary McGrew Web: http://zmcgrew.no-ip.com From zbiggy at o2.pl Fri Feb 26 01:07:17 2010 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Fri, 26 Feb 2010 01:07:17 +0100 Subject: Florin (or someone else) please revert mysql from 5.0.90 back to 5.1.44 new mysql does NOT break akonadi Message-ID: <201002260107.17761.zbiggy@o2.pl> Hello, Florin (or someone else) please revert mysql from 5.0.90 back to 5.1.44 asap. New mysql does NOT break akonadi. Currently I can not do this myself. After lining mysql you have to lin qt4 to recompile qt4's mysql driver. I also lined akonadi then but I think lining qt4 might be enough. lunar fix/nofix will NOT detect the need of qt4 recompilation because of mysql change. Going back to 5.0.90 is the worst thing. I doubt it will have new security releases. Now on my machine KMail, a heavy akonadi dependent util, works perfect and akonadi starts well with MySQL 5.1.44 running. have a nice day, Zbigniew Luszpinski From dennisveatch at bellsouth.net Fri Feb 26 01:37:57 2010 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Thu, 25 Feb 2010 19:37:57 -0500 Subject: Florin (or someone else) please revert mysql from 5.0.90 back to 5.1.44 new mysql does NOT break akonadi In-Reply-To: <201002260107.17761.zbiggy@o2.pl> References: <201002260107.17761.zbiggy@o2.pl> Message-ID: <201002251937.58020.dennisveatch@bellsouth.net> On Thursday 25 February 2010 7:07:17 pm Zbigniew Luszpinski wrote: > Hello, > > Florin (or someone else) please revert mysql from 5.0.90 back to 5.1.44 > asap. New mysql does NOT break akonadi. Currently I can not do this > myself. > After lining mysql you have to lin qt4 to recompile qt4's mysql driver. I > also lined akonadi then but I think lining qt4 might be enough. lunar > fix/nofix will NOT detect the need of qt4 recompilation because of mysql > change. > > Going back to 5.0.90 is the worst thing. I doubt it will have new security > releases. Now on my machine KMail, a heavy akonadi dependent util, works > perfect and akonadi starts well with MySQL 5.1.44 running. > > have a nice day, > Zbigniew Luszpinski > _______________________________________________ Yes we are aware of this and some of the issues you noted. Even though a lunar fix or update does not find anything wrong with qt4 after the bump to mysql-5.1.44, you still need to relin qt4. Ratler is working on a revamp of the mysql module and I am testing his changes atm. Mysql will most likely be bumped tomorrow. Dennis. From duncan.gibson at xs4all.nl Sat Feb 27 12:44:00 2010 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Sat, 27 Feb 2010 12:44:00 +0100 Subject: lfirsttime and other man pages on wiki for community update Message-ID: <8359f34d80396295647227d87dcbbfa3.squirrel@webmail.xs4all.nl> I've seen repeated comments on #lunar that the various Lunar man pages need to be updated, especially lfirsttime(8), and this should probably be done before the release of the next ISO. There was a suggestion to put the man pages on the wiki to allow some community editing. Google docs? We don't need no Google docs! :-) PacManLives started the ball rolling by putting the lin(8) online. El_Angelo already had a page for lvu(1) - but I've overwritten it. I've restructured the wiki pages so that most of the tools now have summary pages in the Tools: section rather than at the top level, so you will need to link using [[Tools:lvu|lvu]] rather than plain [[lvu]] Each summary page now also has a link to its corresponding man page. I've also added a wiki page for lfirsttime(8) for good measure. They are just cut'n'paste from my terminal, which results in weird wiki formatting, but I don't see the point of reformatting just yet. It's all got to go back to nroff/man format in the moonbase anyway. For ease of access here are the links: http://wiki.lunar-linux.org/index.php/Installation:lfirsttime.8.manpage http://wiki.lunar-linux.org/index.php/Tools:lget http://wiki.lunar-linux.org/index.php/Tools:lget.8.manpage http://wiki.lunar-linux.org/index.php/Tools:lin http://wiki.lunar-linux.org/index.php/Tools:lin.8.manpage http://wiki.lunar-linux.org/index.php/Tools:lrm http://wiki.lunar-linux.org/index.php/Tools:lrm.8.manpage http://wiki.lunar-linux.org/index.php/Tools:lunar http://wiki.lunar-linux.org/index.php/Tools:lunar.8.manpage http://wiki.lunar-linux.org/index.php/Tools:lvu http://wiki.lunar-linux.org/index.php/Tools:lvu.1.manpage These pages should be open for all registered wiki users to edit. I can unprotect other pages for update on request. Cheers Duncan From duncan.gibson at xs4all.nl Sun Feb 28 18:28:56 2010 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Sun, 28 Feb 2010 18:28:56 +0100 Subject: gnome-2.28.2 updates for Lunar Message-ID: <9fb76ae973c8e6fba451272d04e8beb2.squirrel@webmail.xs4all.nl> I've been holding off on the module submission queue entries because several of them relate to gnome-2.28 and beyond. My old box died recently, and I have a new vanilla system, so I thought it might be interesting to have a go with gnome, only to find that the existing gnome2 profiles didn't build for me. So I decided to set off on the voyage of discovery to update the gnome modules from scratch, using only zlocal, and soon got in a huge mess. But I learned a couple of things doing it: 0. don't try to update the docbook modules if you don't know how 1. git is your friend (but first I had to get more proficient) 2. zmcgrew already had a gnome branch in his moonbase.git 3. the jhbuild utility doesn't tell the complete story because jhbuild --list shows the order of build without versions 4. lazyape pointed out that there is a list of version numbers http://ftp.acc.umu.se/pub/gnome/teams/releng/2.28.2/ So I cloned the moonbase, fetched zmcgrew's zmcgrew and gnome branches, and merged them into a new working branch. Then I worked through the jhbuild list in order, using the versions file as guide, and build each module, one at a time. The following text relates to the attached 'jhbuild-2.28-list.txt' and 'versions-2.28.2-annotated.txt' files. For those modules in the original versions-2.28.2 list, I did not check whether there were updates or not, only whether I could build them directly from the working branch moonbase. Those are marked with 'ok'. Those modules in the working branch moonbase with a version newer than the versions-2.28.2 list, I've marked with the [zmcgrew: x.y.z] tag whether Zach updated them or not. Those that I have had to update are marked with the [engelsman: x.y.z] tag. There are also annotations about specific options to be set/unset. There were a lot of modules in the jhbuild list that didn't appear in the versions file, or which were pulled in as dependencies of the other modules. I've checked all of the moonbase versions against the project home pages and have marked with the [available: x.y.z] tags those modules which I could build but for which newer versions are available and which might need to be updated later. The modules that I have updated are available on the gnome branch of git://lunar-linux.org/~engelsman/moonbase.git (note the '~') I've almost completed all of the modules on the jhbuild list, but have become stuck on DeviceKit-power with its undefined references, and all of the ones on the versions-2.82 list that depend on it, such as gdm and gnome-session. I've searched the web, but haven't found the clue that I need to solve this. So now I'm stuck, and don't have much time to devote to this for the next couple of weeks, so I'm sending this out in the hope that it will help someone else, such as zmcgrew or lazy_ape. I've been running in a minimal twm and xterm environment, so have only been able to test that the modules download, compile and install OK. I haven't tried to run any of them yet. I'm saving that for later :-) Cheers Duncan / engelsman -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jhbuild-2.28-list.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: versions-2.28.2-annotated.txt URL: