e
of this bug; but it's been fixed upstream, so updating the Debian
package is the appropriate response, not removing it from Debian!
--
Rod Smith
rodsm...@rodsbooks.com
I believe I've fixed this bug. It's in the following commit to the GPT
fdisk git repository:
https://sourceforge.net/p/gptfdisk/code/ci/b056f3860ad587c01ed9e2a0bae6cc3ba8d41535/
I expect to make a new 1.0.9 release of GPT fdisk sometime in the next
few days, including this bug fix
Thanks for the bug report and patch. I've added the patch referenced in
this bug report to the GPT fdisk git repository. I expect to make a new
1.0.9 release with this fix in the next few days.
https://sourceforge.net/p/gptfdisk/code/ci/4be26d7228a5dadfd04488618f08a29f0c67dd8c/
--
Rod
Thanks for the patch! I've just added it to the GPT fdisk git repository:
https://sourceforge.net/p/gptfdisk/code/ci/8ff360f49eda175142e01d46edbb494cfebe309d/
(I expect to do a new release soon, FWIW.)
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
I've just added a fix for this; see:
https://sourceforge.net/p/gptfdisk/code/ci/6b7486db9927a1b3f6dd9cc84dff54c33a8aef8c/tree/gpt.cc?diff=4be26d7228a5dadfd04488618f08a29f0c67dd8c
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
;>> | make[2]: *** [Makefile:86: gnuefi] Error 2
>>> | make[2]: Leaving directory '/<>'
>>> | dh_auto_build: error: make -j1 gnuefi ARCH=x86_64 returned exit code 2
>>> | make[1]: *** [debian/rules:33: override_dh_auto_build] Error 25
>>> | make[1]: Leaving directory '/<>'
>>> | make: *** [debian/rules:26: build] Error 2
>>> | dpkg-buildpackage: error: debian/rules build subprocess returned exit
>>> status 2
>>>
>>> Also seen by crossqa:
>>> http://crossqa.debian.net
>>>
>>> Reproduced natively on arm64 by reproducible builds:
>>> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/refind_0.12.0-1.rbuild.log.gz
>>>
>>> Helmut
>>>
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
verride_dh_auto_build] Error 25
>> | make[1]: Leaving directory '/<>'
>> | make: *** [debian/rules:26: build] Error 2
>> | dpkg-buildpackage: error: debian/rules build subprocess returned exit
>> status 2
>>
>> Also seen by crossqa:
>> http://crossqa.debian.net
>>
>> Reproduced natively on arm64 by reproducible builds:
>> https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/refind_0.12.0-1.rbuild.log.gz
>>
>> Helmut
>>
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
browser
Note that I released rEFInd 0.11.5 a few days ago, and this commit is
the first since then.
As to efibootmgr requiring "/dev/nvme0n1p1", rather than the as-expected
"/dev/nvme0n1", as an option to "-d", that sounds like an efibootmgr
bug, and on my main test system (running Linux Mint 19, using efibootmgr
15-1), it takes "/dev/nvme0n1" and works correctly.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
ble filesystem driver in this context. OTOH, presenting a
disseration on the differences between the Linux vfat and msdos drivers
in this warning would be overkill. Probably changing "...it must be
VFAT!" to "...it must be VFAT (not msdos)!" would help. I've just pushed
that change to the rEFInd git repository.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
On 11/03/2016 02:16 PM, Tianon Gravi wrote:
> On 3 November 2016 at 11:03, Rod Smith wrote:
>> Good question. I guess it depends on what efibootmgr wants, since that's
>> where the variable is used. The efibootmgr man page implies it wants a
>> number, so I've commi
On 11/03/2016 01:29 PM, Tianon Gravi wrote:
> On 3 November 2016 at 10:28, Tianon Gravi wrote:
>> On 3 November 2016 at 10:19, Rod Smith wrote:
>>> Note, however, that I have no NVMe or similar devices on which to test.
>>> The new code does the right thing on my /dev/
xotic devices.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
ssary, I'll do a 0.10.1.1 release with Debian packaging
tweaks and we can base the first Debian release off of it.
I think that's about it. Unless there are other outstanding issues. I'm
ready to push this version for inclusion in Debian! Tianon, if you can
advise me on the next
e
applied to rEFInd.
I've collected enough changes in the main rEFInd package since 0.10.0
that I hope to push out a 0.10.1 version soon -- probably in a week or
two. My intent is to get the debian/copyright and other major packaging
files in order by that time so as to smooth the way to getting 0.10.1
included in the Debian repos, assuming no major unforseen hangup.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
Package: partman-efi
Severity: normal
Dear Maintainer,
The partman-efi package refers to the EFI System Partition (ESP) as an "EFI
boot partition." The latter name is non-standard; AFAIK, it's used *only* in
partman-efi and tools derived from it, such as Ubuntu's ubiquity. It's
therefore potentia
Note that the parent package (rEFIt) is no longer maintained. I've
forked rEFIt into rEFInd (http://www.rodsbooks.com/refind) and I've
updated the gptsync program in rEFInd in such a way that this problem is
fixed; however, at present, gptsync compiles only into an EFI binary.
Patches to suppor
t sure when the required features were added, but GNU-EFI 3.0p is
sufficient.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
y of my computers, but I'll get it up and running on one
of them. With any luck that'll enable me to reproduce and fix the bug.
In the meantime, the workaround for you is obvious: Use your
locally-compiled (with GCC 4.4.5) version of gdisk!
--
Rod Smith
rodsm...@rodsbooks.com
http://
'll look into
setting up a virtual ARM machine using QEMU, but it may be a few days
before I can get to that
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
19 matches
Mail list logo
