unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: bokr@bokr.com
To: Maxime Devos <maximedevos@telenet.be>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	"Chris Marusich" <cmmarusich@gmail.com>,
	53355@debbugs.gnu.org, 51466@debbugs.gnu.org
Subject: bug#51466: bug#53355: guix shell --check: confusing error message
Date: Sat, 25 Jun 2022 22:06:46 +0200	[thread overview]
Message-ID: <20220625200646.GA8075@LionPure> (raw)
In-Reply-To: <bf5b3b83c03de0c5056255ea60a3d0b4f8036478.camel@telenet.be>

On +2022-06-25 19:40:48 +0200, Maxime Devos wrote:
> Chris Marusich schreef op za 25-06-2022 om 09:52 [-0700]:
> > Yes, I agree those are good reasons to avoid a temporary file if we
> > can.
> > To that end, do you know if we can somehow force Guile to use a
> > specific
> > file descriptor for the pipe?  In the patch I wrote earlier, which
> > uses
> > redirection, the problem was that I could not control Guile's choice
> > of
> > file descriptors.  Guile chose file descriptor 19 for one end of the
> > pipe, and I don't know how to make it use anything else.  If we can
> > arrange for Guile to consistently use file descriptor 7, for example,
> > then probably it would work in all the shell I've tested.
> > 
> > I wonder if maybe I can just duplicate the file descriptor?  I don't
> > know; if for example Guile reserves all the file descriptors below 10
> > for other uses, it might be hard.
> > 
> 
> Have a look at ‘(guile)Ports and File Descriptors’.  It has lots of
> procedures for duplicating and renumbering.  That's fragile though, you
> might accidentally overwrite an fd that's being used for something
> else.
> 
> (Normally move->fdes would prevent overwriting things by moving pre-
> existing fds out of the way, adjusting ports automatically, but move-
> >fdes doesn't know (yet) about the pipe that Guile uses for
> finalisation, see maybe:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48563>)
> 
> I think it would be best to patch the dash appropriately (though fixing
> move->fdes would be nice too).
> 
> Greetings,
> Maximee.

Could this help?:

(from man 2 openat (scroll down a fair bit):
-8<---------------cut here---------------start------------->8---
  There are two main use cases for O_TMPFILE:

  *  Improved tmpfile(3) functionality: race-free creation of temporary files that (1) are automatically
     deleted  when closed; (2) can never be reached via any pathname; (3) are not subject to symlink at‐
     tacks; and (4) do not require the caller to devise unique names.

  *  Creating a file that is initially invisible, which is then populated with data and adjusted to have
     appropriate  filesystem  attributes (fchown(2), fchmod(2), fsetxattr(2), etc.)  before being atomi‐
     cally linked into the filesystem in a fully formed state (using linkat(2) as described above).

  O_TMPFILE requires support by the underlying filesystem; only a subset of  Linux  filesystems  provide
  that  support.   In  the  initial  implementation,  support was provided in the ext2, ext3, ext4, UDF,
  Minix, and shmem filesystems.  Support for other filesystems has subsequently been added  as  follows:
  XFS (Linux 3.15); Btrfs (Linux 3.16); F2FS (Linux 3.16); and ubifs (Linux 4.9)
--8<---------------cut here---------------end--------------->8---

BTW, IIRC, this can be used to create an invisible file that
can be mmap-ed, and the mmap will persist when you delete
the file. Which then can be used as an anonymous buffer
passed to wayland, along with metadate saying what the buffer
contains, e.g. different kinds of rgb or rgba permutations
and encodings, (or anything, which you can tell wayland just
to keep track of for you.

You need a directory for openat, so probably
    XDG_RUNTIME_DIR=/run/user/1000
is suitable if it exists. Worked in my case.

HTH
--
Regards,
Bengt Richter




  reply	other threads:[~2022-06-25 20:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19  3:29 bug#53355: guix shell --check: confusing error message Chris Marusich
2022-01-24 14:35 ` Ludovic Courtès
2022-01-25  0:55   ` Chris Marusich
2022-01-25 13:39     ` Ludovic Courtès
2022-02-02  7:49       ` bug#51466: " Chris Marusich
2022-02-08  9:26         ` Ludovic Courtès
2022-02-13 23:17           ` Chris Marusich
2022-02-14  9:47             ` Ludovic Courtès
2022-03-08 19:07               ` Ludovic Courtès
2022-05-20 21:37                 ` Ludovic Courtès
2022-05-24  4:42               ` Chris Marusich
2022-06-13 10:03                 ` Ludovic Courtès
2022-06-19 20:40                   ` Chris Marusich
2022-06-20  7:34                     ` bug#51466: " Ludovic Courtès
2022-06-20 10:12                     ` bug#53355: " bokr
2022-06-20 17:56                       ` Bengt Richter
2022-06-20 23:27                         ` bug#51466: " Bengt Richter
2022-06-21  4:00                           ` Thiago Jung Bauermann via Bug reports for GNU Guix
2022-06-25  9:07                 ` Chris Marusich
2022-06-25  9:37                   ` bug#53355: bug#51466: " Maxime Devos
2022-06-25 16:52                     ` Chris Marusich
2022-06-25 17:40                       ` Maxime Devos
2022-06-25 20:06                         ` bokr [this message]
2022-06-25 21:04                           ` bug#51466: " Maxime Devos
2022-06-26 10:33                         ` Josselin Poiret via Bug reports for GNU Guix
2022-06-26 13:07                           ` Maxime Devos
2022-06-26 19:45                             ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-06-27 10:17                   ` bug#51466: " Ludovic Courtès
2022-06-27 10:34                     ` bug#53355: " Maxime Devos
2022-06-28  7:45                       ` Ludovic Courtès
2022-06-28 10:38                         ` Maxime Devos
2022-06-28 16:57                           ` bug#53355: " paren--- via Bug reports for GNU Guix
2022-06-28 17:31                             ` bug#51466: " Maxime Devos
2022-07-04  8:11                             ` Ludovic Courtès
2022-06-27 11:23                     ` bokr
2022-06-27 14:22                       ` bug#51466: bug#53355: " Bengt Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220625200646.GA8075@LionPure \
    --to=bokr@bokr.com \
    --cc=51466@debbugs.gnu.org \
    --cc=53355@debbugs.gnu.org \
    --cc=cmmarusich@gmail.com \
    --cc=ludo@gnu.org \
    --cc=maximedevos@telenet.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).