x11/xset needs a direct dependency on xproto
... otherwise it misses the need to upgrade xproto, thus: checking for XSET... configure: error: Package requirements (xproto = 7.0.17 xmuu) were not met: Requested 'xproto = 7.0.17' but version of Xproto is 7.0.16 Index: Makefile === RCS file: /home/pcvs/ports/x11/xset/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- Makefile7 Sep 2011 21:19:05 - 1.6 +++ Makefile10 Sep 2011 06:25:34 - @@ -13,7 +13,7 @@ COMMENT= User preference utility for X XORG_CAT= app -USE_XORG= xmuu +USE_XORG= xmuu xproto PLIST_FILES= bin/xset -- 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 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: deprecated because: Development has ceased??? Maybe development is *complete*
Conrad J. Sabatier wrote on 10.09.2011 09:35: While I haven't done an extensive search for alternative language translation software (truth is, I was in a bit of a hurry to get something useful installed as quickly as possible, and ksteak seemed the most appealing), I do think ksteak is one of the most pleasant to use, and also offers a fairly rich set of translations compared to some others that I've tried in the past. I'd really hate to see it go before it really is necessary. I think that http://translate.google.com is a best of them :) And there is firefox addons for it. But if you need local dictionary, take a look at textproc/goldendict, it able to look in both local files, and many online sources like urbandictionary. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: x11/xset needs a direct dependency on xproto
Doug Barton wrote on 10.09.2011 10:26: ... otherwise it misses the need to upgrade xproto, thus: checking for XSET... configure: error: Package requirements (xproto= 7.0.17 xmuu) were not met: Requested 'xproto= 7.0.17' but version of Xproto is 7.0.16 http://bugs.freebsd.org/160595 -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Baptiste Daroussin b...@freebsd.org wrote: The main problem with that is: we have no way to keep a valid sum of the distfiles if it is autogenerated (in particular with github) and this sum is really important. No question about the importance of the checksum, to prevent trojans and other problems if the distfile were to change silently. If I am understanding correctly, you seem to be saying that two distfiles autogenerated from the _same_ tag etc. in the _same_ repository, and actually containing exactly the same code, can nevertheless generate different checksums!? Wouldn't that be a bug in the DVCS? ___ freebsd-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: deprecated because: Development has ceased??? Maybe development is *complete*
On Sat, 10 Sep 2011 10:40:29 +0400 Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: I think that http://translate.google.com is a best of them :) And there is firefox addons for it. I had to laugh at one of the Spanish translations I got from Microsoft Translator on a site I was using (MT was one of three engines provided on this particular site). The phrase was I'll be right back. Microsoft's translation: I'll be back derecho. (I mean, how lame is *that*?) :-) But if you need local dictionary, take a look at textproc/goldendict, it able to look in both local files, and many online sources like urbandictionary. Thanks for the suggestions. I will take a look at those. -- 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: mod_gnutls
On Fri, Sep 09, 2011 at 03:15:01PM +0200, Dash Shendy wrote: I have noticed that you are responsible the FreeBSD port, and have include the current version (0.5.10). The actual maintainer of that port is fumif...@abacustech.jp . po...@freebsd.org is a place-holder maintainer to indicate no one person is maintaining this port, fwiw. 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: Removed ports - looking from the bench
The way that the FreeBSD project handles deleted ports is to leave them in the CVS repository, where they are easily available to everyone who would like to access them. However I think that your idea is interesting, and I'd love to see the people who are deeply concerned about deleted ports pursue it as an independent project. If they do, I will personally put a reference to it in the Handbook. :) Doug On 09/10/2011 01:08, Carsten Jensen wrote: I've seen many requests of late, for ports that are no longer in active development, abandoned etc but still working, but they've been removed from ports. here's an idea, I don't know if this has been discussed before. It requires work of course. But doesn't require a person to know how to develop, which is the biggest issue for people who use ports but don't know how to make a fix to keep it active. When a port is removed, it'll be compressed and put as a single download file. this way the patch information isn't lost and it'll be easier for someone to build said package. Of course there'll be complications, this is where a disclaimer comes in (no support, you are on your own). As I see it, the work required, after the initial setup, is when a port is marked for deletion is to pack it, upload it, and add a comment as last known working (FBSD) version. It sounds easier than probable will be The package could then be deleted when it survives 2 major FBSD versions. I know this will be 2 databases need maintaining, but look at the good aspects. * Ports will be cleaned of old/(almost) unused stuff * People will still have a chance to use an old application I could be wrong but I don't think that it requires a lot to maintain, just a few hours a month. Some major things to discuss about this is: Hosting: will freebsd.org / mirrors lend space/bandwidth to this ? Initial setup: package should be download-able using fetch, perhaps a nice web interface with descriptions of the package. By definition of package I mean the files in ports excluding the source code compressed, so you basically could extract said package into ports and use it as it never was removed. If there's enough backup for this project, I wouldn't mind taking on the job, but for it to get most the success it'll need help from the port committers. Cheers Carsten ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Perryh. You wrote 10 сентября 2011 г., 18:03:41: If I am understanding correctly, you seem to be saying that two distfiles autogenerated from the _same_ tag etc. in the _same_ repository, and actually containing exactly the same code, can nevertheless generate different checksums!? Wouldn't that be a bug in the DVCS? If archive contains timestamp of its creation in header, checksums of ARCHIVE will be different for sure. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removed ports - looking from the bench
On 10 September 2011 09:40, Doug Barton do...@freebsd.org wrote: The way that the FreeBSD project handles deleted ports is to leave them in the CVS repository, where they are easily available to everyone who would like to access them. However I think that your idea is interesting, and I'd love to see the people who are deeply concerned about deleted ports pursue it as an independent project. If they do, I will personally put a reference to it in the Handbook. :) Doug I also don't think this is a terrible idea, but perhaps we could just put a little section about Resurrecting dead ports with a quick cvs tutorial into the Porter's Handbook? Chris On 09/10/2011 01:08, Carsten Jensen wrote: I've seen many requests of late, for ports that are no longer in active development, abandoned etc but still working, but they've been removed from ports. here's an idea, I don't know if this has been discussed before. It requires work of course. But doesn't require a person to know how to develop, which is the biggest issue for people who use ports but don't know how to make a fix to keep it active. When a port is removed, it'll be compressed and put as a single download file. this way the patch information isn't lost and it'll be easier for someone to build said package. Of course there'll be complications, this is where a disclaimer comes in (no support, you are on your own). As I see it, the work required, after the initial setup, is when a port is marked for deletion is to pack it, upload it, and add a comment as last known working (FBSD) version. It sounds easier than probable will be The package could then be deleted when it survives 2 major FBSD versions. I know this will be 2 databases need maintaining, but look at the good aspects. * Ports will be cleaned of old/(almost) unused stuff * People will still have a chance to use an old application I could be wrong but I don't think that it requires a lot to maintain, just a few hours a month. Some major things to discuss about this is: Hosting: will freebsd.org / mirrors lend space/bandwidth to this ? Initial setup: package should be download-able using fetch, perhaps a nice web interface with descriptions of the package. By definition of package I mean the files in ports excluding the source code compressed, so you basically could extract said package into ports and use it as it never was removed. If there's enough backup for this project, I wouldn't mind taking on the job, but for it to get most the success it'll need help from the port committers. Cheers Carsten ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- 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 ___ freebsd-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: Removed ports - looking from the bench
On Saturday 10 September 2011 10:53:54 Chris Rees wrote: I also don't think this is a terrible idea, but perhaps we could just put a little section about Resurrecting dead ports with a quick cvs tutorial into the Porter's Handbook? why not writing a make target in bsd.port.mk to do it? cvs is in base, after all. something like `make resurrect the/port`... -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla Invest in physics -- own a piece of Dirac! signature.asc Description: This is a digitally signed message part.
FreeBSD Port: redmine-1.2.1_1
have tried to install the current port version on several systems now. All attempt failed. No fresh install is possible (Freebsd 8.1, 8.2, 7.1), and using portupgrade/portmaster also breaks Redmine. Ruby version is at # ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-freebsd8] all the way I get errors saying Gem::SourceIndex#add_spec called from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. and additional = Rails 2.3.11 application starting on http://0.0.0.0:3000 /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for actionmailer:String (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' (or other comparable messages if certain gems are not installed) Do you have any clue why this breaks ? (I'm not a Ruby/rails expert... but I sure do like Redmine...) tx, wim -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-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: deprecated because: Development has ceased??? Maybe development is *complete*
Am 10.09.2011 07:35, schrieb Conrad J. Sabatier: Well, I'm certainly willing to do what I can, for as long as I can. I maintain a handful of other ports, so I'm not unfamiliar with ports maintenance. As long as I'm capable of doing so, I'd be glad to. If at some point, some change in the base system or ports renders further maintenance extraordinarly difficult or impossible, well then of course, I would have to relinquish those duties and let these two ports climb the stairs to the Attic. :-) Thank you, and good speed with your new ports. :) Well, I' sure you know that installing from source by hand is often much more difficult than using ports. All sorts of odd little road bumps often crop up that have to be dealt with, and many users simply may not have the necessary skills. And if they don't have the skills to self-support such installations, they shouldn't be using dead software, because they must be able to rely on us for some support. For these users, it's better if they find themselves another ports that fits their purpose. That whole area still just seems rather fuzzy and grey to me. Opinions as to what constitutes support seem to vary widely. It's a fuzzy term indeed. The point is avoiding making promises (by packaging dead ports) that we can't live up to -- and for me, it was an implicit given all the time that we're talking about unmaintained ports. My *personal* feeling is that as long as a port continues to build and run and doesn't require any modifications to other ports in order to do so, and has no known serious vulnerabilities that would render it truly dangerous to use, then we should try to keep it around (yes, even if it means we have to host the distfiles(s) after the original site is gone, which I know many would disagree with). I think that I could live with, although I'd extend the restriction beyond just serious vulnerabilities, but those would be criteria other people would subscribe to (such as critical bugs, like corrupting data. According to Debian's definitions [1], it'd be somewhere around serious or grave bugs. [1] http://www.debian.org/Bugs/Developer#severities - note the site negotiates language with your browser, be sure to configure the latter properly. Again, just my personal feelings on the matter. Having dabbled with a number of Linux distributions, I feel very strongly that the ports collection is one of FreeBSD's strongest assets (relative to Linux), and that we should strive to keep it as complete (for lack of a better word) and rich and diverse as possible. Yes, but my personal feeling is not at all costs. If the trade-ins to be made in order to have a port in get too large, time to reconsider inclusion. Which is what has happened more extensively than in the past. When I made first contact with FreeBSD (4.X with 3.X still popular), it was just short of 6,000 ports. That has more than tripled in the years since. That is a humongous amount of software, and even if we drop 1,000 ports, that's less than 5% today. Of course someone's favourite may be one of those 5%, which hurts and gets complaints, but in perspective it doesn't look that bad. While I haven't done an extensive search for alternative language translation software (truth is, I was in a bit of a hurry to get something useful installed as quickly as possible, and ksteak seemed the most appealing), I do think ksteak is one of the most pleasant to use, and also offers a fairly rich set of translations compared to some others that I've tried in the past. I'd really hate to see it go before it really is necessary. Looks like these two guys (steak and ksteak) didn't have sufficient momentum to be ported over to Qt4. So, yes, I will officially volunteer to take over as maintainer of these ports. I'll send-pr them shortly. Thanks a bunch for helping us! ___ freebsd-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: Removed ports - looking from the bench
On 10 September 2011 10:46, Alberto Villa avi...@freebsd.org wrote: On Saturday 10 September 2011 10:53:54 Chris Rees wrote: I also don't think this is a terrible idea, but perhaps we could just put a little section about Resurrecting dead ports with a quick cvs tutorial into the Porter's Handbook? why not writing a make target in bsd.port.mk to do it? cvs is in base, after all. something like `make resurrect the/port`... Kinda needs more manual intervention-- one needs to find out from cvsweb how long ago the port was deleted, but it's pretty simple from a maintainer point of view; [crees@zeus]~/workspace/ports/pcvs% pcvs co -D last week ports/mail/libspf2-10 cvs checkout: Updating ports/mail/libspf2-10 U ports/mail/libspf2-10/Makefile U ports/mail/libspf2-10/distinfo U ports/mail/libspf2-10/pkg-descr U ports/mail/libspf2-10/pkg-plist Of course, pcvs should be replaced by whatever anoncvs command anyone would care to use, and actually readding the port involves mail/Makefile and MOVED, but the committer dealing with the PR can deal with that. 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: FreeBSD Port: redmine-1.2.1_1
On Sat, 10 Sep 2011 12:10:08 +0200, Wim De Nocker wrote: have tried to install the current port version on several systems now. All attempt failed. No fresh install is possible (Freebsd 8.1, 8.2, 7.1), and using portupgrade/portmaster also breaks Redmine. Ruby version is at # ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-freebsd8] all the way I get errors saying Gem::SourceIndex#add_spec called from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. and additional = Rails 2.3.11 application starting on http://0.0.0.0:3000 /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for actionmailer:String (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' Haven't got those messages yet but something like this: undefined method `name' for daemons:String /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:277:in `==' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `find_all' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:410:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:409:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:1200:in `gem' /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:75:in `add_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `each' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:132:in `process' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:113:in `send' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:113:in `run' /usr/local/www/redmine/config/environment.rb:20 Well obviously someone broke redmine _again_! So I've CC'd ruby@ because they should at least know when they break something though they usually don't care about it. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removed ports - looking from the bench
Am 10.09.2011 10:40, schrieb Doug Barton: The way that the FreeBSD project handles deleted ports is to leave them in the CVS repository, where they are easily available to everyone who would like to access them. However I think that your idea is interesting, and I'd love to see the people who are deeply concerned about deleted ports pursue it as an independent project. If they do, I will personally put a reference to it in the Handbook. :) I think the question that we can find an easy answer to is see to documenting and possibly providing a script that checks out ports from anoncvs's Attic for them. Along with some documentation explaining typical upgrade chores, like removing shared library versions from the _DEPENDS lines. If it then fails to build, the user knows why we killed the port -- and/or it can serve a starting point for those who try to polish it, and possibly submit. A committer could, after a PR, possibly stuff new submissions in the attic. We're out of responsibility for anything, users can still have it. Fewer questions asked, no CVS skills needed, and a lower barrier for users to get to the work we have done in the past but are no longer carrying forward. I somewhat dislike the idea of keeping a separate repository though, and I want to make installing dead ports harder for users. Collecting all places where relevant documentation is required would take some time, and could be a job up for grabs for non-developers. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: redmine-1.2.1_1
On Sat, 10 Sep 2011 15:47:48 +0200, Bernhard Froehlich wrote: On Sat, 10 Sep 2011 12:10:08 +0200, Wim De Nocker wrote: have tried to install the current port version on several systems now. All attempt failed. No fresh install is possible (Freebsd 8.1, 8.2, 7.1), and using portupgrade/portmaster also breaks Redmine. Ruby version is at # ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-freebsd8] all the way I get errors saying Gem::SourceIndex#add_spec called from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:91. NOTE: Gem::SourceIndex#add_spec is deprecated, use Specification.add_spec. It will be removed on or after 2011-11-01. and additional = Rails 2.3.11 application starting on http://0.0.0.0:3000 /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:277:in `==': undefined method `name' for actionmailer:String (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' Haven't got those messages yet but something like this: undefined method `name' for daemons:String /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:277:in `==' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `===' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:217:in `matching_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `find_all' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:410:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:409:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `find_all' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:216:in `matching_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:238:in `to_specs' /usr/local/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:256:in `to_spec' /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:1200:in `gem' /usr/local/www/redmine/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:75:in `add_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `each' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:132:in `process' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:113:in `send' /usr/local/www/redmine/config/../vendor/rails/railties/lib/initializer.rb:113:in `run' /usr/local/www/redmine/config/environment.rb:20 Well obviously someone broke redmine _again_! So I've CC'd ruby@ because they should at least know when they break something though they usually don't care about it. It turned out that this problem is a regression in RubyGems 1.8 and hasn't been fixed upstream yet. http://rubyforge.org/tracker/index.php?func=detailaid=29188group_id=126atid=575 The temporary workaround is to downgrade devel/ruby-gems to 1.7.2 so I've created an port for that out of the history: http://home.bluelife.at/patches/ruby-gems-1.7.2-port.tar.gz There is no need to reinstall any of the installed gems. I will mark the port as BROKEN for now until a fix for RubyGems 1.8.x is available or someone finds a workaround for 1.8. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 04:39:14PM +0100, Klaus T. Aehlig wrote: Until recently, github required two requests to get a tarball: one to initiate the tarball creation, the other to download it. Yes, that's what I remember. The URL you got after the first redirect was then good for a couple of days -- till eventually it wasn't used for long enough time and the initial request was necessary again to initiate tarball creation once again. When did they change that? That's definitely good news. The change occurred sometime in the last few months. This might be related: https://github.com/blog/900-nodeload2-downloads-reloaded -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson pgpt31kI015Db.pgp Description: PGP signature
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: Why was rdiff.1 removed from net/librsync?
On Sat, Sep 10, 2011 at 04:34:27AM +0100, Klaus T. Aehlig wrote: I recently had a quick look at net/librsync and was puzzled that it installs rdiff, but not the man page for rdiff. Looking at the history, this has happened with the update to 0.9.6, submitted in PR ports/55469 [1]. However, I fail to see the reason for removing the man page. Leaving it in, i.e., applying the attached patch, the port still builds and installs cleanly (see, e.g., my tinderboxlog[2]). Moreover, portsearch -f man1/rdiff.1 didn't find me any other port installing a rdiff man page. So, can someone explain me, why the port deliberatly removes the man page? I've applied your patch to re-add the man page. The PR you referenced removed the rdiff binary too, but it was restored in a later commit. Presumably the man page was forgotten. -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson pgpcMqHefHjlN.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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On 9 September 2011 15:28, Baptiste Daroussin b...@freebsd.org wrote: On Fri, Sep 09, 2011 at 02:24:37PM +0100, Klaus T. Aehlig wrote: The main problem with that is: we have no way to keep a valid sum of the distfiles if it is autogenerated (in particular with github) and this sum is really important. With github this fortunately is a non-issue. Even though they autogenerate their tar balls, they keep enough information to make them reproduciable. Just try: /tmpfetch https://github.com/Dieterbe/uzbl/tarball/2011.07.25 2011.07.25 100% of 143 kB 177 kBps /tmpsha256 2011.07.25 SHA256 (2011.07.25) = 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 /tmpcat /usr/ports/www/uzbl/distinfo SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 /tmp There still remain some minor issuses, like * due to autogeneration, you're quite likely to get a http-redirect, * filenames like 2011.07.25 are not too suitable for a distfile. But they certainly can be fixed by an appropriate framework. The nice thing is, github does the autogeneration right. Best, Klaus This is new because I already poke them about this in the past (more than a year ago and they clearly stated that they can't change that and that github people shouldn't use this for realease but should use the real download space of github) The issue opened about this seems to have disapear from github, maybe they change their mind I agree 100% with Bapt here-- I had the same problem with security/gorilla (I think it was gorilla...) -- the tarball wasn't stable over time and I had many problems with distinfo. I solved the problem, as Bapt suggested by approaching the author and politely asking if he would host the tarball on github. He agreed to do this. Most of the time developers using github simply overlook the problems of autogenerated tarballs, and just don't think to host dedicated ones -- I've never had a negative response from upstream about providing a proper stable tarball. Counterexamples welcome! 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: Removed ports - looking from the bench
On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: I want to make installing dead ports harder for users. Why? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpVidnJd8Edb.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Chris Rees wrote on 10.09.2011 21:33: Counterexamples welcome! Chris When i worked on net/erlyvideo port there on github were tarballs for some old versions of it. When i asked author to create tarballs for new versions too, he just delete all the tarballs :) So i just create and host them by myself. -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removed ports - looking from the bench
On 10 September 2011 18:15, Chad Perrin c...@apotheon.net wrote: On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: I want to make installing dead ports harder for users. Why? Someone who wants to install a port that has been deprecated and removed should really have enough skills to check a port out of the Attic at least-- it's one command line. I don't see how much simpler it could get: cvs -d __insert_anoncvs_host_here co -D day_before_port_was_deleted ports/category/dead_port 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On 10 September 2011 18:47, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: Chris Rees wrote on 10.09.2011 21:33: Counterexamples welcome! Chris When i worked on net/erlyvideo port there on github were tarballs for some old versions of it. When i asked author to create tarballs for new versions too, he just delete all the tarballs :) So i just create and host them by myself. Hm, plain spiteful. I like to think (or hope) that's not representative of most of our upstream friends ;) The main question is, is it worth us writing code to handle a small minority of projects that refuse, or is it just easier to host this same minority ourselves? I'm perfectly happy to mirror anything if needed, by the way. 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Chris Rees wrote on 10.09.2011 21:58: On 10 September 2011 18:47, Ruslan Mahmatkhanovcvs-...@yandex.ru wrote: Chris Rees wrote on 10.09.2011 21:33: Counterexamples welcome! Chris When i worked on net/erlyvideo port there on github were tarballs for some old versions of it. When i asked author to create tarballs for new versions too, he just delete all the tarballs :) So i just create and host them by myself. Hm, plain spiteful. I like to think (or hope) that's not representative of most of our upstream friends ;) Yep, for the second (and last) example - mediacore guys also ignored my request. But they use tags on github and has tarballs on main website. The main question is, is it worth us writing code to handle a small minority of projects that refuse, or is it just easier to host this same minority ourselves? Sure it worth. From my POV, maintainer should be avoided the pleasure to mess with selfhosted and selfpackaged tarballs as much as possible. Besides of inconvenience it also less reliable (both in availability and security aspects). I'm perfectly happy to mirror anything if needed, by the way. Chris -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
The change occurred sometime in the last few months. This might be related: https://github.com/blog/900-nodeload2-downloads-reloaded Ah, I see. Thanks for the link. Klaus ___ freebsd-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: Removed ports - looking from the bench
On Sat, 10 Sep 2011, Chris Rees wrote: On 10 September 2011 18:15, Chad Perrin c...@apotheon.net wrote: On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: I want to make installing dead ports harder for users. Why? Someone who wants to install a port that has been deprecated and removed should really have enough skills to check a port out of the Attic at least-- it's one command line. I don't see how much simpler it could get: cvs -d __insert_anoncvs_host_here co -D day_before_port_was_deleted ports/category/dead_port Finding the values for a (working) anoncvs_host and day_before_port_was_deleted are nontrivial. portdowngrade still has the first, but makes the second easy. I've never tried it for bringing back a removed port, though. ___ freebsd-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: Why was rdiff.1 removed from net/librsync?
The PR you referenced removed the rdiff binary too, but it was restored in a later commit. yes, you're absolutely right! I missed that point. Thanks for the explanation -- and thanks for readding the man page. Best, Klaus ___ freebsd-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: Removed ports - looking from the bench
On 10 September 2011 19:39, Warren Block wbl...@wonkity.com wrote: On Sat, 10 Sep 2011, Chris Rees wrote: On 10 September 2011 18:15, Chad Perrin c...@apotheon.net wrote: On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: I want to make installing dead ports harder for users. Why? Someone who wants to install a port that has been deprecated and removed should really have enough skills to check a port out of the Attic at least-- it's one command line. I don't see how much simpler it could get: cvs -d __insert_anoncvs_host_here co -D day_before_port_was_deleted ports/category/dead_port Finding the values for a (working) anoncvs_host and day_before_port_was_deleted are nontrivial. portdowngrade still has the first, but makes the second easy. I've never tried it for bringing back a removed port, though. Another committer has also suggested looking on cvsweb and using 'Download as tarball'. cvsweb can also be used to find the day the port was deleted. 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: Removed ports - looking from the bench
I was thinking of this problem, and i believe compressed file is not the solution, since the ports tree infrastructure changes, and that removed ports should be changed also. The second problem is where to store distfiles? Because the majority (nb: not all of them) of removed ports it's a disappeared projects with only distfile hosted on FreeBSD ftp servers. The first problem maybe solved by public github repo (ports graveyard) with liberal write access permissions (since users use it on their own risk anyway) to allow this ports be in good shape. But three problems still remains: a) how to integrate needed port from graveyard into the working tree? (suggest user to manually copy port subdirectory is ugly) b) what to do with port-management tools that know nothing about this guys (or know via MOVED that they were removed some time ago) c) where to store distfiles I treat manual copying ugly, but not impossible, since i supposed that all portname conflicts (caused by repocopies, renames etc) already will be solved in graveyard repo. Just my 0.02 kopeks. Carsten Jensen wrote on 10.09.2011 12:08: I've seen many requests of late, for ports that are no longer in active development, abandoned etc but still working, but they've been removed from ports. here's an idea, I don't know if this has been discussed before. It requires work of course. But doesn't require a person to know how to develop, which is the biggest issue for people who use ports but don't know how to make a fix to keep it active. When a port is removed, it'll be compressed and put as a single download file. this way the patch information isn't lost and it'll be easier for someone to build said package. Of course there'll be complications, this is where a disclaimer comes in (no support, you are on your own). As I see it, the work required, after the initial setup, is when a port is marked for deletion is to pack it, upload it, and add a comment as last known working (FBSD) version. It sounds easier than probable will be The package could then be deleted when it survives 2 major FBSD versions. I know this will be 2 databases need maintaining, but look at the good aspects. * Ports will be cleaned of old/(almost) unused stuff * People will still have a chance to use an old application I could be wrong but I don't think that it requires a lot to maintain, just a few hours a month. Some major things to discuss about this is: Hosting: will freebsd.org / mirrors lend space/bandwidth to this ? Initial setup: package should be download-able using fetch, perhaps a nice web interface with descriptions of the package. By definition of package I mean the files in ports excluding the source code compressed, so you basically could extract said package into ports and use it as it never was removed. If there's enough backup for this project, I wouldn't mind taking on the job, but for it to get most the success it'll need help from the port committers. Cheers Carsten -- Regards, Ruslan Tinderboxing kills... the drives. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Removed ports - looking from the bench
On Sat, Sep 10, 2011 at 06:48:30PM +0100, Chris Rees wrote: On 10 September 2011 18:15, Chad Perrin c...@apotheon.net wrote: On Sat, Sep 10, 2011 at 04:45:02PM +0200, Matthias Andree wrote: I want to make installing dead ports harder for users. Why? Someone who wants to install a port that has been deprecated and removed should really have enough skills to check a port out of the Attic at least-- it's one command line. I don't see how much simpler it could get: This does not answer my question. I find the very concept of wanting to make it harder for a user to install software bizarre. I could understand wanting to achieve some other goal, and suffering the unfortunate case of making it harder to install something, but I do not understand the simple fact of wanting to make life harder for others, unless it is a matter of pure spite. Thus my question: Why? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] pgpjC6TJTJnQb.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: x11/xset needs a direct dependency on xproto
http://bugs.freebsd.org/160595 I've sent this patch to my mentors. When they approve I'll commit. -- 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 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Matthew D. Fuller fulle...@over-yonder.net wrote: On Sat, Sep 10, 2011 at 07:03:41AM -0700 I heard the voice of per...@pluto.rain.com, and lo! it spake thus: If I am understanding correctly, you seem to be saying that two distfiles autogenerated from the _same_ tag etc. in the _same_ repository, and actually containing exactly the same code, can nevertheless generate different checksums!? Wouldn't that be a bug in the DVCS? There're all sorts of ways the same content could wind up with different checksums. The compression may happen slightly differently, higher, or lower. The files could wind up in the tarball in a different order. Timestamps could differ. etc. I can't address the non-specific etc, but I would claim that each of those 3 specific examples is a VCS bug. Creating a tarball of a particular content set _should_ be a deterministic process: * The compression method, and the ordering of the files, should be consistent. * Each file's timestamp in the tarball should be the selected version's timestamp as recorded in the repository, typically the time when the selected version of that file was committed to the VCS. Ditto for directories, provided the VCS maintains directory history. * If the VCS does _not_ maintain directory history (which is a deficiency, but not really a bug), each directory's timestamp in the tarball should match the most-recent file or subdirectory in that directory. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
