From zbiggy at o2.pl  Sun Jul  4 14:32:57 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sun, 4 Jul 2010 14:32:57 +0200
Subject: [Lunar-commits] <moonbase> NVIDIA: updated to official 256.35 Now
	NVIDIA and NVIDIA-beta modules are the same
In-Reply-To: <201006232124.16341.dennisveatch@bellsouth.net>
References: <20100624001624.22A049B220@doppio.foo-projects.org>
	<201006232124.16341.dennisveatch@bellsouth.net>
Message-ID: <201007041433.05783.zbiggy@o2.pl>

> Its borked.
> 
> First: You have nvidia conflicting with nvidia. 

Trivial error which slipped in.

> Second:
> sed: can't read public.mk: No such file or directory

Remove this section from BUILD:

  if [[ $(arch) == x86_64 ]] ; then
    # Don't compile 32-bits on pure 64-bit Lunar
    sedit 's/COMPAT_32_SRC *= */\0#/' Makefile &&
    sedit 's/COMPAT_32_SRC *= */\0#/' public.mk &&
    sedit 's/-DNV_X86_64//' Makefile &&
    sedit 's/-DNV_X86_64//' public.mk
  fi &&


> install: cannot stat `_out/Linux_x86_64/nvidia-settings': No such file or 
> directory
> install: cannot stat `_out/Linux_x86_64/nvidia-settings.1.gz': No such file or 
> directory

Tell me what you see in _out directory. There will be only one directory there.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100704/dd01f43b/attachment.bin>

From zbiggy at o2.pl  Sat Jul 10 14:11:37 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 10 Jul 2010 14:11:37 +0200
Subject: lunar's distrowatch module list badly out of sync again - who
	maintains it?
Message-ID: <201007101411.44101.zbiggy@o2.pl>

Hello,

some modules are bad displayed on distrowatch:

distrowatch module	| bad module| correct module
------------------------------------------------
grub				|	grub	| grub2
k3b					|	k3b4??? | k3b
apache-tomcat		|	-       | tomcat6-bin
kaffeine			| kaffeine4 | kaffeine
kdevelop			|	-		| kdevelop4
koffice				|	-?		| koffice
ktorrent			|	-?		| ktorrent
links				|	-?		| links
OpenOffice.org		| openoffice-bin | openoffice-src (openoffice-bin is good module but is older than src)
sylpheed			|	-		| sylpheed
VirtualBox			|	-		| VirtualBox

distrowatch module - module name on distrowatch web page
bad module - module name which I suppose is bad in Lunar's distrowatch database:
? - I'm guessing bad module name
- module is not in Lunar's distrowatch db but should be because we have it in moonbase
-? probably module is in Lunar's distrowatch db but may have broken name so it is not present

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100710/ad0befbc/attachment.bin>

From zbiggy at o2.pl  Sat Jul 10 16:06:28 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 10 Jul 2010 16:06:28 +0200
Subject: to kde module developers: kde itself and all kde applications have
	broken integration with dbus and policykit
Message-ID: <201007101606.36470.zbiggy@o2.pl>

Hello,

I have just discovered that kde itself and almost all kde applications have broken dbus/messagebus and policykit integration.
This integration break was caused by installing kde in non standard directory: /opt/lunar/kde/4

The result of this broken integration is that:
*KAuth is broken: you can not use kde sudo like features to do root duties from casual user account. For example setting the clock:

Discussion on Lunar ML: Re: Hello world - my response:
>> I asked about password request in KDE 
>> config tool because I couldn't set ntp as default service.
>
> I reproduced the bug you probably encountered setting ntp:
> "Unable to authenticate/execute the action: 7, DBus Backend error: could not contact the helper. Connection error: Could not get owner of name >
> 'org.kde.kcontrol.kcmclock': no such name. Message error: The name org.kde.kcontrol.kcmclock was not provided by any .service files"
>
> Will look at it deeper later - Lunar installs dbus files in wrong place.

I manually copied dbus and policykit kde files to correct locations and this bug is fixed. Another advantage is that when I plug in usb drive the kde file browser auto opens its content. Many other hotplug actions also become active. I still discover other new capabilities which appeared thanks to fixing dbus integration.

How about moving kde to /usr which is right place for it to have full kde features enabled?
I understand that in kde3/4 transition time it was right to keep both of them in separate dirs.
But now after someone brutally smashed off kde3 from moonbase and knowing that there is no kde5 for a long time why not moving kde4 to /usr?

Adding:
-DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy \
-DDBUS_INTERFACES_INSTALL_DIR:PATH=/usr/share/dbus-1/interfaces \
-DDBUS_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/services \
-DDBUS_SYSTEM_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/system-services \
-DSYSCONF_INSTALL_DIR:PATH=/etc \ <--- I'm not sure if it will work

to almost every kde module makes no sense. Not all files will be correctly installed. For example there is no option for installing files in the following right directories:

/usr/share/polkit-1/actions

k3b:
/etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
/usr/share/dbus-1/system-services/org.kde.kcontrol.k3bsetup.service

kdebase4-workspace:
/etc/dbus-1/system.d/org.kde.fontinst.conf
/etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
/etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf

kdelibs4:
/etc/dbus-1/system.d/org.kde.auth.conf
/etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf

Let's talk about pros/cons of moving kde to /usr

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100710/0d891518/attachment.bin>

From dennisveatch at bellsouth.net  Sat Jul 10 16:32:47 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 10 Jul 2010 10:32:47 -0400
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007101606.36470.zbiggy@o2.pl>
References: <201007101606.36470.zbiggy@o2.pl>
Message-ID: <201007101032.47164.dennisveatch@bellsouth.net>

On Saturday, July 10, 2010 10:06:28 am Zbigniew Luszpinski wrote:
> Hello,
> 
> I have just discovered that kde itself and almost all kde applications have
> broken dbus/messagebus and policykit integration. This integration break
> was caused by installing kde in non standard directory: /opt/lunar/kde/4
> 
> The result of this broken integration is that:
> *KAuth is broken: you can not use kde sudo like features to do root duties
> from casual user account. For example setting the clock:
> 
> Discussion on Lunar ML: Re: Hello world - my response:
> >> I asked about password request in KDE
> >> config tool because I couldn't set ntp as default service.
> > 
> > I reproduced the bug you probably encountered setting ntp:
> > "Unable to authenticate/execute the action: 7, DBus Backend error: could
> > not contact the helper. Connection error: Could not get owner of name >
> > 'org.kde.kcontrol.kcmclock': no such name. Message error: The name
> > org.kde.kcontrol.kcmclock was not provided by any .service files"
> > 
> > Will look at it deeper later - Lunar installs dbus files in wrong place.
> 
> I manually copied dbus and policykit kde files to correct locations and
> this bug is fixed. Another advantage is that when I plug in usb drive the
> kde file browser auto opens its content. Many other hotplug actions also
> become active. I still discover other new capabilities which appeared
> thanks to fixing dbus integration.
> 
> How about moving kde to /usr which is right place for it to have full kde
> features enabled? I understand that in kde3/4 transition time it was right
> to keep both of them in separate dirs. But now after someone brutally
> smashed off kde3 from moonbase and knowing that there is no kde5 for a
> long time why not moving kde4 to /usr?
> 
> Adding:
> -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy \
> -DDBUS_INTERFACES_INSTALL_DIR:PATH=/usr/share/dbus-1/interfaces \
> -DDBUS_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/services \
> -DDBUS_SYSTEM_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/system-services \
> -DSYSCONF_INSTALL_DIR:PATH=/etc \ <--- I'm not sure if it will work
> 
> to almost every kde module makes no sense. Not all files will be correctly
> installed. For example there is no option for installing files in the
> following right directories:
> 
> /usr/share/polkit-1/actions
> 
> k3b:
> /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
> /usr/share/dbus-1/system-services/org.kde.kcontrol.k3bsetup.service
> 
> kdebase4-workspace:
> /etc/dbus-1/system.d/org.kde.fontinst.conf
> /etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
> /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
> 
> kdelibs4:
> /etc/dbus-1/system.d/org.kde.auth.conf
> /etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
> 
> Let's talk about pros/cons of moving kde to /usr
> 
> have a nice day,
> Zbigniew Luszpinski

Yes. I am aware the policy kit stuff needs and has needed some attention. 
Instead of moving everything to /usr; unless there is a consensus to do so. I 
think I would rather see the appropriate CMake flags added to their respective 
modules so some of the things you point out are thrown in the right system 
directories.

-- 
Dennis Veatch

From ratler at lunar-linux.org  Sat Jul 10 17:53:07 2010
From: ratler at lunar-linux.org (Stefan Wold)
Date: Sat, 10 Jul 2010 17:53:07 +0200
Subject: lunar's distrowatch module list badly out of sync again - who
	maintains it?
In-Reply-To: <201007101411.44101.zbiggy@o2.pl>
References: <201007101411.44101.zbiggy@o2.pl>
Message-ID: <1278777188.21027.6.camel@localhost>

I'll take a look at it.

grub2 is still not supported out of the box by lunar, so the correct one
is actually being displayed.

/Stefan


On Sat, 2010-07-10 at 14:11 +0200, Zbigniew Luszpinski wrote:
> Hello,
> 
> some modules are bad displayed on distrowatch:
> 
> distrowatch module	| bad module| correct module
> ------------------------------------------------
> grub				|	grub	| grub2
> k3b					|	k3b4??? | k3b
> apache-tomcat		|	-       | tomcat6-bin
> kaffeine			| kaffeine4 | kaffeine
> kdevelop			|	-		| kdevelop4
> koffice				|	-?		| koffice
> ktorrent			|	-?		| ktorrent
> links				|	-?		| links
> OpenOffice.org		| openoffice-bin | openoffice-src (openoffice-bin is good module but is older than src)
> sylpheed			|	-		| sylpheed
> VirtualBox			|	-		| VirtualBox
> 
> distrowatch module - module name on distrowatch web page
> bad module - module name which I suppose is bad in Lunar's distrowatch database:
> ? - I'm guessing bad module name
> - module is not in Lunar's distrowatch db but should be because we have it in moonbase
> -? probably module is in Lunar's distrowatch db but may have broken name so it is not present
> 
> have a nice day,
> Zbigniew Luszpinski
> _______________________________________________
> Lunar-dev mailing list
> Lunar-dev at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar-dev

-- 
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/20100710/cc6dbdb7/attachment-0001.bin>

From zbiggy at o2.pl  Sat Jul 10 18:02:30 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 10 Jul 2010 18:02:30 +0200
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007101032.47164.dennisveatch@bellsouth.net>
References: <201007101606.36470.zbiggy@o2.pl>
	<201007101032.47164.dennisveatch@bellsouth.net>
Message-ID: <201007101802.37088.zbiggy@o2.pl>

> Yes. I am aware the policy kit stuff needs and has needed some attention. 
> Instead of moving everything to /usr; unless there is a consensus to do so. I 
> think I would rather see the appropriate CMake flags added to their respective 
> modules so some of the things you point out are thrown in the right system 
> directories.

But there are many modules which require these flags.
I doubt we have enough man power to check and fix all modules which needs changing.
What to do with dbus dirs which have no cmake flag?:
/etc/dbus-1/system.d/
I'm not sure if -DSYSCONF_INSTALL_DIR:PATH=/etc  will cover this.
What about (lvu install kdelibs4 | grep share/polkit-1/actions):
/opt/lunar/kde/4/share/polkit-1/actions/org.kde.kcontrol.kcmremotewidgets.policy
there is no cmake flag for polkit-1 dir.
I have done short lvu install module_name | grep dbus-1 and here are the modules which require changing:

akonadi
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-DDBUS_SERVICES_INSTALL_DIR=/usr/share/dbus-1/services

k3b: no cmake flag for this one:
k3b:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
-DDBUS_SYSTEM_SERVICES_INSTALL_DIR=/usr/share/dbus-1/system-services

kdebase4:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
kdebase4-runtime:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-DDBUS_SERVICES_INSTALL_DIR=/usr/share/dbus-1/services
kdebase4-workspace:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-DDBUS_SERVICES_INSTALL_DIR=/usr/share/dbus-1/services
-DDBUS_SYSTEM_SERVICES_INSTALL_DIR=/usr/share/dbus-1/system-services
no cmake flag for these:
kdebase4-workspace:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.fontinst.conf
kdebase4-workspace:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
kdebase4-workspace:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
kdegraphics4:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
no cmake flag for these:
kdelibs4:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.auth.conf
kdelibs4:/opt/lunar/kde/4/etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-DDBUS_SYSTEM_SERVICES_INSTALL_DIR=/usr/share/dbus-1/system-services
kdemultimedia:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
kdenetwork:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-DDBUS_SERVICES_INSTALL_DIR=/usr/share/dbus-1/services
kdepim and kdepim-runtime, kdepimlibs:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
plasma, addons:
-DDBUS_SERVICES_INSTALL_DIR=/usr/share/dbus-1/services
kdesdk,kdeutils,kdewebdev,phonon:
-DDBUS_INTERFACES_INSTALL_DIR=/usr/share/dbus-1/interfaces
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100710/5c43a3f9/attachment.bin>

From zbiggy at o2.pl  Sat Jul 10 18:27:30 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Sat, 10 Jul 2010 18:27:30 +0200
Subject: lunar's distrowatch module list badly out of sync again - who
	maintains it?
In-Reply-To: <1278777188.21027.6.camel@localhost>
References: <201007101411.44101.zbiggy@o2.pl>
	<1278777188.21027.6.camel@localhost>
Message-ID: <201007101827.37478.zbiggy@o2.pl>

> I'll take a look at it.

Thanks. :)

> grub2 is still not supported out of the box by lunar, so the correct one
> is actually being displayed.

??? I do not understand your point of view.
What distrowatch script has in common with files on ISO (out of the box)?
We are talking about distrowatch script/database and what an user can have in Lunar. Not on iso.
If we have to match distrowatch modules with our tiny iso we should remove 90% of modules from distrowatch list
to meet your out of the box requirement.

In distrowatch we show how much up to date we are. What can be installed in Lunar.
If their grub version matches our grub2 module version why not show this?
Take as example gtk+ module:
Distrowatch version: gtk+ (2.20.1)
Lunar gtk+ module version: 1.2.10
Lunar gtk+-2 module version: 20.1
Lunar version reported to distrowatch: 2.20.1
this is true and correct we have gtk+ 2.20.1 but not in module gtk+ but gtk+-2.
As a result lin gtk+-2 installs gtk+ 2.20.1 so we do not lie.

Now in distrowatch we lie in case of grub:
Distrowatch version: grub (1.98)
Lunar grub module version: 0.97
Lunar grub2 module version: 1.98
Lunar version reported to distrowatch: 0.97

By telling 0.97 we actually lie we do not have grub 1.98 (because we have it).
If you take seriously political correctness of module versions rename grub according to gnu naming:
grub -> grub-legacy
grub2 -> grub

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100710/a59554f3/attachment.bin>

From ratler at lunar-linux.org  Sat Jul 10 20:31:24 2010
From: ratler at lunar-linux.org (Stefan Wold)
Date: Sat, 10 Jul 2010 20:31:24 +0200
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007101032.47164.dennisveatch@bellsouth.net>
References: <201007101606.36470.zbiggy@o2.pl>
	<201007101032.47164.dennisveatch@bellsouth.net>
Message-ID: <1278786684.21027.9.camel@localhost>

On Sat, 2010-07-10 at 10:32 -0400, Dennis Veatch wrote:
> On Saturday, July 10, 2010 10:06:28 am Zbigniew Luszpinski wrote:
> > Hello,
> > 
> > I have just discovered that kde itself and almost all kde applications have
> > broken dbus/messagebus and policykit integration. This integration break
> > was caused by installing kde in non standard directory: /opt/lunar/kde/4
> > 
> > The result of this broken integration is that:
> > *KAuth is broken: you can not use kde sudo like features to do root duties
> > from casual user account. For example setting the clock:
> > 
> > Discussion on Lunar ML: Re: Hello world - my response:
> > >> I asked about password request in KDE
> > >> config tool because I couldn't set ntp as default service.
> > > 
> > > I reproduced the bug you probably encountered setting ntp:
> > > "Unable to authenticate/execute the action: 7, DBus Backend error: could
> > > not contact the helper. Connection error: Could not get owner of name >
> > > 'org.kde.kcontrol.kcmclock': no such name. Message error: The name
> > > org.kde.kcontrol.kcmclock was not provided by any .service files"
> > > 
> > > Will look at it deeper later - Lunar installs dbus files in wrong place.
> > 
> > I manually copied dbus and policykit kde files to correct locations and
> > this bug is fixed. Another advantage is that when I plug in usb drive the
> > kde file browser auto opens its content. Many other hotplug actions also
> > become active. I still discover other new capabilities which appeared
> > thanks to fixing dbus integration.
> > 
> > How about moving kde to /usr which is right place for it to have full kde
> > features enabled? I understand that in kde3/4 transition time it was right
> > to keep both of them in separate dirs. But now after someone brutally
> > smashed off kde3 from moonbase and knowing that there is no kde5 for a
> > long time why not moving kde4 to /usr?
> > 
> > Adding:
> > -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy \
> > -DDBUS_INTERFACES_INSTALL_DIR:PATH=/usr/share/dbus-1/interfaces \
> > -DDBUS_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/services \
> > -DDBUS_SYSTEM_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/system-services \
> > -DSYSCONF_INSTALL_DIR:PATH=/etc \ <--- I'm not sure if it will work
> > 
> > to almost every kde module makes no sense. Not all files will be correctly
> > installed. For example there is no option for installing files in the
> > following right directories:
> > 
> > /usr/share/polkit-1/actions
> > 
> > k3b:
> > /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
> > /usr/share/dbus-1/system-services/org.kde.kcontrol.k3bsetup.service
> > 
> > kdebase4-workspace:
> > /etc/dbus-1/system.d/org.kde.fontinst.conf
> > /etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
> > /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
> > 
> > kdelibs4:
> > /etc/dbus-1/system.d/org.kde.auth.conf
> > /etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
> > 
> > Let's talk about pros/cons of moving kde to /usr
> > 
> > have a nice day,
> > Zbigniew Luszpinski
> 
> Yes. I am aware the policy kit stuff needs and has needed some attention. 
> Instead of moving everything to /usr; unless there is a consensus to do so. I 
> think I would rather see the appropriate CMake flags added to their respective 
> modules so some of the things you point out are thrown in the right system 
> directories.
> 


I'm all for moving it to /usr, that is where it should belong in the
first place. Everytime I've tried kde4 I moved the prefix to /usr,
always worked good for me without any conflicts. I don't see any reason
to keep it in /opt anymore.

-- 
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/20100710/863d6fe9/attachment-0001.bin>

From ratler at lunar-linux.org  Sat Jul 10 20:40:46 2010
From: ratler at lunar-linux.org (Stefan Wold)
Date: Sat, 10 Jul 2010 20:40:46 +0200
Subject: lunar's distrowatch module list badly out of sync again - who
	maintains it?
In-Reply-To: <201007101827.37478.zbiggy@o2.pl>
References: <201007101411.44101.zbiggy@o2.pl>
	<1278777188.21027.6.camel@localhost> <201007101827.37478.zbiggy@o2.pl>
Message-ID: <1278787246.21027.18.camel@localhost>

On Sat, 2010-07-10 at 18:27 +0200, Zbigniew Luszpinski wrote:
> > I'll take a look at it.
> 
> Thanks. :)
> 
> > grub2 is still not supported out of the box by lunar, so the correct one
> > is actually being displayed.
> 
> ??? I do not understand your point of view.
> What distrowatch script has in common with files on ISO (out of the box)?
> We are talking about distrowatch script/database and what an user can have in Lunar. Not on iso.
> If we have to match distrowatch modules with our tiny iso we should remove 90% of modules from distrowatch list
> to meet your out of the box requirement.

I never talked about the iso, I was talking about the ability for a user to run "lin grub2"
and that it would take care of everything, ie the user can issue reboot after install without any other intervention.
As long as that isn't possible we should not lure our users (read distrowatch viewers) to think that
grub2 is well supported within lunar. There is a reason why we don't even bother putting grub2 as a bootloader during
ISO install, it's an experimental module.

If grub2 is fixed properly I will agree to rename grub -> grub-legacy and grub2 -> grub.

-- 
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/20100710/3fee7804/attachment.bin>

From dennisveatch at bellsouth.net  Sat Jul 10 20:50:41 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Sat, 10 Jul 2010 14:50:41 -0400
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <1278786684.21027.9.camel@localhost>
References: <201007101606.36470.zbiggy@o2.pl>
	<201007101032.47164.dennisveatch@bellsouth.net>
	<1278786684.21027.9.camel@localhost>
Message-ID: <201007101450.41815.dennisveatch@bellsouth.net>

On Saturday, July 10, 2010 2:31:24 pm Stefan Wold wrote:
> On Sat, 2010-07-10 at 10:32 -0400, Dennis Veatch wrote:
> > On Saturday, July 10, 2010 10:06:28 am Zbigniew Luszpinski wrote:
> > > Hello,
> > > 
> > > I have just discovered that kde itself and almost all kde applications
> > > have broken dbus/messagebus and policykit integration. This
> > > integration break was caused by installing kde in non standard
> > > directory: /opt/lunar/kde/4
> > > 
> > > The result of this broken integration is that:
> > > *KAuth is broken: you can not use kde sudo like features to do root
> > > duties from casual user account. For example setting the clock:
> > > 
> > > Discussion on Lunar ML: Re: Hello world - my response:
> > > >> I asked about password request in KDE
> > > >> config tool because I couldn't set ntp as default service.
> > > > 
> > > > I reproduced the bug you probably encountered setting ntp:
> > > > "Unable to authenticate/execute the action: 7, DBus Backend error:
> > > > could not contact the helper. Connection error: Could not get owner
> > > > of name > 'org.kde.kcontrol.kcmclock': no such name. Message error:
> > > > The name org.kde.kcontrol.kcmclock was not provided by any .service
> > > > files"
> > > > 
> > > > Will look at it deeper later - Lunar installs dbus files in wrong
> > > > place.
> > > 
> > > I manually copied dbus and policykit kde files to correct locations and
> > > this bug is fixed. Another advantage is that when I plug in usb drive
> > > the kde file browser auto opens its content. Many other hotplug
> > > actions also become active. I still discover other new capabilities
> > > which appeared thanks to fixing dbus integration.
> > > 
> > > How about moving kde to /usr which is right place for it to have full
> > > kde features enabled? I understand that in kde3/4 transition time it
> > > was right to keep both of them in separate dirs. But now after someone
> > > brutally smashed off kde3 from moonbase and knowing that there is no
> > > kde5 for a long time why not moving kde4 to /usr?
> > > 
> > > Adding:
> > > -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy
> > > \ -DDBUS_INTERFACES_INSTALL_DIR:PATH=/usr/share/dbus-1/interfaces \
> > > -DDBUS_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/services \
> > > -DDBUS_SYSTEM_SERVICES_INSTALL_DIR:PATH=/usr/share/dbus-1/system-servic
> > > es \ -DSYSCONF_INSTALL_DIR:PATH=/etc \ <--- I'm not sure if it will
> > > work
> > > 
> > > to almost every kde module makes no sense. Not all files will be
> > > correctly installed. For example there is no option for installing
> > > files in the following right directories:
> > > 
> > > /usr/share/polkit-1/actions
> > > 
> > > k3b:
> > > /etc/dbus-1/system.d/org.kde.kcontrol.k3bsetup.conf
> > > /usr/share/dbus-1/system-services/org.kde.kcontrol.k3bsetup.service
> > > 
> > > kdebase4-workspace:
> > > /etc/dbus-1/system.d/org.kde.fontinst.conf
> > > /etc/dbus-1/system.d/org.kde.kcontrol.kcmclock.conf
> > > /etc/dbus-1/system.d/org.kde.ksysguard.processlisthelper.conf
> > > 
> > > kdelibs4:
> > > /etc/dbus-1/system.d/org.kde.auth.conf
> > > /etc/dbus-1/system.d/org.kde.kcontrol.kcmremotewidgets.conf
> > > 
> > > Let's talk about pros/cons of moving kde to /usr
> > > 
> > > have a nice day,
> > > Zbigniew Luszpinski
> > 
> > Yes. I am aware the policy kit stuff needs and has needed some attention.
> > Instead of moving everything to /usr; unless there is a consensus to do
> > so. I think I would rather see the appropriate CMake flags added to
> > their respective modules so some of the things you point out are thrown
> > in the right system directories.
> 
> I'm all for moving it to /usr, that is where it should belong in the
> first place. Everytime I've tried kde4 I moved the prefix to /usr,
> always worked good for me without any conflicts. I don't see any reason
> to keep it in /opt anymore.

In the past I have tinkered with the BUILD of polkit, polkit-qt-1, and the kde 
modules as pointed out by zbiggy their related dbus stuff where it "should" be 
and its a headache really. At this point Ratler, I think that is probably the 
best thing to do and put it back in /usr. If that is the consensus, I think 
qt4 should be included with that move.

However, I don't think any of this should happen until August when kde-4.5 
arrives. From what I can tell it will want qt-4.7. So if qt-4.7 is released 
before kde-4.5, we should hold off on a bump until kde-4.5 is out. That way 
people will not have to recompile twice..or more. I think when when I update 
those, that would be the best way to do it. 

-- 
Dennis Veatch

From zbiggy at o2.pl  Mon Jul 12 23:15:47 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Mon, 12 Jul 2010 23:15:47 +0200
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007101450.41815.dennisveatch@bellsouth.net>
References: <201007101606.36470.zbiggy@o2.pl>
	<1278786684.21027.9.camel@localhost>
	<201007101450.41815.dennisveatch@bellsouth.net>
Message-ID: <201007122315.54387.zbiggy@o2.pl>

How about yet another solution: let's do skeleton symlinks before kde 
install:
ln -sf /usr/share/polkit-1		/opt/lunar/kde/4/share/polkit-1
ln -sf /usr/share/dbus-1		/opt/lunar/kde/4/share/dbus-1
ln -sf /usr/share/PolicyKit		/opt/lunar/kde/4/share/PolicyKit
ln -sf /etc						/opt/lunar/kde/4/etc

This way all required files should jump in right directories without the 
need of moving kde to /usr.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100712/3dbf0a18/attachment.bin>

From dennisveatch at bellsouth.net  Tue Jul 13 00:18:46 2010
From: dennisveatch at bellsouth.net (Dennis Veatch)
Date: Mon, 12 Jul 2010 18:18:46 -0400
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007122315.54387.zbiggy@o2.pl>
References: <201007101606.36470.zbiggy@o2.pl>
	<201007101450.41815.dennisveatch@bellsouth.net>
	<201007122315.54387.zbiggy@o2.pl>
Message-ID: <201007121818.46117.dennisveatch@bellsouth.net>

On Monday, July 12, 2010 5:15:47 pm Zbigniew Luszpinski wrote:
> How about yet another solution: let's do skeleton symlinks before kde
> install:
> ln -sf /usr/share/polkit-1		/opt/lunar/kde/4/share/polkit-1
> ln -sf /usr/share/dbus-1		/opt/lunar/kde/4/share/dbus-1
> ln -sf /usr/share/PolicyKit		/opt/lunar/kde/4/share/PolicyKit
> ln -sf /etc						/opt/lunar/kde/4/etc
> 
> This way all required files should jump in right directories without the
> need of moving kde to /usr.
> 
> have a nice day,
> Zbigniew Luszpinski

Hmm. 

The only thing I don't like about that is the /etc symlink.

-- 
Dennis Veatch

From zbiggy at o2.pl  Tue Jul 13 23:27:54 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Tue, 13 Jul 2010 23:27:54 +0200
Subject: to kde module developers: kde itself and all kde applications
	have broken integration with dbus and policykit
In-Reply-To: <201007121818.46117.dennisveatch@bellsouth.net>
References: <201007101606.36470.zbiggy@o2.pl> <201007122315.54387.zbiggy@o2.pl>
	<201007121818.46117.dennisveatch@bellsouth.net>
Message-ID: <201007132328.02827.zbiggy@o2.pl>

> On Monday, July 12, 2010 5:15:47 pm Zbigniew Luszpinski wrote:
> > How about yet another solution: let's do skeleton symlinks before kde
> > install:
> > ln -sf /usr/share/polkit-1		/opt/lunar/kde/4/share/polkit-1
> > ln -sf /usr/share/dbus-1		/opt/lunar/kde/4/share/dbus-1
> > ln -sf /usr/share/PolicyKit		/opt/lunar/kde/4/share/PolicyKit
> > ln -sf /etc						/opt/lunar/kde/4/etc
> > 
> > This way all required files should jump in right directories without
> > the need of moving kde to /usr.
> > 
> > have a nice day,
> > Zbigniew Luszpinski
> 
> Hmm.
> 
> The only thing I don't like about that is the /etc symlink.

It is not so bad as it looks I think:
ls /opt/lunar/kde/4/etc
dbus-1  ksysguarddrc  xdg

If kde will be installed in /usr it will become /usr/etc where nothing 
interesting  lies. This will be problem because dbus-1 files again will 
not go to right place. That is why I start to think the symlinks idea is 
much better than moving to /usr.

have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100713/613e8002/attachment.bin>

From zbiggy at o2.pl  Wed Jul 14 21:45:03 2010
From: zbiggy at o2.pl (Zbigniew Luszpinski)
Date: Wed, 14 Jul 2010 21:45:03 +0200
Subject: lunar's distrowatch module list badly out of sync again - who
	maintains it?
In-Reply-To: <201007101411.44101.zbiggy@o2.pl>
References: <201007101411.44101.zbiggy@o2.pl>
Message-ID: <201007142145.10968.zbiggy@o2.pl>

These modules are not counted by distrowatch however we have them:
chromium
deluge
lzip
mythtv
privoxy
 
have a nice day,
Zbigniew Luszpinski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4595 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20100714/361ded39/attachment.bin>

From sofar at foo-projects.org  Fri Jul 16 05:09:29 2010
From: sofar at foo-projects.org (Auke Kok)
Date: Thu, 15 Jul 2010 20:09:29 -0700
Subject: [Lunar-commits] <moonbase> telepathy-gabble: version bump to 0.9.5
In-Reply-To: <20100715201631.29C3E9B389@doppio.foo-projects.org>
References: <20100715201631.29C3E9B389@doppio.foo-projects.org>
Message-ID: <4C3FCD69.3050707@foo-projects.org>

Zachary McGrew wrote:
> commit 916798674fccc6acff66d89b3dac70dcfe81d76f
> Author: Zachary McGrew <zmcgrew at lunar-linux.org>
> Date:   Sat Feb 20 20:56:46 2010 -0800
> 
>     telepathy-gabble: version bump to 0.9.5
> ---
>  chat/telepathy-gabble/DETAILS |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/chat/telepathy-gabble/DETAILS b/chat/telepathy-gabble/DETAILS
> index 5db67af..f437ae3 100644
> --- a/chat/telepathy-gabble/DETAILS
> +++ b/chat/telepathy-gabble/DETAILS
> @@ -1,11 +1,11 @@
>            MODULE=telepathy-gabble
> -         VERSION=0.9.1
> +         VERSION=0.9.5
>            SOURCE=$MODULE-$VERSION.tar.gz
>        SOURCE_URL=http://telepathy.freedesktop.org/releases/$MODULE/
> -      SOURCE_VFY=sha1:35e5d7158a14253d96b5d1fe05e451b0aa894d42
> +      SOURCE_VFY=sha1:58ec6b7708d84ff8a32c4211d2939677da41f423
>          WEB_SITE=http://telepathy.freedesktop.org/wiki/
>           ENTERED=20071029
> -         UPDATED=20091003
> +         UPDATED=20100220
>             SHORT="telepathy jabber/xmpp connection manager"
>  cat << EOF
>  A Jabber/XMPP connection manager that handles single- and multi-user chats and 
> _______________________________________________


I need to educate people about merge "folding" or squashing:

from git merge --help:


        --squash
            Produce the working tree and index state as if a real merge
            happened (except for the merge information), but do not actually
            make a commit or move the HEAD, nor record 
$GIT_DIR/MERGE_HEAD to
            cause the next git commit command to create a merge commit. This
            allows you to create a single commit on top of the current 
branch
            whose effect is the same as merging another branch (or more 
in case
            of an octopus).

From zmcgrew at gmail.com  Sat Jul 17 07:04:28 2010
From: zmcgrew at gmail.com (Zachary McGrew)
Date: Fri, 16 Jul 2010 22:04:28 -0700
Subject: [Lunar-commits] <moonbase> telepathy-gabble: version bump to 
	0.9.5
In-Reply-To: <4C3FCD69.3050707@foo-projects.org>
References: <20100715201631.29C3E9B389@doppio.foo-projects.org>
	<4C3FCD69.3050707@foo-projects.org>
Message-ID: <AANLkTikpJEWo9t8Fr3EXSiFE9liq_UE8IQ2GVYNuJr0J@mail.gmail.com>

> from git merge --help:
>
>
> ? ? ? --squash


Thanks. Will do that that in the future. And sorry about the ~500 commits. =)
-- 
Zachary McGrew
Web: http://zmcgrew.no-ip.com

From duncan.gibson at xs4all.nl  Fri Jul 23 22:20:01 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Fri, 23 Jul 2010 22:20:01 +0200
Subject: 1.6.5-rc1 ISO Installation page on the wiki
Message-ID: <4aa51197356b8f18ea28821e6d0779eb.squirrel@webmail.xs4all.nl>

I've just copied the old Installation page and edited it for 1.6.5:

http://wiki.lunar-linux.org/index.php/Lunar_Linux:Installation-1.6.5

The page is currently not protected, and therefore can be updated by
anyone who has registered on the wiki, so I would like to invite you
all to check it, and provide comments and corrections as needed.

Cheers
Duncan


From duncan.gibson at xs4all.nl  Sat Jul 24 20:38:21 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sat, 24 Jul 2010 20:38:21 +0200
Subject: 1.6.5-rc1 ISO Installation page on the wiki
In-Reply-To: <4aa51197356b8f18ea28821e6d0779eb.squirrel@webmail.xs4all.nl>
References: <4aa51197356b8f18ea28821e6d0779eb.squirrel@webmail.xs4all.nl>
Message-ID: <b0a679108c33c71504cc35a97880107a.squirrel@webmail.xs4all.nl>

> I've just copied the old Installation page and edited it for 1.6.5:
>
> http://wiki.lunar-linux.org/index.php/Lunar_Linux:Installation-1.6.5
>
> The page is currently not protected, and therefore can be updated by
> anyone who has registered on the wiki, so I would like to invite you
> all to check it, and provide comments and corrections as needed.

In the same vein, I've just added a page to bridge the gap after install:
http://wiki.lunar-linux.org/index.php/Lunar_Linux:DesktopEnvironments

Please feel free to expand or even correct these pages.

D


From duncan.gibson at xs4all.nl  Sat Jul 31 11:15:42 2010
From: duncan.gibson at xs4all.nl (Duncan Gibson)
Date: Sat, 31 Jul 2010 11:15:42 +0200
Subject: FreeIPA?
Message-ID: <4647d5946282fec8088e54b444265978.squirrel@webmail.xs4all.nl>

I see that Ratler has just closed out some resolve bug reports, so...

On the bugtracker there's a feature request to provide FreeIPA:
http://bugs.lunar-linux.org/view.php?id=364
http://www.freeipa.org

Does anyone have a room full of secure Lunar boxes and could comment?

I suspect that it's never going to happen, so we should just say so
and close the request.

Comments?
D