This weekend, I decided it was time that I checked on port updates in my
/compat/i386 FreeBSD 'system'. Which primarily exists to provide me some ports that don't build on 64-bit, namely emulators/wine-devel and net/nxserver. Don't recall the last time I used nx since I got it working, probably should check to see whether it is still working or not (probably okay on my home system, but might be broke on work one....and might see about setting it up on other work computer too).
Hmmm, hadn't updated ports since May 5th. Start with working through
/usr/ports/UPDATING, run into a problem that on 20130609: AFFECTS: users of audio/flac and any port that depends on it, in that there it thinks perl depends on it (kind of an annoyance I have with dependencies....there can be miles of separation between one port and another port, but everything get's marked as depending on that very bottom port, when it in fact didn't or doesn't... Was annoying in trying to figure out why a port was marked BROKEN / DEPRECATED and not get any attention except that people should stop using it...when 100's of ports on my system depend on it. When it turns out that its one or two ports, had an option set that caused it to depend on it. While the other ports generally don't care what options are enabled in that port, just that the command exists for it...or other reason. Though there are some ports that do care about what options were used, which I had ranted about earlier...and I ran into Thunderbird also having that dependency, resulting in this kluge patch:
But, I let the
portmaster -r flac run aways, with the suspicion that it would break later because perl modules that depend on perl (and not flac) wouldn't get picked up as needed to be re-installed or upgraded, due to 20130612: AFFECTS: users of lang/perl* and any port that depends on it. But, would break the re-install or upgrade of a port somewhere and abort. Which is what I found when I checked on it this morning.
So, I did a
portmaster -R -r perl, and noticed that it seemed to include most of the ports that the previous
portmaster hadn't done. In fact it included all of them. I also peeked in
/usr/local/lib/perl5/site_perl/5.14.2 to see what perl modules had gotten missed....mainly the p5-XML-* ones that caused the previous
portmaster to abort.
Though I probably should've looked to see if the second
portmaster was going to address those, instead of doing them while it was asking to proceed. Because that caused it to abort when re-installing those perl modules (that I had done while it was waiting), but restarting it got things done.
That leaves the latest entry 20130627: AFFECTS: users of ports-mgmt/portmaster, which is just informational and not currently applicable.
Before running in to the flac entry, there had been "20130527: AFFECTS: users of lang/ruby18" which was pretty straight forward, since it only exists as a dependency to
ports-mgmt/portupgrade, which I seldom use now...but I have other scripts that use binaries that come as part of it (namely
portsclean), which I could probably replace with the
portmaster way or something else. But, its not really a priority, plus who knows if I won't decide to go back to using
portupgrade...which has options in its
pkgtools.conf that I haven't found equivalents for with
portmaster, though isn't currently an issue right now. Except perhaps that I'm holding back on updating to the latest
emulators/virtualbox-ose, since I've gotten warnings from various sources to stay away from it.
The other big one is what's the
portmaster equivalent to
Will eventually run into a port that has a line one of these:
Where I'm using
Somehow expected there would be more than 12 ports wanting either client or server... probably missing the occurrences in multiline RUN_DEPENDS or some other way to specify the depend. Since pkg_info says there are 103 ports that depend on the client, and two ports that depend on the server (neither being
mail/roundcube, which are the ports that I'm running on 'zen' using the mysql server. On cbox, there are 73 ports that depend on it, some are obviously true...like
net-mgmt/cacti-spine, but nothing is depending on the server...though it is obviously being used by cacti. I left dbox with the default
databases/mysql55-client...there are 71 ports depending on it.
Meanwhile I have postgres server running on zen, which was a depend of something else that I had since removed....but I haven't stopped or removed postgres yet....
In fact after dealing with ruby, flac and perl....the only ports left to update are:
dialog4ports-0.1.3 < needs updating (index has 0.1.5_1)
freeglut-2.8.0 < needs updating (index has 2.8.1)
portmaster-3.16 < needs updating (index has 3.17)
Might be time to see what else I can get working under wine.
Wonder when I had last updated ports in the
/compat/i386 on my system at work? And, do I want to tackle that from home, on a Sunday instead of other important tasks/projects....
But first...lets see what port got updated since yesterday....
Odd, I seemed to have missed updating to
lang/ruby18 on cbox and dbox....
For some reason I had cd'd into
/usr/local/lib/perl5 on dbox and noticed that 5.16.2 was still present...well 5.12.4 was still on zen after I the upgrade to 5.14.2... and it just had
whatis files. But, I went and looked inside, and found more than just
'pkg_info -W', I found that I had other ports that had installed perl modules that didn't start with 'p5-' or depend on
So, off to rebuild those ports.
On dbox/cbox it was just
print/pdflib...plus some stray files left by already updated ports or removed ports. But, on zen there was a much bigger list of ports:
japanese/p5-Jcode (which was missed, because the package name is
Hmmm, probably need to update my i386 space, which is going to be wrong now...because uses the name
make.conf of 'global', and I haven't updated it in a long time.... Not since May 4th.
emulators/wine-devel has been updated since then, so I guess I'll have to tackle it sooner than later.... Especially, since I'm thinking of making another attempt to see if I can get other apps running in
wine versus VirtualBox....
So being up ridiculously early this morning, because I got up at the right time during the night...but forgot to take my second dose, and too late to take it when I woke again.
So, I thought I would tackle updating to the latest perl on zen. Choose not to just do a blind
'portmaster -r perl', since that would include anything that depends on being able to run perl or depends on something that depends on perl...possibly many levels down. Somebody should come up with a simple way to only rebuild the ports that directly depend on another port....
What I decided to do what after updating perl, was
'portmaster p5-*' then do a pkg_libchk to see what ports are missing libperl.so and redo those.
I did this first by logging into my machine at work (mew) and it went quickly and worked pretty cleanly. Though there are only half the number p5- ports, and less ports missing libperl.so as well.
So, back on zen...I updated perl and then started the
'portmaster p5-*', when it stopped. A port is dependent on /usr/local/bin/perl5.14.2, which is not found because I just updated to 5.14.4!
How do you have ports that are dependent on a specific version, especially since its possible to have a different version of perl. When I first installed zen, the default perl was 5.12.x...but I had elected to upgrade to 5.14.x when that became the new default. OTOH, when I setup cbox/dbox, I opted to go with 5.16.x...and at work, mew had started before zen, so it was also 5.12.x initially...but I choose to jump that up to 5.16.x (actually no .x at first, but it was very quickly followed by a .1...which inflicted a lot of pain again....though in this latest update they have switched to just major.minor for module path, which means no more pain until its time to upgrade to a newer minor release....
The first casualty was
devel/p5-B-Keywords ...and I find its depended on by
textproc/p5-Test-Perl-Critic....with the last port being the leaf. So that seems to be that it was probably just a build depend for something I had installed long ago (since it doesn't sound like anything I could call in any of my own perl scripts.) So, I figure I'll just delete those packages and carry on.
Nope, the next port also fails with the same strange demand.
After hunting around a bit, to try and figure out what is making this port think it depends on the previous version of perl...it dawns on me that the perl port updates
/etc/make.conf as to what version of perl is installed.
And, I have
being managed by cfengine3.
So, I go update the file, and try to svn commit the change....which blows up because the perl modules needed for the commit hook haven't been updated yet.
Well, guess I'll stop cfengine3 from reverting my
/etc/make.conf (by disabling the promise from the root side) Though IIRC now, the commit hook is mainly to prevent root from doing commits into my subversion repository, instead of the put subversion on an NFS filesystem and have rootsquash prevent root from being able to write into the repository, that we do at work.
Phew....I can commit updated
/etc/make.conf and let cfengine promise it. Perhaps in a future project, I'll see if there's some way to have cfengine set that dynamically or something.
Though should I have cfengine promising all of
/etc/make.conf ? There's a block in
/etc/make.conf that is the same across all my FreeBSD systems, since its the ports that I come across that don't like
'make -j#'. And, it was intended to have cfengine promise that part, though it there have been other additions that I want the same on all my FreeBSD systems, like the override on modules in net-snmp, that I mention when I ran into some cacti. Though there's value in having cfengine having the whole file....or rather its that the files are in subversion.
Next up...nagios has alerted me that spamassassin has stopped, yeah, I guess that would happen. Which means there's going to be a big chunk of spam in all my mailboxes (126...I need to find a good way to aggregate them back so that I can read them all ... from roundcube) module rebuilds are done, and spamassassin seems to be running again (probably because cfengine3 has a promise to keep for that) Though might work better if I do an 'sa-compile' to make sure that part is right...though seemed to me it was only major.minor....
It was a dark and stormy...late afternoon...yesterday, and....
I had started out almost 7 years ago with a Siemens 4100 DSL Modem, which worked the way I needed it to for my home network. And, wasn't sure how easy it would be to find another like it. I was running it in the cross between router and bridge mode...so that my router could maintain my dyndns info (though it wasn't too long after that I moved that to ddclient on box, which has been more reliable...but I was having ddclient scrape from the router, though the ddclient for the router on my Cox connection wasn't supported so that uses checkip.dyndns.org. So, now both do.
Would probably be too much work to make ddclient go out on the right IP so that ip route will send it to the DSL router, so it can query the DSL modem for what the real external IP is. Though the new cbox/dbox setup would simplify things....but the migration has stalled as I've been working on getting cacti moved from box...and it hasn't been going well. Lots of old templates and such don't work on the new, so I've been reworking what I feel I can't live without....
That includes the graphs of my DSL modem stats....
Anyways....when the Siemens 4100 started dropping the connection a lot (around the 3 year mark) and changing the filter didn't help, I had heard that these things wear out... So, I tracked down a new Siemens 4100 on eBay...and switched to that....and that got things working again.... Then a couple years ago, things go bad consistently....though I could see from my cacti graphs that SNR drops in the evening. Though I wasn't able to get local service to restore/fix things. I tried the AT&T forum on dslreports.com, and they changed me to Interleaved, which helped....
But, I had started shopping around for a new DSL modem.... somewhere in my journey's I acquired a Zoom ADSL X3 5760 Modem. But, since things were working...I put it aside as my spare for when things stop. Seems I've had it so long that its no longer available....got it July 9, 2012 according to Amazon.com
For a while now, it would drop the connection now and then during the week (between its weekly self-reboot)...at first I suspected the router, since its twin had gone away in much the same way several months earlier. Though the router do also have failsafe configured, so if it can't talk (ping) to box or the WAN gateway...it reboots. Though at some point AT&T made their gateways unpingable. So, it was pinging google.
But, on April 6 it got really bad....my IRC connection was resetting practically constantly. Though since I had swapped the router before, and swapped it again. Though maybe now I wonder if its watchdog was too aggressive. Things were usable, but the line drops would be annoying. Also the IP staying the same through drops didn't make me question the DSL modem.
But, then on April 13, things start getting really bad....and I was getting 50+ messages a day from ddclient that my IP changed. It seemed to stablize a bit on Monday....though it was still dropping regular enough that I switched to using Cox for my IRC screen session. Was going to defer to the weekend to make the swap.
Well, yesterday the weather was bad...lots of lightning, rain....and I first display I looked at when I got home said "NO INTERNET". Though it was probably a temporary outage, because it did appear to eventually come back while I was working on unboxing my 'new' DSL modem. And, try to figure out how to set it up without the Windows wizard it provides or the lack of documentation with it...there was a small CD, which didn't really provide much depth....but I found what IP it would be and that it has web interface....it also has a telnet interface and an FTP interface.
Anyways...it turned out to be pretty straight forward getting it working...the hard part was figuring out what the non-default options meant, and whether I would want them.... the main one I turned on was "fullcone NAT". And, I set my router in with a reserved IP and made it DMZ host, so I can keep all my forwards there...plus the Zoom is limited to 16, which isn't enough .... though this may change when I make use of its DMZ feature as well (doing reverse proxy on cbox/dbox to everywhere else on my home network...running firewall on these boxes already, to implement policy based routing.) And, enabling ICMP on the WAN interface (its also possible to enable http, ftp and telnet on the WAN interface as well.)
Getting it working in Cacti again, turned out to be much harder.
Pages: 1· 2
Latest Poopli Updaters -- http://lkc.me/poop
|<< <||> >>|
ebay tivo zen progressive «powersource 400» «tivo hd» «windows xp» cox orac «air purifier» boinc usb «instant streaming» wifi tardis «watch instantly» raid1 «hd movie» lhaven freebsd twitter prescription «tivo premiere» dvd «sans digital» ubuntu «chicago tardis» «windows 7» appletv raid cpap 10.04lts backuppc upgrade dsl ups netflix «amazon prime» amazon.com replaytv box virtualbox linux «doctor who» mdadm b2evolution cfengine3 eyeglasses tv woot