• SPDX

    December 1, 2017 - Mauro Carvalho Chehab

    Linux Kernel License Practices Revisited with SPDX®

    The licensing text in the Linux kernel source files is inconsistent in verbiage and format. Typically, in each of its ~100k files there is a license text that describes which license applies to each specific file. While all licenses are GPLv2 compatible, properly identifying the licenses that are applicable to a specific file is very hard. To address this problem, a group of developers recently embarked on a mission to use SPDX® to research and map these inconsistencies in the licensing text. As a result of this 10 month long effort, the Linux 4.14 release includes changes to make the licensing text consistent across the kernel source files and modules. Linux Kernel License As stated on its COPYING file, the Linux kernel’s default license is GPLv2, with an exception that grants additional rights to the kernel users:

    The kernel’s COPYING file produces two practical effects: User-space applications can use non-GPL […]

    Read More
  • November 29, 2017 - Phil Coval

    Building IoTivity for ARM on ARTIK Devices

    There are several options to build IoTivity for ARM targets or any non x86 hardware, but first you have to decide which operating system you want to use. In this article, I won’t compare OS or devices; instead, I’ll give a couple of hints that apply to ARTIK 5, 7, and 10 devices (not the ARTIK 0 family, which run TizenRT). These steps can also be applied to other single board computers like the Raspberry PI. Build for Tizen with GBS The first and easiest way to build IoTivity is for Tizen, using GBS. This process was explained in a previous article on this blog: An Introduction to Tizen Development on ARTIK For your knowledge, GBS was inspired by Debian’s git-build-package and uses an ARM toolchain that runs in a chrooted ARM environment using QEMU. Both ARTIK boards and the Raspberry Pi are used as Tizen reference platforms. Build for […]

    Read More
  • When debugging kernel problems that aren’t obvious, it’s necessary to understand the history of changes to the source files. For example, a race condition that results in a lockdep warning might have tentacles into multiple code paths. This requires us to examine and understand not only the changes made, but also why they were made. Individual patch commit logs are the best source of the information on why a change was made. So how do we find this information? My goto tool set for such endeavors has been a combination of git gui and git log. Recently I started using cregit. I will go over these options in this blog. git log Running git log on a source file will show all the commits for that file, then you can find the corresponding code change by generating the patch. Using git log can be tedious, but useful for targeted commit […]

    Read More
  • November 3, 2017 - Mike Blumenkrantz

    New Features in Enlightenment 22

    The E22 development cycle has been underway for over a year, and it has included over 1,500 patches to address nearly 200 tickets on our issue tracker. With this has come a number of new features and improvements. Greatly Improved Wayland Support The majority of development for this cycle has gone towards improving Wayland support. This covers, but is not limited to: adding support for xdg-shell v6, pointer constraints, and relative pointer motion protocols. These additions improve XWayland support and increase stability across all components running under Wayland. Continued Improvements to New Gadget Infrastructure As previous posts have indicated, a lot of work is being done in this area. The goal is to create a more robust infrastructure with a simpler and more intuitive EFL-based API, moving away from the legacy “gadcon” interface, which has its own API and currently only functions due to mountains of gadget-specific workarounds that make […]

    Read More
  • In the upcoming Linux 4.14-rc3 release, work continues to develop the Kselftest TAP13 framework API and convert tests to TAP13. The new tests include Kselftest common RUN_TESTS in lib.mk that have been enhanced to print TAP13 to cover test shell scripts that won’t be able to use the Kselftest TAP13 API; this also covers test programs that aren’t converted yet. Several fixes have been made to existing tests to prevent failure in unsupported cases as part of an ongoing work based on feedback from Kselftest stable release users that don’t want the tests to fail due to unmet dependencies, such as config options being disabled. Additionally, a new watchdog test has been added and much needed cleanups to the existing watchdog tests have been made by Eugeniu Rosca. A New Kselftest Use-Case A notable change in this release is new support for the “make O=dir kselftest” use-case.  Several developers rely on this […]

    Read More
  • October 5, 2017 - Mike Blumenkrantz

    How to Create an EFL Gadget Sandbox

    The new gadget API and infrastructure for Enlightenment continue to undergo heavy development. In addition to improving and extending the base gadget UI, work has recently begun on creating a gadget provider with the new API to provide sandboxing and allow gadgets to be written as regular applications that don’t have or require access to compositor internals. The primary enabler of the new sandboxing system is the efl-wl compositor widget. This allows the compositor to launch applications in isolation, and also provides the ability to add protocol extensions for only that specific instance of the compositor widget. Using these features, it becomes possible to add gadget-specific protocols and utilities on the compositor side that are passed through transparently to the client gadget application. Currently, there is one base protocol in use: the e-gadget protocol, which looks like this:

    The purpose of this is to mimic the gadget API. Applications […]

    Read More
  • August 2, 2017 - Bryce Harrington

    Better Attachment Handling with Mutt

    The Mutt email client is famed for its extensive configuration options, but since it’s text-based, certain things are more challenging to do when compared to its graphical brethren. Viewing attachments is one such annoyance; fortunately, as with most things, Mutt is extensively configurable! By default, Mutt does fine with most plain text documents, and depending on your installation may also handle HTML documents in some fashion. Attachments that Mutt doesn’t recognize can of course be downloaded and viewed manually, but we can do better. To tell Mutt that it should handle a new attachment type, or its “MIME type”, we associate it with Mutt’s “auto_view” parameter. For example, add this to your ~/.muttrc (and restart Mutt):

    Note: if you plan to add a number of file types, you may wish to put these in their own config file (e.g. ~/.mutt/auto-views), and include a line in ~/.muttrc like the following: […]

    Read More
  • July 28, 2017 - Shuah Khan

    Kselftest for Linux 4.13 to Include TAP13

    Linux 4.13-rc1 was released on July 15th 2017  and it includes enhancements to the Kselftest framework to support The Test Anything Protocol v13 (TAP13). TAP13 defines a human friendly output format for tests. Kselftest is run in test rings and is widely used for Linux kernel stable release regression testing. It’s important to make it easier to identify run-to-run differences; TAP13 adaption makes it easier to understand the test results, and helps pin point differences between one run to another run of the test suite. Credit goes to Tim Bird for recommending TAP13 as a suitable format, and to Greg KH for kick starting the work with help from Paul Elder and Alice Ferrazzi. The first phase of the TAP13 conversion is included in Linux 4.13. Future releases will include updates to rest of the tests. The following shows membarrier test results before and after TAP 13 conversion: Before:

    After: […]

    Read More
  • The X.org Foundation is a non-profit governance entity charged with overseeing core components of the open source graphics community. X.org had been structured as a legal (non-profit) corporate entity registered in the state of Delaware for some years, which provided tax deduction on donations and other such benefits. Unfortunately, being a non-profit is not cheap and entails various administrative tasks – filing annual reports, maintaining a bank account, dealing with donations and expenses, and so on – so the overhead of being an independent non-profit was deemed not worth the benefits, and in 2016 the members voted to join Software in the Public Interest (SPI). Joining SPI made a lot of sense; primarily, it would relieve X.org of administrative burdens while preserving the benefits of non-profit status. The costs of being in SPI are offset by the savings of not having to pay the various fees required to upkeep the […]

    Read More
  • July 18, 2017 - Bryce Harrington

    Introduction to GPG Encryption and git-crypt

    While Open Source prides itself on open transparency, there are certain things that must be kept secret like team credentials or personal information.  GNU’s OpenPGP (GPG) encryption tool set coupled with git-crypt can be invaluable for sharing such information privately with colleagues. For people unfamiliar with GPG it can seem a bit intimidating to start with, but it needn’t be! This article is a step-by-step introduction to getting set up with your own GPG key. Install GPG Since GPG has become pretty ubiquitous it should be straightforward to install via the usual method for your operating system. debian/ubuntu:

    OSX (using ports):

    etc. Create Your Own GPG Key Easy enough! The following command will ask for the info needed to make the key. Pick RSA with a key length of 4096 bits, and be very careful to set a unique GPG password that you’re not using anywhere else (but pick one you can remember!):

    […]

    Read More
1 2 3 22