Canonical Voices

Posts tagged with 'uncategorized'

Robie Basak

Meeting information

Agenda

Minutes

Review ACTION points from previous meeting

The discussion about “Review ACTION points from previous meeting” started at 16:00.

  • No actions from previous meeting.

Development Release

The discussion about “Development Release” started at 16:00.

Assigned merges/bugwork (rbasak)

The discussion about “Assigned merges/bugwork (rbasak)” started at 16:02.

  • rbasak has triaged some bugs, tagging some “bitesize”, and advised prospective Ubuntu developers to take a look at these.

Server & Cloud Bugs (caribou)

The discussion about “Server & Cloud Bugs (caribou)” started at 16:05.

  • Squid, Samba and MySQL bugs noted; all are in progress. Nothing else in particular to bring up.

Weekly Updates & Questions for the QA Team

The discussion about “Weekly Updates & Questions for the QA Team” started at 16:06.

  • No questions to or from the QA team
  • jgrimm noted that the Canonical Server Team currently have an open QA position and invited applications and recommendations.

Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)

The discussion about “Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)” started at 16:07.

  • No questions to/from the kernel team

Upcoming Call For Papers

The discussion about “Upcoming Call For Papers” started at 16:10.

  • No upcoming CfPs of note

Ubuntu Server Team Events

The discussion about “Ubuntu Server Team Events” started at 16:11.

  • No upcoming events of note

Open Discussion

The discussion about “Open Discussion” started at 16:11.

Announce next meeting date, time and chair

The discussion about “Announce next meeting date, time and chair” started at 16:18.

  • The next meeting will be at Tue 17 May 16:00:00 UTC 2016. jamespage will chair.

Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)

Read more
David Henningsson

So; assume that you have some new hardware that works for the most part, but you have some problems with your built-in sound card. The problem has been fixed upstream, but if you start using that particular upstream kernel only, you will lose Ubuntu kernel security updates. In some cases, bug fixes will come to Ubuntu kernels too – after some time – but in other cases these fixes won’t, for a variety of reasons.

You want to run a standard Ubuntu kernel, except for your sound driver (or some other driver), which you want to be something different. This actually happens quite often when our team enables hardware that isn’t yet on the market, and therefore lack full support in already released kernels.

DKMS

To the rescue comes DKMS (short for Dynamic kernel module support), which installs the source of the actual driver on the machine, and, whenever the Ubuntu kernel is upgraded, automatically recompiles the driver to fit the new kernel. The compiled modules are installed into the right directory for them to be used at next boot. We’ve used this tool for several years, and found it to be incredibly useful.

Launchpad automation

Launchpad got a feature called recipes, which combines one or more bzr branches and automatically makes a source package whenever one of the source packages change. The source package is then uploaded to a ppa, which builds a binary package from the source package.

What is then the result of all this well-oiled machinery? That every day, you have the latest sound driver which is ready for you to install and use to see if it fixes your sound issues – and because it’s packaged as a normal Debian package, uninstallation is easy in case it does not work. We have had this up and running for the Intel HDA driver for several years now, and it’s been useful for both Canonical and the Ubuntu community.

Details

That’s the birds-eye overview. In practice, things are a bit more complicated. Get ready for the mandatory boxes-and-arrows picture:

hda-build-flow2

Preparing for import

Our main source is the master branch of sound.git, maintained by Takashi Iwai. However, Launchpad does not yet support git in recipe builds, therefore, a machine somewhere in the cloud runs a preparation script. This script checks the git branch for updates every hour and if there is one, starts with filtering out the “sound” directory (this is a simple optimization, because kernel trees are huge). The result is added to a bzr branch.

Actually this cloud machine does one more thing, but it’s more of a bonus: it runs some hda-emu based testing. Hda-emu is a tool for emulating an HD-audio codec, and takes alsa-info as input. So, we contributed a lot of alsa-infos from machines Canonical enable to the upstream hda-emu repository, along with some scripts to run some emulation tests on all of them. So, in case something breaks, we get an early warning, before the code reaches more people. The most common case for the test to break however is not an actual bug, but that the hda-emu tool needs updating to handle changes in the kernel driver. Therefore, the script is not stopped when this happens, it just puts a warning message in the bzr commit log.

The cloud machine runs a bzr server, which Launchpad then checks a few times per day for updates, and imports changes into a Launchpad hosted mirror branch.

Making a DKMS package

As our launchpad recipe detects that the bzr branch has changed, it re-runs the recipe. The recipe is quite simple – it only copies files from different branches into some directory, creates a source package out of the result, and uploads that package to a PPA. That’s where we combine the upstream source with our DKMS configuration. There is some scripting involved to e g figure out the names of the built kernel modules – if you’re making your own DKMS package, it will probably be easier to write that file by hand.

Unfortunately, compiling a new driver on an older kernel can be challenging, when the driver starts relying on features only present in the new kernel. Therefore, we regularly need to manually add patches to the new driver to make it compile on the older kernel.

Launchpad build

This part is just like any other build on a Launchpad PPA – it takes a source package and builds a binary package. This is where the backport patches actually get applied to the source. Please note that even though this is a binary package, what’s inside the package is not compiled binaries, it’s the source code for the driver. This is because the final compilation occurs on the end user machine.

(A funny quirk: when DKMS is invoked, it creates a .deb file by itself, but for some reason Launchpad wouldn’t accept this .deb file. I never really figured out why, but instead worked around it by manually unpacking DKMS’s .deb, then repacking it again using low-level dpkg-gencontrol and dpkg-deb tools.)

The binary package is then published in the PPA, downloaded/copied by the end user to his/her machine, and installed just like any other Debian package.

On the end user machine

The final step; where the driver source is combined with a standard Ubuntu kernel, is done on the end user’s machine. DKMS itself installs triggers on the end user machine that will be called every time a new kernel is installed, upgraded or removed.

On installation of a new kernel, DKMS will verify that the relevant kernel header package is also installed, then use these headers to recompile all installed DKMS binary packages against the new kernel. The resulting files are copied into /lib/modules/<kernel>/updates/dkms. On installation of a new DKMS binary package, the default is to recompile the new package against the latest kernel and the currently running kernel.

DKMS also runs depmod to ensure the kernel will pick up the newly compiled modules.

Final remarks

There are some caveats which might be worth mentioning.

First, if you combine the regular Ubuntu kernel (with security updates) with a DKMS driver, you will get security updates for the entire kernel except that specific driver, so in theory, you could be left with a security issue if the vulnerability is in the specific driver you use DKMS for. However, in practice the vast majority of security bugs are userspace facing code, rather than deep down in hardware specific drivers.

Second, on every Ubuntu kernel released there is a potential risk for breakage, e g, if the DKMS driver calls a function in the kernel and that function changes its signature, then the DKMS driver will fail to compile and install on the new kernel. Or even worse, the function changes behavior without changing signature, so that the DKMS driver will compile just fine, but break in some way when the driver runs. All I can say about that is that, to my knowledge, if this can happen then it happens very rarely – I’ve never seen it cause any problems in practice.

Read more
Lorn Potter

Hello world!

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Read more
David Henningsson

2.1 surround sound is (by a very unscientific measure) the third most popular surround speaker setup, after 5.1 and 7.1. Yet, ALSA and PulseAudio has since a long time back supported more unusual setups such as 4.0, 4.1 but not 2.1. It took until 2015 to get all pieces in the stack ready for 2.1 as well.

The problem

So what made adding 2.1 surround more difficult than other setups? Well, first and foremost, because ALSA used to have a fixed mapping of channels. The first six channels were decided to be:

1. Front Left
2. Front Right
3. Rear Left
4. Rear Right
5. Front Center
6. LFE / Subwoofer

Thus, a four channel stream would default to the first four, which would then be a 4.0 stream, and a three channel stream would default to the first three. The only way to send a 2.1 channel stream would then be to send a six channel stream with three channels being silence.

This was not good enough, because some cards, including laptops with internal subwoofers, would only support streaming four channels maximum.

(To add further confusion, it seemed some cards wanted the subwoofer signal on the third channel of four, and others wanted the same signal on the fourth channel of four instead.)

ALSA channel map API

The first part of the solution was a new alsa-lib API for channel mapping, allowing drivers to advertise what channel maps they support, and alsa-lib to expose this information to programs (see snd_pcm_query_chmaps, snd_pcm_get_chmap and snd_pcm_set_chmap).

The second step was for the alsa-lib route plugin to make use of this information. With that, alsa-lib could itself determine whether the hardware was 5.1 or 2.1, and change the number of channels automatically.

PulseAudio bass / treble filter

With the alsa-lib additions, just adding another channel map was easy.
However, there was another problem to deal with. When listening to stereo material, we would like the low frequencies, and only those, to be played back from the subwoofer. These frequencies should also be removed from the other channels. In some cases, the hardware would have a built-in filter to do this for us, so then it was just a matter of setting enable-lfe-remixing in daemon.conf. In other cases, this needed to be done in software.

Therefore, we’ve integrated a crossover filter into PulseAudio. You can configure it by setting lfe-crossover-freq in daemon.conf.

The hardware

If you have a laptop with an internal subwoofer, chances are that it – with all these changes to the stack – still does not work. Because the HDA standard (which is what your laptop very likely uses for analog audio), does not have much of a channel mapping standard either! So vendors might decide to do things differently, which means that every single hardware model might need a patch in the kernel.

If you don’t have an internal subwoofer, but a separate external one, you might be able to use hdajackretask to reconfigure your headphone jack to an “Internal Speaker (LFE)” instead. But the downside of that, is that you then can’t use the jack as a headphone jack…

Do I have it?

In Ubuntu, it’s been working since the 15.04 release (vivid). If you’re not running Ubuntu, you need alsa-lib 1.0.28, PulseAudio 7, and a kernel from, say, mid 2014 or later.

Acknowledgements

Takashi Iwai wrote the channel mapping API, and also provided help and fixes for the alsa-lib route plugin work.

The crossover filter code was imported from CRAS (but after refactoring and cleanup, there was not much left of that code).

Hui Wang helped me write and test the PulseAudio implementation.

PulseAudio upstream developers, especially Alexander Patrakov, did a thorough review of the PulseAudio patch set.

Read more
Robie Basak

  • rbasak listed areas that he thinks needs looking at before Xenial feature freeze on 18 Feb. hallyn pointed out that this should be in a blueprint, so rbasak agreed to take an action to create one. Some work item assignments were made for the blueprint.
  • No other discussion was required for the other standing agenda items.
  • Meeting actions assigned:
    • rbasak look at
      https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 and https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298
    • rbasak to create blueprint for Xenial feature work
    • rbasak to find kickinz1 a merge to do
  • The next meeting will be on Tue Nov 24 16:00:00 UTC 2015 in #ubuntu-meeting.

Full agenda and log

Read more
Mark W Wenning

Hello world!

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20151027 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Xenial Development Kernel

Our Xenial kernel is open for development. The repo’s have been opened
in LP:
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-meta/+git/xenial
git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-signed/+git/xenial
Our Xenial master branch is still tracking Wily’s v4.2 based kernel.
However, Xenial master-next is currently rebased to v4.3-rc7.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/XenialXerus/ReleaseSchedule
    Thurs Dec 31 – Alpha 1 (~ weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid/Wily

Status for the main kernels, until today:

  • Precise – Testing and Verification
  • Trusty – Testing and Verification
  • lts-Utopic – Testing and Verification
  • Vivid – Testing and Verification
  • Wily – Testing and Verification

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    Current cycle: 18-Oct through 07-Nov
    ====================================================================
    16-Oct Last day for kernel commits for this cycle
    18-Oct – 24-Oct Kernel prep week.
    25-Oct – 31-Oct Bug verification & Regression testing.
    01-Nov – 07-Nov Regression testing & Release to -updates.

    Next cycle: 08-Nov through 28-Nov
    ====================================================================
    06-Nov Last day for kernel commits for this cycle
    08-Nov – 14-Nov Kernel prep week.
    15-Nov – 21-Nov Bug verification & Regression testing.
    22-Nov – 28-Nov Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
finnie-admin

2ping 3.0.0 has been released. It is a total rewrite, with the following features:

  • Total rewrite from Perl to Python.
  • Multiple hostnames/addresses may be specified in client mode, and will be pinged in parallel.
  • Improved IPv6 support:
    • In most cases, specifying -4 or -6 is unnecessary. You should be able to specify IPv4 and/or IPv6 addresses and it will "just work".
    • IPv6 addresses may be specified without needing to add -6.
    • If a hostname is given in client mode and the hostname provides both AAAA and A records, the AAAA record will be chosen. This can be forced to one or another with -4 or -6.
    • If a hostname is given in listener mode with -I, it will be resolved to addresses to bind as. If the hostname provides both AAAA and A records, they will both be bound. Again, -4 or -6 can be used to restrict the bind.
    • IPv6 scope IDs (e.g. fe80::213:3bff:fe0e:8c08%eth0) may be used as bind addresses or destinations.
  • Better Windows compatibility.
  • ping(8)-compatible superuser restrictions (e.g. flood ping) have been removed, as 2ping is a scripted program using unprivileged sockets, and restrictions would be trivial to bypass. Also, the concept of a "superuser" is rather muddied these days.
  • Better timing support, preferring high-resolution monotonic clocks whenever possible instead of gettimeofday(). On Windows and OS X, monotonic clocks should always be available. On other Unix platforms, monotonic clocks should be available when using Python 2.7
  • Long option names for ping(8)-compatible options (e.g. adaptive mode can be called as --adaptive in addition to -A). See 2ping --help for a full option list.

Because of the IPv6 improvements, there is a small breaking functionality change. Previously, to listen on both IPv4 and IPv6 addresses, you needed to specify -6, e.g. 2ping --listen -6 -I 127.0.0.1 -I ::1. Now that -6 restricts binds to IPv6 addresses, that invocation will just listen on ::1. Simply remove -6 to listen on both IPv4 and IPv6 addresses.

This is a total rewrite in Python, and the original Perl code was not used as a basis, instead writing the new version from the 2ping protocol specification. (The original Perl version was a bit of a mess, and I didn't want to pick up any of its habits.) As a result of rewriting from the specification, I discovered the Perl version's implementation of the checksum algorithm was not even close to the specification (and when it comes to checksums, "almost" is the same as "not even close"). As the Perl version is the only known 2ping implementation in the wild which computes/verifies checksums, I made a decision to amend the specification with the "incorrect" algorithm described in pseudocode. The Python version's checksum algorithm matches this in order to maintain backwards compatibility.

This release also marks the five year anniversary of 2ping 1.0, which was released on October 20, 2010.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20151020 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Wily Development Kernel

We release Wily 15.10 in 2 days this Thurs Oct 22. Any kernel patches submitted for Wily will now be queued for SRU and must adhere to SRU
policy.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Oct 22 – 15.10 Release (~2 days away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Kernel Prep
  • Trusty – Kernel Prep
  • lts-Utopic – Kernel Prep
  • Vivid – Kernel Prep

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 18-Oct through 07-Nov
    ====================================================================
    16-Oct Last day for kernel commits for this cycle
    18-Oct – 24-Oct Kernel prep week.
    25-Oct – 31-Oct Bug verification & Regression testing.
    01-Nov – 07-Nov Regression testing & Release to -updates.

    Note: Oct. 22 is release day



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20151006 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Wily Development Kernel

We are approaching Wily Kernel Freeze this Thurs Oct 8, ~2 days away!
If there are any patches which need to land for 15.10, please get them
submitted immediately. Following the Kernel Freeze deadline, all
patches are subject to our SRU policy and could miss the release.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Oct 8 – Kernel Freeze (~2 days away)
    Thurs Oct 15 – Final Freeze (~1 weeks away)
    Thurs Oct 22 – 15.10 Release (~2 weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Kernel Prep
  • Trusty – Kernel Prep
  • lts-Utopic – Kernel Prep
  • Vivid – Kernel Prep

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 27-Sep through 17-Oct
    ====================================================================
    25-Sep Last day for kernel commits for this cycle
    27-Sep – 03-Oct Kernel prep week.
    04-Oct – 10-Oct Bug verification & Regression testing.
    11-Oct – 17-Oct Regression testing & Release to -updates.
    Note: We have gotten off to a late start on this cycle due to some patches
    that came in at the last minute. We intend to stick to the schedule
    though that may change as we get farther along.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
niemeyer

Another stable release of the mgo Go driver for MongoDB hits the shelves, and this one brings some important improvements and fixes. As usual, it also remains fully compatible with prior releases in the v2 series.

Please read along for the complete list of changes.


New read preference modes

In addition to the traditional Strong, Monotonic, and Eventual modes, the driver now supports all read preference modes defined by the MongoDB specification:

  • PrimaryMode – Talk only to the replica set primary. That’s the same as mgo.Strong.
  • PrimaryPreferredMode – Talk to one of the closest secondaries if the primary is not available.
  • Secondary – Talk to one of the closest replica set secondaries.
  • SecondaryPreferredMode – Talk to the primary if a secondary is not available.
  • NearestMode – Talk to one of the closest servers, whether primary or secondary.

See Session.SetMode for details on how to switch modes.

bson.NewObjectId random initial counter

The bson.NewObjectId method will now uses a random initial counter value, as defined by the specification.

Documentation improvements

Various documentation improvements have been made, as suggested or submitted by contributors.

Bulk API improvements

Several improvements have been made to the Bulk API, including support for update and upsert operations, error reporting improvements, and a more efficient implementation based on write commands where that’s supported (MongoDB 2.6+).

Custom index name support

Indexes created by Collection.EnsureIndex may now declare a custom name during creation, if convenient. The Collection.DropIndexName method was also added to support the dropping of indexes by name.

Collection.Indexes method fixes

The Collection.Indexes method was returning results that lacked some of the information that was input into the Collection.EnsureIndexe method during creation. This has been fixed.

Problem reported by Louisa Berger.

Introduced Index.Minf/Maxf

The Min and Max fields currently offered by the Index type for tuning of geographical indexes were incorrectly assumed to be integers. Unfortunately these types cannot be changed without a backwards incompatible modification, so two new Minf and Maxf fields were introduced with the float64 type. Despite still working, the old fields are now obsolete.

Problem reported by Louisa Berger.

Name resolution fixed for Go 1.5

Go 1.5 modified the behavior of address resolution in a way that breaks the procedure implemented by mgo to resolve names within a given time span. This was addressed and now both IPv4 and IPv6 servers should be working correctly. This change was also applied as a hot fix to the previous release of the driver, to ensure developers could make use of the newly released compiler with mgo.

Issue reported and collaborated around by several contributors.

Read more
Ryan Finnie

Hello world!

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Read more
Victor Palau

My first steps into snappifying, I have publish a RestApi for PiGlow (glowapi 0.1.2). I though it might be a good first step and mildly useful for people wanting to set up build notifications, twitter mentions, whatever you fancy!

You can find it in the webdm store…
Code is here: https://code.launchpad.net/~vtuson/+junk/glowapi

And here is how it works:
PiGlow Api exposes PiGlow in your board port 8000, so you can easy accessing by POST in port 8000.

remeber to do the hardware assign, something like: sudo snappy hw-assign glowapi.vtuson /dev/i2c-1

API calls , method POST:

v1/flare
turns all the leds on to max brightness
v1/on
turns all the leds on to med brigthness
v1/clear
turns off all leds
v1/legs/:id
turns all the leds in a leg (:id) to a given brightness
(if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/legs/1?intensity=0.3
v1/legs/:id/colors/:colid
turns on one led (colid) in a leg (:id) to a given brightness
(if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/legs/1/colors/green?intensity=0.3
v1/colors/:colid
turn on all leds for a color across all legs
if not specify it uses a default setting)
parms: intensity , range 0 to 1
eg: http://localhost:8000/v1/colors/green?intensity=0.3

ID ranges
legs range : 0 – 2
colors:
green
white
blue
yellow
orange
red


Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150929 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Wily Development Kernel

Our Wily kernel remains based on stable v4.2.1 and we will continue to
track 4.2 for the remainder of the 15.10 cycle. As a reminder, we are
approaching Wily Kernel Freeze on Oct 8, ~1 week away. If there are any patches which need to land for 15.10, please get them submitted soon.
Following the Kernel Freeze deadline, all patches are subject to our SRU policy.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Oct 8 – Kernel Freeze (~1 weeks away)
    Thurs Oct 15 – Final Freeze (~2 weeks away)
    Thurs Oct 22 – 15.10 Release (~3 weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Kernel Prep
  • Trusty – Kernel Prep
  • lts-Utopic – Kernel Prep
  • Vivid – Kernel Prep
    Current opened tracking bugs details:
  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html
    Schedule:
    cycle: 27-Sep through 17-Oct
    ====================================================================
    25-Sep Last day for kernel commits for this cycle
    27-Sep – 03-Oct Kernel prep week.
    04-Oct – 10-Oct Bug verification & Regression testing.
    11-Oct – 17-Oct Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150922 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Wily Development Kernel

Our Wily kernel has been rebased to stable v4.2.1 and uploaded to
wily-proposed, ie 4.2.0-11.13. We will continue to track 4.2 for
the remainder of the 15.10 cycle. As a reminder, we are approaching
Wily Kernel Freeze on Oct 8, ~2 weeks away. If there are any patches
which need to land for 15.10, please get them submitted soon. Following
the Kernel Freeze deadline, all patches are subject to our SRU policy.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Oct 8 – Kernel Freeze (~2 weeks away)
    Thurs Oct 15 – Final Freeze (~3 weeks away)
    Thurs Oct 22 – 15.10 Release (~4 weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Verification & Testing
  • Trusty – Verification & Testing
  • lts-Utopic – Verification & Testing
  • Vivid – Verification & Testing

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 04-Sep through 26-Sep
    ====================================================================
    04-Sep Last day for kernel commits for this cycle
    06-Sep – 12-Sep Kernel prep week.
    13-Sep – 19-Sep Bug verification & Regression testing.
    20-Sep – 26-Sep Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150915 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: Wily Development Kernel

Our Wily kernel remains based on 4.2 final and is available in the
archive, ie. 4.2.0-7.7. We will continue to track 4.2 for
the remainder of the 15.10 cycle. As a reminder, we are approaching
Wily Kernel Freeze on Oct 8, ~3 weeks away. If there are any patches
which need to land for 15.10, please get them submitted soon. Following
the Kernel Freeze deadline, all patches are subject to our SRU policy.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Sep 24 – Final Beta (~1 week away)
    Thurs Oct 8 – Kernel Freeze (~3 weeks away)
    Thurs Oct 15 – Final Freeze (~4 weeks away)
    Thurs Oct 22 – 15.10 Release (~5 weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Verification & Testing
  • Trusty – Verification & Testing
  • lts-Utopic – Verification & Testing
  • Vivid – Verification & Testing

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 04-Sep through 26-Sep
    ====================================================================
    04-Sep Last day for kernel commits for this cycle
    06-Sep – 12-Sep Kernel prep week.
    13-Sep – 19-Sep Bug verification & Regression testing.
    20-Sep – 26-Sep Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150908 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt
    That page is coming up blank, but it will be fixed today.



Status: Wily Development Kernel

We have rebased our Wily master branch to a 4.2 based kernel and have
upoaded to the archive, ie 4.2.0-7.7. We will continue to track 4.2 for
the remainder of the 15.10 cycle.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Sep 24 – Final Beta (~2 weeks away)
    Thurs Oct 8 – Kernel Freeze (~4 weeks away)
    Thurs Oct 15 – Final Freeze (~5 weeks away)
    Thurs Oct 22 – 15.10 Release (~6 weeks away)



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Kernel Build & Prep
  • Trusty – Kernel Build & Prep
  • lts-Utopic – Kernel Build & Prep
  • Vivid – Kernel Build & Prep

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 04-Sep through 26-Sep
    ====================================================================
    04-Sep Last day for kernel commits for this cycle
    06-Sep – 12-Sep Kernel prep week.
    13-Sep – 19-Sep Bug verification & Regression testing.
    20-Sep – 26-Sep Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150901 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/lts-utopic/Vivid

Status for the main kernels, until today:

  • Precise – Verification & Testing
  • Trusty – Verification & Testing
  • lts-Utopic – Verification & Testing
  • Vivid – Verification & Testing

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 16-Aug through 05-Sep
    ====================================================================
    14-Aug Last day for kernel commits for this cycle
    15-Aug – 22-Aug Kernel prep week.
    23-Aug – 29-Aug Bug verification & Regression testing.
    30-Aug – 05-Sep Regression testing & Release to -updates.



Status: Wily Development Kernel

We have rebased and uploaded Wily master-next branch to 4.2 final from upstream.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Sep 24 – Final Beta (~3 weeks away)
    Thurs Oct 8 – Kernel Freeze (~5 weeks away)
    Thurs Oct 15 – Final Freeze (~6 weeks away)
    Thurs Oct 22 – 15.10 Release (~7 weeks away)



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20150825 Meeting Agenda



Release Metrics and Incoming Bugs

Release metrics and incoming bug data can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kt-meeting.txt



Status: CVE’s

The current CVE status can be reviewed at the following link:

  • http://kernel.ubuntu.com/reports/kernel-cves.html



Status: Wily Development Kernel

We have rebased our Wily master-next branch to the latest upstream
v4.2-rc8 and uploaded to our ~canonical-kernel-team PPA. The fglrx DKMS
package is still failing to build with this latest kernel. We are
actively investigating to get this resolved.
—–
Important upcoming dates:

  • https://wiki.ubuntu.com/WilyWerewolf/ReleaseSchedule
    Thurs Aug 27 – Beta 1 (~2 days away)
    Thurs Sep 24 – Final Beta (~4 weeks away)
    Thurs Oct 8 – Kernel Freeze (~6 weeks away)
    Thurs Oct 15 – Final Freeze (~7 weeks away)
    Thurs Oct 22 – 15.10 Release (~8 weeks away)



Status: Stable, Security, and Bugfix Kernel Updates – Precise/Trusty/Utopic/Vivid

Status for the main kernels, until today:

  • Precise – Verification & Testing
  • Trusty – Verification & Testing
  • lts-Utopic – Verification & Testing
  • Vivid – Verification & Testing

    Current opened tracking bugs details:

  • http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
    For SRUs, SRU report is a good source of information:
  • http://kernel.ubuntu.com/sru/sru-report.html

    Schedule:

    cycle: 16-Aug through 05-Sep
    ====================================================================
    14-Aug Last day for kernel commits for this cycle
    15-Aug – 22-Aug Kernel prep week.
    23-Aug – 29-Aug Bug verification & Regression testing.
    30-Aug – 05-Sep Regression testing & Release to -updates.



Open Discussion or Questions? Raise your hand to be recognized

No open discussion.

Read more
Michi Henning

Hello world!

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Read more