Re: The cost of a source based package system
On Thu, Sep 08, 2011 at 04:45:30PM -0700, Xin LI wrote: Both portmaster and portupgrade have 'package' mode, which uses packages when available. If one can live with default optimization (which is usually good anyways) and if most times the default options would satisfy his/her need, or if the port doesn't provide any options, binary packages would save a lot of time. The real problem for FreeBSD's packaging system is, in my opinion, we do not maintain branches and ports tree is a fast moving target, making it impractical to build packages and push to mirrors. Absolotely right. There is also so ongoing work to move away from the current model. We already are using a consistent model for from which src branch we build packages on. Previously, this was RELENG_X on a given day, where that day was defined by whenever the portmgr running that architecture has time to do so. This is now oldest supported minor release within each major branch. More on: http://www.freebsd.org/portmgr/policies_eol.html We also need to do this for the ports tree. The best way to do so is to provide consistent package sets which are not overwritten on the mirrors when a new package set becomes available, but let the user move between sets manually. This requires some large changes, both to the code and infrastructure which we are working on. The code needs to be able to identify which package set is installed and an ability to move to a new set. The PKGNG project will provide us that. Also, the current mirror infrastructure cannot support the extra amount of data needed. Currently, a full set of packages for one architecture is about 30G. Just supporting the Tier-1 architectures on 2-3 live branches add up, especially if we also need to keep multipe full sets around. There's a short presentation from BSDCan with some bullet points: http://people.freebsd.org/~erwin/presentations/20110512-BSDCan-packages-summary.pdf This is also a topic we'll talk more about at EuroBSDCon next month. My $0.02: It might be worthy to experiment a branched development model and only pull up changes at a much lower pace to branch (e.g. create a branch near a release and drop the branch after a few weeks once a new one is created, and only pullup changes when there is need, like because security vulnerability or serious reliability/performance issue), it would be easier to produce binary package and sync them across mirrors. I don't think brances is the right solution here. Talking to the pkgsrc people, they use quite a lot of time on pullups and we have almost 3 times as many packages. This would not scale to ports. Unfortunately, as I do like the model in principle. I think we can come near though wil clearly defined EOL/EOS lifetimes for the package sets (see slides). Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: The cost of a source based package system
- no 'make clean' and reusing the object files of the current version for building the new, updated, version. That should save significant compilation time. Does that work as of today? I doubt that that will work in that form. In fact, I quite like that 'make clean' in ports throws away the whole directory so that you are definitely in a well-defined state afterwards. (That's not true for all upstream 'clean' targets.) But what does work in avoiding (at least some) unnecessary recompilation, even today, is installing and using devel/ccache. 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: 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
[RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Freebsd-ports. I notice, that many software projects are hosted on social DVCS hostings nowadays. Other common feature among them is absence of official tarballs for versions. I don't say, that ALL projects whith primary hosting on these DVCS sites don't publish official tarballs. But many of them don't. On other hand, all these DVCS sites provide way to download auto-generated tarballs for any tag or branch or revision. Maybe, we need support for this model to ports system directly? Like we support SourceForge and other code hosting sites. -- // 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
What is difference between ${MASTER_SITE_GNU}/${MASTER_SITE_SUNSITE} and SF/CPAN in MASTER_SITES?
Hello, Freebsd-ports. Why some groups of sites in ports system are make variables and some -- special strings? -- // 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
deprecated because: Development has ceased??? Maybe development is *complete*
On Wed, 7 Sep 2011 08:33:08 +0200 (CEST) lini...@freebsd.org wrote: portname: german/ksteak description:KDE frontend for steak, an english - german dictionary maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=ksteak portname: german/steak description:An english - german dictionary under the GPL maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=steak Pardon my objection (I know you guys are getting slammed with a lot of complaints lately), but... Development has ceased: Is that really the only reason for removing these two ports? There's really nothing wrong with either of them, to the best of my knowledge, and both are very useful to me in my correspondence with native German speakers. Development has ceased just seems to be insufficient as an *automatic* cause (excuse?) for removing a port, IMHO. Are we saying that once a program has reached a finished, final, stable working state, the developer(s) should be required to continue coming up with ways of modifying it for no good reason other than to avoid being dropped from our ports collection? Viewed from this perspective, doesn't that seem just a tad unreasonable? I mean, it's more like: deprecated because: development is *complete* and needs no further refinement (which is, of course, patently absurd) This really does lead one to wonder just what exactly is motivating the individuals leading the charge in this latest rash of ports removals. I realize many of the people involved in handling the ports collection are seasoned, experienced FreeBSD veterans, but this almost feels as if some new, overly eager intern has just recently been turned loose on the ports collection and, drunk on their newly acquired power, is just madly and capriciously slashing-and-burning with wild abandon. If having a maintainer for these two ports might spare them from the executioner's ax, I'll be happy to add them to my existing list of responsibilities. Thank you. -- 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 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
Standalone mksh
Hi all, I wanted to propose the addition of a standalone mksh in shells/, which , of course, is compiled with -static and installs to /bin . Attached is the modified Makefile. Thanks, -- Rares Aioanei Makefile Description: Binary data ___ 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
net-snmp-5.7_3 issue with tcpCurrEstab
Hi, Since upgrading to version 5.7, the Gauge32 of .1.3.6.1.2.1.6.9.0 (TCP-MIB::tcpCurrEstab.0) only returns zero. Tested on 8.2-RELEASE-p2 with 5.7_3 today. -- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:u...@twe.net http://blog.andersen.nu/ ___ 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 02:30:52PM +0400, Lev Serebryakov wrote: Hello, Freebsd-ports. I notice, that many software projects are hosted on social DVCS hostings nowadays. Other common feature among them is absence of official tarballs for versions. I don't say, that ALL projects whith primary hosting on these DVCS sites don't publish official tarballs. But many of them don't. On other hand, all these DVCS sites provide way to download auto-generated tarballs for any tag or branch or revision. Maybe, we need support for this model to ports system directly? Like we support SourceForge and other code hosting sites. 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. regards, Bapt pgpmHhPdusTdh.pgp Description: PGP signature
Re: What is difference between ${MASTER_SITE_GNU}/${MASTER_SITE_SUNSITE} and SF/CPAN in MASTER_SITES?
Lev Serebryakov wrote on 09.09.2011 14:35:
Hello, Freebsd-ports.
Why some groups of sites in ports system are make variables and some --
special
strings?
They are not. You can use both ${MASTER_SITE_GNU} and just GNU (it will
expanded automatically to corresponding make variable). Just checked
with archivers/gzip.
--
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
net/clamz should have pkg-message on how to set cookie to download amz-files
When reinstalling net/clamz I noticed that it is necessary to have a cookie from the local amazon site (amazon.com, amazon.de) confirming that the amazon downloader is installed when in fact it is not and you are using clamz. That information will only be accessible from the project website, http://code.google.com/p/clamz/, where users can also get a link to set the aformentioned cookie. It might be an idea to include a pkg-message in the port net/claz, for instance * For convenience, users may want to set a cookie using the link on http://code.google.com/p/clamz/. It is feasible to substitute the top level domain with the applicable amazon-TLD. Not having the cookie set, users will fail to download Amazon .amz files to download albums. * I do not want to be rude by making a PR without consulting you as maintainer and ports@ beforehand. Thank you for your consideration, cheers, -- Christopher J. Ruwe TZ GMT + 2 pkg-message Description: Binary data pgpoSPGmSX9dp.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
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.25100% 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 ___ 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, Baptiste. You wrote 9 сентября 2011 г., 17:04:58: 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. I've thought about checksums, but my simple experiment shows, that tag-related (not tip-related, of course) archives give same chsum after re-downloading in short time. But I don't check it for long-term stability. Ok, other idea: check-out sources (require hg/git as BUILD dependency, but anyway user will need them to build software by hands) and check strong checksum of checked out revision (as both DVCS uses strong checksums as IDs internally). It is more complex feature, than adding additional MASTER_SITES, 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
I've thought about checksums, but my simple experiment shows, that tag-related (not tip-related, of course) archives give same chsum after re-downloading in short time. But I don't check it for long-term stability. Well, let's do at least one check with a one and a half year old tar ball. [root@kta1c10 /tmp]# fetch https://github.com/Dieterbe/uzbl/tarball/2010.01.05 2010.01.05100% of 130 kB 320 kBps [root@kta1c10 /tmp]# sha256 2010.01.05 SHA256 (2010.01.05) = 0aae5c9994d968b4f4ec7f8f2ce935c25e25d19cabbce27e3ded0672756132c8 [root@kta1c10 /tmp]# cd /usr/ports/www/uzbl/ [root@kta1c10 /usr/ports/www/uzbl]# cvs diff -r1.1 distinfo Index: distinfo === RCS file: /usr/ctm/cvs-cur/ports/www/uzbl/distinfo,v retrieving revision 1.1 retrieving revision 1.11 diff -r1.1 -r1.11 1,3c1,2 MD5 (uzbl-0.0.0.2010.01.05.tar.gz) = 2574fc68a7a7693297d371ca58a4edb4 SHA256 (uzbl-0.0.0.2010.01.05.tar.gz) = 0aae5c9994d968b4f4ec7f8f2ce935c25e25d19cabbce27e3ded0672756132c8 SIZE (uzbl-0.0.0.2010.01.05.tar.gz) = 133875 --- SHA256 (uzbl-0.0.0.2011.07.25.tar.gz) = 2e61fa6c62e48d3f13e95a4ea7e7aead65345f6c88a688844ef921685dffe565 SIZE (uzbl-0.0.0.2011.07.25.tar.gz) = 146851 [root@kta1c10 /usr/ports/www/uzbl]# There it works as well... 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
Hello, Klaus.
You wrote 9 сентября 2011 г., 17:24:37:
* due to autogeneration, you're quite likely to get a http-redirect,
Does fetch support redirects?
* filenames like 2011.07.25 are not too suitable for a distfile.
DIST_SUBIDR=${PORTNAME} is solution for this.
--
// Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru
___
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.
* due to autogeneration, you're quite likely to get a http-redirect,
Does fetch support redirects?
Yes. But for good reasons, Mk/bsd.ports.mk contains the line
FETCH_ARGS?=-AFpr
Note the -A. Of course, it's no problem to make an exception for github, but
at least, one should be aware of this.
* filenames like 2011.07.25 are not too suitable for a distfile.
DIST_SUBIDR=${PORTNAME} is solution for this.
yes. And a github framework probably should set this by default...
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: Same concerns about our postgresql and plpython ports
Thu, Sep 08, 2011 at 02:17:09PM +0400, Ruslan Mahmatkhanov wrote: Hi, for me it's too many time has passed for maintainer timeout. Please commit this anybody, until this port wasn't removed because it doesn't builds with some NOTEXISTENT PostgreSQL version. Ruslan Mahmatkhanov wrote on 31.08.2011 11:11: [...] http://www.freebsd.org/cgi/query-pr.cgi?pr=159842 2. postgresql-plpython unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159843 3. postgresql9x-client unbreak: http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 Taking those three. Will test them on the coming Monday and will commit afterwards. -- Eygene Ryabinkin,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] pgpip4MYn3Pad.pgp Description: PGP signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
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.25100% 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 regards, Bapt pgpzmDDTJ4Neb.pgp Description: PGP signature
Re: Same concerns about our postgresql and plpython ports
Fri, Sep 09, 2011 at 06:26:13PM +0400, Eygene Ryabinkin wrote: 3. postgresql9x-client unbreak: Taking those three. Will test them on the coming Monday and will commit afterwards. Hmm, actually only http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 the others are already committed. Sorry, should have been checked them before writing the mail. -- rea ___ 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
subversion 1.7.0-rc2 port - second revision
Hello, FreeBSD.
New revision of this vital port.
Changes:
(1) No external FreeBSD hack patch anymore -- ${PATCH_DIR} located
extra-patches instead.
(2) FreeBSD hacks splitted into three:
(a) Perforce-style conflict markers
(b) Enhanced keywords
(c) FreeBSD-specific commit template
(3) Some cleanups in port docs
(4) Master site subdir fixed
(5) Makefile general cleanups
(6) Patch names cleanup.
Thanks David O'Brien for (1) and (2)
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
port-subversion-1.7.0-rc2_1.tar.bz2
Description: Binary data
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Same concerns about our postgresql and plpython ports
Eygene Ryabinkin wrote on 09.09.2011 18:38: Fri, Sep 09, 2011 at 06:26:13PM +0400, Eygene Ryabinkin wrote: 3. postgresql9x-client unbreak: Taking those three. Will test them on the coming Monday and will commit afterwards. Hmm, actually only http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 the others are already committed. Sorry, should have been checked them before writing the mail. One of them is committed (python plist fix). This one taken by sunpoet@ yesterday: http://www.freebsd.org/cgi/query-pr.cgi?pr=159843 and this one is maintainer timeout: http://www.freebsd.org/cgi/query-pr.cgi?pr=159844 So i think that the last one may be taken :) -- 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
mod_gnutls
Good day, I'm the current maintainer (as of July 2011) of mod_gnutls. I have noticed that you are responsible the FreeBSD port, and have include the current version (0.5.10). I greatly appreciate your help. The latest tarball can be downloaded from mod_gnutls' official page at: http://modgnutls.sourceforge.net/ Thank you in advance for all your help. I look forward to working with you. Sincerely, -- Dash Shendy Coder/Pentester/Security-Analyst http://dash.za.net/?smtpsig gtalk: dash.za@gmail.com skype: dashula2006 mopho: (+27) 72 23 75 199 signature.asc Description: OpenPGP digital signature
Re: [RFC] New ports idea: github / gitorious / bitbucket direct support.
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. 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: [RFC] New ports idea: github / gitorious / bitbucket direct support.
On Fri, Sep 09, 2011 at 03:05:42PM +0100, Klaus T. Aehlig wrote: * due to autogeneration, you're quite likely to get a http-redirect, Does fetch support redirects? Yes. But for good reasons, Mk/bsd.ports.mk contains the line FETCH_ARGS?=-AFpr Note the -A. Of course, it's no problem to make an exception for github, but at least, one should be aware of this. The redirect is often avoidable if you can determine the final URL of the distfile. Github only uses a single hostname for tarball downloads, so there is no issue with maintaining a list of mirrors. Until recently, github required two requests to get a tarball: one to initiate the tarball creation, the other to download it. I was able to work around this in one of my ports, but the hack is no longer needed. -- Shaun Amott // PGP: 0x6B387A9A A foolish consistency is the hobgoblin of little minds. - Ralph Waldo Emerson pgpRTUDcBWUnD.pgp Description: PGP signature
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: deprecated because: Development has ceased??? Maybe development is *complete*
Am 09.09.2011 13:15, schrieb Conrad J. Sabatier: On Wed, 7 Sep 2011 08:33:08 +0200 (CEST) lini...@freebsd.org wrote: portname: german/ksteak description:KDE frontend for steak, an english - german dictionary maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=ksteak portname: german/steak description:An english - german dictionary under the GPL maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=steak Pardon my objection (I know you guys are getting slammed with a lot of complaints lately), but... Development has ceased: Is that really the only reason for removing these two ports? There's really nothing wrong with either of them, to the best of my knowledge, and both are very useful to me in my correspondence with native German speakers. Are you willing to fill in as a spare for the original author if users have problem with the port or with the software? Are you willing to keep the software going as the FreeBSD environment, ports libraries, and everything changes? If so, welcome Conrad Sabatier the new maintainer for steak and ksteak. If you're not willing or uncapable of doing that work, then you can complain all you want but won't be heard. Development has ceased just seems to be insufficient as an *automatic* cause (excuse?) for removing a port, IMHO. Are we saying that once a program has reached a finished, final, stable working state, the developer(s) should be required to continue coming up with ways of modifying it for no good reason other than to avoid being dropped from our ports collection? Viewed from this perspective, doesn't that seem just a tad unreasonable? Software maintenance doesn't mean that the software has to change if there's nothing that needs to change. Leafnode-1 (news/leafnode) barely changes at all these last years, just an occasional fix. However, it's still maintained and if you report a serious bug I - as the upstream author - will fix it. If the author of another package stated that maintenance ceased, that is no longer the case. Any why let port users fall into this pit? They are still able to install from source, but we're no longer offering assistance. This really does lead one to wonder just what exactly is motivating the individuals leading the charge in this latest rash of ports removals. I no capacity to support, as was restated more than once. If having a maintainer for these two ports might spare them from the executioner's ax, I'll be happy to add them to my existing list of responsibilities. I take it that sooner or later it will be unworkable. steak is no longer available, and ksteak hasn't been ported to KDE4/Qt4. I suppose that Qt3's days are counted, and once that's removed, so will ksteak be even if you can find and hosting the steak sources and possibly fix bugs. It might prolong the port's life a bit, but I think the overall prospect for this port is bleak unless someone assumes the upstream maintainer job. I think the time would be better spent on finding and/or recommending a replacement for KDE 4 so that we can point users in the right direction when they look for a translator. I would not believe that there's no alternative, but I'm not about to research 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: OpenCASCADE port outdated
Le mar 6 sep 11 à 17:10:01 +0200, Andrea Venturoli m...@netfence.it écrivait : Hello. Hello, Port is at 6.3, but 6.5.1 is out. Is upgrading under way or planned? Yes, I know, but unfortunately I have been too busy. Hope to work on it RSN. Anyway, patches are welcome! Regards, -- Th. Thomas. ___ 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
git distfiles on the local mirror
Could someone please place the latest devel/git distfiles on the local mirrors, so that they are available while kernel.org is recovering from being hacked? The github mirror only has gzipped development tarballs, that don't work with the current ports Makefile. b. ___ 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: git distfiles on the local mirror
On Fri, Sep 09, 2011 at 09:37:08PM +, b. f. wrote: Could someone please place the latest devel/git distfiles on the local mirrors, so that they are available while kernel.org is recovering from being hacked? The github mirror only has gzipped development tarballs, that don't work with the current ports Makefile. b. ___ 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 Hi b.f. Before wxs@ updates MASTER_SITES, you can manually download git/git-manpages tarballs from http://people.freebsd.org/~sunpoet/distfiles/ Regards, -- Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org 4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B http://people.FreeBSD.org/~sunpoet/pgpkeys.txt ___ 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: Standalone mksh
On 9/9/2011 7:35 AM, Aioanei Rares wrote: Hi all, I wanted to propose the addition of a standalone mksh in shells/, which , of course, is compiled with -static and installs to /bin . Attached is the modified Makefile. Thanks, Aioanei, No attachment, I think it got filtered out by the list. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) signature.asc Description: OpenPGP digital signature
Re: git distfiles on the local mirror
On Fri, Sep 09, 2011 at 09:37:08PM +, b. f. wrote: Could someone please place the latest devel/git distfiles on the local mirrors, so that they are available while kernel.org is recovering from being hacked? The github mirror only has gzipped development tarballs, that don't work with the current ports Makefile. I was hoping that kernel.org would get their act together before I had a chance to fix this tonight. I will be updating the port to point to a couple of new locations now. -- WXS ___ 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: Standalone mksh
On 9/9/11 9:48 PM, Chris Brennan wrote: On 9/9/2011 7:35 AM, Aioanei Rares wrote: Attached is the modified Makefile. Thanks, Aioanei, No attachment, I think it got filtered out by the list. I received the Makefile. -- 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
Why was rdiff.1 removed from net/librsync?
Hallo,
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?
Best regards,
Klaus
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=55469
[2]
http://www.linta.de/~aehlig/download/uucp/tinderboxlogs/20110910-librsync-0.9.7_2.log
diff -ruN librsync.orig/Makefile librsync/Makefile
--- librsync.orig/Makefile 2011-09-10 04:05:00.0 +0100
+++ librsync/Makefile 2011-09-10 04:05:23.0 +0100
@@ -26,9 +26,7 @@
CONFIGURE_ARGS= --enable-shared --disable-trace
USE_LDCONFIG= yes
+MAN1= rdiff.1
MAN3= librsync.3
-post-patch:
- @${REINPLACE_CMD} -e 's|= rdiff.1|=|g' ${WRKSRC}/doc/Makefile.in
-
.include bsd.port.mk
___
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: Standalone mksh
I wanted to propose the addition of a standalone mksh in shells/, which , of course, is compiled with -static and installs to /bin . Attached is the modified Makefile. 1) Please submit unified diffs, not entire files. It makes it easier to see what changed and it makes it easier to actually use when testing 2) We assume that LOCALBASE is read only (except for some very specific hacks like perl's symlink) so such a port will not be committed 3) Don't change PREFIX in the port's Makefile. This is a user specific option which should not be overwritten 4) If anything, the -static should be an OPTION. 5) Your change would require approval by the maintainer (m...@freebsd.org). I would hope he does not approve it based on points 2-4 above. Thanks for your contribution. Please don't take my criticism of this specific patch as reason not to try again! -- 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: deprecated because: Development has ceased??? Maybe development is *complete*
On Fri, 09 Sep 2011 19:29:15 +0200 Matthias Andree matthias.and...@gmx.de wrote: Am 09.09.2011 13:15, schrieb Conrad J. Sabatier: On Wed, 7 Sep 2011 08:33:08 +0200 (CEST) lini...@freebsd.org wrote: portname: german/ksteak description:KDE frontend for steak, an english - german dictionary maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=ksteak portname: german/steak description:An english - german dictionary under the GPL maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2011-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=germanportname=steak Pardon my objection (I know you guys are getting slammed with a lot of complaints lately), but... Development has ceased: Is that really the only reason for removing these two ports? There's really nothing wrong with either of them, to the best of my knowledge, and both are very useful to me in my correspondence with native German speakers. Are you willing to fill in as a spare for the original author if users have problem with the port or with the software? Are you willing to keep the software going as the FreeBSD environment, ports libraries, and everything changes? If so, welcome Conrad Sabatier the new maintainer for steak and ksteak. If you're not willing or uncapable of doing that work, then you can complain all you want but won't be heard. 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. :-) Development has ceased just seems to be insufficient as an *automatic* cause (excuse?) for removing a port, IMHO. Are we saying that once a program has reached a finished, final, stable working state, the developer(s) should be required to continue coming up with ways of modifying it for no good reason other than to avoid being dropped from our ports collection? Viewed from this perspective, doesn't that seem just a tad unreasonable? Software maintenance doesn't mean that the software has to change if there's nothing that needs to change. Leafnode-1 (news/leafnode) barely changes at all these last years, just an occasional fix. However, it's still maintained and if you report a serious bug I - as the upstream author - will fix it. If the author of another package stated that maintenance ceased, that is no longer the case. Any why let port users fall into this pit? They are still able to install from source, but we're no longer offering assistance. 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. This really does lead one to wonder just what exactly is motivating the individuals leading the charge in this latest rash of ports removals. I no capacity to support, as was restated more than once. That whole area still just seems rather fuzzy and grey to me. Opinions as to what constitutes support seem to vary widely. 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). 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. If having a maintainer for these two ports might spare them from the executioner's ax, I'll be happy to add them to my existing list of responsibilities. I take it that sooner or later it will be unworkable. steak is no longer available, and ksteak hasn't been ported to KDE4/Qt4. I suppose that Qt3's days are counted, and once that's removed, so will ksteak be even if you can find and hosting the steak sources and possibly fix bugs. Yes, that will no doubt eventually some to pass, but in the meantime... It might prolong the port's life a
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
