Re: stable ports?
On 29/03/2010 17:57, Ivan Voras wrote: One way to do it, my proposal, would be to maintain a stable overlay of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), containing ports deemed important for some reason. Who would be doing the additional work? I figure we'd need additional maintainers for the different branches. I don't see myself maintaining several branches of my ports, apart from ioquake3 and ioquake3-devel. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: stable ports?
On Mon, Mar 29, 2010 at 3:57 PM, eculp ec...@encontacto.net wrote: Quoting Ivan Voras ivo...@freebsd.org: Doug Hardie wrote: On 29 March 2010, at 08:57, Ivan Voras wrote: In some cases the burdens are obvious - the maintainer(s) would need to e.g. maintain three versions of the ports - a random example would be e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future (CURRENT/9.x) branch. I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. It was done (in Linux), hence it can be done. If all else fails and both the project and the maintainer cannot find suitable build and test machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole stable dance only for Tier 1 platforms (enumerated in http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to be considered separately. Virtualization (VirtualBox) may help maintainers test on the architecture they don't run natively. IIRC, pcbsd uses both ports and package system that I have assumed was similar to linux but I have never used it so I can't comment but it would seem practical to work together if there is common ground. Their site says: -- The PBI Format Part of making a Desktop Operating System that people feel immediately comfortable with is ensuring that software installation is as easy and familiar as possible. PC-BSD has taken this approach when developing the PBI (Pc-Bsd Installer or Push-Button Installer) file format. Programs under PC-BSD are completely self-contained and self-installing, in a graphical format. A PBI file also ships with all the files and libraries necessary for the installed program to function, eliminating much of the hardship of dealing with broken dependencies and system incompatibilities. PBI files also provide developers and packagers with advanced scripting and user interaction in an entirely graphical format, making the entire install procedure similar to what a user would expect from other popular graphical operating systems. -- I personally like the way the ports work and will probably not change to any type of packages but you never know. I have never felt comfortable with the Linux packages. From what I've heard PBIs actually resemble OSX's dmgs more than Linux packages as Linux doesn't package in `bundle' format (contain all of the needed applications and libraries in one container). HTH, -Garrett ___ 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: stable ports?
On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras ivo...@freebsd.org wrote: Alexey Shuvaev wrote: One way to do it, my proposal, would be to maintain a stable overlay of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), containing ports deemed important for some reason. What is the criteria which port version goes into particular branch? That is, which versions of, say, gtk will have 6.x, 7.x and 8.x? Is it supposed to be what was available at the time when the branch was out? I'd suggest that yes - keeping the current ports tree as-is as the unstable HEAD. If this is the case, 6.x branch will have pretty outdated heavy infrastructure ports (like gnome/kde libs, see below). Yes. Exactly as with all other operating systems with long-term support and binary packages. OTOH, users can always track HEAD as they do now. Only the users who really need it would follow the stagnating branches. See ref: Debian :) Also, nothing (for some values of nothing) would stop people running FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not, depending on ports developers. What if the supported lifetime of the port upstream is less than supported lifetime of FreeBSD branch? Only if an update is needed (e.g. for security purposes), either of these: 1) Some other OS, Linux distribution, etc. nags the developers to fix it upstream or do the patch themselves, which we can pick up 2) The port maintainer(s) do it themselves (discouraged, of course) 3) The port is marked as insecure (possibly in vuxml) and the users are left to nag the developers for #1 or #2 :) If there is no immediate pressing need to update such a port (e.g. security), people can run arbitrarily old versions of applications forever. Or track HEAD. Who will backport at least security fixes to the port? I'd suggest that, previously to including the port in the stable branched the maintainer(s) agree to do it if necessary. Of course, it would be completely voluntarily - no maintainance, no stable port. It would defeat the purpose. * Updates which break shared libraries would not be allowed within such a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng, libjpeg, xorg). On the one side who will maintain such a beasts like outdated version of xorg??? On the other side, if all major ports are frozen what is left Outdated beasts tend not to change much. to be updated? In other words what is the difference between proposed stable ports branch and a static snapshot? The static snapshot doesn't magically evolve Apache from 2.2.0 to 2.2.14+ but deliberately stays away from 2.4.0 because it would break its ABI and require recompilation of its modules :) As others noted, shared libraries are the issue - if a port, during its update, bumps its shared library version (libsomething.so.1 - libsomething.so.2), it would *not* *ever* be upgraded in the stable branch. * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on 7.0 for all 7.x branches). Could not this be done already with the current ports? Yes it could. This is really tangential for the discussion, it concerns more the next step - binary packages and updates. I have not used Linux myself in the last 6 years, so I'm not very confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu installations not far from me. Well, as tools they (apt, ...) may be quite good, but I remember the too early update to firefox3 (which crashed every few minutes and that was an official gnome browser!) and the problems with intel video card (hard freeze of the system) after upgrade to the new Xorg. So, the tools alone do not solve that many problems... Yes, of course. Most of the problems here are not technical but organizational. Creating a package manager is relatively easy compared to the project infrastructure (peopleware) that need to support it. Weighting these all, I would say no. There is already enough fun keeping ports working on CURRENT. And see below. Ok. Back on topic, would not it be better to provide official packages for upgrades built from some chosen snapshots of the ports tree? No, since it doesn't solve the major problem of forced upgrades of entires subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg, qt). In some cases (when really needed?) there are already different variants of the same port (port / portXY / port-devel). This makes sense for a very small number of ports. E.g. having PHP 5.2 and 5.3 at the same time in the same ports tree would probably add to the confusion. But you *must* upgrade to latest php-5.x port because of security updates and so you are forced to upgrade php to 5.3 (and everything that depends on it) even when 5.2 is supported upstream. There is one important note to make: Many times you're forced to upgrade packages because of ABI breakages, etc. What would happen if there was a CVE assigned for
Re: stable ports?
On Mon, Mar 29, 2010 at 12:49 PM, Ivan Voras ivo...@freebsd.org wrote: Doug Hardie wrote: On 29 March 2010, at 08:57, Ivan Voras wrote: In some cases the burdens are obvious - the maintainer(s) would need to e.g. maintain three versions of the ports - a random example would be e.g. X.Org 7.0 for 6.x, 7.2 for 7.x and 7.4 for 8.x. Another would be keeping PHP 5.2 for 7.x and 8.x and having 5.3 in the future (CURRENT/9.x) branch. I am a bit concerned about your concept of maintain, being able to build a port successfully, does not necessarily mean it will work properly. For example, qpopper (which I maintain) has an issue where one feature does not work properly on 64 bit machines where it works fine on 32 bit machines. In addition, there are a number of other machine types that are currently not heavily used but might become so in the future. Thats a lot of different combinations of hardware and OSs to keep running for the maintainers. It was done (in Linux), hence it can be done. If all else fails and both the project and the maintainer cannot find suitable build and test machines, I'd suggest using ONLY_FOR_ARCHS, or doing the whole stable dance only for Tier 1 platforms (enumerated in http://www.freebsd.org/doc/en/articles/committers-guide/archs.html to be i386, amd64, pc98). AFAIK from the ports POW, pc98 and i386 are too close to be considered separately. Virtualization (VirtualBox) may help maintainers test on the architecture they don't run natively. Virtualbox only runs x86-compatible platforms: An x86 virtualization software package developed by Sun Microsystems. Distributed under either the GNU GPL or a proprietary license with additional ... That would leave arm, ia64, mips, powerpc, and sparc64 out in the cold. Maybe folks should try qemu (despite the fact that it's a buggy-ish emulator?): From http://wiki.qemu.org/download/qemu-doc.html: For system emulation, the following hardware targets are supported: * PC (x86 or x86_64 processor) * ISA PC (old style PC without PCI bus) * PREP (PowerPC processor) * G3 Beige PowerMac (PowerPC processor) * Mac99 PowerMac (PowerPC processor, in progress) * Sun4m/Sun4c/Sun4d (32-bit Sparc processor) * Sun4u/Sun4v (64-bit Sparc processor, in progress) * Malta board (32-bit and 64-bit MIPS processors) * MIPS Magnum (64-bit MIPS processor) * ARM Integrator/CP (ARM) * ARM Versatile baseboard (ARM) * ARM RealView Emulation/Platform baseboard (ARM) * Spitz, Akita, Borzoi, Terrier and Tosa PDAs (PXA270 processor) * Luminary Micro LM3S811EVB (ARM Cortex-M3) * Luminary Micro LM3S6965EVB (ARM Cortex-M3) * Freescale MCF5208EVB (ColdFire V2). * Arnewsh MCF5206 evaluation board (ColdFire V2). * Palm Tungsten|E PDA (OMAP310 processor) * N800 and N810 tablets (OMAP2420 processor) * MusicPal (MV88W8618 ARM processor) * Gumstix Connex and Verdex motherboards (PXA255/270). * Siemens SX1 smartphone (OMAP310 processor) * Syborg SVP base model (ARM Cortex-A8). * AXIS-Devboard88 (CRISv32 ETRAX-FS). * Petalogix Spartan 3aDSP1800 MMU ref design (MicroBlaze). Thanks, -Garrett ___ 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: stable ports?
On Tue, Mar 30, 2010 at 12:26 AM, Garrett Cooper yanef...@gmail.com wrote: On Tue, Mar 30, 2010 at 12:18 AM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Mar 29, 2010 at 11:35 AM, Ivan Voras ivo...@freebsd.org wrote: Alexey Shuvaev wrote: One way to do it, my proposal, would be to maintain a stable overlay of the ports, one for each major supported branch (i.e. 6.x, 7.x, 8.x), containing ports deemed important for some reason. What is the criteria which port version goes into particular branch? That is, which versions of, say, gtk will have 6.x, 7.x and 8.x? Is it supposed to be what was available at the time when the branch was out? I'd suggest that yes - keeping the current ports tree as-is as the unstable HEAD. If this is the case, 6.x branch will have pretty outdated heavy infrastructure ports (like gnome/kde libs, see below). Yes. Exactly as with all other operating systems with long-term support and binary packages. OTOH, users can always track HEAD as they do now. Only the users who really need it would follow the stagnating branches. See ref: Debian :) Also, nothing (for some values of nothing) would stop people running FreeBSD 6.x to track the 7.x stable ports branch if they want. Or not, depending on ports developers. What if the supported lifetime of the port upstream is less than supported lifetime of FreeBSD branch? Only if an update is needed (e.g. for security purposes), either of these: 1) Some other OS, Linux distribution, etc. nags the developers to fix it upstream or do the patch themselves, which we can pick up 2) The port maintainer(s) do it themselves (discouraged, of course) 3) The port is marked as insecure (possibly in vuxml) and the users are left to nag the developers for #1 or #2 :) If there is no immediate pressing need to update such a port (e.g. security), people can run arbitrarily old versions of applications forever. Or track HEAD. Who will backport at least security fixes to the port? I'd suggest that, previously to including the port in the stable branched the maintainer(s) agree to do it if necessary. Of course, it would be completely voluntarily - no maintainance, no stable port. It would defeat the purpose. * Updates which break shared libraries would not be allowed within such a branch/overlay (i.e. no updating gnome 2.xx to 2.x(x+1), libpng, libjpeg, xorg). On the one side who will maintain such a beasts like outdated version of xorg??? On the other side, if all major ports are frozen what is left Outdated beasts tend not to change much. to be updated? In other words what is the difference between proposed stable ports branch and a static snapshot? The static snapshot doesn't magically evolve Apache from 2.2.0 to 2.2.14+ but deliberately stays away from 2.4.0 because it would break its ABI and require recompilation of its modules :) As others noted, shared libraries are the issue - if a port, during its update, bumps its shared library version (libsomething.so.1 - libsomething.so.2), it would *not* *ever* be upgraded in the stable branch. * Binary packages for a whole X.Y branch would be built on X.0 (e.g. on 7.0 for all 7.x branches). Could not this be done already with the current ports? Yes it could. This is really tangential for the discussion, it concerns more the next step - binary packages and updates. I have not used Linux myself in the last 6 years, so I'm not very confident with all these 'apt', 'yum' and co, however I have 2 Ubuntu installations not far from me. Well, as tools they (apt, ...) may be quite good, but I remember the too early update to firefox3 (which crashed every few minutes and that was an official gnome browser!) and the problems with intel video card (hard freeze of the system) after upgrade to the new Xorg. So, the tools alone do not solve that many problems... Yes, of course. Most of the problems here are not technical but organizational. Creating a package manager is relatively easy compared to the project infrastructure (peopleware) that need to support it. Weighting these all, I would say no. There is already enough fun keeping ports working on CURRENT. And see below. Ok. Back on topic, would not it be better to provide official packages for upgrades built from some chosen snapshots of the ports tree? No, since it doesn't solve the major problem of forced upgrades of entires subtrees when an ancestor changes (e.g. libgtk, libpng, libjpeg, qt). In some cases (when really needed?) there are already different variants of the same port (port / portXY / port-devel). This makes sense for a very small number of ports. E.g. having PHP 5.2 and 5.3 at the same time in the same ports tree would probably add to the confusion. But you *must* upgrade to latest php-5.x port because of security updates and so you are forced to upgrade php to 5.3 (and everything that depends on it) even when 5.2 is supported upstream. There is one
Re: stable ports?
Am 30.03.2010 09:30, schrieb Garrett Cooper: If this is really slick and tinderbox / whatever tools is doing its job and no PRs have been reported for X number of days on a given port (would require tie-ins to GNATS, or whatever), perhaps it would be nice if ports were automatically `promoted' from HEAD to STABLE? I mean, why do something if a computer can do it for you, right :)? It appears you're proposing the Debian style of management, which has a stable branch, a testing branch and an unstable branch. Packages usually propagate from unstable to testing under certain preconditions. -- Matthias Andree ___ 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: stable ports?
Am 30.03.2010 09:18, schrieb Garrett Cooper: There is one important note to make: Many times you're forced to upgrade packages because of ABI breakages, etc. What would happen if there was a CVE assigned for PNG tomorrow (like there was for JPEG a year and change ago) where mass changes were required of 1k ports -- you could either have to bump the versions or patch _every_ single port like Dirk has been doing for the past week and a half (and is still doing... also with other folks' help thankfully -- poor guy). Well, a security fix usually does not mean you're breaking ABI. The ABI break would be caused by a design flaw in the application that cannot be fixed any other way, or by lack of backports of the fix to the old ABI version, so you're forced to use the new ABI. To complicate matters, using stable versions is exactly the trigger for the latter situation: your using an older than the latest version is what creates the need for backporting the fix to the stable API. Furthermore, people could check out packages with RELENG_* tags, and maintainers could use their best judgment to tag the files appropriate to the change being committed? I don't think this proposal is useful. Technically it would work, but socially it wouldn't. Why? RELENG_* tagging would require that port maintainers oversee the implications for all supported FreeBSD releases, possibly run tinderboxen to test (and thereabouts) and would likely scare away maintainers. Not exactly what we need. Also, another idea that was briefly underscored that I (and other folks more importantly) like is that release branches should only be updated for security releases. I admit, this is a pain in the rear with large / sweeping commits (JPEG/PNG anyone :/?), but at least it would ensure that stability is largely maintained. Basically you'd try to hold off on the large/sweeping commits for those branches and backport. How about if we create a new port if the ABI or API change in incompatible ways? As in: jpeg.(N-1) is kept around for compatibility with ports that don't support jpeg.N (either ABI or API wise) and slowly phased out later. This takes care of the libraries. Open issue: how to handle includes. This approach (remotely) resembles what the (regexp) database/db[34]. ports are doing, with some magic in Mk/bsd.database.mk to allow for picking the incurred DB version semi-automatically. -- Matthias Andree ___ 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: stable ports?
On Tue 30 Mar 2010 at 04:55:01 PDT Matthias Andree wrote: I don't think this proposal is useful. Technically it would work, but socially it wouldn't. Why? RELENG_* tagging would require that port maintainers oversee the implications for all supported FreeBSD releases, possibly run tinderboxen to test (and thereabouts) and would likely scare away maintainers. Not exactly what we need. Maintainers are already effectively forced to run tinderboxen when commmitters respond to PR's with terse comments like Build failed on FreeBSD 6.x, here's the build log, please look into it. ;) Not that I mind. I enjoy the debugging exercise. But if there's going to be increased pressure to use tinderbox, perhaps something could be done to streamline and speedup the creation of new jails? I'm not sure what I think about this proposal, however, or whether my relatively obscure ports will even be affected by it. So I'm following the discussion with interest but don't know enough to contribute anything useful. -- Charlie ___ 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
x11-toolkits/qt4-gui fails with png
c++ -c -pipe -g -g -g -I../../include/Qt -I../../include -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -I/usr/local/include -I/usr/local/include/freetype2 -fPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/debug-shared -I../3rdparty/xorg -I/usr/local/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/debug-shared -I/usr/local/include -I.uic/debug-shared -I/usr/local/include -o .obj/debug-shared/qbezier.o painting/qbezier.cpp image/qpnghandler.cpp: In function 'void setup_qt(QImage, png_struct*, png_info*, float)': image/qpnghandler.cpp:169: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) image/qpnghandler.cpp:169: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) image/qpnghandler.cpp:214: warning: 'trans_color' is deprecated (declared at /usr/local/include/png.h:732) image/qpnghandler.cpp:214: warning: 'trans_color' is deprecated (declared at /usr/local/include/png.h:732) image/qpnghandler.cpp:223: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:223: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:236: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:236: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:239: warning: 'num_trans' is deprecated (declared at /usr/local/include/png.h:643) image/qpnghandler.cpp:239: warning: 'num_trans' is deprecated (declared at /usr/local/include/png.h:643) image/qpnghandler.cpp:241: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:241: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:242: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:242: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:243: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:243: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:247: warning: 'trans_alpha' is deprecated (declared at /usr/local/include/png.h:730) image/qpnghandler.cpp:247: warning: 'trans_alpha' is deprecated (declared at /usr/local/include/png.h:730) image/qpnghandler.cpp:254: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:254: warning: 'num_palette' is deprecated (declared at /usr/local/include/png.h:641) image/qpnghandler.cpp:256: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:256: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:257: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:257: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:258: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp:258: warning: 'palette' is deprecated (declared at /usr/local/include/png.h:639) image/qpnghandler.cpp: In member function 'QImage::Format QPngHandlerPrivate::readImageFormat()': image/qpnghandler.cpp:534: warning: 'color_type' is deprecated (declared at /usr/local/include/png.h:647) image/qpnghandler.cpp:534: warning: 'color_type' is deprecated (declared at /usr/local/include/png.h:647) image/qpnghandler.cpp:536: warning: 'bit_depth' is deprecated (declared at /usr/local/include/png.h:645) image/qpnghandler.cpp:536: warning: 'bit_depth' is deprecated (declared at /usr/local/include/png.h:645) image/qpnghandler.cpp:536: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) image/qpnghandler.cpp:536: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) image/qpnghandler.cpp:538: warning: 'bit_depth' is deprecated (declared at /usr/local/include/png.h:645) image/qpnghandler.cpp:538: warning: 'bit_depth' is deprecated (declared at /usr/local/include/png.h:645) image/qpnghandler.cpp:543: warning: 'color_type' is deprecated (declared at /usr/local/include/png.h:647) image/qpnghandler.cpp:543: warning: 'color_type' is deprecated (declared at /usr/local/include/png.h:647)
Re: x11-toolkits/qt4-gui fails with png
Hallo Doug Barton, I can not reproduce this. The upstream code contains support for libpngi 1.4 #FreeBSD: ports/x11-toolkits/qt4-gui/Makefile,v 1.30 2010/03/28 06:47:25 dinoex Exp $ kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] http://people.freebsd.org/~dinoex/errorlogs/ r...@build7:/usr/ports/local/update# sh pkg_update make-packages x11-toolkits/qt4-gui # checking: /usr/ports/x11-toolkits/qt4-gui === Vulnerability check disabled, database not found = MD5 Checksum OK for KDE/qt-everywhere-opensource-src-4.6.1.tar.gz. = SHA256 Checksum OK for KDE/qt-everywhere-opensource-src-4.6.1.tar.gz. r...@build7:/usr/ports/local/update# sh pkg_update make-packages x11-toolkits/qt4-gui ___ 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-toolkits/qt4-gui fails with png
On Tue, 30 Mar 2010, Doug Barton wrote: c++ -c -pipe -g -g -g -I../../include/Qt -I../../include -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -I/usr/local/include -I/usr/local/include/freetype2 -fPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/debug-shared -I../3rdparty/xorg -I/usr/local/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/debug-shared -I/usr/local/include -I.uic/debug-shared -I/usr/local/include -o .obj/debug-shared/qbezier.o painting/qbezier.cpp image/qpnghandler.cpp: In function 'void setup_qt(QImage, png_struct*, png_info*, float)': image/qpnghandler.cpp:169: warning: 'channels' is deprecated (declared at /usr/local/include/png.h:658) ... image/qpnghandler.cpp:961: warning: 'height' is deprecated (declared at /usr/local/include/png.h:634) image/qpnghandler.cpp:961: warning: 'height' is deprecated (declared at /usr/local/include/png.h:634) *** Error code 1 1 error *** Error code 1 Stop in /usr/local/ports/x11-toolkits/qt4-gui. With a fresh ports tree, it just built and reinstalled here. Same warnings, but no error. I don't see the actual error in your output. FreeBSD lightning 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar 29 14:57:45 MDT 2010 r...@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 -Warren Block * Rapid City, South Dakota USA ___ 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: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
Alexey.
___
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-toolkits/qt4-gui fails with png and/or zlib.h off64_t
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/30 12:22, Doug Barton wrote: Testing it again I see that I didn't go far enough up to find the real error, sorry Dirk. The actual problem seems to be with zlib.h. This is from qt4-gui: [...] -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. There are some discussion about these _LARGEFILE64_SOURCE usage on zlib developers' mailing list. To put it short, it's now believed that the usage of _LARGEFILE64_SOURCE on FreeBSD is wrong. I'm not quite sure though, if I should use some workaround over this, like Mac OS X did (newer zlib has a similar change by requiring _LFS64_SOURCE): Index: zconf.h === - --- zconf.h (revision 205883) +++ zconf.h (working copy) @@ -375,7 +375,7 @@ # endif #endif - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) # include sys/types.h #endif Index: zlib.h === - --- zlib.h(revision 205883) +++ zlib.h (working copy) @@ -1556,7 +1556,7 @@ inflateBackInit_((strm), (windowBits), (window), \ ZLIB_VERSION, sizeof(z_stream)) - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); ZEXTERN off64_t ZEXPORT gzseek64 OF((gzFile, off64_t, int)); ZEXTERN off64_t ZEXPORT gztell64 OF((gzFile)); Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLslHRAAoJEATO+BI/yjfBXOUIAKW6UkjU8JGw2CQyNWVhqxXg dz1OKJVk5iS1abpPANZPPWRnl/XK2MiDIVdkc5HQCCbFIuodR4nWlbZN21yGMJvf DZX3L15nhXE7LSMLxOgrfzqlgIRxnu6P/7mjlZq/y/TERrpHh48lN7HcHfRrWZd4 H/dFdSQbL81T7/LGPmrHOsR9uXPOmlaa1hUMCgJhNl2S6AahfyfcEj5hQeCBXqHd ms9gORkFuMb9LStS3kaTSpb6/D81ci+WbGpHozIA1zGyTazyj9AJjFkYHhC9VZLF 9kSGF3yuD95pGHrOrZJQSyTNBMtWFAoLm1qMMZu+D8b1vpP3AnVdSGVhTR8QrM8= =vFcJ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t
I can't comment intelligently on whether or not the fix below is correct, but with it, qt4-qmake compiles. I'll move on to try recompiling the rest of qt4. Doug On 03/30/10 12:32, Xin LI wrote: On 2010/03/30 12:22, Doug Barton wrote: Testing it again I see that I didn't go far enough up to find the real error, sorry Dirk. The actual problem seems to be with zlib.h. This is from qt4-gui: [...] -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. There are some discussion about these _LARGEFILE64_SOURCE usage on zlib developers' mailing list. To put it short, it's now believed that the usage of _LARGEFILE64_SOURCE on FreeBSD is wrong. I'm not quite sure though, if I should use some workaround over this, like Mac OS X did (newer zlib has a similar change by requiring _LFS64_SOURCE): Index: zconf.h === --- zconf.h (revision 205883) +++ zconf.h (working copy) @@ -375,7 +375,7 @@ # endif #endif -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) # include sys/types.h #endif Index: zlib.h === --- zlib.h(revision 205883) +++ zlib.h(working copy) @@ -1556,7 +1556,7 @@ inflateBackInit_((strm), (windowBits), (window), \ ZLIB_VERSION, sizeof(z_stream)) -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); ZEXTERN off64_t ZEXPORT gzseek64 OF((gzFile, off64_t, int)); ZEXTERN off64_t ZEXPORT gztell64 OF((gzFile)); Cheers, -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: Old ports bugs analyzis
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with
custom
settings for my FreeBSD machines. I know about many programs, which
do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on
them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you remember
The Bat mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about
Makefile syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And when
ports tree has changed place in system, it's not good idea to rebuild
index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but
enough version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/docs
Thanks,
Alexey.
___
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: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com wrote:
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you remember The Bat
mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about Makefile
syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And when ports
tree has changed place in system, it's not good idea to rebuild index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
Caveat: static libraries are build dependencies; dynamic libraries are
lib dependencies. We had a discussion about this on #bsdports
yesterday and it was a well understood fact that was being proposed
for a move forward in terms of installing binary packages.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but enough
version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX, see
py program for comments about types.
I have tried to understand what is in these files but have not managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/docs
Cheers,
-Garrett
___
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: Old ports bugs analyzis
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com
wrote:
--
With pleasure
On 30 Mar 2010, at 23:14, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with
custom
settings for my FreeBSD machines. I know about many programs,
which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on
them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is
1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you
remember The Bat
mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about
Makefile
syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And
when ports
tree has changed place in system, it's not good idea to rebuild
index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
Caveat: static libraries are build dependencies; dynamic libraries are
lib dependencies. We had a discussion about this on #bsdports
yesterday and it was a well understood fact that was being proposed
for a move forward in terms of installing binary packages.
Port building ability will be avaliable? Now ports tree has bugs, but
I can turn on/of custom build options. I use most of ports with custom
settings.
I put my analysys in several work files:
I've removed ${PORTSDIR} from paths for readability in index files.
http://freebsd.eroese.org/bsd.local.mk - different describe target
(clean and simple)
http://freebsd.eroese.org/portInfo.py - py-IDX maker. old, but
enough
version.
http://freebsd.eroese.org/tag - portsnap(8) tag
http://freebsd.eroese.org/IDX - special maked IDX
http://freebsd.eroese.org/py-IDX - human readable format of IDX,
see
py program for comments about types.
I have tried to understand what is in these files but have not
managed
it completely.
The file py-IDX lists 2 of my ports, devel/slglade and
x11-toolkits/gtkdatabox as being fixed:
fix devel/slglade
fix x11-toolkits/gtkdatabox
Could you elaborate more what was 'fixed' in these 2 examples?
Thanks,
I've striped out debug output from top.
I've updated files py-IDX and python program.
And also put some documentation in file http://freebsd.eroese.org/
docs
Cheers,
-Garrett
___
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
opennms port
There is an opennms port at: http://www.geeklan.co.uk/files/opennms/ however, it is a little dated. I have attached a version that works for opennms 1.6.10 (at least it worked for me with make install, after I uploaded the java dependencies in /usr/ports/distfiles ) Attached is a tar ball of opennms from /usr/ports/net-mgmt/ of my machine. The changes from geeklan's ports are the bumped version, new signatures, and a corrected path for the source files. Micheas -- And do you think (fop that I am) that I could be the Scarlet Pumpernickel? ___ 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: [kde-freebsd] x11-toolkits/qt4-gui fails with png and/or zlib.h off64_t
On Wednesday 31 March 2010 06:32:33 Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2010/03/30 12:22, Doug Barton wrote: Testing it again I see that I didn't go far enough up to find the real error, sorry Dirk. The actual problem seems to be with zlib.h. This is from qt4-gui: [...] -DQ_INTERNAL_QAPP_SRC -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. There are some discussion about these _LARGEFILE64_SOURCE usage on zlib developers' mailing list. To put it short, it's now believed that the usage of _LARGEFILE64_SOURCE on FreeBSD is wrong. I'm not quite sure though, if I should use some workaround over this, like Mac OS X did (newer zlib has a similar change by requiring _LFS64_SOURCE): Index: zconf.h === - --- zconf.h (revision 205883) +++ zconf.h (working copy) @@ -375,7 +375,7 @@ # endif #endif - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) # include sys/types.h #endif Index: zlib.h === - --- zlib.h (revision 205883) +++ zlib.h(working copy) @@ -1556,7 +1556,7 @@ inflateBackInit_((strm), (windowBits), (window), \ ZLIB_VERSION, sizeof(z_stream)) - -#ifdef _LARGEFILE64_SOURCE +#if defined(_LARGEFILE64_SOURCE) !defined(__FreeBSD__) ZEXTERN gzFile ZEXPORT gzopen64 OF((const char *, const char *)); ZEXTERN off64_t ZEXPORT gzseek64 OF((gzFile, off64_t, int)); ZEXTERN off64_t ZEXPORT gztell64 OF((gzFile)); Confirmed, with this patch all qt4 builds fine now. FreeBSD Fluffy.Khv.RU 9.0-900010-CURRENT FreeBSD 9.0-900010-CURRENT #0 r205776M: Sun Mar 28 15:56:58 VLAST 2010 flu...@fluffy.khv.ru:/usr/obj/usr/src/sys/Spot amd64 Dima Red Fox Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 k...@freebsd Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 ___ 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: Old ports bugs analyzis
On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin eir...@gmail.com wrote:
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com wrote:
On 30 Mar 2010, at 23:14, Alexey Shuvaev
shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with custom
settings for my FreeBSD machines. I know about many programs, which do
same, but I don't like strange depends, which are not controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you remember The
Bat
mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about Makefile
syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And when
ports
tree has changed place in system, it's not good idea to rebuild index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
Caveat: static libraries are build dependencies; dynamic libraries are
lib dependencies. We had a discussion about this on #bsdports
yesterday and it was a well understood fact that was being proposed
for a move forward in terms of installing binary packages.
Port building ability will be avaliable? Now ports tree has bugs, but I can
turn on/of custom build options. I use most of ports with custom settings.
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
Thanks,
-Garrett
___
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: Old ports bugs analyzis
On 31 Mar 2010, at 04:14, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:54 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 31 Mar 2010, at 00:49, Garrett Cooper yanef...@gmail.com wrote:
On Tue, Mar 30, 2010 at 1:25 PM, Arseny Nasokin eir...@gmail.com
wrote:
On 30 Mar 2010, at 23:14, Alexey Shuvaev
shuv...@physik.uni-wuerzburg.de
wrote:
On Tue, Mar 30, 2010 at 01:05:39AM +0400, Eir Nym wrote:
I work on creating system for system and ports autobuilder with
custom
settings for my FreeBSD machines. I know about many programs,
which do
same, but I don't like strange depends, which are not
controlled by
OPTIONS and some another
I've analyse ports tree and want to say about.
There're lot problems with ports to create per-port PRs
manually.Common types of problems are listed here:
0) Main part of problems in tons of ports, which has hidden
options
(WITH WITHOUT checking), but not using OPTIONS for them.
1) There many libraries added with BUILDRUN dependencies, not as
LIB-DEPENDS.
2) Some ports has only BUILD depends to libraries, but links them
dynamicly.
3) All(?) samba33 slaves define dependency as samba33, and make
warning me about master target redefinition when do something
on them.
4) many ports define dependencies as
${.CURDIR}/../../category/dep-port-name
5) And some adds trailing slash.
I want fix these problems, but I have no much time to fix several
thousands of ports. This work (include PR sending) needs about
is 1-2
month per 8-10 hours a day.
If the problems are so common, maybe there are not so many
problems
at all? :)
Yes, it's features! Let's all bugs will be features! Do you
remember The
Bat
mail client, which doesn't want support standarts at all?
Cases 0, 2, 3 and 4 are bugs.
0: I want to control options via OPTIONS, not by knowledge about
Makefile
syntax with much time.
2: build port, install, remove lib and get this port unusable.
3: where program should find package orign samba33?
4: when reading Makefile, it hard to explain where port is. And
when
ports
tree has changed place in system, it's not good idea to rebuild
index.
2, 5 are questions at most.
2: libraries should be LIB_DEPENDS
Caveat: static libraries are build dependencies; dynamic libraries
are
lib dependencies. We had a discussion about this on #bsdports
yesterday and it was a well understood fact that was being proposed
for a move forward in terms of installing binary packages.
Port building ability will be avaliable? Now ports tree has bugs,
but I can
turn on/of custom build options. I use most of ports with custom
settings.
Today binary packages are rolled as generic as possible provided the
architecture they're built for and are monolithic, meaning that they
contain the build, lib, patch, and run dependencies required to build
everything, as they're generated after an in-place install in
${PREFIX} .
One of many ideas we were kicking around on #bsdports was to produce
`fat packages' which would be usable in package installation and ports
building scenarios (similar to the headache that exists in many Linux
distros with -devel and non-devel packages), but the user could
specify whether or not they wanted the -devel pieces or not (if it
applied) -- so only one set of packages would need to be distributed.
We didn't really kick the idea around too much, but it was still a
novelty that should be `nursed' to a proper conclusion as it would
allow folks who roll packages and install on embedded systems /
install bases, or prefer installing via packages, to have small
install bases, and smaller potential binary roll up after the fact.
Thanks,
-Garrett
I can't see and discuss in IRC due browser and platform(software part)
limitations in nearest future.
I don't clearly understand, will be ports system removed? Will there
will be sourse and binary packages or will it be Gentoo-style
portages, which will provide installation from binary or source with
options?
Almost all packages in my systems has custom settings.
___
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: Old ports bugs analyzis
On 03/30/10 21:36, Arseny Nasokin wrote: I don't clearly understand, will be ports system removed? At this time all discussion is theoretical. LONG before we make any actual changes the users will have a chance to chime in, and will be notified if any actual changes are made. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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
