Re: Hammer Hardlinks (directory question)
On 8/25/2012 13:38, s...@bestmx.ru wrote: Karthik Subramanian пишет: Not a hammer expert - but in general directory hardlinks are bad because they can cause cycles in the directory tree. yep. i just discovered that hammer simply prohibits directory hardlinks, throwing a proper error message. i am sorry i asked it before try it (why did i?) I don't think any filesystem allows hardlinking to directories.
Re: Latest pkgsrc status - as compared to last report of 11 August (+66)
On 8/18/2012 00:44, Pierre Abbat wrote: On Wednesday 15 August 2012 13:35:23 John Marino wrote: This was a full run, nothing was masked. We're over 11,700 packages for now (96.4%). The build logs are available this time, see link below. Most of the regressions have already been fixed by their maintainers and Asterisk 10 should build cleanly next time. Where should I point pkgin? I checked the usual location and there are no packages for i386. Pierre So far I don't upload packages, I'm just doing private build runs to help me determine what needs fixing. These aren't official packages. Unless Justin instructs me to start uploading... John
Latest pkgsrc status - as compared to last report of 11 August (+66)
This was a full run, nothing was masked. We're over 11,700 packages for now (96.4%). The build logs are available this time, see link below. Most of the regressions have already been fixed by their maintainers and Asterisk 10 should build cleanly next time. John pkgsrc bulk build report DragonFly 3.1/i386 Compiler: gcc Build start: 2012-08-14 19:51 Build end: 2012-08-15 16:41 Full report: http://leaf.dragonflybsd.org/~marino/masterbulk/20120814.1951/meta/report.html Total number of eligible packages: 12144 Successfully built: 11707 Failed to build: 377 Depending on failed package:60 Total number of masked packages: 334 Depending on masked package:33 Packages breaking the most other packages Breaks Location Package - 7 textproc/cabocha cabocha-0.53 3 filesystems/py-fuse-bindings py27-fuse-bindings-0.2.1 2 devel/ruby-ffiruby19-ffi-1.1.2 2 lang/eieioeieio-0.17nb3 2 lang/gauche Gauche-0.9.3.3 2 lang/sun-jre6 sun-jre6-6.0.33 2 multimedia/libflashsupport-pulse libflashsupport-pulse-20081219nb2 2 net/kdenetwork3 kdenetwork-3.5.10nb19 2 sysutils/lsof lsof-4.84nb1 1 cad/sci-wcalc sci-wcalc-1.0nb3 1 converters/p5-MARC-Charsetp5-MARC-Charset-1.33 1 databases/p5-DBD-Oracle p5-DBD-Oracle-1.23nb2 1 databases/py-ldap py27-ldap-2.4.9 1 databases/ruby-dbd-pg ruby18-dbd-pg-0.3.9 1 databases/ruby-pg ruby18-pg-0.14.0nb1 1 devel/SOPESOPE-2.0.0b3nb1 1 devel/emacs20-elibemacs20-elib-1.0nb3 1 devel/py-stompclient py25-stompclient-0.3.2 1 devel/sapnwrfcsdk sapnwrfcsdk-7.11 1 devel/semanticsemantic-1.4.4nb1 1 editors/emacs24 emacs-24.1nb3 1 games/simgear simgear-2.0.0nb10 1 graphics/enblend-enfuse enblend-enfuse-4.0nb5 1 graphics/kipi-plugins-kde3kipi-plugins-0.1.7nb20 1 graphics/unicap unicap-0.9.3nb11 1 lang/SmartEiffel SmartEiffel-2.0nb1 1 lang/sun-jdk6 sun-jdk6-6.0.33 1 math/octave-forge octave-forge-2006.03.17nb7 1 math/scilab scilab-4.1nb5 1 math/xylibxylib-0.8nb1 1 multimedia/libva libva-1.0.6nb1 1 multimedia/mltmlt-0.5.10nb9 1 multimedia/py-gstreamer0.10 py25-gstreamer0.10-0.10.22nb3 1 multimedia/xine-uixine-ui-0.99.7 1 net/py-zmqpy26-zmq-2.1.11 1 parallel/ganglia-monitor-core ganglia-monitor-core-3.1.2nb12 1 print/LPRng-core LPRng-core-3.8.28nb3 1 print/pdvipsk pdvipsk-5.98pl1.7b 1 security/honeyd-arpd honeyd-arpd-0.2nb13 1 sysutils/py-dbus py32-dbus-1.1.1 1 sysutils/skillskill-4.1.4 1 textproc/pxp pxp-1.1.6nb1 1 www/ruby-activeresource3 ruby19-activeresource-3.0.17 1 x11/fixesproto4 fixesproto-4.0 1 x11/liblbxutilliblbxutil-1.0.1 1 x11/rxvt rxvt-2.7.10nb6 Masked Packages breaking the most other packages Breaks Location Package - 8 audio/mbrola mbrola-301hnb2 5 emulators/suse113_x11 suse_x11-11.3 3 emulators/suse113_alsasuse_alsa-11.3nb3 3 emulators/suse113_basesuse_base-11.3nb8 3 emulators/suse113_gtk2suse_gtk2-11.3nb5 3 lang/pnet pnet-0.8.0nb1 3 pkgtools/x11-linksx11-links-0.70 List of packages added to pkgsrc since 2012-08-11 21:45 (26) Location Package - built devel/py-daemon py25-daemon-1.5.5 built devel/py-daemon py26-daemon-1.5.5 built devel/py-daemon py27-daemon-1.5.5 built devel/py-lockfile py27-lockfile-0.9.1 built devel/py-lockfile py26-lockfile-0.9.1 built devel/py-lockfile py25-lockfile-0.9.1 built devel/py-stompclient py26-stompclient-0.3.2 built devel/py-stompclient py27-stompclient-0.3.2 failed
Top ten interesting broken packages (Volunteers?)
This is an opinionated list of packages that are broken only on DragonFly and we should want to see fixed. I'd like to see some people volunteer to fix them, preferable somebody would wants to use the package themselves. I'm sure people have a much different opinion of what is top ten so please express if you see an obvious package missing from the list. Excluded from the list: * Asterisk10, Asterisk18: The package maintainer intentionally removed the DragonFly fix without replacing it because he doesn't understand why an extra library builds on DragonFly and doesn't want to expand the PLIST w/o this comprehension. He doesn't care that it's broken on DragonFly in the meantime. Since he removed a working solution, he's on the hook to come up with another one. * lang/sbcl: profmakx and I have put some work into this one and profmakx is slowly getting to the end as his time permits. * misc/libreoffice: Fixed for pbulk (and then upgraded, hopefully upgraded libreoffice still builds in pbulk) 01. Emacs 24(editors/emacs24 + editors/emacs24-nox11). 02. perfuse (filesystems/perfuse) 03. lsof(sysutils/lsof) 04. jabberd (chat/jabberd) 05. xymonclient (net/xymonclient) 06. gnome-commander (sysutils/gnome-commander) 07. grub2 (sysutils/grub2) 08. xine-ui (multimedia/xine-ui) 09. racket (lang/racket) 10. gprolog (lang/gprolog) BONUS: 11. koffice (misc/kofice) 12. mame(emulators/mame) Problems with package: 01. build utility temacs segfaults 02. Insufficient puffs support? Seems to need heavy patching. 03. Needs extensive dfly patches 04. Probably simple (main.c, missing reference during linking) 05. simple, fails in install phase (conflict PLIST/CHECK_FILES_SKIP) 06. 'setErrorFunction' not declared in scope 07. Needs extensive dfly patches (getroot.c, hostdisk.c) 08. hitting lots of macro #warnings, probable needs #if __DragonFly__ somewhere 09. can't find schsys.h header from string.c 10. exception raised in pl utility during build 11. ks_pdf_import.cpp, poppler issue 12. I added dfly to config and fixed some drivers, but it broke again. Don't have log, need to reapply patches to see what's up.
Re: Top ten interesting broken packages (Volunteers?)
On 8/13/2012 14:08, Jelle Hermsen wrote: I can take a look at fixing Racket. Should I test on both df64 and df32? Cheers, Jelle Jelle, Yes, please. The lang/* packages usually require extra scrutiny with regards to platform. It's common to see a compiler work on i386 and not x86_64 and vice-versa. As an update for everyone else: net/xymon and net/xymonclient are now fixed. Thanks to Francois Tigeot fixing poppler016, misc/koffice is also now fixed along with graphics/kdegraphics3. So I'd like to add sysutils/k3b (DVD and CD authoring program) to the top ten. It should have been there before -- the error has something to do with missing cam-* devices. John
Re: Top ten interesting broken packages (Volunteers?)
On 8/13/2012 20:52, John Marino wrote: As an update for everyone else: net/xymon and net/xymonclient are now fixed. Thanks to Francois Tigeot fixing poppler016, misc/koffice is also now fixed along with graphics/kdegraphics3. So I'd like to add sysutils/k3b (DVD and CD authoring program) to the top ten. It should have been there before -- the error has something to do with missing cam-* devices. John Update #2: Number 4 should have been chat/jabberd2 rather than chat/jabberd, but it doesn't matter. Both versions of jabberd are building on recent master, both i386 and x86_64. The packages didn't change, something in the world must have improved. (It was masked in pbulk so it's been in the failed list falsely.). John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/7/2012 23:06, Justin Sherrill wrote: If you follow the link in the message, it should take you to the HTML report, which links to the build reports for each failed item. Or at least it should; I can't check stuff easily from where I am right now. On Aug 7, 2012 4:04 PM, Francois Tigeot ftig...@wolfpond.org I just checked, LibreOffice from pkgsrc-2012Q2 builds perfectly. I'm curious as to what the issue was. Hi Francois, It shouldn't be a surprise to you. I informed you a month ago that libreoffice *will* fail all bulk build attempts on every platform, without a doubt. It simply will not build in a clean environment. Not pbulk, not Tinderbox. it's an issue because it takes over 3 hours to build on a fast, multicore box and a binary package would be extremely nice. Although very time consuming, it would be worth the time to either disable the unit tests or add to the build environment what is missing. Some depends or buildlink3 inclusion is missing. Regards, John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/7/2012 22:04, Francois Tigeot wrote: On Tue, Aug 07, 2012 at 10:08:37AM -0400, Justin Sherrill wrote: pkgsrc bulk build report Build failures Package Breaks Maintainer - misc/libreoffice ftig...@wolfpond.org I just checked, LibreOffice from pkgsrc-2012Q2 builds perfectly. I'm curious as to what the issue was. (mail server issue fixed) Francois, do you have a patch for misc/libreoffice that I can commit that disables font handling? I'll test it first and if libreoffice builds in a clean environment, I'll commit it or tell you the next problem. John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/10/2012 13:11, Francois Tigeot wrote: On Fri, Aug 10, 2012 at 12:53:17PM +0200, John Marino wrote: Francois, do you have a patch for misc/libreoffice that I can commit that disables font handling? Disabling font handling is unthinkable! That would render the whole program useless... The error message is bogus, and caused by an unit test run at the end of the build. I've pushed one patch to wip/libreoffice to disable this particular test, patch-sw_Module_sw.mk I haven't been able to reproduce the No fonts could be found on the system error myself, I'm not sure if you'll be able to get a complete build with it. It was a typo, I mean the font unit testing. Can I use patch-sw_Module_sw.mk in misc/openoffice without modification? Fixing wip doesn't fix libreoffice that is already in pkgsrc. To only way to reproduce this is build libreoffice in Tinderbox-DragonFly or in pbulk... John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/7/2012 22:04, Francois Tigeot wrote: On Tue, Aug 07, 2012 at 10:08:37AM -0400, Justin Sherrill wrote: pkgsrc bulk build report Build failures Package Breaks Maintainer - misc/libreoffice ftig...@wolfpond.org I just checked, LibreOffice from pkgsrc-2012Q2 builds perfectly. I'm curious as to what the issue was. By the way, there's already a patch with that name in libreoffice -- it was added by NetBSD to disable that test and two more, but only for NetBSD. It might be worthwhile just pulling these three tests for all platforms. Anyway, FYI. I'll replace the existing page with the wip patch for the my testing purposes. John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/10/2012 15:02, Francois Tigeot wrote: Yes, I did disable these few tests permanently upstream. NetBSD is a fragile platform from LO's point of view. My philosophy are tests are for the packager. E.g. I have a few compiler packages that have test capability. I run the tests. Once I'm satisfied with the package state, the tests are off by default. We already know the result of the test, retesting is redundant work that doesn't buy you anything. I'd like to see LO have the ability to *NOT* test per switch. Unless the tests are part of the compilation process, they are a waste of time in production mode. IMHO, of course. John
Re: Fwd: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35
On 8/7/2012 16:08, Justin Sherrill wrote: I am in a spot with limited bandwidth, so I can't confirm this, but this should have uploaded as pkgsrc-2012q2 on Avalon. I haven't had a i386 build complete yet. Hasn't crashed yet, though... -- Forwarded message -- From: Charlie Root r...@df64.v12.su mailto:r...@df64.v12.su Date: Aug 6, 2012 1:25 AM Subject: df64 pkgsrc 2012Q2 DragonFly 3.0/x86_64 2012-07-24 11:35 To: jus...@shiningsilence.com mailto:jus...@shiningsilence.com pkgsrc bulk build report DragonFly 3.0/x86_64 Compiler: gcc Build start: 2012-07-24 11:35 Build end: 2012-08-06 12:20 Full report: http://avalon.dragonflybsd.org/reports/x86_64/3.0/20120724.1135/meta/report.html Machine readable version: http://avalon.dragonflybsd.org/reports/x86_64/3.0/20120724.1135/meta/report.bz2 Total number of packages: 12390 Successfully built: 11352 Failed to build: 295 Depending on failed package: 144 Explicitly broken or masked: 556 Depending on masked package:43 Packages breaking the most other packages Package Breaks Maintainer - devel/libdbusmenu-qt 106 pkgsrc-us...@netbsd.org math/eigen29 pkgsrc-us...@netbsd.org security/openvas-libraries 4 pkgsrc-us...@netbsd.org sysutils/coreutils 3 pkgsrc-us...@netbsd.org lang/gauche2 en...@netbsd.org devel/libFoundation2 pkgsrc-us...@netbsd.org sysutils/lsof 2 pkgsrc-us...@netbsd.org devel/libusb1 2 pkgsrc-us...@netbsd.org multimedia/fxtv2 pkgsrc-us...@netbsd.org devel/SOPE 1 pkgsrc-us...@netbsd.org Build failures There's nothing wrong with devel/libdbusmenu-qt or math/eigen2. The problem is that curl doesn't work in a chroot (I have no idea why) so the source tarball for those two packages didn't get fetched. You have to fetch them manually and then bulkbuild will happily build the packages. I really wish someone could tell me what the trick to use curl in a chroot is, it's really been biting me on both bulkbuild and tinderbox. John
Re: a couple of things I dislike about BSD
On 7/23/2012 02:39, Pierre Abbat wrote: 1. When I run bc, I frequently edit the previous line and make a change: 15/56 .26785714285714285714 a(15/56) .26171350240120506395 a(15/56)*45/a(1) 14.99507912917598589467 In Linux, I hit uparrow and edit the line. In DFBSD, I have to type the whole line again. This is, I'm sure, a license issue; the readline library in DFly is GNU readline. The bugs section says It’s too big and too slow, so why not write a BSD version that's smaller and faster? (The calculation relates to the upper slope of my future house's roof.) That's a shell configuration issue, not a readline issue. I edit previous commands just fine just as you suggest. Pick the right shell and set it up via the .profile/.??rc/ etc files and it will work as you want. 2. less in Linux saves the screen when it starts and restores it when it ends. In DFly it doesn't; it leaves a screenful of the file visible when it exits. I've seen this via SSH but it doesn't do it the console. I'm sure it's another config issue, but being lazy I just use cat and scroll backwards rather than taking the time to fix it. :) John
Re: seamonkey 2.10 from 2012Q2 pkgsrc build fails
On 7/20/2012 06:23, Edward M wrote: hello, trying to build seamonkey 2.10 from pkgsrc2012Q2 however, it fails with the following error: pkg_create: lstat failed for file lib/seamonkey/extensions/inpec...@mozilla.org/chrome/ icons/default/winInspectorMain.xpm: no such file or directory Error code 2 thanks Seamonkey generally builds on DragonFly, but a broken version must have gotten locked into the Q2 branch. Lately seamonkey 2.10 didn't pass PKG_DEVELOPER checks but it would have installed without them, but the seamonkey-l10n version was completely broken. Yesterday it got updated to 2.11, no idea yet if once again compiles on Dragonfly. Firefox has several versions: www/firefox which changes a couple time of month (currently on version 14), this is hit and miss www/firefox10 which is locked in at firefox v10 and should always work www/firefox36 which is locked in at firefox 3.6 and also aways works. There are -l10n versions of all of them that usually build if the non-l10n version builds. anyway, in general, Seamonkey builds on DragonFly, it just happened to be in a bad state for Q2. You can always switch to the trunk branch. John
Re: DragonFly GUI desktop at work - not bad at all
On 7/20/2012 17:12, Stéphane Russell wrote: Wojciech Puchar a écrit : despite of an error message at startup is working fine, as long as I'm not trying to configure it, since GConf is not working. just use windows manager like cwm or fvwm2+your own configuration. I for example use my 9 year old .fvwm2rc which results in cwm-alike environment. it's really easier to just run program you need (like openoffice writer, mail client, gimp etc.) instead of running bells and whistles like Gnome. I assume you need workstation (==computer to do actual work). Gnome nor XFCE nor KDE doesn't help in doing actual work. I always try to use Gnome whenever possible, and fall back to XFCE when it's not. It might be time to rethink that approach. The gnome library version numbers are all mismatched. Some are 2.24, others 2.26, others 2.32. Effectively they can't all be brought to the current level of glib2 due to the increasing amount of linux-only functionality there. The days of Gnome on non-Linux might be numbered, at least modern Gnome... On the flipside, KDE has been compiling completely and all the modules have matching versions numbers. Currently KDE 3.5 just lost regressed a module or two, but before that we had fully building KDE 3.5 and 4.8.x. XFCE has been building as well, but it's still on 4.6 John
Re: DragonFly GUI desktop at work - not bad at all
On 7/20/2012 20:53, Carsten Mattner wrote: On Fri, Jul 20, 2012 at 8:33 PM, Stéphane Russell Complaining is important, but contributing platform support patches (if you have the skills) would possibly be a better choice, wouldn't it? Besides that statement also applying to yourself, the answer is no. The BSD community simply will not accept the substandard replacements of BSD functionality that Linux is adding to gnome. In other words, the functionality is already on BSD, Linux people are reinventing the wheel, and coming up with a worse product. The BSD folks will just stick with what they have as it's better. That's one of the issues and no amount of patch skills is going to fix that. It's a philosophical difference. Lennart Poettering: BSD isn't relevant anymore http://bsd.slashdot.org/story/11/07/16/0020243/Lennart-Poettering-BSD-Isnt-Relevant-Anymore Slashdot sensationalism, but basically gnome doesn't care if it's BSD-friendly or not and it's diverging to the point of no compatibility.
Latest pkgsrc status -- as compared to May 27 status
I did a couple of pkgsrc bulk build runs this week. Recently the PKG_DEVELOPER checks got more stringent and a single package, help2man, caused 3500 package failures under the check! After cleaning up the big regressions, here's a report. I used the data in the report files to generate it, and it compares yesterday's run with one on May 27 to show which packages got added, which got fixed, and which suffered regressions. VLC 1.0 and VLC 1.1 are listed as regressions, but that's actually a pbulk resolve failure (the famous can't find digest error that we're told shouldn't happen but does on multiple machines maintained by different people. Libreoffice does fail in the bulk environment, but it will build outside of it. Some of the 50+ regressions we suffered was caused by a new zlib inport and affects all platforms. Others are also not-specific to DragonFly, but the majority are true regressions caused by package updates. Please contribute a fix if you can. The report itself should be self-explanatory. We're not far from 11,600 packages now; just fixing the regressions would put us over. Oh, packages that aren't available for i386 or DragonFly aren't included in the totals and neither are any downstream packages that depend on them. The top 5 are list at the Masked Packages breaking the most other packages section. There aren't any build logs publicly available yet; I need to write a script to compile the latest from all runs first. John pkgsrc bulk build report DragonFly 3.1/i386 Compiler: gcc Build start: 2012-07-16 08:19 Build end: 2012-07-16 23:14 Total number of eligible packages: 12097 Successfully built: 11568 Failed to build: 445 Depending on failed package:84 Total number of masked packages: 328 Depending on masked package:26 Packages breaking the most other packages Breaks LocationPackage --- 7 textproc/cabochacabocha-0.53 6 security/libpreludedb libpreludedb-0.9.15.3nb3 4 net/ocamlnetocamlnet-3.5.1 4 pkgtools/x11-links x11-links-0.70 3 filesystems/py-fuse-bindingspy27-fuse-bindings-0.2.1 3 mail/evolution evolution-2.32.3nb8 3 security/libpreludedb-pythonlibpreludedb-python-0.9.15.3nb4 3 sysutils/coreutils coreutils-8.13nb4 2 devel/libusb1 libusb1-1.0.9 2 graphics/kdegraphics3 kdegraphics-3.5.10nb20 2 lang/eieio eieio-0.17nb3 2 lang/gauche Gauche-0.9.3.3 2 lang/sun-jre6 sun-jre6-6.0.33 2 multimedia/fxtv fxtv-1.03nb19 2 multimedia/libflashsupport-pulselibflashsupport-pulse-20081219nb2 2 net/kdenetwork3 kdenetwork-3.5.10nb19 2 net/net6net6-1.3.10nb1 2 security/openvas-libnaslopenvas-libnasl-2.0.0nb4 2 sysutils/lsof lsof-4.84nb1 1 cad/sci-wcalc sci-wcalc-1.0nb3 1 converters/p5-MARC-Charset p5-MARC-Charset-1.33 1 databases/p5-DBD-Oracle p5-DBD-Oracle-1.23nb2 1 databases/py-ldap py27-ldap-2.4.9 1 devel/SOPE SOPE-2.0.0b3nb1 1 devel/emacs20-elib emacs20-elib-1.0nb3 1 devel/libFoundation libFoundation-1.1.7.168nb1 1 devel/p5-VCPp5-VCP-0.9beta20050110nb3 1 devel/sapnwrfcsdk sapnwrfcsdk-7.11 1 devel/semantic semantic-1.4.4nb1 1 editors/obbyobby-0.4.7nb1 1 games/simgear simgear-2.0.0nb9 1 graphics/camlimages camlimages-4.0.1nb10 1 graphics/kipi-plugins-kde3 kipi-plugins-0.1.7nb20 1 graphics/unicap unicap-0.9.3nb11 1 lang/SmartEiffelSmartEiffel-2.0nb1 1 lang/sun-jdk6 sun-jdk6-6.0.33 1 mail/evolution-exchange evolution-exchange-2.32.2nb9 1 mail/qpopperqpopper-4.1.0 1 math/octave-forge octave-forge-2006.03.17nb7 1 math/scilab scilab-4.1nb5 1 meta-pkgs/gnome gnome-2.26.2nb4 1 multimedia/libvalibva-1.0.6nb1 1 multimedia/mlt mlt-0.5.10nb9 1 multimedia/py-gstreamer0.10 py25-gstreamer0.10-0.10.22nb3 1 net/TransmissionTransmission-2.60 1 net/py-zmq py26-zmq-2.1.11 1 net/xymonclient
Re: Install problems
On 7/1/2012 15:07, Sascha Wildner wrote: On Sun, 01 Jul 2012 12:58:55 +0200, Jasse Jansson ja...@yberwaffe.com wrote: Hi. I'm trying to install dfly on two different computers right now and it's not going well. Case 1: A 6-7 years old laptop (ASUS A6Km) just got an Fatal trap 12 after a very long time exercising the cd drive. I think the install-o-meter was at 56% when it happened. The fault code says: supervisor write data, protection violation. I have a picture of the screen if anybody want it. Yeah, please put up the picture. Were you installing DragonFly 3.0.x with UFS (as opposed to HAMMER)? If so, that's a known UFS softupdates bug that still hasn't been completely fixed. The workaround is either to install from a latest snapshot (the current bug is unlikely to prevent installation from completing now) or better yet to turn off softupdates flag from the installer. John
Re: emulators/wine-devel builds on pkgsrc trunk (i386 only)
On 5/23/2012 19:54, John Marino wrote: I submitted a number of patches that allow WINE to build on an i386-DragonFly. I don't have a desktop set up on this machine yet, so I can't actually test it. If some user with an i386 setup has been looking forward to wine on DragonFly, it would be great if they could test it out and report back. Remember, it's emulators/wine-devel, not emulators/wine. John Sorry, the distinfo file was misgenerated, I'm not sure why. I committed a fix, but if you hit a checksum error trying to build wine then either pull the repo again to get the fix or bmake mdi to generate the distinfo yourself. John
emulators/wine-devel builds on pkgsrc trunk (i386 only)
I submitted a number of patches that allow WINE to build on an i386-DragonFly. I don't have a desktop set up on this machine yet, so I can't actually test it. If some user with an i386 setup has been looking forward to wine on DragonFly, it would be great if they could test it out and report back. Remember, it's emulators/wine-devel, not emulators/wine. John Module Name:pkgsrc Committed By: marino Date: Wed May 23 17:48:54 UTC 2012 Modified Files: pkgsrc/emulators/wine-devel: distinfo pkgsrc/emulators/wine-devel/patches: patch-ab patch-ac patch-ad Added Files: pkgsrc/emulators/wine-devel/patches: patch-dlls_kernel32_heap.c patch-dlls_ntdll_file.c patch-dlls_ntdll_nt.c patch-dlls_ntdll_server.c patch-libs_wine_ldt.c Log Message: emulators/wine-devel: Add DragonFly support I have no idea if this actually works, but at least it builds which was not the case before. To generate a diff of this commit: cvs rdiff -u -r1.18 -r1.19 pkgsrc/emulators/wine-devel/distinfo cvs rdiff -u -r1.1.1.1 -r1.2 pkgsrc/emulators/wine-devel/patches/patch-ab cvs rdiff -u -r1.3 -r1.4 pkgsrc/emulators/wine-devel/patches/patch-ac cvs rdiff -u -r1.6 -r1.7 pkgsrc/emulators/wine-devel/patches/patch-ad cvs rdiff -u -r0 -r1.1 \ pkgsrc/emulators/wine-devel/patches/patch-dlls_kernel32_heap.c \ pkgsrc/emulators/wine-devel/patches/patch-dlls_ntdll_file.c \ pkgsrc/emulators/wine-devel/patches/patch-dlls_ntdll_nt.c \ pkgsrc/emulators/wine-devel/patches/patch-dlls_ntdll_server.c \ pkgsrc/emulators/wine-devel/patches/patch-libs_wine_ldt.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
DragonFly pkgsrc policy for packages without freely or generally available sources
Pkgsrc will occasionally maintain packages in the repository that no longer have retrievable source tarballs and also legally restrict others from hosting copies of them. The justification is that some older users may still be in possession of the source tarballs, and the package is maintained for these very few people. Personally I disagree with this philosophy. Pkgsrc packages should be buildable by anyone as a minimum requirement for being a package, and if this capability is lost, I believe the package should be removed from pkgsrc once it's clear the capability will never be regained. Along the same vein, there are some packages that depend on sources that one has to purchase. I wouldn't be shocked if all of these only worked for NetBSD only. Since the unavailable packages aren't getting removed upstream, I'm going to mark them all NOT-FOR-DRAGONFLY. Currently this is less than 10 packages. The ones depending on commercially-purchased source tarballs will also be marked NOT-FOR-DRAGONFLY. For the vast majority of users, this will not affect you in the least (unless you run the bulk build script, then your life will improve). If you find yourself with sources to build one of these packages, you can simply comment out the NOT-FOR-PLATFORM+= DragonFly-*-* line in the Makefile before trying to build it. John
Re: DragonFly pkgsrc policy for packages without freely or generally available sources
On 5/19/2012 17:13, Justin Sherrill wrote: On Sat, May 19, 2012 at 8:29 AM, John Marinodragonfly...@marino.st wrote: Personally I disagree with this philosophy. Pkgsrc packages should be buildable by anyone as a minimum requirement for being a package, and if this capability is lost, I believe the package should be removed from pkgsrc once it's clear the capability will never be regained. Along the same vein, there are some packages that depend on sources that one has to purchase. I wouldn't be shocked if all of these only worked for NetBSD only. Syntactically, it bugs me, because NOT-FOR-PLATFORM usually indicates there's something wrong that keeps it from building on a given platform, and what this really is should be PROBABLY-WILL-NEVER-BUILD-ANYWAY. It's a fix that adds noise to the makefiles. However, I'm complaining about form, not purpose, so my complaint is irrelevant. It's the best compromise. NOT-FOR-PLATFORM builds won't even be attempted. These packages don't need to attempt to fetch every bulk pass and show as an error in the report. So it's actually the opposite of noise - it suppresses known issues. I'm not concerned with muddying up Makefiles on these packages. It's a standard line and I've commented WHY it exists with a link to this archive in every Makefile. John
Re: DragonFly pkgsrc policy for packages without freely or generally available sources
On 5/19/2012 15:08, Venkatesh Srinivas wrote: Just for reference, can you point of some/all of these packages? Thanks! -- vs; http://ops101.org/4k/ Hi Venkatesh, The following eight packages were masked: net/skype1 cad/simian cad/simian-docs sysutils/ipw-firmware sysutils/iwi-firmware sysutils/iwi-firmware3 sysutils/storage-manager * games/ultima4-online * The last two are manual fetch packages which are fine normally, but the source files are no longer available. The Return to Castle Wolfenstein game was on the list, but I fixed the package by updating the MASTER_SITE. John
Re: DragonFly pkgsrc policy for packages without freely or generally available sources
On 5/20/2012 04:19, Pierre Abbat wrote: On Saturday 19 May 2012 12:00:31 John Marino wrote: On 5/19/2012 15:08, Venkatesh Srinivas wrote: Just for reference, can you point of some/all of these packages? Thanks! -- vs; http://ops101.org/4k/ Hi Venkatesh, The following eight packages were masked: net/skype1 There's also a skype21 package. Is that available for DragonFly? Pierre Yes. Nobody can fetch the source for skype1. Skype removed it from their servers and won't allow anyone else to host it. Everybody can fetch the source for skype21. Therefore it's not masked. John
Re: HEADS UP: comconsole breakage on master
On 5/14/2012 15:43, Sepherosa Ziehau wrote: On Mon, May 14, 2012 at 4:22 PM, Sepherosa Ziehausepher...@gmail.com wrote: Hi all, For master users that use comconsole, please DO NOT upgrade your system beyond following commit: 52f9ffcfb1a0e8fc03e584cd8ef8f66b7f71f884 Some commits between master and above commit could leave your comconsole blank after upgrading. We are working on a fix, hopefully it will be working again soon. As of 8c4a123d231777a281ec4eb6dd40d5a8f4ab9d47 The comconsole is fixed. Please feel free to upgrade; make sure to use make buildworld Best Regards, sephe Please use commit 6b7d23fca80545bf9326d16e4ad4821ae39c7c46 as the minimum commit to jump to instead. This addresses a possible broken world caused by a missing ncursesw (wide character) library. Regards, John
Re: dbsdlog takes ridiculously long time to load
On 4/5/2012 10:58, elekktrett...@exemail.com.au wrote: While inspecting the html code to see whats causing it to load for about 3 minutes i found this - iframe allowtransparency=true frameborder=0 scrolling=no src=http://platform.twitter.com/widgets/tweet_button.html?url=http%3A%2F%2Fwww.shiningsilence.com%2Fdbsdlog%2F2012%2F03%2F28%2F9471.htmlamp;counturl=http%3A%2F%2Fwww.shiningsilence.com%2Fdbsdlog%2F2012%2F03%2F28%2F9471.htmlamp;count=horizontalamp;text=ldconfig%20search%20path%20change: style=width:97px; height:20px;/iframe on every post on the page. This is causing slowdowns in both IE and Chrome, but particularly chrome. Petr I assume it's a temporary problem with Twitter but in any case the dbsdlog belongs to Justin Sherrill so it's best to contact him directly. (As an aside, since I never got caught up in Twitter I wouldn't be upset if the Twitter stuff were just removed outright). John
Re: Fwd: Single boot EFI Mac install
On 3/24/2012 02:48, peeter (must) wrote: Thanks, this is very interesting. Could you describe your boot setting, i.e. did you use GPT or MBR? Did you put /boot partition in a separate GPT/MBR partition or was it in a big bsd slice? What filesystem did DragonFly have? I started with MBR, and then I converted it to GPT using gdisk which was a bad idea. It may have worked if I started with a GPT formatted disk, but I got a missing-bios flag error message before the conversion. Using bad advice from the internet, I added this flag to a partition using gparted and proceeded to lose all the data in that partitions. Oops. I guess I ended up at the same place with grub-1.99. I created bootx64.efi image (btw, my mbpro5,5 has 64bit EFI, so 32bit efi did not work) and blessed it; and EFI-boot to grub2; and grub2 could list the file contents of FreeBSD partitions in the grub2 shell, but no kfreebsd /loader or kfreebsd /kernel/kernel worked. Actually, the latter was most promising in the sense that it did not produce an error message; it went off and hang. I also tried to see if grub2 recognizes any DragonFly partitions. I cheated a little; I created GPT partitions with FreeBSD's gpart which labels them freebsd ufs; then disklabel64-d with DragonFly and newfs (ufs). Now grub2 saw directories as files; it seemed it has the same understanding of DragonFly's ufs as FreeBSD---which thought they're a little corrupted. So it seems to me that grub2 does not even correctly identify files on a DragonFly filesystem and then also can't find or boot them. Maybe that's the source of the unrecognized signature that I was seeing. I agree, there's nothing to suggest that grub2 can handle DragonFly out of the box. To be fair, FreeBSD people were getting the same message. Do you know if grub-legacy handles gpt partitions? Peeter I don't know, I'm sorry. My grub knowledge is very limited. John
Re: Fwd: Single boot EFI Mac install
On 3/22/2012 00:29, peeter (must) wrote: I wonder if there's a way to make refit recognize how to boot from the dfly ufs partition? I was browsing around to find if grub2 might work but haven't found the right .efi image yet. mjg59.livejournal.com is a good read! Peeter -- Hi Peeter, This may be unrelated, but I spent a lot of last weekend trying to get DragonFly to boot from grub2 v1.99 and only got an unrecognized signature for my efforts. No amount of tweaking fixed this, not chainloading, not direct kernel loading, etc. Finally I did the only thing that others (people with similar issues with grub2) had success with: downgrade grub2 to grub-legacy. That also worked for me. John
Re: pkgsrc current DragonFly 3.1/x86_64 2012-03-20 02:35
On 3/23/2012 1:46 PM, Justin Sherrill wrote: pkgsrc bulk build report DragonFly 3.1/x86_64 Compiler: gcc Build start: 2012-03-20 02:35 Build end: 2012-03-23 10:18 Full report: http://avalon.dragonflybsd.org/reports/x86_64/bleeding-edge/20120320.0235/meta/report.html Machine readable version: http://avalon.dragonflybsd.org/reports/x86_64/bleeding-edge/20120320.0235/meta/report.bz2 Total number of packages: 12376 Successfully built: 11084 Failed to build: 391 Depending on failed package: 357 Explicitly broken or masked: 499 Depending on masked package:45 Packages breaking the most other packages Package Breaks Maintainer - databases/postgresql84-client127 a...@netbsd.org textproc/rasqal 55 mki...@netbsd.org sysutils/libgtop 22 pkgsrc-us...@netbsd.org www/ruby-actionpack3 18 pkgsrc-us...@netbsd.org print/a2ps13 pkgsrc-us...@netbsd.org devel/ruby-activesupport3112 pkgsrc-us...@netbsd.org x11/kde-workspace4 9 ma...@netbsd.org databases/ruby-dm-types9 pkgsrc-us...@netbsd.org devel/ruby-activesupport32 9 pkgsrc-us...@netbsd.org net/bind99 7 pkgsrc-us...@netbsd.org Build failures textproc/rasqal is non-dragonfly issue, already fixed on march 20 x11/kde-workspace4 is not a real error, something happened to the bulk build I'll look at pg84-client John
Re: pkgsrc current DragonFly 3.1/x86_64 2012-03-14 16:32
On 3/20/2012 03:22, Justin Sherrill wrote: lang/ruby193-base is I thought fixed in pkgsrc-current, so either I had an older flavor of pkgsrc-current downloaded when I started this, or I screwed up. pkgsrc bulk build report DragonFly 3.1/x86_64 Compiler: gcc Build start: 2012-03-14 16:32 Build end: 2012-03-20 01:34 The fix was made Thu Mar 15 08:35:24 2012 UTC, so if the build time is accurate, it was started before the ruby193 fix. There might be extra time needed to propagate to CVS (Git?) mirrors as well. John
Re: cross-Compiling DFBSD on an Ubuntu machine.
On 3/11/2012 19:14, karim.allah.ah...@gmail.com wrote: I've an Ubuntu machine ( oneiric ), Is it possible to cross-compile DFBSD ? Thanks. -- Karim Allah Ahmed. LinkedIn http://eg.linkedin.com/pub/karim-allah-ahmed/13/829/550/ What is it exactly that you want to cross-compile? The userland? The kernel? Or just some program that can run DragonFly? The basic answer is that yes it's possible, but cross compiling is not particularly easy to set up (in general, applies to all systems). I don't know what you are trying to accomplish though. John
Re: dfly kvm
On 3/6/2012 17:35, Andrey N. Oktyabrski wrote: Good day. Today I tried to update 2.10 to 3.0 on my VPS. 3.0 do not boot. Have anybody tested dfly on kvm? Is it possible to update, or I must use 2.10 there? DFly 3.0.1 (i386) wouldn't boot on virtualbox until VT-x extensions were enabled (APIC-caused panic). You didn't provide details of do not boot, so it would be hard to speculate what the issue is and if there is a workaround. I was told x86_64 has different APIC so maybe you could try that if you tried i386 before. John
Re: pid (conftest), uid 0: exited on signal 11 (core dumped) on 3.0 stable
On 3/1/2012 11:38 AM, Siju George wrote: Hi, I just complied from DragonFly_RELEASE_3_0 and I am running 3.0-RELEASE DragonFly v3.0.1.2.g19b92-RELEASE #3: Thu Mar 1 13:18:23 IST 2012. I get these messages pid 63230 (conftest), uid 0: exited on signal 11 (core dumped) pid 73438 (conftest), uid 0: exited on signal 11 (core dumped) pid 81398 (conftest), uid 0: exited on signal 11 (core dumped) pid 91564 (conftest), uid 0: exited on signal 11 (core dumped) pid 93541 (conftest), uid 0: exited on signal 11 (core dumped) pid 93611 (conftest), uid 0: exited on signal 11 (core dumped) Why is it? Where do I look for the coredump in this case? Thanks Were you building pkgsrc packages? If so, just ignore these. Occasionally during the configure phase, a configure test results in a segfault. It's pretty harmless. And there aren't any core dumps to see. (strangely, running the same test outside of the autotools doesn't coredump). John
Re: 3.0 release this weekend
On 2/17/2012 6:38 AM, Samuel J. Greear wrote: I don't know if it [KDE] installed completely in 2.10, come to think of it. The KDE versions in pkgsrc are grossly out of date. Users should actually have better luck compiling newer KDE version by hand from the KDE repo's directly, because of work Alex H. did getting DragonFly patches into upstream. Sam I fixed all the broken KDE3 packages before the Q4 branch. All of them should build now. Whether they work or not is a different story, but they should. The reason they are still broken on bulkbuild was they were a casualty of the DSO binutils 2.22 issue (esound), and the pkgsrc build box had (or still has) some sort of permissions problem that shows up in the install stage of some packages (mainly ruby-based ones). John
Re: pkgsrc: multimedia/handbrake
On 1/31/2012 4:48 PM, Tim Darby wrote: The build of handbrake fails as shown below. What do I need to do to get this working? A lot. You need to: bmake clean bmake patch then go into the work directory and figure out why HB_NORMAL_PRIORITY isn't defined. The normal cause of these things is that DragonFly isn't recognized in the configuration or the cpp macros and header includes/definitions don't get made. Sometimes the package is very system-specific and just isn't supported by anything other than NetBSD. You will be troubleshooting a broken package and this can take quite some time. After you've identified the cause you can create a patch (or update an existing patch if the file is question is already patched), and open a PR with your patch. http://www.netbsd.org/support/send-pr.html If you fix it, tell me the PR number and I'll claim it and try to get the fix into pkgsrc permanently. John
Re: error compiling kernel
On 1/18/2012 12:06 AM, Pierre Abbat wrote: I did make -j 2 buildworld and make -j 2 buildkernel. The kernel and world I'm currently running are dated August 19. Pierre Are you running with a custom kernel config? If so, try using the provided generic one. I completely built world and kernel 2 days ago without issue. John
Re: freezes on Powering system off using ACPI
On 12/29/2011 4:32 AM, Edward Martinez wrote: Hello, When I execute shutdown -p now to turn off DragonFLyBSD, it freezes right after syncing disks, done, uptime, on Powering system off using ACPI. I need to hold the power button to turn the system off. I'm using DragonFly v2.13.0.733.gd7f53-DEVELOPMENT. Thanks for your help It's an annoying, long-standing bug that apparently isn't high-visibility enough to get any attention: http://bugs.dragonflybsd.org/issues/2167 http://bugs.dragonflybsd.org/issues/2232 I would fix it if I could. John
Re: w3m / boehm-gc issue (really is getcontext in x86_64)
On 2010-07-30 Markus Pfeiffer wrote: On 2010-07-06, Matthew Dillon dil...@apollo.backplane.com wrote: :Dear all, : :I started using dragonfly not too long ago. I wanted to build w3m from :pkgsrc on x86_64. Configure failed in a check for libgc, which is installed. :I found out that libgc uses getcontext (and assumes it to exist) which it :doesn't on x86_64 dragonfly. :To fix boehm-gc + w3m, I just inserted a defined(__DragonFly__) into mach_deps.c :Would it be a good idea to port the i386 version of getcontext into x86_64? I :am willing to do that, then. : :Markus Yes, it would be a good idea! I didn't even realize that we did not have a getcontext() implementation for x86_64 in libc. It looks fairly straight-forward if you are familiar with x86_64 argument passing. If you have questions you can ask them here or on irc. Heya, Just to keep everyone updated on the matter: It took me longer than expected to get it working (mainly due to the fact that I am running dfly in a VM at the time which does not do make quickworld very quickly.) I think I have a working getcontext now, I will implement setcontext as well and then submit a patch. I would then appreciate testing and someone to look at it whether there is nothing massively broken (I believe get_mcontext was broken as well). Markus I can't find any follow up. Did this effort die? This issue comes up repeatedly for x86_64: http://bugs.dragonflybsd.org/issues/2108 http://bugs.dragonflybsd.org/issues/2179 Numerous packages won't build on x86_64 because of this missing functionality, including ruby193-based packages and anything depending on boehm-gc. I consider this a must-fix issue before the next release. I am not comfortable creating this feature myself. It would be great if somebody who is qualified to do it start working in earnest on it as pkgsrc 2011Q4 freeze is almost here. This has been discussed many times in IRC but in the end nothing is getting done. None of the IRC talk is making it back to bugs either. 18 months has gone by since this thread started... John
Re: Lilypond wants FlexLexer
On 12/8/2011 5:37 AM, Pierre Abbat wrote:
On Tuesday 06 December 2011 13:48:57 John Marino wrote:
Just apply this patch to print/lilypond/Makefile:
I tried that and got this error:
bmake
bmake: ../../mk/tools/../../mk/tools/replace.mk line 153: Malformed
conditional ((${_TOOLS_DEPMETHOD.flex} == BUILD_DEPENDS)
defined(_TOOLS_DEPMETHOD.lex))
bmake: Fatal errors encountered -- cannot continue
bmake: stopped in /usr/pkgsrc/print/lilypond
Pierre
Pierre,
as a follow-up, the correct solution would have been to bmake clean
before bmake. The old toolset was cached and that was the source of
the error.
You should remove your modification to replace.mk.
Regards,
John
Diagnosing our recent failed bulk builds
The last good bulk build run for x86_64 current was Oct 28. Since then two more runs have been performed resulting in thousands of failed packages reported. They were caused by failures at the checksum phase where *sometimes* the bulk build script could not find the digest. One checksum failure can cascade to hundreds of packages (see math/pari). It's likely that something about the bulk build setup has changed since Oct 28. I read somewhere that Justin was using NFS to access the pkgsrc directory. Is that the setup being used here? If so, when was it set up like this? Can we use rsync to make a local copy of the latest pkgsrc on each build box and take NFS out of the equation? NFS issues could explain why sometimes the bulkbuild can access the digest folder and sometimes it can't. There should be a significant improvement since the Oct 28 build report on both platforms. It would be nice to figure out exactly what broke with the bulk builds and get some updated reports here soon. John
Re: Lilypond wants FlexLexer
On 12/8/2011 5:37 AM, Pierre Abbat wrote:
On Tuesday 06 December 2011 13:48:57 John Marino wrote:
Just apply this patch to print/lilypond/Makefile:
I tried that and got this error:
bmake
bmake: ../../mk/tools/../../mk/tools/replace.mk line 153: Malformed
conditional ((${_TOOLS_DEPMETHOD.flex} == BUILD_DEPENDS)
defined(_TOOLS_DEPMETHOD.lex))
bmake: Fatal errors encountered -- cannot continue
bmake: stopped in /usr/pkgsrc/print/lilypond
Pierre
Then update mk/tools/replace.mk
http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/mk/tools/replace.mk
The patch is good and has been committed. The replace issue is a
separate one.
John
Re: Lilypond wants FlexLexer
On 12/8/2011 8:44 PM, Pierre Abbat wrote:
On Thursday 08 December 2011 14:11:25 John Marino wrote:
Pierre, I'm seeing a similar message regarding gsed. Were you still on
the 2011Q3 branch when you got your message?
John
Yes. But I still can't compile it even when I replace replace.mk. And the fix
doesn't appear to be in master. I guess I'll wait till Q4 comes out.
Pierre
Are you really going to give up so easily after you got lilypond fixed?
At least find replace make and put double quotes around the flex
variable, e.g.
FROM: ((${_TOOLS_DEPMETHOD.flex} == BUILD_DEPENDS)
TO: ((${_TOOLS_DEPMETHOD.flex} == BUILD_DEPENDS)
Just to get past the error.
Re: Lilypond wants FlexLexer
On 12/8/2011 11:29 PM, Pierre Abbat wrote: On Thursday 08 December 2011 15:11:45 John Marino wrote: Are you really going to give up so easily after you got lilypond fixed? I didn't get lilypond fixed. I have another box with lilypond on it, so it's not urgent. Pierre you got lilypond fixed is another way of saying I gave you the patch to fix it You've got the patch. I told you how to work around the replace.mk problem. I can't help more than that, you should have everything you need assuming there are no other issues with 2011Q3. John
Re: sharing files between DF guest and Win host in VirtualBox
On 12/9/2011 12:48 AM, sweepslate wrote: On 12/5/2011 10:04 PM, John Marino wrote: If you just want to transfer a few files in and out, the easiest way is through ftp through ssh (e.g. http://www.bitvise.com/tunnelier). You didn't specify what you were trying to achieve. For my purposes, Tunnelier works great when I'm using DragonFly in a Windows-hosted Virtualbox. This sounds one nice. Or a Samba/SMB share. However, in the meantime, I just noticed that DF can't access the Internet. This is an issue I need to take in a VBox forum. Thanks guys! I swear to you that DF in vbox has no problems accessing the internet. I always use the bridge interface so outside machines can find Dfly in vbox.
Re: Lilypond wants FlexLexer
On 12/9/2011 2:50 AM, Pierre Abbat wrote: On Thursday 08 December 2011 17:42:36 John Marino wrote: you got lilypond fixed is another way of saying I gave you the patch to fix it You've got the patch. I told you how to work around the replace.mk problem. I can't help more than that, you should have everything you need assuming there are no other issues with 2011Q3. I have compiled it. Thanks and sorry for the misunderstanding. Pierre Great!
Re: Lilypond wants FlexLexer
On 12/6/2011 3:27 PM, Pierre Abbat wrote:
On Monday 05 December 2011 20:27:44 John Marino wrote:
I committed fixes for both Lilypond and kdesdk3. The pkgsrc-current
should build now.
The last two commits I see are to devel/opal and a very short change to the
list of changes. I'm on 2011Q3 and don't see a branch called pkgsrc-current.
Do I switch to master, or do I have to do something else?
Pierre
2011Q3 is a branch, -current is the head of pkgsrc (bleeding edge).
Just apply this patch to print/lilypond/Makefile:
--- Makefile.orig 2011-12-06 18:41:16.069151000 +0100
+++ Makefile2011-12-06 19:28:43.86175 +0100
@@ -16,7 +16,7 @@
GNU_CONFIGURE= YES
USE_PKGLOCALEDIR= YES
USE_LANGUAGES= c c++
-USE_TOOLS+=bison flex gmake gs:run makeinfo perl pkg-config msgfmt
+USE_TOOLS+=bison gmake gs:run makeinfo perl pkg-config msgfmt
USE_TOOLS+=texi2html
MAKE_FILE= GNUmakefile
@@ -42,6 +42,13 @@
# 1.7 coredumps when generating eps files
DEPENDS+= potrace=1.8:../../graphics/potrace
+.if ${OPSYS} == DragonFly
+CONFIGURE_ENV+= LEX=${PREFIX}/bin/flex
+.include ../../devel/flex/buildlink3.mk
+.else
+USE_TOOLS+= flex
+.endif
+
.include ../../devel/pango/buildlink3.mk
.include ../../fonts/fontconfig/buildlink3.mk
.include ../../lang/guile/buildlink3.mk
Re: Lilypond wants FlexLexer
On 12/5/2011 2:46 PM, Jeremy C. Reed wrote: On Sat, 3 Dec 2011, Pierre Abbat wrote: Didn't work. I verified that FlexLexer.h is present: /usr/include/c++/FlexLexer.h /usr/pkg/include/FlexLexer.h /usr/pkg/include/freehdl/FlexLexer.h /usr/pkgsrc/devel/flex/work/flex-2.5.35/FlexLexer.h /usr/src/usr.bin/lex/FlexLexer.h Well it looks like it was not tested correctly or something else is wrong. After using that include you should probaly also have: /usr/pkgsrc/print/lilypond/work/.buildlink/include/FlexLexer.h Where's pngtopnm? I didn't find it in pkgin or pkgsrc or anywhere else. graphics/netpbm package It seems that kdesdk3 is not building due to the same flexLexer.h problem. If/when I solve it for kdesdk3, I'll try to apply the same fix for lilypond. John
Re: sharing files between DF guest and Win host in VirtualBox
On 12/5/2011 6:34 PM, sweepslate wrote: I'm giving DragonFly a try, inside VirtualBox. The host OS is Windows XP 32-bit. I want to share files between host and guest. How do I go about this? If you just want to transfer a few files in and out, the easiest way is through ftp through ssh (e.g. http://www.bitvise.com/tunnelier). You didn't specify what you were trying to achieve. For my purposes, Tunnelier works great when I'm using DragonFly in a Windows-hosted Virtualbox. John
Re: Lilypond wants FlexLexer
On 12/5/2011 8:45 PM, John Marino wrote: On 12/5/2011 2:46 PM, Jeremy C. Reed wrote: On Sat, 3 Dec 2011, Pierre Abbat wrote: Didn't work. I verified that FlexLexer.h is present: /usr/include/c++/FlexLexer.h /usr/pkg/include/FlexLexer.h /usr/pkg/include/freehdl/FlexLexer.h /usr/pkgsrc/devel/flex/work/flex-2.5.35/FlexLexer.h /usr/src/usr.bin/lex/FlexLexer.h Well it looks like it was not tested correctly or something else is wrong. After using that include you should probaly also have: /usr/pkgsrc/print/lilypond/work/.buildlink/include/FlexLexer.h Where's pngtopnm? I didn't find it in pkgin or pkgsrc or anywhere else. graphics/netpbm package It seems that kdesdk3 is not building due to the same flexLexer.h problem. If/when I solve it for kdesdk3, I'll try to apply the same fix for lilypond. John I committed fixes for both Lilypond and kdesdk3. The pkgsrc-current should build now.
Re: Lilypond wants FlexLexer
On 12/4/2011 5:40 AM, Pierre Abbat wrote: On Saturday 03 December 2011 21:01:28 Jeremy C. Reed wrote: On Sat, 3 Dec 2011, Pierre Abbat wrote: ERROR: Please install required programs: FlexLexer.h (flex package) flex-2.5.35nb2 = Fast clone of lex(1), the lexical scanner generator Maybe the lilypond/Makefile needs near end: .include ../../devel/flex/buildlink3.mk (make clean first before trying again) Didn't work. I verified that FlexLexer.h is present: /usr/include/c++/FlexLexer.h /usr/pkg/include/FlexLexer.h /usr/pkg/include/freehdl/FlexLexer.h /usr/pkgsrc/devel/flex/work/flex-2.5.35/FlexLexer.h /usr/src/usr.bin/lex/FlexLexer.h Where's pngtopnm? I didn't find it in pkgin or pkgsrc or anywhere else. Pierre You might want to try adding USE_TOOLS+= flex somewhere in the makefile (and remove the buildlink3 link that you added). No guarantees though, I didn't try this myself. John
Re: Core Dump fault virtual address on DragonFly v2.13.0.154.g481b38-DEVELOPMENT
On 11/15/2011 9:05 AM, Siju George wrote: On Tue, Nov 15, 2011 at 1:03 PM, John Marinodragonfly...@marino.st wrote: BTW, that's not really a useful message. The useful message is in the file /var/crash/core.text.X where X is the crash number of the saved dump. Look in there for the 1-2 line text that more descriptively describes the panic. Ok Thanks :-) I have uploaded the whole core dump files to the account that matt gave me on the leaf server. --Siju --Siju As you said before, but that's like having a thick book with a blank cover. If you want somebody to read the book before the others, you entice them with an interesting title (e.g. interesting panic message). Otherwise it's going to get at the end of the queue with everything else if it doesn't stand out. John
Fwd: Re: Core Dump fault virtual address on DragonFly v2.13.0.154.g481b38-DEVELOPMENT
(forward to list) On 11/15/2011 7:51 AM, Siju George wrote: Hi, I didn't receive any response to the core dump message i sent yesterday. Should i be sending these messages to bugs instead? please let me know. I have put the coredump at leaf:/home/sgeorge/crash/Coredump2015.tbz My kernel version is DragonFly v2.13.0.154.g481b38-DEVELOPMENT These Core dumps does not happen every time. Now I have removed a 512 MB RAM from the machine and I have got the system up now and I am upgrading to the latest src. Thanks --Siju The core dump message was The devs are very busy with MP performance development (see gitweb for all recent kernel modifications) and probably nobody has had time to even look at this. BTW, that's not really a useful message. The useful message is in the file /var/crash/core.text.X where X is the crash number of the saved dump. Look in there for the 1-2 line text that more descriptively describes the panic. P.S. I can't help you, but people are reading this list. John
Re: Is anyone still using gcc 4.1 on master?
On 11/7/2011 3:05 PM, Venkatesh Srinivas wrote: kaffe (from pkgsrc) seems to need gcc 4.1 to build correctly... -- vs; I would think that's either a problem with kaffe or a problem with the gcc44 compiler. If it's the latter, the gcc44 compiler should be fixed rather than use kaffe as a reason to maintain gcc41.
Re: Is anyone still using gcc 4.1 on master?
On 11/7/2011 8:03 PM, Samuel J. Greear wrote: pcc is not a candidate. Sorry, I disagree, although I understand if you aren't going to be the one to port it. Sam I don't understand that sentence. Are you saying you or somebody else is going to port pcc into base? A compiler that don't do c++?
Re: Is anyone still using gcc 4.1 on master?
On 11/8/2011 7:10 AM, joris dedieu wrote: 2011/11/8 Juan Francisco Cantero Hurtadoi...@juanfra.info: On 11/07/2011 10:50 PM, Samuel J. Greear wrote: Our C++ dependencies would not be that difficult to overcome and I do not see why the system compiler should necessarily have to support pkgsrc directly. What C++ software or dependencies has DragonFly? I'm curious. At least devd(8), Joris -- Juan Francisco Cantero Hurtado http://juanfra.info groff and gold linker are two more. Tangential to the discussion of the lack of stated and current project goals, it's not a stated goal that DragonFly have a C-only base, nor that the virtue of simplicity is more valued over performance to the point of eliminating useful functionality. As Samuel alluded, that's what he thinks is best. I'm in the other camp and actually favor a system compiler capable of more languages. John
Re: skype missing
On 11/4/2011 5:43 AM, Pierre Abbat wrote:
200 Switching to Binary mode.
250 Directory successfully changed.
250-If you're looking for one of the FreeBSD releases, please look in the
250-releases/${ARCH}/${RELNAME} directory, where ARCH = alpha, amd64,
250-i386, ia64, pc98, or sparc64 and RELNAME = the release
250-you're interested in, e.g. 7.1-RELEASE or 8.0-RELEASE.
250 Directory successfully changed.
250 Directory successfully changed.
local: skype_static-1.4.0.118-oss.tar.bz2 remote:
skype_static-1.4.0.118-oss.tar.bz2
It doesn't appear to be DragonFly specific (in other words, it a pkgsrc
problem)
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44913
It's kind of absurd that nobody has looked at this since the PR was
written in april.
If you tell me where this file is available locally, I'll commit a fix
to the package.
Probably the ftp server rearranged it's directories and broke the package
John
Re: CPAN Cannot Guess build type.
On 10/31/2011 10:01 AM, Alex Hornung wrote: It is already telling you how to fix it: update your config.guess. Cheers, Alex On 31/10/11 08:25, Siju George wrote: Hi, I got the following error trying to install File::RsyncP on 2.13-DEVELOPMENT DragonFly v2.13.0.76.g0a4d48-DEVELOPMENT How do I fix it? Thanks Or pass --build=i386-pc-dragonfly2.13 to the configuration script so it doesn't have to guess.
Re: pkgsrc current DragonFly 2.11/x86_64 2011-09-17 01:22
On 9/26/2011 3:33 PM, Justin Sherrill wrote: I finally got a build of pkgsrc-current done; this was on x86_64. The number 1 break is databases/postgresql84-client, from a packaging error. I should have a new report in a few days since this initial build is complete. Justin, I just pulled in pkgsrc-current and built postgresql84-client on x86_64, and then followed that with bmake package. Everything worked fine. Those files declared missing from the bulk-build were there, and the package built without issue. FYI, there were two additional commits to this postgresql84 since I committed to it, and one of them had to do with the locale location. That commit was done on sept. 20, so you probably have it. I doubt it's the problem, but I thought I would mention it. This bulk-build represents pkgsrc-current on which date? Also, was this bulk-build done with a single job or multiple jobs? Thanks, John P.S. I was able to build heirloom-libcommon without incident as well, so I suspect this is a multiple-job issue again.
Re: pkgsrc current DragonFly 2.11/x86_64 2011-09-17 01:22
On 9/26/2011 8:49 PM, Justin Sherrill wrote: This build started on the 17th, so I wouldn't have any additions newer than that for postgresql84-client. The Build start line tells you when this kicked off, which will be within a few minutes of when pkgsrc was downloaded for the build. I don't see any recent updates since 04/22 when I look at that, though: http://cvsweb.se.netbsd.org/cgi-bin/bsdweb.cgi/pkgsrc/databases/postgresql84-client/ Am I looking in the wrong space? Yes. the package /databases/postgresql84 holds the patches used by the subpackages, including postgresql84-client. John
Re: Streamline pkgsrc issues: DragonFly developer gained NetBSD commit privilege
On 9/12/2011 9:22 AM, Francois Tigeot wrote: On Sun, Sep 11, 2011 at 09:21:58PM -0400, Justin Sherrill wrote: From what I've seen in the Problem Report system, there's a 'dfly-pkg-people' alias that DragonFly issues get placed with; if you are in that group, you'll probably catch things directly. The pkgsrc people are usually very quick to act. The only exception I've found is this dfly-pkg-people@ alias Once a PR is assigned to it, you can abandon all hope it will be fixed. It would be best to remove this alias IMHO. I don't know if I'd use the word usually. Like most things in life, it likely depends on who is involved. If you have already dealt with a specific maintainer who reacts quickly, then it's appropriate to keep working through him. However it can take a while for a PR to even get assigned, and then the maintainer may sit on it indefinitely without any communication. If it's just a simple patch, and especially if it's highly-used package, it might be more efficient to ping me instead. I think the dfly-pkg-people idea was probably okay in theory, but it doesn't sound like it's been too successful so far. John
Streamline pkgsrc issues: DragonFly developer gained NetBSD commit privilege
Hi @users, With all my work upgrading gcc, binutils, rtld, and ELF handling, I was invited to become a DragonFly developer earlier this year, which I was honored to accept. A couple of months ago, the NetBSD foundation extended a similar offer to me based on my work with Ada packages and pkgsrc fixes. It was a much more strict and time-consuming application process, but I was granted a commit bit for NetBSD last week. I've already put that privilege to good use to fix long-standing breakage with the postgresql 8.3 and 8.4 client packages. This situation should allow DragonFly pkgsrc breakage to be fixed more quickly than maybe it has been in the past. DragonFly users should still use the NetBSD Problem Report system (http://www.netbsd.org/support/query-pr.html) to report issues with DragonFly packages, and hopefully provide a patch to fix them. However, after they report the issue, send me an email with the PR number listed, and I'll try to get the fix in the system quickly. Again, I'm really talking about the situations where a patch has been created, and not particularly where the package broken for reasons not yet known. -- John
Re: pkgsrcv2.git not syncing correctly; around 400 missing files
On 7/25/2011 9:07 PM, Matthew Dillon wrote: Ok, I upgraded rsync to the latest version and it appears to work now. I think it might have been a protocol incompatibility between the older rsync crater was running (2.something) verses the current version 3.0.8. I will manually run the pkgsrc updating script, please check in about an hour to see if the repo has been corrected. -Matt Hi Matt, It looks much better now. All the MISSING files have been restored. There are still some DIFF files making it through the script. I increased the regex to filter out $Revision[:$] and $Date[:$] as well as $Id[:$] and $NetBSD[:$], and the attached file shows what is left. The remaining files on the list feature the $Log$ CVSID and others, so the git pkgsrc repository looks 100% synchronized to me! John DIFF:archivers/libarchive/files/contrib/libarchive.spec DIFF:archivers/libarchive/files/contrib/libarchive.1aix53.spec DIFF:archivers/libarchive/files/build/windows/mvcpp.nt DIFF:archivers/libarchive/files/build/windows/wccpp.nt DIFF:graphics/vcg/files/globals.h DIFF:sysutils/munin-node/files/node/node.d.netbsd/df_inode.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/cpu.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/df.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/if_errcoll_.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/forks.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/if_.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/interrupts.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/iostat.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/iostat_ops.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/irqstats.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/load.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/memory.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/memory_pools.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/memory_types.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/netstat.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/nfs_client.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/nfsd.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/open_files.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/processes.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/sensors_.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/swap.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/uptime.in DIFF:sysutils/munin-node/files/node/node.d.netbsd/vmstat.in
pkgsrcv2.git not syncing correctly; around 400 missing files
I have been using pkgsrc from our git mirror (pkgsrcv2), but I recently noticed some patches were missing as it caused me to submit a bad patch to pkgsrc while fixing multimedia/xine-lib port, and since then I've found many missing files. I pulled pkgsrc via CVS and created a script to compare both repositories. I had to tell diff to ignore differences that we caused by CVSID tags (e.g. $NetBSD$ and $Id$) because for some reason these CVSIDs were the only difference in hundreds of files. The result is attached. 367 files are shown as missing and the remaining 36 are shown as different. At the very least, this report could be used to manually sync pkgsrcv2.git, but it appears something systematic is amiss due to the large number of missing patches. Hopefully this can be fixed? Regards, John DIFF:archivers/libarchive/files/contrib/libarchive.spec DIFF:archivers/libarchive/files/contrib/libarchive.1aix53.spec DIFF:archivers/libarchive/files/build/windows/mvcpp.nt DIFF:archivers/libarchive/files/build/windows/wccpp.nt MISSING: audio/libsndfile/patches/patch-aa MISSING: audio/libsndfile/patches/patch-ab MISSING: audio/libsndfile/patches/patch-ac MISSING: audio/pulseaudio/patches/patch-src_pulsecore_svolume_mmx.c MISSING: comms/libopensync/patches/patch-af MISSING: converters/qrencode/patches/patch-libqrencode.pc.in MISSING: databases/qdbm/patches/patch-ak MISSING: databases/sqlitebrowser/patches/patch-sqlitebrowser_sqlbrowser__util.c MISSING: devel/atk/patches/patch-aa MISSING: devel/atk/patches/patch-ab MISSING: devel/liboil/patches/patch-ae MISSING: devel/roundup/patches/patch-setup-py MISSING: devel/xulrunner/patches/patch-security_nss_cmd_shlibsign_sign.sh MISSING: devel/xulrunner/patches/patch-toolkit_toolkit-tiers.mk MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_platform__file__posix.cc MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_debug__util__posic.cc MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_file__util.h MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_file__util__posix.cc MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_platform__thread__posix.cc MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_sys__info__posix.cc MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_base_third__party_nspr_prcpucfg.h MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_build_build__config.h MISSING: devel/xulrunner/patches/patch-ipc_chromium_src_chrome_common_ipc__channel__posix.h MISSING: devel/gps/patches/patch-ah MISSING: devel/gps/patches/patch-ai MISSING: devel/gps/patches/patch-aj MISSING: devel/p5-File-Listing/Makefile MISSING: devel/p5-File-Listing/DESCR MISSING: devel/p5-File-Listing/distinfo MISSING: devel/py-funcparserlib/Makefile MISSING: devel/py-funcparserlib/DESCR MISSING: devel/py-funcparserlib/distinfo MISSING: devel/py-funcparserlib/PLIST MISSING: devel/py-testtools/Makefile MISSING: devel/py-testtools/DESCR MISSING: devel/py-testtools/distinfo MISSING: devel/py-testtools/PLIST MISSING: devel/lua-lrexlib/DESCR.common MISSING: devel/lua-lrexlib/Makefile MISSING: devel/lua-lrexlib/Makefile.common MISSING: devel/lua-lrexlib/Makefile.version MISSING: devel/lua-lrexlib/distinfo MISSING: devel/lua-lrexlib/patches/patch-aa MISSING: devel/lua-lrexlib/patches/patch-ab MISSING: devel/lua-lrexlib/patches/patch-ac MISSING: devel/lua-lrexlib-onig/Makefile MISSING: devel/lua-lrexlib-onig/DESCR MISSING: devel/lua-lrexlib-onig/Makefile.common MISSING: devel/lua-lrexlib-onig/PLIST MISSING: devel/lua-lrexlib-pcre/Makefile MISSING: devel/lua-lrexlib-pcre/DESCR MISSING: devel/lua-lrexlib-pcre/PLIST MISSING: devel/lua-lrexlib-posix/Makefile MISSING: devel/lua-lrexlib-posix/DESCR MISSING: devel/lua-lrexlib-posix/PLIST MISSING: emulators/gxemul/patches/patch-ad MISSING: emulators/gxemul/patches/patch-ae MISSING: emulators/gxemul/patches/patch-af MISSING: emulators/qemu/patches/patch-ioport.c MISSING: filesystems/glusterfs/PLIST.georeplication MISSING: filesystems/glusterfs/options.mk MISSING: filesystems/fuse-ext2/Makefile MISSING: filesystems/fuse-ext2/DESCR MISSING: filesystems/fuse-ext2/distinfo MISSING: filesystems/fuse-ext2/PLIST MISSING: filesystems/fuse-ext2/patches/patch-aa MISSING: filesystems/fuse-ext2/patches/patch-ab MISSING: filesystems/fuse-ext2/patches/patch-ac MISSING: filesystems/fuse-ext2/patches/patch-af MISSING: filesystems/fuse-ext2/patches/patch-ag MISSING: games/maelstrom-x11/patches/patch-macres_cpp MISSING: games/maelstrom-x11/patches/patch-maelstrom_sound_cpp MISSING: games/maelstrom-x11/patches/patch-randtest_cpp MISSING: games/maelstrom-x11/patches/patch-testlist_cpp DIFF:graphics/vcg/files/globals.h MISSING: graphics/py-blockdiag/Makefile MISSING: graphics/py-blockdiag/DESCR MISSING: graphics/py-blockdiag/distinfo MISSING: graphics/py-blockdiag/PLIST MISSING: ham/locator/patches/patch-locator.cc MISSING: lang/gcc/patches/patch-Makefile.in MISSING:
Re: Fwd: pkgbox64 pkgsrc 2011Q1 DragonFly 2.11/x86_64 2011-06-03 02:14
Justin, I just tried building libcanberra on x86_64 and it built and installed just fine. original error logs: http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110603.0214/libcanberra-0.26nb1/ The current version in pkgsrc is libcanberra-0.26nb2 but I don't think the pkg revision made a difference. It looks like the bulk-build itself screwed up. e.g. pkg_add: Write error for share/locale/am/LC_MESSAGES/gtk20-properties.mo: Write failed pkg_add: Directory `/usr/pkg/lib/gtk-2.0/immodules' disappeared, skipping pkg_add: Directory `/usr/pkg/lib/gtk-2.0/2.10.0/filesystems' disappeared, skipping Anyway, I think canberra is okay. John On 6/6/2011 5:36 AM, Justin Sherrill wrote: pkgsrc bulk build report DragonFly 2.11/x86_64 Compiler: gcc Build start: 2011-06-03 02:14 Build end: 2011-06-06 03:10 Full report: http://avalon.dragonflybsd.org/reports/i386/2.11/20110603.0214/meta/report.html Machine readable version: http://avalon.dragonflybsd.org/reports/i386/2.11/20110603.0214/meta/report.bz2 Total number of packages: 10967 Successfully built: 8551 Failed to build: 591 Depending on failed package: 1255 Explicitly broken or masked: 507 Depending on masked package:63 Packages breaking the most other packages Package Breaks Maintainer - devel/libglade 360 droch...@netbsd.org net/avahi251 pkgsrc-us...@netbsd.org audio/libcanberra156 pkgsrc-us...@netbsd.org databases/postgresql84-client103 a...@netbsd.org editors/emacs 87 mins...@netbsd.org devel/libgweather 62 pkgsrc-us...@netbsd.org multimedia/xine-lib 62 pkgsrc-us...@netbsd.org x11/wxGTK28 61 jo...@netbsd.org print/teTeX3-texmf42 pkgsrc-us...@netbsd.org lang/ocaml37 a...@netbsd.org B
Re: Fwd: pkgbox64 pkgsrc 2011Q1 DragonFly 2.11/x86_64 2011-06-03 02:14
On 7/16/2011 4:17 PM, John Marino wrote: Justin, I just tried building libcanberra on x86_64 and it built and installed just fine. original error logs: http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110603.0214/libcanberra-0.26nb1/ The current version in pkgsrc is libcanberra-0.26nb2 but I don't think the pkg revision made a difference. It looks like the bulk-build itself screwed up. e.g. pkg_add: Write error for share/locale/am/LC_MESSAGES/gtk20-properties.mo: Write failed pkg_add: Directory `/usr/pkg/lib/gtk-2.0/immodules' disappeared, skipping pkg_add: Directory `/usr/pkg/lib/gtk-2.0/2.10.0/filesystems' disappeared, skipping Anyway, I think canberra is okay. John devel/libglade and net/avahi also build just fine. libglade had the exact same errors as libcanberra: http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110603.0214/libglade-2.6.4nb5/depends.log and so did avahi: http://avalon.dragonflybsd.org/reports/x86_64/2.11/20110603.0214/avahi-0.6.27nb4/depends.log Maybe it was a gtk2 problem causing it. I've got the latest gtk2.24 on the system, so maybe the update to that package fixed these on x86_64. John On 6/6/2011 5:36 AM, Justin Sherrill wrote: pkgsrc bulk build report DragonFly 2.11/x86_64 Compiler: gcc Build start: 2011-06-03 02:14 Build end: 2011-06-06 03:10 Full report:http://avalon.dragonflybsd.org/reports/i386/2.11/20110603.0214/meta/report.html Machine readable version: http://avalon.dragonflybsd.org/reports/i386/2.11/20110603.0214/meta/report.bz2 Total number of packages: 10967 Successfully built: 8551 Failed to build: 591 Depending on failed package: 1255 Explicitly broken or masked: 507 Depending on masked package:63 Packages breaking the most other packages Package Breaks Maintainer - devel/libglade 360droch...@netbsd.org net/avahi251pkgsrc-us...@netbsd.org audio/libcanberra156pkgsrc-us...@netbsd.org databases/postgresql84-client103a...@netbsd.org editors/emacs 87mins...@netbsd.org devel/libgweather 62pkgsrc-us...@netbsd.org multimedia/xine-lib 62pkgsrc-us...@netbsd.org x11/wxGTK28 61jo...@netbsd.org print/teTeX3-texmf42pkgsrc-us...@netbsd.org lang/ocaml37a...@netbsd.org B
The gold linker is now in the base system
Today I flipped a switch a switch which allows the gold linker to be built with world. After the next build, you'll find it located at /usr/libexec/binutils221/elf/ld.gold . It is considered experimental at this point. Users of large C++ projects should see a large jump in compiling speed when using gold (could be up to 5x faster), so if you are a frequent builder of such a project, you might be interested to switch linkers. For additional information: /usr/bin/ld is objformat-linked to /usr/libexec/binutils221/elf/ld /usr/libexec/binutils221/elf/ld is hardlinked to /usr/libexec/binutils221/ld.bfd Gold will NOT build a usable kernel or world. The only way to attempt this is to modify to the ld.bfd and ld.gold makefiles, so you luckily can't do this accidentally. Therefore, you should be safe if you decide to change the /usr/libexec/binutils221/elf/ld hardlink to gold. It would be great to hear about successes and failures encountered with the use of the gold linker. -- John
Re: Filesystems
This post has me so perplexed, I just have to explore further. On 4/23/2011 2:15 AM, David Crosswell wrote: Yes, I understand that. I'm looking forward to doing something with Hammer, but I've spoken to a couple of guys at the local Users group who swear they'll never use anything else but ZFS You are apparently talking about random people at some local club. Why is their preference of filesystem impacting your intention to try out Hammer?What makes their opinion so special? - got it running on FreeBSD and I looked at Dragonfly with UFS and Hammer and thought with ZFS they'd have every scenario covered. Who is they? DragonFly community? Linux is working to incorporate ZFS compatibility into the kernel, No, Linux is not. As long as ZFS has the CDDL license, it won't be incorporated into the kernel. People are working on putting ZFS in a module that users can manually load in to work around license issues. It's not a technical incompatibility, it's a license incompatibility for which there is no solution other than Oracle changing the ZFS license. and even with various filesystem developers looking at substantial jail sentences for killing their wives, they've still got an over abundance of filesystems. Again, why is Linux filesystem situation relevant to DragonFly? How does Linux having too many filesystems (in your opinion) relate to DragonFly not having ZFS? I'm not following any logic train. It's going to have to wait for a while before I learn C then. Regards, What? There's going to be a delay in your learning C because of which following reason? A) Reiser was convicted of killing his wife B) Linux has too many filesystems C) Linux is putting ZFS in the kernel D) Random people in local user groups swear by ZFS E) Nobody is bothering to import ZFS to DragonFly. F) Other? -- John David Crosswell. On 23/04/2011, Justin Sherrilljus...@shiningsilence.com wrote: It's certainly possible. Nobody's working on it right now, to my knowledge. I'm more interesting in seeing Hammer grow, so I'm not that concerned about it. On Fri, Apr 22, 2011 at 5:03 PM, David Crosswell david.crosswe...@gmail.com wrote: I understand the availability of UFS and Hammer in the Dragonfly environment, but is ZFS possible, or are there any plans to facilitate it if it isn't? Regards, David Crosswell. -- In a world without walls and fences, what need have we for Windows or Gates? http://www.weavers-web.org
Re: How to test and debug Dragonfly BSD?
Hi Sdävtaker, Apparently your experience differs from mine. I've been running Dragonfly i386 and Dragonfly x86_64 within Virtualbox for a year now, and it works great. I've had no issues whatsoever, and that's on host machines of both windows and Solaris. We've even found and fixed a couple of bugs in Dfly due to running it inside vbox. I think your vbox information might be a bit obsolete, or maybe there is something wrong with your instance of it. It requires no tricks. I recommend that one picks FreeBSD or 64-bit FreeBSD as the OS when they create the machine. Regards, John On 11/8/2010 9:25 PM, Sdävtaker wrote: DragonflyBSD got Virtual Kernels, those are a tool to run kernels over kernel and debug them. In the documentation site: http://www.dragonflybsd.org/docs/documentation/ there is a section for developer where you can read about codeing standards, tools, repository handling, most what you need is there :-) VBox doesnt run in DFBSD as far as i know and it had some tricks to make DFBSD work in a VBox too, there is a reported bug to oracle that never was fixed and give troubles time to time (if you use it with no-acpi, probably the only issue you will have is a necesity for reboot after turn on, it works for me that way, no idea why, turn on, it halts, soft reset, it workssome kind of Vudu for sure). Also, check the irc, most the developers are there most the time :-) Enjoy the project, there is a lot of fascinating things going on Damian On Mon, Nov 8, 2010 at 17:07,Marcin Ropa marcinr...@gmail.com wrote: Hello, A few weeks ago I decided to spend my free time working on dfbsd and i started digging in code. I have experience as developer but there everything is new for me and probably I will have to spend many time before i will be helpful for the project. :) I have my first question.: How do you organize your work on DragonFly BSD? I am not going to ask you about your editor but how do you run, test and debug your code. Do you use VirtualBox, qemu or seperate machine? Does VirtualBox run on dfbsd or you run VirtualBox on another system, e.g.: FreeBSD and this is your development platform? I know you are busy, but if you find time please give me some hints how to organize work on operating system. thanks a lot and Greeting Marcin
