https access to git repository is not working
$ git clone https://gcc.gnu.org/git/gcc.git Cloning into 'gcc'... fatal: repository 'https://gcc.gnu.org/git/gcc.git/' not found Uros.
Re: https access to git repository is not working
On Wed, Mar 11, 2020 at 08:41:11AM +0100, Uros Bizjak via Gcc wrote: > $ git clone https://gcc.gnu.org/git/gcc.git > Cloning into 'gcc'... > fatal: repository 'https://gcc.gnu.org/git/gcc.git/' not found I believe #overseers are aware of this and other still unresolved issues (email to bugzilla integration not working, svn/viewcvs not working, ...). Jakub
GCC bugzilla: REST API
Hi. I'm working on a script that will catch the missing email into Bugzilla that are triggered by git commits mentioning a PR. For that I would need the enablement of REST API that was enabled in previous bugzilla instance. Thank you, Martin
Henri Schmelcher wins the Rallye de Hannut, Grégoire Munster out to confirm matter in the Spa Rally
http://www.bma-autosport.com #English #Francais #Nederlands http://www.bma-autosport.com/ ** HENRI SCHMELCHER WINS THE RALLYE DE HANNUT. GRÉGOIRE MUNSTER OUT TO CONFIRM MATTER IN THE SPA RALLY. Last Sunday Henri Schmelcher (VW Polo GTI R5) claimed victory on the Rallye de Hannut, a strongly filled field in the ASAF Championship. This is Schmelcher’s first victory in Hannut, and his first ever victory with an R5. This coming Saturday he will be at the start of the Spa Rally, where also Charles Munster (Opel Adam R2), Pieter-Jan Michiel Cracco (Skoda Fabia R5), Kevin Hommes (Skoda Fabia R5) and Grégoire Munster (Hyundai i20 R5) will be present. Both Munster brothers are out to confirm the excellent performances they put in during the Rally of Haspengouw Both for Cracco and Hommes this will be their first competition in the championship. Following on from the Rally of Haspengouw Henri Schmelcher was well prepared to tackle the Rallye de Hannut, an event he has competed in for at least thirty years. This event boasted a strong field and poor weather conditions. “The weather also complicated the choice of tyres and in the beginning I got it completely wrong”, Henri Schmelcher admitted. “But we still managed to produce three top times. Following the downpour just after midday I really felt at ease in the BMA VW Polo. With three stages still to go I decided to consolidate my 1 minute down on the leader and my 30 sec advantage on my nearest rival. With still one stage to go the arrear was down to 18 sec. Just then it started to pour with rain which resulted in a fair amount of aquaplaning. Conditions were really difficult. Nonetheless it didn’t hold me back from giving it my all. I produced the fastest time and to my complete surprise I had converted my arrears into grabbing the advantage. After thirty years I now have finally clinched victory in this event. That’s awesome! My thanks go out to my co-driver Kathleen Ombelet, and to BMA who produced a fabulous car for me. On Saturday I will be at the start of the Spa Rally. This year my ambition is to finish within the top 10 in the Belgian Rally Championship. Roll on the Spa Rally.” Pieter-Jan Michiel Cracco is once again fit and well and will be competing in his first Jobfixers Belgian Rally Championship. “As the result of a bacterial infection combined with the ‘flu my body was attacked from different angles. Following 5 days in hospital, with the necessary rest and medication I’m now ready to tackle the Spa Rally. In the past I have always performed well there. The approach might well be different this time around. The major difference is that my father is no longer with us. More than ever I want to drive and enjoy myself, something different from working and having fun. With 16 R5 machines at the start I’m aiming at a mid-range result. A place in the top 8 would suit me down to the ground.” After their entry in their home event, namely the East Belgian Rally last year, the Hommes brothers have once again opted for an R5. “According to Bernard the Skoda Fabia would have been a somewhat easier car”, Kevin Hommes commented. “No tests were carried out beforehand. In fact I will be covering my first metres with the car during the shakedown on Friday. Luckily, I’m someone who can quickly adapt to new conditions so I’m not too concerned. We carried out a recce during the weekend. Similar to the East Belgian event, Spa also has a fast course, with the big difference being that here the roads are worse. Recent weather conditions have ensured that the course will remain pretty greasy. My ambition is to match my 11th place of the East Belgian or to improve on it. Taking into account the competition it will not be easy.” Grégoire Munster comes out in the Rallye de Hannut in fourth place. “The overall ambition is to confirm matters. Spa is a rally that suits me down to the ground. I’ really looking forward to be at the start with my Hyundai. The appearance of Mikkelsen has added some spice. For me this in the ideal opportunity to go head to head with an experienced driver.” Charles Munster just missed out by a 0.6 sec hair’s breadth from claiming victory among the Junior in the Rally van Haspengouw “This will be my first participation in the Spa Rally. The recces last weekend soon showed me that this will be an entirely different competition from that of two weeks ago. The typical parcelled type of roads make way for a both fast and technical course interspersed with a fair amount of treacherous sections. Last week’s rain also means that the special stages are now pretty greasy. Not much improvement if one takes into account the weather forecasts. It doesn’t worry me. I quite enjoy rain, or least if it’s competing in a rally. The ambition remains the same as that of the Haspengouw: I’m out to win the classification in the Juniors. Eve
Re: Compiling GCC using an older sysroot
On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote: > The tricky bit is that although both the host and target are always > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on > much older systems than the one I build it on. > > I have a sysroot I've created (downloading RPMs from older systems and > unpacking them) which is sufficient to build GCC (and binutils etc.) I > need the GCC binaries I create to be compiled using this sysroot so > that they can run on older systems. I suggest using containers for this. Once you've got a working Dockerfile it makes life much easier in my experience. The podman and buildah utilities are great alternatives to docker itself. By building in a container using something like "FROM centos:6" you know you're using those packages, not trying to convince GCC to use a cobbled-together sysroot based on old RPMs.
Re: Compiling GCC using an older sysroot
On Wed, 2020-03-11 at 14:17 +, Jonathan Wakely wrote:
> On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > The tricky bit is that although both the host and target are always
> > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> > much older systems than the one I build it on.
>
> I suggest using containers for this. Once you've got a working
> Dockerfile it makes life much easier in my experience.
>
> The podman and buildah utilities are great alternatives to docker itself.
>
> By building in a container using something like "FROM centos:6" you
> know you're using those packages, not trying to convince GCC to use a
> cobbled-together sysroot based on old RPMs.
That's a good idea, certainly for building the compiler: it would save me
having to build the initial compiler ("step 1" in Joseph's email): I can
skip that step and just build the target compiler in a container.
Unfortunately currently I target RHEL/CentOS 6.5 and there's no official
docker image for that, but that's not a major problem.
However I don't think, at least for now, I can switch to having developers
build in a docker container. Getting that integrated with all the
tooling/IDE environments everyone uses, etc. will be a lot of change.
Since I want to use a much newer version of GCC than was provided in these
older releases, a docker image won't save me having to build the compiler
anyway; it would only change the way the compiler is distributed and used
(inside a docker image/container vs. stand-alone with a sysroot).
Luckily for me our product only relies on a handful of system libraries and
I have a simple script that will extract them from RPMs via cpio. It's
actually quite easy and robust to create the sysroot and the entire thing
is only 16M.
Re: Compiling GCC using an older sysroot
On Wed, 11 Mar 2020 at 16:46, Paul Smith wrote:
>
> On Wed, 2020-03-11 at 14:17 +, Jonathan Wakely wrote:
> > On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > > The tricky bit is that although both the host and target are always
> > > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> > > much older systems than the one I build it on.
> >
> > I suggest using containers for this. Once you've got a working
> > Dockerfile it makes life much easier in my experience.
> >
> > The podman and buildah utilities are great alternatives to docker itself.
> >
> > By building in a container using something like "FROM centos:6" you
> > know you're using those packages, not trying to convince GCC to use a
> > cobbled-together sysroot based on old RPMs.
>
> That's a good idea, certainly for building the compiler: it would save me
> having to build the initial compiler ("step 1" in Joseph's email): I can
> skip that step and just build the target compiler in a container.
>
> Unfortunately currently I target RHEL/CentOS 6.5 and there's no official
> docker image for that, but that's not a major problem.
>
> However I don't think, at least for now, I can switch to having developers
> build in a docker container. Getting that integrated with all the
> tooling/IDE environments everyone uses, etc. will be a lot of change.
> Since I want to use a much newer version of GCC than was provided in these
> older releases, a docker image won't save me having to build the compiler
> anyway; it would only change the way the compiler is distributed and used
> (inside a docker image/container vs. stand-alone with a sysroot).
My thinking was to build GCC inside the container, then package up the
results and install that on your dev machines (outside a container).
But actually that won't work because you'd also need to package the
glibc from the container, and at that point you're basically back to
using a sysroot.
Re: GCC bugzilla: REST API
Hi - > I'm working on a script that will catch the missing email into > Bugzilla that are triggered by git commits mentioning a PR. > For that I would need the enablement of REST API that was enabled > in previous bugzilla instance. Just for clarity, which REST API was this? Have a test URL we can useto smoke-test? - FChE
Re: GCC bugzilla: REST API
On Wed, 11 Mar 2020, Frank Ch. Eigler via Gcc wrote: > Hi - > > > I'm working on a script that will catch the missing email into > > Bugzilla that are triggered by git commits mentioning a PR. > > For that I would need the enablement of REST API that was enabled > > in previous bugzilla instance. > > Just for clarity, which REST API was this? Have a test URL we can > useto smoke-test? Here's anm example for sourceware bugzilla, where it's also broken, but used to work. https://sourceware.org/bugzilla/rest.cgi/bug?product=glibc&resolution=FIXED&target_milestone=2.32&include_fields=id,component,summary (as used in the list-fixed-bugs.py script to generate a list of bugs that goes in the glibc NEWS file at release time). /www/gcc/bugzilla/Bugzilla/Install/Requirements.pm has a list of perl modules required by various Bugzilla features. It appears new-sourceware is missing at least JSON::RPC and Test::Taint required for the REST API. Likely the other features people report are missing are the result of other such missing modules. Some of those were in what's now the lib.rhel6-obsolete directory in both GCC and sourceware Bugzilla (going through the modules there to see what features they might cause to be missing may be a good idea), but you may want to install relevant modules from appropriate OS packages if available. -- Joseph S. Myers jos...@codesourcery.com
Re: GCC bugzilla: REST API
Hi - > I'm working on a script that will catch the missing email into > Bugzilla that are triggered by git commits mentioning a PR. > For that I would need the enablement of REST API that was enabled > in previous bugzilla instance. I believe this should work now. Thanks to Joseph Myers for pointing out that we were missing some more perl modules. Fought with koji & etc. awhile and now bugzilla's checksetup.pl is happy all around. - FChE
