Karl Voit writes:
> I just committed a minimal change to that file which caused the CI
> to re-build the page: https://builds.sr.ht/~bzg/job/975519 which
> ended successfully but still shows an error:
> from the Orgdown file.
> ...
> The issue still persists.
I can finally see this update being
On 09/08/2023 14:44, Ihor Radchenko wrote:
Unfortunately, I was not able to find a way to do it and yet display the
error backtraces.
The best we can do is using `backtrace-get-frames' in the error
handler:
My version of the script prints allowed number of error messages and
stack of the
Ihor Radchenko writes:
>>> Note that I just pushed an alternative (but very similar) change in
>>> https://git.sr.ht/~bzg/worg/commit/b38a1f08
>>
>> It fails on first error. I find a report containing several errors much
>> more helpful for figuring out what has actually happened. On the other
Thanks for the fixes!
Ihor Radchenko writes:
> And I can see that it is not all yet. There is some major change in the
> latest ESS that is causing ob-R to fail (see our latest R session test
> failures in sr.ht CI). It is also preventing publishing because Org
> attempts to evaluate some R
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> May it be enough to drop --quick in Emacs call from publish.sh instead
>> of manually adding system-installed Emacs packages?
>
> Indeed. Please go ahead: experimental commits won't hurt much.
Done.
Ihor Radchenko writes:
> May it be enough to drop --quick in Emacs call from publish.sh instead
> of manually adding system-installed Emacs packages?
Indeed. Please go ahead: experimental commits won't hurt much.
> May we just set #+PROPERTY: header-args :eval no-export across
> examples?
Max Nikulin writes:
>> I am not sure why it would be useful to limit the number of errors to
>> anything other than 0/infinity.
>
> You have agreed that aborting of upload on any error may be
> disappointing when the error was introduced by another person.
This will not happen now.
See
On 05/08/2023 19:23, Ihor Radchenko wrote:
Max Nikulin writes:
I was trying to modify publish.sh to collect errors up to a reasonable
number, a draft is attached.
...
Currently it just prints summary of failures. When allowed failures
count is exceeded, it fails immediately.
./publish.sh
Bastien Guerry writes:
>> So, there is still a problem with ESS installation.
>> We may need to update the build manifest yet more.
>> Probably "elpa-ess" is installed into some weird place, out of
>> load-path.
>
> I added the load-path for ess, this seems to work.
May it be enough to drop
Ihor Radchenko writes:
> So, there is still a problem with ESS installation.
> We may need to update the build manifest yet more.
> Probably "elpa-ess" is installed into some weird place, out of
> load-path.
I added the load-path for ess, this seems to work.
I also added the gnuplot dependency
Max Nikulin writes:
> I was trying to modify publish.sh to collect errors up to a reasonable
> number, a draft is attached. It can be improved further to save list of
> failures to some file, so final step of .build.yml may be to check
> whether this file is empty and to send a notification
On 31/07/2023 23:41, Ihor Radchenko wrote:
Max Nikulin writes:
I hope, there is a better way to address the issue with failure
notifications.
That sounds too complex.
I think we can simply add an extra "check" task to
https://git.sr.ht/~bzg/worg/tree/master/item/.build.yml
It will run after
Bastien Guerry writes:
>> What about the other approach I proposed?
>> (where we export skipping errors first, upload, and then re-export,
>> catching all errors this time just to trigger an email to notify about
>> the failure).
>
> Yes, let's do this.
Ok. I added a new --debug command line
Hi Ihor,
Ihor Radchenko writes:
> I am not sure.
> We now got exactly the concern Max raised: New commits do not update
> WORG as long as even a single WORG page is broken:
> https://builds.sr.ht/~bzg/job/1035051
Mh, yes, I reverted this change.
> What about the other approach I proposed?
>
Bastien Guerry writes:
> Ihor Radchenko writes:
>
>> I am attaching tentative patch that will revert demoting errors to
>> messages. However, I do not fully understand the purpose of the original
>> `condition-case' code in the publish.sh. Bastien?
>
> Applied. I'm aware it only fixes part of
Ihor Radchenko writes:
> I am attaching tentative patch that will revert demoting errors to
> messages. However, I do not fully understand the purpose of the original
> `condition-case' code in the publish.sh. Bastien?
Applied. I'm aware it only fixes part of the issue at hand, but I
believe
Max Nikulin writes:
> On 30/07/2023 16:16, Ihor Radchenko wrote:
>> The problem with dependencies is only there for local builds and that's
>> probably the motivation of the `condition-case' I proposed to change in
>> my patch.
>
> Worg is a set of independent documents, so fail on first error
On 30/07/2023 16:16, Ihor Radchenko wrote:
The problem with dependencies is only there for local builds and that's
probably the motivation of the `condition-case' I proposed to change in
my patch.
Worg is a set of independent documents, so fail on first error in CI is
reasonable mostly only
Max Nikulin writes:
> On 30/07/2023 13:40, Ihor Radchenko wrote:
>> We already have
>> (load "/usr/share/emacs/site-lisp/elpa-src/htmlize-1.56/htmlize.el")
>
> --no-init-file may allow to avoid specifying versions of packages.
Then, +1 for --no-init-file, I guess.
>> publish.sh already takes
On 30/07/2023 13:40, Ihor Radchenko wrote:
We already have
(load "/usr/share/emacs/site-lisp/elpa-src/htmlize-1.56/htmlize.el")
--no-init-file may allow to avoid specifying versions of packages.
publish.sh already takes care about not re-exporting unchanged files.
I do not think it has any
Max Nikulin writes:
> On 29/07/2023 19:14, Ihor Radchenko wrote:
>> I suspect that there is some misconfiguration of the build.
>
> Despite the .build.yml file file installs the elpa-ess package, it is
> ignored when .org files are processed due to the --quick option in
> publish.sh. Perhaps
On 29/07/2023 19:14, Ihor Radchenko wrote:
I suspect that there is some misconfiguration of the build.
Despite the .build.yml file file installs the elpa-ess package, it is
ignored when .org files are processed due to the --quick option in
publish.sh. Perhaps --no-init-file (-q) will help,
Karl Voit writes:
>> I believe that I fixed the issue in
>> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f
>>
>> But I am not sure if I actually did. We need to trigger WORG rebuild to
>> see, I think.
>
> I just committed a minimal change to that file which caused
Hi Ihor,
* Ihor Radchenko wrote:
> Karl Voit writes:
>
>> Okay, that was also my idea when I saw the log file. Can somebody
>> fix ESS here or should we convert the R blocks to a different block
>> type (EXAMPLE)?
>
> I believe that I fixed the issue in
>
Karl Voit writes:
> Okay, that was also my idea when I saw the log file. Can somebody
> fix ESS here or should we convert the R blocks to a different block
> type (EXAMPLE)?
I believe that I fixed the issue in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f
But I am
* Ihor Radchenko wrote:
> Karl Voit writes:
>
>> CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of
>> HTML pages but for org-tools, there is no HTML output generated as
>> it seems. Whatever I write in org-tools/index.org doesn't get to the
>> HTML version of it.
>>
>> Maybe
Karl Voit writes:
> CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of
> HTML pages but for org-tools, there is no HTML output generated as
> it seems. Whatever I write in org-tools/index.org doesn't get to the
> HTML version of it.
>
> Maybe somebody has an idea what's going on
Hi,
After fixing my WORG setup and being able to push again, I found out
that https://orgmode.org/worg/org-tools/ isn't updated by the CI
job.
https://git.sr.ht/~bzg/worg/tree/master/item/org-tools/index.org
shows the latest changes, https://orgmode.org/worg/org-tools/
doesn't.
CI example:
28 matches
Mail list logo
