Fetching a tag from #ubuntu #linux #kernel tree:

function git-fetch-linux-ubuntu-tag {
  local tag=refs/tags/cod/mainline/$1
  git fetch --no-tags \
    git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack \
    $tag:$tag
}

Usage example:

$ git checkout -b tmp
Switched to a new branch 'tmp'

$ git-fetch-linux-ubuntu-tag v6.3
From git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
 * [new tag]                   cod/mainline/v6.3 -> cod/mainline/v6.3

$ git merge v6.3

Building:

LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch

still no idea how to remove duplicate emails, and the query language is not in par with mutt but benefits overcome these minor glitches :-)

thank you #mutt 1999-2023, i've now fully moved into #aerch as my main #email client. https://aerc-mail.org/

I like virt manager otherwise, except for its crappy looking icon :-) #kvm #qemu #libvirt

So to test my next branch I just need to do pretty trivial steps to get a properly packaged distro kernel:

git fetch --no-tags git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack refs/tags/cod/mainline/v6.3-rc7:refs/tags/cod/mainline/v6.3-rc7
git checkout next
git checkout -b next-test
git merge cod/mainline/v6.3-rc7
LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic 

In my experience even in archlinux test kernel packaging is more involved than ubuntu.

I favor Ubuntu in my machines because it has so streamlined kernel workflow, which lends itself to testing new upstream patches (even among Debian derivatives).

#remindertomyself: fetch a #git tag for the given #ubuntu #mainline #linux #kernel #snapshot:

$ git fetch --no-tags git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack refs/tags/cod/mainline/v6.3-rc7:refs/tags/cod/mainline/v6.3-rc7
From git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack
 * [new tag]                   cod/mainline/v6.3-rc7 -> cod/mainline/v6.3-rc7

suppilovahvero in linux-tpmdd on  next took 19s
$ git tag
cod/mainline/v6.3-rc7

Compilation:

LANG=C fakeroot debian/rules clean
LANG=C fakeroot debian/rules binary-headers binary-generic binary-perarch

#libreoffice #draw is the only reason why i install it in the first place anywhere. it provides equivalent user experience and robustness to all #subscription based #diagram tools, without the subscription fees.

the only thing i would improve in it would be t separate it from the rest of the suite because i don't have any use for the other libreoffice applications.

One blocker is lack of equivalent for set trash (in #mutt).

trying out #aerc #email client

I have now kind of current state of desktop in both #x86 and #ARM ends :-)

1. i9-13900k / 64 GB / Intel ARC A-770
2. Mac Mini M2 Pro 12 12/19 core version / 32 GB

The 2nd is both the computer I do music with (i.e. my studio machine) and also #ARM test farm for #TPM. I compile ARM kernels with it and run them in VMWare Fusion, which provides nicely packaged #vTPM’s.

i find paying for #sublimetext and using it with #neovintageous much better option than #vscode, if I need a GUI editor e.g. in meetings. It is fast and uncluttered. If you write code normally in the #terminal with #neovim, vscode can feel a bit sticky, and also stressful because it has too much shit going on in the screen estate. Milliseconds do affect to the overall feeling just like they would when e.g. when playing with a MIDI keyboard.

And generally if it is not fully open source, I feel less worried to use an application where I pay a sum of money for the license. Because the profit is often acquired by some means anyway, it is the most transparent for me…

#remindertomyself

$ ps -T -o comm,policy,rtprio -p $(pgrep -w -d ',' irq) | egrep '(snd|hci)'
irq/148-xhci_hc FF      85
irq/147-ahci[00 FF      50
irq/203-snd_hda FF      90
irq/204-snd_hda FF      90

#renewed my accidentally #expired
@lwnnet #subscription. unintentionally i had used single time payment last year (before that i was using corporate subscription while i was still working at intel). now it is set to automatic payment like it should be :-)

i have now kind of "#intel of the present day" #desktop configurtion in my main #development machine: i9-13900k with 64GB of DDR and Intel Arc A770 GPU.

ive been waiting the day to get rid of shitty #nvidia #hardware, causing all the time compatibility issues...

on #macos (which I have in my #university laptop, thus learning the ways) the easiest way to do #linux #kernel development and testing is podman (brew install podman). each container will have a #QEMU instance backing it up.

that sorted out, using macos does not really make any difference, as full-screen #tmux is pretty much the same always :-) any desktop that can launch a web browser is good enough desktop for me really...

this is how i deal with #password's. i protect the critical passwords with #PGP public key. Any password where #leakage is not an existential question is offloaded to #lastpass. The keyring itself is protected by #yubikey. i feel overally pretty safe :-)

@bitzero Another perspective is that for a kernel developer, it is an asset to have devices and machines running different operating systems for multitude of reasons :-) It is always good to have references...

@bitzero i use my desktop pc anyway for anything more serious when it comes to development (i9-13900k/64GB). possibly i would consider otherwise if it was the only machine i could use

@bitzero There's no VM image getting deployed to the external drive, as I already denoted in my text. Provisioning USB device nodes is trivial in all popular VMM's of which I'm aware of at least.