This was recently addressed via
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/40694280efc5c3d40dbb6d89dbdc7b2ae69f4968
and
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/7f2ed354cc8f966de444b8c278c208ea4e13ef75
Looks like this can be closed as "fixed" now.
Ping - any news on this?
Package: dosfstools
Version: 4.2-1
As upstream maintenance has stalled [1], the long-integrated commit to
add SOURCE_DATE_EPOCH support [2] is missing even in the latest Debian
package as there were no further upstream releases. This breaks building
of reproducible disk images and forces us to
Package: gnu-efi
Version: 3.0.18-1
Severity: important
Somewhere after 3.0.15, upstream gnu-efi broke armhf users. Specifically
the current EFI Boot Guard kernel stub (0.18-1+b1) for trixie/sid does
not start on armhf (tested via isar-cip-core integration [1][2]):
...
Full path for kernel is:
Quoting mistake and some other shellcheck finding addressed in
https://salsa.debian.org/jan-kiszka/initramfs-tools/-/commit/356e11370643f100dfc10e32b16c9dab506675aa
Pipeline is now green:
https://salsa.debian.org/jan-kiszka/initramfs-tools/-/pipelines/722208
recipes in
isar. I'm sure there are nicer ways to achieve the same, and the above
may even have some issues I missed. But it would be great if something
like this could be integrated into that standard package.
[1] https://github.com/ilbers/isar/
[2]
https://salsa.debian.org/jan-kiszka/initramfs-tools/-/commit/17d04411408f693e1af8949b17a6aed89ccc73a2
Quirin, I don't you have a local version working using the isar-cip-core
integration?
Chris, you could check if already the vanilla stub fails to run as EFI
binary. It should at least print "Unified kernel stub (EFI Boot Guard
v0.17)" and "Missing .kernel section" when there is no kernel linked to
Package: release.debian.org
Please align the uploaded versions of libgssapi-krb5-2 so that
cross-building is working again for riscv64.
TIA,
Jan
Package: release.debian.org
Please align the uploaded versions of sqlite3 packages so that
cross-building against some lib of this source is working for riscv64.
TIA,
Jan
Package: libkeyutils1
Version: 1.6.3-2+b1
Currently, libkeyutils1 is the last blocker to automatically set up an
essential cross-build environments for riscv64:
$ docker run --rm -it debian:sid
root@d897052b9483:/# dpkg --add-architecture riscv64
root@d897052b9483:/# apt update
...
root@032073e91
Sorry to bother, but I heard rumors about potential progress, just found
no update here yet. Was there a decision made, or are there even changes
pending now?
Upstream patch proposal sent:
https://sourceforge.net/p/gnu-efi/mailman/message/37684742/
Note that there is also the upstream ticket
https://sourceforge.net/p/gnu-efi/bugs/28/.
I'm not sure why EFI stacks would need to be executable. The better
solution should be resolving that upstream and meanwhile carrying a
gnu-efi patch. This does not only affect systemd-boot.
Package: swig4.0
Version: 4.0.2-1
Unfortunately, the last released upstream swig version lacked support
for nodejs12, which is the version that bullseye ships. I've identified
the following four patches from upstream that are needed on top of 4.0.2:
554aeead5 Introduce macros to support both Hand
Package: npm
Version: 7.4.0+ds-1~bpo10+2
Severity: grave
Justification: renders package unusable
Tried out via, e.g., "npm install serialport" inside a debian:buster-slim
container. Happens with both "npm node-*" as well only the required
node-packages takes from backports.
-- System Information:
Package: linux-image-amd64
Version: 5.10.4-1
In order to support the Ethernet controller found on Intel Elkhart Lake
SOCs which are STMMAC-based, CONFIG_DWMAC_INTEL and dependencies are
needed. Please enable.
Just to add my 2 cents after spending half of today debugging this issue
out of our kas-isar container [1]: Affects the buster version of
debootstrap as well. The proposed patch fixes it there, too.
Any plans to include this? Would be great!
Thanks,
Jan
[1]
https://groups.google.com/d/msgid/kas
Sent a MR to address the issue:
https://salsa.debian.org/debian/shadow/merge_requests/5
Package: u-boot-sunxi
Version: 2016.11+dfsg1-4
Severity: normal
Tags: patch
Dear Maintainer,
it seems reasonable to integrate
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=8792a64d87708139bc0cf8b48d4a580a39167473
into the stable version of u-boot-sunxi. I personally wasn't able to
reproduce a
On 2017-11-03 19:28, Andreas Metzler wrote:
> On 2017-11-03 Jan Kiszka wrote:
>> Has this topics also been brought up upstream already? Didn't find a
>> reference so far.
>
> No, I have not yet done so. The OCB licenses is listed in GIT's LICENSES
> file, it is
Has this topics also been brought up upstream already? Didn't find a
reference so far.
On 2015-06-27 17:04, Tobias Frost wrote:
> Am Samstag, den 27.06.2015, 15:54 +0200 schrieb Jan Kiszka:
>> On 2015-06-27 15:48, Tobias Frost wrote:
>>> Hallo everyone,
>>>
>>> as promised I bisected the issue and bisecting just finished.
>>> See belo
kernel in the Debian archives
> with that commit reverted to see if I can boot a more recent kernel.
Could you also collect /proc/cpuinfo of the affected systems?
Thanks,
Jan
>
> --
> tobi
>
>
> $ git bisect good
> acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5 is the first
On 2014-10-01 14:42, Christophe Thil wrote:
> I have attached the output of /proc/cpuinfo (kernel 3.16-2-amd64) and cpuid
> (20140123).
This is from my N2800:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 54
model name : Intel(R) Atom(TM) CPU N2800
e. If
>> 3.16 is booted with intel_idle.max_cstate=0 processor.max_cstate=0,
>> which disables the intel_idle, the CPU also stays cool.
> [...]
>
> It looks like the relevant change is:
>
> commit acead1b0fac5b10d0ae3f1cc5f7820b9f9f924f5
> Author: Jan Kiszka
> Date:
On 2013-11-01 11:10, Michael Tokarev wrote:
> 01.11.2013 13:54, Michael Büsch wrote:
>> On Fri, 01 Nov 2013 13:32:49 +0400
>> Michael Tokarev wrote:
>>
>>> That looks right. Are you okay adding your Signed-off-by to the patch
>>> you initially submitted? If yes, I'll make a formal patch submissi
On 2012-09-27 20:43, Michael Tokarev wrote:
> On 27.09.2012 22:28, Jan Kiszka wrote:
> []
>>> --- a/hw/intel-hda.c
>>> +++ b/hw/intel-hda.c
>>> @@ -1107,6 +1107,9 @@ static void intel_hda_reset(DeviceState *dev)
>>> DeviceState *qdev;
>>>
0xe0
> [ 36.055026] [] ? 0xa00a6fff
> [ 36.055026] [] alsa_card_azx_init+0x1e/0x1000
> [snd_hda_intel]
> [ 36.055026] [] do_one_initcall+0x12a/0x180
> [ 36.055026] [] sys_init_module+0x10f6/0x20b0
> [ 36.055026] [] system_call_fastpath+0x16/0x1b
>
> I
28 matches
Mail list logo
