[conspire] Thank you

Mon Jul 25 19:52:34 PDT 2011

Rick,

I am basically a linux desktop user. I do however always look for the 
deb package first! I usually pass when there isn't one and either wait 
for it to be added in the future or find an equivalent program to do the 
job.

Repsnapper is an exception. As noted on the software's page, there are no
packages for any distros and you need to compile. There really aren't any
equivalent programs that don't have a problem that rules them out for the 
use I am going to put it to.

3D printers are non-standard enough that when the people who make the kit
and specifically the circuit board to drive it recommend a specific program 
because they have had problems with the others, I follow their recommendation.

I hope to have some time to work on the printer this week and hopefully get a bit
further along with the build and commissioning. With repsnapper installed, I am now
a bit closer as I can now-check out and adjust the electronics.

I am also evaluating 3D CAD and 3D modeling software. Another can of worms opened.

Thanks, once again.

Ross

On Jul 25, 2011, at 2:30 PM, Rick Moen wrote:

> Quoting Ross Bernheim (rossbernheim at speakeasy.net):
> 
>> I want to thank Christian and Rick for helping me get repsnapper 
>> to compile and run under Mint.
> 
> When Ross called me over, he was trying to work through the Readme.txt
> file provided inside the RepSnapper source tarball.  (RepSnapper is
> controller software for the RepRap 3D printer.)
> 
> It turns out that the build (compilation) instructions in the Readme.txt
> are somewhat halfassed and incomplete.  A brief search turned up the
> full instructions online:
> https://github.com/timschmidt/repsnapper/blob/master/doc/manual.asciidoc
> 
> So, there were some tools and libs Ross needed for compiling RepSnapper,
> and I'll detail that, but first a few words about a more important
> matter, software sourcing.
> 
> It happens all the time:  You hear about a piece of software that might
> be handy, and a quick check suggests it wasn't installed as part of your
> Linux distribution's default (or whatever) installation.  You Web-search
> its name, and find the developer site where you can download a .tar.gz
> ('tarball') source code archive.  Or perhaps you see instructions for
> equivalently checking out the package's source code from CVS, or svn, or
> git.
> 
> It's natural to charge right ahead and compile the software from source
> code in accordance with the developer's instructions.  However, that's
> exactly when you should take a break and rethink the matter.
> 
> Many people are unaware of the benefits they typically enjoy from using
> already packaged, compile, software from their distributions' package
> maintainers, who in the jargon are called 'downstream' software
> sources, where the developers are deemed 'upstream'.  The package
> maintainer does (or should do) quality control for you, for starters.
> It's the maintainer's job to ensure that distro users don't get
> halfbaked betas.  The package maintainer also takes on the job of
> vetting that the upstream source code he/she adopts for packaging is
> genuine, i.e., gpg-signed by the upstream developer's real key, thus 
> protecting you against forgeries inserted on compromised hosting sites.
> The latter is a real concern:  See
> http://linuxmafia.com/~rick/faq/index.php?page=virus, several paragraphs
> starting with the words 'Three objections', where I detail seven
> examples of that happening at upstream ftp sites.  In all cases, no
> distro maintainers were fooled.
> 
> Also, the fact that the distro-packaged versions are _maintained_ means
> you will get updates through distro maintenance channels.  If you
> compile from source, updates happen only if/when you remember to update
> manually.  Also, it's regrettable that your distro package tools won't
> know that the locally compiled software is even there, so you can't get
> the benefit of automatic dependency management, let alone remove
> software with a single package command.
> 
> So, in short, locally compiling packages from source tarballs should be
> avoided if there's any sign of a reasonable alternative.
> 
> Ross and I took a break from the compiling to look around for such an
> alternative.  
> 
> Ross runs Linux Mint's main (GNOME) edition, which is Ubuntu with some
> extra stuff.  Ubuntu uses Debian-style .deb packages.  So, obvious
> searches to find .deb packages compatible with Ubuntu were:
> 
>   repsnapper ubuntu
> 
>   repsnapper deb
> 
> In Mint itself, Ross could search the available distro packages by
> doing:
> 
>   sudo apt-cache search repsnapper
> 
> That does a full-text search of Mint's local database on available
> packages.  _Or_, Ross can use Mint's online package search engine:
> http://packages.linuxmint.com/
> 
> (Note:  'sudo apt-file search repsnapper' would match against only
> _filenames_ in available packages; 'sudo apt-cache search repsnapper' 
> searches package name, filenames and the long description of packages.)
> 
> Ross had basically already done that, so the _best_ type of packages 
> (maintained distro packages) had already been ruled out.  Web-searching
> for 'repsnapper deb' and 'repsnapper ubuntu' allowed essentially ruling
> out the second-best option, a third-party .deb repository of repsnapper
> packages compatible with Ubuntu/Mint.  No such luck.
> 
> The third-best alternative would be a locally compiled package done
> Debian-style, producing a binary .deb at the end of compilation.  We
> checked in the repsnapper tarball to see if there were a 'debian/'
> subdirectory with a 'rules' file in it.  No luck.
> 
> Given a debian/rules subtree, compiling a deb is trivial.  Here's one of
> many write-ups about how:
> http://carlo17.home.xs4all.nl/howto/debian.html
> 
> The fourth-best option is a plain ol' non-Debianised compilation and
> installation into /usr/local/ , which is what we did.  Tools exist to
> write a debian/rules tree for you, notably Joey Hess's novice-friendly
> debhelper tool.  However, we were in a hurry and didn't bother.
> 
> 
> 
> About the stuff that Ross's system was missing that needed to be
> retrofitted before we could compile repsnapper:  It wasn't exactly
> surprising, but Linux Mint includes roughly none of the tools needed to
> compile software, because it's targeted at the Ubuntu crowd of desktop
> users, who are assumed to be not interested.
> 
> Before we found
> https://github.com/timschmidt/repsnapper/blob/master/doc/manual.asciidoc
> , the real build instructions, and while still assuming that Readme.txt 
> was all we had, I had just followed Readme.txt's first two steps:
> 
>  ./autogen.sh
>  make
> 
> Each time 'make' (the compile step) failed on a missing dependency, I
> just Web-searched its name and installed the related Mint / Ubuntu 
> package via 'aptitude install [packagename]'.  I think that got us
> through build-essential automake intltool libtool .  The compile finally
> worked, and then we realised that Readme.txt lacked some obvious steps,
> and so looked around and found the other, real instructions.
> 
> 
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
> 