Re: upgrading ports with a lot of dependencies
On 26/08/2012 06:40, Jim Pazarena wrote: My question is a general one, with the following specific example. I wanted to re-compile the latest phpmyadmin but when I tried that, I get a you must have the latest php5 (5.4.6) The phpMyAdmin port only imposes the restriction that you must be running at least version 5 of php. It should work fine with any of lang/php5, lang/php53 or lang/php52. However, if you already had lang/php5 installed from a few months ago, that would predate the switch of that port from php 5.3.x to 5.4.x. This change did necessitate recompiling and reinstalling anything php dependent. Except that there is an alternative: you could switch to using lang/php53 instead. Unfortunately there are no instructions on how to do that without reinstalling everything in /usr/ports/UPDATING: it involves rewriting dependency information stored in /var/db/pkg and other somewhat risque manipulation of port metadata. Unless you know exactly what you're doing, a full-blown upgrade of php is more likely to give you a good result. when I try php5 I get a dependency of devel/pkgconf when I compile pkgconf, it conflicts with devel/pkg-config Now, this one is covered in UPDATING -- the 20120726 entry to be precise. Follow the instructions there, and you can avoid mass-reinstallation of everything that uses pkg-config / pkgconf (which is basically just about everything.) Upon investigation it looks like pkg-config is replaced with pkgconf however attempting to remove it show dozens of dependencies preventing the removal. I find this series of challenges frequently as installs move along in age, and usually wind up re-loading the entire server to beat the challenge. There must be an easier way. Advice would be greatly appreciated. It's a lot easier if you update your system more frequently. Meaning each update will be smaller and you're less likely to run into a stack of problems all needing to be solved at once. Fortnightly or monthly updates should be sufficient. Also, get in the habit of reading /usr/ports/UPDATING -- it tells you about most of the gotchas, and more importantly, how to deal with them without having to nuke-and-repave. Finally, yes, this is an area where FreeBSD ends up consuming lots of time and CPU power. You might consider trying out pkgng (http://wiki.freebsd.org/pkgng), which is being developed as a solution to this and other problems. pkgng is just coming up to release-1.0: the code is in pretty good shape, but the infrastructure to support general use isn't in place yet. To get round that, try out poudriere as a way of building pkgs off-line and maintaining your own pkgng repository. pkgng makes upgrading even large numbers of ports very much faster. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
INDEX build failed for 7.x
INDEX build failed with errors: Generating INDEX-7 - please wait.. Done. make_index: linux-huludesktop-0.9.8_2: no entry for /usr/ports/www/linux-f10-flashplugin10 Committers on the hook: bsam rene Most recent CVS update was: U www/Makefile U www/web2ldap/Makefile U www/web2ldap/distinfo U www/web2ldap/pkg-plist U x11-wm/Makefile ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD port: stellarium 0.11.4
Hi! 2012/8/26 Alexander Wolf alex.v.w...@gmail.com: Today has been released Stellarium 0.11.4 with improvements for *BSD systems. I'm sorry but we fixed two stupid typos and re-upload source code - stellarium-0.11.4a.tar.gz -- With best regards, Alexander ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sat, Aug 25, 2012 at 06:34:43PM -0500, CyberLeo Kitsana wrote: On 08/24/2012 07:01 PM, Baptiste Daroussin wrote: Can anyone give me he details on the security related problem? Off the top of my head, it seems to represent a break in the chain of trust: how does the bootstrapper verify that the tarball it just downloaded to bootstrap pkg is genuine, and not, for example, a trojan? The source in usr.sbin/pkg/pkg.c[1] doesn't seem to suggest it cares. Indeed it does not care, and the current security features are insufficient (unless the bootstrapper can use the signed sqlite db to verify the pkg package). I think the fix is to modify 'pkg repo' so it detects the pkg package and creates a separate signature for it which can be verified by the bootstrapper, without needing sqlite. The public key for this signature will have to be distributed with base (like the public keys for freebsd-update and portsnap). -- Jilles Tjoelker ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, Aug 26, 2012 at 02:26:50PM +0200, Jilles Tjoelker wrote: On Sat, Aug 25, 2012 at 06:34:43PM -0500, CyberLeo Kitsana wrote: On 08/24/2012 07:01 PM, Baptiste Daroussin wrote: Can anyone give me he details on the security related problem? Off the top of my head, it seems to represent a break in the chain of trust: how does the bootstrapper verify that the tarball it just downloaded to bootstrap pkg is genuine, and not, for example, a trojan? The source in usr.sbin/pkg/pkg.c[1] doesn't seem to suggest it cares. Indeed it does not care, and the current security features are insufficient (unless the bootstrapper can use the signed sqlite db to verify the pkg package). I think the fix is to modify 'pkg repo' so it detects the pkg package and creates a separate signature for it which can be verified by the bootstrapper, without needing sqlite. The public key for this signature will have to be distributed with base (like the public keys for freebsd-update and portsnap). The is the longer plan but this with also true with pkg_add -r, and the pkg bootstrap may it be pkg-bootstrap or /usr/sbin/pkg. We have been discussing with Security officers and we are waiting for the plan being written and setup by them, so we can improved security in both pkgng and the bootstrap. This should have happen in BSDCan, but lack of time from everyone, didn't made it happen, we are now aiming at Cambridge DevSummit for that. Given that such a security issue is already in with the current pkg_* tools, it was accepting that we can still go that way until the policy is written, given that the final goal is to have the pkgng package checked against a signature. regards, Bapt pgpEF920EdyX3.pgp Description: PGP signature
INDEX now builds successfully on 7.x
___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/25/2012 02:49, Julien Laffaye wrote: True. But when you create jails without the installer, you have to install pkgng by hand. Just like all the other ports you have to install in a jail. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, Aug 26, 2012 at 11:34:08AM -0700, Doug Barton wrote: On 08/25/2012 02:49, Julien Laffaye wrote: True. But when you create jails without the installer, you have to install pkgng by hand. Just like all the other ports you have to install in a jail. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) We are speaking about binary only packages, not ports. regards, Bapt pgps40PW8Thqu.pgp Description: PGP signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/26/2012 11:37, Baptiste Daroussin wrote: On Sun, Aug 26, 2012 at 11:34:08AM -0700, Doug Barton wrote: On 08/25/2012 02:49, Julien Laffaye wrote: True. But when you create jails without the installer, you have to install pkgng by hand. Just like all the other ports you have to install in a jail. We are speaking about binary only packages, not ports. Um, duh. I have a bad habit of using the terms interchangeably, sorry if I caused confusion. Doesn't change my actual point though. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/26/2012 05:58, Baptiste Daroussin wrote: The is the longer plan but this with also true with pkg_add -r, and the pkg bootstrap may it be pkg-bootstrap or /usr/sbin/pkg. We have been discussing with Security officers and we are waiting for the plan being written and setup by them, so we can improved security in both pkgng and the bootstrap. This should have happen in BSDCan, but lack of time from everyone, didn't made it happen, we are now aiming at Cambridge DevSummit for that. It would be nice if this were in place before 10-current shifted to pkg by default in order to limit the number of times that we have to start testing over from scratch. Given that such a security issue is already in with the current pkg_* tools, it was accepting that we can still go that way until the policy is written, given that the final goal is to have the pkgng package checked against a signature. This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, Aug 26, 2012 at 11:39:07AM -0700, Doug Barton wrote: On 08/26/2012 05:58, Baptiste Daroussin wrote: The is the longer plan but this with also true with pkg_add -r, and the pkg bootstrap may it be pkg-bootstrap or /usr/sbin/pkg. We have been discussing with Security officers and we are waiting for the plan being written and setup by them, so we can improved security in both pkgng and the bootstrap. This should have happen in BSDCan, but lack of time from everyone, didn't made it happen, we are now aiming at Cambridge DevSummit for that. It would be nice if this were in place before 10-current shifted to pkg by default in order to limit the number of times that we have to start testing over from scratch. Given that such a security issue is already in with the current pkg_* tools, it was accepting that we can still go that way until the policy is written, given that the final goal is to have the pkgng package checked against a signature. This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. I received more feedback about keep pkg and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? regards, Bapt pgpnisowrHYbh.pgp Description: PGP signature
Re: portmaster 3.13.13 real endless loop Waiting on fetch checksum..
On 08/25/2012 16:58, G. Paul Ziemba wrote: The second scenario exhibits the problem. Here, I delete the distfile and just run portmaster without -F. The fetch completes, but portmaster does not seem to notice. Can you try that second test again, and add -D to the command line? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/26/2012 11:58, Baptiste Daroussin wrote: On Sun, Aug 26, 2012 at 11:39:07AM -0700, Doug Barton wrote: On 08/26/2012 05:58, Baptiste Daroussin wrote: The is the longer plan but this with also true with pkg_add -r, and the pkg bootstrap may it be pkg-bootstrap or /usr/sbin/pkg. We have been discussing with Security officers and we are waiting for the plan being written and setup by them, so we can improved security in both pkgng and the bootstrap. This should have happen in BSDCan, but lack of time from everyone, didn't made it happen, we are now aiming at Cambridge DevSummit for that. It would be nice if this were in place before 10-current shifted to pkg by default in order to limit the number of times that we have to start testing over from scratch. Given that such a security issue is already in with the current pkg_* tools, it was accepting that we can still go that way until the policy is written, given that the final goal is to have the pkgng package checked against a signature. This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. I received more feedback about keep pkg As far as I could tell the people who responded that way don't seem to be aware that every command to /usr/local/sbin/pkg is going to pass through /usr/sbin/pkg. On its face, that is a bad idea for many reasons, not the least of which is that it adds complexity where that complexity does not need to be. The larger problem with that approach is that gives an attacker 2 places to compromise the package installation process instead of just 1. This becomes even more important if the pkg bootstrap tool is the place that the public key for the digital signature is located. and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? A) You said you had no objections to changing it B) I'm not the only one asking Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, 2012-08-26 at 20:58 +0200, Baptiste Daroussin wrote: On Sun, Aug 26, 2012 at 11:39:07AM -0700, Doug Barton wrote: On 08/26/2012 05:58, Baptiste Daroussin wrote: This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. I received more feedback about keep pkg and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? Would this get better if the bootstrap tool were named pkg and were installed on a fresh system at /usr/local/sbin, so that it in effect replaces itself with the real thing, and has no need to leave a forwarding stub in /usr/sbin ? Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of replacing itself, so that you could re-bootstrap your way out of a problem later. Hmmm, might have to be careful that future updates don't replace the real thing with a newer bootstrap program. -- Ian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/26/2012 12:08, Ian Lepore wrote: Would this get better if the bootstrap tool were named pkg and were installed on a fresh system at /usr/local/sbin, so that it in effect replaces itself with the real thing, and has no need to leave a forwarding stub in /usr/sbin ? Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of replacing itself, so that you could re-bootstrap your way out of a problem later. That's certainly creative thinking, but I'm still queasy about 2 commands with the same name that do 2 different things. And having it rename itself adds to the confusion down the road. Having a simple pkg bootstrapping tool in the base is a good idea. But the functionality needs to be extremely limited so that we don't increase the security exposure; and so that we don't end up in a situation where a bug fix for something in the base limits our ability to innovate with pkg in the ports tree. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Cannot upgrade php5-simplexml
On 08/24/2012 11:37, Lars Eighner wrote: I can't seem to upgrade textproc/php5-simplexml because the existing version has no recorded origin. pkg_delete won't delete it. pkgdb -F doesn't seem to detect anything wrong. deinstall doesn't work. Remove the associated directory in /var/db/pkg by hand, then you can install the port. -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, 26 Aug 2012, Ian Lepore wrote: On Sun, 2012-08-26 at 20:58 +0200, Baptiste Daroussin wrote: On Sun, Aug 26, 2012 at 11:39:07AM -0700, Doug Barton wrote: On 08/26/2012 05:58, Baptiste Daroussin wrote: This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. I received more feedback about keep pkg and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? Would this get better if the bootstrap tool were named pkg and were installed on a fresh system at /usr/local/sbin, so that it in effect replaces itself with the real thing, and has no need to leave a forwarding stub in /usr/sbin ? Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of replacing itself, so that you could re-bootstrap your way out of a problem later. Ew. But on a similar note, an idea I just had in IRC is to have pkgng overwrite the base /usr/bin/pkg with a link to /usr/local/bin/pkg. That effectively removes that binary. We do have precedent for ports overwriting base with sendmail and openssl. Hmmm, might have to be careful that future updates don't replace the real thing with a newer bootstrap program. Yes. A link could be detected by installworld and not overwritten... although that's a hack. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 08/26/2012 13:35, Warren Block wrote: On Sun, 26 Aug 2012, Ian Lepore wrote: On Sun, 2012-08-26 at 20:58 +0200, Baptiste Daroussin wrote: On Sun, Aug 26, 2012 at 11:39:07AM -0700, Doug Barton wrote: On 08/26/2012 05:58, Baptiste Daroussin wrote: This isn't the security issue I was talking about by having sbin/pkg pass every command line to local/sbin/pkg. You keep saying that you have no objections to changing the name. I am asking you to do that. I don't care if it is pkg-bootstrap or something else you like better. But please change the name to not be pkg, and limit the functionality of the tool to bootstrapping the pkg package. I received more feedback about keep pkg and changing it to pkg-bootstrap, so what should I do, changing it because you are asking for it? Would this get better if the bootstrap tool were named pkg and were installed on a fresh system at /usr/local/sbin, so that it in effect replaces itself with the real thing, and has no need to leave a forwarding stub in /usr/sbin ? Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of replacing itself, so that you could re-bootstrap your way out of a problem later. Ew. But on a similar note, an idea I just had in IRC is to have pkgng overwrite the base /usr/bin/pkg with a link to /usr/local/bin/pkg. That effectively removes that binary. We do have precedent for ports overwriting base with sendmail and openssl. ... and bind, but that's a whole different category of problems. Hmmm, might have to be careful that future updates don't replace the real thing with a newer bootstrap program. Yes. A link could be detected by installworld and not overwritten... although that's a hack. Like you said above, Ew. :) There really is no need to be so clever here. The bootstrapping issue is going to be a minor annoyance that affects a small percentage of our users. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Regression in PREFIX handling in packages
Hi, I detected a regression in the handling of the registration of the PREFIX in packages. I'm not sure when it was introduced, surely more than a month ago. The problem: - I have a symlink from /usr/local to another place X. - I share packages between this system A and some jails. - The jails don't have place X and /usr/local is no symlink. - Packages generated on the system A are installed into place X in the jails. So in short: the realpath of PREFIX is recorded in the packages, not the value of PREFIX as before. I had a quick look at bsd.*.mk, but didn't notice something obvious. So in case it is pkg_create which is doing this, I updated from r238438 to r239708. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Regression in PREFIX handling in packages
On 8/26/2012 3:54 PM, Alexander Leidinger wrote: Hi, I detected a regression in the handling of the registration of the PREFIX in packages. I'm not sure when it was introduced, surely more than a month ago. Are you using any tools for managing these packages? portmaster, portupgrade? Or just pkg_add -r? The problem: - I have a symlink from /usr/local to another place X. - I share packages between this system A and some jails. - The jails don't have place X and /usr/local is no symlink. - Packages generated on the system A are installed into place X in the jails. So in short: the realpath of PREFIX is recorded in the packages, not the value of PREFIX as before. I had a quick look at bsd.*.mk, but didn't notice something obvious. So in case it is pkg_create which is doing this, I updated from r238438 to r239708. Bye, Alexander. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Can we please just remove the old Makefile headers?
The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On 8/26/2012 4:02 PM, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please. If we can't agree to mass delete them with churn, let's at least agree to remove as we update ports, and in the template for new ports. Doug -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On 26 August 2012 22:04, Bryan Drewery br...@shatow.net wrote: On 8/26/2012 4:02 PM, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please. If we can't agree to mass delete them with churn, let's at least agree to remove as we update ports, and in the template for new ports. Now in the days of Subversion... we could do the entire tree in one lovely atomic commit! Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
Am 26.08.2012 23:06, schrieb Chris Rees: On 26 August 2012 22:04, Bryan Drewery br...@shatow.net wrote: On 8/26/2012 4:02 PM, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please. If we can't agree to mass delete them with churn, let's at least agree to remove as we update ports, and in the template for new ports. Now in the days of Subversion... we could do the entire tree in one lovely atomic commit! I'm not too sure if we should do that. The server-side changeset would be of humongous size. (OTOH that's a nice test for the infrastructure - but if it breaks, we're in for trouble). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can we please just remove the old Makefile headers?
On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote: The old Makefile headers, ala: # New ports collection makefile for:BIND 9.9.x # Date created: 27 January 2012 # Whom: dougb # # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $ have not served a purpose for longer than almost anyone who has a ports commit bit has been around. My proposal is simple, let's remove everything before the # $FreeBSD$. In the past when this has been proposed the objection was that it would cause too much churn. If we had done this back when we had 5,000 ports then we would have solved the problem with less churn, and no drama for the 15,000 ports that followed. Every day we don't do this we make the churn problem worse, and deepen the roots of something that has no relevance. Can we please just deal with this now and be done with it? ... and yes, I am volunteering to help with and/or do the work myself. Yes please! We've got a nice repository that stores all the data in question much more accurately than a silly header. -- Brooks pgppCJv0YgbyO.pgp Description: PGP signature
Re: Can we please just remove the old Makefile headers?
On Sun, Aug 26, 2012 at 11:04 PM, Bryan Drewery br...@shatow.net wrote: If we can't agree to mass delete them with churn, let's at least agree to remove as we update ports, and in the template for new ports. as we update ports Hear hear! The only sensible suggestion about how to handle it so far, IMHO. -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On 2012-Aug-26 12:27:41 -0700, Doug Barton do...@freebsd.org wrote:
On 08/26/2012 12:08, Ian Lepore wrote:
Maybe it could rename itself to /usr/local/sbin/pkg-bootstrap as part of
replacing itself, so that you could re-bootstrap your way out of a
problem later.
That's certainly creative thinking, but I'm still queasy about 2
commands with the same name that do 2 different things. And having it
rename itself adds to the confusion down the road.
I also like the idea of a pkg-bootstrap command. Possibly a symlink
from pkg to pkg-bootstrap, that gets removed as part of the bootstrap
process, would help - but it should just tell you how to run
pkg-bootstrap. I don't like the idea of pkg{-bootstrap} autonomously
installing something I didn't ask for. And I don't like the idea that
all pkg commands get bounced through a /usr/sbin/pkg once it has been
bootstrapped.
Having a simple pkg bootstrapping tool in the base is a good idea. But
the functionality needs to be extremely limited so that we don't
increase the security exposure; and so that we don't end up in a
situation where a bug fix for something in the base limits our ability
to innovate with pkg in the ports tree.
Agreed. BTW, one thing that needs to be considered is how to recover
from the embedded public key needing to be invalidated (eg due to the
private key being exposed).
--
Peter Jeremy
pgpvdn7KHnqSv.pgp
Description: PGP signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Sun, 26 Aug 2012, Doug Barton wrote:
...
There really is no need to be so clever here. The bootstrapping issue is
going to be a minor annoyance that affects a small percentage of our users.
I think Doug's correct in this case about it being a one-time
problem as installing via bsdinstall, etc should take care of this (I
disagree with the small percentage of our users part though). There's
still a chicken and egg problem with installing packaging via bsdinstall,
etc though, as ports requires pkg* in order to function; I really hope
that some of the naysayers have considered this minor issue as this
would be a stop-gap to removing pkg(8) from base.
Rather than providing a solution for that problem because that's a
bigger architectural issue (and not my job to solve), I offer this patch I
quickly hacked up instead as my 2 cents for the discussion on how to make
users aware that pkg_install is dying/dead, as this is one case that
needs to be better handled.
Thanks,
-Garrett
PS It's really sad that no one really has been updating UPDATING in either
ports or src, as I think this would help alleviate the need for
unnecessary obfuscation.
Index: UPDATING
===
--- UPDATING(revision 239716)
+++ UPDATING(working copy)
@@ -24,6 +24,10 @@
disable the most expensive debugging functionality run
ln -s 'abort:false,junk:false' /etc/malloc.conf.)
+2014:
+ pkg_install has been replaced with pkgng; please see webpage
+ XXX/install port YYY for more details.
+
20120727:
The sparc64 ZFS loader has been changed to no longer try to auto-
detect ZFS providers based on diskN aliases but now requires these
Index: usr.sbin/pkg_install/version/main.c
===
--- usr.sbin/pkg_install/version/main.c (revision 239290)
+++ usr.sbin/pkg_install/version/main.c (working copy)
@@ -123,6 +123,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
return pkg_perform(argv);
}
Index: usr.sbin/pkg_install/add/main.c
===
--- usr.sbin/pkg_install/add/main.c (revision 239290)
+++ usr.sbin/pkg_install/add/main.c (working copy)
@@ -215,6 +215,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
if (AddMode != SLAVE) {
pkgs = (char **)malloc((argc+1) * sizeof(char *));
for (ch = 0; ch = argc; pkgs[ch++] = NULL) ;
Index: usr.sbin/pkg_install/info/main.c
===
--- usr.sbin/pkg_install/info/main.c(revision 239290)
+++ usr.sbin/pkg_install/info/main.c(working copy)
@@ -238,6 +238,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
if (Flags SHOW_PTREV) {
if (!Quiet)
printf(Package tools revision: );
Index: usr.sbin/pkg_install/delete/main.c
===
--- usr.sbin/pkg_install/delete/main.c (revision 239290)
+++ usr.sbin/pkg_install/delete/main.c (working copy)
@@ -128,6 +128,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
/* Get all the remaining package names, if any */
while (*argv) {
/* Don't try to apply heuristics if arguments are regexs */
Index: usr.sbin/pkg_install/create/main.c
===
--- usr.sbin/pkg_install/create/main.c (revision 239290)
+++ usr.sbin/pkg_install/create/main.c (working copy)
@@ -229,6 +229,8 @@
argc -= optind;
argv += optind;
+PKG_PORTS_MSG();
+
/* Get all the remaining package names, if any */
while (*argv)
*pkgs++ = *argv++;
Index: usr.sbin/pkg_install/lib/lib.h
===
--- usr.sbin/pkg_install/lib/lib.h (revision 239290)
+++ usr.sbin/pkg_install/lib/lib.h (working copy)
@@ -31,6 +31,7 @@
#include sys/utsname.h
#include ctype.h
#include dirent.h
+#include err.h
#include stdarg.h
#include stdio.h
#include stdlib.h
@@ -239,4 +240,33 @@
extern int AutoAnswer;
extern int Verbose;
+#defineEOL_VERSION 1100
+
+#definePKG_INSTALL_DEPRECATION_MSG \
+ pkg_install has been deprecated in favor of pkgng; please see UPDATING for
more details
+
+#if __FreeBSD_version EOL_VERSION
+
+#define PKG_PORTS_MSG() \
+do { \
+ if (Quiet) { \
+ exit(1); \
+ } else { \
+ warnx(PKG_INSTALL_DEPECATION_MSG); \
+ } \
+} while (0)
+
+#else
+
+#define PKG_PORTS_MSG() \
+do { \
+ if (Quiet) { \
+ exit(1); \
+ } else { \
+ errx(1, PKG_INSTALL_DEPRECATION_MSG); \
+ } \
+} while (0)
+
+#endif /* __FreeBSD_version EOL_VERSION */
+
#endif /* _INST_LIB_LIB_H_ */
Index: usr.sbin/pkg_install/updating/main.c
Re: Cannot upgrade kdesdk-4.7.4_1 to 4.8.4
I had the same problem the only solution I could find after 2 weeks of upgrading de-installing and reinstalling was simply to not install KDESDK from the KDE 4.8.4 installer -- View this message in context: http://freebsd.1045724.n5.nabble.com/Cannot-upgrade-kdesdk-4-7-4-1-to-4-8-4-tp5729386p5738258.html Sent from the freebsd-ports mailing list archive at Nabble.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
