Canonical Voices

Jouni Helminen

Malta Sprint

Our Apps and Platform teams took part at a design/engineering sprint on the beautiful island of Malta in May, and we thought we would share some pics to show a peek into “behing the scenes” and people working on the apps and operating system.

The sprint itself was a great experience, with over 150 people, engineers and designers, working together and planning out the next steps. Refined designs for mobile apps such as Browser, Camera and Telephony suite (Dialer, Contacts and Messaging) were unveiled and implementation got well underway, and on the platform team Scopes are starting to look really beautiful on the phone. There were plenty of tech demos and talks ranging from Cloud to Convergence to Mobile to Internet of Things – it was great to see everyone hacking, designing and discussing together about super exciting things. A good reminder that although Canonical has grown in size, at the core it still feels like a startup in a good sense.

It is an interesting time coming up to the release of the phone hardware, and these two weeks at Malta were a brilliant opportunity for all teams to sync up, work hard and squeeze in some R&R in the evenings too. Sun, great grilled seafood and the historical buildings of Valeta – it was fantastic to work in such a beautiful setting, and we cannot wait to get all the new goodies in the hands of people.

IMG_2665

20140522-DSC05138ubuntu_team

20140519-DSC01071

20140519-DSC01063

Screen Shot 2014-06-10 at 23.22.09

Read more
Benjamin Keyser

Cueing up users

The bottom edge swipe gesture is simple and accessible for users, so it’s strategic for application developers. By giving instant access to the most needed settings, controls, and views through the bottom edge, app developers have a powerful tool for crafting more useful and usable experiences.

In earlier postings we’ve talked about how the bottom edge can be harnessed effectively, but helping users to get curious about this special place on the interface is the key to unlocking the full value of an app. The solution is simple and elegant: smart cues.

What is a cue?

1-telephone_bottom_edge_hint

On first glance, the bottom edge cue is just a tiny label space that pops up when an app is opened, looking much like a simple tab or handle. When the user grabs it, or simply swipes up, anywhere along the bottom edge, the edge is activated normally.

The cue component can stay on screen as a label, or retract to a minimal handle that doesn’t clog the screen or distract from the user’s primary task. Finally, and perhaps most interestingly, the cue can become an app indicator bar, reminder the user about which settings are currently selected.

How to cue

For many apps, the bottom edge is ideal for providing a simple, always-accessible way for users to compose a new item like a message, note or add to a list of things. A cue for this purpose can be as straight forward as a “Create New” text label that slides up when the app is loaded to remind users of the action, but then retracts neatly to either a simple handle, or altogether, as the user interacts with other parts of the application. The minimized cue can remain on top of the screen if desired, providing users with an unobtrusive but persistent cue.

Combination cue and indicators

2-camera_bottom_zoom

While a simple cue such as “create new” may be just right sometimes, but in some cases where settings or controls are located in the bottom edge, cues can work even harder, providing the user with an indicator bar of current setting. For example, in the camera app, the bottom edge cue shows the current flash setting and whether GPS tagging of photos is enabled. If the user triggers the bottom edge, controls for all of these settings are revealed.

Please and cues

Before you finalize your app design, think about how the bottom edge can help you deliver the most pleasing and effective user experience. Part of this plan should include the best use of the bottom edge cue, either as a label, a settings indicator, or both. Make it easy for users to discover what the bottom edge can do, and get more from your application.

Read more
jdstrand

Last time I discussed AppArmor, I talked about new features in Ubuntu 13.10 and a bit about ApplicationConfinement for Ubuntu Touch. With the release of Ubuntu 14.04 LTS, several improvements were made:

  • Mediation of signals
  • Mediation of ptrace
  • Various policy updates for 14.04, including new tunables, better support for XDG user directories, and Unity7 abstractions
  • Parser policy compilation performance improvements
  • Google Summer of Code (SUSE sponsored) python rewrite of the userspace tools

Signal and ptrace mediation

Prior to Ubuntu 14.04 LTS, a confined process could send signals to other processes (subject to DAC) and ptrace other processes (subject to DAC and YAMA). AppArmor on 14.04 LTS adds mediation of both signals and ptrace which brings important security improvements for all AppArmor confined applications, such as those in the Ubuntu AppStore and qemu/kvm machines as managed by libvirt and OpenStack.

When developing policy for signal and ptrace rules, it is important to remember that AppArmor does a cross check such that AppArmor verifies that:

  • the process sending the signal/performing the ptrace is allowed to send the signal to/ptrace the target process
  • the target process receiving the signal/being ptraced is allowed to receive the signal from/be ptraced by the sender process

Signal(7) permissions use the ‘signal’ rule with the ‘receive/send’ permissions governing signals. PTrace permissions use the ‘ptrace’ rule with the ‘trace/tracedby’ permissions governing ptrace(2) and the ‘read/readby’ permissions governing certain proc(5) filesystem accesses, kcmp(2), futexes (get_robust_list(2)) and perf trace events.

Consider the following denial:

Jun 6 21:39:09 localhost kernel: [221158.831933] type=1400 audit(1402083549.185:782): apparmor="DENIED" operation="ptrace" profile="foo" pid=29142 comm="cat" requested_mask="read" denied_mask="read" peer="unconfined"

This demonstrates that the ‘cat’ binary running under the ‘foo’ profile was unable to read the contents of a /proc entry (in my test, /proc/11300/environ). To allow this process to read /proc entries for unconfined processes, the following rule can be used:

ptrace (read) peer=unconfined,

If the receiving process was confined, the log entry would say ‘peer=”<profile name>”‘ and you would adjust the ‘peer=unconfined’ in the rule to match that in the log denial. In this case, because unconfined processes implicitly can be readby all other processes, we don’t need to specify the cross check rule. If the target process was confined, the profile for the target process would need a rule like this:

ptrace (readby) peer=foo,

Likewise for signal rules, consider this denial:

Jun 6 21:53:15 localhost kernel: [222005.216619] type=1400 audit(1402084395.937:897): apparmor="DENIED" operation="signal" profile="foo" pid=29069 comm="bash" requested_mask="send" denied_mask="send" signal=term peer="unconfined"

This shows that ‘bash’ running under the ‘foo’ profile tried to send the ‘term’ signal to an unconfined process (in my test, I used ‘kill 11300′) and was blocked. Signal rules use ‘read’ and ‘send to determine access, so we can add a rule like so to allow sending of the signal:

signal (send) set=("term") peer=unconfined,

Like with ptrace, a cross-check is performed with signal rules but implicit rules allow unconfined processes to send and receive signals. If pid 11300 were confined, you would adjust the ‘peer=’ in the rule of the foo profile to match the denial in the log, and then adjust the target profile to have something like:

signal (receive) set=("term") peer=foo,

Signal and ptrace rules are very flexible and the AppArmor base abstraction in Ubuntu 14.04 LTS has several rules to help make profiling and transitioning to the new mediation easier:

# Allow other processes to read our /proc entries, futexes, perf tracing and
# kcmp for now
ptrace (readby),
 
# Allow other processes to trace us by default (they will need
# 'trace' in the first place). Administrators can override
# with:
# deny ptrace (tracedby) ...
ptrace (tracedby),
 
# Allow unconfined processes to send us signals by default
signal (receive) peer=unconfined,
 
# Allow us to signal ourselves
signal peer=@{profile_name},
 
# Checking for PID existence is quite common so add it by default for now
signal (receive, send) set=("exists"),

Note the above uses the new ‘@{profile_name}’ AppArmor variable, which is particularly handy with ptrace and signal rules. See man 5 apparmor.d for more details and examples.

14.10

Work still remains and some of the things we’d like to do for 14.10 include:

  • Finishing mediation for non-networking forms of IPC (eg, abstract sockets). This will be done in time for the phone release.
  • Have services integrate with AppArmor and the upcoming trust-store to become trusted helpers (also for phone release)
  • Continue work on netowrking IPC (for 15.04)
  • Continue to work with the upstream kernel on kdbus
  • Work continued on LXC stacking and we hope to have stacked profiles within the current namespace for 14.10. Full support for stacked profiles where different host and container policy for the same binary at the same time should be ready by 15.04
  • Various fixes to the python userspace tools for remaining bugs. These will also be backported to 14.04 LTS

Until next time, enjoy!


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

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

Deciding how you’re going to handle responsive images is a big part of most responsive projects — also, one that usually causes many headaches!

We had really interesting discussions within the team to try to find out which options were out there, being used by other people, and whether those solutions could be useful (and possible) for us.

There is a range of solutions and opinions on this matter, but ultimately it’s all down to the content and types of images your website actually has to handle, and the technical and resource limitations of your team.

We tried to keep an open mind as to what would be possible to achieve within a very small timeframe: we wanted to find a solution that would work for our content, that would be achievable within our deadlines, and obviously, that would improve the experience of the visitors to our site.

Making an image inventory

Before discussing any potential solutions, it’s important to understand exactly what type of images are used on your site, how they are created, who creates them, how they are added to the site and in which locations, how the images play with the content and whether there are different levels of importance (UI icons, purely decorative images, infographics, editorial images, etc.).

You might realise you only use UI icons and vector illustrations, or that all your images are decorative and secondary, or even that all your images are photos commissioned to professional photographers and photojournalists that add great value to your content and designs. It’s only after doing this inventory that you’ll have sufficient information to decide what to do next and what your site needs.

On ubuntu.com there are five different types of image assets:

  • Pictograms: from an existing set of pre-approved pictograms, created in various formats, in a small subset of colours
  • Illustrations: usually created using two or more pictograms, or in a similar style, in vector format
  • Photography: these can be product shots of devices, screengrabs of our operating system and applications, and sometimes other types of photographic images
  • Logos: not only Ubuntu and Canonical’s own logos, but several partner logos
  • Backgrounds: these can be anything from dot patterns to textured backgrounds

Ubuntu image arsenalPictograms, illustrations, photography, logos and backgrounds are part of the image arsenal of ubuntu.com.

The pictograms and illustrations are always created in vector format and can easily be exported to an SVG. Similarly, many of the logos we use on the site can be sourced in an SVG format, but many times this isn’t possible. The photography and backgrounds used on the site, however, are usually provided to us in bitmap format, that lose definition when scaled up.

With this inventory in mind, we knew we’d have to come up with different solutions for the different types of assets rather than a single solution for all images.

Scalable vectors: pictograms, illustrations and logos

We investigated the possibility of creating a font for our icons and even started this process, but quickly decided that the lack of consistent browser support wasn’t acceptable.

The decision to move from GIF and PNG icons to SVG was relatively straightforward for us, as all our icons and pictograms are created in vector format from the outset. This would allow us to have crisp, scalable icons in most browsers, whether the device has a retina screen or not.

It was at this point that we thought it would be a good idea to finally introduce Modernizr into our toolset. With Modernizr we could target browsers that don’t support SVG and serve them with a PNG image replacement.

We did run into some browser support issues, mainly with Opera Mini which doesn’t support background-size (necessary if you’re scaling the same image asset instead of creating copies at different sizes) but does support SVG. To solve this problem, Ant wrote a JavaScript snippet that detects Opera Mini and adds the class .opera-mini to the body of the document. He will be covering this in more detail in a following post in this series.

Opera Mini rendering issuesOpera Mini’s SVG rendering issues.

We have explored the possibility of dynamically changing the colours of our SVG pictograms, but haven’t yet found a solution that is compatible across browsers — we’re open to suggestions!

Bitmap formats: photography and backgrounds

This is where things usually get trickier: how do you create a balance between serving users the best quality image they can get and saving their bandwidth?

Ideally, we’d have had the time to add the ability of images to be called on the fly in the size needed, so that the user didn’t have to download a size that was not intended for his or her screen size. This is something that we still want to work on, but just couldn’t justify to be added to the scope of this first iteration of the responsive transition.

Eventually we decided to use Imager.js — made by the BBC News developers — for responsive imaging in the markup. We chose this solution as it has simple syntax and is being used in production on high traffic websites, so it was proven to work. It seemed like a simple solution that fit our needs. In simple terms, the script runs through the page, looking up placeholder elements and replacing them with the closest available image size based on the width of the container.

CSS helper classes

We’ve created three CSS classes that can be used to hide/show images and other elements according to the size of the viewport:

  • .for-small: only shows in the smallest media query viewport
  • .for-medium: only shows in the small and medium media query viewports
  • .not-for-small: doesn’t show in the smallest media query viewport

These classes give us enough flexibility to decide which images should be visible based on our breakpoints in cases where we need more control. This means if we change the breakpoints, the classes will inherit the change.

File size

Initially we were planning on creating several versions of the images on the site, for small, medium and large screen sizes, but we found out that some of the current images on the site had a much larger file size than they needed to — for example, some transparent PNGs were being used when transparency was not a requirement.

With the limited time available, we opted for focusing on reducing file sizes as much as possible for existing images as a priority. This way, we’d make our pages smaller but small higher density screens would still see crisp images, since at smaller sizes they’d be reduced to about half their original size.

You can see a comparison of the file size per section of the site before and after this process.

Section Size before Ubuntu 14.04 LTS release (KB) Size after Ubuntu 14.04 LTS release (KB)
Homepage 434 193
About 1460 1787
Cloud 2809 2304
Desktop 3794 2571
Download 2921 3990
Management 991 1102
Partners 2243 2320
Phone 6943 2021
Server 1483 636
Support 679 480
Tablet 3318 1829
TV 603 733

We obtained these sizes using a combination of YSlow and PhantomJS.

Some of the sections were expanded for the Ubuntu 14.04 LTS release in April, which justifies some of the increases. The desktop, phone and tablet sections, however — the worst offenders — saw a significant reduction in file size, mainly from switching to the most appropriate file format instead of all PNGs.

Another way to create more consistency and file size savings across the site was the introduction of a pictogram and logo package. Instead of creating pictograms ad-hoc as needed, we now have a defined set of pictograms in a central location that can be reused across the site, in all its different colour variations. Because the pictograms and many of the logos are provided in an SVG format, they can be scaled to the size that is needed.

Ideas for the future

Despite the visible improvements, there are plenty of things we’d still like to explore in the way we handle images in a responsive world.

We are currently working on an asset server that will allow us to dynamically request different sizes and formats of assets (for example, SVG to PNG), which we can offset, crop, etc., right from the src property, also being far more cacheable with long expiry times. It will also make it easier to share assets, as they will be located at a permanent URL and will become findable through a database and metadata, which should encourage reuse.

These were the solutions we came up with and worked best with your timescales and resources. We’d love to hear how you’ve handled images in your responsive projects too, so let us know in the comments!

Read the next post in this series: “Making ubuntu.com responsive: updating font sizes and increasing readability”

Reading list

Read more
Prakash Advani

The company has pledged to invest $1 billion in open cloud products and services over the next two years, along with community-driven, open-source cloud technologies.

“Just as the community spread the adoption of Linux in the enterprise, we believe OpenStack will do the same for the cloud,” said Hewlett-Packard CEO and President Meg Whitman, in a webcast announcing Helion Tuesday.

Read More

Read more
David Murphy (schwuk)

This is really inspiring to me, on several levels: as an Ubuntu member, as a Canonical, and as a school governor.

Not only are they deploying Ubuntu and other open-source software to their students, they are encouraging those students to tinker with their laptops, and – better yet – some of those same students are directly involved in the development, distribution, and providing support for their peers. All of those students will take incredibly valuable experience with them into their future careers.

Well done.

Read more
Corey Bryant

Agenda

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

Minutes

  • vUDS is next week (Tues-Thurs) – Pat (gaughen) is still working on topics, so if someone has a suggestion please talk to her.
  • bug 1319555 should not be on the list – list needs refreshing
  • bug 1315052 has fix committed upstream
  • bug 1317587 is in progress
  • The team is working on getting the blueprints filled out completely.  Expecting them to be solidified around vUDS.
  • Louis (caribou) created blueprint: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-u-networked-kdump and working on getting it filled in and approved.
  • kdump may be added to vUDS agenda
  • There’s an Openstack meetup in London on Thursday – James (jamespage) and Liam (gnuoy) are attending.  http://www.eventbooking.uk.com/openstack/home.html

Next Meeting

Next meeting will be on Tuesday, June 10th at 16:00 UTC in #ubuntu-meeting.

Additional logs @ https://wiki.ubuntu.com/MeetingLogs/Server/20140603

Read more
facundo

Malta


La semana pasada estuve de sprint, esta vez en un destino al que no había ido nunca. Malta. Siempre que lo menciono, todo me preguntan donde está Malta (yo tampoco sabía)... bueno, está acá:

Mapa de Malta

Es una isla principal, con un par de islas pequeñas alrededor... parece chica, pero tiene casi medio millón de habitantes, y sorprendentemente la más alta densidad de población de Europa [-].

No pude pasear demasiado y conocer, lamentablemente, porque el domingo llegué tarde y el sábado me fui temprano... y durante la semana trabajé un montón. Muchos de mis compañeros llegaron un día antes y se fueron un día después, pero yo no elegí eso. En parte porque eran dos días más que estaba lejos de casa, extrañando, en parte porque le complicaba la vida a Moni dos días más de la semana.

La ciudad es rara. Tiene algo de pintoresco, pero también de decadente. Hay edificios muy lindos, y hay otros que son directamente feos. Que el 90% de las construcciones estén hechas con la misma piedra local le da a todo un tono peculiar.

Edificios

Aunque es una isla, y algunas playitas de arena tiene, la mayoría de la costa es rocosa. Obvio, igual la gente toma sol, nada, disfruta del mar, etc. Algo que nos llamó mucho la atención fueron unas piletas cavadas en las rocas de la playa... algo así como saunas naturales...

Piletas en la costa

Todas las fotos acá.

Read more
David Planella

As part of the Ubuntu App Developer Week, I just ran a live on-air session on how to internationalize your Ubuntu apps. Some of the participants on the live chat asked me if I could share the slides somewhere online.

So here they are for your viewing pleasure :) If you’ve got any questions on i18n or in Ubuntu app development in general, feel free to ask in the comments or ping me (dpm) on IRC.

The video

The slides

Enjoy!

The post Internationalizing your apps at the Ubuntu App Developer Week appeared first on David Planella.

Read more
Martin Albisetti

As previously announced, the file services for Ubuntu One will be discontinued starting today.
In order to make it easier for you to move your content away, we have rolled out a new feature that lets you download all your content with just one click.
As a reminder, on July 31st 2014, all content in the file services will be deleted.

Just log into our website, and you will see the button placed prominently on the page:

u1-shutdown

 

For those looking for another Cloud storage option we’ve talked to a number of companies that wanted to tell Ubuntu One users about their services.

Mover.io

Mover is a web service that helps you migrate and backup files between cloud storage providers. The Mover team tells us they process more than two billion files each month, so that users can migrate files of all shapes and sizes, from a personal photo collection, to all of a workgroups files.

With Mover you can transfer files between services such as Dropbox, Box, Google Drive, Amazon S3 and a range of others.

Mover is helping U1 users to move transfer files for free. Simply create a Mover account and any transfers made in or out of the U1 connector will be free.

To find out more about their service see the blog post.

SpiderOak

SpiderOak is a cloud file service that is similar to Ubuntu One with all files stored in the Cloud. They have a ‘Zero-Knowledge’ privacy environment that provides end-to-end encryption to ensure you – and only you – can view your data. The SpiderOak team tell us they’ve been natively supported Linux from the start in 2007.

SpiderOak is offering two special deals for Ubuntu One customers:

  • 20 GB for $24.99/year

  • 40 GB for for $29.99/year

To take advantage of one of these offers use the Promotion Code LongLiveUbuntu. The steps are:

1. Click here to create your account.
2. Download and install the client.
3. Click  ‘Buy More Space’ in the client itself, or via the web portal (which you can only access once you’ve downloaded the client). In the web portal, you will go to Account, and then choose Upgrade My Plan.
4. Choose YEARLY and enter the following promotion code: LongLiveUbuntu. (NOTE: You MUST type in the promotion code as it will not work if you cut & paste.)
5. Congratulations – SpiderOak now has your back(up)!

For some more information on SpiderOak’s Linux support see their blog post.

 

ownCloud

ownCloud is an Open Source managed file sync and sharing software that you install on your own servers. It’s a great option for those that want the Cloud storage capability but would like to control where the files are stored. The ownCloud team told us that their Community version is well supported under Ubuntu and they also support Windows and Mac desktop machines, while on the mobile side there are clients for Android and iPhone/iPad. For those that need advanced enterprises capabilities there’s also a commercial version that adds those features.

You can read about how to install ownCloud Server and the Desktop clients here.

 

Refunds and Support

For those of you who have been paying customers, we have started processing refunds, and you should see it reflected in your credit cards or Paypal accounts within the next 7-10 days.

 

Read more
Joseph Salisbury

Meeting Minutes

IRC Log of the meeting.

Meeting minutes.

Agenda

20140603 Meeting Agenda


ARM Status

No new update this week.


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


Milestone Targeted Work Items

   apw    core-1405-kernel    2 work items   
   ogasawara    core-1405-kernel    2 work items   


Status: Utopic Development Kernel

We have most recently rebased our Utopic kernel to v3.15-rc8 and
uploaded (3.15.0-5.10). We are planning on converging on the v3.16
kernel for Utopic. It also appears that the Utopic release date has
been pushed out a week to Thurs Oct 23 in order to not conflict with
the Linux Plumbers Conference.
—–
Important upcoming dates:
Mon-Wed June 10 – 12, UOS – Ubuntu Online Summit (~1 week away)
Thurs Jun 26 – Alpha 1 (~3 weeks away)
Fri Jun 27 – Kernel Freeze for 12.04.5 and 14.04.1 (~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 – Trusty/Saucy/Precise/Lucid

Status for the main kernels, until today (June 3):

  • Lucid – Verification and Testing
  • Precise – Verification and Testing
  • Quantal – No changes this cycle
  • Saucy – Verification and Testing
  • Trusty – Verification and Testing

    Current opened tracking bugs details:

  • http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html

    For SRUs, SRU report is a good source of information:

  • http://people.canonical.com/~kernel/reports/sru-report.html

    Schedule:

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


Open Discussion or Questions? Raise your hand to be recognized

No open discussions.

Read more
David Planella

A sample of the wider Ubuntu Community team, with Canonicalers and volunteer core app developers

A sample of the wider Ubuntu Community team, with Canonicalers and volunteer core app developers

After the recent news of Jono stepping down as the Ubuntu Community Manager to seek new challenges at XPRIZE, a new era in Ubuntu begins. Jono’s leadership, passion and drive to continually push the boundaries have been contagious over the years, and have been the catalyst for growing the unique community of individuals that defines Ubuntu today.

Jono is now joining the ranks of non-Canonical Ubuntu members, and while this will change the angle of participation, I’m certain that it won’t change his energy and dedication one bit. But most importantly, it’s a testament to his work that his former team will continue to thrive and take up the torch in pushing those boundaries.

For us, it will be business as usual in the sense of implementing our roadmap, continuing to grow a strong and open community, being innovative in how we do it, and coordinating the logistics around our plans. So not much will be different in that regard, but obviously some organizational bits will change.

As part of the transition, the Ubuntu Community Team at Canonical in full, that is, Michael Hall, Daniel Holbach, Alan Pope, Nicholas Skaggs and myself, will now be hosting the weekly Ubuntu Q&A, starting today at 18:00 UTC on Ubuntu On Air (click here for the time at your location).

The Ubuntu Community Team Q&A

Openness, both in being a transparent and welcoming community, is one of the core values of Ubuntu, and we believe the channels should be always open for a healthy information flow and to help contributors get involved.

As such, the Ubuntu Community Team Q&A will continue to provide a weekly, 1-hour-long session open for participation to anyone who wants to ask their questions about Ubuntu. In fact, as in former editions, you can ask the Community Team just anything about Free Software, Technology, or whatever you come up with. As before, the only questions we won’t answer are those related to technical support, where you’ll be much better served using Ask Ubuntu, the Ubuntu forums or IRC.

Join the Ubuntu Community Team Q&A at 18:00 UTC today and ask your questions >

The Ubuntu Online Summit is coming soon!

Also, following the thread of events and participation, the new Ubuntu Online Summit (UOS) is coming up very soon, and it’s an excellent opportunity to learn about getting involved in Ubuntu, organizing or presenting the plans of the different Ubuntu teams for the next months.

UOS will be held on June 10th – 12th and it will be a combination of the former Ubuntu Developer Summit and the more user-facing events we’ve been organizing in the past. This opens the door to a wider audience that can follow a richer mix of developer and user or contributor content.

If you want to learn about the details, check out Michael’s UOS post on how it’s going to work. If you want to contribute and make a difference in Ubuntu, do register a session too!

Looking forward to seeing you soon!

The post A new era for the Ubuntu community team, or business as usual appeared first on David Planella.

Read more
Nicholas Skaggs

Calling for your UOS users session!

Ubuntu Online Summit is approaching, happening on June 10th-12th.This time it's a bit different from how vUDS has been in the past. Rather than the narrower developer focus, this intends to be a full blown community summit. If you've attending things like ubuntu open week or a classroom session in the past, all of those types of sessions are welcome and encouraged too.

To help foster these types of sessions, there is a special Users track.

"The focus of the Users track is to highlight ways to get the most out of Ubuntu, on your laptop, your phone or your server. From detailed how-to sessions, to tips and tricks, and more, this track can provide something for everybody, regardless of skill level."

Track Leads:
Elizabeth Krumbach Joseph
Nicholas Skaggs
Valorie Zimmerman

I'm excitied to be a track lead for this track along with Liz and Val. We are all inviting you to consider scheduling a session to share your knowledge of ubuntu. Share an idea, discuss your passion, give a how-to, etc. The sessions in this track are meant for other users of ubuntu like yourself, so feel free to share.

Regardless of your desire to contribute a session, I would encourage everyone to take a look at the schedule as it evolves and considering joining in sessions they find interesting.
.
Remember, this track is your track and filled with your sessions. Let's help make the online summit a success.

So ready to propose a session? Checkout this page and feel free to ping Val, Liz or myself for help. Don't forget to register to attend and check out the currently scheduled sessions!

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

One of the biggest challenges when making the move to responsive was tackling the navigation in ubuntu.com. This included rethinking not only the main navigation with first, second and third level links, but also a big 3-tier footer and global navigation.

Navigation in large screens

Footer in large screensDesktop size main navigation and footer on ubuntu.com.

1. Brainstorming

Instead of assigning this task to a single UX designer, and with the availability of everyone in the team very tight, we gathered two designers and two UX designers in a room for a few hours for an intensive brainstorming session. The goal of the meeting was to find an initial solution for how our navigation could work in small screens.

We started by analysing examples of small screen navigation from other sites and discussing how they could work (or not) for ubuntu.com. This was a good way of generating ideas to solve the navigation for our specific case.

Guardian, BBC, John Lewis navigationSome of the small screen navigation examples we analysed, from left to right: the Guardian, BBC and John Lewis.

We decided to keep to existing common design patterns for small screen navigation rather than trying to think of original solutions, so we stuck with the typical menu icon on the top right with a dropdown on click for the top level links.

Settling on a solution for second and third level navigation was trickier, as we wanted to keep a balance between exposing our content and making the site easy to navigate without the menus getting in the way.

We thought keeping to simple patterns would make it easier for users to understand the mechanics of the navigation quickly, and assumed that in smaller screens users tend to forgive extra clicks if that means simpler and uncluttered navigation.

SketchesSome of the ideas we sketched during the brainstorming session.

2. Prototyping

With little time on our hands, we decided we’d deliver our solution in paper sketches for a prototype to be created by our developers. The starting point for the styling of the navigation should follow closely that of Ubuntu Insights, and the remaining tweaks should be built and designed directly in code.

Ubuntu Insights navigationNavigation of Ubuntu Insights on large and small screens.

We briefed Ant with the sketches and some design and UX direction and he quickly built a prototype of the main navigation and footer for us to test and further improve.

Initial navigation prototypeFirst navigation prototype.

3. Improving

We gathered again to test and review the prototype once it was ready, and suggest improvements.

Everyone agreed that the mechanics of the navigation were right, and that visual tweaks could make it easier to understand, providing the user with more cues about the hierarchy of the content.

Initially, when scaling down the screen the search and navigation overlapped a small amount before the small screen menu icon kicked in, so we also thought it would be nice to animate the change of the amount of padding between widths.

We also made sure that if JavaScript is not available, when the user clicks on the menu icon the page scrolls down to the footer, where the navigation is accessible.

Final navigation prototypeFinal navigation prototype, after some tweaks.

Some final thoughts

When time is of essence, but you still want to be able to experiment and generate as many ideas as possible, spending a couple of hours in a room with other team members, talking through case studies and how they can be applied to your situation proved a really useful and quick way to advance the project. And time and time again, it has proved very useful to invite people who are not directly involved with the project to give the team valuable new ideas and insights.

We’re now planning to test the navigation in our next quarterly set of usability testing, which will surely provide us with useful feedback to make the website easier to navigate across all screen sizes.

Read the next post in this series: “Making ubuntu.com responsive: dealing with responsive images”

Reading list

Read more
mark

This is a series of posts on reasons to choose Ubuntu for your public or private cloud work & play.

We run an extensive program to identify issues and features that make a difference to cloud users. One result of that program is that we pioneered dynamic image customisation and wrote cloud-init. I’ll tell the story of cloud-init as an illustration of the focus the Ubuntu team has on making your devops experience fantastic on any given cloud.

 

Ever struggled to find the “right” image to use on your favourite cloud? Ever wondered how you can tell if an image is safe to use, what keyloggers or other nasties might be installed? We set out to solve that problem a few years ago and the resulting code, cloud-init, is one of the more visible pieces Canonical designed and built, and very widely adopted.

Traditionally, people used image snapshots to build a portfolio of useful base images. You’d start with a bare OS, add some software and configuration, then snapshot the filesystem. You could use those snapshots to power up fresh images any time you need more machines “like this one”. And that process works pretty amazingly well. There are hundreds of thousands, perhaps millions, of such image snapshots scattered around the clouds today. It’s fantastic. Images for every possible occasion! It’s a disaster. Images with every possible type of problem.

The core issue is that an image is a giant binary blob that is virtually impossible to audit. Since it’s a snapshot of an image that was running, and to which anything might have been done, you will need to look in every nook and cranny to see if there is a potential problem. Can you afford to verify that every binary is unmodified? That every configuration file and every startup script is safe? No, you can’t. And for that reason, that whole catalogue of potential is a catalogue of potential risk. If you wanted to gather useful data sneakily, all you’d have to do is put up an image that advertises itself as being good for a particular purpose and convince people to run it.

There are other issues, even if you create the images yourself. Each image slowly gets out of date with regard to security updates. When you fire it up, you need to apply all the updates since the image was created, if you want a secure machine. Eventually, you’ll want to re-snapshot for a more up-to-date image. That requires administration overhead and coordination, most people don’t do it.

That’s why we created cloud-init. When your virtual machine boots, cloud-init is run very early. It looks out for some information you send to the cloud along with the instruction to start a new machine, and it customises your machine at boot time. When you combine cloud-init with the regular fresh Ubuntu images we publish (roughly every two weeks for regular updates, and whenever a security update is published), you have a very clean and elegant way to get fresh images that do whatever you want. You design your image as a script which customises the vanilla, base image. And then you use cloud-init to run that script against a pristine, known-good standard image of Ubuntu. Et voila! You now have purpose-designed images of your own on demand, always built on a fresh, secure, trusted base image.

Auditing your cloud infrastructure is now straightforward, because you have the DNA of that image in your script. This is devops thinking, turning repetitive manual processes (hacking and snapshotting) into code that can be shared and audited and improved. Your infrastructure DNA should live in a version control system that requires signed commits, so you know everything that has been done to get you where you are today. And all of that is enabled by cloud-init. And if you want to go one level deeper, check out Juju, which provides you with off-the-shelf scripts to customise and optimise that base image for hundreds of common workloads.

Read more
Michael Hall

Last year the main Ubuntu download page was changed to include a form for users to make a donation to one or more parts of Ubuntu, including to the community itself. Those donations made for “Community projects” were made available to members of our community who knew of ways to use them that would benefit the Ubuntu project.

Every dollar given out is an investment in Ubuntu and the community that built it. This includes sponsoring community events, sending community representatives to those events with booth supplies and giveaway items, purchasing hardware to make improve development and testing, and more.

But these expenses don’t cover the time, energy, and talent that went along with them, without which the money itself would have been wasted.  Those contributions, made by the recipients of these funds, can’t be adequately documented in a financial report, so thank you to everybody who received funding for their significant and sustained contributions to Ubuntu.

As part of our commitment to openness and transparency we said that we would publish a report highlighting both the amount of donations made to this category, and how and where that money was being used. Linked below is the first of those reports.

View the Report

Read more
Inayaili de León Persson

This post is part of the series ‘Making ubuntu.com responsive‘.

A big part of converting our existing fixed-width desktop site to be responsive was to make sure we had a flexible grid that would flow seamlessly from small to large screens.

From the start, we decided that we were going to approach the move as simply as possible: we wanted the content our grid holds to become easier to read and browse on any screen size, but that doesn’t necessarily mean creating anything too complex.

Our existing fixed-width grid

Before the transition, our grid consisted of 12 columns with 20px gutters.

The width of each column could be variable, but we were working with 57px columns and 40px padding on each side of the main content container.

GridOur existing fixed-width desktop grid.

Inside that grid, content can be divided into one, two, three or four columns. In extreme cases, we can also use five columns, but we avoid this.

Grid overlaidOur grid laid over an existing page of the site.

We also try keeping text content below eight columns, as it becomes harder to read otherwise.

Adding flexibility

When we first created our web style guide, we decided that, since we were getting our hands dirty with the refactoring of the CSS, we’d go ahead and convert our grid to use percentages instead of pixels.

The idea was that it would be useful for the future, while keeping everything looking almost exactly the same, since the content would still be all held within a fixed-width container for the time being.

Using percentagesA fixed-width container holding percentage-based columns.

This proved one of the best decisions we made and it made the transition to responsive much smoother than we initially thought.

The CSS

We used Gridinator to initially create our basic grid, removed any unnecessary rules and properties from the CSS it generated and added others we needed.

The settings we’ve input, in case you’re wondering, were:

  • Number of columns: 12
  • Column width: 57px
  • Column margins: 20px (technically, the gutters)
  • Container margin: 40px
  • Body font size: 16px
  • Option: percentage units

Gridinator settingsScreenshot of our Gridinator settings.

We could have created this CSS from scratch, but we found this tool saved us some precious time when creating all the variations we needed when using the grid.

You can have a peek into our current grid stylesheet now.

First prototypes

The first two steps we took when creating the initial responsive prototype of ubuntu.com were:

  • Remove the fixed-width container and see how the content would flow freely and fluidly
  • Remove all the floats and positioning rules from the existing CSS and see how the content would flow in a linear manner, and test this on small screen devices

When we removed the fixed-width container, all the content became fluid. Obviously, there were no media queries behind this, so the content was free to grow to huge sizes, with really long line lengths, and equally the columns could shrink to unreasonably narrow sizes. But it was fluid, and we were happy!

Similarly, when checking the float-free prototype, even though there were quite a few issues with background images and custom, absolutely positioned elements, the results were promising.

Float free prototypeOur first float-free prototype: some issues but overall a good try.

These tests showed to us that, even though the bulk of the work was still ahead of us, a lot had been accomplished by simply making the effort to convert our initial pixel-based columns into percentage based ones. This is a test that we think other teams could be able to do, before moving on to a complete revamp of their CSS.

Defining breakpoints

We didn’t want to relate our breakpoints to specific devices, but it was important that we understood what kind of screen sizes people were using to visit our site on.

To give you an idea, here are the top 10 screen sizes (not window size, mind) between 4 March and 3 April 2014, in pixels, on ubuntu.com:

  1. 1366 x 768: 26.15%
  2. 1920 x 1028: 15.4%
  3. 1280 x 800: 7.98%
  4. 1280 x 1024: 7.26%
  5. 1440 x 900: 6.29%
  6. 1024 x 768: 6.26%
  7. 1600 x 900: 5.51%
  8. 1680 x 1050: 4.94%
  9. 1920 x 1200: 2.73%
  10. 1024 x 600: 2.12%

The first small screen (360×640) comes up at number 17 in the list, followed by 320×568 and 320×480 at numbers 21 and 22, respectively.

We decided to test the common approach and try breakpoints at:

  • Under 768px: small screen styles
  • Between 768px and under 986px: medium screen styles
  • 986px and up: large screen styles

This worked well for our content and was in line with what we had seen in our analytics numbers.

At the small screen breakpoint we have:

  • Reduced typographic scale
  • Reduced margins and padding
  • Reduced main content container padding

At this scale, following what we had done in Ubuntu Resources (now Ubuntu Insights), we reused the grid from the Ubuntu phone designs, which divides the portrait screen into 40 squares, horizontally.

Phone gridThe phone grid.

At the medium screen breakpoint we have:

  • Increased (from small screen) typographic scale
  • Increased margins and padding
  • Increased main content container padding

At the large screen break point we have:

  • The original typographic scale
  • The original margins and padding
  • The original main content container padding

Small, medium and large screen spacingComparison between small, medium and large screen spacing.

Ideas for the future

In the future, we would like to use more component-specific breakpoints. Some of our design components would work better if they reflowed or resized at different points than the rest of the site, so more granular control over specific elements would be useful. This usually depends on the type and amount of content the component holds.

What about you? We’d love to know how other people have tackled this issue, and what suggestions you have to create flexible and robust grids. Have you used any useful tools or techniques? Let us know in the comments section.

Read the next post in this series: “Making ubuntu.com responsive: adapting our navigation to small screens”

Reading list

Read more
David Planella

Ubuntu emulator guide

Following the initial announcement, the Ubuntu emulator is going to become a primary Engineering platform for development. Quoting Alexander Sack, when ready, the goal is to

[...] start using the emulator for everything you usually would do on the phone. We really want to make the emulator a class A engineering platform for everyone

While the final emulator is still work in progress, we’re continually seeing the improvements in finishing all the pieces to make it a first-class citizen for development, both for the platform itself and for app developers. However, as it stands today, the emulator is already functional, so I’ve decided to prepare a quickstart guide to highlight the great work the Foundations and Phonedations teams (along with many other contributors) are producing to make it possible.

While you should consider this as guide as a preview, you can already use it to start getting familiar with the emulator for testing, platform development and writing apps.

Requirements

To install and run the Ubuntu emulator, you will need:

  • Ubuntu 14.04 or later (see installation notes for older versions)
  • 512MB of RAM dedicated to the emulator
  • 4GB of disk space
  • OpenGL-capable desktop drivers (most graphics drivers/cards are)

Installing the emulator

If you are using Ubuntu 14.04, installation is as easy as opening a terminal, pressing Ctrl+Alt+T and running these commands, followed by Enter:

sudo add-apt-repository ppa:ubuntu-sdk-team/ppa && sudo apt-get update
sudo apt-get install ubuntu-emulator

Alternatively, if you are running an older stable release such as Ubuntu 12.04, you can install the emulator by manually downloading its packages first:

Show me how

  1. Create a folder named MARKDOWN_HASHb3eeabb8ee11c2be770b684d95219ecbMARKDOWN_HASH in your home directory
  2. Go to the goget-ubuntu-touch packages page in Launchpad
  3. Scroll down to Trusty Tahr and click on the arrow to the left to expand it
  4. Scroll further to the bottom of the page and click on the MARKDOWN_HASH05556613978ce6821766bb234e2ff0f2MARKDOWN_HASH package corresponding to your architecture (i386 or amd64) to download in the MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder you created
  5. Now go to the Android packages page in Launchpad
  6. Scroll down to Trusty Tahr and click on the arrow to the left to expand it
  7. Scroll further to the bottom of the page and click on the MARKDOWN_HASH1843750ed619186a2ce7bdabba6f8062MARKDOWN_HASH package corresponding to download it at the same MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder
  8. Open a terminal with Ctrl+Alt+T
  9. Change the directory to the location where you downloaded the package writing the following command in the terminal: MARKDOWN_HASH8844018ed0ccc8c506d6aff82c62c46fMARKDOWN_HASH
  10. Then run this command to install the packages: MARKDOWN_HASH0452d2d16235c62b87fd735e6496c661MARKDOWN_HASH
  11. Once the installation is successful you can close the terminal and remove the MARKDOWN_HASH1e681dc9c2bfe6538971553668079349MARKDOWN_HASH folder and its contents

Installation notes

  • Downloaded images are cached at ~/.cache/ubuntuimage –using the standard XDG_CACHE_DIR location.
  • Instances are stored at ~/.local/share/ubuntu-emulator –using the standard XDG_DATA_DIR location.
  • While an image upgrade feature is in the works, for now you can simply create an instance of a newer image over the previous one.

Running the emulator

Ubuntu emulator guide

The ubuntu-emulator tool makes it again really easy to manage instances and run the emulator. Typically, you’ll be opening a terminal and running these commands the first time you create an instance (where myinstance is the name you’ve chosen for it):

sudo ubuntu-emulator create myinstance --arch=i386
ubuntu-emulator run myinstance

You can create any instances you need for different purposes. And once the instance has been created, you’ll be generally using the ubuntu-emulator run myinstance command to start an emulator session based on that instance.

Notice how in the command above the --arch parameter was specified to override the default architecture (armhf). Using the i386 arch will make the emulator run at a (much faster) native speed.

Other parameters you might want to experiment with are also: --scale=0.7 and --memory=720. In these examples, we’re scaling down the UI to be 70% of the original size (useful for smaller screens) and specifying a maximum of 720MB for the emulator to use (on systems with memory to spare).

There are 3 main elements you’ll be interacting with when running the emulator:

  • The phone UI – this is the visual part of the emulator, where you can interact with the UI in the same way you’d do it with a phone. You can use your mouse to simulate taps and slides. Bonus points if you can recognize the phone model where the UI is in ;)
  • The remote session on the terminal – upon starting the emulator, a terminal will also be launched alongside. Use the phablet username and the same password to log in to an interactive ADB session on the emulator. You can also launch other terminal sessions using other communication protocols –see the link at the end of this guide for more details.
  • The ubuntu-emulator tool – with this CLI tool, you can manage the lifetime and runtime of Ubuntu images. Common subcommands of ubuntu-emulator include create (to create new instances), destroy (to destroy existing instances), run (as we’ve already seen, to run instances), snapshot (to create and restore snapshots of a given point in time) and more. Use ubuntu-emulator --help to learn about these commands and ubuntu-emulator command --help to learn more about a particular command and its options.

Runtime notes

  • Make sure you’ve got enough space to install the emulator and create new instances, otherwise the operation will fail (or take a long time) without warning.
  • At this time, the emulator takes a while to load for the first time. During that time, you’ll see a black screen inside the phone skin. Just wait a bit until it’s finished loading and the welcome screen appears.
  • By default the latest built image from the devel-proposed channel is used. This can be changed during creation with the --channel and --revision options.
  • If your host has a network connection, the emulator will use that transparently, even though the network indicator might show otherwise.
  • To talk to the emulator, you can use standard adb. The emulator should appear under the list of the adb devices command.

Learn more and contribute

I hope this guide has whetted your appetite to start testing the emulator! You can also contribute making the emulator a first-class target for Ubuntu development. The easiest way is to install it and give it ago. If something is not working you can then file a bug.

If you want to fix a bug yourself or contribute to code, the best thing is to ask the developers about how to get started by subscribing to the Ubuntu phone mailing list.

If you want to learn more about the emulator, including how to create instance snapshots and other cool features, head out to the Ubuntu Emulator wiki page.

And next… support for the tablet form factor and SDK integration. Can’t wait for those features to land!

The post A quickstart guide to the Ubuntu emulator appeared first on David Planella.

Read more
Michael Hall

A couple of months ago Jono announced the dates for the Ubuntu Online Summit, June 10th – 12th,  and those dates are almost upon us now.  The schedule is opened, the track leads are on board, all we need now are sessions.  And that’s where you come in.

Ubuntu Online Summit is a change for us, we’re trying to mix the previous online UDS events with our Open Week, Developer Week and User Days events, to try and bring people from every part of our community together to celebrate, educate, and improve Ubuntu. So in addition to the usual planning sessions we had at UDS, we’re also looking for presentations from our various community teams on the work they do, walk-throughs for new users learning how to use Ubuntu, as well as instructional sessions to help new distro developers, app developers, and cloud devops get the most out of it as a platform.

What we need from you are sessions.  It’s open to anybody, on any topic, anyway you want to do it.  The only requirement is that you can start and run a Google+ OnAir Hangout, since those are what provide the live video streaming and recording for the event.  There are two ways you can propose a session: the first is to register a Blueprint in Launchpad, this is good for planning session that will result in work items, the second is to propose a session directly in Summit, which is good for any kind of session.  Instructions for how to do both are available on the UDS Website.

There will be Track Leads available to help you get your session on the schedule, and provide some technical support if you have trouble getting your session’s hangout setup. When you propose your session (or create your Blueprint), try to pick the most appropriate track for it, that will help it get approved and scheduled faster.

Ubuntu Development

Many of the development-oriented tracks from UDS have been rolled into the Ubuntu Development track. So anything that would previously have been in Client, Core/Foundations or Cloud and Server will be in this one track now. The track leads come from all parts of Ubuntu development, so whatever you session’s topic there will be a lead there who will be familiar with it.

Track Leads:

  • ?ukasz Zemczak
  • Steve Langasek
  • Leann Ogasawara
  • Antonio Rosales
  • Marc Deslaurs

Application Development

Introduced a few cycles back, the Application Development track will continue to have a focus on improving the Ubuntu SDK, tools and documentation we provide for app developers.  We also want to introduce sessions focused on teaching app development using the SDK, the various platform services available, as well as taking a deeper dive into specifics parts of the Ubuntu UI Toolkit.

Track Leads:

  • Michael Hall
  • David Planella
  • Alan Pope
  • Zsombor Egri
  • Nekhelesh Ramananthan

Cloud DevOps

This is the counterpart of the Application Development track for those with an interest in the cloud.  This track will have a dual focus on planning improvements to the DevOps tools like Juju, as well as bringing DevOps up to speed with how to use them in their own cloud deployments.  Learn how to write charms, create bundles, and manage everything in a variety of public and private clouds.

Track Leads:

  • Jorge Castro
  • Marco Ceppi
  • Patricia Gaughen
  • Jose Antonio Rey

Community

The community track has been a stable of UDS for as long as I can remember, and it’s still here in the Ubuntu Online Summit.  However, just like the other tracks, we’re looking beyond just planning ways to improve the community structure and processes.  This time we also want to have sessions showing users how they can get involved in the Ubuntu community, what teams are available, and what tools they can use in the process.

Track Leads:

  • Daniel Holbach
  • Jose Antonio Rey
  • Laura Czajkowski
  • Svetlana Belkin
  • Pablo Rubianes

Users

This is a new track and one I’m very excited about. We are all users of Ubuntu, and whether we’ve been using it for a month or a decade, there are still things we can all learn about it. The focus of the Users track is to highlight ways to get the most out of Ubuntu, on your laptop, your phone or your server.  From detailed how-to sessions, to tips and tricks, and more, this track can provide something for everybody, regardless of skill level.

Track Leads:

  • Elizabeth Krumbach Joseph
  • Nicholas Skaggs
  • Valorie Zimmerman

So once again, it’s time to get those sessions in.  Visit this page to learn how, then start thinking of what you want to talk about during those three days.  Help the track leads out by finding more people to propose more sessions, and let’s get that schedule filled out. I look forward to seeing you all at our first ever Ubuntu Online Summit.

Read more
Antonio Rosales

Meeting Minutes: May 20th

Agenda

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

Minutes

Pretty straightforward meeting given 14.04 release is still pretty fresh in our minds, and ODS was last week. Great Demo at UDS! Utopic Unicorn is underway way (https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule) the first Alpha release scheduled for June 26th, and vUDS on June 12th. Server team blueprints are also in progress with the topic blueprint (https://blueprints.launchpad.net/ubuntu/+spec/topic-u-server_ already created and dependencies being posted to it.

The Bugs we covered were:

  • Launchpad bug 1319555 in ec2-api-tools (Ubuntu Utopic) “update out-dated ec2-api-tools for 12.04″ [High,New]
  • Launchpad bug 1315052 in lxc (Ubuntu Utopic) “lxc-attach from a different login session fails” [High,Triaged]
  • Launchpad bug 1317587 in clamav (Ubuntu Utopic) “ClamAV 0.98.1 is Outdated” [High,In progress]
  • Launchpad bug 1317811 in linux (Ubuntu) “Dropped packets on EC2, “xen_netfront: xennet: skb rides the rocket: x slots”” [Medium,In progress]

Next Meeting

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

Additional logs @ https://wiki.ubuntu.com/MeetingLogs/Server/20140520

Read more