On Wed, 2021-03-31 at 09:54 +0200, Thomas Huth wrote:
> On 30/03/2021 15.19, Daniel P. Berrangé wrote:
> > Yep, that looks similar to what we do in libvirt, though we don't override
> > the compiler at the job level. Instead we just ensure the dir containing
> > ccache symlinks appears first in $PA
On 30/03/2021 15.19, Daniel P. Berrangé wrote:
On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
On 30/03/2021 13.19, Daniel P. Berrangé wrote:
[...]
ccache is a no-brainer and assuming it isn't already working with
our gitlab jobs, we must fix that asap.
I've found some nice inst
On Tue, Mar 30, 2021 at 10:11 AM Peter Maydell
wrote:
> On Tue, 30 Mar 2021 at 17:00, Warner Losh wrote:
> > submodules have caused me significant pain in rebasing the bsd-user work.
> > The way QEMU does things, you wind up with unclean trees after a build,
> > which causes grief at times... I
On Tue, 30 Mar 2021 at 17:00, Warner Losh wrote:
> submodules have caused me significant pain in rebasing the bsd-user work.
> The way QEMU does things, you wind up with unclean trees after a build,
> which causes grief at times... I for one, would shed no tears at the number of
> submodules dropp
On 30/03/2021 15.27, Daniel P. Berrangé wrote:
On Tue, Mar 30, 2021 at 03:19:49PM +0200, Paolo Bonzini wrote:
On 30/03/21 15:12, Daniel P. Berrangé wrote:
Now, but that may change already in 6.1 in order to add CFI support.
We can bundle a newer version, but we don't need to require a newer
ve
On Tue, Mar 30, 2021 at 7:33 AM Daniel P. Berrangé
wrote:
> The use of submodules has imposed significant pain on QEMU developers over
> the years, and as such I think our general goal should be to have zero git
> submodules over the long term. Usage of submodules ought to be considered
> a short
On Tue, Mar 30, 2021 at 04:23:35PM +0200, Paolo Bonzini wrote:
> On 30/03/21 16:13, Stefan Hajnoczi wrote:
> > On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
> > > On 30/03/2021 13.19, Daniel P. Berrangé wrote:
> > > > On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
>
On 30/03/21 16:13, Stefan Hajnoczi wrote:
On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
On 30/03/2021 13.19, Daniel P. Berrangé wrote:
On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
Hi,
I wanted to follow up with a summary of the CI jobs:
1. Containers & Conta
On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
> On 30/03/2021 13.19, Daniel P. Berrangé wrote:
> > On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
> > > Hi,
> > > I wanted to follow up with a summary of the CI jobs:
> > >
> > > 1. Containers & Containers Layer2 - ~3
On Tue, Mar 30, 2021 at 12:19:38PM +0100, Daniel P. Berrangé wrote:
> On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
> > Hi,
> > I wanted to follow up with a summary of the CI jobs:
> >
> > 1. Containers & Containers Layer2 - ~3 minutes/job x 39 jobs
> > 2. Builds - ~50 minutes/j
On Tue, Mar 30, 2021 at 03:19:49PM +0200, Paolo Bonzini wrote:
> On 30/03/21 15:12, Daniel P. Berrangé wrote:
> > > Now, but that may change already in 6.1 in order to add CFI support.
> > We can bundle a newer version, but we don't need to require a newer
> > version. Simply conditional compile fo
On 30/03/21 15:12, Daniel P. Berrangé wrote:
Now, but that may change already in 6.1 in order to add CFI support.
We can bundle a newer version, but we don't need to require a newer
version. Simply conditional compile for the bits we need. If distro
slirp is too old, then sorry, you can't enable
On Tue, Mar 30, 2021 at 01:55:48PM +0200, Thomas Huth wrote:
> On 30/03/2021 13.19, Daniel P. Berrangé wrote:
> > Another example, is that we test builds on centos7 with
> > three different combos of crypto backend settings. This was
> > to exercise bugs we've seen in old crypto packages in RHEL-7
On Tue, Mar 30, 2021 at 02:45:43PM +0200, Paolo Bonzini wrote:
> On 30/03/21 14:23, Philippe Mathieu-Daudé wrote:
> > On 3/30/21 2:09 PM, Paolo Bonzini wrote:
> > > On 30/03/21 13:55, Thomas Huth wrote:
> > > >
> > > > Also I wonder whether we could maybe even get rid of the capstone and
> > > > s
On Tue, Mar 30, 2021 at 02:09:38PM +0200, Paolo Bonzini wrote:
> On 30/03/21 13:55, Thomas Huth wrote:
> >
> > Since the build system has been converted to meson, I think the
> > configure script prefers to use the submodules instead of the distro
> > packages. I've tried to remedy this a little b
On 30/03/21 14:23, Philippe Mathieu-Daudé wrote:
On 3/30/21 2:09 PM, Paolo Bonzini wrote:
On 30/03/21 13:55, Thomas Huth wrote:
Also I wonder whether we could maybe even get rid of the capstone and
slirp submodules in QEMU now
At least for slirp, we probably want to stay more on the bleeding
On 3/30/21 1:55 PM, Thomas Huth wrote:
> On 30/03/2021 13.19, Daniel P. Berrangé wrote:
>> On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
>>> Traditionally ccache (https://ccache.dev/) was used to detect
>>> recompilation of the same compiler input files. This is trickier to do
>
On 3/30/21 2:09 PM, Paolo Bonzini wrote:
> On 30/03/21 13:55, Thomas Huth wrote:
>>
>> Also I wonder whether we could maybe even get rid of the capstone and
>> slirp submodules in QEMU now
>
> At least for slirp, we probably want to stay more on the bleeding edge
> which implies having to keep the
On Tue, 30 Mar 2021 at 12:56, Thomas Huth wrote:
> Right, I think we should also work more towards consolidating the QEMU
> binaries, to avoid that we have to always build sooo many target binaries
> again and again. E.g.:
>
> - Do we still need to support 32-bit hosts? If not we could
>finall
On 30/03/21 13:55, Thomas Huth wrote:
Since the build system has been converted to meson, I think the
configure script prefers to use the submodules instead of the distro
packages. I've tried to remedy this a little bit here:
https://gitlab.com/qemu-project/qemu/-/commit/db0108d5d846e9a8
..
On 30/03/21 13:55, Thomas Huth wrote:
Since the build system has been converted to meson, I think the
configure script prefers to use the submodules instead of the distro
packages. I've tried to remedy this a little bit here:
https://gitlab.com/qemu-project/qemu/-/commit/db0108d5d846e9a8
..
On 30/03/2021 13.19, Daniel P. Berrangé wrote:
On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
Hi,
I wanted to follow up with a summary of the CI jobs:
1. Containers & Containers Layer2 - ~3 minutes/job x 39 jobs
2. Builds - ~50 minutes/job x 61 jobs
3. Tests - ~12 minutes/job
On Mon, Mar 29, 2021 at 03:10:36PM +0100, Stefan Hajnoczi wrote:
> Hi,
> I wanted to follow up with a summary of the CI jobs:
>
> 1. Containers & Containers Layer2 - ~3 minutes/job x 39 jobs
> 2. Builds - ~50 minutes/job x 61 jobs
> 3. Tests - ~12 minutes/job x 20 jobs
> 4. Deploy - 52 minutes x 1
On Fri, Mar 19, 2021 at 12:27:10PM -0300, Wainer dos Santos Moschetta wrote:
> Hi,
>
> On 3/19/21 8:34 AM, Philippe Mathieu-Daudé wrote:
> > On 3/19/21 11:59 AM, Paolo Bonzini wrote:
> > > On 19/03/21 11:18, Andrew Jones wrote:
> > > > > Yikes, that is 41 hours per CI run. I wonder if GitLab's CI
Hi,
On 3/19/21 8:34 AM, Philippe Mathieu-Daudé wrote:
On 3/19/21 11:59 AM, Paolo Bonzini wrote:
On 19/03/21 11:18, Andrew Jones wrote:
Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
on slow machines or if we'll hit the same issue with dedicated runners.
It seems like C
On 19/03/2021 13.07, Markus Armbruster wrote:
Andrew Jones writes:
On Fri, Mar 19, 2021 at 09:33:43AM +, Stefan Hajnoczi wrote:
On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota
Andrew Jones writes:
> On Fri, Mar 19, 2021 at 09:33:43AM +, Stefan Hajnoczi wrote:
>> On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
>> > On 18/03/21 20:46, Stefan Hajnoczi wrote:
>> > > The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
>> > > GitLab Merge
On 3/19/21 10:41 AM, Paolo Bonzini wrote:
> On 19/03/21 10:33, Stefan Hajnoczi wrote:
>> On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
>>> On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests
On 3/19/21 11:59 AM, Paolo Bonzini wrote:
> On 19/03/21 11:18, Andrew Jones wrote:
>>> Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
>>> on slow machines or if we'll hit the same issue with dedicated runners.
>>> It seems like CI optimization will be necessary...
>>>
>> We
On 19/03/21 11:18, Andrew Jones wrote:
Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
on slow machines or if we'll hit the same issue with dedicated runners.
It seems like CI optimization will be necessary...
We need to reduce the amount of CI we do, not only because we
On Fri, Mar 19, 2021 at 09:33:43AM +, Stefan Hajnoczi wrote:
> On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
> > On 18/03/21 20:46, Stefan Hajnoczi wrote:
> > > The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
> > > GitLab Merge Requests so that anyone can s
On 19/03/21 10:33, Stefan Hajnoczi wrote:
On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests so that anyone can submit a merge request and get
CI cove
On Thu, Mar 18, 2021 at 09:30:41PM +0100, Paolo Bonzini wrote:
> On 18/03/21 20:46, Stefan Hajnoczi wrote:
> > The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
> > GitLab Merge Requests so that anyone can submit a merge request and get
> > CI coverage.
>
> Each merge request co
On 18/03/2021 11.28, Philippe Mathieu-Daudé wrote:
On 3/18/21 10:50 AM, Philippe Mathieu-Daudé wrote:
On 3/18/21 10:33 AM, Daniel P. Berrangé wrote:
[...]
It feels like what you hit here is fallout from your account accidentally
getting blocked, rather than something which is hitting every con
On 3/18/21 8:52 PM, John Snow wrote:
> On 3/18/21 3:46 PM, Stefan Hajnoczi wrote:
>> On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
>>> Now I'm having serious doubts about Gitlab usefulness for the QEMU
>>> community...
>>
>> The QEMU Project has 50,000 minutes of GitLab CI
On 18/03/21 20:46, Stefan Hajnoczi wrote:
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests so that anyone can submit a merge request and get
CI coverage.
Each merge request consumes about 2500. That won't last long.
Paolo
On 3/18/21 3:46 PM, Stefan Hajnoczi wrote:
On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
Now I'm having serious doubts about Gitlab usefulness for the QEMU
community...
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests so that
On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
> Now I'm having serious doubts about Gitlab usefulness for the QEMU
> community...
The QEMU Project has 50,000 minutes of GitLab CI quota. Let's enable
GitLab Merge Requests so that anyone can submit a merge request and get
C
On 3/18/21 10:50 AM, Philippe Mathieu-Daudé wrote:
> On 3/18/21 10:33 AM, Daniel P. Berrangé wrote:
>> On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
>>> Hi,
>>>
>>> For some (unclear) reason I got my free tier Gitlab account renewed and
>>> lost the privilege for users ope
On 3/18/21 10:33 AM, Daniel P. Berrangé wrote:
> On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> For some (unclear) reason I got my free tier Gitlab account renewed and
>> lost the privilege for users opening account before the quota limit.
>>
>> I pushed a sing
On Wed, Mar 17, 2021 at 09:29:32PM +0100, Philippe Mathieu-Daudé wrote:
> Hi,
>
> For some (unclear) reason I got my free tier Gitlab account renewed and
> lost the privilege for users opening account before the quota limit.
>
> I pushed a single branch to my namespace repo to trigger a pipeline.
On 3/18/21 2:28 AM, Bin Meng wrote:
> On Thu, Mar 18, 2021 at 4:32 AM Philippe Mathieu-Daudé
> wrote:
>>
>> Hi,
>>
>> For some (unclear) reason I got my free tier Gitlab account renewed and
>> lost the privilege for users opening account before the quota limit.
>>
>> I pushed a single branch to m
On Thu, Mar 18, 2021 at 4:32 AM Philippe Mathieu-Daudé wrote:
>
> Hi,
>
> For some (unclear) reason I got my free tier Gitlab account renewed and
> lost the privilege for users opening account before the quota limit.
>
> I pushed a single branch to my namespace repo to trigger a pipeline.
> 1h lat
Hi,
For some (unclear) reason I got my free tier Gitlab account renewed and
lost the privilege for users opening account before the quota limit.
I pushed a single branch to my namespace repo to trigger a pipeline.
1h later I was surprised to see the pipeline was stuck, having completed
99 jobs of
44 matches
Mail list logo
