Re: sysutils/cfs
Hi, If not, see to backups and/or migration in due time. We can't possibly support software that is unsupported by the vendor, but that's what We already do. Been working just fine for many years. No I wont tell you where, because I don't trust you a few other irresponsible ports crusaders who should have their commit bits revoked to protect the FreeBSD we've held dear since before version numbers. Please consider resigning. 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 17 Sept, http://berklix.org/sfd/ 22 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: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, or leave, or be revoked. FreeBSD would be better without immature ports slaughterers. 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 17 Sept, http://berklix.org/sfd/ 22 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 deprecations (was: sysutils/cfs)
No, I won't tell you which window manager, because if I want to use it again I don't want to discover that calling it to the minds of some of the ports people caused it to be deleted. That summarises it. I too avoided mentioning a port for fear of the immature kids who destroy ports. At least one only got his commit bit recently. Its time a few commit bits were revoked. 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 17 Sept, http://berklix.org/sfd/ 22 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: sysutils/cfs
On Mon, Sep 12, 2011 at 11:32:01PM +0200, Julian H. Stacey wrote: Please consider resigning. plonk. mcl ___ 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 12.09.2011 23:32, schrieb Julian H. Stacey: Hi, If not, see to backups and/or migration in due time. We can't possibly support software that is unsupported by the vendor, but that's what We already do. Been working just fine for many years. No I wont tell you where, because I don't trust you a few other irresponsible ports crusaders who should have their commit bits revoked to protect the FreeBSD we've held dear since before version numbers. Please consider resigning. Julian, while you are entitled to mention your opintion, even in Germany, that right ends where it affects other people's personal dignity, honesty and rights, and this posting of yours was trespassing the red line with the irresponsible ports crusaders part that is entirely inadequate. If you care to avoid prosecutors and judges, stick to the facts, and avoid insults. We can have a discussion about facts, but yours is an ad-hominem attack. And as rebuttal of your we already do [support unsupported software] claim, please fix, until end 2011, in mail/procmail, in collaboration with sunpoet@: - the design flaw that with a .procmailrc that consists of a set of samples from the procmail documentation you end up with random misdeliveries and possibly bounced or lost mail in the case of write hitches on the mail spool and/or your $HOME. - all things that 3.23pre (available from the rwth-aachen mirror) fixed - all things for which there are non-cosmetic TODO's in the various documents through procmail Unless and until that happens, there's no point in arguing that we were routinely and universally filling support in for upstream maintainers. ___ 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 deprecations (was: sysutils/cfs)
On 12 September 2011 22:07, Julian H. Stacey j...@berklix.com wrote: No, I won't tell you which window manager, because if I want to use it again I don't want to discover that calling it to the minds of some of the ports people caused it to be deleted. That summarises it. I too avoided mentioning a port for fear of the immature kids who destroy ports. At least one only got his commit bit recently. Its time a few commit bits were revoked. Destroyed? Hardly. Put away for 'safe keeping', if you prefer. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports-system priorities rant (Re: sysutils/cfs)
Hi, Reference: From: Chris Rees cr...@freebsd.org Date: Tue, 13 Sep 2011 18:44:37 +0100 Message-id: cadlo83-zcvaeyznw5dtehv1tosburzllr2hjxfjrx_qewph...@mail.gmail.com Chris Rees wrote: On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com wrote: Matthias Andree wrote: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, or leave, or be revoked. FreeBSD would be better without immature ports slaughterers. Julian, Your arguments have become excessively ad-hominem, and please don't think you're upsetting anyone in the slightest with them. Use rational and technical arguments, or take a break. Chris Your proposal to remove procmail among others was ridiculous. Please consider resigning Chris. 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 17 Sept, http://berklix.org/sfd/ 22 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)
Chris Rees wrote: On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com wrote: Matthias Andree wrote: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, or leave, or be revoked. FreeBSD would be better without immature ports slaughterers. Julian, Your arguments have become excessively ad-hominem, and please don't think you're upsetting anyone in the slightest with them. Use rational and technical arguments, or take a break. Chris Revised reply as I subsequently notice Chris Rees lack of attribution falsely implies I wrote stuff I did not. the first place). Bullshit! I did not write that. That was From Erik Trulsson ertr1...@student.uu.se In reply to Matthias Andree Fri, 9 Sep 2011 07:22:10 +0200 http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/070018.html Seems Chris's butcher colleague Matthias annoyed Erik too. Further Chris's unattributed chunk Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. Was not from or to me, but was: From: Matthias Andree mand...@freebsd.org Date: Fri, 09 Sep 2011 18:06:30 +0200 To: Erik Trulsson ertr1...@student.uu.se http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/070075.html Only Chris's final bit had me as sender or recipient, namely: I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, which was not to Chris but was: From Julian H. Stacey jhs at berklix.com Tue Sep 13 08:44:10 UTC 2011 To Matthias Andree http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/070164.html Chris's lack of attribution checking was misleading, but not suprising, Chris Rees it was who wanted to kick out procmail. Poor judgement. A few ports butchers should lose commit bits before ports/ will be safe again. 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 17 Sept, http://berklix.org/sfd/ 22 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)
Hi, Reference: From: Chris Rees cr...@freebsd.org Date: Tue, 13 Sep 2011 19:25:01 +0100 Message-id: CADLo838gUfrGhOYWYBym=5yiatyjy8r9bndxcu8gmbjebre...@mail.gmail.com Chris Rees wrote: On 13 September 2011 18:54, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Chris Rees cr...@freebsd.org Date: Tue, 13 Sep 2011 18:44:37 +0100 Message-id: cadlo83-zcvaeyznw5dtehv1tosburzllr2hjxfjrx_qewph...@mail.gmail.com Chris Rees wrote: On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com wrote: Matthias Andree wrote: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, or leave, or be revoked. FreeBSD would be better without immature ports slaughterers. Julian, Your arguments have become excessively ad-hominem, and please don't think you're upsetting anyone in the slightest with them. Use rational and technical arguments, or take a break. Chris Your proposal to remove procmail among others was ridiculous. Please consider resigning Chris. Not mine. Please consider reading mailing lists properly rather than jumping to conclusions. Chris Chris Rees You are False. You posted this: http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/069860.html Chris Rees utisoft at gmail.com Sun Sep 4 16:56:37 UTC 2011 Guys, I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Please would someone consider stepping up to fix and maintain it? It has two months to live. Thanks! Chris [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137378 - - Chris Rees | FreeBSD Developer You then pressurised new Maintainer to fix quick or delete, despite several of us told you in use working fine for ages. Chris Rees, you are butchering ports/ You were give a commit bit 11th June 2011. http://www.freebsd.org/news/newsflash.html Its time that commit bit was revoked to protect ports/ along with perhaps 3 other misguided butchers' commit bits, perhaps one of whom might have been your commit mentor. 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 17 Sept, http://berklix.org/sfd/ 22 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 13 Sep 2011 20:57, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Chris Rees cr...@freebsd.org Date: Tue, 13 Sep 2011 19:25:01 +0100 Message-id: CADLo838gUfrGhOYWYBym= 5yiatyjy8r9bndxcu8gmbjebre...@mail.gmail.com Chris Rees wrote: On 13 September 2011 18:54, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Chris Rees cr...@freebsd.org Date: Tue, 13 Sep 2011 18:44:37 +0100 Message-id: cadlo83-zcvaeyznw5dtehv1tosburzllr2hjxfjrx_qewph...@mail.gmail.com Chris Rees wrote: On 12 September 2011 22:18, Julian H. Stacey j...@berklix.com wrote: Matthias Andree wrote: An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop it. No. You should stop advocating killing ports, or leave, or be revoked. FreeBSD would be better without immature ports slaughterers. Julian, Your arguments have become excessively ad-hominem, and please don't think you're upsetting anyone in the slightest with them. Use rational and technical arguments, or take a break. Chris Your proposal to remove procmail among others was ridiculous. Please consider resigning Chris. Not mine. Please consider reading mailing lists properly rather than jumping to conclusions. Chris Chris Rees You are False. You posted this: http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/069860.html Chris Rees utisoft at gmail.com Sun Sep 4 16:56:37 UTC 2011 Guys, I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Please would someone consider stepping up to fix and maintain it? It has two months to live. Thanks! Chris [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137378 - - Chris Rees | FreeBSD Developer You then pressurised new Maintainer to fix quick or delete, despite several of us told you in use working fine for ages. Chris Rees, you are butchering ports/ You were give a commit bit 11th June 2011. http://www.freebsd.org/news/newsflash.html Its time that commit bit was revoked to protect ports/ along with perhaps 3 other misguided butchers' commit bits, perhaps one of whom might have been your commit mentor. You are quite hilarious. I did not suggest depreciation of procmail, so I'm unsure why you keep asserting that. Why don't you count the number of ports I've actually 'butchered'? The cvs-ports list is public and easy to search. You're asserting that I've turned up and suddenly started to destroy the tree, which is anything but true, and I find it quite pathetic. Perhaps you need to take a break-- I'm rather tired of being called to defend myself, I've plenty of better things to be doing. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Matthias Andree wrote: claim, please fix, until end 2011, in mail/procmail, in collaboration with sunpoet@: Procmail works for me, for a friend, others on list. It was remains irresponsible to try to force satisfied users to fix other people's reported problems on threat of ports being otherwise removed. FreeBSD would be safer dropping irresponsible ports commit bits inc. yours. 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 17 Sept, http://berklix.org/sfd/ 22 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 9/13/11 4:52 PM, Chris Rees wrote: I'm rather tired of being called to defend myself, I see no reason why you should find it necessary. Bravo for the work you've done. I've plenty of better things to be doing. Agreed. Julian, amongst others this past few weeks, have successfully made it indefinitely to my bit bucket. I suggest you do the same, and take the advice of /etc/motd: Shut Up and Code!!! :-) -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ 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 10 September 2011 06:45, Conrad J. Sabatier conr...@cox.net wrote: On Fri, 09 Sep 2011 19:05:49 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 11:09, schrieb Conrad J. Sabatier: On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: 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. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. If a port may need to be reinstalled then you failed organize proper backups. Not a valid point here. Not necessarily. A simple bump in library versioning could require ports to be rebuilt. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? Can we please change the subject line? Most of us are in agreement that this particular case is not that questionable. This thread is for volunteers to fix cfs. Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 11:09, schrieb Conrad J. Sabatier: You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. If a port may need to be reinstalled then you failed organize proper backups. Not a valid point here. Last I knew, if port X uses services provided by port Y and port Y changes, port X often needs to be rebuilt and reinstalled even though nothing in port X has changed. AFAIK this has nothing to do with backups. If you've found a way to avoid ever having to rebuild, say, kdiff3 when something changes in KDE, I'm sure the authors of portupgrade and portmaster would like to hear about it! It would greatly simplify their job. ___ 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 10.09.2011 16:08, schrieb per...@pluto.rain.com: Last I knew, if port X uses services provided by port Y and port Y changes, port X often needs to be rebuilt and reinstalled even though nothing in port X has changed. AFAIK this has nothing to do with backups. If you've found a way to avoid ever having to rebuild, say, kdiff3 when something changes in KDE, I'm sure the authors of portupgrade and portmaster would like to hear about it! It would greatly simplify their job. Interesting question that you pose. In cases where only the so-called SONAME of libraries in port Y changed, but not that part of the ABI that port X used, chances are we might go without it for the majority of ports, but that's not done currently. However, the versioning of .so files and FreeBSD's linker isn't currently up to such a task, so we might have to hack the executables and libraries in port X to include the new SONAME, and wouldn't get guarantees it actually worked. On the other hand, you're pointing out a problem of dead ports in the first place: if the API of (usually library) port Y changes, and port X is unmaintained, that's typically a situation where port X needs to be deprecated and removed (and also will no longer build and/or work). ___ 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)
An obscure piece of software is undesirable (and shouldn't be ported in the first place). Bullshit! I think that suffices. If the discussion is getting emotional, we should stop 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: ports deprecations (was: sysutils/cfs)
Am 10.09.2011 07:45, schrieb Conrad J. Sabatier: Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? Conrad, (courtesy Cc: after changed subject, please reply to the list) I'd see that as proactive maintenance. If there is no upstream maintainer any more, chances is that one time the port needs code changes to adapt to changes in underlying libraries. For the sake of argument, let's assume this example (I'm not sure if libpng would be a real-world instance of it, I didn't care enough to have a closer look): There are points in time when dead port X using a changed library Y needs code changes, for instance, if library Y in some old unmaintained version is vulnerable, and its fixed versions have a different API. Now, if we tell people soon enough that they may run into that problem, chances are that people never hit the problem, and chances are that people hit the problem soon - and the fewer users of the dead port are forced to make the switch, the better. The open question is, is there a point in marking a point DEPRECATED without giving an expiration date. My personal answer is no because no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and people will be disappointed because they've grown used to custom and practice and I can already see the we told you it was DEPRECATED. The real point is that the FreeBSD ports system can not fill in for the maintainers of discontinued ports. There is a certain pragmatism to as long as it builds, appears to work, and there are no known critical bugs, let's keep it, but it has this organizational drawback that it becomes custom and practice at some time, and ends up hurting more people in the end. Best regards, Matthias ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports deprecations (was: sysutils/cfs)
On Sat, Sep 10, 2011 at 12:24:33PM +0200, Matthias Andree wrote: The open question is, is there a point in marking a point DEPRECATED without giving an expiration date. My personal answer is no because no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and people will be disappointed because they've grown used to custom and practice and I can already see the we told you it was DEPRECATED. The real point is that the FreeBSD ports system can not fill in for the maintainers of discontinued ports. There is a certain pragmatism to as long as it builds, appears to work, and there are no known critical bugs, let's keep it, but it has this organizational drawback that it becomes custom and practice at some time, and ends up hurting more people in the end. Maybe DEPRECATED is the wrong term for something that builds and works but has no maintainer, then. Maybe the term for it should be something like UNMAINTAINED or ABANDONED. That way, the message conveyed to the user is This appears to work for now, and there are still using it, so we aren't going to make it exceedingly difficult to install on new deployments where people feel a need for it or want to maintain compatibility with other systems. There is no guarantee it will work in six months, though. Use at your own risk. If someone wants to start maintaining it, now is the time. I think part of the problem with the disagreements in this discussion is that everyone is focused on whether something builds, whether it has an obscure vulnerability that only affects particular use cases, and whether there is an upstream maintainer. Meanwhile, nobody seems to be discussing whether anyone uses it. I used a window manager in FreeBSD for about five years that had not upstream maintainer, because while the creator still maintained the codebase on his Website he no longer used it himself and never put any time into upkeep. Luckily, it was stable, had no known vulnerabilities, and did not appear to need any feature additions, either. It was my favorite window manager during that entire time and, though I've moved on early this year, the switch to a new window manager turns out to be a bit of a trade-off rather than a clear improvement -- but a trade-off that I think suits my current needs. No, I won't tell you which window manager, because if I want to use it again I don't want to discover that calling it to the minds of some of the ports people caused it to be deleted. Anyway, my point is that someone was *using* it, and quite liked it. If something is stable and secure and has an active maintainer, but nobody in the world uses it (or is likely to use it) other than that maintainer, it probably doesn't matter if it gets deleted from ports. If it has no upstream maintainer, but still builds, appears to be secure for pretty much every use case, and there are hundreds of users, deleting it is likely to make a lot of people unhappy. The problem with that, of course, is that it can be very difficult to measure actual users. I just don't think we should lose sight of the fact that should be regarded as one of the most important factors in determining whether a given port should exist. If enough people want it, a maintainer will probably appear eventually, even if it's not in the next few weeks, after all. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgphmrMrwk5h2.pgp Description: PGP signature
Re: sysutils/cfs
On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote: On the other hand, you're pointing out a problem of dead ports in the first place: if the API of (usually library) port Y changes, and port X is unmaintained, that's typically a situation where port X needs to be deprecated and removed (and also will no longer build and/or work). I want to understand all the reasoning behind this stuff. Please explain the reason that library Y changing means that dependent port X should be deprecated and removed, regardless of whether it no longer builds and/or works. Note that I'm working on the assumption that your assertion it should be deprecated and removed does not rely on it no longer building and/or working because of the way you mentioned no longering building and/or working as a parenthetical addendum rather than a condition of deprecation and removal. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpKRwbf1dYTs.pgp Description: PGP signature
Re: sysutils/cfs
Am 10.09.2011 18:17, schrieb Chad Perrin: On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote: On the other hand, you're pointing out a problem of dead ports in the first place: if the API of (usually library) port Y changes, and port X is unmaintained, that's typically a situation where port X needs to be deprecated and removed (and also will no longer build and/or work). I want to understand all the reasoning behind this stuff. Please explain the reason that library Y changing means that dependent port X should be deprecated and removed, regardless of whether it no longer builds and/or works. Note that I'm working on the assumption that your assertion it should be deprecated and removed does not rely on it no longer building and/or working because of the way you mentioned no longering building and/or working as a parenthetical addendum rather than a condition of deprecation and removal. I suppose you missed the meaning of if the API of port Y changes. API = application programming interface. This implies that either the application no longer builds, or it is known that it would behave inappropriately with the new library (because semantics changed). This is just one of the many reasons why a dead port may stop working. ___ 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 deprecations (was: sysutils/cfs)
On Sat, 10 Sep 2011 12:24:33 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 10.09.2011 07:45, schrieb Conrad J. Sabatier: Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? Conrad, (courtesy Cc: after changed subject, please reply to the list) I'd see that as proactive maintenance. If there is no upstream maintainer any more, chances is that one time the port needs code changes to adapt to changes in underlying libraries. For the sake of argument, let's assume this example (I'm not sure if libpng would be a real-world instance of it, I didn't care enough to have a closer look): There are points in time when dead port X using a changed library Y needs code changes, for instance, if library Y in some old unmaintained version is vulnerable, and its fixed versions have a different API. Now, if we tell people soon enough that they may run into that problem, chances are that people never hit the problem, and chances are that people hit the problem soon - and the fewer users of the dead port are forced to make the switch, the better. The open question is, is there a point in marking a point DEPRECATED without giving an expiration date. My personal answer is no because no-one will believe in a DEPRECATED tag without EXPIRATION_DATE and people will be disappointed because they've grown used to custom and practice and I can already see the we told you it was DEPRECATED. The real point is that the FreeBSD ports system can not fill in for the maintainers of discontinued ports. There is a certain pragmatism to as long as it builds, appears to work, and there are no known critical bugs, let's keep it, but it has this organizational drawback that it becomes custom and practice at some time, and ends up hurting more people in the end. Yes, I understand what you're saying, and I don't disagree at all, really. I'm coming to realize that I initially overestimated the extent of this latest round of ports cleanups. It seemed enormous at first, but then, looking back over some of the announcements containing the lists of ports due for deletion, I see now that it's really nowhere near as extensive as my initial impression led me to think. So, basically, I'm cool with what's going on. I did do some checking through the lists one more time last night, and put in a few requests to assume maintainership of some ports that I did think were perhaps being prematurely scheduled for removal, but overall, I have no objections whatsoever to the remainder of the them being dropped, and certainly am not interested in investing the time or effort to see what may need to be done to save them. The majority simply aren't worth it, IMHO. :-) Thanks. I'm glad we do, in fact, see eye-to-eye on this. And as usual, the policy FreeBSD has in place on this matter *is*, in fact, a sane, sensible and practical one. Please excuse me if I did, for a moment, appear to be having a knee-jerk reaction. :-) Take care, Conrad -- Conrad J. Sabatier conr...@cox.net ___ 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 Sat, Sep 10, 2011 at 10:38:55PM +0200, Matthias Andree wrote: Am 10.09.2011 18:17, schrieb Chad Perrin: On Sat, Sep 10, 2011 at 12:09:16PM +0200, Matthias Andree wrote: On the other hand, you're pointing out a problem of dead ports in the first place: if the API of (usually library) port Y changes, and port X is unmaintained, that's typically a situation where port X needs to be deprecated and removed (and also will no longer build and/or work). I want to understand all the reasoning behind this stuff. Please explain the reason that library Y changing means that dependent port X should be deprecated and removed, regardless of whether it no longer builds and/or works. Note that I'm working on the assumption that your assertion it should be deprecated and removed does not rely on it no longer building and/or working because of the way you mentioned no longering building and/or working as a parenthetical addendum rather than a condition of deprecation and removal. I suppose you missed the meaning of if the API of port Y changes. API = application programming interface. This implies that either the application no longer builds, or it is known that it would behave inappropriately with the new library (because semantics changed). That would have been an unwarranted assumption. If the API changes, it might mean a couple of changes were made -- and they do not affect the parts of the API that port X uses. I chose to take what you said at face value, rather than make a bunch of assumptions about it. Thanks for clearing up your intended meaning, though. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgp66Owl5ETND.pgp Description: PGP signature
ports deprecations (was: sysutils/cfs)
Matthias Andree matthias.and...@gmx.de wrote: Am 10.09.2011 16:08, schrieb per...@pluto.rain.com: Last I knew, if port X uses services provided by port Y and port Y changes, port X often needs to be rebuilt and reinstalled even though nothing in port X has changed. AFAIK this has nothing to do with backups. If you've found a way to avoid ever having to rebuild, say, kdiff3 when something changes in KDE, I'm sure the authors of portupgrade and portmaster would like to hear about it! It would greatly simplify their job. Interesting question that you pose. In cases where only the so-called SONAME of libraries in port Y changed, but not that part of the ABI that port X used, chances are we might go without it for the majority of ports, but that's not done currently. What about the case where Y's API and SONAME did *not* change, but its PORTVERSION or PORTREVISION was bumped to reflect a bugfix? No change to X is needed at all, but * X may still need to be rebuilt (e.g. if Y is statically linked into X's executable(s)), and * portupgrade/portmaster will probably determine that X needs to be rebuilt -- even if it actually doesn't -- because they have no way of determining how pertinent the change in Y was to the way Y is used in X. I believe Conrad's original point[1], that a port (X) may need to be rebuilt and reinstalled even though nothing about it has changed _or needs to change_, stands. [1] http://lists.freebsd.org/pipermail/freebsd-ports/2011-September/070022.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On Fri, Sep 09, 2011 at 07:27:51AM +0200, Erik Trulsson wrote: 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. I can't necessarily speak for everyone, but I suspect that this is why 'being maintained' is seen as important. All software has bugs; what is important is that they are fixed as they are discovered, rather than being left to rot. -- 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
On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org 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. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. It feels like this latest ports collection cleanup effort most likely started with the best intentions, but is now fast becoming a runaway locomotive. Please, can we try to maintain the sanity and restraint that FreeBSD has always been known for? -- Conrad J. Sabatier conr...@cox.net ___ 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
Greg Byshenk wrote: On Fri, Sep 09, 2011 at 07:27:51AM +0200, Erik Trulsson wrote: 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. I can't necessarily speak for everyone, but I suspect that this is why 'being maintained' is seen as important. All software has bugs; what is important is that they are fixed as they are discovered, rather than being left to rot. Sorry, but maintained doesn't mean any quarantee of quick and proper fix. FreeBSD it-self has many known bugs unfixed for a years. (and some of them are really serious) Does it mean that we should stop using FreeBSD, deinstall it from all servers and use something else? I don't think so. I am happy user of FreeBSD for more than 10 years, because it gives me a freedom of choice - not enforcing me to anything. I am expecting warning message in case of some problem in base or ports / packages, but I am here to make a decision what to do next. If I like foreign decision, I will use another OS, which can silently uninstall affected packages... but I don't like this idea! -- From my point of view, there are huge pressure in cleaning ports by removing anything suspicious. There are more and more people working on removing ports. FreeBSD lacks man power on another places. For example I repeatedly sent some improvements and fixes to freebsd-rc in last few years without any reaction. It's OK, I can maintain it privately, but nobody else will benefit from this work. So FreeBSD have not working iSCSI initiator rc.d script in these days, but will have few ports less... I don't think this is the right way to go, but I can live with it. I know that it is all about interest of other volunteers. Just my $0.02 to this almost useless discussion. 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: sysutils/cfs
On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: Am 08.09.2011 13:52, schrieb Matt Burke: 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). And just how in the world can you verify that *any* port is perfectly usable by your definition? Should we just go ahead and delete every port in the collection then? -- Conrad J. Sabatier conr...@cox.net ___ 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/08/11 17:54, Matthias Andree wrote: 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 British Engligh at least, perfectly can mean adequately e.g. A scaffold pole and a short wall is a perfectly usable jack for changing a car tyre. Apologies. However, it is still the case that software with known security vulnerabilities is almost always still usable for the most part. If the kernel had a flaw which took someone with a username exactly 17 characters long to have UID 0, would you refuse to, or be unable to use the operating system until it's fixed? What if I mentioned FreeBSD has a 16-character hard-coded limit on usernames? Nobody stands there pointing a gun at your head and forces you to uninstall a port that got removed from the ports/ tree. If someone deletes a package I use from ports, they are FORCING me to jump through an awful load of hoops to get what I want/need. Let's look at the subject of this thread: What happens if I'm a CFS user and my hard disk dies? I install the latest release, pull my backups back in, and find that the FreeBSD people have decided they don't want me to be able to access my encrypted data any more. What do I do? Attempt to compile CFS from vendor source? Waste time trying to re-make a port? Install the ports tree from a FreeBSD6.1 CD I have lying around? Just install some other OS? What exactly is the administrative overhead of having a FORBIDDEN, etc port in the tree if it compiles, works, and people are happy to use it regardless of its flaws? ___ 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 09.09.2011 11:09, schrieb Conrad J. Sabatier: On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org 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. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. If a port may need to be reinstalled then you failed organize proper backups. Not a valid point here. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. ___ 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 09.09.2011 14:38, schrieb Matt Burke: If someone deletes a package I use from ports, they are FORCING me to jump through an awful load of hoops to get what I want/need. No. If people would please take note that the package does *not* magically disappear from your computers because someone deletes it from ports -- and usually it has been abandoned by the upstream years before that happens. Let's look at the subject of this thread: What happens if I'm a CFS user and my hard disk dies? I install the latest release, pull my backups back in, and find that the FreeBSD people have decided they don't want me to be able to access my encrypted data any more. What do I do? It's not FreeBSD people who've decided that, but the upstream vendor. Don't use unsupported/unmaintained software for critical purposes, it's as simple as that. I refuse (as one who vouches for removal of dead ports) to be held as a scapegoat for someone else's mistakes. The whole discussion turns into wanting FreeBSD to jump in if someone else abandons their software. That won't work. Attempt to compile CFS from vendor source? Possibly. If not, see to backups and/or migration in due time. We can't possibly support software that is unsupported by the vendor, but that's what you're asking for. Waste time trying to re-make a port? In need, check it out from the Attic and beat it into shape. Install the ports tree from a FreeBSD6.1 CD I have lying around? Quick answer. Just install some other OS? As though that would fix anything about upstream disappeared issues. What exactly is the administrative overhead of having a FORBIDDEN, etc port in the tree if it compiles, works, and people are happy to use it regardless of its flaws? That's been answered often enough. No need to reiterate the arguments. ___ 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 Fri, 09 Sep 2011 19:05:49 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 11:09, schrieb Conrad J. Sabatier: On Thu, 08 Sep 2011 18:54:36 +0200 Matthias Andree mand...@freebsd.org wrote: 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. You fail to take into account the case where a port may need to be reinstalled. An extraordinary effort is required if the port no longer exists in the ports tree. If a port may need to be reinstalled then you failed organize proper backups. Not a valid point here. Not necessarily. A simple bump in library versioning could require ports to be rebuilt. Frankly, I'm growing increasingly concerned that this push to eliminate ports is getting out of control. I don't much care for the notion that, having invested the time in installing, configuring and tuning a certain set of software packages, suddenly the rug could be pulled out from under me, so to speak, in essence *forcing* me to abandon using certain packages or else deal with maintaining them (in the ports maintainer sense) on my own. The rug is pulled by the upstream maintainers abandoning their software, not by FreeBSD no longer packaging it years after the fact. While I understand the reasoning behind this, I still feel that as long as a package continues to build and run without any known issues, then why be in a rush to drop it? The argument that the ports collection is not a museum is valid to some degree, but if a package is still usable (and useful), then aren't we shooting ourselves in the foot by dropping it? -- Conrad J. Sabatier conr...@cox.net ___ 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: 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: 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: 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: 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: 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
Re: sysutils/cfs
On Mon, 05 Sep 2011 12:05:35 +0200 Julian H. Stacey j...@berklix.com mentioned: Mark Linimon wrote: On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. portmgr has no such policy. Ports get deleted all the time due to various issues. I prefer to see a 1- or 2-month warning via EXPIRATION_DATE, but that's my personal preference, not a written policy. mcl Drive by ports shootings are becoming too frequent, will get FreeBSD a bad name as immature poorly managed A solution: Ensure a policy of expiry dates expire a release after a warning is given in a previous releases (except in emergency). I second this opinion. We might have not needed the policy a while ago when such deprecations were rare. Given that we gained several people working actively on this I'd like to see some policy regarding deprecation as well. I saw several occasions when ports were deprecated for no apparent reason, so I can understand Julian and other people dissatisfaction with this. What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? Personally, I'd also love to see people deprecating ports provide a clear reasoning for deprecation in the commit message (not just deprecated some old ports etc), so one won't need to guess if he would like to fix/resurrect the port in the feature? Thanks! -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgp2aK1wO2h4c.pgp Description: PGP signature
Re: sysutils/cfs
On Sep 7, 2011, at 8:30 AM, Stanislav Sedov wrote: On Mon, 05 Sep 2011 12:05:35 +0200 Julian H. Stacey j...@berklix.com mentioned: Mark Linimon wrote: On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. portmgr has no such policy. Ports get deleted all the time due to various issues. I prefer to see a 1- or 2-month warning via EXPIRATION_DATE, but that's my personal preference, not a written policy. mcl Drive by ports shootings are becoming too frequent, will get FreeBSD a bad name as immature poorly managed A solution: Ensure a policy of expiry dates expire a release after a warning is given in a previous releases (except in emergency). I second this opinion. We might have not needed the policy a while ago when such deprecations were rare. Given that we gained several people working actively on this I'd like to see some policy regarding deprecation as well. I saw several occasions when ports were deprecated for no apparent reason, so I can understand Julian and other people dissatisfaction with this. What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? Personally, I'd also love to see people deprecating ports provide a clear reasoning for deprecation in the commit message (not just deprecated some old ports etc), so one won't need to guess if he would like to fix/resurrect the port in the feature? Portmgr is aware of the current discussion and will handle it in due time. Thank you for bringing it to our attention. -erwin___ 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 Tue, Sep 06, 2011 at 09:15:01PM -0700, Doug Barton wrote: On 09/07/2011 00:07, per...@pluto.rain.com wrote: 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, 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. 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). The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. Perhaps I have not been paying enough attention, but this is the first time I have seen this argument advanced clearly in this particular thread of discussion. I can fully understand the reasoning, now that it has been explained. (It might be obvious from this that I'm relatively new to this list.) I realize that what you're proposing sounds attractive from a purely theoretical standpoint. The problem is that it increases the maintenance burden a non-trivial amount without providing any substantive benefit. I think it might provide some benefit to users that place a premium on certain types of stability, but it probably doesn't approach offsetting the additional investment of time and effort it would require. Perhaps something could be done with little or no additional effort to help ease the process for those conservative users, probably involving some kind of notification mechanism not currently in place -- or perhaps not. I'm no expert on the management of FreeBSD's ports system. One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. I would think that the porter's handbook, at least, should mention it (perhaps with a brief explanation of why and how one might make use of it). -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpvIVs270KlM.pgp Description: PGP signature
Re: sysutils/cfs
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. 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. 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. 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). The proposal is to increase the liklihood that, come upgrade time, a release user gets a specific, actionable description of any problems that have arisen, rather than having a port that they have been using mysteriously disappear. The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. s/point/claim/ Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. To answer your question more directly, start thinking through all the possible permutations of having 4 completely separate branches of FreeBSD active and supported at the same time, with releases happening several times a year. So define a variable along the lines of NEXT_PORT_PURGE_DATE in one of the /usr/share/mk/bsd.port*.mk files, which (being part of the base) _are_ branched, and when a situation of the kind under discussion arises set the port's EXPIRATION_DATE to NEXT_PORT_PURGE_DATE. (And before you start jumping all over the details, I recognize that this is a rough first cut at a mechanism that would need some details fleshed out.) Now consider how to handle EOL branches. Last I heard, the ports tree does not claim to support EOL branches. Why does this proposal need to? Then consider that FreeBSD has _never_ supported a release-branched ports tree, precisely because it's a huge amount of additional work that we don't have person-hours for. How does this proposal require a release-branched ports tree? I realize that what you're proposing sounds attractive from a purely theoretical standpoint. The problem is that it increases the maintenance burden a non-trivial amount without providing any substantive benefit. Benefit: see above. Maintenance: I would not think that updating NEXT_PORT_PURGE_DATE as required -- a couple of times per release cycle, maybe a few more if the schedule slips repeatedly -- would constitute a significant additional maintenance burden. ___ 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! One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. http://www.freebsd.org/cgi/cvsweb.cgi/ports/?hideattic=0#dirlist For example, net/ztelnet is no longer in the ports, but: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/ztelnet/?hideattic=0 will list the files and you can download from there. -- p...@opsec.eu+49 171 3101372 9 years to 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
On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org wrote: What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? This might be reasonable for broken ports but ports with known vulnerabilities should either be fixed or removed promptly. Personally, I'd also love to see people deprecating ports provide a clear reasoning for deprecation in the commit message (not just deprecated some old ports etc), so one won't need to guess if he would like to fix/resurrect the port in the feature? This is a reasonable requirement. On 2011-Sep-07 01:35:54 -0600, Chad Perrin c...@apotheon.net wrote: One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. Any VCS worthy of the name will retain history for objects that no longer exist because you might want to look at the state as it was at some point in the past when that object still existed. CVS stores the RCS masters for these deleted files is a subdirectory 'Attic' under the original directory. The data is only accessible via CVS - either using a local repository or via CVSweb. As an example, look at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=0 I would think that the porter's handbook, at least, should mention it (perhaps with a brief explanation of why and how one might make use of it). Again, it comes down to someone with the knowledge, motivation and time to write the content. On 2011-Sep-07 10:02:42 -0700, per...@pluto.rain.com wrote: 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. ... In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. This last statement isn't true - when a port is moved or removed, a one-line reason for the change is added to /usr/ports/MOVED The package management tools are generally aware of this file. It's only going to be removed if no one fixes it. 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). This isn't necessarily a wise approach. The proposal is to increase the liklihood that, come upgrade time, a release user gets a specific, actionable description of any problems that have arisen, rather than having a port that they have been using mysteriously disappear. Again, ports don't mysteriously disappear - there will be a record of why it was removed in the MOVED file. Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. Cleaning out the cruft will still leave a very large number of ports. And a better selling point is having a large number of functional ports - having a ports tree full of ports that are broken doesn't benefit anyone. So define a variable along the lines of NEXT_PORT_PURGE_DATE in one of the /usr/share/mk/bsd.port*.mk files, which (being part of the base) _are_ branched, and when a situation of the kind under discussion arises set the port's EXPIRATION_DATE to NEXT_PORT_PURGE_DATE. Two issues: 1) Since the ports tree isn't branched and a port either exists or it doesn't exist, there needs to be a single expiration date. 2) There still needs to be a minimum expiration duration so you need a way to handle the case where a port is marked to be purged immediately before the NEXT_PORT_PURGE_DATE. -- Peter Jeremy pgpRs3WpUoaIF.pgp Description: PGP signature
Re: sysutils/cfs
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org wrote: What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? This might be reasonable for broken ports but ports with known vulnerabilities should either be fixed or removed promptly. That depends somewhat on the exact nature of the vulnerability. Depending on how the port is used a given vulnerability might not be a problem. (E.g. if a port has a vulnerability which allows a local user to become root, then it is a problem for multi-user systems with untrusted users, but for a system which only has a single user or only trusted users it would not be a significant problem.) If a port can be used safely despite existing vulnerabilities it is not at all clear it need to be removed quickly even if it is not fixed. (Marking it FORBIDDEN so potential users are warned about known problems is another thing.) -- 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
Erik Trulsson wrote: On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: On 2011-Sep-06 23:30:04 -0700, Stanislav Sedov s...@freebsd.org wrote: What about requiring that the ports deprecated should be either broken or have known published vulnerabilties for a long period of time (say 6 months) for the start? This might be reasonable for broken ports but ports with known vulnerabilities should either be fixed or removed promptly. That depends somewhat on the exact nature of the vulnerability. Depending on how the port is used a given vulnerability might not be a problem. (E.g. if a port has a vulnerability which allows a local user to become root, then it is a problem for multi-user systems with untrusted users, but for a system which only has a single user or only trusted users it would not be a significant problem.) If a port can be used safely despite existing vulnerabilities it is not at all clear it need to be removed quickly even if it is not fixed. (Marking it FORBIDDEN so potential users are warned about known problems is another thing.) I tend to agree with Erik here. In my opinion, the important thing is to let the user know about the problem, so the *user* can make an educated decision instead of having ports committers force the decision upon all users. There are many examples of security problems that might not affect all users. Users might also decide to take the risk, especially if the software in question provides a unique feature that is essential to the user and cannot be replaced. Appropriate measures can be taken to contain the risk, such as running the software inside a jail or VM. The question is how to inform the user in a reasonable and reliable way. I think ports-mgmt/portaudit already does a very good job, but it is optional, and I guess that many (maybe even most) non-expert users don't install it or don't even know about it. It might be a good idea to make portaudit a mandatory part of the ports framework and enable it by default. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing. -- Dick Brandon ___ 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 Wed, Sep 07, 2011 at 12:53:31PM +0200, Kurt Jaeger wrote: One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. http://www.freebsd.org/cgi/cvsweb.cgi/ports/?hideattic=0#dirlist For example, net/ztelnet is no longer in the ports, but: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/ztelnet/?hideattic=0 will list the files and you can download from there. Where is this documented? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpCEAG2Kgybw.pgp Description: PGP signature
Re: sysutils/cfs
On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: On 2011-Sep-07 01:35:54 -0600, Chad Perrin c...@apotheon.net wrote: One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. Any VCS worthy of the name will retain history for objects that no longer exist because you might want to look at the state as it was at some point in the past when that object still existed. CVS stores the RCS masters for these deleted files is a subdirectory 'Attic' under the original directory. The data is only accessible via CVS - either using a local repository or via CVSweb. As an example, look at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=0 My understanding is that you are saying attic is just the standard term for CVS history. Is that the case, or do I misunderstand your point? I would think that the porter's handbook, at least, should mention it (perhaps with a brief explanation of why and how one might make use of it). Again, it comes down to someone with the knowledge, motivation and time to write the content. I'm aware of that. I just wanted to support the notion so that someone with the knowledge and time might be encouraged to have the motivation. It seemed to get lost in the argumentative back-and-forth about other details in the discussion, and I thought it would be a shame for this matter to go ignored because of that. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpZZNHUTWu8r.pgp Description: PGP signature
Re: sysutils/cfs
On Wed, Sep 07, 2011 at 09:25:15AM -0600, Chad Perrin wrote: On Wed, Sep 07, 2011 at 09:37:07PM +1000, Peter Jeremy wrote: On 2011-Sep-07 01:35:54 -0600, Chad Perrin c...@apotheon.net wrote: One thing I've seen come up that I definitely think would be a good idea, though, is more accessible documentation of the CVS attic, though. I had no idea such a thing existed for old FreeBSD ports until fairly recently, and still don't know much about it. Any VCS worthy of the name will retain history for objects that no longer exist because you might want to look at the state as it was at some point in the past when that object still existed. CVS stores the RCS masters for these deleted files is a subdirectory 'Attic' under the original directory. The data is only accessible via CVS - either using a local repository or via CVSweb. As an example, look at: http://www.freebsd.org/cgi/cvsweb.cgi/ports/audio/xmms/?hideattic=0 My understanding is that you are saying attic is just the standard term for CVS history. Is that the case, or do I misunderstand your point? Almost correct. Attic is the standard term for where CVS stores files that have been deleted. -- 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 7 Sep 2011 16:53, Mikhail T. mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Chris Rees wrote: I don't actually think they've been divisive -- it's been policy for years. 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 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? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On 07.09.2011 12:04, Chris Rees wrote: However... I find it deeply troubling that you consider buildability more important than security fixes. Are you actually serious? Yes, I'm, of course, serious. As you formulated above, the question is a no brainer: software, that does not build is ultimately secure. Ha-ha... Seriously, this ought to remain up to the user. To quote an ancient principle, we are to provide mechanism, not policy. If we are aware of a problem, we ought to advise the user of it. But to completely remove the mechanism for the sake of enforcing, what we think ought to be the user's own policy, is wrong... For example, the cfs' known vulnerability strikes only, when a particular file's size exceeds 2Gb (that's about 3 CDs). I can see a number of use-cases, when the entire encrypted FS is less than that. One can certainly fit all of one's passwords, as well as high-res scans of important documents and have room to spare. It may also be possible to prevent hitting that threshold with quotas. And so on. 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: sysutils/cfs
On -10.01.-28163 14:59, Chris Rees wrote: I don't actually think they've been divisive -- it's been policy for years. 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 call four weeks for software with a security vulnerability short notice. We count a maintainer timeout as half that. 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. My problem with 'whining' (perhaps a less emotional response from me would have been better) was the sheer number of people stepping up and refusing to provide any fixes, just criticising me for wanting to remove something. It's just not constructive. 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... Patches gratefully received (this is a volunteer effort after all) 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. 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. -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: sysutils/cfs
On Wed, Sep 07, 2011 at 05:57:17PM +0200, Erik Trulsson wrote: On Wed, Sep 07, 2011 at 09:25:15AM -0600, Chad Perrin wrote: My understanding is that you are saying attic is just the standard term for CVS history. Is that the case, or do I misunderstand your point? Almost correct. Attic is the standard term for where CVS stores files that have been deleted. Okay, thanks for clearing that up. I first started using version control with any regularity in the days of Subversion, so I (for good or ill) I missed out on the CVS culture that came before it. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpqVWYtpZHXY.pgp Description: PGP signature
Re: sysutils/cfs
Peter Jeremy peterjer...@acm.org wrote: On 2011-Sep-07 10:02:42 -0700, per...@pluto.rain.com wrote: 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. ... In contrast, if the port is _no longer_ in the tree, they have no clue why it disappeared. This last statement isn't true - when a port is moved or removed, a one-line reason for the change is added to /usr/ports/MOVED The package management tools are generally aware of this file. Unfortunately, the information quality of those lines is highly variable. Absent elaboration, entries like no longer needed, obsolete, removed deprecated port, or security vulnerability are not actionable: they don't identify what would need to be done to restore the now-missing functionality. It's only going to be removed if no one fixes it. 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). This isn't necessarily a wise approach. It may not be wise, but I suspect it is widespread (and based on the discussion I think that Julian and several others would agree). I agree with Doug that we need to provide the best support possible for the largest percentage of our users. One problem in doing so is that, absent hard data, one guess is as good as another WRT to how often the largest percentage of our users check for issues in their installed ports. My guess is that the largest percentage of our users currently do _not_ monitor port vulnerabilities on an ongoing basis, and I would not expect this situation to change until * portaudit has been made a dependency of the infrastructure and enabled by default, and * there has subsequently been a release cycle on each supported branch. At that point I would think it reasonable to presume that most newly-installed or -updated systems _will_ be running portaudit if they are using ports or packages. So define a variable along the lines of NEXT_PORT_PURGE_DATE in one of the /usr/share/mk/bsd.port*.mk files, which (being part of the base) _are_ branched, and when a situation of the kind under discussion arises set the port's EXPIRATION_DATE to NEXT_PORT_PURGE_DATE. Two issues: 1) Since the ports tree isn't branched and a port either exists or it doesn't exist, there needs to be a single expiration date. My idea with NEXT_PORT_PURGE_DATE was that the port Makefile would specify EXPIRATION_DATE=$(NEXT_PORT_PURGE_DATE) so that the _advertised_ expiration date would vary depending on which base branch was in use, but that's needlessly complicated. Much simpler would be to maintain a list of the next anticipated release date for each supported branch -- I think we already have this somewhere on freebsd.org, although it is not always as up-to-date as might be desired -- and ask ports committers to consult that list and set EXPIRATION_DATE to, say, 3 months past the last next release. (3 months would allow for a month's slippage in the release, and still leave 2 months between release and expiration.) Another variant would be to provide that set of dates somewhere in /usr/ports/Mk, as (say) REL_74_PURGE_DATE, REL_83_PURGE_DATE, etc. so the committer only has to choose the latest of them and put EXPIRATION_DATE=$(REL_83_PURGE_DATE) -- or whatever -- in the Makefile. That would allow for centralized updating to account for release slips. 2) There still needs to be a minimum expiration duration so you need a way to handle the case where a port is marked to be purged immediately before the NEXT_PORT_PURGE_DATE. The above takes care of this also. In the last variant, if the latest REL_xx_PURGE_DATE is too soon, it almost certainly means that the list is out of date and needs a new entry added (for a release that will be subsequent to any currently listed). ___ 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 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, that's one of the reasons for the operational separation of ports and src. That said, users are of course welcome to operate in the manner you describe. They just shouldn't be surprised if they run into problems doing it that way. The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. s/point/claim/ Point being made by people actually doing the work. Those who don't like that answer attempting to refute it as a claim. :) Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. 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. Maintaining a high level of actual support for the ports tree is the goal here. In the near term future we're also hoping to provide some new, better tools; as well as better/more consistent package support. In order to do those things we need to make sure that we're putting our effort where it is most needed. Benefit: see above. Maintenance: I would not think that updating NEXT_PORT_PURGE_DATE as required -- a couple of times per release cycle, maybe a few more if the schedule slips repeatedly -- would constitute a significant additional maintenance burden. To put it bluntly, you don't see it because you're not the one doing the work. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
ports-system priorities rant (Re: sysutils/cfs)
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... Maintaining a high level of actual support for the ports tree is the goal here. Without paid contracts talk of high level actual support is meaningless. Both src and ports are maintained by people, to whom software-development and engineering is FUN. Support is not fun -- it is a burden. A burden we undertake (you, perhaps, more than others), but do not like... In the near term future we're also hoping to provide some new, better tools; as well as better/more consistent package support. In order to do those things we need to make sure that we're putting our effort where it is most needed. This is great, but: 1. I don't see, how the sliver of removed ports, actually, helps you there. 2. In the past consistent package support used to conflict with the loose building from source (recall the ongoing problem with major shlib numbers bogusly included in most LIB_DEPENDS lines). 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. Also, having to provide high level support for those packages limits their number. No, I don't want FreeBSD to go in that direction at all. Let RedHat cater to that market :-) To rephrase: your opinion seems to be: let's provide better support to fewer ports. I say, that's misguided -- you will not be able to significantly improve the support quality, even if you do remove the niche ports from the tree. But the removal will in itself be harmful... 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: sysutils/cfs
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, it gets tagged goes on cdrom images, packages get rolled. (Yes, Not quite the same as src/ ) cvs -Q -R export -r RELENG_8_2_0_RELEASE src # du=548 M tgz=115 M cvs -Q -R export -r RELEASE_8_2_0 ports # du=475 M tgz= 49 M cvs -Q -R export -r RELEASE_8_2_0 doc # du=100 M tgz= 27 M that's one of the reasons for the operational separation of ports and src. That said, users are of course welcome to operate in the manner you describe. They just shouldn't be surprised if they run into problems doing it that way. The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. s/point/claim/ Point being made by people actually doing the work. Those who don't like that answer attempting to refute it as a claim. :) Last I checked, freebsd.org was claiming that the very large number of supported ports was a feature. It seems that some of the ports committers disagree. 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. Maintaining a high level of actual support for the ports tree is the goal here. In the near term future we're also hoping to provide some new, better tools; as well as better/more consistent package support. In order to do those things we need to make sure that we're putting our effort where it is most needed. Benefit: see above. Maintenance: I would not think that updating NEXT_PORT_PURGE_DATE as required -- a couple of times per release cycle, maybe a few more if the schedule slips repeatedly -- would
Re: sysutils/cfs
On 9/7/11 9:28 PM, Julian H. Stacey wrote: 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, FreeBSD doese tie the ports tree to specific releases. We have ports freezes before each release, it gets tagged goes on cdrom images, packages get rolled. (Yes, Not quite the same as src/ ) Packages are tied to a specific release (and are distributed with said release). Ports are not. -- Glen Barber ___ 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 Mon, 5 Sep 2011 21:02:14 +0300 Kostik Belousov kostik...@gmail.com wrote: Second, I personally consider the crusade to remove old but compiling and working (*) ports as a damage both to the project functionality and to the project reputation. I find this whole discussion rather strange. You use the highly loaded term crusade and someone else refers to drive by ports shootings and yet you claim it is the FreeBSD ports developers who are being immature and unprofessional. I am a happy user of FreeBSD and have been for years. I currently have 1341 ports installed. From time to time that brings difficulties, but I know from experience that they will be resolved pretty quickly. I follow the ports mailing list and read /usr/ports/UPDATING. If I am using a port that is no longer being maintained and is known to have vulnerabilities or potentially data-destroying bugs, I would much prefer to know about that and, if necessary, move to another port that provides equivalent functionality, even if that means I have to learn another set of options, configurations etc. I do not want abandoned and broken software on my computer so having them removed from ports (or put into the attic) seems to me exactly right - it pushes me to learn some other program that will do the same thing more securely or more correctly. How can that be a bad thing? The irresponsible thing surely would be to leave everything in ports and wonder why FreeBSD got a reputation for supporting broken or vulnerable software. I use FreeBSD because it is so stable and does what I need it to do. Paradoxically, that stability requires constant change. Of course I understand the concern about release users who might be faced with a surprise when they upgrade. But for such users I guess upgrading is a big deal anyway and they would presumably research the impact of the move before jumping to a newer version. I suppose, for what it's worth, I just wanted to offer a different point of view from the rather negative posts I've read recently. I see the work being done to clean up the ports tree as necessary in the short term and very beneficial in the longer term. Best, Tony ___ 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 5 September 2011 22:46, Julian H. Stacey j...@berklix.com wrote: Matthias Andree mand...@freebsd.org wrote: So either Kostik, or you, or someone else steps up to maintain the port at least to the extent that the known security bugs and reported bugs get fixed, or to hell the port goes. Recent un-professional threats to throw out ports at un-necessarily short notice, with half baked assessments based on flakey challenged send-prs (viz eg all of procmail diskcheckd cfs) have been divisive, un-professional, get FreeBSD a bad name. I don't actually think they've been divisive -- it's been policy for years. The clumsy short notice threats to delete were not stopped by senior ports/ colleagues, so they're part culpable (= to blame (nod to plain English request on another thread :-)). I don't call four weeks for software with a security vulnerability short notice. We count a maintainer timeout as half that. Probably other people are afraid to criticise the ports masters especially when a ports leader accused an innocent of whining, when he (Mikhail) was just observing tech merits. For clarification, I am neither a ports master nor a leader, just a developer. Mikail is in fact a developer just like me, and in no way is he afraid of me-- we have discussed and fixed similar issues in the past, where he has kindly stepped up and worked with upstream to find a new maintainer. My problem with 'whining' (perhaps a less emotional response from me would have been better) was the sheer number of people stepping up and refusing to provide any fixes, just criticising me for wanting to remove something. It's just not constructive. FreeBSD ports is not the personal toy of the leadership, but held in trust on behalf of those who send in code fixes. Mature professionalism peer control is required. Time heads[s] rolled. Julian, you have sent some excellent patches to me in the past. You have the skills, please use them to repair the problems, or suggest an alternative bit of software. Patches gratefully received (this is a volunteer effort after all) Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
Yar Tikhiy yar.tik...@gmail.com wrote: By the way, the Debian folks invested certain effort in keeping cfs up to date. Their git repo is still available at http://smarden.org/git/cfs.git/ . In particular, the DoS fix can be easily obtained from the repo and placed under files/ in the port. So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and _do_ that. ___ 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
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. I was trying to be polite. 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? (Note that this is in no way exclusive with setting FORBIDDEN, and/or making an entry in the portaudit database, immediately upon discovering a vulnerability.) My *guess* is that the largest percentage of our users are what Julian calls release users -- those who install a release and corresponding ports, and don't touch it subsequently until they become aware of a problem. They _may_ follow the security branch for their base release, but that won't make them aware of issues that have turned up in ports. For security issues we have portaudit to handle this. Provided it is installed and activated. Perhaps it should be made into a part of the ports infrastructure, or even moved into the base, so as to be present on any machine having packages installed? ___ 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 Wed, Sep 7, 2011 at 5:09 PM, per...@pluto.rain.com wrote: Yar Tikhiy yar.tik...@gmail.com wrote: By the way, the Debian folks invested certain effort in keeping cfs up to date. Their git repo is still available at http://smarden.org/git/cfs.git/ . In particular, the DoS fix can be easily obtained from the repo and placed under files/ in the port. So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and _do_ that. You are absolutely right mate, that will be a natural step for me to take next. I just need to ensure first that I will have long-term access to an environment to test the code in. I can't help believing that reckless commitments are no better than hasty port removals. Yar ___ 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/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. I was trying to be polite. 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, 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. 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). The point has repeatedly been made that with almost 23,000 ports in the tree both innovation and maintenance become significantly more difficult. Keeping that burden as low as possible is a feature. To answer your question more directly, start thinking through all the possible permutations of having 4 completely separate branches of FreeBSD active and supported at the same time, with releases happening several times a year. Now consider how to handle EOL branches. Then consider that FreeBSD has _never_ supported a release-branched ports tree, precisely because it's a huge amount of additional work that we don't have person-hours for. I realize that what you're proposing sounds attractive from a purely theoretical standpoint. The problem is that it increases the maintenance burden a non-trivial amount without providing any substantive benefit. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: sysutils/cfs
On 07.09.2011 03:09, per...@pluto.rain.com wrote: So at this point, all that is needed is for someone interested in preserving the port -- like maybe you? -- to step up and_do_ that. The main topic here -- despite the subject line -- is not about the particular part, but about the conflicting opinions on when to remove ports from the tree. The fate of sysutils/cfs or any other individual port is, really, secondary to that discussion... Yar, myself, as well as other folks, who object to the on-going deprecations/removals of ports for the slightest of offenses, can fix /any/ port currently on the death-row, but we can not fix /all/ of them. Still, we would like them to remain in the tree -- unless they flat-out do not build. 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: sysutils/cfs
Chris Rees wrote: On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com wrote: Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. 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 (or if a firm using releases, perhaps time to allocate a staff member if a port is important to them). Yeah... perhaps if there isn't a vulnerability. At the moment it's marked FORBIDDEN, Correction: At the moment all those with 8.2-RELEASE/ports still see no FORBIDDEN, Only current At the moment sees FORBIDDEN=... DEPRECATED=... EXPIRATION_DATE=... so it's useless Correction: A port marked FORBIDDEN is not useless but forbidden, Ref.: /usr/ports/Mk/bsd.port.mk: # FORBIDDEN - Package build should not be attempted because of # security vulnerabilities. Users can delete FORBIDDEN be aware there's an issue, consider risk /or volunteering to maintain. (in this particular case BTW, a mobile laptop with cfs no net might not worry about remote attackers) -- anyone who is serious about fixing it at whatever time is welcome to check it out of the Attic -- Only any with CVS. Not anyone just with a release, who will find it gone between releases with no trace, warning, or reason given. a slight inconvenience ... ^ A Major inconvenience to any release users, for which again no warning to Release was given. for which we apologise. Not credible. Repeat drive by FreeBSD ports shootings are increasingly regular. The Attic is the standard myopic excuse, ignoring not all FreeBSD release users have CVS, or read daily bleeding edge current ports@ inc. threat of the day to destroy the next port. In the mean time, record class=brokenthe ports tree is not a museum for ancient insecure bug-ridden software/record. Drive by code shootings should not occur without warning to release users, except in emergency. 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: sysutils/cfs
Mark Linimon wrote: On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. portmgr has no such policy. Ports get deleted all the time due to various issues. I prefer to see a 1- or 2-month warning via EXPIRATION_DATE, but that's my personal preference, not a written policy. mcl Drive by ports shootings are becoming too frequent, will get FreeBSD a bad name as immature poorly managed A solution: Ensure a policy of expiry dates expire a release after a warning is given in a previous releases (except in emergency). 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: sysutils/cfs
per...@pluto.rain.com wrote: Chris Rees utis...@gmail.com wrote: Whoops, also missed a CVE -- buffer overflows can cause a DoS. Er, am I the only one who does not recognize what CVE stands for? CVE == Common Vulnerabilities and Exposures To put it simply, it's a database of security threats maintained by MITRE: http://cve.mitre.org Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie. ___ 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/05/2011 02:33, Julian H. Stacey wrote: Chris Rees wrote: On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com wrote: Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. We understand that this is your perspective, however the community in general has a different idea. 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 (or if a firm using releases, perhaps time to allocate a staff member if a port is important to them). That's an interesting idea, but incredibly unlikely to happen. Yeah... perhaps if there isn't a vulnerability. At the moment it's marked FORBIDDEN, Correction: At the moment all those with 8.2-RELEASE/ports still see no FORBIDDEN, That's what portaudit is for. The Attic is the standard myopic excuse, ignoring not all FreeBSD release users have CVS, It is available to everyone, and trivial to configure. The fact that removed ports still exist in CVS is not a myopic excuse, it's a fact. We need to make the best decisions we can to provide the best support possible for the largest percentage of our users. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: sysutils/cfs
Hi, Doug Barton wrote: On 09/05/2011 02:33, Julian H. Stacey wrote: Chris Rees wrote: On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com wrote: Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. We understand that this is your perspective, however the community in general has a different idea. Whose vision, which community ;-) I wasn't worrying about an elite user community of those who don't seem/need to care much beyond ports@ subscribers with CVS commit privs. I'm concerned about FreeBSD ports release users that excludes, how they will see un-professional ports release management, how they may dump or not adopt FreeBSD, taking projects jobs with them. People may like to ask compare about project management with people in other projects on Saturday, September 17th at http://www.softwarefreedomday.org in ~ 600 cities around the planet, FreeBSD claims to consider Principle Of Least Suprise. Best ask oursleves if FreeBSD ports release management complies. 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 (or if a firm using releases, perhaps time to allocate a staff member if a port is important to them). That's an interesting idea, but incredibly unlikely to happen. Yeah... perhaps if there isn't a vulnerability. At the moment it's marked FORBIDDEN, Correction: At the moment all those with 8.2-RELEASE/ports still see no FORBIDDEN, That's what portaudit is for. The Attic is the standard myopic excuse, ignoring not all FreeBSD release users have CVS, It is available to everyone, and trivial to configure. The fact that removed ports still exist in CVS is not a myopic excuse, it's a fact. We need to make the best decisions we can to provide the best support possible for the largest percentage of our users. Yes, So long as Users != just ports@ subscribers with CVS. Thanks. 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: Re: sysutils/cfs
On 5 Sep 2011 18:15, Mikhail T. mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Chris Rees wrote: I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. Is this the only vulnerability you are talking about? http://www.debian.org/security/2006/dsa-1138 Does not seem hard to fix at all... Listing all of the fatal problems would be helpful... -mi If it's not that hard to fix then do it. If you're not going to fix it, why are you even commenting? More noise. Stop whining and do something about it. I saw a port that is: - broken - vulnerable - unmaintained - dead upstream - has been removed by other distributions I don't use it, you don't use it, why do you care? Chris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Re: sysutils/cfs
On Mon, Sep 05, 2011 at 06:32:00PM +0100, Chris Rees wrote: On 5 Sep 2011 18:15, Mikhail T. mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Chris Rees wrote: I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. Is this the only vulnerability you are talking about? http://www.debian.org/security/2006/dsa-1138 Does not seem hard to fix at all... Listing all of the fatal problems would be helpful... -mi If it's not that hard to fix then do it. If you're not going to fix it, why are you even commenting? More noise. Stop whining and do something about it. No, it is not a noise. First, note that an issue in the local deamon can be only utilized by local users. As a consequence, there is a huge set of machines for which the cited issue is simply irrelevant. For the analogous issues that are irrelevant for 90% of the port users, look at the vulnerabilities listed for the quake ports. Second, I personally consider the crusade to remove old but compiling and working (*) ports as a damage both to the project functionality and to the project reputation. * Working exactly because users report bugs in the software, otherwise they would not be able to describe corner cases that break. I saw a port that is: - broken - vulnerable - unmaintained - dead upstream - has been removed by other distributions I don't use it, you don't use it, why do you care? See above. This is the sort of rethoric that I find damaging. The only point that I buy from the list is 'had been removed by other distributions'. Everything else is relative, and since _you_ are not the user of the package, did not even tried to use it, and obviously not estimated the risks and brokeness of the package right (as shown by two episodes, once with the NLM, second with the vulnerability), I consider the removal as frivolous and damaging. It only continues the trend, I agree. pgpYXDW4UqgUY.pgp Description: PGP signature
Re: sysutils/cfs
On 05.09.2011 13:32, Chris Rees wrote: If it's not that hard to fix then do it. Before doing it, I wanted to confirm, that there are no other, more serious vulnerabilities. Things, for which no fixes have been posted -- unlike for this particular one, which Debian fixed several years ago (before dropping it for whatever reasons). Instead of confirming (or denying), you yelled at me. Ouch... -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: sysutils/cfs
Am 05.09.2011 20:29, schrieb Mikhail T.: On 05.09.2011 13:32, Chris Rees wrote: If it's not that hard to fix then do it. Before doing it, I wanted to confirm, that there are no other, more serious vulnerabilities. Things, for which no fixes have been posted -- unlike for this particular one, which Debian fixed several years ago (before dropping it for whatever reasons). Instead of confirming (or denying), you yelled at me. Ouch... I don't see yelling. Note that Chris isn't obliged to research things that you are interested in but he isn't -- that expectation of yours is over the top. He's not your research slave^Wstudent. The point is that Chris isn't interested in fixing dead ports with known bugs, and keeping known-broken ports in the tree is dangerous to our users no matter if it's locally or remotely exploitable. Typically ports with buffer overflow vulnerabilities have more issues than the discovered ones, and unless the port is _actively_ maintained it's better to remove it, lest users shout at us for letting them run into this knife without our telling them. So either Kostik, or you, or someone else steps up to maintain the port at least to the extent that the known security bugs and reported bugs get fixed, or to hell the port goes. If neither of you is to become the maintainer, EXPIRATION_DATE stands. Regarding Kostik's damage to the project, keeping known broken ports around isn't fostering our reputation either. And, repeat message: once someone steps up to fix the issues, the port can be revived. It happens. Anyways, there are four weeks to fix the issues in the port. ___ 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 mand...@freebsd.org wrote: So either Kostik, or you, or someone else steps up to maintain the port at least to the extent that the known security bugs and reported bugs get fixed, or to hell the port goes. Recent un-professional threats to throw out ports at un-necessarily short notice, with half baked assessments based on flakey challenged send-prs (viz eg all of procmail diskcheckd cfs) have been divisive, un-professional, get FreeBSD a bad name. The clumsy short notice threats to delete were not stopped by senior ports/ colleagues, so they're part culpable (= to blame (nod to plain English request on another thread :-)). Probably other people are afraid to criticise the ports masters especially when a ports leader accused an innocent of whining, when he (Mikhail) was just observing tech merits. FreeBSD ports is not the personal toy of the leadership, but held in trust on behalf of those who send in code fixes. Mature professionalism peer control is required. Time heads[s] rolled. 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: sysutils/cfs
Doug Barton do...@freebsd.org wrote: On 09/05/2011 02:33, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. We understand that this is your perspective, however the community in general has a different idea. I suppose it may depend on how one defines the community. AFAIK there are maybe half a dozen or so developers who have recently put themselves on record as supporting the current, agressive deprecation campaign. The number who have posted in opposition may well be smaller, so you are probably right if the community is defined as consisting only of those two groups :) 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! The Attic is the standard myopic excuse, ignoring not all FreeBSD release users have CVS, It is available to everyone, and trivial to configure. The fact that removed ports still exist in CVS is not a myopic excuse, it's a fact. Last I checked (8.1 release) there was no mention of the Attic in either the Handbook or the Porter's Handbook. Do I hear a volunteer to add a section describing the Attic and how to retrieve things from it? (I am not qualified to write such a section -- I'm not that familiar with CVS.) We need to make the best decisions we can to provide the best support possible for the largest percentage of our users. But how do we know what the best support possible consists of? I somehow doubt that anyone has polled even a modest percentage of our users -- to find out what they would consider the best support possible -- since AFAIK we have no way of even _identifying_ more than a tiny fraction of the user base. My *guess* is that the largest percentage of our users are what Julian calls release users -- those who install a release and corresponding ports, and don't touch it subsequently until they become aware of a problem. They _may_ follow the security branch for their base release, but that won't make them aware of issues that have turned up in ports. Instead, they will be unpleasantly surprised that a port they use has disappeared sometime after they installed it and before they have occasion to (attempt an) upgrade. ___ 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
AFAIK there are maybe half a dozen or so developers who have recently put themselves on record as supporting the current, agressive deprecation campaign. The number who have posted in opposition may well be smaller, so you are probably right if the community is defined as consisting only of those two groups :) I'm probably counted as one of the half-dozen developers here. However... 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 ... If this will help a number of people this sounds like an excellent suggestion! I somehow doubt that anyone has polled even a modest percentage of our users -- to find out what they would consider the best support possible -- since AFAIK we have no way of even _identifying_ more than a tiny fraction of the user base. A) We need better statistics for ports in general B) We need better ways of communicating with our users to find out how people actually use the ports tree. -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysutils/cfs
On 09/05/2011 22:48, per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: On 09/05/2011 02:33, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. We understand that this is your perspective, however the community in general has a different idea. I suppose it may depend on how one defines the community. AFAIK there are maybe half a dozen or so developers who have recently put themselves on record as supporting the current, agressive deprecation campaign. The number who have posted in opposition may well be smaller, so you are probably right if the community is defined as consisting only of those two groups :) I don't. There have indeed been a few highly vocal individuals who have opposed the idea of deprecating/removing anything. In contrast you have a larger number of committers who are actively involved in attempting to improve the situation, and a larger number who are silently supporting the program. In addition you have a much larger number of people who actively discuss the topic in #bsdports. Currently there are 135 people in there, the majority of whom are active ports maintainers. So I'm defining the community as the vast majority of people who are actively working on supporting FreeBSD ports. 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. I was trying to be polite. My *guess* is that the largest percentage of our users are what Julian calls release users -- those who install a release and corresponding ports, and don't touch it subsequently until they become aware of a problem. They _may_ follow the security branch for their base release, but that won't make them aware of issues that have turned up in ports. For security issues we have portaudit to handle this. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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
Re: sysutils/cfs
Hi, On 9/6/11 4:02 AM, Kostik Belousov wrote: On Mon, Sep 05, 2011 at 06:32:00PM +0100, Chris Rees wrote: On 5 Sep 2011 18:15, Mikhail T.mi+t...@aldan.algebra.com wrote: On -10.01.-28163 14:59, Chris Rees wrote: I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. Is this the only vulnerability you are talking about? http://www.debian.org/security/2006/dsa-1138 Does not seem hard to fix at all... Listing all of the fatal problems would be helpful... -mi If it's not that hard to fix then do it. If you're not going to fix it, why are you even commenting? More noise. Stop whining and do something about it. No, it is not a noise. First, note that an issue in the local deamon can be only utilized by local users. As a consequence, there is a huge set of machines for which the cited issue is simply irrelevant. For the analogous issues that are irrelevant for 90% of the port users, look at the vulnerabilities listed for the quake ports. By the way, the Debian folks invested certain effort in keeping cfs up to date. Their git repo is still available at http://smarden.org/git/cfs.git/ . In particular, the DoS fix can be easily obtained from the repo and placed under files/ in the port. Second, I personally consider the crusade to remove old but compiling and working (*) ports as a damage both to the project functionality and to the project reputation. * Working exactly because users report bugs in the software, otherwise they would not be able to describe corner cases that break. This is true: cfs is still in use out there. E.g., I know a company still relying on cfs. They don't seem to care about ports/137378. I'd be glad to suggest they move on to something newer and better supported but I'm aware of no other open-source file encryption framework that is a) transparent at filesystem level and at the same time b) can support multiple security domains without requiring as many mount points. As soon as there is an alternative available, the cfs port can be safely retired, but trashing it prematurely would be unwise. Cheers, Yar ___ 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
sysutils/cfs
Guys, I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Please would someone consider stepping up to fix and maintain it? It has two months to live. Thanks! Chris [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137378 -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ 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 4 September 2011 17:56, Chris Rees utis...@gmail.com wrote: Guys, I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. Please would someone consider stepping up to fix and maintain it? It has two months to live. Thanks! Chris [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137378 Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. By the way, Debian has dropped this as well, and upstream says it was due a rewrite in 2002. With the vulnerability in mind, whoever volunteers to maintain this port should probably look at becoming the upstream too. Chris -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ 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: Sun, 4 Sep 2011 20:21:10 +0100 Message-id: CADLo83_A+Oh+i4ZFQ=KnZyvBk0h2pf+bJnjhYHm=5uyacje...@mail.gmail.com Chris Rees wrote: On 4 September 2011 17:56, Chris Rees utis...@gmail.com wrote: Guys, I've had to deprecate sysutils/cfs -- there's a confirmed issue with failing locks [1] which has been open for two years with no fix. No reason to suddenly panic then. Please would someone consider stepping up to fix and maintain it? It has two months to live. Thanks! Chris [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/137378 Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. 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 (or if a firm using releases, perhaps time to allocate a staff member if a port is important to them). 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: sysutils/cfs
On 4 September 2011 21:32, Julian H. Stacey j...@berklix.com wrote: Whoops, also missed a CVE -- buffer overflows can cause a DoS. Expiration date altered to 1 month accordingly. It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. 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 (or if a firm using releases, perhaps time to allocate a staff member if a port is important to them). Yeah... perhaps if there isn't a vulnerability. At the moment it's marked FORBIDDEN, so it's useless -- anyone who is serious about fixing it at whatever time is welcome to check it out of the Attic -- a slight inconvenience for which we apologise. In the mean time, record class=brokenthe ports tree is not a museum for ancient insecure bug-ridden software/record. Chris -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ 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 Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote: It is not responsible to threaten to remove ports without warning between releases for non urgent reasons. portmgr has no such policy. Ports get deleted all the time due to various issues. I prefer to see a 1- or 2-month warning via EXPIRATION_DATE, but that's my personal preference, not a written policy. mcl ___ 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
Chris Rees utis...@gmail.com wrote: I've had to deprecate sysutils/cfs ... s/sysutils/security (at least in my instance of the ports tree). Whoops, also missed a CVE -- buffer overflows can cause a DoS. Er, am I the only one who does not recognize what CVE stands for? BTW thanks for the heads-up, which has enabled me to grab the distfile before the port goes away :) While I have no great interest in the specific service that this port provides, some of its mechanism may be pertinent to a related interest. ___ 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
