GNU bug report logs - #38616
emacs: fix odt export

Previous Next

Package: guix-patches;

Reported by: anothersms <at> gmail.com (Nicolò Balzarotti)

Date: Sat, 14 Dec 2019 23:46:01 UTC

Severity: normal

Done: Nicolò Balzarotti <anothersms <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38616 in the body.
You can then email your comments to 38616 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to guix-patches <at> gnu.org:
bug#38616; Package guix-patches. (Sat, 14 Dec 2019 23:46:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to anothersms <at> gmail.com (Nicolò Balzarotti):
New bug report received and forwarded. Copy sent to guix-patches <at> gnu.org. (Sat, 14 Dec 2019 23:46:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: anothersms <at> gmail.com (Nicolò Balzarotti)
To: guix-patches <at> gnu.org
Subject: emacs: fix odt export
Date: Sun, 15 Dec 2019 00:45:09 +0100
[Message part 1 (text/plain, inline)]
Hello Guix!

Neither on NixOS or in guix I've ever been able to export an org file to
otd. The error was
'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.

I've seen some report of this error on the web, like:
- https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html
- https://github.com/syl20bnr/spacemacs/issues/1482

but also on our IRC:
- http://logs.guix.gnu.org/guix/2019-05-07.log
- http://logs.guix.gnu.org/guix/2019-07-25.log
but I was not able to find a fix for it.

Today I checked the source and figured it out. The explanation, as
written in the patch, is the following

> Files inside the guix store are read only. "styles.xml" is copied from the
> store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too.
> ox-odt needs this file, so if it's not writable it will fail. This patch
> adjust the permissions.

So, this patches fixes the permissions on the file.

I've two questions:
1. Is it fine to have a .patch, or should I add a phase where I fix the
   file? this seemed to be easier
2. If the same error happens for other programs, might it make sense to
   "fake" rw permissions in the store (by using a virtual fs or
   something) so that files are copied as rw, but files in the store are
   still ro?

Thanks!

Nicolò

[0001-gnu-packages-emascs.scm-emacs-patches-Fix-odt-export.patch (text/x-patch, attachment)]

Information forwarded to guix-patches <at> gnu.org:
bug#38616; Package guix-patches. (Sun, 15 Dec 2019 14:24:02 GMT) Full text and rfc822 format available.

Message #8 received at 38616 <at> debbugs.gnu.org (full text, mbox):

From: Jelle Licht <jlicht <at> fsfe.org>
To: Nicolò Balzarotti <anothersms <at> gmail.com>,
 38616 <at> debbugs.gnu.org
Subject: Re: [bug#38616] emacs: fix odt export
Date: Sun, 15 Dec 2019 15:23:48 +0100
Hello Nicholò,

anothersms <at> gmail.com (Nicolò Balzarotti) writes:

> Hello Guix!
>
> Neither on NixOS or in guix I've ever been able to export an org file to
> otd. The error was
> 'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.
>
> I've seen some report of this error on the web, like:
> - https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html
> - https://github.com/syl20bnr/spacemacs/issues/1482
>
> but also on our IRC:
> - http://logs.guix.gnu.org/guix/2019-05-07.log
> - http://logs.guix.gnu.org/guix/2019-07-25.log
> but I was not able to find a fix for it.
>
> Today I checked the source and figured it out. The explanation, as
> written in the patch, is the following
>
>> Files inside the guix store are read only. "styles.xml" is copied from the
>> store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too.
>> ox-odt needs this file, so if it's not writable it will fail. This patch
>> adjust the permissions.
Thanks for figuring this out! I've been using my local (terrible)
workarounds for years to make this work.

>
> So, this patches fixes the permissions on the file.
>
> I've two questions:
> 1. Is it fine to have a .patch, or should I add a phase where I fix the
>    file? this seemed to be easier

I can't really advise on the best way forward here, but if you do decide
to go with the .patch route, you should probably also add your .patch
file to `dist_patch_DATA' in gnu/local.mk.

> 2. If the same error happens for other programs, might it make sense to
>    "fake" rw permissions in the store (by using a virtual fs or
>    something) so that files are copied as rw, but files in the store are
>    still ro?

IMHO, software shouldn't assume certain permissions are set, and instead
check or make-it-so. Perhaps you could upstream your patch instead of
embedding it into Guix?

Furthermore, the same issue as the one your fixed here is also present
in our `emacs-org' package. Do you think your approach would work there
as well? If so, it might make sense to fix both emacs and emacs-org.

Thanks!
- Jelle




Information forwarded to guix-patches <at> gnu.org:
bug#38616; Package guix-patches. (Sun, 15 Dec 2019 14:58:02 GMT) Full text and rfc822 format available.

Message #11 received at 38616 <at> debbugs.gnu.org (full text, mbox):

From: Nicolò Balzarotti <anothersms <at> gmail.com>
To: Jelle Licht <jlicht <at> fsfe.org>, 38616 <at> debbugs.gnu.org
Subject: Re: [bug#38616] emacs: fix odt export
Date: Sun, 15 Dec 2019 15:56:50 +0100
Jelle Licht <jlicht <at> fsfe.org> writes:

> Hello Nicholò,
Nicolò :P

>
> anothersms <at> gmail.com (Nicolò Balzarotti) writes:
>
>> Hello Guix!
>>
>> Neither on NixOS or in guix I've ever been able to export an org file to
>> otd. The error was
>> 'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.
>>
>> I've seen some report of this error on the web, like:
>> - https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html
>> - https://github.com/syl20bnr/spacemacs/issues/1482
>>
>> but also on our IRC:
>> - http://logs.guix.gnu.org/guix/2019-05-07.log
>> - http://logs.guix.gnu.org/guix/2019-07-25.log
>> but I was not able to find a fix for it.
>>
>> Today I checked the source and figured it out. The explanation, as
>> written in the patch, is the following
>>
>>> Files inside the guix store are read only. "styles.xml" is copied from the
>>> store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too.
>>> ox-odt needs this file, so if it's not writable it will fail. This patch
>>> adjust the permissions.
> Thanks for figuring this out! I've been using my local (terrible)
> workarounds for years to make this work.

I tried org -> pandoc (docx), org -> pandoc (odt), org -> html -> pandoc
(docx) ... and so on but nothing was good enough, so my last resort was
to try to fix it :D

>
>>
>> So, this patches fixes the permissions on the file.
>>
>> I've two questions:
>> 1. Is it fine to have a .patch, or should I add a phase where I fix the
>>    file? this seemed to be easier
>
> I can't really advise on the best way forward here, but if you do decide
> to go with the .patch route, you should probably also add your .patch
> file to `dist_patch_DATA' in gnu/local.mk.
Ops thanks, I missed that bit.

>
>> 2. If the same error happens for other programs, might it make sense to
>>    "fake" rw permissions in the store (by using a virtual fs or
>>    something) so that files are copied as rw, but files in the store are
>>    still ro?
>
> IMHO, software shouldn't assume certain permissions are set, and instead
> check or make-it-so. Perhaps you could upstream your patch instead of
> embedding it into Guix?

I'll write a mail to emacs-orgmode <at> gnu.org right now. I've never
submitted bug reports to emacs or org (tried writing them on the IRC
channel but I've never received answers).

>
> Furthermore, the same issue as the one your fixed here is also present
> in our `emacs-org' package. Do you think your approach would work there
> as well? If so, it might make sense to fix both emacs and emacs-org.
>
With a quick look, I see no differences between the two files, (and I
assume no differences between file permissions, too). But if we can get
this patched upstream it would be better (I believe it will helps nixos
users too)

> Thanks!
> - Jelle

Thanks!




Information forwarded to guix-patches <at> gnu.org:
bug#38616; Package guix-patches. (Sun, 15 Dec 2019 15:08:02 GMT) Full text and rfc822 format available.

Message #14 received at 38616 <at> debbugs.gnu.org (full text, mbox):

From: anothersms <at> gmail.com (Nicolò Balzarotti)
To: emacs-orgmode <at> gnu.org
Cc: 38616 <at> debbugs.gnu.org
Subject: [Nicolò Balzarotti] [bug#38616] emacs: fix odt
 export
Date: Sun, 15 Dec 2019 16:07:41 +0100
[Message part 1 (text/plain, inline)]
Hello Org Mode people!

This is my first bug-report :)

I found a problem on org-odt-export-to-odt function.
The export fails with 'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.

The problem happens on ox-odt, when the file OrgOdtStyles.xml
permissions are read-only (this is true especially for Guix and Nix
where all the "store" is readonly). The file gets copied to /tmp/ob-*/
directory, and is then modified. However, the file is assumed to be
read/write. When the file is not, the export fails. I've sent a one-line
patch (simply change permissions to the newly-copied file):

> (set-file-modes (concat org-odt-zip-dir "styles.xml") #o600)

to guix-patches (here in CC, I'm also forwarding my original patch
submission here), but I've been suggested to send the patch upstream.

What do you think? I can submit a proper patch if needed (but feel free
to patch it yourself)

I want to thank everybody for how wonderful Org Mode is :)

Nicolò


[Message part 2 (message/rfc822, inline)]
From: anothersms <at> gmail.com (Nicolò Balzarotti)
To: 38616 <at> debbugs.gnu.org
Subject: [bug#38616] emacs: fix odt export
Date: Sun, 15 Dec 2019 00:45:09 +0100
[Message part 3 (text/plain, inline)]
Hello Guix!

Neither on NixOS or in guix I've ever been able to export an org file to
otd. The error was
'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.

I've seen some report of this error on the web, like:
- https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html
- https://github.com/syl20bnr/spacemacs/issues/1482

but also on our IRC:
- http://logs.guix.gnu.org/guix/2019-05-07.log
- http://logs.guix.gnu.org/guix/2019-07-25.log
but I was not able to find a fix for it.

Today I checked the source and figured it out. The explanation, as
written in the patch, is the following

> Files inside the guix store are read only. "styles.xml" is copied from the
> store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too.
> ox-odt needs this file, so if it's not writable it will fail. This patch
> adjust the permissions.

So, this patches fixes the permissions on the file.

I've two questions:
1. Is it fine to have a .patch, or should I add a phase where I fix the
   file? this seemed to be easier
2. If the same error happens for other programs, might it make sense to
   "fake" rw permissions in the store (by using a virtual fs or
   something) so that files are copied as rw, but files in the store are
   still ro?

Thanks!

Nicolò

[0001-gnu-packages-emascs.scm-emacs-patches-Fix-odt-export.patch (text/x-patch, attachment)]

Information forwarded to guix-patches <at> gnu.org:
bug#38616; Package guix-patches. (Tue, 17 Dec 2019 09:37:02 GMT) Full text and rfc822 format available.

Message #17 received at 38616 <at> debbugs.gnu.org (full text, mbox):

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: anothersms <at> gmail.com (Nicolò Balzarotti)
Cc: 38616 <at> debbugs.gnu.org, emacs-orgmode <at> gnu.org
Subject: Re: [Nicolò Balzarotti] [bug#38616] emacs: fix
 odt export
Date: Tue, 17 Dec 2019 10:36:51 +0100
Hello,

anothersms <at> gmail.com (Nicolò Balzarotti) writes:

> The problem happens on ox-odt, when the file OrgOdtStyles.xml
> permissions are read-only (this is true especially for Guix and Nix
> where all the "store" is readonly). The file gets copied to /tmp/ob-*/
> directory, and is then modified. However, the file is assumed to be
> read/write. When the file is not, the export fails. I've sent a one-line
> patch (simply change permissions to the newly-copied file):
>
>> (set-file-modes (concat org-odt-zip-dir "styles.xml") #o600)
>
> to guix-patches (here in CC, I'm also forwarding my original patch
> submission here), but I've been suggested to send the patch upstream.
>
> What do you think? I can submit a proper patch if needed (but feel free
> to patch it yourself)

It sounds good. Could you send a patch against "maint" branch?

Thank you.

Regards,

-- 
Nicolas Goaziou




Reply sent to Nicolò Balzarotti <anothersms <at> gmail.com>:
You have taken responsibility. (Sun, 22 Dec 2019 09:35:01 GMT) Full text and rfc822 format available.

Notification sent to anothersms <at> gmail.com (Nicolò Balzarotti):
bug acknowledged by developer. (Sun, 22 Dec 2019 09:35:01 GMT) Full text and rfc822 format available.

Message #22 received at 38616-done <at> debbugs.gnu.org (full text, mbox):

From: Nicolò Balzarotti <anothersms <at> gmail.com>
To: Jelle Licht <jlicht <at> fsfe.org>, 38616-done <at> debbugs.gnu.org
Subject: Re: [bug#38616] emacs: fix odt export
Date: Sun, 22 Dec 2019 10:34:13 +0100
Closing this since my commit has been merged upstream! [1]

(I read on debbugs that to close the issue I need to add -done after the
bug #, let's try)

[1] https://code.orgmode.org/bzg/org-mode/commit/6315e1e76087a013198bfc33f0ec6a444cf5e662

Jelle Licht <jlicht <at> fsfe.org> writes:

> Hello Nicholò,
>
> anothersms <at> gmail.com (Nicolò Balzarotti) writes:
>
>> Hello Guix!
>>
>> Neither on NixOS or in guix I've ever been able to export an org file to
>> otd. The error was
>> 'OpenDocument export failed: Buffer is read-only: #<killed buffer>'.
>>
>> I've seen some report of this error on the web, like:
>> - https://lists.gnu.org/archive/html/emacs-orgmode/2018-05/msg00545.html
>> - https://github.com/syl20bnr/spacemacs/issues/1482
>>
>> but also on our IRC:
>> - http://logs.guix.gnu.org/guix/2019-05-07.log
>> - http://logs.guix.gnu.org/guix/2019-07-25.log
>> but I was not able to find a fix for it.
>>
>> Today I checked the source and figured it out. The explanation, as
>> written in the patch, is the following
>>
>>> Files inside the guix store are read only. "styles.xml" is copied from the
>>> store (/share/emacs/26.3/etc/org/OrgOdtStyles.xml), so it's read only too.
>>> ox-odt needs this file, so if it's not writable it will fail. This patch
>>> adjust the permissions.
> Thanks for figuring this out! I've been using my local (terrible)
> workarounds for years to make this work.
>
>>
>> So, this patches fixes the permissions on the file.
>>
>> I've two questions:
>> 1. Is it fine to have a .patch, or should I add a phase where I fix the
>>    file? this seemed to be easier
>
> I can't really advise on the best way forward here, but if you do decide
> to go with the .patch route, you should probably also add your .patch
> file to `dist_patch_DATA' in gnu/local.mk.
>
>> 2. If the same error happens for other programs, might it make sense to
>>    "fake" rw permissions in the store (by using a virtual fs or
>>    something) so that files are copied as rw, but files in the store are
>>    still ro?
>
> IMHO, software shouldn't assume certain permissions are set, and instead
> check or make-it-so. Perhaps you could upstream your patch instead of
> embedding it into Guix?
>
> Furthermore, the same issue as the one your fixed here is also present
> in our `emacs-org' package. Do you think your approach would work there
> as well? If so, it might make sense to fix both emacs and emacs-org.
>
> Thanks!
> - Jelle




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 19 Jan 2020 12:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 155 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.