Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit

2010-01-29 Thread Paulo Matias
On Fri, Jan 29, 2010 at 8:39 AM, Joerg Schilling
joerg.schill...@fokus.fraunhofer.de wrote:
 As long as there is no support code in Linux distros to set
 capabilities without making the target program suid root anyway,

Don't be afraid, Arch Linux has support for that :)

BTW, congratulations and thanks for your software. I use cdrtools and
it is a nice piece of very high quality software.


Re: [arch-general] phonon: gstreamer support will be dropped

2009-01-23 Thread Paulo Matias
Hi,

On Fri, Jan 23, 2009 at 1:22 PM, Alberto Gonzalez i...@gnebu.es wrote:
 Gstreamer has its problems, but it's used by all the gnome people (most
 Ubuntu/Fedora users and more) so it's can't be that bad. Not as to not allow
 users to use it if they want to.

The last time I checked, sound didn't work with the Xine backend when
using OSS - http://wiki.archlinux.org/index.php/OSS#KDE_Phonon

Later I will check if this problem still persists and see if there is
a solution for making it to work with the Xine backend.

Does someone already has a solution or knows if it is working now?


Best regards,

Paulo Matias


Re: [arch-general] [arch-dev-public] request for dbus in core

2008-10-13 Thread Paulo Matias
Hi,

On Mon, Oct 13, 2008 at 4:16 AM, James Rayner [EMAIL PROTECTED] wrote:
 On Sun, Oct 12, 2008 at 3:53 PM, Paulo Matias [EMAIL PROTECTED] wrote:
 On Sun, Oct 12, 2008 at 2:49 AM, James Rayner [EMAIL PROTECTED] wrote:
 my support for [core], as an upcoming netcfg version will take
 advantage of the wpa_supplicant dbus interface.


 Please avoid using dbus in netcfg. I like it because it's clean, KISS,
 and uses only default/native stuff. I can help integrating with UNIX
 domain sockets or UDP sockets if needed.

 [1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html

 It wasn't an immediate decision to use dbus and I did evaluate other
 options such as the aforementioned sockets interface.

 dbus is just as default/native if not more native than a custom
 control interface. These days, you'll struggle to find a system out
 there which doesnt at least have dbus installed. I picked the dbus
 setup as it's quicker for me to implement, easier to maintain in the
 long term, more KISS and easily the future for linux wireless
 configuration.


I agree the dbus interface is quicker to implement. This is why I
offered help to implement the socket stuff if needed. Anyway, it would
not take a lot of time, as the /dev/udp bash interface could be used.

But if you think dbus is the future for Linux wireless configuration,
and that wpa_supplicant would let another control interfaces
unmaintained or even drop them, then it is really better to use dbus
since now.

 dbus should be available in 2.2 and default in 3.0. In 3.0 the old
 interface will not be removed, instead renamed to wireless-old and
 so available for those who dislike dbus for some odd reason.


Great.

How will the new wireless interface be configured? DAEMONS=(dbus
net-profiles) for those who want it being configured at boot up?

 If you want to implement a sockets interface, go for it. netcfg is
 designed to be modular, allowing a range of different interfaces
 implemented in any programming language (more in 2.2).


Yes, I know. It's very a good job you had done in netcfg. It was very
easy to implement a modified wireless-ral interface when I needed
some iwpriv magic to use WPA in my ralink card, in the times I had
to use rt73-cvs :)

Thanks for the quick response and please don't understand me bad. I
really appreciate your work, and I was only willing to help.

If I was too boring, please forgive this purism and my fears. The
first thing that had came to my mind when I read the dbus in [core]
message was a lot of another services (like hal) being included after
that, but no, this is not going to happen.


Best regards,

Paulo Matias


Re: [arch-general] [arch-dev-public] request for dbus in core

2008-10-12 Thread Paulo Matias
Hi,

 On Sat, Oct 11, 2008 at 3:09 PM, Jan de Groot [EMAIL PROTECTED] wrote:
 A while ago I got a request from Thomas to make a stripped down dbus
 package that does not depend on libx11 so he could use it for
 wpa_supplicant which is also in core.
 As more and more services start to interact with this dbus thing, I'd
 like to move the new dbus-core package into core. This pulls in one
 extra dependency from extra, which is expat at this moment.

Which software is interacting with wpa_supplicant using dbus? Is it
NetworkManager or something like that?

The dbus service will be let disabled by default, right?

It's worthy remembering that wpa_supplicant already supports IPC by
using UNIX domain sockets or UDP sockets, which are Linux
default/native stuff. (see [1])

On Sun, Oct 12, 2008 at 2:49 AM, James Rayner [EMAIL PROTECTED] wrote:
 my support for [core], as an upcoming netcfg version will take
 advantage of the wpa_supplicant dbus interface.


Please avoid using dbus in netcfg. I like it because it's clean, KISS,
and uses only default/native stuff. I can help integrating with UNIX
domain sockets or UDP sockets if needed.

[1] http://hostap.epitest.fi/wpa_supplicant/devel/wpa__ctrl_8c-source.html


Best regards,

Paulo Matias