LV2_blacklist.txt & Debian packaging improvements contributions
Hi GG, Phylis, Sam and all Now that things as settled around, and now that I'm good with the website French translation, I'm taking back the packaging of Cin-GG for my audio-linux debian-based distribution (and maybe later, a potential inclusion into Debian mainstream, but... one step after another). I've been doing a build with the last cin_5.1.20190430 and it seems to be successful so far. Doing that, I found a bunch of LV2 plugins which are avoided Cin to be launched and then, which needs to be added to the LV2_blacklist.txt file (after I did that locally, Cin is launching fine). Those following lines are the culprits: file:///usr/lib/lv2/MonoEffect.ingen/MonoEffect.ttl file:///usr/lib/lv2/MonoInstrument.ingen/MonoInstrument.ttl file:///usr/lib/lv2/StereoEffect.ingen/StereoEffect.ttl file:///usr/lib/lv2/StereoInstrument.ingen/StereoInstrument.ttl http://example.org/raffo http://www.wodgod.com/newtonator/1.0 https://sami.boukortt.com/plugins/intersect#Intersect https://sami.boukortt.com/plugins/intersect#SymmetricDifference https://sami.boukortt.com/plugins/intersect#Upmix Also, please, find attached an improved version for the ./blds/debian/control file which contains those improvements/changes: - I added a bit of description (then it looks better with the packages managers) - I improved the Maintainer field (changed the name from "mailing list" to "Cinelerra-GG devs") - I moved the Standard-version and the Homepage fields downer (standard good practice for Debian packaging) - Build-depends : -- 1 item per line (standard good practice for Debian packaging even if it doesn't change anything computer-side, it is easier to human-read) -- alphabetically ordered (standard good practice for Debian packaging too, easier for human-reading) -- removing of duplicates : libxft-dev, libxinerama-dev, and libxv-dev -- adding libusb-1.0-0-dev (the compilation failed here without it) I've got a few questions about the debian/control file which I'd like to have your dev's point of view here (I left those as-is for now waiting for your answers in case I'm missing something): - Build-depends field: -- why is inkscape needed for building ? It sounds like a mistake at a first glance. -- why is e2fsprogs needed ? For information, it contains those binaries : https://packages.debian.org/stretch-backports/amd64/e2fsprogs/filelist -- same for linux-firmware, why is that needed for building ? It doesn't even look to be in the Debian repository anymore - The "Standards-Version" number is currently defined to "5.1.20190430". It is not supposed to be the program version number (which is defined in the debian/changelog file), but a number matching a Debian standard. If you're OK with that, I would set it up to 3.9.8 which is the standard for Debian Stretch (current stable - Debian 9) and which will work as well for the next stable (Buster - Debian 10). I hope that helps. Thanks for your continuous work on cin-gg ! Cheers, Olivier PS: last but not least, I've send it to the mailing list as I did a few months ago back in the cin-cv times, but feel free to let me know if you would better like me to use the Mantis bug-tracker or any other way to contribute. I'm planning to send you other improvements/contributions on a next step. -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK
Olivier, it is going to take me some time to absorb all of this and have GG answer the Developer questions. Meanwhile, I will look at the parts that I can like the blacklist that I can do. I think the Mailing List is best for this kind of communication rather than MantisBT. BTW, yesterday we downloaded the "testing" version of Debian 10 and will try to do a build for that at the end of the month, due to a request in the comment on April News on the website. This is not what we would normally do but if someone takes the time to write about it, we should at least look at it. More later, Phyllis/GG On Fri, May 24, 2019 at 9:52 AM Olivier Humbert <[email protected]> wrote:
Hi GG, Phylis, Sam and all
Now that things as settled around, and now that I'm good with the website French translation, I'm taking back the packaging of Cin-GG for my audio-linux debian-based distribution (and maybe later, a potential inclusion into Debian mainstream, but... one step after another).
I've been doing a build with the last cin_5.1.20190430 and it seems to be successful so far.
Doing that, I found a bunch of LV2 plugins which are avoided Cin to be launched and then, which needs to be added to the LV2_blacklist.txt file (after I did that locally, Cin is launching fine). Those following lines are the culprits:
file:///usr/lib/lv2/MonoEffect.ingen/MonoEffect.ttl file:///usr/lib/lv2/MonoInstrument.ingen/MonoInstrument.ttl file:///usr/lib/lv2/StereoEffect.ingen/StereoEffect.ttl file:///usr/lib/lv2/StereoInstrument.ingen/StereoInstrument.ttl http://example.org/raffo http://www.wodgod.com/newtonator/1.0 https://sami.boukortt.com/plugins/intersect#Intersect https://sami.boukortt.com/plugins/intersect#SymmetricDifference https://sami.boukortt.com/plugins/intersect#Upmix
Also, please, find attached an improved version for the ./blds/debian/control file which contains those improvements/changes: - I added a bit of description (then it looks better with the packages managers) - I improved the Maintainer field (changed the name from "mailing list" to "Cinelerra-GG devs") - I moved the Standard-version and the Homepage fields downer (standard good practice for Debian packaging) - Build-depends : -- 1 item per line (standard good practice for Debian packaging even if it doesn't change anything computer-side, it is easier to human-read) -- alphabetically ordered (standard good practice for Debian packaging too, easier for human-reading) -- removing of duplicates : libxft-dev, libxinerama-dev, and libxv-dev -- adding libusb-1.0-0-dev (the compilation failed here without it)
I've got a few questions about the debian/control file which I'd like to have your dev's point of view here (I left those as-is for now waiting for your answers in case I'm missing something): - Build-depends field: -- why is inkscape needed for building ? It sounds like a mistake at a first glance. -- why is e2fsprogs needed ? For information, it contains those binaries : https://packages.debian.org/stretch-backports/amd64/e2fsprogs/filelist -- same for linux-firmware, why is that needed for building ? It doesn't even look to be in the Debian repository anymore - The "Standards-Version" number is currently defined to "5.1.20190430". It is not supposed to be the program version number (which is defined in the debian/changelog file), but a number matching a Debian standard. If you're OK with that, I would set it up to 3.9.8 which is the standard for Debian Stretch (current stable - Debian 9) and which will work as well for the next stable (Buster - Debian 10).
I hope that helps.
Thanks for your continuous work on cin-gg ! Cheers, Olivier
PS: last but not least, I've send it to the mailing list as I did a few months ago back in the cin-cv times, but feel free to let me know if you would better like me to use the Mantis bug-tracker or any other way to contribute. I'm planning to send you other improvements/contributions on a next step.
-- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Olivier: Now that things as settled around, and now that I'm good with the
website French translation, I'm taking back the packaging of Cin-GG for my audio-linux debian-based distribution (and maybe later, a potential inclusion into Debian mainstream, but... one step after another).
When you do get this packaged with audio-linux LibraZiK, it would be good to add this to cinelerra-gg.org same as AV Linux and Bodhi Linux.
Doing that, I found a bunch of LV2 plugins which are avoided Cin to be launched and then, which needs to be added to the LV2_blacklist.txt file (after I did that locally, Cin is launching fine). Those following lines are the culprits:
file:///usr/lib/lv2/MonoEffect.ingen/MonoEffect.ttl file:///usr/lib/lv2/MonoInstrument.ingen/MonoInstrument.ttl file:///usr/lib/lv2/StereoEffect.ingen/StereoEffect.ttl file:///usr/lib/lv2/StereoInstrument.ingen/StereoInstrument.ttl http://example.org/raffo http://www.wodgod.com/newtonator/1.0 https://sami.boukortt.com/plugins/intersect#Intersect https://sami.boukortt.com/plugins/intersect#SymmetricDifference https://sami.boukortt.com/plugins/intersect#Upmix
The latest GIT checkin a few minutes ago, includes the updated lv2_blacklist.txt with the first 4 lines BUT I could not test it. You already did so it should be fine. HOWEVER, I do not understand the last 5 URL lines. None of them worked for me and I am confused as to why they were included.
Also, please, find attached an improved version for the ./blds/debian/control file which contains those improvements/changes:
At the end of the month, GG is really pressed for time doing all of the distros. He is not very good at Debian system packaging/maintenance -- we work on Fedora. Today he is trying to jam in some changes that got put off while working on the update of OpenGL. We will save your "control" file and work on looking more carefully at your suggested improvements. He did take the time to evaluate it, found the duplicate libraries that your control file pointed out and the libusb missing one and alphabetized all of the dependencies to make it easier to find a specific one. The reason for not listing them one per line despite the fact that it is more human-readable is that just like cpu-s, memory, and disks, the *screen is a resource* -- most people do not think of that as such, but when you are working with several windows on several program routines simultaneously, you need space. So he really needs to see fewer lines to get to the one he needs to see. Also, time is a big factor and when he does all of the monthly builds, he uses *xen* and he has to edit a bunch of individual files before starting to get the builds to work and wants to quickly find the lines he has to modify in each. Their are some real experts on package control for all of the distros -- in the commercial world where he used to work, there was a "builder" who took care of all of this type of stuff. We are using bare bones / old stuff just to manage. Maybe some day, a Cinelerra builder will show up and take care of all of this!
-- why is inkscape needed for building ? It sounds like a mistake at a first glance.
There is a plugin called SVG for Inkscape so that is why it is needed.
-- why is e2fsprogs needed ?
We did not find the exact reason -- i think it is for mount bluray - I will see if I can find out for sure but at any rate he does not want to take it out until we are sure.
-- same for linux-firmware, why is that needed for building ?
The main reason for this is supposed to be OpenGL + the TV tuner _ hardware. I will look at this again too since you say it is not even in the Debian repository anymore.
- The "Standards-Version" number is currently defined to "5.1.20190430". It is not supposed to be the program version number (which is defined in the debian/changelog file), but a number matching a Debian standard. If you're OK with that, I would set it up to 3.9.8 which is the standard for Debian Stretch (current stable - Debian 9) and which will work as well for the next stable (Buster - Debian 10).
Every month when gg does a build for Debian, it errors out UNLESS he change the Standards-Version in the control file -- so we are surprised that he could put this at 3.9.8 and it would work, month after month. Again, this may be because of xen. Also, this is why he leaves this line at the beginning of the file -- to make it easy to find to change it. Thanks for all of your input. If I find out anything more, I will let you know. gg/Phyllis
Hi Phyllis, Le 2019-05-29 01:50, Phyllis Smith a écrit :
Now that things as settled around, and now that I'm good with the website French translation, I'm taking back the packaging of Cin-GG for my audio-linux debian-based distribution (and maybe later, a potential inclusion into Debian mainstream, but... one step after another).
When you do get this packaged with audio-linux LibraZiK, it would be good to add this to cinelerra-gg.org [1] same as AV Linux and Bodhi Linux.
OK, I'll let you know when it'll leave the testing phase and enter the users' repo.
Doing that, I found a bunch of LV2 plugins which are avoided Cin to be launched and then, which needs to be added to the LV2_blacklist.txt file (after I did that locally, Cin is launching fine). Those following lines are the culprits:
file:///usr/lib/lv2/MonoEffect.ingen/MonoEffect.ttl file:///usr/lib/lv2/MonoInstrument.ingen/MonoInstrument.ttl file:///usr/lib/lv2/StereoEffect.ingen/StereoEffect.ttl file:///usr/lib/lv2/StereoInstrument.ingen/StereoInstrument.ttl http://example.org/raffo http://www.wodgod.com/newtonator/1.0 https://sami.boukortt.com/plugins/intersect#Intersect https://sami.boukortt.com/plugins/intersect#SymmetricDifference https://sami.boukortt.com/plugins/intersect#Upmix
The latest GIT checkin a few minutes ago, includes the updated lv2_blacklist.txt with the first 4 lines BUT I could not test it. You already did so it should be fine.
OK.
HOWEVER, I do not understand the last 5 URL lines. None of them worked for me and I am confused as to why they were included.
I'm unsure what you mean here while writing they didn't worked ? I'm assuming you're meaning that you tried to enter the url in a browser. If this assumption is wrong, please correct me. Whether or not they are opening a web page when entered in a browser isn't very relevant for our purpose. To the LV2 stack, they are used as URIs, meaning lilv is using those URI (starting with http, https, file,...) as an unique identifier for a plugin. They are identifier for the following LV2 plugins: - https://github.com/nicoroulet/moog/ - http://newtonator.sourceforge.net/ - and https://github.com/sboukortt/intersect-lv2 I've got them installed here on my LibraZiK-2, and if I'm launching cin without blacklisting those URIs, then the LV2 check step fails which lead to cin not being launched. That's a big issue since I'm can still patch the LV2_blacklist.txt for my LibraZiK-2 package and I'll be good. That said I'd strongly recommend them being added to the cin repo LV2_blacklist.txt because it's likely to be a blocker (read: unable to launch cin) for anyone on any system with one of those plugins installed.
Also, please, find attached an improved version for the ./blds/debian/control file which contains those improvements/changes:
At the end of the month, GG is really pressed for time doing all of the distros. He is not very good at Debian system packaging/maintenance -- we work on Fedora. Today he is trying to jam in some changes that got put off while working on the update of OpenGL. We will save your "control" file and work on looking more carefully at your suggested improvements. He did take the time to evaluate it, found the duplicate libraries that your control file pointed out and the libusb missing one and alphabetized all of the dependencies to make it easier to find a specific one.
OK, nice.
The reason for not listing them one per line despite the fact that it is more human-readable is that just like cpu-s, memory, and disks, the SCREEN IS A RESOURCE -- most people do not think of that as such, but when you are working with several windows on several program routines simultaneously, you need space. So he really needs to see fewer lines to get to the one he needs to see. Also, time is a big factor and when he does all of the monthly builds, he uses _xen_ and he has to edit a bunch of individual files before starting to get the builds to work and wants to quickly find the lines he has to modify in each.
OK, fair enough.
Their are some real experts on package control for all of the distros -- in the commercial world where he used to work, there was a "builder" who took care of all of this type of stuff. We are using bare bones / old stuff just to manage. Maybe some day, a Cinelerra builder will show up and take care of all of this!
I don't want to be looking arrogant enough to consider myself as a "debian packaging expert", but just letting you know that I've got >200 debian packages that I'm working on for my LibraZiK-2 project, plus I'm contributing to a few Debian packages in the official Debian repo where/when I can.
-- why is inkscape needed for building ? It sounds like a mistake at a first glance.
There is a plugin called SVG for Inkscape so that is why it is needed.
I'm not 100% sure of this here. Let me rephrase it my thought: I'm questionning myself if: 1) inkscape is need to build Cin, or 2) if inkscape is need to run Cin. If you tell me that Inkscape is needed to *build* the cin SVG plugin, then OK we're fine, I get it. But if you're telling me that inkscape is needed to run the cin SVG plugin when using cin, then there is a modification to do in the cin debian packaging script since *build-dependencies* aren't considered the same from the debian/control point of view. Please let me know.
-- why is e2fsprogs needed ?
We did not find the exact reason -- i think it is for mount bluray - I will see if I can find out for sure
OK, let me know when you find out (with the same as above regarding: *build* dependency or *runtime* dependency?)
but at any rate he does not want to take it out until we are sure.
Neither I do.
-- same for linux-firmware, why is that needed for building ?
The main reason for this is supposed to be OpenGL + the TV tuner _ hardware. I will look at this again too since you say it is not even in the Debian repository anymore.
OK, thanks. Same as above (*build* or *runtime* dependency? )
- The "Standards-Version" number is currently defined to "5.1.20190430". It is not supposed to be the program version number (which is defined in the debian/changelog file), but a number matching a Debian standard. If you're OK with that, I would set it up to 3.9.8 which is the standard for Debian Stretch (current stable - Debian 9) and which will work as well for the next stable (Buster - Debian 10).
Every month when gg does a build for Debian, it errors out UNLESS he change the Standards-Version in the control file -- so we are surprised that he could put this at 3.9.8 and it would work, month after month. Again, this may be because of xen. Also, this is why he leaves this line at the beginning of the file -- to make it easy to find to change it.
Please, not that this isn't a big deal from my side since I'm changing it when packaging it for LZK-2. Something sounds to be strange here. You can find more info here: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-standards...
Thanks for all of your input. If I find out anything more, I will let you know.
Thank you too, Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK
Olivier: still have a lot of issues that need addressing but GG found an OpenGL error with masking that is driving him crazy. A little bit of feedback:
HOWEVER, I do not understand the last 5 URL lines. None of them
worked for me and I am confused as to why they were included.
I'm unsure what you mean here while writing they didn't worked ? I'm assuming you're meaning that you tried to enter the url in a browser.
Duh... is on me!! I never could understand why the LV2 gurus put http for the file name. I will fix lv2_blacklist.txt with these 5 added. Because they showed up as blue links in my gmail email, I clicked on them and they looked different than the other LV2 plugins so I got confused.
I don't want to be looking arrogant enough to consider myself as a "debian packaging expert", but just letting you know that I've got >200 debian packages that I'm working on for my LibraZiK-2 project, plus I'm contributing to a few Debian packages in the official Debian repo where/when I can.
I would have to call you an expert for sure. Still looking at figuring out the need for Inkscape, fs2progs, and linux-firmware definitively. And the strangeness of Standards-Version needing to be changed monthly -- it would be much more convenient if he did not have to change it. Phyllis
Le 2019-05-29 20:12, Phyllis Smith a écrit :
Olivier: still have a lot of issues that need addressing but GG found an OpenGL error with masking that is driving him crazy.
Seems important!
A little bit of feedback:
HOWEVER, I do not understand the last 5 URL lines. None of them worked for me and I am confused as to why they were included.
I'm unsure what you mean here while writing they didn't worked ? I'm assuming you're meaning that you tried to enter the url in a browser.
Duh... is on me!! I never could understand why the LV2 gurus put http for the file name.
AFAIK, it is not compulsory to use http as an identifier, but most of the LV2 devs are doing this way, because the URL used is usually pointing to online documentation.
I will fix lv2_blacklist.txt with these 5 added. Because they showed up as blue links in my gmail email, I clicked on them and they looked different than the other LV2 plugins so I got confused.
OK. Good.
I don't want to be looking arrogant enough to consider myself as a "debian packaging expert", but just letting you know that I've got
200 debian packages that I'm working on for my LibraZiK-2 project, plus I'm contributing to a few Debian packages in the official Debian repo where/when I can.
I would have to call you an expert for sure.
Please, don't since it would put too much pressure on my shoulders!
Still looking at figuring out the need for Inkscape, fs2progs, and linux-firmware definitively.
OK. I'll wait quietly till you get time to check all of that and come back to me. No hurry from my side that being said. Just trying to contribute some little thing I can do to the project.
And the strangeness of Standards-Version needing to be changed monthly -- it would be much more convenient if he did not have to change it.
OK. Cheers, Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a0000053625 Mastodon : https://mastodon.xyz/@LibraZiK
participants (2)
-
Olivier Humbert -
Phyllis Smith