* Fwd: [X-POST] patchwork.sourceware.org refresh
[not found] <78c774ef-9f9c-3339-aeb8-84636ee94360@gotplt.org>
@ 2019-11-28 5:04 ` Siddhesh Poyarekar
[not found] ` <alpine.LFD.2.21.1911280509420.3472978@eddie.linux-mips.org>
2019-12-08 12:06 ` Siddhesh Poyarekar
2 siblings, 0 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-11-28 5:04 UTC (permalink / raw)
To: help-guix
Bounced from info-guix, so sending to help-guix as instructed.
Siddhesh
-------- Forwarded Message --------
Subject: [X-POST] patchwork.sourceware.org refresh
Date: Thu, 28 Nov 2019 10:30:39 +0530
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: GLIBC Devel <libc-alpha@sourceware.org>, gdb-patches@sourceware.org,
info-guix@gnu.org
Hi,
During discussions over patch tracking systems on the glibc libc-alpha
mailing list[1] we thought it would be a worthwhile experiment to try
the latest patchwork to see if it fits our needs. A quick look through
the current instance on patchwork.sourceware.org indicates that none of
the current projects (glibc, gdb, guix) are actively using the instance,
so I will be nuking it and reinstalling it afresh.
I intend to do this during the day of 1 Dec 2019, India time, so if
there are any objections or if you would like to take backups, please do
so before that.
Thanks,
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
[not found] ` <alpine.LFD.2.21.1911280509420.3472978@eddie.linux-mips.org>
@ 2019-11-28 5:47 ` Siddhesh Poyarekar
2019-11-28 15:47 ` Carlos O'Donell
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-11-28 5:47 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: GLIBC Devel, gdb-patches, help-guix
On 28/11/19 10:55 am, Maciej W. Rozycki wrote:
> Well, I've been using it to track the state my own patches submitted (and
> during the period of my active MIPS GDB port maintenance also for other
> people's submissions).
Can you please take a snapshot of your state?
> Is it actually necessary to destroy all the recorded state (not only for
> patches, but also for e-mail accounts linked, which AFAIK cannot be
> restored once you've lost access to any) just for an engine upgrade?
> That would be an odd requirement and ISTR at least one of the patchworks
> I've had an account with to have been seamlessly upgraded at one point.
Hmm, I will try to do an in-place upgrade without actually deleting
anything. I can't promise that it will go well because we'll be
upgrading from a very ancient version and I don't know right now if the
schema has changed incompatibly.
I'll do a backup too FWIW.
> Or do you have something else, i.e. not just an upgrade, in mind?
To begin with, I intend to add hooks to close patchwork patches on merge
so that that aspect is automated. It was the one problem we had with
patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
likely to get close to that goal.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-11-28 5:47 ` Siddhesh Poyarekar
@ 2019-11-28 15:47 ` Carlos O'Donell
2019-11-30 11:35 ` Maciej W. Rozycki
2019-12-03 19:07 ` Tom Tromey
2 siblings, 0 replies; 19+ messages in thread
From: Carlos O'Donell @ 2019-11-28 15:47 UTC (permalink / raw)
To: Siddhesh Poyarekar, Maciej W. Rozycki; +Cc: GLIBC Devel, gdb-patches, help-guix
On 11/28/19 12:47 AM, Siddhesh Poyarekar wrote:
> On 28/11/19 10:55 am, Maciej W. Rozycki wrote:
>> Well, I've been using it to track the state my own patches submitted (and
>> during the period of my active MIPS GDB port maintenance also for other
>> people's submissions).
>
> Can you please take a snapshot of your state?
>
>> Is it actually necessary to destroy all the recorded state (not only for
>> patches, but also for e-mail accounts linked, which AFAIK cannot be
>> restored once you've lost access to any) just for an engine upgrade?
>> That would be an odd requirement and ISTR at least one of the patchworks
>> I've had an account with to have been seamlessly upgraded at one point.
>
> Hmm, I will try to do an in-place upgrade without actually deleting
> anything. I can't promise that it will go well because we'll be
> upgrading from a very ancient version and I don't know right now if the
> schema has changed incompatibly.
>
> I'll do a backup too FWIW.
When I looked at this the upgrade was *very* complicated, and carrying over
the data from a version that is so old was going to be hard.
>> Or do you have something else, i.e. not just an upgrade, in mind?
>
> To begin with, I intend to add hooks to close patchwork patches on merge
> so that that aspect is automated. It was the one problem we had with
> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
> likely to get close to that goal.
Agreed!
For me as a reviewer, knowing what's up-to-date and ready for review,
having a tool (like pwclient) to pull the patch and build a local branch
from it, and then being able to use local diff tooling is really the key
things to accelerate patch review for patches that don't require complex
consensus.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-11-28 5:47 ` Siddhesh Poyarekar
2019-11-28 15:47 ` Carlos O'Donell
@ 2019-11-30 11:35 ` Maciej W. Rozycki
2019-12-01 4:35 ` Siddhesh Poyarekar
2019-12-01 16:26 ` Siddhesh Poyarekar
2019-12-03 19:07 ` Tom Tromey
2 siblings, 2 replies; 19+ messages in thread
From: Maciej W. Rozycki @ 2019-11-30 11:35 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: GLIBC Devel, gdb-patches, help-guix
On Thu, 28 Nov 2019, Siddhesh Poyarekar wrote:
> > Well, I've been using it to track the state my own patches submitted (and
> > during the period of my active MIPS GDB port maintenance also for other
> > people's submissions).
>
> Can you please take a snapshot of your state?
How do I do that though? There doesn't appear to be anything there I
could do from my profile page or elsewhere.
> > Or do you have something else, i.e. not just an upgrade, in mind?
>
> To begin with, I intend to add hooks to close patchwork patches on merge
> so that that aspect is automated. It was the one problem we had with
> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
> likely to get close to that goal.
Sure, and greatly appreciated too (I've seen your proposal in the other
thread of discussion), but adding hooks is not supposed to affect any
existing patchwork state that the lone upgrade puts at risk. Some kind of
restructuring could.
Maciej
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-11-30 11:35 ` Maciej W. Rozycki
@ 2019-12-01 4:35 ` Siddhesh Poyarekar
2019-12-01 16:26 ` Siddhesh Poyarekar
1 sibling, 0 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-01 4:35 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: GLIBC Devel, gdb-patches, help-guix
On 30/11/19 5:05 pm, Maciej W. Rozycki wrote:
> How do I do that though? There doesn't appear to be anything there I
> could do from my profile page or elsewhere.
Oh I was only thinking of something rudimentary like copying over the
list of pending patches into a text file.
> Sure, and greatly appreciated too (I've seen your proposal in the other
> thread of discussion), but adding hooks is not supposed to affect any
> existing patchwork state that the lone upgrade puts at risk. Some kind of
> restructuring could.
Yeah, I hope it works out without having to nuke the repo too. I'll
find out later today.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-11-30 11:35 ` Maciej W. Rozycki
2019-12-01 4:35 ` Siddhesh Poyarekar
@ 2019-12-01 16:26 ` Siddhesh Poyarekar
1 sibling, 0 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-01 16:26 UTC (permalink / raw)
To: GLIBC Devel; +Cc: gdb-patches, help-guix
Hello,
A quick update on status. I attempted an update today and discovered
that I need help from overseers to update a few system packages before I
can do this. As a result, the patchwork update won't happen today.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-11-28 5:47 ` Siddhesh Poyarekar
2019-11-28 15:47 ` Carlos O'Donell
2019-11-30 11:35 ` Maciej W. Rozycki
@ 2019-12-03 19:07 ` Tom Tromey
2019-12-04 1:05 ` Carlos O'Donell
2 siblings, 1 reply; 19+ messages in thread
From: Tom Tromey @ 2019-12-03 19:07 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: Maciej W. Rozycki, GLIBC Devel, gdb-patches, help-guix
>>>>> "Siddhesh" == Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>> Or do you have something else, i.e. not just an upgrade, in mind?
Siddhesh> To begin with, I intend to add hooks to close patchwork patches on merge
Siddhesh> so that that aspect is automated. It was the one problem we had with
Siddhesh> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
Siddhesh> likely to get close to that goal.
For gdb, I'd like this to be much more reliable than it is today. We
were thinking we'd simply add a kind of patch-id to the commit message
-- the way we're currently doing with gerrit -- and then have patchworks
recognize this ID and use it as its internal key.
I think this is not a very large amount of work in patchworks.
Tom
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-03 19:07 ` Tom Tromey
@ 2019-12-04 1:05 ` Carlos O'Donell
0 siblings, 0 replies; 19+ messages in thread
From: Carlos O'Donell @ 2019-12-04 1:05 UTC (permalink / raw)
To: Tom Tromey, Siddhesh Poyarekar
Cc: Maciej W. Rozycki, GLIBC Devel, gdb-patches, help-guix
On 12/3/19 2:07 PM, Tom Tromey wrote:
>>>>>> "Siddhesh" == Siddhesh Poyarekar <siddhesh@gotplt.org> writes:
>
>>> Or do you have something else, i.e. not just an upgrade, in mind?
>
> Siddhesh> To begin with, I intend to add hooks to close patchwork patches on merge
> Siddhesh> so that that aspect is automated. It was the one problem we had with
> Siddhesh> patchwork and with ChangeLogs gone in glibc, we're definitely a lot more
> Siddhesh> likely to get close to that goal.
>
> For gdb, I'd like this to be much more reliable than it is today. We
> were thinking we'd simply add a kind of patch-id to the commit message
> -- the way we're currently doing with gerrit -- and then have patchworks
> recognize this ID and use it as its internal key.
>
> I think this is not a very large amount of work in patchworks.
That would be awesome.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
[not found] <78c774ef-9f9c-3339-aeb8-84636ee94360@gotplt.org>
2019-11-28 5:04 ` Fwd: [X-POST] patchwork.sourceware.org refresh Siddhesh Poyarekar
[not found] ` <alpine.LFD.2.21.1911280509420.3472978@eddie.linux-mips.org>
@ 2019-12-08 12:06 ` Siddhesh Poyarekar
2019-12-08 12:10 ` Florian Weimer
2019-12-09 15:44 ` Sergio Durigan Junior
2 siblings, 2 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-08 12:06 UTC (permalink / raw)
To: GLIBC Devel, gdb-patches, help-guix
Hello,
I've been battling with this on and off for a couple of weeks now and
I've finally given up because I haven't been able to get the
dependencies in order for the latest patchwork+django on the sourceware
server.
I can bring patchwork.siddhesh.in (that thing i set up before moving to
patchwork.sourceware.org) back up to the latest with data from
patchwork.sourceware.org. Would that work for people wanting to try
this out? We can migrate back to patchwork.sourceware.org once it is
ready for the latest patchwork.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-08 12:06 ` Siddhesh Poyarekar
@ 2019-12-08 12:10 ` Florian Weimer
2019-12-08 12:21 ` Christian Brauner
2019-12-09 15:44 ` Sergio Durigan Junior
1 sibling, 1 reply; 19+ messages in thread
From: Florian Weimer @ 2019-12-08 12:10 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: GLIBC Devel, gdb-patches, help-guix
* Siddhesh Poyarekar:
> I've been battling with this on and off for a couple of weeks now and
> I've finally given up because I haven't been able to get the
> dependencies in order for the latest patchwork+django on the sourceware
> server.
>
> I can bring patchwork.siddhesh.in (that thing i set up before moving to
> patchwork.sourceware.org) back up to the latest with data from
> patchwork.sourceware.org. Would that work for people wanting to try
> this out? We can migrate back to patchwork.sourceware.org once it is
> ready for the latest patchwork.
Maybe we can use <https://patchwork.kernel.org/> for temporary
hosting? It already covers some non-kernel lists.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-08 12:10 ` Florian Weimer
@ 2019-12-08 12:21 ` Christian Brauner
2019-12-09 7:56 ` Siddhesh Poyarekar
0 siblings, 1 reply; 19+ messages in thread
From: Christian Brauner @ 2019-12-08 12:21 UTC (permalink / raw)
To: Florian Weimer
Cc: Siddhesh Poyarekar, GLIBC Devel, gdb-patches, help-guix,
konstantin
On Sun, Dec 08, 2019 at 01:10:37PM +0100, Florian Weimer wrote:
> * Siddhesh Poyarekar:
>
> > I've been battling with this on and off for a couple of weeks now and
> > I've finally given up because I haven't been able to get the
> > dependencies in order for the latest patchwork+django on the sourceware
> > server.
> >
> > I can bring patchwork.siddhesh.in (that thing i set up before moving to
> > patchwork.sourceware.org) back up to the latest with data from
> > patchwork.sourceware.org. Would that work for people wanting to try
> > this out? We can migrate back to patchwork.sourceware.org once it is
> > ready for the latest patchwork.
>
> Maybe we can use <https://patchwork.kernel.org/> for temporary
> hosting? It already covers some non-kernel lists.
If this is an option you'd probably need to talk to Konstantin about
this.
Christian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-08 12:21 ` Christian Brauner
@ 2019-12-09 7:56 ` Siddhesh Poyarekar
2019-12-09 16:52 ` Konstantin Ryabitsev
0 siblings, 1 reply; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-09 7:56 UTC (permalink / raw)
To: Christian Brauner, Florian Weimer
Cc: GLIBC Devel, gdb-patches, help-guix, konstantin
On 08/12/19 5:51 pm, Christian Brauner wrote:
>> Maybe we can use <https://patchwork.kernel.org/> for temporary
>> hosting? It already covers some non-kernel lists.
>
> If this is an option you'd probably need to talk to Konstantin about
> this.
Oh of course, less work is always better, I was only trying not to
bother them since we had not finalized use of patchwork. Konstantin if
you're OK with us using the patchwork.kernel.org instance as a pilot,
it'll be great if you could set up an instance for glibc.
I had a couple of questions though before we set this up because these
were points that led to bitrot in our patchwork instance:
1. Do you have hooks in place to auto-close patches in patchwork when
they're committed?
2. Do you know if patchwork reliably closes off older versions of patch
submissions, or if there's a way other projects are managing this.
3. Could you allow one of us (me to start with) to add hooks to do CI
runs? Alternatively, do you have some CI infrastructure in place that
allows projects to do builds against a patchwork submission and report
errors to the mailing list?
These are things I was going to explore with a local patchwork instance
and if it's possible with patchwork.kernel.org, I'm all for it.
Thanks,
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-08 12:06 ` Siddhesh Poyarekar
2019-12-08 12:10 ` Florian Weimer
@ 2019-12-09 15:44 ` Sergio Durigan Junior
2019-12-09 16:56 ` Siddhesh Poyarekar
1 sibling, 1 reply; 19+ messages in thread
From: Sergio Durigan Junior @ 2019-12-09 15:44 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: GLIBC Devel, gdb-patches, help-guix
On Sunday, December 08 2019, Siddhesh Poyarekar wrote:
> Hello,
>
> I've been battling with this on and off for a couple of weeks now and
> I've finally given up because I haven't been able to get the
> dependencies in order for the latest patchwork+django on the sourceware
> server.
>
> I can bring patchwork.siddhesh.in (that thing i set up before moving to
> patchwork.sourceware.org) back up to the latest with data from
> patchwork.sourceware.org. Would that work for people wanting to try
> this out? We can migrate back to patchwork.sourceware.org once it is
> ready for the latest patchwork.
Hey, Siddhesh,
I know you're in touch with Konstantin already, but another option would
be to use the OSCI VM running on gnutoolchain-gerrit.osci.io. I can
talk to the OSCI folks and ask them if it'd be possible to have an alias
hostname or something to make it easier to separate the services, if needed.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-09 7:56 ` Siddhesh Poyarekar
@ 2019-12-09 16:52 ` Konstantin Ryabitsev
2019-12-09 16:59 ` Siddhesh Poyarekar
0 siblings, 1 reply; 19+ messages in thread
From: Konstantin Ryabitsev @ 2019-12-09 16:52 UTC (permalink / raw)
To: Siddhesh Poyarekar
Cc: Christian Brauner, Florian Weimer, GLIBC Devel, gdb-patches,
help-guix
On Mon, Dec 09, 2019 at 01:26:16PM +0530, Siddhesh Poyarekar wrote:
> On 08/12/19 5:51 pm, Christian Brauner wrote:
> >> Maybe we can use <https://patchwork.kernel.org/> for temporary
> >> hosting? It already covers some non-kernel lists.
> >
> > If this is an option you'd probably need to talk to Konstantin about
> > this.
Hi, all:
I'm not sure it makes that much sense to put glibc on
patchwork.kernel.org. I know we have some non-kernel projects there, but
they are pretty tiny and were approved largely because they wouldn't
make much of an impact on kernel.org infra.
The same wouldn't be true for glibc, especially if we're talking bot and
CI integration. It really needs to stay on its own dedicated
infrastructure where it can be properly scoped and resourced.
Sorry that I don't have a better answer.
Best,
-K
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-09 15:44 ` Sergio Durigan Junior
@ 2019-12-09 16:56 ` Siddhesh Poyarekar
2019-12-09 17:15 ` Sergio Durigan Junior
0 siblings, 1 reply; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-09 16:56 UTC (permalink / raw)
To: Sergio Durigan Junior; +Cc: GLIBC Devel, gdb-patches, help-guix
On 09/12/19 9:14 pm, Sergio Durigan Junior wrote:
> Hey, Siddhesh,
>
> I know you're in touch with Konstantin already, but another option would
> be to use the OSCI VM running on gnutoolchain-gerrit.osci.io. I can
> talk to the OSCI folks and ask them if it'd be possible to have an alias
> hostname or something to make it easier to separate the services, if needed.
That works too, since Konstantin just confirmed that they cannot host
this on kernel.org.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-09 16:52 ` Konstantin Ryabitsev
@ 2019-12-09 16:59 ` Siddhesh Poyarekar
0 siblings, 0 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2019-12-09 16:59 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Christian Brauner, Florian Weimer, GLIBC Devel, gdb-patches,
help-guix
On 09/12/19 10:22 pm, Konstantin Ryabitsev wrote:
> I'm not sure it makes that much sense to put glibc on
> patchwork.kernel.org. I know we have some non-kernel projects there, but
> they are pretty tiny and were approved largely because they wouldn't
> make much of an impact on kernel.org infra.
>
> The same wouldn't be true for glibc, especially if we're talking bot and
> CI integration. It really needs to stay on its own dedicated
> infrastructure where it can be properly scoped and resourced.
>
> Sorry that I don't have a better answer.
>
I understand, thanks anyway.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-09 16:56 ` Siddhesh Poyarekar
@ 2019-12-09 17:15 ` Sergio Durigan Junior
2020-01-14 19:05 ` Christian Biesinger
0 siblings, 1 reply; 19+ messages in thread
From: Sergio Durigan Junior @ 2019-12-09 17:15 UTC (permalink / raw)
To: Siddhesh Poyarekar; +Cc: GLIBC Devel, gdb-patches, help-guix
On Monday, December 09 2019, Siddhesh Poyarekar wrote:
> On 09/12/19 9:14 pm, Sergio Durigan Junior wrote:
>> Hey, Siddhesh,
>>
>> I know you're in touch with Konstantin already, but another option would
>> be to use the OSCI VM running on gnutoolchain-gerrit.osci.io. I can
>> talk to the OSCI folks and ask them if it'd be possible to have an alias
>> hostname or something to make it easier to separate the services, if needed.
>
> That works too, since Konstantin just confirmed that they cannot host
> this on kernel.org.
Alright. I'll get in touch with OSCI. Please send me your public SSH
key so I can give you access to the machine.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2019-12-09 17:15 ` Sergio Durigan Junior
@ 2020-01-14 19:05 ` Christian Biesinger
2020-01-15 2:33 ` Siddhesh Poyarekar
0 siblings, 1 reply; 19+ messages in thread
From: Christian Biesinger @ 2020-01-14 19:05 UTC (permalink / raw)
To: Sergio Durigan Junior
Cc: Siddhesh Poyarekar, GLIBC Devel, gdb-patches, help-guix
On Mon, Dec 9, 2019 at 12:16 PM Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
>
> On Monday, December 09 2019, Siddhesh Poyarekar wrote:
>
> > On 09/12/19 9:14 pm, Sergio Durigan Junior wrote:
> >> Hey, Siddhesh,
> >>
> >> I know you're in touch with Konstantin already, but another option would
> >> be to use the OSCI VM running on gnutoolchain-gerrit.osci.io. I can
> >> talk to the OSCI folks and ask them if it'd be possible to have an alias
> >> hostname or something to make it easier to separate the services, if needed.
> >
> > That works too, since Konstantin just confirmed that they cannot host
> > this on kernel.org.
>
> Alright. I'll get in touch with OSCI. Please send me your public SSH
> key so I can give you access to the machine.
Any news on this upgrade? Would be nice to play with patchwork for gdb.
Christian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [X-POST] patchwork.sourceware.org refresh
2020-01-14 19:05 ` Christian Biesinger
@ 2020-01-15 2:33 ` Siddhesh Poyarekar
0 siblings, 0 replies; 19+ messages in thread
From: Siddhesh Poyarekar @ 2020-01-15 2:33 UTC (permalink / raw)
To: Christian Biesinger, Sergio Durigan Junior
Cc: GLIBC Devel, gdb-patches, help-guix
On 15/01/20 12:35 am, Christian Biesinger wrote:
> Any news on this upgrade? Would be nice to play with patchwork for gdb.
>
Sorry I got caught up in other work and had to put this aside. I hope
to resume in a week or so.
Siddhesh
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-01-15 2:33 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <78c774ef-9f9c-3339-aeb8-84636ee94360@gotplt.org>
2019-11-28 5:04 ` Fwd: [X-POST] patchwork.sourceware.org refresh Siddhesh Poyarekar
[not found] ` <alpine.LFD.2.21.1911280509420.3472978@eddie.linux-mips.org>
2019-11-28 5:47 ` Siddhesh Poyarekar
2019-11-28 15:47 ` Carlos O'Donell
2019-11-30 11:35 ` Maciej W. Rozycki
2019-12-01 4:35 ` Siddhesh Poyarekar
2019-12-01 16:26 ` Siddhesh Poyarekar
2019-12-03 19:07 ` Tom Tromey
2019-12-04 1:05 ` Carlos O'Donell
2019-12-08 12:06 ` Siddhesh Poyarekar
2019-12-08 12:10 ` Florian Weimer
2019-12-08 12:21 ` Christian Brauner
2019-12-09 7:56 ` Siddhesh Poyarekar
2019-12-09 16:52 ` Konstantin Ryabitsev
2019-12-09 16:59 ` Siddhesh Poyarekar
2019-12-09 15:44 ` Sergio Durigan Junior
2019-12-09 16:56 ` Siddhesh Poyarekar
2019-12-09 17:15 ` Sergio Durigan Junior
2020-01-14 19:05 ` Christian Biesinger
2020-01-15 2:33 ` Siddhesh Poyarekar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).