Re: Bugs in display scaling and screen resolution setting

[George at Clug]

On Monday, 23-09-2024 at 19:48 newbie...@gmx.de wrote:
> 
> hello friends, 
>  
> I tried but found it too confusing to find where to report bugs for debian 
> :-(  . 

What GUI are you using?  (e.g. Gnome, KDE, Xfec, etc ?)

Wayland or X11 ?

What is the model number of monitor are you using?

>  
> I see an issues in ver. 12.6.0 started from the live image: 
>  
> Scaling the desktop by Settings - Display - General - Scale works 
> counter-intuitive, setting it to 2x reduces everything on screen to quarter 
> size, 
> half height and half width, while setting it to Custom - 0.5x enlarges it to 
> double height and double width.
>  
> And an issue where I can't decide if debian or Kali: 
>  
> Between Kali 2024-W32 and 2024-W36 ( weekly unstable ) something got lost 
> which 
> makes some display resolution switches impossible. E.g. switching Settings - 
> Display - General - Resolution from 3840x2160 to 1920x1200 works, while 
> towards 
> 1920x1080 it doesn't. You get the dialog but nothing changes on screen, and 
> after 
> confirmation and reopening the settings dialog the old resolution shows 
> active. 
>  
> Can anybody care for it or give advice? 
>  
> Thanks a lot, newbie. 
> 
> 

Bugs in display scaling and screen resolution setting

[newbie-02]

hello friends, 
 
I tried but found it too confusing to find where to report bugs for debian :-(  
. 
 
I see an issues in ver. 12.6.0 started from the live image: 
 
Scaling the desktop by Settings - Display - General - Scale works 
counter-intuitive, setting it to 2x reduces everything on screen to quarter 
size, 
half height and half width, while setting it to Custom - 0.5x enlarges it to 
double height and double width. 
 
And an issue where I can't decide if debian or Kali: 
 
Between Kali 2024-W32 and 2024-W36 ( weekly unstable ) something got lost which 
makes some display resolution switches impossible. E.g. switching Settings - 
Display - General - Resolution from 3840x2160 to 1920x1200 works, while towards 
1920x1080 it doesn't. You get the dialog but nothing changes on screen, and 
after 
confirmation and reopening the settings dialog the old resolution shows active. 
 
Can anybody care for it or give advice? 
 
Thanks a lot, newbie. 

Proper place to file bugs against kernel

[Richard]

Hi,

a while ago I reported a bug against the kernel (Bug#1070717). But the bug 
isn't limited to that kernel version and not even to the Debian kernel. The 
same even happens when I e.g. compile Linux 9.3 from sources, using the config 
from Debian's 6.6.15 - the latest version I tried that didn't show the bug - 
and setting all newer config options to default with make olddefconfig. So it 
seems to be an upstream issue. Now, what would be the best place for reporting 
the bug? Just leave as is, make a bug report against linux-image-amd64 
mentioning the original report or even something else?


Best

Richard

Re: debian-devel wishlist "bugs"

[Gareth Evans]

On Fri 01/03/2024 at 05:30, Jeffrey Walton  wrote:
> On Fri, Mar 1, 2024 at 12:22 AM Gareth Evans  wrote:
>>
>> I'm subscribed to debian-devel for entertainment purposes and see regular 
>> wishlist "bug" reports, eg.
>>
>> https://lists.debian.org/debian-devel/2024/02/msg00321.html
>>
>> Can anyone advise of the appropriate way for non-developers to 
>> request/suggest inclusion of packages?
>
> Open a bug report against the wnpp package. See
>  and .
>
>> Freenginx doesn't seem to be in testing but might be a worthwhile addition.
>
> 
>
> Jeff

I asked if the project might provide debs/rpms which resulted in a response re 
Debian-legal.

Not looking good for Debian/Ubuntu inclusion at least in binary form.

https://freenginx.org/pipermail/nginx/2024-March/60.html

Just FYI

Gareth

Re: debian-devel wishlist "bugs"

[Jeffrey Walton]

On Fri, Mar 1, 2024 at 12:22 AM Gareth Evans  wrote:
>
> I'm subscribed to debian-devel for entertainment purposes and see regular 
> wishlist "bug" reports, eg.
>
> https://lists.debian.org/debian-devel/2024/02/msg00321.html
>
> Can anyone advise of the appropriate way for non-developers to 
> request/suggest inclusion of packages?

Open a bug report against the wnpp package. See
 and .

> Freenginx doesn't seem to be in testing but might be a worthwhile addition.



Jeff

Re: debian-devel wishlist "bugs"

[Gareth Evans]

> On 1 Mar 2024, at 02:29, John Hasler  wrote:
> 
> https://wiki.debian.org/RFP
> --
> John Hasler
> j...@sugarbit.com
> Elmwood, WI USA

Excellent thanks
G

Re: debian-devel wishlist "bugs"

[John Hasler]

https://wiki.debian.org/RFP
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

debian-devel wishlist "bugs"

[Gareth Evans]

I'm subscribed to debian-devel for entertainment purposes and see regular 
wishlist "bug" reports, eg.

https://lists.debian.org/debian-devel/2024/02/msg00321.html

Can anyone advise of the appropriate way for non-developers to request/suggest 
inclusion of packages?

Freenginx doesn't seem to be in testing but might be a worthwhile addition.

https://freenginx.org/

Thanks,
Gareth

Re: Does reporting bugs from inside the live CD work?

[Charles Curley]

On Sun, 19 Nov 2023 08:56:11 +0100
dub...@grey-panther.net wrote:

> I didn't get an email reply and the reportbug script said something
> about the email being sent from "localhost" (since this is a LiveCD,
> email accounts are not properly set up). Hence me suspecting that the
> email never went anywhere (or maybe the recipient server dropped it).
> But reportbug itself never reported any errors...

Had all gone well, you would have gotten a reply email with the bug
number and URL for the bug. That you didn't suggests something failed.
The lack of error message from reportbug means that everything went
well on your computer, which suggests that the failure was either at
the server or in between.

Before you file a bug report, you might see if the wiki entry for
reportbug is any help. https://wiki.debian.org/reportbug

Or inquire on the Debian live list.
https://lists.debian.org/debian-live/

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Does reporting bugs from inside the live CD work?

[dubser]

On Sat, Nov 18, 2023 at 10:37 PM Charles Curley - charlescurley at
charlescurley.com <
charlescurley_at_charlescurley_com_futffkb...@simplelogin.co> wrote:

> On Sat, 18 Nov 2023 22:07:46 +0100
> dub...@grey-panther.net wrote:
>
> > Anyway, I ran the reportbug program with the cdimage.debian.org
> > meta-package, as described at https://www.debian.org/Bugs/Reporting,
> > however my bug doesn't show up in the bugtracker, even though it has
> > been several days now since I submitted it.
>
> Did you get an email response? If so, have you visited the link to the
> bug report in the email?
>

I didn't get an email reply and the reportbug script said something about
the email being sent from "localhost" (since this is a LiveCD, email
accounts are not properly set up). Hence me suspecting that the email never
went anywhere (or maybe the recipient server dropped it). But reportbug
itself never reported any errors...

Attila


>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
>
>
>

Re: Does reporting bugs from inside the live CD work?

[Charles Curley]

On Sat, 18 Nov 2023 22:07:46 +0100
dub...@grey-panther.net wrote:

> Anyway, I ran the reportbug program with the cdimage.debian.org
> meta-package, as described at https://www.debian.org/Bugs/Reporting,
> however my bug doesn't show up in the bugtracker, even though it has
> been several days now since I submitted it.

Did you get an email response? If so, have you visited the link to the
bug report in the email?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Does reporting bugs from inside the live CD work?

[dubser]

Hi all,

I tried to report the bug that in the live Gnome CD, if one starts the
installer, one is asked for a password, that is (as far as I can tell) not
documented anywhere inside the CD:
https://kdrive.infomaniak.com/app/share/545250/a4c87792-3ed2-4a70-bc1c-ae629842f9cb/preview/image/876245

Anyway, I ran the reportbug program with the cdimage.debian.org
meta-package, as described at https://www.debian.org/Bugs/Reporting,
however my bug doesn't show up in the bugtracker, even though it has been
several days now since I submitted it.

Does anybody know if reporting a bug from the live-CD images is even
supported?

Best,
Attila

PS. Subscribing to the mailing list through the web interface results in a
"Gateway Timeout" at https://lists.debian.org/cgi-bin/subscribe.pl :(

Re: bugs submitted by me rss feed?

[Brian]

On Thu 08 Sep 2022 at 10:02:15 +1000, David wrote:

> On Thu, 8 Sept 2022 at 03:14, Brian  wrote:
> > On Wed 07 Sep 2022 at 15:48:35 +0100, Brad Rogers wrote:
> > > On Wed, 07 Sep 2022 12:39:23 + "jindam, vani" 
> > >  wrote:
> 
> > Reports submitted from a specicic address may be viewed with
> >
> >   
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi/submitter=jindam.vani%40disroot.org
> 
> I tried that, and it replied:
>   "An error occurred. Error was: You have to choose something to select by"
> 
> Perhaps because between 'pkgreport.cgi' and 'submitter' should be
> a question mark, not a forward slash.
> 
> I tried this, and it seemed to work:
>   
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;submitter=jindam.vani%40disroot.org

Thanks for spotting the typo.

-- 
Brian. 

Re: bugs submitted by me rss feed?

[David]

On Thu, 8 Sept 2022 at 03:14, Brian  wrote:
> On Wed 07 Sep 2022 at 15:48:35 +0100, Brad Rogers wrote:
> > On Wed, 07 Sep 2022 12:39:23 + "jindam, vani"  
> > wrote:

> Reports submitted from a specicic address may be viewed with
>
>   
> https://bugs.debian.org/cgi-bin/pkgreport.cgi/submitter=jindam.vani%40disroot.org

I tried that, and it replied:
  "An error occurred. Error was: You have to choose something to select by"

Perhaps because between 'pkgreport.cgi' and 'submitter' should be
a question mark, not a forward slash.

I tried this, and it seemed to work:
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;submitter=jindam.vani%40disroot.org

Re: bugs submitted by me rss feed?

[Brad Rogers]

On Wed, 7 Sep 2022 18:14:22 +0100
Brian  wrote:

Hello Brian,

>Reports submitted from a specicic address may be viewed with

Good to know.  Bookmarked for future reference.  Thank you.

-- 
 Regards  _
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
People stare like they've seen a ghost
Titanic (My Over) Reaction - 999


pgpWLS_0MoMbo.pgp
Description: OpenPGP digital signature

Re: bugs submitted by me rss feed?

[Brian]

On Wed 07 Sep 2022 at 15:48:35 +0100, Brad Rogers wrote:

> On Wed, 07 Sep 2022 12:39:23 +
> "jindam, vani"  wrote:
> 
> Hello vani,
> 
> >luckily there were few bugs created 
> >by me..
> 
> Yeah, it will probably be a real PITA to find all those bugs already
> submitted by you.

Reports submitted from a specicic address may be viewed with

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi/submitter=jindam.vani%40disroot.org

-- 
Brian.

Re: bugs submitted by me rss feed?

[Brad Rogers]

On Wed, 07 Sep 2022 12:39:23 +
"jindam, vani"  wrote:

Hello vani,

>luckily there were few bugs created 
>by me..

Yeah, it will probably be a real PITA to find all those bugs already
submitted by you.

At least from now on, you've got some sort of mechanism to monitor any
bug action.

It might not be exactly what you wanted but, hey, we can't have
everything.   :-)

-- 
 Regards  _
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Junk floats on polluted water
Hong Kong Garden - Siouxsie & The Banshees


pgpZiWUUXPdta.pgp
Description: OpenPGP digital signature

Re: bugs submitted by me rss feed?

[jindam, vani]

On 7 September 2022 7:51:29 AM UTC, Brad Rogers  wrote:
>On Wed, 07 Sep 2022 07:09:46 +
>"jindam, vani"  wrote:
>
>Hello vani,
>
>>is it possible to view changes made 
>>on bugs submitted by me using rss.
>
>AFAIAA, no.  However, you *can* 'subscribe' to the bug on bugs.debian
>in much the same way you can subscribe to a mailing list (near the top
>there's line that starts "Reply or subscribe").  That way, you get

ha... got it
luckily there were few bugs created 
by me..

regards,
jindam vani

>all the messages relating to that bug in your inbox.  They can then, of
>course, be filtered to suit you.
>

Re: bugs submitted by me rss feed?

[The Wanderer]

On 2022-09-07 at 03:37, to...@tuxteam.de wrote:

> On Wed, Sep 07, 2022 at 07:09:46AM +, jindam, vani wrote:
>
>> hello debian users,
>> 
>> is it possible to view changes made 
>> on bugs submitted by me using rss. perhaps, 
>> a moreinfo needed tag of a bug submitted 
>> by me didnt received through email.
>> 
>> i am talking about bugs submitted on 
>> bugs.debian.org
> 
> If you know your bug nummber, you can just:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
> 
> (replacing  by the actual number).

That's changes per bug report.

From the mention of an RSS feed, and the use of "bugs" in the plural, I
infer that the question is about changes per submitter, irrespective of
which bug report number the change was made on.

As far as I know, there's no facility for that.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: bugs submitted by me rss feed?

[Brad Rogers]

On Wed, 07 Sep 2022 07:09:46 +
"jindam, vani"  wrote:

Hello vani,

>is it possible to view changes made 
>on bugs submitted by me using rss.

AFAIAA, no.  However, you *can* 'subscribe' to the bug on bugs.debian
in much the same way you can subscribe to a mailing list (near the top
there's line that starts "Reply or subscribe").  That way, you get
all the messages relating to that bug in your inbox.  They can then, of
course, be filtered to suit you.

-- 
 Regards  _
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Looking for something I can call my own
Chairman Of The Bored - Crass


pgpZ2sIghbyim.pgp
Description: OpenPGP digital signature

Re: bugs submitted by me rss feed?

[tomas]

On Wed, Sep 07, 2022 at 07:09:46AM +, jindam, vani wrote:
> hello debian users,
> 
> is it possible to view changes made 
> on bugs submitted by me using rss. perhaps, 
> a moreinfo needed tag of a bug submitted 
> by me didnt received through email.
> 
> i am talking about bugs submitted on 
> bugs.debian.org

If you know your bug nummber, you can just:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=

(replacing  by the actual number).

The bugs page has also a full text search. If you tell more about your bug,
perhaps someone here can help finding it (the most obvious attempt, trying
your name, turned out empty for me, but I might be making a mistake).

Cheers
-- 
t


signature.asc
Description: PGP signature

bugs submitted by me rss feed?

[jindam, vani]

hello debian users,

is it possible to view changes made 
on bugs submitted by me using rss. perhaps, 
a moreinfo needed tag of a bug submitted 
by me didnt received through email.

i am talking about bugs submitted on 
bugs.debian.org

regards,
jindam, vani

Re: Why are some Debian bugs ignored for a long time?

[tomas]

On Sun, Aug 21, 2022 at 10:06:08AM +0200, Oliver Schoede wrote:
> On Sat, 20 Aug 2022 13:26:14 +0100
> Brian  wrote:
> 
> >Reasons for the perceived "ignored" status might be:
[...]

> No, these are (more or less reasonable) grounds for not getting *to
> work* on some potential issue, and that is what you state yourself! With
> one exception--a fix warranting no further comment is imminent--none of
> these points however justifies providing no *feedback* to begin with,
[...]

That's how *you* think things should be. If you don't put any effort
into making it happen, this mail stays what it is: a useless rant.

Telling others what they should do will be pretty ineffective unless
you have something to offer in exchange :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Why are some Debian bugs ignored for a long time?

[Oliver Schoede]

On Sat, 20 Aug 2022 13:26:14 +0100
Brian  wrote:

>Reasons for the perceived "ignored" status might be:
>
> * The maintainer judges that the bug affects very few users.
> * The maintainer does not have the resources to deal with the bug.
> * A solution is already in hand and awaiting upload to unstable.
> * The maintainer puts the report on the back burner and forgets about
>   it.
> * The bug is low down on the priority list.
> * The maintainer sees the bug as a user issue and not an issue with
>   package quality.
> * The maintainer has little or nothing to contribute that would lead
> to the report progressing.
> * Fixing this issue is not worth the effort, if possible at all.
>

No, these are (more or less reasonable) grounds for not getting *to
work* on some potential issue, and that is what you state yourself! With
one exception--a fix warranting no further comment is imminent--none of
these points however justifies providing no *feedback* to begin with,
and if it's a won't-fix/don't care plus signature. In fact, most if not
all would seem to explicitly ask for it. I'd even think there might
well be less reason for interaction other than the auto confirmation
once some change is pending, especially if it's obvious. As I
understand it though Chuck is not primarily complaining about ignored
issues. But about ignored reporters. We are a peoples project?

And while I perfectly understand there can be countless causes
*even* preventing maintainers from providing feedback, whether timely or
long-time, this is simply an entirely different matter and would have to
be explained in another way. At least this is getting us somewhere:

>
>Neither should a user have any expectation of a timely interaction,
>nice though it may be to be get further involvement from a maintainer.

So be it. If also a rule I'm afraid it's probably about as old as
Debian and a rather antiquated conception of software development or
the expectations of its wider ecosystem. Nor does volunteering in itself
relieve you from certain minimal considerations that naturally arise
when contributing to what is ultimately a social enterprise.
Not to mention that, hopefully, all testing and bug reporting here is
just as voluntary. ;) It's the whole point, isn't it? And if
consideration means to, perhaps temporarily, *visibly* suspend some
role when there's not enough time or more pressing issues, or at least
to leave some clue to that effect somewhere, like on a personal
website, as some have done. Pushing issues into some black hole however
isn't exactly enticing, I can easily imagine technically advanced users
instead rather sorting some things out themselves immediately, locally,
and from experience just forgo the BTS altogether.


Oliver

Re: Why are some Debian bugs ignored for a long time?

[tomas]

On Sat, Aug 20, 2022 at 04:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/20/2022 2:06 PM, Stefan Monnier wrote:

[...]

> > But note that *you* can help, by taking on some of the work, looking for
> > bugs that haven't gotten an answer yet and trying to address them.
> 
> That's a fair point. It may not be so easy for me to work on a bug that does 
> not affect
> my systems, but I am willing to help with bugs important to the Debian 
> project now, as
> the bookworm development process continues [...]

Yay! Thank you!

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/20/22 4:28 PM, Stefan Monnier wrote:
> Chuck Zmudzinski [2022-08-20 16:20:21] wrote:
> > That's a fair point. It may not be so easy for me to work on a bug that 
> > does not affect
> > my systems, but I am willing to help with bugs important to the Debian 
> > project now, as
> > the bookworm development process continues. I will take some time and see 
> > if I can
> > help out with some other open bugs that do not directly affect my systems. 
> > Such bugs
> > can be found by querying BTS for bugs marked as critical or grave by the 
> > maintainer
> > and bugs that are blocking a release, as these are the ones most important 
> > to the
> > maintainers and developers. I don't know if I have the skills to fix such 
> > bugs which are
> > probably not so easy to fix, but it wouldn't hurt to ask if there is 
> > anything I can do to
> > help. One thing that is always helpful are testers to test the proposed 
> > fixes for open
> > bugs, and I could help with that in cases when the bug affects a package on 
> > one or more
> > of my systems, at least to tell the maintainer, "that proposed fix looks 
> > good, it does not
> > break anything on my systems."
>
> Yes, there are many things one can do to help.  E.g. several bugs are
> misfiled (for example, sent to the Debian maintainer instead of being
> sent to the package's developer even though the bug is unrelated to the
> Debian packaging itself).  Or often the bug report lacks information to
> reproduce it.
>
>
> Stefan
>

On Debian, the best thing users can do to help, AFAICT, is to run the
testing distribution on non-critical systems to see if the development
of the next stable Debian version is causing problems. The more people
who run testing and give the developers feedback about problems on BTS,
the more likely the stable version won't break someone's current setup
when it is released and users start upgrading to the new stable version
in larger numbers. Still, for this development process that Debian uses to
be effective, when problems are reported to BTS, the developers and
maintainers need to respond to the bugs that are reported and not ignore
them.

Best regards,

Chuck

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/20/2022 2:06 PM, Stefan Monnier wrote:
> > So that means "free" software written and maintained by volunteers will 
> > never be as
> > stable and secure as software that is written by people who are paid by the 
> > hour.
>
> Not necessarily.  Have you filed a bug report about a problem you
> perceived in macOS, Windows, other your usual shrink wrapped software?
> Has it always been fixed promptly?
>
> If you want your bugs to be fixed, you generally need resort to some
> kind of support contract, which you can get for Free Software just as
> easily as for proprietary software (probably more easily, actually).
>
> Notice also that the goal of Free Software is not to be technically
> better (you may be confusing it for Open Source software), but
> ethically better.
>
> I suspect most maintainers who don't respond promptly to bug reports
> aren't happy about that fact: its demoralizing to be in charge of
> something you can't devote the resources it really deserves.
>
> But note that *you* can help, by taking on some of the work, looking for
> bugs that haven't gotten an answer yet and trying to address them.

That's a fair point. It may not be so easy for me to work on a bug that does 
not affect
my systems, but I am willing to help with bugs important to the Debian project 
now, as
the bookworm development process continues. I will take some time and see if I 
can
help out with some other open bugs that do not directly affect my systems. Such 
bugs
can be found by querying BTS for bugs marked as critical or grave by the 
maintainer
and bugs that are blocking a release, as these are the ones most important to 
the
maintainers and developers. I don't know if I have the skills to fix such bugs 
which are
probably not so easy to fix, but it wouldn't hurt to ask if there is anything I 
can do to
help. One thing that is always helpful are testers to test the proposed fixes 
for open
bugs, and I could help with that in cases when the bug affects a package on one 
or more
of my systems, at least to tell the maintainer, "that proposed fix looks good, 
it does not
break anything on my systems."

Thanks,

Chuck

> I don't think anyone can do that for any random bug, but I'm pretty sure
> most people on this list would be able to do that for at least one of
> the pending bug reports.
>
>
> Stefan
>

Re: Why are some Debian bugs ignored for a long time?

[Brian]

On Sat 20 Aug 2022 at 16:13:29 +0100, Brad Rogers wrote:

> On Sat, 20 Aug 2022 15:22:27 +0100
> Brian  wrote:
> 
> Hello Brian,
> 
> >On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:
> >> On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:  
> 
> >> Usually upstream projects want and expect users to report bugs to
> >> the distro, not to the upstream project, for many good reasons that I
> >> need not explain here.  
> >
> >You would have to explain it for my benefit because I am not familiar
> >with that procedure.
> 
> Distros can, and do, apply patches to software.  Bugs should be reported
> to distros in the first instance because the maintainers are best placed
> to determine if the bug is specific to the distro or not.  Furthermore,
> the bug reported may not even be in the package it was reported against,
> but in (say) a library that the package uses.  Either way, the package
> maintainers can pass the bug to the relevant place (self, other package
> within distro, upstream).
> 
> If we all went straight to the dev team of the software, they would end
> up having to deal with a load of distro specific stuff they have no hope
> of fixing.  Of course, that's be a massive waste of everybody's time.
> 
> Plus, of course, what Greg said.

What you and Greg Wooledge say makes complete sense. I suppose it
also helps our users by exposing the bug in the BTS and, theoretically,
avoids duplication of reports. It was just that my limited experience
does not include upstreams wanting and expecting bugs to be reported
first to the distro as a matter of course, sensible though it might be.
As has been said:

 > In the end, everyone just has to do the best they can with
 > the knowledge they possess.

I would expect that "everyone" includes maintainers.

-- 
Brian.

Re: Why are some Debian bugs ignored for a long time?

[tomas]

On Sat, Aug 20, 2022 at 11:14:27AM -0400, Chuck Zmudzinski wrote:

[...]

> > So they will allocate their resources accordingly. I've worked
> > in the belly of big corps for a while and I assure you that my
> > boss wouldn't allow me to fix a bug unless (s)he could justify
> > to their bosses that the 1400 dollars "spent" on this are coming
> > back in some way.
> 
> There are plenty of "volunteers" for free software projects that also
> work, as you say, in the "belly of big corps." Are you suggesting these
> "volunteers" will ignore bugs in free software projects because their
> boss does not want them to fix the bugs in the free project and force
> users to buy a paid version of the project?

No. I'm not talking about what those people do /as volunteers/ (i.e.
in their free time, out of their own motivation), but /as employees/
(i.e. on "company time"). This was in answer to your

> > So that means "free" software written and maintained by volunteers will 
> > never be as
> > stable and secure as software that is written by people who are paid by the 
> > hour.

It should be clear that the same person may play different roles (e.g.
"paid by the hour" or "free time").

When paid by the hour, it is clear that the employer has a say in what
the employee uses her time for. If the bug doesn't seem important to
the company, it won't get fixed.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:
> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > >
> > > > I have noticed that some Debian bugs are ignored for a long time [...]
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
>
> There is another point: the package maintainer is very autonomous
> in how (s)he does her thing. This has advantages and disadvantages.
>
> There are processes in place for resolving such situations as when
> a maintainer becomes unresponsive (perhaps (s)he has moved on to
> other things, perhaps (s)he is in some situation of distress). Among
> others, there is the NMU [0].
>
> This question comes up regularly in this list. Had you searched
> the archives, you'd found things like this [1] with advice (hint:
> this would leave developers more time for fixing bugs ;-)
>
> There is good advice by Jonathan Dowland in the linked thread on
> how to do something about it. Want to give it a try?
>
> > So that means "free" software written and maintained by volunteers will 
> > never be as
> > stable and secure as software that is written by people who are paid by the 
> > hour.
>
> This is, of course, nonsense. This would be only the case if
> the instance giving out the cash had an interest on the software
> being "stable and secure". Most of the time they have an interest
> on the software being sold, or on it generating cash flow via
> other means (gathering user data, for that to be sold, for example).
>
> So they will allocate their resources accordingly. I've worked
> in the belly of big corps for a while and I assure you that my
> boss wouldn't allow me to fix a bug unless (s)he could justify
> to their bosses that the 1400 dollars "spent" on this are coming
> back in some way.

There are plenty of "volunteers" for free software projects that also
work, as you say, in the "belly of big corps." Are you suggesting these
"volunteers" will ignore bugs in free software projects because their
boss does not want them to fix the bugs in the free project and force
users to buy a paid version of the project?

Best regards,

Chuck

Re: Why are some Debian bugs ignored for a long time?

[Brad Rogers]

On Sat, 20 Aug 2022 15:22:27 +0100
Brian  wrote:

Hello Brian,

>On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:
>> On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:  

>> Usually upstream projects want and expect users to report bugs to
>> the distro, not to the upstream project, for many good reasons that I
>> need not explain here.  
>
>You would have to explain it for my benefit because I am not familiar
>with that procedure.

Distros can, and do, apply patches to software.  Bugs should be reported
to distros in the first instance because the maintainers are best placed
to determine if the bug is specific to the distro or not.  Furthermore,
the bug reported may not even be in the package it was reported against,
but in (say) a library that the package uses.  Either way, the package
maintainers can pass the bug to the relevant place (self, other package
within distro, upstream).

If we all went straight to the dev team of the software, they would end
up having to deal with a load of distro specific stuff they have no hope
of fixing.  Of course, that's be a massive waste of everybody's time.

Plus, of course, what Greg said.

-- 
 Regards  _
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Age of destruction, age of oblivion
Neuromancer - Billy Idol


pgpyPCmYcwsAN.pgp
Description: OpenPGP digital signature

Re: Why are some Debian bugs ignored for a long time?

[Greg Wooledge]

On Sat, Aug 20, 2022 at 03:22:27PM +0100, Brian wrote:
> On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:
> > Usually upstream projects want and expect users to report bugs to
> > the distro, not to the upstream project, for many good reasons that I
> > need not explain here.
> 
> You would have to explain it for my benefit because I am not familiar
> with that procedure.

When encountering a bug in a Debian package, the typical end user has
no way of knowing whether the bug is in the upstream program, or in the
patches added by Debian.

So, the correct thing for the end user to do is to report the bug to
Debian's bug tracking system.  If the maintainer determines that the
bug is in the upstream code, then the maintainer is supposed to pass
the bug upstream.

Of course, this assumes limited knowledge on the part of the end user,
and active maintenance by the Debian maintainer.  Either of those things
might turn out not to be the case.

An end user with a bit of technical prowess might build the upstream code
and test it to see whether the bug is also there.

A Debian maintainer might turn out to be severely inactive, for any
number of reasons.

In the end, everyone just has to do the best they can with the knowledge
they possess.

Re: Why are some Debian bugs ignored for a long time?

[Brian]

On Sat 20 Aug 2022 at 09:06:54 -0400, Chuck Zmudzinski wrote:

> On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:

[...]

> > I get you want to contribute?
> 
> Yes, that's what mystifies me. I don't know why Debian ignores
> someone who wants to contribute time to help the project.
> 
> In another case, the bug was upstream and although I reported the
> bug on Debian first, marked it 'patch' and 'upstream' in the BTS, it was
> still being ignored, so I just submitted the patch directly to upstream who
> accepted my patch.

You did the best possible thing.

> Usually upstream projects want and expect users to report bugs to
> the distro, not to the upstream project, for many good reasons that I
> need not explain here.

You would have to explain it for my benefit because I am not familiar
with that procedure.

>Then the distro package maintainer, rather
> than the user, interacts with the upstream developers and maintainers.

That is the general practice, but it is not unknown for the maintainer
to request the user to forward the report upstream.

> Of course if the distro maintainers ignore upstream bugs reported to the
> distro, the whole free software ecosystem will suffer, not just Debian.

Fair comment.

-- 
Brian.

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/20/2022 1:25 AM, to...@tuxteam.de wrote:
> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > >
> > > > I have noticed that some Debian bugs are ignored for a long time [...]
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
>
> There is another point: the package maintainer is very autonomous
> in how (s)he does her thing. This has advantages and disadvantages.
>
> There are processes in place for resolving such situations as when
> a maintainer becomes unresponsive (perhaps (s)he has moved on to
> other things, perhaps (s)he is in some situation of distress). Among
> others, there is the NMU [0].

I know about nmu, and I submitted one once but withdrew it because the
package maintainer did eventually indicate a fix the problem was coming
once I sent out the nmu.

>
> This question comes up regularly in this list. Had you searched
> the archives, you'd found things like this [1] with advice (hint:
> this would leave developers more time for fixing bugs ;-)
>
> There is good advice by Jonathan Dowland in the linked thread on
> how to do something about it. Want to give it a try?
>
> > So that means "free" software written and maintained by volunteers will 
> > never be as
> > stable and secure as software that is written by people who are paid by the 
> > hour.
>
> This is, of course, nonsense. This would be only the case if
> the instance giving out the cash had an interest on the software
> being "stable and secure". Most of the time they have an interest
> on the software being sold, or on it generating cash flow via
> other means (gathering user data, for that to be sold, for example).
>
> So they will allocate their resources accordingly. I've worked
> in the belly of big corps for a while and I assure you that my
> boss wouldn't allow me to fix a bug unless (s)he could justify
> to their bosses that the 1400 dollars "spent" on this are coming
> back in some way.
>
> Witness the whole history of Microsoft software with its incredible
> ecosystem of malware, and you'll see how wrong your idea is :)
>
> So each "world" has its upsides and (surprise!) its downsides.
>
> That doesn't mean I wouldn't like to see projects like Debian
> better funded, mind you. There are also people thinking about
> this. There are companies which sponsor Debian, there are
> companies which let employees work for Debian on their company
> time; one seemingly successful example is Freexian [2], which
> offers services by keeping alive older versions of Debian.
>
> I get you want to contribute?

Yes, that's what mystifies me. I don't know why Debian ignores
someone who wants to contribute time to help the project.

In another case, the bug was upstream and although I reported the
bug on Debian first, marked it 'patch' and 'upstream' in the BTS, it was
still being ignored, so I just submitted the patch directly to upstream who
accepted my patch.

Usually upstream projects want and expect users to report bugs to
the distro, not to the upstream project, for many good reasons that I
need not explain here. Then the distro package maintainer, rather
than the user, interacts with the upstream developers and maintainers.
Of course if the distro maintainers ignore upstream bugs reported to the
distro, the whole free software ecosystem will suffer, not just Debian.

Best regards,

Chuck

> [0] https://wiki.debian.org/NonMaintainerUpload
> [1] https://lists.debian.org/debian-user/2022/05/threads.html#00028
> [2] https://www.freexian.com/services/debian-lts.html
>

Re: Why are some Debian bugs ignored for a long time?

[Brian]

On Fri 19 Aug 2022 at 13:57:29 -0400, Chuck Zmudzinski wrote:

> Hello,
> 
> I have noticed that some Debian bugs are ignored for a long time,
> sometimes even when the person who submitted the bug offered a patch.
> The Debian developers/maintainers sometimes don't even reply and
> therefore never explain why the proposed patch cannot be applied. Why
> is that the case with Debian developers/maintainers?

AFAICT, there isn't any requirement for a maintainer/triager to engage
with each and every submitted bug report.

  
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-handling

Each report is unique and so is every maintainer. Therefore it is not
possible to generalise with certainty on the reasons for not getting an
immediate response.

Neither should a user have any expectation of a timely interaction, nice
though it may be to be get further involvement from a maintainer.
Reasons for the perceived "ignored" status might be:

 * The maintainer judges that the bug affects very few users.
 * The maintainer does not have the resources to deal with the bug.
 * A solution is already in hand and awaiting upload to unstable.
 * The maintainer puts the report on the back burner and forgets about
   it.
 * The bug is low down on the priority list.
 * The maintainer sees the bug as a user issue and not an issue with
   package quality.
 * The maintainer has little or nothing to contribute that would lead to
   the report progressing.
 * Fixing this issue is not worth the effort, if possible at all.

-- 
Brian.

Re: Why are some Debian bugs ignored for a long time?

[piorunz]

On 19/08/2022 22:06, Chuck Zmudzinski wrote:


So that means "free" software written and maintained by volunteers will never 
be as
stable and secure as software that is written by people who are paid by the 
hour. That is,
Debian software can *never* be as stable and secure as software that is written 
and
maintained by people who are paid by the hour.


Oh,  that  means Microsoft Windows must be most stable OS in the world,
right?
Right?...


 Not only that, you are saying if a Debian
user experiences a bug in Debian software, Debian developers/maintainers do not 
have
to fix it. That's fine, but...

If Debian developers/maintainers actively refuse to fix some bugs that 
inevitably arise
by ignoring them, why would anyone depend on Debian software for anything 
important?


Did you not read Debian disclaimer when you log in?

"The programs included with the Debian GNU/Linux system are free
software; the exact distribution terms for each program are described in
the individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

You are free to use paid software if you think it is somewhat better. In
 line with your logic, I think Microsoft Windows is an excellent choice
for you.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Re: Why are some Debian bugs ignored for a long time?

[Teemu Likonen]

* 2022-08-19 17:06:38-0400, Chuck Zmudzinski wrote:

> On 8/19/2022 4:44 PM, piorunz wrote:

>> Maybe because developers/maintainers are not paid by the hour, but
>> mere volunteers, don't you think?
>
> So that means "free" software written and maintained by volunteers
> will never be as stable and secure as software that is written by
> people who are paid by the hour. That is, Debian software can *never*
> be as stable and secure as software that is written and maintained by
> people who are paid by the hour.

Too much generalizing. If some piece of software has bugs and no active
maintenance then that particular software may be insecure, but not the
whole software category (by maintenance strategy).

Almost every piece of software is maintained different way and has its
own security concerns. There is no general security rule for all
volunteer maintained and all paid-by-hour maintained software. Both
volunteers and companies lose interest in maintaining software at some
point. I don't know which strategy is generally better, but even if I
knew, the knowledge wouldn't say anything about any particular piece of
software.

It's good to bring attention to long-ignored bugs in Debian. It can help
get them fixed sooner.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Why are some Debian bugs ignored for a long time?

[tomas]

On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 4:44 PM, piorunz wrote:
> > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> >
> > > I have noticed that some Debian bugs are ignored for a long time [...]
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?

There is another point: the package maintainer is very autonomous
in how (s)he does her thing. This has advantages and disadvantages.

There are processes in place for resolving such situations as when
a maintainer becomes unresponsive (perhaps (s)he has moved on to
other things, perhaps (s)he is in some situation of distress). Among
others, there is the NMU [0].

This question comes up regularly in this list. Had you searched
the archives, you'd found things like this [1] with advice (hint:
this would leave developers more time for fixing bugs ;-)

There is good advice by Jonathan Dowland in the linked thread on
how to do something about it. Want to give it a try?

> So that means "free" software written and maintained by volunteers will never 
> be as
> stable and secure as software that is written by people who are paid by the 
> hour.

This is, of course, nonsense. This would be only the case if
the instance giving out the cash had an interest on the software
being "stable and secure". Most of the time they have an interest
on the software being sold, or on it generating cash flow via
other means (gathering user data, for that to be sold, for example).

So they will allocate their resources accordingly. I've worked
in the belly of big corps for a while and I assure you that my
boss wouldn't allow me to fix a bug unless (s)he could justify
to their bosses that the 1400 dollars "spent" on this are coming
back in some way.

Witness the whole history of Microsoft software with its incredible
ecosystem of malware, and you'll see how wrong your idea is :)

So each "world" has its upsides and (surprise!) its downsides.

That doesn't mean I wouldn't like to see projects like Debian
better funded, mind you. There are also people thinking about
this. There are companies which sponsor Debian, there are
companies which let employees work for Debian on their company
time; one seemingly successful example is Freexian [2], which
offers services by keeping alive older versions of Debian.

I get you want to contribute? 

;-)

Cheers

[0] https://wiki.debian.org/NonMaintainerUpload
[1] https://lists.debian.org/debian-user/2022/05/threads.html#00028
[2] https://www.freexian.com/services/debian-lts.html

-- 
t


signature.asc
Description: PGP signature

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 9:18 PM, Andy Smith wrote:
> Hi Chuck,
>
> On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 6:59 PM, Andy Smith wrote:
> > > Volunteers cannot be forced to do work, else they are not
> > > volunteers.
> > 
> > The fact that Debian is created by volunteers and therefore the chances are
> > high that users might run into problems and not get help from the volunteers
> > who alone have the power to fix the problems is a fact that Debian users, 
> > and
> > all users of free software, need to keep in mind.
>
> A danger here is that you write as if this is a particular problem
> for Debian, but I think you've merely stated a truism for every
> volunteer effort of any kind.
>
> People do sometimes need reminding that they are relying on a
> volunteer effort, however.
>
> > I am going to try some other projects and find out by experience
> > where the consideration for the user has a higher priority than in
> > Debian.
>
> I am not going to tell you that Debian is the best Linux
> distribution for you or anyone specific, though you could perhaps
> expect responses along those lines given that we're having this
> conversation in a Debian space.
>
> The thing is though, you can experience a problem within one project
> that is frustrating and demotivating and so move to another project
> that does not have that particular problem, only to later experience
> a different problem in the next project that is also frustrating and
> demotivating. Only you can decide which one overall suits you best;
> what's certain is that nothing is going to be perfect.

Of course.

>
> If any Linux distribution were asked, "do you consider the user
> experience to be a high priority?" they are probably all going to
> answer, "yes!" But in reality there will always be some decisions
> (or lack of decisions) made where some number of users feel they
> were mistreated.
>
> If you have the time and interest to look at other distributions
> it's probably not going to be wasted time, anyway, if only to
> compare and contrast.
>
> Cheers,
> Andy
>

Thanks for the feedback, I do have the time to experiment with other distros 
and obviously I will use what best serves my goals. Debian still has the 
advantage that I have been using it for quite a while, have invested much time 
in tweaking it, and it still works fairly well for me. But at this point, I 
don't know if I will upgrade to bookworm or move to another distro before 
bookworm is released.

Best regards,

Chuck

Re: Why are some Debian bugs ignored for a long time?

[Joe Pfeiffer]

Chuck Zmudzinski  writes:

> On 8/19/2022 6:59 PM, Andy Smith wrote:
>> Hello,
>>
>> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
>> > On 8/19/2022 4:44 PM, piorunz wrote:
>> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
>> > > > I have noticed that some Debian bugs are ignored for a long
>> > > > time, sometimes even when the person who submitted the bug
>> > > > offered a patch. The Debian developers/maintainers sometimes
>> > > > don't even reply and therefore never explain why the proposed
>> > > > patch cannot be applied. Why is that the case with Debian
>> > > > developers/maintainers?
>> > >
>> > > Hi Chuck,
>> > >
>> > > Maybe because developers/maintainers are not paid by the hour, but mere
>> > > volunteers, don't you think?
>> > 
>>
>> > you are saying if a Debian user experiences a bug in Debian
>> > software, Debian developers/maintainers do not have to fix it.
>>
>> That is a direct consequence of the meaning of the term "volunteer";
>> you may as well have said, "water is wet". Volunteers cannot be
>> forced to do work, else they are not volunteers.
>
> The fact that Debian is created by volunteers and therefore the chances are
> high that users might run into problems and not get help from the volunteers
> who alone have the power to fix the problems is a fact that Debian users, and
> all users of free software, need to keep in mind.

This is equally true of commercial software: if the company feels it's a
low-enough impact bug it won't get fixed.

Commercial software has the additional risk that a product may simply
be withdrawn from the market.  With cloud-based commercial software,
this means it could completely fail to function (one that's particularly
noticeable is that as companies withdraw from the home automation space,
consumers are discovering their smart home has suddenly become
completely dumb).

Re: Why are some Debian bugs ignored for a long time?

[Andy Smith]

Hi Chuck,

On Fri, Aug 19, 2022 at 08:20:21PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 6:59 PM, Andy Smith wrote:
> > Volunteers cannot be forced to do work, else they are not
> > volunteers.
> 
> The fact that Debian is created by volunteers and therefore the chances are
> high that users might run into problems and not get help from the volunteers
> who alone have the power to fix the problems is a fact that Debian users, and
> all users of free software, need to keep in mind.

A danger here is that you write as if this is a particular problem
for Debian, but I think you've merely stated a truism for every
volunteer effort of any kind.

People do sometimes need reminding that they are relying on a
volunteer effort, however.

> I am going to try some other projects and find out by experience
> where the consideration for the user has a higher priority than in
> Debian.

I am not going to tell you that Debian is the best Linux
distribution for you or anyone specific, though you could perhaps
expect responses along those lines given that we're having this
conversation in a Debian space.

The thing is though, you can experience a problem within one project
that is frustrating and demotivating and so move to another project
that does not have that particular problem, only to later experience
a different problem in the next project that is also frustrating and
demotivating. Only you can decide which one overall suits you best;
what's certain is that nothing is going to be perfect.

If any Linux distribution were asked, "do you consider the user
experience to be a high priority?" they are probably all going to
answer, "yes!" But in reality there will always be some decisions
(or lack of decisions) made where some number of users feel they
were mistreated.

If you have the time and interest to look at other distributions
it's probably not going to be wasted time, anyway, if only to
compare and contrast.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 6:59 PM, Andy Smith wrote:
> Hello,
>
> On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> > On 8/19/2022 4:44 PM, piorunz wrote:
> > > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > > I have noticed that some Debian bugs are ignored for a long time, 
> > > > sometimes even when the person who submitted the bug offered a patch. 
> > > > The Debian developers/maintainers sometimes don't even reply and 
> > > > therefore never explain why the proposed patch cannot be applied. Why 
> > > > is that the case with Debian developers/maintainers?
> > >
> > > Hi Chuck,
> > >
> > > Maybe because developers/maintainers are not paid by the hour, but mere
> > > volunteers, don't you think?
> > 
>
> > you are saying if a Debian user experiences a bug in Debian
> > software, Debian developers/maintainers do not have to fix it.
>
> That is a direct consequence of the meaning of the term "volunteer";
> you may as well have said, "water is wet". Volunteers cannot be
> forced to do work, else they are not volunteers.

The fact that Debian is created by volunteers and therefore the chances are
high that users might run into problems and not get help from the volunteers
who alone have the power to fix the problems is a fact that Debian users, and
all users of free software, need to keep in mind.

>
> > If Debian developers/maintainers actively refuse to fix some bugs that 
> > inevitably arise
> > by ignoring them, why would anyone depend on Debian software for anything 
> > important?
>
> I would argue that the situation is similar (and often worse) in
> every other free software project.

In Linux itself, I think it is *much* better than in Debian. I am going to try 
some other projects
and find out by experience where the consideration for the user has a higher 
priority than in
Debian.

>
> I would also argue that while you may pay a software vendor to care
> about your use case, that can also come with different issues.
>
> So really, life is not perfect, and we all do what we can to cope
> with that. Things are not perfect in Debian nor elsewhere both
> within and outside the free software world.
>
> I think I know some of the bugs that you are referring to as I keep
> on eye on those developments. A gentle ping on the relevant bugs to
> ask where things are may be appropriate.That's really the strongest
> thing you can do.

I do that and I am ignored. I am not holding my breath waiting for a response
from the relevant developers and maintainers. However, it would be a pleasant
surprise if they *did* respond and I would be grateful if they did. I just don't
think volunteers trying to help Debian but who ignore users who report bugs
in Debian is over the long term a good thing for Debian.

> Others may be tempted to try to drag more info out
> of you to determine what the exact history is here and who is
> right/wrong, but I don't think that will help anyone in these
> particular cases.

We agree on that point.

Best regards,

Chuck

Re: Why are some Debian bugs ignored for a long time?

[Andy Smith]

Hello,

On Fri, Aug 19, 2022 at 05:06:38PM -0400, Chuck Zmudzinski wrote:
> On 8/19/2022 4:44 PM, piorunz wrote:
> > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
> > > I have noticed that some Debian bugs are ignored for a long time, 
> > > sometimes even when the person who submitted the bug offered a patch. The 
> > > Debian developers/maintainers sometimes don't even reply and therefore 
> > > never explain why the proposed patch cannot be applied. Why is that the 
> > > case with Debian developers/maintainers?
> >
> > Hi Chuck,
> >
> > Maybe because developers/maintainers are not paid by the hour, but mere
> > volunteers, don't you think?
> 
> So that means "free" software written and maintained by volunteers will never 
> be as
> stable and secure as software that is written by people who are paid by the 
> hour.

This is an assertion of your own that does not automatically follow
from what piorunz wrote.

> That is, Debian software can *never* be as stable and secure as
> software that is written and maintained by people who are paid by
> the hour.

This is also an assertion of your own that does not automatically
follow from what piorunz wrote.

> you are saying if a Debian user experiences a bug in Debian
> software, Debian developers/maintainers do not have to fix it.

That is a direct consequence of the meaning of the term "volunteer";
you may as well have said, "water is wet". Volunteers cannot be
forced to do work, else they are not volunteers.

> If Debian developers/maintainers actively refuse to fix some bugs that 
> inevitably arise
> by ignoring them, why would anyone depend on Debian software for anything 
> important?

I would argue that the situation is similar (and often worse) in
every other free software project.

I would also argue that while you may pay a software vendor to care
about your use case, that can also come with different issues.

So really, life is not perfect, and we all do what we can to cope
with that. Things are not perfect in Debian nor elsewhere both
within and outside the free software world.

I think I know some of the bugs that you are referring to as I keep
on eye on those developments. A gentle ping on the relevant bugs to
ask where things are may be appropriate. That's really the strongest
thing you can do. Others may be tempted to try to drag more info out
of you to determine what the exact history is here and who is
right/wrong, but I don't think that will help anyone in these
particular cases.

Regards,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 6:43 PM, Timothy M Butterworth wrote:
>
>
> On Fri, Aug 19, 2022 at 6:40 PM Chuck Zmudzinski  
> wrote:
>
> On 8/19/2022 6:20 PM, Timothy M Butterworth wrote:
> >
> >
> > On Fri, Aug 19, 2022 at 5:07 PM Chuck Zmudzinski 
>  wrote:
> >
> >     On 8/19/2022 4:44 PM, piorunz wrote:
> >     > On 19/08/2022 18:57, Chuck Zmudzinski wrote:
>     >     >
> >     > > I have noticed that some Debian bugs are ignored for a long 
> time, sometimes even when the person who submitted the bug offered a patch. 
> The Debian developers/maintainers sometimes don't even reply and therefore 
> never explain why the proposed patch cannot be applied. Why is that the case 
> with Debian developers/maintainers?
> >     >
> >     > Hi Chuck,
> >     >
> >     > Maybe because developers/maintainers are not paid by the hour, 
> but mere
> >     > volunteers, don't you think?
> >
> > Debian Stable usually only ships security and stability patches. 
> >  
> >
> >     So that means "free" software written and maintained by volunteers 
> will never be as
> >     stable and secure as software that is written by people who are 
> paid by the hour.
> >
> > Freexian has developers that are paid by the hour to work on Debian, 
> anyone who wants with cash to spare can purchase some hours to have work done 
> on packages of their choosing.
> >
> >   * 2 hours pack: 240 EUR + VAT (120 EUR/hour)
> >   * 5 hours pack: 600 EUR + VAT (120 EUR/hour)
> >   * 10 hours pack: 1150 EUR + VAT (115 EUR/hour)
> >   * 20 hours pack: 2300 EUR + VAT (115 EUR/hour)
> >   * 50 hours pack: 5500 EUR + VAT (110 EUR/hour)
> >
>
> That's good to know. Thanks. Presumably the work they do would be 
> contributed back
> to Debian for the benefit of all. I am curious if they would be able to 
> help in a case when
> a bug with a known fix has been ignored for a long time. I would prefer 
> that Debian would
> just fix the bug instead of having to pay someone to tell Debian they 
> should fix the bug.
>
> I could also just migrate to Fedora since their distro does not have the 
> bug and I wouldn't
> have to pay anyone for my system to work using Fedora.
>
> Distro hopping is one of the best things about Linux, I personally switch 
> between Debian, openSUSE and Fedora. One day I want to roll my own distro. I 
> am planning on making a stripped down debian focusing on KDE Plasma and KDE 
> Apps. One DE one hardware platform.

Yes, the many distros is a nice thing about Linux, and now it looks like it is 
time for
me to start hopping from Debian to other distros when necessary.

Sorry, I forgot to reply-to the list, so I am bringing the discussion back to 
the list.

Thanks,

Chuck

>  
>
> Best regards,
>
> Chuck
> >
> >
> >
> >
> > --
> > ⢀⣴⠾⠻⢶⣦⠀
> > ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> > ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> > ⠈⠳⣄⠀⠀
>
>
>
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀

Re: Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

On 8/19/2022 4:44 PM, piorunz wrote:
> On 19/08/2022 18:57, Chuck Zmudzinski wrote:
>
> > I have noticed that some Debian bugs are ignored for a long time, sometimes 
> > even when the person who submitted the bug offered a patch. The Debian 
> > developers/maintainers sometimes don't even reply and therefore never 
> > explain why the proposed patch cannot be applied. Why is that the case with 
> > Debian developers/maintainers?
>
> Hi Chuck,
>
> Maybe because developers/maintainers are not paid by the hour, but mere
> volunteers, don't you think?

So that means "free" software written and maintained by volunteers will never 
be as
stable and secure as software that is written by people who are paid by the 
hour. That is,
Debian software can *never* be as stable and secure as software that is written 
and
maintained by people who are paid by the hour. Not only that, you are saying if 
a Debian
user experiences a bug in Debian software, Debian developers/maintainers do not 
have
to fix it. That's fine, but...

If Debian developers/maintainers actively refuse to fix some bugs that 
inevitably arise
by ignoring them, why would anyone depend on Debian software for anything 
important?

Best regards,

Chuck

Re: Why are some Debian bugs ignored for a long time?

[piorunz]

On 19/08/2022 18:57, Chuck Zmudzinski wrote:


I have noticed that some Debian bugs are ignored for a long time, sometimes 
even when the person who submitted the bug offered a patch. The Debian 
developers/maintainers sometimes don't even reply and therefore never explain 
why the proposed patch cannot be applied. Why is that the case with Debian 
developers/maintainers?


Hi Chuck,

Maybe because developers/maintainers are not paid by the hour, but mere
volunteers, don't you think?

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Why are some Debian bugs ignored for a long time?

[Chuck Zmudzinski]

Hello,

I have noticed that some Debian bugs are ignored for a long time, sometimes 
even when the person who submitted the bug offered a patch. The Debian 
developers/maintainers sometimes don't even reply and therefore never explain 
why the proposed patch cannot be applied. Why is that the case with Debian 
developers/maintainers?

Best regards,

Chuck

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Vincent Lefevre]

On 2022-07-23 09:29:33 -0400, Greg Wooledge wrote:
> Sometimes, the only way to fix security bugs is to use a newer upstream
> version.  The Debian teams try hard to avoid it, but it has happened
> before, and it will happen again.

Yes, they did that with firefox in the past, with a major consequence
as it broke most extensions.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Greg Wooledge]

On Sat, Jul 23, 2022 at 11:34:45AM +0200, Thomas Schmitt wrote:
> Alexander V. Makartsev wrote:
> > Then why "nvidia-driver" in Stable was switched from previous "460.91.03-1"
> > version to "470.129.06-6~deb11u1"?
> 
>   
> https://tracker.debian.org/news/1345038/accepted-nvidia-graphics-drivers-47012906-6deb11u1bpo101-source-amd64-into-buster-backports-backports-policy-buster-backports/
> closes 24 bugs and fixes 6 CVEs.
> 
> Obviously this was not a cautious detail fix by a concise patch but
> rather a switch to a new upstream release. Already the first CVE in the
> list shows that the old situation was quite desparate.

Sometimes, the only way to fix security bugs is to use a newer upstream
version.  The Debian teams try hard to avoid it, but it has happened
before, and it will happen again.

A couple other packages that have a history of receiving new upstream
versions in stable, in order to fix security bugs, are samba and bind9.
Samba once received such a new version that it required users to change
their configuration files in the middle of a stable release.  Annoying,
but such is the world in which we live.

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Thomas Schmitt]

Hi,

i wrote:
> > Well, "stable" means old software with old bugs. Those who want the new
> > bugs, which are introduced by fixing the old ones, have to run something
> > else.

Alexander V. Makartsev wrote:
> Then why "nvidia-driver" in Stable was switched from previous "460.91.03-1"
> version to "470.129.06-6~deb11u1"?

  
https://tracker.debian.org/news/1345038/accepted-nvidia-graphics-drivers-47012906-6deb11u1bpo101-source-amd64-into-buster-backports-backports-policy-buster-backports/
closes 24 bugs and fixes 6 CVEs.

Obviously this was not a cautious detail fix by a concise patch but
rather a switch to a new upstream release. Already the first CVE in the
list shows that the old situation was quite desparate.

  https://security-tracker.debian.org/tracker/CVE-2022-28181
  "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability
   in the kernel mode layer, where an unprivileged regular user on the
   network can cause an out-of-bounds write through a specially crafted
   shader, which may lead to code execution, denial of service, escalation
   of privileges, information disclosure, and data tampering."

(Actually, given the CVEs and extrapolating the number of undetected similar
vulnerabilities, i would have scruples to employ such a software. But i have
no need for high GPU performance.)


> Should I file a new bug?

I would do. Maybe the problem gets then fixed with the next emergency
upload. But of course it would have to be somewhat reproducible.


> If so, what is the best way to do it, if the last freeze happened 4 days
> ago, according by timestamps in syslog, and now I plan to downgrade the
> driver to be able to use full capabilities of my PC?

I guess you will have to wait with the downgrade several days after you
filed the bug. So the maintainers at least have a theoretical chance to
propose experiments or workarounds.


Have a nice day :)

Thomas

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Alexander V. Makartsev]

On 23.07.2022 12:39, Thomas Schmitt wrote:

Hi,


Surely "Closes:" is very convenient, but wouldn't you agree that this
puts the users of Stable at a disadvantage?

Well, "stable" means old software with old bugs. Those who want the new
bugs, which are introduced by fixing the old ones, have to run something
else.
Then why "nvidia-driver" in Stable was switched from previous 
"460.91.03-1" version to "470.129.06-6~deb11u1"?

    $ rmadison nvidia-driver
    nvidia-driver | 340.106-1    | 
oldoldoldstable/non-free    | amd64, armhf, i386
    nvidia-driver | 390.138-1    | 
oldoldstable/non-free   | amd64, armhf, i386
    nvidia-driver | 418.152.00-1~bpo9+1  | 
stretch-backports/non-free  | amd64, armhf, i386
    nvidia-driver | 418.211.00-1 | 
oldstable/non-free  | amd64, armhf, i386
    nvidia-driver | 470.103.01-1~bpo11+1 | 
bullseye-backports/non-free | amd64, arm64
    nvidia-driver | 470.129.06-6~deb11u1~bpo10+1 | 
buster-backports/non-free   | amd64, arm64
    nvidia-driver | 470.129.06-6~deb11u1 | 
stable/non-free | amd64, arm64
    nvidia-driver | 470.129.06-6 | 
testing/non-free    | amd64, arm64
    nvidia-driver | 470.129.06-6 | 
unstable/non-free   | amd64, arm64
    nvidia-driver | 510.73.08-3  | 
experimental/non-free   | amd64, arm64


This change made my system unstable, causing it to freeze sporadically 
with "Xid" error in syslog.
    kernel: NVRM: GPU at PCI::01:00: 
GPU-7565947f-d476-7159-d106-172c793521e6

    kernel: NVRM: Xid (PCI::01:00): 8, pid=2039, Channel 0010

And now I can't perform an easy enough downgrade to last working version.
Freezes are only happening with 470.xxx versions of the "nvidia-driver", 
every other versions up to 460.91.03 worked flawlessly.


    $ lspci
    ...
    01:00.0 VGA compatible controller: NVIDIA Corporation GP106 
[GeForce GTX 1060 6GB] (rev a1) (prog-if 00 [VGA controller])

    Subsystem: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB]
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast 
>TAbort- SERR- 
    Latency: 0
    Interrupt: pin A routed to IRQ 135
    IOMMU group: 1
    Region 0: Memory at ee00 (32-bit, non-prefetchable) 
[size=16M]

    Region 1: Memory at d000 (64-bit, prefetchable) [size=256M]
    Region 3: Memory at e000 (64-bit, prefetchable) [size=32M]
    Region 5: I/O ports at e000 [size=128]
    Expansion ROM at 000c [virtual] [disabled] [size=128K]
    Capabilities: 
    Kernel driver in use: nvidia
    Kernel modules: nvidia

    $ uname -a
    Linux fortune 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) 
x86_64 GNU/Linux


Should I file a new bug?
If so, what is the best way to do it, if the last freeze happened 4 days 
ago, according by timestamps in syslog, and now I plan to downgrade the 
driver to be able to use full capabilities of my PC?



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Thomas Schmitt]

Hi,

> Surely "Closes:" is very convenient, but wouldn't you agree that this
> puts the users of Stable at a disadvantage?

Well, "stable" means old software with old bugs. Those who want the new
bugs, which are introduced by fixing the old ones, have to run something
else.

I understand that fixes for severe bugs get backported to stable and even
oldstable if they are important enough, and feasible, and the maintainers
take action.
As upstream developer and auxiliary package preparer i only experienced
this once:
  
https://tracker.debian.org/news/1092508/accepted-libburn-150-1deb10u1-source-into-proposed-updates-stable-new-proposed-updates/
along the rules of
  https://www.debian.org/releases/proposed-updates


Have a nice day :)

Thomas

Re: closing Bullseye bugs pointing to a fix in Unstable?

[Tixy]

On Sat, 2022-07-23 at 09:04 +0200, Harald Dunkel wrote:
> Hi folks,
> 
> what is Debian's policy wrt bugs reported for a package in Stable (e.g.
> some daemon eating up 100% CPU)? Looking at the "Closes:" feature for
> debian/changelog I have the impression that a fix in Unstable is seen
> to be sufficient "to get rid" of the bug report.
> 
> Surely "Closes:" is very convenient, but wouldn't you agree that this
> puts the users of Stable at a disadvantage?

As a rule, the Stable release is stable, i.e. unchanging and doesn't
receive bug fixes except for serious security issues. Though some very
serious bugs do get fixed in Stable point releases too, I don't know
what criteria such updates need to meet. I expect that it's the release
team that makes the final decision.

-- 
Tixy 

closing Bullseye bugs pointing to a fix in Unstable?

[Harald Dunkel]

Hi folks,

what is Debian's policy wrt bugs reported for a package in Stable (e.g.
some daemon eating up 100% CPU)? Looking at the "Closes:" feature for
debian/changelog I have the impression that a fix in Unstable is seen
to be sufficient "to get rid" of the bug report.

Surely "Closes:" is very convenient, but wouldn't you agree that this
puts the users of Stable at a disadvantage?


Regards
Harri

Re: How do I see fixed bugs for a package at bugs.debian.org?

[Greg Wooledge]

On Thu, Jul 21, 2022 at 02:16:40PM -0500, kjohn...@eclypse.org wrote:
> I would like to see fixed bugs for the mailman3 package, and related packages.

Start by going to the package's bug page:

<http://bugs.debian.org/mailman3>

At the bottom of the page, there's a form with several fields.

Change the "Select bugs" dropdown from "in package" to "in source package".
Now verify the name of the source package that mailman3 comes from.  In
this case, the source package name is also mailman3, so you can leave
that alone.

Finally, change the last dropdown in the "Misc options" section from
"Unarchived" to "Archived".

How do I see fixed bugs for a package at bugs.debian.org?

[kjohnson]

How do I see fixed bugs for a package at bugs.debian.org?  I can find open bugs 
from https://www.debian.org/Bugs/, but maybe something that has been fixed 
would give me insight.

I would like to see fixed bugs for the mailman3 package, and related packages.

I am trying to migrate from mailman2 to mailman3.  One step is to create a 
brand-new mailman2 list, populate it with a few emails, and then migrate that 
list to mailman3.  The mailman import21 seems to work, but the 
hyperkitty_import does not.  A search of hyperkitty_import on this list comes 
up empty.  My Google searches have not been helpful.  Anyhow, looking at the 
fixed bugs _might_ give me a clue, but I don't see how to do that.

Yes, it will probably seem obvious once I know how.

Thanks,

Ken

Re: Reporting Bugs Against the Debian Website

[Brian]

On Fri 10 Jun 2022 at 19:38:22 +, Jonathan Wiebe wrote:

> I need a pointer as to how to file a bug against the Debian website.

File against www.debian.org.

-- 
Brian.

Reporting Bugs Against the Debian Website

[Jonathan Wiebe]

I need a pointer as to how to file a bug against the Debian website.
The following webpages all contain the text:
The second set of tags indicate what releases a bug applies to: O for oldstable 
(jessie), S for stable (stretch), T for testing (buster), U for unstable (sid) 
or E for experimental.

The text should be:
The second set of tags indicate what releases a bug applies to: O for oldstable 
(buster), S for stable (bullseye), T for testing (bookworm), U for unstable 
(sid) or E for experimental.

Pages containing this text:

-   https://bugs.debian.org/release-critical/other/all.html


-   https://bugs.debian.org/release-critical/other/stable.html


-   https://bugs.debian.org/release-critical/other/testing.html


-   and possibly others.


--
Jonathan Wiebe
"Get thy vaccine." --Matt 22:39

publickey - jonathan.b.wiebe@proton.me - 0x835A0CE0.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: number of bugs affecting a package version

[Andrei POPESCU]

On Ma, 02 feb 21, 14:23:05, kamaraju kusumanchi wrote:
> Is there a way to get the number of bugs filed against a package that
> affect a specific version of a package? The closest I was able to
> achieve is
> 
>  % querybts -u text -b libc6-dev 2> /dev/null | wc -l
> 38
> 
> which shows all bugs filed on libc6-dev. But it does not, for example,
> show me the number of bugs currently affecting 2.28-10 (the version in
> stable) or 2.31-9 (the version in testing).

Considering querybts is meant to be used by reportbug this seems like it 
would be out of scope for it.

Your use case seems more appropriate for 'bts' (in package devscripts), 
though on a quick read of the manpage it seems to support this for the 
'show' command, but not for the 'select' command.

It might be possible to hack something together by setting BROWSER to a 
text browser, but it's probably easier to just use BTS URLs directly, 
e.g. something like:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=testing;package=libc6-dev


UDD might also be worth looking into.

https://wiki.debian.org/UltimateDebianDatabase

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

number of bugs affecting a package version

[kamaraju kusumanchi]

Is there a way to get the number of bugs filed against a package that
affect a specific version of a package? The closest I was able to
achieve is

 % querybts -u text -b libc6-dev 2> /dev/null | wc -l
38

which shows all bugs filed on libc6-dev. But it does not, for example,
show me the number of bugs currently affecting 2.28-10 (the version in
stable) or 2.31-9 (the version in testing).

thanks
raju
-- 
Kamaraju S Kusumanchi | http://www.kamaraju.xyz/dk/blog

libselenium-remote-driver-perl Bugs: 839...@bugs.debian.org

[Alexandre GRIVEAUX]

Hello,


Will trying to install OpenQA on Debian, I discovered a bugs opened on 
bugs.debian.org.


I tried to make the driver, it's seem to work but i've been stuck, how i 
can help DD on this paquages, it's been 5 years old now.



Thanks

Why is my account is been bugs

[Lowles]

Why is my account is been bugs
My

Re: I would like some assistance filing two xen related bugs

[Andy Smith]

Hello,

On Sun, Jun 28, 2020 at 01:42:02PM +0200, Daniel Widenfalk wrote:
> I would very much appreciate some quick pointers on how to properly report
> this so that I don't have to dig up my posts to the xen users mailing list
> to figure out something I already should know.

Xen is a pretty fringe technology so I wouldn't expect there to be
much of a community of users and developers on debian-user. I use it
but don't have any useful input to your questions.

You can reach Debian's Xen maintainers on pkg-xen-devel:

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel

but they are quite likely to refer you to upstream's xen-user or
xen-devel lists.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

I would like some assistance filing two xen related bugs

[Daniel Widenfalk]

Hi,

Four years ago I ran into two issues with the xen support in Debian - at 
that time I forgot to report these issues back to Debian. Now, when 
setting up a new machine I ran into the second of these issues (and it 
turned out that the first one was still there).


Scenario: An Amd 3700X CPU on a X570 based motherboard

1) Using EFI boot will incorrectly add "no-real-mode edd=off" to the 
kernel (xen) command line:


For me this manifested (four years ago) as not getting a working 
console. Digging around it turned out that the GRUB script generator 
(20_linux_xen) emitted code that checked if $grub_platform was either 
"pc" or "". When using EFI boot this variable gets set to "efi". This 
mismatch causes the script to add "no-real-mode edd=off" to the command 
line.


In latest stable Debian this works, although it still adds those two 
kernel (xen) command line options. The fix is very simple:


--- /etc/grub.d/20_linux_xen~   2020-06-28 12:37:08.394067050 +0200
+++ /etc/grub.d/20_linux_xen2020-06-28 12:41:46.056439654 +0200
@@ -125,7 +125,7 @@
   lmessage="$(gettext_printf "Loading Linux %s ..." ${version})"
   sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$xmessage" | grub_quote)'
-if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "" ]; then
+if [ "\$grub_platform" = "pc" -o "\$grub_platform" = "efi" -o 
"\$grub_platform" = "" ]; then

 xen_rm_opts=
 else
 xen_rm_opts="no-real-mode edd=off"

2) CPU frequency scaling does not seem to work.

This one was a bit trickier to figure out. You can see my mail (from 
2016) to the xen users mailing list here: 
http://xen.1045712.n5.nabble.com/CPU-frequency-scaling-there-be-dragons-here-td5732214.html


The core issue is that the xen-acpi-processor module is not loaded 
during boot which in turn causes the xen/drivers/cpufreq stuff to not 
get initialized. Again, the fix was very simple - just add 
xen-acpi-processor to /etc/modules. I guess this should be done whenever 
installing the xen hypervisor?


I would very much appreciate some quick pointers on how to properly 
report this so that I don't have to dig up my posts to the xen users 
mailing list to figure out something I already should know.


/D

Re: Reporting bugs in Stable

[David Wright]

On Mon 20 Apr 2020 at 00:11:08 (-0700), Ihor Antonov wrote:
> On Sunday, 19 April 2020 23:30:43 PDT Andrei POPESCU wrote:
> > On Du, 19 apr 20, 13:28:57, Ihor Antonov wrote:
> > > Reporting from Debian Sid, everything is quite stable. I do run ZFS on
> > > root
> > > and make snapshots prior to big upgrades as a pre-caution, but so far
> > > I did not have a reason to revert anything.
> > 
> > It's just a matter of time. Even if Debian does much more automated
> > testing now than in the past some serious issues could still slip
> > through.
> 
> I know, for me this is exactly the point: unstable becomes stable only if 
> someone uses it and finds out issues, reports/fixes them. 
> 
> > > I was using Archlinux for a long time, and I can say that Sid feels
> > > more stable than Archlinux, although software is less fresh. But
> > > overall quite usable as a daily driver on my Lenovo X1 Extreme
> > 
> > As far as I know Archlinux is also not a beginners distro (like Mint or
> > Ubuntu), so issues that may appear trivial to you can be major
> > showstoppers for others.
> 
> Absolutely, no disputing that. 
> I was trying to make a point that "unstable", despite scary name is quite 
> usable. Also as someone mentioned - backports should be the first option to 
> try 
> if you run stable. I run a few servers stable + backports and everything is 
> rock-solid.
> 
> But I am afraid that we have deviated from the original topic.  If I 
> understood Carl correctly - he was expressing his pain because of  
> bureaucratic scrutiny of filing bugs to stable that brings absolutely no 
> results.

"Told not to bother" and "bureaucratic scrutiny" don't exactly explain
the problem.

> I can't help much here as I am just a mere user, but IMHO if software 
> in stable does not work - it is a severe bug.

A bit of an assumption here. There are such things as normal and minor
bugs, and also the fact that many users may never happen upon the
circumstances that trigger a bug's effect. That's one of the reasons
they need reporting.

> It has to be either fixed or 
> software should be removed from stable.

Steady on: we want some software to remain available. Even some
serious and important bugs may have no effect on users' workflow,
or be easily worked around if people are able to find out that
they exist (by being reported).

Cheers,
David.

Re: Reporting bugs in Stable

[Ihor Antonov]

On Sunday, 19 April 2020 23:30:43 PDT Andrei POPESCU wrote:
> On Du, 19 apr 20, 13:28:57, Ihor Antonov wrote:
> > Reporting from Debian Sid, everything is quite stable. I do run ZFS on
> > root
> > and make snapshots prior to big upgrades as a pre-caution, but so far
> > I did not have a reason to revert anything.
> 
> It's just a matter of time. Even if Debian does much more automated
> testing now than in the past some serious issues could still slip
> through.

I know, for me this is exactly the point: unstable becomes stable only if 
someone uses it and finds out issues, reports/fixes them. 

> > I was using Archlinux for a long time, and I can say that Sid feels
> > more stable than Archlinux, although software is less fresh. But
> > overall quite usable as a daily driver on my Lenovo X1 Extreme
> 
> As far as I know Archlinux is also not a beginners distro (like Mint or
> Ubuntu), so issues that may appear trivial to you can be major
> showstoppers for others.

Absolutely, no disputing that. 
I was trying to make a point that "unstable", despite scary name is quite 
usable. Also as someone mentioned - backports should be the first option to try 
if you run stable. I run a few servers stable + backports and everything is 
rock-solid.


But I am afraid that we have deviated from the original topic.  If I 
understood Carl correctly - he was expressing his pain because of  
bureaucratic scrutiny of filing bugs to stable that brings absolutely no 
results. I can't help much here as I am just a mere user, but IMHO if software 
in stable does not work - it is a severe bug. It has to be either fixed or 
software should be removed from stable.


Thanks

Ihor Antonov

Re: Reporting bugs in Stable

[Andrei POPESCU]

On Du, 19 apr 20, 13:28:57, Ihor Antonov wrote:
>  
> Reporting from Debian Sid, everything is quite stable. I do run ZFS on root 
> and make snapshots prior to big upgrades as a pre-caution, but so far 
> I did not have a reason to revert anything.

It's just a matter of time. Even if Debian does much more automated 
testing now than in the past some serious issues could still slip 
through.

> I was using Archlinux for a long time, and I can say that Sid feels 
> more stable than Archlinux, although software is less fresh. But 
> overall quite usable as a daily driver on my Lenovo X1 Extreme

As far as I know Archlinux is also not a beginners distro (like Mint or 
Ubuntu), so issues that may appear trivial to you can be major 
showstoppers for others.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Reporting bugs in Stable

[Keith Bainbridge]

On 20/4/20 12:26 am, Andrei POPESCU wrote:

On Du, 19 apr 20, 09:43:46, Carl Fink wrote:

So this has bugged me every time I run Debian Stable: you find a bug. You
try to report it, and are told not to bother because there's a newer
version.


By? I'm guessing you mean the standard request from reportbug to try a
newer version.
  

Why is reportbug even in Stable? Why not just replace it with a script that
says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
literally the Debian policy, that only security fixes are done in Stable.


Actually bugs of severity "important" or higher can be fixed in stable,
provided certain criteria are met.
  

So, actual question: how usable is the current Testing?


It's usable, though with less guarantees. Have a backup plan in case of
breakage. Mine is typically a paralel stable install, though other
methods exist (e.g. snapshots)

Kind regards,
Andrei



Agree. I have had a couple of issues, but reverting a few days with my 
snapshot has saved my   a couple of times - not for several months 
now, though.   I use timeshift, which is usable from terminal or a live 
.iso of a linux which includes timeshift as a default. Try Mint if you 
don't have a better option.



You will get more downloads with package updates though. But that is the 
real difference between stable and testing - testing finds bits that 
still need updating. Even SID is a stable OS, just gets even more 
packages updated (from memory, packages stay in SID until about 2 weeks 
of no major issues?).




--
Keith Bainbridge

ke1th3...@zoho.com
+61 (0)447 667 468

Re: Reporting bugs in Stable

[David Wright]

On Sun 19 Apr 2020 at 09:43:46 (-0400), Carl Fink wrote:
> So this has bugged me every time I run Debian Stable: you find a bug. You
> try to report it, and are told not to bother because there's a newer
> version. There is no way to install the newer version without manually
> fiddling with pointlessly arcane configuration files that are sort of 
> documented
> if you squint.
> 
> (Yes, the pun on "bug" is deliberate.)
> 
> Why is reportbug even in Stable? Why not just replace it with a script that
> says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
> literally the Debian policy, that only security fixes are done in Stable.
> 
> Yes, technically if the version number in Stable and Experimental are the
> same, the bug might get fixed, but the fix would never actually be in Stable
> until the current Testing is released.

Aren't you assuming that a bug fix is the sole use for the Bug
Tracking System. I find it's a help when I suspect that I might
be seeing the effect of a bug. It can also be useful for finding
workarounds, and for comparing competing packages. You can also get
advanced warning of serious bugs by apt-listbugs before you install
a package.

> So, actual question: how usable is the current Testing? Because Stable is
> ... not so much, and decreasing. (It's fine as a server OS, it's just as a
> client box that it effectively degrades over time as software upgrades don't
> happen.)

I'm not sure I understand: isn't it your perspective that changes,
as you discover unfixed bugs. The software itself stays the same.

However, as someone obviously keen to report bugs, your using Testing
could be valuable for the project.

Cheers,
David.

Re: Reporting bugs in Stable

[riveravaldez]

On 4/19/20, Andrei POPESCU  wrote:
> On Du, 19 apr 20, 09:43:46, Carl Fink wrote:
>> So this has bugged me every time I run Debian Stable: you find a bug. You
>> try to report it, and are told not to bother because there's a newer
>> version.
>
> By? I'm guessing you mean the standard request from reportbug to try a
> newer version.
>
>> Why is reportbug even in Stable? Why not just replace it with a script
>> that
>> says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously,
>> that's
>> literally the Debian policy, that only security fixes are done in Stable.
>
> Actually bugs of severity "important" or higher can be fixed in stable,
> provided certain criteria are met.

Just in case it helps: you also have Backports.

«Backports are packages taken from the next Debian release (called
"testing"), adjusted and recompiled for usage on Debian stable.»[1]

>> So, actual question: how usable is the current Testing?
>
> It's usable, though with less guarantees. Have a backup plan in case of
> breakage. Mine is typically a paralel stable install, though other
> methods exist (e.g. snapshots)

Another option - if disk-space is a concern - is to have a pendrive at
hand with a couple of your preferred (updated) LiveUSB distros in
something like MultiSystem[2] (which I *really* don't know why isn't
available in Debian repositories...) or anything similar that you
like[3].

Best regards.

[1] https://backports.debian.org/
[2] http://liveusb.info/dotclear/
[3] 
https://alternativeto.net/software/multisystem/?license=opensource&platform=linux

Re: Reporting bugs in Stable

[Ihor Antonov]

On Sunday, 19 April 2020 07:26:31 PDT Andrei POPESCU wrote:
> On Du, 19 apr 20, 09:43:46, Carl Fink wrote:
> > So this has bugged me every time I run Debian Stable: you find a bug. You
> > try to report it, and are told not to bother because there's a newer
> > version.
> 
> By? I'm guessing you mean the standard request from reportbug to try a
> newer version.
> 
> > Why is reportbug even in Stable? Why not just replace it with a script
> > that
> > says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously,
> > that's literally the Debian policy, that only security fixes are done in
> > Stable.
> Actually bugs of severity "important" or higher can be fixed in stable,
> provided certain criteria are met.
> 
> > So, actual question: how usable is the current Testing?
 
Reporting from Debian Sid, everything is quite stable. I do run ZFS on root 
and make snapshots prior to big upgrades as a pre-caution, but so far I did 
not have a reason to revert anything. I was using Archlinux for a long time, 
and I can say that Sid feels more stable than Archlinux, although software is 
less fresh. But overall quite usable as a daily driver on my Lenovo X1 Extreme

---
Ihor Antonov

Re: Reporting bugs in Stable

[Jim Popovitch]

On Sun, 2020-04-19 at 10:27 -0400, Carl Fink wrote:
> On Sun, Apr 19, 2020 at 09:51:02AM -0400, Jim Popovitch wrote:
> 
> > What applications do you feel aren't up-to-date enough for your liking?
> > I'm genuinely curious.
> 
> Mr. Heskett's comments made me want to tell him how to lower the CPU usage
> of BOINC. However, boinc-manager in Stable, at least on my system, has a bug
> resulting in a blank Computing Preferences dialog. 
> 
> (Options >> Computing preferences)
> 
> > > So, actual question: how usable is the current Testing? Because Stable is
> > > ... not so much, and decreasing. (It's fine as a server OS, it's just as a
> > > client box that it effectively degrades over time as software upgrades 
> > > don't
> > > happen.)
> > 
> > I run stable on a work laptop, it's quite stable (which is what I want
> > out of it)
> 
> This is, of course, not actually an answer to my question.

It wasn't meant to be.  It was a comment on how stable, for me, is
certainly not degrading over time.  

Best wishes,

-Jim P.

Re: Reporting bugs in Stable

[Celejar]

On Sun, 19 Apr 2020 09:51:02 -0400
Jim Popovitch  wrote:

> On Sun, 2020-04-19 at 09:43 -0400, Carl Fink wrote:
> > Why is reportbug even in Stable? Why not just replace it with a script that
> > says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
> > literally the Debian policy, that only security fixes are done in Stable.
> 
> I agree with your sentiments, but need to point out that some
> applications are updated regularly in stable (Firefox-ESR is one that
> comes to mind), and there are regular point-releases that contain
> updates.   

To clarify: the official absolute assertion that:

"Once a Debian version is released and tagged `stable' it will only get
security updates. That is, only packages for which a security
vulnerability has been found after the release will be upgraded." [1]

is not quite accurate - point releases also fix "important bugs in the
current release." [2]

Additionally, it's not always clear what constitutes a security
vulnerability. In any event, a quick browsing of (for example) the most
recent (10.3) point release notice shows that numerous bugs that aren't
necessarily security vulnerabilities have indeed been fixed. [3]

[1] 
https://www.debian.org/doc/manuals/debian-faq/getting-debian.en.html#updatestable
[2] https://wiki.debian.org/DebianReleases/PointReleases
[3] https://www.debian.org/News/2020/20200208

Celejar

Re: Reporting bugs in Stable

[Carl Fink]

On Sun, Apr 19, 2020 at 09:51:02AM -0400, Jim Popovitch wrote:

> What applications do you feel aren't up-to-date enough for your liking?
> I'm genuinely curious.

Mr. Heskett's comments made me want to tell him how to lower the CPU usage
of BOINC. However, boinc-manager in Stable, at least on my system, has a bug
resulting in a blank Computing Preferences dialog. 

(Options >> Computing preferences)

> > So, actual question: how usable is the current Testing? Because Stable is
> > ... not so much, and decreasing. (It's fine as a server OS, it's just as a
> > client box that it effectively degrades over time as software upgrades don't
> > happen.)
> 
> I run stable on a work laptop, it's quite stable (which is what I want
> out of it)

This is, of course, not actually an answer to my question.
-- 
Carl Fink  c...@finknetwork.com 
https://reasonablyliterate.com   https://nitpicking.com 
If you want to make a point, somebody will take the point and stab you with it. 
-Kenne Estes

Re: Reporting bugs in Stable

[Andrei POPESCU]

On Du, 19 apr 20, 09:43:46, Carl Fink wrote:
> So this has bugged me every time I run Debian Stable: you find a bug. You
> try to report it, and are told not to bother because there's a newer
> version.

By? I'm guessing you mean the standard request from reportbug to try a 
newer version.
 
> Why is reportbug even in Stable? Why not just replace it with a script that
> says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
> literally the Debian policy, that only security fixes are done in Stable.

Actually bugs of severity "important" or higher can be fixed in stable, 
provided certain criteria are met.
 
> So, actual question: how usable is the current Testing? 

It's usable, though with less guarantees. Have a backup plan in case of 
breakage. Mine is typically a paralel stable install, though other 
methods exist (e.g. snapshots)

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Reporting bugs in Stable

[Jim Popovitch]

On Sun, 2020-04-19 at 09:43 -0400, Carl Fink wrote:
> Why is reportbug even in Stable? Why not just replace it with a script that
> says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
> literally the Debian policy, that only security fixes are done in Stable.

I agree with your sentiments, but need to point out that some
applications are updated regularly in stable (Firefox-ESR is one that
comes to mind), and there are regular point-releases that contain
updates.   

What applications do you feel aren't up-to-date enough for your liking?
I'm genuinely curious.

> So, actual question: how usable is the current Testing? Because Stable is
> ... not so much, and decreasing. (It's fine as a server OS, it's just as a
> client box that it effectively degrades over time as software upgrades don't
> happen.)

I run stable on a work laptop, it's quite stable (which is what I want
out of it)

-Jim P.

Reporting bugs in Stable

[Carl Fink]

So this has bugged me every time I run Debian Stable: you find a bug. You
try to report it, and are told not to bother because there's a newer
version. There is no way to install the newer version without manually
fiddling with pointlessly arcane configuration files that are sort of documented
if you squint.

(Yes, the pun on "bug" is deliberate.)

Why is reportbug even in Stable? Why not just replace it with a script that
says "Sorry, bugs in Stable are never fixed. Try Testing." Seriously, that's
literally the Debian policy, that only security fixes are done in Stable.

Yes, technically if the version number in Stable and Experimental are the
same, the bug might get fixed, but the fix would never actually be in Stable
until the current Testing is released.

So, actual question: how usable is the current Testing? Because Stable is
... not so much, and decreasing. (It's fine as a server OS, it's just as a
client box that it effectively degrades over time as software upgrades don't
happen.)
-- 
Carl Fink  c...@finknetwork.com 
https://reasonablyliterate.com   https://nitpicking.com 
If you want to make a point, somebody will take the point and stab you with it. 
-Kenne Estes

Re: Reporting Spam in Debian Bugs (and geogebra 4.2+ is non-free btw)?

[Sven Joachim]

On 2019-11-17 20:48 +, Brian wrote:

> On Sun 17 Nov 2019 at 21:36:11 +0100, Linux-Fan wrote:
>
>> Brian writes:
>>
>> > On Sun 17 Nov 2019 at 21:01:16 +0100, Linux-Fan wrote:
>>
>> [...]
>>
>> > >  Verify report for bug 692728
>> > >  Yes, report that bug 692728 has spam
>> > >
>> > > Now I am not sure (maybe it's a language thing): Is it OK to continue
>> > > eventhough most of the bug is quite important discussion and only the 
>> > > last
>> > > message is spam? Will that work as intended (only removing the last
>> > > message)
>> > > when I continue on that page?
>> >
>> > Continue with reporting the spam message. It does not remove the bug
>> > record. You will not bring the BTS to its knees by doing this.
>> >
>> > In fact, it does not remove the spam. That has to be done by hand by
>> > a user who is involved in spam removal.
>>
>> [...]
>>
>> Thank you very much for the clarification. I proceeded with reporting the
>> spam and it now says:
>>
>>  Report accepted
>>  Thank you for reporting that this bug log contains spam. These reports 
>> are
>>  reviewed regularly and used to clean the bug logs and train the spam
>>  filters.
>>
>> Which makes it perfectly clear for me :)
>
> Reviewing is the issue. It needs a real person to read the mail, make
> a judgement and do it. Half-a-dozen dedicated volunteers would probably
> be enough to keep the BTS clean of spam.

AFAICT the number of volunteers has been zero for many years.  I have
reported dozens if not hundreds of spam-infested bugs, and never saw the
spam actually removed.

So reporting a bug as spam does not do any harm, but it is a minor waste
of time in my experience.

Cheers,
   Sven

Re: Reporting Spam in Debian Bugs (and geogebra 4.2+ is non-free btw)?

[Brian]

On Sun 17 Nov 2019 at 21:36:11 +0100, Linux-Fan wrote:

> Brian writes:
> 
> > On Sun 17 Nov 2019 at 21:01:16 +0100, Linux-Fan wrote:
> 
> [...]
> 
> > >   Verify report for bug 692728
> > >   Yes, report that bug 692728 has spam
> > >
> > > Now I am not sure (maybe it's a language thing): Is it OK to continue
> > > eventhough most of the bug is quite important discussion and only the last
> > > message is spam? Will that work as intended (only removing the last
> > > message)
> > > when I continue on that page?
> > 
> > Continue with reporting the spam message. It does not remove the bug
> > record. You will not bring the BTS to its knees by doing this.
> > 
> > In fact, it does not remove the spam. That has to be done by hand by
> > a user who is involved in spam removal.
> 
> [...]
> 
> Thank you very much for the clarification. I proceeded with reporting the
> spam and it now says:
> 
>   Report accepted
>   Thank you for reporting that this bug log contains spam. These reports 
> are
>   reviewed regularly and used to clean the bug logs and train the spam
>   filters.
> 
> Which makes it perfectly clear for me :)

Reviewing is the issue. It needs a real person to read the mail, make
a judgement and do it. Half-a-dozen dedicated volunteers would probably
be enough to keep the BTS clean of spam.

-- 
Brian.

Re: Reporting Spam in Debian Bugs (and geogebra 4.2+ is non-free btw)?

[Linux-Fan]

Brian writes:


On Sun 17 Nov 2019 at 21:01:16 +0100, Linux-Fan wrote:


[...]


>Verify report for bug 692728
>Yes, report that bug 692728 has spam
>
> Now I am not sure (maybe it's a language thing): Is it OK to continue
> eventhough most of the bug is quite important discussion and only the last
> message is spam? Will that work as intended (only removing the last
> message)
> when I continue on that page?

Continue with reporting the spam message. It does not remove the bug
record. You will not bring the BTS to its knees by doing this.

In fact, it does not remove the spam. That has to be done by hand by
a user who is involved in spam removal.


[...]

Thank you very much for the clarification. I proceeded with reporting the
spam and it now says:

Report accepted
Thank you for reporting that this bug log contains spam. These reports 
are
reviewed regularly and used to clean the bug logs and train the spam
filters.

Which makes it perfectly clear for me :)

Thanks again
Linux-Fan

Re: Reporting Spam in Debian Bugs (and geogebra 4.2+ is non-free btw)?

[Brian]

On Sun 17 Nov 2019 at 21:01:16 +0100, Linux-Fan wrote:

> I just came across the following bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692728
> It is really a shame that the program is no longer licensed freely*** :(
> 
> If one scrolls down to the last message of the bug, it seems to be spam and
> a dangerous one at that with a suspicious .zip attachment. I have not
> checked it's contents though.
> 
> However, wanting to report it as spam, I pressed the link at
> "Send a report that this bug log contains spam." which leads to a
> confirmation page:
> 
>   Verify report for bug 692728
>   Yes, report that bug 692728 has spam
> 
> Now I am not sure (maybe it's a language thing): Is it OK to continue
> eventhough most of the bug is quite important discussion and only the last
> message is spam? Will that work as intended (only removing the last message)
> when I continue on that page?

Continue with reporting the spam message. It does not remove the bug
record. You will not bring the BTS to its knees by doing this.

In fact, it does not remove the spam. That has to be done by hand by
a user who is involved in spam removal.

-- 
Brian.

Reporting Spam in Debian Bugs (and geogebra 4.2+ is non-free btw)?

[Linux-Fan]

Hello fellow list members,

I just came across the following bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692728
It is really a shame that the program is no longer licensed freely*** :(

If one scrolls down to the last message of the bug, it seems to be spam and
a dangerous one at that with a suspicious .zip attachment. I have not
checked it's contents though.

However, wanting to report it as spam, I pressed the link at
"Send a report that this bug log contains spam." which leads to a
confirmation page:

Verify report for bug 692728
Yes, report that bug 692728 has spam

Now I am not sure (maybe it's a language thing): Is it OK to continue
eventhough most of the bug is quite important discussion and only the last
message is spam? Will that work as intended (only removing the last message)
when I continue on that page?

TIA
Linux-Fan
(academic /and/ commercial user)

~~~ ~~~ ~~~ ~~~

***OT for those interested:

I actually came there because I went on Geogebra's website to check how one
does 3D points. It seems to work with Version 5+, but on the website it has
"noncommercial" all over. Now that I knew that it is in Debian, my first
reaction was: What it must be in non-free? Then $ apt-cache policy geogebra
revealed `main` so I thought: It's free, nice! Then I went to check and saw
that Debian sid has this old version 4.X where 6 seems to be current... I
wondered if there was a bug about it and yes: That harmless wishlist bug has
all the stuff of interest. Thank you very much all Debian maintainers that
you take so much effort to steer back those "noncommercial" folks back to
free software... although in this case it seems not to have been fruitful
(one might be hopeful: yet?)?

I have been recommending geogebra ever since I knew about its existence.
Seems this came to a sudden end today (the last time such a thing happened
was literally years ago:
https://lists.debian.org/debian-user/2012/06/msg02248.html).

I need some help with some old Bugs

[TJ Johnson]

I would appreciate it since y’all received it

Sent from my iPhone

Re: how to report bugs? (reportbug broken)

[David Wright]

On Wed 22 May 2019 at 13:32:09 (-0400), nico.schloe...@gmail.com wrote:
> > Try avoid the GUI mode of reportbug.
> 
> How do I do this? `reportbug -h` doesn't say anything about it.

Supply 'text' to -u.

$ reportbug -h | grep -i interface
  -u INTERFACE, --interface=INTERFACE, --ui=INTERFACE
choose which user interface to use
$ 

Cheers,
David.

Re: how to report bugs? (reportbug broken)

[Jonas Smedegaard]

Quoting nico.schloe...@gmail.com (2019-05-22 19:32:09)
> Thank you too for the quick reply.
> 
> > Try avoid the GUI mode of reportbug.
> 
> How do I do this? `reportbug -h` doesn't say anything about it.

On my Debian system `man reportbug` mentions "gtk" in relation to a "-u" 
option - if yours doesn't then I guess that's one of the areas Ubuntu 
differ, or perhaps a difference in versions used: I use reportbug 7.5.2.

Maybe do `reportbug --configure`


> > If literally "nothing happened"
> 
> Your scepticism prompted me to check again and indeed, I had 
> overlooked a failure message from debian. Apparently, there was 
> something wrong with my "pseudo headers". I'll read the instructions 
> [1] again and try once more.

Nice :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: how to report bugs? (reportbug broken)

[Nico Schlömer]

Okay, I couldn't figure out how to change the the order of paths in
`sys.path`, but I went ahead and removed
```
pip3 uninstall pysimplesoap
```
from `~/.local/`. I have no idea what was the difference between my
locally installed version and the system version but reportbug works
now.

Thanks everyone, cheers,
Nico

On Wed, May 22, 2019 at 7:33 PM Michael Lange  wrote:
>
> On Wed, 22 May 2019 19:04:52 +0200
> Nico Schlömer  wrote:
>
> > Thanks Michael for the quick response!
> > ```
> > python3 -c "import sys; print(sys.path)"
> > ```
> > gives
> > ```
> > ['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
> > '/usr/lib/python3.7/lib-dynload',
> > '/home/nschloe/.local/lib/python3.7/site-packages',
> > '/usr/local/lib/python3.7/dist-packages',
> > '/usr/lib/python3/dist-packages']
> > ```
> > Looks normal?
>
> Actually not, '/usr/lib/python3/dist-packages' should appear
> before '/home/nschloe/.local/lib/python3.7/site-packages' (resp. your
> custom Python should be at the very end of sys.path). Obviously this is
> the reason why reportbug tries to import some module from your custom
> Python3 install which refuses to work. You should definitely fix this,
> otherwise the next bad surprise will be waiting just around the corner ;)
>
> I am not sure how to do this properly, though. Maybe the Python-path is
> somehow created from $PATH, is your ~/.local somewhere in $PATH and could
> you possibly move it to the end?
>
> According to
> https://stackoverflow.com/questions/18247333/python-pythonpath-in-linux
> you could also try to set the PYTHONPATH environment variable with
> something like
> export
> PYTHONPATH="":/usr/lib/python37.zip:/usr/lib/python3.7:/usr/lib/python3/dist-packages:
> (etc.)
>
> however I am not sure if this is actually wise (Python2 should also be
> taken into account of course).
>
> As a quick-and-dirty workaround you could try to add something like
>
> import sys
> sys.path = ['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
> '/usr/lib/python3.7/lib-dynload',
> '/usr/local/lib/python3.7/dist-packages',
> '/usr/lib/python3/dist-packages']
>
> to the very beginning of /usr/bin/reportbug .
> This wouldn't help with other misbehaving Python3 programs of course.
>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> Our way is peace.
> -- Septimus, the Son Worshiper, "Bread and Circuses",
>stardate 4040.7.
>

Re: how to report bugs? (reportbug broken)

[Michael Lange]

On Wed, 22 May 2019 19:04:52 +0200
Nico Schlömer  wrote:

> Thanks Michael for the quick response!
> ```
> python3 -c "import sys; print(sys.path)"
> ```
> gives
> ```
> ['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
> '/usr/lib/python3.7/lib-dynload',
> '/home/nschloe/.local/lib/python3.7/site-packages',
> '/usr/local/lib/python3.7/dist-packages',
> '/usr/lib/python3/dist-packages']
> ```
> Looks normal?

Actually not, '/usr/lib/python3/dist-packages' should appear
before '/home/nschloe/.local/lib/python3.7/site-packages' (resp. your
custom Python should be at the very end of sys.path). Obviously this is
the reason why reportbug tries to import some module from your custom
Python3 install which refuses to work. You should definitely fix this,
otherwise the next bad surprise will be waiting just around the corner ;)

I am not sure how to do this properly, though. Maybe the Python-path is
somehow created from $PATH, is your ~/.local somewhere in $PATH and could
you possibly move it to the end?

According to
https://stackoverflow.com/questions/18247333/python-pythonpath-in-linux
you could also try to set the PYTHONPATH environment variable with
something like
export
PYTHONPATH="":/usr/lib/python37.zip:/usr/lib/python3.7:/usr/lib/python3/dist-packages:
(etc.)

however I am not sure if this is actually wise (Python2 should also be
taken into account of course).

As a quick-and-dirty workaround you could try to add something like

import sys 
sys.path = ['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload',
'/usr/local/lib/python3.7/dist-packages',
'/usr/lib/python3/dist-packages']

to the very beginning of /usr/bin/reportbug .
This wouldn't help with other misbehaving Python3 programs of course.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Our way is peace.
-- Septimus, the Son Worshiper, "Bread and Circuses",
   stardate 4040.7.

Re: how to report bugs? (reportbug broken)

[nico . schloemer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Jonas,

Thank you too for the quick reply.

> Try avoid the GUI mode of reportbug.

How do I do this? `reportbug -h` doesn't say anything about it.

> If you happen to use reportbug-ng

Nope.

> If literally "nothing happened"

Your scepticism prompted me to check again and indeed, I had overlooked a
failure message from debian. Apparently, there was something wrong with my
"pseudo headers". I'll read the instructions [1] again and try once more.

Cheers,
Nico

[1] https://www.debian.org/Bugs/Reporting
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.7.7 Gmail Encryption
Comment: Seamlessly send and receive encrypted email

wsFcBAEBCAAGBQJc5YeXAAoJEJFPgzQ3IEx1jw8QAJjbY81vCVNrYDB6InJB
fxj+yVPYq5xJg6MMqIptOVL4U0Y4sx8Lc17B+ngCeFO2ZBSZLWssVGgWUFfW
fXWuO32Y25/0iRWkg6J3lAg7/4MqMTOH75kGnLZpApWBT4DV8F4mMPdyghRw
nIbdsA6uXvr+Yd45QGYdzN/Y9plWlXVJqpZh2c+nC5ICDC8OxACDJd5hzwV2
8cE8+8YAvUXh3vprnRyFRPdA4g6g1GRdjgzdyifRlJTfi/nTGMfnsHfcNrqE
zzi9y3kJKwrCHLlWJttFuot1MqiL1Sm/h4HckGtgA9A2e85It/ZqgCQ/TbVO
94Y1VSKxfpE0OgdfmvcifM99TbYJPpvNp9GDebHZvFlPB1+d5Ctz0YEQ8Q9L
WiZZYPsbXuQ0rfjyh4gGqq1AthcJRu0w1gNr9xt4q+fZGzJdmw0cSAqTe+6E
8xgpvduUpOO93w1+TH3WYnoJZWRVUjpwyCxYG6aeF3TD1m+nG7Lsq6HxVOiK
OxeNAqtpHAuKz+dZdPn7frvqO9oyur+lisW6mxyAi6rCUk87nVEQsWytOPp2
n76BDhdua9PvIKYAmae7aBSB5AYZFfcAPe0B3VxZ2ZvnBmMZuIzk/u7Nj6hA
gJaJO6hixpzdDMzwY1oNLc4v1pYTKgjxT5qYCXTAapTLJIXz96+u60cXBvhd
ZaeW
=JD9F
-END PGP SIGNATURE-

Re: how to report bugs? (reportbug broken)

[Jonas Smedegaard]

Hi Nico,

Quoting Nico Schlömer (2019-05-22 18:25:16)
> Phew, I find it quite difficult to report bugs in Debian.

[ meta complaints snipped ]

> When launching
> ```
> reportbug -B debian
> ```
> (running Ubuntu 19.04) and after two, three clicks I'm getting

Thanks for mentioning that you use Ubuntu.  I cannot help with eventual 
Ubuntu specifics and you might have better luck asking for advice in 
Ubuntu forums, but let's try...


> 1763, in func
> args, kwargs = op.sync_pre_operation(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line

Try avoid the GUI mode of reportbug.

If you happen to use reportbug-ng (if that even exists any longer) then 
please try use the good old reportbug.



> How can I submit a new bug instead? (Mailing to
> sub...@bugs.debian.org didn't work for me, nothing happened.) Help
> appreciated.

If literally "nothing happened" then you need to consult your mail setup 
or contact your mail service administrator (a.k.a. postmaster): When you 
send an email to the Debian bugtracker - either from an email program or 
using reportbug (which also at the end sends an email unless told 
otherwise) then within 5-10 minutes you should receive a confirmation 
with a bug number.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: how to report bugs? (reportbug broken)

[Nico Schlömer]

Thanks Michael for the quick response!
```
python3 -c "import sys; print(sys.path)"
```
gives
```
['', '/usr/lib/python37.zip', '/usr/lib/python3.7',
'/usr/lib/python3.7/lib-dynload',
'/home/nschloe/.local/lib/python3.7/site-packages',
'/usr/local/lib/python3.7/dist-packages',
'/usr/lib/python3/dist-packages']
```
Looks normal?

Cheers,
Nico

On Wed, May 22, 2019 at 6:57 PM Michael Lange  wrote:
>
> Hi,
>
> On Wed, 22 May 2019 18:25:16 +0200
> Nico Schlömer  wrote:
>
> (...)
>
> > Perhaps I've got an incompatible version of a dependency installed in
> > `~/.local/`?
>
> It looks like this.
>
> Here reportbug uses modules from the default system Python3:
>
> > E: You must put some 'source' URIs in your sources.list
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
> > 1049, in sync_pre_operation
> > http_proxy=http_proxy, archived=archived, source=source)
> >   File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line
> > 1069, in get_reports
> > bugs = debianbts.get_bugs(pkg_filter, package)
> >   File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line
> > 401, in get_bugs
> > reply = soap_client.call('get_bugs', method_el)
> >   File
>
> and now here all of a sudden it uses modules you installed into ~/.local :
>
> > "/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
> > line 256, in call self.xml_response = self.send(method,
> > self.xml_request) File
> > "/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
> > line 318, in send location, http_method, body=xml, headers=headers)
> >   File
> > "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
> > line 1763, in request
> > disable_ssl_certificate_validation=self.disable_ssl_certificate_validation,
> > File
> > "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
> > line 1247, in __init__ context=context, TypeError: fixer() missing 1
> > required positional argument: 'check_hostname'
>
> This doesn't seem sound, I guess this custom Python version is probably
> the culprit. Maybe some environment variable messes with your Python-path?
> What do you get if you do the following:
>
> $ python3
> Python 3.5.3 (default, Sep 27 2018, 17:25:39)
> [GCC 6.3.0 20170516] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> sys.path
> ['', '/usr/lib/python35.zip', '/usr/lib/python3.5',
> '/usr/lib/python3.5/plat-x86_64-linux-gnu',
> '/usr/lib/python3.5/lib-dynload',
> '/usr/local/lib/python3.5/dist-packages',
> '/usr/local/lib/python3.5/dist-packages/pdoc3-0.6.1-py3.5.egg',
> '/usr/local/lib/python3.5/dist-packages/Markdown-3.1-py3.5.egg',
> '/usr/local/lib/python3.5/dist-packages/setuptools-41.0.1-py3.5.egg',
> '/usr/local/lib/python3.5/dist-packages/youtube_dl-2019.5.11-py3.5.egg',
> '/usr/lib/python3/dist-packages']
>
> Regards
>
> Michael
>
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
>
> A man either lives life as it happens to him, meets it head-on and
> licks it, or he turns his back on it and starts to wither away.
> -- Dr. Boyce, "The Menagerie" ("The Cage"), stardate
> unknown
>

Re: how to report bugs? (reportbug broken)

[Michael Lange]

Hi,

On Wed, 22 May 2019 18:25:16 +0200
Nico Schlömer  wrote:

(...)

> Perhaps I've got an incompatible version of a dependency installed in
> `~/.local/`?

It looks like this.

Here reportbug uses modules from the default system Python3:

> E: You must put some 'source' URIs in your sources.list
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
> 1049, in sync_pre_operation
> http_proxy=http_proxy, archived=archived, source=source)
>   File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line
> 1069, in get_reports
> bugs = debianbts.get_bugs(pkg_filter, package)
>   File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line
> 401, in get_bugs
> reply = soap_client.call('get_bugs', method_el)
>   File

and now here all of a sudden it uses modules you installed into ~/.local :

> "/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
> line 256, in call self.xml_response = self.send(method,
> self.xml_request) File
> "/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
> line 318, in send location, http_method, body=xml, headers=headers)
>   File
> "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
> line 1763, in request
> disable_ssl_certificate_validation=self.disable_ssl_certificate_validation,
> File
> "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
> line 1247, in __init__ context=context, TypeError: fixer() missing 1
> required positional argument: 'check_hostname'

This doesn't seem sound, I guess this custom Python version is probably
the culprit. Maybe some environment variable messes with your Python-path?
What do you get if you do the following:

$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python35.zip', '/usr/lib/python3.5',
'/usr/lib/python3.5/plat-x86_64-linux-gnu',
'/usr/lib/python3.5/lib-dynload',
'/usr/local/lib/python3.5/dist-packages',
'/usr/local/lib/python3.5/dist-packages/pdoc3-0.6.1-py3.5.egg',
'/usr/local/lib/python3.5/dist-packages/Markdown-3.1-py3.5.egg',
'/usr/local/lib/python3.5/dist-packages/setuptools-41.0.1-py3.5.egg',
'/usr/local/lib/python3.5/dist-packages/youtube_dl-2019.5.11-py3.5.egg',
'/usr/lib/python3/dist-packages']

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

A man either lives life as it happens to him, meets it head-on and
licks it, or he turns his back on it and starts to wither away.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate
unknown

how to report bugs? (reportbug broken)

[Nico Schlömer]

Hi everyone,

Phew, I find it quite difficult to report bugs in Debian. The
recommended way [1] is to use the command line tool reportbug instead
of a logging into a bug tracker and clicking "New Issue" like
everywhere else. (I'm sure there has been plenty discussion about that
before.)

Anyhow. One disadvantage of using a cmd tool is that tools can break,
and it's been broken for a while on my machine now. (Unfortunately,
this has prevented me from submitting multiple bugs already.)

When launching
```
reportbug -B debian
```
(running Ubuntu 19.04) and after two, three clicks I'm getting
```
E: You must put some 'source' URIs in your sources.list
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
1049, in sync_pre_operation
http_proxy=http_proxy, archived=archived, source=source)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line
1069, in get_reports
bugs = debianbts.get_bugs(pkg_filter, package)
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line
401, in get_bugs
reply = soap_client.call('get_bugs', method_el)
  File 
"/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
line 256, in call
self.xml_response = self.send(method, self.xml_request)
  File 
"/home/nschloe/.local/lib/python3.7/site-packages/pysimplesoap/client.py",
line 318, in send
location, http_method, body=xml, headers=headers)
  File "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
line 1763, in request
disable_ssl_certificate_validation=self.disable_ssl_certificate_validation,
  File "/home/nschloe/.local/lib/python3.7/site-packages/httplib2/__init__.py",
line 1247, in __init__
context=context,
TypeError: fixer() missing 1 required positional argument: 'check_hostname'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2293, in 
main()
  File "/usr/bin/reportbug", line 1115, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1736, in user_interface
latest_first=self.options.latest_first)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
1763, in func
args, kwargs = op.sync_pre_operation(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
1051, in sync_pre_operation
error_dialog("Unable to connect to %s BTS." % sysinfo['name'])
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
137, in error_dialog
_assert_context(ui_context)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk_ui.py", line
92, in _assert_context
(_describe_context(really), _describe_context(expected)))
AssertionError: Function should be called in  but was called in 
```
Perhaps I've got an incompatible version of a dependency installed in
`~/.local/`? Not sure, but looks like a classical Python dependency
thing.

How can I submit a new bug instead? (Mailing to
sub...@bugs.debian.org didn't work for me, nothing happened.) Help
appreciated.

Cheers,
Nico

[1] https://www.debian.org/Bugs/Reporting

Re: How do I report a bug to Debian? ... as ReportBug has bugs.

[John Hasler]

Howard writes:
> The URL for the Debian Bug project apparently isn't working or has
> changed.  I've found two links that are not working.  The first one is
> here in ReportBug, where the blue link for "Homepage of reportbug
> project" is broken.  (The yellow tool tip shows the bad URL being
> tried).

You must mean reportbug-ng.  Reportbug is working fine but it isn't
graphical.  Reportbug-ng also seems to work here, but I don't know what
you mean by the "blue link".

Your attempt to insert the stuff from Synaptic failed.


-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: How do I report a bug to Debian? ... as ReportBug has bugs.

[john doe]

On 12/6/2018 8:22 AM, Howard Johnson wrote:
> Aloha,
> 
> The URL for the Debian Bug project apparently isn't working or has
> changed.  I've found two links that are not working.  The first one is
> here in ReportBug, where the blue link for "Homepage of reportbug
> project" is broken.  (The yellow tool tip shows the bad URL being tried).
> 
> Here is the version info for reportbug as reported in synaptic package
> manager:
> 
> 
> Also in synaptic, the link to "Visit Homepage" is also not working here:
> 
> 
> I searched for a replacement link and found this page
> *https://wiki.debian.org/reportbug*, but unfortunately it says,
> 
>    "*Note*: this page is not maintained by reportbug maintainers, so
>    the information in here might be outdated or no longer correct."
> 
> :-(
> 
> Searched again and found this page:
> *https://packages.debian.org/stable/utils/reportbug*
> 
> *
> *
> 
> *SO, *I previously tonight spent an hour and submitted a bug, only to
> have it vanish in this bugreport tool.  I clicked the save.  It gave me
> a new dialog box, for what I still don't know. I put my home path into
> it.  And clicked ok or whatever, and it was gone.
> 
> Some days are like this...
> 
> Hope you can help. Thanks.
> 

If the reportbug utility is not working, you can always send the bug
report per e-mail (1).

"How to report a bug in Debian using email (and advanced usage of
reportbug)"

HTH.


1)  https://www.debian.org/Bugs/Reporting

-- 
John Doe

How do I report a bug to Debian? ... as ReportBug has bugs.

[Howard Johnson]

Aloha,

The URL for the Debian Bug project apparently isn't working or has 
changed.  I've found two links that are not working.  The first one is 
here in ReportBug, where the blue link for "Homepage of reportbug 
project" is broken.  (The yellow tool tip shows the bad URL being tried).


Here is the version info for reportbug as reported in synaptic package 
manager:



Also in synaptic, the link to "Visit Homepage" is also not working here:


I searched for a replacement link and found this page 
*https://wiki.debian.org/reportbug*, but unfortunately it says,


   "*Note*: this page is not maintained by reportbug maintainers, so
   the information in here might be outdated or no longer correct."

:-(

Searched again and found this page: 
*https://packages.debian.org/stable/utils/reportbug*


*
*

*SO, *I previously tonight spent an hour and submitted a bug, only to 
have it vanish in this bugreport tool.  I clicked the save.  It gave me 
a new dialog box, for what I still don't know. I put my home path into 
it.  And clicked ok or whatever, and it was gone.


Some days are like this...

Hope you can help. Thanks.

Re: need help: some words is not easy to understand in /Bugs/server-request

[Curt]

On 2018-08-14, Byung-Hee HWANG (황병희, 黃炳熙)  wrote:
> writes:
>
>> On Tue, Aug 14, 2018 at 03:34:06PM +0900, Byung-Hee HWANG (황병희, 黃炳熙) wrote:
>>> Hellow, i'm translating to Korean /Bugs section -- WWW. Though i try 3
>>> times for reading again again, i don't understand what means. See below:
>>
>> I can't find the text you are referring to. An URL would be nice.
>>
>> Anyway, I'll try to do my best without context:
>>
>>> #+BEGIN_SRC: text from /Bugs/server-request
>>> The Subject of the message is ignored, except for generating the Subject
>>> of the reply.
>>> #+END_SRC
>>
>> I interpret this as "the only place where the Subject of the message is
>> used is in the Subject of the reply".
>>
>> Perhaps this is about the Debian Bug Tracking System (BTS); some of the
>> bug report's mail headers have a special meaning to the BTS (the To:
>> address, for example, contains the bug ID). That would mean that the
>> Subject itself is not used, except to generate the reply's Subject
>> (which would be important to help the person sending the bug report
>> to correlate the reply (s)he receives).
>>
>> Don't hesitate to ask back if things seem less clear now :-)
>
> So the reply's Subject is important, is this key point?
> The URL was https://www.debian.org/Bugs/server-request.en.html
>
> I need more example. Tomas, please...
>
> Thanks for advance...
>

My take on it is the following. 

You send an email to requ...@bugs.debian.org because you want to know
all about bug # 22:

 Subject: Everything on bug # 22
 
(body of message containing one command and one control terminator)

 send-detail 22 (command)

 thank you (control terminator)

The automated program derives the subject line of its reply from 
the sender's subject line (common practice in the email world):

Reply:

 Subject: Re: Everything on bug # 22

 Blah blah blah blah on bug # 22

-- 
"She was a blank wall, fresh painted." 
Louise Erdrich, Love Medicine

SOLVED (Was: Re: need help: some words is not easy to understand in /Bugs/server-request)

[Byung-Hee HWANG (황병희, 黃炳熙)]

Brian  writes:

> On Tue 14 Aug 2018 at 15:34:06 +0900, Byung-Hee HWANG (황병희, 黃炳熙) wrote:
>
>> Hellow, i'm translating to Korean /Bugs section -- WWW. Though i try 3
>> times for reading again again, i don't understand what means. See below:
>> 
>> #+BEGIN_SRC: text from /Bugs/server-request
>> The Subject of the message is ignored, except for generating the Subject
>> of the reply.
>> #+END_SRC
>> 
>> Help me, please...
>
> It needs to be understood in the context of the whole of the first
> section.
>
> The body of the mail contains the commands to requ...@bugs.debian.org.
> This is the important aspect; the process will not work without its
> being done.
>
> The subject of the mail has no importance and requ...@bugs.debian.org
> will completely ignore it. So you can put anything in the subject line,
> such as "Send for bugnumber" (or even leave it blank). The reply will
> have "Re: Send for bugnumber". That might be useful to the sender.

Thanks for explanation for background reason, indeed...

> IMO, the sentence could simply be rewritten to "The Subject of the
> message is ignored." without loss of essential meaning.

So i now solved problem, thanks Brian^^^

Sincerely, Byung-Hee.

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

Re: need help: some words is not easy to understand in /Bugs/server-request

[Thomas Schmitt]

Hi,

i now understand that the page is not about _submitting_ bugs but rather
for operating the bug tracker.
In that light, Brian's statement would indeed explain the meaning.

Brian wrote:
> The subject of the mail has no importance and requ...@bugs.debian.org
> will completely ignore it. So you can put anything in the subject line,
> such as "Send for bugnumber" (or even leave it blank).
> 
> IMO, the sentence could simply be rewritten to "The Subject of the
> message is ignored." without loss of essential meaning.

If this theory is correct, i'd prepend a half sentence to the original
statement:

  "Other than with submitting a bug report,
   the Subject of the message is ignored, except for generating the
   Subject of the reply."

I lookied up some control action in closed bugs.
The message
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632865;msg=25
indeed has a subject which does not show up on the bug page:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632865


Have a nice day :)

Thomas

Re: need help: some words is not easy to understand in /Bugs/server-request

[Brian]

On Tue 14 Aug 2018 at 15:34:06 +0900, Byung-Hee HWANG (황병희, 黃炳熙) wrote:

> Hellow, i'm translating to Korean /Bugs section -- WWW. Though i try 3
> times for reading again again, i don't understand what means. See below:
> 
> #+BEGIN_SRC: text from /Bugs/server-request
> The Subject of the message is ignored, except for generating the Subject
> of the reply.
> #+END_SRC
> 
> Help me, please...

It needs to be understood in the context of the whole of the first
section.

The body of the mail contains the commands to requ...@bugs.debian.org.
This is the important aspect; the process will not work without its
being done.

The subject of the mail has no importance and requ...@bugs.debian.org
will completely ignore it. So you can put anything in the subject line,
such as "Send for bugnumber" (or even leave it blank). The reply will
have "Re: Send for bugnumber". That might be useful to the sender.

IMO, the sentence could simply be rewritten to "The Subject of the
message is ignored." without loss of essential meaning.

-- 
Brian.

Re: need help: some words is not easy to understand in /Bugs/server-request

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Aug 14, 2018 at 04:49:00PM +0900, Byung-Hee HWANG wrote:

[...]

> So the reply's Subject is important, is this key point?
> The URL was https://www.debian.org/Bugs/server-request.en.html

Hey, thanks for the link!

> I need more example. Tomas, please...

It might take me a while to read & understand, but I'll come back
to it later, promised :-)

In the meantime hoping for insightful answers (I see one by Thomas).
Cheers, later
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAltylQIACgkQBcgs9XrR2kb10ACdFLLX68nbzaXKsLBIh0McqTaA
9N0AoIJNv53220nzfzjRtzUukDwOKtoj
=i4C7
-END PGP SIGNATURE-