On Thu, 2 Mar 2023 03:48:49 +0800
jeremy ardley wrote:
> 2. The known hosts file used is /etc/ssh/known_hosts rather that
> ~/.ssh/known_hosts - which causes a permissions error
I am not seeing that, for either root or my regular non-root user.
You indicated you created your ~/.ssh/config as
I may have found a bug in openssh.
I raise it here as the ssh mailing list is actually a newsgroup that
no-one seems to use.
I can ssh jer...@client.example.com without the issue
I have created a ~/.ssh/config file with contents
Host jeremy_client
HostName client.example.com
User
On 27/02/2023 19:58, Jonathan Dowland wrote:
I see the maintainer has
uploaded a new version with a fix for your issue (--execute), but
they have pointed out that the original bug was complaining about
something different (-c): I hadn't noticed the difference, and it
seems only the former
On 28/02/2023 09:00, John Crawley wrote:
On 27/02/2023 19:58, Jonathan Dowland wrote:
I see the maintainer has
uploaded a new version with a fix for your issue (--execute), but
they have pointed out that the original bug was complaining about
something different (-c): I hadn't noticed
On 27/02/2023 19:58, Jonathan Dowland wrote:
I see the maintainer has
uploaded a new version with a fix for your issue (--execute), but
they have pointed out that the original bug was complaining about
something different (-c): I hadn't noticed the difference, and it
seems only the former
(--execute), but
they have pointed out that the original bug was complaining about
something different (-c): I hadn't noticed the difference, and it
seems only the former is a policy violation in their eyes. I hope
the action properly addresses *your* issue.
(They didn't merge your MR as part of the upload
any other necessary changes), and raise a
"Merge Request" on Salsa, pointing back at the Debian bug. Then the work
required to integrate the fix is as small as possible.
I've done this. [1]
Have you tried emailing the python packaging maintainers? They're listed
as Debian Python Team ,
Hi,
[ honouring Reply-To as set ]
I might have missed many nuances in the situation but from what I've
read, here's what I observe.
On Thu, Feb 23, 2023 at 11:23:26AM +0900, John Crawley wrote:
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901245
This is the "right" bu
.
There is an existing bug [3] with the title "Handling of -e violates policy for
x-terminal-emulator" - the issue was fixed upstream some time ago but the bug
remained open. The bug has now returned with the same result of breaking compliance with
Debian Policy.
I was unsure whether to post a new
I suspect you just need firmware-linux installed if it isn’t already.
That’s if that hardware requires the Radeon firmware.
On Mon, Feb 20, 2023 at 5:48 AM Felix Miata wrote:
> Omoikane Omake composed on 2023-02-19 21:50 (UTC+0300):
>
> > Excuse me for my broken English.
> > I don't know what
Omoikane Omake composed on 2023-02-19 21:50 (UTC+0300):
> Excuse me for my broken English.
> I don't know what exactly is cause of problem.
> Old notebook eMachines d620 with radeon x1200, rs960m.
> Driver works but no hardware acceleration.
> Because of that some programs do not work properly.
>
On 19/02/2023 18:50, Omoikane Omake wrote:
Hello.
Excuse me for my broken English.
I don't know what exactly is cause of problem.
Old notebook eMachines d620 with radeon x1200, rs960m.
Driver works but no hardware acceleration.
Because of that some programs do not work properly.
For example,
Hello.
Excuse me for my broken English.
I don't know what exactly is cause of problem.
Old notebook eMachines d620 with radeon x1200, rs960m.
Driver works but no hardware acceleration.
Because of that some programs do not work properly.
For example, geeqie segfault, vlc crashed when opening file,
found a problem, or
> type
> 'other' to report a more general problem. If you don't know what package the
> bug is in, please contact debian-user@lists.debian.org for assistance.
> > other
> Please enter the name of the package in which you have found a problem, or
> choose
package the
bug is in, please contact debian-user@lists.debian.org for assistance.
> other
Please enter the name of the package in which you have found a problem, or
choose one of these bug categories:
1 amprolla Everything related to amprolla
2 arm-sdk The ARM SDK and images (
Hola Juan, gracias por confirmar el bug,
Comentarte que en una actualización de hoy día el problema por lo menos en
mi caso desapareció, por ahora parece que funciona bien,
saludos!
El mar, 31 ene 2023 a las 13:16, juan martinez ()
escribió:
> Hola Leo ,mi caso es igual a tratar de ent
El 2023-01-29 a las 14:40 -0500, juan martinez escribió:
> es mi primera vez pasandome a debian testing y me gusto mucho debian, pero
> me pasa algo curioso, cada vez que trato de cambiar los iconos en el menú
> de configuración de kde se cierra de forma inesperada, no se si sea un bug
ación de kde se cierra de forma inesperada, no se si sea un bug
> o si ya esta reportada perdonen en si no es bug pero soy nuevo en este
> mundo
>
> --
> *Juan C. Martínez Anaya*
> * Ingeniero civil*
> "Se oyen pasos de alguien que no llega nunca "
>
>
>
--
L.J.Marín
Usando: Debian Testing
hola chicos,
es mi primera vez pasandome a debian testing y me gusto mucho debian, pero
me pasa algo curioso, cada vez que trato de cambiar los iconos en el menú
de configuración de kde se cierra de forma inesperada, no se si sea un bug
o si ya esta reportada perdonen en si no es bug pero soy
another excellent example why your posts are almost always worth reading.
thank you! :)
On Thu, Jan 19, 2023 at 02:00:00PM +0100, DdB wrote:
> Am 19.01.2023 um 13:13 schrieb Greg Wooledge:
> > The fact that this *appears* to work is what causes so much confusion.
> > It will "work" some of the time, but not all of the time, and you'll
> > get different results depending on which
On Thu, Jan 19, 2023 at 02:00:00PM +0100, DdB wrote:
[...]
> I was really curious, how Greg would put words to this one. And i gotta
> applaud: Such unambiguous explanations, and so circumspect at the same
> time. Even understanding the basis for confusion, i could learn
> something new from
Am 19.01.2023 um 13:13 schrieb Greg Wooledge:
> The fact that this *appears* to work is what causes so much confusion.
> It will "work" some of the time, but not all of the time, and you'll
> get different results depending on which directory you're in, on which
> computer.
>
> Bash has two other
On Thu, Jan 19, 2023 at 07:13:46AM -0500, Greg Wooledge wrote:
[...]
> So, just to add to the list of people who've already said it: always
> quote the patterns that you pass to apt list, because you want apt
> to use them directly, without your shell interfering.
And, if in doubt, just replace
On Thu, Jan 19, 2023 at 12:11:43PM +0100, Christoph Brinkhaus wrote:
> For curiosity If have done a small test as below.
> Unfortunately there are a few outputs in German. For this comparisons
> the exact meanings of the German text has no importance at all.
>
> 1. The first command of the
llo together,
> > > listing packages in apt with ”sudo“ in the title returns different output
> > > (bash commands at the end of the email). I would fill a bug report, but
> > > I'm not sure whether to address it to grep or apt. How do you see this?
> > >
>
> (bash commands at the end of the email). I would fill a bug report, but I'm
> > not sure whether to address it to grep or apt. How do you see this?
> >
> > Kind regards
> > Julian Schreck
> > --
> > $ apt list sudo* vs. $ apt list | grep "^sudo[a-z-]"
Am Thu, Jan 19, 2023 at 09:10:30AM +0100 schrieb js-p...@online.de:
Hello Julian,
> Hello together,
> listing packages in apt with ”sudo“ in the title returns different output
> (bash commands at the end of the email). I would fill a bug report, but I'm
> not sure whether to addres
19.01.23, 09:10 +0100, js-p...@online.de:
Hello together,
listing packages in apt with ”sudo“ in the title returns different output (bash
commands at the end of the email). I would fill a bug report, but I'm not sure
whether to address it to grep or apt. How do you see this?
To me it seems
Am 19.01.2023 um 09:10 schrieb js-p...@online.de:
> Hello together,
> listing packages in apt with ”sudo“ in the title returns different output
> (bash commands at the end of the email). I would fill a bug report, but I'm
> not sure whether to address it to grep or apt. Ho
Hello together,
listing packages in apt with ”sudo“ in the title returns different output (bash
commands at the end of the email). I would fill a bug report, but I'm not sure
whether to address it to grep or apt. How do you see this?
Kind regards
Julian Schreck
--
$ apt list sudo* vs. $ apt
but everybody is unsure when it will find it's way into
mainline.
Thank You again, David & have a nice day, Y'all,
Martin
On 2023-01-15 12:04, David wrote:
Hi list readers
A FYI: I am far from expert in these things but I noticed that a kernel
with a known bug affecting AMD graphics is about to e
Hi list readers
A FYI: I am far from expert in these things but I noticed that a kernel
with a known bug affecting AMD graphics is about to enter the unstable
distribution [1], and possibly the testing distribution as well.
[1]:"""
I would like to upload linux version 6.1.
Greg wrote:
>On Wed, Jan 11, 2023 at 10:42:31PM +, Tim Woodall wrote:
>> On Tue, 10 Jan 2023, songbird wrote:
>>
>> > kudoes to everyone who helped with this in getting it done, finding
>> > bugs, fixing problems, converting code, updating docs and testing. :)
>> >
>>
>> What does debian
On Wed, Jan 11, 2023 at 10:42:31PM +, Tim Woodall wrote:
> On Tue, 10 Jan 2023, songbird wrote:
>
> > kudoes to everyone who helped with this in getting it done, finding
> > bugs, fixing problems, converting code, updating docs and testing. :)
> >
>
> What does debian use for moinmoin? Is
On Tue, 10 Jan 2023, songbird wrote:
kudoes to everyone who helped with this in getting it done, finding
bugs, fixing problems, converting code, updating docs and testing. :)
What does debian use for moinmoin? Is the debian wiki stuck on buster?
kudoes to everyone who helped with this in getting it done, finding
bugs, fixing problems, converting code, updating docs and testing. :)
songbird
Bonjour
Je suis face à un truc bizarre.
L'analiseur d'utilisation du disque me dit que j'ai un SSD de 500Go.
Gparted me dit que le SSD fait 256 Go.
Un df -h me dit 256 Go.
L'application Analyseur d'utilisation de disque a un bug?
--
Gestionnaire d'infrastructure/ Gestionnaire de parc
Erazo escribió:
Saludos equipo de Debian 11 bullseyes, tegno instalado en mi maquina
esta version, el bug seria en el navegador firefox-esr la ultima
version ya que posee un bug, en el chat de messenger de facebook, ya
que se cierre inesperadamente, la pestaña con la red social, y se
cierra el
Saludos equipo de Debian 11 bullseyes, tegno instalado en mi maquina
esta version, el bug seria en el navegador firefox-esr la ultima version
ya que posee un bug, en el chat de messenger de facebook, ya que se
cierre inesperadamente, la pestaña con la red social, y se cierra el
navegador
Hi all, thanks for your time! Please let me know if this isn't the right
spot for this, or if I should file a bug.
I'm on debian buster, package versions for ones in question are:
systemd - 241-7~deb10u8
prometheus-node-exporter - 0.17.0+ds-3+b11
dbus - 1.12.20-0+deb10u1
pacemaker - 2.0.1-5
rhkramer writes:
> Some examples from (simple) math include adding zero or multiplying by
> 1.
Those are respectively the additive and multiplicative identities. They
are, of course, idempotent but not good examples because they never
change the operand even on first application.
A better
On Mon, Sep 26, 2022 at 07:27:45PM -0400, The Wanderer wrote:
> My guess is: there's a collection of image files which (occasionally?)
> gets added to, he wants to clean up this data from the files in that
> collection that have it, and he doesn't want to have to keep track of
> which ones have
On 2022-09-26 at 19:16, David Wright wrote:
> On Mon 26 Sep 2022 at 21:31:55 (+0200), Emanuel Berg wrote:
>
>> Greg Wooledge wrote:
>>> The entire thread was a result of your assumption that exif would
>>> NOT write the words "Wrote file" if the input file had no exif
>>> tag in it. This turned
On Mon 26 Sep 2022 at 21:31:55 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:
>
> >> Look more, quote less ...
> >>
> >> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> > 'Wrote
> >> file' | wc -l # 2277 (1st invocation)
> >>
> >> for f in
debian-user wrote:
>> In programming the focus is perhaps better, for something
>> idempotent, something like: Do it the first time.
>> Don't screw it up the second time? And don't do the
>> computing if it doesn't need to be done?
>
> Sorry, but idempotence says nothing at all about
>
> In programming the focus is perhaps better, for something
> idempotent, something like: Do it the first time. Don't screw
> it up the second time? And don't do the computing if it
> doesn't need to be done?
Sorry, but idempotence says nothing at all about computational
efficiency or cost.
Greg Wooledge wrote:
>> Look more, quote less ...
>>
>> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' | wc -l # 2277 (1st invocation)
>>
>> for f in **/*.jpg; do exif --remove -o $f $f; done | grep
> 'Wrote
>> file' |
On Mon, Sep 26, 2022 at 09:07:29PM +0200, Emanuel Berg wrote:
> David Wright wrote:
>
> See the first post ...
> >>>
> >>> The OP didn't contain any exif output, only a couple of
> >>> command lines, apparently written in zsh shell
> >>
> >> Look again!
> >
> > Look at it? I'll quote it in
Curt wrote:
> One "programming" example given on that same Wikipedia page
> was that if you applied an update operation to Lutz
> Mueller's email address in a database (*ich habe
> Kopfschmerzen*!) that same update applied a second or third
> time (ad infinitum) would produce identical results.
David Wright wrote:
See the first post ...
>>>
>>> The OP didn't contain any exif output, only a couple of
>>> command lines, apparently written in zsh shell
>>
>> Look again!
>
> Look at it? I'll quote it in full (attached).
Look more, quote less ...
for f in **/*.jpg; do exif
mick.crane wrote:
>> I have now clarified to the best of my ability the meaning
>> of that word and I think that will help people understand
>> at last why incorrect tech information, actually
>> disinformation at that point, can't be allowed in software
>> documentation. I get it now that this
.org (Postfix) with QMQP
id EF8442074B; Wed, 21 Sep 2022 07:02:38 + (UTC)
[ … ]
Mail-Followup-To: debian-user@lists.debian.org
To: debian-user@lists.debian.org
From: Emanuel Berg
Subject: exif --remove not idempotent, and a Debian man page bug
Date: Wed, 21 Sep 2022 09:02:09 +0200
Messag
On Sunday, September 25, 2022 08:42:57 AM The Wanderer wrote:
> On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
> > Oops, ignore that previous response ...
> >
> > On second thought, what hede wrote is correct, it is just stated in a
> > way that I wasn't famiiar with (and I haven't had my
On 2022-09-25, Emanuel Berg wrote:
> The Wanderer wrote:
>
>> If the nature of operation O is such that objects B and
>> C are guaranteed to always be identical, no matter what
>> object A was, then operation O is categorized as
>> being idempotent.
>
> It has to do with the number of times it is
On 2022-09-26 06:42, Emanuel Berg wrote:
<...>
I have now clarified to the best of my ability the meaning of
that word and I think that will help people understand at last
why incorrect tech information, actually disinformation at
that point, can't be allowed in software documentation. I get
it
David Wright wrote:
>> See the first post ...
>
> The OP didn't contain any exif output, only a couple of
> command lines, apparently written in zsh shell
Look again!
> The focus of the thread seems to have changed to the meaning
> of a word in the Subject, and an old email address that
> might
On Sun 25 Sep 2022 at 07:52:38 (+0200), Emanuel Berg wrote:
> Greg Wooledge wrote:
> > If I had the first inkling of a clue what an exif tag
> > actually *was* I might try testing it myself. I'm gathering
> > that it has something to do with JPEG images, based on the
> > *.modified.jpeg default
> rhkramer wrote:
>
> > An operation that produces the same results no matter how
> > many times it is performed.
>
> Yeah, obviously it is a term from math and in practical and
> applied engineering as is programming I thought of
> a definition (not really) like this
>
> - apply once, you
The Wanderer wrote:
> If the nature of operation O is such that objects B and
> C are guaranteed to always be identical, no matter what
> object A was, then operation O is categorized as
> being idempotent.
It has to do with the number of times it is applied,
abs(x) = abs(abs(x)) =
rhkramer wrote:
> An operation that produces the same results no matter how
> many times it is performed.
Yeah, obviously it is a term from math and in practical and
applied engineering as is programming I thought of
a definition (not really) like this
- apply once, you get the change
- apply
Am 25.09.2022 14:42, schrieb The Wanderer:
On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
On second thought, what hede wrote is correct, it is just stated in a
way that I wasn't famiiar with (and I haven't had my morning coffee
yet)
Are you sure?
Meanwhile, I do think my description was
On 2022-09-25 at 08:22, rhkra...@gmail.com wrote:
> Oops, ignore that previous response ...
>
> On second thought, what hede wrote is correct, it is just stated in a
> way that I wasn't famiiar with (and I haven't had my morning coffee
> yet)
Are you sure?
Because it doesn't seem to match my
Oops, ignore that previous response ...
On second thought, what hede wrote is correct, it is just stated in a way that
I wasn't famiiar with (and I haven't had my morning coffee yet)
Sorry for the noise!
On Sunday, September 25, 2022 07:56:08 AM rhkra...@gmail.com wrote:
> On Saturday,
On Saturday, September 24, 2022 09:17:31 AM hede wrote:
> "Idempotent" means, that a task with the same input data and the same
> config (for example to remove a tag via exif-tool) results in the same
> output data. Is this the case here?
That is not my understanding of itempotent (nor of
On 2022-09-25 at 01:43, Emanuel Berg wrote:
> The Wanderer wrote:
>>> There should be no history entries in the man pages that
>>> relates to practical aspects that are no
>>> longer operational.
>>
>> The E-mail address doesn't relate to a practical
>> aspect, though.
>
> Ikr? Since it doesn't
Greg Wooledge wrote:
>> The "-o" means: "Write output image to FILE". And it does
>> so, as far as I can see.
>
> The question is whether specifying "-o f f" where the output file
> has the same name as the input file actually overwrites the original
> input file. Another person reported that it
hede wrote:
> "Idempotent" means, that a task with the same input data and
> the same config (for example to remove a tag via exif-tool)
> results in the same output data.
Determinism.
--
underground experts united
https://dataswamp.org/~incal
The Wanderer wrote:
>>> That's maintainership history, with E-mail
>>> addresses attached.
>>
>> There should be no history entries in the man pages that
>> relates to practical aspects that are no
>> longer operational.
>
> The E-mail address doesn't relate to a practical
> aspect, though.
ith a patch to do this, and maintain it to cope
with upstream modifications, you're at the mercy of the upstream
and, of course, the Author.
> > In the case of the bash(1) page, it's actually followed by a BUG REPORTS
> > section, telling you how to submit bug reports to the upstream
On Sat 24 Sep 2022 at 10:43:04 (-0400), Greg Wooledge wrote:
> On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> > Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > > Maybe related to the '-o f f' part as your imagination
> > > tells you ...
> >
> > The "-o" means: "Write output image to
On Fri 23 Sep 2022 at 16:14:43 (+0200), Emanuel Berg wrote:
> David Wright wrote:
> >> exif(1) which says on line 57 that --remove
> >>
> >> Remove the tag or (if no tag is specified) the entire IFD.
> >>
> >> Only if it does, why is it there the next time to be removed
> >> as well?
> >
> >
On 2022-09-24, Alex King wrote:
>
>
> I've been using Debian as my main OS since 1997 or earlier. I've spent
> 100s of hours reading man pages. Although it's a reasonable assumption
> (since there are a lot of man pages with outdated AUTHORS sections), I
> didn't know the AUTHORS section is
On Sat, Sep 24, 2022 at 03:17:31PM +0200, hede wrote:
> Am 21.09.2022 14:46, schrieb Emanuel Berg:
> > Maybe related to the '-o f f' part as your imagination
> > tells you ...
>
> The "-o" means: "Write output image to FILE". And it does so, as far as I
> can see.
The question is whether
Am 21.09.2022 14:46, schrieb Emanuel Berg:
I don't know what the intended behaviof of "exif --remove -o
file file" is. I'm imagining [...]
exif(1) which says on line 57 that --remove
Remove the tag or (if no tag is specified) the entire IFD.
"Idempotent" means, that a task with the same
(some) man pages
have a HISTORY section for historical information.
In the case of the bash(1) page, it's actually followed by a BUG REPORTS
section, telling you how to submit bug reports to the upstream maintainer.
That's not common in man pages, but clearly not unheard of either.
As a Debian
On 2022-09-23 at 12:02, Emanuel Berg wrote:
> The Wanderer wrote:
>
>> That's maintainership history, with E-mail addresses attached.
>
> There should be no history entries in the man pages that relates to
> practical aspects that are no longer operational.
The E-mail address doesn't relate to
n Fox has not been involved with bash development for
> decades. Nevertheless, removing Brian's email address from
> the AUTHORS section is neither necessary nor desirable.
> Everyone knows it's a historical section.
I think it's wrong to include tech information in manpages
that looks usefu
The Wanderer wrote:
> That's maintainership history, with E-mail
> addresses attached.
There should be no history entries in the man pages that
relates to practical aspects that are no longer operational.
Commands, examples that once worked but are now removed,
options that are
a historical section.
>
> In the case of the bash(1) page, it's actually followed by a BUG
> REPORTS section, telling you how to submit bug reports to the
> upstream maintainer. That's not common in man pages, but clearly not
> unheard of either.
>
> As a Debian user, however,
r. Brian Fox has not
been involved with bash development for decades. Nevertheless, removing
Brian's email address from the AUTHORS section is neither necessary nor
desirable. Everyone knows it's a historical section.
In the case of the bash(1) page, it's actually followed by a BUG REPORT
ight © 2002-2012 Thomas Pircher,
>>Dan Fandrich and others.
>>
>> This isn't a contact address for bug reports.
>> It's a historical note.
>
> Indeed, that e-mail belongs to history, which is why it should
> be removed from actively deployed documentation concerning
Greg Wooledge wrote:
> https://manpages.debian.org/bullseye/exif/exif.1.en.html
>
>AUTHOR
>exif was written by Lutz Mueller
> and numerous contributors.
>This man page is Copyright © 2002-2012 Thomas Pircher,
>Dan Fandrich and others.
>
> This isn'
exif was written by Lutz Mueller and
numerous contributors. This man page is Copyright © 2002-2012 Thomas
Pircher, Dan Fandrich and others.
This isn't a contact address for bug reports. It's a historical note.
David Wright wrote:
>> But: isn't it still a bug in the distribution man page to
>> refer to mail address that bounces?
>
> I hope the maintainers (Debian's) have better things to do
Are you saying incorrect information in the man pages are OK
in Debian?
> than trawl th
C'd, let's see what they say.
>
> But: isn't it still a bug in the distribution man page to
> refer to mail address that bounces?
I hope the maintainers (Debian's) have better things to do than trawl
through email addresses in man pages. The man page has its origin and
date clear
Greg Wooledge wrote:
> According to the package metadata, the Debian maintainer of
> exif is:
OK, cool.
> Maintainer: Debian PhotoTools Maintainers
>
They are CC'd, let's see what they say.
But: isn't it still a bug in the distribution man page to
refer to mail address
aps what you actually want is additional clarity
about how the --remove option (or the -o option) works.
In any case, if you want to file a Debian bug report, see
<https://www.debian.org/Bugs/>.
>From IRC ...
vengeance, you the exif(1) guy here, right, how
can it be it isn't idempotent? I just run it for
every jpg on the HDD and after done, it does the
same thing again upon a 2nd invocation
I'll mail Lutz Mueller as well
Steve McIntyre wrote:
...
> I'm building a new unstable package (2.06-4) right now with Valentin's
> patch applied, and once I've uploaded that I'll do a new bullseye
> package too.
that's great! thank you! :)
songbird
e version in stable
>rather than backported from unstable, but in this case there were no
>intermediate versions in unstable and it was probably thought safer to
>use the package which had been tested in unstable rather than starting
>over and potentially introducing a new bug. That probably w
> On Aug 30, 2022, at 1:12 PM, Casey Deccio wrote:
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the problem
On 9/12/2022 11:36 AM, Tim Woodall wrote:
> On Mon, 12 Sep 2022, David Wright wrote:
>
> >
> > AFAICT it had two months in testing without this problem being
> > hit and reported.
> >
>
> Unfortunately, g-x-h is probably mostly used on stable or oldstable with
> guests running testing.
>
> I'm not
, but in this case there were no
intermediate versions in unstable and it was probably thought safer to
use the package which had been tested in unstable rather than starting
over and potentially introducing a new bug. That probably was even true,
as the problem was identified during the test period on unstable
been higher.
I think in this case the package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
No, it wasn't; as far as I can tell, the bug didn't become "grave"
On Mon, 12 Sep 2022, David Wright wrote:
On Mon 12 Sep 2022 at 14:20:59 (+0100), Tim Woodall wrote:
The same version also went to oldstable - where it turns out it works
fine - so I can see how it could be missed but this was a bug that I
feel would have, if necessary, justified delaying
ke sense. "Should bugs make it into Debian releases"?
> >
> > Ah, sorry, I think I misunderstood - you are literally asking if the
> > presence of a severity "serious" bug in Grub should have prevented
> > the whole 11.5 point release happening?
> >
> &
e package was already present in testing and
stable-proposed-updates before the bug was found. It was reported as
"grave" and bounced between that and "serious".
Also I am not sure if there are the same processes around this for
packages going in to stable-proposed-updates. The mig
On Mon, Sep 12, 2022 at 02:20:59PM +0100, Tim Woodall wrote:
Agreed. While I tend to try to file bugs at the lowest severity that can
be justified, I know that others go the other way. This is one I'd
probably have filed as Grave or even Critical. (I see it's now been
bumped to Grave)
If it's
On Mon, 12 Sep 2022, David wrote:
On Mon, 12 Sept 2022 at 23:21, Tim Woodall wrote:
It just felt wrong to me that this bug (and version bump of the
package) could go to stable without someone at least acknowleging the
bug. AFAICT there's no fundamental reason it needed to go out
301 - 400 of 8562 matches
Mail list logo
