BSD Release: GhostBSD 10.3

The GhostBSD project develops a desktop friendly operating system based on FreeBSD. The project has updated its 10.x series with the launch of GhostBSD 10.3. The new version supports booting on UEFI-enabled computers, supports ZFS volumes and includes VirtualBox modules. “What changed in GhostBSD 10.3: The installer partition….

Development Release: openSUSE 42.2 Beta 1

Ludwig Nussel has announced the availability of the first beta build of openSUSE 42.2, the upcoming new stable release scheduled to arrive on 16 November 2016: “openSUSE 42.2 beta 1 is on the mirrors. Even though it’s called beta 1, the base system is mostly in sync with….

Presenting Xisco Fauli, the new QA Engineer

developer_xisco_fauliXisco Fauli, a Spanish LibreOffice developer working in Madrid as a Quality Assurance (QA) specialist, will be a consultant for The Document Foundation effective from September 1st, as QA Engineer.

Xisco got a bachelor’s degree in system data processing at the Polytechnic University of València in 2011. Since then, he has worked for four years as a QA Engineer for a company providing Digital TV solutions, where he has focused mainly on testing software for PCs and portable devices.

Xisco has recently been interviewed by Mike Saunders based on his volunteer development activity and his involvement in the project.

Xisco’s main responsibilities will be the following:

  1. Monitor and report about the state of LibreOffice QA, fostering communications between QA and other teams and encouraging people to join the QA team (and help onboarding new contributors);

  2. Provide and maintain bibisect repositories of the LibreOffice codebase;

  3. Maintain, update and create feature patches for TDF Bugzilla instance;

  4. Organize and coordinate bug hunting sessions, test LibreOffice development builds daily on multiple platforms, run master to try to find regressions early in release cycles, and run release tests on alphas, betas and release candidates to identify blockers;

  5. Triage unconfirmed bugs on master;

  6. Create, improve and keep up-to-date introductions, documentation and howtos for volunteers to LibreOffice QA;

  7. Represent the QA project during weekly Engineering Steering Committee calls.

Amazing Artists Are Needed to Contribute New Wallpapers to Ubuntu 16.10 Linux OS

Yes, it’s that time of the year again, when your artist skills are needed for a new collection of astonishing wallpapers that will be included by default in the upcoming Ubuntu 16.10 (Yakkety Yak) operating system.

Once again, Nathan Haines has the enormous pleasure of announcing that the Ubuntu Free Culture Showcase wallpaper gathering event for the next Ubuntu Linux release starts now, and the community is urged to contribute beautiful wallpapers that will enchant both newcomers and veterans of one of the most popular Linux kernel-based operating systems.

“The Ubuntu Free Culture Showcase is a way to celebrate the Free Culture movement, where talented artists across the globe create media and release it under licenses that encourage sharing and adaptation. We’re looking for content which shows off the skill and talent of these amazing artists and will greet Ubuntu 16.10 … (read more)

Ubuntu 16.04 LTS Kernel for Raspberry Pi 2 Updated to Fix Eight Vulnerabilities

We reported the other day on the availability of new kernel updates for the Ubuntu 16.04 LTS (Xenial Xerus), as well as for the Ubuntu 14.04 LTS (Trusty Tahr) and Ubuntu 12.04 LTS (Precise Pangolin) operating systems.

One day later, on August 30, 2016, Canonical published a new security advisory to inform the Ubuntu Linux community about the availability of an updated kernel for the Raspberry Pi 2 port of the Ubuntu 16.04 LTS (Xenial Xerus) operating system, patching the same eight vulnerabilities discovered in the desktop and server kernel packages.

If you didn’t read our previous report, we can tell you now that among the patched kernel security f… (read more)

Development Release: Fedora 25 Alpha

Dennis Gilmore has announced that the initial alpha build of the upcoming Fedora 25 release is ready for download and testing. “The Fedora project is pleased to announce the immediate availability of the Fedora 25 alpha, an important milestone on the road to our Fedora 25 release in….

Fedora 25 Alpha Officially Released with Linux Kernel 4.8, Wayland & GNOME 3.22

Today, August 30, 2016, the Fedora Project was pleased to announce the immediate availability for download and public testing of the Alpha pre-release build of the upcoming Fedora 25 operating system.

The biggest new feature of the Fedora 25 Alpha milestone is the migration to the next-generation Wayland display server in addition to X11 (a.k.a. X.Org Server), which is enabled by default on systems that support it, but it’s available only for the Workstation edition that’s built around the GNOME desktop environment.

Talking about GNOME, Fedora 25 Alpha ships with the GNOME 3.21.4 development build of the upcoming GNOME 3.22 desktop environment, due for release on September 21, 2016, though some packages are at GNOME 3.20.2. Most probably this version will soon be upgraded to the current milestone, namely GNOME 3.22 Beta<... (read more)

Documentation overhaul

One of the biggest content areas on Drupal.org—and one of the most important assets of any open source project—is documentation. Community-written Drupal documentation consists of about 10,000 pages. Preparations for the complete overhaul of the documentation tools were in the works for quite some time, and in the recent weeks we finally started to roll out the changes on the live site.

Background

Improving documentation on Drupal.org has been a part of a larger effort to restructure content on the site based on content strategy we developed.

The new section comes after a few we launched earlier in the year. It also uses our new visual system, which will slowly expand into other areas.

Goals and process

The overall goal for the new Documentation section is to increase the quality of the community documentation.

On a more tactical level, we want to:

  • Introduce the concept of “maintainers” for distinct parts of documentation
  • Flatten deep documentation hierarchy
  • Split documentation per major Drupal version
  • Notify people about edits or new documentation
  • Make comments more useful

To achieve those goals, we went through the following process:

First, we wrote a bunch of user stories based on our user research and the story map exercise we went through with the Documentation Working Group members. Those stories cover all kinds of things different types of users do while using documentation tools.

We then wireframed our ideas for how the new documentation system should look and work. We ran a number of remote and in person usability testing sessions on those wireframes.

Our next step was to incorporate the feedback, update our wireframes, and create actual designs. And then we tested them again, in person, during DrupalCamp London.
Incorporated feedback again, and started building.

The new system

So, how does the new documentation system work exactly? It is based on two new content types:

  1. Documentation guide: a container content type. It will group documentation pages on a specific topic, and provide an ability to assign ‘maintainers’ for this group of pages (similar to maintainers for contributed projects). Additionally, users will be able to follow the guide and receive notifications about new pages added or existing pages edited.
  2. Documentation page: a content type for the actual documentation content. These live inside of documentation guides.

Documentation guide screenshot
Example of a new documentation guide

All of the documentation is split per major Drupal version, which means every documentation guide or page lives inside of one of a few top level ‘buckets’, e.g. Drupal 7 documentation, Drupal 8 documentation.
It is also possible to connect guides and pages to each other via a ‘Related content’ field, which should make it easier to discover relevant information. One of our next to-do’s is to provide an easy way to connect documentation guides to projects, enabling ‘official’ project documentation functionality.

More information on various design decisions we made for the new documentation system, and the reasons behind them, can be found in our DrupalCon New Orleans session (slides).

Current status

Right now, we have the new content types and related tools ready on Drupal.org.
We are currently migrating existing documentation (all 10,000 pages!) into the new system. The first step is generic documentation (e.g. ‘Structure Guide’), with contributed projects documentation to follow later.

While working on the migration, we are recruiting maintainers for the new guides. If you are interested in helping out, sign up in the issue. Please only sign up if you actually have some time to work on documentation in the near future.

There is a lot of work to be done post-migration (both by guide maintainers and regular readers/editors). The content is being migrated as-is, and it needs to be adapted for the new system. This means almost every single page needs to be edited. New fields (such as Summary) filled out with meaningful text (to replace text automatically generated by the migration script). A lot of pages include information for both Drupal 7 and Drupal 8, but this content needs to be split, with Drupal 8 information moved to pages in the appropriate version of the guide. These are just some of the steps that need to happen once the documentation has been migrated into the new system.

Next steps

As staff, we have a few follow-up tasks for minor improvements to the content types and tools. However, the bulk of the work is editing and improving the actual documentation, as I described above. This is in your hands now. Not only do we not have enough staff members to edit every single documentation page in a reasonable amount of time, we are also not subject matter experts for many of the topics, and so can’t provide meaningful edits. The tools are ready, now it is up to the community to pick them up and write great documentation.

Documentation page screenshot
Example of a documentation page

Thank you

Lastly we want to say thanks.

Thanks to all the community volunteers who wrote those 10,000 pages over the years. Thanks to the Documentation Working Group members for their expertise, insight, and patience.

And, of course, thanks to staff. Unfortunately due to recent changes for the Engineering team, this will be the last section we’ll have resources to work on for a while. This was a fun and important project to work on, and we are glad that we got to finish it. It is a beautiful legacy of the work we did together with some of our former colleagues: DyanneNova, japerry, and joshuami. Thank you!

Documentation overhaul

One of the biggest content areas on Drupal.org—and one of the most important assets of any open source project—is documentation. Community-written Drupal documentation consists of about 10,000 pages. Preparations for the complete overhaul of the documentation tools were in the works for quite some time, and in the recent weeks we finally started to roll out the changes on the live site.

Background

Improving documentation on Drupal.org has been a part of a larger effort to restructure content on the site based on content strategy we developed.

The new section comes after a few we launched earlier in the year. It also uses our new visual system, which will slowly expand into other areas.

Goals and process

The overall goal for the new Documentation section is to increase the quality of the community documentation.

On a more tactical level, we want to:

  • Introduce the concept of “maintainers” for distinct parts of documentation
  • Flatten deep documentation hierarchy
  • Split documentation per major Drupal version
  • Notify people about edits or new documentation
  • Make comments more useful

To achieve those goals, we went through the following process:

First, we wrote a bunch of user stories based on our user research and the story map exercise we went through with the Documentation Working Group members. Those stories cover all kinds of things different types of users do while using documentation tools.

We then wireframed our ideas for how the new documentation system should look and work. We ran a number of remote and in person usability testing sessions on those wireframes.

Our next step was to incorporate the feedback, update our wireframes, and create actual designs. And then we tested them again, in person, during DrupalCamp London.
Incorporated feedback again, and started building.

The new system

So, how does the new documentation system work exactly? It is based on two new content types:

  1. Documentation guide: a container content type. It will group documentation pages on a specific topic, and provide an ability to assign ‘maintainers’ for this group of pages (similar to maintainers for contributed projects). Additionally, users will be able to follow the guide and receive notifications about new pages added or existing pages edited.
  2. Documentation page: a content type for the actual documentation content. These live inside of documentation guides.

Documentation guide screenshot
Example of a new documentation guide

All of the documentation is split per major Drupal version, which means every documentation guide or page lives inside of one of a few top level ‘buckets’, e.g. Drupal 7 documentation, Drupal 8 documentation.
It is also possible to connect guides and pages to each other via a ‘Related content’ field, which should make it easier to discover relevant information. One of our next to-do’s is to provide an easy way to connect documentation guides to projects, enabling ‘official’ project documentation functionality.

More information on various design decisions we made for the new documentation system, and the reasons behind them, can be found in our DrupalCon New Orleans session (slides).

Current status

Right now, we have the new content types and related tools ready on Drupal.org.
We are currently migrating existing documentation (all 10,000 pages!) into the new system. The first step is generic documentation (e.g. ‘Structure Guide’), with contributed projects documentation to follow later.

While working on the migration, we are recruiting maintainers for the new guides. If you are interested in helping out, sign up in the issue. Please only sign up if you actually have some time to work on documentation in the near future.

There is a lot of work to be done post-migration (both by guide maintainers and regular readers/editors). The content is being migrated as-is, and it needs to be adapted for the new system. This means almost every single page needs to be edited. New fields (such as Summary) filled out with meaningful text (to replace text automatically generated by the migration script). A lot of pages include information for both Drupal 7 and Drupal 8, but this content needs to be split, with Drupal 8 information moved to pages in the appropriate version of the guide. These are just some of the steps that need to happen once the documentation has been migrated into the new system.

Next steps

As staff, we have a few follow-up tasks for minor improvements to the content types and tools. However, the bulk of the work is editing and improving the actual documentation, as I described above. This is in your hands now. Not only do we not have enough staff members to edit every single documentation page in a reasonable amount of time, we are also not subject matter experts for many of the topics, and so can’t provide meaningful edits. The tools are ready, now it is up to the community to pick them up and write great documentation.

Documentation page screenshot
Example of a documentation page

Thank you

Lastly we want to say thanks.

Thanks to all the community volunteers who wrote those 10,000 pages over the years. Thanks to the Documentation Working Group members for their expertise, insight, and patience.

And, of course, thanks to staff. Unfortunately due to recent changes for the Engineering team, this will be the last section we’ll have resources to work on for a while. This was a fun and important project to work on, and we are glad that we got to finish it. It is a beautiful legacy of the work we did together with some of our former colleagues: DyanneNova, japerry, and joshuami. Thank you!

LibreOffice contributor interview: Susobhan Ghosh

Susobhan Ghosh LibreOffice developer

In this week’s interview, we talk to Susobhan Ghosh, who got involved in the project earlier this year and has been working on tasks for the Google Summer of Code (GSoC).

First off, what’s your IRC nickname, nationality and blog URL?

Where are you currently based, and do you work for a LibreOffice-related company or just code in your spare time?

​I’m currently living in Hyderabad, India. I’m a third year Computer Science and Engineering student at IIIT Hyderabad. I’ve been coding full time throughout the summer for LibreOffice as a GSoC student – otherwise I code in my spare time.

How did you get involved with LibreOffice?

I started in January 2016, with bug tdf#95845 – I had to replace methods for labels/tooltips with CommandInfoProvider. I ended up causing a regression, which I later on fixed with help from samuel_m. I started contributing more frequently in March, and learnt a lot while fixing the Firefox persona search (tdf#88502).

What was your initial experience of contributing to LibreOffice like?

Initially I had trouble building the suite, and also pushing patches due to network restrictions, but I received good support from the developers like JanIV and chris_wot on IRC, and also samuel_m for submitting my first patch. Overall, the initial experience was pretty nice.

What areas of the project do you normally work on? Anything else you want to tackle?

I’m currently working on the sidebar for GSoC, and I’m familiar with the Firefox personas search. I’d personally like to work on adding theming support for LibreOffice (similar to other office suites) apart from the Firefox themes and color changing options, to provide better customization options.

What is your vision for the future of LibreOffice?

I’m very much looking forward to quite a few things: LibreOffice Online, LibreOffice for Android, the NotebookBar, and added customization and themes for LibreOffice – all of which are under development right now.

What was the very first program you wrote?

My first program was in C++, similar to a Hello World program, except I printed my own name instead of “Hello, World”.

Which is your preferred text editor, and why?

I’m not really a fan of the command line when it comes to editing. My favorite editor would be Sublime Text 3. I won’t bring up the debate as to whether it’s better than Vim or Atom or Emacs – I choose this just because I’m familiar with it have mastered it.

What do you do when you’re not working on LibreOffice?

I’m generally busy with studies and research throughout the year. Otherwise during my holidays, I like to play games – FIFA, Assassin’s Creed, Pokemon etc. Other than that, I watch football (FC Barcelona fan), go out for movies and hang out with my friends.

Thanks Susobhan! And thanks indeed to our whole community – if you’re reading this and want to get involved, join us today and help to make LibreOffice even better.

Remembering Vernon Adams


Vernon

LWN reports on the sad death of Vernon Adams, designer of the Oxygen font and author of the invaluable how to use Font Forge guide.

VDG Artist Thomas Pfeiffer writes:

The name Vernon Adams might not ring any bells for you, but if you have used Plasma in the recent past, you know at least one of his works: The Oxygen font, which was Plasma’s default user interface font for a long time.

Vernon did excellent work on the font, and we’d still be using it as our default today if a tragic car accident had not rendered him unable to continue his work (sadly nobody else took it up, either). Sadly, Vernon has now passed away.

Vernon Adams will always be remembered by the Free Software community for his tireless work for freedom in font design, and we hope he will inspire countless font designers to come.

Remembering Vernon Adams


Vernon

LWN reports on the sad death of Vernon Adams, designer of the Oxygen font and author of the invaluable how to use Font Forge guide.

VDG Artist Thomas Pfeiffer writes:

The name Vernon Adams might not ring any bells for you, but if you have used Plasma in the recent past, you know at least one of his works: The Oxygen font, which was Plasma’s default user interface font for a long time.

Vernon did excellent work on the font, and we’d still be using it as our default today if a tragic car accident had not rendered him unable to continue his work (sadly nobody else took it up, either). Sadly, Vernon has now passed away.

Vernon Adams will always be remembered by the Free Software community for his tireless work for freedom in font design, and we hope he will inspire countless font designers to come.

Linux Kernel 3.10.103 LTS Has Lots of MIPS Improvements, Updated Radeon Drivers





Linux kernel developer Willy Tarreau has announced the release of the one hundred and third maintenance update to the long-term supported Linux 3.10 kernel series.
For some reason, the Linux 3.10 kernel branch is still getting updates, and this new version promises to add quite some improvements and updated drivers. According to the appended shortlog and the diff from the Linux kernel 3.10.102 LTS build, a total of 161 files have been changed, with 1,800 insertions and 1,293 deletions.
For those of you who are wondering what’s new in the Linux kernel 3.10.103 LTS, we would like to tell you that this update brings many improvements to the MIPS, PowerPC (PPC), x86, ARM, ARC, and s390 hardware architectures, as well as various enhancements and fixes to the EXT4, CIFS, NFS, NILFS2, UBIFS, XFS, FUSE, and eCryptfs filesystems.
There are also lots of updated drivers, in particular for Radeon, InfiniBand, SCSI, USB, Virtio, Xen, MTD, MMC, MD, iiO, HID, GPIO, ATA, Crypto, and networking (mostly Ethernet and Wireless) devices, as well as an updated networking stack with IPv6, IPv4, Netfilter, Netlabel, Ceph, Bluetooth, IrDA, mac80211, SCTP, SunRPC, and RFKill fixes. The sound stack has been updated as well with some new audio drivers.

Source: http://news.softpedia.com/news/linux-kernel-3-10-103-lts-has-lots-of-mips-improvements-updated-radeon-drivers-507689.shtml
Submitted by: Arnfried Walbrecht

HP Linux Imaging and Printing 3.16.8 Adds Support for Linux Mint 18, Fedora 24

The open-source HP Linux Imaging and Printing (HPLIP) project has been updated on August 29, 2016, to version 3.16.8, a maintenance update that adds support for new printers and GNU/Linux operating systems.

According to the release notes, HP Linux Imaging and Printing 3.16.8 adds support for new all-in-one HP printers, including HP OfficeJet Pro 6970, HP OfficeJet Pro 6960, HP OfficeJet 250 Mobile, HP DeskJet 3700, as well as HP DeskJet Ink Advantage 3700.

Also new in the HPLIP 3.16.8 update is support for the recently released Linux Mint 18 “Sarah” Cinnamon, MATE, Xfce, and the upcoming KDE editions, the Fedora 24 Linux operating system, as well as the Debian GNU/Linux 8.5 “Jessie” distribution. So if you’re using any of these OSes, you can now update to the latest HPLIP release.

Secure PIN Printing improvements

Besides adding support for new HP printers and Linux kernel-based… (read more)

Crablet Plunder | Catherby & White Wolf Mountain Rework | Crystal Peacock Armour

Get an XP reward every day in September and boost it by logging in on consecutive days!

MPlayer-Based MPV 0.20.0 Video Player Released with New Options and Commands

The popular, open-source, and cross-platform MPV video player software has received a new update, version 0.20.0, which comes only two weeks after the previous 0.19.0 maintenance release.

MPV 0.20.0 is not a major update, and according to the release notes, it only implements a couple of new options and commands, such as “–video-unscaled=downscale-big” for changing the aspect ratio.

Additionally, the MPlayer-based video playback application also gets the “–image-display-duration” option for controlling the duration of image display and a new “dcomposition” flag for controlling DirectComposition.

Bug fixes and minor improvements

As mentioned before, MPV 0.20.0 is all about bug fixes than new features, so its maintainers have managed to improve … (read more)

Distribution Release: Salix 14.2 “Xfce”

George Vlahavas has announced the release of Salix 14.2 “Xfce”. The new version of Salix, a Slackware-based desktop distribution, improves the boot process, provides better language support at install time and includes a few new graphical configuration tools. “We also have two new GUI system tools, both developed….

Canonical Patches Eight Linux Kernel Vulnerabilities for Ubuntu 16.04 LTS

Just a few minutes ago, Canonical published multiple security advisories to inform the Ubuntu Linux community about the availability of new kernel updates for all of its supported Ubuntu OSes, including Ubuntu 16.04 LTS (Xenial Xerus).

Launched in April 21, 2016 and being a long-term supported release, Ubuntu 16.04 LTS has already received its first big update, dubbed by the company as Ubuntu 16.04.1 LTS, but that won’t stop Canonical from pushing new software versions and security updates whenever threats are found, all in order to keep users safe and secure.

Today’s Ubuntu Security Notice USN-3070-1, tells us about an important kernel update for the Ubuntu 16.04 LTS (Xenial Xerus) operating system, which patches a total of eight vulnerabilities discovered by various kernel hackers and developers in the upstream Linux 4.4 LTS kernel branch (the latest release is Linux kernel 4.4.19 LTS).

The security flaws vary … (read more)

The Peppermint Twist Is Still Cool


The Peppermint operating system is built around a concept not found in most Linux distros. It is a hybrid combination of traditional Linux desktop applications and cloud-based infrastructure. Peppermint 7, the annual update released in June, is a lightweight distribution based on Ubuntu 16.04. It uses LXDE as the default desktop environment, and shows considerable growth since our review of Peppermint 5 two years ago. The key to this process of linking full desktop functionality to cloud apps is an in-house developed application dubbed “Ice.”

Getting involved with the Fedora kernel

There are countless ways to contribute to open source projects like Fedora. Perhaps one of the most obvious ways to contribute is by helping with the Linux kernel in Fedora. At Flock 2016, I gave a talk about the state of the Fedora kernel. One of the themes of the talk was getting more people involved. The kernel is a project for everyone and all are welcome to take part. This article details what you can do to become a part of the kernel.

Understanding the Fedora kernel

If this is your first time sending patches, kernel newbies has a good tutorial on setting up your git environment. One way to get involved is to contribute to the Fedora-specific parts of the kernel. The Fedora kernel is separate, but based on the upstream kernel. Almost all the files in the Fedora kernel pkg-git repository are Fedora-specific. This includes the kernel.spec, kernel configuration options, and support scripts. Changes to these files can be sent directly to the Fedora kernel mailing list. In general, anything that is not a kernel patch can be sent directly to the Fedora kernel mailing list for review. If there are configuration options that need to be adjusted for example, send a patch to the mailing list or attach it directly to a Bugzilla report.

Contributing upstream

For patches to the kernel itself, the best practice is to make sure all patches go into the upstream project first and then come into Fedora. It’s okay to have discussion in Fedora spaces first though. Fedora maintainers and other contributors give input about whether a proposal makes sense in general before it goes to a wider audience. Eventually, discussion and approval will need to head to the appropriate kernel mailing lists.

New comers may feel intimidated contributing to the kernel community outside of Fedora. It’s helpful to remember that the kernel community does not expect every patch to be perfect the first time, especially from new contributors. The best way to be successful in the kernel community is to do background research, make the best effort you can, and listen to whatever feedback is given. When maintainers have “acked” (acknowledged) your patch for the upstream kernel, you can submit it as a patch for the Fedora pkg-git repository and send it to the mailing list or attach it to a Bugzilla report.

First contribution

Figuring out a first contribution can be tricky. The best way to get ideas is to build and run the project. Start by learning how to build the Fedora kernel. When patches come on to the Fedora kernel mailing list, download and apply them to your own build. As you build and test patches, think about if there is part of the process that could be improved. Would a script make building easier? Is some of the documentation confusing? Patches that improve your experience with the kernel will benefit everyone, even small fixes.

The easiest way to have discussions about the Fedora kernel is to use the Fedora kernel mailing list. Bugzilla may also be appropriate if the proposal has to do with a bug. There is also an IRC channel on Freenode, #fedora-kernel.

Happy hacking!