Re: [gentoo-user] Firefox, downloading files and odd behavior.
вс, 6 янв. 2019 г. в 02:54, Dale : > > gevisz wrote: > > вт, 1 янв. 2019 г. в 06:45, Dale : > >> With the newer Firefox versions, I've noticed something weird about > >> downloading files. Usually these are videos using a download helper for > >> videos and sometimes it is a normal file download, depends on the site. > >> Either way, I get something odd at times. So far, I've yet to see any > >> rhyme or reason to it. I can't figure out what triggers it. This is > >> what it does. I start a download, either using a video helper add on or > >> downloading as a file. I give it a name and location and it shows in > >> the download window that it is downloading. However, if I go to the > >> directory where it should be, sometimes nothing shows up. It will > >> complete the download and then show that it failed after finishing the > >> download. However, if I notice that it is not in the directory where it > >> should be and I go back to the download window, hit pause and then > >> resume, it starts over from the beginning and then shows up in the > >> directory where it should be. Most of the time, it shows up that it is > >> downloading and it is where it should be without be doing anything > >> further but sometimes, it doesn't. > >> > >> One other thing that it does on rare occasions. It will show it is > >> downloading for a good while, sometimes more than half way, then > >> disappear in the directory as if it is deleted but still show that it is > >> downloading in the download window. I've only seen it do that a few > >> times but it is annoying to look and make sure it is downloading a file > >> that takes a hour or more only to have it disappear part way through. > >> > >> This started with the new multi-process versions or whatever it is > >> called of Firefox. It acts like a permissions problem or something to > >> me. It either thinks it doesn't have write permissions at the start or > >> thinks it loses them part way through or something. If it only did this > >> when using the add on, I'd think it is that but it also does it when I'm > >> downloading as a file with no add on being used. Either way, I'm not > >> sure what to look into really. I'm not even sure what to google for to > >> see if anyone else is noticing this. What does one call this problem??? > >> > > I experience similar problems with downloading files in Firefox for quite > > a long time. I cannot say for how long time exactly, but estimating it > > from memory: for about a few years. Yes, t is quite annoying but > > currently I have already got the habit to open download manager > > every time I download a file, stop downloading it and then restart again. > > (I even try to do the same automatically while using other web browsers > > like chromium or google-chrome. :) > > > > However, I believe that it has nothing to do with "the newer Firefox > > versions" > > as I still use Firefox version 52.9.0 (compiled without clang) and all these > > troubles with downloading files started even on much more earlier versions. > > > > Interesting. I don't recall it ever doing this with the older versions > but maybe whatever it is is just now hitting me for some reason. That's > the thing about random problems, they are random. Still, at least I > know it is not just me. > > Since you mention chromium etc, that makes me wonder if it is the > browser at all. Could it be something else? A permissions issue > maybe? Some sort of file system problem? Could it be a common package > that these browsers depend on? Which leads to this question. Do you > use LVM or ext4 or both? I use LVM and ext4 here. Odds are, we both > have the same dependencies installed so not sure how to figure out if it > is one of those. I should clarify: I experience the said download problem only in Firefox, never with Chromium or Google-chrome. I have mentioned Chromium and Google-chrome only to indicate that my habit of opening download manager became so unconscious that I try to open download manager even in Chromium and Google-chrome, when it is not needed. Luckily, the hot keys for opening download manager in Firefox and Chromium/Google-chrome do not coincide, so I just end up opening something else and then realize that download manager is not needed. I never used LVM as I believe that it increases the chance of loosing all the information on hard disks. And yes, I do use ext4 as it is the default file system for Linux. P.S. Most often, I download html pages and have noticed that the said download problem does not arise when I download html pages in the so called "read" view, that is after pressing that little book icon in the Firefox URL address line, whereas downloading the same pages from a usual default view, with a lot of additional files, almost sure leads to the said download problem.
Re: [gentoo-user] Firefox, downloading files and odd behavior.
On Sunday, 6 January 2019 11:05:10 GMT gevisz wrote: > I never used LVM as I believe that it increases the chance of [losing] > all the information on hard disks. Interesting. Would you like to explain why? -- Regards, Peter.
[gentoo-user] How to trace down compilation issues if the compilation does not break...?
Hi, the usual event, if something comilation-related, is a list of all files, which could be examined to find the problem and a lot of styff put under /var/tmp/portage... I have a problem with the Krita-installation and I think it is a wrong way of configuration of the compilation problem. The problem with this problem is, that the compilation process is successful and all files will be removed from /var/tmp/portage afterwards. I checked the manpage of emerge to find an option to prevent the deletion of the remainders, but found nothing. Is there a way to keep these? Thanks a lot in advance for any help! Cheers! Meino
Re: [gentoo-user] How to trace down compilation issues if the compilation does not break...?
On Sun, Jan 6, 2019 at 10:31 AM wrote: > > The problem with this problem is, that the compilation process > is successful and all files will be removed from /var/tmp/portage > afterwards. > If you already have the dependencies installed all you have to do is chdir to the directory with the ebuild and run: ebuild krita-x.y.z.ebuild configure You can use compile/install to step through the compile and install steps. In general you can just go straight to install and end up with a complete build and install image, but it won't touch your actual root filesystem. Note that the ebuild tool is mainly intended for troubleshooting ebuilds and such - it does not resolve dependencies, so you need to take care of that before running it. If you need to start over just run the clean command. man ebuild... -- Rich
Re: [gentoo-user] Firefox, downloading files and odd behavior.
вс, 6 янв. 2019 г. в 15:57, Peter Humphrey : > > On Sunday, 6 January 2019 11:05:10 GMT gevisz wrote: > > > I never used LVM as I believe that it increases the chance of [losing] > > all the information on hard disks. > > Interesting. Would you like to explain why? I had once a 40GB HDD failure and I have managed to restore all the data on it by repeatedly putting it in a fridge what enabled me to dd its partions for about 10 minutes or so. But in that case the partitions were relatively small and the disk mounted quick and easy. Now imagine that have failed a 4TB HDD disk that is part of much bigger LVM volume. Moreover, suppose that it is impossible to restore that part of the failed HDD disk that indexes all that LVM volume...
Re: [gentoo-user] Firefox, downloading files and odd behavior.
On Sunday, 6 January 2019 17:07:35 GMT gevisz wrote: > вс, 6 янв. 2019 г. в 15:57, Peter Humphrey : > > On Sunday, 6 January 2019 11:05:10 GMT gevisz wrote: > > > I never used LVM as I believe that it increases the chance of [losing] > > > all the information on hard disks. > > > > Interesting. Would you like to explain why? > > I had once a 40GB HDD failure and I have managed to restore > all the data on it by repeatedly putting it in a fridge what enabled > me to dd its partions for about 10 minutes or so. But in that case > the partitions were relatively small and the disk mounted quick > and easy. Now imagine that have failed a 4TB HDD disk that is > part of much bigger LVM volume. Moreover, suppose that it is > impossible to restore that part of the failed HDD disk that indexes > all that LVM volume... There's also the probability of corruption of the LVM table on the disk. Arguably a small probability, but nevertheless one additional reference table for things to go wrong, should Murphy and his law have anything to do with it. I also prefer to keep disks with critical data as simple as possible, plan ahead of applying partitioning schemes for particular use case requirements and consequently I do not use LVM. On the other hand, there are use cases where LVM can be invaluable - ill defined or ever changing disk space requirements where over-provisioning of spare space can be expensive. So as with most things in life it is a balancing act. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Firefox, downloading files and odd behavior.
gevisz wrote: > вс, 6 янв. 2019 г. в 15:57, Peter Humphrey : >> On Sunday, 6 January 2019 11:05:10 GMT gevisz wrote: >> >>> I never used LVM as I believe that it increases the chance of [losing] >>> all the information on hard disks. >> Interesting. Would you like to explain why? > I had once a 40GB HDD failure and I have managed to restore > all the data on it by repeatedly putting it in a fridge what enabled > me to dd its partions for about 10 minutes or so. But in that case > the partitions were relatively small and the disk mounted quick > and easy. Now imagine that have failed a 4TB HDD disk that is > part of much bigger LVM volume. Moreover, suppose that it is > impossible to restore that part of the failed HDD disk that indexes > all that LVM volume... > > The thing to remember tho, the drive failed. That is why you had the problem. That isn't the fault of LVM. That is a defective drive. From what I've read, you can have a drive fail, remove that drive and lose the data from it but keep what is on other drives. If you have all your files on a single drive with no LVM and that drives fails suddenly, what is different? The important part, monitoring your drives and at the first sign of problems, replace the drive. That is true whether you use LVM or not. Right? I might add, long before I started using LVM, I've had drives to fail and either had to backup real quick or lose data. While LVM can cause a problem, I suspect it is rare if managed properly. For me, and many others, it adds many benefits to managing data. Just recently, my home partition was starting to fill up. It was made up of two 3TB drives. I replaced one of the 3TB drives with a 6TB drive. Because I use LVM, it was painless and easy. If I hadn't been using LVM, like in the past, it would have been much harder to do. I might add, I would have had to replace with larger drives, which also cost a good bit more. Even from my simple setup, LVM adds more benefits to managing data and drives than it does risk. The biggest thing, placing blame where it lies. Blaming LVM for a drive dying is placing the blame on something that wasn't the root of the problem. The dying drive was the problem, using LVM or not. Back to Firefox, I recently did a emerge -e world with no change. It still does it on occasion. So, it's not some weird quirk where something needs to be rebuilt after a upgrade. Still a annoying problem. Thinking on that firefox-bin package next. :/ Dale :-) :-)
[gentoo-user] Re: How to trace down compilation issues if the compilation does not break...?
On 06/01/2019 17:31, tu...@posteo.de wrote: The problem with this problem is, that the compilation process is successful and all files will be removed from /var/tmp/portage afterwards. I checked the manpage of emerge to find an option to prevent the deletion of the remainders, but found nothing. You can set FEATURES=keeptemp while emerging the package for which you want to keep the tmp files. In your case: sudo FEATURES=keeptemp emerge -1 media-gfx/krita
