Conflict subversion sitecopy
It appears to me from 7-STABLE, that there is a conflict between sitecopy and subversion as that sitecopy insists on neon26 and subversion requires neon28. -- Lars Eighner http://www.larseighner.com/index.html 8800 N IH35 APT 1191 AUSTIN TX 78753-5266 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
USE_GECKO=firefox and firefox3
Hi all,
I have firefox3 installed. my make.conf shows USE_GECKO=firefox.
When I try to install any port (in particular today, the latest eclipse 3.3.2 )
which uses USE_GECKO, www/firefox is pulled into the dependencies, rather tha
firefox3.
I use portupgrade to launch the eclipse upgrade ( portupgrade -p eclipse ) ,
and my /usr/local/etc/pkgtools.conf contains the following relevant entries:
ALT_PKGDEP = {
'www/mozilla' = 'www/firefox3',
'www/firefox' = 'www/firefox3',
'firefox-2*' = 'firefox-3*',
'firefox' = 'firefox3',
[...]
}
still, no luck, ffox 2 gets pulled in.
should Mk/bsd.gecko.mk have support for firefox3 ? Is there any solution,other
than deinstalling ffox3, install ffox2, install eclipse, and then replace ffox2
with 3 ?
( I *suspect* that portupgrade -o {ffox something} {ffox other} eclipse would
do , but not entirely sure how it works
Thanks for any help!!
B, now gmail powered.
_
{Beto|Norberto|Numard} Meijome
I respect faith, but doubt is what gives you an education.
Wilson Mizner
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade has serious problems
On Sunday 07 September 2008 13:41:14 David Southwell wrote: On Friday 05 September 2008 09:16:23 you wrote: David Southwell wrote: On Thursday 04 September 2008 09:38:22 you wrote: David Southwell wrote: On Tuesday 02 September 2008 08:26:26 you wrote: Show please an output of the command: pkg_info -o apache-2.2.9 Following up this one here is another weirdo:: ttp://httpd.apache.org/ === Cleaning for apache-2.2.9_5 --- Cleaning out obsolete shared libraries [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1047 packages found (-0 +1) . done] --- Skipping 'bsdpan-Term-ReadLine-Perl-1.0302' because it is held by user (specify -f to force) --- Skipping 'devel/p5-IO' because it is held by user (specify -f to force) --- Skipping 'graphics/ImageMagick' (ImageMagick-6.4.3.4) because a requisite package 'apache-2.2.9_3' () failed (specify -k to force) --- Skipping 'bsdpan-Shell-0.72' because it is held by user (specify -f to force) --- Skipping 'misc/p5-Array-Compare' because it is held by user (specify -f to force) --- Skipping 'devel/p5-Devel-Symdump' because it is held by user (specify -f to force) ** Listing the failed packages (-:ignored / *:skipped / !:failed) Here we have another example of portupgrade gets its dependencies in a twist. Not install Image-Magick on the grounds that apache, which it has just upgraded does not have the previous version installed. This is a constant repeat of the same problem as has happened with kde and elsewjhere Just again. Show pkg_info -o apache-2.2.9_5 please. Here is output.. But how does it help? It helps me to uderstand why there is no origin in the line: because a requisite package 'apache-2.2.9_3' () failed (specify -k to Having installed the upgradefrom apache-2.2.9_3 to 2.2.9_5 the database naturally shows the result of upgrading the database. Is it not more about what version portupgrade is expecting to find? Having upgraded why dhould it expect to find apache-2.2.9_3 I don't know. After apache was updated portupgrade should rebuild its databases. It did it (line: [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1047 packages found (-0 +1) . done]). But for some reason it use old values. What version of db do you [EMAIL PROTECTED] /var/spool/mqueue]# pkg_info |grep db apr-gdbm-db42-1.3.3.1.3.4 Apache Portability Library db4-4.0.14_1,1 The Berkeley DB package, revision 4 db42-4.2.52_5 The Berkeley DB package, revision 4.2 dbus-1.2.1 A message bus system for inter-application communication dbus-glib-0.76 GLib bindings for the D-BUS messaging system gdb-6.6_1 GNU GDB of newer version than comes with the system gdbm-1.8.3_3The GNU database manager gnome-db-0.2.96_10 Provide uniform access to data sources for the GNOME enviro libcddb-1.3.0 A library to access data on a CDDB server qt4-dbus-4.4.1 Qt4 bindings for the D-BUS messaging system qt4-odbc-plugin-4.4.1 Qt ODBC database plugin qt4-qdbusviewer-4.4.1 Qt4 D-BUS viewer ruby18-bdb-0.6.4Ruby interface to Sleepycat's Berkeley DB revision 2 or lat xcmsdb-1.0.1Device Color Characterization utility for X xdbedizzy-1.0.2 Demo of DBE creating a double buffered spinning scene xrdb-1.0.4 X server resource database [EMAIL PROTECTED] /usr/home/david]# pkg_info -o apache* Information for apache-2.2.9_5: Origin: www/apache22 Information for apache-ant-1.7.0_2: Origin: devel/apache-ant Here is another example: [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1046 packages found (-1 +0) (...) done] --- Installing the new version via the port === Installing for ruby18-gdk_pixbuf2-0.16.0.20080905 === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on file: /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd7/glib2.so - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on file: /usr/local/bin/ruby18 - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on executable: pkg-config - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on file: /usr/local/lib/gio/modules/libgiofam.so - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on shared library: atk-1.0.0 - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on shared library: glib-2.0.0 - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on shared library: gtk-x11-2.0.0 - found === ruby18-gdk_pixbuf2-0.16.0.20080905 depends on shared library: pango-1.0.0 - found === Generating temporary packing list === Checking if graphics/ruby-gdk_pixbuf2 already installed /usr/bin/install -c -o root -g wheel -m 0755 gdk_pixbuf2.so /usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd7 install -o root -g wheel -m 444 /usr/ports/graphics/ruby-gdk_pixbuf2/work/ruby-gnome2-all-0.16.0.20080905/gdkpixbuf/lib/gdk_pixbuf2.rb
net-p2p/torrentflux - fails: mtree
Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Excerpt from http://T64.TecNik93.com/logs/7-STABLE-FTP/torrentflux-2.0.b1.log : building torrentflux-2.0.b1 in directory /var/tinderbox/7-STABLE-FTP maintained by: [EMAIL PROTECTED] building for: 7.0-STABLE amd64 port directory: /usr/ports/net-p2p/torrentflux Makefile ident: $FreeBSD: ports/net-p2p/torrentflux/Makefile,v 1.5 2007/08/04 11:41:13 gabor Exp $ prefixes: LOCALBASE=usr/local X11BASE=usr/local NO* env vars: NOPORTDOCS=yes NOPORTEXAMPLES=yes NOPORTDATA=yes build started at Mon Sep 8 11:40:16 UTC 2008 .Last 40 lines of the log.. === torrentflux-2.0.b1 depends on file: /usr/local/lib/php/20060613/session.so - found === torrentflux-2.0.b1 depends on file: /usr/local/lib/php/20060613/sqlite.so - found === Generating temporary packing list === Checking if net-p2p/torrentflux already installed === Download directory created. === Torrentflux database created. === kern.ps_arg_cache_limit: 256 - 1024 The TorrentFlux package has been successfully installed. Files will be downloaded to /usr/local/share/torrentflux/data, to check how much space is left on the partition, try df -H /usr/local/share/torrentflux/data Visit the TorrentFlux forum at http://www.torrentflux.com/forum/ for more information. === Registering installation for torrentflux-2.0.b1 phase 7: make package === Building package for torrentflux-2.0.b1 Creating package /tmp/packages/All/torrentflux-2.0.b1.tbz Registering depends: adodb-4.99.0 php5-sqlite-5.2.6_2 php5-spl-5.2.6_2 php5-pcre-5.2.6_2 php5-session-5.2.6_2 php5-simplexml-5.2.6_2 php5-5.2.6_2 libxml2-2.6.32 libiconv-1.11_1 sqlite-2.8.17_1 pkg-config-0.23_1 py25-BitTornado-core-0.3.18_3,1 py25-pycrypto-2.0.1_1 python25-2.5.2_3 libgmp-4.2.3. Creating bzip'd tar ball in '/tmp/packages/All/torrentflux-2.0.b1.tbz' Deleting torrentflux-2.0.b1 === Deleted TorrentFlux database. === Checking filesystem state list of extra files and directories in / (not present before this port was installed but present after it was deinstalled) 28734404 drwxr-xr-x2 root wheel 512 Sep 8 11:40 usr/local/www/data build of /usr/ports/net-p2p/torrentflux ended at Mon Sep 8 11:40:37 UTC 2008 A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/testing_process.txt Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - [EMAIL PROTECTED], PGP Key ID 057E9F8B493A297B ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Mail services checking - URGENT
Hi I have had a series of attacks on a system which resulted in a hijack of our mail system. I believe I have now fixed the main problem but I need a tool that will reliably, and independently of the mail logs check my network for all outgoing mails and hold them up until I am certain that there all loopholes have been closed. Can anyone please let me have some recomendations on the best way of going about this Thanks David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Monday 08 September 2008 05:19:51 Jeremy Chadwick wrote: On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. I believe I have now fixed the main problem but I need a tool that will reliably, and independently of the mail logs check my network for all outgoing mails and hold them up until I am certain that there all loopholes have been closed. Can anyone please let me have some recomendations on the best way of going about this I'm not sure what exactly you want. Someone compromising your system means they could've done *anything*, including running their own MTA, replacing libc to include an open proxy for spamming, or any other thing. There's no way to detect that sort of thing aside from deep packet inspection to look for mail-like network traffic, which is predominantly the job of a router or network tap. It's going to be impossible for you to 100% ensure the system is in a working state. What happened was compromising 2 windows systems and installing a trojan on those two systems. They were used to send mail via the MTA's on the freebsd server to the outside world and in particular permissions to send mail to root on the freebsd server. There was no actual compromise of the freebsd server and the windows systems had no ability to access the server. Keeping it simple, making the (horrible) assumption that they compromised something that affected your MTA: it depends completely an entirely on what MTA you're using (sendmail, postfix, etc.). See the your MTA's manpages for looking at outbound/delivery mail queue. In addition to the above I am loking for an additional way of monitoring smptd 25 outbound traffic at the network level, filter the traffic, and do an extra checks to make sure there is nothing left when I reopen the service to the local network. By the way, and I apologise if I'm stepping over a line here, but fixed the main problem doesn't sound like you fixed anything. You might have addressed the hole they used to get in on, but what makes you think they didn't replace binaries (including using touch -amcf to adjust a/m/ctimes) or do something even more sneaky? The main problem was the trojan and stuff that it brought in. Hefty use of Kaspersky and about six other tools on the windows systems has resolved the issue. I have not been able to detect any attempts from the windows systems to abuse the mail system but I want to monitor dynamically for some time. If someone compromised one of your systems, do the world a favour: pull the Ethernet out of it or have it shut off *immediately* (this is how MIT does it -- yes I'm serious), go to the datacentre and format the disk(s). No I am not exaggerating. The longer you keep that system up, the higher the chance is that you'll get contacted by your provider, Internet users (blacklisted, etc.), or possibly law enforcement. You are not out of line -- I understand That is why the system was shut down for 48 hours. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. I believe I have now fixed the main problem but I need a tool that will reliably, and independently of the mail logs check my network for all outgoing mails and hold them up until I am certain that there all loopholes have been closed. Can anyone please let me have some recomendations on the best way of going about this I'm not sure what exactly you want. Someone compromising your system means they could've done *anything*, including running their own MTA, replacing libc to include an open proxy for spamming, or any other thing. There's no way to detect that sort of thing aside from deep packet inspection to look for mail-like network traffic, which is predominantly the job of a router or network tap. It's going to be impossible for you to 100% ensure the system is in a working state. Keeping it simple, making the (horrible) assumption that they compromised something that affected your MTA: it depends completely an entirely on what MTA you're using (sendmail, postfix, etc.). See the your MTA's manpages for looking at outbound/delivery mail queue. By the way, and I apologise if I'm stepping over a line here, but fixed the main problem doesn't sound like you fixed anything. You might have addressed the hole they used to get in on, but what makes you think they didn't replace binaries (including using touch -amcf to adjust a/m/ctimes) or do something even more sneaky? If someone compromised one of your systems, do the world a favour: pull the Ethernet out of it or have it shut off *immediately* (this is how MIT does it -- yes I'm serious), go to the datacentre and format the disk(s). No I am not exaggerating. The longer you keep that system up, the higher the chance is that you'll get contacted by your provider, Internet users (blacklisted, etc.), or possibly law enforcement. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade has serious problems
David Southwell wrote: --- Skipping 'x11-toolkits/ruby-gtk2' (ruby18-gtk2-0.16.0.20080706) because a requisite package 'ruby18-gdk_pixbuf2-0.16.0.20080706' () failed (specify -k to force) Empty brackets display a problem with a database. But for some reason it can't be detected by bdb engine. --- Skipping 'devel/ruby-libglade2' (ruby18-libglade2-0.16.0.20080706) because a requisite package 'ruby18-gtk2-0.16.0.20080706' (x11-toolkits/ruby-gtk2) failed (specify -k to force) All these problems have identical symptoms and are fixed by rerunning portupgrade!! It looks as though portupgrade is failing to reexamine the database after each upgrade OR is searching for a dependency which is limited to the previous version! Could you remove both /var/db/pkg/pkgdb.db and /usr/ports/INDEX*.db and rerun portupgrade? They will be recreated automatically. -- Dixi. Sem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: Ports freeze for 6.4 and 7.0 in effect
In preparation for both the 6.4 and 7.1 releases, the ports tree has been frozen. All commits have to be approved by portmgr. See the portmgr webpage[1] for more information about what is and isn't allowed during the freeze. We are aiming for a short freeze period, so we will be quite strict in allowing commits during the freeze. Of course, we do appreciate any help fixing existing errors in the tree, so if anyone is bored, a good starting point will be portsmon[2]. Best, -erwin [1]: http://www.freebsd.org/portmgr/policies_committing.html [2]: http://portsmon.freebsd.org/portserrs.py -- Erwin Lansing http://droso.org [EMAIL PROTECTED] You are now free to move around the cabin [EMAIL PROTECTED] pgpLjTK4e2RqI.pgp Description: PGP signature
net-p2p/teknap - fails: install_error
Hi, The build which triggered this email is done under tinderbox-2.4.3, on 7-STABLE on amd64, with tinderd_flags=-nullfs -plistcheck -onceonly and ccache support, with the official up-to-date Ports Tree, with the following vars set: NOPORTDOCS=yes, NOPORTEXAMPLES=yes, NOPORTDATA=yes, FORCE_PACKAGE=yes. Excerpt from http://T64.TecNik93.com/logs/7-STABLE-FTP/TekNap-1.3.g_2.log : building TekNap-1.3.g_2 in directory /var/tinderbox/7-STABLE-FTP maintained by: [EMAIL PROTECTED] building for: 7.0-STABLE amd64 port directory: /usr/ports/net-p2p/teknap Makefile ident: $FreeBSD: ports/net-p2p/teknap/Makefile,v 1.23 2008/01/09 15:19:46 tabthorpe Exp $ prefixes: LOCALBASE=usr/local X11BASE=usr/local NO* env vars: NOPORTDOCS=yes NOPORTEXAMPLES=yes NOPORTDATA=yes build started at Mon Sep 8 11:37:20 UTC 2008 .Last 40 lines of the log.. tar: share/TekNap/help/6_Functions/toupper: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/tow: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/tr: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/twiddle: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/uname: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/unlink: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/unshift: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/utime: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/winnum: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/winsize: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/word: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/wordtoindex: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/write: Cannot stat: No such file or directory tar: share/TekNap/help/6_Functions/xmms: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/7_Docs: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Arrays: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Command_Line: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Environment: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Expressions: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Introduction: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Key_Bindings: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Patterns: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Programming: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Serial_Numbers: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Server_Numerics: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Signals: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Special_Vars: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Status_Line: Cannot stat: No such file or directory tar: share/TekNap/help/7_Docs/Text_Highlight: Cannot stat: No such file or directory tar: share/doc/TekNap/README: Cannot stat: No such file or directory tar: Error exit delayed from previous errors. pkg_create: make_dist: tar command failed with code 256 Creating package /tmp/packages/All/TekNap-1.3.g_2.tbz Registering depends:. Creating bzip'd tar ball in '/tmp/packages/All/TekNap-1.3.g_2.tbz' *** Error code 1 Stop in /a/ports/net-p2p/teknap. build of /usr/ports/net-p2p/teknap ended at Mon Sep 8 11:37:51 UTC 2008 A description of the testing process can be found here: http://T32.TecNik93.com/FreeBSD/QA-Tindy/testing_process.txt Thanks for your work on making FreeBSD better, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - [EMAIL PROTECTED], PGP Key ID 057E9F8B493A297B ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade has serious problems
On Monday 08 September 2008 05:42:48 David Southwell wrote: On Monday 08 September 2008 04:59:06 Sergey Matveychuk wrote: David Southwell wrote: --- Skipping 'x11-toolkits/ruby-gtk2' (ruby18-gtk2-0.16.0.20080706) because a requisite package 'ruby18-gdk_pixbuf2-0.16.0.20080706' () failed (specify -k to force) Empty brackets display a problem with a database. But for some reason it can't be detected by bdb engine. --- Skipping 'devel/ruby-libglade2' (ruby18-libglade2-0.16.0.20080706) because a requisite package 'ruby18-gtk2-0.16.0.20080706' (x11-toolkits/ruby-gtk2) failed (specify -k to force) All these problems have identical symptoms and are fixed by rerunning portupgrade!! It looks as though portupgrade is failing to reexamine the database after each upgrade OR is searching for a dependency which is limited to the previous version! Could you remove both /var/db/pkg/pkgdb.db and /usr/ports/INDEX*.db and rerun portupgrade? They will be recreated automatically. OK done that I will report back when I have done a few cvsups and portupgrade runs and see whether that fixes the problem. Thanks for keeping on to this. Lets hope this works No such luck I am afraid we still have the same problem;; === Registering installation for poppler-0.8.7 === Cleaning for poppler-0.8.7 --- Cleaning out obsolete shared libraries [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1047 packages found (-0 +1) . done] --- Skipping 'graphics/poppler-qt' (poppler-qt-0.8.6) because a requisite package 'poppler-0.8.6' () failed (specify -k to force) --- Skipping 'graphics/poppler-gtk' (poppler-gtk-0.8.6) because a requisite package 'poppler-0.8.6' () failed (specify -k to force) ** Listing the failed packages (-:ignored / *:skipped / !:failed) # /usr/ports]# pkg_info -o poppler* Information for poppler-0.8.7: Origin: graphics/poppler Information for poppler-data-0.2.0: Origin: graphics/poppler-data Information for poppler-gtk-0.8.6: Origin: graphics/poppler-gtk Information for poppler-qt-0.8.6: Origin: graphics/poppler-qt [EMAIL PROTECTED] /usr/ports]# Looks like same problem David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Portupgrade has serious problems
On Monday 08 September 2008 04:59:06 Sergey Matveychuk wrote: David Southwell wrote: --- Skipping 'x11-toolkits/ruby-gtk2' (ruby18-gtk2-0.16.0.20080706) because a requisite package 'ruby18-gdk_pixbuf2-0.16.0.20080706' () failed (specify -k to force) Empty brackets display a problem with a database. But for some reason it can't be detected by bdb engine. --- Skipping 'devel/ruby-libglade2' (ruby18-libglade2-0.16.0.20080706) because a requisite package 'ruby18-gtk2-0.16.0.20080706' (x11-toolkits/ruby-gtk2) failed (specify -k to force) All these problems have identical symptoms and are fixed by rerunning portupgrade!! It looks as though portupgrade is failing to reexamine the database after each upgrade OR is searching for a dependency which is limited to the previous version! Could you remove both /var/db/pkg/pkgdb.db and /usr/ports/INDEX*.db and rerun portupgrade? They will be recreated automatically. OK done that I will report back when I have done a few cvsups and portupgrade runs and see whether that fixes the problem. Thanks for keeping on to this. Lets hope this works David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. Also, one other point I forgot to make: This **should not** have gone to freebsd-ports, as the issue has absolutely nothing to do with ports. This should have gone to freebsd-isp, freebsd-security, or possibly freebsd-questions. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Monday 08 September 2008 06:07:26 Jeremy Chadwick wrote: On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. Also, one other point I forgot to make: This **should not** have gone to freebsd-ports, as the issue has absolutely nothing to do with ports. This should have gone to freebsd-isp, freebsd-security, or possibly freebsd-questions. I am sure you are right.. I was just hoping there might have been a port which would do something like.. trap all outgoing mail from the server - irrespective of the mta pas it through a filer and dump it in a file until you have had a chance to inspect it. Bearing in mind mail can come from multiple sources such a port would have been useful. Apologies for generating too much traffic david ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Mon, Sep 08, 2008 at 05:59:54AM -0700, David Southwell wrote: On Monday 08 September 2008 05:19:51 Jeremy Chadwick wrote: On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. I believe I have now fixed the main problem but I need a tool that will reliably, and independently of the mail logs check my network for all outgoing mails and hold them up until I am certain that there all loopholes have been closed. Can anyone please let me have some recomendations on the best way of going about this I'm not sure what exactly you want. Someone compromising your system means they could've done *anything*, including running their own MTA, replacing libc to include an open proxy for spamming, or any other thing. There's no way to detect that sort of thing aside from deep packet inspection to look for mail-like network traffic, which is predominantly the job of a router or network tap. It's going to be impossible for you to 100% ensure the system is in a working state. What happened was compromising 2 windows systems and installing a trojan on those two systems. They were used to send mail via the MTA's on the freebsd server to the outside world and in particular permissions to send mail to root on the freebsd server. There was no actual compromise of the freebsd server and the windows systems had no ability to access the server. Okay, in that case you can disregard my comments about formatting the FreeBSD machine. Instead, format the Windows machine. ;-) Keeping it simple, making the (horrible) assumption that they compromised something that affected your MTA: it depends completely an entirely on what MTA you're using (sendmail, postfix, etc.). See the your MTA's manpages for looking at outbound/delivery mail queue. In addition to the above I am loking for an additional way of monitoring smptd 25 outbound traffic at the network level, filter the traffic, and do an extra checks to make sure there is nothing left when I reopen the service to the local network. You didn't disclose what MTA you're using on the FreeBSD box. On postfix, you should use the 'mailq' command. I believe sendmail also uses 'mailq', but requires specific arguments to examine the outbound queue. Regarding monitoring TCP port 25 traffic: I'm not sure what you mean by monitoring. You should be able to tail logfiles, or use tcpdump to monitor those packets: tcpdump -p -l -n tcp and port 25 Regarding blocking outbound SMTP traffic (traffic your MTA is sending to mail servers on the Internet), you should be able to use pf to block that. These rules, in this order, in /etc/pf.conf should suffice and should not affect existing IP traffic or lock you out (but I HIGHLY recommend you apply these over serial or VGA console -- doing in-band firewall changes is a very, VERY risky/bad idea): pass in all no state pass out all no state block in quick on interface proto tcp from mailserverIP to any port 25 Replace 'interface' with the network interface used for this traffic, and 'mailserverIP' with the IP of your mail server. (For readers: the reason I'm telling him to use no state is that I don't want to bother getting into a discussion about pf state tracking and oh man suddenly my SSH connection died to the box or other things which are expected but require explanation.) Enable pf by using this in /etc/rc.conf: pf_enable=yes Then run /etc/rc.d/pf start. I'm making the assumption you have pf in your kernel, or that it will load as a kernel module successfully. If you get a warning about ALTQ (traffic flow/shaping) not working, you can ignore it. By the way, and I apologise if I'm stepping over a line here, but fixed the main problem doesn't sound like you fixed anything. You might have addressed the hole they used to get in on, but what makes you think they didn't replace binaries (including using touch -amcf to adjust a/m/ctimes) or do something even more sneaky? The main problem was the trojan and stuff that it brought in. Hefty use of Kaspersky and about six other tools on the windows systems has resolved the issue. I have not been able to detect any attempts from the windows systems to abuse the mail system but I want to monitor dynamically for some time. I still wouldn't trust it, and it has nothing to do with it being Windows. Members of the FreeBSD security team would likely provide the same advice (format the disk and reinstall the OS entirely). This concept applies universally. You have even less visibility into the inner workings of a Windows box than you do a *IX box; it's just the nature of the beast. Otherwise, congratulations, assuming this is your first encounter dealing with hackers. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking
Re: VirtualBox looks for FreeBSD developer
[third attempt - the first two were blocked by the smart freebsd.org mailserver, which rejected the mail because it couldn't get the name for the sun mail server's IP address - which looks like a DNS misconfiguration on freesbd.org. Not nice when trying to send such messages as the following.] #include disclaimer Some user on the #vbox irc channel brought this topic to my attention. So don't misinterpret my response here as declaring myself the best possible contact - I'm not. I'm not on the freebsd-ports list either. The issue with getting VirtualBox working on freebsd is mainly a manpower problem. Sorry to say that, but it's the root of why there has been no substantial progress from the Sun (and previously innotek). freebsd is yet another kernel for which the VirtualBox devs would have to figure out how to safely achieve a few things normal applications don't ever need. Like dealing with physical memory, getting along with the scheduler and stuff like that. It's also true that the written documentation in VirtualBox about this area leaves something to be desired - again a manpower problem. So the only chance I personally see is for getting the freebsd port over the initial big bump is that some kernel gurus from the freebsd community help out. If someone capable and willing to look into this contacts the VirtualBox team, he'll eventually find someone on #vbox-dev who has time to explain - if time permits. We do our best to be responsive, but bear with us that many things have higher priorities. Remember, the team is located in Europe. There's the vbox-dev mailing list if it's too hard to find a time where both parties are awake. Sorry to babble so much, but I hope that this puts off the unwanted audience - serious low-level stuff needs to be done before worrying about compilation issues on particular freebsd versions. Once the mentioned hurdle is taken, keeping it working will be much less work - and the VirtualBox team probably will do most of it. Klaus On Sat, Mar 01, 2008 at 08:04:55AM +1100, Edwin Groothuis wrote: On Fri, Feb 29, 2008 at 09:48:45PM +0100, Olivier Cochard-Labbe wrote: I can't compile VirtualBox with your patch (I'm using a FreeBSD 7.0Release). It works with 6.3, 7.0 has the ULE scheduler which doesn't have sched_lock. Rink@ has been trying to get it work on 7.0, but... rink Mavvie: haven't gotten it to link yet :-/ It works on 6.3, until you try to start the VM: With VBOX_SUPLIB_FAKE=fake set you get: VM creation failed (GVMM). VBox status code: -37 (VERR_NOT_SUPPORTED). Without it (i.e. using the kernel module): Failed to load VMMR0.r0. VBox status code: -609 (VERR_SYMBOL_NOT_FOUND). And the documentation about the kernel module as described on http://www.virtualbox.org/wiki/Porting_VirtualBox are lacking a bit of essential information. FYI: I've given up on it, despite the fact that it compiles and runs on 6.3, I can't get around the problems with the kernel driver and the lack of documentation. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mail services checking - URGENT
On Sep 8, 2008, at 06:04, Jeremy Chadwick wrote: On Mon, Sep 08, 2008 at 05:59:54AM -0700, David Southwell wrote: On Monday 08 September 2008 05:19:51 Jeremy Chadwick wrote: On Mon, Sep 08, 2008 at 05:10:27AM -0700, David Southwell wrote: I have had a series of attacks on a system which resulted in a hijack of our mail system. I believe I have now fixed the main problem but I need a tool that will reliably, and independently of the mail logs check my network for all outgoing mails and hold them up until I am certain that there all loopholes have been closed. Can anyone please let me have some recomendations on the best way of going about this You might want to look at the clamav port. If there are examples of the things you would be checking for, you can create your own signatures for those and clamav will do the monitoring for you. You can configure it to quarantine messages which have the signature for manual review. It won't find anything new, it just does a better job of finding things you have seen before. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Sell Cisco Systems equipment items
Hello, We are professional manufacturer,we can supply lots of networking products: 100% compatible,3rd party Cisco Card,GBIC,SFP,module,WIC,Cisco Console cable items,and so on... we have competitive price and excellent capability of filling customers requirements. In addition to high quality,in-time delivery and excellent after-sale service also help us to win customers. please do not hesitate to contact me if you have interested. example of the products: CWDM-SFP-1G WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, GLC-SX-MM SFP-GE-L .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, NM-1E, NM-4E, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, WS-X6K-MSFC2-KIT, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D. Thanks Helen.Zhou Newstar networking technology www.nstnetwork.com Email/MSN: [EMAIL PROTECTED] AOL helenxuezhou ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Making ports from source with weird download restrictions
Hi, There are two embedded software tools I've been wanting to port for some time. Both have inconsistent/funky downloads, so I have no idea how to get them into a port. Both are very active projects, and used by pretty much all embedded ARM7/9 developers (embedded as in microwaves thermostats not PDA's IPods). 1) lpc21isp - http://tech.groups.yahoo.com/group/lpc21isp/ - the source for this project is only located in the files section of this yahoo group, and I'm pretty sure you need a yahoo password to get it. Also it's guarded by a bunch of antisocial types, if you know what I mean. I got flamed for suggesting a feature that would increase flexibility. I suspect the only choice here is to make sure the license is open, and branch it to a new sourceforge project, correct? Otherwise, there's really no way for someone to get the source in an automated fashion. 2) openocd - http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD - this is a bit more sensible - there's a stable SVN repository for it, it's just that the only ports I've seen are on sourceforge, and come from release .tgz archives, not a SVN archive (although I've never gotten a broken version from the openocd SVN). If someone pointed me at a port that built from SVN instead of a .tgz, I'm sure I could get the port done. Best, Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USE_GECKO=firefox and firefox3
Norberto Meijome wrote:
Hi all,
I have firefox3 installed. my make.conf shows USE_GECKO=firefox.
When I try to install any port (in particular today, the latest eclipse 3.3.2 )
which uses USE_GECKO, www/firefox is pulled into the dependencies, rather tha
firefox3.
I use portupgrade to launch the eclipse upgrade ( portupgrade -p eclipse ) ,
and my /usr/local/etc/pkgtools.conf contains the following relevant entries:
ALT_PKGDEP = {
'www/mozilla' = 'www/firefox3',
'www/firefox' = 'www/firefox3',
'firefox-2*' = 'firefox-3*',
'firefox' = 'firefox3',
[...]
}
As far as I can tell, from having this problem with the VLC Firefox plugin after
the FF3 release, you need to use WITH_GECKO=xulrunner instead of firefox or
firefox3. Of course, that will only work if the eclipse port has xulrunner in
the list for USE_GECKO and isn't pulling in the old bsd.gecko.mk from the
mozilla folder.
The reason for that is that after Firefox 2, the Mozilla team moved all the
stuff for building into xulrunner, as Firefox 3 doesn't have a firefox3-config
like Firefox 2 had firefox-config. I don't use eclipse, so I can't comment if
changing it so it uses xulrunner will work, but it's worth a shot.
Naram Qashat
still, no luck, ffox 2 gets pulled in.
should Mk/bsd.gecko.mk have support for firefox3 ? Is there any solution,other
than deinstalling ffox3, install ffox2, install eclipse, and then replace ffox2
with 3 ?
( I *suspect* that portupgrade -o {ffox something} {ffox other} eclipse would
do , but not entirely sure how it works
Thanks for any help!!
B, now gmail powered.
_
{Beto|Norberto|Numard} Meijome
I respect faith, but doubt is what gives you an education.
Wilson Mizner
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making ports from source with weird download restrictions
On Mon, Sep 08, 2008 at 10:03:22AM -0700, Steve Franks wrote: Hi, There are two embedded software tools I've been wanting to port for some time. Both have inconsistent/funky downloads, so I have no idea how to get them into a port. Both are very active projects, and used by pretty much all embedded ARM7/9 developers (embedded as in microwaves thermostats not PDA's IPods). 1) lpc21isp - http://tech.groups.yahoo.com/group/lpc21isp/ - the source for this project is only located in the files section of this yahoo group, and I'm pretty sure you need a yahoo password to get it. Also it's guarded by a bunch of antisocial types, if you know what I mean. I got flamed for suggesting a feature that would increase flexibility. I suspect the only choice here is to make sure the license is open, and branch it to a new sourceforge project, correct? Otherwise, there's really no way for someone to get the source in an automated fashion. As long as the license allows redistribution, we can host it on FreeBSD infrastructure using MASTER_SITE_LOCAL. 2) openocd - http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD - this is a bit more sensible - there's a stable SVN repository for it, it's just that the only ports I've seen are on sourceforge, and come from release .tgz archives, not a SVN archive (although I've never gotten a broken version from the openocd SVN). If someone pointed me at a port that built from SVN instead of a .tgz, I'm sure I could get the port done. Doing an svn export in the fetch stage is possible, but probably not ideal. In my devel/llvm-devel port I have a do-fetch target that fetches a snapshot and makes a tarball out of it, but I only use that for my own use and host a snapshot on the FreeBSD ftp servers for normal users since a tarball allows users to do a make clean and retry without having to fetch files again. -- Brooks pgpWvq02Uu17s.pgp Description: PGP signature
Re: HEADS UP: Ports freeze for 6.4 and 7.0 in effect
On Mon, 8 Sep 2008 14:01:25 +0200, Erwin Lansing [EMAIL PROTECTED] wrote: In preparation for both the 6.4 and 7.1 releases, the ports tree has been frozen. All commits have to be approved by portmgr. See the portmgr webpage[1] for more information about what is and isn't allowed during the freeze. We are aiming for a short freeze period, so we will be quite strict in allowing commits during the freeze. Of course, we do appreciate any help fixing existing errors in the tree, so if anyone is bored, a good starting point will be portsmon[2]. Damn :/ My emacs-22.3 release update almost made it into ports before the freeze by 1-2 days. Is there any chance I could bribe you guys to get it in, so we can have the latest stable 22.X GNU Emacs in the release? Having said that, I am a bit unfamiliar with all the work port builders have to do during the freeze, so if getting a new Emacs in the tree is completely out of the question because it would create a lot of work for you guys, that's ok. On the other hand, if the ports stay frozen for several weeks and we still have time to let it settle into the tree, it would be very nice to include this version. It includes a mildly important fix in the way Emacs spawns Python processes[1] that would be _very_ nice to have in ports sooner, rather than a couple of months later. http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html pgpd2oySxxtNF.pgp Description: PGP signature
Re: VirtualBox looks for FreeBSD developer
Hello, On Mon, Sep 8, 2008 at 3:22 PM, Klaus Espenlaub [EMAIL PROTECTED] wrote: #include disclaimer I speak for myself and nobody else. I do not claim that I in any way represent FreeBSD. freebsd is yet another kernel for which the VirtualBox devs would have to figure out how to safely achieve a few things normal applications don't ever need. Like dealing with physical memory, getting along with the scheduler and stuff like that. It's also true that the written documentation in VirtualBox about this area leaves something to be desired - again a manpower problem. It is easy for me as an outsider to see that this can be viewed from the opposite angle: VirtualBox is just another virtualization solution for FreeBSD. We are sorry that the VirtualBox team can't find any time to provide the necessary documentation. Currently FreeBSD don't have any developers with enough free time to figure things out from the documentation available now. You see - it is simply a manpower problem. I do hope I'm wrong, and that some FreeBSD developer will work on this. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports patch for comm/rxtx
Zach Metzinger píše v po 08. 09. 2008 v 14:33 -0500: The configure and configure.in files for comm/rxtx are broken when using java/jdk16. Two patches, below, fix this problem. The actual credit for figuring this out belongs to netbeans at gatworks.com. I just created patches to fix the issue. Unpatched, the port does not indicate an error, but the installation fails (no files installed). If installed by hand at this point, programs using rxtx fail due to: java.lang.UnsatisfiedLinkError: gnu.io.RXTXCommDriver.nativeGetVersion()Ljava/lang/String; thrown while loading gnu.io.RXTXCommDriver This looks useful. Let me test and commit it. --- Zach *** configure+ Mon Sep 8 14:22:44 2008 --- configure Mon Sep 8 14:23:16 2008 *** *** 21611,21617 TARGETLIB=\$(target_triplet)/librxtxSerial.la \ \$(target_triplet)/librxtxParallel.la case $JAVA_VERSION in ! 1.2*|1.3*|1.4*|1.5*) #fix_parameters $JPATH/jre/lib/javax.comm.properties CLASSPATH=.:\$(TOP):\$(TOP)/src:`find $JPATH/ -name RXTXcomm.jar |head -n1` RXTX_PATH=\$(JPATH)/jre/lib/\$(OS_ARCH) --- 21611,21617 TARGETLIB=\$(target_triplet)/librxtxSerial.la \ \$(target_triplet)/librxtxParallel.la case $JAVA_VERSION in ! 1.2*|1.3*|1.4*|1.5*|1.6*) #fix_parameters $JPATH/jre/lib/javax.comm.properties CLASSPATH=.:\$(TOP):\$(TOP)/src:`find $JPATH/ -name RXTXcomm.jar |head -n1` RXTX_PATH=\$(JPATH)/jre/lib/\$(OS_ARCH) *** configure.in+ Mon Sep 8 14:22:51 2008 --- configure.inMon Sep 8 14:23:25 2008 *** *** 533,539 TARGETLIB=\$(target_triplet)/librxtxSerial.la \ \$(target_triplet)/librxtxParallel.la case $JAVA_VERSION in ! 1.2*|1.3*|1.4*|1.5*) #fix_parameters $JPATH/jre/lib/javax.comm.properties CLASSPATH=.:\$(TOP):\$(TOP)/src:`find $JPATH/ -name RXTXcomm.jar |head -n1` RXTX_PATH=\$(JPATH)/jre/lib/\$(OS_ARCH) --- 533,539 TARGETLIB=\$(target_triplet)/librxtxSerial.la \ \$(target_triplet)/librxtxParallel.la case $JAVA_VERSION in ! 1.2*|1.3*|1.4*|1.5*|1.6*) #fix_parameters $JPATH/jre/lib/javax.comm.properties CLASSPATH=.:\$(TOP):\$(TOP)/src:`find $JPATH/ -name RXTXcomm.jar |head -n1` RXTX_PATH=\$(JPATH)/jre/lib/\$(OS_ARCH) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] Your sig line (k) was stolen! -more- There is a puff of smoke! signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP: Ports freeze for 6.4 and 7.0 in effect
Giorgos Keramidas [EMAIL PROTECTED] writes: On Mon, 8 Sep 2008 14:01:25 +0200, Erwin Lansing [EMAIL PROTECTED] wrote: In preparation for both the 6.4 and 7.1 releases, the ports tree has been frozen. All commits have to be approved by portmgr. See the portmgr webpage[1] for more information about what is and isn't allowed during the freeze. We are aiming for a short freeze period, so we will be quite strict in allowing commits during the freeze. Of course, we do appreciate any help fixing existing errors in the tree, so if anyone is bored, a good starting point will be portsmon[2]. Damn :/ My emacs-22.3 release update almost made it into ports before the freeze by 1-2 days. Is there any chance I could bribe you guys to get it in, so we can have the latest stable 22.X GNU Emacs in the release? Having said that, I am a bit unfamiliar with all the work port builders have to do during the freeze, so if getting a new Emacs in the tree is completely out of the question because it would create a lot of work for you guys, that's ok. On the other hand, if the ports stay frozen for several weeks and we still have time to let it settle into the tree, it would be very nice to include this version. It includes a mildly important fix in the way Emacs spawns Python processes[1] that would be _very_ nice to have in ports sooner, rather than a couple of months later. http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html Since it is a security issue it may be resolved before release. Just the patch should be polished a little. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports patch for comm/rxtx
Pav Lucistnik píše v po 08. 09. 2008 v 22:13 +0200: Zach Metzinger píše v po 08. 09. 2008 v 14:33 -0500: The configure and configure.in files for comm/rxtx are broken when using java/jdk16. Two patches, below, fix this problem. The actual credit for figuring this out belongs to netbeans at gatworks.com. I just created patches to fix the issue. Unpatched, the port does not indicate an error, but the installation fails (no files installed). If installed by hand at this point, programs using rxtx fail due to: java.lang.UnsatisfiedLinkError: gnu.io.RXTXCommDriver.nativeGetVersion()Ljava/lang/String; thrown while loading gnu.io.RXTXCommDriver This looks useful. Let me test and commit it. Committed, thanks! -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] The Novice rogue. A rather shifty individual signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: HEADS UP: Ports freeze for 6.4 and 7.0 in effect
On Mon, 08 Sep 2008 23:51:32 +0400, Boris Samorodov [EMAIL PROTECTED] wrote:
Giorgos Keramidas [EMAIL PROTECTED] writes:
My emacs-22.3 release update almost made it into ports before the freeze
by 1-2 days. Is there any chance I could bribe you guys to get it in,
so we can have the latest stable 22.X GNU Emacs in the release?
Since it is a security issue it may be resolved before release. Just
the patch should be polished a little.
Thanks Boris :)
Yeah, the patch as it is attached in the port now lacks at least the
`bsd.emacs.mk' changes, which I attached to this message. I've
resubmitted the patch to ports/127168 in the version I emailed to Erwin
earlier.
I don't know how busy you are these days, and I wouldn't want to put too
much pressure on your schedule, but if you can email me about the
changes to polish the patch, I'll do it resubmit the patch to the PR,
and get it committed later today.
%%%
Index: Mk/bsd.emacs.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.emacs.mk,v
retrieving revision 1.73
diff -u -r1.73 bsd.emacs.mk
--- Mk/bsd.emacs.mk 3 Jun 2008 14:36:49 - 1.73
+++ Mk/bsd.emacs.mk 8 Sep 2008 19:46:40 -
@@ -83,7 +83,7 @@
# Emacs-22.x
.elif (${EMACS_PORT_NAME} == emacs22)
EMACS_NAME=emacs
-EMACS_VER= 22.2
+EMACS_VER= 22.3
EMACS_MAJOR_VER= 22
EMACS_LIBDIR?= share/${EMACS_NAME}
EMACS_LIBDIR_WITH_VER?=share/${EMACS_NAME}/${EMACS_VER}
Index: editors/emacs/Makefile
===
RCS file: /home/ncvs/ports/editors/emacs/Makefile,v
retrieving revision 1.79
diff -u -r1.79 Makefile
--- editors/emacs/Makefile 21 Aug 2008 06:16:55 - 1.79
+++ editors/emacs/Makefile 8 Sep 2008 19:46:05 -
@@ -29,7 +29,7 @@
xemacs-[0-9]* xemacs-devel-[0-9]* \
xemacs-mule-[0-9]* xemacs-devel-mule-[0-9]*
-EMACS_VER= 22.2
+EMACS_VER= 22.3
GNU_CONFIGURE= yes
USE_GMAKE= yes
Index: editors/emacs/distinfo
===
RCS file: /home/ncvs/ports/editors/emacs/distinfo,v
retrieving revision 1.13
diff -u -r1.13 distinfo
--- editors/emacs/distinfo 3 Jun 2008 14:36:49 - 1.13
+++ editors/emacs/distinfo 8 Sep 2008 19:46:05 -
@@ -1,3 +1,3 @@
-MD5 (emacs-22.2.tar.gz) = d6ee586b8752351334ebf072904c4d51
-SHA256 (emacs-22.2.tar.gz) =
216839e1fb38ca4f2ed0a07689fb47ee80d90845f34e0a56fe781d6aa462e367
-SIZE (emacs-22.2.tar.gz) = 38694318
+MD5 (emacs-22.3.tar.gz) = aa8ba34f548cd78b35914ae5a7bb87eb
+SHA256 (emacs-22.3.tar.gz) =
7bd9b719db8ee20c75ee0d256737f7fd2c0e2ea30a285a3afbfc32c856420d16
+SIZE (emacs-22.3.tar.gz) = 39587396
Index: editors/emacs/pkg-plist
===
RCS file: /home/ncvs/ports/editors/emacs/pkg-plist,v
retrieving revision 1.27
diff -u -r1.27 pkg-plist
--- editors/emacs/pkg-plist 3 Jun 2008 14:36:49 - 1.27
+++ editors/emacs/pkg-plist 8 Sep 2008 19:46:05 -
@@ -2381,10 +2381,10 @@
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/artist.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bib-mode.el.gz
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bib-mode.elc
-%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex.el.gz
-%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex-style.el.gz
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex-style.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/bibtex.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/conf-mode.el.gz
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/conf-mode.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/css-mode.el.gz
@@ -2403,6 +2403,16 @@
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/makeinfo.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/nroff-mode.el.gz
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/nroff-mode.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-export-latex.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-export-latex.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-irc.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-irc.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-mac-message.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-mac-message.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-mouse.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-mouse.elc
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-publish.el.gz
+%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org-publish.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org.el.gz
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/org.elc
%%DATADIR%%/%%EMACS_VER%%/lisp/textmodes/page-ext.el.gz
@@ -2620,9 +2630,10 @@
%%DATADIR%%/site-lisp/subdirs.el
var/games/emacs/snake-scores
var/games/emacs/tetris-scores
[EMAIL PROTECTED] libexec/emacs/%%EMACS_VER%%/%%EMACS_ARCH%%
[EMAIL PROTECTED] libexec/emacs/%%EMACS_VER%%
[EMAIL
Re: HEADS UP: Ports freeze for 6.4 and 7.0 in effect
Giorgos Keramidas [EMAIL PROTECTED] writes:
On Mon, 08 Sep 2008 23:51:32 +0400, Boris Samorodov [EMAIL PROTECTED] wrote:
Giorgos Keramidas [EMAIL PROTECTED] writes:
My emacs-22.3 release update almost made it into ports before the freeze
by 1-2 days. Is there any chance I could bribe you guys to get it in,
so we can have the latest stable 22.X GNU Emacs in the release?
Since it is a security issue it may be resolved before release. Just
the patch should be polished a little.
Thanks Boris :)
My pleasure. BTW since you released the PR I've taken it.
Yeah, the patch as it is attached in the port now lacks at least the
`bsd.emacs.mk' changes, which I attached to this message. I've
Usually I don't like such changes (to *.mk stuff) just before
freeze/release... But since you are the maintainer I'm not scared.
resubmitted the patch to ports/127168 in the version I emailed to Erwin
earlier.
I don't know how busy you are these days, and I wouldn't want to put too
I whish I had more spare time. :-(
much pressure on your schedule, but if you can email me about the
changes to polish the patch,
I've just was going to do it and have received your email.
First of all, I'd like to ask you to send me (may be without CC to
ports@) a proposed commit log. And since it is a security issue it
will be good to add an entry to ports/security/vuxml/vuln.xml.
I'll do it resubmit the patch to the PR,
and get it committed later today.
%%%
Index: Mk/bsd.emacs.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.emacs.mk,v
retrieving revision 1.73
diff -u -r1.73 bsd.emacs.mk
--- Mk/bsd.emacs.mk 3 Jun 2008 14:36:49 - 1.73
+++ Mk/bsd.emacs.mk 8 Sep 2008 19:46:40 -
@@ -83,7 +83,7 @@
# Emacs-22.x
.elif (${EMACS_PORT_NAME} == emacs22)
EMACS_NAME= emacs
-EMACS_VER= 22.2
+EMACS_VER= 22.3
As you may see at my email headers I'm already using the new emacs
version. But it states itself (at the window name) that it is 22.3.1.
I'm not sure why. I was always curious why those versions don't
correspond to the ports versions (i.e. PORTVERSION).
[...]
I'm not sure why the following patch is needed:
Index: editors/emacs/files/patch-man-Makefile.in
===
RCS file: /home/ncvs/ports/editors/emacs/files/patch-man-Makefile.in,v
retrieving revision 1.1
diff -u -r1.1 patch-man-Makefile.in
--- editors/emacs/files/patch-man-Makefile.in 16 Jul 2007 17:06:44 -
1.1
+++ editors/emacs/files/patch-man-Makefile.in 8 Sep 2008 19:46:05 -
@@ -1,5 +1,5 @@
./man/Makefile.in.orig Sat May 6 18:54:21 2006
-+++ ./man/Makefile.inFri Sep 1 21:10:08 2006
+--- man/Makefile.in.orig 2008-09-07 05:25:12.0 +0300
man/Makefile.in 2008-09-07 05:25:12.0 +0300
@@ -32,7 +32,7 @@
# The makeinfo program is part of the Texinfo distribution.
And those two patches seems to only rename an existing file
if I'm not mistaken. With all my respect to you as a mantainer
I'd say that you should have a good reason for that and if so
it worth mentionning at the commit's log. As for me I won't
do any renames while at ports freeze. But sure it's up to you. ;-)
Index: editors/emacs/files/patch-src-alloc.c
===
RCS file: editors/emacs/files/patch-src-alloc.c
diff -N editors/emacs/files/patch-src-alloc.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ editors/emacs/files/patch-src-alloc.c 8 Sep 2008 19:46:05 -
@@ -0,0 +1,15 @@
+--- src/alloc.c.orig 2008-09-07 05:25:27.0 +0300
src/alloc.c 2008-09-07 05:25:27.0 +0300
+@@ -4573,8 +4573,12 @@
+ needed on ia64 too. See mach_dep.c, where it also says inline
+ assembler doesn't work with relevant proprietary compilers. */
+ #ifdef __sparc__
++#ifdef __sparc64__
++ asm (flushw);
++#else
+ asm (ta 3);
+ #endif
++#endif
+
+ /* Save registers that we need to see on the stack. We need to see
+ registers used to hold register variables and registers used to
Index: editors/emacs/files/patch-src__alloc.c
===
RCS file: editors/emacs/files/patch-src__alloc.c
diff -N editors/emacs/files/patch-src__alloc.c
--- editors/emacs/files/patch-src__alloc.c16 Jul 2007 17:06:44 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
./src/alloc.c.orig Thu Aug 31 20:50:29 2006
-+++ ./src/alloc.cFri Sep 1 21:10:08 2006
-@@ -4560,7 +4560,11 @@
- needed on ia64 too. See mach_dep.c, where it also says inline
- assembler doesn't work with relevant proprietary compilers. */
- #ifdef sparc
-+#ifdef __sparc64__
-+ asm (flushw);
-+#else
- asm (ta 3);
-+#endif
- #endif
-
- /* Save registers that we need to see on the stack. We need
devel/libtool15 unconditionally hardcodes autodetected textproc/gsed
Hello all! While the ports are in freeze just want to point to the problem I have encountered. Not sure if this is a critical bug, just a bug or not a bug at all (so, no PR yet). If one installs/rebuilds devel/libtool15 while textproc/gsed is installed, libtool autodetects it and hardcodes gsed in itself. If later one removes gsed (and nothing prevents him from doing this), libtool is left in a broken state. FWIW, textproc/gsed is a BUILD_DEPENDS of some ports. Ideally, I think, one should hack libtool's configure framework to not detect gsed at all. Sorry, no patch here. Attached is the diff between unpacked libtool packages, one built with system sed and one - with gsed. Alexey. diff -ruN libtool-good/+CONTENTS libtool-bad/+CONTENTS --- libtool-good/+CONTENTS 2008-09-08 10:29:34.0 +0200 +++ libtool-bad/+CONTENTS 2008-09-08 20:50:41.0 +0200 @@ -4,7 +4,7 @@ @cwd /usr/local @comment $FreeBSD: ports/devel/libtool15/pkg-plist,v 1.13 2006/02/23 10:36:03 ade Exp $ bin/libtool [EMAIL PROTECTED] MD5:d82d18482a1bdb6a66b4a88e5f6af477 [EMAIL PROTECTED] MD5:553962c30b1587c8cd17cd90a252a8f2 bin/libtoolize @comment MD5:efbc69981145a9fac91f0f875ba11c3e share/aclocal/libtool.m4 diff -ruN libtool-good/bin/libtool libtool-bad/bin/libtool --- libtool-good/bin/libtool2008-09-08 10:29:29.0 +0200 +++ libtool-bad/bin/libtool 2008-09-08 20:50:36.0 +0200 @@ -30,10 +30,10 @@ # the same distribution terms that you use for the rest of that program. # A sed program that does not truncate output. -SED=/usr/bin/sed +SED=/usr/local/bin/gsed # Sed that helps us avoid accidentally triggering echo(1) options like -n. -Xsed=/usr/bin/sed -e 1s/^X// +Xsed=/usr/local/bin/gsed -e 1s/^X// # The HP-UX ksh and POSIX shell print the target directory to stdout # if CDPATH is set. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making ports from source with weird download restrictions
Brooks Davis wrote: As long as the license allows redistribution, we can host it on FreeBSD infrastructure using MASTER_SITE_LOCAL. 2) openocd - http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD - this is a bit more sensible - there's a stable SVN repository for it, it's just that the only ports I've seen are on sourceforge, and come from release .tgz archives, not a SVN archive (although I've never gotten a broken version from the openocd SVN). If someone pointed me at a port that built from SVN instead of a .tgz, I'm sure I could get the port done. Doing an svn export in the fetch stage is possible, but probably not ideal. In my devel/llvm-devel port I have a do-fetch target that fetches a snapshot and makes a tarball out of it, but I only use that for my own use and host a snapshot on the FreeBSD ftp servers for normal users since a tarball allows users to do a make clean and retry without having to fetch files again. Yes, this is the right way to do it. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: qemu problem
I am using qemu without any problems on a 7.0-p4 host, here are a few things I learnt a lot the way: 1. qemu (with kqemu kernel module loaded) will cause the problems you are having (extreme instability). 2. qemu-devel (with kqemu-devel kernel module loaded) will work fine until you start swapping memory, then it seems some sort of memory corruption will occur and crash the VM. If you have plenty of RAM give the -devel versions a go, otherwise do not use kqemu as it seems to be unstable. At the moment I am running a WindowsXP-SP3 VM with qemu-devel (albeit very slowly) without kqemu or stability problems. Thanks, Mark Picone, Trainee Unix Administrator Information Technology Services Division Phone: 03 5227 8602 International: +61 3 5227 0806 Fax: 03 5227 8799 International: +61 3 5227 8799 Email: [EMAIL PROTECTED] Website: http://www.deakin.edu.au -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Ganbold Sent: Sunday, 7 September 2008 3:54 PM To: Carlos A. M. dos Santos Cc: freebsd-ports Subject: Re: qemu problem Carlos A. M. dos Santos wrote: On Sat, Sep 6, 2008 at 9:52 AM, Ganbold [EMAIL PROTECTED] wrote: Hi, I have problem installing FreeBSD-7.0 using qemu in RELENG_7. It starts installing FreeBSD, but it crashes and dumps core in different places. It would be important to know what different places means. It is *during* installation or *after* it? Both. It happens when it tries to copy something, or when it tries to compile something. Yesterday it hanged and crashed when I tried to upgrade 7.0 to CURRENT (buildworld). Did somebody experience this before? devil# uname -an FreeBSD devil.micom.mng.net 7.0-STABLE FreeBSD 7.0-STABLE #9: Tue Aug 19 18:35:02 ULAT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL i386 devil# devil# qemu -boot d -hda freebsd.img -m 256 -cdrom ~tsgan/7.0-RELEASE-i386-disc1.iso -localtime -net nic -net tap smp 2 qemu: fatal: triple fault EAX=c0bfe67c EBX=000c ECX=f001003f EDX=f001003f ESI=c0bfe67c EDI=c24f7c60 EBP=c0bfe670 ESP=c0bfe5e0 EIP=c0a49004 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0028 00cf9300 CS =0020 00cf9b00 SS =0028 00cf9300 DS =0028 00cf9300 FS =0008 ffc0 ffcf93c0 GS =0028 00cf9300 LDT=0050 c0bfef20 0087 c000e2bf TR =0060 c0bff1c0 0067 c00089bf GDT= c0bfe5a0 0097 IDT= c0c00240 07ff CR0=e005003b CR2=f0010043 CR3=0141e000 CR4=0690 CCS=c0bfe67c CCD=c0bfe6e8 CCO=ADDB FCW=127f FSW=0020 [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4=ccc4 3ffe FPR5=8000 3ffe FPR6=e670d1fa33376800 3ffe FPR7=8e670d1fa3337800 4002 XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Abort (core dumped) QEMU treats triple faults generated by the guest OS as fatal errors, so it aborts execution and dumps core. In my opinion this is a too self-punishing behavior that chould be replaced by a less harmful VM restart. Triple faults are in fact fatal errors, so QEMU is correct, in theory. In practice, however, some operating systems generate triple faults on purpose in order to force a system reboot. The Linux kernel used to do this. It appears that the FreeBSD boot loader does it as well, so if you start FreeBSD and choose option 7 in the boot prompt you will ever crash QEMU. %pkg_info|grep qemu kqemu-kmod-1.3.0.p11_9 Kernel Accelerator for QEMU CPU Emulator qemu-0.9.1_9QEMU CPU Emulator %kldstat Id Refs AddressSize Name 1 22 0xc040 701ae4 kernel 21 0xc0b02000 5844 if_tap.ko 31 0xc0b08000 15524snd_hda.ko 42 0xc0b1e000 52a08sound.ko 52 0xc0b71000 10ebcdrm.ko 61 0xc0b82000 71c4 i915.ko 71 0xc0b8a000 1ff24kqemu.ko 81 0xc0baa000 b8c8 aio.ko 91 0xc0bb6000 6b3d0acpi.ko 101 0xc434 9000 if_bridge.ko 111 0xc4349000 6000 bridgestp.ko 122 0xc44ac000 d000 ipfw.ko 131 0xc450 4000 ipdivert.ko 141 0xc4526000 22000linux.ko 151 0xc45a e000 fuse.ko ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
opendx port
I have been looking at the graphics/opendx port (ports is the maintainer). If I select WITHOUT_JAVA, then in fact it builds and installs just fine on the amd64 architecture, despite that it is currently marked broken for amd64. If I don't select WITHOUT_JAVA, it doesn't even install properly on my i386 machines. The easiest way - at least as a band aid solution - to fix this port is to make WITHOUT_JAVA the default (presumably turn it into WITH_JAVA, or even delete this possibility altogether). I plan to submit a PR in a while, but not until the ports freeze is over. If anyone objects to my proposed solution, they have plenty of time to discuss it here. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
