Re: [Oneiric-Foundations-Topic]Python Goals

2011-04-26 Thread Scott Kitterman
On Tuesday, April 26, 2011 05:49:22 PM Matthias Klose wrote:
> On 04/26/2011 08:50 PM, Barry Warsaw wrote:
> > Apologies for the long delayed response.
> > 
> > On Apr 01, 2011, at 01:11 PM, Scott Kitterman wrote:
> >> On Friday, April 01, 2011 12:58:37 PM Barry Warsaw wrote:
> >>> Agreed.  Can you elaborate on what "experimental support for Python3 as
> >>> the Python that is shipped on the various Ubuntu ISOs" means to you? 
> >>> Does that mean no Python 2.7 on the ISO?  Also, by "experimental" do
> >>> you mean having a process for creating alternative CDs that have only
> >>> Python 3.2 but not on the standard daily CDs?
> >> 
> >> There is a lot of Python code in the Ubuntu insfrastructure.  I'm not
> >> sure exactly what I meant by that, but here's an example:
> >> 
> >> Ubiquity is written in Python.  It's a reasonably complex program that
> >> is non- trivial to maintain and improve.  It's also mission critical
> >> for Ubuntu.  I would be really suprised if it was fully ported with no
> >> regressions in one cycle.  In this case, I think "experimental support"
> >> would be a python3 branch that ~works, but may not be fully tested/have
> >> issues/or not be at feature parity so we wouldn't want to switch to it
> >> in the oneiric cycle.
> >> 
> >> The goal would be to have it be mature enough during oneiric that in the
> >> "P" cycle we could switch to it early and have it land ~smoothly for
> >> the LTS.
> >> 
> >> I know there are others.
> >> 
> >> My impression is that most upstreams for core desktop packages support
> >> Python3.  Mostly what we lack is packaging changes to support it.  My
> >> expectation is that most of the challenge around a Python3 desktop in
> >> "P" will be around more peripheral modules/extensions and custom Ubuntu
> >> code.
> >> 
> >> That shouldn't preclude shipping some Python3 stuff in oneiric if it's
> >> ready and we've got room on the relevant image.
> >> 
> >> Does that help?
> > 
> > It does, thanks.  I wonder, with work going on in Launchpad to support
> > derivatives, can we pervert that to create a Python 3 Ubuntu derivative
> > that could be used for this experiment?  It may not be fully functional,
> > but I think it would be a great test and status tracker for how well our
> > Python 3 efforts are going.
> 
> which packages are affected, and what work is needed to get these packages
> even built?

I've only looked (a bit) at Kubuntu.  PyQt4 and PyKDE have upstream support 
for Python3, but it's not packaged yet.  I suspect it's incomplete as not all 
the python modules PyQt4 depends on for Python have been ported to Python3 
(e.g. python-dbus).  There are quite a number of Python packages higher in the 
stack and I have not checked their status:

  usb-creator-kde
  update-manager-kde
  ubiquity-frontend-kde
  system-config-printer-kde
  software-properties-kde
  plasma-scriptengine-python
  kde-config-touchpad
  jockey-kde
  gdebi-kde
  apturl-kde
  apport-kde

You can imagine the similar list for Ubuntu.  If someone was focused on doing 
this sort of work, I think it might be doable in a cycle (porting to Python3 
isn't particularly hard).  Even though I used Kubuntu as an example here, I 
don't think we're in a position to pursue this in Oneiric.  Since I initially 
suggested this, I found out the one full time developer on Kubuntu is going on 
a rotation off the distro team this cycle, so among the community developers 
we've got to pick up the slack and that leaves little to no room for anything 
vaguely optional.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


UDS/LDS Scheduling updates

2011-04-26 Thread Jorge O. Castro
Hello everyone,

We're 14 days from UDS and LDS, here's the skinny so far:

119 blueprints have been filed, we had 360 BPs filed for UDS-O, so you
should feel "One thirdish" of the way done with your blueprints. The
list of blueprints is available here:
https://blueprints.launchpad.net/sprints/uds-o

We ran the scheduler and started to fill in some sessions, Track/Tech
leads, you should be able to eyeball how along your track is filling
up by looking at this list. Please don't start moving sessions into
slots manually just yet (unless you're doing morning roundtables that
you know won't move). We need to give people some time to subscribe to
the blueprints. I'll announce when the schedule is full enough for you
to shuffle sessions.

Here's what everyone should be doing:

- Attendees: You should be filing blueprints and subscribing to
blueprints you want to go to. If you're important to a blueprint make
sure you mark yourself as essential. If you've submitted your
blueprints and they're not on that list you need to talk to your track
or tech lead and ask them to approve it.
- Tech Leads: Same thing, except you should be annoying people in your
teams to submit blueprints if they have not done so already.
- Track Leads: All that, plus you should be approving/declining bp's
from this list:
https://blueprints.launchpad.net/sprints/uds-o/+settopics

Some of you have noticed that when you click on the cool notepad icon
in the schedule that you can see an etherpad note for the session.
While etherpad support has landed in summit this is currently using
Daviey's server; do NOT use it for critical data as it will be gone.

We've filed a ticket with IS to push forward about having a real
etherpad for UDS itself, I'll post how that goes, many thanks to the
server team and IS for trying to make this happen.

-- 
Jorge Castro
Canonical Ltd.
http://twitter.com/castrojo
Help fix Unity Bitesize Bugs: http://goo.gl/i1WA1

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: [Oneiric-Foundations-Topic]Python Goals

2011-04-26 Thread Matthias Klose

On 04/26/2011 08:50 PM, Barry Warsaw wrote:

Apologies for the long delayed response.

On Apr 01, 2011, at 01:11 PM, Scott Kitterman wrote:


On Friday, April 01, 2011 12:58:37 PM Barry Warsaw wrote:

Agreed.  Can you elaborate on what "experimental support for Python3 as the
Python that is shipped on the various Ubuntu ISOs" means to you?  Does that
mean no Python 2.7 on the ISO?  Also, by "experimental" do you mean having
a process for creating alternative CDs that have only Python 3.2 but not
on the standard daily CDs?



There is a lot of Python code in the Ubuntu insfrastructure.  I'm not sure
exactly what I meant by that, but here's an example:

Ubiquity is written in Python.  It's a reasonably complex program that is non-
trivial to maintain and improve.  It's also mission critical for Ubuntu.  I
would be really suprised if it was fully ported with no regressions in one
cycle.  In this case, I think "experimental support" would be a python3 branch
that ~works, but may not be fully tested/have issues/or not be at feature
parity so we wouldn't want to switch to it in the oneiric cycle.

The goal would be to have it be mature enough during oneiric that in the "P"
cycle we could switch to it early and have it land ~smoothly for the LTS.

I know there are others.

My impression is that most upstreams for core desktop packages support
Python3.  Mostly what we lack is packaging changes to support it.  My
expectation is that most of the challenge around a Python3 desktop in "P" will
be around more peripheral modules/extensions and custom Ubuntu code.

That shouldn't preclude shipping some Python3 stuff in oneiric if it's ready
and we've got room on the relevant image.

Does that help?


It does, thanks.  I wonder, with work going on in Launchpad to support
derivatives, can we pervert that to create a Python 3 Ubuntu derivative that
could be used for this experiment?  It may not be fully functional, but I
think it would be a great test and status tracker for how well our Python 3
efforts are going.


which packages are affected, and what work is needed to get these packages even 
built?


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: [Oneiric-Foundations-Topic]Python Goals

2011-04-26 Thread Barry Warsaw
Apologies for the long delayed response.

On Apr 01, 2011, at 01:11 PM, Scott Kitterman wrote:

>On Friday, April 01, 2011 12:58:37 PM Barry Warsaw wrote:
>> Agreed.  Can you elaborate on what "experimental support for Python3 as the
>> Python that is shipped on the various Ubuntu ISOs" means to you?  Does that
>> mean no Python 2.7 on the ISO?  Also, by "experimental" do you mean having
>> a process for creating alternative CDs that have only Python 3.2 but not
>> on the standard daily CDs?

>There is a lot of Python code in the Ubuntu insfrastructure.  I'm not sure 
>exactly what I meant by that, but here's an example:
>
>Ubiquity is written in Python.  It's a reasonably complex program that is non-
>trivial to maintain and improve.  It's also mission critical for Ubuntu.  I 
>would be really suprised if it was fully ported with no regressions in one 
>cycle.  In this case, I think "experimental support" would be a python3 branch 
>that ~works, but may not be fully tested/have issues/or not be at feature 
>parity so we wouldn't want to switch to it in the oneiric cycle.
>
>The goal would be to have it be mature enough during oneiric that in the "P" 
>cycle we could switch to it early and have it land ~smoothly for the LTS.
>
>I know there are others.  
>
>My impression is that most upstreams for core desktop packages support 
>Python3.  Mostly what we lack is packaging changes to support it.  My 
>expectation is that most of the challenge around a Python3 desktop in "P" will 
>be around more peripheral modules/extensions and custom Ubuntu code.
>
>That shouldn't preclude shipping some Python3 stuff in oneiric if it's ready 
>and we've got room on the relevant image.
>
>Does that help?

It does, thanks.  I wonder, with work going on in Launchpad to support
derivatives, can we pervert that to create a Python 3 Ubuntu derivative that
could be used for this experiment?  It may not be fully functional, but I
think it would be a great test and status tracker for how well our Python 3
efforts are going.

Maybe it's not a good feature-fit, but rather than (or better, in addition to)
tracking individual packages, I think it would be really helpful to have an
integrated system image that you could test drive and report bugs against.  I
don't think we'd need that right away, as the focus will initially be on
getting individual libraries and applications ported, but once we have
reasonable coverage on that, the Python 3 image will help us identify the
holes.

-Barry


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Ubuntu Kernel Team Meeting Minutes - 2011-04-26

2011-04-26 Thread Brad Figg

= Meeting Minutes =
[[http://irclogs.ubuntu.com/2011/04/26/%23ubuntu-meeting.txt|IRC Log of the 
meeting.]]
<>
[[http://voices.canonical.com/kernelteam|Meeting minutes.]]

== Agenda ==
[[https://wiki.ubuntu.com/KernelTeam/Meeting#Tues, 26 Apr, 2011|20110426 
Meeting Agenda]]


=== Release Metrics  ===
Release Meeting Bugs (15 bugs, 6 Blueprints)
 Release Milestoned Bugs (21 across all packages (down 31)) 
 * 1 linux kernel bugs (down 1)
 * 0 linux-ti-omap4 bugs (no change)
 * 0 linux-meta-ti-omap4 bug (no change)
 Release Targeted Bugs (272 across all packages (up 36)) 
 * 38 linux kernel bugs (up 4)
 * 16 linux-ti-omap4 bugs (up 14)
 * 0 linux-meta-ti-omap4 bug (no change)
 Milestoned Features 
 * 6 blueprints (Including HWE Blueprints)
 Maverick Updates Bugs 
 * 5 Linux Bugs (no change)
 Lucid Updates Bugs 
 * 16 Linux Bugs (up 1)
 Bugs with Patches Attached:87 (down 5) 
 * 
[[https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on 
| Bugs with Patches]]
 * [[http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/ 
| Breakdown by status]]

=== Blueprints: Natty Bug Handling  ===
All items completed or postponed

===  Status: General Natty ===
The kernel remains frozen for the Natty release.  We now have 2.6.38.4 pending 
for SRU.  We do have some desirable fixes pending and we likely would like an 
early SRU if possible.

===  Status: Stable Kernel Team ===
We are not currently in a normal SRU kernel cycle due to allocation of testing 
resources to Natty.  There are new kernels for Hardy, Lucid, and Maverick which 
need verification.
<>
<>
The Dapper kernel which is in -proposed will not be released. Instead, the 
stable kernel team will prepare one final Dapper kernel by the end of this week.

===  Security & bugfix kernels - Maverick/Lucid/Karmic/Hardy/Dapper ===
|| Package|| Upd/Sec  || 
Proposed ||  TiP || Verified ||
||||  ||
  ||  ||  ||
|| dapper   linux-source-2.6.15   || 2.6.15-57.94 || 
2.6.15-57.95 ||0 ||0 ||
||||  ||
  ||  ||  ||
|| hardylinux || 2.6.24-29.88 || 
2.6.24-29.89 ||0 ||0 ||
||||  ||
  ||  ||  ||
|| karmic   linux-ec2 || 2.6.31-308.28|| 
2.6.31-308.29||1 ||1 ||
|| ---  linux || 2.6.31-23.74 || 
2.6.31-23.75 ||1 ||1 ||
||||  ||
  ||  ||  ||
|| lucidlinux-ec2 || 2.6.32-314.27|| 
2.6.32-316.30||8 ||6 ||
|| ---  linux-ports-meta  || 2.6.32.31.23 || 
2.6.32.32.24 ||0 ||0 ||
|| ---  linux-meta-lts-backport-maverick  || 2.6.35.25.36 || 
2.6.35.28.37 ||0 ||0 ||
|| ---  linux-lts-backport-maverick   || 2.6.35-25.44~lucid1  || 
2.6.35-28.50~lucid1  ||   13 ||   13 ||
|| ---  linux-backports-modules-2.6.32|| 2.6.32-31.31 || 
2.6.32-32.32 ||0 ||0 ||
|| ---  linux || 2.6.32-31.61 || 
2.6.32-32.62 ||4 ||2 ||
|| ---  linux-meta|| 2.6.32.31.37 || 
2.6.32.32.38 ||1 ||0 ||
|| ---  linux-meta-ec2|| 2.6.32.314.15|| 
2.6.32.316.17||0 ||0 ||
||||  ||
  ||  ||  ||
|| maverick linux-ports-meta  || 2.6.35.28.21 || 
2.6.35.29.22 ||0 ||0 ||
|| ---  linux-backports-modules-2.6.35|| 2.6.35-28.20 || 
2.6.35-29.21 ||0 ||0 ||
|| ---  linux-meta|| 2.6.35.28.36 || 
2.6.35.29.37 ||0 ||0 ||
|| ---  linux-firmware|| 1.38.6   || 1.38.7 
  ||1 ||0 ||
|| ---  linux || 2.6.35-28.50 || 
2.6.35-29.51 ||   11 ||5 ||
||||  ||
  ||  ||  ||

=== Incoming Bugs: Regressions  ===
Incoming Bugs
 934 Natty Bugs (up 17)
 1129 Maverick Bugs (down 136)
 1022 Lucid Bugs (down 53)
Current regression stats (broken down by release):
 regression-update 
  * 41 maverick bugs (down 6)
  * 74 luc

Re: [Oneiric-Foundations-Topic] Boost Defaults

2011-04-26 Thread Scott Kitterman
On Tuesday, April 26, 2011 07:56:17 AM Scott Kitterman wrote:
> On Tuesday, April 26, 2011 05:51:05 AM Matthias Klose wrote:
> > On 04/26/2011 04:47 AM, Scott Kitterman wrote:
> > > On Saturday, April 23, 2011 06:26:27 AM Matthias Klose wrote:
> > >> On 04/14/2011 06:28 PM, Scott Kitterman wrote:
> > >>> This should get done before UDS, during toolchain upload (i.e. before
> > >>> the first autosync), but I think it's worth mentioning.
> > >>> 
> > >>> The current Boost that's default and in Main is 1.42.  Debian's
> > >>> current default is 1.46. My proposal for Oneiric is that we switch
> > >>> our default/Main version to 1.46 at the start of Oneric development
> > >>> and then in Debian updates their default prior to feature freeze,
> > >>> we'll assess where we are and decide if we should stay with 1.46 or
> > >>> advance.
> > >> 
> > >> whatever version you do choose, please make sure it does build with
> > >> GCC 4.6.
> > > 
> > > Please update the gcc-defaults in the toolchain PPA in Natty to be
> > > newer than the one in natty itself and I'll check it out.
> > 
> > See https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033042.html
> > Is there something missing?
> 
> Thanks.  I looked in the wrong PPA.

Boost1.46 builds with gcc4.6:

https://launchpad.net/~kitterman/+archive/ppa/+buildjob/2499742
https://launchpad.net/~kitterman/+archive/ppa/+buildjob/2499743

I built the entire package with Universe, so it will still have to be split 
for the archive, but there don't appear to be gcc4.6 related problems.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: [Oneiric-Foundations-Topic] Boost Defaults

2011-04-26 Thread Scott Kitterman
On Tuesday, April 26, 2011 05:51:05 AM Matthias Klose wrote:
> On 04/26/2011 04:47 AM, Scott Kitterman wrote:
> > On Saturday, April 23, 2011 06:26:27 AM Matthias Klose wrote:
> >> On 04/14/2011 06:28 PM, Scott Kitterman wrote:
> >>> This should get done before UDS, during toolchain upload (i.e. before
> >>> the first autosync), but I think it's worth mentioning.
> >>> 
> >>> The current Boost that's default and in Main is 1.42.  Debian's current
> >>> default is 1.46. My proposal for Oneiric is that we switch our
> >>> default/Main version to 1.46 at the start of Oneric development and
> >>> then in Debian updates their default prior to feature freeze, we'll
> >>> assess where we are and decide if we should stay with 1.46 or advance.
> >> 
> >> whatever version you do choose, please make sure it does build with GCC
> >> 4.6.
> > 
> > Please update the gcc-defaults in the toolchain PPA in Natty to be newer
> > than the one in natty itself and I'll check it out.
> 
> See https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033042.html
> Is there something missing?

Thanks.  I looked in the wrong PPA.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


Re: [Oneiric-Foundations-Topic] Boost Defaults

2011-04-26 Thread Matthias Klose

On 04/26/2011 04:47 AM, Scott Kitterman wrote:

On Saturday, April 23, 2011 06:26:27 AM Matthias Klose wrote:

On 04/14/2011 06:28 PM, Scott Kitterman wrote:

This should get done before UDS, during toolchain upload (i.e. before the
first autosync), but I think it's worth mentioning.

The current Boost that's default and in Main is 1.42.  Debian's current
default is 1.46. My proposal for Oneiric is that we switch our
default/Main version to 1.46 at the start of Oneric development and then
in Debian updates their default prior to feature freeze, we'll assess
where we are and decide if we should stay with 1.46 or advance.


whatever version you do choose, please make sure it does build with GCC
4.6.


Please update the gcc-defaults in the toolchain PPA in Natty to be newer than
the one in natty itself and I'll check it out.


See https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033042.html
Is there something missing?

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel