Re: portmaster: problem with --packages-build?
On 06/11/10 15:56, Alberto Villa wrote: i would suggest just checking if the port is already installed That's not an adequate test because something could have been installed as a build dependency previously, which means it could safely be deleted with --delete-build-only. However, this is your lucky day! I looked at the problem and it wasn't as difficult as I first suspected. I've added code to the devel version of portmaster, can you test it? You can get the information on downloading it from svn at http://dougbarton.us/portmaster-proposal.html Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qt4-moc link failure
on 12/06/2010 03:40 Rob Farmer said the following: On Fri, Jun 11, 2010 at 12:31 PM, Doug Barton do...@freebsd.org wrote: Full log is at http://people.freebsd.org/~dougb/qt4-moc.log It looks like you compiled with g++45 but the very last command (the link) is using g++ (ie the base system gcc). I don't know enough about compilers to say for sure if that would cause the problem or not, but its probably a good starting point. Yeah, here is my earlier post to kde@ list, no reply to it: http://www.mail-archive.com/kde-free...@kde.org/msg08123.html -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
kdpepim...
Hi! After todays updtae of kdepim4 4.4.4_1 deskutils files touched by this commit Libraries for KDE-PIM applications kdepim4-runtime 4.4.4_1 deskutils files touched by this commit Libraries for KDE-PIM applications kdepimlibs4 4.4.4_1 deskutils files touched by this commit Libraries for KDE-PIM applications KMail doesn't works anymore because Akonadi cannot start: Akonadi Server Self-Test Report === Test 1: SUCCESS Database driver found. Details: The QtSQL driver 'QMYSQL' is required by your current Akonadi server configuration and was found on your system. File content of '/home/ajtim/.config/akonadi/akonadiserverrc': [%General] Driver=QMYSQL SizeThreshold=4096 ExternalPayload=false [QMYSQL] Name=akonadi Host= User= Password= Options=UNIX_SOCKET=/home/ajtim/.local/share/akonadi/db_misc/mysql.socket ServerPath=/usr/local/bin/mysqld_safe StartServer=true [Debug] Tracer=null Test 2: SUCCESS MySQL server found. Details: You currently have configured Akonadi to use the MySQL server '/usr/local/bin/mysqld_safe'. Make sure you have the MySQL server installed, set the correct path and ensure you have the necessary read and execution rights on the server executable. The server executable is typically called 'mysqld', its locations varies depending on the distribution. Test 3: SUCCESS MySQL server is executable. Details: MySQL server found: /usr/local/bin/mysqld_safe: cannot create /var/db/mysql/athena.wi.rr.com.err: No such file or directory eval: cannot create /var/db/mysql/athena.wi.rr.com.err: No such file or directory tee: /var/db/mysql/athena.wi.rr.com.err: No such file or directory tee: /var/db/mysql/athena.wi.rr.com.err: No such file or directory Starting mysqld daemon with databases from /var/db/mysql STOPPING server from pid file /var/db/mysql/athena.wi.rr.com.pid 100612 09:49:07 mysqld ended Test 4: WARNING MySQL server log contains warnings. Details: The MySQL server log file apos;a href='/home/ajtim/.local/share/akonadi/db_data/mysql.err'/home/ajtim/.local/share/akonadi/db_data/mysql.err/aapos; contains warnings. File content of '/home/ajtim/.local/share/akonadi/db_data/mysql.err': 100612 6:36:02 InnoDB: Started; log sequence number 0 132140 100612 6:36:03 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them 100612 6:36:03 [Note] /usr/local/libexec/mysqld: ready for connections. Version: '5.0.90-log' socket: '/home/ajtim/.local/share/akonadi/db_misc/mysql.socket' port: 0 FreeBSD port: mysql-server-5.0.90 100612 7:30:22 [Note] /usr/local/libexec/mysqld: Normal shutdown 100612 7:30:24 InnoDB: Starting shutdown... 100612 7:30:26 InnoDB: Shutdown completed; log sequence number 0 132170 100612 7:30:26 [Note] /usr/local/libexec/mysqld: Shutdown complete Thread 2eb1ed40 has exited with leftover thread-specific data after 4 destructor iterations Test 5: SUCCESS MySQL server default configuration found. Details: The default configuration for the MySQL server was found and is readable at a href='/usr/local/kde4/share/config/akonadi/mysql-global.conf'/usr/local/kde4/share/config/akonadi/mysql-global.conf/a. File content of '/usr/local/kde4/share/config/akonadi/mysql-global.conf': # # Global Akonadi MySQL server settings, # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp k...@mysql.com # [mysqld] skip_grant_tables skip_networking # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled #sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat #sql_mode=strict_trans_tables # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # case-insensitive table names, avoids trouble on windows lower_case_table_names=1 character_set_server=latin1 collation_server=latin1_general_ci table_cache=200 thread_cache_size=3 log_bin=mysql-bin expire_logs_days=3 #sync_bin_log=0 # error log file name, relative to datadir log_error=mysql.err log_warnings=2 # log all queries, useful for debugging but generates an enormous amount of data #log=mysql.full # log queries slower than n seconds, log file name relative to datadir (for debugging only) #log_slow_queries=mysql.slow #long_query_time=1 # log queries not using indices, debug only, disable for production use #log_queries_not_using_indexes=1 # maximum blob size max_allowed_packet=32M max_connections=256 # makes sense when having the same query multiple times # makes no sense with prepared statements and/or transactions query_cache_type=0 query_cache_size=0 innodb_file_per_table=1 innodb_log_buffer_size=1M innodb_additional_mem_pool_size=1M # messure database size and adjust # SELECT sum(data_length) as bla, sum(index_length) as blub FROM
security/gorilla outdated
Just noticed that they moved to github http://github.com/zdia/gorilla and the current version is 1.5.3, rather than the 1.4.4 version in the ports tree. I don't use the program, but thought it best to make a note of it here; cheers. -- TerryP / Spidey01 Just Another Computer Geek. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/gorilla outdated
On Sat, Jun 12, 2010 at 05:32:10PM +, Terry Poulin wrote: Just noticed that they moved to github http://github.com/zdia/gorilla and the current version is 1.5.3, rather than the 1.4.4 version in the ports tree. I don't use the program, but thought it best to make a note of it here; cheers. It's unmaintained, so unless someone sends a PR updating it, it will probably stay outdated :-) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/gorilla outdated
On Sat 12 Jun 2010 at 12:14:03 PDT Mark Linimon wrote: On Sat, Jun 12, 2010 at 05:32:10PM +, Terry Poulin wrote: Just noticed that they moved to github http://github.com/zdia/gorilla and the current version is 1.5.3, rather than the 1.4.4 version in the ports tree. I don't use the program, but thought it best to make a note of it here; cheers. It's unmaintained, so unless someone sends a PR updating it, it will probably stay outdated :-) The same is true for many other ports, as you can see in this list on the portscout website: http://www.portscout.org/po...@freebsd.org.html This is a list of all unmaintained ports. The lines highlighted in yellow are the ones where the port is known to be out-of-date. There might also be some others where portscout didn't detect the availability of a newer version. Here's another list, this time listing ports by maintainer: http://www.portscout.org/index-total.html When I checked this just now, there were 4872 unmaintained ports, of which 314 (6.44%) were known to be out-of-date. According to http://www.freebsd.org/ports/index.html there are currently 21869 ports in the ports collection. Doing a little math, that means that 22.3% of all ports are unmaintained, but only 1.4% are both unmaintained and out-of-date. Just thought I'd add a little perspective to Mark's reply. :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/gorilla outdated
On 06/12/10 14:48, Charlie Kester wrote: Doing a little math, that means that 22.3% of all ports are unmaintained, but only 1.4% are both unmaintained and out-of-date. First number's not so good, but the second one is actually pretty impressive (especially considering the first). Thanks for compiling these numbers. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qt4-moc link failure
On 06/12/10 00:18, Andriy Gapon wrote: on 12/06/2010 03:40 Rob Farmer said the following: On Fri, Jun 11, 2010 at 12:31 PM, Doug Bartondo...@freebsd.org wrote: Full log is at http://people.freebsd.org/~dougb/qt4-moc.log It looks like you compiled with g++45 but the very last command (the link) is using g++ (ie the base system gcc). I don't know enough about compilers to say for sure if that would cause the problem or not, but its probably a good starting point. Yeah, here is my earlier post to kde@ list, no reply to it: http://www.mail-archive.com/kde-free...@kde.org/msg08123.html Thanks Andriy, your suggestion to edit /usr/local/share/qt4/mkspecs/common/g++.conf did the trick. :) So, kde folks, is this going to be _the_ solution to this problem, or can y'all come up with a better one? If we're going to push in the direction of a ports compiler this is a problem that needs to be solved. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: problem with --packages-build?
No hurry for testing, I found some good test cases locally and was able to confirm that the new code works to detect this problem so I committed it to the ports version (2.29). Thanks again for bringing this to my attention. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: problem with --packages-build?
On Sunday 13 June 2010 01:40:19 Doug Barton wrote: No hurry for testing, I found some good test cases locally and was able to confirm that the new code works to detect this problem so I committed it to the ports version (2.29). i just saw the e-mail, so i wasn't able to test it before :) i have only one question: what if the port is listed only in build dependencies but is installed because i want it installed (of course, portmaster cannot know why a port was installed)? will it get removed? Thanks again for bringing this to my attention. thank you for fixing it! -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla Work is the curse of the drinking classes. -- Mike Romanoff signature.asc Description: This is a digitally signed message part.
Re: portmaster: problem with --packages-build?
On 06/12/10 17:10, Alberto Villa wrote: On Sunday 13 June 2010 01:40:19 Doug Barton wrote: No hurry for testing, I found some good test cases locally and was able to confirm that the new code works to detect this problem so I committed it to the ports version (2.29). i just saw the e-mail, so i wasn't able to test it before :) No problem. I initially thought it would be more difficult to fix than it actually turned out to be, so I was able to devote some time to writing the fix and then regression testing it (the latter part is usually the complicated bit). i have only one question: what if the port is listed only in build dependencies but is installed because i want it installed (of course, portmaster cannot know why a port was installed)? will it get removed? The list of ports for --delete-build-only and/or --packages-build (which use the same code to build the list, FWIW) is still calculated on each portmaster run. So let's say you have gmake installed already, and it is a build-only dependency on the current portmaster run. If gmake is up to date (i.e., portmaster doesn't need to do anything to it) then it will simply be used, and not deleted when you're done. The way the code stands now, if you already had it installed (or for that matter, if you did not have it installed, but it was a build-only dep for something else in the current run) then it would be installed/updated, then with --delete-build-only it would be deleted at the end of that portmaster run.[1] To answer your question more directly, there is currently no provision for the idea of this port is a build-only dependency but I do not want --delete-build-only to mess with it. The update today doesn't change this, it only addresses the issue of not treating something as a build-only dep on _this_ run if it is listed as a run dependency for something else that is already installed. I'm not sure that the complexity of the extra code required to exempt ports from --delete-build-only is justified. If I were a typical FreeBSD user I would probably use the combination of --packages-build and --delete-build-only, perhaps along with a local package repo so that I could build my own custom versions of those tools that I cared about. As long as the packages are up to date, they don't have have to be refetched each time you build a port so there is only a small delay when the build dep is installed. The reason I don't do this personally is that when I'm working on updating the ports that I maintain it's more convenient for me to already have the typical tools installed. hth Doug [1] There is another case of multiple ports on the command line, such as 'portmaster thing-that-has-gmake-as-a-build-dep gmake'. In that case, portmaster already has code to prevent gmake from being treated as a build dep. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
