Bug#735909:

2023-12-05 Thread Adam Ggod

Bug#735909: testing more architectures with piuparts

2017-04-14 Thread Holger Levsen
reassign 762308 piuparts.debian.org
merge 735909 762308
retitle 735909 piuparts.$ARCH.debian.org
thanks

> On Sun, Mar 19, 2017 at 09:30:05AM +0800, Paul Wise wrote:
> > > However, I realized today, that there is a cheap way out:
> > > - rename piuparts.d.o to amd64.piuparts.d.o
> > > - point piuparts.d.o at somewhere sensible (on amd64.piu….d.o)
> > We would need to make sure that this part doesn't break all the
> > services that use it or link to it. 
> of course.
> that's actually the beauty of this solution: amd64 stays the same. 

to be clear, for a start it's enough to 
- add two new vhosts, piuparts.amd64.d.o and piuparts.i386.d.o
  and point piuparts.d.o to piuparts.adm64.d.o
- run two masters on pejacevic, one for amd64 and one for i386, which
  create two websites and are served by different slaves…

Then, we will want to add some inter-architecture links, though maybe
this will stay rather minimal, as I believe the long term solution should
rather be to store the piuparts results in postgresql and use a dynamic
frontend… but this is really longterm and independent of the above "hack"
to support several archs with minimal code changes now.

> >That appears to be at minimum,
> > release.d.o, UDD, PTS/tracker, DDPO and jenkins.

Yes, indeed.


This is currently awaiting feedback from DSA about the new i386 slave.


-- 
cheers,
Holger


signature.asc
Description: Digital signature


Bug#735909: we should test i386 completly

2016-02-11 Thread Holger Levsen
control: retitle -1 "add support for testing several architectures"
control: severity -1 wishlist

Hi,

we have an i386 VM set up just like the amd64 slave, what we are missing is 
code to test more than one architecture… help with that much welcome. If 
someone is interested on working on this, I'd be more than glad to help 
describing what's needed where.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.


Bug#735909: piuparts.debian.org should test i386 packages not available on amd64

2014-01-18 Thread Holger Levsen
package: piuparts.debian.org

Hi,

currently piuparts.d.o only tests packages of arch amd64 and all, while the 
machines could trivially have i386 chroots, to also tests packages which are 
i386 only.

This needs some more work on piuparts, from the TODO: 

- really support multiple architectures:
  - piuparts-report should have a list of available arch and list packages 
only
available on untested archs in a new state
(depends-)not-available-on-tested-archs
  - master should (per default) only schedule packages which are not available
on the master arch to slaves of different archs -
schedule-evenly-to-slaves = no


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.


Bug#735909: piuparts.debian.org should test i386 packages not available on amd64

2014-01-18 Thread Andreas Beckmann
On 2014-01-18 15:12, Holger Levsen wrote:
 currently piuparts.d.o only tests packages of arch amd64 and all, while the 
 machines could trivially have i386 chroots, to also tests packages which are 
 i386 only.

We could start with having both sid_i386 and sid_amd64 for now. And they
should be tested *full*.

I've seen failures on i386 (mainly upgrade related) that were not
reproducible in amd64 - but for packages available in both arches.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735909: piuparts.debian.org should test i386 packages not available on amd64

2014-01-18 Thread Holger Levsen
Hi Andreas,

On Samstag, 18. Januar 2014, Andreas Beckmann wrote:
 We could start with having both sid_i386 and sid_amd64 for now. And they
 should be tested *full*.

we really want to test testing2sid and wheezy2jessie on those archs, and 
testing them in full will add significant load on the slave... 

Which maybe is ok, I *believe* we can get more cores and more RAM for the 
slave...
 
 I've seen failures on i386 (mainly upgrade related) that were not
 reproducible in amd64 - but for packages available in both arches.

do you have an estimate how many? 2 out of 2 sourcepackage or rather 200?


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.


Bug#735909: [Piuparts-devel] Bug#735909: piuparts.debian.org should test i386 packages not available on amd64

2014-01-18 Thread Andreas Beckmann
On 2014-01-18 15:57, Holger Levsen wrote:
 Hi Andreas,
 
 On Samstag, 18. Januar 2014, Andreas Beckmann wrote:
 We could start with having both sid_i386 and sid_amd64 for now. And they
 should be tested *full*.
 
 we really want to test testing2sid and wheezy2jessie on those archs, and 
 testing them in full will add significant load on the slave... 
 
 Which maybe is ok, I *believe* we can get more cores and more RAM for the 
 slave...

Looking at
https://munin.debian.org/debian.org/piu-slave-bm-a.debian.org/cpu.html
https://munin.debian.org/debian.org/piu-slave-bm-a.debian.org/memory.html
there seems to be enough capacity to increase the number of sections as
well as running 1-2 additional slaves with the current equipment.

 I've seen failures on i386 (mainly upgrade related) that were not
 reproducible in amd64 - but for packages available in both arches.
 
 do you have an estimate how many? 2 out of 2 sourcepackage or rather 200?

about 5 in total, two not fixed in squeeze2wheezy/i386 (iirc python
upgrade race)


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org