<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - memfd doesn't work between 64-bit server and 32-bit client"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=97769#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - memfd doesn't work between 64-bit server and 32-bit client"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=97769">bug 97769</a>
              from <span class="vcard"><a class="email" href="mailto:userwithuid@gmail.com" title="userwithuid <userwithuid@gmail.com>"> <span class="fn">userwithuid</span></a>
</span></b>
        <pre>Works for me using custom PA 9.0 arch pkgs with your patch applied, thanks for
the fix.



If I understand correctly, the current solution requires the fix to be applied
in the 32-bit client libs (libpulsecommon)? If that's true, this could be a
small problem for the 10.0 memfd default: Default 9.0 seems to compile memfd
and use it client-side (unless explicitly disabled in client.conf) when the
server requests it (which the 10.0 server will do by default).

Ideally, this shouldn't be a problem as the client can be updated to 10.0 like
the server, but bundling/snapshotting/embedding libs obviously happens in
practice (e.g. steam, games). As of right now, this is mostly a theoretical
issue because the legacy 32-bit clients I'm aware of use <9.0 anyway and
therefore don't have memfd at all. But until a fixed 9.1 or 10.0 is released,
faulty 9.0 clients have time to get adopted in such bundles.

That is, if I got this right, it's a little confusing and I might have missed
something. :-)</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>