Re: [arch-general] Best Practices...

[Pierre Chapuis]

On Tue, 28 Sep 2010 18:41:20 +0300, Ionu?^? Bîru 
wrote:

> use abs to recompile mplayer against x264-git

That would be a good solution for most packages but in this case you
should be aware that:

 - x264 is used only for video encoding, not decoding, so unless you 
   encode videos you simply don't need x264-git;

 - if you *do* encode videos and care about performance you should 
   compile mplayer on your machine with a custom PKGBUILD or one from 
   AUR that lets its build process auto-detect your hardware.
   mplayer-svn is probably a good choice.

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] dovecot.conf kills update (conflicting file)

[Pierre Chapuis]

On Thu, 02 Sep 2010 23:02:53 -0500, "David C. Rankin"
 wrote:

>   I'm not knocking Arch, I'm just trying to explore how much work it
> would take to make pacman just a little smarter so it avoids some of
> these things. That is what I DON'T know.

The work it would take is not the only problem. I (and probably other
people too) don't want Pacman to be too smart. Because it does only what
it must in a conservative manner, I can understand what it does and fix
my system if needed. For instance, I had the same problem with Dovecot
and I understood immediately what had happened so I changed my
configuration file and it didn't crash on reboot.

The more things a tool does, the more difficult it is to understand.
Aptitude is probably "smarter" than Pacman but I screw my system up a
lot more when I use it on Debian than when I use an Arch box. That's the
advantage of simplicity: as an operations guy I prefer to run several
commands and edit a bunch of configuration files but know perfectly what
I've done than run one command that works 99% of the time but doesn't
give you a chance to fix the system when it screws up.

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] Unificate login credentials in Arch's website

[Pierre Chapuis]

On Tue, 3 Aug 2010 13:32:36 +0200, Dieter Plaetinck 
wrote:

> Still, unified logins is a problem we're having for years. and many
> people have 1 main pc.  If browser programmers would implement a small
> and easily accessible "account manager" which uses client ssl
> certificates (and web server/application developers would make client
> ssl certificates a bit more userfriendly) then we would have a much
> better and cleaner unified login system then openid, as far as i can
> see.

The point of OpenID is that it leaves the choice of the authentication
method to the user. For instance, you could use OpenID with SSL certs
if you choose a provider like https://certifi.ca/.

-- 
catwell

Re: [arch-general] Better NILFS2 Support

[Pierre Chapuis]

On Sun, 1 Aug 2010 16:58:00 +0200, Dieter Plaetinck 
wrote:
> On Sun, 1 Aug 2010 16:46:33 +0200
> Heiko Baums  wrote:
> 
>> I don't think that nilfs-utils should be moved to the base group. I
>> agree with moving it to [core] but not to base, because base is
>> assumed to be installed on every computer and packages in the base
>> group are usually not listed in the depends array of a PKGBUILD.
>> 
>> On the contrary I think there could be some other file system tools
>> like jfsutils, lvm2 and xfsprogs be removed from the base group (not
>> from [core]).
> 
> I think this explanation makes sense.  I just found this back:
> http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup
> So indeed, it seems like the goal is to remove all non-essential things
> (reiserfs, xfs, ..) from base.

Just for information, the opposite point of view recently came up on the
suckless mailing-list: http://lists.suckless.org/dev/1007/5256.html

I prefer Arch's approach but it is probably true that a large base system
reduces the workload of package maintainers.

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] makepkg creates symlink to the package file

[Pierre Chapuis]

"C Anthony Risinger"  a écrit :

>beh, i thought you were onto something... i didn't look at the makepkg
>sources, but it is treating PKGDEST='"" as if it was never set.  so,
>no dice :-(
>
>however, if i use an absolute path (instead of ".") it works alright.
>in fact, i seem to have general problems with trying to use relative
>paths as PKGDEST:
>
>==> ERROR: You do not have write permission to store packages in ./pkg/out.
>Aborting...
>
>but i do of course.

Maybe you could use PKGDEST="$(pwd)" as a workaround?

-- 
catwell

Re: [arch-general] PKGBUILD parser

[Pierre Chapuis]

"Andre "Osku" Schmidt"  a écrit :

>> A regular
>> expression will never be able to parse that.because it can never decide
>> which brace is the final one. This might be better explained here.
>>
>> http://stackoverflow.com/questions/133601/can-regular-expressions-be-used-to-match-nested-patterns
>
>thank you. i'll continue my journey on parsing this another way.

Actually if you read the page linked above completely you will notice that it 
says that you can. Regexps like POSIX that use finite automata can't but PCRE 
(that are everywhere) can, at least recent versions. That's also why they are 
slower.
-- 
catwell (from mobile phone) 

Re: [arch-general] New Using AUR

[Pierre Chapuis]

On Wed, 24 Mar 2010 15:34:01 +0100, Samuel Martín Moro 
wrote:

> but yaourt is very slow (other programming language, don't know exactly,
> but
> even on a core i7, it's shocking to see how long it took to do simple
> things...)

It used to be slow mainly because it did a lot of parsing with Bash and
Unix tools. Its experimental branch [1] relies on a new, external tool
in C and is much faster.

[1] http://aur.archlinux.org/packages.php?ID=35479

Re: [arch-general] .pyo files in twisted package

[Pierre Chapuis]

On Thu, 11 Mar 2010 16:42:08 +0200, Nezmer  wrote:
> Hi,
> 
> I don't know If this has been brought up before.
> 
> The PKGBUILD includes "--optimize=1". So .pyo files are included in
> the package and they conflict with existing ones.
> 
> Is there a reason to do this for twisted specifically? Or did I miss a
> change in python packaging policies?

You missed a change in the packaging policy:
http://bugs.archlinux.org/task/17376

-- 
catwell

Re: [arch-general] [arch-dev-public] Replace Planet wit h Planet-Venus?

[Pierre Chapuis]

On Sun, 28 Feb 2010 00:21:05 +1000, Allan McRae 
wrote:

> Nope. It is still an issue.  I made two posts since the update and they 
> are the only two posts of mine on the feed.  There was two others on 
> there earlier and they dropped off.  So the current setup does only 
> display two posts from each blog.

This is strange. For example on http://planet.resel.org/ there are 3
posts from my weblog, so I don't know where this limit comes from.

Here's the relevant part of the configuration file:

[Planet]

name= Planet Teubreux
link= http://planet.resel.org
owner_name  = ResEl
owner_email = *** hidden (nospam) ***
output_theme= /srv/www/planet-venus/theme
cache_directory = /srv/www/planet-venus/cache
output_dir  = /srv/www/planet-venus/output
feed_timeout= 20
items_per_page  = 30
log_level   = DEBUG
items_per_page  = 20
days_per_page   = 0
date_format = %d %B %Y à %H:%M %p
new_date_format = %A %d %B %Y
encoding= utf-8
locale  = fr_FR.UTF-8

-- 
catwell

Re: [arch-general] [arch-dev-public] Clean up the base group

[Pierre Chapuis]

(Forked from arch-dev-public)

On Fri, 26 Feb 2010 15:40:27 +0200, Roman Kyrylych
 wrote:

> The following packages are questionable:
> * diffutils - why it should be on every system?
> * gawk - why it should be on every system?
> [...]
> * mailx
> [...]
> * vi - ok, no bikeshed thing here, but there's nano for base

Those are required for Single UNIX Specification v3 conformance. However
I think Arch Linux doesn't conform for other reasons anyway, and I
support their removal from the base group. I always remove the 2 latter
by hand after installing.

-- 
catwell

Re: [arch-general] [arch-dev-public] Replace Planet wit h Planet-Venus?

[Pierre Chapuis]

On Sat, 27 Feb 2010 17:56:50 +1000, Allan McRae 
wrote:
>
> The setup seems to post the last two post form each person, no matter 
> how long ago they were.  That means we get a couple of posts from 2006 
> at the bottom of the page.  Also, people who post quite frequently (e.g.

> cactus) will only get their two newest posts shown.
> 
> Is there an option to go back to showing the most recent (e.g.) 30 
> posts, not matter who they are from like the old setup?

(Forked from arch-dev-public)

This only happens on the initial import of feeds. New posts will be
displayed in chronological order as expected.

-- 
catwell

Re: [arch-general] pacman.conf: can I use wildcards?

[Pierre Chapuis]

On Wed, 17 Feb 2010 20:34:09 -0600, Aaron Griffin

wrote:
>>
>> No, we don't support globbing in these options. Question to the list-
>> does it make sense to do so?
> 
> Yes, but it would also be nice to support recursion here as well. For
> instance:
> 
> NoExtract = /usr/share/doc/*
> 
> should disable ALL doc extraction, no matter how deep it's nested

Recursion is a good idea but that's not what is usually expected from *.
I would suggest to use ** like in ZSH if it is implemented. Real regular
expressions support would solve all those problems but that's probably
overkill.

Re: [arch-general] xf86-video-intel and KMS

[Pierre Chapuis]

On Thu, 11 Feb 2010 23:05:26 +0100, Damjan Georgievski 
wrote:
>>  - Is there a way to change the mode on the fly without rebooting?
> 
> I haven't tested it but you can try "fbset"

fbset works without KMS but not with it. It does change something, but
not thye way you want. For example with a 1280x960 screen it is possible
to get a 640x480 console in the top left corner of the screen but not
fullscreen.

>  - Is there a way to enforce an aspect ratio, eg. to have a 4:3 mode
>>with black stripes on the sides on a 16:10 strip?
> 
> I'm not sure about this, maybe if you set a lower 4:3 resolution on
> your 16:10 screen AND in the BIOS of your laptop it's setup to NOT
> scale the screen it will show the black stripes.

Maybe, sadly I don't have this option in my BIOS.

-- 
catwell

Re: [arch-general] xf86-video-intel and KMS

[Pierre Chapuis]

On Thu, 11 Feb 2010 21:52:37 +0100, Pierre Chapuis 
wrote:
> on a 16:10 strip?

Of course I meant a 16:10 screen...

-- 
catwell

Re: [arch-general] xf86-video-intel and KMS

[Pierre Chapuis]

On Thu, 11 Feb 2010 12:28:53 -0500, Alexander Lam 
wrote:
> On Thu, Feb 11, 2010 at 7:30 AM, Pierre Chapuis 
> wrote:
>> I saw on arch-announce that xf86-video-intel now only supports KMS, and
I
>> wanted to ask: is there still a way to specify the resolution of
virtual
>> consoles, like we used to do with vga=XXX in kernel options?
> 
> vga=:

Thank you, just what I needed! It was in the commit log from Damien's
link too. I tried it, and it works.

As Thomas said, the right mode is chosen automatically on a laptop, but
sometimes I might need to set it on an external device such as a beamer
(overhead projector), or I might need a 80x24 console even on my laptop 
screen.

Now, more questions:
 
  - Is there extensive documentation about that somewhere?
  - Is there a way to enforce an aspect ratio, eg. to have a 4:3 mode
with black stripes on the sides on a 16:10 strip?
  - Is there a way to change the mode on the fly without rebooting?

I will edit the Arch wiki once I get answer to those.  

--
catwell

[arch-general] xf86-video-intel and KMS

[Pierre Chapuis]

I saw on arch-announce that xf86-video-intel now only supports KMS, and I
wanted to ask: is there still a way to specify the resolution of virtual
consoles, like we used to do with vga=XXX in kernel options?

-- 
catwell

Re: [arch-general] A suggestion for the devs regarding rebuilds

[Pierre Chapuis]

Le Tue, 09 Feb 2010 03:05:14 +,
Mauro Santos  a écrit :

> > I'm facing a decision to change five 'critical' machines
> > in need of an upgrade to Arch or not. Over the last months
> > I've installed Arch on three less critical ones to get to
> > know the system. Up to yesterday the decision looked quite
> > clear
> 
> Then maybe you should select something that gives you more peace of
> mind. I'm not saying that you can't use Arch for mission critical
> machines but you need to know very well what you are doing.

That's the whole idea behind http://www.archserver.org/

-- 
catwell

Re: [arch-general] A suggestion for the devs regarding rebuilds

[Pierre Chapuis]

Le Tue, 9 Feb 2010 09:12:29 +0100,
f...@kokkinizita.net a écrit :

> On Mon, Feb 08, 2010 at 08:02:04PM -0700, Brendan Long wrote:
> 
> > Except then you'd annoy everyone who wants their package manager to work
> > properly. When I update a package I expect it to clean up after itself.
> 
> Work properly = not remove things that are still needed.
> Clean up after itself = remove them when no longer needed.
> 
> The situation is now very clear. Pacman in its current
> form just *can't* do this, and this defect is being
> presented as a virtue, which is a classical marketing
> scenario.

There are package managers that can do that, I think apt-get is one.
Pacman can not by design because it is made for rolling release
distributions: the system is considered to be always up to date, all of
it. You are not supposed to update just part of it.

Now if you agree to that you have too problems:

1) Sometimes installing new packages drag updates of libraries. Simple
solution: never use pacman -Sy, always -Syu; if you want to install a
package without updating everything use -S without the y.

2) There are problems with mirror sync. This is a *mirror sync*
problem, not a Pacman problem. And by the way, the mirror I use doesn't
have that problem because it updates the database files before the
packages themselves. Because of that, if some packages are out of date,
you get transient resolver failures at download time on -Syu and pacman
just doesn't update. All you have to do is try again later... Updating
all the database files *last* would be even better: there would never
be any sync problem (if I understand well how it works).

-- 
catwell

Re: [arch-general] A suggestion for the devs regarding rebuilds

[Pierre Chapuis]

Le Tue, 09 Feb 2010 02:21:58 +0100,
hollunder  a écrit :

> Maybe the issues are somewhere else? I don't know. One observation I, as
> a stinking normal user, could make is that there are few devs around
> where users hang out. Let's see.. I know of one dev active in #archlinux
> on IRC and about three devs active on this mailinglist, including you,
> Aaron and the IRC-dev. So maybe it's the devs who detached from the
> users and there's simply no-one around who could pass on the knowledge?

What? I have not been on IRC or the forums for a long time because of
the low signal to noise ratio there, but that's just because the number
of users increased, not because the presence of the devs decreased.
Just by reading the MLs or looking at Flyspray you could easily say
that a lot of them are very active and responsive. Not to mention the
TUs...

> One thing is for sure, elitist and cocky behavior will alienate users,
> competent ones as well, and alienated users wont help, they wont write
> patches, they'll switch distro at best.

I'm not sure of that. If by an elitist behavior you mean one that
consists in refusing to add complexity to the system to simplify the
life of users, then I think it will not alienate all the users. I for
one use Arch precisely because of that. You can call it an elitist
attitude, or the Arch Way, as opposed to the Ubuntu Way. Ubuntu is
"Linux for human beings", Arch Linux is Linux for grown-ups who are not
afraid to think, learn and spend some time repairing their mistakes
when they fuck up.

So I'm with Allan here: either the user base has to adapt / change, or
Arch itself has to change. But knowing that the devs are users
themselves and that most of them understand the original Arch Way, I
guess the users who don't like it will have no choice but to adapt,
leave or fork.

-- 
catwell

Re: [arch-general] A suggestion for the devs regarding rebuilds

[Pierre Chapuis]

Le Tue, 09 Feb 2010 09:26:37 +1000,
Allan McRae  a écrit :

> So the cause must be... A change in user-base? Maybe just an increase in 
> user-base resulting in more people who think Arch should be done their 
> way and not the Arch way?

That looks obvious to me. Pacman has been working the same way for a
long time, and yet each major rebuild brings more criticism. Most of
them, I suppose, come from users who come from other distributions with
different founding principles.

There was a time (not so far) when if a package didn't work after a
rebuild the users would be told to try to build it using ABS, patch it
if it didn't, send the patch upstream and eventually to Flyspray if
upstream didn't take act. The thing that had to be fought by the devs
was users advising other users to symlink. But that was two-three years
ago, when most Arch users came from a Gentoo / Slackware background.
Now the user base has increased consequently, mostly with users that
come from the Debian / Ubuntu world. No need to look further, really...

Maybe those new users should be reminded that:
  - Arch is not a democracy. Devs decide, users either agree with them
or go away / fork. Or at least they are expected to send patches.
  - If they came to Arch because it worked better, they should wonder
why it does. Otherwise, why not use another distribution?

-- 
catwell

Re: [arch-general] A suggestion for the devs regarding rebuilds

[Pierre Chapuis]

Le Mon, 8 Feb 2010 23:29:48 +0100,
f...@kokkinizita.net a écrit :

> *** There is no conflict. *** Pacman can forget
> about and even delete the package that supplied
> the old version. It just *should not remove the
> old library itself*.

And you end up with .so files not tracked by Pacman in your filesystem?
Imagine what will happen to a 2 year-old installation...

As you said, maintenance is something that should be planned. So if you
really need to be sure that your machine will still work after an
upgrade, either try it in a clone VM first (I used to do that with my
server) or be ready to use the Pacman cache / Arch Rollback Machine to
reinstall the old version of the package that broke everything.

-- 
catwell

Re: [arch-general] Arch Linux and security - it needs some work

[Pierre Chapuis]

Le Mon, 1 Feb 2010 22:21:03 +0100,
Heiko Baums  a écrit :

> If a security bug is found it should be filed to and fixed by upstream
> anyway.

This is true, except sometimes upstream patching can take a while and
it would be a good idea to warn users about the problem in the meantime
so that they can take temporary measures. If there's a single thing
that I miss about Arch security, it's Arch Sheriff : it basically did
that. Maybe people who want to do something about security could begin
with resurrecting it.

-- 
catwell

Re: [arch-general] Arch Linux and security - it needs some work

[Pierre Chapuis]

Le Sun, 31 Jan 2010 15:01:15 +,
Ananda Samaddar  a écrit :

> After some discussion we should be able to reach a consensus and
> start giving security issues the priority they deserve.

Maybe this is the problem: some people (including me) might think that
perfect security is not a priority. The people from Debian see it this
way:

security > functionnality > simplicity

I see it the other way around:

simplicity > functionnality > simplicity

Meaning: I prefer something that is simple and insecure. I am OK with
more security if it doesn't make Arch tools overly complex. Otherwise,
because Arch is a desktop (as opposed to server) distribution, it is
just not worth it.

-- 
catwell

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

[Pierre Chapuis]

Le Fri, 29 Jan 2010 17:36:58 +,
Pierre Chapuis  a écrit :

> Le Fri, 29 Jan 2010 17:58:42 +0100,
> Jan de Groot  a écrit :
> 
> > Implementing it in star has no use, as our package manager doesn't use
> > star but libarchive, the library that bsdtar is based on.
> 
> Technically the PKGBUILD could makedepends('star') and use it to
> extract the source with ACL support...

Ignore this, I just understood how stupid that is. The point is not to
support ACLs for the source tarball but for the package itself.

-- 
catwell

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

[Pierre Chapuis]

Le Fri, 29 Jan 2010 17:58:42 +0100,
Jan de Groot  a écrit :

> Implementing it in star has no use, as our package manager doesn't use
> star but libarchive, the library that bsdtar is based on.

Technically the PKGBUILD could makedepends('star') and use it to
extract the source with ACL support...

-- 
catwell

Re: [arch-general] A universal Operating System API - why don't we have it?

[Pierre Chapuis]

Le Sat, 19 Dec 2009 23:10:29 +0100,
Frédéric Perrin  a écrit :

> Le vendredi 18 à 10:24, RedShift a écrit :
> > Things like enumerating all hardware
> > devices, configuring a network interface, drawing a window, ejecting
> > the CD-ROM drive, getting notified about new hardware plugged in,
> > etc... It's different on every operating system. 
> 
> Isn't it one of the goals of hal ? It does exist outside of Linux (in
> FreeBSD for instance: ).

The problem is that it's deprecated. But you have a point that the
FreeDesktop initiative tries to fulfill part of those wishes.

-- 
catwell

Re: [arch-general] A universal Operating System API - why don't we have it?

[Pierre Chapuis]

There are things like that (think NDIS - it's Microsoft, but it's a
step in the right direction), just not enough , but I think it's a
question of time.

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Fri, 4 Dec 2009 23:26:27 +0100,
Xavier  a écrit :

> If I got that right, I find it quite funny and ironical that a
> clueless and endless ranting about dbus ended up making me understand
> the coolness of dbus.

I agree, it sounds cool, but then I thought: web browsers have been
doing that for years. Then comes Google Chrome, which uses a new
process for each tab to increase stability, and most people love it.

I say maybe we need design patterns on that issue ;)

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Sat, 05 Dec 2009 00:34:59 +0100,
Jan de Groot  a écrit :

> Please don't post things you haven't looked into. Hal has nothing to do
> with your gfx driver, as gfx drivers are probed by xorg itself using the
> libpciaccess library. The only things managed by hal/dbus in xorg are
> input devices.

By the way, for those who wanted an example of something broken, I'm
not sure but I think this might be related:
http://bugs.archlinux.org/task/17380

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Fri, 4 Dec 2009 10:33:38 +1030,
Ty John  a écrit :

> I don't really understand what this project does other than being able
> to execute Plan 9 binaries.
> What's the point then?

The point is to have a Plan 9 userspace on the Linux kernel (which is
maintained and mainstream), instead of the GNU userspace (which is
-arguably- not unixy enough).

It makes it Linux, but not GNU/Linux (a bit like Android).

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Thu, 3 Dec 2009 21:58:25 +0100,
Xavier  a écrit :

> On Thu, Dec 3, 2009 at 9:32 PM, Pierre Chapuis  wrote:
> >
> > I like D-Bus because it can actually simplify the applications that
> > rely on it and avoid reiventing the wheel. But I do agree that
> > applications that *don't* need to communicate with other applications
> > have no reason to be linked against it!
> >
> 
> Is there any application that actually does that ?

Take gedit for example. It is a text editor, and:

[23:44 TA|catwell] ldd $(which gedit) | grep dbus
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 
(0x7f5df48bb000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x7f5df467c000)

AFAIK it uses dbus only to communicate with itself (between its instances).
There is no iteroperability problem, so D-Bus is not that useful to me.
But then again, maybe I don't know how gedit works well enough to judge...

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Thu, 3 Dec 2009 20:41:26 -0200,
Denis A. Altoé Falqueto  a écrit :

> On Thu, Dec 3, 2009 at 4:14 PM, Arvid Picciani  wrote:
> > Aaron Griffin wrote:
> > "Those who don't understand UNIX are condemned to reinvent it, poorly." –
> > Henry Spencer
> 
> "And those who do understand it are doomed to implement it right,
> that's why there is Plan 9." - Me.
> 
> :) (For those who don't know, Plan 9 was made by the some of people
> who created Unix.)

By the way, we could have both: http://www.glendix.org/

-- 
catwell

Re: [arch-general] [OT] What is wrong with DBus anyway?

[Pierre Chapuis]

Le Thu, 3 Dec 2009 17:05:18 -0200,
Denis A. Altoé Falqueto  a écrit :

> In fact, DBus is implemented over Unix sockets. FIFOs and sockets
> don't define the format that will be used over them, they are just
> channels of communication. DBus is a wire protocol, as they say in the
> home page. It defines the format the methods and parameters should be
> converted to make the communication viable, as well as an event system
> so that applications can register interest in some activity.

I do not know how D-Bus works on the technical level, but as far as I
understand D-Bus means many things and people mix them up. Here is what
I understand.

There is indeed a D-Bus protocol [1], and I don't see why anybody would
be against that, because a protocol is a written document and not a
piece of software: it doesn't enforce an implementation.

Then, there is a library, libdbus, that implements that protocol. Note
that it is not the only one, D-Bus's home page states that the
implementations of D-Bus for Java, C# and Ruby do not rely on it. I
don't think that's what everybody is targeting either.

Finally, there is the D-Bus message bus daemon. The one you see in top,
here:

3188 dbus 20 0 10664 1028 724 S 0 0.1 0:00.51 dbus-daemon

Actually, there are multiple instances of the daemon running at the
same time. Basically, what they do is route the D-Bus messages between
the applications. This is what most people target, because it is an
extra process running on their system.

That being said, I am in favor of simplicity, I am even often called a
minimalist, but I kind of like the idea of having a unified way to
communicate between Unix applications. I even appreciate the fact that
it relies on a daemon and not on an in-kernel thing but I am also
fascinated by Minix3, so I have a bias towards putting everything in
user space ;)

I like D-Bus because it can actually simplify the applications that
rely on it and avoid reiventing the wheel. But I do agree that
applications that *don't* need to communicate with other applications
have no reason to be linked against it!

[1] http://dbus.freedesktop.org/doc/dbus-specification.html

-- 
catwell

Re: [arch-general] usable browser?

[Pierre Chapuis]

Le Fri, 27 Nov 2009 19:59:42 +0100,
Gordon Schulz  a écrit :

> > compressed pages like lxde.org

> On Mac right now - but my Webkit based Safari renders this page just fine. As 
> about any page anyway. And so does Chrome.

Surf on Arch renders it well too.

Re: [arch-general] Frustrating Dependencies

[Pierre Chapuis]

Le Mon, 23 Nov 2009 04:46:44 -0800,
Giovanni Scafora  a écrit :

> mplayer != everything

Agreed, and mplayer is meant to be compiled on the machine on which it
is used. No set of dependencies will ever make all the users happy. You
should use one of the packages on the AUR for that, with Yaourt if you
are too lazy to update it yourself by hand.

-- 
catwell

Re: [arch-general] MUA

[Pierre Chapuis]

Le Tue, 17 Nov 2009 13:23:25 -0600,
Aaron Griffin  a écrit :

> Aha, so this is the same as the "threaded vs nested comments" when it
> comes to web page commenting. As far as I know, that's a holy war no
> one will ever win.

Strange that you like Gmail-style but the comments on your own blog are
nested ;)

Otherwise, I am also searching for something a console application that
could efficiently replace claws-mail (because I would like to use it
through SSH and I don't like -X and the like) but I haven't found any
for now. The best one I've tried is sup but its (and gmail's) model
doesn't work well with mutiple mailoxes. I have seven, and I want to
keep using all of them for receiving *and* sending messages, as they
serve different purposes.

Notmuch looks promising and I could maybe build a nice interface on top
of it if I had more time / fewer projects / was less lazy...

-- 
catwell

Re: [arch-general] archlinuxfr bad virtualbox_bin-3.0.10-1 package

[Pierre Chapuis]

Le Wed, 18 Nov 2009 00:56:24 -0600,
"David C. Rankin"  a écrit :

> On Tuesday 17 November 2009 05:50:02 and regarding:
> > Am Dienstag 17 November 2009 12:22:35 schrieb tuxce:
> > > I'm uploading it right now, thanks for the information.
> > 
> > You know that redistribution of the binary package is not legal? (except
> >  you have got the permission from Sun of course)
> > 
> 
> UUH?
> 
>   ... and the penalty? Answer: The profits made from the distribution in 
> violation of the patent, trademark or copyright. The normal profits of 3rd 
> partry repository maintainer for hosting any type of generally distributed 
> quasi opensource package (usually $0, nada, gratto...) So in the case of 
> damages=profits -- you can do the math.

Afaik the archlinux.fr mirror is in France, so the law is not the same.
I don't know exactly what they risk but they would at least have to pay
the lawyer fees in case of a trial. Sun probably wouldn't do that, but
Oracle I don't know.

>   Of course all just assuming arguendo, because we know the archfr folks 
> have 
> the permissions they require :p

Why am I almost sure that they don't? ;)

-- 
catwell

Re: [arch-general] [arch-dev-public] Strange behaviour of pacman

[Pierre Chapuis]

Le Thu, 22 Oct 2009 16:13:33 -0500,
Aaron Griffin  a écrit :

> >> > I have found a way to automate that which is, I believe, not 
> >> > PKGBUILD-dependant.
> >> >
> >> > Here's what I do in the PKGBUILD:
> >> >
> >> > [...]
> >> > install="pyo_remover.install"
> >> > [...]
> >> > build() {
> >> >  [...]
> >> >  # Take care of .pyo files
> >> >  cd $pkgdir
> >> >  echo "post_install() {" > $startdir/$install
> >> >  for _i in  $(find . -name '*.pyo'); do
> >> >    echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
> >> >    echo > "$_i"
> >> >  done
> >> >  echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >>  
> >> > $startdir/$install
> >> > }
> >> >
> >> > pyo_remover.install can be anything, even an empty file. For packages 
> >> > that need a .install file this has to be adapted.
> >> >
> >> > Does this look like a good way to solve the problem?  I know the way I 
> >> > do it for now is kind of ugly, but I think it could be much cleaner if 
> >> > the same kind of thing was done directly by makepkg.
> >>
> >>
> >> Did you mean for this to be post_install? This should be done on
> >> remove, if I'm not mistaken, as the pyo files are actually a good
> >> thing
> >
> > No, I meant that to be post_install, because that way:
> >
> >  - Pacman will track the .pyo files because they are in the package (as 
> > empty text files), so they will be deleted on removal.
> >
> >  - The .pyo files will be deleted after install so I think they will be 
> > re-generated at runtime. This means there will always be generated for the 
> > right architecture and Python version.
> >
> > By the way I think you can do the same for .pyc files.
> 
> This requires that the program has write access to those files, which
> is generally not the case

This is true. A way to fix it would be to run 'python -O -mcompileall -q 
/usr/lib/python2.6' as root. That will generate .pyo files for all python 
packages though, so it means all the packages have to track theirs, otherwise 
there will be stray files.

-- 
catwell

Re: [arch-general] [arch-dev-public] Strange behaviour of pacman

[Pierre Chapuis]

Le Thu, 22 Oct 2009 14:02:53 -0500,
Aaron Griffin  a écrit :

> On Thu, Oct 22, 2009 at 1:45 PM, Pierre Chapuis  wrote:
> > On Tue, 20 Oct 2009 09:48:58 +1000,
> > Allan McRae  wrote:
> >
> >> Jan de Groot wrote:
> >> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
> >> >
> >> >> Are you saying that the .pyo files are no longer architecture
> >> >> independent? I was under the assumption they were.
> >> >>
> >> >
> >> > Actually, they're even python-version specific. Updating python could
> >> > break the precompiled .pyo files.
> >> >
> >>
> >> And this whole issue was a fairly major source of headaches during the
> >> python-2.6 transition...  which is why I started making the python
> >> packaging policy to deal with them, although that obviously was never
> >> finished with  (in fact, I had never seen the comment with --optimize=1
> >> in it).
> >>
> >> Now my main concern about all of this is that .pyc and .pyo files used
> >> to contain full paths to where they were created.  That meant they need
> >> to be created on the users system and not during the packaging stage.
> >> I have not confirmed if this is still the case.
> >>
> >> So the best way to deal with them seems to be:
> >> 1) touch them during packaging
> >> 2) generate them during post_install()
> >
> > I have found a way to automate that which is, I believe, not 
> > PKGBUILD-dependant.
> >
> > Here's what I do in the PKGBUILD:
> >
> > [...]
> > install="pyo_remover.install"
> > [...]
> > build() {
> >  [...]
> >  # Take care of .pyo files
> >  cd $pkgdir
> >  echo "post_install() {" > $startdir/$install
> >  for _i in  $(find . -name '*.pyo'); do
> >    echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
> >    echo > "$_i"
> >  done
> >  echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >>  $startdir/$install
> > }
> >
> > pyo_remover.install can be anything, even an empty file. For packages that 
> > need a .install file this has to be adapted.
> >
> > Does this look like a good way to solve the problem?  I know the way I do 
> > it for now is kind of ugly, but I think it could be much cleaner if the 
> > same kind of thing was done directly by makepkg.
> 
> 
> Did you mean for this to be post_install? This should be done on
> remove, if I'm not mistaken, as the pyo files are actually a good
> thing

No, I meant that to be post_install, because that way:

 - Pacman will track the .pyo files because they are in the package (as empty 
text files), so they will be deleted on removal.

 - The .pyo files will be deleted after install so I think they will be 
re-generated at runtime. This means there will always be generated for the 
right architecture and Python version.

By the way I think you can do the same for .pyc files.

-- 
catwell

Re: [arch-general] [arch-dev-public] Strange behaviour of pacman

[Pierre Chapuis]

On Tue, 20 Oct 2009 09:48:58 +1000,
Allan McRae  wrote:

> Jan de Groot wrote:
> > On Mon, 2009-10-19 at 15:18 -0500, Aaron Griffin wrote:
> >   
> >> Are you saying that the .pyo files are no longer architecture
> >> independent? I was under the assumption they were.
> >> 
> >
> > Actually, they're even python-version specific. Updating python could
> > break the precompiled .pyo files. 
> >   
> 
> And this whole issue was a fairly major source of headaches during the 
> python-2.6 transition...  which is why I started making the python 
> packaging policy to deal with them, although that obviously was never 
> finished with  (in fact, I had never seen the comment with --optimize=1 
> in it).
> 
> Now my main concern about all of this is that .pyc and .pyo files used 
> to contain full paths to where they were created.  That meant they need 
> to be created on the users system and not during the packaging stage.   
> I have not confirmed if this is still the case.
> 
> So the best way to deal with them seems to be:
> 1) touch them during packaging
> 2) generate them during post_install()

I have found a way to automate that which is, I believe, not PKGBUILD-dependant.

Here's what I do in the PKGBUILD:

[...]
install="pyo_remover.install"
[...]
build() {
  [...]
  # Take care of .pyo files
  cd $pkgdir
  echo "post_install() {" > $startdir/$install
  for _i in  $(find . -name '*.pyo'); do
echo "rm -f "$(echo "$_i" | cut -c2-) >> $startdir/$install
echo > "$_i"
  done
  echo -e '}\npost_upgrade() {\npost_install $1\n}\n' >>  $startdir/$install
}

pyo_remover.install can be anything, even an empty file. For packages that need 
a .install file this has to be adapted.

Does this look like a good way to solve the problem?  I know the way I do it 
for now is kind of ugly, but I think it could be much cleaner if the same kind 
of thing was done directly by makepkg.

-- 
catwell

Re: [arch-general] VPS hosting with Arch

[Pierre Chapuis]

Le Mon, 28 Sep 2009 15:10:15 -0500,
Crouse  a écrit :

> I had an account with slicehost before as well, i did not like the way
> the kernel updates were handled, so elected not to continue using
> them, however they were not bad to work with.

They have just changed that! 
http://www.slicehost.com/articles/2009/9/22/kernels-in-the-slicemanager

I use SliceHost too and I'm as happy as I could be.

Re: [arch-general] Status of bluetooth in Arch, specially bluez package

[Pierre Chapuis]

Le Sat, 12 Sep 2009 21:49:42 +,
Ricardo Hernandez  a écrit :

> Sorry i hit tab and send the message before i finish. The situation is that
> bluez in Arch is version 4.39 and upstream version is 4.53, is a lot of
> difference, taking into account that it fixes a bunch of errors.
> 
> I have a personal repo and updated bluez to newest version ASAP. I don't
> know what happened to Geoffroy, maybe is busy but bluez needs some
> attention, and PKGBUILD doesn't change a lot.
> 
> I'm also in contact with new maintainer of kbluetooth ( that's the official
> name that he commits now ), is also an Arch user and keep tracking all
> changes in svn. Package kbluetooth4-svn now builds in last revision, i
> upload and updated PKGBUILD with the revision that builds successfully.

Looks like the devs are aware of it: 
http://mailman.archlinux.org/pipermail/arch-dev-public/2009-September/013363.html

-- 
catwell

Re: [arch-general] "hardware clock" on a VPS

[Pierre Chapuis]

Le Fri, 28 Aug 2009 15:26:43 -0500,
Dan McGee  a écrit :

> Look at the newest initscripts package, I just fixed this. Setting the
> clock to anything except "localtime" or "UTC" will omit the hwclock
> calls now.
> 
> http://projects.archlinux.org/?p=initscripts.git;a=commitdiff;h=2008846efe204b79d1c0f281d609a1f4b23431c8

Oh great, fixed *before* the request. I guess nobody can top you in reactivity 
now! That was the update to *that* version of initscripts that made me send 
that mail, I just hadn't noticed that it fixed the problem since I still had 
HARDWARECLOCK="UTC" in my rc.conf.

Thanks anyway!

-- 
catwell

[arch-general] "hardware clock" on a VPS

[Pierre Chapuis]

Hi everybody,

I was wondering if there's a means to specify, in rc.conf or somewhere else, 
that you never want to set your hardware clock.

That's because, on Xen-based VPS, the hardware clock is handled on the 
hypervisor level, and /etc/cron.hourly/adjtime gives warnings such as:

Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.

An easy workaround is to delete this file but it will come back after each 
initscripts update.

Does anybody know a solution to prevent that?

-- 
catwell

Re: [arch-general] which package provides ifup & ifdown command ?

[Pierre Chapuis]

Le Wed, 26 Aug 2009 00:06:16 +0200,
Frédéric Perrin  a écrit :

> Le mardi 25 à 10:05, Jeff Horelick a écrit :
> > As Sven-Hendrik said, you need to use ifconfig $interface up and ifconfig
> > $interface down. If you really need ifup and ifdown, put this in your
> > .bashrc:
> >
> > alias 'ifup eth0'='ifconfig eth0 up'
> > alias 'ifdown eth0'='ifconfig eth0 down"
> 
> You *do* realise that ifup does slightly more than ifconfig up ?

ifup allows you to configure some stuff using /etc/network/interfaces. If 
that's what you're looking for, you probably want to take a look at netcfg 
instead of ifconfig.

-- 
catwell

Re: [arch-general] Arch minimum kernel version (udev) and SliceHost

[Pierre Chapuis]

Le Mon, 10 Aug 2009 12:26:17 -0500,
Dan McGee  a écrit :

> The kernel is not an Arch package at all, it is managed externally by Slice.
> 
> If you send them a support request requesting a new kernel, they are
> happy to oblige, remembering that they will need to reboot your slice
> for it to be rolled out.

OK, I'll do that then. Thanks for the information.

[arch-general] Arch minimum kernel version (udev) and SliceHost

[Pierre Chapuis]

Mon, 3 Aug 2009 10:29:02 -0500,
Dan McGee  wrote on [arch-dev-public] :

> Got a response from Slice:
> The following kernels are available for your slice to upgrade. Please
> let us know and we can take care of that for you.
> 2.6.24 - 23.48
> 2.6.24 - 24.55
> 
> I believe these should be Ubuntu kernel versions; I'm seeing right now
> what they actually include as it might include a fully working
> signalfd().
> 
> If anyone wants to contact some other providers (especially if you are
> already using their services) and post the response here, that would
> be cool.

Did someone with a Slice perform the update yet? It looks like I'm stuck with 
2.6.18-xen when I -Syu. Do all SliceHost users have to email them to upgrade 
the kernel, and do these kernel versions really work? I wouldn't like to break 
my Slice too much...

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] Pacman version 2.98 or pacman 3.0

[Pierre Chapuis]

Le Sun, 26 Jul 2009 06:35:04 -0400,
Baho Utot  a écrit :

> On Sat, 2009-07-25 at 18:23 -0700, Aaron Griffin wrote:

> > https://dev.archlinux.org/packages/core/i686/pacman/
> > 
> > Deps are libarchive, libdownload, bash, and the mirrorlist package...
> > what are you having a problem with?

> Secure Connection Failed
> 
> dev.archlinux.org uses an invalid security certificate.

> Then:
> Developer Login 
> Username:
> Password:

I think it's the same thing as 
http://www.archlinux.org/packages/core/i686/pacman/, and I don't see why you 
say there are 10 deps either.

-- 
catwell

Re: [arch-general] [arch-dev-public] Most up-to-date distro

[Pierre Chapuis]

Le Mon, 20 Jul 2009 19:48:51 -0400,
Daniel J Griffiths  a écrit :

> You may well have more success than I do. Finding the current upstream 
> version for packages on hosting sites is easy, doing it for joe schmoe's 
> website isn't so simple... If all you want to do is monitor what 
> packages you maintain that are actually /marked/ out of date, that's 
> simple.. I could throw together a shell script for that in a few seconds 
> (let me know if you think I should).

Actually my script already does that (using the AUR json interface). What's 
left to do is expand it with scriptlets for each kind of upstream website we 
can find.

I have put what I've done for now here 
http://catwell.info/darcs/index.py?r=scripts;a=tree;f=/luachecks

As I said it's really just a beginning, it took like 15 minutes between two LSM 
conferences to get it working and I didn't touch it since then. Moreover, it 
was just to see how I could do it, but I don't think using Lua is a good idea 
if other people have to help (maybe Bash ?).

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] [arch-dev-public] Most up-to-date distro

[Pierre Chapuis]

Le Mon, 20 Jul 2009 18:07:15 -0400,
Daniel J Griffiths  a écrit :
   
> I'm working on a script for arch that does this.

I'm working on something like that too, to help me monitor my AUR packages. I 
haven't done anything much yet though, and I have begun to write it in Lua 
which is probably a bad idea because most people don't know it.

Could you share your code somewhere so that we don't duplicate the work?

-- 
catwell

Re: [arch-general] [arch-dev-public] [signoff] vc/* -> tty* transition

[Pierre Chapuis]

Le Sat, 18 Jul 2009 23:29:28 -0500,
Aaron Griffin  a écrit :

> And to be clear, I definitely do not like the pandering to users thing... if
> people whining about stupid shit gets on your nerves, stop visiting the
> forums and IRC. It worked for me! ( google 'eternal september' for kicks :).
> Pyther, I like your sentiment.

Same here. I'm just a user but I like to think that Arch is a distribution that 
gives control to power users, and that teaches other users how things work.

That teaching might require breaking the system of those that don't follow 
simple rules such as read the output of Pacman.

Moreover, I have modified /etc/inittab, and depending on what the sed does, it 
might break my system. I don't think I'm the only user to have done that. So, 
even if you go the sed way, you will need to use post_upgrade() to warn the 
users that you changed something, and probably create a .pacsave... But in 
fact, if your goal is to make the systems of people who don't know what 
/etc/inittab is work, why use sed and not just replace the file with a new one 
using tty?

Anyway, I second pyther, phrakture and all those who are against automatic 
changes to critical configuration files. And I think every post or bug report 
complaining about that should be closed with a link to the news post about the 
move from vc to tty.

-- 
catwell

[arch-general] mplayer sources

[Pierre Chapuis]

Hi,

it looks like the sources used by Arch for MPlayer are not just a SVN snapshot 
of the main trunk.

Here's what I did:

$ wget ftp://ftp.archlinux.org/other/mplayer/ mplayer-29411.tar.bz2
$ tar xf mplayer-29411.tar.bz2
$ svn export mplayer mplayer-export-arch
$ svn co svn://svn.mplayerhq.hu/mplayer/trunk/ -r 29411 mplayer-svn-29411
$ svn export mplayer-svn-29411 mplayer-export-svn
$ diff -r mplayer-export-arch mplayer-export-svn > diff.txt

And here's what I got in diff.txt:

http://www.friendpaste.com/6JgZsbPEH80zirD88rTazL

Can somebody tell me where the changes come from?

-- 
catwell

Re: [arch-general] readline GPL violation on two pkgs?

[Pierre Chapuis]

Le Wed, 24 Jun 2009 01:22:03 -0300,
Gerardo Exequiel Pozzi  a écrit :

> Hi,
> 
> I just do a quick scan of soft linked with readline and  I think that
> these two pkgs that are linked with readline violates GPL:
> 
> extra/tftp-hpa
> community/ngspice
> 
> Both have the "old" BSD (4-clause) license and is linked with readline
> that is GPL, so there is an incompatibility [#1]

For tftp-hpa, the license used in the PKGBUILD looks wrong. tftp-hpa is 
"available under the same license as the "OpenBSD" operating system", and 
OpenBSD uses a 3-clause license.

I guess the packager just copied a part of http://www.openbsd.org/policy.html 
without looking further :

"Berkeley rescinded the 3rd term (the advertising term) on 22 July 1999. 
Verbatim copies of the Berkeley license in the OpenBSD tree have that term 
removed."

-- 
catwell

[arch-general] Anyone coming to LSM '09?

[Pierre Chapuis]

The 10th Libre Sofrware Meeting will take place in Nantes (France) from July 
7th to July 11th. It is the biggest Open Source event in the country (see 
http://2009.rmll.info/?lang=en).

Are there Archers planning to attend? Speaking French is probably required to 
take part in some of the conferences but not mandatory for all of them.

-- 
catwell

Re: [arch-general] 1080p playback

[Pierre Chapuis]

Le Mon, 01 Jun 2009 11:57:00 +0100,
Paulo Santos  a écrit :

> If vdpau really doesn't support it, is there a way for me to watch 1080p 
> movies on my machine? Maybe some kind of patch to mplayer that makes it 
> use both cores or something...

No need to patch mplayer for that. Try using:

mplayer -lavdopts fast:skiploopfilter=nonkey:threads=2

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] New vi/vim/gvim in testing requires intervention

[Pierre Chapuis]

Le Wed, 6 May 2009 14:53:43 -0500,
Aaron Griffin  a écrit :

> Might be worth seeing if we can find a patch to fix the crash at least.

Patching might be a good idea, but if you just patch the crash I think it will 
still be even more dangerous to put this version of vi in core because of the 
behavior described by André Ramaciotti.

If any user whose language is not English writes a comment at the top of a 
config file (say rc.conf or /etc/sudoers if he runs visudo) and saves it, this 
config file will be emptied and he won't know it. Guess what will happen when 
he tries to reboot.

There is a simple, easy to use and mostly bug-free editor in core, it's nano. 
Why the need for another one?

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] [arch-dev-public] Mplayer in two separate packages

[Pierre Chapuis]

(from arc-dev-public)

On Sat, 18 Apr 2009 13:42:17 -0300,
Hugo Doria  wrote :

> There is an old feature request for mplayer [1]: create it using two
> separate packages, one with only the CLI version and one for the GUI.
> 
> There are some reasons for this:
> 
> 1) By default the GUI is not enabled on mplayer
> 2) The package will not depend on gtk2
> 3) The user will be able to choose which GUI he wants to use. Now
> gmplayer is installed, even when the user wants to use another GUI, or
> do not use a GUI at all.
> 
> Obviously there are some points that need to be discussed:
> 
> 1) We do not usually split packages. Maybe this case is not a real
> division of packages because, by default, the GUI is not compiled.
> Don't know.
> 2) What do we do with the GUI version? Keep it on [extra] or move to
> community/AUR?
> 
> I would like to hear your opinions.
> 
> [1] http://bugs.archlinux.org/task/10220
> [2] http://aur.archlinux.org/packages.php?ID=18516

I am the current maintainer of the package you linked. That package can't be 
used as is to build a repository package, because I have tried to rely as much 
as possible on its autodetection features for everything so that the resulting 
build fits to the machine it's built on. Slumslayer's packages 
(http://aur.archlinux.org/packages.php?K=Slumslayer&SeB=m) would probably be a 
better base.

To me, compiling from source is the best way to install mplayer since not 
everybody wants it to depend on the same things. It is also one of the rare 
programs for which I find optimization useful: I want my video player to be as 
fast as possible when playing HD video on my low-power laptop ;). These are the 
reasons why I will always install mplayer from the AUR (or ABS).

Yet, a no-gui mplayer package in community would be good for those who don't 
want to bother with the AUR. I think you should also think about making a 
separate package for mencoder like Slumslayer did , because most people don't 
need it and it ads useless dependencies to the mplayer package (for example 
x264). I hope the new split packages can help with that.

-- 
catwell

Re: [arch-general] i686 build machines for rent

[Pierre Chapuis]

Le Wed, 1 Apr 2009 16:20:13 +0200 (CEST),
"Thomas Bohn"  a écrit :

> That is why Arch should drop x86_64 too. MMIX is the future!

You're absolutely right. I'd love to port Arch to MMIX, who's with me?

Of course we will have to port Pacman, the Linux kernel and make an actual 
hardware MMIX CPU beforehand, but I guess that won't be too difficult with the 
power of an Open Source community.

-- 
catwell

Re: [arch-general] File notification question

[Pierre Chapuis]

Le Thu, 19 Mar 2009 07:35:19 +1100,
richard terry  a écrit :

> Is it possible to set up a process( which notifies me via some sort of icon 
> on 
> taskbar try like email alert does) which monitors a particular directory on 
> my computer and if a new file is added to that directory, triggers the alert?
> 
> If so, if anyone can point me in the direction it would be appreciated.
> 
> Thanks in advance


Take a look at incron. I would use it and make it call a script that shows the 
popup.

-- 
catwell

Re: [arch-general] smtp daemon

[Pierre Chapuis]

Le Wed, 4 Mar 2009 22:44:09 +0100,
Johannes Held  a écrit :

> What about postfix?

Postfix would work but it's far from being small. Maybe msmtp can do that?

-- 
catwell

Re: [arch-general] x264, mplayer, ffmpeg rebuild?

[Pierre Chapuis]

Le Mon, 29 Dec 2008 00:09:23 +0100,
Markus Heuser  a écrit :

> Well, I'm not to familiar with the development procedures of mplayer but what 
> I mean by stable is "stable enough to be packaged" ;)

To me, the only way to use an up-to-date mplayer is to compile it yourself on 
your machine (by using one of the AUR packages).

Making a binary mplayer package is very difficult and the result can't be 
perfect for everybody because you have to make choices about what will be 
enabled in it (and add deps) and what will not (but some users might want it). 
It's the prototype of the package that should stay source-based if possible.

-- 
catwell

Re: [arch-general] Arch Linux automatic (prescripted) installer/deployment tool

[Pierre Chapuis]

Le Thu, 18 Dec 2008 21:17:48 +0100,
Dieter Plaetinck  a écrit :

> Does anyone have thoughts, ideas, requirements, ...?

Sounds good. I've worked with FAI (http://www.informatik.uni-koeln.de/fai/), 
which is powerful but a bit too complex. Its concepts are still good:

- Hooks at many times of the setup procedure to run scripts.

- Can be run from any media, such as CD-ROM or a mounted NFS drive after a PXE 
boot.

- Error-tolerant, but everything is logged on each client.

- Class-based: you define actions that belong to classes, then define the 
classes you want to run for each machine. It allows to make similar 
installations on machines that don't have the same hardware and need different 
drivers, for example.

- Can run scripts in many languages including Bash, Perl, cfagent...

Maybe you could take a look at it before starting, maybe even reuse some code 
(it's mostly made of Bash scripts).

-- 
catwell

Re: [arch-general] Build from source question.

[Pierre Chapuis]

Le Wed, 17 Dec 2008 12:49:48 +1000,
Allan McRae  a écrit :

> makepkg can not do this.

This is not completely true to me, you could do this in Bash directly in the 
Build() part of the PKGBUILD. It would not be so KISS though.

-- 
catwell

Re: [arch-general] [arch-dev-public] [signoff] pacman 3.2.1-2, pacman-mirrorlist

[Pierre Chapuis]

Le Sun, 14 Dec 2008 10:03:03 +0200,
"Grigorios Bouzakis"  a écrit :

> May i ask why pacman requires pacman-mirrorlist and not the other way
> around? Pacman can operate without a mirrorlist. Pacman-mirrorlist can
> not operate without pacman..

Agreed, but I think a lot of users would forget to install if it weren't a dep. 
of pacman. Maybe pacman should be renamed something like pacman-core and both 
of them added to a "pacman" group?

Also, I don't like the fact that the new mirrorlist is installed in place of 
the user's. I think most people edit their mirrorlist, and they don't want to 
redo it every time. A .pacnew file would probably be a better idea.

-- 
catwell

Re: [arch-general] remove HWD from extra and wiki!

[Pierre Chapuis]

Le Wed, 3 Dec 2008 01:10:34 +0100,
Pierre Schmitz <[EMAIL PROTECTED]> a écrit :

> Well, it does not produce working xorg.conf files. However: X -configure 
> should be prefered; so there is no need for hwd (anymore).

It doesn't provide working xorg.conf files only since xorg 1.5 was moved to 
extra. That was less than 5 days ago... I believe it will be updated to take 
the changes into account.

To me, hwd is a very useful tool, so please don't remove it from extra without 
a second thought.

-- 
catwell

Re: [arch-general] Arch USB Drive

[Pierre Chapuis]

Le Fri, 14 Nov 2008 16:34:49 -0600,
"Aaron Griffin" <[EMAIL PROTECTED]> a écrit :

> Got this in the mail today, so I thought I'd share a blurry picture
> with you all 8)
> 
> http://flickr.com/photos/phrakture/3029993921/

Lucky you. I guess it will take a little longer until mine reaches France :)

-- 
catwell

Re: [arch-general] [arch-dev-public] archweb port essentially complete, please test

[Pierre Chapuis]

Le Wed, 22 Oct 2008 20:06:00 -0400,
"Dusty Phillips" <[EMAIL PROTECTED]> a écrit :

> Hey all,
> 
> I've finished my first iteration of porting the archweb_pub and
> archweb_dev sites to django-1.0, along with a substantial rewrite of
> several portions of the code, as I mentioned in a previous status
> update. I'm confident the porting part has gone smoothly, but I have
> concerns that I overlooked testing all aspects (as there are no unit
> tests on this project as yet) of the code I rewrote.
> 
> As such I'm soliciting developer and community to test both sites. The
> more people that break it, the better I'll feel about putting it into
> production. ;-) I've copied the current archweb database into a
> playground for testing. The two sites can be accessed here:
> 
> Public Arch Linux site:
> http://pub.playground.archlinux.ca/
> 
> Developer Arch Linux site:
> http://dev.playground.archlinux.ca/
> 
> [...]
>
> Dusty

Since you asked help from the community I forked the thread to arch-general...

I've tested the public part of the website and found no breakage, good job!

I just wanted to point the fact that archlinuxfr.org, where I was an admin, 
won't be updated anymore (source : 
http://forums.archlinuxfr.org/viewtopic.php?id=1818) so it can be removed from 
this page : http://pub.playground.archlinux.ca/moreforums/.  It means there's 
only one french community website now (archlinux.fr). That should make it 
easier for new french Archers to find their way.

-- 
catwell

Re: [arch-general] problem updating klibc with kdemod3 on "Dont Panic"

[Pierre Chapuis]

Le Sat, 11 Oct 2008 22:29:08 +0200,
Nigel Henry <[EMAIL PROTECTED]> a écrit :

> klibc: /usr/lib/klibc/include/asm/Kbuild exists in filesystem

Read : http://archlinux.org/news/411/

-- 
catwell

Re: [arch-general] [arch-dev-public] Cleaning up the base group

[Pierre Chapuis]

Le Sun, 31 Aug 2008 10:25:00 +0200,
wakeup <[EMAIL PROTECTED]> a écrit :

> I am a vim user but I do agree that nano is the more convenient way for
> beginners.

Same here.

> Besides that, the version of vim installed with base is compiled with a
> low fetureset and represents a different package than extra/vim, in my
> opinion this is very confusing and unnecessary!

I use vim from base (vi), mostly because their buffers don't behave the same 
way. With vi I can copy and paste using middle click between my laptop and my 
server through ssh in urxvt out-of-the-box, with vim I have to change some 
configuration options.

And anyway, I don't need the extra bloat added by --with-features=big 
--with-x=yes.

-- 
catwell

Re: [arch-general] [arch-dev-public] adding http user/group to filesystems

[Pierre Chapuis]

Le Mon, 23 Jun 2008 19:14:58 +0200,
Arvid Ephraim Picciani <[EMAIL PROTECTED]> a écrit :

> On Monday 23 June 2008 19:10:30 Pierre Chapuis wrote:
> 
> > [1] http://httpd.apache.org/docs/2.2/misc/security_tips.html#serverroot
> 
> that link states exactly the oposit of what you where saing before. 
> no user owned files anywhere. all owned by root. 

In fact I really meant the page you get when you click on the word "User", 
which is http://httpd.apache.org/docs/2.2/mod/mpm_common.html#user.

It reads:

"It is recommended that you set up a new user and group specifically for 
running the server. Some admins use user nobody, but this is not always 
desirable, since the nobody user can have other uses on the system."

and also:

"Don't set User (or Group) to root unless you know exactly what you are doing, 
and what the dangers are."

Re: [arch-general] [arch-dev-public] adding http user/group to filesystems

[Pierre Chapuis]

Le Mon, 23 Jun 2008 18:48:12 +0200,
Arvid Ephraim Picciani <[EMAIL PROTECTED]> a écrit :

> so this is the official announcment that the vanilla-style-do-it-yourself for 
> professional engineers and manual readers is no more, and that in future 
> there will be rather debian-style-out-of-the-box solutions for  those who 
> want it to "just work" ?
> I'm fine with that new way. I'm going to look for a different distro then 
> instead of having to unpatch more and more packages. I just would like to 
> have a clear signal finally. The back and forth between those different 
> styles is really painfull for somone who has to actually maintain a few 
> dozens of machines. 

This is not a patch but a small change in default configuration to follow 
upstream advice [1]. I wouldn't go as far as saying that we're becoming Debian 
for that much.

[1] http://httpd.apache.org/docs/2.2/misc/security_tips.html#serverroot

Re: [arch-general] Problem starting vsftpd service. (Don't Panic)

[Pierre CHAPUIS]

If you start vsftpd as a daemon you have to :

 - Have listen=YES and background=YES in vsftpd.conf
 - Change line 11 from /etc/rc.d/vsftpd from /usr/sbin/vsftpd & to 
/usr/sbin/vsftpd

-- 
catwell

Re: [arch-general] Arch64 specific mailing list?

[Pierre CHAPUIS]

Le Wed, 23 Apr 2008 16:02:51 -0500,
"Aaron Griffin" <[EMAIL PROTECTED]> a écrit :

> Why would we do this? The point of having two architectures in one
> distribution is to MERGE things, not further separate them.

Moreover, these architectures are about the same and have been merged in the 
kernel recently.

I'm running i686 on a 64 bits able laptop, I'm thinking of switching soon. I'll 
get an Arch 64 slice at Slicehost too. The only real problem is with binary, 
non-free programs such as Flash, otherwise it should be all fine. Except the 
packages are not as up to date as i686 in the repos sometimes, but that's 
doomed to change as more and more people will have 64 bits hardware now.

-- 
catwell

Re: [arch-general] [arch-dev-public] initscripts changes

[Pierre CHAPUIS]

Would it not be possible to do something like moving all the virtual FS stuff 
to a specific file (say fstab.virtual or whatever you want) imported from fstab 
(thus easy to locate) ?

To me, it would make it easy to edit while keeping the content of fstab simple, 
and nothing would be hardcoded...

Otherwise I'm for keeping everything in fstab.

-- 
Pierre 'catwell' Chapuis

Re: [arch-general] [English] New Distro - Can't Read German

[Pierre CHAPUIS]

On Mon, 31 Mar 2008 23:03:07 -0500,
Jeffrey Parke <[EMAIL PROTECTED]> wrote :

> Brandon Martin wrote:
> > Is this for real?

> yes

I'm willing to start a French fork then. :)
What's german pronunciation for "Arch" by the way ?

-- 
catwell