[PATCH] gnu: Add Libogg.

[PATCH] gnu: Add Libogg.

[Nikita Karetnikov]

[-- Attachment #1.1: Type: text/plain, Size: 35 bytes --]

Hi,

Can I push this one?

Nikita


[-- Attachment #1.2: 0001-gnu-Add-Libogg.patch --]
[-- Type: text/x-diff, Size: 2874 bytes --]

From ae433f077cd8f0ec4a415b0526138d39f6078dce Mon Sep 17 00:00:00 2001
From: Nikita Karetnikov <nikita@karetnikov.org>
Date: Fri, 18 Jan 2013 01:51:08 +0000
Subject: [PATCH] gnu: Add Libogg.

* gnu/packages/libogg.scm: New file.
* Makefile.am (MODULES): Add it.
---
 Makefile.am             |    1 +
 gnu/packages/libogg.scm |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 47 insertions(+), 0 deletions(-)
 create mode 100644 gnu/packages/libogg.scm

diff --git a/Makefile.am b/Makefile.am
index 86f9651..3ac2379 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -85,6 +85,7 @@ MODULES =					\
   gnu/packages/libffi.scm			\
   gnu/packages/libidn.scm			\
   gnu/packages/libjpeg.scm			\
+  gnu/packages/libogg.scm			\
   gnu/packages/libsigsegv.scm			\
   gnu/packages/libtiff.scm			\
   gnu/packages/libunistring.scm			\
diff --git a/gnu/packages/libogg.scm b/gnu/packages/libogg.scm
new file mode 100644
index 0000000..9bbc982
--- /dev/null
+++ b/gnu/packages/libogg.scm
@@ -0,0 +1,46 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages libogg)
+  #:use-module ((guix licenses) #:select (bsd-3))
+  #:use-module (gnu packages compression)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public libogg
+  (package
+    (name "libogg")
+    (version "1.3.0")
+    (source
+     (origin
+      (method url-fetch)
+      (uri (string-append "http://downloads.xiph.org/releases/ogg/libogg-"
+                          version ".tar.xz"))
+      (sha256
+       (base32
+        "0jy79ffkl34vycnwfsj4svqsdg1lwy2l1rr49y8r4d44kh12a5r3"))))
+    (build-system gnu-build-system)
+    (inputs `(("xz" ,xz)))
+    (home-page "http://xiph.org/ogg/")
+    (synopsis
+     "Libogg, a library that allows to create, decode, and work with Ogg
+bitstreams")
+    (description
+     "Libogg allows to create, decode, and work with Ogg bitstreams.")
+    (license bsd-3)))
\ No newline at end of file
-- 
1.7.5.4


[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] gnu: Add Libogg.

[Andreas Enge]

[-- Attachment #1.1: Type: text/plain, Size: 909 bytes --]

Hello,

I prepared the same, but did not push it yet. Actually, I wanted to package 
the vorbis-tools, and got sucked into a dependency chain that started with 
curl and currently ends with ghostscript...

> +    (inputs `(("xz" ,xz)))

You do not need this; it is only used for unpacking, which is handled 
automatically.

Concerning the license, I have
   (license (bsd-style "file://COPYING"
                       "See COPYING in the distribution."))
instead of
+    (license bsd-3)))

My reason was that the license contained a line
"Neither the name of the Xiph.org Foundation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission."
So this is not precisely the original BSD-3 license, which does not mention 
Xiph.

What is our policy here?

So I would suggest the following more comprehensive patch.

Andreas

[-- Attachment #1.2: Type: text/html, Size: 5069 bytes --]

[-- Attachment #2: 0001-gnu-Add-libogg-libvorbis-and-vorbis-tools.patch --]
[-- Type: text/x-patch, Size: 5775 bytes --]

From 657506537c1167d97b43ce8a69a2bf74b06e33f4 Mon Sep 17 00:00:00 2001
From: Andreas Enge <andreas@enge.fr>
Date: Fri, 18 Jan 2013 11:02:26 +0100
Subject: [PATCH] gnu: Add libogg, libvorbis and vorbis-tools.

* gnu/packages/oggvorbis.scm: New file.
* Makefile.am (MODULES): Add it.
---
 Makefile.am                |    1 +
 gnu/packages/oggvorbis.scm |  108 ++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 109 insertions(+)
 create mode 100644 gnu/packages/oggvorbis.scm

diff --git a/Makefile.am b/Makefile.am
index 86f9651..5c58131 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -102,6 +102,7 @@ MODULES =					\
   gnu/packages/ncurses.scm			\
   gnu/packages/nettle.scm			\
   gnu/packages/openssl.scm			\
+  gnu/packages/oggvorbis.scm			\
   gnu/packages/perl.scm				\
   gnu/packages/pkg-config.scm			\
   gnu/packages/pth.scm				\
diff --git a/gnu/packages/oggvorbis.scm b/gnu/packages/oggvorbis.scm
new file mode 100644
index 0000000..d92dfc3
--- /dev/null
+++ b/gnu/packages/oggvorbis.scm
@@ -0,0 +1,108 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2013 Andreas Enge <andreas@enge.fr>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages oggvorbis)
+  #:use-module (gnu packages)
+  #:use-module (guix licenses)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public libogg
+  (package
+   (name "libogg")
+   (version "1.3.0")
+   (source (origin
+            (method url-fetch)
+            (uri (string-append "http://downloads.xiph.org/releases/ogg/libogg-"
+                                version ".tar.xz"))
+            (sha256
+             (base32
+              "0jy79ffkl34vycnwfsj4svqsdg1lwy2l1rr49y8r4d44kh12a5r3"))))
+   (build-system gnu-build-system)
+   (synopsis "libogg, a library for manipulating the ogg multimedia format")
+   (description
+    "The libogg library allows to manipulate the ogg multimedia container
+format, which encapsulates raw compressed data and allows the interleaving of
+audio and video data. In addition to encapsulation and interleaving of
+multiple data streams, ogg provides packet framing, error detection, and
+periodic timestamps for seeking.")
+   (license (bsd-style "file://COPYING"
+                       "See COPYING in the distribution."))
+   (home-page "http://xiph.org/ogg/")))
+
+(define-public libvorbis
+  (package
+   (name "libvorbis")
+   (version "1.3.3")
+   (source (origin
+            (method url-fetch)
+            (uri (string-append "http://downloads.xiph.org/releases/vorbis/libvorbis-"
+                                version ".tar.xz"))
+            (sha256
+             (base32
+              "1gby6hapz9njx4l9g0pndyk4q83z5fgrgc30mfwfgx7bllspsk43"))))
+   (build-system gnu-build-system)
+   (inputs `(("libogg" ,libogg)))
+   (arguments `(#:configure-flags '("LDFLAGS=-lm")))
+   (synopsis "libvorbis, a library implementing the vorbis audio format")
+   (description
+    "The libvorbis library implements the ogg vorbis audio format,
+a fully open, non-proprietary, patent-and-royalty-free, general-purpose
+compressed audio format for mid to high quality (8kHz-48.0kHz, 16+ bit,
+polyphonic) audio and music at fixed and variable bitrates from 16 to
+128 kbps/channel.")
+   (license (bsd-style "file://COPYING"
+                       "See COPYING in the distribution."))
+   (home-page "http://xiph.org/vorbis/")))
+
+(define-public vorbis-tools
+  (package
+   (name "vorbis-tools")
+   (version "1.4.0")
+   (source (origin
+            (method url-fetch)
+            (uri (string-append "http://downloads.xiph.org/releases/vorbis/vorbis-tools-"
+                                version ".tar.gz"))
+            (sha256
+             (base32
+              "1g12bnh5ah08v529y72kfdz5lhvy75iaz7f9jskyby23m9dkk2d3"))))
+   (build-system gnu-build-system)
+   (inputs `(("libogg" ,libogg)
+             ("libvorbis" ,libvorbis)))
+;; FIXME: Add more inputs, see the documentation:
+;; All of the tools require libogg and libvorbis to be installed (along
+;; with the header files).  Additionally, ogg123 requires libao, libcurl,
+;; and a POSIX-compatible thread library.  Ogg123 can optionally compiled
+;; to use libFLAC, and libspeex.  Oggenc can be optionally compiled with
+;; libFLAC, and libkate.  The libraries libogg, libvorbis, and libao are
+;; all available at
+;;   http://www.vorbis.com/download.psp
+   (synopsis "ogg vorbis tools")
+   (description
+    "Ogg vorbis is a non-proprietary, patent-and-royalty-free,
+general-purpose compressed audio format.
+
+The package vorbis-tools contains
+ogg123,  an ogg vorbis command line audio player;
+oggenc,  the ogg vorbis encoder;
+oggdec,  a simple, portable command line decoder (to wav and raw);
+ogginfo, to obtain information (tags, bitrate, length, etc.) about
+         an ogg vorbis file.")
+   (license gpl2)
+   (home-page "http://xiph.org/vorbis/")))
-- 
1.7.10.4

Re: [PATCH] gnu: Add Libogg.

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

So maybe to avoid working on the same things, I currently have gnunet, 
libextractor, flac (with a patch), curl, groff, netpbm, openldap and 
ghostscript in my pipeline. These are all dependencies in one way or 
another of gnunet. But I think it could take quite a while until I arrive 
at the top of the (only partially discovered) dependency tree...

Andreas

[-- Attachment #2: Type: text/html, Size: 1278 bytes --]

To-do lists

[Ludovic Courtès]

Hi!

Andreas Enge <andreas@enge.fr> skribis:

> So maybe to avoid working on the same things, I currently have gnunet, 
> libextractor, flac (with a patch), curl, groff, netpbm, openldap and 
> ghostscript in my pipeline. These are all dependencies in one way or 
> another of gnunet. But I think it could take quite a while until I arrive 
> at the top of the (only partially discovered) dependency tree...

Good, thanks for sharing your to-do list.

Another thing we can do to avoid duplicated work, is to commit and push
individual packages as soon as we have them.  For instance, as soon as
you have a working libextractor, go ahead and push it.

Some packages require more effort, and in that case it’s a good idea to
announce your plans as you start working on it.

Or maybe we should use an Org file somewhere, or a wiki, or some sort of
locally-hosted Web 2.0 task management thing.

Ideas?

Ludo’.

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Am Freitag, 18. Januar 2013 schrieb Ludovic Courtès:
> Another thing we can do to avoid duplicated work, is to commit and push
> individual packages as soon as we have them.  For instance, as soon as
> you have a working libextractor, go ahead and push it.

That is what I do. But I am not fond of pushing packages for which I would 
still like to add more inputs; it is possible to push libextractor without 
lots of optional dependencies. This is what my proposed patch for vorbis-
tools does, there is a FIXME explaining which inputs are missing. But then 
there is a higher risk of forgetting to add them.

Otherwise said, currently I am doing a depth-first exploration of the 
dependency graph, but one could do something closer to breadth-first.

> Or maybe we should use an Org file somewhere, or a wiki, or some sort of
> locally-hosted Web 2.0 task management thing.

Anything would be fine for me as long as it is easy. Maybe a wiki would be 
easiest for the time being.

Andreas

[-- Attachment #2: Type: text/html, Size: 3688 bytes --]

Re: [PATCH] gnu: Add Libogg.

[Ludovic Courtès]

Hello!

Looking into more details, given that Andreas’s patch adds more stuff,
I think it would be wise to commit this one.  WDYT?

And presumably, Andreas should get the lock on all things Xiph-related.
:-)

Ludo’.

Re: [PATCH] gnu: Add Libogg.

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 243 bytes --]

> So this is not precisely the original BSD-3 license, which does not mention Xiph.

> What is our policy here?

You're right.  'bsd-style' should be used.

> So I would suggest the following more comprehensive patch.

Please push it.

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: To-do lists

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 954 bytes --]

>> Another thing we can do to avoid duplicated work, is to commit and push
>> individual packages as soon as we have them. For instance, as soon as
>> you have a working libextractor, go ahead and push it.

Sounds good.

> That is what I do. But I am not fond of pushing packages for which I
> would still like to add more inputs; it is possible to push
> libextractor without lots of optional dependencies. This is what my
> proposed patch for vorbis-tools does, there is a FIXME explaining
> which inputs are missing. But then there is a higher risk of
> forgetting to add them.

I suggest to announce such things on the list.

>> Or maybe we should use an Org file somewhere, or a wiki, or some sort of
>> locally-hosted Web 2.0 task management thing.

Can Savannah be used?

> Anything would be fine for me as long as it is easy. Maybe a wiki
> would be easiest for the time being.

I guess that the easiest thing is to stick with this list.

Nikita

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: To-do lists

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> That is what I do. But I am not fond of pushing packages for which I
>> would still like to add more inputs; it is possible to push
>> libextractor without lots of optional dependencies. This is what my
>> proposed patch for vorbis-tools does, there is a FIXME explaining
>> which inputs are missing. But then there is a higher risk of
>> forgetting to add them.
>
> I suggest to announce such things on the list.

Yes, but that’s inconvenient.  Typically, I’m likely to have forgotten
what others are doing by the time I actually start packaging something.
;-)

>>> Or maybe we should use an Org file somewhere, or a wiki, or some sort of
>>> locally-hosted Web 2.0 task management thing.
>
> Can Savannah be used?

Could be, though it’s really inconvenient (heavyweight, browser-only).

>> Anything would be fine for me as long as it is easy. Maybe a wiki
>> would be easiest for the time being.
>
> I guess that the easiest thing is to stick with this list.

You mean this /mailing/ list?

Ludo’.

Re: To-do lists

[Nikita Karetnikov]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

> Could be, though it’s really inconvenient (heavyweight, browser-only).

There are some bug trackers that support email [1].  Have you ever tried
them?

> You mean this /mailing/ list?

Yes, I was talking about the mailing list.

Nikita

[1] http://webapps.stackexchange.com/questions/6115/which-bug-trackers-support-email

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: To-do lists

[Ludovic Courtès]

Nikita Karetnikov <nikita@karetnikov.org> skribis:

>> Could be, though it’s really inconvenient (heavyweight, browser-only).
>
> There are some bug trackers that support email [1].  Have you ever tried
> them?

Yes, http://bugs.gnu.org is a Debbugs instance, used by Guile, among others.

It’s convenient for bug reports, but cannot be used as a task list, AFAICS.

There are things like Trac or RedMine that we could run on
hydra.gnu.org, but that’s more heavyweight and webish than I would like.

Another option would be to have a simple Org-mode file in a repo hosted
on hydra.gnu.org (say), but that means that everyone would need to have
an SSH account on that machine (unless we can use a single SSH account
for everyone who needs to access the repo?).

Suggestions welcome!

Ludo’.

Re: To-do lists

[Jason Self]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

Ludovic Courtès <ludo@gnu.org> wrote ..
> Another option would be to have a simple Org-mode file in a repo hosted
> on hydra.gnu.org (say), but that means that everyone would need to have
> an SSH account on that machine (unless we can use a single SSH account
> for everyone who needs to access the repo?).
>
> Suggestions welcome!
>
> Ludo’.

Another option might be GNU Recutils.

Regardless of the use of Org-mode or Recutils, is there any reason
such a file couldn't exist in version control on Savannah? It could be
part of either the source code repository or web pages repository.
Access would be easily controlled using the existing mechanisms on
Savannah, with anonymous access for anyone to view it as well.

If this doesn't work, Savannah also has a Task Tracker. Then people
would just create tasks and assign it to themselves/someone as an
indicator that they're working on it.

Re: To-do lists

[Ludovic Courtès]

Hi Jason,

"Jason Self" <jason@bluehome.net> skribis:

> Another option might be GNU Recutils.

Right.

> Regardless of the use of Org-mode or Recutils, is there any reason
> such a file couldn't exist in version control on Savannah? It could be
> part of either the source code repository or web pages repository.
> Access would be easily controlled using the existing mechanisms on
> Savannah, with anonymous access for anyone to view it as well.

Yes.  This only thing is that I wouldn’t want to clutter the source
repository history with these things, so we definitely need a separate
repo.

It could be the web repo, but that’s the CVS, so we may well lose our
temper.  ;-)

Perhaps we should ask savannah-hackers for a secondary Git repo?

> If this doesn't work, Savannah also has a Task Tracker. Then people
> would just create tasks and assign it to themselves/someone as an
> indicator that they're working on it.

I’d prefer something easily accessible from a text editor.

Thanks,
Ludo’.

Re: To-do lists

[Jason Self]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

Ludovic Courtès <ludo@gnu.org> wrote ..

> Perhaps we should ask savannah-hackers for a secondary Git repo?

I don't suppose there's any harm in that, except that it means using
Git but I'll go be quiet now.

Re: To-do lists

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> "Jason Self" <jason@bluehome.net> skribis:
>
>> Another option might be GNU Recutils.
>
> Right.
>
>> Regardless of the use of Org-mode or Recutils, is there any reason
>> such a file couldn't exist in version control on Savannah? It could be
>> part of either the source code repository or web pages repository.
>> Access would be easily controlled using the existing mechanisms on
>> Savannah, with anonymous access for anyone to view it as well.
>
> Yes.  This only thing is that I wouldn’t want to clutter the source
> repository history with these things, so we definitely need a separate
> repo.
>
> It could be the web repo, but that’s the CVS, so we may well lose our
> temper.  ;-)
>
> Perhaps we should ask savannah-hackers for a secondary Git repo?

Done at <https://savannah.gnu.org/support/?108240>.

Ludo’.

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Am Montag, 28. Januar 2013 schrieb Ludovic Courtès:
> > "Jason Self" <jason@bluehome.net> skribis:
> > Perhaps we should ask savannah-hackers for a secondary Git repo?
> Done at <https://savannah.gnu.org/support/?108240>.

I am not sure whether a git repo is the right thing, since we do not need 
version control and history; collaborative text editing is more what comes 
to my mind, or a lightweight wiki.

So I set up a gobby server. I do not know whether there are console based 
clients, but you can use the gtk program "gobby". Upon connecting, it 
allows to edit files, with contributions by different persons highlighted 
in different colours. And there is a little chat client integrated.

As there is a password I do not wish to post worldwide, I will send it to 
the developers given in the AUTHORS file. Please try it out and tell me 
what you think.

Andreas

[-- Attachment #2: Type: text/html, Size: 3162 bytes --]

Re: To-do lists

[Cyril Roelandt]

On 01/28/2013 10:47 PM, Andreas Enge wrote:
> Am Montag, 28. Januar 2013 schrieb Ludovic Courtès:
>>> "Jason Self"<jason@bluehome.net>  skribis:
>>> Perhaps we should ask savannah-hackers for a secondary Git repo?
>> Done at<https://savannah.gnu.org/support/?108240>.
>
> I am not sure whether a git repo is the right thing, since we do not need
> version control and history; collaborative text editing is more what comes
> to my mind, or a lightweight wiki.
>
> So I set up a gobby server. I do not know whether there are console based
> clients, but you can use the gtk program "gobby". Upon connecting, it
> allows to edit files, with contributions by different persons highlighted
> in different colours. And there is a little chat client integrated.
>
> As there is a password I do not wish to post worldwide, I will send it to
> the developers given in the AUTHORS file. Please try it out and tell me
> what you think.
>

Is it possible to have a read-only access to the files ? It would be 
nice for potential contributors to be able to read our TODO list.

Cyril.

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

Am Dienstag, 29. Januar 2013 schrieb Cyril Roelandt:
> Is it possible to have a read-only access to the files ? It would be
> nice for potential contributors to be able to read our TODO list.

I do not think so.

Andreas


[-- Attachment #2: Type: text/html, Size: 1882 bytes --]

Re: To-do lists

[Florian Friesdorf]

[-- Attachment #1: Type: text/plain, Size: 764 bytes --]

Andreas Enge <andreas@enge.fr> writes:
> Am Montag, 28. Januar 2013 schrieb Ludovic Courtès:
>> > "Jason Self" <jason@bluehome.net> skribis:
>> > Perhaps we should ask savannah-hackers for a secondary Git repo?
>> Done at <https://savannah.gnu.org/support/?108240>.
>
> I am not sure whether a git repo is the right thing, since we do not need 
> version control and history; collaborative text editing is more what comes 
> to my mind, or a lightweight wiki.

I think having version control and history is quite beneficial for
keeping track who closed what when.

-- 
Florian Friesdorf <flo@chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

Am Dienstag, 29. Januar 2013 schrieb Florian Friesdorf:
> I think having version control and history is quite beneficial for
> keeping track who closed what when.

There is already the git for the project itself, and at some point in time, 
we might need a bug tracker. Here it is more about intra project 
communication; like writing down non-committally who works on what, without 
having to be reminded months later which promises one did not keep...

Andreas

[-- Attachment #2: Type: text/html, Size: 1965 bytes --]

Re: To-do lists

[Ludovic Courtès]

Cyril Roelandt <tipecaml@gmail.com> skribis:

> Is it possible to have a read-only access to the files ? It would be
> nice for potential contributors to be able to read our TODO list.

I agree that would be nice.

If the tool doesn’t support it, perhaps we could have a cron job that
periodically exports the file somewhere?

Ludo’.

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

Am Dienstag, 29. Januar 2013 schrieb Ludovic Courtès:
> Cyril Roelandt <tipecaml@gmail.com> skribis:
> > Is it possible to have a read-only access to the files ? It would be
> > nice for potential contributors to be able to read our TODO list.
>
> I agree that would be nice.
> 
> If the tool doesn’t support it, perhaps we could have a cron job that
> periodically exports the file somewhere?

That would be easily possible; the files are stored in xml format, and can 
also be exported (at least manually) to html.

Andreas


[-- Attachment #2: Type: text/html, Size: 3083 bytes --]

Re: To-do lists

[Florian Friesdorf]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

Andreas Enge <andreas@enge.fr> writes:
> Am Dienstag, 29. Januar 2013 schrieb Florian Friesdorf:
>> I think having version control and history is quite beneficial for
>> keeping track who closed what when.
>
> There is already the git for the project itself, and at some point in time, 
> we might need a bug tracker. Here it is more about intra project 
> communication; like writing down non-committally who works on what, without 
> having to be reminded months later which promises one did not keep...

k - I thought for a moment you were about to implement bug tracking with
org-mode/git and was about to cheer.

-- 
Florian Friesdorf <flo@chaoflow.net>
  GPG FPR: 7A13 5EEE 1421 9FC2 108D  BAAF 38F8 99A3 0C45 F083
Jabber/XMPP: flo@chaoflow.net
IRC: chaoflow on freenode,ircnet,blafasel,OFTC

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: To-do lists

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> So I set up a gobby server. I do not know whether there are console based 
> clients, but you can use the gtk program "gobby". Upon connecting, it 
> allows to edit files, with contributions by different persons highlighted 
> in different colours. And there is a little chat client integrated.

I finally installed Gobby, and it works beautifully!

Perhaps if we type in using Org-mode “syntax” we can then use Org’s HTML
export facility in the cron job.  WDYT?

(Now to try Rudel...)

Ludo’.

Re: To-do lists

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 332 bytes --]

Am Dienstag, 29. Januar 2013 schrieb Ludovic Courtès:
> I finally installed Gobby, and it works beautifully!
> 
> Perhaps if we type in using Org-mode “syntax” we can then use Org’s HTML
> export facility in the cron job.  WDYT?

I do not know how to write it; is it difficult? How about recutils instead? 

Andreas

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

Re: To-do lists

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Am Dienstag, 29. Januar 2013 schrieb Ludovic Courtès:
>> I finally installed Gobby, and it works beautifully!
>> 
>> Perhaps if we type in using Org-mode “syntax” we can then use Org’s HTML
>> export facility in the cron job.  WDYT?
>
> I do not know how to write it; is it difficult?

No, see ‘TODO’ and ‘README’ for examples–I bet you wouldn’t have guessed
that this is special syntax.  ;-)

> How about recutils instead?

Yeah, it would work too, though it’s slightly more heavyweight (and its
fancy Emacs modes is in the not-yet-released version...)  OTOH, it would
allow us to add special fields, like ‘assigned-to’, etc.

So, whichever you prefer is fine with me.  :-)

Ludo’.