When updating and upgrading pkgsrc and its packages using
sudo pkgin -y update
sudo pkgin -y full-upgrade
sudo pkgin -y autoremove
it suggested that some directories could be deleted:
downloading packages...
p5-Variable-Magic-0.62.tgz 100% 42KB 41.6KB/s 41.6KB/s 00:00
p5-Role-Tiny-2.000006.tgz
...
removing packages to be upgraded...
removing pkgin-0.9.4nb7...
===========================================================================
The following files are no longer being used by pkgin-0.9.4nb7,
and they can be removed if no other packages are using them:
/opt/pkg/etc/pkgin/repositories.conf
===========================================================================
===========================================================================
The following directories are no longer being used by pkgin-0.9.4nb7,
and they can be removed if no other packages are using them:
/opt/pkg/etc/pkgin
/var/db/pkgin
===========================================================================
removing p5-PerlMagick-7.0.7.8nb1...
removing jasper-2.0.12...
...
My question is that how does one determine if no other packages are using the directories suggested above so they can be deteled? Simply ignoring this step and deleting them does not seem safe.
Those messages are, for the most part, really just for the pedants who would worry and fuss over things that they no longer need and might get confused by, even when they don't cause any problems or get in the way of anything. (Such leftovers could possibly be of some concern if one was working on changing the package they were used by.)
In this particular case though the messages are actually misleading since they are about components used by pkgin itself and once pkgin upgrades itself they will in fact be in use again. One might even consider the appearance of those messages in this case to be a bug.
Related
The yarn.lock file saves all the dependencies versions and the hashes of the modules. I know that I can globally disable this hash checking with the option --skip-integrity-check.
We have an internal module that is continually developed. The dependency is really of a snapshot package. When it is updated, it fails in our continuous integration environment because the updated package hash is different of the yarn.lock saved hash.
Is it possible to disable the integrity check just for a specific module?
I'll accept the answer even if it tells how to disable the check for all the modules of a specific registry.
Update: My problem is that my continuous integration server job is breaking when the dependency is updated, even if there's no modification in my code. These are spurious failings and I want to stop them.
Update 2: The accepted solution is really a hack to solve a problem in a usual development workflow. There is an issue open for Yarn in GitHub to fix this problem.
Instead of running
yarn install
You should run it like below
yarn add <specificpackage>#^<versions> --update-checksums
yarn install
This will make sure that the yarn.lock is updated with latest hash for that package and then yarn install will install the rest of the packages with integrity check
Update-1: 20-April
Another possible options is to use the preinstall hook. There are few things you can try here. You can try updating the package. But be aware that launching the yarn command again in preinstall can cause infinite loops.
So better way may be to run a grep, awk or a sed command and get ride of the package entry in the yarn.lock file. This will make sure the yarn install command has no information on the hash and a mismatch can't occur
If you don't want to use awk, sed or grep because of windows compatibility then you should just write a simple nodejs script to get rid of the package from the yarn.lock file. This will cross-os compatible. Below code shows how to do the same
yarn_remove_hash.js
const fs = require('fs')
const content = fs.readFileSync("yarn.lock", "utf-8");
const packageToDelete = "yallist"
let lines = content.split("\n")
for (let [i, line] of Object.entries(lines)) {
if (line.startsWith(packageToDelete + "#")) {
lines[i]="";
let y = i;
while (lines[++y][0] ==" "){
lines[y]= ""
}
}
}
fs.writeFileSync("yarn.lock", lines.join("\n"))
And you will update your scripts section in package.json like below
...
"preinstall": "node yarn_remove_hash.js"
...
If you want to make #Tarun Lalwani's --update-checksums more of a transparent process for you and others, you can add the following to .yarnrc:
--install.update-checksums true
Now when a user runs yarn install it will also update checksums implicitly. This was needed for me because one of my dependencies is linked to a snapshot .tar.gz that changes and NPM/Yarn would assume that it wouldn't, obviously leading us to this integrity issue. I had to move away from NPM because of this and also tried the preinstall hook (I thought I was clever but I guess you guys did the same).
At least Yarn has an option around this. Tarun's updated answer did not work for me either because yarn.lock is checked against before any hooks are ran.
I have the same code, running the same highcharts-convert.js and phantomjs on two servers. One produces perfect charts images the other is missing all labels. Does anyone know why or where to start looking?
This is most likely missing font packages on the failing host. Highcharts-convert uses the fonts available to it, but will silently skip labels if there aren't any available. I had this happen and running
sudo yum install dejavu-fonts-common dejavu-sans-fonts dejavu-serif-fonts libXfont xorg-x11-fonts-Type1
fixed it. I don't yet know what subset of those packages would have been sufficient, but I suspect "libXfont xorg-x11-fonts-Type1" would do it.
This Homebrew Cookbook manual is helpful in giving some clues on how the homebrewsystem works. I have installed PhantomJS using brew install phantomjs, but I need to apply some patches. I can see that the formula already has a patch applied:
# Qt Yosemite build fix. Upstream commit/PR:
# https://qt.gitorious.org/qt/qtbase/commit/70e442
# https://github.com/ariya/phantomjs/pull/12934
patch do
url "https://raw.githubusercontent.com/Homebrew/patches/480b7142c4e2ae07de6028f672695eb927a34875/phantomjs/yosemite.patch"
sha256 "f54bd1592185f031552d3ad5c8809ff27e8f3be4f1c05c81b59bf7dbc4a59de1"
end
What is the 'correct' way to modify the source and rebuild? I suppose I could modify the source, repackage it using tar/gz, place it in the cache folder, and then change the checksum in the formula, but is that the right way to do it?
Add your patches like the one that’s already there:
patch do
url "https://where.your.patch/is"
sha256 "... its checksum ..."
end
patch do
url "https://another.patch.url"
sha256 "... its checksum ..."
end
Make sure it’s in the stable do block like the existing patch.
Then run brew install --build-from-source phantomjs. Once it’s installed, edit the formula to its original state or your next brew update will fail.
If you know what you’re doing you can avoid adding sha256s to each patch; Homebrew will warn you it can’t verify them but won’t abort the install.
I use emerge to check the status of ebuild, and I get this:
gentoo ~ # emerge -pv libvirt
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-emulation/libvirt-0.9.10-r4 USE="libvirtd lxc nls policykit python udev -avahi* -caps -debug -iscsi -lvm -macvtap -nfs -numa -openvz -parted -pcap -phyp -qemu -sasl* (-selinux) -uml -virt-network* -virtualbox* -xen" 0 kB
The USE label avahi*, virt-network*, sasl*, virt-network* virtualbox* , what does the '*' mean in these labels. Thanks. I think these packages are already installed . Right?
Just look at man page: http://linuxreviews.org/man/emerge/ Everything is explain there.
'R' stands for: rebuild (specific version of package is installed already)
'*' stands for: change from/to enabled state' - If use flags changed, portage will prompt you to rebuild packages because the use flags might have a significant impact on package functionality.
Compared to your currently installed libvirt, this new emerge will remove avahi module.
This might come from several possibilities :
Change in make.conf USE
Change in /etc/portage/package.use
Change of profile
Previously compiled libvirt with forced USE flags (i.e. USE="avahi" emerge libvirt)
I'm using rvmrc with the following text:
rvm_path=/local/rvm
(on Ubuntu 11.10) but trying to install gives an obscure error:
$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
Successfully checked out branch ''
Current branch master is up to date.
Successfully pulled (rebased) from origin
: No such file or directory
Any ideas?
You have no need at all to set $rvm_path. You're using a multi-user install. Please follow the explicit instructions for the Multi-User install at https://rvm.io and remove any existing installations, remove /etc/rvmrc, /etc/profile.d/rvm.sh, and $HOME/.rvmrc. Comment out any RVM sourcing lines in your .bash_profile, and .bashrc and log out of the machine then back in. Then reinstall correctly. Setting the rvm_path has never been a requirement of the installer UNLESS you already have a Multi-User working installation in place, and you want to attempt to use a per-user install with it. THEN you would preset the $rvm_path to $HOME/.rvm in your own $HOME/.rvmrc, log out then back in and then attempt the install again. BUT, that is not a supported installation type. Which is why 99.999% of users will not need to set rvm_path at all.
The real problem was that the git configuration for auto-converting line endings was not set correctly which prevented any installation from working. It had nothing to do with using rvmrc settings.
The fix for this is simple (and comes straight from the github help page):
$ git config --global core.autocrlf input
Line endings are important in linux and by forgetting that setting, everything the rvm-install script was pulling from github had \r\n endings. I made that change so long ago on my work machine, I didn't even remember it -- but it was not set on my home system.
I'll leave it up in case someone else has the same problem.