aur - git encryption (arch)

So far, it appears affected: standardnotes-desktop.

I don't know if this will happen again, but could be helpful. Apparently, git recently changed to an authenticated SSL (encrypted) connection. AUR actions which attempt to use an unencrypted git download fail with the following.

The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
==> ERROR: Failure while downloading desktop git repo

One of the reported fixes is to simply change http to https, however this is not possible within AUR actions performed by yay -- yay will make the call to git, without any option for the user to change the URL.

solution

As time goes on, AUR package builders will write calls to "https" instead of "http". For the time being, it's a difficult problem.

wine -- can we do this better?

Wine works but has been useless to me since its creation. Each app requires a custom installation -- that's fine -- but when we start the actual app with the "wine" command preceeding the EXE file, Wine "updates"(overwrites) the custom settings, and one receives the same suboptimal performance as if customization hadn't been accomplished in the first place. Because it's been entirely eliminated. It's essentially a repeat of the old problem we used to have with Python when running "pip" instead of a package manager. But Wine doesn't ask first.

Summary of iRoot steps

See backstory below for the steps regarding this USB connected device.

1. Download PC version from website.
2. Enter the ~/.wine and delete all files
3. Prepare Wine and .NET using winetricks

   $ mkdir .wine/Win7
   $ WINEARCH=win32 WINEPREFIX=/home/$USER/.wine/Win7 winetricks dotnet452 vcrun2010 corefonts wininet

4. Unzip the downloaded installation file somewhere, eg ~/.wine/Win7install.exe
5. Install the iRoot program using wine.

   $ WINEPREFIX=/home/$USER/.wine/Win7 wine explorer /desktop=somename,720x480 "/home/$USER/.wine/Win7/iRoot_1.8.9.21144_cid1005.exe"

6. Connect the tablet via USB and be sure screenlock is off, and data transfer enabled.
7. Run the program, using wine. You could make an iDesk icon or menu entry with same info.

   $ WINEPREFIX=/home/$USER/.wine/Win7 wine explorer /desktop=somename,720x480 "/home/$USER/.wine/Win7/iRoot/1.8.9.21144/Root.exe"

Summary of audio editor steps

1. $ mkdir .wine/Win7/audio
2. $ cp audio.exe .wine/Win7/audio/audio.exe

3. $ WINEPREFIX=/home/$USER/.wine/Win7 wine explorer "/home/$USER/.wine/Win7/audio/audio.exe"

backstory

For me, there are four applications with operating system complexity inside Linux use: Linux itself, LaTeX, Wine, and Blender. Plus perhaps the only slightly lesser issues of ALSA audio and CUPS printing. This time it was Wine, due to the need for two Windows PC apps, one for audio editing, another (iRoot) for rooting a cheap tablet. The former was straightforward, but the tablet rooting app was apparently developed using the .NET framework, and requires a USB connection to the tablet. As is well known, even in Windows proper, .NET dependent USB connections are horrible. Then add Wine complexity. The plan was to work through the errors to get a good Wine installation, then do the same thing for a good application installation.

part 1 :: wine (12+ hrs)

Strategy: follow someone else. Bracing for turbulence and a lost weekend, I downloaded the iRoot PC app and began Googling. The closest I could find was the Garmin Nüvi PC application for updating maps. It is .NET framework dependent, with a USB connection. Chris Titus has a helpful video (11:45) and a helpful web page on the Garmin. I followed his steps, only with the iRoot app, but wasn't successful. It's important to be specific about failures, the USB device was detected but then...
... and the tablet did not appear in the iRoot app, in spite of being detected beneath the hood.

directory structure

Unless two applications can run on the same version of Windows, each application requires a separate installation of windows. I put them in folders as seen here.

That is, although I keep wine and winetricks in the system, I completely eliminate all their files inside of /home/foot/.wine/. I then add directories for each version of Windows required. Based on my iRoot application, and Chris Titus' stuff above, I knew I wanted to work it into Windows 7.

$ mkdir .wine/Win7
$ WINEARCH=win32 WINEPREFIX=/home/$USER/.wine/Win7 winetricks dotnet452 vcrun2010 corefonts

installation errors

During the .NET (dotnet452) portion of the installation, several files are downloaded from Microsoft. A status box (left) also appears, and displays the error that I lack "Windows Modules Installer Service" (C:\Windows\servicing\TrustedInstaller.exe). I sought this executable afterward, but could not locate it. Based on the terminal, it appears the lack of this file prevented a certain level of software use.

0060:fixme:service:QueryServiceConfig2W Level 6 not implemented

I hoped to perhaps remedy this via the cleanup tool, once the Win7 was in, the next step.

$ WINEARCH=win32 WINEPREFIX="/home/$USER/.wine/Win7" winetricks win7

registry cleanup

This doesn't have to be run, but I was curious about it. With Windows 7 in, I placed the cleanup tool just inside the Windows 7 installation, in /home/foo/.wine/win7/drive_c/. It should look like this:

I had read about the (.NET framework cleanup tool) and wanted this operating. Cleanup would also have to be placed in any other installed folders -- XP, 10, whatever -- in which a person wanted to check their .NET install. The prefix is the OS folder, and then I gave it a 720x480 desktop to run inside, in case the Cleaner requires one.

$ WINEPREFIX="/home/$USER/.wine/win7" wine explorer /desktop=cleaner,720x480 "/home/foo/.wine/win7/drive_c/cleanup_tool.exe"

As it ran, the Cleaner, among many thousands of errors it revealed, noted the lack of level 6 implementation. Here are some of the error notifications...

Level 6 is not implemented.
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\Components key is not present.
No product/patch data was found.

part 2 :: application (12+ hrs)

First run indicated some missing pieces from my installation

0054:err:wininet:open_http_connection create_netconn failed: 12029

... it appeared the program needed to dial home. So, I added the missing wininet.

$ WINEARCH=win32 WINEPREFIX="/home/$USER/.wine/Win7" winetricks wininet

Here's more of the garbled mess that popped up. The program itself indicated a bug.

dead ends

A collection of various things I tried and which were apparently irrelevant.

lack of Windows Module Installer Service

During .Net (aka. "dotnet452") installation, if the installer is unable to find the Windows Module Installer Service,then it provides an error window. There is a noticeable effect downstream from this.

For example, error messages will appear if one attempts to attach a USB device via USB. This is because Level 6 of the .Net installation was not met. The USB device will successfully be detected, but the device will not be able to send file information or be written to. The complaints will take a form similar to...

0060:fixme:service:QueryServiceConfig2W Level 6 not implemented

The situation has been encountered by others, for example as documented here.

linux library checks - AUR

One of my dead ends was checking the Linux libraries. Mine turned out to be fine, but I read of them being a problem for others and having similar problems. Eg, a Battlenet article noted some missing Linux libraries had led to fails. The only one I thought might be mine was hal, so I checked for it...

$ ldconfig -p | grep hal

... returning nothing. Hal is in the AUR,so it has to be built.I'd want the 32 bit version. My luck, yaourt is no longer functioning.

$ yaourt -Ss hal
package-query: error while loading shared libraries: libalpm.so.11: cannot open shared object file: No such file or directory
$ ldconfig -p | grep alpm
libalpm.so.12 (libc6,x86-64) => /usr/lib/libalpm.so.12
libalpm.so (libc6,x86-64) => /usr/lib/libalpm.so

... so it's annoying as heck. Time to move to yay, I suppose; yaourt getting just too unmaintained -- I'm not going to create softlinks to libraries and such. Buh-bye...

yay build

# nano /etc/sudoers
foo ALL=(ALL) ALL

... otherwise the build will fail. Then...

$ cd Downloads
$ git clone https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg -si

[solved] Epson V30 (04b8:0131) v. V370 (04b8:0141a)

nb: 2022 - subbed "yay" for all "yaourt"

short version

Neither scanner will be detected in $ scanimage -L unless correct driver is used. Typically the V30 works well with only the driver, whereas the V370 needs the driver and may also need "epowka" adjustments described further down this page. Neither scanner requires CUPS.

V30 (04b8:0131) - $ yay -S iscan-plugin-gt-f720

V370 (04b8:014a) - $ yay -S iscan-plugin-perfection-v370

If still no proper V370 detection, check the "epowka" and "hpaio" notes further down. I've never been able to configure a box for both scanners so I could hook up either. I remove the driver for the scanner not being used.

---

prevention

• check the connection

  $ lsusb
  ID 04b8:0131 Seiko Epson Corp. GT-F720 [GT-S620/Perfection V30/V300 Photo]

• install and enable cups

  # pacman -S cups
  # systemctl list-unit-files |grep cups
  [if necesary....]
  # systemctl enable cups.service
  # systemctl restart cups.service

• can play with turning cups on and off or even uninstalling it later, but it's likely to be initially necessary for the scanner to successfully build against
• install the AUR driver

  $ yay -S iscan-plugin-gt-f720

• verify it's a detected scanner

  $ scanimage -L
  device `epkowa:interpreter:001:006' is a Epson Perfection V30 flatbed scanner

• try a test scan with, e.g. xsane

problem

Initiating the GUI xsane application with a USB-connected Epson V30 scanner results in a pause, then termination of the xsane application (without scanning). Connecting an Epson V370, the same actions result in normal xsane scanning operations. Using a known-good, functioning USB-connected Epson V370, let's run similar applications on both the V370 and the non-functioning V30, until we can find a difference, and hopefully solve the V30 non-operation.

---

CLI software

First, can we at least detect the V30 using the command-line? Two command line interface (CLI) scanner probes, scanimage and sane-find-scanner, verify slightly different features. Scanimage is the more thorough. Scanimage on the V30 pauses, but eventually goes to completion, describing the V30 as "unknown model".

$ scanimage -L
device `epkowa:usb:001:004' is a Epson (unknown model) flatbed scanner

... on the V370 there's no delay and the model name is identified.

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V370 Photo flatbed scanner

Model name aside, the V30 and V370 are properly detected and trigger the kernel to create data files; we can rule-out hardware, firmware, or kernel problems. Since the USB device name for the V370 includes "interpreter", but the V30 device name remains "usb"; the kernel is not receiving additional information for the V30, beyond the simple usb connection. Let's locate the (operational) V370 driver on the hard drive, and see if the V30 is in the same folder and perhaps not working.
Attaching the USB V370, and stracing $ scanimage -T ($ strace scanimage -T 2>&1 |tee V370file.txt) and then searching inside the resulting text file, I noted (~line 1195)

open("/usr/lib/iscan/libiscan-plugin-perfection-v370.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/iscan/libiscan-plugin-perfection-v370.so", O_RDONLY|O_CLOEXEC) = 9

The V370 driver inside /usr/lib/iscan, however I could find no driver relevant to the V30 in that folder. It appears we're lacking a V30 driver. A V30 driver would give the kernel more information than "usb".

driver software

I lucked into a premade AUR version of the V30 driver -- one step with yaourt. A conversation about this driver exists on the forums. Apparently, the creator downloaded a DEB file from the Epson site and then converted the DEB into a pacman/yaourt package. It's probably also worth noting that DEB's can be directly installed on Arch with a couple of steps. In this case, I had the premade AUR version I could install more easily using yaourt.

$ yaourt Ss v30
aur/iscan-plugin-gt-f720 0.1.1-1 (8) (0.01)
EPSON Image Scan! plugin for Epson Perfection V30 scanner
$ yaourt -S iscan-plugin-gt-f720

After installation, the V30 should appear with its model information and "interpreter" instead of "usb"...

$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V30 flatbed scanner

...and scan images via xsane.

possible tweaks

If there are still problems, check the following.

• Uncomment "usb" inside /etc/sane.d/epowka.conf, but without adding any make or model information, just leave it as "usb". If you add make or model, scanimage may generate a second, conflicting, instance of the V30.
• Comment "epowka" in /etc/sane.d/dll.conf, or conflicts will occur.
• The scanner libs directory should include softlinks to the main lib, libesci-interpreter-gt-f720.so, eg

  $ ls /usr/lib/iscan/
  libesci-interpreter-gt-f720.so
  libesci-interpreter-gt-f720.so.0
  libesci-interpreter-gt-f720.so.0.0.0

• Run

  $ iscan-registry -a 0x04b8 0x0131 libesci-interpreter-gt-f720.so

See bottom of this page for more configuration file info.

---

Troubleshooting prior to yaourt

block hpaio

Sometimes hpaio loads when there's no HP scanner. Like many Linux apps, they either don't work at all or they can never be disabled. Hpaio won't stop the V30 or other scanners, but it's a hardcore annoyance since it's impossible to turn off via any interface, by disabling CUPS, etc. I got tired of this fast and blacklisted the sumb*tch. Find the names of the hp-related libsane files in /lib/sane.d/, because you can't find it and its dependencies the normal way...

# modinfo -F depends libsane-hp
modinfo: ERROR: Module libsane-hp not found.

... and then blacklist them via /etc/modprobe.d/blacklisted.conf (you can call the file anything).

# nano /etc/modprobe.d/blacklisted.conf
# stop hpaio annoyance when no hp scanner connected
install libsane-hpaio /bin/true
install libsane-hp /bin/true

xsane also loads hpaio

Any time xsane is initiated, xsane finds these hpaio drivers and loads them directly. Stracing xsane

open("./dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/sane.d/dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 7
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(7, /* 4 entries */, 32768) = 76
1572:stat64("/etc/sane.d/dll.d/hpaio", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
1573:open("./dll.d/hpaio", O_RDONLY) = -1 ENOENT (No such file or directory)
1574:open("/etc/sane.d/dll.d/hpaio", O_RDONLY) = 8
1576:read(8, "hpaio\n", 4096) = 6
4071:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY) = 19
4073:open("/usr/lib/sane/libsane-hpaio.so.1", O_RDONLY|O_CLOEXEC) = 19

so you will also have to disable xsane from activating hpaio.

# nano /etc/sane.d/dll.d/hpaio
# comment the following so hpaio doesn't load.
#hpaio

Note: don't forget that, if an HP scanner is ever connected, you'll need to undo these changes to both /etc/sane.d/dll.d/hpaio and to /etc/modprobe.d/blacklisted.conf.

---

But back to yaourt. Yaourt was the end-point, yet I had proceeded through several troubleshooting steps to determine the driver issue. A couple of workday's worth of effort were spent ruling-out any physical connection, firmware, kernel, or configuration files. Some of that is noted above, the remainder is below.

lsub -vv (v370)

Partial information from lsusb -vv:

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x014a
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Perfection V37/V370
iSerial 0

lsub -vv (v30)

Partial information from lsusb -vv

idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x0131 GT-F720 [GT-S620/Perfection V30/V300 Photo]
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner
iSerial 0

sane-find-scanner

Running sane-find-scanner (lsusb -vv also would have been fine) against both models, both scanners properly return hexadecimal model/product codes.

(vendor=0x04b8 [EPSON], product=0x014a [EPSON Perfection V37/V370])

... and for the V30, sane-find-scanner returns...

(vendor=0x04b8 [EPSON], product=0x0131 [EPSON Scanner])

I also attempted to get attributes and do tests on the V30, prior to yaourt.

$ scanimage -A -d 'epkowa:usb:001:004'
$ scanimage -T -d 'epkowa:usb:001:005'

Both of these time-out, returning nothing however, since we have the hexidecimal model code on both scanners (0131 for the V30 and 014a for the V370), firmware, hardware detection, and/or physical USB connection problems are ruled-out. There are three remaining categories of variables for this V30 problem. 1) Kernel software, application software, configuration files.

Kernel side

The kernel creates and destroys files inside the directory /run/udev/data/ whenever a USB device is connected or disconnected to a UNIX system. User-level applications, such as xsane, then read these files for operating parameters. So we'd like to check the /run/udev/data/ files for the V30. If they're good, we know xsane is malfunctioning. If they're bad, we know the kernel is malfunctioning (or not receiving enough V30 info).

/run/udev/data

How do we find the names of the files created when the V370 or the V30 are connected by USB? Sane-find-scanner is helpful, but we'll need to strace it to gather enough information. We'll send the two results to text files we can parse. First, the operating scanner, V370. Connect it to the USB port and, ($ strace sane-find-scanner 2>&1 |tee V370file.txt). At line 700 (YMMV) of V370file.txt, we find a call to the data file c189:5:

$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:5", O_RDONLY|O_CLOEXEC) = 8

Next, the non-scanning V30. Connect it via USB and, $ strace sane-find-scanner 2>&1 |tee V30file.txt . At line 700 (again, YMMV) of V370file.txt, we find a call to the data file c189:4:

$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:4", O_RDONLY|O_CLOEXEC) = 8

Now we have the names of the two data files the kernel creates, 189:5 for the V370, and 189:4 for the V30. Here's the content for the two files. The (functioning) V370

$ cat /run/udev/data/c189:5
I:97119577141
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Perfection_V37_V370
E:ID_MODEL_ENC=EPSON\x20Perfection\x20V37\x2fV370
E:ID_MODEL_ID=014a
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Perfection_V37_V370
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

...and, when the V30 is attached

$ cat /run/udev/data/c189:4
I:138131813751
E:ID_VENDOR=EPSON
E:ID_VENDOR_ENC=EPSON
E:ID_VENDOR_ID=04b8
E:ID_MODEL=EPSON_Scanner
E:ID_MODEL_ENC=EPSON\x20Scanner
E:ID_MODEL_ID=0131
E:ID_REVISION=0100
E:ID_SERIAL=EPSON_EPSON_Scanner
E:ID_BUS=usb
E:ID_USB_INTERFACES=:ffffff:
E:libsane_matched=yes
E:ID_VENDOR_FROM_DATABASE=Seiko Epson Corp.
E:ID_MODEL_FROM_DATABASE=GT-F720 [GT-S620/Perfection V30/V300 Photo]
E:ID_PATH=pci-0000:00:12.2-usb-0:2
E:ID_PATH_TAG=pci-0000_00_12_2-usb-0_2
E:ID_FOR_SEAT=usb-pci-0000_00_12_2-usb-0_2
G:uaccess
G:seat

Since both the V370 and the V30 files are properly created inside /run/udev/data/, the kernel is now ruled-out as a problem. Secondly, these presence of these data files also probably excludes the rules the kernel uses to write data files for /run/udev/data/. These rules for helping the kernel translate a physical USB connection into a data file are in /lib/udev/rules.d/. In the case of the scanner rules, the rules file is /lib/udev/rules.d/49-sane.rules. So far, everything has checked-out normally, and now we have ruled out the kernel's USB firmware detection and data propagation processes.

Unsolved

Our current unsolved clues related to the non-scanning are 1) the pause and eventual time-out when V30 is queried, 2) the unnamed model "Scanner", 3) the name "usb", instead of "interpreter" inside scanimage -L results.

# echo -1 >/sys/module/usbcore/parameters/autosuspend

Still, EAGAINs and the pauses did not stop, and this led me, finally, to a driver.

Other rule-outs: configuration files

• /etc/sane.d/epson.conf - possibly could add the make and model to identify the V30, however if a yaourt or pacman solution is available, remove it.
• /etc/sane.d/saned.conf - Should not be a problem, since V370 is operating
• /etc/sane.d/dll.conf - No problems since V370 is working
• /etc/sane.d/epkowa.conf - No problems since V370 operates
• /usr/share/iscan-data/usb - Neither the 014a or the 0131 models are in this file. This file is opened during scanimage tests however.