[MacPorts] #13848: esound library routine incorrectly identifies DISPLAY on Leopard (fwd)

[robert delius royar]

Because esound has no maintainer, I am copying this ticket to the 
developers' list. 
-- Forwarded message --

Date: Sun, 06 Jan 2008 13:57:41 -
From: MacPorts <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: [MacPorts] #13848: esound library routine incorrectly identifies
DISPLAY on Leopard
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"

#13848: esound library routine incorrectly identifies DISPLAY on Leopard
--+-
 Reporter:  [EMAIL PROTECTED]  |   Owner:  [EMAIL PROTECTED]
 Type:  defect|  Status:  new
 Priority:  High  |   Milestone:
Component:  ports | Version:  1.6.0
 Keywords:  audio esound  |
--+-
 Running Leopard's X11.app the audio/esound port cannot any longer deal
 with a request to play sound on a local machine when code passes the NULL
 parameter to identify the desired server to the esdlib.c library
 functions.  The function esd_open_sound expects a DISPLAY variable to be
 something such as 0:0.  Leopard uses a different scheme.  esd_open_sound
 cannot see DISPLAYs such as /tmp/launch-A6wxg2/:0 as valid.  I have a
 patch that works, but I am not a programmer.  Soemone who understands a
 better way to determine whether the code is running under Leopard should
 fix this.  I have attached my patch.

 This port is not maintained.

--
Ticket URL: 
MacPorts 
Ports system for Mac OS
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32446] trunk/dports/sysutils/rpm-devel/Portfile

[Markus Weissmann]

On 5 Jan 2008, at 22:42, Ryan Schmidt wrote:


On Jan 3, 2008, at 05:11, Anders F Björklund wrote:


Ryan Schmidt wrote:

Perhaps, but these -devel ports usally build from tip of trunk so  
they all had revision "0"...


Ports should never build from tip of trunk or HEAD or similar  
concepts.


These do.


But that's not reproducible, and I thought we always wanted that. If  
I install a specific version of a port today, I should get the same  
software if I install that same version of that port tomorrow. By  
fetching from HEAD, you break that assumption.


Not sure what the alternative would be, should I set up a cron job  
to commit a Portfile daily ?


I see for example that Markus commits a new version of gcc43 every  
week or so. I hope he tests it before committing, however.




I do.


Regards,

-Markus

--
Dipl. Inf. (FH) Markus W. Weissmann
http://www.macports.org/
http://www.mweissmann.de/

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32446] trunk/dports/sysutils/rpm-devel/Portfile

[Landon Fuller]

On Jan 5, 2008, at 1:42 PM, Ryan Schmidt wrote:



On Jan 3, 2008, at 05:11, Anders F Björklund wrote:


Ryan Schmidt wrote:

Perhaps, but these -devel ports usally build from tip of trunk so  
they all had revision "0"...


Ports should never build from tip of trunk or HEAD or similar  
concepts.


These do.


But that's not reproducible, and I thought we always wanted that. If  
I install a specific version of a port today, I should get the same  
software if I install that same version of that port tomorrow. By  
fetching from HEAD, you break that assumption.


This is why I've thought we should not support CVS/SVN fetching in any  
form -- No checksums, no guaranteed reproducibility.___

macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32446] trunk/dports/sysutils/rpm-devel/Portfile

[Anders F Björklund]

Landon Fuller wrote:

But that's not reproducible, and I thought we always wanted that. If 
I install a specific version of a port today, I should get the same 
software if I install that same version of that port tomorrow. By 
fetching from HEAD, you break that assumption.


This is why I've thought we should not support CVS/SVN fetching in any 
form -- No checksums, no guaranteed reproducibility.


Specifying a revision should be reproducible (not verifiably so but), 
but I'll switch to tarball snapshots...


Or delete the ports, whichever works. ("port not found" is guaranteed 
to be reproducible every single time)


--anders

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [32446] trunk/dports/sysutils/rpm-devel/Portfile

[Markus Weissmann]

On 6 Jan 2008, at 21:20, Anders F Björklund wrote:


Landon Fuller wrote:

But that's not reproducible, and I thought we always wanted that.  
If I install a specific version of a port today, I should get the  
same software if I install that same version of that port  
tomorrow. By fetching from HEAD, you break that assumption.


This is why I've thought we should not support CVS/SVN fetching in  
any form -- No checksums, no guaranteed reproducibility.


Specifying a revision should be reproducible (not verifiably so  
but), but I'll switch to tarball snapshots...


Or delete the ports, whichever works. ("port not found" is  
guaranteed to be reproducible every single time)





Imho -- at least for "-devel" ports -- cvs/svn fetching is o.k. if at  
least a date -- in the past ;) -- is supplied. Avoid it if possible,  
but if it leads to you generating weekly snapshots from some  
repository, just use cvs/svn fetching.



Regards,

-Markus

--
Dipl. Inf. (FH) Markus W. Weissmann
http://www.macports.org/
http://www.mweissmann.de/

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev