[arch-proaudio] New [community] additions for 2018
Hey all,
I plan on moving some packages from AUR to [community]. Namely those would be:
cadence * https://aur.archlinux.org/packages/cadence/ * build without claudia support (flowcanvas is dead and should stay dead)
carla * https://aur.archlinux.org/packages/carla/
faust * https://aur.archlinux.org/packages/faust/ * needs more votes
helm * https://aur.archlinux.org/packages/helm/ * needs more votes
jacktrip * https://aur.archlinux.org/packages/jacktrip/ * needs more votes
liblscp * https://aur.archlinux.org/packages/liblscp/
padthv1 * https://aur.archlinux.org/packages/padthv1/ * needs more votes
quastools-qt5 * https://aur.archlinux.org/packages/qastools-qt5/
qsampler * https://aur.archlinux.org/packages/qsampler/
qmidinet * https://aur.archlinux.org/packages/qmidinet/ * needs more votes
ssr * https://aur.archlinux.org/packages/ssr/ * needs more votes
rtmidi * https://aur.archlinux.org/packages/rtmidi/
tuna * https://aur.archlinux.org/packages/tuna * needs more votes
yoshimi * https://aur.archlinux.org/packages/yoshimi/
zita-ajbridge * https://aur.archlinux.org/packages/zita-ajbridge/ * needs more votes
zita-njbridge * https://aur.archlinux.org/packages/zita-njbridge/
As you can see, some of the packages actually still require more votes for them to be able to move to the main repositories (10 is a requirement).
Additionally, I'd like to add stable versions of the following software (first to the AUR, but eventually to [community]):
sc3-plugins * https://github.com/supercollider/sc3-plugins
ingen * https://drobilla.net/software/ingen
machina * https://drobilla.net/software/machina
qmidictl * https://qmidictl.sourceforge.io
qxgedit * https://qxgedit.sourceforge.io
If you are a user of software of the first group, please make sure to vote for it (or just vote for it ;-) ).
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?
Let me know!
Best, David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Daniel (and all),
Thanks for the overview, I upvoted some of your suggestions.
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/
Another I would like to see in community, but maybe hard to do: Linux-rt * https://aur.archlinux.org/packages/linux-rt/
Thanks, in case of questions, here I am
Best, Oli
On 18.01.2018 18:21, David Runge wrote:
Hey all,
I plan on moving some packages from AUR to [community]. Namely those would be:
cadence * https://aur.archlinux.org/packages/cadence/ * build without claudia support (flowcanvas is dead and should stay dead)
carla * https://aur.archlinux.org/packages/carla/
faust * https://aur.archlinux.org/packages/faust/ * needs more votes
helm * https://aur.archlinux.org/packages/helm/ * needs more votes
jacktrip * https://aur.archlinux.org/packages/jacktrip/ * needs more votes
liblscp * https://aur.archlinux.org/packages/liblscp/
padthv1 * https://aur.archlinux.org/packages/padthv1/ * needs more votes
quastools-qt5 * https://aur.archlinux.org/packages/qastools-qt5/
qsampler * https://aur.archlinux.org/packages/qsampler/
qmidinet * https://aur.archlinux.org/packages/qmidinet/ * needs more votes
ssr * https://aur.archlinux.org/packages/ssr/ * needs more votes
rtmidi * https://aur.archlinux.org/packages/rtmidi/
tuna * https://aur.archlinux.org/packages/tuna * needs more votes
yoshimi * https://aur.archlinux.org/packages/yoshimi/
zita-ajbridge * https://aur.archlinux.org/packages/zita-ajbridge/ * needs more votes
zita-njbridge * https://aur.archlinux.org/packages/zita-njbridge/
As you can see, some of the packages actually still require more votes for them to be able to move to the main repositories (10 is a requirement).
Additionally, I'd like to add stable versions of the following software (first to the AUR, but eventually to [community]):
sc3-plugins * https://github.com/supercollider/sc3-plugins
ingen * https://drobilla.net/software/ingen
machina * https://drobilla.net/software/machina
qmidictl * https://qmidictl.sourceforge.io
qxgedit * https://qxgedit.sourceforge.io
If you are a user of software of the first group, please make sure to vote for it (or just vote for it ;-) ).
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?
Let me know!
Best, David
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
How could I forget about those two! ;-) I put them on my list!
And damn, tuxguitar must have slipped right by me during the yearly repository cleanup!
Another I would like to see in community, but maybe hard to do: Linux-rt
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
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
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
Hey all,
I've added a bunch of packages [1]. Some of them were quite a PITA.
Please test!!!
Best, David
[1] https://www.archlinux.org/packages/?sort=&repo=Community-Testing&q=&...
On 26.01.2018 17:45, David Runge wrote:
Please test!!!
How? Just install them and check if there are running?
~Georg
Begin forwarded message:
Date: Sat, 27 Jan 2018 17:45:50 +0100 From: Ralf Mardorf's wrong account :D To: arch-proaudio@lists.archlinux.org Subject: Re: [arch-proaudio] New [community] additions for 2018
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
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
Hi Georg,
On 2018-01-27 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?
Xactly.
You can follow the wiki [1]. However, in theory, it'll be something in the vein of:
* enable the [community-testing] repo in /etc/pacman.conf * `pacman -Syy` # update databases * `pacman -S community-testing/<pkgname>` # install <pkgname> from [community-testing] instead of [community]
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)!
Best, David
[1] https://wiki.archlinux.org/index.php/Official_repositories#testing
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".
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.
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: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 ;).
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.
On 2018-01-27 19:25:29 (+0100), Ralf Mardorf wrote:
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 ;).
I never wrote anything about upgrading the whole system (I rather warned about the possibility, when doing a `pacman -Syu`). That's also not really a "partial upgrade", as those packages are currently not even in [community]. Currently I didn't build against anything in [testing], that would break things in [community-testing] afaik [1]. Therefore, no, activating [testing] should not be required.
Also: Please stop posting gazillion lines of output from your console. It's just not relevant to any of these topics or helpful in any way.
Best, David
[1] https://www.archlinux.org/packages/?sort=&repo=Testing&q=&mainta...
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 2018-01-27 22:02:32 (+0100), Ralf Mardorf wrote:
You missed the whole point.
Maybe that got sweeped away by the many lines of nonesense without linebreaks?
Whatever people do, if they test something from [community-testing], OF COURSE they should be mindful. That's why I sent a link to the wiki instead of a random "install stuff from somewhere" recommendation with random rants on why stuff might break.
You are not the only person on this mailing list and this is not your scratch pad. Reconsider before sending a mail that contains 300 lines and more of random thoughts on something, when at best what you achieve is to add more noise. Pastebins are around for a reason.
I've observed this behavior of yours on every mailing list, that you're on. I get, that you want to contribute, but sometimes maybe just don't or at least in a more condensed form?
Best, David
On 18.01.2018 18:21, David Runge wrote:
If you are a user of software of the first group, please make sure to vote for it (or just vote for it ).
Voted for those I'm using, or may want to use in the future ;)
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?
A bit late to the game, but here two (LV2) synth/effects I've not yet seen on any list.
* setbfree https://aur.archlinux.org/packages/setbfree/
On 27.01.2018 13:52, Hanspeter Portner wrote:
On 18.01.2018 18:21, David Runge wrote:
If you are a user of software of the first group, please make sure to vote for it (or just vote for it ).
Voted for those I'm using, or may want to use in the future ;)
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?
A bit late to the game, but here two (LV2) synth/effects I've not yet seen on any list.
- setbfree
https://aur.archlinux.org/packages/setbfree/
- mda-lv2
This should definitely go into community, already has enough votes, I hope.
On Sat, 27 Jan 2018 15:52:24 +0100, Hanspeter Portner wrote:
- 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.
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. In my experiences it works with all 4.x releases and it even should work with many 3.x releases, at least I didn't experience an issue around the last 3 years. However, in the past there where a few issues, the release model distro Ubuntu Studio shipped with a rtirq release that didn't fit to the provided "lowlatency" kernel. This couldn't happen to us, but we could run into a mainline vs LTS kernel issue. In my opinion rtirq should fit to the mainline kernel, if it can't be used for all provided kernels.
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?
On Sun, 28 Jan 2018 12:30:24 +0100, Joakim Hernberg wrote:
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?
There were reasons for Rui to update rtirq several times. Once there e.g. was the change from the name ICE1712 to the nowadays snd_ice1. I don'r remembr if the user just had to edit the config or if Rui needs to rewrite rtirq, however, this was an issue when rtirq worked for one, but not for another kernel.
[rocketmouse@archlinux ~]$ rtirq status | grep ice 303 FF 80 - 120 0.0 S irq/16-snd_ice1
However, even the recent version of rtirq is not completely immune against pitfalls, see https://bugs.launchpad.net/ubuntu/+bug/1482347 ;), resp. https://lists.linuxaudio.org/pipermail/linux-audio-user/2015-August/102254.h... ;).
Hey all,
helm
- https://aur.archlinux.org/packages/helm/
- needs more votes
jacktrip
- https://aur.archlinux.org/packages/jacktrip/
- needs more votes
padthv1
- https://aur.archlinux.org/packages/padthv1/
- needs more votes
qmidinet
- https://aur.archlinux.org/packages/qmidinet/
- needs more votes
zita-ajbridge
- https://aur.archlinux.org/packages/zita-ajbridge/
- needs more votes
zita-njbridge
the above and additionally all remaining zita-tools are now in [commmunity-testing]. Please test!
@Fons: It would be cool, if you had a look at the zita-{aj,nj}bridge and e.g. zita-mu1 PKGBUILDs [1] [2] [3]. I would rather not apply such hacks during prepare(): Some of the install procedures are broken, but could be fixed either with the target flag (-t) or by being specific about their destination. pacman (and most other package managers) are now compressing man pages themselves by default (which is why I disabled the targets and just install the plain files in my fix).
Best, David
[1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [3] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa...
Hi all,
On 2018-02-22 19:23:18 (+0100), David Runge wrote:
the above and additionally all remaining zita-tools are now in [commmunity-testing]. Please test!
@Fons: It would be cool, if you had a look at the zita-{aj,nj}bridge and e.g. zita-mu1 PKGBUILDs [1] [2] [3]. I would rather not apply such hacks during prepare(): Some of the install procedures are broken, but could be fixed either with the target flag (-t) or by being specific about their destination. pacman (and most other package managers) are now compressing man pages themselves by default (which is why I disabled the targets and just install the plain files in my fix).
Best, David
[1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [2] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... [3] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa...
All are now in [community]. Hydrogen was updated, as well.
Please note, that during the upgrade of rtirq to the latest version, I moved the configuration file to /etc/rtirq.conf (as this should be caught by the script by default, so no patching needed).
Best, David
participants (6)
-
David Runge
-
Georg Krause
-
Hanspeter Portner
-
Joakim Hernberg
-
Oliver Friedrich
-
Ralf Mardorf