Tag Archives: ArchLinux

Install Viavdo 2016.2 on ArchLinux (x86_64)

As of the date of this post, Xilinx Vivado 2016.2 works fine on Arch with minimal coaxing. Said coaxing is documented here in case it will be useful for others.

1. Install ncurses5-compat-libs from AUR, or the installer will hang during a later step. It appears to be required at runtime as well.

2. Mark the installer executable, eg. chmod +x Xilinx_Vivado_SDK_2016.2_0605_1_Lin64.bin, and run it with the confirm flag, ./Xilinx_Vivado_SDK_2016.2_0605_1_Lin64.bin --confirm

3. Hit Y at the “unpack” prompt, then go into the directory it creates at /tmp/selfgz[RANDOMSTRING], and edit xsetup to replace `uname -i` with `uname -m`, which is what they should have used in the first place.

4. Pre-create and permission the install path, a reasonable choice is the default /opt/Xilinx, which needs to be writable by the user doing the install (eg. chgrp users /opt/Xilinx, chmod g+w /opt/Xilinx)

5. Return to the terminal and hit Y to continue until the GUI installer runs.

6. Follow the GUI installer instructions, Feed the prompt your Xilinx credentials, Select Vivado HL WebPACK, etc.

7. The activation prompt at the end of the installation procedure is misleading, in the 2016.x versions if you simply quit without activating, the install automatically goes into WebPACK mode. If you don’t have/need any of the non-WebPACK features, activating the 30-day free trial of the nonfree version is asking for a headache when it expires.

8. It works. (and as a bonus convenience over the old toolchain, at least the Digilent Basys 3 boards use a normal FTDI usb-serial as their onboard programmer, so you don’t have to fight with drivers to program boards, that just works too.)

Posted in Computers, General, School | Tagged , | Leave a comment

Clevo P650SE/NP8651

P650SET510Flat_web

My 5-year-old T510 has been showing its age, mostly by falling apart (speakers died, parts held on with gaffers tape, occasional probably-thermal GPU lockups, etc.) and I decided it was time for a replacement. Unfortunately, the laptop market right now has absolutely nothing appealing (clickpads everywhere!) so I gave up and bought a closest-match Clevo P650SE chassis that I could kit out myself. There are a couple annoyances, but overall it’s a nice machine. Really long detail notes including a bunch of Linux tweaking below.

Continue reading

Posted in Computers, Electronics, General, Objects | Tagged , , | 5 Comments

chdk-ptp PKGBUILD

In another episode of fixing things for the Cameras as Computing Systems class I’m taking, I made a PKGBUILD that apparently correctly builds and installs chdk-ptp on Archlinux systems. Chdk-ptp is a tethered-control application for Canon cameras running CHDK, that hooks a variety of custom extensions to the ptp protocol. Their build system is a little lackluster, is missing things like an install rule, and requires a helper script be installed to do some path munging before running the binary, but the documentation is good enough to sort it out, and the program itself seems to work. My package depends on iup-all-bin from the AUR which also provides the cd dependency (not marked in its provides array, though there isn’t an official package to conflict with). I tried to use the built-from-source AUR packages for cd (Seriously, who thought that was a good name for a piece of software?) and iup, but iup was giving me a hassle and the chdk-ptp documentation suggests the binary distribution will be less trouble anyway.

The PKGBUILD format has changed a bit since I was last making my own- I like most of the changes in terms of clarity and modularity, but it does require a bit of re-learning. It also means I have a couple of pet packages that probably need attention.

The build is a little janky so despite it passing through namcap with only one expected warning, I don’t want to put it in the AUR until I’ve tested it enough to be reasonably sure it works as intended. I expect I will get around to that eventually.

Posted in Computers, DIY, Electronics, General, Objects, School | Tagged , , , , , , | Leave a comment

Linux 3!


I just ran my first major-version-number Linux kernel upgrade, and nothing caught fire. The “no fire” is mostly thanks to the Arch maintainers, who held it until a clean upgrade path and driver compatibility was established, so props to them.

Posted in Computers, General | Tagged , | Leave a comment

Package Manager Security

(The following is long, rather technical, and somewhat esoteric. Sorry, it’s what I do.)
I try to keep reasonably abreast of developments in Arch Linux, since it has been my favorite distribution for about seven years now, and the OS on my primary-use computer for five of them. Someone (almost entirely a single very loud someone as it turns out) has been making noise about package signing in pacman, the package manger used by and written for Arch, and said noise propagated up to an article on LWN, so I took some time out tonight to read up on the matter.

The short version is that the description of events on pacman developer Dan McGee’s blog seems to be essentially correct, and the “Arrogant and dismissive” accusations were the result of someone new showing up and making long-winded demands on the mailing list in regard to a topic which has been under (occasionally contentious) discussion for years. The Arch community can certainly be a little blunt, but it has never struck me as unfriendly or inappropriately autocratic (there is quite a bit of the “Those people actually doing things get to decide how they are done” mentality: as far as I am concerned this is exactly right for community projects).

The two primary things I learned in reading are that package manager security is indeed a hard problem, and that most of the possible attacks would be extremely difficult to carry out, regardless of package signing. The typical least concern matter of security: if production machines anywhere that matters are having their DNS (& etc.) spoofed on the required scale, there is a much bigger problem than trying to slip compromised packages into systems during updates. I’ve also discovered that generally, people don’t seem to care: for example, as best I can make out, gentoo has had discussions on package/repository signing since 2002, support since 2004… and it isn’t generally used today. The Arch Wiki has a nifty article about how various distributions handle package security in the context of designing a system for Arch – it is somewhat incomplete, but the only comparison of existing systems I found. Note that the page was started and largely populated in July of 2009.

One thing I don’t quite understand is why there isn’t a movement toward, at least optionally, performing updates over secured connections: simply using ssl (which has it’s own problems) for mirror-to-mirror and user-to-mirror communication would (aside from making the CPU load involved in running a mirror much higher and considerably slowing update downloads…) convey many of the befits of signed packages/repositories with less hassle. More importantly, it would close many of the holes in package management systems which do support signing for those individuals and organizations with sufficiently critical systems and/or paranoid administrators to be willing to swallow the overhead.

With all that in mind, I find myself agreeing with the pacman developer’s ambivalence on the issue – a security scheme for pacman is not so much a “critical feature” as a”nice to have”, largely for future proofing. Likewise, a broken scheme, or one so obtrusive it goes unused is probably worse than none at all. The obtrusive issue is honestly probably the most important to me – one of my favorite things about pacman is that the makepkg process is incredibly easy. I can often go from a source tarball or CMS checkout to a easily handled package as fast as I can (safely) build and install by hand. Contrast this with, say, Debian, where packaging and installing even simple software is often a painful multi-hour affair even with things like debhelper, and simple packages tend to (in my experience) do unhelpful things like fail to uninstall cleanly. I want making my own packages, and building or modifying packages with scripts written by others to remain easy and transparent much more than I want to be protected from improbable attacks.

Forcing the issue (it looks like security features will appear in the next few pacman release cycles as a result of the noise, mostly handled by existing developers) was probably not the right thing – the security scheme should have been done slowly, carefully, and correctly by someone who is actually interested in the matter – the last point both so that it really is done right, and because Arch and Pacman are community maintained projects, where everything should be done by someone who cares, as Linus himself puts it, just for fun.

Posted in Computers, DIY | Tagged , , | Leave a comment