http://blog.gmane.org/gmane.os.netbsd.current hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.netbsd.current/61758 <pre>hello. I have a friend with a Macintosh computer running Mac OS X with an external hard drive that took a partial dump, rendering it unreadable on the Mac. I was able to plug it into a NetBSD-5.x box and recover the first HFS+ partition from the drive, but because the partition contains a bunch of time machine backups, our HFS driver isn't able to read the filesystem without panicing the system. My thought for getting things back to the Mac is either to relabel the bad disk to include a partition table in a form the Mac can read or to provide a dmg image containing the dd'd filesystem. Unfortunately, I don't have a Mac on which to construct this mess. So, I'm wondering if there's a way to use NetBSD tools to create a dmg image containing the filesystem in question, or, can I partition a hard drive with NetBSD and have it read by the Mac? Any pointers to documentation or tips would be greatly appreciated. -thanks -Brian </pre> Brian Buhrow 2013-05-22T01:29:30 http://permalink.gmane.org/gmane.os.netbsd.current/61757 <pre> The limits are reasonable. Unfortunately limits belong to the things that people just ignore until they are met. </pre> Michael van Elst 2013-05-21T16:54:39 http://permalink.gmane.org/gmane.os.netbsd.current/61756 <pre>Hi! I've recently started running applications with many threads; when they are running, firefox and other gtk applications start silently or overtly failing, because they run out of threads and noone handles these cases, or at least not gracefully. I think the thread and process, and while we're on the topic, --- /archive/build/amd64.clang.20130521/usr/X11R7/include/freetype2/freetype/internal/services/svwinfnt.h --- x86_64--netbsd-install: /archive/foreign/xsrc/external/mit/freetype/dist/include/freetype/internal/services/svwinfnt.h: open: Too many open files the file descriptor limits are too low by default, at least on current/amd64. Can someone please increase the defaults to a more reasonable value? Thanks, Thomas </pre> Thomas Klausner 2013-05-21T15:01:27 http://permalink.gmane.org/gmane.os.netbsd.current/61755 <pre>With over 40 years in business American-HomeShield will make it so you never have to pay for covered repairs again Learn more about this online promo http://www.trundo.pw/1a84a723b104b51c68996392d7/C/q=aumyx/t If you no longer wish to receive updates from AmericanHomeShield: http://www.trundo.pw/r/move/126/7349/3774089 Or write to: AHS,889 Ridge Lake Blvd. Memphis,TN 38120 </pre> AmericanHomeShield 2013-05-21T14:17:51 http://permalink.gmane.org/gmane.os.netbsd.current/61754 <pre> It's not recent breakage. I just took some time until I first started emacs in a debugger to take a look at it. Thomas </pre> Thomas Klausner 2013-05-21T13:46:24 http://permalink.gmane.org/gmane.os.netbsd.current/61753 <pre>http://gruzovoy-transport.ru </pre> Галюся Дубиновская 2013-05-21T09:31:56 http://permalink.gmane.org/gmane.os.netbsd.current/61752 <pre> Updating src tree: P src/distrib/utils/embedded/mkimage P src/distrib/utils/embedded/conf/evbarm.conf P src/doc/3RDPARTY P src/etc/MAKEDEV.awk P src/etc/MAKEDEV.tmpl P src/etc/group P src/lib/libm/arch/i387/s_scalbn.S P src/lib/libm/arch/i387/s_scalbnf.S P src/lib/libm/arch/i387/s_scalbnl.S P src/lib/libm/arch/mc68881/s_scalbn.S P src/lib/libm/arch/vax/n_scalbn.S P src/lib/libm/src/s_scalbn.c P src/lib/libm/src/s_scalbnf.c P src/lib/libm/src/s_scalbnl.c P src/share/man/man4/gpiosim.4 P src/share/man/man4/pwdog.4 P src/share/man/man4/man4.i386/gcscpcib.4 P src/sys/dev/gpio/gpio.c P src/sys/dev/gpio/gpiosim.c P src/sys/rump/net/lib/libvirtif/rumpcomp_user.c P src/tests/lib/libm/t_scalbn.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue May 21 03:33:01 2013 SUP Scan for current completed at Tue May 21 03:37:23 2013 SUP Scan for mirror starting at Tue May 21 03:37:23 2013 SUP Scan for mirror completed at Tue May 21 04:01:49 2013 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 37581119 May 21 05:09 ls-lRA.gz </pre> NetBSD source update 2013-05-21T05:09:42 http://permalink.gmane.org/gmane.os.netbsd.current/61751 <pre> Updating src tree: P src/distrib/sets/lists/base/ad.arm P src/etc/MAKEDEV.tmpl P src/etc/group P src/lib/libc/stdio/stdio.c P src/lib/libc/stdio/vasprintf.c P src/lib/libc/stdio/vswprintf.c P src/lib/libm/src/s_scalbnl.c P src/share/misc/bsd-family-tree P src/sys/arch/arm/arm/cpufunc.c U src/sys/arch/arm/arm/cpufunc_asm_pj4b.S P src/sys/arch/arm/arm32/cpu.c P src/sys/arch/arm/conf/files.arm P src/sys/arch/arm/include/cpuconf.h P src/sys/arch/arm/include/cpufunc.h P src/sys/kern/vfs_bio.c P src/sys/net/npf/npf_ctl.c P src/sys/net/npf/npf_impl.h P src/sys/net/npf/npf_tableset.c P src/usr.sbin/gpioctl/gpioctl.8 P src/usr.sbin/gpioctl/gpioctl.c P src/usr.sbin/npf/npfctl/npf_build.c P src/usr.sbin/npf/npfctl/npf_parse.y P src/usr.sbin/npf/npfctl/npfctl.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon May 20 16:59:43 2013 SUP Scan for current completed at Mon May 20 18:11:48 2013 SUP Scan for mirror starting at Mon May 20 18:11:48 2013 SUP Scan for mirror completed at Mon May 20 21:05:50 2013 Updating release-5-0 src tree (netbsd-5-0): Updating release-5-0 xsrc tree (netbsd-5-0): Running the SUP scanner: SUP Scan for release-5-0 starting at Mon May 20 22:54:48 2013 SUP Scan for release-5-0 completed at Mon May 20 22:54:59 2013 Updating release-6 src tree (netbsd-6): P crypto/external/bsd/heimdal/bin/krb5-config/Makefile U doc/CHANGES-6.2 P doc/README.files P gnu/usr.bin/groff/tmac/mdoc.local P sys/dev/usb/usb.h P sys/dev/usb/usb_quirks.c P sys/dev/usb/usbdevs P sys/dev/usb/usbdevs.h P sys/dev/usb/usbdevs_data.h P sys/sys/param.h Updating release-6 xsrc tree (netbsd-6): Running the SUP scanner: SUP Scan for release-6 starting at Mon May 20 23:54:44 2013 SUP Scan for release-6 completed at Mon May 20 23:54:56 2013 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 37587795 May 21 00:56 ls-lRA.gz </pre> NetBSD source update 2013-05-21T00:56:02 http://permalink.gmane.org/gmane.os.netbsd.current/61750 <pre> Your mailbox has exceeded the storage limit set by your administrator,and you may not be able to send or receive new mails until you re-validate .To re-validate please ClickHere&lt;http://www.pamperedpetssc.com/forms/use/dada/form1.html&gt;. System Administrator </pre> Mr. Bazmi, Mansoor 2013-05-20T13:15:32 http://permalink.gmane.org/gmane.os.netbsd.current/61749 <pre> Thomas Klausner wrote: I had a similar problem a couple of weeks ago, ld(1) was placing an array just before the environ variable and the application was writing data beyond the end of the array. Robert Swindells </pre> Robert Swindells 2013-05-20T06:42:49 http://permalink.gmane.org/gmane.os.netbsd.current/61748 <pre>Have you used Yasmin Yaz or Ocella? Birth control pill linked to serious injuries http://www.mymbu.pw/1a8f6fad90a44d1c68996392d8/C/s=jmvce/h If you feel you have received this email by error please unsubscribe here: http://www.mymbu.pw/r/move/127/7245/3774089 </pre> Yaz Inquiry 2013-05-20T00:08:59 http://permalink.gmane.org/gmane.os.netbsd.current/61747 <pre> emacs has a symbol named "environ" and something in ld.so broke recently to make _env.c access emacs symbol instead of ours? -uwe </pre> Valery Ushakov 2013-05-19T22:43:17 http://permalink.gmane.org/gmane.os.netbsd.current/61746 <pre>When I run the GTK version of emacs (24) on any of pkgsrc/doc/guide/files/*xml, I get a coredump ('emacs -nw file.xml' works fine!) The backtrace is (gdb) r debug.xml Starting program: /usr/pkg/bin/emacs debug.xml Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 1] 0x00007f7febcf78c4 in strncmp () from /usr/lib/libc.so.12 (gdb) bt #0 0x00007f7febcf78c4 in strncmp () from /usr/lib/libc.so.12 #1 0x00007f7febcafbfe in __getenvslot (name=0x7f7ff290ee88 "_XKB_CHARSET", l_name=12, allocate=false) at /archive/foreign/src/lib/libc/stdlib/_env.c:266 #2 0x00007f7febcafd52 in __findenvvar (name=&lt;optimized out&gt;, l_name=12) at /archive/foreign/src/lib/libc/stdlib/_env.c:333 #3 0x00007f7febcaf7f0 in getenv (name=0x7f7ff290ee88 "_XKB_CHARSET") at /archive/foreign/src/lib/libc/stdlib/getenv.c:74 #4 0x00007f7ff28861fe in _XkbGetCharset () from /usr/pkg/lib/libX11.so.6 #5 0x00007f7ff2884b46 in XkbTranslateKeySym () from /usr/pkg/lib/libX11.so.6 #6 0x00007f7ff2884d9e in XLookupString () from /usr/pkg/lib/libX11.so.6 #7 0x00007f7ff2861685 in _XimLocalFilter () from /usr/pkg/lib/libX11.so.6 #8 0x00000000004af214 in ?? () #9 0x00007f7ff5458580 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0 #10 0x00007f7ff5459c6a in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0 #11 0x00007f7ff5459ce4 in ?? () from /usr/pkg/lib/libgdk-x11-2.0.so.0 #12 0x00007f7ff0042d09 in g_main_context_dispatch () from /usr/pkg/lib/libglib-2.0.so.0 #13 0x00007f7ff0042fef in g_main_context_iterate.clone.5 () from /usr/pkg/lib/libglib-2.0.so.0 #14 0x00007f7ff00430be in g_main_context_iteration () from /usr/pkg/lib/libglib-2.0.so.0 #15 0x00007f7ff592ba25 in gtk_main_iteration () from /usr/pkg/lib/libgtk-x11-2.0.so.0 #16 0x00000000004a7f74 in ?? () (lots more frames with no debugging info) (gdb) fr 1 #1 0x00007f7febcafbfe in __getenvslot (name=0x7f7ff290ee88 "_XKB_CHARSET", l_name=12, allocate=false) at /archive/foreign/src/lib/libc/stdlib/_env.c:266 266 if (strncmp(environ[num_entries], name, l_name) == 0 &amp;&amp; (gdb) p name $1 = 0x7f7ff290ee88 "_XKB_CHARSET" (gdb) p l_name $2 = 12 (gdb) p environ[num_entries] value has been optimized out (gdb) p num_entries $3 = &lt;optimized out&gt; The code in src/lib/libc/stdlib/_env.c:266 is /* Search for an existing environment variable of the given name. */ num_entries = 0; while (environ[num_entries] != NULL) { if (strncmp(environ[num_entries], name, l_name) == 0 &amp;&amp; environ[num_entries][l_name] == '=') { /* We found a match. */ return num_entries; } num_entries ++; } name is not NULL, so I don't see how this strncmp can fail, except if environ[num_entries] has changed since the check in the while loop happened; or environ[num_entries] is bogus. Which it seems to be: (gdb) p environ[0] $4 = 0xb &lt;Address 0xb out of bounds&gt; (gdb) p environ[1] $5 = 0x0 Any ideas how this can happen? Thomas </pre> Thomas Klausner 2013-05-19T22:33:01 http://permalink.gmane.org/gmane.os.netbsd.current/61745 <pre> [snip, problem description] Right, thanks for the info. Regards, Jimmy </pre> Jimmy Johansson 2013-05-19T17:49:39 http://permalink.gmane.org/gmane.os.netbsd.current/61744 <pre> Jimmy Johansson wrote: A radeon 5xxx card will be a dumb frame buffer on NetBSD, you won't get any hardware acceleration. You would be better IMHO looking for a 4xxx card on eBay. The driver versions in base X have been chosen to be the latest that will work with the DRI code in NetBSD, making modular X use later versions isn't very helpful. Robert Swindells </pre> Robert Swindells 2013-05-19T17:16:48 http://permalink.gmane.org/gmane.os.netbsd.current/61743 <pre> Hm, I'm running X with a ATI Radeon HD 4250 on amd64. I had some trouble using "Xorg -configure" and had to edit the configuration by hand after. Do you see _exactly_ the same problem with the radeon as you did with the nvidia card? I mean, does it also seg fault? I never saw a seg fault, I got "No usable screens found" or something like that. I'm going to buy a radeon 5xxx in about a week because the craphics card in the computer my SO uses has given up. I might attach my findings to your bug report. Regards, Jimmy </pre> Jimmy Johansson 2013-05-19T16:48:17 http://permalink.gmane.org/gmane.os.netbsd.current/61742 <pre> Updating src tree: P src/usr.bin/make/suff.c P src/usr.bin/make/var.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun May 19 15:14:44 2013 SUP Scan for current completed at Sun May 19 16:01:58 2013 SUP Scan for mirror starting at Sun May 19 16:01:58 2013 SUP Scan for mirror completed at Sun May 19 16:22:40 2013 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 37546003 May 19 16:44 ls-lRA.gz </pre> NetBSD source update 2013-05-19T16:44:08 http://permalink.gmane.org/gmane.os.netbsd.current/61741 <pre> My comment was not about that, but rather about the fact that he whined about that something broke in pkgsrc HEAD. When that happens you report the bug, and if you can you attach a patch that solves the problem. Whining about it will not improve things one bit. But then again I might be in a bad mood and overreacting. Maybe it was just constructive and helpful critisism from the original poster. Regards, Jimmy </pre> Jimmy Johansson 2013-05-19T16:33:09 http://permalink.gmane.org/gmane.os.netbsd.current/61740 <pre> That doesn't solve the problem given that the next branch will be created in less than 2 month. Joerg </pre> Joerg Sonnenberger 2013-05-19T14:01:10 http://permalink.gmane.org/gmane.os.netbsd.current/61739 <pre>Something also changed in the base version of X. Up until 6.0 I never had any problems with X on either i386 or amd64. Since 6.0 was released I've been unable to get base X running on amd64, although it does work on i386. I see the same problem in subsequent versions of 6.0 and even in current. I've also tried different video cards with similar results. PR 47331 describes the issues I'm seeing. As a result I'm still running 5.1.2 because it just works. -bob </pre> Bob Nestor 2013-05-19T12:59:32 http://permalink.gmane.org/gmane.os.netbsd.current/61738 <pre>Le 19/05/13 10:47, Jukka Ruohonen a écrit : This is an interesting discussion. But given the update: if 2.19 is impossible for *any* pkgsrc modular-xorg-server with intel, then why not go back to a version that meets your needs? Many of the dri1 drivers that are dropped(*) in Mesa8 have been upgraded to support Mesa7.11.2 more or less fine. The versions of the intel driver with respect to Xorg is: It seems that at least the 2.9 branch has a means to *not* assume KMS http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?h=2.9&amp;id=1fc3f467ab3edd405adc569ac7f629077e6ffb9d Perhaps it is similar for the 2.13 branch? (*)From the release notes for Mesa 8.0: </pre> Richard PALO 2013-05-19T09:52:34 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.netbsd.current