Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
From: Thomas Mueller mueller6...@bellsouth.net To: freebsd-ports@freebsd.org Subject: Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing There are many messages on this thread, and I don't know which or what to quote, but I agree on send-pr being user-unfriendly. I disagree. I use only send-pr to send PRs. I use sendmail. For later analysis and search I use the web interface. Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ruBSD 2013 pkg talk report
On Wed, Dec 18, 2013 at 12:13:44AM +, Vsevolod Stakhov wrote: Hello, I'd like to summarize the feedback I've received from pkg users during that event. I got many questions about ports and packages and I think that questions are useful for the overall pkg development. First thank you for having given that presentation and for this feedback! The most of questions were related to options and base system: Q: What if I have a package built from ports with some custom options and a repository has newer package but with different set of options? A: I proposed to skip updating such a package from binary repo, but initiate its building from ports directly (assuming that ports uses pkg for dependency/conflicts resolving). That sounds reasonable and seems to be very convenient for an end user. Right now I would recommand to pkg lock the said package. The other solution would be to create a home made repository and say to pkg that the said package can only be upgraded from that repository. The other solution would be to extend the plugin system of pkg to get plugable repository system and create a portstree plugin that build directory the ports to update it, and will respect pkg annotate -A repository but this depends on the ports using pkg for dependency/conflict resolution and that will be quite tough to do. Q: What if I have a system with some build options that are not compatible with binary packages, e.g. DISABLE_IPV6. A: I think it is useful to have a special metafile for each repo that describes compatible systems, including not merely ABI, but a specific set of non-compatible options. The alternative is to create virtual base system packages (e.g. kernel-noipv6), that may be placed in the dependencies list. the useful things would be to extend imho the system to depend on symbols being able to create smart provides (based on symbols) and smart requires (need a libbla.so with (bla_ipv6 function) this is doable but tough as well (any idea welcome here) Q: What if I have my own custom repo that has older software but with my local patches. A: I suggested to assign a priority to each repo and never replace packages from a high priority repo by packages from low priority repo. That should fix this request. We need priorities, we do not have it yet, beside that you can use pkg annotate -A repository to say a package can only be upgraded from a given repository. Q: What about portupgrade and other related tools? A: I claimed that these tools are going to be deprecated and packages will be managed from pkg even if you want to build a custom package from the sources. I agree with that beside pkg will never know directly how to build from the ports tree, but a plugin can do it. (pkg should remain package building system agnostic) Q: Why have you chosen SAT and not X/Y or Z? A: SAT provides mathematically proved basis for the whole problem and it is much simpler to extend some proved base than to invent the wheel trying to solve the specific problem. +1 Q: Why haven't you chosen other solutions? A: We have 28K ports and it is literally impossible to adopt each port to some external system. Therefore we plan to migrate to the new world smoothly by adding new features to SAT algorithm. +1 Q: It seems that all these improvements are only in development or projected state. A: Indeed, many of these features are not yet implemented. Unfortunately, pkg system requires more developers than there is now and we appreciate any help in improving pkg to make our packages system better :) +1 I would like to add here that lots of things like vsevolod's sat solver are tough to incorporate because we first need to workaround (and fix) lots of problem in the ports tree, he has done a really fantastic work on the solver we really need it, but to go in that direction we will need to: 1 fix https://wiki.freebsd.org/ports/PkgNameCollisions 2 face a very complicated migration from ORIGIN to pkgname and unique identifier internally. The choice to continue with the ports tree was a good and reasonable choice, but it also have a huge price. regards, Bapt pgp93pnSqVeit.pgp Description: PGP signature
Re: ruBSD 2013 pkg talk report
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/12/13 11:19, Baptiste Daroussin wrote: On Wed, Dec 18, 2013 at 12:13:44AM +, Vsevolod Stakhov wrote: Hello, Q: What if I have a package built from ports with some custom options and a repository has newer package but with different set of options? A: I proposed to skip updating such a package from binary repo, but initiate its building from ports directly (assuming that ports uses pkg for dependency/conflicts resolving). That sounds reasonable and seems to be very convenient for an end user. Right now I would recommand to pkg lock the said package. The other solution would be to create a home made repository and say to pkg that the said package can only be upgraded from that repository. The other solution would be to extend the plugin system of pkg to get plugable repository system and create a portstree plugin that build directory the ports to update it, and will respect pkg annotate -A repository but this depends on the ports using pkg for dependency/conflict resolution and that will be quite tough to do. I still think that this functionality should be essential for pkg. For example, I've built vim package with motiff, and I have no chance to upgrade it from pkg repo. Hence, the proper choice is to let ports to do this stuff (since we plan ports to use pkg solver for dependencies resolution). Certainly, we should not stick to /usr/ports and make being hardcoded, but this should be provided out of the box for FreeBSD. Q: What if I have a system with some build options that are not compatible with binary packages, e.g. DISABLE_IPV6. A: I think it is useful to have a special metafile for each repo that describes compatible systems, including not merely ABI, but a specific set of non-compatible options. The alternative is to create virtual base system packages (e.g. kernel-noipv6), that may be placed in the dependencies list. the useful things would be to extend imho the system to depend on symbols being able to create smart provides (based on symbols) and smart requires (need a libbla.so with (bla_ipv6 function) this is doable but tough as well (any idea welcome here) It is very, very dangerous way to do it in this way. Remember all those dlopen and LD_PRELOAD stuff which would definitely break everything. From my sense, the base system and kernel should generate virtual packages that contains specific options. Then we may deal with them in an ordinary way. Q: What if I have my own custom repo that has older software but with my local patches. A: I suggested to assign a priority to each repo and never replace packages from a high priority repo by packages from low priority repo. That should fix this request. We need priorities, we do not have it yet, beside that you can use pkg annotate -A repository to say a package can only be upgraded from a given repository. Q: What about portupgrade and other related tools? A: I claimed that these tools are going to be deprecated and packages will be managed from pkg even if you want to build a custom package from the sources. I agree with that beside pkg will never know directly how to build from the ports tree, but a plugin can do it. (pkg should remain package building system agnostic) See above: I think that pkg should have some abstract build system interface with plugins to concrete ones. Q: Why have you chosen SAT and not X/Y or Z? A: SAT provides mathematically proved basis for the whole problem and it is much simpler to extend some proved base than to invent the wheel trying to solve the specific problem. +1 Q: Why haven't you chosen other solutions? A: We have 28K ports and it is literally impossible to adopt each port to some external system. Therefore we plan to migrate to the new world smoothly by adding new features to SAT algorithm. +1 Q: It seems that all these improvements are only in development or projected state. A: Indeed, many of these features are not yet implemented. Unfortunately, pkg system requires more developers than there is now and we appreciate any help in improving pkg to make our packages system better :) +1 I would like to add here that lots of things like vsevolod's sat solver are tough to incorporate because we first need to workaround (and fix) lots of problem in the ports tree, he has done a really fantastic work on the solver we really need it, but to go in that direction we will need to: 1 fix https://wiki.freebsd.org/ports/PkgNameCollisions 2 face a very complicated migration from ORIGIN to pkgname and unique identifier internally. The choice to continue with the ports tree was a good and reasonable choice, but it also have a huge price. Actually, my solver uses origins as well at the moment. So if pkgname conversion is too though then we may try to start with the solver merging (which is a complicated task anyway). - -- Vsevolod Stakhov -BEGIN PGP
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ editors/texmacs | 1.0.7.14| 1.99.1 +-+ net-im/turpial | 1.6.9 | 3.0 +-+ www/xist| 3.25| 5.4.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. So, the fault is on our side. Why should we spam GNATS with our problem? GNATS for confirmed problems, the list for anything else. Where is this cited? PRs are not for confirmed problems. They are for any problem. However, this kind of confirmation post is not the type of post I was complaining about. Unless your confirmation is no more than an except of a log, then it is. To iterate my opinion, if a breakage is a symptom of a systematic issue, or the port in question breaks like 6000 dependent ports, the ports@ is appropriate. If it's a single broken port, then a PR is appropriate. Alternatively, email the maintainer only. The majority of us on this list do not care about individual broken ports and getting a sent a log is noise at best. John ___ 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] xorg version switch in CURRENT
On 12/17/13 17:28, Aleksandr Rybalko wrote: On 18.12.2013 01:27, Nathan Whitehorn wrote: On 12/17/13 15:32, Aleksandr Rybalko wrote: On Tue, 17 Dec 2013 14:12:05 -0600 Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 12/17/13 14:07, Steve Kargl wrote: On Mon, Dec 16, 2013 at 12:20:53PM +0100, Niclas Zeising wrote: To get VT switching when using KMS drivers (ATI, Intel) please use newcons: https://wiki.freebsd.org/Newcons or if that is not possible, force the use of the vesa driver for xorg. It appears that newcons is unusable with a static kernel. Adding 'device drm2' and 'device i915kms' to my kernel config results in a quick death to 'make buldkernel'. You may not want it either. The radeon KMS driver, if loaded with newcons before X, replaces your console with snow (or at least it did the last time I tried it). Nathan, on which h/w you did that test? 3 different systems with Intel graphic works fine for me. This is on the following graphics card on amd64: vgapci0@pci0:3:0:0: class=0x03 card=0x10022f43 chip=0x95cc1002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV620 [ATI FireGL V3700]' I'll run the test again today or tomorrow and see if it still happens. -Nathan Please do. Thanks! Still gives beautiful snow with r259418. I'll be traveling the next 3 weeks and won't be able to test for that period. -Nathan ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
Hi, On Thu, 19 Dec 2013 14:04:10 +0100 John Marino freebsd.cont...@marino.st wrote: On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. so, you want to say, that all the little problems which are solved mainly by people who are not the maintainer should become PRs? So, the fault is on our side. Why should we spam GNATS with our problem? GNATS for confirmed problems, the list for anything else. Where is this cited? PRs are not for confirmed problems. They are for any problem. However, this kind of confirmation post is not the type of post I was complaining about. Unless your confirmation is no more than an except of a log, then it is. To iterate my opinion, if a breakage is a symptom of a systematic issue, or the port in question breaks like 6000 dependent ports, the ports@ is appropriate. If it's a single broken port, then a PR is appropriate. Alternatively, email the maintainer only. The majority of us on this list do not care about individual broken ports and getting a sent a log is noise at best. The sender of an e-mail does not need the majority but a single individual with the proper hint. Erich ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/19/2013 14:41, Erich Dollansky wrote: Hi, On Thu, 19 Dec 2013 14:04:10 +0100 John Marino freebsd.cont...@marino.st wrote: On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. so, you want to say, that all the little problems which are solved mainly by people who are not the maintainer should become PRs? Yes, that's the point. The GNATs system hold searchable information for others that care: A) A PR has already been filed B) A fix may already be proposed C) The state of the fix D) Whether the maintainer is delinquent. After a timeout (two weeks) other maintainers can take over any submitted fix. Without a PR, we don't know the port maintainer is delinquent, so we assume he/she is not. You have to submit the PR to start to two-week countdown. E) Many improvements come from people that are not maintainers. The sender of an e-mail does not need the majority but a single individual with the proper hint. For the reasons above, a PR is still better. The rest of us have visibility if we care, and the maintainer still gets an email from the GNATS system. John ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 19/12/13 21:41 +0800, Erich Dollansky wrote: Hi, On Thu, 19 Dec 2013 14:04:10 +0100 John Marino freebsd.cont...@marino.st wrote: On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. so, you want to say, that all the little problems which are solved mainly by people who are not the maintainer should become PRs? IMHO, it's the only way to reach quality in the port tree with a very accurate traceability. regards, - rodrigo ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
Hi, On Thu, 19 Dec 2013 14:46:41 +0100 Rodrigo Osorio rodr...@bebik.net wrote: On 19/12/13 21:41 +0800, Erich Dollansky wrote: Hi, On Thu, 19 Dec 2013 14:04:10 +0100 John Marino freebsd.cont...@marino.st wrote: On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. so, you want to say, that all the little problems which are solved mainly by people who are not the maintainer should become PRs? IMHO, it's the only way to reach quality in the port tree with a very accurate traceability. you want to say i.e. all the e-mails regarding the switch to KMS supported X should be PRs just because the writer did not read UPDATING and the other sources? I think that this can easily handled here without any PR. Erich ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 19/12/13 22:09 +0800, Erich Dollansky wrote: Hi, On Thu, 19 Dec 2013 14:46:41 +0100 Rodrigo Osorio rodr...@bebik.net wrote: On 19/12/13 21:41 +0800, Erich Dollansky wrote: Hi, On Thu, 19 Dec 2013 14:04:10 +0100 John Marino freebsd.cont...@marino.st wrote: On 12/19/2013 06:54, Erich Dollansky wrote: you got the point. We have to assume that a port which is not marked broken has to work. I build the entire port tree several times a month. I can tell you from experience that this assumption is not valid. so, you want to say, that all the little problems which are solved mainly by people who are not the maintainer should become PRs? IMHO, it's the only way to reach quality in the port tree with a very accurate traceability. you want to say i.e. all the e-mails regarding the switch to KMS supported X should be PRs just because the writer did not read UPDATING and the other sources? I think that this can easily handled here without any PR. Erich I don't think ocular problems are in my skillsbut... why not, specially if they think there is a real problem with a port. I'm not saying PR is the only, mandatory, way to solve problems. You can talk about a problem in forums,ml, wathever, but if a fix is required it's better to report it as a PR. PR are bette in many ways, with a PR, a problem is - most of the time - assigned to someone so you can complain if nothing is done, in a ML, if nobody cares, there is no problem. obviously, sumarize a problem takes or found a solution takes more time than shoot a this port doesn't work email. - rodrigo ___ 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
radeonhd driver DEPRECATED?
Or so the Makefile says. What's the canonical replacement? Respectfully, Robert Huff ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/17/2013 4:33 PM, John Marino wrote: Over the months I've seen several ports users copy a failure log and mail it to ports@, usually without even saying hello. I've tried to discourage that behavior but other members of this mail list encourage this method of bypassing writing PRs. One user even proudly boasted that sending email to ports@ is faster than writing a PR so of course he was going to do that instead. If this kind of post is acceptable to the rest of the people here, and I'm alone in not only finding it very rude, but also making the volume of ports@ too high, then please tell me that the problem is with me. If nothing is going to change, I am going to unsubscribe from ports@ list. The gcc developers on g...@gcc.gnu.org always tell a poster when a post in appropriate for that list and as a result and as a result the posters usually only make a mistake once. I'd like to see something closer to that, but if the list isn't going to be policed then it's too noisy for me. John I sincerely disagree and think it's quite rude to users to not accept their reports however they send them to us. current@ constantly has build failures on it, even automated. There's no reason ports@ shouldn't either. It tells everyone that yes there is a problem with this port and it's not just me. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On Thu, Dec 19, 2013 at 8:07 PM, Bryan Drewery bdrew...@freebsd.org wrote: I sincerely disagree and think it's quite rude to users to not accept their reports however they send them to us. current@ constantly has build failures on it, even automated. There's no reason ports@ shouldn't either. It tells everyone that yes there is a problem with this port and it's not just me. We should accept reports from users - ack. However, there is nothing wrong with educating people about what, how and why when it comes to problems reports. If you accept anything, you will only end up with useless garbage. HTH -- 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/19/2013 20:07, Bryan Drewery wrote: I sincerely disagree and think it's quite rude to users to not accept their reports however they send them to us. current@ constantly has build failures on it, even automated. There's no reason ports@ shouldn't either. It tells everyone that yes there is a problem with this port and it's not just me. What can I say? I think pasting an error log, and only an error log, is quite rude. But I'm also serious -- if this is the official response (and seeing that you are a member of portmgr, that makes it pretty close to official), then I'll follow through and simply unsubscribe from the list. If FreeBSD isn't going to enforce their own procedures and use of infrastructure, I will limit my exposure to the continuing anarchy and let customer service to those that agree that ports@ is a free-for-all. John ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/19/2013 1:21 PM, John Marino wrote: On 12/19/2013 20:07, Bryan Drewery wrote: I sincerely disagree and think it's quite rude to users to not accept their reports however they send them to us. current@ constantly has build failures on it, even automated. There's no reason ports@ shouldn't either. It tells everyone that yes there is a problem with this port and it's not just me. What can I say? I think pasting an error log, and only an error log, is quite rude. But I'm also serious -- if this is the official response (and seeing that you are a member of portmgr, that makes it pretty close to official), then I'll follow through and simply unsubscribe from the list. If FreeBSD isn't going to enforce their own procedures and use of infrastructure, I will limit my exposure to the continuing anarchy and let customer service to those that agree that ports@ is a free-for-all. John I didn't say I spoke for portmgr. I just don't see the big deal and it's odd that it's OK on 1 list but not another. It's anti-user to get mad at them for trying to get help or report it for others. Of course we prefer they use GNATS, but go look in there and you'll see it grows every day upward. ports@ is a community that more people read than freebsd-ports-bugs and are more likely to get help and discuss how they fixed the issue. We are a mailing-list driven organization after all. IMHO threatening to unsubscribe for users trying to get help is not appropriate. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On 12/19/2013 20:28, Bryan Drewery wrote: I didn't say I spoke for portmgr. I just don't see the big deal and it's odd that it's OK on 1 list but not another. It's anti-user to get mad at them for trying to get help or report it for others. Of course we prefer they use GNATS, but go look in there and you'll see it grows every day upward. ports@ is a community that more people read than freebsd-ports-bugs and are more likely to get help and discuss how they fixed the issue. We are a mailing-list driven organization after all. IMHO threatening to unsubscribe for users trying to get help is not appropriate. This is not what is going on. Writing a PR is more work than sending an email. Many of these people using ports@ as an alternate for GNATS are very well aware of GNATS, and they are simply bypassing it. In other words, they are happy to cause more work to the FreeBSD ports committers if it saves them 3 minutes. They aren't users trying to get help, they are users gaming the system. I don't find the status quo personally acceptable, but I only have control of my actions, therefore my threats are the only recourse I have and thus they are appropriate. John ___ 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: ruBSD 2013 pkg talk report
On 19/12/13 19:10, Bryan Drewery wrote: On 12/17/2013 6:13 PM, Vsevolod Stakhov wrote: Hello, I'd like to summarize the feedback I've received from pkg users during that event. I got many questions about ports and packages and I think that questions are useful for the overall pkg development. The most of questions were related to options and base system: Q: What if I have a package built from ports with some custom options and a repository has newer package but with different set of options? A: I proposed to skip updating such a package from binary repo, but initiate its building from ports directly (assuming that ports uses pkg for dependency/conflicts resolving). That sounds reasonable and seems to be very convenient for an end user. Q: What if I have a system with some build options that are not compatible with binary packages, e.g. DISABLE_IPV6. A: I think it is useful to have a special metafile for each repo that describes compatible systems, including not merely ABI, but a specific set of non-compatible options. The alternative is to create virtual base system packages (e.g. kernel-noipv6), that may be placed in the dependencies list. Q: What if I have my own custom repo that has older software but with my local patches. A: I suggested to assign a priority to each repo and never replace packages from a high priority repo by packages from low priority repo. That should fix this request. Q: What about portupgrade and other related tools? A: I claimed that these tools are going to be deprecated and packages will be managed from pkg even if you want to build a custom package from the sources. These tools are not deprecated for port building. portupgrade and portmaster will live on. They are port building tools. pkg is not. These are only no longer intended to be used to install packages. Well, considering that we plan to use pkg for dependencies and conflicts resolving what's the real purpose of having 3 alternative systems of ports management? I really have no understanding why do we want to complicate things that are already complicated? From the point of view of a normal user, I may tell that everything I want is to have an ability to manage packages and ports transparently. Look at the macports, their user shell is perfect: you have no difference between building software from sources and getting it from repository. However, you can use only source packages while the default behaviour is to choose binary packages. I'm not talking about the current situation when pkg cannot work with ports and source packages. But eventually we want to implement that feature and use pkg as the only solver for both ports and binary packages. In this situation I consider portupgrade and portmaster as a confusing evil: a user can easily break his system by improper usage of such tools. -- Vsevolod Stakhov ___ 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 FreeBSD Ports Mangement team has a Google Community
I am pleased to announce that portmgr@ now has a Google Community. We have very slowly been building up membership through our Circles, and now it it time to announce it to all! You can find us at https://plus.google.com/u/0/communities/108335846196454338383 Come join our Community and G+1 us :) http://blogs.freebsdish.org/portmgr/2013/12/19/the-freebsd-ports-mangement-team-has-a-google-community/ ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
19.12.2013 23:35, John Marino пишет: I don't find the status quo personally acceptable, but I only have control of my actions, therefore my threats are the only recourse I have and thus they are appropriate. May be you just ignore those emails? I don't think that there are plenty of them. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
Bryan Drewery wrote: If FreeBSD isn't going to enforce their own procedures and use of infrastructure, I will limit my exposure to the continuing anarchy and let customer service to those that agree that ports@ is a free-for-all. [snip] ports@ is a community that more people read than freebsd-ports-bugs and are more likely to get help and discuss how they fixed the issue. We are a mailing-list driven organization after all. I hope you folks don't mind if I weigh in here. Besides the various mailing lists we also still have the forums. Recently some forum users have started to express their frustration at the lack of coordination between the lists and the forums. Suggestions have been raised that perhaps the forums should start posting mailing list digests and/or vice versa in order to increase integration between the two media. The forums have a special section for port issues and although many people try to help each other it happens a bit too often (IMO) that people post a problem and all we can do is refer them to this list because too few port committers/maintainers/experts use the forums. In short: if the way this list is being used (at least by some, vis-a-vis the dump an error log without as much as a hello), I wouldn't mind if people were more encouraged to try the forums, provided that enough people with expertise are willing to start participating there. A quick search reveals that the vast majority of (port or src) committers have forum accounts but rarely, if ever, use them. Just my two (euro)cents, though. Personally I'm not too bothered by the noise on any FreeBSD mailing list I am subscribed to; I have a 'D' button (combined with Ctrl for good measure when needed) and a ~/.procmailrc for that. AvW -- I'm not completely useless, I can be used as a bad example. pgpnx44LK7zu8.pgp Description: PGP signature
Re: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
I wrote: In short: if the way this list is being used (at least by some, vis-a-vis the dump an error log without as much as a hello) Was supposed to be followed by bothers certain people here I wouldn't mind if people were more encouraged to try the forums, [snip] Sorry for the omission, AvW -- I'm not completely useless, I can be used as a bad example. pgpvQ3PTodIWh.pgp Description: PGP signature
Re: radeonhd driver DEPRECATED?
On 12/19/13 17:25, Robert Huff wrote: Or so the Makefile says. What's the canonical replacement? xf86-video-ati. The xf86-video-radeonhd hasn't seen any upstream development since 2010. Regards! -- Niclas Zeising ___ 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: radeonhd driver DEPRECATED?
Niclas Zeising writes: Or so the Makefile says. What's the canonical replacement? xf86-video-ati. The xf86-video-radeonhd hasn't seen any upstream development since 2010. Thanks. Robert Huff ___ 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: If ports@ list continues to be used as substitute for GNATS, I'm unsubscribing
On Thu, Dec 19, 2013 at 01:44:57AM -0800, Anton Shterenlikht wrote: From: Thomas Mueller There are many messages on this thread, and I don't know which or what to quote, but I agree on send-pr being user-unfriendly. I disagree. I use only send-pr to send PRs. I use sendmail. I disagree with you. For new users, send-pr is a fucking usability train wreck, and insufficiently well documented. Sendmail is legendary for its obtuse configuration. I suppose you should be proud of the fact you find these tools easy to use, but that does not mean you should dismiss others' concerns over how difficult some people find them. The fact many people find these tools very difficult to use is in fact kind of a big problem, and I'm glad something is being done about it with regard to the bugzilla system. I wouldn't have chosen bugzilla if it was up to me, but it's not up to me and it's sure to be a huge improvement over the system currently in place, so I'm grateful for the work being done. Hopefully the command line send-pr tool will also be replaced with something that actually provides a low-friction way for people with problem reports to contribute to the FreeBSD project. In conclusion, I agree with Thomas (though I much prefer fdm over mpop, personally), and believe that send-pr (or its replacement, whenever that happens) desperately needs some better documentation. I rather suspect that a lot of people with problems to report simply give up and leave us with no clue there's anything wrong. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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
x11/fbpanel: pkg fallout at 10.x
Hi All! The last week I started to get pkg-fallout@ emails about x11/fbpanel error: - cc panel.o misc.o plugin.o gtkbar.o bg.o gtkbgbox.o ev.o run.o xconf.o gconf.o gconf_panel.o gconf_plugins.o -o fbpanel -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype -Wl,--export-dynamic -lgmodule-2.0 -pthread -L/usr/local/lib -lglib-2.0 -lintl -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype /usr/bin/ld: �: invalid DSO for symbol `XChangeGC' definition //usr/local/lib/libX11.so.6: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [fbpanel] Error 1 - Full log is here: http://beefy2.isc.freebsd.org/bulk/10amd64-default/2013-12-19_20h45m51s/logs/fbpanel-6.1_4.log However I can not reproduce it myself: http://gw.wart.ru/bulk/10-i386-testing/2013-12-19_21h02m40s/logs/fluxbox-1.3.5.log http://gw.wart.ru/bulk/10-amd64-testing/2013-12-19_21h01m49s/logs/fluxbox-1.3.5.log Any help is appreciated. Thanks. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: x11/fbpanel: pkg fallout at 10.x
On Fri, Dec 20, 2013 at 10:42:38AM +0400, Boris Samorodov wrote: Hi All! The last week I started to get pkg-fallout@ emails about x11/fbpanel error: - cc panel.o misc.o plugin.o gtkbar.o bg.o gtkbgbox.o ev.o run.o xconf.o gconf.o gconf_panel.o gconf_plugins.o -o fbpanel -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype -Wl,--export-dynamic -lgmodule-2.0 -pthread -L/usr/local/lib -lglib-2.0 -lintl -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype /usr/bin/ld: �: invalid DSO for symbol `XChangeGC' definition //usr/local/lib/libX11.so.6: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [fbpanel] Error 1 - Full log is here: http://beefy2.isc.freebsd.org/bulk/10amd64-default/2013-12-19_20h45m51s/logs/fbpanel-6.1_4.log However I can not reproduce it myself: http://gw.wart.ru/bulk/10-i386-testing/2013-12-19_21h02m40s/logs/fluxbox-1.3.5.log http://gw.wart.ru/bulk/10-amd64-testing/2013-12-19_21h01m49s/logs/fluxbox-1.3.5.log Any help is appreciated. Thanks. That is probably a gtk2 upgrade fallout. gtk2 pkgconfig file is not adding -lX11 to LDFLAGS anymore. In general: on FreeBSD 10+, the ld(1) behaviour has been changed so that it does not recursively get the DT_NEEDED from libraries it linked binaries to. Meaning in that case something exposes a X function to fbpanel, but does not tell it is needs to link to X11 /usr/bin/ld: �: invalid DSO for symbol `XChangeGC' definition //usr/local/lib/libX11.so.6: could not read symbols: Bad value LDFLAGS+= -lX11 should solve this. regards, Bapt pgpzujELtEw9N.pgp Description: PGP signature
Re: x11/fbpanel: pkg fallout at 10.x
On 20-12-2013 7:58, Baptiste Daroussin wrote: On Fri, Dec 20, 2013 at 10:42:38AM +0400, Boris Samorodov wrote: Hi All! The last week I started to get pkg-fallout@ emails about x11/fbpanel error: - cc panel.o misc.o plugin.o gtkbar.o bg.o gtkbgbox.o ev.o run.o xconf.o gconf.o gconf_panel.o gconf_plugins.o -o fbpanel -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype -Wl,--export-dynamic -lgmodule-2.0 -pthread -L/usr/local/lib -lglib-2.0 -lintl -L/usr/local/lib -lglib-2.0 -lintl -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lfontconfig -L/usr/local/lib -lfreetype /usr/bin/ld: �: invalid DSO for symbol `XChangeGC' definition //usr/local/lib/libX11.so.6: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [fbpanel] Error 1 - Full log is here: http://beefy2.isc.freebsd.org/bulk/10amd64-default/2013-12-19_20h45m51s/logs/fbpanel-6.1_4.log However I can not reproduce it myself: http://gw.wart.ru/bulk/10-i386-testing/2013-12-19_21h02m40s/logs/fluxbox-1.3.5.log http://gw.wart.ru/bulk/10-amd64-testing/2013-12-19_21h01m49s/logs/fluxbox-1.3.5.log Any help is appreciated. Thanks. That is probably a gtk2 upgrade fallout. gtk2 pkgconfig file is not adding -lX11 to LDFLAGS anymore. In general: on FreeBSD 10+, the ld(1) behaviour has been changed so that it does not recursively get the DT_NEEDED from libraries it linked binaries to. Meaning in that case something exposes a X function to fbpanel, but does not tell it is needs to link to X11 /usr/bin/ld: �: invalid DSO for symbol `XChangeGC' definition //usr/local/lib/libX11.so.6: could not read symbols: Bad value LDFLAGS+= -lX11 should solve this. regards, Bapt Yeah this is my fault, will fix. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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
