Department of Chemistry

...California State University Stanislaus

  • Increase font size
  • Default font size
  • Decrease font size
Home News Feeds Planet Ubuntu
Newsfeeds
Planet Ubuntu
Planet Ubuntu - http://planet.ubuntu.com/

  • Ian Weisser: You should be using Find-a-Task
    Find-a-Task is the Ubuntu community's job board for volunteers.

    Introduced in January 2015, Find-a-Task shows fellow volunteers the variety of tasks and roles available.

    The goal of Find-a-Task is for a volunteer, after exploring the Ubuntu Project, to land on a team or project's wiki page. They are interested, ready to join, and ready to start learning the skills and tools. 

    However, it only works if *you* use it, too.


    Try it.


    Take a quick look, and see the variety of volunteer roles available. We have listings for many different skills and interests, including many non-technical tasks.


    Is your team listed?


    Hey teams, are you using Find-a-Task to recruit volunteers?
    • Are your team roles listed?
    • Are they accurate?
    • Is your landing page welcoming and useful to a new volunteer?

    When it's time to update your postings on the job board, simply jump into Freenode IRC: #ubuntu-community-team.


    Gurus: Are your pointing Padwans toward it?


    Find-a-Task is a great place to send new enthusiasts. No signup, no login, no questions. It's a great way to survey the roles available in the big, wide, Ubuntuverse, and get new enthusiasts involved in a team.

    It's also handy for experienced enthusiasts looking for a new challenge, of course.
    • If you're active in the various forums, refer new enthusiasts to Find-a-Task.
    • Add it to your signature.
    • If you know a Find-a-Task success story, please share.

    Improving Find-a-Task


    Ideas to increase usage of Find-a-Task are welcome.
    Ideas on how to improve the tool itself are also welcome.
    Please share your suggestions to improve Find-a-Task on the ubuntu-community-team mailing list.



  • Jonathan Riddell: Jonathan Riddell™ IP Policy

    This is the Jonathan Riddell™ IP Policy.  It applies to all Jonathan’s intellectual property in Ubuntu archives.  Jonathan is one of the top 5 uploaders, usually the top 1 uploader, to Ubuntu compiling hundreds of packages in the Ubuntu archive.  Further Jonathan reviews new and updated packages in the archive.  Further Jonathan selects compiler defaults and settings for KDE and Qt and other packages in the Ubuntu archive.  Further Jonathan builds and runs tests for Ubuntu packages in the archives.  Further Jonathan Riddell™ is a trademark of Jonathan Riddell™in Scotland, Catalunya and other countries; a trademark which is included in all packages edited by Jonathan Riddell™.  Further Jonathan is the author of numberous works in the Ubuntu archive.  Further Jonathan is the main contributor to the selection of software in Kubuntu. Therefore Jonathan has IP in the Ubuntu archive possibly including but not limited to copyright, patents, trademarks, sales marks, geographical indicators, database rights, compilation copyright, designs, personality rights and plant breeders rights.  To deal with, distribute, modify, look at or smell Jonathan’s IP you must comply with this policy.

    Policy: give Jonathan a hug before using his IP.

    If you want a licence for Jonathan’s IP besides this one you must contact Jonathan first and agree one in writing.

    Nothing in this policy shall be taken to override or conflict with free software licences already put on relevant works.

     

    facebooktwittergoogle_pluslinkedinby feather

  • Luca Falavigna: Resource control with systemd

    I’m receiving more requests for upload accounts to the Deb-o-Matic servers lately (yay!), but that means the resources need to be monitored and shared between the build daemons to prevent server lockups.

    My servers are running systemd, so I decided to give systemd.resource-control a try. My goal was to assign lower CPU shares to the build processes (debomatic itself, sbuild, and all the related tools), in order to avoid blocking other important system services from being spawned when necessary.

    I created a new slice, and set a lower CPU share weight:
    $ cat /etc/systemd/system/debomatic.slice
    [Slice]
    CPUAccounting=true
    CPUShares=512
    $

    Then, I assigned the slice to the service unit file controlling debomatic daemons by adding the Slice=debomatic.slice option under the Service directive.

    That was not enough, though, as some processes were assigned to the user slice instead, which groups all the processes spawned by users:
    systemd-cgls

    This is probably because schroot spawns a login shell, and systemd considers it belonging to a different process group. So, I had to launch the command systemctl set-property user.slice CPUShares=512, so all processes belonging to the user.slice will receive the same share of the debomatic ones. I consider this a workaround, I’m open to suggestions how to properly solve this issue :)

    I’ll try to explore more options in the coming days, so I can improve my knowledge of systemd a little bit more :)




  • Launchpad News: Launchpad news, August 2015

    Here’s a summary of what the Launchpad team got up to in August.

    Code

    • Webhook support for Git repositories is almost finished, and only needs a bit more web UI work (#1474071)
    • The summary of merge proposal pages now includes a link to the merged revision, if any (#892259)
    • Viewing individual comments on Git-based merge proposals no longer OOPSes (#1485907)

    Mail notifications

    Our internal stakeholders in Canonical recently asked us to work on improving the ability to filter Launchpad mail using Gmail.  The core of this was the “Include filtering information in email footers” setting that we added recently, but we knew there was some more to do.  Launchpad’s mail notification code includes some of the oldest and least consistent code in our tree, and so improving this has entailed paying off quite a bit of technical debt along the way.

    • Bug notifications and package upload notifications now honour the “Include filtering information in email footers” setting (#1474071)
    • Bug notifications now log an OOPS rather than crashing if the SMTP server rejects an individual message (#314420, #916939)
    • Recipe build notifications now include an X-Launchpad-Archive header (#776160)
    • Question notification rationales are now more consistent, including team annotations for subscribers (#968578)
    • Package upload notifications now include X-Launchpad-Message-Rationale and X-Launchpad-Notification-Type headers, and have more specific footers (#117155, #127917)

    Package build infrastructure

    • Launchpad now supports building source packages that use Debian’s new build profiles syntax, currently only with no profiles activated
    • Launchpad can now build snap packages (#1476405), with some limitations; this is currently only available to a group of alpha testers, so let us know if you’re interested
    • Builders can now access Launchpad’s Git hosting (HTTPS only) in the same way that they can access its Bazaar hosting
    • All amd64/i386 builds now take place in ScalingStack, and the corresponding bare-metal builders have been detached pending decommissioning; some of the newer of those machines will be used to further expand ScalingStack capacity
    • We have a new ScalingStack region including POWER8-based ppc64el builders, which is currently undergoing production testing; this will replace the existing POWER7-based builders in a few weeks, and also provide virtualised build capacity for ppc64el PPAs
    • We’ve fixed a race condition that sometimes caused a user’s first PPA to be published unsigned for a while (#374395)

    Miscellaneous

    • The project release file upload limit is now 1 GiB rather than 200 MiB (#1479441)
    • We spent some more time supporting translations for the overlay PPA used for current Ubuntu phone images, copying a number of existing translations into place from before the point when they were redirected automatically
    • Your user index page now has a “Change password” link (#1471961)
    • Bug attachments are no longer incorrectly hidden when displaying only some bug comments (#1105543)


  • Ubuntu App Developer Blog: The Next Generation SDK

    Up until now the basic architecture of the SDK IDE and tools packaging was that we have packaged and distributed the QtCreator IDE and our Ubuntu plugins as separate distro packages which strongly depend on the Qt available in the same release.

    Since 14.04 we have been jumping through hoops to provide the very same developer experience from a single development branch of the SDK projects. Just to give a quick picture on what we have available in the last few releases (note that 1.3 UITK is not yet released):

    14.04 Trusty Qt 5.2.1 QtCreator 3.0.1 UI Toolkit 0.1
    14.10 Utopic Qt 5.3. QtCreator 3.1.1 UI Toolkit 1.1
    15.04 Vivid Qt 5.4.1 QtCreator 3.1.1 UI Toolkit 1.2
    15.10 Wily Qt 5.4.2 QtCreator 3.5.0 UI Toolkit 1.3

    Life could have been easier by sticking to one stable Qt and QtCreator and base our SDK on it. Obviously it was not a realistic option as the phone development needed the most recent Qt and our friend Kubuntu required a hot new engine under its hood too. So Qt was quickly moving forward and the SDK followed it. Of course it was all beneficial as new Qt releases brought us bugfixes, new features and improved performance.

    But on the way we came to realize that continuously backporting the UITK and the QtCreator plugins to older releases and the LTS was simply not going to be possible. It went fine for some time, but the more API breaks the new Qt and QtCreator releases brought the more problems we had to face. Some people have asked why we don’t backport the latest Qt releases to the LTS or to the stable Ubuntu. As an idea it may sound good, but changing the Qt to 5.4.2 under an application in LTS what was built against 5.2.1 Qt would certainly break that application. So it is simply not cool to mess around with such fundamental bits of a stable and long term supported release.

    The only option we had was to decouple the SDK from the archive release of Qt and build it as a standalone package without any external Qt dependencies. That way we could provide the exact same experience and tools to all developers regardless if they are playing safe on Trusty/LTS or enjoy the cutting edge on the daily developed release of Wily.

    The idea manifested in a really funny project. The source tree of the project is pretty empty. Only cmake and the debian/rules take care of the job. The builder pulls the latest stable Qt, QtCreator and UITK. Builds and integrates the libdbusmenu-qt and appmenu-qt5 projects and deploys the SDK IDE. The package itself is super skinny. Opposing the old model where QtCreator has pulled most of the Qt modules as dependencies this package contains all it needs and the size of it is impressing 36MB. Cheap. Just the way I like it. Plus this package already contains the 1.3 UITK as our QtCreator plugin (Devices Tab) is using it. So in fact we are just one step from enabling desktop application development on 14.04 LTS with the same UI Toolkit as we use on the commercial phone devices. And that is a super hot idea.

    The Ubuntu SDK IDE project lives here: https://launchpad.net/ubuntu-sdk-ide

    If you want to check out how it is done:

    $ bzr branch lp:ubuntu-sdk-ide

    Since we considered such a big facelift on the SDK I thought why not to make the change much bigger. Some might remember that there was a discussion on the Ubuntu Phone mailing list about the possibility to improve the Kit creation in the IDE. Since then we have been playing with the idea and I think it is now a good time to unleash the static chroots.

    The basic idea is that creating the builder chroots runtime is a super slow and fragile process. The bootstrapping of the click chroot already takes a long time and installing the SDK API packages (all the libs and dev packages with headers) into the chroot is also time consuming. So why not to create these root filesystems in advance and provide them as single installable packages.

    This is exactly what we have done. The base of the API packages is the Vivid core image. It is small and contains only the absolutely necessary packages, we install the SDK libs, dev packages and development tools on the core image and configure the Overlay PPA too. So the final image is pretty much equivalent with the image on a freshly updated device out there. It means that the developer can build and test against the same API set as it is available on the devices.

    These API packages are still huge. Their size is around 500MB, so on a slow connection it still takes ages to download, but still it is way faster than bootstrapping a 1.6GB chroot package by package.

    This API packages contain a single tar.gz file and the post install script of the package puts the content of this tar.gz to the right place and wires it in, in the way it should be. Once the package is installed the new Kit will be automatically recognized by the IDE.

    One important note on this API package! If you have an armhf 15.04 Kit (click chroot) already on your system when you install this package, then your original Kit will not be removed but simply renamed to backup-[timestamp]-[original name]. So do not worry if you have customized Kits, they are safe.

    The Ubuntu SDK API project is only a packaging project with a simple script to take care of the dirty details. The project is hosted here: https://launchpad.net/ubuntu-sdk-api-15.04

    And if you want to see what is in it just do

    $ bzr branch lp:ubuntu-sdk-api-15.04  

    The release candidate packages are available from the Tools Development PPA of the SDK team: https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/tools-development

    How to test these packages?

    $ sudo add-apt-repository ppa:ubuntu-sdk-team/tools-development -y

    $ sudo apt-get update

    $ sudo apt-get install ubuntu-sdk-ide ubuntu-sdk-api-tools

    $ sudo apt-get install ubuntu-sdk-api-15.04-armhf ubuntu-sdk-api-15.04-i386

    After that look for the Ubuntu SDK IDE in the dash.