postfix-vda-v11-2.9.5.patch
HI,I don’t download the postfix-vda-v11-2.9.5.patch. Please help me. Thank you! Chenyiyi Error: root@mail:/usr/ports/mail/postfix # make install clean === Found saved configuration for postfix-2.9.5,1 = postfix-vda-v11-2.9.5.patch doesn't seem to exist in /usr/ports/distfiles/postfix. = Attempting to fetch http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5. patch fetch: http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5.patch: Operation timed out = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/postfix and try again. *** [do-fetch] Error code 1 Stop in /usr/ports/mail/postfix. *** [install] Error code 1 ___ 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: [CFT] add a config.site cache for the ports
On Sun, Mar 24, 2013 at 08:56:52PM -0400, Steve Wills wrote: I'm sure your list probably includes this, but just in case, databases/db42 broke with this for me. Steve Here is a new version that fix the issue for db42 and others: http://people.freebsd.org/~bapt/config_site.diff Thanks all for testing. regards, Bapt pgpRxfyWGfnhS.pgp Description: PGP signature
Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
On Mon, Mar 25, 2013 at 1:03 AM, Ivan Klymenko fi...@ukr.net wrote: В Sun, 24 Mar 2013 14:05:07 +0200 Konstantin Belousov kostik...@gmail.com пишет: On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: I have uname -a FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri Mar 22 01:17:08 EET 2013 ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod After load the module a have kernel panic. Panic String: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:1396 http://pkgupdate.nevosoft.ru/backtrace.txt This looks like a vbox issue, the driver did not properly locked the object passed to the vm_page_alloc_contig(). If you want this fixed, you probably need to look up the code yourself, compiling the vbox kld with debugging, finding the offending call to vm_page_alloc_contig() and looking around it to see which object is passed and why it is not locked. The problem is that port commiter did not listen your advice: http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794 and used in the patch is not the functions that need http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314794r2=314796 I replaced the all function VM_OBJECT_RLOCK on VM_OBJECT_WLOCK and VM_OBJECT_RUNLOCK on VM_OBJECT_WUNLOCK and the kernel panic ceased. Thanks. This problem is solved. Thanks a lot! I've fixed it in the port now. Would be great if you could verify that it's correct now. -- Bernhard Froehlich http://www.bluelife.at/ ___ 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: cannot open tty-output
On 25.03.2013 00:58, Michael Gmelin wrote: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). I tried to go with ssh to localhost. The result is the same error. As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer Tmux helped. Thank you. (screen will do as well, but is also heavier). If you do jexec inside screen, it does not help. In jail screen does not start. -- Eugene ___ 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: cannot open tty-output
On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo -- Eugene ___ 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: ports/175104: [PATCH] net/libosip: update to 4.0.0
Muhammad Moinur Rahman wrote on 24.03.2013 23:08: Hi Ruslan, Do we need to do it in a REPOCOPY style? Or plain simple new port? Regards, Muhammad Yes, net/libosip will be svn cp'ed to net/libosip24 and then your patch applied to it (with you as maintainer). I'll try to do that later this day. On Mon, Mar 25, 2013 at 12:14 AM, Ruslan Makhmatkhanov cvs-...@yandex.ruwrote: Ruslan Makhmatkhanov wrote on 24.03.2013 22:07: Hi Muhammad, Muhammad Moinur Rahman wrote on 24.03.2013 17:41: Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad net/siproxd fails to build with this version of libosip [1] (and builds fine with 3.6.0), so or this update should be coordinated with siproxd maintainer (cc:ed) or it should be added to the tree as libosip24 or something. The first one is preferred, because there is newer version of siproxd that may work with new libosip. [1] http://people.freebsd.org/~rm/**siproxd-0.7.2_3.loghttp://people.freebsd.org/~rm/siproxd-0.7.2_3.log Looks like the first one will fail because 0.8.1 also requires libosip2 (3.x.x), according to release notes [1]. It may worth to check, but I'm afraid it will be new port. [1] http://siproxd.sourceforge.**net/index.php?op=relnoteshttp://siproxd.sourceforge.net/index.php?op=relnotes -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: ports/175104: [PATCH] net/libosip: update to 4.0.0
Thanks Ruslan. I think we need to modify the siproxd and libexosip too. But I have got a new patch for libexosip too. Should I create a patch for it or wait for libosip to complete? Regards, Muhammad On Mon, Mar 25, 2013 at 2:59 PM, Ruslan Makhmatkhanov cvs-...@yandex.ruwrote: Muhammad Moinur Rahman wrote on 24.03.2013 23:08: Hi Ruslan, Do we need to do it in a REPOCOPY style? Or plain simple new port? Regards, Muhammad Yes, net/libosip will be svn cp'ed to net/libosip24 and then your patch applied to it (with you as maintainer). I'll try to do that later this day. On Mon, Mar 25, 2013 at 12:14 AM, Ruslan Makhmatkhanov cvs-...@yandex.ru wrote: Ruslan Makhmatkhanov wrote on 24.03.2013 22:07: Hi Muhammad, Muhammad Moinur Rahman wrote on 24.03.2013 17:41: Hi, Can anyone please take care of ports/175104? It has been a while and I need to update libexosip2, which is dependent on this. Regards, Muhammad net/siproxd fails to build with this version of libosip [1] (and builds fine with 3.6.0), so or this update should be coordinated with siproxd maintainer (cc:ed) or it should be added to the tree as libosip24 or something. The first one is preferred, because there is newer version of siproxd that may work with new libosip. [1] http://people.freebsd.org/~rm/siproxd-0.7.2_3.loghttp://people.freebsd.org/~rm/**siproxd-0.7.2_3.log http://**people.freebsd.org/~rm/**siproxd-0.7.2_3.loghttp://people.freebsd.org/~rm/siproxd-0.7.2_3.log Looks like the first one will fail because 0.8.1 also requires libosip2 (3.x.x), according to release notes [1]. It may worth to check, but I'm afraid it will be new port. [1] http://siproxd.sourceforge.net/index.php?op=relnoteshttp** ://siproxd.sourceforge.net/**index.php?op=relnoteshttp://siproxd.sourceforge.net/index.php?op=relnotes -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: cannot open tty-output
Eugene V. Boontseff wrote on 25.03.2013 09:57: On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo Same here. With and without ezjail, same behaviour on all 8.x machines I tried. Using a serial console on a 9.1 machine yields the same behaviour when jexec is used, while there's no error when connected per ssh. MfG CoCo ___ 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: cannot open tty-output
On 03/25/13 14:01, Marco Steinbach wrote: Eugene V. Boontseff wrote on 25.03.2013 09:57: On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo Same here. With and without ezjail, same behaviour on all 8.x machines I tried. Using a serial console on a 9.1 machine yields the same behaviour when jexec is used, while there's no error when connected per ssh. MfG CoCo ___ 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 Hi All, Fixed in https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef Thanks Marco. After checking it will committed, but you already can test it: - change dialog4ports version to 0.1.2 - make makesum - portmaster -d /usr/ports/ports-mgmt/dialog4ports - add 2(stderr) in Tools/scripts/dialog4ports.sh in exec $DIALOG4PORTS 2 $OPTIONSFILE line. - test it :) -- WBR, Ilya A. Arkhipov ___ 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: maintainer timeout for FreeBSD commiters
On 2012-07-14 18:27, Chris Rees wrote: On 14 July 2012 16:24, Vitaly Magerya vmage...@gmail.com wrote: One problem (at least how it appears to me) is that when a PR gets automatically assigned to a maintainer who is also a committer, it is not automatically unassigned if the person is missing for a few months, and other committers ignore the PR because it is already assigned. This only happened once to me, but it took 6 months for another committer to notice it. And that was pretty fast, comparing to, say ports/154456 [1], which is open since 2011-02. Is automatic unassignment possible? Technically yes, but it's highly undesirable. You can feel free to bring it up here if you think that's happened. Hi, everyone. Two of my PRs, ports/175223 [1] and ports/176701 [2], have been automatically assigned to committers, and both have reached maintainer timeout a while ago. Could someone unassign them, so other committers could take a look? Thanks in advance. (I still think this should be done automatically. I would prefer not to bother everyone at ports@ for such things). [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175223 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176701 ___ 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: cannot open tty-output
Ilya A. Arkhipov wrote on 25.03.2013 11:11: On 03/25/13 14:01, Marco Steinbach wrote: Eugene V. Boontseff wrote on 25.03.2013 09:57: On 25.03.2013 03:37, Marco Steinbach wrote: Michael Gmelin schrieb: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer (screen will do as well, but is also heavier). dialog4ports(1) uses stdout for passing back results, where the former dialog(1) used stderr. I reverted the new behaviour back to the previous one, which fixed the problem for me. I don't know about other implications, though. Ilya (author of dialog4ports) is aware of the problem and having a look at it. I'm glad that other people are running into this, also. I was beginning to think, that there's something fundamentally wrong with the way our 8.x jails are configured. What could it be? I configure jail with ezjail. Nothing special.. :-) MfG CoCo Same here. With and without ezjail, same behaviour on all 8.x machines I tried. Using a serial console on a 9.1 machine yields the same behaviour when jexec is used, while there's no error when connected per ssh. MfG CoCo [...] Hi All, Fixed in https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef Thanks Marco. After checking it will committed, but you already can test it: - change dialog4ports version to 0.1.2 - make makesum - portmaster -d /usr/ports/ports-mgmt/dialog4ports - add 2(stderr) in Tools/scripts/dialog4ports.sh in exec $DIALOG4PORTS 2 $OPTIONSFILE line. - test it :) Tried it on 9.1 and 8.3, both with jexec using a serial console and jexec from a ssh connection. Works as advertised. Thank you for fixing this, Ilya :) MfG CoCo ___ 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
Current unassigned ports problem reports
(Note: an HTML version of this report is available at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .) The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description f ports/177368[PATCH] net/fping: Add option to compile in timestamps o ports/177367[maintainer update] www/xpi-ghostery version update o ports/177364[patch] math/scilab port build fails configuration ste o ports/177363graphics/pqiv aborts when opening an image f ports/177357[UPDATE] x11-themes/gtk-murrine-engine to 0.98.2 o ports/177353[PATCH] ftp/yafc: fix for NLS support o ports/177347[patch] x11/xtrlock needs to run setuid root f ports/177340[PATCH] devel/php-xdebug: update to 2.2.2 o ports/177338[NEW PORT] games/chessx: A Qt4 chess database applicat o ports/177336New port: security/sav o ports/177334New port: audio/lua51-mpd a lua mpd client o ports/177303[patch] net/quagga update to 0.99.22 o ports/177302[UPDATE] devel/z80ex to v1.1.20rev1 o ports/177300New port: java/intellij IntelliJ IDEA Community Editi f ports/177288x11-fm/krusader2 missing minimize icon in windowmaker f ports/177285[patch] fix audio/audacity build with samplerate=off f ports/177242x11-wm/wmconfig port update to version 1.3.8 o ports/177236devel/pmd - fix for building with strict unicode Java o ports/177228new version of editors/yui f ports/177222deskutils/cairo-dock-plugins won't build o ports/177220New Port: ports-mgmt/chucky f ports/177212[PATCH] net/nss_ldap: options ng o ports/177211net-mgmt/cflowd: cflowd CflowdPacketQueue.cc fix o ports/177208[NEW PORT] databases/yac: Yac is a user data cache bas o ports/177207multimedia/xbmc maint update to 12.1 f ports/177206[patch] graphics/optipng: update to 0.7.4 and fix CVE- f ports/177193audio/moc: please include FLAC support by default in p o ports/177182audio/mixxx segmentation fault o ports/177168[maintainer] mail/opendkim update to 2.8.1 f ports/177152sysutils/fusefs-kmod missing pkg-message file o ports/177113[MAINTAINER] update net/torsocks to version 1.2_1 o ports/177103security/secure_delete bsd.sites.mk: MASTER_SITES is o ports/177101[new port] www/qupzilla a QtWebKit web browser o ports/177100[maintainer] security/libgcrypt update to 1.5.1 o ports/177074[fix] audio/timidity and audio/guspat o ports/177071editors/slime not working with emacs-24 o ports/177046deskutils/taskjuggler: documentation attempts to write o ports/177042[new port] emulators/ucon64 f ports/177033[maintainer update] german/BBBike update to 3.18 o ports/177023x11-toolkits/flowcanvas doesn't build with recent grap o ports/177014new port: databases/sqlayer o ports/177001[NEW PORT] www/owncloud5: Personal cloud which runs on f ports/176995[patch] add config testing to net/quagga rc script f ports/176994lang/abcl: upgrade to version 1.1.1 f ports/176986[PATCH] games/uqm: Install the music and voice addons f ports/176932[PATCH] net-mgmt/nfsen: add missing RUN_DEPENDS f ports/176907[PATCH] sysutils/syslog-ng2 restore PKGNAMESUFFIX o ports/176893editors/libreoffice 4.0.1.2 doesn't start - crashed f ports/176874sysutils/fusefs-sshfs crashes on amd64 f ports/176830[PATCH] graphics/libexif-gtk: update to 0.4.0, Options o ports/176823[NEW PORT] www/redaxo: The REDAXO content management s f ports/176816www/privoxy+ipv6 is obsolete o ports/176811[PATCH] editors/semi-xemacs21-mule: should be unbreake f ports/176805rc scripts provided with security/heimdal haven't a co f ports/176785[patch] update games/nlarn from 0.7 to 0.7.2 f ports/176781math/openblas: /usr/include/sys/time.h:134:17: error: o ports/176767[patch] net-im/ari-yahoo broken on freebsd-head o ports/176745[new ports] www/eaccelerator-devel: PHP 5.4 compatible o ports/176720sysutils/syslinux 5.01 not installing all c32 files o ports/176716[patch] devel/boehm-gc update to 7.2d combining previo o ports/176708x11-fonts/code2001: broken checksum f ports/176706www/mambo: MASTER_SITES dns expired o ports/176701[patch] update games/angband from 3.3.2 to 3.4.1 o ports/176700Update
Re: maintainer timeout for FreeBSD commiters
On 3/25/2013 5:19 AM, Vitaly Magerya wrote: On 2012-07-14 18:27, Chris Rees wrote: On 14 July 2012 16:24, Vitaly Magerya vmage...@gmail.com wrote: One problem (at least how it appears to me) is that when a PR gets automatically assigned to a maintainer who is also a committer, it is not automatically unassigned if the person is missing for a few months, and other committers ignore the PR because it is already assigned. This only happened once to me, but it took 6 months for another committer to notice it. And that was pretty fast, comparing to, say ports/154456 [1], which is open since 2011-02. Is automatic unassignment possible? Technically yes, but it's highly undesirable. You can feel free to bring it up here if you think that's happened. Hi, everyone. Two of my PRs, ports/175223 [1] and ports/176701 [2], have been automatically assigned to committers, and both have reached maintainer timeout a while ago. Could someone unassign them, so other committers could take a look? Thanks in advance. (I still think this should be done automatically. I would prefer not to bother everyone at ports@ for such things). [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175223 [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/176701 I've reset these PR to the pool so anyone can grab them now. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
В Mon, 25 Mar 2013 09:04:40 +0100 Bernhard Fröhlich de...@freebsd.org пишет: On Mon, Mar 25, 2013 at 1:03 AM, Ivan Klymenko fi...@ukr.net wrote: В Sun, 24 Mar 2013 14:05:07 +0200 Konstantin Belousov kostik...@gmail.com пишет: On Sat, Mar 23, 2013 at 01:26:27PM +0200, Ivan Klymenko wrote: I have uname -a FreeBSD nonamehost 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248596: Fri Mar 22 01:17:08 EET 2013 ivan@nonamehost:/usr/obj/usr/src/sys/GENERIC amd64 I updated the ports tree to r314921 and recompiled virtualbox-ose-kmod After load the module a have kernel panic. Panic String: Lock vm object not exclusively locked @ /usr/src/sys/vm/vm_page.c:1396 http://pkgupdate.nevosoft.ru/backtrace.txt This looks like a vbox issue, the driver did not properly locked the object passed to the vm_page_alloc_contig(). If you want this fixed, you probably need to look up the code yourself, compiling the vbox kld with debugging, finding the offending call to vm_page_alloc_contig() and looking around it to see which object is passed and why it is not locked. The problem is that port commiter did not listen your advice: http://docs.freebsd.org/cgi/mid.cgi?20130312151751.GJ3794 and used in the patch is not the functions that need http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314794r2=314796 I replaced the all function VM_OBJECT_RLOCK on VM_OBJECT_WLOCK and VM_OBJECT_RUNLOCK on VM_OBJECT_WUNLOCK and the kernel panic ceased. Thanks. This problem is solved. Thanks a lot! I've fixed it in the port now. Would be great if you could verify that it's correct now. Yes - it is correctly http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797r2=315200 ___ 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: cannot open tty-output
On 25.03.2013 14:43, Marco Steinbach wrote:
Ilya A. Arkhipov wrote on 25.03.2013 11:11:
On 03/25/13 14:01, Marco Steinbach wrote:
Eugene V. Boontseff wrote on 25.03.2013 09:57:
On 25.03.2013 03:37, Marco Steinbach wrote:
Michael Gmelin schrieb:
On Sun, 24 Mar 2013 23:40:47 +0400
Eugene V. Boontseff eug...@home.wdc.spb.ru wrote:
*Marco Steinbach wrote:
*
Hi,
after installing dialog4ports, I'm getting the following behaviour
on each 8.3-STABLE I tried:
# jexec JID /bin/tcsh
# cd SomePortDir
# make config
cannot open tty-output
=== Options unchanged
#
Regardless, if I'm logged in on the console or connect to the host
via ssh.
I've also tried on 8.4-BETA1 (r248617), but got the same
behaviour.
Anyone else experiencing this ?
Yes, I have also experienced this.
8.3-STABLE r244863
Only if i do a make config in a jail.
Outside the jail all goes well.
MfG CoCo
This problem doesn't exist in 9.1. On 8 it only happens when you
jexeced into the jail (ssh should be ok). As a workaround you can
run
tmux (sysutils/tmux) within your jail and install ports from
within the
terminal multiplexer (screen will do as well, but is also heavier).
dialog4ports(1) uses stdout for passing back results, where the
former dialog(1) used stderr. I reverted the new behaviour back
to the previous one, which fixed the problem for me. I don't know
about other implications, though.
Ilya (author of dialog4ports) is aware of the problem and having a
look at it.
I'm glad that other people are running into this, also. I was
beginning to think, that there's something fundamentally wrong
with the way our 8.x jails are configured.
What could it be? I configure jail with ezjail. Nothing special.. :-)
MfG CoCo
Same here. With and without ezjail, same behaviour on all 8.x
machines I tried.
Using a serial console on a 9.1 machine yields the same behaviour
when jexec is used, while there's no error when connected per ssh.
MfG CoCo
[...]
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in exec
$DIALOG4PORTS 2 $OPTIONSFILE line.
- test it :)
Tried it on 9.1 and 8.3, both with jexec using a serial console and
jexec from a ssh connection. Works as advertised.
Thank you for fixing this, Ilya :)
Hmm.. I've applied the patch:
eugene@repo-home [/]# diff -u
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
---
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
2013-03-21 21:46:12.0 +0400
+++
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
2013-03-25 15:17:45.0 +0400
@@ -273,8 +273,8 @@
/* return all active items */
for (i = 0; i list_no; i++) {
if (items[i].state == 1) {
- printf(\%s\, items[i].name);
- printf( );
+ fprintf(stderr, \%s\, items[i].name);
+ fprintf(stderr, );
}
}
} else {
Then build the port dialog4ports again.
Then tried make config:
eugene@repo-home [/]# make -C /usr/ports/devel/apr1 config
cannot open tty-output
=== Options unchanged
FreeBSD 8.3 stable.
jexec from a console and from a gnome-terminal give the same result.
What I did wrong?
--
Eugene
___
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: LEGAL variable to capture generic issues
Eitan Adler li...@eitanadler.com wrote: I have been trying to capture the differences between LEGAL and the ports tree. At this point I am convinced we need a new variable to capture in a machine usable way issues such as special permission granted to distribute under the GPL or No license -- see http://cr.yp.to/softwarelaw.html;. Furthermore some ports define NO_PACKAGE for reasons of legality (GPL issues) and others defined it for other reasons (the package becomes too big). We have no method to differentiate between these two reasons. I'd like to add a global meta variable that captures this relationship. This would add the ability to mark per port special text to be included in LEGAL even if it doesn't affect the ports tee behavior. The patch below would require a little bit of additional work (ports which defined NO_PACKAGE for reasons other than legality would also need to define LEGAL_PACKAGE= yes). This would make it much easier to autogenerate LEGAL from the tree. Thoughts? Index: Mk/bsd.port.mk === --- Mk/bsd.port.mk(revision 315169) +++ Mk/bsd.port.mk(working copy) @@ -161,6 +161,9 @@ FreeBSD_MAINTAINER= port...@freebsd.org # but distfiles can be put on ftp sites and CDROMs. # FORBIDDEN - Package build should not be attempted because of # security vulnerabilities. +# LEGAL_TEXT - Port has legal issues (e.g., special +# permission to distribute, lacks a license). +# LEGAL_PACKAGE - Port has no legal issues but defines NO_PACKAGE As a ports maintainer I'm neither willing nor able to guarantee that my ports have no legal issues. In fact some of my ports are (according to the upstream) licensed under the GPLv2 which is partly invalid in my jurisdiction. Would this legal issue require a LEGAL_TEXT? Fabian signature.asc Description: PGP signature
Re: cannot open tty-output
On 3/25/2013 5:11 AM, Ilya A. Arkhipov wrote: Hi All, Fixed in https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef Thanks Marco. After checking it will committed, but you already can test it: - change dialog4ports version to 0.1.2 - make makesum - portmaster -d /usr/ports/ports-mgmt/dialog4ports - add 2(stderr) in Tools/scripts/dialog4ports.sh in exec $DIALOG4PORTS 2 $OPTIONSFILE line. - test it :) This has now been released to the ports tree. You will need to update dialog4ports as normal with portmaster to see the jail fixes. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: cannot open tty-output
Eugene V. Boontseff wrote on 25.03.2013 12:29:
On 25.03.2013 14:43, Marco Steinbach wrote:
Ilya A. Arkhipov wrote on 25.03.2013 11:11:
On 03/25/13 14:01, Marco Steinbach wrote:
Eugene V. Boontseff wrote on 25.03.2013 09:57:
On 25.03.2013 03:37, Marco Steinbach wrote:
Michael Gmelin schrieb:
On Sun, 24 Mar 2013 23:40:47 +0400
Eugene V. Boontseff eug...@home.wdc.spb.ru wrote:
*Marco Steinbach wrote:
*
Hi,
after installing dialog4ports, I'm getting the following behaviour
on each 8.3-STABLE I tried:
# jexec JID /bin/tcsh
# cd SomePortDir
# make config
cannot open tty-output
=== Options unchanged
#
Regardless, if I'm logged in on the console or connect to the host
via ssh.
I've also tried on 8.4-BETA1 (r248617), but got the same
behaviour.
Anyone else experiencing this ?
Yes, I have also experienced this.
8.3-STABLE r244863
Only if i do a make config in a jail.
Outside the jail all goes well.
MfG CoCo
This problem doesn't exist in 9.1. On 8 it only happens when you
jexeced into the jail (ssh should be ok). As a workaround you can
run
tmux (sysutils/tmux) within your jail and install ports from
within the
terminal multiplexer (screen will do as well, but is also heavier).
dialog4ports(1) uses stdout for passing back results, where the
former dialog(1) used stderr. I reverted the new behaviour back
to the previous one, which fixed the problem for me. I don't know
about other implications, though.
Ilya (author of dialog4ports) is aware of the problem and having a
look at it.
I'm glad that other people are running into this, also. I was
beginning to think, that there's something fundamentally wrong
with the way our 8.x jails are configured.
What could it be? I configure jail with ezjail. Nothing special.. :-)
MfG CoCo
Same here. With and without ezjail, same behaviour on all 8.x
machines I tried.
Using a serial console on a 9.1 machine yields the same behaviour
when jexec is used, while there's no error when connected per ssh.
MfG CoCo
[...]
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in exec
$DIALOG4PORTS 2 $OPTIONSFILE line.
- test it :)
Tried it on 9.1 and 8.3, both with jexec using a serial console and
jexec from a ssh connection. Works as advertised.
Thank you for fixing this, Ilya :)
Hmm.. I've applied the patch:
eugene@repo-home [/]# diff -u
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
---
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
2013-03-21 21:46:12.0 +0400
+++
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
2013-03-25 15:17:45.0 +0400
@@ -273,8 +273,8 @@
/* return all active items */
for (i = 0; i list_no; i++) {
if (items[i].state == 1) {
- printf(\%s\, items[i].name);
- printf( );
+ fprintf(stderr, \%s\, items[i].name);
+ fprintf(stderr, );
}
}
} else {
Then build the port dialog4ports again.
Then tried make config:
eugene@repo-home [/]# make -C /usr/ports/devel/apr1 config
cannot open tty-output
=== Options unchanged
FreeBSD 8.3 stable.
jexec from a console and from a gnome-terminal give the same result.
What I did wrong?
Did you change Tools/scripts/dialog4ports.sh, also ?
MfG CoCo
___
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: cannot open tty-output
On Mon, 25 Mar 2013 12:44:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: On 25.03.2013 00:58, Michael Gmelin wrote: On Sun, 24 Mar 2013 23:40:47 +0400 Eugene V. Boontseff eug...@home.wdc.spb.ru wrote: *Marco Steinbach wrote: * Hi, after installing dialog4ports, I'm getting the following behaviour on each 8.3-STABLE I tried: # jexec JID /bin/tcsh # cd SomePortDir # make config cannot open tty-output === Options unchanged # Regardless, if I'm logged in on the console or connect to the host via ssh. I've also tried on 8.4-BETA1 (r248617), but got the same behaviour. Anyone else experiencing this ? Yes, I have also experienced this. 8.3-STABLE r244863 Only if i do a make config in a jail. Outside the jail all goes well. MfG CoCo This problem doesn't exist in 9.1. On 8 it only happens when you jexeced into the jail (ssh should be ok). I tried to go with ssh to localhost. The result is the same error. As a workaround you can run tmux (sysutils/tmux) within your jail and install ports from within the terminal multiplexer Tmux helped. Thank you. (screen will do as well, but is also heavier). If you do jexec inside screen, it does not help. In jail screen does not start. I've got to admit that I didn't test screen myself. I've been using tmux on 8.x machines for a while for using the mysql monitor (mysql -p would echo the password you type otherwise). Based on that experience sshing from a remote machine (not localhost) should work though. -- Michael Gmelin ___ 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
postfix-vda-v11-2.9.5.patch
HI,I don’t download the postfix-vda-v11-2.9.5.patch. Please help me. Thank you! Chenyiyi Error: root@mail:/usr/ports/mail/postfix # make install clean === Found saved configuration for postfix-2.9.5,1 = postfix-vda-v11-2.9.5.patch doesn't seem to exist in /usr/ports/distfiles/postfix. = Attempting to fetch http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5. patch fetch: http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5.patch: Operation timed out = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/postfix and try again. *** [do-fetch] Error code 1 Stop in /usr/ports/mail/postfix. *** [install] Error code 1 ___ 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
postfix-vda-v11-2.9.5.patch
HI,I don’t download the postfix-vda-v11-2.9.5.patch. Please help me. Thank you! Chenyiyi Error: root@mail:/usr/ports/mail/postfix # make install clean === Found saved configuration for postfix-2.9.5,1 = postfix-vda-v11-2.9.5.patch doesn't seem to exist in /usr/ports/distfiles/postfix. = Attempting to fetch http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5. patch fetch: http://vda.sourceforge.net/VDA/postfix-vda-v11-2.9.5.patch: Operation timed out = Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/postfix/postfix-vda-v11-2. 9.5.patch: File unavailable (e.g., file not found, no access) = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/postfix and try again. *** [do-fetch] Error code 1 Stop in /usr/ports/mail/postfix. *** [install] Error code 1 ___ 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: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
Yes - it is correctly http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797r2=315200 Ah, thank you. My patch definitely was not right and I was wondering where the kpanic on load/startup was coming from. :-) ___ 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: cannot open tty-output
On 25.03.2013 15:40, Marco Steinbach wrote:
Eugene V. Boontseff wrote on 25.03.2013 12:29:
On 25.03.2013 14:43, Marco Steinbach wrote:
Ilya A. Arkhipov wrote on 25.03.2013 11:11:
On 03/25/13 14:01, Marco Steinbach wrote:
Eugene V. Boontseff wrote on 25.03.2013 09:57:
On 25.03.2013 03:37, Marco Steinbach wrote:
Michael Gmelin schrieb:
On Sun, 24 Mar 2013 23:40:47 +0400
Eugene V. Boontseff eug...@home.wdc.spb.ru wrote:
*Marco Steinbach wrote:
*
Hi,
after installing dialog4ports, I'm getting the following
behaviour
on each 8.3-STABLE I tried:
# jexec JID /bin/tcsh
# cd SomePortDir
# make config
cannot open tty-output
=== Options unchanged
#
Regardless, if I'm logged in on the console or connect to the
host
via ssh.
I've also tried on 8.4-BETA1 (r248617), but got the same
behaviour.
Anyone else experiencing this ?
Yes, I have also experienced this.
8.3-STABLE r244863
Only if i do a make config in a jail.
Outside the jail all goes well.
MfG CoCo
This problem doesn't exist in 9.1. On 8 it only happens when you
jexeced into the jail (ssh should be ok). As a workaround you
can run
tmux (sysutils/tmux) within your jail and install ports from
within the
terminal multiplexer (screen will do as well, but is also
heavier).
dialog4ports(1) uses stdout for passing back results, where the
former dialog(1) used stderr. I reverted the new behaviour back
to the previous one, which fixed the problem for me. I don't
know about other implications, though.
Ilya (author of dialog4ports) is aware of the problem and having
a look at it.
I'm glad that other people are running into this, also. I was
beginning to think, that there's something fundamentally wrong
with the way our 8.x jails are configured.
What could it be? I configure jail with ezjail. Nothing special..
:-)
MfG CoCo
Same here. With and without ezjail, same behaviour on all 8.x
machines I tried.
Using a serial console on a 9.1 machine yields the same behaviour
when jexec is used, while there's no error when connected per ssh.
MfG CoCo
[...]
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in exec
$DIALOG4PORTS 2 $OPTIONSFILE line.
- test it :)
Tried it on 9.1 and 8.3, both with jexec using a serial console and
jexec from a ssh connection. Works as advertised.
Thank you for fixing this, Ilya :)
Hmm.. I've applied the patch:
eugene@repo-home [/]# diff -u
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
---
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c.orig
2013-03-21 21:46:12.0 +0400
+++
/var/ports/basejail/usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.1/dialog4ports.c
2013-03-25 15:17:45.0 +0400
@@ -273,8 +273,8 @@
/* return all active items */
for (i = 0; i list_no; i++) {
if (items[i].state == 1) {
- printf(\%s\, items[i].name);
- printf( );
+ fprintf(stderr, \%s\,
items[i].name);
+ fprintf(stderr, );
}
}
} else {
Then build the port dialog4ports again.
Then tried make config:
eugene@repo-home [/]# make -C /usr/ports/devel/apr1 config
cannot open tty-output
=== Options unchanged
FreeBSD 8.3 stable.
jexec from a console and from a gnome-terminal give the same result.
What I did wrong?
Did you change Tools/scripts/dialog4ports.sh, also ?
Oh, I completely lost sight of it.
Everything works.
MfG CoCo
--
Eugene
___
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
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ deskutils/gworkspace| 0.9.1 | 0.9.2 +-+ deskutils/gworkspace-gwmetadata | 0.9.1 | 0.9.2 +-+ devel/rubygem-notify| 0.4.0 | 0.5.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt If wish to stop receiving portscout reminders, please contact portsc...@portscout.freebsd.org Thanks. ___ 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: LEGAL variable to capture generic issues
Eitan Adler ha scritto: I have been trying to capture the differences between LEGAL and the ports tree. At this point I am convinced we need a new variable to capture in a machine usable way issues such as special permission granted to distribute under the GPL or No license -- see http://cr.yp.to/softwarelaw.html;. Furthermore some ports define NO_PACKAGE for reasons of legality (GPL issues) and others defined it for other reasons (the package becomes too big). We have no method to differentiate between these two reasons. For license reasons we already have this: # RESTRICTED- Prevent the distribution of distfiles and packages to # the FTP sites or on CDROM (e.g. forbidden by license # considerations). and related /usr/ports/LEGAL entries. -- Alex Dupre ___ 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: LEGAL variable to capture generic issues
On 25 March 2013 09:36, Alex Dupre a...@freebsd.org wrote: Eitan Adler ha scritto: I have been trying to capture the differences between LEGAL and the ports tree. At this point I am convinced we need a new variable to capture in a machine usable way issues such as special permission granted to distribute under the GPL or No license -- see http://cr.yp.to/softwarelaw.html;. Furthermore some ports define NO_PACKAGE for reasons of legality (GPL issues) and others defined it for other reasons (the package becomes too big). We have no method to differentiate between these two reasons. For license reasons we already have this: # RESTRICTED- Prevent the distribution of distfiles and packages to # the FTP sites or on CDROM (e.g. forbidden by license # considerations). RESTRICTED does not cover special permission granted to distribute and other not-a-restriction things. and related /usr/ports/LEGAL entries. The intent is to generate /usr/ports/LEGAL from the ports tree. -- Eitan Adler ___ 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: LEGAL variable to capture generic issues
Eitan Adler ha scritto: RESTRICTED does not cover special permission granted to distribute and other not-a-restriction things. And why do we need them? RESTRICTED is for !distributable, exactly as the LEGAL file. We can improve RESTRICTED to automatically generate LEGAL. For particular licenses we already have a controversial LICENSE framework. -- Alex Dupre ___ 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: LEGAL variable to capture generic issues
On 25 March 2013 10:08, Alex Dupre a...@freebsd.org wrote: Eitan Adler ha scritto: RESTRICTED does not cover special permission granted to distribute and other not-a-restriction things. And why do we need them? RESTRICTED is for !distributable, exactly as the LEGAL file. We can improve RESTRICTED to automatically generate LEGAL. The LEGAL file is for a broader set of things than just RESTRICTED. It covers no commercial use which is NO_CDROM but not RESTRICTED and it covers normally something else, but we have special permission to use the GPLv3. We have no way to express the latter in ports in a usable manner. For particular licenses we already have a controversial LICENSE framework. I have no comment on the framework. It has many issues, but is not related to this discussion. -- Eitan Adler ___ 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: LEGAL variable to capture generic issues
Eitan Adler ha scritto: The LEGAL file is for a broader set of things than just RESTRICTED. It covers no commercial use which is NO_CDROM but not RESTRICTED Yup, LEGAL is both NO_CDROM and RESTRICTED, and RESTRICTED_FILES already contains the list of !distributable files. I'd say this is enough for generating LEGAL (modulo correct use of these knobs). -- Alex Dupre ___ 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: LEGAL variable to capture generic issues
On 25 March 2013 10:37, Alex Dupre a...@freebsd.org wrote: Eitan Adler ha scritto: The LEGAL file is for a broader set of things than just RESTRICTED. It covers no commercial use which is NO_CDROM but not RESTRICTED Yup, LEGAL is both NO_CDROM and RESTRICTED, and RESTRICTED_FILES already contains the list of !distributable files. I'd say this is enough for generating LEGAL (modulo correct use of these knobs). This is insufficient to include, say, line 212: raknet-*devel/raknetOriginal license is Indy license, special authorization granted to provide RakNet under GPL v3 -- Eitan Adler ___ 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: LEGAL variable to capture generic issues
Eitan Adler ha scritto: This is insufficient to include, say, line 212: raknet-*devel/raknetOriginal license is Indy license, special authorization granted to provide RakNet under GPL v3 Ehmm, I could argue about the private email permission, but if it's listed in LEGAL it should be marked as RESTRICTED or NO_CDROM, otherwise it should not listed there (the LICENSE framework already says that special authorization has been granted). -- Alex Dupre ___ 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: LEGAL variable to capture generic issues
On 25 March 2013 10:49, Alex Dupre a...@freebsd.org wrote: Eitan Adler ha scritto: This is insufficient to include, say, line 212: raknet-*devel/raknetOriginal license is Indy license, special authorization granted to provide RakNet under GPL v3 Ehmm, I could argue about the private email permission The email has been made public (see the files directory). but if it's listed in LEGAL it should be marked as RESTRICTED or NO_CDROM, otherwise it should not listed there or NO_PACKAGE. However, merely being listed as NO_PACKAGE is insufficient as some NO_PACKAGE entries are not for legal issues. (the LICENSE framework already says that special authorization has been granted). It should also be listed in LEGAL in this case (there was a long discussion about this in the past). -- Eitan Adler ___ 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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From ger...@pfeifer.com Mon Mar 18 00:32:16 2013
On Sat, 16 Mar 2013, Bryan Drewery wrote:
So I wonder if there are any side effects or unexpected
effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7?
I don't think this is working as expected. See also ports/177017
which I
believe is a bsd.gcc.mk issue and not a pkgng or portmaster issue. My
understanding is that this user want
When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47
package, but still is using lang/gcc:
You're right!
In addition to setting GCC_DEFAULT_VERSION to 4.7, one also needs
to adjust the following in Mk/bsd.gcc.mk:
. if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
_GCC_PORT:= gcc
. else
_GCC_PORT:= gcc${V}
. endif
The most correct way of doing this would be replacing the first line by
. if ${_USE_GCC} == 4.6
That should then do the right thing; or you could just remove everything
except for
_GCC_PORT:= gcc${V}
Either should work.
(I'd love to update GCC_DEFAULT_VERSION to 4.7 one of these days; is
the cluster sufficiently recovered for a test run?)
Gerald
Hi Gerald
I've now run ia64 with the above change for over 2 weeks,
mostly rebuilding ports, etc.
I didn't see any issues with gcc47.
So, from my very limited testing,
gcc47 can be made default.
Also, I saw that gcc48 is released.
Do you have any plans to make gcc49 port?
Anton
___
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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Mon, 25 Mar 2013, Anton Shterenlikht wrote: I've now run ia64 with the above change for over 2 weeks, mostly rebuilding ports, etc. I didn't see any issues with gcc47. So, from my very limited testing, gcc47 can be made default. Thanks for the feedback, Anton! To really make that switch globally, we'll need more extensive testing, a full ports builds run, since there is a chance that some port you are not using may be broken, and I hope to get this done in the coming weeks. Also, I saw that gcc48 is released. Do you have any plans to make gcc49 port? I did so yesterday. :-) It should be in your ports tree with the next update. Gerald ___ 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
${PORT_OPTIONS:MDOCS}
I have a problem with updating a Makefile for an existing port. When
running portlint -a on the Makefile, it pops up with this warning:
WARN: Makefile: [53]: NOPORTDOCS found. Consider using
PORT_OPTIONS:MDOCS
So, I have tried doing what the Porters Handbook suggested, and it just
bombs out with this useless message:
Makefile, line 53: Malformed conditional (${PORT_OPTIONS:MDOCS})
Makefile, line 58: if-less endif
make: fatal errors encountered -- cannot continue
I have tried all sorts of edits, but sans success. This is the latest
edit. I have omitted the useless stuff, I think.
PORTDOCS= README CHANGE.LOG INSTALL Release.pdf
post-install:
@if [ ! -d ${ETCDIR} ]; then \
${MKDIR} ${ETCDIR} ; \
fi
@${INSTALL_DATA} ${FILESDIR}/default.sample ${ETCDIR}
@if [ ! -f ${ETCDIR}/default ]; then \
${CP} -p ${ETCDIR}/default.sample \
${ETCDIR}/default ; \
fi
do-install:
cd ${WRKSRC} ${INSTALL_SCRIPT} ${PORTNAME}.sh ${PREFIX}/bin
cd ${WRKSRC} ${INSTALL_MAN} scamp.1 ${MANPREFIX}/man/man1
# Documentation
.if ${PORT_OPTIONS:MDOCS}
${MKDIR} ${DOCSDIR}
for f in ${PORTDOCS}
${INSTALL_DATA} ${WRKSRC}/${f} ${DOCSDIR}
endfor
.endif
@${CAT} ${PKGMESSAGE}
.include bsd.port.mk
So what am I doing wrong?
--
Carmel ✌
carmel...@hotmail.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: ${PORT_OPTIONS:MDOCS}
Carmel ha scritto:
I have a problem with updating a Makefile for an existing port. When
running portlint -a on the Makefile, it pops up with this warning:
WARN: Makefile: [53]: NOPORTDOCS found. Consider using
PORT_OPTIONS:MDOCS
So, I have tried doing what the Porters Handbook suggested, and it just
bombs out with this useless message:
You should add:
.include bsd.port.options.mk
before checking for ${PORT_OPTIONS:MDOCS}
--
Alex Dupre
___
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: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
Em Seg, 2013-03-25 às 04:49 -0700, sean bruno escreveu: Yes - it is correctly http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797r2=315200 Ah, thank you. My patch definitely was not right and I was wondering where the kpanic on load/startup was coming from. :-) ___ 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 Hello, I am running BSD10 svn=248699 and virtualbox runs without problems ___ 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: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@pfeifer.com wrote: On Mon, 25 Mar 2013, Anton Shterenlikht wrote: I've now run ia64 with the above change for over 2 weeks, mostly rebuilding ports, etc. I didn't see any issues with gcc47. So, from my very limited testing, gcc47 can be made default. Thanks for the feedback, Anton! To really make that switch globally, we'll need more extensive testing, a full ports builds run, since there is a chance that some port you are not using may be broken, and I hope to get this done in the coming weeks. From my expiriense, devel/glib20 cannot be compiled with gcc47. Reason, as I see it, the reality may be slightly different or more complex, but, I hope it will give a hint about direction: 1. glib'c configure checks whether -Bsymbolic-functions option is supported by linker (by passing it as -Wl,-Bsymbolic-functions through CC/CXX frontend) 2. Because gcc47 frontend calls /usr/local/lib/ld, which is fresh enough, the check passes as supported. 3. configure registers gcc47 as linker frontend, generates libtool script, and so on... 4. At the real link time the port machinery hijacks invocations to the generated libtool scrips and redirects them to the own gnome-libtool, which know nothing about configure results, and which uses hardcoded cc instead of requested gcc47 5. cc is /usr/bin/cc aka gcc-4.2 in my case. It uses /usr/bin/ld (from base) instead of /usr/local/bin/ld (from ports). 6. Base version lf ld is old enough and know nothing about -Bsymbolic-functions flag. 7. As consequence, build finishes with linker error. Again: The description above may be inaccurate or wrong in details. I didn't investigate the problem throughly. But it is how it looks like. -- Andrew W. Nosenko andrew.w.nose...@gmail.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: ${PORT_OPTIONS:MDOCS}
On Mon, 25 Mar 2013 17:23:10 +0100
Alex Dupre articulated:
Carmel ha scritto:
I have a problem with updating a Makefile for an existing port. When
running portlint -a on the Makefile, it pops up with this warning:
WARN: Makefile: [53]: NOPORTDOCS found. Consider using
PORT_OPTIONS:MDOCS
So, I have tried doing what the Porters Handbook suggested, and it
just bombs out with this useless message:
You should add:
.include bsd.port.options.mk
before checking for ${PORT_OPTIONS:MDOCS}
Thanks, I don't recall seeing that even mentioned, although it
probably was. It took awhile but I did finally figure out where to
place it in the file.
--
Carmel ✌
carmel...@hotmail.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: cannot open tty-output
On 3/25/2013 6:35 AM, Bryan Drewery wrote: On 3/25/2013 5:11 AM, Ilya A. Arkhipov wrote: Hi All, Fixed in https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef Thanks Marco. After checking it will committed, but you already can test it: - change dialog4ports version to 0.1.2 - make makesum - portmaster -d /usr/ports/ports-mgmt/dialog4ports - add 2(stderr) in Tools/scripts/dialog4ports.sh in exec $DIALOG4PORTS 2 $OPTIONSFILE line. - test it :) This has now been released to the ports tree. You will need to update dialog4ports as normal with portmaster to see the jail fixes. The jail fix was reverted for now. We missed that changing the wrapper (Tools/scripts/dialog4ports.sh) from stdout to stderr would break existing installs of previous versions. So this would cause the options to not save (and be cleared) if using an older version with the new wrapper. If you are using a jail just remove the '2' at the end of the wrapper for now until we get a more backwards-compatible change ready. -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: ${PORT_OPTIONS:MDOCS}
On 25 Mar 2013 17:36, Carmel carmel...@hotmail.com wrote:
On Mon, 25 Mar 2013 17:23:10 +0100
Alex Dupre articulated:
Carmel ha scritto:
I have a problem with updating a Makefile for an existing port. When
running portlint -a on the Makefile, it pops up with this warning:
WARN: Makefile: [53]: NOPORTDOCS found. Consider using
PORT_OPTIONS:MDOCS
So, I have tried doing what the Porters Handbook suggested, and it
just bombs out with this useless message:
You should add:
.include bsd.port.options.mk
before checking for ${PORT_OPTIONS:MDOCS}
Thanks, I don't recall seeing that even mentioned, although it
probably was. It took awhile but I did finally figure out where to
place it in the file.
Hm, it's not mentioned.
If the text below the inclusion of bsd.port.options.mk were included,
would that be helpful?
Chris
___
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: OPTIONSng: Overide options in /var/db/ports/*/options ?
Marco Steinbach wrote on 17.03.2013 21:02: Baptiste Daroussin wrote on 17.03.2013 19:49: On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote: Chris Rees wrote on 17.03.2013 17:15: On 17 Mar 2013 15:45, Marco Steinbach c...@executive-computing.de wrote: Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. No, that's a bad idea. It's more confusing to have options not being set that are checked in the OPTIONS dialog. Setting those in make.conf sets defaults, and allows them to be overridden in individual ports. Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what I willingly or accidentially configured in an OPTIONS dialog (or is defaulted to in a ports Makefile), either because I didn't understand the dependancy of a choice, I fat-fingered something or someone helps me configuring something, and wants to make sure I get it right: OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS Same goes for the complementary case of having options set forcibly, either system-wide or per port: particularport_SET_FORCE= EXAMPLES DOCS I'd set these in /etc/make.conf, and be done for good. I have a local patch for that kind of behaviour, but wanted to check for possible alternatives besides the beaten path, before bothering bapt@. The thing is half of people wants the /var/db/*/options to be the last word, the other half want the behaviour you are exposing, so getting a final word that will satisfy everyone is hard. I think the approach of having a choice between the two by allowing for a new 'force it down the throat'-mechanism could serve both quite nicely. Existing /var/db/*/options files would still be read, but options can be forcibly set or unset from /etc/make.conf, overriding the corresponding options setting in options files. I personnally really dislike /var/db/port/*/options and the dialog :). The new option framework has been design to: 1/ respect the same behaviour has it used to be before: /var/db/port/*/options has the final word. 2/ provide the ability to users to be able to tune the whole system in a consistent way. 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you can't save a option file by mistake. What we can probably do in the end is provide a new macro to totally in all cases ignore /var/db/port/*/options. Would that satisfy your needs? I'll recap the approaches: a) Options in /etc/make.conf only take precedence, if no /var/db/ports/*/options file exists for a given port b) Options in /etc/make.conf always take precedence over options of the same name read from /var/db/ports/*/options c) Options in /etc/make.conf are the only source of wisdom, anything in /var/db/ports/*/options is ignored a) is currently in place (*_SET, *_UNSET) b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE) c) probably comes closer to what you're suggesting I've attached my current workaround for b), where I simply duplicated parts of your code in bsd.options.mk, adding a new suffix. Maybe this further clarifies, what I'm currently missing. c) would come in handy, if you'd like to make sure nothing whatsoever from /var/db/ports/*/options impacts a build. Baptiste, are you considering b) ? MfG CoCo ___ 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: ${PORT_OPTIONS:MDOCS}
On Mon, 25 Mar 2013 19:12:53 + Chris Rees articulated: Hm, it's not mentioned. If the text below the inclusion of bsd.port.options.mk were included, would that be helpful? Yes, it most certainly would. I am surprised that it was not mentioned. -- Carmel ✌ carmel...@hotmail.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: cannot open tty-output
Bryan Drewery wrote on 25.03.2013 19:46:
On 3/25/2013 6:35 AM, Bryan Drewery wrote:
On 3/25/2013 5:11 AM, Ilya A. Arkhipov wrote:
Hi All,
Fixed in
https://bitbucket.org/m1cro/d4p/commits/42e03ab186b30120fa79e2d0a6093a3c673385ef
Thanks Marco.
After checking it will committed, but you already can test it:
- change dialog4ports version to 0.1.2
- make makesum
- portmaster -d /usr/ports/ports-mgmt/dialog4ports
- add 2(stderr) in Tools/scripts/dialog4ports.sh in exec $DIALOG4PORTS
2 $OPTIONSFILE line.
- test it :)
This has now been released to the ports tree. You will need to update
dialog4ports as normal with portmaster to see the jail fixes.
The jail fix was reverted for now. We missed that changing the wrapper
(Tools/scripts/dialog4ports.sh) from stdout to stderr would break
existing installs of previous versions. So this would cause the options
to not save (and be cleared) if using an older version with the new wrapper.
If you are using a jail just remove the '2' at the end of the wrapper
for now until we get a more backwards-compatible change ready.
How about enabling dialog4ports to show it's version ? That would
reduce the problem to having a look at the output of e.g.
'${PREFIX}/bin/dialog4ports --version'. Something like 'Version: 0.1.2'
would do, which is easily parseable.
From there, you'd be able to check this in the wrapper, and act
differently on different versions (no, please do not upgrade anything
without ask the user first, although it's tempting :) ). Naturally, if
the executable exists, but no version output is detected, then it's an
old version.
MfG CoCo
___
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: OPTIONSng: Overide options in /var/db/ports/*/options ?
On Mon, Mar 25, 2013 at 09:45:19PM +0100, Marco Steinbach wrote: Marco Steinbach wrote on 17.03.2013 21:02: Baptiste Daroussin wrote on 17.03.2013 19:49: On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote: Chris Rees wrote on 17.03.2013 17:15: On 17 Mar 2013 15:45, Marco Steinbach c...@executive-computing.de wrote: Matthew Seaman wrote on 17.03.2013 14:49: On 17/03/2013 12:16, Marco Steinbach wrote: Hi, is there a way to overide options stored in /var/db/ports/*/options, basically getting back the pre-OPTIONSng behaviour of being able to overide port options in /etc/make.conf ? Before OPTIONSng was introduced, I was able to specify options in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that option in any port (or just specific ones, by e.g. checking .CURDIR), regardless of the setting the ports option file contained. Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in /etc/make.conf uniquename_SET= FOO BAR BAZ uniquename_UNSET= BLURFL will override the default settings in that port's Makefile for the FOO, BAR, BAZ and BLURFL options. Note: this won't override any settings you make from an options dialog. Might be a good idea to 'make rmconfig' if you only want to rely on /etc/make.conf [...] Exactly my point. Currently, with OPTIONSng there seems to be no way to overide anything in /var/db/ports/*/options. I find it irritating, that I no longer can be sure about options in /etc/make.conf. I have to check/reconfigure to make sure. As much as I like OPTIONSng (especially in combination with dialog4ports), this is one thing I'd very much like OPTIONSng to relearn: Enforce options regardless of what's in a ports options file. No, that's a bad idea. It's more confusing to have options not being set that are checked in the OPTIONS dialog. Setting those in make.conf sets defaults, and allows them to be overridden in individual ports. Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what I willingly or accidentially configured in an OPTIONS dialog (or is defaulted to in a ports Makefile), either because I didn't understand the dependancy of a choice, I fat-fingered something or someone helps me configuring something, and wants to make sure I get it right: OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS Same goes for the complementary case of having options set forcibly, either system-wide or per port: particularport_SET_FORCE= EXAMPLES DOCS I'd set these in /etc/make.conf, and be done for good. I have a local patch for that kind of behaviour, but wanted to check for possible alternatives besides the beaten path, before bothering bapt@. The thing is half of people wants the /var/db/*/options to be the last word, the other half want the behaviour you are exposing, so getting a final word that will satisfy everyone is hard. I think the approach of having a choice between the two by allowing for a new 'force it down the throat'-mechanism could serve both quite nicely. Existing /var/db/*/options files would still be read, but options can be forcibly set or unset from /etc/make.conf, overriding the corresponding options setting in options files. I personnally really dislike /var/db/port/*/options and the dialog :). The new option framework has been design to: 1/ respect the same behaviour has it used to be before: /var/db/port/*/options has the final word. 2/ provide the ability to users to be able to tune the whole system in a consistent way. 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you can't save a option file by mistake. What we can probably do in the end is provide a new macro to totally in all cases ignore /var/db/port/*/options. Would that satisfy your needs? I'll recap the approaches: a) Options in /etc/make.conf only take precedence, if no /var/db/ports/*/options file exists for a given port b) Options in /etc/make.conf always take precedence over options of the same name read from /var/db/ports/*/options c) Options in /etc/make.conf are the only source of wisdom, anything in /var/db/ports/*/options is ignored a) is currently in place (*_SET, *_UNSET) b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE) c) probably comes closer to what you're suggesting I've attached my current workaround for b), where I simply duplicated parts of your code in bsd.options.mk, adding a new suffix. Maybe this further clarifies, what I'm currently missing. c) would come in handy, if you'd like to make sure nothing whatsoever from /var/db/ports/*/options impacts a build. Baptiste, are you considering b) ? MfG CoCo I will definitly I need
Status of packages
There haven't been any package updates since last October, even September in the soon to be legacy case of RELENG_8 i386. So lets say six months. Last status I noticed was in January pending 'security review of build farm code'. Nearly two months later this would seem to be an unusual amount of time to leave those users who use only packages (not ports) hanging. What needs done to get this rolling and out to the users again? Thx. ___ 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
[HEADS UP] Ports Freeze for upcoming 8.4 Release
The FreeBSD Ports Management team as decided to do a hard freeze to co-incide with the release of 8.4-FreeBSD RC1, tentatively scheduled for March 30. During this hard freeze, only security updates, critical fixes, and related fixes related to the clean-up of the tree will be allowed. This is a change from our recent Feature Safe policy. If you want/need something to get into the tree after the freeze, email a patch to portmgr@, and await approval. Once we feel the tree is in good shape for shipping, we will open up for a slush. More details on that once we get closer to release time. Thomas on behalf of portmgr@ ___ 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
