On 02/25/2016 01:39 PM, zimbatm wrote:
> The output file wasn't exactly right, I had to replace ` id="something">` to `` tags and wrap it in a tag.
That's because pandoc uses an older version of docbook where some tags
are different. (IIRC I looked a few months ago and it didn't support the
On Thu, Feb 25, 2016 at 2:00 PM, Eelco Dolstra
wrote:
> Hi,
>
> On 24/02/16 01:14, Anderson Torres wrote:
>
> > 2016-02-23 19:22 GMT-03:00 zimbatm :
> >> I started writing some docbook. Maybe I will get used to it but writing
> >> `foobar` is way
Hi,
On 24/02/16 01:14, Anderson Torres wrote:
> 2016-02-23 19:22 GMT-03:00 zimbatm :
>> I started writing some docbook. Maybe I will get used to it but writing
>> `foobar` is way more painful
>> that `* foobar` in markdown. Especially in writing I think it's important to
>>
Basically wrote the doc in markdown and then:
```
$ nix-env -iA nixos.pandoc
$ pandoc -f markdown -t docbook release.md > release.xml
```
The output file wasn't exactly right, I had to replace `` to `` tags and wrap it in a tag. That
was quickly done and less work that writing in docbook
> On Tue, 23 Feb 2016 at 21:29 Vladimír Čunát wrote:
> > My personal opinion is that this is mostly an excuse. It's a XML subset
> > and everyone should know at least a bit of (X)HTML or similar stuff.
> > Note that for almost all docs we use ~10 types of tags and the format is
Nobody has written the Nix/NixOS book yet.
On 24/02/2016 11:14 AM, "Anderson Torres"
wrote:
> 2016-02-23 19:22 GMT-03:00 zimbatm :
> > I started writing some docbook. Maybe I will get used to it but writing
> > `foobar` is way more
> painful
> >
2016-02-23 19:22 GMT-03:00 zimbatm :
> I started writing some docbook. Maybe I will get used to it but writing
> `foobar` is way more painful
> that `* foobar` in markdown. Especially in writing I think it's important to
> be able to move text around without too much overhead
I started writing some docbook. Maybe I will get used to it but writing
`foobar` is way more
painful that `* foobar` in markdown. Especially in writing I think it's
important to be able to move text around without too much overhead so that
text can be reworked until it feels right.
Thanks god
On 02/23/2016 12:18 PM, Rok Garbas wrote:
> docbook is just something that is not known by majority of our community
My personal opinion is that this is mostly an excuse. It's a XML subset
and everyone should know at least a bit of (X)HTML or similar stuff.
Note that for almost all docs we use
On 16-02-20 03:11pm, Anthony Cowley wrote:
> The point being that once a wiki item gets a handful of positive votes, it
> gets turned into an Issue on the manual for someone with a better
> understanding of how things are put together to find it a home. At that
> point, the wiki item could have a
Hi Eelco,
>> I've given this a try [1] for the zero-build-failures entry and my
>> experience so
>> far was:
>>
>> 1/ How do I actually build docbook?
>> => copy doc/default.nix and adjust
>> 2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think).
>> => Wait 2h.
>> 3/ GHC build
Hi,
On 22/02/16 00:58, Thomas Hunger wrote:
> I've given this a try [1] for the zero-build-failures entry and my experience
> so
> far was:
>
> 1/ How do I actually build docbook?
> => copy doc/default.nix and adjust
> 2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think).
> =>
On 02/22/2016 12:58 AM, Thomas Hunger wrote:
> 2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think).
Basing your work on a channel should remove such problems, as for any
regular package.
--Vladimir
smime.p7s
Description: S/MIME Cryptographic Signature
Thanks Rok!
I've given this a try [1] for the zero-build-failures entry and my
experience so far was:
1/ How do I actually build docbook?
=> copy doc/default.nix and adjust
2/ nix-build is rebuilding GHC 7.8 and 7.10 (for pandoc I think).
=> Wait 2h.
3/ GHC build fails [2]
4/ We're not using
Hi all,
As some already seen I create tickets for each page in wiki (more or
less) each wiki page.
All are assigned to "Move the wiki!"[1] milestone, so we can track the progress.
Because of the quantity of content that needs to be migrated, and most
importantly reviewed, we must move with small
> On Feb 20, 2016, at 3:20 PM, Kosyrev Serge <_deepf...@feelingofgreen.ru>
> wrote:
>
> Anthony Cowley writes:
>> Bringing together what Thomas and Freddy say here, it seems to me that
>> a rather ideal mixture would be something unstructured like a wiki
>> with buttons for
Bringing together what Thomas and Freddy say here, it seems to me that a rather
ideal mixture would be something unstructured like a wiki with buttons for
readers saying, "This helped me" or "This did not work".
The point being that once a wiki item gets a handful of positive votes, it gets
On Saturday, February 20, 2016 15:16:12 zimbatm wrote:
> That's exactly why the wiki is good. The contribution barrier is fairly low
> and you can do things without having to ask for permission.
> It's very easy for anyone to come along and fix typos. Having the change
> appear directly is also
Adding documentation is one thing, maintaining it is a second. It's great
if someone is willing to convert contributions to Docbook, and I'm thankful
for that. However, that does not help much if you want to modify parts of
it. And as Nixpkgs is updated, so should the documentation.
I agree
I'm tool agnostic but +1 on having a cookbook in git for the
review-workflow (avoids wiki spam). I have a number of snippets (how to
remove gc roots, haskell profiling, how to use ihaskell properly, many
more) but no good place to put them.
I've started a git-book thing [1] a while back to
Someone (I think Vladimir?) offered to translate docs in any format
into the necessary docbook, and has done so at least for one of my PRs.
As long as that offer still stands and isn't overwhelming him, we can
avoid spending time and resources switching over our format until we
actually have
I agree with Vladimir that we already have the infrastructure, the Nixpkgs
repository.
What is needed is a clearer way where to put certain documentation and a
lower barrier for contributing. In `Redesign of documentation` I came with
a proposal of how to structure the documentation. A wiki has a
22 matches
Mail list logo