From duncan.gibson at xs4all.nl Wed May 6 22:42:02 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Wed, 6 May 2009 22:42:02 +0200 (CEST) Subject: %ALIAS timeout and continue Message-ID: <25823.82.93.24.95.1241642522.squirrel@webmail.xs4all.nl> I'm re-installing a slow box, and have been bitten again by the problem where selecting a module for a %ALIAS doesn't timeout so the overnight build was blocked. Therefore I tweaked the aliases.lunar unalias() function to check how many of the options are already installed. If none, it defaults to the first choice, and will timeout. If one, it defaults to that, and will time out. If more than one is already installed, it blocks as before. I had assumed that all %ALIAS options also conflicted with each other, so that having more than one installed would mean a serious problem on the box, but it seems that this is not the case (e.g. XMLRENDERER). There's also the question of what to do if "NEVER_ASK" is already set. I attach this first attempt. Is it worth pursuing further? Comments? Cheers Duncan / engelsman -------------- next part -------------- A non-text attachment was scrubbed... Name: aliases.lunar Type: application/octet-stream Size: 3823 bytes Desc: not available URL: From duncan.gibson at xs4all.nl Fri May 8 12:01:52 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Fri, 8 May 2009 12:01:52 +0200 (CEST) Subject: [Lunar-commits] alsa-driver: version bumped to 1.0.20. Message-ID: <25298.195.169.141.54.1241776912.squirrel@webmail.xs4all.nl> > commit e9889de8fbc4587a4b2eb17a15caaf790cacac39 > Author: Florin Braescu > Date: Fri May 8 12:11:03 2009 +0300 > > alsa-driver: version bumped to 1.0.20. > > New drivers added, bugfixes and enhacements. > --- > audio/alsa-driver/DETAILS | 6 +++--- > audio/alsa-driver/sound.cards | 26 ++++++++++++++++++++++---- > 2 files changed, 25 insertions(+), 7 deletions(-) I'm not at a Lunar box at the moment so I can't verify exactly, but... I installed kqemu this week, and when I ran the modprobe for kqemu I got a warning message that /etc/modules.conf was deprecated and that modules should now go in /etc/modules.d (or something like that). When I looked in /etc/modprobe.conf, all I could see were alsa modules. Adding alsa module names in /etc/modules.{conf,d} needs updating. Cheers Duncan From ratler at lunar-linux.org Sat May 9 15:08:34 2009 From: ratler at lunar-linux.org (Stefan Wold) Date: Sat, 09 May 2009 15:08:34 +0200 Subject: A couple of ideas I want to implement Message-ID: <1241874515.29227.33.camel@localhost> Hey fellow developers! I have a few changes in my mind that I want input on before I actually introduce them into the moonbase and theedge. 1) Adding a verify-sha256 plugin, reason for that would be that sha1 will pretty soon be deprecated due to new attacks making it less reliable. 2) I want to create a cron-common module that most of our crond's will depend upon, there are several that can share the same scripts and configurations. I also want to add a cron-plugin that will search modules for a cron.d directory and install the files into /etc/cron.d/ 3) Several modules could use logrotation scripts, today we don't have the means to do that easily. What I have in mind for this is to fix the logrotate module and add a logrotate-plugin that will check each module for a logrotate.d directory and install the files found. Let me know what you guys think, I believe these are change that make stuff easier for the end users. -- 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 dennisveatch at bellsouth.net Sat May 9 15:17:11 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Sat, 9 May 2009 09:17:11 -0400 Subject: A couple of ideas I want to implement In-Reply-To: <1241874515.29227.33.camel@localhost> References: <1241874515.29227.33.camel@localhost> Message-ID: <200905090917.11080.dennisveatch@bellsouth.net> On Saturday 09 May 2009 9:08:34 am Stefan Wold wrote: > Hey fellow developers! > > I have a few changes in my mind that I want input on before I actually > introduce them into the moonbase and theedge. > > 1) Adding a verify-sha256 plugin, reason for that would be that sha1 > will pretty soon be deprecated due to new attacks making it less > reliable. > Was just reading something about that several days ago. May as well go there before it is depreciated. I like the idea. > 2) I want to create a cron-common module that most of our crond's will > depend upon, there are several that can share the same scripts and > configurations. I also want to add a cron-plugin that will search > modules for a cron.d directory and install the files into /etc/cron.d/ > Sounds like a good idea especially for a server. > 3) Several modules could use logrotation scripts, today we don't have > the means to do that easily. What I have in mind for this is to fix the > logrotate module and add a logrotate-plugin that will check each module > for a logrotate.d directory and install the files found. > > Its one reason on my desktops I have not fiddled with logrotate. Go for it. > Let me know what you guys think, I believe these are change that make > stuff easier for the end users. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From jannis at lunar-linux.org Sat May 9 16:38:07 2009 From: jannis at lunar-linux.org (Jannis Pohlmann) Date: Sat, 9 May 2009 16:38:07 +0200 Subject: A couple of ideas I want to implement In-Reply-To: <1241874515.29227.33.camel@localhost> References: <1241874515.29227.33.camel@localhost> Message-ID: <20090509163807.26f27b7a@lunar-linux.org> On Sat, 09 May 2009 15:08:34 +0200 Stefan Wold wrote: > Hey fellow developers! > > I have a few changes in my mind that I want input on before I actually > introduce them into the moonbase and theedge. > > 1) Adding a verify-sha256 plugin, reason for that would be that sha1 > will pretty soon be deprecated due to new attacks making it less > reliable. > > 2) I want to create a cron-common module that most of our crond's will > depend upon, there are several that can share the same scripts and > configurations. I also want to add a cron-plugin that will search > modules for a cron.d directory and install the files into /etc/cron.d/ > > 3) Several modules could use logrotation scripts, today we don't have > the means to do that easily. What I have in mind for this is to fix > the logrotate module and add a logrotate-plugin that will check each > module for a logrotate.d directory and install the files found. > > > Let me know what you guys think, I believe these are change that make > stuff easier for the end users. Sounds great, I'm all for it! - Jannis From dennisveatch at bellsouth.net Fri May 15 23:54:02 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Fri, 15 May 2009 17:54:02 -0400 Subject: [Lunar-commits] r27033 - lunar/trunk/var/lib/lunar/plugins In-Reply-To: <20090515065603.DACE09B1C0@doppio.foo-projects.org> References: <20090515065603.DACE09B1C0@doppio.foo-projects.org> Message-ID: <200905151754.02225.dennisveatch@bellsouth.net> On Friday 15 May 2009 2:56:03 am Stefan Wold wrote: > Author: ratler > Date: 2009-05-15 08:56:03 +0200 (Fri, 15 May 2009) > New Revision: 27033 > > Added: > lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > Log: > Adding support for sha256 SOURCE_VFY. sha1 will soon be obsolete due to new > attacks. > > Added: lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > =================================================================== > --- lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > (rev 0) +++ > lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin 2009-05-15 06:56:03 > UTC (rev 27033) @@ -0,0 +1,32 @@ > +#!/bin/bash > +############################################################# > +# # > +# verify-sha256.plugin - plugin that performs sha256check # > +# # > +############################################################# > +# # > +# Copyright 2005 by Auke Kok under GPLv2 # > +# Copyright 2009 by Stefan Wold under GPLv2 # > +# # > +############################################################# > + > + > +plugin_source_verify_sha256() { > + # check if we can handle this type of VFY: > + if [ "${2:0:7}" != "sha256:" ] ; then > + return 2 > + fi > + debug_msg "plugin_source_verify_sha256 ($@)" > + TMP_SHA=$(sha256sum $SOURCE_CACHE/$1 | cut -d " " -f 1-1) > + if [ "${2:7}" != "$TMP_SHA" ] ; then > + message "${PROBLEM_COLOR}! sha256sum check failed for > ${DEFAULT_COLOR}${FILE_COLOR}$1${DEFAULT_COLOR}" + verbose_msg > "offending sha256sum: $TMP_SHA" > + verbose_msg "should be sha256sum: ${2:7}" > + return 1 > + else > + # always return 'continue' plugin value > + return 2 > + fi > +} > + > +plugin_register SOURCE_VERIFY plugin_source_verify_sha256 > Something isn't quite right here. When testing the pwgen module, changed sha1 to sha256: with a blank entry, and changed the version/dl link, etc. Tried to lin and it did not stop the build on a invalid sha256. -- 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 Sat May 16 00:56:38 2009 From: dennisveatch at bellsouth.net (Dennis Veatch) Date: Fri, 15 May 2009 18:56:38 -0400 Subject: [Lunar-commits] r27033 - lunar/trunk/var/lib/lunar/plugins In-Reply-To: <200905151754.02225.dennisveatch@bellsouth.net> References: <20090515065603.DACE09B1C0@doppio.foo-projects.org> <200905151754.02225.dennisveatch@bellsouth.net> Message-ID: <200905151856.38605.dennisveatch@bellsouth.net> On Friday 15 May 2009 5:54:02 pm Dennis Veatch wrote: > On Friday 15 May 2009 2:56:03 am Stefan Wold wrote: > > Author: ratler > > Date: 2009-05-15 08:56:03 +0200 (Fri, 15 May 2009) > > New Revision: 27033 > > > > Added: > > lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > > Log: > > Adding support for sha256 SOURCE_VFY. sha1 will soon be obsolete due to > > new attacks. > > > > Added: lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > > =================================================================== > > --- lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin > > (rev 0) +++ > > lunar/trunk/var/lib/lunar/plugins/verify-sha256.plugin 2009-05-15 > > 06:56:03 UTC (rev 27033) @@ -0,0 +1,32 @@ > > +#!/bin/bash > > +############################################################# > > +# # > > +# verify-sha256.plugin - plugin that performs sha256check # > > +# # > > +############################################################# > > +# # > > +# Copyright 2005 by Auke Kok under GPLv2 # > > +# Copyright 2009 by Stefan Wold under GPLv2 # > > +# # > > +############################################################# > > + > > + > > +plugin_source_verify_sha256() { > > + # check if we can handle this type of VFY: > > + if [ "${2:0:7}" != "sha256:" ] ; then > > + return 2 > > + fi > > + debug_msg "plugin_source_verify_sha256 ($@)" > > + TMP_SHA=$(sha256sum $SOURCE_CACHE/$1 | cut -d " " -f 1-1) > > + if [ "${2:7}" != "$TMP_SHA" ] ; then > > + message "${PROBLEM_COLOR}! sha256sum check failed for > > ${DEFAULT_COLOR}${FILE_COLOR}$1${DEFAULT_COLOR}" + verbose_msg > > "offending sha256sum: $TMP_SHA" > > + verbose_msg "should be sha256sum: ${2:7}" > > + return 1 > > + else > > + # always return 'continue' plugin value > > + return 2 > > + fi > > +} > > + > > +plugin_register SOURCE_VERIFY plugin_source_verify_sha256 > > Something isn't quite right here. When testing the pwgen module, changed > sha1 to sha256: with a blank entry, and changed the version/dl link, etc. > Tried to lin and it did not stop the build on a invalid sha256. erf. nm. Didn't notice the "lunar/trunk" part. Will check it out later. -- You can tuna piano but you can't tune a fish. http://www.lunar-linux.org/ It's worth the spin. From duncan.gibson at xs4all.nl Sun May 24 19:03:33 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Sun, 24 May 2009 19:03:33 +0200 (CEST) Subject: GIT: warning message about "updating currently checked out branch" and why you should care Message-ID: <20217.82.93.24.95.1243184613.squirrel@webmail.xs4all.nl> > So, from what's been said, and some experimenting with multiple local > repositories, if I want to continue working in the same way described in > http://wiki.lunar-linux.org/index.php/Module_Submission_for_developers > I need: > > 1. On doppio to clone a bare copy of the central moonbase.git > git clone --bare git://lunar-linux.org/lunar/moonbase.git remote.bare > > 2. On doppio, clone a working copy from that for the review script > git clone remote.bare remote.work > > 3. On my box, clone a local working copy from my bare repo on doppio > git clone ssh://me at lunar-linux.org/~me/remote.bare local.work > > As far as I can tell so far, local.work no longer needs the > git config --get-regexp '^(remote|branch)\.' > git config remote.origin.push master:refs/remotes/satellite/master > lines that came from the Everyday GIT With 20 Commands Or So article. > > In remote.bare I can now 'git push' to moonbase,git without warning, > but I now need to 'git fetch' from moonbase.git instead of 'git pull' > > In remote.work, I can 'git push' to, and 'git pull' from remote.bare. > > In local.work, I can 'git push' to, and 'git pull' from remote.bare. > > I have to push/pull things via remote.bare if I want to share them > between remote.work and local.work because (a) my firewall is closed > so remote.work can't pull from local.work, and (b) local.work can't > push to remote.work because it's not a bare repo. > > Phew! I think I'm getting my head around it. > > Is there anything that I missed before I update the wiki page? I've finally updated the wiki page. Can anyone tell me why the git config line doesn't work from my moonbase.git on doppio when pushing to the central moonbase,git? I don't understand why I still need to git push /var/git/lunar/moonbase.git lunar Cheers Duncan / engelsman From zbiggy at o2.pl Sun May 24 21:32:10 2009 From: zbiggy at o2.pl (Zbigniew Luszpinski) Date: Sun, 24 May 2009 21:32:10 +0200 Subject: Lunar's distrowatch script needs some fine tuning Message-ID: <200905242132.10968.zbiggy@o2.pl> Hello, it looks Distrowatch now count packages' version only for KDE4 modules. It would be nice if someone with rw access to distrowatch script (Auke?) could fine tune module aliases to report correct versions: now: should be: amarok amarok4 krusader krusader4 digikam digikam4 Let's show to the World we keep up with KDE development :) have a nice day, Zbigniew 'zbiggy' Luszpinski From duncan.gibson at xs4all.nl Sat May 30 13:13:04 2009 From: duncan.gibson at xs4all.nl (Duncan Gibson) Date: Sat, 30 May 2009 13:13:04 +0200 (CEST) Subject: Unwanted branch on doppio:moonbase.git Message-ID: <16960.82.93.24.95.1243681984.squirrel@webmail.xs4all.nl> Sorry guys, but due to a fat finger typo I've managed to create a new branch in the central doppio moonbase.git, and rather than me trying to correct it and making more of a dog's dinner of it than it already is, I would be most grateful if one of you gitmeisters could correct it. engelsman at doppio ~/moonbase.git $ git push /var/git/lunar/moonbase.git master:maseter Counting objects: 19, done. Delta compression using 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1.05 KiB, done. Total 11 (delta 8), reused 0 (delta 0) Unpacking objects: 100% (11/11), done. To /var/git/lunar/moonbase.git * [new branch] master -> maseter Counting objects: 193276, done. Delta compression using 4 threads. Compressing objects: 100% (61456/61456), done. Writing objects: 100% (193276/193276), done. Total 193276 (delta 126697), reused 193264 (delta 126691)