Re: The cost of a source based package system
Hi, how did you manage to get an answer from Google that fast? http://www.google.com/hostednews/afp/article/ALeqM5gK2BT8m9EhMCL0gI-yqyut3UOz-A?docId=CNG.8da7524161341a630734bbb6cf9ce6e4.231 Erich On Thursday 08 September 2011 11:53:28 Stefan Schaeckeler wrote: Hi all, please don't take this posting too serious. I was just curious ... Just the other day, I bought a kill-a-watt. Among other things, I measured the cost of a source based package system, i.e. I was comparing the energy cost of installing ports from source vs binary packages (setup, see below). Case 1: Source based installation Time: 7 hours, 3 min Energy: 0.489 kw*h Price:4.89 US cent Case 2a: Binary packages based installation Time: 1 hour, 57 min Energy: 0.079 kw*h Price:0.79 US cent If the computer is constantly running, then we should add the installation time of case 1 to case 2a: Case 2b: Binary packages based installation Time: 7 hours, 3 min Energy: (40/1000)kw*(7.05-1.95)h + 0.079 kw*h = 0.283 kw*h Price:2.83 US cent Using source based ports is with almost 5 US cents 6.19 times (case 1 vs case 2a) or 1.73 times (case 1 vs case 2b) more expensive than using binary packages :) - Stefan Details: Price: 1 kw*h = 10 US cent. Kill-a-Watt trick: by setting the price per kw to $9.999 (= $10), I could get one more digit of accuracy for the consumed energy by dividing the price by 10. HW: Sony vaio pcg-k23 laptop (pentium 4, 2,8 GHz, huge display). Booted into FreeBSD, it consumes around 40 Watt (idle). When compiling programs, the power consumption doubles to somewhat above 80 Watt. Internet connection 768kb/s. SW: Installed 259 ports via this script: --- snip --- date for i in /usr/ports/x11/xorg-minimal\ /usr/ports/x11/xorg-apps\ /usr/ports/x11/xorg-cf-files\ /usr/ports/x11/xorg-docs\ /usr/ports/x11/xorg-libraries\ /usr/ports/shells/bash3\ /usr/ports/print/teTeX\ /usr/ports/editors/emacs\ /usr/ports/editors/joe2\ /usr/ports/multimedia/xmms\ /usr/ports/multimedia/ffmpeg\ /usr/ports/lang/clisp\ /usr/ports/lang/hugs\ /usr/ports/lang/swi-pl\ /usr/ports/lang/llvm-gcc4\ /usr/ports/lang/gnat\ /usr/ports/lang/Gofer\ /usr/ports/x11-toolkits/tk86 do cd $i yes o | make install clean done date halt -p --- snip --- Similarly, 246 binary packages have been installed via pkg_add -r. pkg_delete /var/db/pkg/* rm -rf /usr/ports/distfiles/ PACKAGESITE=ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest/ export PACKAGESITE --- snip --- date for i in xorg-minimal\ xorg-apps\ xorg-cf-files\ xorg-docs\ xorg-libraries\ bash3\ teTeX\ emacs\ joe2\ xmms\ ffmpeg\ clisp\ hugs\ swi-pl\ llvm-gcc4\ gnat\ Gofer\ tk86 do pkg_add -r $i done date halt -p --- snip --- The number of ports and binary packages varies slightly. I don't know why. This only introduces a small error. ___ 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: The cost of a source based package system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/07/11 23:26, Erich Dollansky wrote: Hi, On Thursday 08 September 2011 11:53:28 Stefan Schaeckeler wrote: Hi all, please don't take this posting too serious. I was just curious ... your are talking about a serious problem. Using source based ports is with almost 5 US cents 6.19 times (case 1 vs case 2a) or 1.73 times (case 1 vs case 2b) more expensive than using binary packages :) Yes, but: You are moving the cost from you to the the hosting companies. If more people use packages, they will need more capacity to supply all the different variants. Does anybody know what takes more capacity? The sources or the binaries? I would believe that the sources would take more space and bandwidth but the different variants of the binaries could be much bigger at the end. I remember some articles about the electricity bill Google gets every month. It is not that low. So, to paint a more complete picture, we must see both sides of the fence. To make matters worse, people like me do both. I upgrade via the packages and then compile while I am already able to work with the new ports. At least, if the packages worked. Both portmaster and portupgrade have 'package' mode, which uses packages when available. If one can live with default optimization (which is usually good anyways) and if most times the default options would satisfy his/her need, or if the port doesn't provide any options, binary packages would save a lot of time. The real problem for FreeBSD's packaging system is, in my opinion, we do not maintain branches and ports tree is a fast moving target, making it impractical to build packages and push to mirrors. My $0.02: It might be worthy to experiment a branched development model and only pull up changes at a much lower pace to branch (e.g. create a branch near a release and drop the branch after a few weeks once a new one is created, and only pullup changes when there is need, like because security vulnerability or serious reliability/performance issue), it would be easier to produce binary package and sync them across mirrors. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOaVOaAAoJEATO+BI/yjfBWmkH/RRpJWJQn4Gqv7WL/HMsX/4Y kXZjVwS5uRF1hey3kf768P0Z1KcFeWNjyMx/B7VkV30tZzqs6Y/5EDqIEKrbrHJ/ Cq6tJGojG6k58dZPPRmCAo97FNbMYO2Xn4pj4+vz2hy/s0YRpPY9Ry+1yGMW0N2W Z55Xoko51Y5e1ZDtMjXTe+AqW1N+Gt/S/5HNAqTY9znpMADmeTyON+37wd069x+E WDd1oHLGadTt123KBU0NMhAMXGhWZWhQh6u6YRQP9Xkog3k9mNnAO+gHY/xiUG0h 2vlDhbZ5WFbeuw7eLd7sWgfgl77j42TFSFq0PUR9gdEBPkBJSjjJkk+B0Wb+A5E= =V1Bg -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Matthias Andree wrote: Am 08.09.2011 13:52, schrieb Matt Burke: I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. No, you'd use a managed installation. Nobody stands there pointing a gun at your head and forces you to uninstall a port that got removed from the ports/ tree. If people could recognize that, it might help get the derailed discussion back on the right track. Recent butchery degrading ports/ has been unprofessional. Denying users are best to decide for themselves in light of their own circustance, is not acceptable. FreeBSD is for skilled Users not the clueless. Commit bit[s] should be revoked before FreeBSD incures more damage. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with ; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. http://www.softwarefreedomday.org 17th Sept, http://berklix.org/sfd/ Oct. ___ 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-system priorities rant (Re: sysutils/cfs)
Matthias Andree wrote: Am 08.09.2011 16:15, schrieb Mikhail T.: Having a poor port of an obscure piece of software is better, than no port at all. A poor port is undesirable (and shouldn't be in the tree in the first place). Wrong. A `poor' port is is still a port else it would be marked Broken. Still a lot less work to polish than writing a port from scratch. Still a damn sight more use to non programmers than no port. Maybe it might just need a bit more work to speify more depends, but still be working anyway. An obscure piece of software is undesirable (and shouldn't be ported in the first place). Rubbish! Now guess what a poor port of an obscure piece of software is. Something that's still useful cos with it a non programmer has something that will work right now, with a MAINTAINER address he can contact be told Encourage me I'll improve it send omprovements to FreeBSD too We're not there to run a museum of horrors, and we're not the starting point or sole provider of such software. In fact we should not even attempt to do that. People interested in that obscure software can either help themselves without a port, can organize the necessary assistance, or should not be running it. BSD has a history of more niche/ mature/ specialist/ users uses. If you want Linux, use Linux Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with ; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. http://www.softwarefreedomday.org 17th Sept, http://berklix.org/sfd/ Oct. ___ 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-system priorities rant (Re: sysutils/cfs)
On Fri, Sep 09, 2011 at 03:01:09AM +0200, Julian H. Stacey wrote: Matthias Andree wrote: Am 08.09.2011 16:15, schrieb Mikhail T.: Having a poor port of an obscure piece of software is better, than no port at all. A poor port is undesirable (and shouldn't be in the tree in the first place). Wrong. A `poor' port is is still a port else it would be marked Broken. Still a lot less work to polish than writing a port from scratch. Still a damn sight more use to non programmers than no port. Maybe it might just need a bit more work to speify more depends, but still be working anyway. It occurs to me there are people who would call KDE4 a poor port. I suspect deleting that would not go over well. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpdi6O07OpJt.pgp Description: PGP signature
Re: The cost of a source based package system
Hi there, On Thursday 08 September 2011 11:53:28 Stefan Schaeckeler wrote: Hi all, please don't take this posting too serious. I was just curious ... your are talking about a serious problem. Absolutely. Billions are spend on Green Computing and even PhD theses are written on it. Using source based ports is with almost 5 US cents 6.19 times (case 1 vs case 2a) or 1.73 times (case 1 vs case 2b) more expensive than using binary packages :) Yes, but: You are moving the cost from you to the the hosting companies. If more people use packages, they will need more capacity to supply all the different variants. A lot of variants are compile-time options, e.g. ./configure --enable-XXX. Looking at ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/, there is only one vlc binary, although vlc has a lot of variants. Independent of that, diskspace is cheap and there are only a few package mirrors. Does anybody know what takes more capacity? The sources or the binaries? I would believe that the sources would take more space and bandwidth but the different variants of the binaries could be much bigger at the end. Random check, binaries are 7 times slimmer 978427 bash-4.1.10.tbz // binary package 6598300 bash-4.1.tar.gz // source from ftp.gnu.org One could optimize ports a lot more for a) download speed and b) compile time: - downloading only a diff from the current version to the new, updated, version (that's virtually impossible for binary packages). That should save significant download time but might be difficult to implement as most software is only distributed as tar-balls. - no 'make clean' and reusing the object files of the current version for building the new, updated, version. That should save significant compilation time. Does that work as of today? So, in theory, ports could be made greener than packages :) I remember some articles about the electricity bill Google gets every month. It is not that low. So, to paint a more complete picture, we must see both sides of the fence. ... and from your follow up email: how did you manage to get an answer from Google that fast? http://www.google.com/hostednews/afp/article/ALeqM5gK2BT8m9EhMCL0gI-yqyut3UOz-A?docId=CNG.8da7524161341a630734bbb6cf9ce6e4.231 So, Google is going green. FreeBSD ports could try to do the same :) To make matters worse, people like me do both. I upgrade via the packages and then compile while I am already able to work with the new ports. At least, if the packages worked. That's bad for the environment :P At the end, we who want to go green have to stop using the Internet and go back to postal services as it costs less energy. This contradicts your Google link: Three days of streaming YouTube video requires as much energy as making, packaging and delivering a DVD. @ Eitan: The number of ports and binary packages varies slightly. I don't know why. This only introduces a small error. Likely due to build dependencies which are not needed when installing via packages. Bingo! Stefan -- Scotty: Captain, we din' can reference it! Kirk: Analysis, Mr. Spock? Spock: Captain, it doesn't appear in the symbol table. Kirk: Then it's of external origin? Spock: Affirmative. Kirk: Mr. Sulu, go to pass two. Sulu: Aye aye, sir, going to pass two. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On Thu, Sep 08, 2011 at 06:54:36PM +0200, Matthias Andree wrote: Am 08.09.2011 13:52, schrieb Matt Burke: Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? That wouldn't happen anyways because the package is actively maintained, unlike many of the ports the discussion is about. You (and others) place *far* too much emphasis on a piece of software being maintained What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. The port isn't perfectly usable (because that would mean it's usable in all circumstances for all advertised purposes, which is explicitly not the case in the light of known vulnerabilities). In which case just about no port is 'perfectly usable' since almost all non-trivial software contains bugs - at least some of which are not documented, meaning that it isn't usable in *all* circumstances for *all* advertised purposes. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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-system priorities rant (Re: sysutils/cfs)
On Thu, Sep 08, 2011 at 06:36:46PM +0200, Matthias Andree wrote: Am 08.09.2011 16:15, schrieb Mikhail T.: Having a poor port of an obscure piece of software is better, than no port at all. A poor port is undesirable (and shouldn't be in the tree in the first place). Highly debatable. It is clear that a poor port is undesirable compared to a good port, but very often a poor port is more desirable than no port at all. An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! Keep in mind that FreeBSD itself is a fairly obscure piece of software in that most people in the world have never heard of it. For any given individual something like 90+% percent of the ports in the ports-tree could count as obscure since that person has never heard of that particular piece of software before. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On 8 Sep 2011 02:29, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Doug Barton do...@freebsd.org Date: Wed, 07 Sep 2011 15:45:51 -0700 Message-id: 4e67f41f.70...@freebsd.org Doug Barton wrote: On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: On 09/07/2011 00:07, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: Better to deprecate such non urgent ports, wait a while after next release is rolled, to give release users a warning some time to volunteer ... That's an interesting idea, but incredibly unlikely to happen. It _certainly_ won't happen if those in charge refuse to try it! My point was that the idea is impractical ... How is it impractical to, as a rule, set an expiration date based on an anticipated future release date rather than only a month or two out from when the decision is made? As has repeatedly been explained to you ... I think you may have gotten me confused with someone else. Quite possibly. :) Saying the same things over and over again gets mentally exhausting after a while. you're asking the wrong question. The question is, how does it benefit the users to leave it in when we know that we're going to delete it? Either way the user will discover that the port is not easily available for installation when they update their ports tree. Reread the first paragraph. Provided the port is still in the tree, when they try to build it the ports mechanism reports the FORBIDDEN/BROKEN/whatever which describes the problem, and the expiration date a month or two out. (If the expiration date is not included in the report, it should be.) They then know that they need to fix the port, or find someone to fix it, and they know _why_ it needs to be fixed. In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. As was pointed out elsewhere in the thread, the MOVED entry should contain that information. Generally what I do when I actually remove a port is to copy the DEPRECATED/FORBIDDEN message into the MOVED file entry. However, even if that isn't sufficient the entire story is still available in the CVS history. And the user can always ask on freebsd-ports@ if they are really confused and need help. The difference is that in the meantime people doing work on the ports tree don't have to work around the old port (that's going to be removed anyway). It's only going to be removed if no one fixes it. .. which is what happens in the vast majority of cases. The whole point is that release users don't continuously monitor their ports -- they only upgrade when they become aware that they need to (e.g. when a newer release becomes available). And what we have been trying to explain to you is that this has never been a supported mode of operation. We don't tie the ports tree to specific releases, [ I've been reading not writing , as real life priorities intrude, but that phrase has been repeated too often to ignore ...] FreeBSD doese tie the ports tree to specific releases. We have ports freezes before each release We don't, actually. ___ 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: The cost of a source based package system
Hi, On Thursday 08 September 2011 11:53:28 Stefan Schaeckeler wrote: Hi all, please don't take this posting too serious. I was just curious ... your are talking about a serious problem. Using source based ports is with almost 5 US cents 6.19 times (case 1 vs case 2a) or 1.73 times (case 1 vs case 2b) more expensive than using binary packages :) Yes, but: You are moving the cost from you to the the hosting companies. If more people use packages, they will need more capacity to supply all the different variants. Does anybody know what takes more capacity? The sources or the binaries? I would believe that the sources would take more space and bandwidth but the different variants of the binaries could be much bigger at the end. I remember some articles about the electricity bill Google gets every month. It is not that low. So, to paint a more complete picture, we must see both sides of the fence. To make matters worse, people like me do both. I upgrade via the packages and then compile while I am already able to work with the new ports. At least, if the packages worked. At the end, we who want to go green have to stop using the Internet and go back to postal services as it costs less energy. Erich - Stefan Details: Price: 1 kw*h = 10 US cent. Kill-a-Watt trick: by setting the price per kw to $9.999 (= $10), I could get one more digit of accuracy for the consumed energy by dividing the price by 10. HW: Sony vaio pcg-k23 laptop (pentium 4, 2,8 GHz, huge display). Booted into FreeBSD, it consumes around 40 Watt (idle). When compiling programs, the power consumption doubles to somewhat above 80 Watt. Internet connection 768kb/s. SW: Installed 259 ports via this script: --- snip --- date for i in /usr/ports/x11/xorg-minimal\ /usr/ports/x11/xorg-apps\ /usr/ports/x11/xorg-cf-files\ /usr/ports/x11/xorg-docs\ /usr/ports/x11/xorg-libraries\ /usr/ports/shells/bash3\ /usr/ports/print/teTeX\ /usr/ports/editors/emacs\ /usr/ports/editors/joe2\ /usr/ports/multimedia/xmms\ /usr/ports/multimedia/ffmpeg\ /usr/ports/lang/clisp\ /usr/ports/lang/hugs\ /usr/ports/lang/swi-pl\ /usr/ports/lang/llvm-gcc4\ /usr/ports/lang/gnat\ /usr/ports/lang/Gofer\ /usr/ports/x11-toolkits/tk86 do cd $i yes o | make install clean done date halt -p --- snip --- Similarly, 246 binary packages have been installed via pkg_add -r. pkg_delete /var/db/pkg/* rm -rf /usr/ports/distfiles/ PACKAGESITE=ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest/ export PACKAGESITE --- snip --- date for i in xorg-minimal\ xorg-apps\ xorg-cf-files\ xorg-docs\ xorg-libraries\ bash3\ teTeX\ emacs\ joe2\ xmms\ ffmpeg\ clisp\ hugs\ swi-pl\ llvm-gcc4\ gnat\ Gofer\ tk86 do pkg_add -r $i done date halt -p --- snip --- The number of ports and binary packages varies slightly. I don't know why. This only introduces a small error. ___ 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: Bumping lightning to 1.0b5 so it works with Thunderbird 6.0.1
On 08.09.2011 02:16, Lawrence Stewart wrote: Hi Gecko team, The update from Thunderbird 6.0 to 6.0.1 has stopped the Lightning 1.0b5pre plugin from working - it claims to be incompatible with the new version of Thunderbird and can't be enabled. Lightning 1.0b5 seems to work fine with Thunderbird 6.0.1 on my wife's windows PC, so I'm guessing a very minor bump to the lightning build source is needed to get it working again. If you're aware of this issue then great, but if not, just wanted to bring it to your attention so that it's on your radar. Hi Lawrence, did you reinstall the built xpi? It's usually located here /usr/local/share/lightning/lightning-thunderbird.xpi. That one should be compatible. I'm working on making this step automatic, but I'm not there yet, it's on the TODO list ;) Cheers, Florian ___ 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
ports/159978: apply simple upstream patch
Good day, can please anybody commit this: http://bugs.freebsd.org/159978 It's quite simple upstream patch (committed into not yet released 2.4.1 version), that solves OP problem. And maintainer timeout 2weeks+. Thanks. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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-system priorities rant (Re: sysutils/cfs)
On Wed, Sep 07, 2011 at 08:15:04PM -0400, Mikhail T. wrote: On -10.01.-28163 14:59, Doug Barton wrote: Non sequitur. The large number of ports that we support IS a feature. However, it's also a pretty big maintenance burden. Especially when you consider the number of those ports that are either actually or effectively unmaintained. Support? What support? Can I call someone and have a solution to a problem? Some PRs remain open for years and any attempts to escalate are met with patches welcome -- I've been on both sides myself :-) We do not offer support, make no promises of such and offer neither guarantees nor SLAs. What we do offer is: THERE IS A PORT OF IT. If there is a piece of software out there, chances are, it is ported to FreeBSD. Even if the existing port is imperfect, it is a starting point for somebody, who needs that software on their system. With every port removed, that promise wears thinner and thinner... I'm not a developer, but it strikes me that the above hits at the core of the disagreement. For many people, what THERE IS A PORT OF IT actually -means- is that the user can go to ports and install a -working- version of the software, not merley that there is something called 'IT' somewhere in the ports tree that may or may not work. And, if I'm not mistaken, this is also what 'support' means in the context of ports. No, of course there is no helpdesk you can call. But just as with the 'supported hardware' list, 'supported' means that the team will do its best to ensure that things actually work. -- greg byshenk - gbysh...@byshenk.net - Leiden, NL ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Hi, Reference: From: Chris Rees utis...@gmail.com Date: Thu, 8 Sep 2011 07:20:27 +0100 Message-id: CADLo83-4Hbq+Ce5ADJvEQP7167wJt48C8aOfCW8RV=w96st...@mail.gmail.com Chris Rees wrote: --00151774047892f1af04ac680e7e Content-Type: text/plain; charset=ISO-8859-1 On 8 Sep 2011 02:29, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Doug Barton do...@freebsd.org Date: Wed, 07 Sep 2011 15:45:51 -0700 Message-id: 4e67f41f.70...@freebsd.org Doug Barton wrote: On 9/7/2011 10:02 AM, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: On 09/07/2011 00:07, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: Better to deprecate such non urgent ports, wait a while after next release is rolled, to give release users a warning some time to volunteer ... That's an interesting idea, but incredibly unlikely to happen. It _certainly_ won't happen if those in charge refuse to try it! My point was that the idea is impractical ... How is it impractical to, as a rule, set an expiration date based on an anticipated future release date rather than only a month or two out from when the decision is made? As has repeatedly been explained to you ... I think you may have gotten me confused with someone else. Quite possibly. :) Saying the same things over and over again gets mentally exhausting after a while. you're asking the wrong question. The question is, how does it benefit the users to leave it in when we know that we're going to delete it? Either way the user will discover that the port is not easily available for installation when they update their ports tree. Reread the first paragraph. Provided the port is still in the tree, when they try to build it the ports mechanism reports the FORBIDDEN/BROKEN/whatever which describes the problem, and the expiration date a month or two out. (If the expiration date is not included in the report, it should be.) They then know that they need to fix the port, or find someone to fix it, and they know _why_ it needs to be fixed. In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. As was pointed out elsewhere in the thread, the MOVED entry should contain that information. Generally what I do when I actually remove a port is to copy the DEPRECATED/FORBIDDEN message into the MOVED file entry. However, even if that isn't sufficient the entire story is still available in the CVS history. And the user can always ask on freebsd-ports@ if they are really confused and need help. The difference is that in the meantime people doing work on the ports tree don't have to work around the old port (that's going to be removed anyway). It's only going to be removed if no one fixes it. .. which is what happens in the vast majority of cases. The whole point is that release users don't continuously monitor their ports -- they only upgrade when they become aware that they need to (e.g. when a newer release becomes available). And what we have been trying to explain to you is that this has never been a supported mode of operation. We don't tie the ports tree to specific releases, [ I've been reading not writing , as real life priorities intrude, but that phrase has been repeated too often to ignore ...] FreeBSD doese tie the ports tree to specific releases. We have ports freezes before each release We don't, actually. http://www.freebsd.org/doc/en/articles/committers-guide/ports.html#Q13.4.1. http://www.freebsd.org/releases/7.2R/schedule.html http://www.freebsd.org/portmgr/qa.html --00151774047892f1af04ac680e7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Surplus Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with ; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. http://www.softwarefreedomday.org 17th Sept, http://berklix.org/sfd/ Oct. ___ 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
lini...@freebsd.org wrote on 07.09.2011 10:33: portname: databases/postgresql-plpython description:A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date:2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How can i know what this mean - error in parsing Makefile? If this is about it doesn't builds with 9.1b3, then we have pr with patch about it - http://bugs.freebsd.org/159319. There is analogues patches for other postgresql-pl* ports in gnats. There is also http://bugs.freebsd.org/159843 http://bugs.freebsd.org/159844 How can ports be removed if the solutions for them is in gnats? -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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
Ruslan Mahmatkhanov wrote on 08.09.2011 14:04: lini...@freebsd.org wrote on 07.09.2011 10:33: portname: databases/postgresql-plpython description: A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date: 2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How can i know what this mean - error in parsing Makefile? If this is about it doesn't builds with 9.1b3, then we have pr with patch about it - http://bugs.freebsd.org/159319. There is analogues patches for other postgresql-pl* ports in gnats. There is also http://bugs.freebsd.org/159843 http://bugs.freebsd.org/159844 How can ports be removed if the solutions for them is in gnats? I also see on portsmon.FreeBSD.org that this port was failed to build with databases/postgresql74-server. But who cares? We even doesn't have such port in the tree! (PotsgreSQL 7.4 was removed on 04 Apr 2011 from the ports tree). So i thinks this message is completely bogus. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: Same concerns about our postgresql and plpython ports
Hi, for me it's too many time has passed for maintainer timeout. Please commit this anybody, until this port wasn't removed because it doesn't builds with some NOTEXISTENT PostgreSQL version. Ruslan Mahmatkhanov wrote on 31.08.2011 11:11: So... two weeks are now passed and i still see no objections from maintainer. Can please anybody commit? It will be terrible sad if work that took so much time and energy will remains unfinished. Thanks. Ruslan Mahmatkhanov wrote on 17.08.2011 21:54: So i split this up to three pr's as was suggested by Mark: 1. Python pkg-plist fix for WITHOUT_THREADS case: http://www.freebsd.org/cgi/query-pr.cgi?pr=159842 2. postgresql-plpython unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159843 3. postgresql9x-client unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 Palle (maintainer of postgresql ports) cc'ed. Thanks in advance for handling this. PS. I just found that the similar plist fix was submitted for python26 a year ago: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148406 Ruslan Mahmatkhanov wrote on 16.08.2011 19:20: Hi there. We have databases/postgresql-plpython, that is marked as broken with this message: Does not configure without threaded Python, but this is totally wrong - it actually does. I checked the internets and found this: [1] and [2]. People are actually had problems when building it WITH threaded python (that is built with threads support by default). Rebuilding python w/o threads support do the trick actually. But if you will try to build this port with threads-aware python, you'll get this error message: checking whether Python is compiled with thread support... yes configure: error: threaded Python not supported on this platform But the funny thing that it actually builds and works fine with threaded python too :). We just need to apply this patch to postgresqlXX-server's configure: - openbsd*|freebsd*) + openbsd*) And then there is no error: checking whether Python is compiled with thread support... yes checking for main in -lm... yes So what i did - i have tested the build and runtime of 8.4, 9.0, 9.1b3. both with threads-aware python and threadless python (version 2.7.2, runtime is tested only on 9-CURRENT, but with all the three PostgreSQL versions). And all of this configurations works well. For testing i'm used sample function (pymax.sql) from PosgreSQL manual and simple script (plpython.sh), that adds/removes and runs the function: [mrk@smeshariki2 plpython] cat pymax.sql CREATE FUNCTION pymax (a integer, b integer) RETURNS integer AS $$ if a b: return a return b $$ LANGUAGE plpythonu; [mrk@smeshariki2 plpython] cat plpython.sh #!/bin/sh createlang -U pgsql plpythonu test psql -U pgsql test -f pymax.sql psql -U pgsql test -c select pymax(1,2) psql -U pgsql test -c drop function pymax(a integer, b integer) droplang -U pgsql plpythonu test To build databases/postgresql-plpython with PostgreSQL 9.1b3 i've used patch from [4] by Martin Neubauer mn at shodan dot homeunix dot net, it is also included into my patch [3]. Updated regexp also working fine with 8.4 and 9.0. plpython module for 9.0 and 9.1 was renamed to plpython2.so, but there is also plpython.so symlink in 9.0 that points to plpython2.so. 9.1 also installs some extension files, so i fixed pkg-plists accordingly. Since 9.0 PostgreSQL guys use docbook for building all the documentation, including man-pages. They ever listed all the dependencies needed on FreeBSD to make it build. See [5]. But because our postgresql-client ports didn't include needed dependencies, their build are broken. In particular: postgresql91-client is broken on FreeBSD-8.2 postgresql90-client is broken on FreeBSD-7.4 postgresql91-client is broken on FreeBSD-7.4 So i have fixed this too by adding this deps to the ports. And i'm not see another solution. We need man-pages for postgresql9x-client, and man-pages needs all that docbook stuff. To make lang/python27 build without threads under tinderbox, i was forced to fix it's plist. Please see patch [6]. Probably similar patch should be applied against other python versions. The plpython port is unmantained, so please commit this anybody. Below are build logs of various configurations. Threads-aware python: - 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-8.4.8_1.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.0.4_1.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.1.b3_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-8.4.8_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-client-9.0.4_1.log 7.4: http://happy-nation.by.ru/ports/tb/7.4/postgresql-plpython-9.1.b3_1.log Threadless python: -- 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-8.4.8_1-wo-threads.log 8.2: http://happy-nation.by.ru/ports/tb/8.2/postgresql-plpython-9.0.4_1-wo-threads.log 8.2:
FreeBSD Port: xbmc-10.1_2
Hi XBMC seems to depend on sqlite3 (it won't compile without) but it's not on the dependencies list. kind regards Emil Vanherp ___ 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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? Miroslav Lachman ___ 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: xbmc-10.1_2
On Thu, 8 Sep 2011 13:02:56 +0200, emil vanherp wrote: Hi XBMC seems to depend on sqlite3 (it won't compile without) but it's not on the dependencies list. Don't know why you think it's missing but that's plain wrong. It's there at the bottom of the LIB_DEPENDS. http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/xbmc/Makefile?rev=1.11 -- Bernhard Fröhlich http://www.bluelife.at/ ___ 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: portmanager -u -l -- php version not updated
ok i had to restart the fast-cgi demon
# /usr/local/etc/rc.d/php.cgi.sh stop
# /usr/local/etc/rc.d/php.cgi.sh start
Starting php-cgi...
spawn-fcgi: child spawned successfully: PID: 51122
On Thu, Sep 8, 2011 at 1:50 PM, Norman Khine nor...@khine.net wrote:
hello,
i just did a #portmanager -u -l on my freebsd8.1 system, which runs nginx
# php /usr/local/www/nginx-dist/test/php.php
phpinfo()
PHP Version = 5.3.8
System = FreeBSD arawak.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon
Jul 19 02:36:49 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Build Date = Sep 7 2011 16:27:50
Configure Command = './configure' '--with-layout=GNU'
'--localstatedir=/var'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local'
'--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr'
'--program-prefix=' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.1'
Server API = Command Line Interface
Virtual Directory Support = disabled
Configuration File (php.ini) Path = /usr/local/etc
Loaded Configuration File = /usr/local/etc/php.ini
Scan this dir for additional .ini files = /usr/local/etc/php
Additional .ini files parsed = /usr/local/etc/php/extensions.ini,
/usr/local/etc/php/xcache.ini
is the correct version,
but when i navigate to
http://localhost/test/php.php i get the old version of php as being displayed.
what am i missing here?
thanks
norman
--
% .join( [ {'*':'@','^':'.'}.get(c,None) or
chr(97+(ord(c)-83)%26) for c in ,adym,*)uzq^zqf ] )
--
˙ʇı ɹoɟ ƃuıʎɐd ǝɹ,noʎ ʍou puɐ ǝɔıoɥɔ ɐ ʞooʇ ı ʇɐɥʇ sı 'ʇlnɔıɟɟıp sı ʇɐɥʍ
˙uʍop ǝpısdn p,uɹnʇ pןɹoʍ ǝɥʇ ǝǝs noʎ 'ʇuǝɯɐן sǝɯıʇ ǝɥʇ puɐ 'ʇuǝʇuoɔ
ǝq s,ʇǝן ʇǝʎ
% .join( [ {'*':'@','^':'.'}.get(c,None) or
chr(97+(ord(c)-83)%26) for c in ,adym,*)uzq^zqf ] )
___
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
portmanager -u -l -- php version not updated
hello,
i just did a #portmanager -u -l on my freebsd8.1 system, which runs nginx
# php /usr/local/www/nginx-dist/test/php.php
phpinfo()
PHP Version = 5.3.8
System = FreeBSD arawak.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon
Jul 19 02:36:49 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Build Date = Sep 7 2011 16:27:50
Configure Command = './configure' '--with-layout=GNU'
'--localstatedir=/var'
'--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all'
'--enable-libxml' '--with-libxml-dir=/usr/local'
'--with-pcre-regex=/usr/local' '--with-zlib-dir=/usr'
'--program-prefix=' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.1'
Server API = Command Line Interface
Virtual Directory Support = disabled
Configuration File (php.ini) Path = /usr/local/etc
Loaded Configuration File = /usr/local/etc/php.ini
Scan this dir for additional .ini files = /usr/local/etc/php
Additional .ini files parsed = /usr/local/etc/php/extensions.ini,
/usr/local/etc/php/xcache.ini
is the correct version,
but when i navigate to
http://localhost/test/php.php i get the old version of php as being displayed.
what am i missing here?
thanks
norman
--
% .join( [ {'*':'@','^':'.'}.get(c,None) or
chr(97+(ord(c)-83)%26) for c in ,adym,*)uzq^zqf ] )
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On 09/07/11 17:04, Chris Rees wrote: The /new/ policy of removing ports for much lighter offenses, such as having vulnerabilities, has already caused so many objections, that it is time to abolish it. I consider the argument here dead; portmgr is reviewing the policy as Erwin has said. However... I find it deeply troubling that you consider buildability more important than security fixes. Are you actually serious? Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? I've still got non-networked FreeBSD 4.x laptops running with a version of Minicom that for a year or so was FORBIDDEN because it had a local root vulnerability. What's so wrong about that? I'm glad the port wasn't deleted because I still install and use Minicom today. What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. ___ 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
On Thu, Sep 08, 2011 at 02:04:16PM +0400, Ruslan Mahmatkhanov wrote: lini...@freebsd.org wrote on 07.09.2011 10:33: portname: databases/postgresql-plpython description:A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date:2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How can i know what this mean - error in parsing Makefile? If this is about it doesn't builds with 9.1b3, then we have pr with patch about it - http://bugs.freebsd.org/159319. There is analogues patches for other postgresql-pl* ports in gnats. There is also http://bugs.freebsd.org/159843 http://bugs.freebsd.org/159844 How can ports be removed if the solutions for them is in gnats? They won't before deleting ports, we always check gnats, if a PR exists then we leave the ports so that the PR can be committed regards, Bapt pgpUkH8RV4tmy.pgp Description: PGP signature
Re: FreeBSD ports which are currently scheduled for deletion
Baptiste Daroussin wrote on 08.09.2011 17:13: On Thu, Sep 08, 2011 at 02:04:16PM +0400, Ruslan Mahmatkhanov wrote: lini...@freebsd.org wrote on 07.09.2011 10:33: portname: databases/postgresql-plpython description:A module for using Python to write SQL functions maintainer: po...@freebsd.org deprecated because: (error in parsing Makefile) expiration date:2011-04-02 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=postgresql-plpython How can i know what this mean - error in parsing Makefile? If this is about it doesn't builds with 9.1b3, then we have pr with patch about it - http://bugs.freebsd.org/159319. There is analogues patches for other postgresql-pl* ports in gnats. There is also http://bugs.freebsd.org/159843 http://bugs.freebsd.org/159844 How can ports be removed if the solutions for them is in gnats? They won't before deleting ports, we always check gnats, if a PR exists then we leave the ports so that the PR can be committed regards, Bapt Ok, thank you for clarification, i didn't know that. But anyway i think that the reason (that it doesn't builds with postgresql74-server), because of this port ever find it's way into this list, is not a reason at all. -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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: Bumping lightning to 1.0b5 so it works with Thunderbird 6.0.1
Hi Florian, On 09/08/11 17:51, Florian Smeets wrote: On 08.09.2011 02:16, Lawrence Stewart wrote: Hi Gecko team, The update from Thunderbird 6.0 to 6.0.1 has stopped the Lightning 1.0b5pre plugin from working - it claims to be incompatible with the new version of Thunderbird and can't be enabled. Lightning 1.0b5 seems to work fine with Thunderbird 6.0.1 on my wife's windows PC, so I'm guessing a very minor bump to the lightning build source is needed to get it working again. If you're aware of this issue then great, but if not, just wanted to bring it to your attention so that it's on your radar. Hi Lawrence, did you reinstall the built xpi? It's usually located here /usr/local/share/lightning/lightning-thunderbird.xpi. That one should be compatible. You are indeed correct, forcibly removing and re-adding the plugin solved it, sorry for the noise. I'm working on making this step automatic, but I'm not there yet, it's on the TODO list ;) Would be cool, but this was most definitely a case of PEBKAC. I've had to do that step in the past. Not sure why I thought I'd done it this time and it didn't work. Move along, nothing to see here... Cheers, Lawrence ___ 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-system priorities rant (Re: sysutils/cfs)
On 08.09.2011 04:42, Greg Byshenk wrote: For many people, what THERE IS A PORT OF IT actually -means- is that the user can go to ports and install a -working- version of the software, not merley that there is something called 'IT' somewhere in the ports tree that may or may not work. Some ports -- both maintained or disowned -- will always be behind the upstream. Some ports will always be better than others. Simply removing those, where the perceived quality drops below somebody's subjective threshold does not improve quality. Having a poor port of an obscure piece of software is better, than no port at all. And, yes, this is the core of the disagreement... Yours, -mi ___ 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-system priorities rant (Re: sysutils/cfs)
Mikhail T. wrote: Having to deal with RedHat's yum at work, I got to say, I'd rather be building from source, than installing from consistent packages, that somebody else built *to their* tastes. Fedora crap is a very bad example. The canonical example of a binary distribution which *works* is Debian. You can always very easily compile a source Debian package to *your* taste, almost as easily as a FreeBSD port. You don't need to compile the hundreds of packages that sit on your hard disk, maybe you are interested in tweaking a couple of ports to your liking and you get the benefit of a much faster installation and upgrade of all the pristine packages. No, I don't want FreeBSD to go in that direction at all. Let RedHat cater to that market While i think that going in this direction will be very beneficial to FreeBSD and that ReHat doesn't come anywhere close to cater to this market (i work in a lab which is almost 100% RedHat since many years, and i am not happy at all with that. As much as Ubuntu is despised here, it is light years ahead of the Fedora always beta stuff). -- Michel TALON ___ 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-system priorities rant (Re: sysutils/cfs)
Am 08.09.2011 16:15, schrieb Mikhail T.: Having a poor port of an obscure piece of software is better, than no port at all. A poor port is undesirable (and shouldn't be in the tree in the first place). An obscure piece of software is undesirable (and shouldn't be ported in the first place). Now guess what a poor port of an obscure piece of software is. We're not there to run a museum of horrors, and we're not the starting point or sole provider of such software. In fact we should not even attempt to do that. People interested in that obscure software can either help themselves without a port, can organize the necessary assistance, or should not be running 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: sysutils/cfs
Am 07.09.2011 17:53, schrieb Mikhail T.: The policy -- up until fairly recently -- was to remove ports, that *fail to build* for a while. This made sense -- if the port remains unbuildable long enough, then, certainly, it is no longer in use. The /new/ policy of removing ports for much lighter offenses, such as having vulnerabilities, has already caused so many objections, that it is time to abolish it. I don't see ports being killed the first day they are vulnerable. They are killed if they're dead and vulnerable though, and that's good. A maintainer timeout will allow another developer to perform a fix. To completely remove the port (if that has to happen at all), a much longer warning is warranted. Which can certainly be negotiated (and an EXPIRATION_DATE shifted) if and only if the fix is really going to happen. A case like I'll fix it after vacation might be workable. However if you make empty promises repeatedly noone will care. Yes, the matter is exactly that: your wanting to remove something, that continues to build and remains in use. You followed, what you think is an old policy, and are getting flack from people like myself, who object to the (new) policy. Nothing personal... End users are not obliged to delete ports we've removed from the ports, so I wonder what the heck the difficulty is with we no longer care. We're not enforcing port removals on end user's computers. We're not Google removing applications from your Android phone. We're not Apple doing the same to your iOS phone. So can this discussion be ended? If the port was in active use and maintained, we would not be deprecating it. Again. This is not about a particular port -- Julian, myself, and other objectors can fix /any/ port, but we can not fix them /all/, so blaming us for not submitting patches is wrong. Rather than waste your time discussing that you could go maintain and/or fix the ports you feel should not be deprecated. We object to the new policy, because we believe, only those ports, that fail to build, ought to be removed. Problematic ports ought to remain in the tree (as long as they build) -- to make it easier for people to continue using them and/or offer to maintain them. If there remains a vulnerability, then, of course, a loud warning (with a link to the advisory(ies)) is in order, but the users ought to make their own choices and evaluations. They do even after port removal. If a port is known broken and there is no prospect of a fix, it must go. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Am 08.09.2011 13:52, schrieb Matt Burke: Changing to a hypothetical example, why would an Apache vulnerability in mod_rewrite in the least bit bother a person who doesn't have the module enabled, which I believe is the standard configuration? Would you prefer Apache be deleted from ports if it took longer than expected to fix it? That wouldn't happen anyways because the package is actively maintained, unlike many of the ports the discussion is about. What the current FreeBSD policy of actively deleting perfectly usable ports instead of putting a mild hurdle in the way is saying, is that FreeBSD will stop me doing what I may want to do because FreeBSD knows best. The port isn't perfectly usable (because that would mean it's usable in all circumstances for all advertised purposes, which is explicitly not the case in the light of known vulnerabilities). I want machines, tools, to do as *I* say not the other way round, whether it's good for me or not. If I wanted nannying and interference, I'd install Ubuntu. No, you'd use a managed installation. Nobody stands there pointing a gun at your head and forces you to uninstall a port that got removed from the ports/ tree. If people could recognize that, it might help get the derailed discussion back on the right track. ___ 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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
On Sep 8, 2011, at 7:35 AM, Miroslav Lachman 000.f...@quip.cz wrote: Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? I am very sorry to hear that. I already filed a PR after you sent your report to this mailing list, and followed up with portmgr@ earlier this week. I believe they are doing an -exp run before committing the change. I will ping them again if there is no progress in the next few days. Sorry again for the inconvenience.___ 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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
On Thu, Sep 08, 2011 at 01:19:26PM -0400, Sahil Tandon wrote: On Sep 8, 2011, at 7:35 AM, Miroslav Lachman 000.f...@quip.cz wrote: Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. Will the fix be committed to the ports tree? I upgraded Postfix on another machines yesterday and get the same error as reported month ago - upgrade removed postfix from manualy created group. Should I send PR for this? I am very sorry to hear that. I already filed a PR after you sent your report to this mailing list, and followed up with portmgr@ earlier this week. I believe they are doing an -exp run before committing the change. I will ping them again if there is no progress in the next few days. Sorry again for the inconvenience.___ 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 exp-run is running right now, some news about this in the next couple of days regards, Bapt pgpiwz8T7k8sh.pgp Description: PGP signature
Re: ports-system priorities rant (Re: sysutils/cfs)
On Thu, Sep 08, 2011 at 06:36:46PM +0200, Matthias Andree wrote: Am 08.09.2011 16:15, schrieb Mikhail T.: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Wait -- what? Why should something not be ported if it's not popular? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpp62DGAXkxK.pgp Description: PGP signature
Re: sysutils/cfs
Matthias Andree wrote: Am 07.09.2011 17:53, schrieb Mikhail T.: The policy -- up until fairly recently -- was to remove ports, that *fail to build* for a while. This made sense -- if the port remains unbuildable long enough, then, certainly, it is no longer in use. The /new/ policy of removing ports for much lighter offenses, such as having vulnerabilities, has already caused so many objections, that it is time to abolish it. I don't see ports being killed the first day they are vulnerable. They are killed if they're dead If long term dead, fine, but if a port is deleted between releases, without prior warning variables set in Makefile at last release tag, then we deny release users any warning any code to fix, ... Unless user hurdles the extra un-necessarily premature obstacle of CVS Attic; as FreeBSD will have just irresponsibly annoyed user, it's a bad time to expect user to waste extra time learning FreeBSD web or CLI interface to CVS for Attic, additional to fixing a broken port and filing a send-pr. Some users may react: Time for another BSD or Linux with more mature code management. Broken ports should first be marked BROKEN= through a release cycle so more users have time to consider a fix via send-pr. and vulnerable though, and that's good. No. Vulnerable depend on user context you, as others have already explained,it would be cheeky of FreeBSD to dictate policy to others, when we don't know their circumstances, there are Makefile variables, as others have already explained, to help the User decide, not us. A maintainer timeout will allow another developer to perform a fix. To completely remove the port (if that has to happen at all), a much longer warning is warranted. Which can certainly be negotiated (and an EXPIRATION_DATE shifted) if and only if the fix is really going to happen. No. Wooly thinking, that would require commiters making judgements, changing variables, make it easy automatic. We've already read a better proposal for some time/ release/ macro var. Read back on the thread. A case like I'll fix it after vacation might be workable. However if you make empty promises repeatedly noone will care. You'r assuming some rush crusade to delete, backed by time consuming analogue humans making value judgements. Not good, better leave it to the state machine of send-pr automatic non short term var macros for expire. Yes, the matter is exactly that: your wanting to remove something, that continues to build and remains in use. You followed, what you think is an old policy, and are getting flack from people like myself, who object to the (new) policy. Nothing personal... End users are not obliged to delete ports we've removed from the ports, Neither would you be obliged to delete eg your gcc if src/ unbundled it, but you'd find it pretty annoying after no warning, to suddenly need to look for a backup in the Attic. so I wonder what the heck the difficulty is with we no longer care. We no longer care ... to be responsible, we removed it without warning. Or We no longer care ... to give this without warning, so we added some BROKEN= / DEPRECATED= / FORBIDDEN= so users can make their Own decision in light of their circumstances. We're not enforcing port removals on end user's computers. We're not Google removing applications from your Android phone. We're not Apple doing the same to your iOS phone. So can this discussion be ended? When the ill considered ports/ killing campaign is ceased. If the port was in active use and maintained, we would not be deprecating it. Not true. Example: Procmail too was proposed for the ports killing crusade. ( A FreeBSD developer who doesnt have time for ports@ was shocked when he heard that today.) Again. This is not about a particular port -- Julian, myself, and other objectors can fix /any/ port, but we can not fix them /all/, so blaming us for not submitting patches is wrong. Rather than waste your time discussing that you could go maintain and/or fix the ports you feel should not be deprecated. Wrong. Re-Read Mikhail above Again. This is not ... We object to the new policy, because we believe, only those ports, that fail to build, ought to be removed. Problematic ports ought to remain in the tree (as long as they build) -- to make it easier for people to continue using them and/or offer to maintain them. If there remains a vulnerability, then, of course, a loud warning (with a link to the advisory(ies)) is in order, but the users ought to make their own choices and evaluations. They do even after port removal. Wrong. They will find the port they were going to look at has been irresponsibly removed without warning, no code left there to fix. If a port is known broken and there is no prospect of a fix, it must go. no prospect of a fix is a value judgement not easily made in a rush. ( some value judgement in the ports crusade
