~sircmpwn/aerc2#540: 
aerc cannot open certain guix bug report emails

I get a red message at the bottom saying mime: no media type Not all are sent by the same person. It sounds like a web-ui bug formatting tool may be somewhat to blame, but the emails open okay in a webmail client, and I hear they also open fine in mutt. I'll see if I can forward one of the bad emails to this thread after it's created. If I run :forward from the inbox, this seems to be the only way aerc can view the message body that I've found so far. I can open the message after forwarding it to myself, still in aerc, so forwarding it might be stripping some stuff. It seems attachments are involved.

https://issues.guix.gnu.org/52684 Here's a link to the thread. Most or all of the problematic emails seemed to be ones with [BUG] in the subject. The ones sent by Christopher in this thread in particular seem to the busted. Replies from Maxime open fine, somehow.

Status
REPORTED
Submitter
bdju@tilde.team
Assigned to
No-one
Submitted
22 days ago
Updated
22 days ago
Labels
No labels applied.

bdju@tilde.team 22 days ago · edit

Forwarded message from Christopher Rodriguez on Tue Dec 21, 2021 at 4:38 PM: Ah, I see. That makes sense.

However, I don't think we need to necessarily use all of 'beets' inputs as inputs for 'beets-bandcamp', because it will build fine with just the inputs listed. I know it isn't DRY, but it seems like the most efficient way to define the package might be to simply define the packages it is expecting to see, and only those packages: That way, should someone install 'beets' and then 'beets-bandcamp' at a later time, they don't need to download unused inputs (like, for instance, 'python-rarfile').

That said, I suppose at least 'beets' needs to be a propagated-input for 'beets-bandcamp', because IIUC the main difference between the propagated-inputs and inputs is that inputs are used only at build time (like 'BuildRequires' in RPM), whereas propagated-inputs are pulled in as installed dependencies (like 'Requires' in RPM). 'beets' would need to be a propagated-input because 'beets-bandcamp' is a plugin for 'beets', and requires 'beets' to function as expected. Is that correct?

If so, I am unsure why the other originally propagated-inputs were listed as such when they weren't needed for beets to function. I just built beets-bandcamp with everything listed as a propagated-input in my patch moved to an input, and it built fine. Is there a way I could install that built version to test it, to ensure none of the inputs need to be propagated-inputs (aside from 'beets')?

Please let me know if I'm way off base here; I'm very new to packaging in GNU/Guix! (And thank You for the help while I learn!)

As for the GUIX_PYTHONPATH and GUIX_BEETSPATH idea, I would love to implement something like that here, but I am running against my inexperience here, and was unable to find useful docs on defining PATHs or 'wrap-program' (I haven't looked exhaustively yet, but only have so much time in the day to do so, unfortunately).

Could You point me to some resources to explain the mechanisms involved in defining PATHs, or on the 'wrap-program' function? I am more than willing to learn.

Sorry if I'm asking a lot of questions; I'm excited to be a part of this project!

Register here or Log in to comment, or comment via email.