Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Csete oz9...@gmail.com wrote: On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete oz9...@gmail.com wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? Done. Thanks! As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Maybe as compromise we can remove all optional dependencies except rtl-sdr and uhd. That would provide a good default for 95% of the users today and only require rtl-sdr as extra package since the gnuradio recipe already depends on uhd. Alex I can see that, especially since we have uhd as a dep for gnuradio, too. Also, rtl-sdr is lightweight and only depends on libusb, so it's a pretty safe one to install. And yeah, I agree, that takes care of most people's needs right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On 07/29/2013 11:10 AM, Tom Rondeau wrote: On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Cseteoz9...@gmail.com wrote: On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeaut...@trondeau.com wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Cseteoz9...@gmail.com wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? Done. Thanks! As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Maybe as compromise we can remove all optional dependencies except rtl-sdr and uhd. That would provide a good default for 95% of the users today and only require rtl-sdr as extra package since the gnuradio recipe already depends on uhd. Alex I can see that, especially since we have uhd as a dep for gnuradio, too. Also, rtl-sdr is lightweight and only depends on libusb, so it's a pretty safe one to install. And yeah, I agree, that takes care of most people's needs right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio rtl-sdr is just the device-driver library for RTL dongles. You need gr-osmosdr as well. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Mon, Jul 29, 2013 at 11:16 AM, Marcus D. Leech mle...@ripnet.com wrote: On 07/29/2013 11:10 AM, Tom Rondeau wrote: On Sun, Jul 28, 2013 at 6:40 PM, Alexandru Cseteoz9...@gmail.com wrote: On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeaut...@trondeau.com wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Cseteoz9...@gmail.com wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? Done. Thanks! As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Maybe as compromise we can remove all optional dependencies except rtl-sdr and uhd. That would provide a good default for 95% of the users today and only require rtl-sdr as extra package since the gnuradio recipe already depends on uhd. Alex I can see that, especially since we have uhd as a dep for gnuradio, too. Also, rtl-sdr is lightweight and only depends on libusb, so it's a pretty safe one to install. And yeah, I agree, that takes care of most people's needs right now. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio rtl-sdr is just the device-driver library for RTL dongles. You need gr-osmosdr as well. The debate is whether or not to include rtl-sdr and uhd as dependencies to gr-osmosdr. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On 07/29/2013 11:26 AM, Tom Rondeau wrote: The debate is whether or not to include rtl-sdr and uhd as dependencies to gr-osmosdr. Tom I'll just, um, just go crawl back into my cave, and perhaps increase the caffeine dose -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Fri, Jul 26, 2013 at 4:27 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete oz9...@gmail.com wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? Done. As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Maybe as compromise we can remove all optional dependencies except rtl-sdr and uhd. That would provide a good default for 95% of the users today and only require rtl-sdr as extra package since the gnuradio recipe already depends on uhd. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
On Thu, Jul 25, 2013 at 7:28 AM, Alexandru Csete oz9...@gmail.com wrote: Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Alex, Thanks for the report and all of the patches you submitted to PyBOMBS. It's a new project and will definitely need wide-spread testing and help to get working well on various systems and for various needs. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? The 'recommends' is a very interesting idea. I'm not sure I like forcing the installation of all of the base drivers for gr-osmosdr, but if we have a menu-driven section if the dependencies are recommended and allow the user to select which, if any, to also install, that'd be great. Would you open a feature issue on the PyBOMBS Redmine page suggesting this? As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. I'm not sure, either. Until we figure out a concept like the recommendations, my preference is to not include them as dependencies, but I could be persuaded out of that thought. I'm guessing Philip would argue for a meta-layer :) Otherwise I found pybombs to be very easy to use and provide sufficient flexibility for me to replace my own build-gnuradio scripts for managing multiple installations of gnuradio. Alex Thanks again! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PyBOMBS: First impressions and optional dependencies
Greetings, Yesterday, I started playing with pybombs and fixed a few recipes related to gr-osmosdr. During this process I made gr-osmosdr depend on uhd, rtl-sdr, osmo-sdr, hackrf and gr-iqbal. I did this to ensure that all supported input devices are made available to users. It should be noted that all these packages are optional and gr-osmosdr would work just fine with gnuradio as the only dependency still supporting funcube dongles and I/Q file sources. Later I will be adding a recipe for the gr-fcdproplus OOT source block and add that as a gr-osmosdr dependency as well. This works well for now since all these driver libraries are recent and well maintained. However, as time goes this driver list will grow and the risk of something breaking will increase. This made me think whether there may be a need for a weaker dependency specification, something like the recommends section in deb packages or the variant in macports? As an alternate solution here now, we could just remove all optional dependencies from the gr-osmosdr recipe and instruct users to install their preferred driver libraries prior to installing gr-osmosdr. Or create meta-recipes that would provide the most common combinations. I don't know what would be the best solution. Otherwise I found pybombs to be very easy to use and provide sufficient flexibility for me to replace my own build-gnuradio scripts for managing multiple installations of gnuradio. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
