March 2009 - macports-tickets - lists.macosforge.org

Re: [MacPorts] #14986: port activate keeps waiting for lock on file_map.db
by MacPorts 07 Mar '09

07 Mar '09

#14986: port activate keeps waiting for lock on file_map.db ----------------------------------+----------------------------------------- Reporter: paulbeard@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.6.0 Resolution: worksforme | Keywords: Port: | ----------------------------------+----------------------------------------- Changes (by jmr@…): * status: new => closed * resolution: => worksforme Comment: No response, and everyone else seems to always to have another instance running. -- Ticket URL: <http://trac.macports.org/ticket/14986#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #5063: RFE: sped up dependency searching and added dependent finding
by MacPorts 07 Mar '09

07 Mar '09

#5063: RFE: sped up dependency searching and added dependent finding ------------------------------------+--------------------------------------- Reporter: erickt@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts Future Component: base | Version: Resolution: fixed | Keywords: Port: | ------------------------------------+--------------------------------------- Changes (by jmr@…): * cc: erickt@… (added) * status: new => closed * resolution: => fixed Old description: > Hello All, > > I whipped up a little patch to darwinports to figure out what packages > depend on a particular port > (opposite to the deps command). This allows some nice things. In > addition, I've added a mode -R to the > upgrade command that if specified, should rebuild all of the ports that > depend on the one we're > upgrading. I could also see having something similar to be added to the > uninstall, but I haven't gotten > around to that yet. > > Finally, in order to make this usable, I had to speed up the loading of > the portindex file. Previously, > each time you did a dportsearch, each source file would have to be > walked. Since I have to build a list of > all the dependencies, I had to walk each file for each installed port. So > to optimize this, I read each file > once, and throw all the results into an array. All my testing appeared > that this provided the same > functionality, but I'm not sure if some other command modifies these > files while port is running, so it'd > break that functionality. > > I've attached diffs for port.tcl and darwinports.tcl. Thanks! > > -e New description: Hello All, I whipped up a little patch to darwinports to figure out what packages depend on a particular port (opposite to the deps command). This allows some nice things. In addition, I've added a mode -R to the upgrade command that if specified, should rebuild all of the ports that depend on the one we're upgrading. I could also see having something similar to be added to the uninstall, but I haven't gotten around to that yet. Finally, in order to make this usable, I had to speed up the loading of the portindex file. Previously, each time you did a dportsearch, each source file would have to be walked. Since I have to build a list of all the dependencies, I had to walk each file for each installed port. So to optimize this, I read each file once, and throw all the results into an array. All my testing appeared that this provided the same functionality, but I'm not sure if some other command modifies these files while port is running, so it'd break that functionality. I've attached diffs for port.tcl and darwinports.tcl. Thanks! -e -- Comment: It looks like everything applicable here has been done. -- Ticket URL: <http://trac.macports.org/ticket/5063#comment:23> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #8431: BUG: port uninstall can't resolve dependencies
by MacPorts 07 Mar '09

07 Mar '09

#8431: BUG: port uninstall can't resolve dependencies --------------------------------------+------------------------------------- Reporter: namely_void@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: Resolution: | Keywords: Port: | --------------------------------------+------------------------------------- Changes (by jmr@…): * priority: High => Normal -- Ticket URL: <http://trac.macports.org/ticket/8431#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

[MacPorts] #17367: port tries to deactivate wrong version on upgrade
by MacPorts 07 Mar '09

07 Mar '09

#17367: port tries to deactivate wrong version on upgrade -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts base bugs Component: base | Version: 1.7.0 Keywords: | Port: -------------------------------------+-------------------------------------- This is with MacPorts from trunk @42527 on Mac OS X 10.4.11 Intel with Xcode 2.5: {{{ $ port installed freetype The following ports are currently installed: freetype @2.3.7_1+doc+universal (active) freetype @2.3.7_1+universal $ port upgrade freetype ---> Fetching freetype ---> Verifying checksum(s) for freetype ---> Extracting freetype ---> Applying patches to freetype ---> Configuring freetype ---> Building freetype ---> Staging freetype into destroot ---> Deactivating freetype @2.3.7_1+universal Error: Deactivating freetype 2.3.7_1 failed: Active version of freetype is not 2.3.7_1+universal but 2.3.7_1+doc+universal. $ }}} -- Ticket URL: <http://trac.macports.org/ticket/17367> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #16454: Fail to set time in many directories and "%% port" is not being recognized
by MacPorts 07 Mar '09

07 Mar '09

#16454: Fail to set time in many directories and "%% port" is not being recognized ---------------------------------------+------------------------------------ Reporter: X_iLeH(a)yahoo.com | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: Port failed Couldn't sync | Port: ---------------------------------------+------------------------------------ I installed MacPorts using the installer and then did the profile fix, MANPATH and helppath and the man and help worked until I closed the terminal and opened a new one. and then not even those would work. So I don't really no what's wrong I've messed with it a bit (pico .profile and copied over what it should be but still didn't work). So a few days later and out of ideas, I need some help. If you want the output from the curl then ill send it but other than that I don't know what to tell you. This is the end output of the curl to fix .profile {{{ sent 36540 bytes received 367818 bytes 38510.29 bytes/sec total size is 18789274 speedup is 46.47 rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-35.2/rsync/main.c(1400) [generator=2.6.9] Error: /opt/local/bin/port: port selfupdate failed: Couldn't sync the ports tree: Synchronization the local ports tree failed doing rsync An attempt to synchronize your recent MacPorts installation with the project's rsync server failed! Please run 'sudo port -d selfupdate' manually to find out the cause of the error. You have succesfully installed the MacPorts system, launch a terminal and try it out! Read the port(1) manual page and http://guide.macports.org for help, http://www.macports.org/contact.php if you need to get in touch with The MacPorts Project. }}} -- Ticket URL: <http://trac.macports.org/ticket/16454> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

Re: [MacPorts] #13787: ManOpen fails to install on Mac OS X 10.5.1
by MacPorts 07 Mar '09

07 Mar '09

#13787: ManOpen fails to install on Mac OS X 10.5.1 -----------------------------------------+---------------------------------- Reporter: mayer.julian@… | Owner: waqar@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: ManOpen | -----------------------------------------+---------------------------------- Comment(by tweiand@…): I have recently gotten ManOpen to compile on Leopard using this patch. Hope this helps. {{{ diff -Naur -x '*.xcode' -x '*.nib' -x '*.pbxproj' ManOpen-2.5.1/ManOpen/ManDocument.m ManOpen/ManOpen/ManDocument.m --- ManOpen-2.5.1/ManOpen/ManDocument.m 2005-11-27 23:32:39.000000000 -0800 +++ ManOpen/ManOpen/ManDocument.m 2009-03-06 14:12:48.000000000 -0800 @@ -325,7 +325,7 @@ #ifdef MACOS_X /* The new ATS typesetter in Jaguar causes some weirdnesses... but is fixed in later versions. */ if (IsPantherOrEarlier()) - [[textView layoutManager] setTypesetter:[NSSimpleHorizontalTypesetter sharedInstance]]; + [[textView layoutManager] setTypesetter:[NSTypesetter sharedSystemTypesetter]]; #endif if (sizeString != nil) @@ -631,7 +631,9 @@ NSFont *font = ManFont(); int currPage = [[NSPrintOperation currentOperation] currentPage]; NSString *str = [NSString stringWithFormat:@"%d", currPage]; - float strWidth = [font widthOfString:str]; +// float strWidth = [font widthOfString:str]; + NSSize strSize = [str sizeWithAttributes:[NSDictionary dictionaryWithObject:font forKey: NSFontAttributeName]]; + float strWidth = strSize.width; NSPoint point = NSMakePoint(size.width/2 - strWidth/2, 20.0); #ifdef MACOS_X @@ -641,8 +643,8 @@ CGContextSetTextMatrix(context, CGAffineTransformIdentity); CGContextSetTextDrawingMode(context, kCGTextFill); //needed? CGContextSetGrayFillColor(context, 0.0, 1.0); - CGContextSelectFont(context, [[font fontName] cString], [font pointSize], kCGEncodingMacRoman); - CGContextShowTextAtPoint(context, point.x, point.y, [str cString], [str cStringLength]); + CGContextSelectFont(context, [[font fontName] UTF8String], [font pointSize], kCGEncodingMacRoman); + CGContextShowTextAtPoint(context, point.x, point.y, [str UTF8String], [str lengthOfBytesUsingEncoding:NSASCIIStringEncoding]); CGContextRestoreGState(context); #else PSgsave(); }}} -- Ticket URL: <http://trac.macports.org/ticket/13787#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #9053: BUG gmp: crash in config.guess due to mfpvr instruction
by MacPorts 07 Mar '09

07 Mar '09

#9053: BUG gmp: crash in config.guess due to mfpvr instruction ----------------------------------------+----------------------------------- Reporter: vincent-opdarw@… | Owner: gwright@… Type: defect | Status: reopened Priority: Low | Milestone: Port Bugs Component: ports | Version: 1.0 Resolution: | Keywords: Port: gmp | ----------------------------------------+----------------------------------- Comment(by vinc17@…): Replying to [comment:26 mcalhoun@…]: > The test suite passed in 32 bit mode.[[BR]] > The test suite passed in 64 bit mode.[[BR]] > Since I only have access to the one G5 machine, such testing will have to suffice even if it does not qualify as having "tried hard."[[BR]] > Is there any reason to believe this is not correct? The correctness of arch-related options only matters if you try the binary on a different machine. So, if you test the library only on your machine, you're not doing any real test concerning these options. > I would respectfully suggest that unless the patch is quite small, there is no reason for it.[[BR]] The patch is small (I could make it even smaller by changing only one line, e.g. with a reinplace in the Portfile, but I think that the way it is is cleaner and 5 KB is not too much). > Correct me if I am wrong, but the crash is part of a normal test process.[[BR]] No, this is not normal. The test in question (where the crash occurs) is designed for Linux. I wonder why it isn't disabled on other systems (at least on those where this particular test is known to fail, as documented). > Code is run, it fails, and so the configure script knows not to run that code.[[BR]] No. The configure script runs config.guess, but only uses its output. But removing the mfpvr test doesn't change the config.guess output since this test fails to give any information on the processor. Under Mac OS X, the information on the processor is given by the test designed for Mac OS X (or more generally Mach-O). Note: it is theoretically possible to make the AIX test "work" and return an incorrect result (thus making the GMP build fail) by adding a sys/systemcfg.h header to the system (I don't think there's anything wrong with that, because sys/systemcfg.h isn't standard under Mac OS X thus well-written software shouldn't use it), even though this is quite unlikely in practice (but remember that there was a real problem with malloc.h, and this was quite similar). However since there's a patch, it was the occasion to remove the second buggy test. -- Ticket URL: <http://trac.macports.org/ticket/9053#comment:27> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #9053: BUG gmp: crash in config.guess due to mfpvr instruction
by MacPorts 06 Mar '09

06 Mar '09

#9053: BUG gmp: crash in config.guess due to mfpvr instruction ----------------------------------------+----------------------------------- Reporter: vincent-opdarw@… | Owner: gwright@… Type: defect | Status: reopened Priority: Low | Milestone: Port Bugs Component: ports | Version: 1.0 Resolution: | Keywords: Port: gmp | ----------------------------------------+----------------------------------- Comment(by mcalhoun@…): Replying to [comment:25 vinc17@…]: > Replying to [comment:24 mcalhoun@…]: > > On a G5 machine -mpowerpc64, -force_cpusubtype_ALL, and -mcpu seem to coexist.[[BR]] > > Yes, ''seem''. But you haven't tried hard (such as testing the library, at least the 64-bit version, on a different PowerPC machine). I will clarify.[[BR]] The test suite passed in 32 bit mode.[[BR]] The test suite passed in 64 bit mode.[[BR]] Since I only have access to the one G5 machine, such testing will have to suffice even if it does not qualify as having "tried hard."[[BR]] Is there any reason to believe this is not correct? > I'm reopening it since there's no reason not to fix the crash itself (which is annoying). I'm going to attach a patch. I would respectfully suggest that unless the patch is quite small, there is no reason for it.[[BR]] Correct me if I am wrong, but the crash is part of a normal test process.[[BR]] Code is run, it fails, and so the configure script knows not to run that code.[[BR]] The only issue is the minor and infrequent annoyance of CrashReporter telling you about the failure. -- Ticket URL: <http://trac.macports.org/ticket/9053#comment:26> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #9053: BUG gmp: crash in config.guess due to mfpvr instruction
by MacPorts 06 Mar '09

06 Mar '09

#9053: BUG gmp: crash in config.guess due to mfpvr instruction ----------------------------------------+----------------------------------- Reporter: vincent-opdarw@… | Owner: gwright@… Type: defect | Status: reopened Priority: Low | Milestone: Port Bugs Component: ports | Version: 1.0 Resolution: | Keywords: Port: gmp | ----------------------------------------+----------------------------------- Changes (by vinc17@…): * status: closed => reopened * resolution: wontfix => Comment: Replying to [comment:24 mcalhoun@…]: > On a G5 machine -mpowerpc64, -force_cpusubtype_ALL, and -mcpu seem to coexist.[[BR]] Yes, ''seem''. But you haven't tried hard (such as testing the library, at least the 64-bit version, on a different PowerPC machine). > I will therefore close this ticket. I'm reopening it since there's no reason not to fix the crash itself (which is annoying). I'm going to attach a patch. -- Ticket URL: <http://trac.macports.org/ticket/9053#comment:25> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0

Re: [MacPorts] #13658: yacas-1.1.10 fails to build on PowerPC Leopard
by MacPorts 06 Mar '09

06 Mar '09

#13658: yacas-1.1.10 fails to build on PowerPC Leopard -------------------------------------+-------------------------------------- Reporter: glen.henshaw@… | Owner: olt@… Type: defect | Status: closed Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: worksforme | Keywords: ppc 10.5 Port: yacas | -------------------------------------+-------------------------------------- Changes (by blb@…): * status: new => closed * resolution: => worksforme Comment: Closing, lack of response. -- Ticket URL: <http://trac.macports.org/ticket/13658#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0