i am using a yum repository on fury.io.
Due to a mistakenly infinite loop I've gotten now 37000 versions of a package in my repository.
Deleting it from settings is removing 5-20 versions each time.
But its kinda obvious i wont succeed this way.
Any idea about this one?
Their support insists the deletion is continuing in the background.
Well, I don't see any progress after hours.
Related
On my Windows 10 machine it's 3.5GG. What is it storing? How can I trim it down?
It is storing all the downloaded crates you have used, their binaries, the index of registries, etc. It is going to take a lot of space and will keep increasing.
You can safely remove .cargo/registry/ (if you remove the entire folder, you will lose installed binaries and your Cargo configuration if you had one). Afterwards, everything you use again will be downloaded and it will start growing back. It is a common way of getting rid of very old dependencies you are not using anymore.
I am creating a simple linux kernel with buildroot and I am adding a small driver I've done myself, I created the Config.in file and drivername.mk to be able to select the driver in make menuconfig succesfully.
When executing make to build the image, the compilation goes correctly until my driver starts to compile, it looks to compile and create the image right but I get loooots of warnings saying that different files in ./lib/gcc/arm-buildroot-linux-uclibcgnueabihf/ are touched by more than one package: [u'host-gcc-initial', u'host-gcc-final'].
Anyone can explain me a bit about this issue and what is causing it? Do you need any more info to know what is happening? Is it safe to ignore them?
Thanks beforehand
Actually, doing a search on 'touched by more than one package', I found http://lists.busybox.net/pipermail/buildroot/2017-October/205602.html, where we find that this warning can safely be ignored if you're not doing a parallel build and aren't a kernel maintainer.
That said, if you're submitting code for inclusion in the Linux kernel, please be a good citizen and make sure you identify all of the things your code is dependent upon. (I'm not actually an active kernel hacker, so I don't know what method they're using for this right now.)
The basic idea is that there are a bunch of steps in compiling things that need to be done in a logical order. In a small project, we simply use dependencies that we know to put in because we also coded in that dependency. But with a project the size of the kernel, you can guarantee that not everyone does this. Some of them instead just specify dependencies if they're needed for things to build properly - if the default order works, things could go years before someone figures out that there was a missing dependency, causing them grief when they were trying to update just the one thing that was a missing dependency, and the other code not getting updated as a result.
When you're doing things in parallel, on the other hand, it becomes a lot more complicated. Now you really need to have every dependency specified, because there is no longer any inherent dependable order. Some people will probably still build serially, while others use two processing threads. I'll use 8. I've worked in groups that would be inclined to do 30, because they're on a 32 processor machine, and don't really need all of those during the off hours. Suddenly the fact that the file you needed from a directory that normally got processed 30 directories before yours is now getting processed at the same time as your file that needed it, because you didn't list the dependency and everything in those 30 directories that hasn't already been processed and isn't being processed has a dependency that's not yet finished its processing.
These two folders take up significant space on my hard disk
%USER_HOME%/.gradle
%USER_HOME%/.AndroidStudio3.1
Can they be safely deleted? If not, what subfolders can I safely delete?
Well, it's "safe" in that it won't blow up your computer. But the .gradle folder is a dependency cache - every library your app needs is going to need to be stored there in order for you to actually build / test / run your code. It's to be expected that it'll take up a lot of space. You might get some mileage out of deleting it and re-downloading the dependencies, especially if there are a lot of old dependencies in there that you're not using it, but by virtue of your work it's going to get re-created and start filling back up again.
The Android Studio folder is a bit similar - it's not a dependency cache in that lots of different things aren't going to get installed there, but it's still necessary for you to actually build your code. If you delete it you're just going to have to reinstall things there to get your code to work.
So what are my options if an update to the next major version fails due to database migrations not working? (Parts of the migrations already seem in place?
The problem is that backups all contain that column and I'm not even sure when this problem started. I have done a few backup recoveries a couple of months ago all seemed well at the time, but now I'm pretty sure something went wrong there.
I can think of;
1 going in manually into postgres to delete columns. And try to update then. (how?). Might be that there are other migrations problems further down the line.
2 exporting individual projects, reset to factory settings and reimport all projects. This would depend on the export format (if it's a sql dump I would end up in the same situation)
3 hoping an expert read this and helps me out :-)
Because this ticket hasn't gained any attention https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3156 I'm now trying my luck here. For now it seems I'm stuck at gitlab/gitlab-ce:10.3.6.
I have never had to address this problem (Thankfully!) but in the GitLab docs, they do have a section in their Updating GitLab area about recovering from a failed or partial upgrade. (They seem to indicate that this may happen after you restore from back-up, so that matches with your statement that you have done several backup recoveries).
https://docs.gitlab.com/ee/update/restore_after_failure.html
They say you may have to go through this several times (for different migration steps) before you get yourself back to a point where the migration you want rolls forward successfully.
Based on the log you posted in their issue tracker, I see it failed on migration 20171106171453, so your command to get over the first hurdle probably looks like this (Note different commands depending on Source or Omnibus install):
(Source Install)
sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20171106171453] RAILS_ENV=production
(Omnibus Install)
sudo gitlab-rake gitlab:db:mark_migration_complete[20171106171453]
Again, I have never done this before, so I would take a fresh back-up before trying (because that has worked so well in the prior instances, right?!), and read their doc and warnings thoroughly before attempting.
Good Luck!
I am having a big problem with meteor. Build process "meteor run" is extremely slow it takes about 10 minutes but that is not the bad part since it only happens once when starting.
The bad part is that it takes ~2 minutes to show my changes, file changed watcher taking too long.
When working with a basic example the feedback was way better ~5 seconds and it was workable but now that I am working on a real project it is impossible to make any progress.
I have around 40 packages in packages file and I am using latest meteor (1.3.2.4 at this time).
There were a ton of questions around this problem #4284 #6750, I don't know if there is any tip to bypass this issue ( changing any config,adding more RAM or anything ).
It there is no solution of that it would be helpful if there is a way to limit file watch to only a certain folder at a moment.
Update: I noticed there is ".node_modules" in the root of app can it be excluded from build process?
Thank you guys!
Try Webpack for Meteor.
It supports hot module reload, which can shorten rebuild times a lot. There are some differences compared to the default build process, so you'll need to learn a thing or two about it, but it could be well worth your time.
Try it by fetching kickstart-meteor-react-flowrouter from GitHub.