3.3.0 & 3.3.1.tar.gz not compressed?

[Steve]

I don't believe they're compressed.

When I downloaded the files I was surprised they both were ~3.2MB

I used tar xvf weewx-X.Y.Z.tar.gz rather than tar xvfz weewx-X.Y.Z.tar.gz 

Regards,

Steve

[vince]

Does it matter ?

Regardless - I see a 968KB compressed file there currently FWIW
Downloading via a browser under Windows - same size.

[Liz]

It does matter for those who follow recipes to get things to work with
Linux. If it is not compressed you need an alternate recipe.
That's why Steve gave those full instructions.

Liz

[vince]

On Wednesday, December 9, 2015 at 11:27:23 AM UTC-8, Liz wrote:

It does matter for those who follow recipes to get things to work with
Linux. If it is not compressed you need an alternate recipe.
That's why Steve gave those full instructions.

Really ?   I thought he was (erroneously)  claiming the files aren't compressed in the distribution directory.  They are.

I'm hoping this group doesn't become linux-101-teach-me-the-command-line.  There are thousands of places to learn that stuff.

That said, yes if you're running a command-line you need to learn the command-line.  Sure.   But you also need to know that there are 'many' different ways a file can be compressed meaning different ways you uncompress it.  Yes it is the 'z' switch sometimes.  Not always.  Depends on how it's compressed.

Typically a file that ends in .tar.gz or .tgz means you want to add the 'z' flag to your tar command, but that's just a filename convention not a requirement. You can check the file itself with the 'file' command to know for sure and adjust your tar command accordingly.  'man tar' is your friend there. http://linux.die.net/man/1/tar as one reference showing three different compression algorithms folks use.

[Andrew Milner]

Just to add to the 'confusion' when I downloaded 3.3.1 using windows 10 and Edge the resulting file was .tar.tar - after moving it to the pi I renamed it to .tar.gz - but had to name it back again to .tar.tar in order for tar to be able to handle the unpacking (with the zxvf flags).  I just did not have the energy to investigate further as it had already taken me until now to bite the cherry and upgrade from 2.7 - but something did not seem right with the file!!!

[Steve]

Bah, I was only trying to help in case someone followed the upgrade instructions to the letter and they didn't work. Wouldn't want them to face the wrath of vince by asking why the instructions won't work. :).

FWIW I just downloaded it from here http://www.weewx.com/downloads/ again, using windows and it's 3.2MB not 968kB.

[Steve]

The command line I pasted was a copy and paste from the weewx upgrade page. >> http://www.weewx.com/docs/upgrading.htm

[vince]

On Wednesday, December 9, 2015 at 12:37:41 PM UTC-8, Andrew Milner wrote:

Just to add to the 'confusion' when I downloaded 3.3.1 using windows 10 and Edge the resulting file was .tar.tar - after moving it to the pi I renamed it to .tar.gz - but had to name it back again to .tar.tar in order for tar to be able to handle the unpacking (with the zxvf flags).  I just did not have the energy to investigate further as it had already taken me until now to bite the cherry and upgrade from 2.7 - but something did not seem right with the file!!!

mmmm...the old .tar.tar thing - yup I've seen that before....

All you non-linux people trying to do linux things on other operating systems are just going to cause pain for yourselves with these workarounds and crutches.  Really. 

wget http://www.weewx.com/downloads/weewx-3.3.1.tar.gz -O /tmp/weewx.tgz
cd /tmp
tar zxvf /tmp/weewx.tgz
cd weewx-3.3.1
# (and follow the normal setup build/install procedure)

Or if you want to get slick and totally genericize out the version identifier....

wget http://www.weewx.com/downloads/weewx-3.3.1.tar.gz -O /tmp/weewx.tgz
mkdir /tmp/weewx-sources
tar zxvf /tmp/weewx.tgz -C /tmp/weewx-sources --strip-components=1
cd /tmp/weewx-source
# (and follow the normal setup build/install procedure)

Bottom line - strange and mysterious/frustrating things happen a lot on other operating systems depending on which os and tool you used to grab the file.  Easier to just ssh into your linux box and do it natively for 100% predictable behavior.

[Thomas Keffer]

I'm a little lost here. The file is definitely compressed, and definitely a little under a megabyte big. From an SSH session:

$ ls -lh

total 4.4M

-rw----r-- 1 tomkeffer inetuser  58K Dec  6 17:01 README.txt

drwx---r-x 2 tomkeffer inetuser 4.0K Dec  6 17:07 development_versions

drwx---r-x 2 tomkeffer inetuser 8.0K Dec  6 17:08 previous_versions

-rw----r-- 1 tomkeffer inetuser 1.4M Dec  6 17:02 weewx-3.3.1-1.rhel.noarch.rpm

-rw----r-- 1 tomkeffer inetuser 1.1M Dec  6 17:00 weewx-3.3.1-1.suse.noarch.rpm

-rw----r-- 1 tomkeffer inetuser 969K Dec  6 15:58 weewx-3.3.1.tar.gz

-rw----r-- 1 tomkeffer inetuser 964K Dec  6 17:02 weewx_3.3.1-1_all.deb

I'm certainly willing to clarify the upgrade guide, but I'm not seeing the problem. Is it if you download into a windows box it quietly uncompresses?

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vince]

On Wednesday, December 9, 2015 at 12:45:37 PM UTC-8, Steve wrote:

Bah, I was only trying to help in case someone followed the upgrade instructions to the letter and they didn't work. Wouldn't want them to face the wrath of vince by asking why the instructions won't work. :).

FWIW I just downloaded it from here http://www.weewx.com/downloads/ again, using windows and it's 3.2MB not 968kB.

sigh - you might try with a good problem description so we know if you're trying to help others in the same boat (Liz's note) or reporting a perceived problem, or reporting the instructions didn't work for you (your clarification).  We can't read minds.

I suspect you used a browser and it is 'helping' you and not telling you.

• I got a 968KB download today with Windows7 Pro and Firefox 42.0 on it by clicking on the same link.
  
• Doing the same thing on the same windows box with Chrome 47.0.2526.80 'did' seem to uncompress it without telling me.   Browser hell.

A good problem description lets us know what you did, what platform/apps you used, what versions of each you used, what you expected vs. what you saw, and what problem(s) you're trying to report, if any, so we can try to duplicate the issue and hopefully help.

There's no wrath.  I took time out of my busy day to try to help.  Sorry.  I'll let you thrash moving forward.  Not a problem.


 

[vince]

On Wednesday, December 9, 2015 at 12:49:51 PM UTC-8, Steve wrote:

The command line I pasted was a copy and paste from the weewx upgrade page. >> http://www.weewx.com/docs/upgrading.htm

I'm not seeing it.   I see the command to 'extract' the files, not any command for how to 'download' the file.  How did you download the .tar.gz file ?
 

[Steve]

I don't know what's changed. Perhaps it's a Windows 10 thing if you guys are seeing it compressed. I think that's the only thing that has changed on my end since I upgraded to 3.2.0

There are a total of 7 old weewx upgrade files on my RPi, for all of them I've simply downloaded the file to my Windows machine, used WinSCP to copy it to the RPi then SSH in using PuTTY and upgraded as per the setup.py instructions, except for 3.3.0 & 3.3.1 they appear on my Windows machine (and then the RPi when copied) as 3.2MB files while all the rest are under 1MB.

[Steve]

It's a browser thing.

W10 and Chrome keeps the file name but must uncompress the file as it is 3.2MB 

W10 and Internet Explorer (and Microsoft Edge) renames the file to weewx-3.3.1.tar.tar and it is 969kB

Vinces wget instructions done on the RPi via an SSH session works as expected.

[Neville Davis]

I am no expert but I ran into this problem a long time ago, my fix was to right click the file and "save as" to the desk top, this was the only way I could ensure my system would not "help me".
Mac OS X

Nev

[Liz]

a very interesting observation - one of those conditions where everyone
is correct and yet not everyone is correct.

Liz

[vince]

On Thursday, December 10, 2015 at 11:32:06 AM UTC-8, Liz wrote:

a very interesting observation - one of those conditions where everyone
is correct and yet not everyone is correct.

again if we can get a quality problem description initially, we can get to a quality answer quicker:

•  - I did this
• - on this platform, using this browser (or whatever)
  
•  - I saw this as a result
  
•  - but I expected that
•  - hey guys, is there a bug in the software, or docs, or my computer ?

A (later) description saying "I followed the doc" does not help usually.  Which precise doc, which section, which commands 'in' that doc did you run.

In this particular case, it was assumed by the user that he could take a downloaded-through-some-unspecified-procedure file and run the extract/install steps from the user guide against that file successfully.  Bad assumption..... I think we established pretty conclusively that the docs make some assumptions that your download method is assumed to not have uncompressed or renamed the file that you were trying to download.  The misfeature we found is some browsers mess with the file contents, other browsers mess with the name.   That's just the way browsers aren't standard in behavior.

If the problem description had been "I used chrome-x.x.x.x on windows-y.y.y.y and left-clicked on the link and clicked 'ok' to save it to a file, yet it didn't save the file unaltered" then we would have gotten to the solution in about one or two answers max.

Blindly following a doc like a script without enough thinking on the part of the person who hits 'return' on the keyboard only works if the doc specifies 'every' step exactly.  There are dozens of ways to download the .tar.gz file from an upstream site, no doc could specify every method and the resulting nuances as a script.  User thought and expertise is always required.

Gary's nice new diagnostic utility in 3.3.x will help us quantify the state of the weewx system once it's installed, but we will always need clear/unambiguous/concise descriptions of the perceived problem that have enough data for us to try to figure out where the issue is, and if there's a problem or just user error involved.

Again, best practices for how to report a problem are nothing new.   Here's an old one that's pretty good - see http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

 - if you're busy just scroll to the bottom and read the two last bulleted lists there.....

[Bram Baert]

So

I had the exact same problem two days ago that I had to drop the z option for the tar command to work.

I did it with the weewx 3.3.0 on an Rpi (debian jessie).

Personally I didn't really found it a problem but it would be nice to have the correct command in the manual.

I also downloaded it with chrome on win7 and had no problems extracting it with 7zip

Regards

[vince]

On Thursday, December 10, 2015 at 12:37:44 PM UTC-8, Bram Baert wrote:

Personally I didn't really found it a problem but it would be nice to have the correct command in the manual.

Unfortunately there is no universally correct answer.  It depends on how you downloaded the file and what that method did to the file (its name, whether it was compressed, whatever).  You need 'some' expertise.

I'd suggest if users can't figure this issue out, they shouldn't be using the .tar.gz method, which assumes more Linux expertise than using the pre-packaged .deb  or .rpm distributions of weewx.

[Thomas Keffer]

Personally, I never use the "z" option. The command 'tar' is smart enough to figure it out on its own, at least on the systems I use (Debian, OS X). 

I don't know how general this is. How about other OSs?

-tk

[vince]

On Thursday, December 10, 2015 at 4:54:19 PM UTC-8, Tom Keffer wrote:

Personally, I never use the "z" option. The command 'tar' is smart enough to figure it out on its own, at least on the systems I use (Debian, OS X). 

I don't know how general this is. How about other OSs?

I never rely on that.... but a quick test says:

• OS/X - yes - smart enough to not need -z for foo.tar.gz or foo.tgz 
  
• Debian ARM - yes
  
• CentOS-6 - yes
• Raspbian - yes
  
• Windows cygwin - no (.tgz) and no (.tar.gz)
• Windows msysgit - no (.tgz) or yes (.tar.gz)

So it's not guaranteed FWIW - probably depends on which version of tar you have too.