~oliverpool

Recent activity

Re: [builds.sr.ht] different PATH for build and ssh session 11 months ago

From Olivier C to ~sircmpwn/sr.ht-discuss

> > As a newbie, I think it would be a usability improvement to fix this.
> 
> It is not a bug. It's just how Unix works.

I am just a software developer, not a Unix expert. I don't mean that there
is a bug in Unix. I just want to show that using builds.sr.ht is not as simple
as it could be and I want to help make it a bit easier to use for other users.

> You should just source /etc/profile in your build script, perhaps?
> 
> . /etc/profile

Thanks, this is much better to have a consistent behavior between building
and ssh-debugging.

Re: [builds.sr.ht] different PATH for build and ssh session 11 months ago

From Olivier C to ~sircmpwn/sr.ht-discuss

Thanks for the explanation.

As a newbie, I think it would be a usability improvement to fix this.
But I have no idea, what the preferred solution would be:
- recommend installation of software in /usr/bin (instead of /usr/local/bin)
by running `sudo make PREFIX="/usr" install` in the official builds.sr.ht docs
- adjust the PATH of the build scripts to add /usr/local/bin (like it is done in /etc/profile)
- adjust the PATH of the login shell, to remove /usr/local/bin
- document this subtle difference on the official builds.sr.ht doc

I currently use the first solution.
Should I send a patch to the builds doc? 
In https://man.sr.ht/builds.sr.ht/manifest.md#tasks

[builds.sr.ht] different PATH for build and ssh session 11 months ago

From Olivier C to ~sircmpwn/sr.ht-discuss

I have a build running on alpine/latest.

When I echo $PATH from the build manifest, it outputs:
/bin:/usr/bin:/sbin:/usr/sbin

However if I log into the vm (after a build failure for instance) and run echo $PATH, I get:
/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin

---

I don't know if this behavior is intended, or specific to the alpine image.

---

[PATCH v2] tasks: add tasks.feeds support 11 months ago

From oliverpool to ~adnano/kiln-devel

Every task can now have a [[tasks.feeds]] entry to generate one or more feeds.
It must have the following arguments:

[[tasks.feeds]]
input_dir = ""
title = "Example feed"
template = "atom.xml"
output = "atom.xml"
---
I think having [[tasks.feeds]] is fine. Yes it can generate arbitrary files,
but since they will be provided with the .Pages variable, they will be some
kind of feed or index.

If you have another naming suggestion, I can adjust this patch.
[message trimmed]

Re: [PATCH] tasks: add tasks.feeds support 11 months ago

From Olivier C to ~adnano/kiln-devel

Thanks for the review.

Let me know how I should handle the following points, so that I can make a patch v2:
- feed => integrate inside feeds?
- feeds.Permalink or Dir.path?
(see the details below)

> > +	extraFiles map[string][]byte // extra generated files
> 
> Perhaps this field should be named 'feeds' to make it clear what purpose
> it serves. Eventually we'll also want to remove the current 'feed'
> field. I don't think we'll be needing to store any other extra files any
> time soon.
> 

[PATCH] tasks: add tasks.feeds support 11 months ago

From oliverpool to ~adnano/kiln-devel

Every task can now have a [[tasks.feeds]] entry to generate one or more feeds.
It must have the following arguments:

[[tasks.feeds]]
input_dir = ""
title = "Example feed"
template = "atom.xml"
output = "atom.xml"
---
After our discussion on kiln-discuss, here is my attempt to support the 
[[tasks.feeds]] configuration.

A couple of things must be done after (or before) this is merged:
- update the documentation
[message trimmed]

Re: [PATCH pages.sr.ht] Delete previous site version when publishing new one 11 months ago

From Olivier C to ~sircmpwn/sr.ht-dev

> I wonder if for performance reasons we would be wise to shove this in a
> cronjob instead, so we can return the response back to the user sooner.

Another possibility would be to clean the old files in a goroutine.

> +		if prevVersion != site.Version {

I think that the special version "pending" could be skipped as well:

> +		if prevVersion != site.Version && prevVersion != "pending" {

Re: [kiln] Add content to feed without templating 11 months ago

From Olivier C to ~adnano/kiln-discuss

> Another potential solution would be to expose the
> original content in a new variable available to templates. This would
> fix your problem without breaking existing sites.

I am not fond of having an other variable for the same thing (.Content in the regular templates and .RawContent in the feed template).

Another backward compatible solution would be to deprecate (but still support for now) the [feeds] config and implement a [[tasks.feeds]] entry:

```config.toml
[[tasks]]
input = [".gmi"]
output = ".gmi"
template = ".gmi"
static_dir = "static"

[kiln] Add content to feed without templating 11 months ago

From Olivier C to ~adnano/kiln-discuss

Hi,

just like Ian in https://lists.sr.ht/~adnano/kiln-discuss/%3Cc66331d8-986f-eca1-1978-6d4ed68cefe3%40ianmjones.com%3E I would like to include the HTML content in my feed.
Using {{ exec "gmnitohtml" .Content | safeHTML }} is very neat and much more flexible than the pre-/postprocess options.

Actually, I got rid of the pre-/postprocess options, because my templates live in the kiln templates folder (it forces a copy of <doctype>, but also allows better customization).
But then the {{ .Content }} of the feed includes this template!

I would rather have access to the non-templated content.

The fix is quite trivial (in dir.go, move the feed generation before the templating code).
This change:
- is a breaking change (however if the template is needed, the user can simply copy/paste it in atom.xml)
- but I think it is more natural. I found having templated .Content quite surprising

[PATCH] fix: prevent panic when static_dir does not exist 11 months ago

From oliverpool to ~adnano/kiln-devel

---
This patch prevents a panic when 'static_dir' does not exist.
I choose to simply log it and let the build succeed.
If you prefer, I can change it to abort the build.

Olivier

PS: thank you adnano for your open-source contributions!
 main.go | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/main.go b/main.go
index 39fb70c..b081099 100644
--- a/main.go
[message trimmed]