have: /gettext/ want: /gettext8/ /gettext10/ etc
Just wondering if the change suggested in the Subject line of this message can result in the following scenario of something like it: installed gettext10 installed gettext8 if gettext bumps from so.8 to so.10, both installed and any port which relies upon them uses the lesser until it is bumped "non-gettext", upon which time it uses the more recent one. a path? variable? make.conf? Anything to avoid weeks of rebuild. then when nothing depends on gettext8 it can be deinstalled. ... Jeff (not subscribed) .. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pkgng 1.0 release schedule [...concerns...thread...continued...]
I view, rightly-or-wrongly, the mandatory usage of pkgng VS /var/db/pkg/portname-number, as somewhat of a showstopper, at least without more assurances... I interact daily with /var/db/pkg as follows... using the shells' tab-completion of /var/db/pkg/ to more efficiently pkg_create, pkg_delete portmaster -d -B -P -i -g /var/db/pkg/ /var/db/pkg/ /var/db/pkg/ /var/db/pkg /var/db/pkg/ /var/db/pkg... && yell || yell; #zsh# no space on the machine for pkgng #zsh# in /var/db/pkg # does not pkg_complete without the pwd #zsh# pkg_delete -f portname-number && pkg_add /mnt/portmaster-download/portname-number... #var/db/pkg# ls -lac | grep py26 # upgrading to py27 #var/db/pkg# ls -lac | grep diff # what tools can I use make build-depends-list ls -lac /var/db/pkg/this ls -lac /var/db/pkg/that #... which port is less-recently upgraded that might fix this port... /usr/ports/devel/gettext cp -iv /var/db/pkg/gett[tab]/+REQUIRED_BY . # reference for prior-to rebuild, esp., if UPDATING ... ... # to defer or not the upgrade of a port, Any lesser-easily equivalent to these using pkgng, if it involves actually writing down the name-number (lacking tab completion), would incur a serious time cost AFAIK, not to mention RSI. ... Also, 'fails to register' in pkgng... with /var/db/pkg, at least one can "make -k install" ( I should elaborate this concern more, but where would the "failed to register" exist? Files would be installed but ... pkgng would put a file in /work/ detailing its failure to register the port and why?? I rightly-or-wrongly picture pkgng sort of as a front-end to /var/db/pkg/, then removal of the latter. Unless clear equivalents using pkgng to the CLI and scenarios I've posted above are elucidated, put in a flowchart somewhere (or the wiki...)... it *sort of* forces the use of packages rather than building from ports ?? Or I am just inexperienced... Thanks J. Bouquet ___ 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"
pkgng default schedule... registering a few reasons for rethinking the final implementation...
I am following with dread the planned implementation of the deprecation of /var/db/pkg as a package registry... I use each /var/db/pkg directory as a database into the port installation/status, using sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff. For instance, an upgrade py26 > py27. cd /var/db/pkg ls -lac | grep py26 ls -lac | grep python as the more simple example. With due respect to its developers and the persons who agree that the package tools could be upgraded, the mandatory usage of a front-end database to a file directory one is here viewd as mutt-only-mbox, registry-and-bsod rather than /etc/local/rc files, deprecation of sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade the ports that are registered; ... I see concurrently too few tests on lower-end p2, p3 as to whether pkg can run with lesser memory machines (routers...) (pfsense) ... I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd, pfsense..) due to less-reliability, more-possibility of bugs.. ... Not to mention native tab-completion not dependent upon further customizations, ... Introduces complexity to running earlier versions of BSD virtualized in later versions and vice versa... ... I've innumerable times made "quick work" (2 hours or so) of cross-disk backup/fix/upgrade using /var/db/pkg where doing so with just the pkg tools or my own scripts would take immeasurably longer... ... It would deprecate searching +CONTENTS, for example, or quickly checking the text file +REQUIRED_BY without a database frontend. ... Almost every reply and post have glossed over those points, referring to the benefits of a newer package management system, again glossing over the added memory requirements, number of .so. required, lack of extensive testing across all hardware cpu/memory scenarios... ... "it will be a single tool that will do the job of all the many port/package management scripts currently only available in the ports system (bsdadminscripts)" for example. A single tool, yes. But it won't do all of the edge-case jobs *not* covered by the present pkg_ tools that can be crafted hooking into the /var/db/pkg/ directory structure, with find for example. "pkgng is not a replacement for portmaster or portupgrade..." That was not my question. My concern was with the deprecation of the latter and /var/db/pkg along with the introduction of pkgng. ... Each pkg_ legacy uses about 3-6 .so. afaik. pkg uses 19. ... A review of pkgng on mebsd.com, suggests replacment CLI for tasks one might do with portmaster now. However, they are much more arcane (%H-%M vs -g...) and thus unwelcoming... ... "patches for portmaster and portupgrade to use pkgng tools" Memory requirements with both working together? The ABI between them breaks? ... My concerns are more or less, why should the following *ever* be mandatory... "On both FBSD 10 boxes, the installation of the port security/cyrus-sasl2 got corrupted by "install" and/or "mtree" dumping core and signalling SIGNAL 11. Booting into multiuser mode is impossible, login core dumps SIGNAL 11, many other daemons, too. The only way is to boot into single user mode. An installation failed due to pkg(ng) was missing libarchive.so via portmaster or via core dumping install. By installing on one box, my home box, port security/cyrus-sasl2 manually, luckily install and mtree didn't coredump and it worked - and this procedure rescued me. But on my lab's development box, it didn't work! " (Continues with more equally terrible detail...) (Freebsd-questions, august) ... Or my own experience, today, testing on a p4 pre-p2 memory req. investigations. # pkg stats Unable to open remote database "repo". Try running 'pkg update' first. # pkg update Updating repository catalogue zsh: segmentation fault pkg update . So, a kernel option (non default) to deprecate /var/db/pkg? A further development of pkg to concurrently maintain a /var/db/pkg? ...not implying the concurrent deprecation of the latter! Brighter ideas? Thanks for reading these concerns. I am quite perturbed by the announcement of v11 erasing the /var/db/pkg upon which I presently use daily numerous times... And I apologize, in advance, for typos etc. herein... J. Bouquet 2004 v5... ___ 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 default release schedule (contd...)
A few more reasons (unless I have not seen some relevant documentation to the contrary) to not mandate pkgng as the default... Nowadays, one can save time by installing two ports which officially or unofficially conflict, and have /var/db/pkg entries for both, and even local workarounds (for instance, moving the duplicate binary elsewhere before the second install) (Perchance removing the line in the Makefile). ... A failed "make install (register)", one can check the /var/db/pkg/ directory(ies) to double check visually to what extent it did NOT fail. Similarly for a failed "make deinstall (unregister)"... ... pkgdb -F to fixup stale dependencies and resolve dependency information. A proven method in the portmaster manpage to reinstall all 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"
Fw: RE: pkgng default release schedule (s/ABI/API/g ...typo)
s/ABI/API/g Sorry! --- On Fri, 8/24/12, Jeffrey Bouquet wrote: > From: Jeffrey Bouquet > Subject: RE: pkgng default release schedule (contd...) > To: "Chris Rees" > Date: Friday, August 24, 2012, 1:28 PM > Comments below. I've no idea how to > fix the quoting system so I'll try to do it manually, Maybe > in a few weeks... it is webmail and its-all-text seems no to > function at the moment. > > --- On Fri, 8/24/12, Chris Rees > wrote: > > From: Chris Rees > Subject: RE: pkgng default release schedule (contd...) > To: "Jeffrey Bouquet" > Date: Friday, August 24, 2012, 10:57 AM > > > > On 24 Aug 2012 15:37, "Jeffrey Bouquet" > wrote: > > > > > > Comments inline below... > > > > > > --- On Fri, 8/24/12, Chris Rees > wrote: > > >> > > >> > > >> From: Chris Rees > > >> Subject: RE: pkgng default release schedule > (contd...) > > >> To: "Jeffrey Bouquet" > > >> Cc: "FreeBSD Mailing List" , > "freebsd-current" > > > >> Date: Friday, August 24, 2012, 4:37 AM > > >> > > >> > > >> On 24 Aug 2012 11:08, "Jeffrey Bouquet" > >>wrote: > > >> > > > >> > A few more reasons (unless I have not seen > some relevant >>documentation to the contrary) to not > mandate pkgng as the default... > > >> > > >> > > >> Why don't you phrase this as "How can one ..." so > you sound less >>negative? > > >> > > >Please fix your mailer's quoting. > It is webmail. Sorry. I am fixing part of it as I go along > but I've no idea if it is making it worse... > > > > >> I am unequivocably opposed (reasoning below > included, after I wrote >>this paragraph; ) to pkg > mandated as the default, until convinced > > >> > > >> otherwise, and trying to sound nicer, by making the > sentences >>shorter. If that is > > >> > > >> stubborness-from-ignorance, I sincerely > apologize, in advance. But >>I see no one else > > >> > > >> vocalizing opposition at the moment... vs those in > favor, and am >>simply in my > > >> > > >> view voicing arguments to delay the not-inevitable > deprecation of >>/var/db/pkg... > > >Possibly because your attitude as I mention above makes > people think > >you're trolling. > > I am dismayed by the thought that the package management > system is > broken. We have the Makefile directories (starting > point) /var/db/pkg > directories (registration feature) portmaster/portmanager/ > custom .sh/ > portupgrade (automation feature) and the installed binaries > (end point). > Pkg introduces an ABI making > portmaster/portmanager/portupgrade/to-be-portupgrades/.sh > costlier to implement in time, ABI experience, > and maybe buggier. Meanwhile, the registration feature > (present in > BSD, absent AFAIK in most Linux, abstracted in Windows), > would be > abstracted in BSD also. > > Suppose I rightly viewed that the ports tree was not working > well > enough for the majority of users. > > There is a new tool, portsnap-textonly (psto) > Its use is easy! > psto view makefile editors nano > psto configure editors nano > psto view pkgplist editors nano > psto view editors > > I'm fully justified in putting it somewhere (a port.) > It is only when I remove the actual ports tree to a > xml-based or > sql-based repository, that I begin to de-minimalistic > de-potentially-better > Freebsd, and fork it to something that only may serve better > a subset > (however large) of its users. Even if I obtain the > majority opinion that it is expedient, and > even if it *is* actually expedient for the > majority, I'd maybe want to quell the > concerns of those very reluctant to pursue the paradigm > shift that > it is *not* in their best interests... or do more coding > beforehand > to compensate for the impact it may have upon their use of > the operating system. > > > > > > > >> Certainly not trying to "just complain" for the > sake of impeding >progress. > > >> > > >> > Nowadays, one can save time by installing two > ports which >officially or unofficially conflict, and > have /var/db/pkg entries for >both, and even > > >> > local workarounds (for instance, moving the > duplicate binary >else
P2 testing of pkg
pkg2ng fails to register anything: Undefined symbol "_ThreadRuneLocale" It tries; Each port is attempted to be registered. ... Unknown if that is because of the p2 having an earlier version of 9-STABLE than upon which was built /pkg/ ... As an aside, now that bsdstats.org has its port statistics back up, I see that /pkg/ is installed in only a small subset of reporting BSD/pc-bsd/etc/ machines... portupgrade 4697 portmaster2039 portmanager322 portupgrade-devel 185 pkg 41 As of earlier today anyway. J. Bouquet ___ 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"
One more pkg non-default-please edge-case reasoning...
I should explain opposition to the deprecation of /var/db/pkg more fully (assuming it is to be obsoleted by pkg)... I am accustomed to using the /lookat/ port to view text files (such as +CONTENTS.) Multiple times weekly, I use its 's' key to search (a dialog box appears) bin so etc. This side of simple. (Additionally, a nice white-on-blue readability). Never got used to the search keys in "less" etc. So the flat files here serve a purpose I surmise is not that common. And figuring out which category /editors/ etc (the pkg-plist equivalent) is way slower in many cases. A reason to retain that particular usability... til/when I/someone notices a workaround. J. Bouquet ___ 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"
Portmaster and ccache
WITH_CCACHE_BUILD="yes" seems to be working... howsoever a few (2) times recently, portmaster would complete entirely (signaled by the 'yell' command as " && yell", but returning to that tty0 (xterm or...) the compiler will be still working on the already-upgraded port [1] (easily stopped by a cntl-c, and that is the whole story) but maybe portmaster no longer works with all ports with ccache? or some other recent innovation in the port building system... or the way ccache works, that it didn't previously, or ?? Maybe just trivia, could be a seldom ocurrence ( No time to repeat for now to check which port that was, etc..). Or maybe if I happen across an instance where there is more of a scrollback buffer I'd see the cause right away. [1] as if a second command had been scheduled to start when the first completed... J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Sat, 9/8/12, Kevin Oberman wrote: > From: Kevin Oberman > Subject: Re: [HEADS-UP] Announcing the end of port CVS > To: "Jamie Paul Griffin" > Cc: freebsd-ports@freebsd.org > Date: Saturday, September 8, 2012, 2:42 PM > On Sat, Sep 8, 2012 at 3:09 AM, Jamie > Paul Griffin > wrote: > > [ Lars Eighner wrote on Fri 7.Sep'12 at 10:00:45 > -0500 ] > > > >> On Fri, 7 Sep 2012, Beat Gaetzi wrote: > >> > >> >The development of FreeBSD ports is done in > Subversion nowadays. > >> >For the sake of compatibility a Subversion to > CVS exporter is > >> >in place which has some limitations. For CVSup > mirroring cvsup > >> >based on Ezm3 is used which breaks regularly > especially on amd64 > >> >and with Clang and becomes more and more > unmaintainable. > >> > >> > >> What exactly is the motivation again for moving > from things which work like > >> cvsup and gcc to things that are broken or lame > like subversion and clang? > > > > They're not broken. I've recently been using them and > they're fine. > > There has been plenty of discussion about the reasons > for the changes so > > have a read from the various sites and list archives. > > Looks like a troll to me. No one who has worked with > subversion for a > project of any size would ever want to go back to CVS. While > still > having some of CVS's limitations, it does far, far more and > is much > easier to work with for most things. I really miss the > forced commit > and, for one application, RANCiD, I use CVS so I can grep > through the > ,v files easily. But I can't see any reason for FreeBSD not > to move > the the more advanced system. > > As to clang, there is no choice there. The license on newer > version of > gcc (GPLv3) is simply not acceptable to the community, so > gcc is stuck > forever at 4.2 which is getting very old. clang has > excellent > development support, an acceptable license, and early tests > show that > it generally compiles faster and MAY even generate better, > faster > code. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6...@gmail.com > ___ > freebsd-ports@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > I'd not go so far as to label it trolling ... I searched quite a bit upon this announcement to find csup > svn equivalent guides and found little applying to ports... hopefully they will appear prior to the changeover?, something easily learned? (disregarding portsnap for the moment, and I apologize...) (the .htm I saved from the web searches (svn) appear too complex and irrelevant to this use case to be of use here...) ... As a minor aside, /devel/apr1/ is a dependency of subversion at least on this machine probably... ... All the many FreeBSD texts I've read and used, maybe one of them has a relevant chapter? And/or maybe complete SVN instructions should be added to the UPDATING file as well as a section on ports in the subversion manpage(s). ... All taken as constructive discussion hopefully. I re-edited this email to make it shorter and less critical... J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Fri, 9/7/12, Lars Eighner wrote: > From: Lars Eighner > Subject: Re: [HEADS-UP] Announcing the end of port CVS > To: "Beat Gaetzi" > Cc: freebsd-ports@freebsd.org > Date: Friday, September 7, 2012, 8:00 AM > On Fri, 7 Sep 2012, Beat Gaetzi > wrote: > > > The development of FreeBSD ports is done in Subversion > nowadays. > > For the sake of compatibility a Subversion to CVS > exporter is > > in place which has some limitations. For CVSup > mirroring cvsup > > based on Ezm3 is used which breaks regularly especially > on amd64 > > and with Clang and becomes more and more > unmaintainable. The svn-book: ...you can edit files at will, but you must tell Subversion about everything else that you do... Empirically, to a newbie, this appears quite confusing. Are the files in, say, /usr/ports/devel/boost-libs "owned" in some manner by svn? The extra files I've placed there (automatically generated copies of work/.PList_flattened..)(etc) are ignored/accidentally erased? Lock files are no longer supposed to be placed in the directory by scripts? ... I had intended to simply restore an older copy of /usr/ports over the new one, and have the two combined, as it were, but it appears many unwanted effects (... only certain svn commands from now on? Procedure to only .svn one of the port categories as can be done with csup? Which svn commands transfer files from where to where etc.?) Perhaps it would be better if I practice on the new ports tree before restoring over it, re-restore after practice, etc... Or even better, print out the online documentation, print out the forum svn examples, and spend several weeks practicing for csup equivalents and procedures... (That is what I am maybe wondering. Has anyone done the same and written it all up in a more detailed scenario? Which svn command subsets put files not deeper in .svn at risk? Is there only one .svn or multiple ones? Which svn commands should be run just once, and which routinely? Which to update just one parts of the ports tree? ... Even commands to copy the ports tree elsewhere with a lesser volume of files (no .svn... ) (Subversion appears more of an administrative tool rather than an end-user tool; requiring more complex configuration maybe, though maybe not if just for the ports tree. Possible configuration files to examine/copy persons may have already working for user/ports?) I'd rather use portsnap only on an older laptop... otherwise I would defer to it instead (for now anyway, since there is still time left...) BTW in replies to a question on the freebsd-questions list, I surmise there are many server farm administrators who are comfortable with csup/cvsup and not yet familiar with svn, and may also be thrown a learning curve with this change. Apologies for asking here, but trying to save many hours (or even minutes) of web searching, trial and error, etc... J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Sun, 9/9/12, Eitan Adler wrote: > From: Eitan Adler > Subject: Re: [HEADS-UP] Announcing the end of port CVS > To: "Kevin Oberman" > Cc: "Lowell Gilbert" , > freebsd-ports@freebsd.org > Date: Sunday, September 9, 2012, 2:41 PM > On 9 September 2012 17:30, Kevin > Oberman > wrote: > > On Sun, Sep 9, 2012 at 11:57 AM, Lowell Gilbert > > > wrote: > >> Kevin Oberman > writes: > >> > >>> On Sat, Sep 8, 2012 at 4:08 PM, Jeffrey > Bouquet > >>> > wrote: > >>>> I searched quite a bit > upon this announcement to find csup > svn equivalent > guides and found little applying to ports... > >>>> hopefully they will appear prior to the > changeover?, something > >>>> easily learned? > >>> > >>> Good point. I found the handbook information > adequate, but not as easy > >>> to follow as it might be. > >>> Guess I'll write one. It's really quite easy > and much faster then csup. > >>> > >>> 1. Install devel/subversion > >>> 2. Select US east coast or US west as your > server. Pick at random or > >>> pick the one closer to you. > >>> 3. Rename (mv) ports/distfiles and > ports/packages out of /usr/ports > >>> 4. rm -r /usr/ports/* > >>> 5. svn co http://svn0.us-west.freebsd.org/ports/head /usr/ports > >>> OR > >>> svn co http://svn0.us-east.freebsd.org/ports/head /usr/ports > >>> Ports will now be checked out of > the repository and written to /usr/ports > >>> 6. make -f /usr/ports/Makefile fetchindex > >>> 7. Move ports/distfiles and ports/packages back > into /usr/ports. Since > >>> these directories are not in the repository, > they will be ignored by > >>> updates. > >>> 7. Update ports as needed with 'svn up > /usr/ports' and 'make -f > >>> /usr/ports/Makefile fetchindex' > >>> This step does the equivalent of > csup. > >>> 8. Use the Subversion manual from http://svnbook.red-bean.com/ to > >>> learn how to other things with svn. Of > particular interest is 'svn > >>> info /usr/ports and setting up the .subversion > file to do things like > >>> ignore some directories. > >>> If you add private ports to /usr/ports, they > will be ignored by svn as > >>> they don't exist in the repository. > >>> > >>> If anyone has suggestions on other things that > belong in this list, > >>> please let me know. > >> > >> I submitted some changes for the Handbook, but they > really only covered > >> the things that I thought were now Wrong. Your > descriptions are > >> certainly of higher quality. > > > > But I am still learning to count without a computer to > help. 1, 2, 3, > > 4, 5, 6, 7, 7, 8??? **Sigh** > > I think you messed up because you didn't start from the > basics: > > 0, 1, 2, 3 ... > > > -- > 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" > Initial attempts with svn[1] suggest one may skip step 4 (making the svn command more like csup), if that is the case, anyone know of a workaround (easier method) than restoring /usr/ports/distfiles and /usr/ports/packages from backup? Or skipping those steps altogether, svn does extra/unwanted work or? [1] on only x11-themes, for example J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Sun, 9/9/12, Jeffrey Bouquet wrote: > From: Jeffrey Bouquet > Subject: Re: [HEADS-UP] Announcing the end of port CVS > To: "Kevin Oberman" , "Eitan Adler" > Cc: "Lowell Gilbert" , > freebsd-ports@freebsd.org > Date: Sunday, September 9, 2012, 3:47 PM > > > --- On Sun, 9/9/12, Eitan Adler > wrote: > > > From: Eitan Adler > > Subject: Re: [HEADS-UP] Announcing the end of port CVS > > To: "Kevin Oberman" > > Cc: "Lowell Gilbert" , > freebsd-ports@freebsd.org > > Date: Sunday, September 9, 2012, 2:41 PM > > On 9 September 2012 17:30, Kevin > > Oberman > > wrote: > > > On Sun, Sep 9, 2012 at 11:57 AM, Lowell Gilbert > > > > > wrote: > > >> Kevin Oberman > > writes: > > >> > > >>> On Sat, Sep 8, 2012 at 4:08 PM, Jeffrey > > Bouquet > > >>> > > wrote: > > >>>> I searched quite a bit > > upon this announcement to find csup > svn > equivalent > > guides and found little applying to ports... > > >>>> hopefully they will appear prior to > the > > changeover?, something > > >>>> easily learned? > > >>> > > >>> Good point. I found the handbook > information > > adequate, but not as easy > > >>> to follow as it might be. > > >>> Guess I'll write one. It's really quite > easy > > and much faster then csup. > > >>> > > >>> 1. Install devel/subversion > > >>> 2. Select US east coast or US west as > your > > server. Pick at random or > > >>> pick the one closer to you. > > >>> 3. Rename (mv) ports/distfiles and > > ports/packages out of /usr/ports > > >>> 4. rm -r /usr/ports/* > > >>> 5. svn co http://svn0.us-west.freebsd.org/ports/head /usr/ports > > >>> OR > > >>> svn co http://svn0.us-east.freebsd.org/ports/head /usr/ports > > >>> Ports will now be checked out of > > the repository and written to /usr/ports > > >>> 6. make -f /usr/ports/Makefile fetchindex > > >>> 7. Move ports/distfiles and ports/packages > back > > into /usr/ports. Since > > >>> these directories are not in the > repository, > > they will be ignored by > > >>> updates. > > >>> 7. Update ports as needed with 'svn up > > /usr/ports' and 'make -f > > >>> /usr/ports/Makefile fetchindex' > > >>> This step does the equivalent of > > csup. > > >>> 8. Use the Subversion manual from http://svnbook.red-bean.com/ to > > >>> learn how to other things with svn. Of > > particular interest is 'svn > > >>> info /usr/ports and setting up the > .subversion > > file to do things like > > >>> ignore some directories. > > >>> If you add private ports to /usr/ports, > they > > will be ignored by svn as > > >>> they don't exist in the repository. > > >>> > > >>> If anyone has suggestions on other things > that > > belong in this list, > > >>> please let me know. > > >> > > >> I submitted some changes for the Handbook, but > they > > really only covered > > >> the things that I thought were now Wrong. > Your > > descriptions are > > >> certainly of higher quality. > > > > > > But I am still learning to count without a > computer to > > help. 1, 2, 3, > > > 4, 5, 6, 7, 7, 8??? **Sigh** > > > > I think you messed up because you didn't start from > the > > basics: > > > > 0, 1, 2, 3 ... > > > > > > -- > > 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" > > > > Initial attempts with svn[1] suggest one may skip step 4 > (making the > svn command more like csup), if that is the case, anyone > know of > a workaround (easier method) than restoring > /usr/ports/distfiles > and /usr/ports/packages from backup? Or skipping those > steps > altogether, svn does extra/unwanted work > or? > [1] on only x11-themes, for example > > J. Bouquet > ___ > 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" > Sorry to reply to my own email. These CLI worked... mv /usr/ports/distfiles /usr/distfiles mv /usr/ports/packages /usr/packages... (Haven't gotten to the svn part yet...) J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Sat, 9/8/12, Kevin Oberman wrote: > From: Kevin Oberman > Subject: Re: [HEADS-UP] Announcing the end of port CVS > To: "Jeffrey Bouquet" > Cc: "Jamie Paul Griffin" , freebsd-ports@freebsd.org > Date: Saturday, September 8, 2012, 10:15 PM > On Sat, Sep 8, 2012 at 4:08 PM, > Jeffrey Bouquet > > wrote: > > > > > > --- On Sat, 9/8/12, Kevin Oberman > wrote: > > > >> From: Kevin Oberman > >> Subject: Re: [HEADS-UP] Announcing the end of port > CVS > >> To: "Jamie Paul Griffin" > >> Cc: freebsd-ports@freebsd.org > >> Date: Saturday, September 8, 2012, 2:42 PM > >> On Sat, Sep 8, 2012 at 3:09 AM, Jamie > >> Paul Griffin > >> wrote: > >> > [ Lars Eighner wrote on Fri 7.Sep'12 at > 10:00:45 > >> -0500 ] > >> > > >> >> On Fri, 7 Sep 2012, Beat Gaetzi wrote: > >> >> > >> >> >The development of FreeBSD ports is > done in > >> Subversion nowadays. > >> >> >For the sake of compatibility a > Subversion to > >> CVS exporter is > >> >> >in place which has some limitations. > For CVSup > >> mirroring cvsup > >> >> >based on Ezm3 is used which breaks > regularly > >> especially on amd64 > >> >> >and with Clang and becomes more and > more > >> unmaintainable. > >> >> > >> >> > >> >> What exactly is the motivation again for > moving > >> from things which work like > >> >> cvsup and gcc to things that are broken or > lame > >> like subversion and clang? > >> > > >> > They're not broken. I've recently been using > them and > >> they're fine. > >> > There has been plenty of discussion about the > reasons > >> for the changes so > >> > have a read from the various sites and list > archives. > >> > >> Looks like a troll to me. No one who has worked > with > >> subversion for a > >> project of any size would ever want to go back to > CVS. While > >> still > >> having some of CVS's limitations, it does far, far > more and > >> is much > >> easier to work with for most things. I really miss > the > >> forced commit > >> and, for one application, RANCiD, I use CVS so I > can grep > >> through the > >> ,v files easily. But I can't see any reason for > FreeBSD not > >> to move > >> the the more advanced system. > >> > >> As to clang, there is no choice there. The license > on newer > >> version of > >> gcc (GPLv3) is simply not acceptable to the > community, so > >> gcc is stuck > >> forever at 4.2 which is getting very old. clang > has > >> excellent > >> development support, an acceptable license, and > early tests > >> show that > >> it generally compiles faster and MAY even generate > better, > >> faster > >> code. > >> -- > >> R. Kevin Oberman, Network Engineer > >> E-mail: kob6...@gmail.com > >> ___ > >> freebsd-ports@freebsd.org > >> mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports > >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > >> > > > > I'd not go so far as to label it trolling > > The language was highly pejorative, so it felt troll like. > > ... > > I searched quite a bit upon this > announcement to find csup > svn equivalent guides and > found little applying to ports... > > hopefully they will appear prior to the changeover?, > something > > easily learned? > > Good point. I found the handbook information adequate, but > not as easy > to follow as it might be. > Guess I'll write one. It's really quite easy and much faster > then csup. > > 1. Install devel/subversion > 2. Select US east coast or US west as your server. Pick at > random or > pick the one closer to you. > 3. Rename (mv) ports/distfiles and ports/packages out of > /usr/ports > 4. rm -r /usr/ports/* > 5. svn co http://svn0.us-west.freebsd.org/ports/head /usr/ports > OR > svn co http://svn0.us-east.freebsd.org/ports/head /usr/ports > Ports will now be checked out of the > repository and written to /usr/ports > 6. make -f /usr/ports/Makefile fetchindex > 7. Move ports/distfiles and
Csup -- svn -- portsnap -- ctm -- ???
I've always relied on local log files, script-generated files, .txt files with hints on rebuilding, .htm with usage, etc in the ports tree directories (/usr/ports/devel/subversion/Plist_Manually /usr/ports/devel/subversion/Time_toCompile /usr/ports/devel/subversion/svn_ports.msg ) etc etc. With more than one machine low on disk space vs what a fully modern PC might be, are they any hints on how to proceed when the usual csup/cvsup is deprecated? . Portsnap says it will lose local changes, and refuses to update a ports tree I restored over a fresh one (with files as the above). (It wants it created anew again...) . SVN, until I learn how, may not cleanly merge the former ports tree (with the extra files) into the new tree and let the extra files stay there (as portsnap's man page suggest it also might.) I know I could craft a thumbdrive, ftp server, etc etc solution but as this is a wholesale change of how I've always updated ports I am looking for someone else's suggestions (who use portsnap and/or ctm and/or svn, and also have extra files in the ports tree) about which methodology I might try to setup on one machine, and if it works, plan the rest before csup/cvsup deprecates (unless they remain in non-official svn>csup servers somewhere, so to speak...) Thanks J. Bouquet ___ 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: [HEADS-UP] Announcing the end of port CVS
--- On Fri, 9/7/12, Beat Gaetzi wrote:
> From: Beat Gaetzi
> Subject: [HEADS-UP] Announcing the end of port CVS
> To: freebsd-ports@FreeBSD.org
> Date: Friday, September 7, 2012, 5:36 AM
> The development of FreeBSD ports is
> done in Subversion nowadays.
> For the sake of compatibility a Subversion to CVS exporter
> is
> in place which has some limitations. For CVSup mirroring
> cvsup
> based on Ezm3 is used which breaks regularly especially on
> amd64
> and with Clang and becomes more and more unmaintainable.
>
> For those reasons by February 28th 2013 the FreeBSD ports
> tree will
> no longer be exported to CVS. Therefore ports tree updates
> via CVS
> or CVSup will no longer available after that date. All users
> who use
> CVS or CVSup to update the ports tree are encouraged to
> switch to
> portsnap(8) [1] or for users which need more control over
> their ports
> collection checkout use Subversion directly:
>
> % svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
>
> and update a checked out repository using:
>
> % cd /usr/ports && svn update
>
> Advanced users, or larger sites, might consider setting up a
> local
> svn mirror. Both for people doing direct checkouts and for
> people
> wanting to use a local mirror, they can access one of the
> public
> subversion servers [2].
>
> How to set up a Subversion mirror using svnsync(1) is
> described in
> the FreeBSD Committers Guide [3]. Initial seeds to set up a
> svnsync
> mirror are provided on the FreeBSD FTP mirror sites under
> /pub/FreeBSD/development/subversion/.
>
> Binary packages for pkg_install are still provided via the
> FTP mirror
> network. There is also pkgng which is a feature rich
> replacement tool
> for pkg_install available in the ports tree under
> ports/ports-mgmt/pkg.
> Packages for pkgng are available on pkg.FreeBSD.org.
>
> To use pkg.FreeBSD.org at least pkgng 1.0 RC6 is needed and
> can be
> enabled in pkg.conf like this (where ${ABI} is dependent on
> your
> system):
> PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest
> SRV_MIRRORS : YES
>
> With pkgng 1.0 SRV_MIRRORS is enabled by default and no
> longer needs
> to be set explicitly. If pkgng prior to 1.0 RC6 is used
> http://pkgbeta.FreeBSD.org can be used as packagesite
> instead.
>
> Please keep im mind that the pkgng infrastructure is still
> considered
> as beta. More information about pkgng can be found at
> http://wiki.FreeBSD.org/pkgng and https://github.com/pkgng/pkgng.
>
> Beat, on behalf of portmgr@
>
> [1] http://www.FreeBSD.org/doc/handbook/updating-upgrading-portsnap.html
> [2] http://www.FreeBSD.org/doc/handbook/mirrors-svn.html
> [3]
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.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"
>
[1] Should not this go in UPDATING now for persons who have it
set in cron and do not read this list? Thus they would have time
to prepare adequately or to ask questions at the minimum.
[2] Any URL of sites which would be portsnap or svn updated, yet
export via a cvs server for persons to continue using csup/cvsup?
I had a random thought that this change could be delayed one release
so that csup could depend upon a new .so. "on purpose" in v10 that
would notify the user somehow that it is deprecated in v11... but
that neglects cvsup...
J. Bouquet
___
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: [HEADS-UP] Announcing the end of port CVS
--- On Wed, 9/12/12, Jeffrey Bouquet wrote:
> From: Jeffrey Bouquet
> Subject: Re: [HEADS-UP] Announcing the end of port CVS
> To: freebsd-ports@FreeBSD.org, "Beat Gaetzi"
> Date: Wednesday, September 12, 2012, 6:31 AM
>
>
> --- On Fri, 9/7/12, Beat Gaetzi
> wrote:
>
> > From: Beat Gaetzi
> > Subject: [HEADS-UP] Announcing the end of port CVS
> > To: freebsd-ports@FreeBSD.org
> > Date: Friday, September 7, 2012, 5:36 AM
> > The development of FreeBSD ports is
> > done in Subversion nowadays.
> > For the sake of compatibility a Subversion to CVS
> exporter
> > is
> > in place which has some limitations. For CVSup
> mirroring
> > cvsup
> > based on Ezm3 is used which breaks regularly especially
> on
> > amd64
> > and with Clang and becomes more and more
> unmaintainable.
> >
> > For those reasons by February 28th 2013 the FreeBSD
> ports
> > tree will
> > no longer be exported to CVS. Therefore ports tree
> updates
> > via CVS
> > or CVSup will no longer available after that date. All
> users
> > who use
> > CVS or CVSup to update the ports tree are encouraged
> to
> > switch to
> > portsnap(8) [1] or for users which need more control
> over
> > their ports
> > collection checkout use Subversion directly:
> >
> > % svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
> >
> > and update a checked out repository using:
> >
> > % cd /usr/ports && svn update
> >
> > Advanced users, or larger sites, might consider setting
> up a
> > local
> > svn mirror. Both for people doing direct checkouts and
> for
> > people
> > wanting to use a local mirror, they can access one of
> the
> > public
> > subversion servers [2].
> >
> > How to set up a Subversion mirror using svnsync(1) is
> > described in
> > the FreeBSD Committers Guide [3]. Initial seeds to set
> up a
> > svnsync
> > mirror are provided on the FreeBSD FTP mirror sites
> under
> > /pub/FreeBSD/development/subversion/.
> >
> > Binary packages for pkg_install are still provided via
> the
> > FTP mirror
> > network. There is also pkgng which is a feature rich
> > replacement tool
> > for pkg_install available in the ports tree under
> > ports/ports-mgmt/pkg.
> > Packages for pkgng are available on pkg.FreeBSD.org.
> >
> > To use pkg.FreeBSD.org at least pkgng 1.0 RC6 is needed
> and
> > can be
> > enabled in pkg.conf like this (where ${ABI} is
> dependent on
> > your
> > system):
> > PACKAGESITE : http://pkg.freebsd.org/${ABI}/latest
> > SRV_MIRRORS : YES
> >
> > With pkgng 1.0 SRV_MIRRORS is enabled by default and
> no
> > longer needs
> > to be set explicitly. If pkgng prior to 1.0 RC6 is
> used
> > http://pkgbeta.FreeBSD.org can be used as packagesite
> > instead.
> >
> > Please keep im mind that the pkgng infrastructure is
> still
> > considered
> > as beta. More information about pkgng can be found at
> > http://wiki.FreeBSD.org/pkgng and https://github.com/pkgng/pkgng.
> >
> > Beat, on behalf of portmgr@
> >
> > [1] http://www.FreeBSD.org/doc/handbook/updating-upgrading-portsnap.html
> > [2] http://www.FreeBSD.org/doc/handbook/mirrors-svn.html
> > [3]
> > http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.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"
> >
> [1] Should not this go in UPDATING now for persons who have
> it
> set in cron and do not read this list? Thus they would
> have time
> to prepare adequately or to ask questions at the minimum.
>
> [2] Any URL of sites which would be portsnap or svn updated,
> yet
> export via a cvs server for persons to continue using
> csup/cvsup?
>
> I had a random thought that this change could be delayed one
> release
> so that csup could depend upon a new .so. "on purpose" in
> v10 that
> would notify the user somehow that it is deprecated in
> v11... but
> that neglects cvsup...
>
> J. Bouquet
> ___
> 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"
&g
Re: [HEADS-UP] Announcing the end of port CVS
--- On Wed, 9/12/12, Chris Rees wrote:
> From: Chris Rees
> Subject: Re: [HEADS-UP] Announcing the end of port CVS
> To: "Jeffrey Bouquet"
> Cc: "Beat Gaetzi" , freebsd-ports@freebsd.org
> Date: Wednesday, September 12, 2012, 12:07 PM
> On 12 September 2012 15:14, Jeffrey
> Bouquet
> wrote:
> >
> > --- On Wed, 9/12/12, Jeffrey Bouquet
> wrote:
> >
> >> From: Jeffrey Bouquet
> >> Subject: Re: [HEADS-UP] Announcing the end of port
> CVS
> >> To: freebsd-ports@FreeBSD.org,
> "Beat Gaetzi"
> >> Date: Wednesday, September 12, 2012, 6:31 AM
> >>
> >>
> >> --- On Fri, 9/7/12, Beat Gaetzi
> >> wrote:
> >>
> >> > From: Beat Gaetzi
> >> > Subject: [HEADS-UP] Announcing the end of port
> CVS
> >> > To: freebsd-ports@FreeBSD.org
> >> > Date: Friday, September 7, 2012, 5:36 AM
> >> > The development of FreeBSD ports is
> >> > done in Subversion nowadays.
> >> > For the sake of compatibility a Subversion to
> CVS
> >> exporter
> >> > is
> >> > in place which has some limitations. For
> CVSup
> >> mirroring
> >> > cvsup
> >> > based on Ezm3 is used which breaks regularly
> especially
> >> on
> >> > amd64
> >> > and with Clang and becomes more and more
> >> unmaintainable.
> >> >
> >> > For those reasons by February 28th 2013 the
> FreeBSD
> >> ports
> >> > tree will
> >> > no longer be exported to CVS. Therefore ports
> tree
> >> updates
> >> > via CVS
> >> > or CVSup will no longer available after that
> date. All
> >> users
> >> > who use
> >> > CVS or CVSup to update the ports tree are
> encouraged
> >> to
> >> > switch to
> >> > portsnap(8) [1] or for users which need more
> control
> >> over
> >> > their ports
> >> > collection checkout use Subversion directly:
> >> >
> >> > % svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
> >> >
> >> > and update a checked out repository using:
> >> >
> >> > % cd /usr/ports && svn update
> >> >
> >> > Advanced users, or larger sites, might
> consider setting
> >> up a
> >> > local
> >> > svn mirror. Both for people doing direct
> checkouts and
> >> for
> >> > people
> >> > wanting to use a local mirror, they can access
> one of
> >> the
> >> > public
> >> > subversion servers [2].
> >> >
> >> > How to set up a Subversion mirror using
> svnsync(1) is
> >> > described in
> >> > the FreeBSD Committers Guide [3]. Initial
> seeds to set
> >> up a
> >> > svnsync
> >> > mirror are provided on the FreeBSD FTP mirror
> sites
> >> under
> >> > /pub/FreeBSD/development/subversion/.
> >> >
> >> > Binary packages for pkg_install are still
> provided via
> >> the
> >> > FTP mirror
> >> > network. There is also pkgng which is a
> feature rich
> >> > replacement tool
> >> > for pkg_install available in the ports tree
> under
> >> > ports/ports-mgmt/pkg.
> >> > Packages for pkgng are available on
> pkg.FreeBSD.org.
> >> >
> >> > To use pkg.FreeBSD.org at least pkgng 1.0 RC6
> is needed
> >> and
> >> > can be
> >> > enabled in pkg.conf like this (where ${ABI}
> is
> >> dependent on
> >> > your
> >> > system):
> >> > PACKAGESITE
> : http://pkg.freebsd.org/${ABI}/latest
> >> > SRV_MIRRORS
> : YES
> >> >
> >> > With pkgng 1.0 SRV_MIRRORS is enabled by
> default and
> >> no
> >> > longer needs
> >> > to be set explicitly. If pkgng prior to 1.0
> RC6 is
> >> used
> >> > http://pkgbeta.FreeBSD.org can be used as
> packagesite
> >> > instead.
> >> >
> >> > Please keep im mind that the pkgng
> infrastructure is
> >> still
> >> > considered
> >> > as beta. More information about pkgng can be
> found at
> >> > http://wiki.FreeBSD.org/pkgng and https://github.com/pkgng/pkgng.
> >> >
> >> > Beat, on behalf of portmgr@
> >> >
> >> > [
Re: [HEADS-UP] Announcing the end of port CVS
--- On Wed, 9/12/12, Chris Rees wrote:
> From: Chris Rees
> Subject: Re: [HEADS-UP] Announcing the end of port CVS
> To: "Jeffrey Bouquet"
> Cc: "Beat Gaetzi" , freebsd-ports@freebsd.org
> Date: Wednesday, September 12, 2012, 12:07 PM
> On 12 September 2012 15:14, Jeffrey
> Bouquet
> wrote:
> >
> > --- On Wed, 9/12/12, Jeffrey Bouquet
> wrote:
> >
> >> From: Jeffrey Bouquet
> >> Subject: Re: [HEADS-UP] Announcing the end of port
> CVS
> >> To: freebsd-ports@FreeBSD.org,
> "Beat Gaetzi"
> >> Date: Wednesday, September 12, 2012, 6:31 AM
> >>
> >>
> >> --- On Fri, 9/7/12, Beat Gaetzi
> >> wrote:
> >>
> >> > From: Beat Gaetzi
> >> > Subject: [HEADS-UP] Announcing the end of port
> CVS
> >> > To: freebsd-ports@FreeBSD.org
> >> > Date: Friday, September 7, 2012, 5:36 AM
> >> > The development of FreeBSD ports is
> >> > done in Subversion nowadays.
> >> > For the sake of compatibility a Subversion to
> CVS
> >> exporter
> >> > is
> >> > in place which has some limitations. For
> CVSup
> >> mirroring
> >> > cvsup
> >> > based on Ezm3 is used which breaks regularly
> especially
> >> on
> >> > amd64
> >> > and with Clang and becomes more and more
> >> unmaintainable.
> >> >
> >> > For those reasons by February 28th 2013 the
> FreeBSD
> >> ports
> >> > tree will
> >> > no longer be exported to CVS. Therefore ports
> tree
> >> updates
> >> > via CVS
> >> > or CVSup will no longer available after that
> date. All
> >> users
> >> > who use
> >> > CVS or CVSup to update the ports tree are
> encouraged
> >> to
> >> > switch to
> >> > portsnap(8) [1] or for users which need more
> control
> >> over
> >> > their ports
> >> > collection checkout use Subversion directly:
> >> >
> >> > % svn co https://svn0.us-west.FreeBSD.org/ports/head /usr/ports
> >> >
> >> > and update a checked out repository using:
> >> >
> >> > % cd /usr/ports && svn update
> >> >
> >> > Advanced users, or larger sites, might
> consider setting
> >> up a
> >> > local
> >> > svn mirror. Both for people doing direct
> checkouts and
> >> for
> >> > people
> >> > wanting to use a local mirror, they can access
> one of
> >> the
> >> > public
> >> > subversion servers [2].
> >> >
> >> > How to set up a Subversion mirror using
> svnsync(1) is
> >> > described in
> >> > the FreeBSD Committers Guide [3]. Initial
> seeds to set
> >> up a
> >> > svnsync
> >> > mirror are provided on the FreeBSD FTP mirror
> sites
> >> under
> >> > /pub/FreeBSD/development/subversion/.
> >> >
> >> > Binary packages for pkg_install are still
> provided via
> >> the
> >> > FTP mirror
> >> > network. There is also pkgng which is a
> feature rich
> >> > replacement tool
> >> > for pkg_install available in the ports tree
> under
> >> > ports/ports-mgmt/pkg.
> >> > Packages for pkgng are available on
> pkg.FreeBSD.org.
> >> >
> >> > To use pkg.FreeBSD.org at least pkgng 1.0 RC6
> is needed
> >> and
> >> > can be
> >> > enabled in pkg.conf like this (where ${ABI}
> is
> >> dependent on
> >> > your
> >> > system):
> >> > PACKAGESITE
> : http://pkg.freebsd.org/${ABI}/latest
> >> > SRV_MIRRORS
> : YES
> >> >
> >> > With pkgng 1.0 SRV_MIRRORS is enabled by
> default and
> >> no
> >> > longer needs
> >> > to be set explicitly. If pkgng prior to 1.0
> RC6 is
> >> used
> >> > http://pkgbeta.FreeBSD.org can be used as
> packagesite
> >> > instead.
> >> >
> >> > Please keep im mind that the pkgng
> infrastructure is
> >> still
> >> > considered
> >> > as beta. More information about pkgng can be
> found at
> >> > http://wiki.FreeBSD.org/pkgng and https://github.com/pkgng/pkgng.
> >> >
> >> > Beat, on behalf of portmgr@
> >> >
> >> > [
Re: [Patch] Ports and rsync
--- On Sun, 9/16/12, CyberLeo Kitsana wrote: > From: CyberLeo Kitsana > Subject: [Patch] Ports and rsync > To: "FreeBSD Ports" > Date: Sunday, September 16, 2012, 3:42 AM > I've submitted ports/171681[1] with a > patch to add rsync to the list of > update methods for the ports tree. Hopefully I'm not the > only one who > desires such functionality. > > References: > [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/171681 > > -- > Fuzzy love, > -CyberLeo > Technical Administrator > CyberLeo.Net Webhosting > http://www.CyberLeo.Net > > > Furry Peace! - http://.fur.com/peace/ > ___ > 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" > Could this substitute for .svn for those who now use csup? Or is it maybe specific to a local network and nothing upstream. Not clear the implications, here, or entire scenario of this rsync methodology (I use it readily for a whole bunch of other stuff.) But I look forward to its implementation... if it occurs. J. Bouquet ___ 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 ports which are currently scheduled for deletion
Thanks to this email (omitted, too lengthy) I removed directories sheduled for deletion which would have halted portmaster's procedures were they to be only existing with my own files within them... bsdar games/pets and copied portmanager, its .so.'s, and man page for safekeeping (I used it in the past to "figure-stuff-out-before-doing-anything>> Cntl-C" because its list onscreen was very informative as to what I had installed, although in later versions IIRC it guessed wrong for some reason... (/usr/ports/ports-mgmt/portmanager) and deinstalled, "schedule for deletion" doodle gogo The process was aided by TABBING with the flat files in /var/db/pkg, (where is that port, "is it installed"; pkg_delete -f /var/db/pkg/ etc etc) using non-pkgng tools. I hope that when/if pkgng becomes mandatory its man pages are complete enough so that one can easily find/remember the commands to use... or include an option to write an updated /var/db/pkg set upon its cessation of any particular operation. (I foresee without those files, it may take a bit longer). Just two small points to consider. Thanks for reading. Not wishing to trouble anyone with the time needed to formulate a reply. J. Bouquet ___ 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: [HEADSUP] current switched by default to pkgng
--- On Wed, 10/10/12, Glen Barber wrote: > From: Glen Barber > Subject: Re: [HEADSUP] current switched by default to pkgng > To: "Baptiste Daroussin" > Cc: po...@freebsd.org, ports-annou...@freebsd.org, curr...@freebsd.org > Date: Wednesday, October 10, 2012, 6:51 AM > On Wed, Oct 10, 2012 at 03:44:21PM > +0200, Baptiste Daroussin wrote: > > Hi all, > > > > If you are using the ports tree on a FreeBSD current > setup, then you are > > concerned by the announce. > > > > As nvidia-drivers has been fixed and is now properly > working with pkgng, the > > ports tree as been switch by default to use pkgng on > FreeBSD Current based on > > version >= 117 which was the version when we > tested the switch code. > > > > Make sure to read UPDATING (from ports) to correctly > migrate your system or find > > instruction to make your system still running with > legacy pkg_install tools. > > > > Congratulations, and thank you for all of your hard work on > this! > > Glen > > I was/am confused by the UPDATING instructions. To make the switch: (which switch, and only for V10, from which to which?) ... Before and after step 3, how specifically is the system set up? ... Should any of this be done by persons using V9 immediately before a v9 v10 upgrade? And can another synopsis be written for those before the upgrade, specifically to prepare for either case after the upgrade? IOW more subsections and a longer explanation. (I think maybe more context before/after some of the steps in the procedure...) Just a suggestion. I could probably figure it all out later... J. Bouquet ___ 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: thread at the forums this week
There is a thread this week at the FreeBSD forums, "pkgng: pkg upgrade" in which is posted some concerns about maybe not enough documentation prior to pkg being the default package manager. Someone involved in its development wish to address those in code or to the forum/list? ... Also, I am still concerned about the deprecation of /var/db/pkg files while pkg is default. Could a concurrent option (they still exist) be put in place? For instance, the following pipe: for i in $(find . -type f -name "freebsd_unread*"); do less $i && /bin/rm -iv $i; done Serves to greatly reduce the RSI (keystrokes) while deleting most of a set of files. I've used such pipe many times in the past using the flat files in /var/db/pkg/ as a means to investigate or fixup ports stuff. That would seem to be impossible now with pkg as the default and the files gone... the "find" would have to be recoded to deal with the syntax of PKG ... as well as other more complex stuff later in the pipe, thus whichever problem is being worked on is relegated to a more costly, complex methodology or just ignored (desinstalling a problem set of ports, for example for the latter case). J. Bouquet ___ 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"
Cvsup > svn (ports,src) question and...
When using csup/cvsup sometimes I tee the result to a new logfile so that I do not have to run pkg_version for what-to-upgrade information [1]. How could that be attained using subversion (svn)? A not-trivial inconvenience if it is not possible. [1] my $PAGER (/lookat/) has an easy search function, distinfo, for example, and at least here is easier to read than 'less' and its analogues... ... Anyone have any ideas about a ports-mgmt/legacy_pkg port of some sort that could layer a legacy /var/db/pkg set of files "on top of" the workings of /pkg/? I thought about it a while, but came up with nothing to really expound upon, other than it being a good idea. ... Thanks. J. Bouquet ___ 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, 10/29/12, Eitan Adler wrote: > From: Eitan Adler > Subject: Re: tracking number of users for a port > To: "Kristopher Clark" > Cc: "freebsd-ports@freebsd.org" > Date: Monday, October 29, 2012, 1:08 PM > On 29 October 2012 16:05, Kristopher > Clark > wrote: > > Once a port is in the tree is there a way to track how > many people are using that port? > > Not easily. You may be interested in http://www.bsdstats.org/. There > have been discussions about using a dummy, empty, distfile > in order to > track downloads but there were some concerns about privacy > and > implementation issues which makes this very non-likely. > > > -- > 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" > bsdstats.org's ports link was broken for a long time, recently fixed. It is also useful to check which ports one may wish to install; x11-clocks for instance, if many more are using some port it may be more useful overall; also a way to read all the port names conveniently. ___ 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: pkgclean target? by analogy with distclean
--- On Wed, 10/31/12, Anton Shterenlikht wrote:
> From: Anton Shterenlikht
> Subject: pkgclean target? by analogy with distclean
> To: freebsd-ports@freebsd.org
> Date: Wednesday, October 31, 2012, 3:38 AM
> Is there a target similar to
> distclean
> that removes the package and the symlinks from
> ${PORTSDIR}/packages?
> If not, is it worthwhile making it?
> Something like pkgclean, or maybe
> rmpackage, similar to "make package".
>
> Anton
> ___
> freebsd-ports@freebsd.org
> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
>
After copying .tbz out of /usr/ports/packages/All (If I leave
them there, sometimes they disappear... so that is a
workaround...) to answer the question with an answer that
is only a workaround,
cd /usr/ports/packages
cleanlinks .
Is easy to remember (cd /usr/ports/packages/All && touch
cleanlinks_from_packages.todo )
___
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"
Fw: FreeBSD ports you maintain which are out of date
linrename is marked DEPRECATED. I'd like to reinstall it as well as /reed/ ... > Subject: FreeBSD ports you maintain which are out of date > Date: Saturday, November 3, 2012, 7:01 AM > Full details can be found at the following URL: > http://portscout.freebsd.org/po...@freebsd.org.html ---+-+ > sysutils/linrename > > | 2.22 | > 2.22.1 > http://portscout.freebsd.org/info/portscout-portconfig.txt ___ 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: Fw: FreeBSD ports you maintain which are out of date
> wrote: > > linrename is marked DEPRECATED. I'd like to > reinstall it > > as well as /reed/ ... > > Linrename was undeprecated on Friday and updated to 2.22 at > the same time. > > I've tried to update it to 2.22.1, but the file isn't on > the > MASTER_SITES and I haven't investigated any further :) > > What do you mean by /reed/? > > Chris > > >> Subject: FreeBSD ports you maintain which are out > of date > >> Date: Saturday, November 3, 2012, 7:01 AM > > > >> Full details can be found at the following URL: > >> http://portscout.freebsd.org/po...@freebsd.org.html > > > ---+-+ > >> sysutils/linrename > >> > >> | 2.22 > | > >> 2.22.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" > Thanks! I'm reinstalling it now (linrename). /reed/ was probably textproc/reed, a pager with 'reed -u' (the binary I've saved) does auto scrolling (UPDATING, for example...) ___ 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 doesn't deal with perl minor upgrade? Re: svn commit: r306959 - in head: . lang/perl5.16
Reply at the bottom, sorry for the long post of quoted...
--- On Mon, 11/5/12, Adam McDougall wrote:
> From: Adam McDougall
> Subject: pkg doesn't deal with perl minor upgrade? Re: svn commit: r306959 -
> in head: . lang/perl5.16
> To: po...@freebsd.org
> Date: Monday, November 5, 2012, 5:48 AM
> What is the recommended procedure to
> deal with perl modules after a perl
> minor version upgrade like this? poudriere rebuilt all
> my perl modules
> when perl went to 5.16.2 but none of them get pulled down by
> pkg, just
> perl itself. perl-after-upgrade doesn't see any
> packages installed. I
> spot checked a perl module and it is still in
> /usr/local/lib/perl5/5.16.0 but that is no longer in the
> perl include path.
>
> At this point I would either hand pick the perl modules and
> force
> reinstall them, or use the big hammer and do pkg upgrade
> -f. Is there
> something better? Thanks.
>
> On 11/04/12 04:48, Andrej Zverev wrote:
> > Author: az
> > Date: Sun Nov 4 09:48:04 2012
> > New Revision: 306959
> > URL: http://svn.freebsd.org/changeset/ports/306959
> >
> > Log:
> > Update to 5.16.2
> >
> > Changes: http://search.cpan.org/~rjbs/perl-5.16.2/pod/perldelta.pod
> >
> > Approved by: maintainer
> (implicit via email)
> > With hat: perl@
> > Feature safe: yes
> >
> > Modified:
> > head/UPDATING
> > head/lang/perl5.16/Makefile
> > head/lang/perl5.16/Makefile.man
> > head/lang/perl5.16/distinfo
> > head/lang/perl5.16/pkg-plist
> >
> > Modified: head/UPDATING
> >
> ==
> > --- head/UPDATING Sun Nov 4
> 09:42:45 2012 (r306958)
> > +++ head/UPDATING Sun Nov 4
> 09:48:04 2012 (r306959)
> > @@ -5,6 +5,15 @@ they are unavoidable.
> > You should get into the habit of
> checking this file for changes each time
> > you update your ports collection,
> before attempting any port upgrades.
> >
> > +20121104:
> > + AFFECTS: users of lang/perl5.16
> > + AUTHOR: a...@freebsd.org
> > +
> > + lang/perl5.16 has been updated to 5.16.2.
> You should update everything
> > + that depends on perl. The easiest way to
> do that is to use
> > + "perl-after-upgrade" script supplied with
> lang/perl5.16.
> > + Please see its manual page for details.
> > +
> > 20121102:
> > AFFECTS: users of
> shells/bash-completion
> > AUTHOR: ad...@freebsd.org
> >
> > Modified: head/lang/perl5.16/Makefile
> >
> ==
> > --- head/lang/perl5.16/Makefile Sun
> Nov 4 09:42:45 2012 (r306958)
> > +++ head/lang/perl5.16/Makefile Sun
> Nov 4 09:48:04 2012 (r306959)
> > @@ -40,7 +40,7 @@ OPTIONS=
> DEBUGGING "Build with debugging
> >
> > PORTSCOUT=
> limitw:1,even
> >
> > -PERL_VERSION= 5.16.0
> > +PERL_VERSION= 5.16.2
> > PERL_ARCH= mach
> > SITE_PERL_REL?=
> lib/perl5/site_perl/${PERL_VERSION}
> > SITE_PERL?=
> ${LOCALBASE}/${SITE_PERL_REL}
> >
> > Modified: head/lang/perl5.16/Makefile.man
> >
> ==
> > --- head/lang/perl5.16/Makefile.man
> Sun Nov 4 09:42:45 2012 (r306958)
> > +++ head/lang/perl5.16/Makefile.man
> Sun Nov 4 09:48:04 2012 (r306959)
> > @@ -27,8 +27,11 @@ MAN1+=
> perl5123delta.1
> > MAN1+=
> perl5124delta.1
> > MAN1+=
> perl5140delta.1
> > MAN1+=
> perl5141delta.1
> > +MAN1+= perl5143delta.1
> > MAN1+=
> perl5142delta.1
> > MAN1+=
> perl5160delta.1
> > +MAN1+= perl5161delta.1
> > +MAN1+= perl5162delta.1
> > MAN1+=
> perl561delta.1
> > MAN1+=
> perl56delta.1
> > MAN1+=
> perl581delta.1
> >
> > Modified: head/lang/perl5.16/distinfo
> >
> ==
> > --- head/lang/perl5.16/distinfo Sun
> Nov 4 09:42:45 2012 (r306958)
> > +++ head/lang/perl5.16/distinfo Sun
> Nov 4 09:48:04 2012 (r306959)
> > @@ -1,4 +1,4 @@
> > -SHA256 (perl/perl-5.16.0.tar.bz2) =
> 8c1d25e92a5760e84f77baa57fde5606fd6e95ec992408d36fa53c47162721d1
> > -SIZE (perl/perl-5.16.0.tar.bz2) = 13568573
> > +SHA256 (perl/perl-5.16.2.tar.bz2) =
> 5ba91d9aa40220c615b644bb48fa5df7fbca4afb1c9e911bdc0ce2a93f072d7d
> > +SIZE (perl/perl-5.16.2.tar.bz2) = 13725101
> > SHA256 (perl/BSDPAN-2007.tar.bz2)
> =
> 2f03218a592dc65ebfdc3c6b9394d91dcf4c53aa5290a08458b837baad5a21f9
> > SIZE (perl/BSDPAN-2007.tar.bz2) =
> 8448
> >
> > Modified: head/lang/perl5.16/pkg-plist
> >
> ==
> > --- head/lang/perl5.16/pkg-plist Sun
> Nov 4 09:42:45 2012 (r306958)
> > +++ head/lang/perl5.16/pkg-plist Sun
> Nov 4 09:48:04 2012 (r306959)
> > @@ -188,7 +188,6 @@
> lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC
> > lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC/SharedMem.pm
> > lib/perl5/%%PERL_VER%%/%%PERL_ARCH%%/IPC/SysV.p
Re: pkgng woes
--- On Fri, 11/9/12, Chris Rees wrote: > From: Chris Rees > Subject: Re: pkgng woes > To: "Beeblebrox" > Cc: freebsd-ports@freebsd.org > Date: Friday, November 9, 2012, 8:18 AM > On 9 Nov 2012 09:53, "Beeblebrox" > > wrote: > > > > Pkgng, as a concept may be great, but it's not really > working - at least > for > > me: > > > > 1. pkg2ng conversion does not do a complete job and I > have about half of > my > > ports in purgatory or a quasi-installed state. The > program runs and is > > installed but pkgdb does not have a record for it. So > my ports updates do > a > > half-ass job. > > 2. I am used to portmaster and I accept that > portupgrade is "more ready" > to > > be used with pkgng than portmaster. However, portmaster > has the > > "--check-depends" option which I would normally use to > correct problem #1, > > alas I see no similar function in portupgrade or pkg. > The "portupgrade > -Ffu" > > and "pkg check" commands don't do the trick either. > > 3. I have some ports that I never want to install (like > accessibility/atk > or > > net/avahi). The new pkgtools.conf has a nice feature of > IGNORE_CATEGORIES > > and HOLD_PKGS which I hope will allow me to "blacklist" > those ports but I > > have my doubts as the knob is PKGS and not PORTS - so > we'll see. > Separately > > though, while trying to get my system pkgng complient > and doing updates, > > there have been some ports which were pulled in that I > whish to remove. As > > in #2, portmaster --check-depends did a nice job of > this and allowed the > > dependency to be removed from the portsdb structure - > so same problem here > > as #2. > > 4. I know how to do +IGNOREME in the portsdb and that > is a very roundabout > > way of solving an sqlite entry. > > 5. pkg add does not respect existing port version > information on the > system. > > If you try to install a package and its dependencies, > pkg tries to pull in > > its own preferred version. This happened for perl5 - I > have 5.16 already > on > > the system but pkg kept trying to install 5.14. The > only solution was to > use > > the old "pkg-add -i" to install one-by-one and without > the dependencies. > > Interesting how pkgng does not have the -i (no-deps) > option?? > > Mixing versions with binary packages is a bad idea > anyway. Packages are > built with a certain set of dependencies, and you can't mix > and match (this > has always been the case). If you want to do this, use > ports. Packages > are designed to work as a set, hence pkg upgrade just > upgrades everything > to the latest version. > > Chris > ___ > freebsd-ports@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > Does that mean that, for example, when I upgraded a slew of packages ( pkg_add -f ...) that depended upon pkg-config but installed and theoretically now depending upon pkgconf, that I'd have to do them all by *ports* if using /pkg/ not /var/db/pkg? That would seriously hinder fully half of my upgrades, making them last a magnitude of hours longer each time... J. Bouquet ___ 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 woes
--- On Fri, 11/9/12, Anton Shterenlikht wrote: > From: Anton Shterenlikht > Subject: Re: pkgng woes > To: freebsd-ports@freebsd.org, zap...@berentweb.com > Date: Friday, November 9, 2012, 5:22 AM > @anton > portmaster --check-depends does not work > for me. Shows everything as fine > but when I specifically target a port: *# > portmaster -i graphics/gimp* for > example, I get a long list of ports to be > installed - meaning not all of the > existing ports have been registered > correctly, hence --check depends will > not work. Once I re-install all of the > "missing depends" and run the same > command (*# portmaster -i graphics/gimp*) > then there are no problems nor > list of missing depends. > > Well... if it's any consolation, my convertion > to pkgng wasn't easy either. In fact, I'n not > sure I'm all there yet. > > My problem was due to using an outdated portmaster pkgng > patch. > Note: this is no longer an issue. > Anyway, I ended up with a corrupted pkg database. > I had to update many ports manually. > Now that the pkg database is fully under pngng > control (I'm just a user and don't follow > the technical details, hence my using of non-technical > language) I think portmaster can work with it. > For example portmaster --check-port-dbdir seems > to give correct results. > > Anyway, I think the idea is to remove a lot > of functionality from portmaster and give > it to pkgng. For example checking for missing > dependencies, or shared libs. However, I'm used > to working with ports only, never with packages. > I still don't understand if pkgng is the tool > for me or not. People keep talking of poudriere, > but again I'm not sure if some of the portmaster > functionality is supposed to be taken over > by pourdriere or not. > > Anton > ___ > freebsd-ports@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > FWIW, The wiki (FreeBSDPackageBuildingComparison) says poudriere requires ZSH. I'd like to write more on this topic but am out of time. J. Bouquet ___ 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 woes
--- On Fri, 11/9/12, Kimmo Paasiala wrote: > From: Kimmo Paasiala > Subject: Re: pkgng woes > To: "Beeblebrox" > Cc: freebsd-ports@freebsd.org > Date: Friday, November 9, 2012, 4:54 AM > On Fri, Nov 9, 2012 at 2:39 PM, > Beeblebrox > wrote: > > @anton > > portmaster --check-depends does not work for me. > Shows everything as fine > > but when I specifically target a port: *# portmaster -i > graphics/gimp* for > > example, I get a long list of ports to be installed - > meaning not all of the > > existing ports have been registered correctly, hence > --check depends will > > not work. Once I re-install all of the "missing > depends" and run the same > > command (*# portmaster -i graphics/gimp*) then there > are no problems nor > > list of missing depends. > > > > > > 'portmaster --check-depends' has no equivalent in PKGNG > because it > deals directly with the /var/db/pkg/*/+REQUIRED_BY etc. > files that are > no longer used when using PKGNG. > ___ > 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" > It's corollary (pkgdb -F --omit-check) would also be obsolete? Would there be an equivalent in place? J. Bouquet ___ 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 woes
--- On Fri, 11/9/12, Chris Rees wrote: > From: Chris Rees > Subject: Re: pkgng woes > To: "Jeffrey Bouquet" > Cc: "FreeBSD Mailing List" , "Beeblebrox" > > Date: Friday, November 9, 2012, 11:09 AM > On 9 Nov 2012 18:34, "Jeffrey > Bouquet" > wrote: > > > > > > > > --- On Fri, 11/9/12, Chris Rees > wrote: > > > > > From: Chris Rees > > > Subject: Re: pkgng woes > > > To: "Beeblebrox" > > > Cc: freebsd-ports@freebsd.org > > > Date: Friday, November 9, 2012, 8:18 AM > > > On 9 Nov 2012 09:53, "Beeblebrox" > > > > > > wrote: > > > > > > > > Pkgng, as a concept may be great, but it's > not really > > > working - at least > > > for > > > > me: > > > > > > > > 1. pkg2ng conversion does not do a complete > job and I > > > have about half of > > > my > > > > ports in purgatory or a quasi-installed > state. The > > > program runs and is > > > > installed but pkgdb does not have a record > for it. So > > > my ports updates do > > > a > > > > half-ass job. > > > > 2. I am used to portmaster and I accept that > > > portupgrade is "more ready" > > > to > > > > be used with pkgng than portmaster. However, > portmaster > > > has the > > > > "--check-depends" option which I would > normally use to > > > correct problem #1, > > > > alas I see no similar function in portupgrade > or pkg. > > > The "portupgrade > > > -Ffu" > > > > and "pkg check" commands don't do the trick > either. > > > > 3. I have some ports that I never want to > install (like > > > accessibility/atk > > > or > > > > net/avahi). The new pkgtools.conf has a nice > feature of > > > IGNORE_CATEGORIES > > > > and HOLD_PKGS which I hope will allow me to > "blacklist" > > > those ports but I > > > > have my doubts as the knob is PKGS and not > PORTS - so > > > we'll see. > > > Separately > > > > though, while trying to get my system pkgng > complient > > > and doing updates, > > > > there have been some ports which were pulled > in that I > > > whish to remove. As > > > > in #2, portmaster --check-depends did a nice > job of > > > this and allowed the > > > > dependency to be removed from the portsdb > structure - > > > so same problem here > > > > as #2. > > > > 4. I know how to do +IGNOREME in the portsdb > and that > > > is a very roundabout > > > > way of solving an sqlite entry. > > > > 5. pkg add does not respect existing port > version > > > information on the > > > system. > > > > If you try to install a package and its > dependencies, > > > pkg tries to pull in > > > > its own preferred version. This happened for > perl5 - I > > > have 5.16 already > > > on > > > > the system but pkg kept trying to install > 5.14. The > > > only solution was to > > > use > > > > the old "pkg-add -i" to install one-by-one > and without > > > the dependencies. > > > > Interesting how pkgng does not have the -i > (no-deps) > > > option?? > > > > > > Mixing versions with binary packages is a bad > idea > > > anyway. Packages are > > > built with a certain set of dependencies, and you > can't mix > > > and match (this > > > has always been the case). If you want to do > this, use > > > ports. Packages > > > are designed to work as a set, hence pkg upgrade > just > > > upgrades everything > > > to the latest version. > > > > > > > Does that mean that, for example, when I upgraded a > slew of > > packages ( pkg_add -f ...) that depended upon > pkg-config > > but installed and theoretically now depending upon > pkgconf, that I'd > > have to do them all by *ports* if using /pkg/ not > /var/db/pkg? > > That would seriously hinder fully half of my upgrades, > making them > > last a magnitude of hours longer each time... > > I'm afraid I haven't a clue what you're talking about. pkgng > is nothing to > do with /pkg, and certainly nothing to do with pkg_add. > > Chris > ___ > freebsd-ports@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > Sorry. I was referring to 'you can't mix and match', but I've always done it more or less. (Here a feature, not a bug... lower power CPU.s) I apologize for any confusion, just wanted to inquire if the "pkg_add -f" for dependencies, that are not runtime dependencies, which still allow installing a package;... Otherwise, in this instance, I'd have to somehow figure out which of the hundreds of .tbz on a thumbdrive are with pkg-config; which are with pkgconf; greatly complicating what may be just several hours to do a slew of upgrades to one CPU. Admittedly most FreeBSD users may not face this situation. Apologies if it is wasting anyone's time... J. Bouquet ___ 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 woes
--- On Fri, 11/9/12, Bryan Drewery wrote: > From: Bryan Drewery > Subject: Re: pkgng woes > To: "Jeffrey Bouquet" > Cc: freebsd-ports@freebsd.org > Date: Friday, November 9, 2012, 10:51 AM > On 11/9/2012 12:42 PM, Jeffrey > Bouquet wrote: > > > > > > --- On Fri, 11/9/12, Anton Shterenlikht > wrote: > > > >> From: Anton Shterenlikht > >> Subject: Re: pkgng woes > >> To: freebsd-ports@freebsd.org, > zap...@berentweb.com > >> Date: Friday, November 9, 2012, 5:22 AM > >> @anton > >> portmaster --check-depends > does not work > >> for me. Shows everything as fine > >> but when I specifically > target a port: *# > >> portmaster -i graphics/gimp* for > >> example, I get a long list > of ports to be > >> installed - meaning not all of the > >> existing ports have been > registered > >> correctly, hence --check depends will > >> not work. Once I re-install > all of the > >> "missing depends" and run the same > >> command (*# portmaster -i > graphics/gimp*) > >> then there are no problems nor > >> list of missing depends. > >> > >> Well... if it's any consolation, my convertion > >> to pkgng wasn't easy either. In fact, I'n not > >> sure I'm all there yet. > >> > >> My problem was due to using an outdated portmaster > pkgng > >> patch. > >> Note: this is no longer an issue. > >> Anyway, I ended up with a corrupted pkg database. > >> I had to update many ports manually. > >> Now that the pkg database is fully under pngng > >> control (I'm just a user and don't follow > >> the technical details, hence my using of > non-technical > >> language) I think portmaster can work with it. > >> For example portmaster --check-port-dbdir seems > >> to give correct results. > >> > >> Anyway, I think the idea is to remove a lot > >> of functionality from portmaster and give > >> it to pkgng. For example checking for missing > >> dependencies, or shared libs. However, I'm used > >> to working with ports only, never with packages. > >> I still don't understand if pkgng is the tool > >> for me or not. People keep talking of poudriere, > >> but again I'm not sure if some of the portmaster > >> functionality is supposed to be taken over > >> by pourdriere or not. > >> > >> Anton > >> ___ > >> freebsd-ports@freebsd.org > >> mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-ports > >> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > >> > > FWIW, > > The wiki (FreeBSDPackageBuildingComparison) says > poudriere requires > > ZSH. I'd like to write more on this topic but am > out of time. > > ZFS* > > It uses base /bin/sh, not zsh. > > > > > J. Bouquet > > ___ > > freebsd-ports@freebsd.org > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > > ___ > freebsd-ports@freebsd.org > mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > Sorry for the typo. ( I did not actually mean to zsh-ize the Zfs... the shell does autocompletion in that regard so I am not used to differentiate on the typed line, and typed too hastily.) J. Bouquet. ___ 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"
was: portsnap down.. cvs broken?
Reply below... --- On Mon, 11/12/12, Christoph Moench-Tegeder wrote: From: Christoph Moench-Tegeder Subject: portsnap down? To: freebsd-ports@FreeBSD.org Date: Monday, November 12, 2012, 11:33 PM Hi, as I saw noone complaining until right now (and didn't find any announcement about downtime): looks like portsnap does not provide new snapshots; if I'm reading the current snapshot tag correctly, it's from Sun Nov 11 15:54:03 CET 2012. The svnweb interface shows way more recent commits... Anyone to enlighten me or to nudge portsnap? Regards, Christoph -- Spare Space ___ 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" UPDATING is a broken link from freshports.org cvs/cvsup is not doing anything here for the last twelve hours or so... cvsweb is a broken link from freebsd.org UPDATING might have a clue (something about git) but I am unable to view it, as the cvs nor sites have access... ___ 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: Let's talk about subversion/svn
--- On Sun, 11/18/12, olli hauer wrote: From: olli hauer Subject: Re: Let's talk about subversion/svn To: freebsd-ports@freebsd.org Date: Sunday, November 18, 2012, 11:57 PM On 2012-11-19 08:16, Jeremy Chadwick wrote: > Given the incessant focus on everything using Subversion now (please do > not get me started, it will be like arguing with a brick wall), I'd like > to know what the plan is for minimising the number of dependencies. > > The present subversion **package** on the official FTP servers is for > subversion-1.7.6: > > root@icarus:~ # ftp > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/ > ... > ftp> dir subversion*.tbz > 229 Entering Extended Passive Mode (|||10279|). > 150 Here comes the directory listing. > lrwxr-xr-x 1 967 100 32 Oct 14 14:53 subversion-java.tbz > -> ../All/subversion-java-1.7.6.tbz > lrwxr-xr-x 1 967 100 27 Oct 13 13:24 subversion.tbz -> > ../All/subversion-1.7.6.tbz > lrwxr-xr-x 1 967 100 28 Oct 14 01:54 subversion16.tbz -> > ../All/subversion-1.6.18.tbz > 226 Directory send OK. > > And this is partially what it pulls down dependency-wise: > > root@icarus:~ # pkg_add -r -n subversion > Fetching > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz... > Done. > Package dependency sqlite3-3.7.14.1 for > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz > not found! > Package dependency gdbm-1.9.1 for > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz > not found! > Package dependency db42-4.2.52_5 for > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz > not found! > Package dependency neon29-0.29.6_4 for > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-stable/Latest/subversion.tbz > not found! > > I say partially because due to use of -n, some of those packages weren't > downloaded, thus the recursive dependency nature is lost (I consider > this mostly a bug with -n when used with a remote package, but it could > also be deemed a feature). > > However, GDBM and Oracle/Sleepycat DB aren't (by default) enabled > in 1.7.7 which is what's in ports currently: > > root@icarus:/usr/ports/devel/subversion # make run-depends-list > /usr/ports/databases/sqlite3 > /usr/ports/devel/apr1 > /usr/ports/devel/gettext > /usr/ports/textproc/expat2 > /usr/ports/www/neon29 > > So GDBM and Oracle/Sleepycat DB are now disabled by default (good!), > but now we have the following (and I will describe each of them for > readers so they know what they're for): > > - SQLite -- which I believe is used for data storage for commits/etc. > and tends to work well for that, so I'm okay with it. > - gettext -- needed for NLS, which I've learned to accept although I'd > rather everything today just use UTF-8 universally (idealistic me). > However, there are many people who are heavy WITHOUT_NLS advocates, > and I used to be one, so they should be honoured (IMO). > - APR -- have yet to figure this out. All I can think of is "svn is > an Apache project and we like injecting all our crap into everything, > so enjoy!". > - expat2 -- XML parsing library, which I also have yet to figure out > the need for. What VCS uses XML and why? Is this really *needed*? > - neon -- OPTIONS description labels this as "WebDAV/DAV support", > but in reality what this provides that's most important is HTTPS/SSL > support. I found this out the hard way when building svn for a > customer 4-5 months ago. NEON_DESC should really become this: > > NEON_DESC=WebDAV/Delta-V access module + HTTPS/SSL support > > I want people reading this to remember olden days, because it seems > we've taken a step backwards when it comes to applying minimalistic > approaches and KISS principle. I want people to remember the days of > this command: > > pkg_add -r cvsup-without-gui > For most ports you can find the answer of dependency directly in the source. Example subversion: $> cd devel/subversion $> make extract $> less work/subversion-1.7.7/INSTALL Subversion also depends on the following third-party libraries: * SQLite (REQUIRED for client and server) * libz (REQUIRED for client and server) * libapr and libapr-util (REQUIRED for client and server) * libserf or libneon (OPTIONAL for client) ... Hope this helps for all your other dependency related questions. ___ 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" /subversion/ has crashed Xorg building here in an Xterm. From now on I'd probably only build it o/o X. Could the project create packages for it before putting up source so that portmaster etc. skips compiling ?? ... With the deprecation of csup, on this prima
/archivers/ is missing after svn...
As in the subject. Anyone else? r 307953 J. Bouquet ___ 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: /archivers/ is missing after svn...
--- On Wed, 11/28/12, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: /archivers/ is missing after svn... To: freebsd-ports@freebsd.org Date: Wednesday, November 28, 2012, 8:20 PM As in the subject. Anyone else? r 307953 UPDATE: OTOH I can svn it independently to elsewhere than ports, any canonical way to move that /tmp/archivers to /usr/ports/archivers ?? J. Bouquet ___ 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: /archivers/ is missing after svn...
--- On Wed, 11/28/12, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: Re: /archivers/ is missing after svn... To: freebsd-ports@freebsd.org Date: Wednesday, November 28, 2012, 8:28 PM --- On Wed, 11/28/12, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: /archivers/ is missing after svn... To: freebsd-ports@freebsd.org Date: Wednesday, November 28, 2012, 8:20 PM As in the subject. Anyone else? r 307953 UPDATE: OTOH I can svn it independently to elsewhere than ports, any canonical way to move that /tmp/archivers to /usr/ports/archivers ? DONE: moved that /tmp/archivers to /usr/ports/archivers, strangely I did not find its .svn after the move. So a port sees /usr/ports/archivers, but still fails to configure. I'll wait a while to see if that changes... Don't know enough about the port nor svn to figure out much more about it. ___ 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: /archivers/ is missing after svn...
--- On Thu, 11/29/12, Alexander Yerenkow wrote: From: Alexander Yerenkow Subject: Re: /archivers/ is missing after svn... To: "Jeffrey Bouquet" Cc: freebsd-ports@freebsd.org Date: Thursday, November 29, 2012, 4:54 AM Could you run svn status in /usr/ports ? -- Regards, Alexander Yerenkow ___ The only things that stand out are: ? x11-clocks ? archivers besides INDEX-9, etc. J. Bouquet ___ 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: /archivers/ is missing after svn...
--- On Thu, 11/29/12, Jeffrey Bouquet wrote:
From: Jeffrey Bouquet
Subject: Re: /archivers/ is missing after svn...
To: "Alexander Yerenkow" , freebsd-ports@freebsd.org
Date: Thursday, November 29, 2012, 5:09 AM
--- On Thu, 11/29/12, Alexander Yerenkow wrote:
From: Alexander Yerenkow
Subject: Re: /archivers/ is missing after svn...
To: "Jeffrey Bouquet"
Cc: freebsd-ports@freebsd.org
Date: Thursday, November 29, 2012, 4:54 AM
Could you run svn status in /usr/ports ?
--
Regards,
Alexander Yerenkow
___
The only things that stand out are:
? x11-clocks
? archivers
besides INDEX-9, etc.
UPDATED:
/shells/ has also gone missing. I'm wondering if the original svn of the
source tree missed those two somehow... or they disappeared during a
fsck_ffs -y command, or the cntl-c of a { svn ... --depth files }
which I had to unexpectedly end because it was taking longer than
several *hours*...
J. Bouquet
___
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: /archivers/ is missing after svn...
--- On Thu, 11/29/12, Warren Block wrote: From: Warren Block Subject: Re: /archivers/ is missing after svn... To: "Jeffrey Bouquet" Cc: freebsd-ports@freebsd.org Date: Thursday, November 29, 2012, 7:00 AM On Thu, 29 Nov 2012, Jeffrey Bouquet wrote: > UPDATE: > > OTOH I can svn it independently to elsewhere than ports, any canonical way > to move that /tmp/archivers to /usr/ports/archivers ? > > DONE: > moved that /tmp/archivers to /usr/ports/archivers, strangely I did not find > its > .svn after the move. Multiple partial checkouts is not the same as one big checkout. The .svn directory only exists in the base directory of the checkout. Back up /usr/ports (for local changes), delete the entire directory, then check out the entire directory. ___ Done. Unfortunately I forgot to relocate /packages/ and /distfiles/ first, so they have been restored from yesterday's backup. Also there is an INDEX-9.move_distfiles (zero length file) for the next time, as a reminder, as I'd move INDEX* out of the way first. ___ 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: vlc 2.0.5
--- On Fri, 12/21/12, Kevin Oberman wrote: From: Kevin Oberman Subject: Re: CFT: vlc 2.0.5 To: "Juergen Lock" Cc: freebsd-multime...@freebsd.org, "René Ladan" , freebsd-ports@freebsd.org Date: Friday, December 21, 2012, 6:53 PM On Thu, Dec 20, 2012 at 1:38 PM, Juergen Lock wrote: > On Thu, Dec 20, 2012 at 09:18:03PM +0100, René Ladan wrote: >> On 19-12-2012 22:44, Juergen Lock wrote: >> > Hi! >> > >> > It's this time again, there's a new vlc release out and I want to update >> > the port: >> > >> > http://people.freebsd.org/~nox/tmp/vlc-2.0.5-001.patch >> > >> > Everyone is invited to test this update and post any issues they find... >> > >> A quick test with an online mp3 stream works fine, but I do get this >> message in the console: >> >> VLC media player 2.0.5 Twoflower (revision 2.0.5-0-g1661b7d) >> >> Unable to load library icui18n "Cannot load library icui18n: (Shared >> object "libicui18n.so.48" not found, required by "vlc")" >> >> I have icu-50.1 installed, although the port does not seem to use it. >> So maybe it is triggered by some dependency. > > I don't get that here so yes it's probably a problem in a dependency. Sorry for those who have seen this in other threads. To find and fix these issues: Install sysutils/bsdadmonscripts (If you use pkgng, pleaqse be sure that you have the latest version!) # pkg_libchk -o | grep libicu | cut -f1 -d: | sort | uniq > somefile # portmaster -D `cat somefile` This will update all ports that are still linked to the old icu libraries. This should be a very short list as only a handful of ports link directly to these libraries. Many more depend on these ports, but don't directly link to libicu sharables and don't need re-building. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" This email prompted me to run the suggested tool, which found a great many ports linked against older libraries (yay!). So I thought I could diff that list against a list of the build-depends-list in the ports I've tried that don't build. Got a bit more experienced with awk, but ran out of time to craft a final solution in favor of one which takes much less time. To apply part of that procedure to this instance, perhaps run the X-dependent binary at the command line o/o X, and it will show directly which port or library might actually need rebuilding. Found a slew of ports (gnome) to rebuild (from pcre) that way, when they nominally might have been missed. (It also may prevent the rebuild of a binary which may still vaguely fail after is rebuild, but fixing directly the dependency may fix more than just the primary port, providing even greater direct fix(es). May or may not apply in this case, though (I've not vlc installed any longer). ___ 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: Upgrading ports problem with portupgrade(pkgng)
Sorry for the formatting. (The other webmail I could use is even more problematic). --- On Sun, 12/23/12, Beach Geek wrote: From: Beach Geek Subject: Re: Upgrading ports problem with portupgrade(pkgng) To: freebsd-ports@freebsd.org Date: Sunday, December 23, 2012, 1:05 PM On Dec 22, 2012 2:15 PM, "Beach Geek" wrote: > > System: FreeBSD/i386 10-current, base/head(src)=r244363, ports/head=r309344. > > I upgraded to r244363 from an Oct 3rd(ish) version. Followed ports/UPDATING for pkgng to edit make.conf and convert pkgdb.db. > > I'm now trying to update my ports (from tree, not pkgs), and I get: > > # portupgrade -ae > USING PKGNG > Stale dependency: ORBit2-2.14.19 --> glib-2.28.8_4 -- manually run 'pkgdb -F' to fix, or specify -O to force. > > # pkgdb -F USING PKGNG pkgdb -F not supported with PKGNG yet. Use 'pkg check' directly. > > # pkg check -d (also tried pkg check -d -a) > # > > Running portupgrade -ae gives same message as before. > > Went to port tree, upgraded glib with 'make deinstall reinstall clean'. Then > # pkg info glib glib-2.28.8_5 Some useful routines of C programming (current stable version) > > Run portupgrade -ae.. same message. > > Could someone point me in the right direction... > > If I'm misunderstanding the man & wiki pages, please explain (I'll even wear the pointyhat). > > Thanks, BG An update. 4 servers have the problem in my previous post, and I've yet to find a way to use portupgrade. Only answers I've received were to use packages via pkgng. (Not an option). For the other 9 servers, I tried it a little differently. - switch to pkgng - svn base and ports - upgrade base - upgrade ports with portupgrade. Worked fine for 8 of 9. Will be rolling the 5 broke servers back (yes, we have bkups) ;) Will leave the 8 working ones running pkgbg, and see how it goes. Still wondering, how to repair the database w/o pkgfb -F so portupgrade will work? And as I understand, poudriere must be used instead of portupgrade to create packages? Thanks, BG ___ 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" I would hope that pkgng not be the default before someone writes a huge flowchart pointing out all or most all of the here-to-there scenarios, for instance if one uses a -devel version of some /devel/ port suddenly, some packages break, for instance some machines run v8 some run v10, which ports won't be in the official build cluster and would commonly need to be built locally, and a slew of other issues which may be slowly added to the flowchart as the years go by, so that questions would be fewer all around. (Hoping also for a GEOM flowchart, a CUPS flowchart, ... but that is off topic for this email...) BTW I've a methodology to rapidly dispense with unknown-but-need-upgrading dependency upgrading (which just uncovered a slew of ports which won't build, most with a similar error) and it heavily relies upon the /var/db/pkg/ structure for ease of use. I also wish that an adjunct to the pkg(ng) include an option for that structure so that that ease of use is not abstracted in a yet unknown way. If this will all be minor issues vs actual implementation of a v10 default pkg system, I apologize in advance. (After all, most or all of the ports which won't currently build here I seldom if ever actually have time to use...) J. Bouquet ___ 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
Sorry for the formatting. Reply is below --- On Fri, 12/28/12, Gerald Pfeifer wrote: From: Gerald Pfeifer Subject: Re: lang/gcc46 To: "Brendan Fabeny" , "Baptiste Daroussin" Cc: freebsd-ports@freebsd.org, "Kevin Oberman" Date: Friday, December 28, 2012, 4:08 PM On Mon, 6 Aug 2012, b. f. wrote: > Oops: I forgot though, that partly due to this policy of not bumping > gcc shared library versions, we have some shared libraries in the base > system that conflict with the shared libraries of the various gcc > ports, and we have been enforcing the right links by inscribing hints > in the binaries to look first in the right gcc port directories. But > if we update lang/gcc from 4.6.x to another major version (e.g. > 4.7.x), the directory changes, and linking for the old binaries will > fail. So let me qualify my earlier answer: you can keep the old > software working with minimal intervention, for example, by adding a > symlink from the old directory to the new one. What we could do, for the canonical version of GCC (lang/gcc, USE_GCC=yes) is install those libraries into /usr/local/lib instead of /usr/local/lib/gccXY as we are doing for lang/gccXY. What do you think? >>> I had patches to do this even without pkgng, but it made things a >>> little more complicated, and didn't seem to be a high priority, so I >>> didn't pursue it. If people feel that it is important, I could work >>> with Gerald to revive that >> Making this change now would benefit a lot of people, now. > Okay, but since I'm not in charge either, it will require (at least) > Gerald's consent. That would be cool. Bapt wanted to look into this as well a few months ago, so perhaps the two of you can (should?) sync before proceeding? Gerald PS: I don't think we should go for the other option, static linking. ___ 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" ..not a reply but additional information, I hope it is not to off-topic to this post. While trying to install gcc46, it wanted gcc46 already installed for some reason. I had just deleted it "for" the install. I did a workaround of sorts... ___ 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"
Two errors each affecting several ports
First error: configure: error: the pkg-config script could not be found or is too old. Make sure it is in your PATH or set the PKG_CONFIG environment variable to the full path to pkg-config (affects ports such as shared-mime-info, esound...) Second error: /usr/local/bin/ld: main.o: undefined reference to symbol 'curses version' /usr/local/lib/libtinfow.so.6.0: could not read symbols: Invalid operation collect2: ld returned 1 exit status *** [mutt] Error code 1 ... Which affects several other ports (... mc, vitunes...) ... I tried rebuilding binutils to fix it/them, no difference. (BTW binutils needs several of its binaries (/usr/local/bin/ to configure/build/install, I fixed that temporarily by copying some of them elsewhere and back as "extra binaries" until reinstalled and overwritten...) ... Each of these three errors may be specific to some arcane setup here. Posting in the chance that others have fixed it/them and so it is more common problem(s). Thanks J. Bouquet ___ 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: Two errors each affecting several ports
Reply below. --- On Mon, 12/31/12, Kevin Oberman wrote: From: Kevin Oberman Subject: Re: Two errors each affecting several ports To: "Jeffrey Bouquet" Cc: freebsd-ports@freebsd.org Date: Monday, December 31, 2012, 3:37 PM On Mon, Dec 31, 2012 at 3:13 PM, Jeffrey Bouquet wrote: > First error: > configure: error: the pkg-config script could not be found or is too old. > Make sure it is in your PATH or set the PKG_CONFIG environment variable to > the full path to pkg-config > (affects ports such as shared-mime-info, esound...) pkg-config was replaced by pkgconf back in July. Check /usr/ports/UPDATING for the 20120726:entry. Either you didn't relace it or, more likely, you did not follow the instructions in UPDATING. > Second error: > /usr/local/bin/ld: main.o: undefined reference to symbol 'curses version' > /usr/local/lib/libtinfow.so.6.0: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > *** [mutt] Error code 1 > ... > Which affects several other ports (... mc, vitunes...) > ... > I tried rebuilding binutils to fix it/them, no difference. (BTW binutils > needs several > of its binaries (/usr/local/bin/ to configure/build/install, I fixed that > temporarily by > copying some of them elsewhere and back as "extra binaries" until reinstalled > and > overwritten...) > ... > Each of these three errors may be specific to some arcane setup here. > Posting in > the chance that others have fixed it/them and so it is more common problem(s). Yes, it appears that something specific to your environment is making ports unhappy, but I have no idea what. You don't say what version of FreeBSD or whether you have moved to pkgng or are still using the old pkg_* tools. Not that I am sure I would know what was going on with this information, but it would certainly help. The issue with binutils is especially odd. Could you state what "extra binaries" were a problem? It almost sounds like some sort of tool chain issue. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com 9-STABLE, (r243371); I am not yet pkgng; I've lots in /usr/local/lib/compat and some in /usr/local/lib/compat/pkg... the binaries binutils complains about are as, ar, and ranlib.; standard $PATH; I replaced pkg-config with pkgconf ages ago. (Almost wishing for a "wrapper port" that one wraps around a port build to point explicitly at which dependency causes an error, or if not, which parameter to ./configure or which patch file in /files/ or which line in the Makefile... almost like a dtrace/strace GUI-something... but specifically for port building.) ___ 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: portmanager-0.4.1_9
>--- On Thu, 1/10/13, Warren Block wrote: >> Is it gone forever? Is there a successor? >port*manager* is gone, portmaster and portupgrade are still available. BTW portmanager was excellent the for the first few years. One could begin an update, then cntl-c after a few minutes when it actually began building ports, and up in the terminal would be a concise list of what needed to be installed or upgraded. Later, its results were inaccurate (did not find installed ports...). It would serve many well if someone were to rewrite if for the present ports structure IMHO. (That was for just one of its usages that I used a lot, the others I was still using portupgrade or a custom .sh script, for those fifty percent or so of the time in which I did not simply permit portmanager to complete the task.) J. Bouquet ___ 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: reinstalling port - long pkg create run times
--- On Mon, 1/14/13, Anton Shterenlikht wrote: >Subject: reinstalling port - long pkg create run times >This seems too long: > PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU >COMMAND >5861 root 1 101 0 162M 32800K RUN 38:06 91.70% pkg >96440 0 I+ 0:00.15 | `-- /bin/sh /usr/local/sbin/portmaster >ghost teTeX >Are such long run times to be expected on this box >on pkg create? >Thanks >Anton I've a pentium 3 CPU that cannot build/install (usually) ruby19 and/or python27 due to either a long build time or a process running out of memory. Does anyone know the CPU/Memory below which pkgng may cease to create packages easily for some of the larger ports, it such should prove to be the case? In which case, it should maybe be made into a FAQ before pkgng becomes the default for the current STABLE version/release... J. Bouquet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster -w -r (pcre & icu): how to avoid redundant rebuilding?
Reply is at the bottom... --- On Wed, 1/23/13, Kevin Oberman wrote: From: Kevin Oberman Subject: Re: portmaster -w -r (pcre & icu): how to avoid redundant rebuilding? To: "Thomas Mueller" Cc: "Joseph A. Nagy, Jr" , freebsd-ports@freebsd.org Date: Wednesday, January 23, 2013, 6:04 PM On Wed, Jan 23, 2013 at 3:58 AM, Thomas Mueller wrote: > >> On 01/22/13 06:26, Thomas Mueller wrote: >> >I see in the UPDATING file that I need to rebuild all ports that depend on >> >pcre and icu: > >> >portmaster -w -r pcre >> >and >> >portmaster -w -r icu >> >(I don't need -f ?) > >> >How do I do this without rebuilding the same ports twice? > >> >I am on pkgng, so I can use >> >pkg info -r icu >> >and same for pcre to list ports depending on icu and pcre (long lists). > >> >I just updated, from source, to: > > >> >FreeBSD amelia2 9.1-STABLE FreeBSD 9.1-STABLE #14 r245542: Tue Jan 22 >> >03:00:31 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 > >> >Tom > >> I've not had any luck with avoiding redundant rebuilding as pcre and icu >> updates aren't sent out at the same time. Perhaps someone can say if I'm >> off my rocker, has anyone tried issuing 'portmaster -w -r icu pcre'? >> Perhaps that would avoid the redundant rebuilds? > >> Of course that would only work if one waits for both updates to come out. > >> -- >> Yours in Christ, > >> Joseph A Nagy Jr > > I could possibly make lists of ports that depend on pcre and icu using > > pkg info -r icu (and also pcre, redirecting to files) > > Then I could try > portmaster -w -r icu -r pcre > or do I need to use -w twice? > > Then I could see what ports it would build, say n when asked if I wanted to > rebuild those ports, assuming there would be config dialogs along the line. > > Then I would run the portmaster command again with |& tee portm.log at the > right end, see if I like what would be built before answering y. > > I would be able to login to another virtual terminal to examine portm.log > file at the early stage when asked whether to rebuild the ports >My standard answer (and huge time-saver) is to install sysutils/bsdasminscripts and do the following. This example is for pcre and icu >% pkg_libchk -o | grep -E "libpcre|libicu" | cut -d: -f1 | sort | uniq > pcre-updates.txt % portmaster `cat pcre-updates.txt` >This will only update any port once and will only update ports that really need it. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" If you'd rather put off most of the rebuilds until they bump anyway, simply maybe run the ports you want to use in the interim out of X, say an editor (gtk2) run without X may show only one of its dependencies need actual rebuilding. Not recommended as a general procedure for most systems maybe, but something to keep in mind... it shows in some instances more information than simply ldd'ing the binary, resulting in less downtime of the desktop or whatever. J. Bouquet ___ 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"
Build log attached... fail to build deskutils/clipit
I'd not be too concerned, but this same error is manifested in at least ten or so ports that refuse to build here... consistently month after month. J. Bouquet (PS. this may be a followup to the earlier post maybe last month with the same error or it and another, in which case it is a duplicate of sorts...) ___ 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: Build log attached... fail to build deskutils/clipit
Resent with the attachment which apparently did not attach, pasted below it (courtesy of xfw...) . Sorry for the duplicate. --- On Fri, 1/25/13, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: Build log attached... fail to build deskutils/clipit To: freebsd-ports@freebsd.org Date: Friday, January 25, 2013, 5:20 AM I'd not be too concerned, but this same error is manifested in at least ten or so ports that refuse to build here... consistently month after month. J. Bouquet (PS. this may be a followup to the earlier post maybe last month with the same error or it and another, in which case it is a duplicate of sorts...) -Inline Attachment Follows- Script started on Fri Jan 25 04:42:19 2013 make build ===> Found saved configuration for clipit-1.4.2 ===> Extracting for clipit-1.4.2 => SHA256 Checksum OK for clipit-1.4.2.tar.gz. ===> Patching for clipit-1.4.2 ===> clipit-1.4.2 depends on executable: gmake - found ===> clipit-1.4.2 depends on executable: gcc46 - found ===> clipit-1.4.2 depends on file: /usr/local/bin/as - found ===> clipit-1.4.2 depends on file: /usr/local/bin/intltool-extract - found ===> clipit-1.4.2 depends on executable: pkgconf - found ===> clipit-1.4.2 depends on executable: gtk-update-icon-cache - found ===> clipit-1.4.2 depends on file: /usr/local/bin/ccache - found ===> clipit-1.4.2 depends on shared library: intl - found ===> clipit-1.4.2 depends on shared library: atk-1.0.0 - found ===> clipit-1.4.2 depends on shared library: gdk_pixbuf-2.0.0 - found ===> clipit-1.4.2 depends on shared library: glib-2.0.0 - found ===> clipit-1.4.2 depends on shared library: gtk-x11-2.0.0 - found ===> clipit-1.4.2 depends on shared library: pango-1.0.0 - found ===> Configuring for clipit-1.4.2 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking for style of include used by gmake... GNU checking for gcc... gcc46 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc46 accepts -g... yes checking for gcc46 option to accept ISO C89... none needed checking dependency style of gcc46... gcc3 checking how to run the C preprocessor... cpp46 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... no checking for bindtextdomain in -lintl... yes checking for ngettext in -lintl... yes checking for dgettext in -lintl... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/local/bin/msgfmt checking for dcgettext... yes checking if msgfmt accepts -c... yes checking for gmsgfmt... /usr/local/bin/msgfmt checking for xgettext... /usr/local/bin/xgettext checking for catalogs to be installed... cs da de es es_ES et fr hu it ja nb pl pl pt_BR ro ru sv tr zh_CN checking whether NLS is requested... yes checking for intltool >= 0.23... 0.41.1 found checking for intltool-update... /usr/local/bin/intltool-update checking for intltool-merge... /usr/local/bin/intltool-merge checking for intltool-extract... /usr/local/bin/intltool-extract checking for xgettext... (cached) /usr/local/bin/xgettext checking for msgmerge... /usr/local/bin/msgmerge checking for msgfmt... (cached) /usr/local/bin/msgfmt checking for gmsgfmt... (cached) /usr/local/bin/msgfmt checking for perl... /usr/bin/perl checking for perl >= 5.8.1... 5.12.4 checking for XML::Parser... ok checking for msgfmt... (cached) /usr/local/bin/msgfmt checking for gmsgfmt... (cached) /usr/local/bin/msgfmt checking for xgettext... (cached) /usr/local/bin/xgettext checking for msgmerge... (cached) /usr/local/bin/msgmerge checking build system type... i386-portbld-freebsd9.1 checking host system type... i386-portbld-freebsd9.1 checking for ld used by GCC... /usr/local/bin/ld checking if the linker (/usr/local/bin/ld) is GNU ld... yes checking for shared library run path origin...
Re: Build log attached... fail to build deskutils/clipit
BTW the same error occured not three minutes ago with /zathura/ ... 9.1-PRERELEASE r243371 /bin:... ... :/usr/local/clip/bin gettext-0.18.1.1 ncurses-devel-5.9.20110507_1 pkgconf-0.8.9 zsh 5.x /usr/local/lib/compat/pkg has an older libintl.so.6 for some reason... vs. the current so.9 --- On Fri, 1/25/13, Jason Helfman wrote: From: Jason Helfman Subject: Re: Build log attached... fail to build deskutils/clipit To: "Jeffrey Bouquet" Cc: "FreeBSD Ports List" Date: Friday, January 25, 2013, 1:15 PM On Fri, Jan 25, 2013 at 10:50 AM, Jeffrey Bouquet wrote: > Resent with the attachment which apparently did not attach, pasted below > it (courtesy of xfw...) . Sorry for the duplicate. > > --- On Fri, 1/25/13, Jeffrey Bouquet wrote: > > From: Jeffrey Bouquet > Subject: Build log attached... fail to build deskutils/clipit > To: freebsd-ports@freebsd.org > Date: Friday, January 25, 2013, 5:20 AM > > I'd not be too concerned, but this same error is manifested in at least > ten or so ports that refuse to build here... consistently month after month. > > J. Bouquet > > (PS. this may be a followup to the earlier post maybe last month with the > same error or it and another, in which case it is a duplicate of sorts...) > > 2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lm -lgobject-2.0 -lgthread-2.0 > -lgmodule-2.0 -pthread -lglib-2.0 -lfreetype -L/usr/local/lib > -lfontconfig -lX11 > /usr/local/bin/ld: main.o: undefined reference to symbol > 'libintl_bindtextdomain' > /usr/local/bin/ld: note: 'libintl_bindtextdomain' is defined in DSO > //usr/local/lib/libintl.so.9 so try adding it to the linker command line > //usr/local/lib/libintl.so.9: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > gmake[2]: *** [clipit] Error 1 > gmake[2]: Leaving directory > `/usr/ports/deskutils/clipit/work/clipit-1.4.2/src' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/usr/ports/deskutils/clipit/work/clipit-1.4.2' > gmake: *** [all] Error 2 > *** [do-build] Error code 1 > > Stop in /usr/ports/deskutils/clipit. > *** [build] Error code 1 > > Stop in /usr/ports/deskutils/clipit. > > Script done on Fri Jan 25 04:42:35 2013 > > ___ > 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" > >I committed this, and tested on CURRENT, 8.3, 9.0, and 9.1 for amd64, and >i386 respectively. I didn't see this error on any of these builds. >Can you please list some more details of your system, and setup. >Thanks! >-jgh .. _ J Bouquet ___ 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: Cronjob Cvsup -> What?
.. >Thomas Mueller wrote:> I've always used "portsnap fetch update" after the >initial "portsnap> fetch" and "portsnap extract". What would be the adverse >side effect> of using svn instead?In general it's best to avoid mixing update >tools unless you fullyunderstand all the corner cases and know it's safe. The >most significant problem is they can lose track of what filesneed to be >deleted, which can lead to obsolete patch files being leftin the tree. One of >the functions of "portsnap extract" is to eliminateextra files in port >directories to avoid this >problem. . Svn has a a few drawbacks vs csup (space required, longer backups without - .svn # or equiv in an exclude file, maybe others...) however it may be more advantageous if one understands its use cases and the consequences of each one. Someone would someday maybe be resourceful enough to write one up and post it somewhere in a flowchart... (the "revert" "up" "svnweb" script -a a.log svn up /usr/ports (the intitial creation of it with the long CLI in the forum...) # port # svn revert Makefile # port # svn -R revert . # svn up /usr/ports/multimedia/mplayerxp etc etc... As a newbie, those are all I know so far . And one can use workarounds if a disk is short on space, mount -t ufs -o union(fs) /dev/da0 /usr and even svn -up /usr/ports # after it mounts correctly ... to update the thumbdrive before port updates on the low-disk-space machine. (that is the procedure as I recollect it anyway. Something could be slightly different.) (if /ports in on the thumbdrive) (that syntax is probably correct, but I am at another CPU and cannot check it right away.) J. Bouquet (Sorry for the post formatting and any typos...) ___ 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: Updating ports with portmaster after two month "vacation"
Probably will follow someone else with the same reply but even more informative than this one... reply is at the bottom. Sorry for the formatting... --- On Mon, 1/28/13, Edwin L. Culp W. wrote: From: Edwin L. Culp W. Subject: Updating ports with portmaster after two month "vacation" To: "freebsd-ports" Date: Monday, January 28, 2013, 10:56 AM I have not updated all my ports since the end of Noviember. I am still using cvsup to update the machine daily and have, what I hope is, an uptodate kernel and all programes. # uname -a FreeBSD home.encontacto.net 9.1-STABLE FreeBSD 9.1-STABLE #391 r229960M: Sat Jan 26 05:06:18 CST 2013 r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO amd64 The first strange thing that I notice is: # portversion -v portmaster [Updating the pkgdb in /var/db/pkg ... USING PKGNG - 959 packages found (-2 +3) (...)... done] USING PKGNG portmaster-3.14_8 > succeeds port (port has 3.11) The last thing I remember doing era updating ports to PKGNG and that could be my problem. If so, I have no idea how to reconstruct and I'm also not sure that cvsup is still working as before. The kernel seems to work fine. Another error message that I find unusual and can't explain is: # portmaster -a ===>>> Gathering distinfo list for installed ports ===>>> Starting check of installed ports for available updates ===>>> The ports-mgmt/portmanager port has been deleted: Has expired: Does not support modern ports features such as MOVED, is lacking upstream and active contributions, and does not support pkgng. Consider using ports-mgmt/portmaster, ports-mgmt/portupgrade or pkgng ===>>> Aborting update I can't understand the relationship to portupgrade. I'm sure that I missed something very important since portmaster is trying to use portupgrade. Thanks for any help. ed -- Bienes Raíces in Coatepec, Veracruz, Mexico http://www.facebook.com/pages/Inmobiliaria-Bienes-Raices-httpEcoManiainfo/102249989850215?sk=photos_albums ___ 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 message about portmanager > portupgrade is not "using" it AFAIK. Portmanager may still work unless you remove it or permit portmaster to do so. AFAIK csup/cvsup will no longer work to upgrade ports, I switched all CPU over to svn (devel/subversion) awhile back and have posted in the forum informative posts. As to svn for the kernel sources, the freebsd-questions list this month (jan/enero 2013) has a detailed howto also in that regard. I would hesitate to use portmaster -a... portmaster -L --index-only | tee -a /tmp/upgrade.log wait a while... grep -A 3 -B 3 version /tmp/upgrade.log | tee -a /tmp/upgrade2.log in one xterm "head -10 /tmp/upgrade2.log | tail -12 .."head -20 /tmp/upgrade2.log | tail -12 ..."head -30 /tmp/upgrade2.log | tail -12 then in another xterm... portmaster -d -B -P -i -g devel/doxygen devel/cmake # etc as shown in each segment of the latter file from the pipes. Sorry for any typos or incomplete information or inaccuracies or easier ways others may currently do it, especially if one has lesser than thousands of ports installed. J. Bouquet ___ 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: libffi update: #error "Qt has not been ported to this architecture"
Message relevant to libffi but not QT below... --- On Tue, 1/29/13, David Wolfskill wrote: From: David Wolfskill Subject: libffi update: #error "Qt has not been ported to this architecture" To: freebsd-ports@freebsd.org Date: Tuesday, January 29, 2013, 5:56 AM This is running: FreeBSD g1-227.catwhisker.org 9.1-STABLE FreeBSD 9.1-STABLE #359 r246049M/246068: Tue Jan 29 04:55:12 PST 2013 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 with a ports tree at r311159. I use portmaster, so per UPDATING, I issued: portmaster -w -r libffi portmaster reported (near the end): ===>>> The following actions were performed: Upgrade of libffi-3.0.9 to libffi-3.0.11 Re-installation of gobject-introspection-0.10.8_3 Re-installation of pango-1.28.4_1 Re-installation of gtk-update-icon-cache-2.24.6_1 Re-installation of gtk-2.24.6_2 Re-installation of ghostscript9-9.06_1 Re-installation of GraphicsMagick-1.1.15_5,1 Re-installation of libglade2-2.6.4_5 Re-installation of gstreamer-0.10.36 Re-installation of gstreamer-plugins-0.10.36_2,3 Here's the list of activities portmaster expected: ===>>> The following actions will be taken if you choose to proceed: Upgrade libffi-3.0.9 to libffi-3.0.11 Re-install GraphicsMagick-1.1.15_5,1 Re-install ghostscript9-9.06_1 Re-install gtk-2.24.6_2 Re-install gobject-introspection-0.10.8_3 Re-install gtk-update-icon-cache-2.24.6_1 Re-install pango-1.28.4_1 Re-install ImageMagick-6.8.0.7_1 Re-install graphviz-2.30.0 Re-install libglade2-2.6.4_5 Re-install qt4-linguist-4.8.2 Re-install qt4-assistant-4.8.2 Re-install qt4-webkit-4.8.2 Re-install gstreamer-plugins-0.10.36_2,3 Re-install gstreamer-0.10.36 Re-install qt4-designer-4.8.2 Re-install gtkglarea-2.0.1_3 Re-install gtkglext-1.2.0_10 Re-install librsvg2-2.34.1_1 Re-install libgsf-1.14.21_1 Re-install gconf2-2.32.0_3 Re-install dconf-0.5.1_4 Re-install polkit-0.99 Re-install gtk-engines2-2.20.2_1 Re-install R-2.15.2 Re-install abiword-2.8.4_2 Re-install goffice-0.8.17_3 Re-install wv-1.2.9_1 Re-install bombono-1.2.1_3 Re-install gtkmm-2.24.2_1 Re-install pangomm-2.28.2_1 Re-install cm-super-0.3.4_4 Re-install teTeX-base-3.0_23 Re-install consolekit-0.4.3 Re-install dvdauthor-0.7.1 Re-install dvipsk-tetex-5.95a_6 Re-install firefox-18.0.1,1 Re-install gegl-0.1.8_6 Re-install libopenraw-0.0.8_4 Re-install ghostview-1.5_3 Re-install gimp-2.6.12,2 Re-install gimp-app-2.6.12_1,1 Re-install webkit-gtk2-1.4.3_2 Re-install py27-gimp-app-2.6.12_1 Re-install py27-gobject-2.28.6_1 Re-install py27-gtk-2.24.0_1 Re-install gnumeric-1.10.17_1 Re-install gnupg-2.0.19_3 Re-install pinentry-0.8.1_2 Re-install gtk-3.0.12_2 Re-install gtkspell-2.0.16_4 Re-install gv-3.7.3_1 Re-install hal-0.5.14_20 Re-install icedtea-web-1.3.1 Re-install libxul-10.0.12 Re-install inkscape-0.48.2_3 Re-install libwpg-0.2.1_2 Re-install libwpd-0.9.4_1 Re-install libcanberra-0.28_3 Re-install libcanberra-gtk3-0.28_3 Re-install libnotify-0.7.3_2 Re-install mplayer-1.1.r20120721_2 Re-install mtr-0.82_1 Re-install notification-daemon-0.7.2_1 Re-install nspluginwrapper-1.4.4 Re-install nvidia-driver-304.64 Re-install xorg-server-1.7.7_6,1 Re-install nvidia-settings-310.14 Re-install rrdtool-1.4.7_2 Re-install teTeX-3.0_6 Re-install xdvik-tetex-22.84.16_4 Re-install ted-2.22_2 Re-install transcode-1.1.7_8 Re-install transfig-3.2.5d_1 Re-install w3m-0.5.3_1 Re-install wifimgr-1.10_1 Re-install wireshark-1.8.4_1 Re-install xchat-2.8.8_1 Re-install xf86-input-keyboard-1.6.1 Re-install xf86-input-mouse-1.7.1_1 Re-install xf86-video-ati-6.14.3_1 Re-install xf86-video-intel-2.7.1_4 Re-install xf86-video-mach64-6.9.0 Re-install xf86-video-nv-2.1.18_1 Re-install xf86-video-openchrome-0.2.904_3 Re-install xf86-video-r128-6.8.1_3 Re-install xf86-video-radeonhd-1.3.0_5 Re-install xf86-video-vesa-2.3.0_2 Re-install xfig-3.2.5b_1 Re-install xmlto-0.0.25 Re-install xorg-7.5.2 Re-install xorg-drivers-7.5.2 Re-install xorg-nestserver-1.7.7_1,1 ===>>> Proceed? y/n [y] and here's the last part of the attempted rebuild (failing in www/qt4-webkit): ... g++ -c -O2 -pipe -fno-strict-aliasing -I../../../../include/Qt -I../../../../include -Wall -Wextra -Wreturn-type
Re: postgresql-84 upgrade
--- On Sat, 2/9/13, Chris Rees wrote: From: Chris Rees Subject: Re: postgresql-84 upgrade To: "Jeffrey Bouquet" Cc: "pg...@freebsd.org" Date: Saturday, February 9, 2013, 9:01 AM On 9 February 2013 16:12, Jeffrey Bouquet wrote: Year after year, here, if /usr/local/bin/grep exits, the configuration of most or all postgresql84-* ports halts forever at... checking for ranlib... ranlib checking for strip... strip checking whether it is possible to strip libraries.. forever. Works fine if one termporarily moves /usr/local/bin/grep to, say, /usr. >>What if you run: >>: | /usr/local/bin/grep "This should simply return" >>? >>Chris .. It simply returns. ___ 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: postgresql-84 upgrade
--- On Sun, 2/10/13, Palle Girgensohn wrote: From: Palle Girgensohn Subject: Re: postgresql-84 upgrade To: "Chris Rees" Cc: "Jeffrey Bouquet" , "pg...@freebsd.org" Date: Sunday, February 10, 2013, 5:01 AM 9 feb 2013 kl. 18:01 skrev Chris Rees : On 9 February 2013 16:12, Jeffrey Bouquet wrote: Year after year, here, if /usr/local/bin/grep exits, the configuration of most or all postgresql84-* ports halts forever at... checking for ranlib... ranlib checking for strip... strip checking whether it is possible to strip libraries.. forever. Works fine if one termporarily moves /usr/local/bin/grep to, say, /usr. >>What if you run: >> : | /usr/local/bin/grep "This should simply return" ? >>Chris >Seems to me you have /usr/local/bin before /usr/bin in your path? I wouldn't >>recommend that. Even so, seems strange that it would fail either way. Is this >>gnu grep? bsd grep 2.5.1-FreeBSD /usr/local/bin is after /usr/bin in $PATH... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there an easy way to find out which port loads which library?
--- On Sun, 2/17/13, A.J. 'Fonz' van Werven wrote: >From: A.J. 'Fonz' van Werven >Subject: Re: Is there an easy way to find out which port loads which library? >To: "Bernard Higonnet" >Cc: freebsd-ports@freebsd.org >Date: Sunday, February 17, 2013, 9:21 AM >Bernard Higonnet wrote: > Is there a simple, direct, complete, and unequivocal way to find out > which port(s) install which libraries? >Something like this perhaps? ># grep libfoobar.so /usr/ports/*/*/pkg-plist >AvW None of these replies mention pkg which /usr/local/lib/libfoobar.so pkg_which /usr/local/lib/libfoobar.so ... I typically use one or both (still using /var/db/pkg after running pkg2ng once a long time ago...) J. Bouquet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there an easy way to find out which port loads which library?
--- On Sun, 2/17/13, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: Re: Is there an easy way to find out which port loads which library? To: freebsd-ports@freebsd.org Date: Sunday, February 17, 2013, 9:31 PM --- On Sun, 2/17/13, A.J. 'Fonz' van Werven wrote: >From: A.J. 'Fonz' van Werven >Subject: Re: Is there an easy way to find out which port loads which library? >To: "Bernard Higonnet" >Cc: freebsd-ports@freebsd.org >Date: Sunday, February 17, 2013, 9:21 AM >Bernard Higonnet wrote: > Is there a simple, direct, complete, and unequivocal way to find out > which port(s) install which libraries? >Something like this perhaps? ># grep libfoobar.so /usr/ports/*/*/pkg-plist >AvW None of these replies mention [1] pkg which /usr/local/lib/libfoobar.so pkg_which /usr/local/lib/libfoobar.so ... I typically use one or both (still using /var/db/pkg after running pkg2ng once a long time ago...) J. Bouquet [1] of course, the one next in the webmail queue did... which always reads sort of backwards (newest first)... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Is there an easy way to find out which port loads which library?
--- On Mon, 2/18/13, Chris Rees wrote: From: Chris Rees Subject: Re: Is there an easy way to find out which port loads which library? To: "Jeffrey Bouquet" Cc: "FreeBSD Mailing List" Date: Monday, February 18, 2013, 1:01 AM On 18 Feb 2013 05:35, "Jeffrey Bouquet" wrote: > > > > > >Subject: Re: Is there an easy way to find out which port loads which library? > > >Bernard Higonnet wrote: > > > Is there a simple, direct, complete, and unequivocal way to find out > > which port(s) install which libraries? > > >Something like this perhaps? > ># grep libfoobar.so /usr/ports/*/*/pkg-plist > > >AvW > > None of these replies mention > pkg which /usr/local/lib/libfoobar.so > pkg_which /usr/local/lib/libfoobar.so > ... > I typically use one or both (still using /var/db/pkg after running pkg2ng once a > long time ago...) >Why??? >Chris Unsure of the question. Why did I run pkg2ng? I was uncognizant of all the immediate consequences. Why did I revert? Not ready to make /var/db/pkg disappear until I've seen guides explaining the new usages which fit the present workflow here... Why do not I implement it at this time? I've still too much to do in the short term on a daily basis vs. implement anything new until I am one of the *last* to do so, so I would do it in the quickest and most expedient manner. pkg_delete -f /var/db/pkg/rubygem-mime-types-1.19 && pkg_add rubygem-mime-types-1.21.tbz. I don't have to know the 1.19 (the shell does). I do not recall anyone mentioning how the equivalent would work in a pkg system. They may have, but if it was a reply, I archived it somewhere, as I would prefer to switch all the machines I use weekly all at once, and prefer to wait as long as expedient. That works on legacy laptops as well as modern 4-core CPU, aided by the shell doing expansion, and I can type it without thinking, aided by the shell. The subdirectory is directly available to grep, awk, less... without an .so. I've not yet had time to implement a /var/db/pkg/ on a machine running pkg (by script maybe) so that it could continue. I've posted several times why the progress of /pkg/ has not been shown to [1] not slow down the workflow to which I am accustomed to upgrade multiple machines has not been reliably demonstrated... and edge cases in which the legacy method is preferable. Unfortunately, I ran out of time a long time ago to respond more in depth; my views on the matter are scattered in the lists archives and forum archives [further content redacted so as to not waste anyone's time.] J. Bouquet [1] I am not asking for anyone's efforts, nor trying to sound negative; just trying to respond to the question with a wait-and-see viewpoint... ___ 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"
Was: Status of math/gnumeric [req] coincide with another (png) maybe...
--- On Sat, 2/23/13, Koop Mast wrote: From: Koop Mast Subject: Re: Status of math/gnumeric unable to keep up with upstream releases? To: "Thomas Mueller" Cc: gn...@freebsd.org, freebsd-ports@freebsd.org Date: Saturday, February 23, 2013, 1:39 AM On 22-2-2013 21:35, Thomas Mueller wrote: > What is the status of gnumeric being stuck at 1.10.17 when upstream has > released 1.12.0 ? > > I think gnumeric >= 1.11.x has gtk+ >= 3.0.0 as a dependency? I checked > gnumeric web site www.gnumeric.org . > > I see this is the same snag that prevents transmission > 2.5 from building, > though possibly one could do > > portmaster -o transmission-cli transmission ? > > So what is the status now of gtk+ 3.x ? > > > Tom >I'm working on a update for glib20 and gtk+2 and gtk+3. gnumeric is on the list of ports to update afterwards. What I know of transmission is that only transmission-gtk is currently broken because it wants a newer >>gtk+3 version then we got in ports. >>-Koop ___ ... Could both glib20/gtk20 *and* png be delayed until both are ready, so persons could upgrade ports depending upon both simultaneously? (If the latter is a shared library bump anyway...) J. Bouquet ___ 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: Share /var/cache/pkg/ between machines
Just to add a 'something else', unsure how fully it may suffice... [details at the bottom] --- On Mon, 2/25/13, Aristedes Maniatis wrote: From: Aristedes Maniatis Subject: Share /var/cache/pkg/ between machines To: freebsd-ports@freebsd.org Date: Monday, February 25, 2013, 6:57 PM I'd like to share packages between a couple of nearly identical machines in a server farm. I think I have the following options: 1. Set up apache httpd on one primary machine to serve the packages to the others by pointing website root to to /var/cache/pkg/ and setting PACKAGESITE in the other servers. This looks like it might work except that repo.txz is missing from /var/cache/pkg/ 2. rsync /var/cache/pkg/ from the primary machine to the others. Set PACKAGESITE on all machines to point to some central repository where all these packages originally were built (we run poudriere in another location). 3. Something else How do other people cache/proxy built packages under pkgng? I don't want to <>-- --> >>Aristedes Maniatis portmaster? [Cannot directly answer the post question, but...] If you put /portmatster-download/ on /da0 (a thumbdrive) mount -t unionfs /dev/da0 /usr/ports/packages... then the thumbdrive packages will appear to be already downloaded to portmaster, for migrating between machines. [I set up an ftp server for similar functionality, but find this method quicker and reconfigurable. YMMV of course depending upon the number/physical placment of your servers] Sorry to not answer about /pkg/, not fully implemented on most machines, here. [portmaster -d -B -P -i -g category/port category/port... or scripted equivalent in pkg or shell syntax.] I've seen it handily upgrade thirty p5 ports at a stretch using a pipe... just because a thumbdrive was in place, where otherwise it would mean duplicate builds etc. J. Bouquet ___ 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/audacity still does not compile due to issues with soundtouch
--- On Mon, 3/4/13, Joseph A. Nagy, Jr wrote: >having issues with Audacity trying to compile in soundtouch plugins. Is this >an issue with the port (there is no config option to disable this behavior) or >is it an upstream issue? >-- Yours in Christ, >Joseph A Nagy Jr FWIW soundtouch has not built here for quite a while... ___ 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: texlive ports
Maybe off topic to this thread, but... [ reply at bottom] --- On Wed, 2/27/13, Anton Shterenlikht wrote: From: Anton Shterenlikht Subject: Re: CFT: texlive ports Date: Wed, 27 Feb 2013 07:41:41 +0900 (JST) To: po...@freebsd.org Subject: CFT: texlive ports From: Hiroki Sato Please try to install print/texlive-full. The total size of the On ia64 -current I got to: gmake[3]: Entering directory `/usr/ports/print/luatex/work/texlive-20120701-source/texk/web2c' creating link 'texlua' -> 'luatex' creating link 'texluac' -> 'luatex' gmake[3]: Leaving directory `/usr/ports/print/luatex/work/texlive-20120701-source/texk/web2c' gmake[2]: Leaving directory `/usr/ports/print/luatex/work/texlive-20120701-source/texk/web2c' gmake[1]: Leaving directory `/usr/ports/print/luatex/work/texlive-20120701-source/texk/web2c' for D in /usr/local/share/texmf /usr/local/share/texmf-dist /usr/local/share/texmf-local /usr/local/share/texmf-var; do if [ -r $D/ls-R ]; then /usr/local/bin/mktexlsr $D; fi; done *** [do-fmtutil-luatex] Error code 1 Stop in /usr/ports/print/luatex. *** [build-depends] Error code 1 Stop in /usr/ports/print/texlive-full. ># >Anton One of the three recent teTeX ports [that had minor version bumps] would not install without /usr/local/bin/grep being temporarily moved to use instead the one from base... it apparently stalled with a high CPU usage. ___ 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: texlive ports
Date: Tuesday, March 5, 2013, 12:32 AM Date: Mon, 4 Mar 2013 21:00:08 -0800 (PST) From: Jeffrey Bouquet Subject: Re: CFT: texlive ports To: freebsd-ports@freebsd.org One of the three recent teTeX ports [that had minor version bumps] would not install without /usr/local/bin/grep being temporarily moved to use instead the one from base... it apparently stalled with a high CPU usage. Are you talking about ia64 specifically? Anyway, I don't think so: TZAV> pkg version -vX teT teTeX-3.0_7 = up-to-date with port teTeX-base-3.0_24 = up-to-date with port teTeX-texmf-3.0_9 = up-to-date with port TZAV> >Updated just fine with portmaster, with no manual intervention. >Anton It was sort of off-topic, more pertaining to grep (which also here halts the configure of postgresql84-server, and has, for years, the subject of a recent email to this list...) The port installed once I removed the forever-cpu-spiking grep binary so it could use the base one. ___ 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: texlive ports
No, sorry... but it was teTex-base... I could probably reproduce it on another machine if needed, which also has the same move-grep instances. Sorry for the webmail formatting of the remainder of this message.. --- On Mon, 3/4/13, Hiroki Sato wrote: Date: Monday, March 4, 2013, 9:07 PM je> Maybe off topic to this thread, but... [ reply at bottom]...je> One of the three recent teTeX ports [that had minor version bumps] would notje> install without /usr/local/bin/grep being temporarily moved to use instead theje> one from base... it apparently stalled with a high CPU usage.Do you have a log when the installation failed?-- ___ 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_add persistent error...
#pkg_add codelite-5.0.6213.tbz
pkg_add: corrupted record for package codelite-5.0.6213 (...), ignoring
pkg_add: leave_playpen: can't chdir back to ''
This error randomly occurs on a tenth of programs (usually gnome, sometimes
p5-) that I transfer from machine to machine (same installworld...) via
thumbdrive. Not usually a big problem, but some ports (codelite for instance)
then need an additional many minutes or hours of building *again*.
...
I posted the question on the forums a while back, but no one knew.
...
2nd subject...
Should the freebsd forums have subsections (lang, x11...)
/lang/
[bug] how to choose perl threaded
[hint] python for numeric CLI computations
[fix] {some port...} builds with gcc not clang...
/x11/
[fix] yad built with...
... etc etc.
Not only is this a feature they'd be hard put to put to use in other
operating systems, but it may lessen the backlog of PR's if maintainers, say,
check new posts and fix it locally without the need for PR's, essentially
having a bit more streamlining, at the cost of de-standardization of a sort.
J. Bouquet
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/177677: /usr/local/bin/grep halts databases/postgresql84-server configuration
--- On Wed, 4/10/13, cr...@freebsd.org wrote: From: cr...@freebsd.org Subject: Re: ports/177677: /usr/local/bin/grep halts databases/postgresql84-server configuration To: jeffreybouq...@yahoo.com, cr...@freebsd.org, pg...@freebsd.org Date: Wednesday, April 10, 2013, 1:32 AM Synopsis: /usr/local/bin/grep halts databases/postgresql84-server configuration State-Changed-From-To: open->feedback State-Changed-By: crees State-Changed-When: Wed Apr 10 08:32:15 UTC 2013 State-Changed-Why: Please reply to my email regarding this; http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081313.html http://www.freebsd.org/cgi/query-pr.cgi?pr=177677 Output at terminal with Cntl-T: load: 0.49 cmd: grep 2644 [running] 13.59r 13.51u 0.00s 72% 1768k load: 0.57 cmd: grep 2644 [running] 23.44r 23.32u 0.00s 96% 1768k etc... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ports/177677: /usr/local/bin/grep halts databases/postgresql84-server configuration
. . --- On Wed, 4/10/13, olli hauer wrote: From: olli hauer Subject: Re: ports/177677: /usr/local/bin/grep halts databases/postgresql84-server configuration Please test without bsdgrep. Meanwhile I have reports from users several users that portbuild (for example apache22/24) is broken with bsdgrep. . . The ports that are fixed (here) by moving the bsd-grep binary temporarily to where it is not in the path: postgresql84-server configure; [also postgresql-docs postgresql-contrib, one or both, but not postgresql84-client]; teTeX-base install graphics/synaesthesia (configure or build or install) (not retested locally though) J. Bouquet ___ 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"
Browsers...
Firefox 21 would not run (segfaulted). I pkg_added Firefox 20, and it works, but I lost all the sites it for years had open at the start, they are nowhere... maybe I'll find them in a backup later. ... Midori would not run, but "midori -d -p' seems to work. (The latest one will not build, but that is unique to here probably...) This all prompted by one site refusing to proceed to the next clicked action in both opera and seamonkey, which otherwise work fine... Meant just as a FYI for anyone facing a similar situation, not needing an answer to this post... J. Bouquet ___ 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: Browsers...
As firefox is a seldom-used backup browser, I don't want to test it, but would if I had the time (seamonkey stuff is also in that subdirectory and it is one my primary browsers). No NFS mounted. BTW I recovered the url's that I had lost from the adblock preference line in prefs.js, so that is solved anyway. --- On Mon, 5/20/13, Chris Rees wrote: ... Do you have an NFS mounted home directory? I've discovered that Firefox doesn't like that, perhaps something to do with sqlite locking. You can work around by moving your .mozilla folder somewhere local and symlinking it. Even if you're not on NFS, have you tried moving your .mozilla away? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ 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: Rebuild all ports for perl minor version update?
--- On Sun, 6/16/13, Thomas Mueller wrote: > From: Thomas Mueller > Subject: Rebuild all ports for perl minor version update? > To: freebsd-ports@freebsd.org > So now I do the massive portmaster upgrade and am stopped by > silly little things, like a conflict between the old > transmission-gtk2 and the newer version, and later gcc can't > make clean because of checksum errors. It didn't know > to deinstall the old transmission-gtk2? > Tom Provided your pkg_tools still exist the following could be useful, I've haphazardly got it running for several hours (.tbz are present from another machine for portmaster in portmaster-download...). Sometimes it freezes, but cntl-c it restarts again ( A directory had disappeared upon its port reinstall, but the CLI continues .) cd /usr/local/lib/perl5/site_perl/5.12.4 for i in $(find . -type d), do find . -type f | xargs -J % pkg_which | xargs -J % portmaster -d -B -P -i -x gcc-4.7.3.20130323 -R % && cd /usr/local/lib/perl5/site_perl/5.12.4 && pkgdb -u Note that only a template to modify-then-test, [ I ran it, it started to update too much, I might have modified it more, OR maybe it restarted as intended upon cntl-c the first time. Additionally, the first part (the -type d line) does not show in the history of the command, so I cannot be sure of more than one thing in that command. Howsoever, it has been running over an hour with only occaisional freezes, restarting upon cntl-c without reentering the command, and may be useful for someone more expert in shell mechanisms than I to use to craft an all-inclusive python-after-upgrade, perl-after-upgrade, ruby-after-upgrade shell script(s)... Several weeks before I can test it on another machine, am out of time. J. Bouquet [It is certainly working better than ANY instance I ever ran a perl-after-upgrade,... so I apologize for the inexact replication of it in this email. ] ___ 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: Rebuild all ports for perl minor version update? UPDATED
Edited inline correction --- On Sun, 6/16/13, Jeffrey Bouquet wrote: From: Jeffrey Bouquet Subject: Re: Rebuild all ports for perl minor version update? To: freebsd-ports@freebsd.org Date: Sunday, June 16, 2013, 2:52 PM --- On Sun, 6/16/13, Thomas Mueller wrote: > From: Thomas Mueller > Subject: Rebuild all ports for perl minor version update? > To: freebsd-ports@freebsd.org > So now I do the massive portmaster upgrade and am stopped by > silly little things, like a conflict between the old > transmission-gtk2 and the newer version, and later gcc can't > make clean because of checksum errors. It didn't know > to deinstall the old transmission-gtk2? > Tom Provided your pkg_tools still exist the following could be useful, I've haphazardly got it running for several hours (.tbz are present from another machine for portmaster in portmaster-download...). Sometimes it freezes, but cntl-c it restarts again ( A directory had disappeared upon its port reinstall, but the CLI continues .) cd /usr/local/lib/perl5/site_perl/5.12.4 for i in $(find . -type d), do find . -type f | xargs -J % pkg_which | xargs -J % portmaster -d -B -P -i -x gcc-4.7.3.20130323 -R % && cd /usr/local/lib/perl5/site_perl/5.12.4 && pkgdb -u EDIT "do find $i ..." EDIT 2 I had to delete for the duration ports such as PDL which insisted on continual reinstall EDIT 3 finally had to delete several deprecated/broken (p5-Lucene.. p5-Test-Block...) OTHERWISE it ran many hours continually with many cntl-c which did not actually halt it, just its subprocess at the time. END EDITS Note that only a template to modify-then-test, [ I ran it, it started to update too much, I might have modified it more, OR maybe it restarted as intended upon cntl-c the first time. Additionally, the first part (the -type d line) does not show in the history of the command, so I cannot be sure of more than one thing in that command. Howsoever, it has been running over an hour with only occaisional freezes, restarting upon cntl-c without reentering the command, and may be useful for someone more expert in shell mechanisms than I to use to craft an all-inclusive python-after-upgrade, perl-after-upgrade, ruby-after-upgrade shell script(s)... Several weeks before I can test it on another machine, am out of time. J. Bouquet [It is certainly working better than ANY instance I ever ran a perl-after-upgrade,... so I apologize for the inexact replication of it in this email. ] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
svn repositories stale?
svn0.us-west.freebsd.org, r321412 (not updating ) since subversion upgraded in ports (at least vs freshports.org...) Anyone know if it is a configuration at that server, or some other cause, or if it is a know problem, or a PBKAC here at these machines? Thanks J. Bouquet ___ 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: kde3 ports expired today
bsdstats.org > ports stats would have that information probably Here, I've installed snotes, xxdiff and a few others (qt33...) not kde3 per se... Subject: Re: kde3 ports expired today Are there any numbers how many FreeBSD(!) users are using KDE3 or KDE4? If not, what about a well organized(!) straw poll? Just to see, if we are all hunting in the right direction. matthias - ___ 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: editors/vim: buffer.c:(.text+0x1589): undefined reference to `libintl_gettext'
I'd be interested in a solution to this, also, it consistently lets ports such as pinot, mc, mutt etc fail to build, some to be only pkg-added later. (v9.1-Stable) editors/vim: buffer.c:(.text+0x1589): undefined reference to `libintl_gettext' Updating port /editors/vim on a CURRENT box (FreeBSD 10.0-CURRENT #0 r253194: Thu Jul 11 10:45:47 CEST 2013 amd64) ends up in the error shown below. Since this happens only on exact one box running CURRENT (out of a bunch of CURRENT of the same OS revision, the same compiler settings, the same settings in /etc/src.conf et cetera) while other CURRENT don't show this weird error, is suspect a faulty local library, like libintl.so, which belongs to gettext I suppose. Well, I tried to do a portmaster -r editors/vim as well as portmaster -r gettext to "compile away" the suspected problem in one of the prerquisited ports, but that didn't end up in success. The problem is still sticky and I'm a bit out of ideas ... Has anybody an idea? Thanks and regards, Oliver [...] link.sh: $LINK_AS_NEEDED set to 'yes': invoking linker directly. cc -L. -Wl,-rpath=/usr/lib:/usr/local/lib -pthread -L/usr/local/lib -rdynamic -Wl,-R/usr/local/lib/perl5/5.16/mach/CORE -L/usr/local/lib -Wl,--as-needed -o vim objects/buffer.o objects/blowfish.o objects/charset.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o objects/hashtab.o objects/if_cscope.o objects/if_xcmdsrv.o objects/mark.o objects/memline.o objects/menu.o objects/message.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o objects/popupmnu.o objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o objects/sha256.o objects/spell.o objects/syntax.o objects/tag.o objects/term.o objects/ui.o objects/undo.o objects/version.o objects/window.o objects/if_lua.o objects/if_perl.o objects/if_perlsfio.o objects/if_python.o objects/if_tcl.o objects/if_ruby.o objects/netbeans.o objects/main.o objects/memfile.o -lm -lelf -pthread -ltermlib -liconv -Wl,-R/usr/local/lib/perl5/5.16/mach/CORE -pthread -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/local/lib/perl5/5.16/mach/CORE -lperl -lm -lcrypt -lutil -L/usr/local/lib/python2.7/config -lpython2.7 -lutil -lm -Wl,--export-dynamic -L/usr/local/lib -ltcl86 -lz -lpthread -lm -Wl,-R -Wl,/usr/local/lib -L/usr/local/lib -lruby19 -lexecinfo -lpthread -lcrypt -lm -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib -pthread -L/usr/local/lib objects/buffer.o: In function `open_buffer': buffer.c:(.text+0x1df): undefined reference to `libintl_gettext' buffer.c:(.text+0x1fb): undefined reference to `libintl_gettext' objects/buffer.o: In function `close_buffer': buffer.c:(.text+0x5d3): undefined reference to `libintl_gettext' objects/buffer.o: In function `do_buffer': buffer.c:(.text+0x1589): undefined reference to `libintl_gettext' buffer.c:(.text+0x15bc): undefined reference to `libintl_gettext' objects/buffer.o:buffer.c:(.text+0x163f): more undefined references to `libintl_gettext' follow 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" Bottom posting here. New webmail won't even let me see it as I type. so top posting for now... ___ 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: editors/vim: does not compile on CURRENT
I have/had/have had a similar " libintl_textdomain " in a great many ports (currently pcmanfm and about twenty others), and it has persisted on-and-off year after year. No amount of dependency rebuild ususally solves it, eventually sometimes a remote package is installed instead (v9) So I would be interested not so much in those two specific errors, but a wrapper under which one could build a port so that each element of the calling compilation line could be analyzed to see from which the error specifically occurs, no matter how much it slows down the respective port build... From: O. Hartmann To: FreeBSD Ports Sent: Wednesday, July 31, 2013 7:28 AM Subject: editors/vim: does not compile on CURRENT I have one box that is reluctantly not compiling port editors/vim with the following error. main.c:(.text+0xbb7): undefined reference to `libintl_gettext' main.c:(.text+0xc93): undefined reference to `libintl_gettext' objects/main.o:main.c:(.text+0xcaf): more undefined references to `libintl_gettext' follow cc: error: linker command failed with exit code 1 (use -v to see invocation) link.sh: Linking failed *** Error code 1 ... J. Bouquet (Just figured out how to put that top-posting down here, hopefully all the next emails I'll remember and the post will be more readable...) ___ 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: libpkg, sqlite and database problems prevent building any packages
Bottom posting below; will reply in better format when/if I get another webmail client maybe... the text is below the next occurance of "bottom posting" From: Thomas Mueller To: freebsd-ports@freebsd.org Sent: Monday, August 5, 2013 8:36 AM Subject: Re: libpkg, sqlite and database problems prevent building any packages On 05/08/2013 14:30, Thomas Mueller wrote: > I could see my pkg client is out of date, but how do I update it? > > Attempts to update all gave me those error messages. Installation fails. Matthew Seaman responded: > Your package database has got into an inconsistent state. pkg(8) is > attempting to auto-update the schema to the latest version, but failing > because it's trying to remove an 'infos' column from a table where that > column has apparently already been removed. (Likely this situation has > come about because pkg got killed in the middle of doing this update > previously.) > How happy are you to get down'n'dirty with the source code and running > SQL from the command line? If you look at the updates pkg is attempting > to run shown here: > https://github.com/freebsd/pkg/blob/master/libpkg/private/db_upgrades.h > would you be capable of looking at the DB schema, working out which of > those updates had been applied, aplying any outstanding ones by hand and > then setting the user version to 19 by: > sql> PRAGMA user_version = 19 ; ? > If not, check in /var/backups for a good copy of your local.sqlite > database and try and restore from there. Unfortunately, there's no > guarantee that any backup copy doesn't have the same inconsistencies as > your live copy. > We need to make pkg(8) databases more resilient to the effects of SIGHUP > or similar while they are elbows-deep in the bowels of the DB schema... Trying to do what you suggest would in all likelihood be an exercise in futility, especially when I am very tired from being unable to sleep. I didn't realize pkgng was so non-sturdy. I wonder what would happen if I delete /var/db/pkg/local.sqlite, or perhaps better, move it to another location and name so as not to burn my bridges. But anything so I can upgrade pkg. Does pkgng have no means of recovery? Can pkg regenerate a database, and from what? My /var/backups on the USB-stick 9.2-BETA2 amd64 installation shows total 280 -rw-r--r-- 1 root wheel 1674 Apr 2 2012 aliases.bak -rw-r--r-- 1 root wheel 436 Apr 2 2012 group.bak -rw--- 1 root wheel 1500 Apr 2 2012 master.passwd.bak -rw-r--r-- 1 root wheel 269144 Dec 13 2012 pkgdb.bak.tbz -rw-r--r-- 1 root wheel 129 Jul 16 2012 pkgdb.bak.tbz.2 pkg.bak.tbz looks like the database from the old format. My /var/backups on the USB-stick 9.1-STABLE i386 installation shows total 140 -rw-r--r-- 1 root wheel 1688 Jan 20 2013 aliases.bak -rw-r--r-- 1 root wheel 1674 Jun 6 2012 aliases.bak2 -rw-r--r-- 1 root wheel 481 Jan 17 2013 group.bak -rw-r--r-- 1 root wheel 449 Jul 13 2012 group.bak2 -rw--- 1 root wheel 1761 Jan 17 2013 master.passwd.bak -rw--- 1 root wheel 1500 Jun 6 2012 master.passwd.bak2 >-rw-r--r-- 1 root wheel 8524 May 28 03:01 pkgdb.bak.tbz >-rw-r--r-- 1 root wheel 130 Jan 19 2013 pkgdb.bak.tbz.2 >-rw-r--r-- 1 root wheel 100352 May 28 04:29 pkgng.db >pkgng.db looks like the new format, but that was before I built wine and >dependencies. .. .. Bottom posting... Non-sturdy? , but this sort of showstopper is what IMHO should necessite a huge problem-resolving flowchart, before pkg(ng) fully obsoletes its legacy alternative... not to mention the possibility of pkg(ng) not having enough memory, on some installs where before /var/db/pkg would have enough. Just a 2c. As in, if I *have to* migrate to pkg/, I need something from which to copy the succint parts to a few post-its on the monitor... (think HUGE...FLOWCHART...) Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ 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"
Wishlist for pkg before it is default on STABLE
.Actually, the subject is just a title, probably not the subject (multiple issues). I continue to believe svn, (pkg...) (gpart) should have a *flowchart* so issues could be resolved without consulting forums, wikis, ... quicker. Should one compose one for svn, the following fixed "checksum mismatch" svn halts on the ports tree. #problem dir# svn co --set-depth empty (or it was svn up...) #problem dir# svn co --set-depth infinity (or it was svn up...) #/usr/ports# svn up /usr/ports However, that worked only on about ninety percent of the problematic ports, of which there were too many. I quit using it however, and had to re-svn a ports tree, when svn could no longer operate because of segfaulting. (Maybe it is unstable once it is fixed in a nonstandard way...) Hope that hint helps someone. One needs a recent version of svn for it to work. ... Two issues, however, seem problematic here. . One, many gnome ports (pkg_add) fail upon the (pkg_delete && pkg_add ) pkg_add, "playpen: cannot change back to ' ' " and have done so for years, so the machine on which the install is to be done (say, an xargs-fed portmaster) halts with the port newly deinstalled. (for which I found this week, the following make install -C /usr/ports/[category][port] if one is in a hurry...) (Most Freebsd users probably know it already, I had always changed to the directory first.) Anyway, I am wondering if the unknown cause (year after year here) of that pkg_add error will occur also in the equivalent command of pkg, if the cause is not known and determined to be a factor in the new code. .. The other pressing issue, For instance, today reinstalling p5-Text-RecordParser (which btw wont' patch) with portmaster -d -B -P -i -g ... installed p5-Pod-* (2 of) "into" perl 5.14 although I still use 5.12.5 So if I am upgrading hundreds of perl ports at a time, I try to recheck the /usr/local/lib/perl5 to see if they have installed into 5.14, and recompile them for 5.12. I expect the same problem will be present in the /pkg/ repository? IE there is not a pkg-stable-still-perl-5.12 -v10 pkg-stable-perl-5.14-v10 branching of either the repository, or some way to know that the slew of packages intalling are mismatched in the dependent langauge to be installed. Sorry if anything is unclear. No time to rewrite... J. Bouquet ___ 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"
v10 pkg question, maybe
#/# find /var/db/pkg -type d -name "p5*" | xargs -J % find -type f -name
"+CONTENTS" -exec grep -H "5.12" {} \; | grep pm | gtr -s \/ "\n" | grep p5 |
sort | uniq | xargs -J % portmaster -d -B -P -i -g % && yell || yell
If one has gtr (gnu tr) installed, that may work if one has /var/db/pkg...
I had an issue where pkg_which turned up ? for all the perl files it usually
worked on in /usr/local/lib/perl5/site_perl (etc)
to upgrade, say, 5.12.4 to 5.12.5... suddenly failing a bit into the 5.12.5
5.14.4 upgrade, meaning each port had to be
entered manually.
That long CLI pipe at the top is working handily. ( midst of it, a head -110 ,
head -140, head -170 so make its failures
manageble on restart)
And one inserts | grep -v tkdb | , for instance, for p5- ports which won't
rebuild at the moment.
In fact that script is working way better than any other perl upgrade I recall
doing that required an UPDATING course of action.
So I am wondering it someone who uses /pkg/ can craft an equivalent CLI, test
it, and eventually it or its equivalant could be
placed either in the port, or in UPDATING so persons who have many ports could
upgrade leisurely in a few hours rather than
kludgedly over many more hours than the few.
Thanks if anyone has the time... and expertise and experience to look into the
situation.
J. Bouquet
___
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"
Comments on todays non-NEW_XORG update
It is done here, for the most part. (Epiphany remains out of the picture, persistent failure to build webkit...) but there were a few quirks... The reinstall of gtk20 (which was newly missing a dependency) depended upon ibus for the install, but ibus depends on gtk20... gtk20 ) make -k install ibus ) pkg_delete && make package gtk20 ) make package And the rebuild of roxterm, which was missing a vte rebuild, which was missing a pango rebuild. This occurs here at least once a year or so... Here UPDATING usually cannot be followed... that lists over 300 ports needing pixman; I only use several of them daily, and only had to rebuild a few. I'm used to these unexpected less-than-full-rebuild extra-rebuilds occuring, but am wondering if FreeBSD could more precisely anticipate them in the UPDATING instructions someday. [Revising the "portmaster -r pixman" since that may take several days, and in two hours I'm already done with it AFAIK.] [Tangentally, has anyone using pkg only, run across the same situation and resolved it with any ease and repeatable instructions to the ports list??? ] J. Bouquet ___ 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"
Svn wrapper? [pasted from a Q. on the forum] ... To resolve "conflicts remaining"
On many machines here, the ports or src tree upon svn up shows a large number of conflicts, half of which want an answer such as "postpone", the other "theirs-full". Re-downloading with svn seems to not resolve the conflicts. (Why they appear in the first place, nothing changed on this machine in the meantime, is a complete mystery.) The often recommended delete-and-re-checkout procedure is okay, but takes much more time (preserving extra files etc) than I"d like to, if there was any svn command that mimics the old cvs procedure of remove-directory and re- cvs it. Anyone knows of a succinct svn command for use in such situations, or if a wrapper could be crafted that puts forth the series of commands that would take less time than a new src or ports checkout? The handbook refers to the SVN redbook, it might have the answer, but I am reluctant to spend the time reading it thoroughly if someone else has and knows the answer(s) already. Thanks. J. Bouquet [The forum thread has a few posts in it with a few more details ]... ___ 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"
UPDATING libtasn1
UPDATING says to rebuild all that depend upon libtasn1, but the +REQUIRED_BY lists a large number here that still work without it. (Although they don't presently work, being unsed and not having been rebuilt since pixman...not really relevant but I neglect on purpose to rebuild many gnome ports each time, as many often typicall fail without modifying make.conf or switching compilers, they are more or less there for reference in case I want, say, an audio port, I would know which to grab a package maybe for.) ...(Examples: qiv, dillo, which UPDATING probably says to rebuild (untested).) So while the UPDATING syntax may be useful for production machines, many with desktops might benefit from an alternate method which only rebuilds, say, a tenth of the huge list, using a more fine-grained method of finding those which directly depend upon the library... So this message I mean to include all such library bumps in the future, and as a suggestion not for the next 2, 3, 4 or so similar entries, but for those more distant after something tested and useful has been put maybe into a shell script so that the update takes much fewer hours of CPU usage. Thanks J. Bouquet ___ 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"
Confusion about how to specify and also override ( gcc vs clang and versions)
I wonder if anyone knows a page where one can be sure the lines in one's make conf are correct, and also a command line to override the setting. For instance CC=/usr/local/bin/clang33 CXX+= ... As, how many of those are supposed to exist? Are the more for some compilers than others? Other things to consider within the make.conf? The way they should be written for each of gcc46, gcc47, clang, clang33 And a way to override whatever is in make conf, as... make CLANG=/usr/local/bin/clang33 build ... is supposed to work? Or some other suggested or proven method? Checking wiki.freebsd.org I don't see any specific page. Searching for the information in the forums has for a short time not yielded much informaiton. I've six of seven distinct make.conf's (make.conf.clang, make.conf.aria2c, ...) that I'd like to standardize the syntax of the compiler within all of. Thanks if anyone knows. J. Bouquet ___ 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: Upgrading Perl... Somebody just shoot me and put me out of my misery!
I *was* equally setback by this upgrade, but am slowly mostly fixing it on a
build machine to maybe package over to the usual one:
(My quicker pipes have not been working ...)
..
cd /var/db/pkg
gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk
'{print $8 }' xargs -J % find % -type f
-name +MTREE_DIRS -exec /bin/ls -lac {} \;
[ more to the pipe maybe automates the next ...]
...
You'll see ports *since* last upgrading perl and *not since*. Simply type the
older ones into
portmaster -d -B -i -g p5-.. p5-... p5-.
.
I am in a rush on some aspects of this update, so on ones which don't install
use something like...
cd /usr/ports/net/p5-Socket
/bin/rm -rf work
make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall
YMMV. [ It is quite obviously piecemeal, this method...]
..
Another glitch with this upgrade, every Nth port seemingly wants to revert perl
5.16 > 5.14 in the process of
install from a package, so I've often
/bin/rm -v /usr/bin/perl
/bin/rm -v /usr/bin/perl5
/bin/rm -v /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5
After cntl-c the new failing install-older-perl package *BEFORE* it installs
the older perl *ALSO*
.
If I am wiser next time, and maybe even on this older-perl machine, I'll simply
delete all p5-s after printing them out,
and awk / gtr /xargs the file into portmaster. I expect the workarounds to
still be maybe necc. though.
.
J. Bouquet
Sorry for typos
On Friday, November 22, 2013 3:52 AM, Mathieu Arnold wrote:
+--On 22 novembre 2013 00:25:26 -0800 "Ronald F. Guilmette"
wrote:
| AUTHOR: m...@freebsd.org
Cough, cough, yeah, I mostly wrote that.
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.
| pkg_info says that at present I have perl5.14-5.14.4_3 installed. So
| excuse my french, but why the fuck didn't the command:
|
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3
I'll commit an update to that right now.
--
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Fw: Upgrading Perl... yesterday's AWK improved, working...
Sorry for top-posting... [ other email services are on my todo list (
hushmail, runbox, polarismail, if/when the
email volume here increases... ]
the +MTREE_DIRS pipe can be extended...
... | grep -v "v 2" [OMITTING Nov 21 already-updateds] | awk '{print $9}' |
gtr -s \/ "\n" | grep p5 | xargs -J % portmaster -d -B -i -g %
&& yell || yell
If one has gnuls, gtr (coreutils?) installed, and still uses
/var/db/pkg/PORTNAME-NUMBER, that pipe (the second part above, the
first below...) just updated at-once 14 of the hundreds of p5 ports as I had
updated the head -115 to head -135 ( approximately).
I expect to copy [1] that !hint to all /lang/ (perl ) (ruby) (python) to use
until pkgng, at which point I hope that someone has posted
a PKG equivalent... or evolved a feature of PKG where it writes its /var/db/pkg
files out again after each operation, so equivalent
pipes can occur.
1.. actually, scrot of this email before sending, so more information included.
( the .jpg to the /lang/ directories...)
On Friday, November 22, 2013 4:17 AM, Jeffrey Bouquet
wrote:
I *was* equally setback by this upgrade, but am slowly mostly fixing it on a
build machine to maybe package over to the usual one:
(My quicker pipes have not been working ...)
..
cd /var/db/pkg
gnuls -oSr | grep p5 | head [ increment each time... 10, 20...] | awk
'{print $8 }' xargs -J % find % -type f
-name +MTREE_DIRS -exec /bin/ls -lac {} \;
[ more to the pipe maybe automates the next ...]
...
You'll see ports *since* last upgrading perl and *not since*. Simply type the
older ones into
portmaster -d -B -i -g p5-.. p5-... p5-.
.
I am in a rush on some aspects of this update, so on ones which don't install
use something like...
cd /usr/ports/net/p5-Socket
/bin/rm -rf work
make -DNO_STAGE -DMAKE_JOBS_UNSAFE -DNO_PACKAGE reinstall
YMMV. [ It is quite obviously piecemeal, this method...]
..
Another glitch with this upgrade, every Nth port seemingly wants to revert perl
5.16 > 5.14 in the process of
install from a package, so I've often
/bin/rm -v /usr/bin/perl
/bin/rm -v /usr/bin/perl5
/bin/rm -v /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/local/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl
ln -s /usr/local/bin/perl5.16.3 /usr/bin/perl5
After cntl-c the new failing install-older-perl package *BEFORE* it installs
the older perl *ALSO*
.
If I am wiser next time, and maybe even on this older-perl machine, I'll simply
delete all p5-s after printing them out,
and awk / gtr /xargs the file into portmaster. I expect the workarounds to
still be maybe necc. though.
.
J. Bouquet
Sorry for typos
On Friday, November 22, 2013 3:52 AM, Mathieu Arnold wrote:
+--On 22 novembre 2013 00:25:26 -0800 "Ronald F. Guilmette"
wrote:
| AUTHOR: m...@freebsd.org
Cough, cough, yeah, I mostly wrote that.
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
At that time, that line was right. Now, after that, the perl packages name
which had the same name (all named perl) and were conflicting and were
renamed to perl5 for the default perl, that is, 5.16, and perl5.xx for the
non default ones, that are 5.12, 5.14 and 5.18.
| pkg_info says that at present I have perl5.14-5.14.4_3 installed. So
| excuse my french, but why the fuck didn't the command:
|
| portupgrade -o lang/perl5.16 -f perl-5.14.\*
Now, as you can see, your perl is not named perl-5.14 but
perl5.14-5.14.4_3, so, you should change that line to :
portupgrade -o lang/perl5.16 -f perl5.14-5.14.4_3
I'll commit an update to that right now.
--
Mathieu Arnold
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Seamonkey update
pkg today updated seamonkey, now it segfaults, every which way I try to run it. [This is from backup and a rewritten fstab. ] linux-seamonkey also segfaults, first time I installed it. Deinstalled. firefox works only half as efficiently, but passably. seamonkey fails to build with gcc, clang49 or default... vs other times. attempting to fix that with nvidia-driver update, which fails to build, API mismatch... which used to work after installing theolder nvidia.ko and nvidia-modeset from backup, ALSO API mismatch. which I think I used in the past to fix a similar problem... Seamonkey is currently the second most vital part of this FreeBSD Jan 2004-2017 5x > v11 ,,, So the _4 _5 was quite a showstopper. Working backup from a day ago was only coincidence. Any one know where to get _4 etc, i386, without reverting to quarterly repo? portsmon is four weeks behind IIRC with a developer working on a fix... so the .txz there are NGINX 502 or some error... Inaccuracies in the above, maybe. Apologies. Rushed today... And sorry for multi-topic most of which I hardly ever delve into fixing so not really qualified nor time to fix or file PR on... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Seamonkey update
On Sun, 5 Feb 2017 20:05:51 -0500, roberth...@rcn.com wrote:
>
> Jeffrey Bouquet writes:
>
> > pkg today updated seamonkey, now it segfaults,
> > every which way I try to run it.
>
> I am running SeaMonkey 2.46_5 (compiled today) under:
>
> FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64
>
> .
> So far, indistinguishable from _4.
>
>
>
> Respectfully,
>
>
> Robert Huff
More progress but not so encouraging.
Rebuilt the machine on which seamonkey segfaulted, to v12-CURRENT
..
seamonkey still segfaults
after _4 _5 [ a showstopper for the v11 OR v12 desktop on that disk ]
/usr/bin/cc segfaults, prohibiting port building
after installworld [ a showstopper for v12 on that disk ]
pkg -vv reports v11
FreeBSD.conf
containing FreeBSD:12:x86:32,
containing /${ABI}/,
containing FreeBSD:12:i386
each error out in some manner or another, making package not usable.
[a showstopper for pkg usage on that disk ]
Firefox prohibits 2 entry anywhere, so I cannot log into the forums as
jb_fvwm2 on the newer machine to inquire there, not use most any
search query containing the numeric digit(s) 2 and at least two others.
[ a showstopper for firefox usage on that disk ]
.
None of these 4 problems were present on Feb 4 vs by the morning of today Feb
6...
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
12-CURRENT won't configure to download packagesite.txz yet
All the files
/etc/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg.conf
I edit time after time for
{$ABI} which gives FreeBSD:11:i386 but I am on 12-CURRENT i386
Anytime I try to attune to
freebsd:12:x86:32or
FreeBSD:12:i386 ...
it downloads the packagesite again, as it does in the ABI example, but a terse
error of wrong architecture, etc, and a fail to do anything to upgrade to
Pkg-12.
Can the proper file be rename upstream to what its architecture in simpler
terms:
like packagesite-i386-12.txz and a message printed upon de-TXZ the file so that
the proper nomenclature is given to put into each of those three files above
so that the generic packagesite.txz will not error out upon download?
Or, put the instructions in /usr/src/UPDATING ?? since it is part of base?
Or some other way to de-showstopper this v11 April 2016 CURRENT to v12 Feb 2017
CURRENT
upgrade which still has failed to enable seamonkey-2.46_5 to run non-segfault [
ie cannot run ]
vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting?? And
cannot build
from ports for obscure .h clang-header file related reasons?
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Seamonkey update
On Sun, 5 Feb 2017 20:05:51 -0500, roberth...@rcn.com wrote: > > Jeffrey Bouquet writes: > > > pkg today updated seamonkey, now it segfaults, > > every which way I try to run it. > > I am running SeaMonkey 2.46_5 (compiled today) under: > > FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64 > > . > So far, indistinguishable from _4. > > > > Respectfully, > > > Robert Huff About to reinstall the 2004-2017 disk, when a forum tar -C of base.txz etc fixed the pkg v11 > v12 issue, which caused _4 to reinstall from pkg. Built from ports. _5 on i386 segfaults. GENERIC was missing axe0 and ums0 in my kernel which I reverted (the kernel) . So aside from a wholesale from-backup of configuration files (the MANIFEST in /usr/lib/freebsd-dist did not contain the 'motd' etc which it overwrote with new, unfortunately... two concerns remain. . Building from ports again works, seamonkey _5 segfaults. I restored _4 from pkg. (v12) pf is nowhere to be found. Even if in the directory where I kldload pf.ko, I receive a 'no such file' message from kldload. As it was not my primary firewall, it is not a huge problem, but I would like to know if something has changed in CURRENT. As another aside, I could maybe 'jail' _4 seamonkey for a number of years so that it is effecively 'pkg lock seamonkey' without chance for error. But maybe that is a pipe dream... Apologies to the lists for recent messages needed newbie help which I got elsewhere but may still have questions unanswered, besides the one above and the seamonkey i386 _4 _5 breakage I assume to happen someday. Thanks for reading. Very relieved at the moment. J. Bouquet ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
r313305 libevent2 problem and workaround NEED FIXING...
A huge six-day fix of seamonkey breakage on 11-CURRENT of april 2016, upgraded finally last night to pkg 12-CURRENT feb 2017 working and etc by base.txz overwrite etc... ... I've many many hours to restore the desktop to full how-it-was-before, but as it is working, now, a wholesale 3xxx reinstall of ports by pkg (which had to occur OUT OF Xorg for stall issues... and lack of granularity in the use of "pkg upgrade" (ie thirty-by-thirty) or lack of code in "pkg install" (terse deinstalls necc. where reinstalls were needed) as of this date . Mostly fixed as I write from the fixed system, but the only reason I am using seamonkey now, and also fixed firefox, just then, is the series of commands... which I expect to maybe re-break when v12 upgrades _4 seamonkey to _5 which broke (segfaults) here from ports the port... but in the meantime .. cp -iv /[backup mount}/usr/local/lib/libevent-2.0.so.5.10 /usr/local/lib/compat/libevent-2.0.so.5 cp -iv /usr/local/lib/compat/libevent-2.0.so.5 /usr/ports/www/seamonkey/libevent-2.0.so.5-NECC-FOR-SEAMONKEY .. backup restored a newly overnight broken seamonkey AND firefox, the former not as of a day or so from ports being able to run. . This is quite the showstopper here... almost forced a reinstall of 2004-2017 ( this desktop) to a 2016-STABLE v11 new disk which I may have to revert to if seamonkey breaks again or the next iteration of libevent/seamonkey/firefox does not fix up with CLI such as this time. Out of time for a PR or bug report offically, and hope to gain more pressing urgency to this problem than might be attained, that way... out of time also. ... Thanks for reading, and thanks for putting up with interim list messages in the last few days which still had a bit of almost PBKAC combined with lack of documentation combined with newbie-ness here which had yet to resolve... and thanks for the forum post(s) which helped resolve the seemingly-lost-cause issue of the v11-CURRENT upgrade to v12-CURRENT which appears to have worked today vs several days ago, IF seamonkey continues to be fixable locally. J. Bouquet ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
opera browser crash and recovery
About once a year, sometimes more often, sometimes less often, opera browser thinks it is not installed, and wishes to reinstall, placing a plain-vanilla version to where years of customization had comfortably attuned the browser to my workflow due to still-newbie tunings I've backup up. The following two files, for instance, [install dir]/.opera/cache/toolbar/standardtoolbar.ini [install dir]/.opera/cache/operaprefs.ini Please double check those... HOWEVER there may be a third or 4th.. Those two today restored a browser deletion of all the settings [ defaults to no images, for instance... ] I've crafted over the years. So I was thinking maybe a pkg-message may be in order detailing the need to backup one's files, and which ones, so others or even I may save time and aggravation etc, should the crash [system, Xorg, etc] occur at n inconvenient time. Thanks Jeff ps. Hurriedly crafted email. Sorry if any typos. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[RFC] rename nvidia-driver port binaries [ and other comments]
Just had a unique to me, unbootable backup [beside the point, just a sidebar comment... ] quandry dealing with the nvidia-driver update that mesa-libs needed. [ or was appurtenant to it, unsure... ] 12.0 - CURRENT [ my previous 'saves' -- files to consult... were in .jpg, so no avail for me to peruse as I was in the terminal ] Lessons I learned, maybe [RFC] rename nvidia-driver.ko to include its version, for instance nvidia-modeset-37539.ko which would make one's diagnosis a fix easier. [suggestions] ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus made it 'unavailable' ... document better that one can load nvidia[modeset] later than /boot/loader.conf [cli, rc.conf...] [ mini 'what fixed it for you ' and/or stalled the same ... ] ... I had a make.conf in place, 'trapping' a make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39" [and the other two...] install in failure ... I had no clue if Xorg was at fault, and luckily did not have to rebuild. ... I had no access to the forums, as the desktop could not be loaded [yet] ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable module numbers, THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 digit number as above. ... I was taken aback by the less infomative this client has the .39 but the module has the .26 ... specifically stating which file/port/kernel module the 'client' refers to and which specific modules 'this module' was referring to. Unknown if that is fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] where we can ask them to be more specific or code in some more verbose error messages. ... Relieved I did not have to rebuild Xorg nor the kernel, just move files out of the way and do a simple rebuild of the nvidia-driver. [... Not relieved that the nvidia-driver needed install during the mesa-lib reshuffle, maybe did not need to be, just a hazy recollection on my part. So ignore this little bit ] ... All in all a learning experience. Howsoever, I would like this nvidia stuff to be put eventuall in /usr/src/UPDATING so the half or third of persons who run into this yearly will have a more authoritative flowchart of sorts to determine the next course of action. something like if ... this thta if... this that if ... this that OTOH... error message... a... you may need to... ... error message ... r... you may need to... ... And it would have maybe saved a bit of time here, and I would almost if eventually possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver for more easy access if the desktop was broken Apologies for the hurried post. Indeed, I have tasked myself to write it up here locally [ still in scribbled notations...] so I can forestall/fix more quickly this error the next time. also... Running late in other personal matters, and out of time. Respectfully.. J. Bouquet ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [RFC] rename nvidia-driver port binaries [ and other comments]
On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI
wrote:
> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
>
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
>
> *Insufficient loader memory, but OK after kernel is started.
>
> *Accidentally backed to older version that doesn't have
> nvidia-modeset.ko and only nvidia-modeset.ko is written in
> /boot/loader.conf.
>
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
> echo "Loading nvidia-driver modules via rc.conf."
> # kldload nvidia
> if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
> else
> #kldload nvidia
> kld_list="${kld_list} nvidia.ko"
> fi
> fi
>
>
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet" wrote:
>
> > Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ] quandry dealing with the nvidia-driver update
> > that mesa-libs needed. [ or was appurtenant to it, unsure... ]
> >
> > 12.0 - CURRENT
> >
> > [ my previous 'saves' -- files to consult... were in .jpg, so no avail
> > for me to peruse as I was in the terminal ]
> >
> > Lessons I learned, maybe
> >
> > [RFC] rename nvidia-driver.ko to include its version, for instance
> > nvidia-modeset-37539.ko
> > which would make one's diagnosis a fix easier.
> >
> > [suggestions]
> >
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than
> > /boot/loader.conf [cli, rc.conf...]
> >
> > [ mini 'what fixed it for you ' and/or stalled the same ...
> > ]
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39" [and the other two...]
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ...
> > specifically stating which file/port/kernel module the 'client' refers
> > to
> >and which specific modules 'this module' was referring to. Unknown if
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp
> > ] where we can
> > ask them to be more specific or code in some more verbose error
> > messages.
> > ... Relieved I did not have to rebuild Xorg nor the kernel, just move
> > files out of the
> > way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib
> > reshuffle, maybe
> >did not need to be, just a hazy recollection on my part. So ignore this
> > little bit ]
> >
> > ... All in all a learning experience. Howsoever, I would like this nvidia
> > stuff to be put eventuall
> > in /usr/src/UPDATING so the half or third of persons who run into this
> > yearly will have a more
> > authoritative flowchart of sorts to determine the next course of action.
> >something like
> > if ... this thta
> >if... this that
> >if ... this that
> > OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> >
> > ... And it would have maybe saved a bit of time here, and I would almost
> > if eventually
> > possible be sure to copy /usr/src/UPDATING to
> > /usr/ports/x11/nvidia-driver for
> > more easy access if the desktop was broken
> >
> >
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more
> > quickly this
> > error the next time.
> &g
Re: Firefox (and other Mozilla products) after ino64
On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric wrote: > Hi, > > Due to the recent ino64 update in 12.0-CURRENT, there have been some > reports by Firefox port users about crashes. While I personally have > not experienced these crashes, as I immediately rebuilt all my ports > from scratch after the ino64 update, I think can explain why the > following combination is very likely to have problems: > > * kernel+world after ino64 > * www/firefox package from before ino64 > > It is because Firefox's JavaScript engine is doing tricks to get at libc > structures and functions (via an FFI mechanism), and several structure > layouts and offsets are hardcoded into its engine at build time. > > For instance, here is the place where the engine determines the offset > of struct dirent's d_name field: > > > https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648 > > Further down in the file, several offsets of fields in struct stats are > similarly determined: > > > https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677 > > Now, since ino64 changed quite a number of structure layouts, including > struct dirent, struct stat, and others, such offsets determined in the > past will no longer be valid! > > It is pretty likely that Firefox will attempt to access these fields, > finding bogus values, or simply reading invalid memory, and crashing > because of this. Or at the least, the behavior will be unstable. > > This also applies to other Mozilla products, such as Thunderbird, > SeaMonkey, and so on. These should all be rebuilt from scratch under > ino64. > > -Dimitry What of machines where for some reason ports do not always build? [ for instance, ones with past workarounds for a failed installworld... ] that still are in critical use daily? And,or where the system has been installed for so long without reinstall that some ports segfault unless 'pkg lock' ... and not usually upgraded... and/or thus using binaries from backup... Are upstream repositories to have those [ browser, email] ports? For instance, here iridium I cannot get to build... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
undefined symbol 'stat'
The latest pkg updates broke firefox here, which won't build [ patches fail to apply ] Also seamonkey, but building sqlite3 locally fixed that. [ not that I'd expect firefox to build anyway, not been that lucky recently... ] Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can find. Subject give the entirety of the error. Building webkit-gtk2 locally as of now to try to fix it in a third round of ports. ... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
ERRATA: 12.0-CURRENT binaries 'stat' errors.
ne /usr/local/bin/ne: Undefined symbol "stat" ktrace -di ne /usr/local/bin/ne: Undefined symbol "stat" I may have posted in error an 'fstat' instead, unsure, to the ports list just yesterday or so. A workaround is to use pkg.freebsd.org to attain compat11x binaries which run. This is a showstopper here otherwise as some large ports, do not build on the legacy desktop [ 2004 ] that has been updated numerous times, and for which I do not wish to reinstall. And, pkg gives conflicting messages, as pkg binaries are shown ABI v12 whereas if I do build from ports, the ports are shown as v11 ABI. Also, ABI changed: 'freebsd:12:x86:32' > 'freebsd:12:*' upgrades are requested making things so I have to lock many ports at v11 as the newer have the 'stat' or 'fstat' error. So more than one issue, I think maybe three in tandem making 'which to tackle first' even problematic. Any advices? even a binary editor to examine the /ne for 'stat' code ? Apologies for not being knowledgeable in many of the ways to code a solution or even coding... ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: ABI confusion: freebsd:12:x86:64 or ABI: freebsd:12:amd64?
On Tue, 3 Oct 2017 10:51:24 +0200, "O. Hartmann" wrote: > When using "poudriere", it seems ABI is freebsd:12:x86:64. When using FreeBSD > base, it > seems always to be referred to FreeBSD:12:amd64. What now? All non-BSD world > uses x86:64, > FreeBSD is using amd64, but why is this used inconsistently all over the > places? > > I run into trouble setting up some package- and base-servers and ran into the > problem > when deleting - not thinking of this discovered inconsistency - some links on > the servers > regarding FreeBSD:12:x86:64 (the same is for 11-STABLE). > > Can someone shed some light onto this? > > What am I supposed to use now? The handbook referes to amd64, so I thought > poudriere > would, too. > > Thanks in advance, > > oh > -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). [ not using poudriere yet ] /me too I think three places [ etc/pkg, /usr/local/etc/pkg/repos, 2nd place in base, ] fourth: hard coded DESPITE the above in the current DB in var/db/pkg? fifth: derived somehow from uname -a? here: freebsd:12:x86:32 ... when this issue resolved, could it please be added to 'man pkg|poudriere|syntch|portmaster?|portupgrade? [ the latter two when developed further ]' ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [FreeBSD-Ports-Announce] Time to bid farewell to the old pkg_ tools
My first post that quotes good: Thunderbird rather than the webmail...
[As this one is about to be send, I see that it is a restate/duplicate
of the one
lost in a webmail glitch ... so apologies...]
On 02/03/14 14:38, Matthew Seaman wrote:
On 03/02/2014 21:24, Julian H. Stacey wrote:
be beneficial in a very short amount of time. Even if you prefer to
compile from source,
I use source, rarely if ever use packages, (except pkg_delete
to remove old broken dependencies). No opinion which scrips are better.
you will still reap the benefits of the modern
packaging system.
In 10.0 FreeBSD `reaped the benefit` of a default new horrible
registry that smells like Microsoft with quasi binary local.sqlite
needing special tools. (Yes I know there's an export function.)
For 2 decade we've poured scorn on Microsoft & its opaque easily
damaged hard to access registry, & lauded how with FreeBSD we can
examine & manipulate & repair our text based equivalent with any
number of personal choice text tools, & now FreeSBD is burdened by
this horrible Microsoft style registry.
You're being absurd. local.sqlite is nothing like the Microsoft
registry[*]. It's a database of all the files etc. that are managed
through the ports system. No more, no less.
... our TEXT based ...
/# find /var/db/pkg -type d -name "p5*" | xargs -J % find -type f -name
"+CONTENTS" -exec grep -H "5.12" {} \; | grep pm | gtr -s \/ "\n" | grep
p5 | sort | uniq | xargs -J % portmaster -d -B -P -i -g % && yell || yell
That pipe, corrected ( the working version includes an incrementing |
head -NN | thru hundreds of p5 upgrades, 15-25 at a time,
so easy completion of the upgrade with
only a repeat with the up arrow and a minor edit ,) handily upgraded a
/perl5/ subdirectory to
the default on several installs.
All we have done is replace an unreliable collection of text files --
hard to keep consistent, impossible to update in an atomic fashion and
woefully pessimal for certain quite legitimate queries
A subset of the above pipe?
-- with a RDBMS,
Which a user may be expected to learn
which quite neatly disposes of those problems. No, it isn't ascii text
which you can grep through.
That here is a source of dismay... less creativity in pipes etc...
It's a set of relational tables, which you
can query using SQL.
That here is also a lessening of the fun.
And that is a deal more powerful in many ways than
grep, but not so familiar to most; so we've provided a scripting
interface in the form pf pkg-query(8).
Do you complain because ZFS doesn't have it's configuration data in some
ascii text files? How about procstat(8)? Or ld.so(1)/ldconfig(8)?
Truth is, unix has always adopted a pragmatic approach to system data
and stored it in whatever form would be most effective. In our case,
we're pretty clear that a relational database is streaks ahead of a
directory tree full of text files.
For those reluctant to switch over, maybe a concurrent
/usr/ports/ports-mgmt/pkg_legacy_tools
Maybe even concurrent installs [both package systems, ] , if they are
both tweaked to be co-existable, and each in
parallel improved over time. What if an urgent upgrade to a server
failed in one method, the
other could "env -i" in , this one "env -i " out, and the upgrade
proceed apace.
Or a command to test which method would work best of on a specific
upgrade, and that pkg system default (the
other backup) until the next "switchover"
Can't do that in " [ insert other favorite operating system here ]... "
Cheers,
Matthew
J. Bouquet
___
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 fails build on v9-STABLE ... LOG attached (long)
Tried pasting the error, it was all one huge paragraph, not lines... Sorry. It built once, skipping past this error. Almost always fails. ___ 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"
