r00t^2_projects::BUGS:: http://bugs.square-r00t.net/ r00t^2_projects::BUGS::BDisk: Recently edited tasks 2018-09-07T21:57:23Z FS#36: modify pkglist parsing of comments http://bugs.square-r00t.net/index.php?do=details&task_id=36 2018-09-07T21:57:23Z anonymous modify pkg list parsing to support inline commenting   (old content: tail -f chroot_install.log Hangs here: Log: https://pastebin.com/UaSJGznh) modify pkg list parsing to support inline commenting

 

(old content:

tail -f chroot_install.log

Hangs here: Log: https://pastebin.com/UaSJGznh)

]]>
FS#44: Add notes on providing manually-downloaded tarballs http://bugs.square-r00t.net/index.php?do=details&task_id=44 2018-04-17T14:50:19Z brent s. Add a mini-howto under the Advanced Customization section on how to provide a manually/externally-downloaded tarball. Add a mini-howto under the Advanced Customization section on how to provide a manually/externally-downloaded tarball.

]]>
FS#43: use Accept-Ranges: bytes for tarball/other downloads http://bugs.square-r00t.net/index.php?do=details&task_id=43 2018-04-17T14:43:03Z brent s. (recv'd via email) currently if a download fails, one has to scrap the download and start anew. see if urllib supports byteranges and if it does, we need to figure out the best way to manage a failed download from a process standpoint. (recv'd via email)

currently if a download fails, one has to scrap the download and start anew.

see if urllib supports byteranges and if it does, we need to figure out the best way to manage a failed download from a process standpoint.

]]>
FS#42: OibMku <a href="http://ycaakxndukvt.com/">ycaakxndukvt</a>, [url=http://lxinzicivvoa.com/]lxinziciv http://bugs.square-r00t.net/index.php?do=details&task_id=42 2018-04-17T14:38:36Z anonymous OibMku &lt;a href=&quot;http://ycaakxndukvt.com/&quot;&gt;ycaakxndukvt&lt;/a&gt;, [url=http://lxinzicivvoa.com/]lxinzicivvoa[/url], [link=http://ryrexkeqsdmt.com/]ryrexkeqsdmt[/link], http://evrvmugggtur.com/ OibMku <a href="http://ycaakxndukvt.com/">ycaakxndukvt</a>, [url=http://lxinzicivvoa.com/]lxinzicivvoa[/url], [link=http://ryrexkeqsdmt.com/]ryrexkeqsdmt[/link], http://evrvmugggtur.com/

]]>
FS#39: UEFI broken http://bugs.square-r00t.net/index.php?do=details&task_id=39 2018-04-15T19:50:45Z brent s. can no longer find loader.efi. probably some change made upstream in the systemd-boot package or whatever it's called that contains it. can no longer find loader.efi. probably some change made upstream in the systemd-boot package or whatever it's called that contains it.

]]>
FS#40: Feature Request: add ISO overlay http://bugs.square-r00t.net/index.php?do=details&task_id=40 2018-04-15T19:46:20Z GI Jack: All American zero I have a feature request, add an overlay for the iso file system. Needed to support memtest86+, intel microcode and other boot time options. I have a feature request, add an overlay for the iso file system. Needed to support memtest86+, intel microcode and other boot time options.

]]>
FS#41: Feature Request/Design Element: Move to profile based config http://bugs.square-r00t.net/index.php?do=details&task_id=41 2018-02-10T22:09:26Z GI Jack: All American zero As current, bdisk is configured to expect one build configuration per system. This is terrible for both workflow and for sharing your configurations.&lt;p&gt;Suggestion is to move to an instanced profile based solution.&lt;/p&gt;&lt;p&gt;i.e.&lt;/p&gt;&lt;p&gt;move /var/lib/bdisk to /usr/share/bdisk/defaultprofile&lt;/p&gt;&lt;p&gt;move /etc/bdisk/build.ini to /usr/share/bdisk/defaultprofile&lt;/p&gt;&lt;p&gt;each profile is and instance of this template, with build.ini in the root. default libs are in the same dir as build.ini&lt;/p&gt;&lt;p&gt;This allows for many profiles, and profiles to be shared and worked on on git.&lt;/p&gt;&lt;p&gt;When bdisk becomes multi-staged. There should be an option for bdisk --init-profile [directory] which creates a new project profile at specified directory, $PWD if blank&lt;/p&gt; As current, bdisk is configured to expect one build configuration per system. This is terrible for both workflow and for sharing your configurations.
<p>
Suggestion is to move to an instanced profile based solution.
</p><p>
i.e.
</p><p>
move /var/lib/bdisk to /usr/share/bdisk/defaultprofile
</p><p>
move /etc/bdisk/build.ini to /usr/share/bdisk/defaultprofile
</p><p>
each profile is and instance of this template, with build.ini in the root. default libs are in the same dir as build.ini
</p><p>
This allows for many profiles, and profiles to be shared and worked on on git.
</p><p>
When bdisk becomes multi-staged. There should be an option for bdisk --init-profile [directory] which creates a new project profile at specified directory, $PWD if blank</p>

]]>
FS#35: variablize kernel name in build.ini http://bugs.square-r00t.net/index.php?do=details&task_id=35 2018-01-14T08:46:30Z anonymous Make the name of the kernel a variable in build.ini. This allows for custom kernels. related patch from Ninja OS: https://gitlab.com/ninjaos/ninjaos-ng/commit/32c84056234768777bedbf62cb9f058d7eee65ea Make the name of the kernel a variable in build.ini. This allows for custom kernels.
related patch from Ninja OS: https://gitlab.com/ninjaos/ninjaos-ng/commit/32c84056234768777bedbf62cb9f058d7eee65ea

]]>
FS#34: Add build time support for only completeing single phase of build at a time http://bugs.square-r00t.net/index.php?do=details&task_id=34 2018-01-04T22:25:56Z anonymous Add a build time option for only completing one phase of the build process at a time For example: I would like be able to build the chroot without compiling the final .iso. I would also like to compile the final .iso from a previously build chroot without having to re-install the chroot. I would like to do this so I can work on the overlay without having to do a re-install. This would greatly speed up testing and debugging. Also, being able to install the base chroot without compiling the rest would aid in development. Just a design time decision to consider Add a build time option for only completing one phase of the build process at a time
For example: I would like be able to build the chroot without compiling the final .iso. I would also like to compile the final .iso from a previously build chroot without having to re-install the chroot. I would like to do this so I can work on the overlay without having to do a re-install. This would greatly speed up testing and debugging. Also, being able to install the base chroot without compiling the rest would aid in development. Just a design time decision to consider

]]>
FS#24: Run without root http://bugs.square-r00t.net/index.php?do=details&task_id=24 2018-01-04T22:25:19Z anonymous Please make it so bdisk will run without root. Please make it so bdisk will run without root.

]]>