GNU bug report logs -
#43073
Trim/hide full email headers on debbugs
Previous Next
To reply to this bug, email your comments to 43073 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 27 Aug 2020 18:04:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ruben Rodriguez <ruben <at> fsf.org>
:
New bug report received and forwarded. Copy sent to
help-debbugs <at> gnu.org
.
(Thu, 27 Aug 2020 18:04:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Package: debbugs.gnu.org
RT ticket 1599321 requests not showing full email headers on debbugs, a
privacy violation. I'm sending this on behalf of the reporter, please DTRT.
[0x46A70073E4E50D4E.asc (application/pgp-keys, attachment)]
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 27 Aug 2020 18:52:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Ruben Rodriguez wrote:
> RT ticket 1599321 requests not showing full email headers on debbugs, a
> privacy violation. I'm sending this on behalf of the reporter, please DTRT.
On IRC this URL was passed as being in the original report:
rwp: the requestor referenced this link: https://debbugs.gnu.org/db/39/39688.html
That is an alternative view to:
https://bugs.debian.org/63995
I also note that there is nothing new under the sun. This is really a
duplicate of the upstream BTS Debian Bug#63995.
https://bugs.debian.org/63995
Bob
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sun, 30 Aug 2020 00:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Hello Norbert,
Ruben said someone opened a sysadmin RT ticket and then Ruben opened a
BTS ticket on that person's behalf. That was all that we knew. But
now that I see this message from you I am forwarding this message so
that it will be in the correct ticket.
Bob
----- Forwarded message from Norbert de Jonge -----
Date: Mon, 24 Aug 2020 12:44:42 +0200
From: Norbert de Jonge
To: owner <at> debbugs.gnu.org
Cc: gnu <at> gnu.org
Subject: complaint
Hello,
I very much object to full email headers being shown here
https://debbugs.gnu.org/db/39/39688.html
It's an unnecessary invasion of my privacy.
Best regards,
Norbert
----- End forwarded message -----
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Tue, 08 Sep 2020 04:59:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx wrote:
> I also note that there is nothing new under the sun. This is really a
> duplicate of the upstream BTS Debian Bug#63995.
>
> https://bugs.debian.org/63995
I would say it is kind of new, since I don't recall seeing the specific
complaint "I object to full email headers being shown" before.
IMO debbugs.gnu.org is a bit better than bugs.debian.org in this area,
since the former does at least basic email obscuration, and in fact
tries to totally remove email addresses from the static pages such as
https://debbugs.gnu.org/db/39/39688.html (which are the ones indexed by
search engines). I think a better link for that ara would be
https://debbugs.gnu.org/14811
I don't see much value in having the full headers in the static db
pages, so it seems fine to me if someone wants to remove them. (Obviously
they will remain in the downloadable mbox files.) But debbugs.gnu.org
development is moribund.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 06:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 43073 <at> debbugs.gnu.org (full text, mbox):
I see we have yet another complaint about IP addresses. Two if I
count the other mailing list complaint too. Personally I have no
understanding of what people are thinking with regards to IP
addresses. I think I will blame Hollywood movies on it. Hollywood
makes people think it means something that it does not mean.
In any case yet again the complaint was about the db links. It's
really only the db tree view that people are complaining about.
https://debbugs.gnu.org/db/XY/XYABC.html
I use the BTS a lot but really I had never looked at the db views
before these complaints. Is there a use for the db views?
What do people think of disabling the display of the entire db view
tree? I propose to do this unless someone tells me not to.
Just keep it simple and take the brute force and ignorance approach
and add in another apache server rewrite rule redirect so that the
entire tree is redirected to the document root. In one action that
would make all of those views unavailable and perhaps would stop the
complaints. WDYT?
Bob
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 06:58:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 08:34:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx <bob <at> proulx.com> writes:
Hi Bob,
> I see we have yet another complaint about IP addresses. Two if I
> count the other mailing list complaint too. Personally I have no
> understanding of what people are thinking with regards to IP
> addresses. I think I will blame Hollywood movies on it. Hollywood
> makes people think it means something that it does not mean.
>
> In any case yet again the complaint was about the db links. It's
> really only the db tree view that people are complaining about.
>
> https://debbugs.gnu.org/db/XY/XYABC.html
>
> I use the BTS a lot but really I had never looked at the db views
> before these complaints. Is there a use for the db views?
>
> What do people think of disabling the display of the entire db view
> tree? I propose to do this unless someone tells me not to.
>
> Just keep it simple and take the brute force and ignorance approach
> and add in another apache server rewrite rule redirect so that the
> entire tree is redirected to the document root. In one action that
> would make all of those views unavailable and perhaps would stop the
> complaints. WDYT?
Looks reasonable to me.
I add Lars as Cc. I know he's collecting stats about debbugs.org, and I
don't know whether he needs the db links for retrieval of data.
> Bob
Best regards, Michael.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 08:34:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 08:54:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> I add Lars as Cc. I know he's collecting stats about debbugs.org, and I
> don't know whether he needs the db links for retrieval of data.
I just use the debbugs-gnu interfaces when doing stats. Basically:
(apply 'debbugs-get-status (debbugs-get-bugs :archive "both"))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 08:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 17:07:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Hi Bob,
Bob Proulx wrote:
> https://debbugs.gnu.org/db/XY/XYABC.html
>
> I use the BTS a lot but really I had never looked at the db views
> before these complaints. Is there a use for the db views?
>
> What do people think of disabling the display of the entire db view
> tree? I propose to do this unless someone tells me not to.
Note that the "db view tree" is the part that gets indexed by search
engines. Search engines are (obviously) denied from the cgi bug pages,
for reasons of system load. So if you get rid of the db pages, it will
be impossible to search debbugs reports using standard web search
engines. There are ways around this, such as searches of the associated
bug mailing lists, and native search on debbugs.gnu.org, but it would
seem like a loss to me, for very little real gain.
Note that the IP address is also in the mbox mailing list archives:
https://lists.gnu.org/archive/mbox/bug-diffutils/2020-02
and now also in the help-debbugs mailing list archives (Streisand effect
ahoy).
The right solution is probably to make the db pages not include full
header information, but of course that is more work. I think it is
/usr/lib/debbugs/db2html that would need patching (already patched to
hide email addresses).
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 21:06:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen wrote:
> I just use the debbugs-gnu interfaces when doing stats. Basically:
>
> (apply 'debbugs-get-status (debbugs-get-bugs :archive "both"))
Do we know what this does? I mean does it use the db tree view? Or
something different? (I hesitate to ask about the SOAP interface.)
Bob
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 21:06:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 21:23:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx wrote:
> Lars Ingebrigtsen wrote:
> > I just use the debbugs-gnu interfaces when doing stats. Basically:
> >
> > (apply 'debbugs-get-status (debbugs-get-bugs :archive "both"))
>
> Do we know what this does? I mean does it use the db tree view? Or
> something different? (I hesitate to ask about the SOAP interface.)
In further developments my questions do not matter. So please ignore
them. Glenn is teaching me that we need the db tree view regardless.
More in that follow-up message...
Bob
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 21:23:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 21:25:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Note that the "db view tree" is the part that gets indexed by search
> engines.
Hmm... That does explain why when people are complaining that they
are complaining about the db tree view and not the "main" view. (Main
in IMNHO since the regular report display is the one I use.)
> Search engines are (obviously) denied from the cgi bug pages,
> for reasons of system load. So if you get rid of the db pages, it will
> be impossible to search debbugs reports using standard web search
> engines.
Well... That does create problems for my suggestion then.
> There are ways around this, such as searches of the associated
> bug mailing lists, and native search on debbugs.gnu.org, but it would
> seem like a loss to me, for very little real gain.
Agreed. Now that I learn this.
> Note that the IP address is also in the mbox mailing list archives:
> https://lists.gnu.org/archive/mbox/bug-diffutils/2020-02
Yes. But I have yet to see anyone actually complain about those.
(It's possible I have missed seeing a complaint. But I don't recall
having seen one on the mbox archives.)
> and now also in the help-debbugs mailing list archives (Streisand effect
> ahoy).
Right! The Streisand effect. The very act of trying to suppress
something calls attention to it.
http://en.wikipedia.org/wiki/Streisand_effect
Even better John Oliver did a (tremendously humorous but very
irreverent, NSFW due to language) report on this topic too.
https://www.youtube.com/watch?v=r-ERajkMXw0#t=4m04s
Usually it is better to let sleeping dogs lie. Otherwise attempts to
suppress information will only serve to call attention to it.
My best advice to people is to do nothing.
> The right solution is probably to make the db pages not include full
> header information, but of course that is more work. I think it is
> /usr/lib/debbugs/db2html that would need patching (already patched to
> hide email addresses).
Okay then! I'll look at it. Won't be today. I'll put it on the task
queue. Good that I see it is in Perl as that is a good language for
me. I don't see where address hidden is done there but I am sure it
will become clear when digging into it.
Bob
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 21:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Thu, 03 Dec 2020 22:50:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx wrote:
> Okay then! I'll look at it. Won't be today. I'll put it on the task
> queue. Good that I see it is in Perl as that is a good language for
> me. I don't see where address hidden is done there but I am sure it
> will become clear when digging into it.
Thanks!
Debbugs is all perl. :)
My kludge for hiding emails in /usr/lib/debbugs/db2html was the
hide_address_total function. I don't know if a similar strategy will
work for removing the full mail headers.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Thu, 03 Dec 2020 22:50:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Fri, 04 Dec 2020 08:35:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx <bob <at> proulx.com> writes:
> Okay then! I'll look at it. Won't be today. I'll put it on the task
> queue. Good that I see it is in Perl as that is a good language for
> me. I don't see where address hidden is done there but I am sure it
> will become clear when digging into it.
When you have applied the changes, pls tell us. We try to follow them in
a git repository.
> Bob
Best regards, Michael.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Fri, 04 Dec 2020 08:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sat, 05 Dec 2020 02:50:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Note that the "db view tree" is the part that gets indexed by search
> engines. Search engines are (obviously) denied from the cgi bug pages,
> for reasons of system load. So if you get rid of the db pages, it will
> be impossible to search debbugs reports using standard web search
> engines.
I know I asked this in the mailing list but I am going to repeat it
here so it is in the ticket and then add some more.
Where is the seed that the search engines start with to crawl the db
tree? I couldn't find it.
Meanwhile... I find this difference between the systems.
https://debbugs.gnu.org/robots.txt
User-agent: *
Disallow: /cgi-bin/
Disallow: /cgi/
As you say debbugs blocks the robots that comply.
https://bugs.debian.org/robots.txt
User-Agent: Googlebot
User-Agent: bingbot
User-Agent: yandexbot
User-Agent: baiduspider
User-Agent: ia_archiver
Allow: /cgi-bin/bugreport.cgi?bug=
Allow: /cgi-bin/pkgreport.cgi?pkg=*;dist=unstable$
Disallow: /*/
User-agent: *
Disallow: /
But the upstream allows the robots to crawl the cgi main bug ticket
display pages. Maybe they have better resources. Was this allowed on
debbugs previously and then blocked due to load problems?
I am wondering if we should allow it again as a test and then see what
the current state of things results. Because then the main pages
would be indexed and this would also avoid the problem. WDYT?
Bob
Me who keeps making crazy brainstorm suggestions and hoping that maybe
eventually one of them might work out beneficially. :-)
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sun, 06 Dec 2020 23:15:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Bob Proulx wrote:
> Where is the seed that the search engines start with to crawl the db
> tree? I couldn't find it.
The db pages are linked from the main page https://debbugs.gnu.org/
Is that what you are asking? ("static indices")
> But the upstream allows the robots to crawl the cgi main bug ticket
> display pages. Maybe they have better resources. Was this allowed on
> debbugs previously and then blocked due to load problems?
That is my recollection, but it has been a long time.
> I am wondering if we should allow it again as a test and then see what
> the current state of things results. Because then the main pages
> would be indexed and this would also avoid the problem. WDYT?
My initial thought is that it is not a good idea, but feel free to try
it out.
Another idea is that if /usr/lib/debbugs/db2html is impenetrable, just
stick a "formail -I Received:" somewhere near the end of it?
Not the most efficient method, but if it works, may be good enough.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Mon, 07 Dec 2020 00:13:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Bob Proulx wrote:
> > Where is the seed that the search engines start with to crawl the db
> > tree? I couldn't find it.
>
> The db pages are linked from the main page https://debbugs.gnu.org/
> Is that what you are asking? ("static indices")
Oh! Yes! That is the missing link for me. I had never clicked on
that link before.
And I will comment upon the rest when I have more time to do so.
Thanks!
Bob
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Fri, 11 Dec 2020 13:00:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Hi!
Glenn Morris <rgm <at> gnu.org> skribis:
> My kludge for hiding emails in /usr/lib/debbugs/db2html was the
> hide_address_total function. I don't know if a similar strategy will
> work for removing the full mail headers.
On a related note, Guix runs another web interface to Debbugs called
mumi at <https://issues.guix.gnu.org>. It’s all-Guile-no-Perl ;-) and
it hides email addresses. That might also be an option worth
considering longer-term?
Thanks,
Ludo’.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Fri, 11 Dec 2020 13:00:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Fri, 11 Dec 2020 14:58:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi!
Hi Ludovic,
> On a related note, Guix runs another web interface to Debbugs called
> mumi at <https://issues.guix.gnu.org>. It’s all-Guile-no-Perl ;-) and
> it hides email addresses. That might also be an option worth
> considering longer-term?
But only guix bugs seem to be indexed by search engines. A short test
with Google search gave a hit for "22138 site:guix.gnu.org" (a guix
bug), but nothing for "22140 site:guix.gnu.org".
> Thanks,
> Ludo’.
Best regards, Michael.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Fri, 11 Dec 2020 14:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Fri, 11 Dec 2020 18:12:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> skribis:
> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> Hi!
>
> Hi Ludovic,
>
>> On a related note, Guix runs another web interface to Debbugs called
>> mumi at <https://issues.guix.gnu.org>. It’s all-Guile-no-Perl ;-) and
>> it hides email addresses. That might also be an option worth
>> considering longer-term?
>
> But only guix bugs seem to be indexed by search engines. A short test
> with Google search gave a hit for "22138 site:guix.gnu.org" (a guix
> bug), but nothing for "22140 site:guix.gnu.org".
Yes, but if there’s interest, one could imagine setting up a GNU-wide
instance. (There’s a Guix System service for mumi, which simplifies
deployment.)
Ludo’.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Fri, 11 Dec 2020 18:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sat, 12 Dec 2020 16:21:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Michael,
Hi Ludovic,
> Yes, but if there’s interest, one could imagine setting up a GNU-wide
> instance. (There’s a Guix System service for mumi, which simplifies
> deployment.)
Might be an idea, yes. But what we need more urgent are people working
on the debbugs server part. Most of us, except Bob, are kind of retired.
> Ludo’.
Best regards, Michael.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Sat, 12 Dec 2020 16:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sun, 13 Dec 2020 14:21:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
Michael Albinus <michael.albinus <at> gmx.de> skribis:
> Might be an idea, yes. But what we need more urgent are people working
> on the debbugs server part. Most of us, except Bob, are kind of retired.
Understood. There are quite many volunteers in the projects that rely
on bugs.gnu.org, some of which might be willing to help. How would you
go about recruiting them?
I think the first step is to start from a “clean state”, making sure
bugs.gnu.org runs software that’s under version control; without that,
it may be hard to get people to even take a look.
Someone imported that GNU Debbugs modifications to a VCS repo some time
ago. Is that repo still up-to-date? Is bugs.gnu.org running a checkout
of that repo?
Thanks,
Ludo’.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Sun, 13 Dec 2020 14:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Sun, 13 Dec 2020 15:24:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi Michael,
Hi Ludovic,
>> Might be an idea, yes. But what we need more urgent are people working
>> on the debbugs server part. Most of us, except Bob, are kind of retired.
>
> Understood. There are quite many volunteers in the projects that rely
> on bugs.gnu.org, some of which might be willing to help. How would you
> go about recruiting them?
Asking on the help-debbugs <at> gnu.org ML?
> I think the first step is to start from a “clean state”, making sure
> bugs.gnu.org runs software that’s under version control; without that,
> it may be hard to get people to even take a look.
That's the plan, indeed. Bob has already set up another machine from
scratch, debbugs2p.gnu.org. It is waiting for being activated, but
nobody has done it yet. (Bob, pls correct me if I tell a wrong status).
> Someone imported that GNU Debbugs modifications to a VCS repo some time
> ago. Is that repo still up-to-date? Is bugs.gnu.org running a checkout
> of that repo?
That was Noam. Unfortunately, he is silent, and doesn't react. I have
asked him some weeks ago about the status of this repo.
I guess it wouldn't take to long to check this repo, and to bring it
up-to-date. I have a local clone of it, which shall have followed the
latest changes as much as I am aware of.
> Thanks,
> Ludo’.
Best regards, Michael.
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Sun, 13 Dec 2020 15:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
help-debbugs <at> gnu.org
:
bug#43073
; Package
debbugs.gnu.org
.
(Tue, 22 Dec 2020 01:54:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 43073 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus wrote:
> Ludovic Courtès <ludo <at> gnu.org> writes:
> >> Might be an idea, yes. But what we need more urgent are people working
> >> on the debbugs server part. Most of us, except Bob, are kind of retired.
I am still in the "starting to engage" phase with debbugs BTS. Even
though it has been some time. Because I use it quite a bit too and
want to keep it happy and healthy. But I am not knowledgeable with it
enough yet.
> > Understood. There are quite many volunteers in the projects that rely
> > on bugs.gnu.org, some of which might be willing to help. How would you
> > go about recruiting them?
>
> Asking on the help-debbugs <at> gnu.org ML?
With the previous call for help Michael, Noam, and myself jumped in.
> > I think the first step is to start from a “clean state”, making sure
> > bugs.gnu.org runs software that’s under version control; without that,
> > it may be hard to get people to even take a look.
>
> That's the plan, indeed. Bob has already set up another machine from
> scratch, debbugs2p.gnu.org. It is waiting for being activated, but
> nobody has done it yet. (Bob, pls correct me if I tell a wrong status).
Well... That's giving me too much credit by a lot. If you remember
when this latter group assembled we as a group decided we wanted to
work through things on a clean state system. And therefore asked the
FSF sysadmin to set up a new VM for us to work through everything
upon.
We have a new system (debbugs2p) that was set up that is useful for
that purpose. Of course some time has passed and now that system
itself needs an OS upgrade. But that can be easily done. I'll take
that task. Initially Michael and Noam had a good burst of energy
working on things. Unfortunately that seems to have tapered off. We
need to energize up again. My emphasis has been on the hosting OS
part of the system and I am still learning the BTS side of the system.
> > Someone imported that GNU Debbugs modifications to a VCS repo some time
> > ago. Is that repo still up-to-date? Is bugs.gnu.org running a checkout
> > of that repo?
>
> That was Noam. Unfortunately, he is silent, and doesn't react. I have
> asked him some weeks ago about the status of this repo.
As I understand it there were at least four major branches of work for
"the BTS" as we know them. Perhaps more. And that was the main
problem. Converging all of the different directions of work together
into a main trunk.
Upstream there is the Debian BTS as it is running which has drifted
from the code in the upstream BTS git repository. IIRC. So there are
two branches that are close but different. And then the debbugs
install also has the same with what is in its git repository versus
what is actually running. So that is two more.
As so as I recall the problem for convergence was to decide on what
would be converged from all of those. And we also had debbugs running
production code doing useful work that we were cautious not to break.
> I guess it wouldn't take to long to check this repo, and to bring it
> up-to-date. I have a local clone of it, which shall have followed the
> latest changes as much as I am aware of.
I haven't myself touched the BTS repository at all. My focus has been
on things such as OS upgrades and security patches, disk space,
firewalls, web server configuration, and that side of things.
Bob
Message sent on
to
Ruben Rodriguez <ruben <at> fsf.org>
:
bug#43073.
(Tue, 22 Dec 2020 01:54:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 97 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.