Problems with gnome-terminal
Hello, gnome-terminal does not process its command line arguments arguments correctly since tumbleweed snapshot 20220921. The gnome-terminal website asks to file a bug report with the linux distribution, wich I did in <https://bugzilla.suse.com/show_bug.cgi?id=1203762> on 2022-09-26. There seems to be no interest in the bug report, besides one confirmatiion. Is there a better place to report the bug, one, that gets attention? Kinc regards Berthold
Hello Berthold,
The gnome-terminal website asks to file a bug report with the linux distribution
Could you post the website's link for a reference? For gnome-terminal bugs potentially happening in all distributions, upstream report makes it traced easier. For the bug you mentioned, the fix has been merged in the next gnome-terminal update. See: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7930 Best wishes, Yifan On Sun, Oct 09, 2022 at 12:05:16PM +0200, Berthold Höllmann wrote:
Hello,
gnome-terminal does not process its command line arguments arguments correctly since tumbleweed snapshot 20220921.
The gnome-terminal website asks to file a bug report with the linux distribution, wich I did in <https://bugzilla.suse.com/show_bug.cgi?id=1203762> on 2022-09-26.
There seems to be no interest in the bug report, besides one confirmatiion.
Is there a better place to report the bug, one, that gets attention?
Kinc regards Berthold
G'day All, When doing an update, I have noticed that I am getting more bad checksums than usual. A few retries seem to fix the issue, but it is happening a lot. It is more in OBS repos (but it happened a little while ago from OSS main, and in amarok-lang from Packman). It occurs more in large files so retries are a pain. I have uninstalled a few games that I had on here that had big files (ufoai etc -- my son can reliably beat me now anyway). This is a recent example from my last update (this time it is Ghidra from security:forensics, and although this one seems to be a major culprit, it happens randomly but more in large files in lesser-used OBS repos): -------------- ... Retrieving package ffe-0.3.2-2.969.x86_64 (68/76), 55.5 KiB ( 99.4 KiB unpacked) Retrieving: ffe-0.3.2-2.969.x86_64.rpm ..........................................................................[done (14.5 KiB/s)] Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (1.2 MiB/s)] Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm] expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 57c981239bfdb0fdef0fdfd1db81d2d193b086b382ae90d2c28def4bfd98d2dc Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise. However if you made certain that the file with checksum '57c9..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file. Unblock or discard? [57c9/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.2 MiB/s)] Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm] expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 8552a9e101c1ed3e6540a3690d728e0ab27324a3741614a06bf3ca33094782b5 Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise. However if you made certain that the file with checksum '8552..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file. Unblock or discard? [8552/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.5 MiB/s)] Retrieving package termshark-2.4.0-2.30.x86_64 (70/76), 5.1 MiB ( 16.4 MiB unpacked) Retrieving: termshark-2.4.0-2.30.x86_64.rpm ....................................................................[done (563.0 KiB/s)] ... -------------- Refreshes and cleans do not seem to fix it, and it also occurs on other networks (all in Australia though). I have not been having any other trouble with data corruption (network or storage related) on this machine. My zypper cache is on an XFS partition, and it has been working fine for a long time. There are no changes that I can think of on my side that could be causing this. Is anyone else having this issue? Is there something broken with the closest mirrors to AP? Am I just updating right at the same time that the mirrors are updating... about 3 times a week (seriously unlucky)!? -- Ben
Le 10/10/22 à 10:31, Ben Holmes a écrit :
G'day All,
When doing an update, I have noticed that I am getting more bad checksums than usual.
A few retries seem to fix the issue, but it is happening a lot. It is more in OBS repos (but it happened a little while ago from OSS main, and in amarok-lang from Packman). It occurs more in large files so retries are a pain. I have uninstalled a few games that I had on here that had big files (ufoai etc -- my son can reliably beat me now anyway).
This is a recent example from my last update (this time it is Ghidra from security:forensics, and although this one seems to be a major culprit, it happens randomly but more in large files in lesser-used OBS repos):
--------------
... Retrieving package ffe-0.3.2-2.969.x86_64 (68/76), 55.5 KiB ( 99.4 KiB unpacked) Retrieving: ffe-0.3.2-2.969.x86_64.rpm ..........................................................................[done (14.5 KiB/s)] Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (1.2 MiB/s)]
Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm]
expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 57c981239bfdb0fdef0fdfd1db81d2d193b086b382ae90d2c28def4bfd98d2dc
Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.
However if you made certain that the file with checksum '57c9..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file.
Unblock or discard? [57c9/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.2 MiB/s)]
Warning: Digest verification failed for file 'ghidra-10.1.5-2.47.x86_64.rpm' [/var/tmp/AP_0xxsKeL3/x86_64/ghidra-10.1.5-2.47.x86_64.rpm]
expected a3febe663353584c193bceb91497920d8626af01380184964c49437c7c517a2d but got 8552a9e101c1ed3e6540a3690d728e0ab27324a3741614a06bf3ca33094782b5
Accepting packages with wrong checksums can lead to a corrupted system and in extreme cases even to a system compromise.
However if you made certain that the file with checksum '8552..' is secure, correct and should be used within this operation, enter the first 4 characters of the checksum to unblock using this file on your own risk. Empty input will discard the file.
Unblock or discard? [8552/...? shows all options] (discard): Package ghidra-10.1.5-2.47.x86_64 (Forensics Tools and Libraries (openSUSE_Tumbleweed)) seems to be corrupted during transfer. Do you want to retry retrieval? Abort, retry, ignore? [a/r/i] (a): r Retrieving package ghidra-10.1.5-2.47.x86_64 (69/76), 275.3 MiB (929.7 MiB unpacked) Retrieving: ghidra-10.1.5-2.47.x86_64.rpm ........................................................................[done (2.5 MiB/s)] Retrieving package termshark-2.4.0-2.30.x86_64 (70/76), 5.1 MiB ( 16.4 MiB unpacked) Retrieving: termshark-2.4.0-2.30.x86_64.rpm ....................................................................[done (563.0 KiB/s)] ...
--------------
Refreshes and cleans do not seem to fix it, and it also occurs on other networks (all in Australia though). I have not been having any other trouble with data corruption (network or storage related) on this machine. My zypper cache is on an XFS partition, and it has been working fine for a long time. There are no changes that I can think of on my side that could be causing this.
Is anyone else having this issue?
Is there something broken with the closest mirrors to AP?
Am I just updating right at the same time that the mirrors are updating... about 3 times a week (seriously unlucky)!?
-- Ben
I've been seeing this as well (also in Australia: Telstra in Perth). It seems to me like bigger downloads are just being cut off halfway through. I saw it briefly a week or so ago (with some big debuginfo packages), and switched the debug repository over to the NZ mirror, which seemed to resolve it. But it is now showing up even for non-debug packages (e.g. kernel-source-vanilla-6.0.0-1.2.noarch). The "downloads" complete unusually quickly, so I'm guessing it's a problem with the mirror. (The debug packages, which are still on the NZ mirror, seem to be fine.) (After all that, I re-ran it while sending this email, and it worked fine… maybe that's just luck, though.) -- David
Yifan Jiang <yfjiang@suse.com> writes:
Hello Berthold,
The gnome-terminal website asks to file a bug report with the linux distribution
Could you post the website's link for a reference?
I found <https://wiki.gnome.org/Apps/Terminal/ReportingBugs>, where I read: Where you should report the bug to If you're a developer of GNOME Terminal, VTE, or GNOME in general, you can file the bug in the GNOME issue tracker. In all other cases, you should file the bug against your Linux distribution's bug tracker; see here for a list of distribution bug trackers. The distribution bug triagers will then gather all the necessary information and confirmation before forwarding the bug to our issue tracker, if necessary.
For gnome-terminal bugs potentially happening in all distributions, upstream report makes it traced easier. For the bug you mentioned, the fix has been merged in the next gnome-terminal update. See:
Great
Best wishes, Yifan
On Sun, Oct 09, 2022 at 12:05:16PM +0200, Berthold Höllmann wrote:
Hello,
gnome-terminal does not process its command line arguments arguments correctly since tumbleweed snapshot 20220921.
The gnome-terminal website asks to file a bug report with the linux distribution, wich I did in <https://bugzilla.suse.com/show_bug.cgi?id=1203762> on 2022-09-26.
There seems to be no interest in the bug report, besides one confirmatiion.
Is there a better place to report the bug, one, that gets attention?
Kinc regards Berthold
Yifan Jiang <yfjiang@suse.com> writes:
On Sun, Oct 09, 2022 at 12:05:16PM +0200, Berthold Höllmann wrote:
Hello,
gnome-terminal does not process its command line arguments arguments correctly since tumbleweed snapshot 20220921.
It's fixed with the last snapshot, thanks. Kind regards Berthold
participants (4)
-
Ben Holmes -
Berthold Höllmann -
David Gow -
Yifan Jiang