http://permalink.gmane.org/gmane.os.netbsd.devel.packages hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38958 <pre> &gt; &gt; * Droping php5(PHP 5.2.x) support. I plan it before pkgsrc-2012Q2. &gt; &gt; What's the status of compatibility between 5.3 and 5.2? &gt; &gt; Though I'm not fond of it, but people may still need to run software &gt; that may require older PHP, and this: Regardless of whether it was last year or last week, the nature of php is such that if it isn't getting security updates from upstream, it should be removed as a public menace. :-/ </pre> David Holland 2012-05-24T01:58:28 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38957 <pre> Updating pkgsrc tree: ? pkgsrc/INDEX ? pkgsrc/README-IPv6.html ? pkgsrc/README-all.html ? pkgsrc/net/wget/work P pkgsrc/archivers/sapcar/Makefile P pkgsrc/archivers/star/Makefile P pkgsrc/archivers/unalz/distinfo P pkgsrc/archivers/unalz/patches/patch-ad P pkgsrc/audio/sidplay2/distinfo U pkgsrc/audio/sidplay2/patches/patch-src_args_cpp P pkgsrc/benchmarks/hbench/distinfo P pkgsrc/benchmarks/hbench/patches/patch-aq P pkgsrc/cad/lc/Makefile P pkgsrc/cad/lc/PLIST P pkgsrc/chat/ircII/Makefile P pkgsrc/devel/g-wrap/Makefile P pkgsrc/devel/glib2/Makefile.common P pkgsrc/devel/prcs/distinfo U pkgsrc/devel/prcs/patches/patch-src_misc_cc P pkgsrc/devel/qtscriptgenerator/Makefile P pkgsrc/devel/teem/Makefile P pkgsrc/devel/xulrunner10/PLIST P pkgsrc/doc/CHANGES-2012 P pkgsrc/doc/TODO P pkgsrc/doc/pkgsrc.html P pkgsrc/doc/pkgsrc.txt P pkgsrc/doc/guide/files/fixes.xml P pkgsrc/editors/Makefile U pkgsrc/editors/edt/DESCR U pkgsrc/editors/edt/Makefile U pkgsrc/editors/edt/PLIST U pkgsrc/editors/edt/distinfo U pkgsrc/edi</pre> NetBSD source update 2012-05-24T01:05:47 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38955 <pre> I don't know about this particular case but: Every time I performed Gnome updates in the past, some component stopped working because they kept introducing more and more dependencies on Linux-only APIs. At that point during the upgrade, the trade-off was either leaving the component at an older version and updating the rest of Gnome to the latest release, or not being able to do either. My guess is that, at this point, updating Gnome to any newer release is pretty much impossible due to their dependencies on Linux -- or maybe it's possible but too many things would stop working. It'd also be that nobody has had the energy to update the packages. But that, I don't know. </pre> Julio Merino 2012-05-23T23:23:22 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38954 <pre> I object to introduction of more mess in pkgsrc-wip just because of purist attitude to pkgsrc. We have many packages that do have distfile but don't build on some platforms. This problem is definitly more important than having few packages of software not as freely available to everyone as software from GNU project. </pre> Aleksej Saushev 2012-05-23T22:35:49 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38953 <pre> Hello, Takahiro Kambe &lt;taca&lt; at &gt;back-street.net&gt; writes: What's the status of compatibility between 5.3 and 5.2? Though I'm not fond of it, but people may still need to run software that may require older PHP, and this: OA&gt; PHP 5.2 series is NOT supported anymore with PHP-5.3.6 release on 17-Mar-2011: means that it has been only a year. It may be too little time to have most software converted (besides very actively developed projects). </pre> Aleksej Saushev 2012-05-23T21:50:08 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38952 <pre>I tried to use pkgin to install gtk2. This was pkgin and pkg_summary fetched during the sysinst install step (but I also did an pkgin update again). It is using http://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/6.0_BETA/All Should we have a key list of important packages and a cron job that periodically checks and alerts us? I know this is just 6.0_BETA but that is not my point. How do we know if the repo is not useful (common packages)? I also looked at 6.0 and the pkg_summary is identical. (BUILD_DATE and SIZE_PKG are identical so assume this is the exact same collection.) It would also be nice to have a pointer to the build reports if available or at least a note saying that it is not available. I sent an email recently about wanting to identify who built and where the packages came from. The pkg_summary does not tell me. I propose we extend the pkg_summary to include a meta section about this or add the details for every single package (by adding the info to every single package). It</pre> Jeremy C. Reed 2012-05-23T15:11:06 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38951 <pre>I am replying to two emails below: On Tue, 15 May 2012, Joerg Sonnenberger wrote: (Or in pkg_summary) I'd like to extend this idea to also include the username, hostname, contact details of builder. This could be overridden. So maybe a pointer to a webpage for build reports for example. I don't want to download a binary package and analyze it to know what branch was used. On Wed, 16 May 2012, Alistair Crooks wrote: I understand about a local install. (I have a mix of packages from different places going back for several years installed on single system.) BUILD_HOST is useful. The pkgsrc/mk and pkg_create tools may be different between different quarterly releases. So a package with identical version may be very different (for example PLIST metadata changes or improved install scripts). Yes, I'd like to know what version of the infrastructure it was built with. I'd like to know before I install a package if it was built using current pkgsrc or on some quarterly branch. I'd like to kn</pre> Jeremy C. Reed 2012-05-23T15:04:35 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38950 <pre> Typo, I meant at version 2.26. John </pre> John Marino 2012-05-23T08:46:03 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38949 <pre>sysutils/gnome-power-manager doesn't build due to recent glib2 update. However, looking more closely, it's still (intentionally) on version 2.24 while the rest of gnome is on 2.26. The gnome metapkg also has 2.26 commented out without documenting why. So first, does anybody know why? Secondly - Should glib2 be getting constantly bumped to the next version (currently at 2.32) while gnome wallows at 2.26? That's the primary cause of the package failure, glib2 mismatch. Shouldn't these be upgraded together? Or to ask a related question: Is there a technical reason gnome is still at 2.24? Is there a strategy for glib2 version updates - or is it just enthusiasm? The last bump to 2.32 was pretty painful, how necessary was that? I felt bad for dholland. John </pre> John Marino 2012-05-23T08:43:53 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38948 <pre> Updating pkgsrc tree: ? pkgsrc/INDEX ? pkgsrc/README-IPv6.html ? pkgsrc/README-all.html ? pkgsrc/net/wget/work P pkgsrc/devel/glib2/Makefile P pkgsrc/devel/glib2/distinfo P pkgsrc/devel/glib2/options.mk P pkgsrc/devel/glib2/patches/patch-as P pkgsrc/devel/glib2/patches/patch-cl U pkgsrc/devel/glib2/patches/patch-co P pkgsrc/doc/CHANGES-2012 P pkgsrc/doc/TODO P pkgsrc/editors/nvi/distinfo U pkgsrc/editors/nvi/patches/patch-.._dist_Makefile.am P pkgsrc/inputmethod/scim-ccinput/distinfo P pkgsrc/inputmethod/scim-ccinput/patches/patch-ac P pkgsrc/lang/openjdk7/Makefile P pkgsrc/lang/openjdk7/distinfo P pkgsrc/lang/openjdk7/patches/patch-ab P pkgsrc/lang/openjdk7/patches/patch-ak P pkgsrc/lang/py-cxfreeze/Makefile P pkgsrc/lang/py-cxfreeze/PLIST U pkgsrc/lang/py-cxfreeze/distinfo P pkgsrc/lang/py-cxfreeze/patches/patch-aa P pkgsrc/misc/heirloom-time/Makefile P pkgsrc/mk/check/check-files.mk P pkgsrc/multimedia/gpac/Makefile P pkgsrc/multimedia/gpac/distinfo U pkgsrc/multimedia/gpac/patches/patch-modules_oss__aud</pre> NetBSD source update 2012-05-23T01:04:44 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38947 <pre>OK, that explains why the /etc/mtab link created by the SuSE packages: $ ls -l /emul/linux32/etc/mtab lrwxr-xr-x 1 root wheel 33 May 22 13:57 /emul/linux32/etc/mtab -&gt; /usr/pkg/emul/linux32/proc/mounts doesn't work. Obviously, the target should then be either /proc/mounts or ../mounts. </pre> Edgar Fuß 2012-05-22T16:28:14 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38945 <pre> That would be great :) We've just recently started to investigate seriously what needs to be done to add KMS support in our kernel and make the changes necessary. A former GSOC student, David Shao, has been working on it since 2010 but he's really uncommunicative and what he's doing has been mostly overlooked until now. Some pointers: David Shao's git tree: https://github.com/davshao/dflygsocdrm/commits/gsocdrm_github A small report on what needs to be done: https://github.com/davshao/dflygsocdrm/issues/1 Adding clflush support: http://bugs.dragonflybsd.org/issues/2363 </pre> Francois Tigeot 2012-05-22T08:51:52 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38944 <pre> No. NIH and pkgin are absolutely correct. They follow the documentation. Problems with provides/requires 1) Sometimes they are calculated incorrectly. See emails by Filip Hajny for example. The problem here is in pkgsrc infrustructure. 2) Some packages cannot build their REQUIRES correctly for a number of reasons. 3) Garbage in pkg_summary. In ideal world all these problems could be fixed at the same time. In practice 3) caused by 2) existed for at least half an year and I didn't see any activity in this direction. This is why I proposed a workaround. I needed openjdk7 and with my "hacks" it was installable and usable. We use *dirty hacks* from time time, for example, using curl downloading https distfiles. Not that I think it is a good, but until we have a better solution they might make sense. </pre> Aleksey Cheusov 2012-05-22T08:46:55 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38943 <pre> That's easy from my point of view. There're 2 kinds of licenses from pkgsrc perspective - default acceptable and those who not ;) Creating a license package should silently install all acceptable packages (default or overwritten by package builder) and should require either an agreement on license conditions for any other. Those agreement can be get in several ways: - interactive - pkg_add switch (needs implementer, probably Jan is a good choice) - environment variable ... Having a choice to accept/reject license is a very great feature - I'm glad if the idea finds volunteers. /Jens </pre> Jens Rehsack 2012-05-22T08:43:43 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38942 <pre>Hi, On Tue, May 22, 2012 at 10:13:36AM +0200, iMil wrote: My intent is not to upgrade the intel driver itself right now (this will probably not be possible before a few years anyway), but have all the dependencies necessary to try to run it and hack on it without needing other package changes. This is perfectly possible without breaking anything in the existing modular-xorg environment. Oh, I merely thought about moving the existing wip Mesa-7.8 packages to pkgsrc here. They work perfectly as-is :) I plan to import new Mesa-8.x packages in wip/ once the 7.8 ones have been moved to pkgsrc ;) </pre> Francois Tigeot 2012-05-22T08:41:27 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38941 <pre> KMS sounds easy to do, GEM is a bit tricky. I think noone in NetBSD-land realy knows what needs to be done. Would it make sense to join forces with DragonFly and cooperate closer on this issue? Martin </pre> Martin Husemann 2012-05-22T08:34:14 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38940 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - From what I've read and tested, the problem with the intel driver &gt; 1.6.7 is that they dropped XAA/EXA support in favor of UXA which needs GEM/KMS. As long as we (NetBSD) do not have KMS yet, that one cannot be upgraded. Well I can try, but as I said, I'm really not a Mesa/Xorg/drm expert, my approach will be very naive. I wanted to start the work and was afraid of the drawbacks regarding DragonFly, but as long as you're also involved in this, it's a lot less stressing :) Anyone more comfortable with all that graphic world wanting to take the lead ? Cheers, - ------------------------------------------- Emile "iMil" Heitor .°. &lt;imil&lt; at &gt;home.imil.net&gt; _ http://gcu-squad.org ASCII ribbon campaign ( ) - against HTML email X &amp; vCards / \ -----BEGIN PGP SIGNATURE----- Version: GnuP</pre> iMil 2012-05-22T08:13:36 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38939 <pre> &gt; On Sat, May 19, 2012 at 1:06 PM, Joerg Sonnenberger &gt; &lt;joerg&lt; at &gt;britannica.bec.de&gt; wrote: &gt; &gt; On Sat, May 19, 2012 at 09:54:49AM +0300, Aleksey Cheusov wrote: &gt; &gt;&gt; Thanks. As far as I can see this variable is widely used in packages. &gt; &gt;&gt; However there is one problem with it. It disables both PROVIDES and &gt; &gt;&gt; REQUIRES but only REQUIRES should be disabled. Disabling the former may &gt; &gt;&gt; break PROVIDES/REQUIRES consistency with other packages. &gt; &gt;&gt; &gt; &gt;&gt; The following patch solves the problem of temporary directories in &gt; &gt;&gt; REQUIRES. I raised it in November. &gt; &gt;&gt; http://mail-index.netbsd.org/tech-pkg/2011/11/19/msg008014.html &gt; &gt;&gt; &gt; &gt;&gt; Objections? &gt; &gt; &gt; &gt; Objected. &gt; &gt; Joerg: this behavior helps no-one. Please stop it. If you are going &gt; to object, provide a rationale. And while at it, one that makes sense &gt; and is understandable by non-experts. His rationale is: the problem is that the package is broken because it contains wrong rpaths. The PROVIDES/REQUIRES issue is a symptom of this. </pre> David Holland 2012-05-22T08:06:08 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38937 <pre> Well, that definitely fixed the issue, and that seems to be the proper place for it. Thanks, I'll commit the update to check-file.mk John </pre> John Marino 2012-05-22T07:35:27 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38936 <pre> Not 100% sure, but I feel it should be treated same as charset.alias, i.e. add it to CHECK_FILES_SKIP in mk/check/check-files.mk. </pre> OBATA Akio 2012-05-22T07:09:22 http://permalink.gmane.org/gmane.os.netbsd.devel.packages/38935 <pre>On Mon, May 21, 2012 at 10:29 PM, Jan Danielsson &lt;jan.m.danielsson&lt; at &gt;gmail.com&gt; wrote: How would you describe the dependency of e.g. lang/gcc to license/gpl? The normal pkgsrc behaviour would be to install dependencies automatically. This is contrary to the idea of explicitly accepting licenses. I don't know if pkgsrc currently has a mechanism to express "I depend on that package, but I won't install it for you". So you'll need some mechanism in license/gpl to block its installation until you accept it. IMHO, all in all this does not gain very much compared to the current situation. </pre> Jörn Clausen 2012-05-22T07:04:56 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.devel.packages