IRC commit messages for ::u-u (GitHub) repositories

Hi,

Since CIA.vc went down, we lost IRC commit messages for ::u-u repositoriese.
Official repositories now use irker, running on dev.e.o but it is not 
feasible to make it listen to the world.

I developed for my other projects a system in three pieces to support 
the GitHub WebHook. The specific daemon is github-eventc 
(http://git.eventd.org/github-eventc/), which listens for the WebHook 
messages. Dependencies are libsoup, json-glib and libeventc. Then you 
have eventd and its im plugin (libpurple-based), to format and send the 
message to the channel.

It can also support local git hooks, simply calling eventc (the CLI client).

Of course, we can always have a daemon to feed irker directly, but I’ll 
maintain github-eventc for my own projects anyway, so why not using it 
for Exherbo too.

github-eventc can use HTTPS, and is filtering requests with a simple 
text token.

To support such a setup for Exherbo, we just need to install 
eventd[purple], libsoup, json-glib and github-eventc (I may package it, 
not sure it is worth it though) on dev.e.o, and run them all.
Then we just share the token with ::u-u repositories’ maintainers, via 
IRC or email.

What do you guys think?

Removing X drivers for obsolete hardware

A lot of drivers in the tree are incompatible with the latest stable
xorg-server (0.14.1). I'm not really motivated to bump and test those
drivers before the unmask because I think most of them are simply
obsolete or unneeded.

Here is the list of the broken ones:
xf86-input-wacom
xf86-video-apm
xf86-video-ark
xf86-video-ast
xf86-video-chips
xf86-video-dummy
xf86-video-fbdev
xf86-video-glint
xf86-video-i128
xf86-video-i740
xf86-video-mach64
xf86-video-mga
xf86-video-openchrome
xf86-video-neomagic
xf86-video-newport
xf86-video-r128
xf86-video-rendition
xf86-video-s3
xf86-video-s3virge
xf86-video-savage
xf86-video-siliconmotion
xf86-video-sis
xf86-video-sisusb
xf86-video-sunffb

LICENCES in virtuals

Hello,

why do we put LICENCES in virtuals at all? I'd say we shouldn't.

After all, LICENCES is about the *package's* licence(s) and a
virtual's deps can have different licences. We could add them all but
what good would that do?

Most LICENCES entries currently have "as-is" which is almost always wrong.

Unless one of you complains, I'm going to remove LICENCES from all
virtuals next weekend.

--

-- 
Best regards, Wulf

Fwd: [Exherbo Linux] Your organization application has been rejected.

Rejected again...

-------- Original Message --------
Subject: 	[Exherbo Linux] Your organization application has been rejected.
Date: 	Mon, 08 Apr 2013 18:42:30 +0000
From: 	no-reply@...
To: 	philantrop@...

Thank you for submitting "Exherbo Linux" organization application to
Google Summer of Code 2013. Unfortunately, we were unable to accept your
organization's application at this time. Every year we receive many more
applications than we are able to accommodate, and we would encourage you
to reapply for future instances of the program.

If you would like some general feedback on why your organization was not
accepted, please consider attending the IRC meeting in #gsoc on Freenode
on Friday, April 19, 2013 at 16:00 UTC.

Best regards,

Google Open Source Programs

[RFC v2] A new approach to CONFIG_PROTECT

I recently decided to revisit this, and have made some changes.

The current layout of a directory under CONFIG_PROTECT is somewhat
less than ideal. An update to a protected directory results in
._cfg0000_.* files strewn throughout, with no information as to their
origin. Also, this layout does not interact well with configuration
management tools such as etckeeper. Here I will propose an alternate
method for achieving the goals of CONFIG_PROTECT.

First, a different layout could bring many benefits both in terms of
functionality and performance. In all examples, we will be treating
/etc as the directory under CONFIG_PROTECT.

For a new layout, we should avoid splattering dotfiles all over the
directory tree. It would also be beneficial to record the package that
tried to merge the file, as well as a timestamp.  Conveniently,
exndbam already stores a timestamp.

This is how I imagine the new layout might look:

/etc/
    .config-protect/
        new/
        old/
        resolved/
        historic/
        protected/

When a package adds a path to either CONFIG_PROTECT or CONFIG_PROTECT_MASK,
it creates a directory in ${IMAGE}/etc/.config-protect/protected/.

Paludis 1.2.0 Released

Paludis 1.2.0 has been released:

    * Bug fixes.

    * Dep specs can now use '[.key!=value]'. The behaviour of '<' and
      '>' has changed: for key types where order comparisons don't make
      sense, the match now always fails.

    * Various compiler-compatibility fixes.

--

-- 
Ciaran McCreesh

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev

Fwd: Re: git-annex for distfiles

From: <nwmcsween@...>
Subject: Re: [Exherbo-dev] git-annex for distfiles
Date: 2013-03-05 04:43:01 GMT

> I suggested this last september, but unfortunately, the interest didn't seem to be too large.
> I still think that this can actually save us lot of trouble, so I'm all for it.
> 
A better plan IMO would be to only support vs's. This way you could bisect build issues, have instant updates
instead of carrying around patches, have builtin dedup (history size may outweigh this though).
Probably not something one would want to extend paludis though..

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev

git-annex for distfiles

git-annex is a way to manage files with git without checking their
contents into git¹. There have been some chit-chat about using git-annex
for distfiles management on IRC but we never really discussed it
thoroughly.

git-annex may provide several advantages to our distfiles management.
One of the main advantages is integrity checking of files managed by
git-annex². The users can use several remotes which make it a practical
way to handle mirrors for them³.

The deployment may not look simple at first sight but I do not think
this is the case. git-annex is written in Haskell but it is fairly easy
to build it as a static linked binary which may be distributed in
::arbor and stages. I have been using this approach with our radio
station for a while now and haven't had any problems⁴. We can also use
git-annex' special "web" remote to distribute files through http protocol⁵.
The special remotes and especially the "hook" remote can even make it
possible to distribute files via p2p or other protocols⁶.

CC'ing infra monkeys for comments.
Please discuss!

¹: http://git-annex.branchable.com/git-annex/
   http://lwn.net/Articles/419241/
²: http://git-annex.branchable.com/backends/
³: http://git-annex.branchable.com/transferring_data/
⁴: http://dev.exherbo.org/~alip/scripts/cabal-annex
⁵: http://git-annex.branchable.com/special_remotes/
   http://git-annex.branchable.com/special_remotes/web/
   http://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/

Request for testing and pinktrace-check

sydbox-1 which includes a rewritten version of pinktrace - which is
going to be released as pinktrace-1 eventually - now installs
pinktrace's tests and a binary pinktrace-check to easily run pinktrace's
test suite after installation.

pinktrace is very machine dependent and I do not have access to any ARM,
ppc, ppc64 or ia64 boxes at the moment. You can help by testing
pinktrace on these architectures or give me access to such a box so I
can further improve pinktrace on the aforementioned architectures.

I'm particularly interested in ia64 because I couldn't port it to the
new getregs/setregs interface due to the lack of an ia64 to box to
compile pinktrace.

		-alip

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev@...
http://lists.exherbo.org/mailman/listinfo/exherbo-dev

Re: ROOTPATH, pam_env and profile.env

On 07/02/2013 09:21, Nakamura wrote:
> On Thu, Feb 7, 2013 at 5:50 AM, Quentin Glidic <sardemff7 <at> exherbo.org> wrote:
>> Is there any reason to keep profile.env around then? (Same question for
>> profile.csh.)
> 
> Is chroot using pam?
> If not, we need profile.env for chrooted environment (such as system
> installation or development).

Good catch, but nothing problematic here as chroot does not change the
environment at all.
Also, in our current stages, /root/.bashrc is empty, no references to
profile.env either.

--

-- 

Quentin “Sardem FF7” Glidic

_______________________________________________
Exherbo-dev mailing list
Exherbo-dev <at> lists.exherbo.org
http://lists.exherbo.org/mailman/listinfo/exherbo-dev

ROOTPATH, pam_env and profile.env

Let’s start with the easy part.

I’m going to drop ROOTPATH and use
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin for everyone.
Every Exherbo user is highly likely to be a super user, so there is no
real point to keep her from using sbin stuff.
To achieve that, I will add the full PATH to /etc/env.d/00basic, and
simply drop the redefinitions in /etc/profile and other shells
equivalent files (e.g. zprofile).

Now that we have a clean environment, let’s use it correctly.
Using profile.env assumes everything will launch a shell to set the
environment up. This is wrong. DMs parse or source sometimes
/etc/profile to get the basic env, but more rarely the user files. It
depends on the distribution sessions scripts too. It’s messy to work
with. Tools like weston-launch (to launch Weston from a TTY) simply
clean the environment, then launch the compositor: no way to get
profile.env in.

The solution is to use PAM, which is common to all these, even the TTY
login. pam_env module have been around for ages, but not used in the
default configuration.
I will push some basic change to the eclectic env module to keep the
simple KEY=VALUE file around, without the export used in profile.env.

So, here is the status after these two changes:
— No more ROOTPATH, and a full usable PATH with all the tools you need
— The environment is set correctly when using PAM (TTY login, DMs,
weston-launch) with all package-specifics vars