@Zanna It's using dpkg in a lower-level way than most of would manually use it, using separate calls for each of the major steps of installing a deb package. Incidentally, it seems APT cannot be made to use busybox dpkg, which doesn't support options like --status-fd. I had to restore /usr/bin/dpkg by manually unpacking the downloaded .deb file for it with ar x (and then unpacking data.tar.xz with tar xf) and copying that specific file.
The path has to have a / in it to be recognized as such, so where dpkg -i foo.deb and gdebi foo.deb would work, you'd have to use apt install ./foo.deb.
@Zanna I think in your use case with the recipes that it's reasonable to keep the testing recipes in the master branch. You might still branch for particular changes (though in your use case it may be reasonable to develop on master). I think this is like having a program with a whole bunch of official plugins that ship as part of it and are developed in the same repository, where plugins that are less stable are in a separate directory and not enabled by default but still shipped.
@Zanna Do you want to continue with that? If so, what's the current state of your local hello-world repository? Is master up to date with the remote repository?
(I think you were going to check if it was safe to delete the local short branch. If origin/short was merged into origin/master upstream through the GitHub interface, then even though you've already pruned origin/short locally, I think pulling or manually fetching and merging master may let you remove short with git branch -d. If not, then you'll want to examine the differences before using the scary -D option.)
I didn't find it in the man pages when I checked earlier today. That doesn't mean it's not there, only that I don't think it's there.
(The weird self-reply--not that self-replies are weird in general, I mean just that one--is for continuity in case we end up moving the APT-specific parts of the conversation to the Island.)
@Zanna It occurred to me that you might be interested in CodinGame, which I learned about from a recent episode of .NET Rocks. It has Python, among other languages. (I was surprised to find that it has Bash!)
It's good to be comfortable checking out individual files from another branch or commit than the one you're on, which would've probably been the best way to do that if the branch had to stay unmerged. You could just try that now if you want. But it's not done all that often. I'd be interested to move on to, and/or to continue, other things. But it's up to you.
A while ago, I had two laptop keyboards (same laptop, same keyboard or so I thought when I bought the second one but now I'm not sure) where the W key become mostly unusable because it was the key I pressed (and often held) to walk or run forward in video games.
Oh nice. I think that's perfect for this. (Though you can also use your own machine. Your "remote" can even be another directory--the "URL" for a remote can just be a traditional Unix-style path if you really want.)
Would you want your remote accessible from the Internet? If so, you'll have to forward a port, which idk if your Internet connection supports but most do (or use something like UPnP to forward it automatically, which I don't know how to do for an SSH server, but it's possible, if your router or ISP supports it).
@Zanna In that case, you might be unhappy to hear that running your own SSH server on which you have Git repositories does not require much sophisticated networking knowledge.
You'll have to think about security. I mean, you already have to think about that, but I mean, you'll have to think about stuff like how anybody can connect to your SSH server and attempt to authenticate. So you need to keep it up to date, make sure all user accounts that can log in have good passwords and/or reconfigure sshd to allow only key-based authentication, that kind of stuff.
@Zanna I think I might have some trouble figuring out if you can forward ports, based on that website. You may be able to figure it out a lot easier.
Unless there is reason to believe you will have to configure your Ubuntu server specially, my guess is that Super User would be the best Stack Exchange site for your question. I don't think I've seen your question, though. If you include a link to the closed question then more detailed advice sho...
Btw, idk how much you've done with remotes since we last worked with them here. But at that time, you'd only made changes to your repo through the GitHub interface. You'd fetched, and merged from a fetch, and done both by pulling (though under weird circumstances--you may want to try pulling when your branch exists and there's something unfetched to pull). But you hadn't actually pushed to a remote.
If you haven't tried pushing yet, I suggest learning about that before setting up your own bare repository and using it as a remote.
(Because when it comes to using remotes, pushing is one of the most essential operations.)
Do you think you may want to continue this in the next twelve hours or so?
These days, I don't check Ask Ubuntu as much in the evening (where I am) as in the morning but I'd be pleased to check the chat tonight (where I am) if you think you may want to continue then.
It's totally up to you. Note that I'm not promising or committing to being available, only predicting that I might be. You should not inconvenience yourself.
Btw, other things you could try without me (or with me) and that I recommend trying sometime soon-ish are:
(a)git mergetool to resolve merge conflicts using an external program (you can use your mergetool of choice, I suggest starting with meld)
(b)git difftool to display diffs with an external program (most mergetools are also difftools), and
(c) resolving a merge conflict between a local branch and its associated upstream (remote) branch that occurs when you run git pull or when you run git merge after running git fetch.
Also, you should try making a branch locally that doesn't exist on the remote and pushing it to the remote. After that, you might find it interesting to bring your short branch back from the dead, then push it to the remote, then try deleting it on the remote with git commands you run on your computer rather than through the GitHub interface.
There's other stuff I have in mind but this is lots of stuff so I'm going to stop saying stuff until later... or at least slow down. :)
> Unlike dpkg, apt-get does not understand .deb files, it works with the packages proper name and can only install .deb archives from a source specified in /etc/apt/sources.list.
@Kulfy That's out of date in more ways than one. It claims that archives must be specified in /etc/apt/sources.list, but for quite some time they can also be specified in .list files in an /etc/apt/sources.list.d directory.