Source: python-fitsio
Version: 0.9.11+dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Hi!
First seen on the build arm-arm-01 which is an arm64 machine
configured to build for armhf, build log at
https://buildd.debian.org/status/fetch.php?pk
On Wed, Jul 04, 2018 at 04:56:30PM +0100, Steve McIntyre wrote:
>Source: python-fitsio
>Version: 0.9.11+dfsg-1
>Severity: serious
>Justification: fails to build from source (but built successfully in the past)
>
>Hi!
>
>First seen on the build arm-arm-01 which is an arm6
Package: gvfsd-metadata
Version: 1.30.4-1
Severity: serious
Hi folks,
I appear to have had some of the gvfs packages installed by accident
on my machine, I guess through dependencies. I noticed this a few days
ago and purged them all. I saw no errors when I did that. I noticed
again today that I
Control: reassign -1 gvfs-daemons
Arg, failed at cut and paste for the package name. -ENOSLEEP :-(
On Mon, Sep 17, 2018 at 05:23:53PM +0100, Steve McIntyre wrote:
>Package: gvfsd-metadata
>Version: 1.30.4-1
>Severity: serious
>
>Hi folks,
>
>I appear to have had some
;Severity: critical
>Tags: d-i
>Justification: breaks the whole system
...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don
On Fri, Sep 15, 2017 at 06:15:08PM +0100, Steve McIntyre wrote:
>It's blocking KDE live builds at the moment...
*tumbleweed*
Two months later, we still have no fix for this "closed" bug anywhere
except experimental. Any chance of this being properly fixed soon?
--
Steve McInt
e live build problem. Doesn't like the best of ways, maybe?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters
the command line you're using. I'd expect to
see something more like:
efibootmgr -c -L debian -l \EFI\debian\grubx64.efi
(maybe along with some other options).
grub-install -v will show you exactly what commands grub is trying to
use.
--
Steve McIntyre, Cambridge, UK.
Control: severity -1 important
[ Please CC the bug report address 845...@bug.debian.org so other
people can follow this conversation too... ]
On Sat, Nov 19, 2016 at 08:08:58PM +0300, Vladimir Stavrinov wrote:
>On Sat, Nov 19, 2016 at 03:55:43PM +0000, Steve McIntyre wrote:
>
>>
bian 4.9.144-4~20190217~1 (2019-02-17)
>armv7l GNU/Linux
Yes, me too. Built similar and tested on the Marvell Armada XP here
and it solved the problem.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
ed kernelci as a useful thing to help here,
but we really need to be testing kernels complete with all the Debian
patches to...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with "Valor": "Centurion" represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
t: [PATCH] Update debian/arm-avoid-abi-change-in-4.9.139.patch (Closes:
> #922478).
>
>This makes it take into account the function pointers reordering in
>arch/arm/mm/proc-macros.S (addition of check_bugs), fixing the failure
>to boot many armhf devices.
>
>With thanks to Adrian
nsiders that the desireable solution at the time
> of bullseye is `weak`; and asks the debootstrap maintainers to disable
> "merged `/usr`" by default.
There is a deeper worry about builds that may be done against the
"weak" background. Although buildd
a721-cbcf5095c5cf
>
>Lenovo ThinkPad T480s System Firmware Version 1.29.
This isn't a bug in fwupd, it's a problem with the Lenovo firmware
throwing away boot entries on upgrade. There's very little we can do
about that. :-/
--
Steve McIntyre, Cambridge, UK.
his already and I just need
to roll out a new release. Coming very soon - I'm at DebConf at the
moment so time is tight for the next few days.
See https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git
for the latest code if you're interested.
--
Steve McIntyre, Cambridge, UK.
On Wed, Jan 02, 2019 at 11:28:19AM +0200, Timo Lindfors wrote:
>Hi,
>
>On Sat, 29 Dec 2018, Steve McIntyre wrote:
>> Package: src:qi
>> Version: 2013-1
>> Severity: serious
>> Justification: fails to build from source (but built successfully in the
>
ild a
single-CD installer image for xfce. If that's now looking too small
and is missing key packages, I'll check and see what we can do. But we
may now be forced to drop it - we've already worked on minimisation
several times in the last few years.
--
Steve McIntyre, Cambridge, UK.
Package: src:frown
Version: 0.6.2.3-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning
Package: src:spark
Version: 2012.0.deb-11
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
plan
Package: src:thumbor
Version: 6.5.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I've been doing a full rebuild of the Debian archive, building all
source packages targeting armel and armhf using arm64 hardware. We are
planning
f this issue.
ACK. As far as I can see from the kernel source, KASLR has been around
for arm64 since 2016. I'm rebuilding now with the 'world' tests
disabled to verify that's the only problem.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Da
On Sat, Jan 12, 2019 at 01:06:22AM +0100, Andreas Henriksson wrote:
>On Tue, Dec 04, 2018 at 02:53:22AM +0000, Steve McIntyre wrote:
>> ACK, thanks for the pointer. I'm a few releases behind due to lack of
>> time. Hoping to get that fixed shortly...
>
>For your conveni
ng to go that way soon. Our plan is to
switch to building for armel and armhf using arm64 machines before too
long, which would reliably break all packages with bugs like this.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
S
On Mon, Jan 28, 2019 at 10:34:54AM -0800, Steve Langasek wrote:
>On Mon, Jan 28, 2019 at 12:45:22PM +0000, Steve McIntyre wrote:
>> Hi Alastair,
>
>> On Mon, Jan 28, 2019 at 09:50:30AM +, Alastair McKinstry wrote:
>
>> >Yes, thanka for this patch. I'm reluct
Package: cdimage.debian.org
Severity: serious
Tags: d-i
As mentioned by bwh: existing armel and armhf installer CDs are
currently missing vmlinuz and the initramfs...
-- System Information:
Debian Release: 8.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign
ore enabling such a
broken mis-feature in the first place?
We already have a packaging system that works for upgrades in place
without needing reboots like this. I strongly object to this kind of
crap being added to Debian for the sake of certain broken upstream
soft
cross objects may fail
>collect2: error: ld returned 1 exit status
>/build/1st/efibootmgr-14/Make.rules:21: recipe for target 'efibootmgr' failed
Confirmed - just seen the same build failure on a porter box. Looks
like YA issue found with newer gcc. I'll look for a fix.
--
Control: tag -1 +pending
On Wed, Jan 04, 2017 at 07:04:59PM +, Steve McIntyre wrote:
>On Thu, Dec 29, 2016 at 03:22:02PM +, Chris West (Faux) wrote:
>>
>>The package fails to build on armhf:
...
>Confirmed - just seen the same build failure on a porter box. Looks
&g
VM install it is clear that the
>local DNS server returns the correct response, but this is being ignored
>or lost by the D-I initrd.
For the sake of completeness, I can confirm that the same problem
shows up when running on a different network too. I also see this
using the oldest amd64 dai
we could do to fail the build if versions are out of
sync, rather than let a broken build through?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.
've just queued these up in our repo for the next grub upload, due in
a few days.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a r
ic knowledge to cope with issues like this.
If we don't allow for this kind of change, that wouldn't allow us to
*ever* make breaking changes in some packages, and that's just not
sustainable.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Arm
On Tue, Feb 14, 2023 at 12:50:18PM +0100, Daniel Leidert wrote:
>Am Dienstag, dem 14.02.2023 um 10:45 + schrieb Steve McIntyre:
>> On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote:
>> > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o:
>
rypt
>parameters `%s'"),
>++ params);
>++ cipher_mode = grub_strndup (c, seek_head - c);
>++ if (cipher_mode == NULL)
>++grub_util_error (_("could not strndup cipher_mode of length
>`%lu'
Control: tag -1 pending
Hello,
Bug #1028301 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/grub-team/grub/-/commit/7fd3d6f6574fe38c0f6f21d6e62837b353c
gt;
>I have now uploaded this package to unstable, DELAYED/2.
Argh, no. I've taken your changes already, but I'm in the middle of
some other grub work. Let's not waste time and effort on an NMU going
through the system, complete with signing etc.
--
Steve McIntyre, Cambridge, U
Control: tag -1 pending
Hello,
Bug #1033913 in partman-efi reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/installer-team/partman-efi/-/commit/fcd3c59e48dcf4a96
so, GRUB may boot
>them directly without a /boot partition.
Hmmm, maybe.
>4) It appears that partman fails to detect the specially crafted partition
>table on the installation media created with a debian image. Is it intended
>or fortunately unintentional ? If partman could see the EFI partition on the
>installation media, the detection of BIOS-bootable systems would fail.
That's not a worry for today... :-)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
I've just pushed an update to the code here...
On Mon, Apr 10, 2023 at 05:45:15PM +0200, Pascal Hambourg wrote:
>On 10/04/2023 at 15:13, Steve McIntyre wrote:
>>
>> Overall comment: I'm not trying to make the heuristics 100% reliable
>> here, as I don't thi
no longer supports the GRUB_ENABLE_LINUX_LABEL
>parameters and has to be re-written for it to work.
Looking in the history, I can't see where we've ever supported
this. Can you tell me which version(s) ever had this working for you
please?
--
Steve McIntyre, Cambridge, UK.
quot; as shown below, and previously done in commit 334e9afa
>("Switch to using gcc-10 rather than gcc-9. Closes: #978521")?
>The resulting shimx64.efi boots fine here.
I've already done this, but shim is not a package that can just be
tweaked and uploaded. I'm in the mid
(and the upload is old
>enough to migrate to testing).
>
>If I'm going to do the NMU I'll need to proceed very soon so your input
>on this would be very appreciated if you could give it ASAP!
>What do you think?
Please feel free to NMU, I was hoping to get back to s
dy #1035382 open on the live side, let's
bump the severity on that.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
naming things.”
-– Jeff Waugh (https://twitter.com/jdub)
Hey,
The first patch committed here allows people to uninstall
raspi-firmware more easily. I suggest the attached to make things
easier for people even before that removal...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Getting a SCSI chain working is
d the
>files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked
>in any way (no soft or hardlink) and the ID inside the files differ
>from each other.
I've confirmed this bug just now, doing a clean installation from the
12.0
r own installation by deleting OS files for no good reason. If
>someone wants to mess manually with /etc/machine-id and
>/var/lib/dbus/machine-id it's fair that they are allowed to do that,
>but it's also fair to tell them that they get to keep the pieces.
Agreed, 100%.
--
Stev
n this regularly for months now. It seems that we
now finally have movement on the certificate front and I'm hoping
we'll be able to get stuff unblocked in the next couple of weeks.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Rarely is anyone th
Control: tag -1 pending
Hello,
Bug #1021846 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/grub-team/grub/-/commit/552fb3133016abd9b4f49bbafcab5d9b3cd
Control: tag -1 pending
Hello,
Bug #1022184 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/grub-team/grub/-/commit/16895d90dd915342bbb8593c403849b6ba9
thanks for confirming!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
Package: grub2-common
Version: 2.02+dfsg1-18
Severity: serious
Hey Colin,
Now that we have shim and signed binaries in the archive, the extra
code to install grubXXX.efi to the removable media path has to take
this into account too, or people using secure boot will end up with
broken systems that
Source: grub2
Version: 2.02+dfsg1-19
Severity: serious
Tags: patch
The grub-efi-amd64-signed package recommends shim-signed, but the
equivalent grub-efi-ia32-signed and grub-efi-arm64-signed packages are
missing the same Recommends:
Simple tweak needed to the signing-template, MR ready as soon as
On Tue, Jun 25, 2019 at 12:17:20AM +0100, Steve McIntyre wrote:
>Source: grub2
>Version: 2.02+dfsg1-19
>Severity: serious
>Tags: patch
>
>The grub-efi-amd64-signed package recommends shim-signed, but the
>equivalent grub-efi-ia32-signed and grub-efi-arm64-signed packages
Control: tag -1 pending
Hello,
Bug #931038 in grub2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/grub-team/grub/commit/00e557deedd68328e2f1d1352f84953169bf5e
K. We have just got new signed shim binaries back from Microsoft
last week, and we'll be publishing updated packages soon.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
stall --force
>"/dev/sda1"' failed.
>
>The bootloader installs normally using the Buster CD installers on the same
>hardware.
Just a quick sanity check - how did you partition the disk? Does it
have the normal boot partition etc. needed for OpenPOWER? I'll admit
Package: shim-signed
Version: 1.36~1+15.4-5~deb10u1
Severity: grave
Argh.
In pre-release testing I found problems with shim on signed versions
of shim on arm64. The shim binary crashes very early (Synchronous
Exception). Because of that problem, I took the hard decision to
disable Secure Boot sup
able mirroring here. I was not
expecting we'd need it, but it looks like I was wrong.
In terms of making your system boot, I'd suggest temporarily one of:
* switch back to an older shim-signed package
* disable Secure Boot and remove shim-signed
--
Steve McIntyre, Cambridge, UK.
ed* amd64 shim binary, and a checksum file. If you
would be so kind, please copy that shimx64.efi binary into place on
your system and test it boots OK. It may still complain about resource
failures and "import_mok_state() failed", but should then boot anyway
in
back to an older package of shim-signed and shim-signed-common.
ACK, that's the best thing for now.
>One caveat:
>I could not get the older package version via the official package repository
>anymore. Luckily I still had a copy of the old package in a local repository
>mirror.
OK. There's one thing I possibly should have mentioned here, then!
https://snapshot.debian.org/ carries ~all the packages that are ever
uploaded to Debian, so you should almost always be able to find older
packages there. I use it quite frequently as a developer, but I guess
it's not so well know amongst users!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
course, since many of them are Australians, you can't tell." -- Linus Torvalds
On Wed, Jun 23, 2021 at 01:00:51PM +0200, Grzegorz Szymaszek wrote:
>On Tue, Jun 22, 2021 at 10:36:48PM +0100, Steve McIntyre wrote:
>> Could you please verify if this new build fixes the problem you're
>> seeing on your hardware? […] It may still complain about reso
beb971-7, 1.36~1+deb10u2+15.4-5~deb10u1)
>
>--> System does not boot - as expected.
>
>2. Replace /boot/efi/EFI/debian/shimx64.efi with provided build
>
>--> System boots.
Perfect, thanks very much for helping with testing!
--
Steve McIntyre, Cambridge, UK.
w we can't have it all in a single source package, right?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
.
We're in a bind here - by now I was hoping/assuming that we'd have the
signing queue running automatically. I've just prodded in #debian-ftp
to ask people to run the queue.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"War does not determine who is right - only who is left."
-- Bertrand Russell
On Mon, Feb 15, 2021 at 04:35:37PM +0100, Ivo De Decker wrote:
>Hi Steve,
>
>Thanks for the info.
>
>On Mon, Feb 15, 2021 at 12:43:33AM +, Steve McIntyre wrote:
>> >Could you clarify the timing for this, especially the timeline for getting
>> >the
>> &g
ot binNMU-friendly. Please consider setting a version
>> > > range to allow binNMU-ed package to satisfy the dependency
>> > > relationship.
>>
>> Please consider reading https://wiki.debian.org/binNMU and see how can
>> things be improved.
>>
>&g
Control: tag -1 pending
Hello,
Bug #971946 in libdebian-installer reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/installer-team/libdebian-installer/-/commit/05
Source: xfsprogs
Version: 5.10.0-2
Severity: serious
Tags: d-i
Hi folks,
It appears that the latest version of xfsprogs (5.10.0) has just grown
a dependency on libinih1, and there isn't a udeb version of libinih to
meet that dependency. This means that xfs support in d-i just
broke. When trying t
t the
moment, but there's a couple of upstream patches we'll need to take as
well yet I think. It'll be coming soon, I promise.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
Hey Ivo,
On Sun, Feb 14, 2021 at 07:56:20PM +0100, Ivo De Decker wrote:
>On Fri, Feb 12, 2021 at 01:35:52AM +0000, Steve McIntyre wrote:
>> On Tue, Feb 09, 2021 at 04:26:02PM +0100, Ivo De Decker wrote:
>> >Hi Steve,
>> >
>> >On Sun, Sep 27, 2020 at 08
68k.
ACK. If you're happy to take ove cdrkit for now, I'd be very happy. I
don't have the time to care for it any more. Thomas has been doing a
great job with xorriso and friends, so it would be lovely to see us no
longer need to keep the old code around any more...
--
Steve Mc
Either
the package doesn't support non-x86, or there's a bug and it's
mis-detecting which platform you're on.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
>efibootmgr: option requires an argument -- 'd'
>efibootmgr version 14
OK, that's odd. Can you run "grub-install -v --target=arm64-efi" and
grab the output please? Curious to see exactly what the full command
line for efibootmgr is here...
--
Steve McIntyre, Cambridge
5.0-6+deb8u2
ii mbr 1.1.11-5+b1
ii parted 3.2-7
ii qemu-utils 1:2.1+dfsg-12+deb8u6
openstack-debian-images recommends no packages.
openstack-debian-images suggests no packages.
-- no debconf information
>From 12c5e3a7de103e6cb73235cff6d11180a225c98c Mon Sep 17 00
here. I need to update the
update-cd script to use better hashes than just md5sum for the update
images. This setup has worked for a very long time, but newer versions
of apt won't accept it any more. Looking into a fix now...
--
Steve McIntyre, Cambridge, UK.
64 (x86_64)
>
>Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
>Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>
>
--
Steve McIntyre, Cambridge, UK.st...
came up. I tried
>several combinations of --target --boot-directory --recheck
>--efi-directory but with no luck.
>
> * What outcome did you expect instead?
>
>I expected grub to use 'main's grub.cfg instead of 'rescue's.
How exactly are you booting each of the systems?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
I'm uploading this to unstable now rather than to DELAYED; there's not
been any obvious maintainer activity here for ages...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ied gparted locally and it seemed to work OK for me. Could
you give us more information about exactly what you did to trigger
this please?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Simple fix for build failure is to add --no-dynamic-linker to the
linker command lines. Here's the NMU diff; this is in incoming now...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
diff -Nr
Control: severity -1 important
Agreed that this is important, but we don't have lots of similar
reports since jessie d-i RC1 ~two years ago.
Heiko - could you possibly try a newer version of the installer and
see if the problem still exists please?
--
Steve McIntyre, Cambridg
which would help. While that's not implemented, at the very least
I'm thinking about error checking in grub-install. Simply
suggesting the user looks in /sys/fs/pstore and maybe delete things
would be better than the current "can't boot" issue.
--
Steve McI
Package: grub2-common
Version: 2.02~beta2-22+deb8u1
Severity: serious
Tags: upstream
Hi,
As can be seen in #852513 (for example), grub-install will happily
ignore errors from efibootmgr and claim "Installation finished. No
error reported". This is clearly bogus, and can lead to users with
unboota
ignores errors from efibootmgr
I have a simple fix for this which I'm about to post upstream.
* #853237 (efibootmgr): ENOSPC errors should be more helpful
Data from you would be helpful here!
Thanks!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Welco
On Mon, Jan 30, 2017 at 06:32:00PM +, Steve McIntyre wrote:
>Package: grub2-common
>Version: 2.02~beta2-22+deb8u1
>Severity: serious
>Tags: upstream
>
>Hi,
>
>As can be seen in #852513 (for example), grub-install will happily
>ignore errors from efibootmgr and claim
ng consistent ABI flags.
If you're worried about EABIv4, does the logic of the dpkg checker not
match the checks we added in glibc itself?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
On Wed, Feb 01, 2017 at 05:03:13PM +0100, Jens Reyer wrote:
>On 02/01/2017 04:34 PM, Steve McIntyre wrote:
>>
>> Please don't go down that route, the ABI flags are intended to save
>> people from that. I'm curious what's going wrong with libgsm1 here
>>
Hi,
On Thu, Feb 02, 2017 at 05:10:14AM +0100, Guillem Jover wrote:
>On Wed, 2017-02-01 at 15:34:04 +0000, Steve McIntyre wrote:
>>
>> Please don't go down that route, the ABI flags are intended to save
>> people from that. I'm curious what's going wrong with
On Thu, Feb 02, 2017 at 02:42:26PM +0100, Jens Reyer wrote:
>On 02/02/2017 02:30 PM, Steve McIntyre wrote:
>> Dropping the -nostdlib argument to the gcc call inside sonames2elf
>> makes a difference - it'll add libc6 to the mix and force the output
>> to match the syste
On Fri, Aug 04, 2017 at 05:51:45PM +0100, Steve McIntyre wrote:
>On Thu, Aug 03, 2017 at 04:11:23PM -0700, Nicholas Dreyer wrote:
>>
>>Built iso image, then burnt it to a DVD using jigdo information from here:
>>
>> http://cdimage.debian.org/debian-cd/current/i386/ji
or verifying!
>I do not understand the (apparently bogus) warnings about non-existent
>Release files, but they do not seem represent any real trouble.
ACK. AFAICS that's most likely due to the DVDs not including
signatures. That's a separate issue and a much harder change...
--
S
entical?
Yes. They're all set up the same, connected to the same patch panel to
the same switch. What has changed in the last few weeks is that a
broken fibre uplink was swapped out. That was causing problems on
uploads for a while, but it's now fixed. I don't see enough
consi
Source: grub2
Version: 2.02+dfsg1-16
Severity: serious
Tags: security
In discussion with upstream EFI and arm64 folks, it's become clear
that in SB mode we should also be disabling the devicetree command in
Secure Boot mode. I'm testing a patch right now, coming shortly.
-- System Information:
De
On Wed, Apr 24, 2019 at 05:26:00PM +0100, Steve McIntyre wrote:
>Source: grub2
>Version: 2.02+dfsg1-16
>Severity: serious
>Tags: security
>
>In discussion with upstream EFI and arm64 folks, it's become clear
>that in SB mode we should also be disabling the devicetree co
On Wed, Apr 24, 2019 at 05:37:24PM +0100, Steve McIntyre wrote:
>On Wed, Apr 24, 2019 at 05:26:00PM +0100, Steve McIntyre wrote:
>>Source: grub2
>>Version: 2.02+dfsg1-16
>>Severity: serious
>>Tags: security
>>
>>In discussion with upstream EFI and arm64 fol
On Sat, May 04, 2019 at 10:44:26PM +0100, Colin Watson wrote:
>On Fri, May 03, 2019 at 10:42:34PM +0100, Steve McIntyre wrote:
>> diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
>> index c9aee74ef..735c56e45 100644
>> --- a/grub-core/loader/efi/fdt.c
>
ing at all special about your test setup that I should ba
aware of? I'm pondering if there's maybe a locale setup difference or
something, but that's just a guess OTTOMH...!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait: http
is
>useless. So either we convince David to reconsider or a workaround has to
>be found.
Julian has just uploaded with the fix we need, so that should make
things better. Dropping severity.
(We'll probably need a fix for #990669, even so...)
--
Steve McIntyre, Cambridge, UK.
in grub:
The "issue" is definitely coming from grub-efi-$ARCH, but it's
behaving as designed here. Continuing despite failing to update the
EFI boot vars here will potentially leave you with an unbootable
system.
--
Steve McIntyre, Cambridge, UK.
as working firmware which supports setting UEFI boot variables. If
you *also* need to write a copy of grub (etc.) to the removable media
location (EFI/boot) then that's supported as well by the Debian
packaging - run "dpkg-reconfigure grub-efi-arm64" and say yes when the
system asks abou
1 - 100 of 522 matches
Mail list logo
