Back in December, I kept getting Error: Missing remote. https://pijul.zulipchat.com/#narrow/stream/270693-general/topic/missing.20remote

I never did get that one working, so I installed from crates again and cloned pijul into a different folder(pijul2). Now that I read there was a change due to Rust, which I had already updated, I tried to pull the changes. I get Error: No such file or directory (os error 2) on both repositories.

I’m running the 1.0.0-beta.

Not sure what’s going on there. Can you give me exact steps to reproduce?

I’m not sure what steps are missing. If I try to reproduce the error, it would be a clone of what’s there, and then there would be no changes to pull, so that doesn’t help.

I tried several times on the first pijul repo to pull changes, but always got Missing remote. Since I cloned the second pijul repo, I have done pijul pull , but there were 0 changes. Now that there are changes, (20 for the first and 2 for the second – so you should be able to tell when I last pulled them), I get No such file or directory.

Perhaps it would help if the error handling output more information, like the file name or something to try related to the command attempted.

This issue is not just that I can’t pull remote changes; it’s about giving the user some way out of a dead end.

Ok, let me try to guess the steps then. If they aren’t the right steps, please use them as a template to edit them. Without a way to reproduce the bug, there isn’t much we can do.

• Start from a fresh clone of https://nest.pijul.com/pijul/pijul
• Wait until there are new patches to pull.
• Try to pull, using pijul pull.
• This always gives a Missing remote, and a No such file or directory (are these two simultaneously written on the screen?).

In other words, if you tell me precisely what you did, what you expected, and what you got instead, this will be super helpful.

Please click on the link to Zulip, where I put screenshots of the commands. I tried to put that here, but it didn’t work.

I looked at the image on Zulip, but it isn’t a full description. I really need steps in the format from my previous post (sorry). In particular, starting from a fresh clone is important. If you can’t replicate, you can send me (pe@pijul.org) a tarball of your repository, along with exact steps (in text) to reproduce, saying for each step what you expected, and what you got instead.

I know this is a boring way to report bugs, but it makes things so much more efficient. This isn’t Pijul-specific, see https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

There are three issues here, that I think you are converging into one. This particular report (652) is about the problem the user faces when something has gone wrong, but pijul doesn’t give enough information to proceed.

You don’t need to reproduce the error message to fix it. You need to change the code so that more information is output in those cases, so that the user can know what to try next. In one case, a file name is needed. In another, perhaps the name of the remote or a prompt for which remote to use since none is known. I could write a separate issue for the problem I am currently having with the pijul repository generating these errors, but that is a separate concern.

There are three issues here, that I think you are converging into one.

I don’t know, because I haven’t seen a precise description of these issues. Sorry to be a little rigid here, but without a way to reproduce (along with a concrete description of “what you expected” and “what you got instead”), there really is nothing I can do, “changing the code” doesn’t really tell me how to change it.

I looked at the image on Zulip, but it isn’t a full description.

Well, it actually is. I haven’t done anything with the pijul repositories that I have cloned, except occasionally pull changes and then build. I’m not even executing the built versions, so I’ve only been running the pijul that I installed from crates.io (mostly because I kept getting “missing remote”).

“changing the code” doesn’t really tell me how to change it.

Ah, but I did tell you. The code that handles the error needs to output more information so the user can figure out what to do. It would even help you debug this, without having to reproduce the error yourself. Surely you don’t want to be sent tarballs of everyone’s repo that has problems like this, forever. Pijul needs some better error handling and recovery, because as it is now, it’s useless.

Well, it could be automated easily through either pijul or an external program. I think ultimately it does not matter as much if the end result is the same: him getting someone else’s repository who is having an issue.

I agree though, pijul could be a little bit more verbose when it aborts, for one. It should print out the OS, architecture, and so forth; the basic stuff. That is, if it does not already do so.

What kind of information do you have in mind that would help him sufficiently without having the repository in which the bug was encountered? I suspect there are a lot of bug reports that are actually user error and have nothing to do with pijul per se. Those may be weeded out.

At any rate, pmeunier is asking you specifically as to how you reproduced the bug. Give him the commands you entered step-by-step. You may have it in ~/.bash_history.

I do not believe the current way to be useless, but it may be time-consuming on his end; read above.

Here is the steps to reproduce, as before: type pijul pull in the previously untouched Pijul folder. That’s it! I did this today, and got

working/pijul3$ pijul pull
Downloading changes [=====================>                            ] 19/44                     
Error: No such file or directory (os error 2)
working/pijul3$ 

You really don’t need to reproduce the error. Simply go to the code that can get a “missing file” error and make sure the file name is included in the error message. Bonus points if it indicates whether the file is local or remote. (I think there were people getting this error when the Nest had replication problems.)

Possibly related: #723

Can we patch at least to include the filename and spit that out to the stderr with any underlying OSerrors? It seems like this is missing by default from rust, and whilst they discuss there what the best solution is or if it’s going to be implemented, may be worth implementing just for the project.

Hi! I just reviewed this patch, there are several issues:

• A minor one: this patch touches libpijul, yet #IUH7IMWES3KQTHVWA5UNHAO7QWVCC5PQJ6VLK3RC3T4F2MS74P3AC (the contributor license agreement for libpijul) is not an explicit dependency.

• If errors from libpijul provide a context, that context should not be strings describing errors in plain english. They should instead be exploitable by an algorithm. Imagine the simple case where I want to translate all the error messages to French.

• Finally, a more general thing to do, if we want to provide nicer errors, would be to get rid of the dependency on anyhow in Pijul, and replace it with proper error messages. This has been an area of continuous improvements in the Rust community for years, a better solution could be https://github.com/yoshuawuyts/context-attribute. Or maybe something else: part of the job here is to do the literature review.

Can we separate this into two milestones?

1. Add a Option<PathBuf>** field to libpijul::*Error::Io
2. Proper error handling and context

The first milestone is a MVP that would at least assist in debugging. I’m on a tier-2 OS so it is already difficult to use pijul without encountering a nondescript “os error 2.” Seeing the file paths involved would be immensely helpful.

The second milestone would be informed by concurrent efforts in the broader Rust community, and would be a prerequisite for a libpijul 1.0.0.

** Or Vec<PathBuf>/Box<[PathBuf]> if we want to generalize beyond just 0 or 1 paths. For example, the human-readable error message for a failed std::fs::copy should arguably show both the source and destination paths to the user.