Discussion:
[LAD] What's with Nedko Arnaudov?
David Runge
2017-12-06 14:28:30 UTC
Permalink
Hey all,

is anyone maybe in close contact with Nedko Arnaudov?
I've had trouble piecing together the upstream for a2jmidid [1], when
rebuilding the package for Arch Linux and tried contacting him.

There doesn't seem to be any activity in any of his repositories on
github [2] in recent years (not a good sign).

Especially in the case of a2jmidid, everything I hear from people when
asking them is "this was meant as a quick fix and not to stay around
long"... well, it's 2017 and it has stayed around long.
Additionally, it is dependency to some things currently in use, such as
cadence, etc.

Nedko also worked on ladish [3], afaics, which is still dependant on the
- long outdated/dead - flowcanvas [4].
I don't see any activity there either (at least not in the past four
years). Writing "the site is down" [5] doesn't make me believe that that
project is not dead, either.

This actively keeps programs such as cadence to be integrated into the
[community] repository in Arch, as I will not add flowcanvas back and if
upstream for a2jmidid deteroriates even more, it will be removed from
the main repositories eventually!

It would be great, if someone could shed some light on this.

Best,
David


[1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/a2jmidid&id=43147b417cb82d3e0308f94188b5811eb7987a2a
[2] https://github.com/nedko
[3] https://github.com/LADI/ladish
[4] https://drobilla.net/software/flowcanvas
[5] http://ladish.org/
--
https://sleepmap.de
Hanspeter Portner
2017-12-06 15:33:46 UTC
Permalink
Post by David Runge
Hey all,
is anyone maybe in close contact with Nedko Arnaudov?
I've had trouble piecing together the upstream for a2jmidid [1], when
rebuilding the package for Arch Linux and tried contacting him.
There doesn't seem to be any activity in any of his repositories on
github [2] in recent years (not a good sign).
Especially in the case of a2jmidid, everything I hear from people when
asking them is "this was meant as a quick fix and not to stay around
long"... well, it's 2017 and it has stayed around long.
Additionally, it is dependency to some things currently in use, such as
cadence, etc.
Its functionality has been integrated into JACK 1 a while back, so is
superfluous for users of the latter. Nothing should thus have a hard
dependency on it, as the user may well be running JACK 1.
Post by David Runge
Nedko also worked on ladish [3], afaics, which is still dependant on the
- long outdated/dead - flowcanvas [4].
I don't see any activity there either (at least not in the past four
years). Writing "the site is down" [5] doesn't make me believe that that
project is not dead, either.
This actively keeps programs such as cadence to be integrated into the
[community] repository in Arch, as I will not add flowcanvas back and if
upstream for a2jmidid deteroriates even more, it will be removed from
the main repositories eventually!
It would be great, if someone could shed some light on this.
Best,
David
[1] https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/a2jmidid&id=43147b417cb82d3e0308f94188b5811eb7987a2a
[2] https://github.com/nedko
[3] https://github.com/LADI/ladish
[4] https://drobilla.net/software/flowcanvas
[5] http://ladish.org/
David Runge
2017-12-06 19:07:51 UTC
Permalink
Post by Hanspeter Portner
Its functionality has been integrated into JACK 1 a while back, so is
superfluous for users of the latter. Nothing should thus have a hard
dependency on it, as the user may well be running JACK 1.
Okay, good to know. How about jack2 in this use-case though?
My knowledge might just not be up-to-date, as some of the pro-audio packages in Arch are out of date and some were unmaintained for quite some time.
--
https://sleepmap.de
Daniel Swärd
2017-12-07 15:33:09 UTC
Permalink
Post by David Runge
Post by Hanspeter Portner
Its functionality has been integrated into JACK 1 a while back, so is
superfluous for users of the latter. Nothing should thus have a hard
dependency on it, as the user may well be running JACK 1.
Okay, good to know. How about jack2 in this use-case though?
It's not in jack2, but FalkTX says he intends (at some point in time) to
integrate that functionality there as well.

/Daniel

Christopher Arndt
2017-12-06 16:17:53 UTC
Permalink
Post by David Runge
This actively keeps programs such as cadence to be integrated into the
[community] repository in Arch, as I will not add flowcanvas back
Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its canvas.


Chris
David Runge
2017-12-06 19:14:26 UTC
Permalink
Post by Christopher Arndt
Post by David Runge
This actively keeps programs such as cadence to be integrated into
the
Post by David Runge
[community] repository in Arch, as I will not add flowcanvas back
Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its canvas.
According to its INSTALL file [1] claudia needs ladish. a2jmidid is an optional dependency to cadence.


[1] https://github.com/falkTX/Cadence/blob/master/INSTALL.md
--
https://sleepmap.de
Simon van der Veldt
2017-12-06 19:37:53 UTC
Permalink
I sent Nedko a mail about 6 months ago asking similar questions, to which
he kindly replied. The short version of the answer was no real plans for
ladish, but he did want to bring the ladish site back up.
I didn't ask anything regarding a2jmidid because it's been working
perfectly for me.

If you want to know more I'd suggest to try sending him an e-mail :)

Cheers,
Simon
On December 6, 2017 5:17:53 PM GMT+01:00, Christopher Arndt <
Post by Christopher Arndt
Post by David Runge
This actively keeps programs such as cadence to be integrated into
the
Post by David Runge
[community] repository in Arch, as I will not add flowcanvas back
Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its canvas.
According to its INSTALL file [1] claudia needs ladish. a2jmidid is an
optional dependency to cadence.
[1] https://github.com/falkTX/Cadence/blob/master/INSTALL.md
--
https://sleepmap.de
_______________________________________________
Linux-audio-dev mailing list
https://lists.linuxaudio.org/listinfo/linux-audio-dev
David Runge
2017-12-06 19:57:17 UTC
Permalink
Post by Simon van der Veldt
I sent Nedko a mail about 6 months ago asking similar questions, to which
he kindly replied. The short version of the answer was no real plans for
ladish, but he did want to bring the ladish site back up.
Hmm, that's too bad.
Post by Simon van der Veldt
I didn't ask anything regarding a2jmidid because it's been working
perfectly for me.
The source tarball download link, that I replaced in the PKGBUILD (see first mail) went missing, as there was no web server running on gna.org anymore.
Now I switched to the git repo mentioned in the same link, but the tarball naming is not based on tags.
a2jmidid still works, but a flaky upstream is just not so nice to deal with as a packager at the dawn of reproducible builds in Arch.
Post by Simon van der Veldt
If you want to know more I'd suggest to try sending him an e-mail :)
I did three weeks ago.
--
https://sleepmap.de
Len Ovens
2017-12-07 00:10:09 UTC
Permalink
Post by David Runge
Post by Christopher Arndt
Post by David Runge
This actively keeps programs such as cadence to be integrated into
the
Post by David Runge
[community] repository in Arch, as I will not add flowcanvas back
Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its canvas.
According to its INSTALL file [1] claudia needs ladish. a2jmidid is an
optional dependency to cadence.
That is like saying jackd is an optional dependancy to Cadence. Unless
things have changed, there are many debian packages that end up with a
jackd2 dependancy and switching over to jackd1 is not trivial for many
people. Jackd2 also does not depend on a2jmidid, but there are some
applications that depend on jackd2 being able to access a2jmidid even if
it is not listed in the depends. If jackd1 is the goto... please make it
jackd3 and be done with it. Then depricate jackd2. Or roll the code into
jackd2 as well... I really don't care which.

In case you are wondering, installing jackd1 on a debian based machine
that already has jackd2 and other audio appliactions installed will first
remove jackd2 as well as all appliactions that depend on it and then
install jackd1. The user is left with the task of reinstalling their audio
sw... if that sw doesn't first remove jackd1 so it can drop jackd2 back
in place. Is the packaging clearly broken? Yes. Can it be fixed? Half the
problem is based on policy not code. (how long has Linux Sampler not been
in debian?)

--
Len Ovens
www.ovenwerks.net
David Runge
2017-12-07 01:05:43 UTC
Permalink
Post by Len Ovens
Post by David Runge
Post by Christopher Arndt
Post by David Runge
This actively keeps programs such as cadence to be integrated into
the
Post by David Runge
[community] repository in Arch, as I will not add flowcanvas back
Can you elaborate on that? AFAIK cadence/catia uses PyQt to draw its canvas.
According to its INSTALL file [1] claudia needs ladish. a2jmidid is an
optional dependency to cadence.
That is like saying jackd is an optional dependancy to Cadence. Unless
things have changed, there are many debian packages that end up with a
jackd2 dependancy and switching over to jackd1 is not trivial for many
jack{1,2} _is_ a dependency for cadence on a package and build level.
a2jmidid is a build and (packaging wise) optional dependency.

Maybe I should clarify:
I'm writing about requirements for packages.
This is basically a packaging problem, as I have to build and provide a
package in the main repositories for all build (and of course runtime)
dependencies of a program.
ladish and a2jmidid are runtime and/or build dependencies for cadence,
which means, if I want to push cadence (and all of its parts, i.e.
also claudia) to the main repositories, I have to package ladish as well
(which suffers from the aforementioned problems).
Post by Len Ovens
people. Jackd2 also does not depend on a2jmidid, but there are some
applications that depend on jackd2 being able to access a2jmidid even if it
is not listed in the depends. If jackd1 is the goto... please make it jackd3
and be done with it. Then depricate jackd2. Or roll the code into jackd2 as
well... I really don't care which.
AFAIK, jack2 is a reimplementation, with SMP support, so they are really
two different architectures, that implement the same API.
tbh, I always use jack2 though...
There is no way of merging the two.
Post by Len Ovens
In case you are wondering, installing jackd1 on a debian based machine that
already has jackd2 and other audio appliactions installed will first remove
jackd2 as well as all appliactions that depend on it and then install
jackd1. The user is left with the task of reinstalling their audio sw... if
that sw doesn't first remove jackd1 so it can drop jackd2 back in place. Is
the packaging clearly broken? Yes. Can it be fixed? Half the problem is
based on policy not code. (how long has Linux Sampler not been in debian?)
That luckily is not a problem with pacman on Arch Linux.
I've always found packaging in Debian (derivatives) to be too painful ;-)
--
https://sleepmap.de
Hermann Meyer
2017-12-07 03:42:31 UTC
Permalink
Post by Len Ovens
In case you are wondering, installing jackd1 on a debian based machine
that already has jackd2 and other audio appliactions installed will
first remove jackd2 as well as all appliactions that depend on it and
then install jackd1.
How to you come to this conclusion?
Debian provide a package (only documentation) jackd, this depend on
jackd1 | jackd2. Now, when you'll switch between jackd1 and jackd2, or
versa-vi, all you need to do is install the version you wont, the other
one will be removed within this step. Not a single jack aware app will
be removed during this step. All jack aware packages in debian list
both jackd versions as possible resolver.
I've done the switch often for testing purpose.
Simon van der Veldt
2017-12-06 20:18:44 UTC
Permalink
Post by David Runge
The source tarball download link, that I replaced in the PKGBUILD (see
first mail) went missing, as there was no web server running on gna.org
anymore.
Post by David Runge
Now I switched to the git repo mentioned in the same link, but the
tarball naming is not based on tags.
Post by David Runge
a2jmidid still works, but a flaky upstream is just not so nice to deal
with as a packager at the dawn of reproducible builds in Arch.

Ah, so that was the issue. Yeah, we ran into this issue as well. Using git
probably makes the most sense, or make use of your distro's mirror
functionality (I believe arch offers this as well, not sure though).
The tags do actually match with the releases and the tarball names, they
are just single integers. I.e. the link we had was "http://download.gna.org/
a2jmidid/a2jmidid-8.tar.bz2", which matches git tag 8.
For a list, see http://repo.or.cz/a2jmidid.git/refs, but you probably
already checked that.
Post by David Runge
On December 6, 2017 8:37:53 PM GMT+01:00, Simon van der Veldt <
Post by Simon van der Veldt
I sent Nedko a mail about 6 months ago asking similar questions, to
which
he kindly replied. The short version of the answer was no real plans
for
ladish, but he did want to bring the ladish site back up.
Hmm, that's too bad.
Post by Simon van der Veldt
I didn't ask anything regarding a2jmidid because it's been working
perfectly for me.
The source tarball download link, that I replaced in the PKGBUILD (see
first mail) went missing, as there was no web server running on gna.org
anymore.
Now I switched to the git repo mentioned in the same link, but the tarball
naming is not based on tags.
a2jmidid still works, but a flaky upstream is just not so nice to deal
with as a packager at the dawn of reproducible builds in Arch.
Post by Simon van der Veldt
If you want to know more I'd suggest to try sending him an e-mail :)
I did three weeks ago.
--
https://sleepmap.de
Loading...