DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-02-08T23:53:40ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3343 (Closed): New cookie_* functions in stdio.h should be guarded by somethinghttps://bugs.dragonflybsd.org/issues/33432023-02-08T23:53:40Zdavshao
<p>fopencookie(3): Add a wrapper around funopen(3)<br />commit a765cedf26cef470ba7deee42c365f0221690a1a<br />Date: Sat Feb 4 14:54:20 2023 +0100</p>
<p>changed /usr/include/stdio.h to add</p>
<p><ins>typedef ssize_t (cookie_read_function_t)(void *, char *, size_t);<br />+typedef ssize_t (cookie_write_function_t)(void *, const char *, size_t);<br />+typedef int (cookie_seek_function_t)(void *, off64_t *, int);<br />+typedef int (cookie_close_function_t)(void *);<br />+typedef struct {<br /></ins> cookie_read_function_t *read;<br />+ cookie_write_function_t *write;<br />+ cookie_seek_function_t *seek;<br />+ cookie_close_function_t *close;<br />+} cookie_io_functions_t;<br />+FILE *fopencookie(void *, const char *, cookie_io_functions_t);</p>
<p>These new functions are guarded by nothing, yet ssize_t has a definition<br />in the same header file guarded by something. Trying to build say png,<br />the compile is confused about ssize_t, among other things. For now, moving</p>
<p>#endif /* __BSD_VISIBLE */</p>
<p>to cover the new functions and structs allows png to build, but I<br />cannot guarantee other packages will regard this as sufficient.</p> DragonFlyBSD - Bug #3325 (Closed): Revert sys/vfs/hammer2: Properly set rdonly flag for PFShttps://bugs.dragonflybsd.org/issues/33252022-09-10T18:20:37Zdavshao
<p>After <br />sys/vfs/hammer2: Properly set rdonly flag for PFS<br />commit 5f5122fa2471887600e87e29917d577f65d73a05<br />Date: Wed Sep 7 00:11:28 2022 -0700</p>
<p>the system boots but there are read(only) errors reported with ttys not created, dhcp not working, etc.<br />Bisected to this particular commit.</p>
<p>Maybe unusual these days, I am using grub2 to boot from an ssd (not nvme) formatted mbr.</p>
<p>Here is the /etc/fstab:</p>
<ol>
<li>Device Mountpoint FStype Options Dump Pass#<br />/dev/serno/2017E29D5A8C.s1a /boot ufs rw 2 2<br />/dev/serno/2017E29D5A8C.s1b none swap sw 0 0<br />/dev/serno/2017E29D5A8C.s1d / hammer2 rw 1 1<br />/build/usr.obj /usr/obj null rw 0 0<br />/build/var.crash /var/crash null rw 0 0<br />/build/var.cache /var/cache null rw 0 0<br />/build/var.spool /var/spool null rw 0 0<br />/build/var.log /var/log null rw 0 0<br />/build/var.tmp /var/tmp null rw 0 0<br />tmpfs /tmp tmpfs rw 0 0<br />proc /proc procfs rw 0 0</li>
</ol>
<p>$ uname -a<br />DragonFly xxxxxx 6.3-DEVELOPMENT DragonFly v6.3.0.196.g64e301-DEVELOPMENT #0: Sat Sep 10 10:28:47 PDT 2022 xxxxxx@xxxxxx:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64</p> DragonFlyBSD - Submit #3244 (Resolved): Additional Intel I219-LM and I219-V Ethernet PCI device n...https://bugs.dragonflybsd.org/issues/32442020-08-19T03:06:01Zdavshao
<p>NetBSD current sys/dev/pci/pcidevs.h has additional PCI device numbers for Intel I219-LM and Intel I219-V Ethernet. Simply adding these numbers has been verified to enable em0 on an Asus Prime H470-Plus mATX motherboard for I219-V11 0x0D4D. Also NetBSD current had no problem activating its wm0 Ethernet device for this motherboard.</p>
<p>Note that Phoronix had an article "DragonFlyBSD vs. FreeBSD vs. Ubuntu 20.04 On Intel's Core i9 10900K Comet Lake" that noted on-board Ethernet was not functional on either FreeBSD 12 or DragonFly BSD, and that claimed that even for Linux, 5.6 or later was required. That claim may be incorrect for at least obtaining some minimal functionality on DragonFly for very little effort.</p>
<p>Attached is a patch adding the numbers from NetBSD. The naming of the devices using "CNP", which I believe is an abbreviation for previous generation codename Cannon Point chipsets, is arguably incorrect; however, I was unable to locate any code name at all for current series 400 Intel chipsets. In any case, for at least one device, the Cannon Point handler appears to work unchanged.</p> DragonFlyBSD - Submit #3026 (Resolved): Patch to enable HDMI audio for Gigabyte Radeon R7 240https://bugs.dragonflybsd.org/issues/30262017-04-13T01:27:10Zdavshao
<p>In a years old thread</p>
<p>amd64 panic snd_hda - hdac_get_capabilities: Invalid corb size (0)</p>
<p><a class="external" href="https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html">https://lists.freebsd.org/pipermail/freebsd-current/2010-July/018764.html</a></p>
<p>Andriy Gapon suggested the following patches to enable HDMI audio for<br />an ATI/AMD video card. But at that time the original poster was not<br />able to actually get the sound device to properly attach.</p>
<p>Well these patches DO work for DragonFly, at least using a custom kernel<br />starting from master sometime in the last couple of weeks with<br />radeon audio patches from Linux 4.7.10 (adding radeon_audio.c and radeon_audio.h<br />and updating everything related).</p>
<p>I startx using xfce4 and a custom version of pkgsrc with mesa 17, xorg server 19.3</p>
<ol>
<li>kldload snd_hda</li>
</ol>
<p>Read the end of dmesg:</p>
<p>[drm] Initialized radeon 2.40.0 20080528<br />hdac0: <Intel Panther Point HDA Controller> mem 0xf7f10000-0xf7f13fff irq 22 at device 27.0 on pci0<br />hdac0: link ctrl 0x800<br />hdac0: disable nosnoop<br />hdac1: <ATI (0xaab0) HDA Controller> mem 0xf7e60000-0xf7e63fff irq 17 at device 0.1 on pci2<br />hdac1: link ctrl 0x2800<br />hdac1: disable nosnoop<br />hdacc0: <VIA VT1708S_0 HDA CODEC> at cad 0 on hdac0<br />hdaa0: <VIA VT1708S_0 Audio Function Group> at nid 1 on hdacc0<br />hdacc1: <ATI R6xx HDA CODEC> at cad 0 on hdac1<br />hdaa1: <ATI R6xx Audio Function Group> at nid 1 on hdacc1<br />pcm0: <VIA VT1708S_0 (Analog 7.1+HP/2.0)> at nid 28,34,25,35,29 and 26,30,27 on hdaa0<br />pcm1: <VIA VT1708S_0 (Digital)> at nid 32 on hdaa0<br />pcm2: <VIA VT1708S_0 (Rear-panel Digital)> at nid 33 on hdaa0<br />pcm3: <ATI R6xx (HDMI)> at nid 3 on hdaa1</p>
<ol>
<li>sysctl hw.snd.default_unit=3<br />hw.snd.default_unit: 0 -> 3</li>
</ol>
<p>fire up firefox, go to youtube and listen to whatever.</p>
<p>The following patches are safer for DragonFly because by default<br />no sound drivers are loaded. Original poster actually had<br />kernel crashes because on his version of FreeBSD sound drivers<br />were automatically loaded. Also there was a claim at the time,<br />least if the initial value of corb_size was 0, that Linux actually does<br />do some default assumption of 256.</p>
<p>diff --git a/sys/dev/sound/pci/hda/hdac.c b/sys/dev/sound/pci/hda/hdac.c<br />index d63843a10f..2178243f88 100644<br />--- a/sys/dev/sound/pci/hda/hdac.c<br />+<ins>+ b/sys/dev/sound/pci/hda/hdac.c<br /><code>@ -488,7 +488,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid corb size (%x)\n",<br /> <i>func</i>, corbsize);<br />- return (ENXIO);<br /></ins> if (1) {<br />+ device_printf(sc->dev, "Resetting corb size to 256\n");<br />+ sc->corb_size = 256;<br />+ corbsize =<br />+ HDAC_CORBSIZE_CORBSIZE(HDAC_CORBSIZE_CORBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_CORBSIZE, corbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</p>
<pre><code>rirbsize = HDAC_READ_1(&sc->mem, HDAC_RIRBSIZE);<br /><code>@ -504,7 +512,15 </code>@ hdac_get_capabilities(struct hdac_softc *sc)<br /> else {<br /> device_printf(sc->dev, "%s: Invalid rirb size (%x)\n",<br /> <i>func</i>, rirbsize);<br />- return (ENXIO);<br />+ if (1) {<br />+ device_printf(sc->dev, "Resetting rirb size to 256\n");<br />+ sc->rirb_size = 256;<br />+ rirbsize =<br />+ HDAC_RIRBSIZE_RIRBSIZE(HDAC_RIRBSIZE_RIRBSIZE_256);<br />+ HDAC_WRITE_1(&sc->mem, HDAC_RIRBSIZE, rirbsize);<br />+ }<br />+ else<br />+ return (ENXIO);<br /> }</code></pre>
<pre><code>HDA_BOOTVERBOSE(<br /><code>@ -1211,6 +1227,8 </code>@ hdac_attach(device_t dev)<br /> if (result != 0)<br /> goto hdac_attach_fail;</code></pre>
<p>+ hdac_reset(sc, 1);<br />+<br /> /* Get Capabilities */<br /> result = hdac_get_capabilities(sc);<br /> if (result != 0)</p> DragonFlyBSD - Bug #2994 (New): Intermittent boot hangs after git: hammer - HAMMER Version 7https://bugs.dragonflybsd.org/issues/29942017-03-28T18:44:52Zdavshao
<p>Bisected to git: hammer - HAMMER Version 7<br />commit 4c09d9c4fd910651904ede280ad90a4abf3fc5d7<br />Date: Fri Mar 17 14:06:24 2017 -0700</p>
<pre><code>hammer - HAMMER Version 7</code></pre>
<p>intermittent boot hangs stopping at</p>
<p>ums0: <Logitech USB-PS2 Optical Mouse, class 0/0, rev 2.00/20.00, addr 5> on usb<br />ums0: 3 buttons and [XYX] coordinates ID=0<br />no B_DEVMAGIC (bootdev=0)</p>
<p>Boot proceeds normally when using verbose option which is why I can attach<br />the verbose dmesg.</p>
<p>The machine uses a refurbished Asus P8H77-V motherboard with several<br />internal hard drives with different OSes using legacy BIOS.</p>
<p>$ hammer info<br />Volume identification<br /> Label ROOT<br /> No. Volumes 1<br /> HAMMER Volumes /dev/serno/WD-WMAYP5624974.s3d<br /> Root Volume /dev/serno/WD-WMAYP5624974.s3d<br /> FSID 9d8141cd-c974-11e5-9ccd-bd5ff4499104<br /> HAMMER Version 6<br />Big-block information<br /> Total 29669<br /> Used 9119 (30.74%)<br /> Reserved 70 (0.24%)<br /> Free 20480 (69.03%)<br />Space information<br /> No. Inodes 856028<br /> Total size 232G (248881610752 bytes)<br /> Used 71G (30.74%)<br /> Reserved 560M (0.24%)<br /> Free 160G (69.03%)<br />PFS information<br /> PFS# Mode Snaps<br /> 0 MASTER 0 (root PFS)</p> DragonFlyBSD - Submit #2985 (Closed): Move drm linux_*.c files to subdirectory drm/linuxhttps://bugs.dragonflybsd.org/issues/29852017-03-22T00:47:50Zdavshao
<p>This patch moves the linux_*.c files under sys/dev/drm to their own<br />sub-directory sys/dev/drm/linux.</p>
<p>The idea is that eventually someone might want to import files<br />from FreeBSD linuxkpi. Though at some point the obvious question<br />is should these files and others added be turned into their own<br />separate module that can be used by drivers other than<br />the drm graphics ones, similar to what FreeBSD does with linuxkpi.</p>
<p>I don't really care where these files are moved: I just want them<br />moved somewhere to have their own separate identity.</p> DragonFlyBSD - Bug #2964 (Resolved): make upgrade REMOVE_OPENSSL_FILES=yes incompatible with make...https://bugs.dragonflybsd.org/issues/29642016-11-02T20:57:53Zdavshao
<p>On DragonFly master, for a previous recent build, if one does</p>
<p>make upgrade REMOVE_OPENSSL_FILES=yes</p>
<p>then updates to the latest master source, then</p>
<p>cd /usr/obj<br />mv usr usr.old<br />cd /usr/src<br />make buildworld</p>
<p>there seems a good chance one will encounter an error, really fast, such as:</p>
<p>===> bin/cpdup (bootstrap-tools)<br />/usr/obj/usr/src/btools_x86_64/usr/src/bin/cpdup created for /usr/src/bin/cpdup<br />rm -f .depend</p>
<blockquote>
<p>.depend</p>
</blockquote>
<p>mkdep -f .depend -a -std=gnu99 /usr/src/bin/cpdup/cpdup.c /usr/src/bin/cpdup/hcproto.c /usr/src/bin/cpdup/hclink.c /usr/src/bin/cpdup/misc.c /usr/src/bin/cpdup/fsmid.c /usr/src/bin/cpdup/md5.c<br />In file included from /usr/include/md5.h:41:0,<br /> from /usr/src/bin/cpdup/cpdup.h:28,<br /> from /usr/src/bin/cpdup/cpdup.c:58:<br />/usr/include/sys/md5.h:45:25: fatal error: openssl/md5.h: No such file or directory<br />compilation terminated.</p>
<p>It seems to me that cpdup.c includes "cpdup.h" which in turn includes <md5.h> if NOMD5 is undefined,<br />which in turn includes <sys/md5.h>, which in turn includes <openssl/md5.h>,<br />which after make upgrade REMOVE_OPENSSL_FILES doesn't exist anymore.</p> DragonFlyBSD - Bug #2928 (Closed): Patch from later Linux drm: drm/fb-helper: Use proper plane ma...https://bugs.dragonflybsd.org/issues/29282016-07-22T16:24:30Zdavshao
<p>Thanks for the update to Linux 4.4 drm. There is a subtle bug<br />in the usage of drm_plane_index() in function pan_display_atomic()<br />of drm_fb_helper.c, found by Matt Roper. For reference:</p>
<p><a class="external" href="https://patchwork.kernel.org/patch/7889051/">https://patchwork.kernel.org/patch/7889051/</a></p>
<p>Please apply the following patch:</p>
<p>diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c<br />index 69cbab5..1e103c4 100644<br />--- a/drivers/gpu/drm/drm_fb_helper.c<br />+++ b/drivers/gpu/drm/drm_fb_helper.c<br /><code>@ -1251,7 +1251,7 </code>@ retry:<br /> goto fail;</p>
<pre><code>plane = mode_set->crtc->primary;<br />- plane_mask |= drm_plane_index(plane);<br />+ plane_mask |= (1 << drm_plane_index(plane));<br /> plane->old_fb = plane->fb;<br /> }</code></pre> DragonFlyBSD - Bug #2910 (Closed): Rethinking __printflike in the context of drm's __printfhttps://bugs.dragonflybsd.org/issues/29102016-05-06T05:34:46Zdavshao
<p>Currently DragonFly drm defines <i>printf to be __printflike. It seems likely to me that Linux drm actually expects behavior __printf0like, without the __nonnull</i>(fmtarg) attribute.</p>
<p>For example, more recent versions of Linux drm want to define a function like this:</p>
<p>extern __printf(6, 7)<br />int drm_crtc_init_with_planes(struct drm_device *dev,<br /> struct drm_crtc *crtc,<br /> struct drm_plane *primary,<br /> struct drm_plane *cursor,<br /> const struct drm_crtc_funcs *funcs,<br /> const char *name, ...);</p>
<p>and call it sometimes (well strangely enough, so far all of the time) with name == NULL.<br />Then inside the newer versions of the function is something like this:</p>
<pre><code>if (name) {<br /> __va_list ap;</code></pre>
<pre><code>__va_start(ap, name);<br /> crtc->name = kvasprintf(GFP_KERNEL, name, ap);<br /> __va_end(ap);<br /> } else {<br /> crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",<br /> drm_num_crtcs(dev));<br /> }</code></pre>
<p>The obvious fix is in sys/dev/drm/include/linux/compiler.h<br />to redefine __printf as __printf0like.</p>
<p>For curiosity's sake, given the gcc 4+ series of compilers now used for DragonFly in 2015<br />as opposed to 2004 when the __printflike and __printf0like distinction was made, is it<br />still necessary to have both __printflike and printf0like?</p> DragonFlyBSD - Submit #2904 (Closed): Update drm/uapi_drm to Linux 4.6https://bugs.dragonflybsd.org/issues/29042016-04-28T04:49:07Zdavshao
<p>Attached is a patch to update drm/uapi_drm to Linux 4.6. There should be no functional changes. The possible change in behavior in i915_drm.h, redefining the mask for invalid flags since new flags are added, is #ifdef-ed out.</p>
<p>The patch has been tested on a Intel integrated graphics gen7 Ivybridge machine and an AMD processor machine with a Sapphire Radeon HD6450.</p>
<p>The timeliness of this patch is because Matthew Macy of Nextbsd.org seems quite advanced in his own port of Linux 4.6 drm to FreeBSD, with work at</p>
<p><a class="external" href="https://github.com/iotamudelta/freebsd-base-graphics">https://github.com/iotamudelta/freebsd-base-graphics</a></p>
<p>With all the great work that has been done for DragonFly, there is no reason an independent effort should not make similar progress. I apologize if this is a duplicate of no doubt better work by those who have already contributed so much to DragonFly.</p> DragonFlyBSD - Bug #2903 (Closed): args->flags & ~(I915_MMAP_WC) 7ec9f8e589bca0a Linux scatterlis...https://bugs.dragonflybsd.org/issues/29032016-04-24T07:25:32Zdavshao
<p>Commit 7ec9f8e589bca0a drm/i915/gem: Switch to the Linux scatterlist API<br />does a bit more than that. Commenting out the newly added</p>
<pre><code>if (args->flags & ~(I915_MMAP_WC))<br /> return -EINVAL;</code></pre>
<p>in i915_gem.c allows an Asrock Z77M motherboard machine using current pkgsrc with dports patches backported to once again startx xfce4.</p>
<p>Given that using packages from dports on the same machine allows startx xfce4, it would appear the fault is mine for using a hacked version of pkgsrc; nonetheless, I don't have the slightest idea what to do in userspace to avoid the conflict with the newly added check.</p>
<p>As an aside, I don't understand the logic of the following code in i915_gem_gtt.c, so in the attached diff the addition is commented out as well:</p>
<pre><code>ppgtt->base.allocate_va_range = aliasing ? NULL : gen6_alloc_va_range;<br /> ppgtt->base.allocate_va_range = gen6_alloc_va_range;</code></pre> DragonFlyBSD - Bug #2893 (Closed): Don't clean /usr/obj/usr error: conflicting types for 'unctrl'https://bugs.dragonflybsd.org/issues/28932016-03-13T00:58:20Zdavshao
<p>Update through (I have been using full buildworlds after latest updates including cleaning /usr/obj/usr):</p>
<p>commit b34d3b9b8fa26892a7eb1f0fbf9a053d72798cd8<br />Date: Thu Mar 10 10:43:31 2016 +0200</p>
<pre><code>nrelease: Allow to build snapshots on tmpfs.</code></pre>
<p>After installation,</p>
<p>cd /usr/obj<br />mv usr usr.prev</p>
<p>because it appears one needs a functioning /usr/obj/usr to build anymore.</p>
<p>Now update through:</p>
<p>commit 3eec877432eb8056a5450dd96fad6f6abad016b9<br />Date: Fri Mar 11 20:11:40 2016 +0100</p>
<pre><code>ncurses: Upgrade version 5.9 (20110402) => 6.0 (20160305)</code></pre>
<p>cd /usr/src<br />make buildworld</p>
<p>Not long into the build, reproduced on 2 separate machines so far:</p>
<p>echo tic: /usr/obj/usr/src/btools_x86_64/usr/lib/libc.a /usr/obj/usr/src/btools_x86_64/usr/lib/priv/libprivate_ncurses.a >> .depend<br />cc -O -pipe -g -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -DSET_NCURSES_CH_T=cchar_t -DSET_NEED_WCHAR_H=1 -I/usr/src/usr.bin/tic/../../contrib/ncurses/progs -I. -I/usr/src/usr.bin/tic/../../contrib/ncurses/include -I/usr/src/usr.bin/tic/../../lib/libncurses/include -I/usr/src/usr.bin/tic -I/usr/obj/usr/src/btools_x86_64/usr/src/usr.bin/tic -std=gnu99 -Wmissing-include-dirs -Wsystem-headers -Wall -Wformat-security -Winit-self -Wno-pointer-sign -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c -o tic.o<br />In file included from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/progs.priv.h:121:0,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c:42:<br />/usr/src/usr.bin/tic/../../lib/libncurses/include/unctrl.h:60:38: error: conflicting types for 'unctrl'<br /> NCURSES_EXPORT(NCURSES_CONST char <strong>) NCURSES_SP_NAME(unctrl) (SCREEN</strong>, chtype);<br /> ^<br />In file included from /usr/include/curses.h:1971:0,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/progs.priv.h:121,<br /> from /usr/src/usr.bin/tic/../../contrib/ncurses/progs/tic.c:42:<br />/usr/src/usr.bin/tic/../../lib/libncurses/include/unctrl.h:57:38: note: previous declaration of 'unctrl' was here<br /> NCURSES_EXPORT(NCURSES_CONST char *) unctrl (chtype);</p>
<ul>
<li>Error code 1</li>
</ul>
Stop.<br />make<sup><a href="#fn3">3</a></sup>: stopped in /usr/src/usr.bin/tic<br />sh /usr/src/tools/install.sh -o root -g wheel -m 555 tic /usr/obj/usr/src/btools_x86_64/usr/bin<br />install: tic: No such file or directory
<ul>
<li>Error code 71</li>
</ul>
<p>The /etc/make.conf used is:</p>
<p>CFLAGS+=-g<br />STRIP=</p>
<p>WITH_PKGNG=yes<br />DISABLE_VULNERABILITIES=yes</p>
<p>WITH_VIM_OPTIONS=yes</p>
<p>On one machine, moving back /usr/obj/usr allows<br />make quickworld<br />to complete successfully. However I have not attempted to install this world yet.</p> DragonFlyBSD - Bug #2836 (Closed): Removal of /usr/include/regex.h needs to be loudly announcedhttps://bugs.dragonflybsd.org/issues/28362015-08-09T01:06:20Zdavshao
<p>The removal of /usr/include/regex.h as a consequence of updating the regex library needs to be loudly announced, such as in UPDATING and on the user mailing list.</p>
<p>Software that used to do something like check for PCRE and if that fails check for a native regex library by searching for /usr/include/regex.h is now broken building. A prominent example of this is x11/xterm. In either dports or pkgsrc, try building xterm.</p>
<p>For the example of xterm, changing to enabling PCRE will probably fix the build. A more serious problem is that software that used to find DragonFly's native regex library will do something like dump core. An example of this is apparently pkgsrc's bmake, where one can see during its configuration that it is checking for regex.h. At least this is happening to me using latest 4.3-DEVELOPMENT and doing a full buildworld.</p>
<p>The change to the new regex library I believe should be treated as a flag day event, with users told to rebuild or obtain updated packages of all userland software.</p> DragonFlyBSD - Bug #2835 (New): /usr/include/c++/5.0/bits/c++locale.h likes _POSIX_C_SOURCE>=200809https://bugs.dragonflybsd.org/issues/28352015-08-04T15:05:55Zdavshao
<p>Using current master DragonFly, trying to build dports devel/ncurses or pkgsrc devel/ncurses fails with:</p>
<p>c++ -DHAVE_CONFIG_H -I. -I../../c++ -I../include -I../../c++/../include -D_BSD_TYPES -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -DNDEBUG -pipe -g -O2 -fno-strict-aliasing -fPIC -DPIC -c ../../c++/cursesmain.cc -o ../obj_s/cursesmain.o<br />In file included from /usr/include/c++/5.0/bits/localefwd.h:40:0,<br /> from /usr/include/c++/5.0/ios:41,<br /> from /usr/include/c++/5.0/ostream:38,<br /> from /usr/include/c++/5.0/iostream:39,<br /> from ../../c++/cursesmain.cc:39:<br />/usr/include/c++/5.0/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)':<br />/usr/include/c++/5.0/bits/c++locale.h:61:47: error: 'locale_t' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);<br /> ^<br />/usr/include/c++/5.0/bits/c++locale.h:61:62: error: 'uselocale' was not declared in this scope<br /> _<em>c_locale __old = (</em>_c_locale)uselocale((locale_t)__cloc);</p>
<p>I suspect the responsible change may be:</p>
<p>commit d1732c039257d5ff06e218b885a2d1ee92daa355<br />Date: Thu Jul 30 22:22:02 2015 +0200</p>
<pre><code>gcc50: Remove generic versions of added files</code></pre>
<p>where in particular<br />.../libstdc++-v3/config/locale/generic/c_locale.h <br />was removed.</p>
<p>c++/5.0/bits/c++locale.h contains<br />#include <clocale></p>
<p>/usr/include/c++/5.0/clocale contains<br />#include <locale.h></p>
<p>/usr/include/locale.h contains</p>
<p>#if __POSIX_VISIBLE >= 200809<br />#include <xlocale/_locale.h><br />#endif</p>
<p>locale_t appears to be defined in /usr/include/xlocale/_locale.h</p>
<p>And I believe __POSIX_VISIBLE is defined in cdefs.h where it is set depending on the value of _POSIX_C_SOURCE.</p>
<p>At least on pkgsrc devel/ncurses, the build was able to be completed when its configure was hacked similar to the following:</p>
<p>cf_POSIX_C_SOURCE=200809L<br />cf_XOPEN_SOURCE=700</p>
<p>Now the obvious workaround is simply to use the built-in ncurses. However I am wondering if in general the new recommendation for userland software is to edit their aclocal.m4's or whatever else they use defining</p>
<p>_POSIX_C_SOURCE=200809<br />_XOPEN_SOURCE=700</p>
<p>for DragonFly. And do they need to test the version of DragonFly?</p>
<p>Or would it be possible to put the deleted generic files back?</p> DragonFlyBSD - Bug #2834 (Resolved): Post 3.16 i915 drm freedesktop Bug 76554 one line fixhttps://bugs.dragonflybsd.org/issues/28342015-08-02T19:53:29Zdavshao
<p>After the update to Linux 3.16 i915 drm, Bug 76554 from freedesktop.org</p>
<p><a class="external" href="https://bugs.freedesktop.org/show_bug.cgi?id=76554">https://bugs.freedesktop.org/show_bug.cgi?id=76554</a></p>
<p>manifests itself on an Intel(R) Core2 Quad CPU Q9400 with G45 integrated graphics:</p>
<p>drm0: taking over the fictitious range 0xd0000000-0xe0000000<br />error: [drm:pid1054:init_ring_common] <strong>ERROR</strong> render ring initialization failed ctl 0001f001 (valid? 1) head 05663004 tail 00000000 start 00003000 [expected 00003000]<br />error: [drm:pid1054:i915_gem_init] <strong>ERROR</strong> Failed to initialize GPU, declaring it wedged</p>
<p>Fortunately Jiri Kosina found a 1-line workaround that is still there in the<br />Linux 4.0.8 code:</p>
<p><a class="external" href="https://bugs.freedesktop.org/attachment.cgi?id=104224">https://bugs.freedesktop.org/attachment.cgi?id=104224</a></p>
<p>This fix has been verified on the Q9400 machine to at least stop the error messages.</p>