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/

  • Costales: From uNav with ❤ to OpenStreetMap

    We (Joerg Berroth, Nekhelesh Ramananthan, Marcos Costales) donated all the money of this quarter from the uNav donate version to OpenStreetMap project.

    We love OSM!

    Donation

    We're happy that the 20% of the purchases are going to Ubuntu already :))


  • The Fridge: Ubuntu Online Summit: 3-5 May

    The next Ubuntu Online Summit (UOS) is going to be from 3-5 May 2016 with sessions happening from 14:00 – 20:00 UTC.

    If you are planning to attend, please register here:

    http://summit.ubuntu.com/uos-1605/registration/

    If you and your team need to discuss something at UOS, please get your sessions in as soon as possible:

    http://summit.ubuntu.com/getinvolved/propose-a-session/

    Getting them in earlier will mean that others can plan their attendance accordingly and you will have better turnout. Please note that we are not only keen to have discussion and planning sessions, but also workshops and presentations.

    Originally posted to the community-announce mailing list on Wed Apr 27 08:06:53 UTC 2016 by Daniel Holbach



  • Ubuntu Podcast from the UK LoCo: S09E09 – Solitary Confinement - Ubuntu Podcast

    It’s Episode Nine of Season Nine of the Ubuntu Podcast! Alan Pope, Mark Johnson, Laura Cowen and Martin Wimpress are connected and speaking to your brain.

    We’re here again, although one of us is in Prague!

    In this week’s show:

    That’s all for this week! If there’s a topic you’d like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.



  • Canonical Design Team: Wallpaper design for Xenial Xerus 16.04

    April marks the release of Xerus 16.4 and with it we bring a new design of our iconic wallpaper. This post will take you through our design process and how we have integrated our Suru visual language.

    Evolution

    The foundation of our recent designs are based on our Suru visual language, which encompasses our core brand values, bringing consistency across the Ubuntu brand.

    Our Suru language is influenced by the minimalist nature of Japanese culture. We have taken elements of their Zen culture that give us a precise yet simplistic rhythm and used it in our designs. Working with paper metaphors we have drawn inspiration from the art of origami that provides us with a solid and tangible foundation to work from. Paper is also transferable, meaning it can be used in all areas of our brand in two and three dimensional forms.

    Design process

    We started by looking at previously released wallpapers across Ubuntu to see how each has evolved from each other. After seeing the previous designs we started to apply our new Suru patterns, which inspired us to move in a new direction.

    Ubuntu 14.10 ‘Utopic Unicorn’’

    wallpaper_unicorn

    Ubuntu 15.04 ‘Vivid Vervet’

    suru-desktop-wallpaper-ubuntu-vivid (1)

    Ubuntu 15.10 ‘Wily Werewolf’

    ubuntu-1510-wily-werewolf-wallpaper

    Step-by-step process

    Step 1. Origami animal

    Since every new Ubuntu release is named after animal, the Design Team wanted to bring this idea closer to the wallpaper and the Suru language. The folds are part of the origami animal and become the base of which we start our design process.

    Origarmi

    Step.2 Searching for the shape

    We started to look at different patterns by using various techniques with origami paper. We zoomed into particular folds of the paper, experimented with different light sources, photography, and used various effects to enhance the design.

    The idea was to bring actual origami to the wallpaper as much as possible. We had to think about composition that would work across all screen sizes, especially desktop. As the wallpaper is a prominent feature in a desktop environment, we wanted to make sure that it was user friendly, allowing users to find documents and folders located on the computer screen easily. The main priority was to not let the design get in the way of everyday usage, but enhance it aesthetically and provide a great user experience.

    After all the experiments with fold patterns and light sources, we started to look at colour. We wanted to integrate both the Ubuntu orange and Canonical aubergine to balance the brightness and played with gradient levels.

    We balanced the contrast of the wallpaper color palette by using a long and subtle gradient that kept the bright and feel look. This made the wallpaper became brighter and more colorful.

    Step.3 Final product

    The result was successful. The new concept and usage of Suru language helped to create a brighter wallpaper that fitted into our overall visual aesthetic. We created a three-dimensional look and feel that gives the feeling of actual origami appearance. The wallpaper is still recognizable as Ubuntu, but at the same time looks fresh and different.

    Ubuntu 16.04 Xenial Xerus

    Xerus - purple

    Ubuntu 16.04 Xenial Xerus ( light version)

    Xerus - Grey

    What is next?

    The Design Team is now looking at ways to bring the Suru language into animation and fold usage. The idea is to bring an overall seamless and consistent experience to the user, whilst reflecting our tone of voice and visual identity.



  • Simon Quigley: Contributing to Ubuntu - 2 - Ubuntu Quality

    For the past nine months, I have done a couple forms of QA for the Ubuntu project and flavors. In this blog post, I plan on highlighting some common practices and how I contributed.

    ISO QA Test

    Download the image

    For demonstration purposes, I'll grab the Lubuntu daily image, which as I'm writing this, is the Yakkety daily image. First, navigate to cdimage.ubuntu.com, it should look similar to the below screenshot:

    Since in this case we are testing Lubuntu, select lubuntu/, the page should look like this after loading:

    Lubuntu is a special case. They have desktop images and alternate images1. The desktop image is the same across all flavors, while the alternate image uses the Debian installer and requires less RAM to run. In this case, let's test the desktop image, so select daily/, the page should look like this after loading:

    In the above screenshot, I have noted a few things, here is the purpose of each directory2:
    20160425/ - I am writing this on April 26, 2016 (20160426), but this directory exists to ensure we have an image from the previous day for testing purposes and in the odd case that something gets messed up.
    20160426/ - These are today's images
    current/ - All of the images go through some automatic testing before proceeding to this directory, these are the last images that passed these tests.
    pending/ - This is the directory that holds the images that are either currently testing or that haven't passed the tests, and this is usually the same files as 20160426/.

    We are going to grab the image from the current/ directory. The page for current/ should look like the following screenshot3:

    Scroll down and you should see the following:

    Listed are three architectures: amd64 (which is 64-bit), i386 (which is 32-bit), and PowerPC (old Macintosh machines). Other Ubuntu flavors usually have only amd64 and i386, but Lubuntu has a PowerPC image as well. We have six (6) files for each architecture:

    1. *.OVERSIZED - irrelevant right now, you do not need to worry about it.
    2. *.iso - the image file.
    3. *.iso.zsync - the zsync file for the image.
    4. *.jigdo - the Jigdo file.
    5. *.list - the list file.
    6. *.template - the jigdo template file.

    I will show you how to utilize two (2) of the six (6) files in this directory to download the images. Ensure the zsync package is installed on your system before continuing. To download the image, yes, you can use your web browser to download the image. But there is a better way, using zsync. zsync allows you to download the image, but when the image changes, it will automatically merge the changes with the existing image that you have. Since it is the same directory and image name for the whole development cycle, you can safely use one link until the development release gets released. I'll create a directory to put the images:
    $ mkdir daily-images && cd daily-images
    Copy the zsync link for your architecture and paste it into the terminal, for example:
    $ zsync http://cdimage.ubuntu.com/lubuntu/daily-live/current/yakkety-desktop-amd64.iso.zsync
    When you press Enter, the image will download. When this is done, you should have the image ready to go.

    Getting set up with the ISO QA Tracker

    Navigate to iso.qa.ubuntu.com in your browser, you should see the following:

    On the left side, click the Log in button. You should be brought to a page that looks like this:

    If you already have an Ubuntu One account, log in with your credentials and press the Log In button. If you don't have an account, create one. I don't plan on going much into detail on this, so let's move on. You should be brought to a screen that looks similar to this:

    Click the Yes, log me in button. You should be brought to the following screen, if you have a black bar at the top like in the image, you have logged in correctly:

    Towards the bottom, you should see the Yakkety Daily suite3. Click on that and you should get to a screen with various options for images. Scroll down and you should get a screen similar to this:

    Since I downloaded the amd64 desktop image earlier, I will select Lubuntu Desktop amd64. You should get to a screen that looks like this:

    Here we have four test cases to choose from:

    • Install (auto-resize) - requires an existing installation.
    • Install (entire disk) - very generic.
    • Install (manual partitioning) - same as entire disk except you get to manually partition everything.
    • Live Session - testing the live instance.

    Because it's the most generic, I'll select Install (entire disk). When you click on that, you should get a screen similar to this:

    If you scroll down to the bottom, you should see something similar to this:

    Filling it out will be covered in a bit, but it's good to know what the submission form looks like.

    Executing the test case

    A lot of the test cases are done in virtual machines, but if you have hardware to spare, that's better, but it's not essential. I'm not going to cover how to use a virtual machines, but you can find good guides below. I prefer KVM because the Linux kernel has built-in support for it, it's a lot more integrated, and it's completely free software. I've used VirtualBox in the past, it's a great program, but it's proprietary, and the kernel modules can be a bit fidgety to get working after a kernel upgrade.

    Before you begin, read over the test case you plan on executing, there may be some important instructions that you need to watch out for. When you are ready to start, on the test case, select the In Progress radio box and press the Submit result button. Complete the test exactly how the test case says it should be done.

    During the installation, if you encounter an error that is critical enough that you cannot proceed, first look at the Bugs to look for. Is there a bug that describes your problem? If not, search Launchpad for the bug. If it's not there, identify the culprit package and file a bug against it. If you have trouble doing this, join the #ubuntu-quality channel using your IRC client or the IRC client provided below and ask for help.

    When you are done, on the test case page, click the button to edit your test case result:

    You should be brought to a page similar to this:

    If you had no trouble installing it using the instructions, select the Passed radio box. For the bugs, from what I have seen, any bugs in the system, NOT just the installation bugs, should be reported. So look at the release notes of the most recent milestone for the flavor you are testing, and go through bug reports. Confirm as much as you can, when you do, mark the bug as Me too and list the bugs under the Bugs header in the following format:

    XXXXX, YYYYY, ZZZZZ

    Be careful, the tracker likes to insert extra commas and sometimes mangle this a bit. Always check this field before updating your result.

    When you have all the bugs cited on this page, select the Update result button. If you then scroll down to the bottom, you should see your Launchpad ID with a green checkmark beside it and links to the bugs you listed. Congrats! You now completed that test case!

    Package QA Test

    The package QA tests exist to ensure that all packages are thoroughly tested for the release. Ensure you have an installation of the daily image for that flavor. Before you begin, ensure you have an Ubuntu One account set up. Also ensure you have read the previous section as I will not repeat some information that is explained above.

    Navigate to packages.qa.ubuntu.com in your browser, you should see the following:

    Click on Yakkety Daily3 and you should be brought to a screen similar to this:

    Since as of the time of writing, Xubuntu is the only flavor with package test cases, click on Xubuntu Desktop and you should be brought to a screen similar to this:

    At this point, open the test case and complete like normal, making sure to follow instructions exactly how they are listed. Instead of checking the release notes, go to the Launchpad bugs page for each package and check against all of the bugs. You can find the bugs for each package at the following URL, replacing PACKAGE with the respective package name:

    https://bugs.launchpad.net/ubuntu/+source/PACKAGE

    After this is done, congrats! You just completed a Package QA test!

    Write a manual test case

    The manual test cases are not automatically generated, they are hand-written for that application. I will tell you how to write a test case but I'm not actually going to write one because that would be too tedious for me to put in this article.

    To keep track of the manual test cases that need writing, we have bugs for each test case and details on what to do to it. I've done this a few times before, so I know these already, but read over the instructions for writing a test case before you begin. First, assign the bug to yourself and mark it as In Progress. Then read over the bug report and responses to ensure you know what you are doing. Next, ensure the program is installed by default in the flavor the bug report specifies. If this is not the case, mark the bug as Incomplete and state that it is not in the flavor you specified. If it is there, you can continue.

    After that, grab the source for the Ubuntu Manual Test Cases. Ensure you have bzr installed and run:

    $ bzr branch lp:ubuntu-manual-tests

    Then cd into the ubuntu-manual-tests directory just created. Go into the testcases/packages/ directory and another subdirectory if applicable. Open your favorite text editor and create a file with the name of the package you are creating a test case for, no need for any numbers. Using the guide above, write the test case and verify it. Below I have embedded a video by Nicholas Skaggs if you prefer to view a video:

    When you are done, make sure you are directly in the ubuntu-manual-tests directory, and execute the following command4:

    $ bzr add * && bzr commit --fixes lp:BUG#

    Then push to a Bazaar branch in Launchpad:

    $ bzr push lp:~/ubuntu-manual-tests/bugfix#####

    Then go to the Bazaar page for the Ubuntu Manual Testcases project and find your branch. Then submit a merge request detailing your test case. Congrats! You wrote a manual test case!

    Further questions?

    Below if you are on my website, I have linked an IRC client for you to use if you do not have your own. Type in a nickname, press start, and press Enter to speak in the channel. If you have an IRC client, go to #ubuntu-quality on irc.freenode.net. If you prefer not to use IRC, we have a mailing list that you can use if you wish. Good luck and I hope to see you around! ☺

    1. We also have a preinstalled image, but I will not cover that in this tutorial.
    2. Even though the directory names will have changed, the information is still accurate.
    3. This information will still be valid after we move on from Yakkety images.
    4. Make sure Bazaar is set up properly before doing this
    If you have questions/comments/concerns/suggestions about this article, my email is tsimonq2@ubuntu.com or I am tsimonq2 on Freenode (PMs and pings welcome).