DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082023-12-05T04:09:21ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Submit #3362 (New): Reduce package dependencies of sysutils/cdrtools in branch wit...https://bugs.dragonflybsd.org/issues/33622023-12-05T04:09:21Zmneumann
<p>Git branch withpkg.</p>
<p>Build `sysutils/cdrtools` without options DOCS, LAME and VORBIS. This should get rid of various dependent packages in `dports.base`.<br />We only need cdrtools for mkisofs, not for burning audio cds...</p> DragonFlyBSD - Submit #3355 (New): [PATCH] Port ext4 extents support from FreeBSDhttps://bugs.dragonflybsd.org/issues/33552023-08-23T03:03:33ZphcoderDragonFlyBSD - Submit #3276 (New): Add option controlling whether gpt expand expands the last par...https://bugs.dragonflybsd.org/issues/32762021-05-27T04:40:52Zfalsifian
<p>Just today I needed a version of the "gpt expand" command that doesn't extend the last partition. The attached patch adds a -x option; the last partition is only expanded if -x is specified.</p>
<p>I have done minimal testing:</p>
<p>- I successfully used it without <del>x after copying my laptop's data to a larger SSD, leaving plenty of space at the end for me to install DragonflyBSD on top of the two existing OSs :</del>)</p>
<p>- I did a really quick test with the -x option on a hastily created vnode disk initialized with gpt init. I just verified that after expanding with -x, the Dfly partition got bigger.</p>
<p>I'm happy to do more testing if requested, though I'm not sure exactly what to try.</p>
<p>(This patch changes the default behaviour. I suppose it could be reversed, but a "don't expand the last partition option" seems a bit more convoluted conceptually.)</p>
<p>Patch is vs. commit 42a874b478.</p> DragonFlyBSD - Submit #3227 (New): Add HAMMER2 instructions in the installation medium READMEhttps://bugs.dragonflybsd.org/issues/32272020-03-26T22:34:50Zdaftaupepierre-alain@toret.fr
<p>As it has been discussed on irc, here's an attempt to give at least basic instructions on how to install manually using HAMMER2.</p> DragonFlyBSD - Submit #3206 (In Progress): update psm/kbd to FreeBSD 12.0 codehttps://bugs.dragonflybsd.org/issues/32062019-09-19T19:21:35Zhtseharald.brinkhof@gmail.com
<p>updates code to this FreeBSD commit</p>
<p>commit 11b574d82f92a010ea507fe962cec39e38954c3a<br />Author: philip <<a class="email" href="mailto:philip@FreeBSD.org">philip@FreeBSD.org</a>><br />Date: Sun Jun 16 03:06:05 2019 +0000</p>
<pre><code>Add macOS-like three finger drag trackpad gesture to psm(4)</code></pre>
<p>Adds three-fingered drag, natural scrolling, a bunch of bugfixes, 4-5 finger support, ...</p> DragonFlyBSD - Submit #3201 (In Progress): Fixes make search displayhttps://bugs.dragonflybsd.org/issues/32012019-08-18T00:28:51Zhtseharald.brinkhof@gmail.com
<p>when doing /usr/dports/Makefile's 'make search'</p>
<p>the result is incorrectly displayed:<br /><pre>
B-deps is empty
R-deps is empty
WWW is empty
</pre></p>
<p>current:<br />--------<br /><pre>
Port: py27-wxPython30-3.0.2.0_7
Path: /usr/dports/x11-toolkits/py-wxPython30
Info: GUI toolkit for the Python programming language
Maint: python@FreeBSD.org
B-deps:
R-deps:
WWW:
</pre></p>
<p>corrections are done in Mk/bsd.port.subdir.mk, function changed starts at line 380:<br />fixed a typo and corrected the offsets</p>
<p>result:<br />-------<br /><pre>
Port: py27-wxPython30-3.0.2.0_7
Path: /usr/dports/x11-toolkits/py-wxPython30
Info: GUI toolkit for the Python programming language
Maint: python@FreeBSD.org
B-deps: /usr/dports/devel/gettext-runtime /usr/dports/devel/gettext-tools /usr/dports/devel/pkgconf /usr/dports/devel/py-setuptools /usr/dports/lang/python27 /usr/dports/x11-toolkits/wxgtk30
R-deps: /usr/dports/devel/gettext-runtime /usr/dports/devel/py-setuptools /usr/dports/lang/python27 /usr/dports/x11-toolkits/py-wxPython-common /usr/dports/x11-toolkits/wxgtk30
WWW: http://www.wxpython.org
</pre></p>
<p>which is the desired info-display</p> DragonFlyBSD - Submit #3154 (New): Update serial handling in bootloaderhttps://bugs.dragonflybsd.org/issues/31542018-11-01T19:43:25Zddegroot
<p>Allow changing serial baud rate in bootloader during boot1/boot2. The speed will automatically be taken over by the loader.</p>
<p>The patch contains multiple changes to improve serial handling through the bootprocess and <br />can be found here: <a class="external" href="https://github.com/DragonFlyBSD/DragonFlyBSD/pull/7">https://github.com/DragonFlyBSD/DragonFlyBSD/pull/7</a></p> DragonFlyBSD - Submit #3147 (New): Enable headless installationhttps://bugs.dragonflybsd.org/issues/31472018-10-08T10:20:30Zddegroot
<p>This patch allow installer frontend (dfuife_curses) to connect to the backend from a remote machine.</p>
<p>Patch also includes a small change to two installer makefiles, so that it can be build correctly from the /usr/src/nrelease directory (not sure if this change is formatted in a way that is acceptable).</p> DragonFlyBSD - Submit #3041 (New): firmware: Remove embedding of multiple images in one module.https://bugs.dragonflybsd.org/issues/30412017-05-25T12:23:23ZAnonymous
<p>Hello,</p>
<p>this patch removes possibility of embedding more than one firmware image in one kernel module through the parent reference in the firmware_register() function.</p>
<p>This patch is a preparation for firmware subsystem modification for moving firmware images from kernel modules to userland.</p>
<p>The mechanism is not used and it can be functionally fully replaced by putting each firmware image in its own module.</p>
<p>Removing the functionality significantly simplifies handling of firmware images. If firmware images are moved to userland the logical grouping of modules could be expressed by putting the related firmware images into one directory if needed.</p>
<p>jan</p> DragonFlyBSD - Submit #2717 (Feedback): Out of range numeric handlinghttps://bugs.dragonflybsd.org/issues/27172014-08-22T12:36:50Zdclinkdevnexen@gmail.com
<p>In a similar way than OpenBSD, the numeric values overflows are checked.</p> DragonFlyBSD - Submit #2438 (Feedback): TRIM fixeshttps://bugs.dragonflybsd.org/issues/24382012-10-22T04:59:20ZAnonymous
<p>This patch is to fix bugs associated with TRIM.</p>
<p>If trim is on as a option, display that when typing "mount".</p>
<p>Change post-trim ffs_blkfree_cg() to use taskqueue_swi_mp and get mp token when modifying freemap.</p>
<p>Make sure TRIM works with softdep. Stash a copy of that vnode's mount point in the ufs inode so that if we are using softdep, we can get access to the mount point through the faked up inode (created in freeblocks). The original mount point path (ip->i_devvp->v_mount->mnt_flag) doesn't have the mount point options.</p>
<p>Tim</p> DragonFlyBSD - Submit #2122 (New): [Review] Fixes to the VFS layerhttps://bugs.dragonflybsd.org/issues/21222011-08-28T17:26:29Zftigeot
<p>Hi,</p>
<p>While working on the vfs-quota branch, I found some problems in the existing<br />kernel VFS code.</p>
<p>The attached patches correspond to local commits I have created to fix them.<br />I'm not too sure if what I've done is ideal, and I'd like these patches<br />to be reviewed before pushing them to master (or not).</p>
<p>They have been applied to two of my machines (one desktop, one database<br />server), and do not seem to cause any problem.</p> DragonFlyBSD - Submit #2098 (New): [PATCH] correct ath man page example (/usr/src/share/man/man4/...https://bugs.dragonflybsd.org/issues/20982011-06-29T04:12:50Znobody
<p>152c152<br />< wepmode on wepkey 0x8736639624 weptxkey 1 up<br />---<br /> > wepmode on wepkey 0x8736639624</p> DragonFlyBSD - Submit #1700 (In Progress): skip boot2 menu on <enter>https://bugs.dragonflybsd.org/issues/17002010-03-22T00:07:18ZJohannes.Hofmann
<p>Hi,</p>
<p>tuxillo noticed that the trick to speedup booting by hitting <enter><br />does not work with default UFS-based installations, as those have no<br />separate /boot partition, and therefore the default location for the<br />loader is wrong (it had been changed to match default HAMMER<br />installations in <a class="changeset" title="boot - Switch boot2 loader path around * Test /loader first, then /boot/loader, makes hitting en..." href="https://bugs.dragonflybsd.org/projects/dragonfly/repository/dragonflybsd/revisions/3735e368a1bdbe773c79c34512f49c905ff77bd7">3735e368a1bdbe773c79c34512f49c905ff77bd7</a>)</p>
<p>We could change boot2 to just continue it's normal operation without<br />entering the prompt when the user hits <enter>. That way one can avoid<br />the delay on UFS and HAMMER systems:</p>
<pre>
<code class="ruby syntaxhl" data-language="ruby"><span class="n">diff</span> <span class="o">--</span><span class="n">git</span> <span class="n">a</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span> <span class="n">b</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="n">index</span> <span class="mi">459436</span><span class="n">f</span><span class="o">..</span><span class="mi">55516</span><span class="n">be</span> <span class="mi">100644</span>
<span class="o">---</span> <span class="n">a</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="o">+++</span> <span class="n">b</span><span class="o">/</span><span class="n">sys</span><span class="o">/</span><span class="n">boot</span><span class="o">/</span><span class="n">pc32</span><span class="o">/</span><span class="n">boot2</span><span class="o">/</span><span class="n">boot2</span><span class="p">.</span><span class="nf">c</span>
<span class="err">@@</span> <span class="o">-</span><span class="mi">346</span><span class="p">,</span><span class="mi">7</span> <span class="o">+</span><span class="mi">346</span><span class="p">,</span><span class="mi">7</span> <span class="err">@@</span> <span class="n">main</span><span class="p">(</span><span class="n">void</span><span class="p">)</span>
<span class="o">*</span><span class="sr">/
if (autoboot && !*kname) {
memcpy(kname, PATH_BOOT3, sizeof(PATH_BOOT3));
- if (!keyhit(3*SECOND)) {
+ if (!keyhit(3*SECOND) || xgetc(0) == '\r') {
load();
memcpy(kname, PATH_BOOT3_ALT, sizeof(PATH_BOOT3_ALT));
load();
</span></code><br /></pre>
<p>To actually enter the prompt one has to hit any other key (e.g. Esc).</p>
<p>The check for '\r' works ok for me, but maybe we also need to check<br />for '\n'?</p>
<p>Cheers,<br />Johannes</p> DragonFlyBSD - Submit #1398 (In Progress): hdestroy(3) restricts hash key to point to malloc'ed s...https://bugs.dragonflybsd.org/issues/13982009-06-11T02:08:49ZAnonymous
<p>Salute.</p>
<p>hdestroy(3) frees the memory pointed to by the hash key. In other words it expects the user to always have malloc()'ed rather than used static allocation for the hash key. This doesn't apply to the data associated with the key.</p>
<p>Although POSIX standard doesn't say much on this particular topic:</p>
<ol>
<li>This is unnecessarily restrictive. If the user wants static allocation, we should allow this. If she wants dynamic then let <strong>her</strong> free the memory she malloc()'ed.</li>
<li>It is in conflict with the example code in the POSIX page. The code segfaults if you add an hdestroy() call in the end of it.</li>
<li>Programs that target other implementations may segfault in DragonFly (that'show I discovered it). AFAIK sunOS 5.10 and a recent glibc work fine, whereas {Net, Free, DragonFly}BSD all are affected because they share the same code. (One could argue that all programs written with the *BSD version in mind would<br />result in a memory leak. But still I think these programs (if any) should be fixed.)</li>
</ol>
<p>Any thoughts ?</p>
<p>Cheers,<br />Stathis</p>