On 2018-01-18 19:18:29 (+0100), Oliver Friedrich wrote:

Thanks for the overview, I upvoted some of your suggestions. Thanks!

Two packages I would like to see in community:

TuxGuitar * https://aur.archlinux.org/packages/tuxguitar/ * needs more votes

DrumGizmo * https://aur.archlinux.org/packages/drumgizmo/ How could I forget about those two! ;-) I put them on my list!

Another I would like to see in community, but maybe hard to do: Linux-rt * https://aur.archlinux.org/packages/linux-rt/

And damn, tuxguitar must have slipped right by me during the yearly repository cleanup! linux-rt is sadly a whole different topic altogether. For this to happen we need more (pro-audio) package maintainers, as maintaining a kernel is (sometimes) not a piece of cake and requires quite some time and testing (thanks again to Joakim Hernberg for taking such good care of it over the years!). And even then, it's not yet very probable, that the other TUs and developers will actually like the idea (too many kernels already). Interested? :)

Thanks, in case of questions, here I am

Best, Oli hi oli!

Best, David -- https://sleepmap.de

On 2018-01-20 21:07:19 (+0100), Joakim Hernberg wrote:

On Thu, 18 Jan 2018 18:21:07 +0100 David Runge <dave@sleepmap.de> wrote:

...

Additionally, this of course is just my short list of "interesting pieces of software, that would be neat to have a binary package of". Maybe you can think of some more?

How about ambiX: http://www.matthiaskronlachner.com/?p=2015 Good idea! Needs to be packaged first. Noted though!

Other candidates would be iannix [1] and i-score [2] I think. Both need votes! [1] https://aur.archlinux.org/packages/iannix [2] https://aur.archlinux.org/packages/i-score -- https://sleepmap.de

On 26.01.2018 17:45, David Runge wrote:

Please test!!!

How? Just install them and check if there are running? ~Georg

Oops, the forwarded copy provided broken line wrapping, here it is again. On Sat, 27 Jan 2018 16:29:13 +0100, Georg Krause wrote:

On 26.01.2018 17:45, David Runge wrote:

...

Please test!!!

How? Just install them and check if there are running?

Yes! I allready build some software myself along time ago, but didn't install it... [rocketmouse@archlinux aur]$ ls -hl total 11M -rw-r--r-- 1 rocketmouse rocketmouse 9.1M Sep 16 16:45 ardour-5.12-1-x86_64.pkg.tar.xz drwxr-xr-x 2 rocketmouse rocketmouse 24K Jan 26 04:33 current drwxr-xr-x 3 rocketmouse rocketmouse 48K Jan 26 04:33 old lrwxrwxrwx 1 rocketmouse rocketmouse 40 Oct 8 2016 very_old -> /mnt/moonstudio/.var/cache/aur/very_old/ -rw-r--r-- 1 rocketmouse rocketmouse 932K May 27 2017 x42-plugins-20170428-1-x86_64.pkg.tar.xz [rocketmouse@archlinux aur]$ pacman -Q ardour5 x42-plugins ardour5 5.8-1 x42-plugins 20161230-1 ...since I'm short in time and tend to start and finish a production without updating relevant software. Btw. I already installed two page-table isolation kernels, that aren't rt patched kernels. At the moment I don't have time to test if booting with or without nokaiser/nopti does make a difference. [root@archlinux moonstudio]# grep \ no..i /boot/syslinux/syslinux.cfg APPEND root=LABEL=archlinux ro threadirqs nopti APPEND root=LABEL=moonstudio ro nokaiser [root@archlinux moonstudio]# pacman -Q linux linux 4.14.15-1 [root@archlinux moonstudio]# systemd-nspawn apt changelog linux-image-4.4.0.112-lowlatency 2>/dev/null | grep "nokaiser" - kaiser: add "nokaiser" boot option, using ALTERNATIVE Btw. I installed [rocketmouse@archlinux aur]$ pacman -Q linux linux-rt linux-rt-cornflower linux-rt-pussytoes linux 4.14.15-1 linux-rt 4.14.12_rt10-1 linux-rt-cornflower 4.11.12_rt16-1 linux-rt-pussytoes 4.14.8_rt9-2 I wonder if it makes a difference to boot https://aur.archlinux.org/packages/linux-rt/ (linux-rt 4.14.15_rt12-1) with or without nopti, realted to pro-audio performance. I already send a request to linux-rt-users@vger.kernel.org at 25 Jan 2018, but nobody replied. "KPTI was merged into Linux kernel version 4.15, to be released in early 2018, and backported to Linux kernels 4.14.11, 4.9.75, 4.4.110. Windows and macOS released similar updates. KPTI does not address the related Spectre vulnerability." - https://en.wikipedia.org/wiki/Kernel_page-table_isolation -- Off-topic: Wow, since the latest upgrade of enchant, some apps build against this latest upgrade of enchant don't provide working spell checking anymore :D. -- https://www.schneier.com/blog/archives/2018/01/spectre_and_mel_1.html

On Sat, 27 Jan 2018 18:32:56 +0100, David Runge wrote:

Please note: If you now do a `pacman -Syu` (with the [community-testing] repo still enabled in /etc/pacman.conf), you'll update your system with everything that's newer in [community-testing] in comparison to [community] (the first has precedence)!

Better do not enable testing, buts simply install the package you wish to test by pacman -S URL_of_the_package_location The only drawback is that pacman -Sc does not remove the "signature" file from /var/cache/pacman/pkg/, you need to do it manually using "rm". -- https://www.schneier.com/blog/archives/2018/01/spectre_and_mel_1.html

On Sat, 27 Jan 2018 19:01:29 +0100, David Runge wrote:

On 2018-01-27 18:39:16 (+0100), Ralf Mardorf wrote:

...

On Sat, 27 Jan 2018 18:32:56 +0100, David Runge wrote:

...

Please note: If you now do a `pacman -Syu` (with the [community-testing] repo still enabled in /etc/pacman.conf), you'll update your system with everything that's newer in [community-testing] in comparison to [community] (the first has precedence)!

Better do not enable testing, buts simply install the package you wish to test by

pacman -S URL_of_the_package_location

Ralf, that's not really a helpful suggestion.

However, if you activate the [community-testing] repository, pacman will properly install all dependencies of a package and be able to keep track of it in a reasonable way. Some of the new additions have dependencies (also in [community-testing]).

So please, refrain from doing it the way Ralf described.

My apologoes for the typo "S" should read "U", "S" doesn't work at all, but "U" would install all dependencies, too. [root@archlinux rocketmouse]# pacman -Q yoshimi yoshimi 1.5.6-1 [root@archlinux rocketmouse]# pacman -U https://mex.mirror.pkgbuild.com/community-testing/os/x86_64/yoshimi-1.5.6-2-... yoshimi-1.5.6-2-x86_64 6.2 MiB 686K/s 00:09 [--------------------------------------------------------------------] 100% yoshimi-1.5.6-2-x86_64.sig 566.0 B 0.00B/s 00:00 [--------------------------------------------------------------------] 100% loading packages... resolving dependencies... looking for conflicting packages... Packages (1) yoshimi-1.5.6-2 Total Installed Size: 10.95 MiB Net Upgrade Size: -1.78 MiB :: Proceed with installation? [Y/n] (1/1) checking keys in keyring [--------------------------------------------------------------------] 100% (1/1) checking package integrity [--------------------------------------------------------------------] 100% (1/1) loading package files [--------------------------------------------------------------------] 100% (1/1) checking for file conflicts [--------------------------------------------------------------------] 100% (1/1) checking available disk space [--------------------------------------------------------------------] 100% :: Processing package changes... (1/1) upgrading yoshimi [--------------------------------------------------------------------] 100% :: Running post-transaction hooks... (1/3) Updating icon theme caches... (2/3) Arming ConditionNeedsUpdate... (3/3) Updating the desktop file MIME type cache... [root@archlinux rocketmouse]# pacman -Q yoshimi yoshimi 1.5.6-2 [root@archlinux rocketmouse]# ls -hl /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz* -rw-r--r-- 1 root root 6.3M Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz -rw-r--r-- 1 root root 566 Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz.sig The only drawaback still is the sig file. Once you install the next upgrade and run "pacman -Sc" the *sig file will not be removed, you need to remove it using rm -i /var/cache/pacman/pkg/*sig [root@archlinux rocketmouse]# rm -i /var/cache/pacman/pkg/*sig rm: remove regular file '/var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz.sig'? y [root@archlinux rocketmouse]# ls -hl /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz* -rw-r--r-- 1 root root 6.3M Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz [root@archlinux rocketmouse]# That's it. Yes, all dependncies already were installed on my system, if not pacman would have installed them.

On Sat, 27 Jan 2018 19:25:29 +0100, Ralf Mardorf wrote:

On Sat, 27 Jan 2018 19:19:10 +0100, Ralf Mardorf wrote:

...

On Sat, 27 Jan 2018 19:01:29 +0100, David Runge wrote:

...

On 2018-01-27 18:39:16 (+0100), Ralf Mardorf wrote:

...

On Sat, 27 Jan 2018 18:32:56 +0100, David Runge wrote:

...

Please note: If you now do a `pacman -Syu` (with the [community-testing] repo still enabled in /etc/pacman.conf), you'll update your system with everything that's newer in [community-testing] in comparison to [community] (the first has precedence)!

Better do not enable testing, buts simply install the package you wish to test by

pacman -S URL_of_the_package_location

Ralf, that's not really a helpful suggestion.

However, if you activate the [community-testing] repository, pacman will properly install all dependencies of a package and be able to keep track of it in a reasonable way. Some of the new additions have dependencies (also in [community-testing]).

So please, refrain from doing it the way Ralf described.

My apologoes for the typo "S" should read "U", "S" doesn't work at all, but "U" would install all dependencies, too.

[root@archlinux rocketmouse]# pacman -Q yoshimi yoshimi 1.5.6-1 [root@archlinux rocketmouse]# pacman -U https://mex.mirror.pkgbuild.com/community-testing/os/x86_64/yoshimi-1.5.6-2-... yoshimi-1.5.6-2-x86_64 6.2 MiB 686K/s 00:09 [--------------------------------------------------------------------] 100% yoshimi-1.5.6-2-x86_64.sig 566.0 B 0.00B/s 00:00 [--------------------------------------------------------------------] 100% loading packages... resolving dependencies... looking for conflicting packages...

Packages (1) yoshimi-1.5.6-2

Total Installed Size: 10.95 MiB Net Upgrade Size: -1.78 MiB

:: Proceed with installation? [Y/n] (1/1) checking keys in keyring [--------------------------------------------------------------------] 100% (1/1) checking package integrity [--------------------------------------------------------------------] 100% (1/1) loading package files [--------------------------------------------------------------------] 100% (1/1) checking for file conflicts [--------------------------------------------------------------------] 100% (1/1) checking available disk space [--------------------------------------------------------------------] 100% :: Processing package changes... (1/1) upgrading yoshimi [--------------------------------------------------------------------] 100% :: Running post-transaction hooks... (1/3) Updating icon theme caches... (2/3) Arming ConditionNeedsUpdate... (3/3) Updating the desktop file MIME type cache... [root@archlinux rocketmouse]# pacman -Q yoshimi yoshimi 1.5.6-2 [root@archlinux rocketmouse]# ls -hl /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz* -rw-r--r-- 1 root root 6.3M Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz -rw-r--r-- 1 root root 566 Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz.sig

The only drawaback still is the sig file.

Once you install the next upgrade and run "pacman -Sc" the *sig file will not be removed, you need to remove it using

rm -i /var/cache/pacman/pkg/*sig

[root@archlinux rocketmouse]# rm -i /var/cache/pacman/pkg/*sig rm: remove regular file '/var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz.sig'? y [root@archlinux rocketmouse]# ls -hl /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz* -rw-r--r-- 1 root root 6.3M Jan 25 15:01 /var/cache/pacman/pkg/yoshimi-1.5.6-2-x86_64.pkg.tar.xz [root@archlinux rocketmouse]#

That's it.

Yes, all dependncies already were installed on my system, if not pacman would have installed them.

My bad :D

indeed, assuming a package should depend on additional packages from any testing repository, it doesn't work ;), but then we are on the "partial" upgrade issue, so it anyway would be required to enable _all_ testing repositories, not just the community testing repository.

IOW the OP needs to upgarde everything using all testing repositories ;). Actually this usually isn't required ;).

PPS: While David's packages in testing might only require dependencies from community testing, some of the local build packages of the OP might require the same dependencies, but of older releases, so installing David's packages from testing anyway isn't safe, if the OP shouldn't know the dependency trees of the local packages she has got installed.

You missed the whole point. Even if installing dependencies from cummunity testing to fullfill the dependencies of your packages provided by community testing should not break dependencies of any package provided by official non-testing repositories, it still could breake local build packages. No matter how you look at it, enabling community testing and installing your packages + the required dependencies from communety testing, even without upgrading everything to community testing, by pacman -S packages, or by installing the wanted packages, including relevant dependencies by using pacman -U URLs, there is exactly the same tendency to break packages. By one way or another you need to care about the dependencies yourself. By my approach you need to do it already when you install the packages, by your way, you need to care about it, when pacman's output shows you the additional packages that would get installed. In short, either way you need to be aware about your install and the dependencie trees of the installed packages or software that even isn't installed by a local package, but a make install. You recommendation is a partial upgrade as well as my pointer to use the URLs instad of enabling a testing repo.

On Sat, 27 Jan 2018 15:52:24 +0100, Hanspeter Portner wrote:

* rtirq https://aur.archlinux.org/packages/rtirq/

Yes, I suspect it is missed, because it's taken for granted and easy to install, even from upstream, IOW without an Arch Linux package, let alone that it nor necessarily fits to all kernels available, e.g a mainline vanilla kernel booted with threadsirq and a long term supported real-time patched kernel. -- Off-topic: Wow, since the latest upgrade of enchant, some apps build against this lates upgrade of enchant don't provide working spell checking anymore :D.

On Sat, 27 Jan 2018 22:28:27 +0100 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

Now that rtirq moved from AUR to community, it's to consider to what kernel rtirq should fit. OTOH I used and still use the current release of rtirq with several kernel releases. At the moment there shouldn't be an issue with all common used kernel releases.

What possible issue could there be with rtirq except for the kernel not having threaded irqs? -- Joakim