• The Vendor's Bazaar forum is for commercial offers and transactions. Only unmoderated members can post here.

    diyAudio provides this forum for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members. Use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

symphonic-mpd

Jump to Latest
#261
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.
 
#262
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?
 
#263
papalius said:
Can you give us some ideas for publishing the source on github?

Suppose you are changing the build options for a package with a Linux distribution built in.
Disabling unnecessary features and changing performance options are commonplace.

Nonetheless, I haven't seen any documentation or build scripts on github that show what options you built with.
If you have a github project that would be helpful, can you point me to it?

Can I interpret the build method as superfluous and not necessary to upload it to github?
Click to expand...
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
 
#264
papalius said:
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.
Click to expand...
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.
 
#266
papalius said:
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?
Click to expand...
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.
 
#268
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.
 
#270
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.
 
#273
papalius said:
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.
Click to expand...

Better thank in your closed forum - not many members here?

//
 
#274
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.
 
Last edited:
#275
kubotayo said:
I'm a member of SMPD forum group that is trying to internationalize SMPD.
Anyone who writes in this thread is unconditionally admitted as a member. If you are interested in SMPD even if you haven't written in this thread, please send me an email with the reason why you are interested in SMPD. If there is no problem, I would like to approve it. As Papalius' first message says, my email address is "kubotayo@jcom.home.ne.jp
Click to expand...


It seems I am also entitled to join the club, but "unconditionally" and "if there is no problem" contradict.
 
#276
papalius said:
Thank you very much, HenrikEnquist.

Most of my questions have been answered.
The build script will take some time to create, so I'll start with what I can.
Click to expand...
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 🙂
 
#277
papalius said:
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.
Click to expand...

Be sure they where carefully chosen.

//
 
You must log in or register to reply here.
Top Bottom