Hi Richard, well, Doxygen is not the best example, because it's only needed to generate documentation at build-time. But consider this: when you set up your soon-to-be-airgapped computer, you install python 2.7.8-15a-spam including the matching development headers. You do the same on your on-line machine. After a month or so, you decide you might want to update the python installation on your on-line computer. You do that, it's now 2.7.9-vikings. Another month passes. You realize that "having the most recent version of GR on the air-gapped computer" might be desirable. So you use pybombs to update GNU Radio on your on-line PC. The problem now is that the version of python on your air-gapped computer (spam) doesn't match the one that the fresh GNU Radio was linked against. Since spam doesn't have the same symbols as vikings, things go wrong as soon as you try to call a python function from C++. That might lead to confusion and ruin [1]. The same mechanism applies to all libraries that GNU Radio or any of the things you build on your on-line PC. So you'd have to make absolutely sure that the libraries installed on your on-line PC match the versions on the air-gapped one.
Greetings, Marcus [1] https://youtu.be/anwy2MPT5RE?t=2m4s On 04/29/2015 09:13 PM, Richard Bell wrote: > Thanks for helping me through this Marcus, I appreciate it. > > Another words, if I installed Doxygen on my non-air gapped computer > and used this to make the target.tar.gz then the air gapped computer > must have Doxygen installed as well for the install to work? > > I'm running into a problem that might be related to this, in that when > I start grc on the air gapped computer after extracting the > target.tar.gz to it, it prints the welcome to gnu radio 3.7.8 message > but then barfs on the following error > > File > .../target/lib/python2.7/dist-packages/gnuradio/grc/base/odict.py", > line 34, in __getitem__ > return self.data[key] > KeyError: 'options' > > Do you know what problem this represents? > > For my understanding, please help me understand this: > As far as the prefix directory is concerned, in a normal pybombs > install where the prefix is a local user directory, you are saying > that the prefix directory is self contained and all that is needed for > a working GRC, assuming all dependencies are installed, is this > correct? The build process doesn't throw files into /usr/local > directories or share directories or any other central locations? > > > On Wed, Apr 29, 2015 at 11:50 AM, Marcus Müller > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: > > Well, if you installed into a prefix on the air gapped computer, > too, you'd just overwrite everything in there with the contents of > the archive. > You must make absolutely sure that you bring all distro packages > that are related in *any* way to the software you'll run to the > same version that you've got on your online PC. > > To be honest, this sounds like something you should ask the people > that decide that and how you air gap your computer. > I think the only practical way to have both an immediately > updateable and yet air-gapped PC is to keep your data as cleanly > archivable and restorable as possible, and script your set up > routines as far as possible. Whenever you need an update, you then > make a backup of your work, flatten the air-gapped PC, use your > scripts to set up the environment in an up-to-date state, and then > air-gap and restore your work. Everything else is just asking for > extra hours. > > Cheers, > Marcus > > > > On 04/29/2015 08:26 PM, Richard Bell wrote: >> Marcus, >> >> I'll try the second approach. I created the target.tar.gz from a >> computer (same OS) that is networked and fully updated. I have >> copied this over to the air gapped machine, but now what do I do? >> Just having the target folder isn't enough to update the install. >> How do I update from here? >> >> v/r, >> Rich >> >> On Wed, Apr 29, 2015 at 10:47 AM, Marcus Müller >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote: >> >> Hi Richard, >> >> 1) depends. Many of the things that pybombs does actually >> consist of calling your distro's package manager. So if you >> can do that with a DVD source, you're set (I remember this >> being relatively easy on debian, with a DVD actually being a >> remote just like debian's repo servers are); for the things >> you build from source: well, you can always just edit all >> recipes involved and change the URLs to something locally >> served, I guess :) >> 2) That's easier. Use "pybombs package", and you get a >> tar.gz of your prefix. again, this will only include things >> that are not installed by using your distro's package manager. >> >> Greetings, >> Marcus >> >> >> On 04/29/2015 07:27 PM, Richard Bell wrote: >>> I originally installed GNU Radio on this computer when it >>> was networked via pybombs. Since then, the computer has >>> become air gapped (no internet connection allowed). I need >>> to update the install to the latest versions of UHD and GNU >>> Radio. Two questions: >>> >>> 1) Is there a way that would allow me to use pybombs to >>> update from a dvd? If so, how would I create this dvd and >>> then point pybombs to it? >>> >>> 2) Should I forget the original pybombs install and start >>> over with a dvd containing all files needed to install the >>> latest version. If so, how do I make this dvd? >>> >>> v/r, >>> Rich >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
