Category: Mint

nope

whbeebe

I’m a glutton for punishment. I’ll install software at the drop of a hat whether I need it or not. This is especially true about Linux desktop environments if they’re pretty enough. I looked at the latest KDE Plasma desktop, 5.26, and thought “shiney!” Because Linux Mint is based on Ubuntu, as is Kubuntu, I decided to install 5.26. After all, with apt, how hard could it be? Turns out an installation would be a bit of a mess. But I’ll get to that further down. First, I had to check to make sure my Linux Mint 21 installation was up to date.

mint ~ sudo apt updateHit:1 https://dl.google.com/linux/chrome/deb stable InReleaseHit:2 http://packages.microsoft.com/repos/code stable InReleaseIgn:3 http://packages.linuxmint.com vanessa InReleaseHit:4 http://security.ubuntu.com/ubuntu jammy-security InReleaseHit:5 http://packages.linuxmint.com vanessa ReleaseHit:6 https://atl.mirrors.clouvider.net/ubuntu jammy InReleaseHit:7 https://atl.mirrors.clouvider.net/ubuntu jammy-updates InReleaseIgn:8 https://repo.vivaldi.com/stable/deb stable InReleaseHit:9 https://atl.mirrors.clouvider.net/ubuntu jammy-backports InReleaseHit:10 https://repo.vivaldi.com/stable/deb stable ReleaseReading package lists... DoneBuilding dependency tree... DoneReading state information... DoneAll packages are up to date.

Great. Nothing needed to be updated. I then went searching for directions on how to add the necessary repo to my local apt so I could install the up-to-date KDE. I found what I thought was a good set of directions, checked to make sure the publication date was recent, and it was, and then attempted to follow the directions. Thus I ran the following.

mint ~ sudo add-apt-repository ppa:kubuntu-ppa/backportsYou are about to add the following PPA:Backports of new versions of KDE Platform, Plasma and Applications as well as major KDE apps for Kubuntu.sudo add-apt-repository ppa:kubuntu-ppa/backportsThis PPA will receive major version updates backported from later Kubuntu releases (and our development release);so if instead you want early access to just point (bugfix) releases of the versions of applications shipped with a Kubuntu release, then our updates PPA provides those: https://pad.lv/ppa/kubuntu-ppaMore info: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/backportsPress Enter to continue or Ctrl+C to cancel

Nothing out of the ordinary, so I typed Enter. Then this was displayed.

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).Executing: /tmp/apt-key-gpghome.ineZ8M22VJ/gpg.1.sh --keyserver hkps://keyserver.ubuntu.com:443 --recv-keys E4DFEC907DEDA4B8A670E8042836CB0A8AC93F7Agpg: key 2836CB0A8AC93F7A: public key "Launchpad Kubuntu Updates" importedgpg: Total number processed: 1gpg:   imported: 1

*sign* I’ve seen this once before. I wanted to install the latest GCC/G++ compiler tools (version 12), so I attempted to add that repo with the same method above, and got the same dire warning. Rather than stopping I bulled ahead trying to install the latest, only to wind up with something of a mess. When I went searching for the proper way to migrate to the correct way to add a repo, those directions were a convoluted mess. In the end I removed everything including the repo entries down /etc/apt. Fortunately there was a backup of /etc/apt/trusted.gpg, so I restored that backup. There’s a second entry for the new repo in /etc/apt/sources.list.d, which in this instance is kubuntu-ppa-backports-jammy.list, so that gets deleted as well.

I have no idea if, let alone when, I’ll try this again. But before I do it sure would be nice if the apt tools would provide a way to automatically convert the old deprecated way into the new-hotness way. The way it currently is is just bullshit.

fixing a flutter problem: accessing a google pixel 4a

whbeebe

I’m in the process of writing an Android app using Flutter. My target is a Google Pixel 4a. I’m using real hardware instead of a virtual handset because of the speed, especially on my low-cost development system. To give you an idea of what I’m running, here’s a capture of neofetch.

My little system is running with the latest Linux Mint release, and I’d just updated it to the latest packages, including the latest kernel for this distribution.

I’ve also got the latest version of Flutter (3.3.4)  installed. I’m not going to tell you how to install and set up Flutter. You can read about that at the Flutter site. Instead this is how I fixed an issue with Flutter unable to communicate with the Pixel 4a.

Even though I’d enabled developer mode on the Pixel 4a, when I plugged the 4a into my machine via USB and then ran flutter doctor, I was informed that adb couldn’t communicate with it. The error message, spit out on the console in lurid red text, said in part “adb: insufficient permissions for device: user in plugdev group; are your udev rules wrong?” It’s that bit about udev rules that’s the key clue to fixing the problem. In my case I had no udev rules for the plugged in 4a.

The udev (userland /dev, see https://opensource.com/article/18/11/udev ) subsystem allows a script to be run if a Linux device is created, usually by plugging in physical hardware. The rule files are located in /etc/udev/rules.d. For the case of plugging in a Pixel 4a, you need to create a rules file for when it’s connected so that code you run as a regular user can work with this specific device. The first step in writing a rules file is identifying the device by executing lsusb at the command line.

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubBus 003 Device 002: ID 8087:0029 Intel Corp. AX200 BluetoothBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. HubBus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubBus 001 Device 008: ID 18d1:4ee7 Google Inc. Nexus/Pixel Device (charging + debug)Bus 001 Device 007: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 006: ID 2e8a:0005 MicroPython Board in FS modeBus 001 Device 005: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 004: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 HubBus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying ReceiverBus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART BridgeBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have a number of devices plugged in, one of which is the Pixel 4a identified in line 6. The key information I need to create a udev rule is the ID 18d1:4ee7.

SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4ee7", MODE="0666", GROUP="plugdev"

You can see how I copied 18d1 to ATTR{idVendor}== and 4ee7 to ATTR{idProduct}==. I saved this single line of text to /etc/udev/rules.d/50-android.rules, then rebooted my system. Once it came back up when I re-ran flutter doctor I got the following;

The first run was after the reboot with the 4a plugged in. Believe it or not, the error message in the first run is actually a Good Thing. As noted on the console output, the 4a had a screen dialog asking if I wanted to trust the computer I was connected to to perform USB debugging “always”. When I selected yes, and re-ran flutter doctor, the output was totally clean.