Re: Starting First Python Transition

2011-04-26 Thread Floris Bruynooghe
On 22 April 2011 19:55, Stefano Rivera stefa...@debian.org wrote:
 Hi Barry (2011.04.22_03:28:12_+0200)
 When I click on 'last log' for say ia64, I just see a build log with
 no failures in it.  So why does it show up on the main page with
 straight red-X's?

 The transition tracker is just tracking the state of the transition.
 Green ticks means the current binary for this architecture of this
 package matched the Good regex at the top, Red cross means it matched
 the Bad regex.

 So a package that hasn't been rebuilt at all (and so matches Bad on
 every architecture) will show up as all Red Xs. One that's been rebuilt
 but had a couple of failures will show Red Xs for the failures because
 new binaries haven't replaced the old bad binaries on those
 architectures yet.

So is there anything a maintainer of a package currently showing as
bad (python-omniorb in my case if you care) needs to do to get a
rebuild?  Or will they just be scheduled as part of the transition
sometime and don't I need to worry until I see a failed build log
(which hopefully I won't!)?

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/BANLkTikoPdhq3qQf=YzjdEPeFS3=w_p...@mail.gmail.com



Re: Starting First Python Transition

2011-04-26 Thread Scott Kitterman
Floris Bruynooghe f...@devork.be wrote:

On 22 April 2011 19:55, Stefano Rivera stefa...@debian.org wrote:
 Hi Barry (2011.04.22_03:28:12_+0200)
 When I click on 'last log' for say ia64, I just see a build log with
 no failures in it.  So why does it show up on the main page with
 straight red-X's?

 The transition tracker is just tracking the state of the transition.
 Green ticks means the current binary for this architecture of this
 package matched the Good regex at the top, Red cross means it
matched
 the Bad regex.

 So a package that hasn't been rebuilt at all (and so matches Bad on
 every architecture) will show up as all Red Xs. One that's been
rebuilt
 but had a couple of failures will show Red Xs for the failures
because
 new binaries haven't replaced the old bad binaries on those
 architectures yet.

So is there anything a maintainer of a package currently showing as
bad (python-omniorb in my case if you care) needs to do to get a
rebuild?  Or will they just be scheduled as part of the transition
sometime and don't I need to worry until I see a failed build log
(which hopefully I won't!)?

For arch any packages no. For arch all they will need a new upload.

Scott K



-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/6e05812b-0274-4bcb-8f1c-f39d64510...@email.android.com



Re: Starting First Python Transition

2011-04-22 Thread Barry Warsaw
On Apr 15, 2011, at 10:17 AM, Scott Kitterman wrote:

I just uploaded python-defaults to Unstable that drops Python 2.5 and adds
Python 2.7 as supports Python versions.  Python-central, distribute, and
python-stdlib-extensions are already updated to support Python 2.7.  The
planned python-support upload later today will complete having the core
Python infrastructure updated.

Once this is all installed in the archive, we'll start doing selective
binNMUs to drop 2.5 and add 2.7 where they won't affect other transitions.
There are also affected arch:all packages that will need uploads to update.
The transition tracker for this transition is at:

http://release.debian.org/transitions/html/python2.7.html

I'm sure I'm being an idiot, but I can't seem to navigate this URL very well.
I have a bunch of Python 2.7 fixes that I've made for Ubuntu 11.04 and I'm
trying to cross check my list with the failures reported on this page, with
the intent to submit my fixes for consideration in Debian.

The problem is that I can't figure out how to see the failure logs for the
individual packages.  The only one I've been able to grok is graphviz:

https://buildd.debian.org/status/package.php?p=graphviz

I got here after clicking on the link that says 'buildd' on the graphviz
line.  I see status Failed, and a bunch of open bugs for the failures.  If I
click on 'last log' for say i386, I can see the build log with the failure.
So for graphviz, I was able to successfully navigate to a bug, and reply with
links to the Ubuntu bug and debdiff I wrote to fix the failure for us.  So far
so good.

But if I try to do the same with subversion (another package where I've
applied a Python 2.7 fix in Ubuntu), I hit a dead end.  On the main
transitions page, I click on `buildd` for the subversion line and end up here:

https://buildd.debian.org/status/package.php?p=subversion

I don't see any `Failed` lines under Status, nor do I see any open bugs.  When
I click on 'last log' for say ia64, I just see a build log with no failures in
it.  So why does it show up on the main page with straight red-X's?

I'd love to help more, but I don't know how :(

-Barry


signature.asc
Description: PGP signature


Re: Starting First Python Transition

2011-04-22 Thread Stefano Rivera
Hi Barry (2011.04.22_03:28:12_+0200)
 When I click on 'last log' for say ia64, I just see a build log with
 no failures in it.  So why does it show up on the main page with
 straight red-X's?

The transition tracker is just tracking the state of the transition.
Green ticks means the current binary for this architecture of this
package matched the Good regex at the top, Red cross means it matched
the Bad regex.

So a package that hasn't been rebuilt at all (and so matches Bad on
every architecture) will show up as all Red Xs. One that's been rebuilt
but had a couple of failures will show Red Xs for the failures because
new binaries haven't replaced the old bad binaries on those
architectures yet.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 465 6908 C: +27 72 419 8559  UCT: x3127


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110422185542.gb19...@bach.rivera.co.za



Re: Starting First Python Transition

2011-04-22 Thread Barry Warsaw
On Apr 22, 2011, at 08:55 PM, Stefano Rivera wrote:

Hi Barry (2011.04.22_03:28:12_+0200)
 When I click on 'last log' for say ia64, I just see a build log with
 no failures in it.  So why does it show up on the main page with
 straight red-X's?

The transition tracker is just tracking the state of the transition.
Green ticks means the current binary for this architecture of this
package matched the Good regex at the top, Red cross means it matched
the Bad regex.

So a package that hasn't been rebuilt at all (and so matches Bad on
every architecture) will show up as all Red Xs. One that's been rebuilt
but had a couple of failures will show Red Xs for the failures because
new binaries haven't replaced the old bad binaries on those
architectures yet.

Hi Stefano.  Thanks, that makes sense. :)

Is there an easy way to track FTBFS for packages that have been rebuilt?
Something perhaps like the opposite of hide fully (re-)built packages
perhaps?

Cheers,
-Barry


signature.asc
Description: PGP signature


Re: Starting First Python Transition

2011-04-22 Thread Scott Kitterman
On Thursday, April 21, 2011 09:28:12 PM Barry Warsaw wrote:
 On Apr 15, 2011, at 10:17 AM, Scott Kitterman wrote:
 I just uploaded python-defaults to Unstable that drops Python 2.5 and adds
 Python 2.7 as supports Python versions.  Python-central, distribute, and
 python-stdlib-extensions are already updated to support Python 2.7.  The
 planned python-support upload later today will complete having the core
 Python infrastructure updated.
 
 Once this is all installed in the archive, we'll start doing selective
 binNMUs to drop 2.5 and add 2.7 where they won't affect other transitions.
 There are also affected arch:all packages that will need uploads to
 update. The transition tracker for this transition is at:
 
 http://release.debian.org/transitions/html/python2.7.html
 
 I'm sure I'm being an idiot, but I can't seem to navigate this URL very
 well. I have a bunch of Python 2.7 fixes that I've made for Ubuntu 11.04
 and I'm trying to cross check my list with the failures reported on this
 page, with the intent to submit my fixes for consideration in Debian.
 
 The problem is that I can't figure out how to see the failure logs for the
 individual packages.  The only one I've been able to grok is graphviz:
 
 https://buildd.debian.org/status/package.php?p=graphviz
 
 I got here after clicking on the link that says 'buildd' on the graphviz
 line.  I see status Failed, and a bunch of open bugs for the failures.  If
 I click on 'last log' for say i386, I can see the build log with the
 failure. So for graphviz, I was able to successfully navigate to a bug,
 and reply with links to the Ubuntu bug and debdiff I wrote to fix the
 failure for us.  So far so good.
 
 But if I try to do the same with subversion (another package where I've
 applied a Python 2.7 fix in Ubuntu), I hit a dead end.  On the main
 transitions page, I click on `buildd` for the subversion line and end up
 here:
 
 https://buildd.debian.org/status/package.php?p=subversion
 
 I don't see any `Failed` lines under Status, nor do I see any open bugs. 
 When I click on 'last log' for say ia64, I just see a build log with no
 failures in it.  So why does it show up on the main page with straight
 red-X's?
 
 I'd love to help more, but I don't know how :(

For this transition we are not scheduling all the needed binNMUs at once, so 
you hit a case where it hasn't been rebuilt yet.  You can try a local rebuild 
and verify the problem exists in Debian and your proposed fix takes care of it. 
 
If so, you can file a FTBFS bug against the package and then set that bug to 
block the transition bug (622279).

Scott K


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104221516.49465.deb...@kitterman.com