I have another issue that I'm a bit confused about, so please lend me your wisdom.
The symphonic-mpd ships with the drivers of a certain DAC that uses ESS chips.
Interpreting the NDA as it stands, it seems to me that disclosing the source of the driver would be a problem.
On the other hand, drivers for some ESS chips are already included in the Linux kernel.
I just want to make sure that this is not an issue.
Have you seen any discussion anywhere about NDAs for ESS chips?
Please let me know.
The symphonic-mpd ships with the drivers of a certain DAC that uses ESS chips.
Interpreting the NDA as it stands, it seems to me that disclosing the source of the driver would be a problem.
On the other hand, drivers for some ESS chips are already included in the Linux kernel.
I just want to make sure that this is not an issue.
Have you seen any discussion anywhere about NDAs for ESS chips?
Please let me know.
The older version for RPi3 is already no longer supported, but some people have expressed a desire to continue using it.
Unfortunately, I'm not sure where the majority of the sources are located.
Is it possible to say "we can't provide the source, but only the binaries" in such cases?
If the user is okay with it, is there a problem?
Or, if I lose the source, can't I distribute binaries?
Unfortunately, I'm not sure where the majority of the sources are located.
Is it possible to say "we can't provide the source, but only the binaries" in such cases?
If the user is okay with it, is there a problem?
Or, if I lose the source, can't I distribute binaries?
I'm not sure but I would think that if you distribute a full image, you should also distribute the tools necessary to build it.
The normal way to do this is what all linux distributions do to build all their packages. You make some kind of script that:
1) installs all dependencies for building
2) downloads the sources from the official source and unpacks them
3) applies some patches to set options or modify some part of the code.
4) compiles the code
5) packages the result in some way (for example as an .rpm)
6) uploads the package somewhere (or just copies it somewhere you can access it)
What you need then is only the build script, the .patch files for modifying the sources, and any extra files that should be included. It's very convenient do do this in a Docker container, so add a Dockerfile as well.
Examples: alsa-lib for Arch:
PKGBUILD << trunk - svntogit/packages.git - Git clone of the 'packages' repository
Build script for complete Volumio image:
GitHub - volumio/Build: Buildscripts for Volumio System
I have only read a short discussion about this, don't remember where. There they thought that since the material that was under NDA was already generally available, it was ok to distribute sources that uses the information. As fas as I understand, pretty much all the distributions for the Pi have these sources published.
I would not publish these. But I would describe how to generate them in the documentation.
I think you can get away with distributing the obsolete binary if you publish the code for the current one.
This is a good reason for making scripts that generate reproducible builds, and then placing those scripts under version control (on Github for example). Then you never get these problems.
Good to see you intend to go for proper administration of your package papalius.
Tim from Moode also had to sort all that out, while his project was already out in the wild.
It's a hell of a job. People out there don't understand that 95% of such a project goes into the administration of data and user support.
So. As a hint. If you consider to continue the project you better automate most of the administrative tasks. It hurts once. It pays off a hundred times later on.
Good luck.
Tim from Moode also had to sort all that out, while his project was already out in the wild.
It's a hell of a job. People out there don't understand that 95% of such a project goes into the administration of data and user support.
So. As a hint. If you consider to continue the project you better automate most of the administrative tasks. It hurts once. It pays off a hundred times later on.
Good luck.
Thanks a lot, soundcheck.
I'll try to find some volunteers to help with the admin work. I may hire an engineer if needed.
I could do anything to improve the sound quality, but honestly, the admin work is, ... boring and painful, as I'm sure we all are.
I've already got a number of volunteers helping me run the forum, which makes it a lot easier than it used to be.
Thanks to all the members.
I'll try to find some volunteers to help with the admin work. I may hire an engineer if needed.
I could do anything to improve the sound quality, but honestly, the admin work is, ... boring and painful, as I'm sure we all are.
I've already got a number of volunteers helping me run the forum, which makes it a lot easier than it used to be.
Thanks to all the members.
yosioka/symphonic-mpd - Libraries.io
OLEDのスクリプト組み込み(関連プログラムのインストールが必要) * Issue #34 * papalius/symphonic-mpd * GitHub
Raspberry Pi Support Questions
If this is the same man, he already knows the github rule.
OLEDのスクリプト組み込み(関連プログラムのインストールが必要) * Issue #34 * papalius/symphonic-mpd * GitHub
Raspberry Pi Support Questions
If this is the same man, he already knows the github rule.
Last edited:
GitHub - papalius/symphonic-mpd
Four stars, not a single line of content. Just like the thread here...
Four stars, not a single line of content. Just like the thread here...
I know that some people can get satisfaction from putting others down.
Fortunately, I can get satisfaction in other ways.
Music, and DIY, is one of those things.
If making fun of me gives you enough pleasure to cover up ugly, twisted self...
Next you should pay attention to the words you choose to use.
It is a reflection of who you are.
Fortunately, I can get satisfaction in other ways.
Music, and DIY, is one of those things.
If making fun of me gives you enough pleasure to cover up ugly, twisted self...
Next you should pay attention to the words you choose to use.
It is a reflection of who you are.
Last edited:
It seems I am also entitled to join the club, but "unconditionally" and "if there is no problem" contradict.
Yes it takes time and isn't super fun. But it really pays off to do it. Try this: next time you compile something, just copy all the commands you type to a file. All of them, also simple ones like "cd ..". Then add "#!/bin/sh" at the top and make it executable. First build script ready
