Re: [e17]please remove some unneeded patches. And cannot fetch enlightenment-0.17.0.tar.bz2
On Sun, 2012-12-23 at 15:23 +0900, Yamaya Takashi wrote: > Hi, > > Following patches cannot be patched. They seem unneeded. > devel/eio/files/patch-configure > lang/embryo/files/patch-src_lib_embryo_str.c > x11-wm/enlightenment/files/patch-src-modules-mixer-pa.c > x11-wm/enlightenment/files/patch-configure > > And cannot fetch enlightenment-0.17.0.tar.bz2. I removed unneeded patches ___ 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: E17 won't start
On Mon, 2012-12-24 at 03:46 +0100, Dominic Fandrey wrote: > On 24/12/2012 03:28, Dominic Fandrey wrote: > > On 24/12/2012 03:19, Dominic Fandrey wrote: > >> > >> On 23/12/2012 20:18, Matthieu Volat wrote: > >>> I've been unable to start an enlightenment session after the recent > >>> upgrade to the release. > >> > >> I have the same issue. > >> > >>> I just have a black screen with the mouse (that can move) and nothing > >>> else. There is nothing that can help in ~/.xession-errors... > >> > >> Well it's noteworthy that after the first ESTART: SLEEP message I've > >> got a line that says "PAUSE !". As far as I can figure this is unusual. > >> > >> If there's anything /unusual/ in my install, it's that all ports that > >> can be built witch clang, were built with clang. > > > > I just ran it in gdb. But gdb reports a series of signals: > > SIGTRAP > > SIGTRAP > > SIGTTIN > > SIGTRAP > > Now, finally the startup procedures are executed until: > > ESTART: 0.34318 [0.1] - Manage all windows > > ESTART: 0.36315 [0.01997] - MAIN LOOP AT LAST > > ESTART: 0.64266 [0.27951] - SLEEP > > > > at which point gdb catches a SIGSEV! > > > > If I continue from here I end up with the single "PAUSE !" line and > > nothing at all happens from here on. > > > > I managed to fix it by building all evas-* packages with base gcc! > I rebuilt all EFL and E17 with clang and I get black screen issue, but E17 start to work after I rebuilt only evas-core with gcc. Can anyone confirm that, building evas-core with gcc fixes this issue. ___ 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: How to launch services that do not fork to background using the rc infrastructure?
On 01/22/2013 04:19 PM, Javier Martín Rueda wrote:
The typical and simple rc.d script to launch a service has, esentially,
the following:
. /etc/rc.subr
name=SERVICE
rcvar=SERVICE_enable
command="/usr/local/sbin/PROGRAM"
pidfile=/var/run/${name}.pid
SERVICE_enable=${SERVICE_enable:-"NO"}
load_rc_config ${name}
run_rc_command "$1"
One of the ports (net/spread4) runs a PROGRAM that does not fork to
background as a daemon and which does not have any command-line option
to ask it to do so. Therefore, the rc.d script never finishes, with
various consequences (system boot stops, no pid file generated...)
I tried adding a "&" to SERVICE_flags to see if it made it run in the
background, but it didn't do the trick. I also quickly checked the
/etc/rc.subr code to see if there is any way of forcing a background
launch, but couldn't see anything. No luck searching the web or problem
reports either.
So, my question is whether there is a non-obvious way of forcing a
program to start in background using the rc infrastructure.
Try command="/usr/sbin/daemon -c -f -p $pidfile PROGRAM"
or some thing like this.
___
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"
Fetching from Github don't work
I can't fetch tarballs from github, they are fetched only from FreeBSD mirror. For example: => ninja-1.3.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://nodeload.github.com/martine/ninja/legacy.tar.gz/v1.3.4?dummy=/ninja-1.3.4.tar.gz fetch: https://nodeload.github.com/martine/ninja/legacy.tar.gz/v1.3.4?dummy=/ninja-1.3.4.tar.gz: Service Unavailable => Attempting to fetch http://nodeload.github.com/martine/ninja/legacy.tar.gz/v1.3.4?dummy=/ninja-1.3.4.tar.gz fetch: http://nodeload.github.com/martine/ninja/legacy.tar.gz/v1.3.4?dummy=/ninja-1.3.4.tar.gz: Connection refused => Attempting to fetch http://cloud.github.com/downloads/martine/ninja/ninja-1.3.4.tar.gz fetch: http://cloud.github.com/downloads/martine/ninja/ninja-1.3.4.tar.gz: Forbidden => Attempting to fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ninja-1.3.4.tar.gz ninja-1.3.4.tar.gz100% of 145 kB 29 kBps 00m05s ===> Fetching all distfiles required by ninja-1.3.4,1 for building Have someone a solution for this issue? ___ 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: enlightenment-0.17.4 hanging from xdm
On 09/05/13 18:16, Baptiste Daroussin wrote: > On Thu, Sep 05, 2013 at 05:49:51PM +0200, Grzegorz Blach wrote: >> On 09/05/13 17:42, Matthieu Volat wrote: >>> Hi e17 users, >>> >>> I can't get e17 to start a session from xdm, and it's quite unreliable from >>> startx too... There's no big error message in .xsession, it just seems to >>> hang after : >>> RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init >>> '/usr/local/share/enlightenment/data/themes/default.edj' '0' >>> 'Enlightenment' '0.17.4' >>> >>> There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with >>> clang set as port compiler... (tried to rebuild just enlightenment with gcc >>> with no avail). Does anybody has found this problem and maybe a solution? >>> >> >> Hi Matthieu, >> >> You need to rebuild graphics/evas-core using gcc, this should resolve >> your problem. > > That means I removed USE_GCC=any by mistake, this is weird, as I am able to > run > e17 on head using clang (meaning clang33)? > > did I miss something? > I don't tried clang33 yet, but I'm sure that building evas-core using clang32 at last on amd64 make e17 unusable. ___ 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: enlightenment-0.17.4 hanging from xdm
On 09/05/13 19:02, Matthieu Volat wrote: > On Thu, 05 Sep 2013 18:46:10 +0200 > Grzegorz Blach wrote: > >> On 09/05/13 18:39, Matthieu Volat wrote: >>> On Thu, 05 Sep 2013 17:49:51 +0200 >>> Grzegorz Blach wrote: >>> >>>> On 09/05/13 17:42, Matthieu Volat wrote: >>>>> Hi e17 users, >>>>> >>>>> I can't get e17 to start a session from xdm, and it's quite unreliable >>>>> from startx too... There's no big error message in .xsession, it just >>>>> seems to hang after : >>>>> RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init >>>>> '/usr/local/share/enlightenment/data/themes/default.edj' '0' >>>>> 'Enlightenment' '0.17.4' >>>>> >>>>> There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with >>>>> clang set as port compiler... (tried to rebuild just enlightenment with >>>>> gcc with no avail). Does anybody has found this problem and maybe a >>>>> solution? >>>>> >>>> >>>> Hi Matthieu, >>>> >>>> You need to rebuild graphics/evas-core using gcc, this should resolve >>>> your problem. >>>> >>> >>> Thanks for the advice, it did not work neither... That's strange since evas >>> were not even updated... I will try to rebuild every e17 port with base gcc >>> to see... maybe try with the vesa driver, too... >>> >> >> Similar issue was reported on https://phab.enlightenment.org/T308 Please >> rebuild e17 with this patch: >> http://git.enlightenment.org/core/enlightenment.git/commit/?h=enlightenment-0.17&id=b17a9b9cc9438b6dfac4402ac4107f08e23a4373 >> and write me if it solves your problem > > Yes, applying the patch *and* building evas-core with base gcc did the trick! > > Thanks a lot for taking time to look into that! > Ok, I'll commit this patch to x11-wm/enlightenment port. ___ 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: enlightenment-0.17.4 hanging from xdm
On 09/05/13 17:42, Matthieu Volat wrote: > Hi e17 users, > > I can't get e17 to start a session from xdm, and it's quite unreliable from > startx too... There's no big error message in .xsession, it just seems to > hang after : > RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init > '/usr/local/share/enlightenment/data/themes/default.edj' '0' > 'Enlightenment' '0.17.4' > > There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with clang > set as port compiler... (tried to rebuild just enlightenment with gcc with no > avail). Does anybody has found this problem and maybe a solution? > Hi Matthieu, You need to rebuild graphics/evas-core using gcc, this should resolve your problem. ___ 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: enlightenment-0.17.4 hanging from xdm
On 09/05/13 18:39, Matthieu Volat wrote: > On Thu, 05 Sep 2013 17:49:51 +0200 > Grzegorz Blach wrote: > >> On 09/05/13 17:42, Matthieu Volat wrote: >>> Hi e17 users, >>> >>> I can't get e17 to start a session from xdm, and it's quite unreliable from >>> startx too... There's no big error message in .xsession, it just seems to >>> hang after : >>> RUN INIT: /usr/local/lib/enlightenment/utils/enlightenment_init >>> '/usr/local/share/enlightenment/data/themes/default.edj' '0' >>> 'Enlightenment' '0.17.4' >>> >>> There's no problem if I rollback to 0.17.3... I'm in 9.2-RC3 amd64 with >>> clang set as port compiler... (tried to rebuild just enlightenment with gcc >>> with no avail). Does anybody has found this problem and maybe a solution? >>> >> >> Hi Matthieu, >> >> You need to rebuild graphics/evas-core using gcc, this should resolve >> your problem. >> > > Thanks for the advice, it did not work neither... That's strange since evas > were not even updated... I will try to rebuild every e17 port with base gcc > to see... maybe try with the vesa driver, too... > Similar issue was reported on https://phab.enlightenment.org/T308 Please rebuild e17 with this patch: http://git.enlightenment.org/core/enlightenment.git/commit/?h=enlightenment-0.17&id=b17a9b9cc9438b6dfac4402ac4107f08e23a4373 and write me if it solves your problem ___ 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: audio/abcde fails to upgrade due to port conflicts
audio/abcde isn't compatible with eyed3-0.7, this means you must deinstall eyed3-0.7 and install eyed3-0.6 to use audio/abcde. On 06/22/14 11:16, Torfinn Ingolfsen wrote: > Hello, > The audio/abcde port fails to upgrade, due to a conflict of a port it > depends on: > root@kg-core1# portupgrade -R abcde > [Gathering depends for audio/abcde > .. > done] > [Exclude up-to-date packages ... done] > ---> Upgrading 'abcde-2.5.4_2' to 'abcde-2.5.4_3' (audio/abcde) > ---> Building '/usr/ports/audio/abcde' > ===> Cleaning for abcde-2.5.4_3 > /!\ WARNING /!\ > pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to > pkgng > http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ > If you do not want to see this message again set > NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf > > ===> License GPLv2 accepted by the user > ===> Found saved configuration for abcde-2.5.4_1 > ===> Fetching all distfiles required by abcde-2.5.4_3 for building > ===> Extracting for abcde-2.5.4_3 > => SHA256 Checksum OK for abcde-2.5.4.tar.gz. > ===> Patching for abcde-2.5.4_3 > ===> Applying FreeBSD patches for abcde-2.5.4_3 > /usr/bin/sed -i.bak -e 's#/etc/#/usr/local/etc/#g' > /usr/ports/audio/abcde/work/abcde-2.5.4/abcde.1 > /usr/bin/sed -i.bak -e 's#/etc/#/usr/local/etc/#g' > /usr/ports/audio/abcde/work/abcde-2.5.4/abcde > ===> Configuring for abcde-2.5.4_3 > ===> Staging for abcde-2.5.4_3 > ===> abcde-2.5.4_3 depends on executable: cd-discid - found > ===> abcde-2.5.4_3 depends on executable: cdparanoia - found > ===> abcde-2.5.4_3 depends on package: eyed3-06>0 - not found > ===>Verifying install for eyed3-06>0 in /usr/ports/audio/py-eyed3-06 > /!\ WARNING /!\ > pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to > pkgng > http://blogs.freebsdish.org/portmgr/2014/02/03/time-to-bid-farewell-to-the-old-pkg_-tools/ > If you do not want to see this message again set > NO_WARNING_PKG_INSTALL_EOL=yes in your make.conf > > > ===> py27-eyed3-06-0.6.18_1 conflicts with installed package(s): > py27-eyed3-0.7.4 > > They install files into the same place. > You may want to stop build with Ctrl + C. > ===> License GPLv2 accepted by the user > ===> Fetching all distfiles required by py27-eyed3-06-0.6.18_1 for building > > ===> py27-eyed3-06-0.6.18_1 conflicts with installed package(s): > py27-eyed3-0.7.4 > > They will not build together. > Please remove them first with pkg_delete(1). > *** Error code 1 > > Stop in /usr/ports/audio/py-eyed3-06. > *** Error code 1 > > Stop in /usr/ports/audio/abcde. > *** Error code 1 > > Stop in /usr/ports/audio/abcde. > ** Command failed [exit code 1]: /usr/bin/script -qa > /tmp/portupgrade20140622-61461-1vu980o env UPGRADE_TOOL=portupgrade > UPGRADE_PORT=abcde-2.5.4_2 UPGRADE_PORT_VER=2.5.4_2 make > ** Fix the problem and try again. > ** Listing the failed packages (-:ignored / *:skipped / !:failed) > ! audio/abcde (abcde-2.5.4_2)(unknown build error) > > Can abcde be fixed to use the newer py-eyed3? (the commit message for > the newer py-eyed3 says it is incompatible). > > ___ 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: why :: in ports makefile ?
On 03/23/2012 03:28 PM, Michael Scheidell wrote:
I have never seen this before, and I wanted to know what it does.
diff -ruN /tmp/p5-Mail-SpamAssassin.org/Makefile
/tmp/p5-Mail-SpamAssassin/Makefile
--- /tmp/p5-Mail-SpamAssassin.org/Makefile 2012-02-08 00:17:28.0
+0900
+++ /tmp/p5-Mail-SpamAssassin/Makefile 2012-03-06 08:55:28.445163638 +0900
@@ -219,7 +219,7 @@
.endif
@${INSTALL_DATA} ${WRKSRC}/spamc/libspamc.h ${PREFIX}/include
-post-install:
+post-install::
.if defined (WITH_SPAMC)
@${STRIP_CMD} ${PREFIX}/bin/spamc
.endif
(this patch was sent to me by the maintainer of ja-p5-Mail-SpamAssassin.
I suggested that he change his port to a slave port so that it would be
easier to follow, and he has done a good job.
I just wanted to know what the differences are in the port Makefile
between a ':' and a '::'
Does this have to do with slave port(ish) things? does this force it to
execute? what is it?
Pardon my ignorance, I have just never seen this before in any port I
have maintained, or worked on.
(reference this PR for context)
From `man make`
: A target is considered out-of-date if its modification time
is less than those of any of its sources. Sources for a
target accumulate over dependency lines when this operator
is used. The target is removed if make is interrupted.
::If no sources are specified, the target is always
re-created. Otherwise, a target is considered out-of-date
if any of its sources has been modified more recently than
the target. Sources for a target do not accumulate over
dependency lines when this operator is used.
The target will not be removed if make is interrupted.
___
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: tracking number of users for a port
On Mon, 2012-10-29 at 13:05 -0700, Kristopher Clark wrote: > Once a port is in the tree is there a way to track how many people are using > that port? > At http://fbsdmon.org/ you can check how many people are using any port, but only for users which are sending list of installed ports. Currently only 32 users are sending statistics. Of course you can join to submitters: http://fbsdmon.org/about ___ 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"
New virtual category proposal: enlightenment
Hi, I'm working on enlightenment 0.17 ports at: http://dev.roorback.net/enlight-ports and I wanna have this ports in one single category called 'enlightenment', just like afterstep, gnome, kde, windowmaker. Now I have abount 90 ports in tree, and there are next 5 ports from enlightenment 0.16 in FreeBSD ports tree. What do you thing about new category? Adding new category have some impact on others ports? ___ 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: New virtual category proposal: enlightenment
On Fri, 10 Sep 2010 14:10:42 +0300, Ion-Mihai Tetcu wrote: > On Fri, 10 Sep 2010 09:14:23 +0200 > Grzegorz Blach wrote: > >> Hi, >> >> I'm working on enlightenment 0.17 ports at: >> http://dev.roorback.net/enlight-ports >> and I wanna have this ports in one single category called >> 'enlightenment', >> just like afterstep, gnome, kde, windowmaker. >> >> Now I have abount 90 ports in tree, and there are next 5 ports from >> enlightenment 0.16 in FreeBSD ports tree. >> >> What do you thing about new category? > > Submit a patch for adding this as a virtual category. > I expect it to be OK'ed. For e16 ports I sent patches in http://www.freebsd.org/cgi/query-pr.cgi?pr=150492 and for e17 ports I added patches in development repo: http://dev.roorback.net/enlight-ports/changeset?old_path=%2Ftrunk&old=30&new_path=%2Ftrunk&new=30 ___ 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: FreeBSD Port: transmission-2.22
On 03/06/2011 12:55, David Demelier wrote: > On 06/03/2011 07:21, Ruslan Mahmatkhanov wrote: >> 06.03.2011 05:18, Alex V. Petrov пишет: >>> FreeBSD alex.super 8.2-STABLE FreeBSD 8.2-STABLE #116: Thu Mar 3 >>> 21:55:50 >>> KRAT 2011 alex@alex.super:/usr/obj/usr/src/sys/ALEX amd64 >>> >>> transmission-2.13< needs updating (port has 2.22) >>> transmission-cli-2.13< needs updating (port has 2.22) >>> transmission-daemon-2.13< needs updating (port has 2.22) >>> transmission-gtk2-2.13< needs updating (port has 2.22) >>> >>> >>> #portmaster -aD >>> >>> [skip] >>> >>> ../libtransmission/libtransmission.a(handshake.o) >>> (.text+0x16d9):/usr/ports/net-p2p/transmission- >>> cli/work/transmission-2.22/libtransmission/handshake.c:610: undefined >>> reference to `evbuffer_get_length' >>> ../libtransmission/libtransmission.a(handshake.o) >>> (.text+0x1714):/usr/ports/net-p2p/transmission- >>> cli/work/transmission-2.22/libtransmission/handshake.c:759: more >>> undefined >>> references to `evbuffer_get_length' follow >>> gmake[1]: *** [transmission-create] Ошибка 1 >>> gmake[1]: Leaving directory `/usr/ports/net-p2p/transmission- >>> cli/work/transmission-2.22/utils' >>> gmake: *** [all-recursive] Ошибка 1 >>> *** Error code 1 >>> >>> Stop in /usr/ports/net-p2p/transmission-cli. >>> >>> ===>>> make failed for net-p2p/transmission-cli >>> ===>>> Aborting update >>> >>> ===>>> Update for net-p2p/transmission-cli failed >>> ===>>> Aborting update >>> >>> >>> - >>> Alex V. Petrov >> >> You should deinstall libevent first. >> > > Why this is not in ports/UPDATING then? :-( > Because, probably it's not a good solution. I'm useing memcached witch need libevent to work. So removing libevent, will broke memcached :-( ___ 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 needs fresh Blood!
I read last post Martin Wilke's blog called "FreeBSD needs fresh Blood!" First of all, I think it's difficult to testing ports. I'm using testing release of VirtualBox, but for build this port I must download patches, apply its on my own tree and merge its with official ports using portshaker. It's possible to build testing ports outside tree, but I must build every port separately, since `Make` don't known how to track dependencies. Another possibility is replace ports in disk, but after upgrade tree eg. with portsnap I lose my changes, and portmaster want to rebuild these ports to stable release. If testing will be simpler, I think more people will do this. Maybe we must create two trees, eg: ports-stable and ports-current First we publish changes to current tree and after week or two without pr, we publish updates to stable tree too. Merging trees is another huge problem. Portshaker do this very well, but after merge I must rebuild INDEX file, which takes long time. This should be faster or even shouldn't be required (hard to do). ___ 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: FreeBSD needs fresh Blood!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/06/2011 18:35, b. f. wrote: >> I read last post Martin Wilke's blog called "FreeBSD needs fresh Blood!" >> >> First of all, I think it's difficult to testing ports. >> >> I'm using testing release of VirtualBox, >> but for build this port I must download patches, >> apply its on my own tree and merge its with official ports >> using portshaker. >> >> It's possible to build testing ports outside tree, >> but I must build every port separately, since `Make` don't known how to >> track dependencies. > > There is always going to be some added work involved in testing. Have > you considered using multiple trees, if you have sufficient disk > space? Or using a version control system? > Multiple trees don't help me a lot, portmaster became fools. There is no significant difference if I use version control system or portshaker to merge trees. >> >> Another possibility is replace ports in disk, but after upgrade tree eg. >> with portsnap I lose my changes, and portmaster want to rebuild these >> ports to stable release. >> > > It sounds like you are using the wrong tools. Although portsnap (which > is not best suited for this purpose) has path arguments and an -l flag > that can be used to add or preserve local changes, and both portmaster > and portupgrade have options to ignore certain ports or to substitute > alternative dependencies, you shouldn't have to make use of them. > Instead, you should probably be using CVS (or another version control > system that can import CVS), which will make merging and reverting > changes easier. And naturally you shouldn't run updating tools until > you've modified your tree. But I won't resign from use updating tools, even when I use merged tree. Because I use merged tree all the time. >> If testing will be simpler, I think more people will do this. >> Maybe we must create two trees, eg: ports-stable and ports-current >> First we publish changes to current tree and after week or two without >> pr, we publish updates to stable tree too. > > This has often been proposed, but since it would require more work > from the already-overstretched committers, and the benefits are > questionable, I don't think it is likely to happen soon. > >> >> Merging trees is another huge problem. >> Portshaker do this very well, but after merge I must rebuild INDEX file, >> which takes long time. This should be faster or even shouldn't be >> required (hard to do). > > Do you really need to rebuild the INDEX? You can often avoid using > it. If you do need to modify it, you can use some improved method, > like > > http://www.lpthe.jussieu.fr/~talon/build_index.py > > or modify it incrementally, with something like > ports-mgmt/p5-FreeBSD-Portindex, > > http://www.lpthe.jussieu.fr/~talon/portindex-18_1.tgz > > , or your own script. > > b. I known that are many different ways to merge ports from different sources, but none of them are simple and fast to use it for first time. Look at last calls for testers: http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/065884.html http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/065983.html There are only links to tarballs, without address to repository. I must download tarballs, commit ports to my tree and merge it with official ports. Another CFT: http://lists.freebsd.org/pipermail/freebsd-ports/2011-February/066007.html There is address for repository, but I still need merging trees and rebuild index for portmaster. I thing if testing ports will be simpler, more people can do this, and want to do this. I proposed stable and current trees, but maybe one official merge tool, which is easy to setup will be better, or something completely different. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNc9RkAAoJEFCzIDMxqoILknMH/2ewFVhIWz02xCXFzp7vNtPO wkcJmzIUjF9LxKQ1mTdsZbBboIWzchihLZoCa8GDhZYmFgGnzhl7UDeDzjJ4/+fL DKcAkmixOR2TbFKoZf8C52wIv4bE9WuuuUlibVyctK4/3rXB3NOpq4xXi1dT5G3q ZzdpWdBi3p6Ec9bnRuWl/aqMhIbHq9NweX50pB4TF5Wldv3fWAGGL/kLOHnAEzCr 8vVRRz6QfnKbrxY830fs5wodgRJGCEWzfat33Y0jV5UWKQwW01f2CxRm9tzbuIJJ X/Nr0QLdi0L7OXEpqaak4OCIUl1M3UCKM2lYovlRt5lXb/0PrAdeZzgzHWMNH9s= =Kl87 -END PGP SIGNATURE- ___ 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: FreeBSD needs fresh Blood!
On Sun, Mar 6, 2011 at 23:25, Doug Barton wrote: > On 03/06/2011 10:37, Grzegorz Blach wrote: >> >> On 03/06/2011 18:35, b. f. wrote: >>>> >>>> I read last post Martin Wilke's blog called "FreeBSD needs fresh Blood!" >>>> >>>> First of all, I think it's difficult to testing ports > > No argument there, it can be hard work. > >>>> I'm using testing release of VirtualBox, >>>> but for build this port I must download patches, >>>> apply its on my own tree and merge its with official ports >>>> using portshaker. > > You could also maintain completely separate trees, or subtrees with CVS. > >>>> It's possible to build testing ports outside tree, >>>> but I must build every port separately, since `Make` don't known how to >>>> track dependencies. > > Setting PORTSDIR for your builds may help. Read ports/Mk/bsd.port.mk for > more information about that. > >>> There is always going to be some added work involved in testing. Have >>> you considered using multiple trees, if you have sufficient disk >>> space? Or using a version control system? >> >> >> Multiple trees don't help me a lot, portmaster became fools. > > Not sure what you mean by that, but portmaster respects PORTSDIR as well. > >> There is address for repository, but I still need merging trees >> and rebuild index for portmaster. > > portmaster does not require the INDEX unless you tell it to. If you have a > ports tree to operate against portmaster doesn't need the INDEX at all. > > > hope this helps, > > Doug > My mistake, sorry. I'll rebuild INDEX after every merges, but not for portmaster, but for pver. > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: FreeBSD needs fresh Blood!
On Tue, Mar 8, 2011 at 18:13, Warren Block wrote: > On Tue, 8 Mar 2011, Warren Block wrote: >> >> On Tue, 8 Mar 2011, Michel Talon wrote: > >>> My experience is that all FreeBSD ports tools are incredibly slow, be it >>> portupgrade, portmaster, even the basic tools like pkg_version. Maybe it >>> would help to recognize that such observations are perhaps not unrelated to >>> the original poster comments. >> >> I don't understand what you mean by that last sentence. OP was talking >> about the difficulty of using or merging alternate ports trees, AFAIR. Sorry >> about the topic drift; we can start a new thread if appropriate. > > And of course now I see it: the OP also mentioned the delay in rebuilding > INDEX after merging ports trees. > > That was a problem back before the ports cluster built INDEX files for > download, and there were Perl and other implementations that could rebuild a > local index faster than the stock ports implementation. Can't recall > exactly what they were. If still applicable, integrating those faster > methods into the ports system would be a solid improvement. > ___ > 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" > Building INDEX is not essential in this thread, merging trees is closer to subject, but primary I want, that testing development version of ports will be simpler. Please look at: 'Firefox 4 - Beta' threat: http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066353.html some people don't known where they can find freebsd-gecko development repo. Or at 'xorg-server 1.9.3 and 1.10.0' threat: http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066421.html Martin wrote: > I'll cleanup all the mess and commit all stuff to the xorg-dev repo. Maybe > someone have intressing to test it. but without any info where I can find xorg-dev repo, How I can test new xorg, since I don't known where this repo is? ___ 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: sysutils/tmux fails to compile
On 2011-05-26 09:25, David Demelier wrote: Hello, Since the last update tmux fails to compile : ===> Building for tmux-1.4_5 cc -iquote. -O2 -pipe -march=core2 -DBUILD="\"1.4\"" -c attributes.c -o attributes.o In file included from attributes.c:23: tmux.h:30:19: error: event.h: No such file or directory In file included from attributes.c:23: tmux.h:830: error: field 'name_timer' has incomplete type tmux.h:1032: error: field 'key_timer' has incomplete type tmux.h:1093: error: field 'event' has incomplete type tmux.h:1117: error: field 'repeat_timer' has incomplete type tmux.h:1139: error: field 'identify_timer' has incomplete type tmux.h:1142: error: field 'message_timer' has incomplete type *** Error code 1 Stop in /usr/ports/sysutils/tmux/work/tmux-1.4. It fails even if LIBEVENT2 is not selected. markand@Melon /usr/ports/sysutils/tmux $ make showconfig ===> The following configuration options are available for tmux-1.4_5: KQUEUE=on "Build without define HAVE_BROKEN_KQUEUE " LIBEVENT2=on "Use libevent version 2" LIBEVENT_STATIC=off "Build with static libevent" BACKSPACE=off "Build with tty/keys patch" ===> Use 'make config' to modify these settings Cheers, I fixed this yesterday on my machine. Generally, CFLAGS from tmux/Makefile is replaced with CLFAGS from /etc/make.conf. For defined include path in tmux/Makefile "CFLAGS+= -I..." should be replaced with "CPPFLAGS+= -I..." ___ 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: sysutils/tmux fails to compile
On 2011-05-26 10:40, wen heping wrote:
2011/5/26 Grzegorz Blach:
On 2011-05-26 09:25, David Demelier wrote:
Hello,
Since the last update tmux fails to compile :
===> Building for tmux-1.4_5
cc -iquote. -O2 -pipe -march=core2 -DBUILD="\"1.4\"" -c attributes.c -o
attributes.o
In file included from attributes.c:23:
tmux.h:30:19: error: event.h: No such file or directory
In file included from attributes.c:23:
tmux.h:830: error: field 'name_timer' has incomplete type
tmux.h:1032: error: field 'key_timer' has incomplete type
tmux.h:1093: error: field 'event' has incomplete type
tmux.h:1117: error: field 'repeat_timer' has incomplete type
tmux.h:1139: error: field 'identify_timer' has incomplete type
tmux.h:1142: error: field 'message_timer' has incomplete type
*** Error code 1
Stop in /usr/ports/sysutils/tmux/work/tmux-1.4.
It fails even if LIBEVENT2 is not selected.
markand@Melon /usr/ports/sysutils/tmux $ make showconfig
===> The following configuration options are available for tmux-1.4_5:
KQUEUE=on "Build without define HAVE_BROKEN_KQUEUE "
LIBEVENT2=on "Use libevent version 2"
LIBEVENT_STATIC=off "Build with static libevent"
BACKSPACE=off "Build with tty/keys patch"
===> Use 'make config' to modify these settings
Cheers,
I fixed this yesterday on my machine.
Generally, CFLAGS from tmux/Makefile is replaced with CLFAGS from
/etc/make.conf. For defined include path in tmux/Makefile
"CFLAGS+= -I..." should be replaced with "CPPFLAGS+= -I..."
Yes, this way fix the build when define CFLAGS in /etc/make.conf.
But it will fail when define CPPFLAGS in /etc/make.conf.
wen
Attached patch fix (I hope) build when CFLAGS and/or CPPFLAGS is defined
in /etc/make.conf.
--- Makefile.orig 2011-05-26 09:57:23.0 +
+++ Makefile2011-05-26 09:56:55.0 +
@@ -35,14 +35,14 @@
.include
.if defined(WITH_LIBEVENT2)
-CFLAGS+= -I${LOCALBASE}/include/event2/compat -I${LOCALBASE}/include
+EXTRA_CPPFLAGS+= -I${LOCALBASE}/include/event2/compat -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib/event2
.else
-CFLAGS+= -I${LOCALBASE}/include
+EXTRA_CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
.endif
-MAKE_ENV+= LDFLAGS="${LDFLAGS}"
+MAKE_ENV+= EXTRA_CPPFLAGS="${EXTRA_CPPFLAGS}" LDFLAGS="${LDFLAGS}"
.if defined(WITH_LIBEVENT_STATIC)
. if defined(WITH_LIBEVENT2)
@@ -81,6 +81,7 @@
${WRKSRC}/tmux.1 ${WRKSRC}/tmux.h
@${REINPLACE_CMD} -e 's|-I/usr/local/include||g' \
-e 's|/usr/local|${LOCALBASE}|g' \
+ -e 's|$${CPPFLAGS}$$|${CPPFLAGS} ${EXTRA_CPPFLAGS}|g' \
-e 's|LDFLAGS+=|#LDFLAGS+=|g' \
${WRKSRC}/Makefile
@${REINPLACE_CMD} -e 's|-levent|${_LEVENT_LIB}|g' \
___
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"
aalib issue
When I call aclocal command, I get warning about syntax in aalib.m4 file. In attachment I'am sending patch which is fixing this issue. patch-aalib.m4 Description: Binary data ___ 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: sysutils/tmux fails to compile
On 2011-06-16 00:24, Andrey Fesenko wrote: I fixed this yesterday on my machine. Generally, CFLAGS from tmux/Makefile is replaced with CLFAGS from /etc/make.conf. For defined include path in tmux/Makefile "CFLAGS+= -I..." should be replaced with "CPPFLAGS+= -I..." Thank you this method worked may formalize pr Reported as ports/157918. ___ 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"
CFT: security/openssh-portable 5.8p2
After became a new maintainer of security/openssh-portable, I updated it to 5.8p2 version. My paches fixes several problems repoted to this port: - ports/144597: Kerberos knob work again - ports/150493: Port updated to (almost) recent version - ports/160389: Port build fine on FreeBSD 9.x - ports/156926: Suffix isn't changed with knobs Next problem can't be fixed: - ports/155456: LPK patch wasn't updated upstream Current snapshot can be downloaded from: https://github.com/downloads/Roorback/mgk_ports/openssh-portable-5.8p2-t1.shar Anyone who have time and desire, please check if everything is working in this port and report bugs to me. ___ 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: security/openssh-portable 5.8p2
Mainly features introduced by external patches should be tested. They work for me, but maybe someone will find some regressions. ___ 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: security/openssh-portable 5.8p2
New snapshot is ready to testing: https://github.com/downloads/Roorback/mgk_ports/openssh-portable-5.8p2-t2.shar In this version WITH_LPK knob is fixed. Thanks to Gleb Smirnoff. ___ 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: TeXLive
TeXLive ports are available from external source: https://code.google.com/p/freebsd-texlive/ ___ 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: best way to bind webserver to port 80 without running as root
On 01/04/2012 11:10 AM, Dino Vliet wrote: Hi all, suddenly I'm facing this quest on freebsd 8. I need to bind my little webserver running aolserver to port 80. In the past I was always using port 8080 and had my router configured to forward requests on port 80 to the server on port 8080. However, I am planning to host my little site on a virtual server with a hosting company and figuredI can't use the workaround I always used. So my question is, how to bind aolserver to port 80 without running as root as I understood ports below 1024 can only be used by root. I found a sysctl net.inet.ip.portrange.reservedhigh which enables me to set it to 0. However, I don't know what the security ramifications are of using that. Are there any other options I could consider? Thanks Dino ___ 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" http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-portacl.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/openssh-portable
On 03/14/2012 09:01 PM, Cy Schubert wrote: In message<4f60ef46.2040...@acsalaska.net>, Mel Flynn writes: Hello Cy, On 3/14/2012 08:57, Cy Schubert wrote: [snip] What I propose to do is remove the GSSAPI patch from security/openssh-portable and for those who need the GSSAPI server key exchange, create a new port (through a repocopy of course) which includes the illinois.edu GSI patch with reworked FreeBSD patches resolving patch conflicts, calling it security/openssh-portable-gsi. Does this make any sense to anyone? Or, instead of the above, just include the GSI patch by default in a one-size-fits-all openssh-portable port? (Meaning that the GSI patch is applied regardless.) Does this make more sense to people? Personally, I use HPN and LPK. If KRB5 becomes a requirement for HPN, I don't find that an issue, but others may. Given that the current LPK patch is unmaintained by our upstream, I think it should be removed and we either move toward a one size fits all port or have a second port with the one-size-fits-all GSI patch. Basically the current hodgepodge of patches in this port are unmaintainable, which is why this port is usually slow to be updated. We can address the KRB5 requirement with an ifdefs. I'm leaning toward gutting a one-size-fits-all approach with patches that are maintainable. Secondly, if there are requirements for an insecure backlevel port, we could repocopy it. I'm not entirely enamoured with that idea, caveat emptor of course. I'm also keeping a local fix you might want to properly integrate into the LPK patch: it fixes a bug that TLS cannot be turned off if LPKLdapConf is used. If I go ahead and have the port repocopied and move forward with this, I'll see if I can include this patch. I'll give it another day before making the repocopy request. The current port should be repocopied to openssh-portable58 and the new port assume the openssh-portable name. I've yet to hear from the maintainer of this port for his thoughts on this. I (maintainer of security/openssh-portable) need one or two days to review GSI patch and other patches which are available for openssh-5.9. But repocopy security/openssh-portable to security/openssh-portable58 and upgrade security/openssh-portable to 5.9 sound reasonable. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: security/openssh-portable
I (maintainer of security/openssh-portable) need one or two days to review GSI patch and other patches which are available for openssh-5.9. But repocopy security/openssh-portable to security/openssh-portable58 and upgrade security/openssh-portable to 5.9 sound reasonable for me. Beginning from FreeBSD 9.0 openssh in base system has applied HPN patches, so I think it isn't a good idea to maintain port which is very close to system's openssh. In this case simply use openssh from base system. ___ 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"
