Canonical Voices

Posts tagged with 'uncategorized'

Greg Lutostanski

Server team meeting minutes: 2015-2-10

Agenda

  • Review ACTION points from previous meeting
  • V Development
  • Server & Cloud Bugs (caribou)
  • Weekly Updates & Questions for the QA Team (psivaa)
  • Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
  • Ubuntu Server Team Events
  • Open Discussion
  • Announce next meeting date, time and chair
  • Minutes

    Meeting Actions

    None

    V Development

    Feb 19th is feature freeze and debian import freeze.
    Progress on OpenStack Kilo features seems to be progressing well

    Server & Cloud Bugs

    None

    Ubuntu Server Team Events

    ODS is coming up

    Open Discussion
    Agree on next meeting date and time

    Next meeting will be on Tuesday, Feb 17th at 16:00 UTC in #ubuntu-meeting. arosales will chair.

    IRC Log
    https://wiki.ubuntu.com/MeetingLogs/Server/20150210

    Read more
    Ryan Finnie

    Download the lastest Ubuntu 14.04 Raspberry Pi 2 image

    If you downloaded an older image than the current one, you shouldn't need to reinstall, but be sure to review the changelog in the link above.

    Note that this blog post originally contained a bunch more information, which has been moved to a dedicated page on wiki.ubuntu.com.

    I've closed comments on this blog post. If you are looking for help, please see this post on the raspberrypi.org forums. If you post there, you'll be reaching a wider audience of people (including myself) who can help you. Thanks for all of your comments!


    After my last post, I went and ported Sjoerd's Raspberry Pi 2 Debian kernel patchset to Ubuntu's kernel package base (specifically 3.18.0-14.15). The result is an RPi2-compatible 3.18.7-based kernel which not only installs in Ubuntu, but has all the Ubuntu bells and whistles. I also re-ported flash-kernel based on Ubuntu's package, recompiled raspberrypi-firmware-nokernel, created a linux-meta-rpi2 package, and put it all in a PPA.

    With that all done, I decided to go ahead and produce a base Ubuntu trusty image. It's 1.75GB uncompressed so you can put it on a 2GB or larger MicroSD card, and includes a full ubuntu-standard setup. Also included in the zip is a .bmap file; if you are writing the image in Linux you can use bmap-tools package to write only the non-zero bytes, saving some time. Otherwise it's the same procedure as other Raspberry Pi images.

    (PS: If this image becomes popular, I should point out ahead of time: This is an unofficial image and is in no way endorsed by my employer, who happens to be the company who produces Ubuntu. This is a purely personal undertaking.)

    Read more
    Ryan Finnie

    UPDATE: I've created a proper Ubuntu 14.04 image for the Raspberry Pi 2.

    My Raspberry Pi 2 arrived yesterday, and I started playing with it today. Unlike the original Raspberry Pi which had an ARMv6 CPU, the Raspberry Pi 2 uses a Broadcom BCM2836 (ARMv7) CPU, which allows for binary compatibility with many distributions' armhf ports. However, it's still early early in the game, and since ARM systems have little standardization, there isn't much available yet. Raspbian works, but its userland still uses ARMv6-optimized binaries. Ubuntu has an early beta of Ubuntu Snappy, but Snappy is a much different environment than "regular" Ubuntu.

    I found this post by Sjoerd Simons detailing getting Debian testing (jessie) on the Pi 2, and he did a good job of putting together the needed software, which I used to get a clean working install of Ubuntu trusty on my Pi 2. This is meant as a rough guide, mostly from memory -- I'll let better people eventually take care of producing a user-friendly system image. This procedure should work for trusty, utopic, and vivid, and might work for earlier distributions.

    1) Install and boot Raspbian on one MicroSD card, and get the system access to a second MicroSD card, e.g. via a USB adapter.

    2) Partition and format the card. #1 must be a vfat partition (64MB should be fine), and for the rest of this post I'm going to assume #2 is a swap partition and #3 is the rest of the card as ext4 for the root partition. Mount the root partition at e.g. /mnt/ubuntu and the vfat partition at e.g. /mnt/ubuntu-boot

    3) Bootstrap a trusty system.

    # apt-get install debootstrap
    # ln -sf gutsy /usr/share/debootstrap/scripts/trusty
    # debootstrap trusty /mnt/ubuntu
    

    4) Chroot into the bootstrapped system.

    # mount -t proc none /mnt/ubuntu/proc
    # mount -t sysfs none /mnt/ubuntu/sys
    # mount --bind /dev /mnt/ubuntu/dev
    # chroot /mnt/ubuntu
    

    5) Configure the base system. At the very least you should add a user, set passwords, and edit /etc/fstab as so:

    proc            /proc           proc    defaults          0       0
    /dev/mmcblk0p3  /               ext4    defaults,noatime  0       1
    /dev/mmcblk0p2  none            swap    sw                0       0
    

    6) Install all the necessary packages in Sjoerd's repository. You can either add the apt repository, or just do as I did and download/dpkg install them manually. However, there's a problem. These are built for jessie, and the linux-image package requires initramfs-tools 0.110 or greater, which is not yet available in Ubuntu. But since the kernel we're using doesn't actually need an initramfs, I've put together an "initramfs-tools 0.110~fake1" package which fakes it. Simply install that package ahead of time.

    7) Outside the chroot, copy /boot/config.txt from the Raspbian installation to /mnt/ubuntu/boot/firmware/config.txt. Then create /mnt/ubuntu/boot/firmware/cmdline.txt with the following:

    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p3 rootwait
    

    8) Copy the firmware files to the actual boot device:

    # cp -a /mnt/ubuntu/boot/firmware/* /mnt/ubuntu-boot/
    

    9) Umount everything, shut down the system, swap the new card into place, and boot. Once you are successfully booted into the Ubuntu system, I'd recommend installing the ubuntu-standard metapackage to get everything not pulled in by the base debootstrap.

    ryan@raspberrypi:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 14.04.1 LTS
    Release:        14.04
    Codename:       trusty
    
    ryan@raspberrypi:~$ uname -a
    Linux raspberrypi 3.18.0-trunk-rpi2 #1 SMP PREEMPT Debian 3.18.5-1~exp1.co1 (2015-02-02) armv7l armv7l armv7l GNU/Linux
    
    ryan@raspberrypi:~$ cat /proc/cpuinfo 
    processor       : [0,1,2,3]
    model name      : ARMv7 Processor rev 5 (v7l)
    BogoMIPS        : 38.40
    Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
    CPU implementer : 0x41
    CPU architecture: 7
    CPU variant     : 0x0
    CPU part        : 0xc07
    CPU revision    : 5
    
    Hardware        : BCM2709
    Revision        : 0000
    Serial          : 0000000000000000
    
    ryan@raspberrypi:~$ gcc -v
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
    Target: arm-linux-gnueabihf
    Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
    Thread model: posix
    gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-19ubuntu1)
    

    Read more
    Joseph Salisbury

    Meeting Minutes

    IRC Log of the meeting.

    Meeting minutes.

    Agenda

    20150210 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    Our Vivid kernel has been rebased to v3.18.5 upstream stable. It’s
    been uploaded to the archive, 3.18.0-13.14. Please test and let us
    know your results.
    We would like to push the v3.19 based kernel we have up to the archive
    soon. We are just cleaning up some DKMS drivers before we do so. For anyone interested in getting an early preview, we have a v3.19 based
    kernel available for testing in our ckt PPA.
    —–
    Important upcoming dates:
    Thurs Feb 19 – 14.04.2 Point Release (~1 week away, yes this was
    delayed)
    Thurs Feb 26 – Beta 1 Freeze (~2 weeks away)
    Thurs Mar 26 – Fina l Beta (~6 weeks away)
    Thurs Apr 09 – Kernel Freeze (~8 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Kernel Prep Week
    • Precise – Kernel Prep Week
    • Trusty – Kernel Prep Week
    • Utopic – Kernel Prep Week

      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 had ended. Waiting for next cycle to start on Feb. 08.
      cycle: 06-Feb through 28-Feb
      ====================================================================
      06-Feb Last day for kernel commits for this cycle
      08-Feb – 14-Feb Kernel prep week.
      15-Feb – 28-Feb Bug verification; Regression testing; Release


    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

    20150203 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel (jsalisbury for ogasawara)

    Our Vivid kernel has been rebased to the v3.18.4 upstream stable. It’s
    been uploaded to the archive, 3.18.0-12.13. Please test and let us
    know your results. We will be rebasing to v3.18.5 shortly and uploading
    as well. We’ll also be rebasing our unstable branch to v3.19-rc7 and will
    upload to our ckt PPA shortly.
    —–
    Important upcoming dates:
    Thurs Feb 5 – 14.04.2 Point Release (~2 days away)
    Thurs Feb 26 – Beta 1 Freeze (~3 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – None
    • Precise – None
    • Trusty – None
    • Utopic – None

      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 had ended. Waiting for next cycle to start on Feb. 08.


    Open Discussion or Questions? Raise your hand to be recognized

    No open discussion

    Read more
    jdstrand

    Most of this has been discussed on mailing lists, blog entries, etc, while developing Ubuntu Touch, but I wanted to write up something that ties together these conversations for Snappy. This will provide background for the conversations surrounding hardware access for snaps that will be happening soon on the snappy-devel mailing list.

    Background

    Ubuntu Touch has several goals that all apply to Snappy:

    • we want system-image upgrades
    • we want to replace the distro archive model with an app store model for Snappy systems
    • we want developers to be able to get their apps to users quickly
    • we want a dependable application lifecycle
    • we want the system to be easy to understand and to develop on
    • we want the system to be secure
    • we want an app trust model where users are in control and express that control in tasteful, easy to understand ways

    Snappy adds a few things to the above (that pertain to this conversation):

    • we want the system to be bulletproof (transactional updates with rollbacks)
    • we want the system to be easy to use for system builders
    • we want the system to be easy to use and understand for admins

    Let’s look at what all these mean more closely.

    system-image upgrades

    • we want system-image upgrades
    • we want the system to be bulletproof (transactional updates with rollbacks)

    We want system-image upgrades so updates are fast, reliable and so people (users, admins, snappy developers, system builders, etc) always know what they have and can depend on it being there. In addition, if an upgrade goes bad, we want a mechanism to be able to rollback the system to a known good state. In order to achieve this, apps need to work within the system and live in their own area and not modify the system in unpredictable ways. The Snappy FHS is designed for this and the security policy enforces that apps follow it. This protects us from malware, sure, but at least as importantly, it protects us from programming errors and well-intentioned clever people who might accidentally break the Snappy promise.

    app store

    • we want to replace the distro archive model with an app store model
    • we want developers to be able to get their apps to users quickly

    Ubuntu is a fantastic distribution and we have a wonderfully rich archive of software that is refreshed on a cadence. However, the traditional distro model has a number of drawbacks and arguably the most important one is that software developers have an extremely high barrier to overcome to get their software into users hands on their own time-frame. The app store model greatly helps developers and users desiring new software because it gives developers the freedom and ability to get their software out there quickly and easily, which is why Ubuntu Touch is doing this now.

    In order to enable developers in the Ubuntu app store, we’ve developed a system where a developer can upload software and have it available to users in seconds with no human review, intervention or snags. We also want users to be able to trust what’s in Ubuntu’s store, so we’ve created store policies that understand the Ubuntu snappy system such that apps do not require any manual review so long as the developer follows the rules. However, the Ubuntu Core system itself is completely flexible– people can install apps that are tightly confined, loosely confined, unconfined, whatever (more on this, below). In this manner, people can develop snaps for their own needs and distribute them however they want.

    It is the Ubuntu store policy that dictates what is in the store. The existing store policy is in place to improve the situation and is based on our experiences with the traditional distro model and attempts to build something app store-like experiences on top of it (eg, MyApps).

    application lifecycle

    • dependable application lifecycle

    This has not been discussed as much with Snappy for Ubuntu Core, but Touch needs to have a good application lifecycle model such that apps cannot run unconstrained and unpredictably in the background. In other words, we want to avoid problems with battery drain and slow systems on Touch. I think we’ve done a good job so far on Touch, and this story is continuing to evolve.

    (I mention application lifecycle in this conversation for completeness and because application lifecycle and security work together via the app’s application id)

    security

    • we want the system to be secure
    • we want an app trust model where users are in control and express that control in tasteful, easy to understand ways

    Everyone wants a system that they trust and that is secure, and security is one of the core tenants of Snappy systems. For Ubuntu Touch, we’ve created a
    system that is secure, that is easy to use and understand by users, and that still honors relevant, meaningful Linux traditions. For Snappy, we’ll be adding several additional security features (eg, seccomp, controlled abstract socket communication, firewalling, etc).

    Our security story and app store policies give us something that is between Apple and Google. We have a strong security story that has a number of similarities to Apple, but a lightweight store policy akin to Google Play. In addition to that, our trust model is that apps not needing manual review are untrusted by the OS and have limited access to the system. On Touch we use tasteful, contextual prompting so the user may trust the apps to do things beyond what the OS allows on its own (simple example, app needs access to location, user is prompted at the time of use if the app can access it, user answers and the decision is remembered next time).

    Snappy for Ubuntu Core is different not only because the UI supports a CLI, but also because we’ve defined a Snappy for Ubuntu Core user that is able to run the ‘snappy’ command as someone who is an admin, a system builder, a developer and/or someone otherwise knowledgeable enough to make a more informed trust decision. (This will come up again later, below)

    easy to use

    • we want the system to be easy to understand and to develop on
    • we want the system to be easy to use for system builders
    • we want the system to be easy to use and understand for admins

    We want a system that is easy to use and understand. It is key that developers are able to develop on it, system builders able to get their work done and admins can install and use the apps from the store.

    For Ubuntu Touch, we’ve made a system that is easy to understand and to develop on with a simple declarative permissions model. We’ll refine that for Snappy and make it easy to develop on too. Remember, the security policy is there not just so we can be ‘super secure’ but because it is what gives us the assurances needed for system upgrades, a safe app store and an altogether bulletproof system.

    As mentioned, the system we have designed is super flexible. Specifically, the underlying system supports:

    1. apps working wholly within the security policy (aka, ‘common’ security policy groups and templates)
    2. apps declaring specific exceptions to the security policy
    3. apps declaring to use restricted security policy
    4. apps declaring to run (effectively) unconfined
    5. apps shipping hand-crafted policy (that can be strict or lenient)

    (Keep in mind the Ubuntu App Store policy will auto-accept apps falling under ‘1’ and trigger manual review for the others)

    The above all works today (though it isn’t always friendly– we’re working on that) and the developer is in control. As such, Snappy developers have a plethora of options and can create snaps with security policy for their needs. When the developer wants to ship the app and make it available to all Snappy users via the Ubuntu App Store, then the developer may choose to work within the system to have automated reviews or choose not to and manage the process via manual reviews/commercial relationship with Canonical.

    Moving forward

    The above works really well for Ubuntu Touch, but today there is too much friction with regard to hardware access. We will make this experience better without compromising on any of our goals. How do we put this all together, today, so people can get stuff done with snappy without sacrificing on our goals, making it harder on ourselves in the future or otherwise opening Pandora’s box? We don’t want to relax our security policy, because we can’t make the bulletproof assurances we are striving for and it would be hard to tighten the security. We could also add some temporary security policy that adds only certain accesses (eg, serial devices) but, while useful, this is too inflexible. We also don’t want to have apps declare the accesses themselves to automatically adds the necessary security policy, because this (potentially) privileged access is then hidden from the Snappy for Ubuntu Core user.

    The answer is simple when we remember that the Snappy for Ubuntu Core user (ie, the one who is able to run the snappy command) is knowledgeable enough to make the trust decision for giving an app access to hardware. In other words, let the admin/developer/system builder be in control.

    immediate term

    The first thing we are going to do is unblock people and adjust snappy to give the snappy core user the ability to add specific device access to snap-specific security policy. In essence you’ll install a snap, then run a command to give the snap access to a particular device, then you’re done. This simple feature will unblock developers and snappy users immediately while still supporting our trust-model and goals fully. Plus it will be worth implementing since we will likely always want to support this for maximum flexibility and portability (since people can use traditional Linux APIs).

    The user experience for this will be discussed and refined on the mailing list in the coming days.

    short term

    After that, we’ll build on this and explore ways to make the developer and user experience better through integration with the OEM part and ways of interacting with the underlying system so that the user doesn’t have to necessarily know the device name to add, but can instead be given smart choices (this can have tie-ins to the web interface for snappy too). We’ll want to be thinking about hotpluggable devices as well.

    Since this all builds on the concept of the immediate term solution, it also supports our trust-model and goals fully and is relatively easy to implement.

    future

    Once we have the above in place, we should have a reasonable experience for snaps needing traditional device access. This will give us time to evaluate how people are accessing hardware and see if we can make things even better by using frameworks and/or a hardware abstraction layer. In this manner, snaps can program to an easy to use API and the system can mediate access to the underlying hardware via that API.


    Filed under: canonical, security, ubuntu, ubuntu-server, uncategorized

    Read more
    Joseph Salisbury

    Meeting Minutes

    IRC Log of the meeting.

    Meeting minutes.

    Agenda

    20150127 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    Our Vivid kernel has been rebased to v3.18.3 upstream stable. It’s been
    uploaded to the archive, 3.18.0-11.2. We’ll rebase to v3.18.4 shortly.
    We’ve also rebased our unstable branch to v3.19-rc6 and uploaded to our
    ckt PPA.
    Important upcoming dates:
    Thurs Feb 5 – 14.04.2 Point Release (~1 weeks away)
    Thurs Feb 26 – Beta 1 Freeze (~4 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Verification & Testing
    • Precise – Verification & Testing
    • Trusty – Verification & Testing
    • Utopic – 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: 09-Jan through 31-Jan
      ====================================================================
      09-Jan Last day for kernel commits for this cycle
      11-Jan – 17-Jan Kernel prep week.
      18-Jan – 31-Jan Bug verification; Regression testing; Release


    Open Discussion or Questions? Raise your hand to be recognized

    No open discussion.

    Read more
    niemeyer

    MongoDB 3.0 (previously known as 2.8) is right around the block, and it’s time to release a few fixes and improvements on the mgo driver for Go to ensure it works fine on that new major server version. Compatibility is being preserved both with old applications and with old servers, so updating should be a smooth experience.

    Release r2015.01.24 of mgo includes the following changes:


    Support ReplicaSetName in DialInfo

    DialInfo now offers a ReplicaSetName field that may contain the name of the MongoDB replica set being connected to. If set, the cluster synchronization routines will prevent communication with any server that does not report itself as part of that replica set.

    Feature implemented by Wisdom Omuya.

    MongoDB 3.0 support for collection and index listing

    MongoDB 3.0 requires the use of commands for listing collections and indexes, and may report long results via cursors that must be iterated over. The CollectionNames and Indexes methods were adapted to support both the old and the new cases.

    Introduced Collection.NewIter method

    In the last few releases of MongoDB, a growing number of low-level database commands are returning results that include an initial set of documents and one or more cursor ids that should be iterated over for obtaining the remaining documents. Such results defeated one of the goals in mgo’s design: developers should be able to walk around the convenient pre-defined static interfaces when they must, so they don’t have to patch the driver when a feature is not yet covered by the convenience layer.

    The introduced NewIter method solves that problem by enabling developers to create normal iterators by providing the initial batch of documents and optionally the cursor id for obtaining the remaining documents, if any.

    Thanks to John Morales, Daniel Gottlieb, and Jeff Yemin, from MongoDB Inc, for their help polishing the feature.

    Improved JSON unmarshaling of ObjectId

    bson.ObjectId can now be unmarshaled correctly from an empty or null JSON string, when it is used as a field in a struct submitted for unmarshaling by the json package.

    Improvement suggested by Jason Raede.

    Remove GridFS chunks if file insertion fails

    When writing a GridFS file, the chunks that hold the file content are written into the database before the document representing the file itself is inserted. This ensures the file is made visible to concurrent readers atomically, when it’s ready to be used by the application. If writing a chunk fails, the call to the file’s Close method will do a best effort to clean up previously written chunks. This logic was improved so that calling Close will also attempt to remove chunks if inserting the file document itself failed.

    Improvement suggested by Ed Pelc.

    Field weight support for text indexing

    The new Index.Weights field allows providing a map of field name to field weight for fine tuning text index creation, as described in the MongoDB documentation.

    Feature requested by Egon Elbre.

    Fixed support for $** text index field name

    Support for the special $** field name, which enables the indexing of all document fields, was fixed.

    Problem reported by Egon Elbre.

    Consider only exported fields on omitempty of structs

    The implementation of bson’s omitempty feature was also considering the value of non-exported fields. This was fixed so that only exported fields are taken into account, which is both in line with the overall behavior of the package, and also prevents crashes in cases where the field value cannot be evaluated.

    Fix potential deadlock on Iter.Close

    It was possible for Iter.Close to deadlock when the associated server was concurrently detected unavailable.

    Problem investigated and reported by John Morales.

    Return ErrCursor on server cursor timeouts

    Attempting to iterate over a cursor that has timed out at the server side will now return mgo.ErrCursor.

    Feature implemented by Daniel Gottlieb.

    Support for collection repairing

    The new Collection.Repair method returns an iterator that goes over all recovered documents in the collection, in a best-effort manner. This is most useful when there are damaged data files. Multiple copies of the same document may be returned by the iterator.

    Feature contributed by Mike O’Brien.

    Read more
    Pat Gaughen

    Our very own James Page blogged about Kilo-1 availability for Vivid and Trusty (via Ubuntu Cloud Archive) . If you are interested in checking out the current OpenStack in development on Ubuntu, this is for you. Enjoy!

    Read more
    Corey Bryant

    Agenda

    • Review ACTION points from previous meeting
      • gaughen to establish new qa-team point of contact for server team
    • V Development
    • Server & Cloud Bugs (caribou)
    • Weekly Updates & Questions for the QA Team (psivaa)
    • Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
    • Ubuntu Server Team Events
    • Open Discussion
    • Announce next meeting date, time and chair

    Minutes

    Meeting Actions
    • gaughen to establish new qa-team point of contact for server team — gaughen and beisner discussing – keeping as ACTION point

    • jamespage to answer question in bug 1410363 in response to smb

    V Development

    Today is Jan 20th.  Jan 22nd is alpha 2 (For opt-in flavors).  Feb 19th is feature freeze and debian import freeze.

    Server & Cloud Bugs
    caribou is busy on a CUPS bug & apport upstream issues
    Ubuntu Server Team Events

    FOSDEM is soon (Saturday 31 January and Sunday 1 February 2015) and hallyn is presenting lxd at FOSDEM on Sunday.

    Open Discussion

    teward says nginx merge coming as soon as the next debian updates come for it (assuming before featurefreeze). last merge introduced out of the box POODLE mitigations in the default confs.

    Agree on next meeting date and time

    Next meeting will be on Tuesday, Jan 27th at 16:00 UTC in #ubuntu-meeting. jamespage will chair.

    IRC Log
    https://wiki.ubuntu.com/MeetingLogs/Server/20150120

    Read more
    Victor Palau

    Just a quick note to tell you that I have published a new scope called uBrick that brings you the awesomeness of Lego, as a catalogue powered by brickset.com, directly to your Ubuntu phone home screen.

    I wrote the scope in Go cause I find it easier to work with for a quick scope ( took about 8 hours with interruptions over 2 days to write this scope).  The scope is now available at the store, just search for uBrick.

    Here are some pics:

    lego1lego2lego3 lego4

    Also I have to congratulate the folks at Brickset for a very nice API, even if it is using SOAP :)


    Read more
    Joseph Salisbury

    Meeting Minutes

    IRC Log of the meeting.

    Meeting minutes.

    Agenda

    20150120 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    Our Vivid kernel remains based on the v3.18.2 upstream stable kernel,
    but we’ll be rebasing to v3.18.3 shortly. We’ll also be rebsaing our
    unstable branch to v3.19-rc5 and get that uploaded to our team PPA soon.
    —–
    Important upcoming dates:
    Thurs Jan 22 – Vivid Alpha 2 (~2 days! away)
    Thurs Feb 5 – 14.04.2 Point Release (~2 weeks away)
    Thurs Feb 26 – Beta 1 Freeze (~5 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Verification & Testing
    • Precise – Verification & Testing
    • Trusty – Verification & Testing
    • Utopic – 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: 09-Jan through 31-Jan
      ====================================================================
      09-Jan Last day for kernel commits for this cycle
      11-Jan – 17-Jan Kernel prep week.
      18-Jan – 31-Jan Bug verification; Regression testing; Release


    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

    20150113 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    Both the master and master-next branches of our Vivid kernel have been
    rebased to the v3.18.2 upstream stable kernel. This has also be
    uploaded to the archive, ie. 3.18.0-9.10. Please test and let us
    know your results. We are also starting to track the v3.19 kernel on
    our unstable branch and have pushed preliminary packages to our ppa.
    —–
    Important upcoming dates:
    Thurs Jan 22 – Vivid Alpha 2 (~1 week away)
    Thurs Feb 5 – 14.04.2 Point Release (~3 weeks away)
    Thurs Feb 26 – Beta 1 Freeze (~6 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Kernel prep week.
    • Precise – Kernel prep week.
    • Trusty – Kernel prep week.
    • Utopic – Kernel prep week.

      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: 09-Jan through 31-Jan
      ====================================================================
      09-Jan Last day for kernel commits for this cycle
      11-Jan – 17-Jan Kernel prep week.
      18-Jan – 31-Jan Bug verification; Regression testing; Release


    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

    20150106 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    Both the master and master-next branches of our Vivid kernel have been
    rebased to the v3.18.1 upstream stable kernel. We have also uploaded
    our first 3.18 based kernel to the archive (3.18.0-8.9). Please test and let us
    know your results. We are also starting to track the v3.19 kernel on
    our unstable branch.
    —–
    Important upcoming dates:
    Fri Jan 9 – 14.04.2 Kernel Freeze (~3 days away)
    Thurs Jan 22 – Vivid Alpha 2 (~2 weeks away)
    Thurs Feb 5 – 14.04.2 Point Release (~4 weeks away)
    Thurs Feb 26 – Beta 1 Freeze (~7 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Verification & Testing
    • Precise – Verification & Testing
    • Trusty – Verification & Testing
    • Utopic – 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: 12-Dec through 10-Jan
      ====================================================================
      12-Dec Last day for kernel commits for this cycle
      14-Dec – 20-Dec Kernel prep week.
      21-Dec – 10-Jan Bug verification; Regression testing; Release


    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

    20141216 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The master-next branch of our Vivid kernel remains rebased to the
    final v3.18 upstream kernel. We have pushed uploads to our team’s PPA
    for preliminary testing. We are still debating on uploading to the
    archive after Alpha1 releases this week. However, we may opt to wait
    until everyone returns from holiday after the new year.
    —–
    Important upcoming dates:
    Thurs Dec 18 – Vivid Alpha 1 (~2 days away)
    Fri Jan 9 – 14.04.2 Kernel Freeze (~3 weeks away)
    Thurs Jan 22 – Vivid Alpha 2 (~5 weeks away)
    Thurs Feb 5 – 14.04.2 Point Release (~7 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Prep
    • Precise – Prep
    • Trusty – Prep
    • Utopic – 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: 12-Dec through 10-Jan
      ====================================================================
      12-Dec Last day for kernel commits for this cycle
      14-Dec – 20-Dec Kernel prep week.
      21-Dec – 10-Jan Bug verification; Regression testing; Release


    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

    20141209 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The master-next branch of our Vivid kernel has been rebased to the
    final v3.18 upstream kernel. We have pushed uploads to our team’s PPA
    for preliminary testing. We’ll likely upload to the official archive
    soon.
    —–
    Important upcoming dates:
    Thurs Dec 18 – Vivid Alpha 1 (~1 weeks away)
    Thurs Jan 22 – Vivid Alpha 2 (~6 weeks away)
    Fri Jan 9 – 14.04.2 Kernel Freeze (~4 weeks away)
    Thurs Feb 5 – 14.04.2 Point Release (~8 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today:

    • Lucid – Testing
    • Precise – Testing
    • Trusty – Testing
    • Utopic – 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: 21-Nov through 13-Dec
      ====================================================================
      21-Nov Last day for kernel commits for this cycle
      23-Nov – 29-Nov Kernel prep week.
      30-Nov – 13-Dec Bug verification; Regression testing; Release


    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

    20141202 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The master-next branch of our Vivid kernel has been rebased to the
    v3.18-rc7 upstream kernel. We have pushed uploads to our team’s PPA
    for preliminary testing. We have still withheld uploading to
    the archive while we iron out some final issues.
    —–
    Important upcoming dates:
    Thurs Dec 18 – Vivid Alpha 1 (~2 weeks away)
    Thurs Jan 22 – Vivid Alpha 2 (~7 weeks away)
    Thurs Feb 5 – 14.04.2 Point Release (~9 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today (02-Dec):

    • Lucid – Verification & Testing
    • Precise – Verification & Testing
    • Trusty – Verification & Testing
    • Utopic – 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: 21-Nov through 13-Dec
      ====================================================================
      21-Nov Last day for kernel commits for this cycle
      23-Nov – 29-Nov Kernel prep week.
      30-Nov – 13-Dec Bug verification; Regression testing; Release
      Note: Utopic and LTS-Utopic kernels are being respun due to a verification
      failure


    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

    20141118 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The master-next branch of our Vivid kernel has been rebased to the
    v3.18-rc5 upstream kernel. We have still withheld uploading to
    the archive until we’ve progressed to a later -rc candidate.
    —–
    Important upcoming dates:
    Thurs Dec 18 – Vivid Alpha 1 (~4 weeks away)
    Thurs Jan 22 – Vivid Alpha 2 (~9 weeks away)


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today (18-Nov):

    • Lucid – Verification & Testing
    • Precise – Verification & Testing
    • Trusty – Verification & Testing
    • Utopic – 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: 31-Oct through 22-Nov
      ====================================================================
      31-Oct Last day for kernel commits for this cycle
      02-Nov – 08-Nov Kernel prep week.
      09-Nov – 15-Nov Bug verification & Regression testing.
      16-Nov – 22-Nov 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

    20141104 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The master-next branch of our Vivid kernel has bee rebased to the
    lastest v3.18-rc3 upstream kernel. We have still witheld uploading to
    the archive until we’ve progressed to a later -rc candidate.
    —–
    Important upcoming dates:
    The Vivid ReleaseSchedule has not yet been posted.


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today (Nov. 04):

    • Lucid – Verification & Testing
    • Precise – Holding (waiting on upstream CVE fixes)
    • Trusty – Verification & Testing
    • Utopic – 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: 31-Oct through 22-Nov
      ====================================================================
      31-Oct Last day for kernel commits for this cycle
      02-Nov – 08-Nov Kernel prep week.
      09-Nov – 15-Nov Bug verification & Regression testing.
      16-Nov – 22-Nov 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

    20141028 Meeting Agenda


    Release Metrics and Incoming Bugs

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

    • http://people.canonical.com/~kernel/reports/kt-meeting.txt


    Status: Vivid Development Kernel

    The Vivid kernel has been opened and master-next rebased to the lastest
    v3.18-rc2 upstream kernel. We have witheld uploading to the archive
    until we’ve progressed to a later -rc candidate.
    —–
    Important upcoming dates:
    The Vivid ReleaseSchedule has not yet been posted.


    Status: CVE’s

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

    http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html


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

    Status for the main kernels, until today (Sept. 30):

    • Lucid -
    • Precise -
    • Trusty – 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: 10-Oct through 31-Oct
      ====================================================================
      8-Oct Last day for kernel commits for this cycle
      09-Oct – 10-Oct Kernel prep
      12-Oct – 18-Oct Bug verification & Regression testing.
      19-Oct – 25-Oct Bug verification & Regression testing.
      26-Oct – 01-Nov Regression testing & Release to -updates.


    Open Discussion or Questions? Raise your hand to be recognized

    No open discussions.

    Read more