Solving conflicts between print/texlive-base and devel/tex-kpathsea

The 20141214 entry in ports/head/UPDATING says:

20141214:
AFFECTS: users of TeXLive
AUTHOR: hrs@FreeBSD.org

Several scripts in print/texlive-base have been moved to devel/tex-kpathsea. Upgrading them can fail because texlive-base depends on tex-kpathsea, and the new ex-kpathsea tries to install files which were installed by the old texlive-base. The following error message indicates this situation:

pkg-static: tex-kpathsea-6.2.0_1 conflicts with texlive-base-20140525_3 (installs files into the same place). Problematic file: /usr/local/bin/kpsewhere

To solve this problem, remove both of tex-kpathsea and texlive-base first and install the new versions:

# pkg delete -f tex-kpathsea texlive-base

The above is a bit drastic, at least for us who build our own ports. These two portupgrade commands gets the job done, albeit with some overhead:

portupgrade -fprv print/texlive-base
portupgrade -fprv print/tex-kpathsea

gettext 0.19.3 in FreeBSD

devel/gettext, as of version 0.19.3, has been split into three ports:

  1. devel/gettext, the meta-port depending the two next ports;
  2. devel/gettext-runtime, the runtime libraries; and
  3. devel/gettext-tools, the tools for managing the message catalogs.

In my case, as I build my own ports, making the transition required manual intervention using both portupgrade and the ports collection tree:

portupgrade -fpvo devel/gettext-runtime gettext
cd /usr/ports/devel/gettext-tools && make && make install && make package && make clean
cd /usr/ports/devel/gettext && make && make install && make package && make clean
portupgrade -fprvx gettext -x gettext-runtime -x gettext-tools devel/gettext-runtime

AutoCAD 2015 woes

If AutoCAD 2015 refuse to install, try to uninstall Microsoft Visual C++ 2012 Redistributable, both 32-bit and 64-bit, and try to reinstall AutoCAD 2015. In one instance was it necessary to uncheck Autodesk ReCap. I really wish there was a simple way to mark only the essential parts necessary for the creation of simple drawings.

If AutoCAD 2015 refuse to run, go through this checklist:

  1. Check, and if necessary, change the computer name; Autodesk’s products expects only latin letters.
  2. Remove any traces of previously or currently installed McAfee products. See my blog entry from November 12th.
  3. Try setting HardwareEnabled in HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R20.0\ACAD-E001:409\3DGS Configuration\Certification to 0 (zero).
  4. Try setting LoadAppInit_DLLs in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows to 0 (zero).
  5. Try setting AppInit_DLLs in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows to a blank string.

Fluke Networks LinkRunner AT Reports in print does not indicate genuine IPv6 tests, the column is always set to False

At work we received a Fluke Networks LinkRunner AT 2000 network analyzer this week. The report generator in the Fluke Networks LinkRunner AT Manager v1.0.9.8 contains a minor flaw. IPv6 tests performed are never marked as such in print.

I created a “Support incident”, and hopefully Fluke will acknowledge the fault, correct it, and issue a new version of their LinkRunner AT Manager. Continue reading

McAfee Consumer Product Removal tool

Sometimes McAfee products causes more grief than joy. For some mysterious reason, some, if not all, McAfee products interfer with the handling of VBScript as they register their own .dll file for handling VBScript.

Not all attempts at manually correcting the Windows Registry prove successful.

In most cases McAfee Consumer Product Removal tool are able to remove the last traces of the McAfee products previously or currently installed, enabling Autodesk software to complete their activation ritual.

I’m also pointer fingers at Autodesk for chosing an activation scheme based on Internet Explorer technology, VBScript, and, JScript, where a simpler approach would more than suffice.

PC|SCHEMATIC Automation og gjenopprettingsfiler

Av og til kan man lure på om programmerere noen gang gjør fullstendig testing av programmene sine. PC|SCHEMATIC Automation trenger en real gjennomgang.

Blir ikke PC|SCHEMATIC Automation avsluttet skikkelig, så blir *.$pr-filer liggende i katalogen til programmet. Dette blir oppdaget neste gang PC|SCHEMATIC Automation starter opp, og da starter en evigvarende runddans mellom å velge enten «Åbn» eller «Slet» (programmet er dansk), og så motta en melding om at programmet ikke finner gjenopprettingsfila eller hva nå enn programmet egentlig prøvde å få til. Dette er enda et nydelig eksempel på mangelfulle feilmeldinger.

Det enkleste er å drepe PC|SCHEMATIC Automation gjennom Oppgavebehandling, og deretter gå på jakt etter *.$pr-filer i programkatalogen. Slett de filene som du finner, og etterpå bør PC|SCHEMATIC Automation virke skikkelig til neste gang.

Det er også lurt å lagre egne filer langt unna PROJEKT-katalogen til PC|SCHEMATIC Automation. Det har aldri lønnet seg å blande brukerdata med programmer.

VirtualBox 4.3.18 and AHCI

Update 2014-11-30

Upgrading to Oracle VirtualBox 4.3.20 removed the timeout messages shown below.

The bug was acknowledged in the change log as

Storage: fixed an interrupt acknowledge issue causing hanging guests or slower I/O (4.3.18
regression)


Since upgrading Oracle VirtualBox from 4.3.16 to 4.3.18 on my Windows 7 x64 host, most of my FreeBSD guests from time to time shows kernel messages like the ones below.

ahcich2: Timeout on slot 7 port 0
ahcich2: is 00000008 cs 00000000 ss 00000000 rs 00000080 tfd 50 serr 00000000 cmd 1000c717
(ada2:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 62 d4 9c 40 00 00 00 00 00 00
(ada2:ahcich2:0:0:0): CAM status: Command timeout
(ada2:ahcich2:0:0:0): Retrying command

It doesn’t matter if your FreeBSD guests run version 4.3.16 or version 4.3.18 of the emulators/virtualbox-ose-additions port.

Someone else reported similar kernel messages on physical servers, making me believe some recent changes in FreeBSD can be blamed. Or, maybe this is just a coincidence, despite the similarities.

Yet another technical oriented blog, more or less