​http://consumerist.com/5032351/demystify-car-repair-prices-with-repairpalcom

​http://www.eserviceinfo.com/

​http://technet.microsoft.com/en-us/magazine/cc162321.aspx

"elevate" acts as sudo

So I spent about three hours trying to get my perl svn_compress script running and I ran kept running into the damned thing segfaulting!

svn_path_basename: Assertion `is_canonical (path, len)' failed.

I finally found the answer. Apparently, libsvn wants '' as the current directory, not '.' like every other program since the beginning of time (Jan 1, 1970, right?).

Three hours.

​Where I read the answer. Pasted here:

Peter Samuelson wrote:
> [Julian Gilbey]
>> burnside:~/debian/tex/tetex-bin $ perl -MSVN::Client -e \
>>   'sub print_names { print "<$_[0]>\n"; } $ctx=new SVN::Client;
>>   $ctx->status("", "BASE", \&print_names, 1, 1, 0, 1);' | head -5
>> <>
>> <.pc>
>> <.pc/.version>
>> <configure>
>> <INSTALL.generic>
> 
> I reproduced your bugs with subversion 1.3.0-5, so I can properly
> discuss it with upstream.  Unfortunately, I don't know much about the
> Perl bindings.  But comparing "svn status" with your command, it does
> seem to correspond to the "." entry.  I wonder if that is even
> considered a bug.  I mean, if you prefix each entry with $(pwd)/, it is
> fine.
> 
> 
>> perl: /tmp/buildd/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:377:
>> svn_path_basename: Assertion `is_canonical (path, len)' failed.
> 
> Right, that's definitely a bug.  Even if this isn't something the perl
> bindings can fix on their own, they should carp or something.

Hi. This is an issue that gets kicked around on dev at svn from time to
time, and usually ends up with the thread fizzling out sooner or later,
with no concrete action being taken, due to a lack of an obvious right
way to proceed. I'll sum up the situation...

There exist a number of path manipulation functions (svn_path_*) which
do not conform to the usual style returning an error status as the
return value, and output data via output pointer parameters. Instead
they return data directly as the return value, and are supposed to only
ever be able to experience errors that merit assert() or abort().

Subversion defines a 'canonical path' format, and most of the functions
(apart from the canonicalizer itself, obviously!) assert that the input
path looks like a canonical path.


Various groups of C programmers will conduct heated debates on whether
this is good programming practice, or an annoyance, but that is
irrelevant where the bindings are concerned, since assert()-ing out of a
scripting language interpreter is clearly bad.

There is a fairly obvious, though non-trivial, solution:
Make the bindings test all input paths (presumably using a path-specific
SWIG "in" typemap) using the same logic as is_canonical, and
canonicalize if necessary. The problem, though, is that discussions of
this nature tend to get intertwined with the parallel issue of whether
the C code is being generally unhelpful in this situation, and should be
changed too.


OK, now you know the background.

Feel free to prod dev at svn to raise awareness of this problem which has
sadly lain dormant for far too long.


Max.

Aside:
The canonical form (IIRC) is mostly common sense stuff:
* no repeated slashes
* no internal /../ sequences
* no trailing slash
BUT it has one weird rule:
* the canonical form of "." is ""

This is what happens when you are at work and you have ISOs for the 6 CDs of CentOS 5.2 but NOT the DVD, and no connection to the 'net… I couldn't use the 5.2 installer thanks to ​this bug (it's an embedded Celeron 650). Since I went thru all the work, I also then imported the directory as a "shared folder" under VMWare player and then did the same upgrade path on that machine (I want it to mirror the embedded machine for all versions of everything, except it also has the gcc suite, etc).

One Time Only

(This can be done on any Linux machine with the external drive connected)

• I mounted the external drive under Linux and there are the 6 ISO CDs. I mounted each and then upgraded what was on it that we already had installed.
• cd /media/ext_drive/<install dir>
• mkdir mnt
• mount -o ro,loop <CDFILE>.iso mnt
• cp -urv mnt/CentOS .
  • If I were doing this again, I may mount the 6 as /mnt1 thru /mnt6 and then try to use cp -l to make links?
  • (Optionally in another window to watch progress: watch -d 'lsof -c cp -s | cut -c37- | grep rpm ' )
• umount mnt
• (Repeat for all 6 - this gives us a CentOS subdir with all the RPMs. If I had the DVD instead of the 6 CDs, this would've been easier)
• Now we will make this new directory into an "official" repository
• cd CentOS
• rpm -i createrepo*rpm (glad that was there!)
• mkdir repo_cache
• createrepo -v -p -d -c repo_cache --update --skip-stat .
  • This step takes forever (even longer than the copying above)
  • With a DVD image, this is most likely not even needed!

Every Target Machine

• We need to disable all the remote repositories:
  • Edit /etc/yum.repos.d/CentOS-Base.repo and add enabled=0 to every section
  • Edit /etc/yum.repos.d/CentOS-Media.repo and change to enabled=1
    • Depending on where the external hard drive is, baseurl will need an added path to it
      • When I did it, it was file:///media/ext_drive/LinuxInstallers/CentOS-5.2-i386-bin-1to6/CentOS/
    • There is a ​known bug in 5.1 - the GPG signature key should be RPM-GPG-KEY-CentOS-5 (not "beta")
• yum clean all
• yum install yum-protect-packages
• yum upgrade yum
• yum clean all
• yum upgrade --exclude=kernel\* -y | tee upgrade.log
  • (Optionally in another window to watch progress: watch -n1 'lsof -c yum -s | cut -c43- | grep rpm ' )
• grep warn upgrade.log
  • For this, you need to diff each file with the .rpmnew file or .rpmold file and merge them together.
• Reboot!