Re: Radio Tray
On Wed, Dec 10, 2014 at 10:42:51PM +, Fred wrote: > Ping? Damn, i thought this was imported ... can anyone import it with my ok; or ok it so i'll import it ? Landry > On 11/26/14 21:57, Fred wrote: > >On 11/24/14 15:01, Landry Breuil wrote: > > > >> > >>Ive played with it a bit, it really doesnt like when a radio is > >>missing... timeouts after a while, then gets a SIGBUS here. Try it with > >>Country/US 181.. Techno/Drone Zone works fine for example. > > > >I think the bug may have been caused by a typo in > >AudioPlayerGStreamer.py - this is fixed by a new patch - the up stream > >code has already had this issue fixed - but they have not released a new > >version. > > > >I was unable to reproduce the error on amd64, i386 and macppc. > > > >Attached is an updated port. > > > >Tests and comments welcomed :~) > > > >Cheers > > > >Fred >
Re: Radio Tray
Ping? On 11/26/14 21:57, Fred wrote: On 11/24/14 15:01, Landry Breuil wrote: Ive played with it a bit, it really doesnt like when a radio is missing... timeouts after a while, then gets a SIGBUS here. Try it with Country/US 181.. Techno/Drone Zone works fine for example. I think the bug may have been caused by a typo in AudioPlayerGStreamer.py - this is fixed by a new patch - the up stream code has already had this issue fixed - but they have not released a new version. I was unable to reproduce the error on amd64, i386 and macppc. Attached is an updated port. Tests and comments welcomed :~) Cheers Fred
Re: Radio Tray
On Wed, Nov 26, 2014 at 09:57:32PM +, Fred wrote: > On 11/24/14 15:01, Landry Breuil wrote: > > > > >Ive played with it a bit, it really doesnt like when a radio is > >missing... timeouts after a while, then gets a SIGBUS here. Try it with > >Country/US 181.. Techno/Drone Zone works fine for example. > > I think the bug may have been caused by a typo in AudioPlayerGStreamer.py - > this is fixed by a new patch - the up stream code has already had this issue > fixed - but they have not released a new version. > > I was unable to reproduce the error on amd64, i386 and macppc. > > Attached is an updated port. > > Tests and comments welcomed :~) Yeah, much better here - ok for me if anyone wants to import it. Landry
Re: Radio Tray
On 11/24/14 15:01, Landry Breuil wrote: Ive played with it a bit, it really doesnt like when a radio is missing... timeouts after a while, then gets a SIGBUS here. Try it with Country/US 181.. Techno/Drone Zone works fine for example. I think the bug may have been caused by a typo in AudioPlayerGStreamer.py - this is fixed by a new patch - the up stream code has already had this issue fixed - but they have not released a new version. I was unable to reproduce the error on amd64, i386 and macppc. Attached is an updated port. Tests and comments welcomed :~) Cheers Fred radiotray.tar.gz Description: application/gzip
Re: Radio Tray
On 2014/11/24 23:36, Landry Breuil wrote:
> On Mon, Nov 24, 2014 at 08:52:21PM +, Fred wrote:
> > On 11/24/14 15:01, Landry Breuil wrote:
> > >On Mon, Nov 24, 2014 at 02:50:06PM +, Fred wrote:
> > >>On 11/22/14 07:55, Landry Breuil wrote:
> > >>>On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
> > Hi Ports@
> >
> > Attached is a port for radio tray an online radio streaming app.
> >
> > I have tested it on i386 and amd64.
> > >>>
> > >>>Some comments:
> > >>>- why hardcoding the python version ?
> > >>
> > >>This confused me a bit - I'm not sure where I have hard coded the python
> > >>version.
> > >
> > >MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> > >
> > >You should only use it if you have a reason..
> >
> > So it's not needed if the code does not work with Python 3?
>
> No reason to prevent it from working someday, even if upstream
> development is dormant, a future release might make this work. And given
> that if imported, no python3 flavor would be linked to the tree, one
> would have to manually set MODPY_VERSION to try building it with py3.
> I'm not sure we have a policy on that, but i just find it wrong to force
> MODPY_VERSION.
Python is not backwards compatible i.e. almost no python2 programs are
likely to work with a 3.x version unless special care was taken to support
both versions when writing them. The common situation for the majority
of Python programs is that they won't work with v3 at all.
As far as ports goes, even for a program which supports v2 and v3, we
can't build a py3 version without PLIST changes, just changing the default
MODPY_VERSION version won't make it work.
When python3 becomes the common case, we'd probably want to change the
default in python.port.mk without breaking the rest of the tree, so we'd
need a marker like this.
So while it isn't necessary at the moment, we could add these as markers
when we know that a port definitely isn't ready for py3.x, it will save
time when sweeping the tree later. Then we have four possible states:
no marker at all -> "don't know, hasn't been tested".
MODPY_DEFAULT_VERSION_2 -> "known to be v2 only".
MODPY_DEFAULT_VERSION_3 -> "known to be v3 only".
py3 FLAVOR/PLIST scaffolding -> "known to work with both".
Re: Radio Tray
On Mon, Nov 24, 2014 at 08:52:21PM +, Fred wrote:
> On 11/24/14 15:01, Landry Breuil wrote:
> >On Mon, Nov 24, 2014 at 02:50:06PM +, Fred wrote:
> >>On 11/22/14 07:55, Landry Breuil wrote:
> >>>On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
> Hi Ports@
>
> Attached is a port for radio tray an online radio streaming app.
>
> I have tested it on i386 and amd64.
> >>>
> >>>Some comments:
> >>>- why hardcoding the python version ?
> >>
> >>This confused me a bit - I'm not sure where I have hard coded the python
> >>version.
> >
> >MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
> >
> >You should only use it if you have a reason..
>
> So it's not needed if the code does not work with Python 3?
No reason to prevent it from working someday, even if upstream
development is dormant, a future release might make this work. And given
that if imported, no python3 flavor would be linked to the tree, one
would have to manually set MODPY_VERSION to try building it with py3.
I'm not sure we have a policy on that, but i just find it wrong to force
MODPY_VERSION.
Landry
Re: Radio Tray
On 11/24/14 15:01, Landry Breuil wrote:
On Mon, Nov 24, 2014 at 02:50:06PM +, Fred wrote:
On 11/22/14 07:55, Landry Breuil wrote:
On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
Hi Ports@
Attached is a port for radio tray an online radio streaming app.
I have tested it on i386 and amd64.
Some comments:
- why hardcoding the python version ?
This confused me a bit - I'm not sure where I have hard coded the python
version.
MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
You should only use it if you have a reason..
So it's not needed if the code does not work with Python 3?
Ive played with it a bit, it really doesnt like when a radio is
missing... timeouts after a while, then gets a SIGBUS here. Try it with
Country/US 181.. Techno/Drone Zone works fine for example.
I'll have take look.
Other than that, looks good to me if anyone wants to import it.
Landry
Cheers
Fred
Re: Radio Tray
On Mon, Nov 24, 2014 at 02:50:06PM +, Fred wrote:
> On 11/22/14 07:55, Landry Breuil wrote:
> >On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
> >>Hi Ports@
> >>
> >>Attached is a port for radio tray an online radio streaming app.
> >>
> >>I have tested it on i386 and amd64.
> >
> >Some comments:
> >- why hardcoding the python version ?
>
> This confused me a bit - I'm not sure where I have hard coded the python
> version.
MODPY_VERSION = ${MODPY_DEFAULT_VERSION_2}
You should only use it if you have a reason..
Ive played with it a bit, it really doesnt like when a radio is
missing... timeouts after a while, then gets a SIGBUS here. Try it with
Country/US 181.. Techno/Drone Zone works fine for example.
Other than that, looks good to me if anyone wants to import it.
Landry
Re: Radio Tray
On 11/22/14 07:55, Landry Breuil wrote:
On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
Hi Ports@
Attached is a port for radio tray an online radio streaming app.
I have tested it on i386 and amd64.
Some comments:
- why hardcoding the python version ?
This confused me a bit - I'm not sure where I have hard coded the python
version.
- you should RDEP on desktop-file-utils and add the @exec/@unexec lines
to PLIST
Done
- as for the datadir setting, it's nice to detect openbsd but you dont
need import platform, os.uname()[0] does the same thing. Do you plan
to send this patch upstream ?
I've sent a patch upstream.
- you shouldnt have FULLPKGNAME in PLIST, it'll break if revision is
set. make update-plist sucks at that, but
radiotray-${MODPY_EGG_VERSION} should be used
Done
Attached is the update version of the port - I have now test on amd64,
i386 and macppc.
Cheers
Fred
radiotray.tar.gz
Description: application/gzip
Re: Radio Tray
On 11/22/14 07:55, Landry Breuil wrote:
On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
Hi Ports@
Attached is a port for radio tray an online radio streaming app.
I have tested it on i386 and amd64.
Some comments:
- why hardcoding the python version ?
- you should RDEP on desktop-file-utils and add the @exec/@unexec lines
to PLIST
- as for the datadir setting, it's nice to detect openbsd but you dont
need import platform, os.uname()[0] does the same thing. Do you plan
to send this patch upstream ?
- you shouldnt have FULLPKGNAME in PLIST, it'll break if revision is
set. make update-plist sucks at that, but
radiotray-${MODPY_EGG_VERSION} should be used
Landry
Hi,
Thanks for the comments - I'll fix it up and resubmit.
I'll submit my patches upstream, but the project has not had much
activity in the last year.
Cheers
Fred
Re: Radio Tray
On Sat, Nov 22, 2014 at 12:34:40AM +, Fred wrote:
> Hi Ports@
>
> Attached is a port for radio tray an online radio streaming app.
>
> I have tested it on i386 and amd64.
Some comments:
- why hardcoding the python version ?
- you should RDEP on desktop-file-utils and add the @exec/@unexec lines
to PLIST
- as for the datadir setting, it's nice to detect openbsd but you dont
need import platform, os.uname()[0] does the same thing. Do you plan
to send this patch upstream ?
- you shouldnt have FULLPKGNAME in PLIST, it'll break if revision is
set. make update-plist sucks at that, but
radiotray-${MODPY_EGG_VERSION} should be used
Landry
