www/linux-f10-flashplugin10 port has been deleted...........
I think I missed the information if it's been discussed on the list. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) /Leslie ___ 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: www/linux-f10-flashplugin10 port has been deleted...........
On Mon, 27 Aug 2012 09:44:09 +0200 Leslie Jensen les...@eskk.nu wrote: I think I missed the information if it's been discussed on the list. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL But it will work, if you have it installed How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) you can switch to flashplugin11. portmaster -o www/linux-f10-flashplugin11 www/linux-f10-flashplugin10 ? /Leslie -- wbr, tiger ___ 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: www/linux-f10-flashplugin10 port has been deleted...........
2012/8/27 Leslie Jensen les...@eskk.nu: I think I missed the information if it's been discussed on the list. It wasn't discussed on the list, just on #bsdports. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) Hm, I could have made the MOVED entry more advanced that it automatically upgrades to www/linux-f10-flashplugin11 René ___ 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: www/linux-f10-flashplugin10 port has been deleted...........
2012-08-27 09:55, Sergey V. Dyatko skrev: On Mon, 27 Aug 2012 09:44:09 +0200 Leslie Jensen les...@eskk.nu wrote: I think I missed the information if it's been discussed on the list. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL But it will work, if you have it installed How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) you can switch to flashplugin11. portmaster -o www/linux-f10-flashplugin11 www/linux-f10-flashplugin10 ? /Leslie Thank you :-) I'll do the upgrade soon. /Leslie ___ 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: www/linux-f10-flashplugin10 port has been deleted...........
2012-08-27 09:55, René Ladan skrev: 2012/8/27 Leslie Jensen les...@eskk.nu: I think I missed the information if it's been discussed on the list. It wasn't discussed on the list, just on #bsdports. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) Hm, I could have made the MOVED entry more advanced that it automatically upgrades to www/linux-f10-flashplugin11 René ___ 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 May I suggest that you put Sergey's advise to me in UPDATING. I always read the UPDATING file but never the MOVED file. /Leslie ___ 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: www/linux-f10-flashplugin10 port has been deleted...........
2012/8/27 Leslie Jensen les...@eskk.nu: 2012-08-27 09:55, René Ladan skrev: 2012/8/27 Leslie Jensen les...@eskk.nu: I think I missed the information if it's been discussed on the list. It wasn't discussed on the list, just on #bsdports. The www/linux-f10-flashplugin10 port has been deleted: Has expired: has vulnerabilities and is EOL How should I do. Delete it from my machine? How about flash support? Not very important but nice to have ;-) Hm, I could have made the MOVED entry more advanced that it automatically upgrades to www/linux-f10-flashplugin11 May I suggest that you put Sergey's advise to me in UPDATING. I always read the UPDATING file but never the MOVED file. No need to, MOVED is automatically read by portupgrade/portmaster. René ___ 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: stellarium 0.11.4
On Sun, Aug 26, 2012 at 02:52:01AM +0700, Alexander Wolf wrote: Today has been released Stellarium 0.11.4 with improvements for *BSD systems. http://astro.uni-altai.ru/~aw/patches/FreeBSD-stellarium.patch Thanks for the patch (albeit it's incomplete: missing distinfo and pkg-plist changes, and port revision should be reset = removed). I've updated the port to v0.11.4(a), enjoy. ./danfe ___ 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
o ports/171112[patch] games/simutrans: version 111.3.1
o ports/17[MAINTAINER] japanese/libskk: update to 1.0.0
o ports/171109[MAINTAINER] devel/gdb: Fix several issues in the last
o ports/171106New Port: net/jdownloader - Download manager (java)
o ports/171100[MAINTAINER] japanese/jd: update to 2.8.5
o ports/171097[NEW PORT] games/iceicepenguin: Remake of an old SEGA
f ports/171086[patch] devel/gdb: various fixes
o ports/171080DOS vulnerability in net-p2p/bitcoin and bitcoind - CV
o ports/171079graphics/rawtherapee hangs x11
o ports/171020science/isis3: New port: USGS ISIS3 planetary mapping
o ports/171019science/isis3: New port: USGS ISIS3 planetary mapping
o ports/171017astro/cspice: New scientific port: NASA/NAIF SPICE C r
o ports/171015[patch] Tidying sysutils/bsdstats
o ports/170995[PATCH] games/ttt: [SUMMARIZE CHANGES], take maintaine
o ports/170993New port: mail/roundcube-automatic_addressbook for rou
o ports/170989typographical and grammatical adjustments to bsd.optio
f ports/170986audio/mpdas: small fix in rc-script
o ports/170946[patch] mark certain ports broken on ARM
o ports/170941[NEW PORT] games/brickout: A ball-and-paddle game wher
o ports/170939[NEW PORT] games/popstar: Simple puzzle game involving
o ports/170918[NEW PORT] games/entombed: A one- or two-player maze g
f ports/170901x11-fonts/tolkien-ttf: fix MASTER_SITES
o ports/170898[PATCH] games/bugsquish: Makefile changed, take mainta
o ports/170887[NEW PORT] games/fightorperish: A dungeon-crawling gam
o ports/170857New port mail/roundcube-automatic_addressbook for roun
o ports/170837[NEW PORT] games/vectoroids: Vector-based rock-shootin
o ports/170836[NEW PORT] games/agendaroids: Vector-based rock-shooti
o ports/170835net/ifstated fails to build because of incorrect lib d
o ports/170823multimedia/podcastdl new port
o ports/170819New port: net-mgmt/UniFi UniFi Wireless Controller
o ports/170779New port: devel/edbg An ollydbg-like debugger based on
o ports/170777[PATCH] Not LIBS but LDFLAGS in Makefile of lang/ruby
f ports/170773sysutils/bacula-server overlaps with sysutils/backula-
o ports/170735Update multimedia/mplayer and mencoder to a recent sna
o ports/170730multimedia/mplayer-skins plist generation under pkgng
f ports/170723[patch] x11-wm/dwm: add optional Xft support
o ports/170704[NEW PORT] games/patapizza-tetris: An unofficial clone
o ports/170695sysutils/fusefs-ntfs - instant reboot when mv from UFS
o ports/170682[NEW PORT] graphics/puckman: An unofficial clone of th
o ports/170666New port: graphics/nomacs simple image viewer
o ports/170662[NEW PORT] devel/pymunk: A easy-to-use pythonic 2d phy
o ports/170661[NEW PORT] graphics/py27-pyglet-devel: Cross-platform
f ports/170641x11-toolkits/open-motif: need mkcatdefs utility
f ports/170626x11-toolkits/open-motif: X11/extensions/XPrint.h is no
o ports/170616gpk-update-viewer
f ports/170610[update]: textproc/ctpp2 up to new version
f ports/170542sysutils/bsdadminscripts does not build correctly in m
f ports/170538x11-wm/enlightenment build breaks
f ports/170537devel/libftdi seems broken on i386 and amd64
f ports/170524devel/ding-libs fails to build in tinderbox
f ports/170502security/sssd failed to connect Ldap server without SA
o ports/170492[REPOCOPY] devel/gwenhywfar - devel/gwenhywfar-{fox16
f ports/170473[patch] audio/alsa-plugins: disable ARIFF_OSS by defau
o ports/170467Unintended effect of /usr/local/include/base64.h in bu
f ports/170457[patch] audio/alsa-lib: implicit declaration of calloc
o ports/170448[NEW PORT] devel/allegro5: Allegro 5 is a game program
f ports/170381x11/slim window manager gives dbus errors starting xfc
f ports/170366lang/libobjc2: update to 1.6.1
f ports/170365Patch updating finance/trytond from version 1.4.7 to 2
f ports/170357net-mgmt/tcptrack Segmentation fault (core dumped)
f ports/170344[UPDATE]
Current problem reports assigned to po...@freebsd.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). 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 p ports/170569 ports sysutils/sec does not start automatically at boot time 1 problem total. ___ 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: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
2012/8/26 Baptiste Daroussin b...@freebsd.org: I received more feedback about keep pkg and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? So, just a me too for renaming pkg, for consistency. I don't mind the new name... -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: Can we please just remove the old Makefile headers?
Brooks Davis wrote: On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: =20 # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ =20 have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. =20 In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. =20 Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks The example from original post of dns/bind99 is rather new, # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ An older Makefile where MAINTAINER= evolved to no longer repeat Whom: # ports collection makefile for:hylafax # Date created: 16 May 1995 # Whom: Julian Stacey j...@freebsd.org # # $FreeBSD: ports/comms/hylafax/Makefile,v 1.101 2010/09/19 12:04:42 dinoex Exp $ MAINTAINER= din...@freebsd.org Yes, first line seem disposable, repeating info in PORTNAME PORTVERSION # ports collection makefile for:hylafax # New ports collection makefile for:BIND 9.9.x But Whom Date are useful on occasion. On various other older ports, when I couldnt get response in time from MAINTAINER (I don't mean re hylafax), perhaps maintainer on holiday, I couldn't wait for send-pr tiem out, didnt want to invoke send-pr, I fell back succesfully, to contacting the Whom: creator, who while no longer regularly motivated to do maintenance, could respond without delay give hints (fallback maintainer). I presume some other users do that too, but we'd not see evidence if people chose not to use send-pr (often a good thing to omit initialy, eg when one isnt sure if one has a local mistake or misunderstanding, or if there's a generic bug.) Hiding Whom in meta data would be bad: Within a cvs or svn would make it much harder to access. ports.tgz comes on CDs etc, all get it. Less people have cvs, less still svn, less svn mirrors, less people (outside commiters) will be experienced/familiar with svn compared to cvs. Some ports are easy to create, eg my lang/pbasic, but some are hard, (eg I'd guess editors/openoffice-3 may have been, One might ask # Whom: Martin Blapp comms/hylafax was a lot of work (whatever might show in Makefile, getting run time interfaces sorted was Work). Let ports creators retain their one line of credit. Removing it would save little be ungrateful, like removing names out of .c .h. (Some (inc. me) may like noticing in passing who created the ports one's working on)). The credit may encourage some ports creators to struggle on, creating sometimes obdurate complex ports one might otherwise be tempted to give up on after a not-yet-port is just hand built hand tested localy, Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. ___ 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: Can we please just remove the old Makefile headers?
On 8/27/2012 7:40 AM, Julian H. Stacey wrote: Brooks Davis wrote: On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: =20 # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ =20 have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. =20 In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. =20 Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks The example from original post of dns/bind99 is rather new, # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ An older Makefile where MAINTAINER= evolved to no longer repeat Whom: # ports collection makefile for:hylafax # Date created: 16 May 1995 # Whom: Julian Stacey j...@freebsd.org # # $FreeBSD: ports/comms/hylafax/Makefile,v 1.101 2010/09/19 12:04:42 dinoex Exp $ MAINTAINER= din...@freebsd.org Yes, first line seem disposable, repeating info in PORTNAME PORTVERSION # ports collection makefile for:hylafax # New ports collection makefile for:BIND 9.9.x But Whom Date are useful on occasion. On various other older ports, when I couldnt get response in time from MAINTAINER (I don't mean re hylafax), perhaps maintainer on holiday, I couldn't wait for send-pr tiem out, didnt want to invoke send-pr, I fell back succesfully, to contacting the Whom: creator, who while no longer regularly motivated to do maintenance, could respond without delay give hints (fallback maintainer). I know several ports where this is the opposite of what the submitter wants. They've long moved on and do not want to be bothered. Plus it only adds to frustration to the reporter, who is sending a *2nd* email to a *2nd* person who may not respond. I presume some other users do that too, but we'd not see evidence if people chose not to use send-pr (often a good thing to omit initialy, eg when one isnt sure if one has a local mistake or misunderstanding, or if there's a generic bug.) Hiding Whom in meta data would be bad: Within a cvs or svn would make it much harder to access. ports.tgz comes on CDs etc, all get it. Less people have cvs, less still svn, less svn mirrors, less people (outside commiters) will be experienced/familiar with svn compared to cvs. You can easily look on freshports. Some ports are easy to create, eg my lang/pbasic, but some are hard, (eg I'd guess editors/openoffice-3 may have been, One might ask # Whom: Martin Blapp comms/hylafax was a lot of work (whatever might show in Makefile, getting run time interfaces sorted was Work). Let ports creators retain their one line of credit. Removing it would save little be ungrateful, like removing names out of .c .h. (Some (inc. me) may like noticing in passing who created the ports one's working on)). The credit may encourage some ports creators to struggle on, creating sometimes obdurate complex ports one might otherwise be tempted to give up on after a not-yet-port is just hand built hand tested localy, I actually agree fully with keeping their line of credit. But I disagree that we should not remove or modify their email address on request from them. Cheers, Julian -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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: Can we please just remove the old Makefile headers?
On 27 August 2012 08:40, Julian H. Stacey j...@berklix.com wrote: On various other older ports, when I couldnt get response in time from MAINTAINER (I don't mean re hylafax), perhaps maintainer on holiday, I couldn't wait for send-pr tiem out, didnt want to invoke send-pr, I fell back succesfully, to contacting the Whom: creator, who while no longer regularly motivated to do maintenance, could respond without delay give hints (fallback maintainer). Which is exactly the reason we should get rid of the whom lines. The submitter is *not* a fallback maintainer, and some users mistakenly assume that the whom line is the maintainer. We should be encouraging users to mail po...@freebsd.org and possibly cc the maintainer if required. Some ports are easy to create, eg my lang/pbasic, but some are hard, (eg I'd guess editors/openoffice-3 may have been, One might ask # Whom: Martin Blapp The whom address might be bouncing, the person might be not be using FreeBSD anymore, or any of the like. Let ports creators retain their one line of credit. Removing it would save little be ungrateful, like removing names out of .c .h. (Some (inc. me) may like noticing in passing who created the ports one's working on)). The credit may encourage some ports creators to struggle on, creating sometimes obdurate complex ports one might otherwise be tempted to give up on after a not-yet-port is just hand built hand tested localy, Interesting argument. But this implies that we should allow the whom line to be changed by creator request -- 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: Can we please just remove the old Makefile headers?
Hi, Reference: From: Bryan Drewery br...@shatow.net Date: Mon, 27 Aug 2012 08:02:15 -0500 Message-id: 503b6fd7.4060...@shatow.net Bryan Drewery wrote: On 8/27/2012 7:40 AM, Julian H. Stacey wrote: Brooks Davis wrote: On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: =20 # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ =20 have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. =20 In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. =20 Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks The example from original post of dns/bind99 is rather new, # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ An older Makefile where MAINTAINER= evolved to no longer repeat Whom: # ports collection makefile for:hylafax # Date created: 16 May 1995 # Whom: Julian Stacey j...@freebsd.org # # $FreeBSD: ports/comms/hylafax/Makefile,v 1.101 2010/09/19 12:04:42 dinoex Exp $ MAINTAINER= din...@freebsd.org Yes, first line seem disposable, repeating info in PORTNAME PORTVERSION # ports collection makefile for:hylafax # New ports collection makefile for:BIND 9.9.x But Whom Date are useful on occasion. On various other older ports, when I couldnt get response in time from MAINTAINER (I don't mean re hylafax), perhaps maintainer on holiday, I couldn't wait for send-pr tiem out, didnt want to invoke send-pr, I fell back succesfully, to contacting the Whom: creator, who while no longer regularly motivated to do maintenance, could respond without delay give hints (fallback maintainer). I know several ports where this is the opposite of what the submitter wants. They've long moved on and do not want to be bothered. Plus it only adds to frustration to the reporter, who is sending a *2nd* email to a *2nd* person who may not respond. Yes, allow Whom: to request his/her Human name /or email address be deleted. I presume some other users do that too, but we'd not see evidence if people chose not to use send-pr (often a good thing to omit initialy, eg when one isnt sure if one has a local mistake or misunderstanding, or if there's a generic bug.) Hiding Whom in meta data would be bad: Within a cvs or svn would make it much harder to access. ports.tgz comes on CDs etc, all get it. Less people have cvs, less still svn, less svn mirrors, less people (outside commiters) will be experienced/familiar with svn compared to cvs. You can easily look on freshports. I just use what's under freebsd.org domain (CTM) feeds of src ports cvs ( now svn). I've never looked much at Me-Too-For-A-BSD-domains eg PCBSD freshports etc. I guessed freshports.org, checked got xants type spider gimmick in browser, so closed browser. Some ports are easy to create, eg my lang/pbasic, but some are hard, (eg I'd guess editors/openoffice-3 may have been, One might ask # Whom: Martin Blapp comms/hylafax was a lot of work (whatever might show in Makefile, getting run time interfaces sorted was Work). Let ports creators retain their one line of credit. Removing it would save little be ungrateful, like removing names out of .c .h. (Some (inc. me) may like noticing in passing who created the ports one's working on)). The credit may encourage some ports creators to struggle on, creating sometimes obdurate complex ports one might otherwise be tempted to give up on after a not-yet-port is just hand built hand tested localy, I actually agree fully with keeping their line of credit. But I disagree that we should not remove or modify their email address on request from them. I always assumed we allowed update deletion of Whom: via send-pr. both of human names (which may vary, eg on marriage) /or email
gdb75 dumps core on startup
Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
Eitan Adler wrote: On 27 August 2012 08:40, Julian H. Stacey j...@berklix.com wrote: On various other older ports, when I couldnt get response in time from MAINTAINER (I don't mean re hylafax), perhaps maintainer on holiday, I couldn't wait for send-pr tiem out, didnt want to invoke send-pr, I fell back succesfully, to contacting the Whom: creator, who while no longer regularly motivated to do maintenance, could respond without delay give hints (fallback maintainer). Which is exactly the reason we should get rid of the whom lines. The submitter is *not* a fallback maintainer, No, - eg, If MAINTAINER of hylafax had resigned I would have resumed maintenance. - Creators of others ports have functioned as fallback if asked. I guess its not an uncommon phenomena, a creator is happy someone else maintains code, but doesnt want to see a port unsupported if maintainer response might slip toward timeout replacement. and some users mistakenly assume that the whom line is the maintainer. If global edit is done, we could be more explicit than Whom: change to eg Creator (but see MAINTAINER below): We should be encouraging users to mail po...@freebsd.org and possibly cc the maintainer if required. Ports is high volume; one can get lost in traffic, sometimes private mail is better, context dependent. Some ports are easy to create, eg my lang/pbasic, but some are hard, (eg I'd guess editors/openoffice-3 may have been, One might ask # Whom: Martin Blapp The whom address might be bouncing, the person might be not be using FreeBSD anymore, or any of the like. Alow deletion update by send-pr Let ports creators retain their one line of credit. Removing it would save little be ungrateful, like removing names out of .c .h. (Some (inc. me) may like noticing in passing who created the ports one's working on)). The credit may encourage some ports creators to struggle on, creating sometimes obdurate complex ports one might otherwise be tempted to give up on after a not-yet-port is just hand built hand tested localy, Interesting argument. But this implies that we should allow the whom line to be changed by creator request I wasnt aware they were not changeable ?. I'd assumed it was free text comment, not auto generated ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with . Send plain text. Not: HTML, multipart/alternative, base64, quoted-printable. ___ 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: gdb75 dumps core on startup
on 27/08/2012 17:03 Andriy Gapon said the following: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. The problem seems to be caused by files/patch-gdb-amd64-nat.h, which for some cryptic reason removes prototype of amd64bsd_target() from amd64-nat.h. That allows the code to be compilable still (sloppy gdb developers!) but the assumed return type of the function becomes int instead of a pointer which it really is. Thus, the returned pointer value gets truncated on amd64 and as a result an invalid pointer is passed to i386_use_watchpoints() from _initialize_amd64fbsd_nat(). Oh, looking at the patch in PR ports/165357 (http://www.freebsd.org/cgi/query-pr.cgi?pr=165357), it seems that amd64bsd_target() should have re-appeared in a new header file amd64bsd-nat.h... But that part of the patch seems to be incorrect in that it would create files/amd64bsd-nat.h instead of a patch file to create amd64bsd-nat.h in the source directory. Apparently this file never made it as a result. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdb75 dumps core on startup
I'm waiting someone commit this: ports/171109 On Mon, Aug 27, 2012 at 4:44 PM, Andriy Gapon a...@freebsd.org wrote: on 27/08/2012 17:03 Andriy Gapon said the following: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. The problem seems to be caused by files/patch-gdb-amd64-nat.h, which for some cryptic reason removes prototype of amd64bsd_target() from amd64-nat.h. That allows the code to be compilable still (sloppy gdb developers!) but the assumed return type of the function becomes int instead of a pointer which it really is. Thus, the returned pointer value gets truncated on amd64 and as a result an invalid pointer is passed to i386_use_watchpoints() from _initialize_amd64fbsd_nat(). Oh, looking at the patch in PR ports/165357 (http://www.freebsd.org/cgi/query-pr.cgi?pr=165357), it seems that amd64bsd_target() should have re-appeared in a new header file amd64bsd-nat.h... But that part of the patch seems to be incorrect in that it would create files/amd64bsd-nat.h instead of a patch file to create amd64bsd-nat.h in the source directory. Apparently this file never made it as a result. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdb75 dumps core on startup
on 27/08/2012 17:44 Andriy Gapon said the following: on 27/08/2012 17:03 Andriy Gapon said the following: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. The problem seems to be caused by files/patch-gdb-amd64-nat.h, which for some cryptic reason removes prototype of amd64bsd_target() from amd64-nat.h. That allows the code to be compilable still (sloppy gdb developers!) but the assumed return type of the function becomes int instead of a pointer which it really is. Thus, the returned pointer value gets truncated on amd64 and as a result an invalid pointer is passed to i386_use_watchpoints() from _initialize_amd64fbsd_nat(). Oh, looking at the patch in PR ports/165357 (http://www.freebsd.org/cgi/query-pr.cgi?pr=165357), it seems that amd64bsd_target() should have re-appeared in a new header file amd64bsd-nat.h... But that part of the patch seems to be incorrect in that it would create files/amd64bsd-nat.h instead of a patch file to create amd64bsd-nat.h in the source directory. Apparently this file never made it as a result. Oh, oops, I misread history a bit and I see now that amd64bsd-nat.h is included upstream. But since the upstream version doesn't have a prototype for amd64bsd_target(), then files/patch-gdb-amd64-nat.h should be dropped. -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdb75 dumps core on startup
on 27/08/2012 17:48 Luca Pizzamiglio said the following: I'm waiting someone commit this: ports/171109 Great, thanks! On Mon, Aug 27, 2012 at 4:44 PM, Andriy Gapon a...@freebsd.org wrote: on 27/08/2012 17:03 Andriy Gapon said the following: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. The problem seems to be caused by files/patch-gdb-amd64-nat.h, which for some cryptic reason removes prototype of amd64bsd_target() from amd64-nat.h. That allows the code to be compilable still (sloppy gdb developers!) but the assumed return type of the function becomes int instead of a pointer which it really is. Thus, the returned pointer value gets truncated on amd64 and as a result an invalid pointer is passed to i386_use_watchpoints() from _initialize_amd64fbsd_nat(). Oh, looking at the patch in PR ports/165357 (http://www.freebsd.org/cgi/query-pr.cgi?pr=165357), it seems that amd64bsd_target() should have re-appeared in a new header file amd64bsd-nat.h... But that part of the patch seems to be incorrect in that it would create files/amd64bsd-nat.h instead of a patch file to create amd64bsd-nat.h in the source directory. Apparently this file never made it as a result. -- Andriy Gapon -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdb75 dumps core on startup
on 27/08/2012 17:51 Andriy Gapon said the following:
on 27/08/2012 17:48 Luca Pizzamiglio said the following:
I'm waiting someone commit this:
ports/171109
Great, thanks!
BTW, you might want to fix another issue along the way: make reinstall fails
because of an existing symlink. -f option to ${LN} should fix that.
install -o root -g wheel -m 555
/usr/obj/ports/usr/ports/devel/gdb/work/gdb-7.5/gdb/gdb /usr/local/bin/gdb75
/bin/ln /usr/local/bin/gdb75 /usr/local/bin/gdbtui75
ln: /usr/local/bin/gdbtui75: File exists
*** [do-install] Error code 1
--
Andriy Gapon
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: gdb75 dumps core on startup
On 08/27/12 16:03, Andriy Gapon wrote: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. I can confirm that this happens on my not so recent 10-CURRENT (r239353), also amd64. I see a similar issue on 8.3-STABLE (r239646) on amd64: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] Segmentation fault: 11 (core dumped) while on i386 gcc75 works OK, but I see: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-portbld-freebsd8.3. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/hans/a.out...done. (gdb) I do not know if the message about the undefined symbol is related to the issue at hand. The previous version (gcc741) did not show this message and functioned perfectly, also on amd64. Kind regards, Hans ___ 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: gdb75 dumps core on startup
Hi, Hans : have you tried the patch included here ports/171109? Andriy: thanks for the report, I create a patch for that as soon as I can! Regards, Luca On Mon, Aug 27, 2012 at 4:59 PM, Hans Ottevanger h...@beastielabs.net wrote: On 08/27/12 16:03, Andriy Gapon wrote: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. I can confirm that this happens on my not so recent 10-CURRENT (r239353), also amd64. I see a similar issue on 8.3-STABLE (r239646) on amd64: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] Segmentation fault: 11 (core dumped) while on i386 gcc75 works OK, but I see: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-portbld-freebsd8.3. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/hans/a.out...done. (gdb) I do not know if the message about the undefined symbol is related to the issue at hand. The previous version (gcc741) did not show this message and functioned perfectly, also on amd64. Kind regards, Hans ___ 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: gdb75 dumps core on startup
On 08/27/12 17:06, Luca Pizzamiglio wrote: Hi, Hans : have you tried the patch included here ports/171109? With that patch gdb75 comes back to life again on amd64, and stops spewing weird messages while starting up on both amd64 and i386. If I stumble over more issues I will let you know. Thanks for your reply. Kind regards, Hans Andriy: thanks for the report, I create a patch for that as soon as I can! Regards, Luca On Mon, Aug 27, 2012 at 4:59 PM, Hans Ottevanger h...@beastielabs.net wrote: On 08/27/12 16:03, Andriy Gapon wrote: Program terminated with signal 11, Segmentation fault ... #0 0x004777e2 in i386_use_watchpoints () #1 0x00476bbd in _initialize_amd64fbsd_nat () #2 0x0060deea in initialize_all_files () #3 0x005e710f in gdb_init () #4 0x00549086 in relocate_gdb_directory () #5 0x00547aa4 in catch_errors () #6 0x00548bb4 in gdb_main () #7 0x00457ea9 in main () This is on amd64 head. I can confirm that this happens on my not so recent 10-CURRENT (r239353), also amd64. I see a similar issue on 8.3-STABLE (r239646) on amd64: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] Segmentation fault: 11 (core dumped) while on i386 gcc75 works OK, but I see: $ gdb75 ./a.out [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb (GDB) 7.5 [GDB v7.5 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-portbld-freebsd8.3. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/hans/a.out...done. (gdb) I do not know if the message about the undefined symbol is related to the issue at hand. The previous version (gcc741) did not show this message and functioned perfectly, also on amd64. Kind regards, Hans ___ 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
PKG_NG: pkg deinstall fails with argument list too long
PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan ___ 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
Job
- This mail is in HTML. Some elements may be ommited in plain text. - Wal Mart is looking for Secret ~Shoppers to help us checkout our stores in your area and we will pay you. Please visit our page to SignUp .. ___ 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
lang/gcc46 dependency loop on lang/gcc
Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. This would seem to be an error in the bsd.gcc.mk logic, or perhaps an error in one of the ports' Makefiles, not sure yet. Any chance you could look into this? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46 dependency loop on lang/gcc
On Mon, Aug 27, 2012 at 12:35:14PM -0700, Doug Barton wrote: Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. FWIW, on the machine on which I'm writing this note, I successfully performed an: Upgrade of gcc-4.6.4.20120608 to gcc-4.6.4.20120817 yesterday without incident (using portmaster). The machine is now running: FreeBSD albert.catwhisker.org 8.3-STABLE FreeBSD 8.3-STABLE #560 239646M: Fri Aug 24 04:21:00 PDT 2012 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT i386 (and had been updated to that just prior to the portmaster run). The ports tree is maintained as an SVN working copy; it was @303183 as of the time of the update in question. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpCdMvKCnRqQ.pgp Description: PGP signature
Re: lang/gcc46 dependency loop on lang/gcc
On 8/27/2012 12:44 PM, David Wolfskill wrote: FWIW, on the machine on which I'm writing this note, I successfully performed an: Upgrade of gcc-4.6.4.20120608 to gcc-4.6.4.20120817 yesterday without incident (using portmaster). Do you have lang/gcc installed, or lang/gcc46? pkg_info -qo gcc-4.6\* Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46 dependency loop on lang/gcc
On Mon, Aug 27, 2012 at 12:46:27PM -0700, Doug Barton wrote: ... Do you have lang/gcc installed, or lang/gcc46? pkg_info -qo gcc-4.6\* albert(8.3-S)[5] pkg_info -qo gcc-4.6\* lang/gcc46 albert(8.3-S)[6] Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp41acYGQzOI.pgp Description: PGP signature
Re: PKG_NG: pkg deinstall fails with argument list too long
On Mon, Aug 27, 2012 at 08:03:46PM +0200, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan ___ 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 The bug is fixed in git and will be in final release. To workaround you can run make FORCE_PKG_REGISTER=1 install this will safely reinstall it, and pkg delete will work again. regards, Bapt pgpj2qemlR6rd.pgp Description: PGP signature
Re: PKG_NG: pkg deinstall fails with argument list too long
On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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: PKG_NG: pkg deinstall fails with argument list too long
On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote: On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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 Can you try changing: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395 to: pkg_addfile(pkg, sbuf_get(tmp), pkg_sum, false); ? regards, Bapt pgpNnTQjewuYe.pgp Description: PGP signature
Re: PKG_NG: pkg deinstall fails with argument list too long
On 2012-08-27 23:23, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote: On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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 Can you try changing: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395 to: pkg_addfile(pkg, sbuf_get(tmp), pkg_sum, false); ? will do, could you please provide a diff fetch 'https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395' gives only glibber and I don't want to enable javascrit to grab a simple patch ... -- Regards, olli ___ 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
fresh install of kde4 fails - japanese/kiten
I elected to do a complete re-install of an 8.3 server, and kde4 fails because of dependencies: x11/kde4 depends on: misc/kdeedu4 which depends on: japanese/kiten WHICH FAILS Is there a way to have kde4 -not- use and therefore not depend on kdeedu4 ? Or not have kdeedu4 depend on kiten? ___ 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: PKG_NG: pkg deinstall fails with argument list too long
On Mon, Aug 27, 2012 at 11:43:54PM +0200, olli hauer wrote: On 2012-08-27 23:23, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote: On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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 Can you try changing: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395 to: pkg_addfile(pkg, sbuf_get(tmp), pkg_sum, false); ? will do, could you please provide a diff fetch 'https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395' gives only glibber and I don't want to enable javascrit to grab a simple patch ... -- Regards, olli sure: http://people.freebsd.org/~bapt/patch-no-test-duplicate-from-manifest just add it to you files/ directory regards, Bapt pgpkSNTKK96Em.pgp Description: PGP signature
Re: fresh install of kde4 fails - japanese/kiten
On Mon, Aug 27, 2012 at 11:49 PM, Jim Pazarena fpo...@paz.bz wrote: Is there a way to have kde4 -not- use and therefore not depend on kdeedu4 ? Or not have kdeedu4 depend on kiten? Of course, you can use OPTIONS to deselect the dependencies. What's the problem, anyway? Can you paste a log? We're interested in fixing it. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: PKG_NG: pkg deinstall fails with argument list too long
On 2012-08-27 23:53, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 11:43:54PM +0200, olli hauer wrote: On 2012-08-27 23:23, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote: On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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 Can you try changing: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395 to: pkg_addfile(pkg, sbuf_get(tmp), pkg_sum, false); ? will do, could you please provide a diff fetch 'https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395' gives only glibber and I don't want to enable javascrit to grab a simple patch ... -- Regards, olli sure: http://people.freebsd.org/~bapt/patch-no-test-duplicate-from-manifest just add it to you files/ directory Thanks, that patch makes really a difference Without the metasploit package time pkg repo -f 8.3-amd64 Generating repo.sqlite in 8.3-amd64: done! 4.699u 0.166s 0:00.85 570.5%127+1407k 0+6io 0pf+0w Now with time pkg repo -f 8.3-amd64 Generating repo.sqlite in 8.3-amd64: done! 10.651u 2.937s 0:09.22 147.2% 127+1411k 0+11io 0pf+0w (before 70-80s. longer) Even the install time goes down 50% time pkg install -y metasploit Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing metasploit: 4.1.0 The installation will require 214 MB more space 0 B to be downloaded Checking integrity... done Installing metasploit-4.1.0... done 21.796u 10.164s 0:34.44 92.7% 127+1408k 180+1183io 0pf+0w time pkg delete -y metasploit The following packages will be deinstalled: metasploit-4.1.0 The deinstallation will free 214 MB Deinstalling metasploit-4.1.0...pkg: rmdir(/usr/local/share/metasploit/): Directory not empty done 5.767u 2.294s 0:08.19 98.2% 128+1414k 2+680io 0pf+0w This looks really better, please close pkgng issue #322 -- Thanks, olli ___ 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: PKG_NG: pkg deinstall fails with argument list too long
On Tue, Aug 28, 2012 at 12:20:16AM +0200, olli hauer wrote: On 2012-08-27 23:53, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 11:43:54PM +0200, olli hauer wrote: On 2012-08-27 23:23, Baptiste Daroussin wrote: On Mon, Aug 27, 2012 at 10:22:27PM +0200, olli hauer wrote: On 2012-08-27 20:03, Stefan Esser wrote: PKG_NG seems to have introduced a limit on the size of ports that can be deinstalled: # cd /usr/ports/math/lapack # make deinstall === Deinstalling for math/lapack === Deinstalling lapack-3.4.0_2 The following packages will be deinstalled: lapack-3.4.0_2 The deinstallation will free 28 MB Deinstalling lapack-3.4.0_2...lapack-3.4.0_2 is required by: qrupdate-1.1.1, deleting anyway pkg: Cannot run script(DEINSTALL): Argument list too long *** [deinstall] Error code 3 This is on an up-to-date -CURRENT with freshly fetched ports and pkg-1.0.r6_1 and WITH_PKGNG=yes in /etc/make.conf. Regards, STefan One limitation I found was if the port has a really long pkg-plist the `pkg repo' command times are going to the roof. For example `pkg repo' a folder with metasploit.txz only takes in a ramdisk and everything else on SSD ~80+ seconds. Extracting the packages takes ~3s. in RAM or on SSD (pkgng issue #322). ___ 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 Can you try changing: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395 to: pkg_addfile(pkg, sbuf_get(tmp), pkg_sum, false); ? will do, could you please provide a diff fetch 'https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_manifest.c#L395' gives only glibber and I don't want to enable javascrit to grab a simple patch ... -- Regards, olli sure: http://people.freebsd.org/~bapt/patch-no-test-duplicate-from-manifest just add it to you files/ directory Thanks, that patch makes really a difference Without the metasploit package time pkg repo -f 8.3-amd64 Generating repo.sqlite in 8.3-amd64: done! 4.699u 0.166s 0:00.85 570.5%127+1407k 0+6io 0pf+0w Now with time pkg repo -f 8.3-amd64 Generating repo.sqlite in 8.3-amd64: done! 10.651u 2.937s 0:09.22 147.2% 127+1411k 0+11io 0pf+0w (before 70-80s. longer) Even the install time goes down 50% time pkg install -y metasploit Updating repository catalogue Repository catalogue is up-to-date, no need to fetch fresh copy The following packages will be installed: Installing metasploit: 4.1.0 The installation will require 214 MB more space 0 B to be downloaded Checking integrity... done Installing metasploit-4.1.0... done 21.796u 10.164s 0:34.44 92.7% 127+1408k 180+1183io 0pf+0w time pkg delete -y metasploit The following packages will be deinstalled: metasploit-4.1.0 The deinstallation will free 214 MB Deinstalling metasploit-4.1.0...pkg: rmdir(/usr/local/share/metasploit/): Directory not empty done 5.767u 2.294s 0:08.19 98.2% 128+1414k 2+680io 0pf+0w This looks really better, please close pkgng issue #322 -- Thanks, olli ___ 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 Committed thanks Bapt pgpydQFpRYRHE.pgp Description: PGP signature
Re: fresh install of kde4 fails - japanese/kiten
this is on a fresh install of 8.3, and AFTER running a csup Alberto Villa wrote, On 2012-08-27 3:16 PM: On Mon, Aug 27, 2012 at 11:49 PM, Jim Pazarena fpo...@paz.bz wrote: Is there a way to have kde4 -not- use and therefore not depend on kdeedu4 ? Or not have kdeedu4 depend on kiten? Of course, you can use OPTIONS to deselect the dependencies. What's the problem, anyway? Can you paste a log? We're interested in fixing it. === Installing for kdeedu-4.8.4 === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/blinken - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/cantor - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kalgebra - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kanagram - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kbruch - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kgeography - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/khangman - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kig - found === kdeedu-4.8.4 depends on file: /usr/local/kde4/bin/kiten - not found ===Verifying install for /usr/local/kde4/bin/kiten in /usr/ports/japanese/kiten = kiten-4.8.4.tar.bz2 is not in /usr/ports/japanese/kiten/distinfo. = Either /usr/ports/japanese/kiten/distinfo is out of date, or = kiten-4.8.4.tar.bz2 is spelled incorrectly. *** Error code 1 Stop in /usr/ports/japanese/kiten. *** Error code 1 Stop in /usr/ports/misc/kdeedu4. ___ 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: fresh install of kde4 fails - japanese/kiten
On Tue, Aug 28, 2012 at 12:52 AM, Jim Pazarena fpo...@paz.bz wrote: = kiten-4.8.4.tar.bz2 is not in /usr/ports/japanese/kiten/distinfo. = Either /usr/ports/japanese/kiten/distinfo is out of date, or = kiten-4.8.4.tar.bz2 is spelled incorrectly. *** Error code 1 Can you show the output of `make -C /usr/ports/japanese/kiten -V USE_BZIP2`, please? -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: Can we please just remove the old Makefile headers?
On 27 August 2012 10:23, Julian H. Stacey j...@berklix.com wrote: Eitan Adler wrote: No, - eg, If MAINTAINER of hylafax had resigned I would have resumed maintenance. This is unrelated to you being the original contributor. It is you, thankfully, being interested in the port. :) - Creators of others ports have functioned as fallback if asked. I guess its not an uncommon phenomena, a creator is happy someone else maintains code, but doesnt want to see a port unsupported if maintainer response might slip toward timeout replacement. It is equally common that the creator left the project and the given address bounces. change to eg Creator (but see MAINTAINER below): or just get rid of it, if we are changing things :) We should be encouraging users to mail po...@freebsd.org and possibly cc the maintainer if required. Ports is high volume; one can get lost in traffic, sometimes private mail is better, context dependent. this brings up a completely different bikeshed of splitting ports@ into -users and -devel, but not for now. :) Alow deletion update by send-pr You mean like a maintainer? If I understand correctly, you want the idea of multiple maintainers. I am completely for this. It is even trivial to do by adding a comment just below the MAINTAINER line. This is unrelated to maintaining the historical originator in the header of the port. I wasnt aware they were not changeable ?. I'd assumed it was free text comment, not auto generated ? this is the property which started this discussion. They are currently the historical address used to submit the port. The address is never changed. -- 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: Can we please just remove the old Makefile headers?
On 08/26/12 17:02, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Doug +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
