when apt warns you to use caution when using it in scripts because it doesn't have a stable CLI interface, what does it mean by caution? Like you are either going to write a script that involves it or not I don't get how I can be cautious here
@AdamL they mean that if you're scripting something, the chance of breakage is higher if you use apt rather than apt-get. aptis being tweaked by its developers more frequently and probably isn't backwardly compatible with older apt versions.
My man apt has this:
The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use.
All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8) as well. apt(8) just changes the default value of some options (see apt.conf(5) and specifically the Binary scope). So you should prefer using these commands (potentially with
faheem@orwell:/usr/local/src/nsepy/nsepy$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
test.py
test.py~
@StephenKitt I even left a comment about how @Kusalananda misunderstood the question and was silently patting myself on the back over how clever I was. Sigh.
Instead, I ended up deleting my answer because it was I who wasn't answering the question, not Kusalananda. Grrr.
Oh, hey @StrongBad! Weird seing you without your diamond :(
Here lies Mr. Stephen Kitt Whose typing has slowed quite a bit. He left quite a trail of quotes Yet managed to restrain his votes. On his way out he exclaimed, "I hope this place doesn't turn to ****!"
@terdon they took away my diamonds today. I still have access to one of my sites mod chat rooms. I thought it might be caching and when I refreshed I got logged into a bunch of rooms.
Are all of you C or C++ programmers? Java has several autobuild tools: Maven, Gradle, Ant, .... With them, I can have a default build file for specific projects ready, and modify it according to my need. I was wondering what autobuild tools are currently popular for C and C++ projects? Do they create default build files for different types of C++ projects? I suck at writing makefiles from scratch, though I can learn Thanks.
@Kusalananda So, in a bit more detail, should one (a) fork on Github (b) clone the fork (c) create a separate branch for the PR (does GitHub have naming preferences of constraints?) (d) commit to the branch (e) push the commit/branch back to the Github fork (f) Do whatever it necessary to actually make a PR?
@Tim autotools works pretty well, though it's not exactly flavor of the month (or any month). There are lots of options. I've tried using scons and CMake before.
Neither of them do everything that autotools does. And I didn't much like CMake, honestly.
Autotools has such a long history that you can practically Google every error one comes across, and you can usually find out what it means, and how to fix it.
@Tim C++ is really more like a collection of closely related languages.
I hear the standard is still evolving, relatively fast.
@FaheemMitha If you don't have write access to the upstream repository, then I would do something like that, but working on a feature branch is not strictly necessary then. I usually follow the "Git flow" workflow, with feature branches called feature/topic (for some "topic") branched off some development branch.
@FaheemMitha (a) yes (b) yes, git clone git@github.com:fmitha/project.git (replacing fmitha and project as appropriate (c) typically yes, no constraints beyond git’s (d) yes (e) git push fmitha yourbranch (f) follow the instructions shown by git after the push
and if you need to update your PR following a review, force-push your branch: git push -f fmitha
@FaheemMitha On the projects I work on there are two main branches: master (a stable release) and develop (where development happens). Features are often developed on separate (temporary) feature branches off of the develop branch.
however with a GitHub-style fork-based workflow, there’s little risk of losing work because of a force-push, which is what the lease system tries to protect against
@terdon yes; my point is that since most GH projects involve only pushing to one’s own fork, leases aren’t necessary
however my use of git isn’t necessarily all that typical, since I only work on open source projects which require reviews before merges (whether the PRs take place using git or email)
so for most people, learning to use --force-with-lease by default (when one has to force-push at all) is better
@terdon the point of leases is to avoid the following scenario: against the master branch at commit A, user F writes commit F, and on top of that, user G writes commit G (and F is unaware of this). So the tree looks like A → F → G, hopefully on a branch, but importantly, a branch shared by F and G. If F updates commit F (F’), and force-pushes, the branch will become A → F’ and G will be lost.
Force-pushing with a lease would fail because of G, and user F would then have to rebase G on top of F’ before being allowed to force-push the branch.
If everyone works on their own branch, this never happens, or at least user G keeps a copy of F in their own repo and user F can’t destroy that.
Likewise if all reviews are done by email (e.g. for the Linux kernel, or MinGW-w64), the issue doesn’t arise either.
(And my tendency to rely on force-pushing and rewriting history is probably tied closely to the fact that I learnt git-based code review on the kernel and on projects using Gerrit.)
The usual way I've handled auth via SSH is to have to generate a private/public keypair, and then create a entry in the ssh config file with a corresponding host. And then use that host. Does git or GitHub have a different way to do it?
And I'm not sure how a ssh domain would work with:
@Kusalananda Yes, I got that part. But how do I tell ssh where to look for the local/private key? Normally the ssh config entry tells ssh which one is being used.
@Kusalananda For something like doing an occasional authentication for a repos push, I'd probably just type in the phrase manually. Though I've used keychain in the past.
When you're prompted to "Enter a file in which to save the key," press Enter. This accepts the default file location.
> Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]
I already have a existing file at that location.
I think I'll just do it the way I know how to do it.
Does anyone here using blank passphrases with GitHub? Is it is bad idea?
@FaheemMitha I don't have all the context here, but if you're creating a new SSH key just for github purposes, then I would suggest a unique filename -- so that you're not clobbering your existing file.
@FaheemMitha it looks to me like the github instructions are just copy/pasting the default ssh-keygen instructions. They could improve by showing /home/you/.ssh/id_rsa_github or similar.
@FaheemMitha I never ever have empty passphrases on keys (SSH or any other type). For SSH, I use ssh-agent. I find it slightly odd that one is even allowed to use empty passphrases (or at least that ssh-keygen lets you know it's possible).
A key with no passphrase is reliant upon nobody else being able to get at that key (who wouldn’t be able to get at the resources it gives access to anyway). So, if the key grants access to a machine next to it, and both machines have the same level of electronic and physical security, then it’s n...
If you're already on a safe enough system, it should make little difference, but if not it could make all the difference in the world.
@FaheemMitha Yes. Part of the actual key is a hardware token stored on a USB dongle, and you would have to touch a plate on the USB device to acknowledge that you are actually there.
@FaheemMitha You could, but now everyone knows that you might have the same password for to things.
@StephenKitt I just don't understand how anyone can write code on that thing. The AZERTY vs QWERTY is fine, but needing two fingers for most basic programming symbols is a pain.
@StephenKitt Yes, -L is almost equivalent to -v in that they negate the result. In this case, the whole file is treated as only one element, so, yes, in this case both work. Thanks.
@Isaac the whole file is treated as only one element only if it doesn’t contain any null bytes
@FaheemMitha the first time you want to push the branch, git push <remote> <branch>, replacing <remote> with the name of the remote, and <branch> with the name of the branch
@JeffSchaller -z, --null-data Treat input and output data as sequences of lines, each terminated by a zero byte (the ASCII NUL character) instead of a newline.
@Isaac right, that's what I refreshed my memory from. You're -r recursively searching, so no incoming filenames, and you give a pattern on the command-line, so I was confused about why you needed -z
@JeffSchaller No Jeff, I do not need the output to be zero delimited, But I could ask for it if interfacing to xargs or something else. I am trying to simplify the answer to this question: unix.stackexchange.com/questions/578956/…
@JeffSchaller Which incoming filenames? The whole find command that calls two grep for each file to then provide an output similar to ls migh be replaced by onlygrep -EirzL 'chmod|archive' or rather: ls -l $(grep -EirzL 'chmod|archive') if you nitpick that we need an output like ls. Of course, more care needs to be taken with files that might include newlines or spaces. But that is outside a chat discussion IMhO.
@JeffSchaller That is a valid point, but find does recurse by default, so it is more similar to grep -r. But yes, to find files on "this directory", the -r is not needed.
@JeffSchaller The -z switch is for internal file \0 not related to an output or input of a list of files. It divides a text file on \0, which a normal unix text file will not contain, thus, the whole file contents will be treated as a single line.
@StephenKitt Then the whole command is not working, the requirement is to find files that contain both chmod and archive. Back to the drawing board ....
To gh:fmitha/nsepy.git
! [rejected] readme -> readme (non-fast-forward)
error: failed to push some refs to 'git@gh:fmitha/nsepy.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
faheem@orwell:/usr/local/src/nsepy/nsepy$ git push --force-with-lease origin
fatal: The current branch readme has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin readme
Not following the logic here. What information does it need that it does not already have?
I'm trying to control myself from pointing out how much better Mercurial is at this, but with Mercurial, you just do a push. If it's an anonymous branch, it tries to stop you from pushing. And I think a named branch needs a specific --new-branch flag. Other than that, it's automatic.
@StephenKitt Good night.
@StephenKitt Yes, I know. So what? What else could I possibly mean by that?
@FaheemMitha I switched over from CVS to Git in 2014 and was extremely frustrated for about a year before Git started to feel as natural as CVS had done before that.
I would have said exactly the same thing as you just did, but with Mercurial replaced by CVS.
There's no information about your new branch in the remote repository. You're talking to that repository, and it doesn't know about your branch. It needs to know how to attach it.
Perhaps it is expecting me to do something different remotely than locally, but I don't;see why. Or why it can't just assume the obvious, default configuration/relationship.
I'm trying to run `sudo ubuntu-drivers autoinstall` but that returns:
The following packages have unmet dependencies: nvidia-driver-440 : Depends: nvidia-dkms-440 (= 440.64.00-0ubuntu1) Depends: nvidia-kernel-source-440 (= 440.64.00-0ubuntu1) but it is not going to be installed Depends: nvidia-compute-utils-440 (= 440.64.00-0ubuntu1) but it is not going to be installed Depends: nvidia-utils-440 (= 440.64.00-0ubuntu1) but it is not going to be installed Depends: xserver-xorg-video-nvidia-440 (= 440.64.00-0ubuntu1) but it is not going to be installed
I've read about 1000 SO threads with similar errors but haven't been able to get my ubuntu-drivers autoinstall command to work
If anyone here could offer some advice I'd be super grateful
@duhaime The package you are trying to install `ubuntu-drivers` requires additional packages (unmet dependencies). Some of the aditional packages **can not** be installed. Probably because they **don't exist** in the repository you are using.
@duhaime Debuging this kind of problem is usually complex. It depends on which ubuntu version yo have installed, which repositories you have used, and which packages you have manually installed in the past. One first step would be to know which version of Ubuntu you are using and what version of libnvidia-compute-440:i386 you have installed.
