Here's an NMU diff that fixes the FTBFS. In incoming right now.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
now I want to be the first with a cranial firewall. " -- Charlie Stross
elp, but the merge isn't the hard bit here.
Tthe new upstream is a little problematic and I'm debugging some boot
failures in my local CI already.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
ort completes the restoration of the image with a
>constant
>transfer rate of +/- 41MB/sec.
>Regards.
What you're describing sounds just as likely to be a hardware problem
with the enclosure, to be honest. Does it work 100% reliably elsewhere?
--
Steve McIntyre, Cambridge, UK.
ins some really awful old C code, and it's taking a bit of
fixing. But I'm getting there...
--
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
t;endianconv.h"
>+ #include "checksum.h"
>++#include "md5.h"
>+ #endif
>+ #ifdef APPLE_HYB
>+ #include
>diff -Nru cdrkit-1.1.11/debian/patches/series
>cdrkit-1.1.11/debian/patches/series
>--- cdrkit-1.1.11/debian/patches/series2022-05-25
evant
>part.
>If required, the full build log is available here:
ACK, this is already known about. The pesign package no longer
provides efisiglist in unstable. I already have the necessary changes
made in shim in git, and we're due a new upload soon-ish.
--
Steve McIntyre, Cambridge, UK.
est to apply their patch rather than yours to make
>the code more consistent with upstream, do you agree?
>
>[1] https://github.com/libssh2/libssh2/issues/1240
>[2] https://github.com/libssh2/libssh2/pull/1241
Thanks, that looks sane enough here! :-)
--
Steve McIntyre, Cambridge, U
On Thu, Nov 23, 2023 at 10:46:34AM -0500, Nicolas Mora wrote:
>Le 2023-11-23 à 09 h 46, Steve McIntyre a écrit :
>>
>> Ah, apologies - that version is bogus, it's just the version on the
>> bullseye machine I ran reportbug from.
>>
>> The tests are failing on c
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote:
>Hello,
>
>On Tue, 21 Nov 2023 13:30:31 +0000 Steve McIntyre wrote:
>> Source: libssh2
>> Version: 1.9.0-2
>> Severity: serious
>> Tags: ftbfs patch
>>
>> Hi!
>>
>> Building
Source: libssh2
Version: 1.9.0-2
Severity: serious
Tags: ftbfs patch
Hi!
Building libssh2 using debuild in a clean local chroot, I get test
failures and even a core dump!
...
PASS: mansyntax.sh
r preinst moved to postinst) was about adding it
>to the Depends field.
>
>In fact, the changelog was correct for what it had to be done,
>just not for what it was actually done.
>
>(note: shim FTBFS in a clean chroot because of this bug)
Oh, gah. :-/
Thanks for the prod, f
or.
After weeks with this breakage, I've just uploaded a minimal NMU to
fix it, reverting the syslog changes since -1. I've buit and tested
successfully locally.
Here's the NMU diff.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the
eting 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%.
--
Steve McIntyre, Cambridge, UK.
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.0 am
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
35382 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)
onger 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.
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 think that's actua
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
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:
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, UK.
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:
ub_util_error (_("could not strndup cipher_mode of length
>`%lu'"), seek_head - c);
>++
>++ remaining -= seek_head - c + 1;
>++ c = seek_head + 1;
>++
>++ err = grub_cryptodisk_setcipher (cryptodisk, cipher,
>cipher_mode);
>
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 sch
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
Armed with "Valor": "Centurion" represents qu
ueued 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 requirement for m
rate 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 strace a while
back but my time has vanished with s
12" 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 middle of tes
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 thanked for th
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
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:
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:
Hi Daniel!
On Sat, Dec 03, 2022 at 01:41:51AM +1100, Daniel Axtens wrote:
>Steve McIntyre writes:
>>
>> программист некто (in CC) reported this bug a few weeks back in
>> Debian. Since I applied the bundle of filesystem bounds-checking fixes
>> a few months back, he c
thong was working
>fine with 2.06-3.
>
>I also noticed that my enrolled keys is no more listed via "mokutil
>--list-enrolled". Although no key were cleared.
OK. I believe that is more likely an unrelated issue.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone
not read past the end of nat journal entries
>
>https://git.savannah.gnu.org/cgit/grub.git/patch/?id=4bd9877f62166b7e369773ab92fe24a39f6515f8
It's exactly the same patch, just the commit hash is different when
pulled into our 2.06 tree.
Cheers,
Steve
--
Steve McIntyre, Cambridge, UK.
Distributing and linking to racist propaganda is really *not*
something Debian should be doing.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
ock device, size 10.85 GiB (11653873664 bytes)
F2FS file system (version 1.14)
$ disktype /dev/sda2
--- /dev/sda2
Block device, size 17.48 GiB (18772656128 bytes)
NTFS file system
Volume size 17.48 GiB (18772652032 bytes, 36665336 sectors)
- End forwarded message -
--
Steve McIntyr
upstream. Are you happy for me to CC you on that discussion too?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone
Hi!
On Thu, Oct 20, 2022 at 06:20:26PM +0100, Steve McIntyre wrote:
>On Thu, Oct 20, 2022 at 08:09:15PM +0300, программист некто wrote:
>># fsck.f2fs -f /dev/sda1
>>didn't report any errors.
>
>OK, that's good to know.
>
>>I can continue testing - rebuild without pa
On Sun, Oct 30, 2022 at 03:38:06PM +0100, Samuel Thibault wrote:
>Steve McIntyre, le lun. 24 oct. 2022 10:16:39 +0100, a ecrit:
>> This bug just bit me, and I'm disappointed nothing appears to have
>> been done here to remedy this.
>
>I had actually not seen the bug report,
n that would be excellent!
--
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
s support for
you. Looking at the patches, I'm not seeing anything *obvious* there
that might be an issue. They're all trying to add checks to avoid
crashes with an invalid/corrupt f2fs filesystem.
Silly question: does your filesystem have errors? Does fsck.f2fs
report anything?
--
Steve McIntyre,
On Sun, Oct 16, 2022 at 09:57:35PM +0100, Steve McIntyre wrote:
>On Sun, Oct 16, 2022 at 07:37:53AM +0300, программист некто wrote:
>>Output already captured. See
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021846 the first message
>>- it have an attached files wit
On Sun, Oct 16, 2022 at 07:37:53AM +0300, программист некто wrote:
>Output already captured. See
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021846 the first message -
>it have an attached files with grub-install output.
Ah, sorry; I missed them. Looking now.
--
Steve
ease
run grub-install with "-v" and capture the output?
--
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 are for
right patches in. But
>for some reason, shim-signed is still at 15.4.
We've had problems in submitting shim 15.6 to Microsoft for
signing. We're working on a solution, but it's going to take a little
longer yet.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"
adding the bullseye-updates suite
to your sources list. That suite is there specifically for this kind
of change, and *should* be automatically included when a system is
installed (using d-i at least).
--
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing rand
Control: tag -1 pending
Hello,
Bug #1017944 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:
we do not have
>systems to test this.
Thanks Valentin, I'm looking at this now.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
'-Wl,--no-undefined',
>
>to systemd for the time being.
ACK, that's probably your best bet for now. The EFI toolchain has
quite special needs here yet...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
9:01.0 +
>+++ sbsigntool-0.9.4/debian/rules 2022-06-04 11:37:18.0 +
>@@ -4,6 +4,7 @@
> include /usr/share/dpkg/architecture.mk
> include /usr/share/dpkg/pkg-info.mk
>
>+export DEB_CFLAGS_MAINT_APPEND=-Wno-error=deprecated-declarations
>
> # Uncomment this to turn on verbose mode.
> export DH_VERBOSE=1
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
^
>> gram.y:119:51: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 119 | ddaSetConfig(READWRITE, (void
>> *)parsebool($2));
>> | ^
>> gram.y:131:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 131 | ddaSetConfig(WORDSIZE, (void *)$2);
>> | ^
>> gram.y:135:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 135 | ddaSetConfig(FRAGSIZE, (void *)$2);
>> | ^
>> gram.y:139:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 139 | ddaSetConfig(MINFRAGS, (void *)$2);
>> | ^
>> gram.y:143:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 143 | ddaSetConfig(MAXFRAGS, (void *)$2);
>> | ^
>> gram.y:147:50: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 147 | ddaSetConfig(NUMCHANS, (void *)$2);
>> | ^
>> gram.y:150:49: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 150 | { ddaSetConfig(MAXRATE, (void *)$2); }
>> | ^
>> gram.y:152:49: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 152 | { ddaSetConfig(MINRATE, (void *)$2); }
>> | ^
>> gram.y:154:46: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 154 | { ddaSetConfig(GAIN, (void *)$2); }
>> | ^
>> gram.y:156:51: warning: cast to pointer from integer of different size
>> [-Wint-to-pointer-cast]
>> 156 | { ddaSetConfig(GAINSCALE, (void *)$2); }
>> | ^
>> gram.y:161:43: warning: implicit declaration of function ‘RemoveDQuote’
>> [-Wimplicit-function-declaration]
>> 161 | RemoveDQuote(ptr);
>> | ^~~~
>> y.tab.c:1497:7: warning: implicit declaration of function ‘yyerror’; did you
>> mean ‘yyerrok’? [-Wimplicit-function-declaration]
>> gram.y: At top level:
>> gram.y:170:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
>> 170 | RemoveDQuote(str)
>> | ^~~~
>> rm -f libdia.a
>> ar clq libdia.a dispatch.o dixutils.o events.o globals.o main.o resource.o
>> swapreq.otables.o swaprep.oaudispatch.o auswap.o autables.o
>> auevents.o auutil.o auconfig.oauprocess.o nasconf.o lex.o gram.o
>> ar: libdeps specified more than once
>> make[4]: *** [Makefile:1083: libdia.a] Error 1
>
>
>The full build log is available from:
>http://qa-logs.debian.net/2021/10/23/nas_1.9.4-7_unstable.log
>
>A list of current common problems and possible solutions is available at
>http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
>If you reassign this bug to another package, please marking it as 'affects'-ing
>this package. See https://www.debian.org/Bugs/server-control#affects
>
>If you fail to reproduce this, please provide a build log and diff it with mine
>so that we can identify if something relevant changed in the meantime.
>
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.
24576 0
virtio_ring28672 5
virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
virtio 20480 5
virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
I'm curious why you might be seeing different. Could you share more
details of your setup please?
pport etc. I've got some Mustang (X-Gene 1)
machines here, which are the same core APM hardware but packaged on
standard motherboard (mini-itx I think?). I'm just trying a bullseye
update on one now.
Out of curiosity: how does an equivalent boot work with buster d-i on
your system?
--
Steve M
On Sat, Aug 14, 2021 at 05:50:47PM +0100, Steve McIntyre wrote:
>
>Starting in BIOS mode on a kde i386 live image. The existing disk on
>my test system has an LVM setup on it. I've told calamares to wipe the
>whole disk and do a fresh installation, but it looks like the code
On Sun, Jul 25, 2021 at 08:19:55PM +0500, Roman Mamedov wrote:
>On Sun, 25 Jul 2021 12:43:48 +0100
>Steve McIntyre wrote:
>
>> Which provider is using secure boot on arm64 at this point? I've not
>> heard of any. Can you share details of package versions et
- the older version of shim left
multiple high-security issues open, allowing people to easily break
into a Secure Boot setup.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
'There is some grim amusement in watching Pence try to run the typical
"politician in the m
Hi Ryan,
On Sat, Jul 17, 2021 at 09:19:22AM -0500, Ryan Thoryk wrote:
>On 7/17/21 8:18 AM, Steve McIntyre wrote:
>> On Sat, Jul 17, 2021 at 07:57:48AM -0500, Ryan Thoryk wrote:
>> EFI/debian is *NOT* wrong, it's the correct location for a system that
>> has working firmware w
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 about that.
--
Steve McInty
t; 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.st...@einval.com
"I'v
. 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.
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.
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 resou
r 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
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 non-secure mod
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.
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
>"/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 I
don't know all the deta
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?
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
>
re - 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
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
nt, 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
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
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:
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
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 McIntyre, Cambridge, UK.
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.
>>
>> Than
dev/disk/by-id/scsi-3600508b1001052395358323050350006
2. Warn if install_devices is empty?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane
[ Dropping the CC to Chad here ]
On Sat, Aug 01, 2020 at 02:36:25PM +0100, Colin Watson wrote:
>On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
>> * Do we need to scan? if grub is installed and doing an upgrade and
>>there is only one disk of an appropr
ting
config in a config file that people can edit. We already store some
of our stuff in /etc/default/grub, let's push more of our config
there?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to
On Fri, Jul 31, 2020 at 03:07:58PM +0100, Geoff Gibbs wrote:
>On Fri, 31 Jul 2020 14:30:14 +0100
>Steve McIntyre wrote:
>
>> I'm guessing - do you have multiple disks on your system? If so, try
>> "grub-install " on each of the bootable disks and that should
>>
lem. If
not, please get back to us ASAP and we'll try to debug the problem
here.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
ers are all handled by LVM
I'm guessing - do you have multiple disks on your system? If so, try
"grub-install " on each of the bootable disks and that should
fix your problem.
I think we need a proper fix for this in the longer term, but that's
not going to happen overnight.
--
Steve McInty
.
ACK. Same thing applies as I suggested to Paul - maybe an inconsistent
set of updates. Have you *fixed* the problem by using the live boot?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss
t. I remembered incorrectly. It’s just one
>unencrypted F2FS formatted partition.
How many disks do you have on your system, please?
*If* you have more than one, there's a potential for grub-install to
have not been run to install grub to all the MBRs, and then the BIOS
finds an old copy of the GRU
Control: tags -1 +patch
On Tue, Jul 28, 2020 at 04:17:08PM +0100, Steve McIntyre wrote:
>Control: severity -1 grave
...
>IMHO this has to be a grave bug - without reimporting this repo we
>can't get our older revisions back. Then I'm worried that this will
>break things if we nee
On Fri, Jun 26, 2020 at 10:29:28AM -0700, John Johansen wrote:
>On 6/26/20 9:50 AM, Steve McIntyre wrote:
>>
>> OK, will try that second...
>>
>
>I have not been able to reproduce but
>
>So looking at linux-4.19.y it looks like
>1f8266ff5884 apparmor: don't
Hi again,
On Fri, Jun 26, 2020 at 05:50:00PM +0100, Steve McIntyre wrote:
>On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote:
>>On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote:
>>> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
>
>...
>
>>&
Hi Jann,
On Fri, Jun 26, 2020 at 04:25:59PM +0200, Jann Horn wrote:
>On Fri, Jun 26, 2020 at 3:41 PM Greg KH wrote:
>> On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
...
>> > Considering I'm running strace build tests to provoke this bug,
>> > find
On Fri, Jun 26, 2020 at 02:45:18PM +0100, Steve McIntyre wrote:
>Hey Greg,
>
>On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote:
>>On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
>>>
>>> e58f543fc7c0926f31a49619c1a3648e49e8d233 i
Hey Greg,
On Fri, Jun 26, 2020 at 03:41:32PM +0200, Greg KH wrote:
>On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
>>
>> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
>> commit e58f543fc7c0926f31a49619c1a3648e49e8d233
>> Author: Ja
g,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
Annoyingly, I can't reproduce this on my disparate other machines
here, suggesting it's maybe(?) timing related.
Hope this helps - happy to give more information, test things, etc.
--
Steve McIntyre, Cam
67084a647e
865a227665e460e159502f21e8a16e6fa590bf50 M security
Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I
On Wed, Jun 24, 2020 at 05:39:38PM +0100, Steve McIntyre wrote:
>On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote:
>>Control: found -1 4.19.118-1
>>Control: tags -1 + upstream
>>
>>>
>>> As I can reproduce this quite easily, I'm happy to
Hey Salvatore!
On Wed, Jun 24, 2020 at 05:57:42PM +0200, Salvatore Bonaccorso wrote:
>Control: found -1 4.19.118-1
>Control: tags -1 + upstream
>
>Hi Steve,
>
>On Mon, Jun 22, 2020 at 12:58:35PM +0100, Steve McIntyre wrote:
>> Source: linux
>> Version: 4.19.118-
Source: linux
Version: 4.19.118-2+deb10u1
Severity: serious
Hi folks,
Trying to reproduce #963462 on my Thinkpad T470, I'm repeatedly
getting a hard lockup running the strace testsuite. I've done this 4
times to be sure. Each time it seems to have failed in a slightly
different place in the
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
dicts.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
>/usr/bin/ld:
>/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdl.so: error
>adding symbols: DSO missing from command line
>collect2: error: ld returned 1 exit status
>make[1]: *** [Makefile:37: qxw] Error 1
On Tue, Mar 24, 2020 at 11:42:02AM +0100, Emilio Pozuelo Monfort wrote:
>Hi,
>
>On Wed, 11 Dec 2019 11:12:56 +0000 Steve McIntyre wrote:
>> On Tue, Dec 10, 2019 at 11:06:49PM -0500, John Scott wrote:
>> >Control: tags -1 patch
>> >
>> >Merge request with
1 - 100 of 510 matches
Mail list logo
