Feeds

myDropWizard.com: Drupal 6 supports MySQL 8 (starting in Drupal 6.51)

Planet Drupal - Tue, 2019-05-21 10:17

As you probably know, Drupal 6 reached its End-of-Life (EOL) on February 24th, 2016. However, the mantle of supporting Drupal 6 was taken up by the Drupal 6 Long-Term Support vendors - including the team here at myDropWizard!

Long-Term Support isn't glamorous or exciting.

It's making security releases. It's minor bug fixes. Sometimes it's updating a contrib module that hasn't had an official release since 2009 to work with PHP 7. :-)

In fact, a big part of Drupal 6 Long-Term Support (D6LTS) is updating Drupal 6 core and contrib to work with new technologies, especially as the older versions that it was originally designed to work with become deprecated or reach their own EOL, like when PHP 5 reached its EOL at the end of last year. (Did you know that Drupal 6 now works with PHP 7?)

Today, I'd like to announce that Drupal 6 supports MySQL 8, starting with Drupal 6.51!

This was implemented in collaboration with the community, largely the contributions of f1mishutka, but also a number of others who contributed testing and bug reports.

I know there's a lot of anxiety over how Drupal 7 Extended Support (D7ES) is going to work, however, I think that this is more evidence that the vendor-supported model used by D6LTS (and soon, D7ES) is working.

You can download the latest Drupal 6 LTS core release from GitHub.

Categories: FLOSS Project Planets

Raphaël Hertzog: Freexian’s report about Debian Long Term Support, April 2019

Planet Debian - Tue, 2019-05-21 10:11

Like each month, here comes a report about the work of paid contributors to Debian LTS.

Individual reports

In April, 204 work hours have been dispatched among 14 paid contributors. Their reports are available:

  • Abhijith PA did 4 hours (out of 14 hours allocated, thus carrying over 10 hours to May).
  • Adrian Bunk did 8 hours (out of 8 hours allocated).
  • Ben Hutchings did 31.25 hours (out of 17.25 hours allocated plus 14 extra hours from April).
  • Brian May did 10 hours (out of 10 hours allocated).
  • Chris Lamb did 17 hours (out of 17.25 hours allocated, thus carrying over 0.25h to May).
  • Emilio Pozuelo Monfort did 8 hours (out of 17.25 hours allocated + 6 extra hours from March, thus carrying over 15.25h to May).
  • Hugo Lefeuvre did 17.25 hours.
  • Jonas Meurer did 14 hours (out of 14 hours allocated).
  • Markus Koschany did 17.25 hours.
  • Mike Gabriel did 11.5 hours (out of 17.25 hours allocated, thus carrying over 5.75h to May).
  • Ola Lundqvist did 5.5 hours (out of 8 hours allocated + 1.5 extra hours from last month, thus carrying over 4h to May).
  • Roberto C. Sanchez did 1.75 hours (out of 12 hours allocated, thus carrying over 10.25h to May).
  • Sylvain Beucler did 17.25 hours.
  • Thorsten Alteholz did 17.25 hours.
Evolution of the situation

During this month, and after a two-year break, Jonas Meurer became again an active LTS contributor. Still, we continue to be looking for new contributors. Please contact Holger if you are interested to become a paid LTS contributor.

The number of sponsors did not change. There are 58 organizations sponsoring 215 work hours per month.

The security tracker currently lists 33 packages with a known CVE and the dla-needed.txt file has 31 packages needing an update.

Thanks to our sponsors

New sponsors are in bold.

No comment | Liked this article? Click here. | My blog is Flattr-enabled.

Categories: FLOSS Project Planets

Neckbeard Republic: Interactive Data Visualization in Python With Bokeh

Planet Python - Tue, 2019-05-21 10:00
This course will get you up and running with Bokeh, using examples and a real-world dataset. You'll learn how to visualize your data, customize and organize your visualizations, and add interactivity.
Categories: FLOSS Project Planets

Red Hat Developers: Use the Kubernetes Python client from your running Red Hat OpenShift pods

Planet Python - Tue, 2019-05-21 09:39

Red Hat OpenShift is part of the Cloud Native Computing Foundation (CNCF) Certified Program, ensuring portability and interoperability for your container workloads. This also allows you to use Kubernetes tools to interact with an OpenShift cluster, like kubectl, and you can rest assured that all the APIs you know and love are right there at your fingertips.

The Kubernetes Python client is another great tool for interacting with an OpenShift cluster, allowing you to perform actions on Kubernetes resources with Python code. It also has applications within a cluster. We can configure a Python application running on OpenShift to consume the OpenShift API, and list and create resources. We could then create containerized batch jobs from the running application, or a custom service monitor, for example. It sounds a bit like “OpenShift inception,” using the OpenShift API from services created using the OpenShift API.

In this article, we’ll create a Flask application running on OpenShift. This application will use the Kubernetes Python client to interact with the OpenShift API, list other pods in the project, and display them back to the user.

You’ll need a couple of things to follow along:

  • An OpenShift cluster
  • A working knowledge of Python

Let’s get started!

Setup

I’ve created a template to alleviate a lot of the boilerplate, so let’s clone it down:

git clone https://github.com/shaneboulden/openshift-client-demo cd openshift-client-demo

You can create a new app on your OpenShift cluster using the provided template and see the application running:

oc new-app openshift_deploy/ocd.yaml

If you do an oc get routes, you’ll be able to see the route that’s been created. For now, if you select the Pods menu item you’ll just get some placeholder text. We’ll fix this shortly

Configure the Kubernetes Python client

Listing pods is trivial once we have our client configured, and, fortunately, we can use a little Kubernetes Python client magic to configure this easily with the correct service account token.

Usually, we’d configure a Kubernetes client using a kubeconfig file, which has the required token and hostname to create API requests. The Kubernetes Python client also provides a method load_incluster_config(), which replaces the kubeconfig file in a running pod, instead using the available environment variables and mount points to find the service account token and build API URLs from the information available within the pod.

There’s another huge benefit to using load_incluster_config()—our code is now portable. We can take this same application to any Kubernetes cluster, assume nothing about hostnames or network addresses, and easily construct API requests using this awesome little method.

Let’s configure our application to use the load_incluster_config() method. First, we need to import the client and config objects, you can verify this in the ocd.py file:

from kubernetes import client, config

We can now use that magic method to configure the client:

config.load_incluster_config() v1 = client.CoreV1Api()

That’s it! This is all of the code we need to be able to interact with the OpenShift API from running pods.

Use the Kubernetes Downward API

I’m going to introduce something new here, and yes, it’s another “OpenShift-inception” concept. We’re going to use the list_namespaced_pod method to list pod details; you can find all of the methods available in the documentation. To use this method, we need to pass the current namespace (project) to the Kubernetes client object. But wait, how do we get the namespace for our pod, from inside the running pod?

This is where another awesome Kubernetes API comes into play. It’s called the Downward API and allows us to access metadata about our pod from inside the running pod. To expose information from the Downward API to our pod, we can use environment variables. If you look at the template, you’ll see the following in the ‘env’ section:

- name: POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace Bring it all together

Now let’s get back to our /pods route in the ocd.py file. The last thing we need to do is to pass the namespace of the app to the Kubernetes client. We have our environment variable configured to use the downward API already, so let’s pass it in:

pods = v1.list_namespaced_pod(namespace=os.environ["POD_NAMESPACE"])

Ensure you’re in the top-level project directory (i.e., you can see the README) and start a build from the local directory:

oc start-build openshift-client-demo --from-dir=.

When you next visit the route and select the Pods menu, you’ll be able to see all of the pods for the current namespace:

I hope you’ve enjoyed this short introduction to the Kubernetes Python client. If you want to explore a little deeper, you can look at creating resources. There’s an example here that looks at creating containerized batch jobs from API POSTs.

The post Use the Kubernetes Python client from your running Red Hat OpenShift pods appeared first on Red Hat Developer Blog.

Categories: FLOSS Project Planets

ComputerMinds.co.uk: Upgrading your site to Drupal 8 or 9

Planet Drupal - Tue, 2019-05-21 08:57

Your current website/platform is built on Drupal 7 and news has hit your ears about 7’s end of life (EOL). Maybe your site is a Drupal 8 site and you want to know what the future has in store for you. Good news is, you don’t have to do anything immediately, but it is definitely a question that you want to start thinking about very soon.

This article is mainly aimed at Drupal 7 builds looking to upgrade to 8 or 9, and we will explore the pros and cons of each. However, if your current platform is based on Drupal 8 and you want to know what your options are with regards to Drupal 9, you can skip to here. Or, if like my fence (yes, that really is my fence and it is in desperate need of an upgrade), you require an upgrade, skip down to see what we can do for you.

Drupal 7’s EOL is November 2021, which is a little way off yet, but it’ll soon creep up on you (very much like my fast approaching wedding day… eek!)! So what does EOL mean? After End of Life in November 2021, Drupal 7 will stop receiving official support: this means no more security fixes and no more new features. Any new ‘Drupalgeddon’ security issues will be ignored, leaving Drupal 7 sites open to attack; we saw a minority of sites being used as bitcoin miners last year as a result of sites not being patched… this is just an example of what could/can happen!

There appear to be talks in the Drupal community about providing LTS (“Long Term Support”) programmes, offering continued support for Drupal 7. Community LTS tends to cover security issues mostly, with minor functionality updates. But if you want the longest term security support prospects, whilst also being on the platform best suited to growth, ongoing development and support we would advise that you don’t look to the D7 LTS programmes.

Crucially, a Drupal 7 to 9 upgrade will largely be the same as a 7 to 8 upgrade - you won’t be missing out on too much; you’ll just wait longer for the new goodness that 7 doesn’t have!

The best option, therefore, is to consider an upgrade. But which version do you go for? Should you go straight in for Drupal 8, or stay longer on your beloved Drupal 7 and switch over to 9 nearer 7’s end of life? Let’s look at the options.

 

Benefits of migrating to Drupal 8

 

Drupal 8 was a complete ground-up rewrite of Drupal 7. D7 was written without a known framework and without utilising Object Orientation, meaning a majority of Drupal 7 was written procedurally; this can make code hard to maintain and inefficient, resulting in a loss of page load performance. Using a framework that is built upon an OO philosophy ensures clearer code that it is easier to maintain, read, and modify - all of which results in a faster, more secure site.

Drupal 8 also runs on PHP 7 as standard; PHP 7 is *much* faster than its predecessor. In addition, D8 utilises a new theming engine called Twig - with benefits that include better security (Twig automatically sanitises user input, for example) and a big emphasis on separation of business logic and presentation as well as being fast and flexible. It also includes nice features such as inline editing, handy for those sites that have lots of ever changing content; this should save you a few clicks of a mouse and multiple page loads! Drupal 8 is also continuing to add new features, like the anticipated Layout builder (which you can read all about here), the newly incorporated media handling and big pipe!

 

Can’t I just upgrade straight to Drupal 9 when it is released?

 

Well you could, but we would recommend not to. Drupal 9’s release is only around the corner, much like Drupal 7’s EOL. 9 is due to be in our hands mid-late 2020. This overlap has been cleverly timed with Drupal 7’s EOL to allow Drupal 7 sites to upgrade to Drupal 9 with time to spare before EOL. So what is the difference between Drupal 8 and 9 and why do we recommend to upgrade to Drupal 8 first?

Drupal 9 - in Layman’s terms - will be a “cleaner” version of the latest Drupal 8 version; they’re essentially the same thing, minus some deprecated code that was present at the start of Drupal 8’s life. (Deprecated code is code that is due to be decommissioned and re-written/re-integrated at a later date. The code is still safe and usable, but if you upgrade in the future, you might have a job on your hands converting all the deprecated code with their replacements. Rule of thumb, always use the newer version if it’s available to avoid future headaches).

Crucially, a Drupal 7 to 9 upgrade will largely be the same as a 7 to 8 upgrade - you won’t be missing out on too much; you’ll just wait longer for the new goodness that 7 doesn’t have! Drupal 9 will also include updates to external libraries/dependencies, which it relies upon, not to mention any new features that’ll it have over 8. At time of writing, we are unsure of what these might be!

The only foreseeable benefit we can see for waiting for Drupal 9 (over 8) is that you get to stay on your tried and trusted Drupal 7 site for a year or two longer whilst giving you maximum time to plan for that eventual upgrade.

 

How easy is it to upgrade my site?

 

At the start of Drupal 8’s life, one of the major goals that 8 wanted to get right over D7 was migration. Therefore, a big emphasis was placed on making sure that migrations were easier and less painful to do, particularly since it (core) would have a completely different architecture. As a result, migrations from 7 to 8 (or 9) are somewhat nicer than those who upgraded from 6 to 7 (Checkout our Conservative Party case study where we migrated an entire Drupal 6 platform to 8)

Some of you who have been reading our articles for the last few years will notice we underwent a huge change - not only did we re-brand, but we also upgraded from 7 to 8 - all of which you can read about, including all the trials and tribulations we experienced.
Drupal 8’s built in migration tools are a huge improvement over 7 and the Drupal community has created some really neat modules too, some that will provide a good starting point for any migration mappings that you may need…  However, any custom code/custom field structures will need additional plugins and migration mappings without discounting an entire re-write of any HTML template files due to the new theme engine Twig.

As far as we are currently aware, a Drupal 8 to 9 migration will be *much* easier than a 7 to 8 migration. Those who have a Drupal 8 site see their minor version (8.5, 8.6, 8.7 etc etc) updated every 6 months with very little hiccups. A Drupal 8 to 9 migration will be not too dissimilar to the minor version updates that current Drupal 8 owners experience today. One of the very few exceptions being that any deprecated code (as explained above) will need converting; upgrading all contrib modules and performing a full custom code audit to make sure this works with the new version of Drupal. The data structures will remain intact as will the theme engine so no need to write new migration mappings or to convert any HTML templates - these tend to make up the bulk of the work for any Drupal migration.

 

What can ComputerMinds do for you?

 

We, at ComputerMinds, have experience of all the different types of upgrade paths that are available to you. Back in the day, we conducted full Drupal 6 to Drupal 7 migrations (no easy feat), but more recently, we have done Drupal 7 to Drupal 8 upgrades (as we mentioned before, in addition to upgrading some of our clients from 7 to 8, we also carried out our own upgrade for this very site) and even Drupal 6 to Drupal 8 upgrades. So we have a wealth of experience and skill.

Furthermore, choosing to upgrade your site is the perfect time to review your current brand, the look and feel of your site and to add any new features that may be in your pipeline. Any new/additional changes are a lot easier to incorporate during the upgrade phase than later down the line; it’s cheaper because we can do all the changes in development phase and it’ll also mean you’ll get shiny, new things quicker - so something definitely worth thinking about.

This article has been written to highlight what options are available now and in the future; we certainly won’t force anyone to upgrade their site, but will always do our best to make people aware of what is coming up in terms of Drupal’s life. With the e-commerce world always advancing, you definitely can’t stand still for long, so this topic will certainly need to be thought about. We also won’t be able to facilitate upgrading everyone in 2021, so please do plan ahead!

Drupal 8 is in the best possible place today. Most of the contributed modules have either been converted from 7 to 8, or brand new modules that have been created in emulate functionality from Drupal 7 that simply didn’t exist for 8. The webform module for example, a staple on 99% of our sites, wasn’t available for a long time due to the time it took to completely rewrite it - a worthwhile wait in our eyes as it is a big improvement over its 7 version. We are currently recommending any new site builds that come our way to start life as a Drupal 8 site. It gets a big thumbs up from us!

If you’ve liked what you’ve read and feel like you’re ready - or in a position - to start thinking about a site upgrade, why not start a conversation with us today either by way of live chat or using our contact form. We’d love to hear from you and look forward to seeing what benefits we can bring to your site.

Categories: FLOSS Project Planets

qed42.com: Pune Drupal Group Meetup - May 2019

Planet Drupal - Tue, 2019-05-21 08:05
Pune Drupal Group Meetup - May 2019 Body

QED42 has always been an ardent participant in the Drupal community. We pride ourselves for contributing to the Drupal community via modules, code patches, Drupal initiatives, DrupalCons, DrupalCamps or hosting Meetups!

Drupal Meetups play an integral role in fostering community. Dries Buytaert was quoted on Drupal.org’s getting involved page:

It’s really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.

We hosted the Pune Drupal Group monthly meetup on 18th May 2019 at our office. The healthy turnout to the local meetup was a reflection of how connected the Pune Drupal Community was.

Packed with people, plenty of snacks, and laptops our Meetup commenced. After a brief introduction from all the attendees, the lights dimmed and Meena Bisht from QED42 started her session ‘ Be Ready for Drupal 9!’

 

 

 

 

 

 

 

It was a highly interactive session that pivoted around Drupal’s ever-evolving nature. She spoke about how long Drupal 7 will be supported, Drupal 8 end of life, and how it would impact businesses. Drupal 8.7 features - Layout Builder and Media Library and challenges faced while moving from Drupal 7 to Drupal 8.

 

 

 

 

 

 

 

We welcomed the newest member to the family, Drupal 9.

 

 

 

 

 

 

 

The session also covered the Drupal release cycle, which justified the difficulties faced while moving to Drupal 8. We were relieved to know that upgrading to Drupal 9 would be a lot easier thanks to the minor upgrades.

The session shed light on why an upgrade is required, and what to expect out of Drupal 9. We ended the session with useful tips on tools for checking our deprecated code while preparing for Drupal 9.

 

 

 

 

 

 

 

Post session, we discussed the hurdles faced during the earlier version releases, our inhibitions, and expectations from Drupal 9.

After a quick break with refreshments and offline chats, we gathered back for the BoF session on the configuration management system. We discussed the origin of configuration management, as a Drupal initiative, the different configuration issues faced by us and identified solutions.

Lastly, we chalked out a map for the DrupalCamp Pune. All the attendees brought helpful ideas to the table, location, sessions, sponsorships, etc.

After an informative and super lucrative agenda of sessions, BoF, and DrupalCamp Pune planning, we wrapped up our Meetup.


 

 

ruchika.mohite Tue, 05/21/2019 - 17:35
Categories: FLOSS Project Planets

Jacob Rockowitz: Sponsor a Feature

Planet Drupal - Tue, 2019-05-21 07:46

Three years ago, I started to talk about "coming to an agreement within the Drupal community and sponsoring a Webform feature." In that blog post, I discussed creating a reusable and free-to-use agreement template with a defined process which could make it easier for organizations to sponsor feature requests. Now I want to share my current process for handling sponsored feature requests to the Webform module for Drupal 8.

For the past three years, organizations have reached out to me for paid support and feature requests. Adding the ability to import submissions was a feature request paid for by Kennesaw State University. Only two parts of my transaction with Kennesaw State University were publicly visible, the issue on Drupal.org (#2902977) and a blog post.

Sharing my process for handling paid feature requests will hopefully clarify how organizations can sponsor a feature for the Webform module and other Drupal and Open Source projects.

Steps for sponsoring a feature

Sponsoring a feature can be broken down into four key steps:

  • Communication

  • Documentation

  • Agreement

  • Payment

Communication

Good communication is one of the keys to the success of any Open Source project. Currently, there are several approaches to initiating the communication process for a sponsored feature.

The easiest and most immediate way to start a sponsored feature request is to create a user...Read More

Categories: FLOSS Project Planets

Srijan Technologies: The Modern Guide to Building the Right Content Strategy with Drupal

Planet Drupal - Tue, 2019-05-21 06:00

To keep up with consumer demand, businesses need to tactically rethink and reform the way they produce and manage content. 

What you need is a way to stand out in the consistent content chaos. To make that happen, you need a strategy that can help:

  • push out content intuitively
  • transform disorganized assets into a comprehensive manner
  • manage real-time collaboration effectively

And that’s where the role of a CMS is important.

Here’s a comprehensive guide to building the right content strategy with Drupal, focusing primarily on the technological aspect, which will help you build and establish the right notes with your audience.

Categories: FLOSS Project Planets

GNU Guix: Creating and using a custom Linux kernel on Guix System

GNU Planet! - Tue, 2019-05-21 06:00

Guix is, at its core, a source based distribution with substitutes, and as such building packages from their source code is an expected part of regular package installations and upgrades. Given this starting point, it makes sense that efforts are made to reduce the amount of time spent compiling packages, and recent changes and upgrades to the building and distribution of substitutes continues to be a topic of discussion within Guix.

One of the packages which I prefer to not build myself is the Linux-Libre kernel. The kernel, while not requiring an overabundance of RAM to build, does take a very long time on my build machine (which my children argue is actually their Kodi computer), and I will often delay reconfiguring my laptop while I want for a substitute to be prepared by the official build farm. The official kernel configuration, as is the case with many GNU/Linux distributions, errs on the side of inclusiveness, and this is really what causes the build to take such a long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package installed on my machine, and as such can be customized just like any other package. The procedure is a little bit different, although this is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which creates a package.

(define* (make-linux-libre version hash supported-systems #:key ;; A function that takes an arch and a variant. ;; See kernel-config for an example. (extra-version #f) (configuration-file #f) (defconfig "defconfig") (extra-options %default-extra-linux-options) (patches (list %boot-logo-patch))) ...)

The current linux-libre package is for the 5.1.x series, and is declared like this:

(define-public linux-libre (make-linux-libre %linux-libre-version %linux-libre-hash '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux") #:patches %linux-libre-5.1-patches #:configuration-file kernel-config))

Any keys which are not assigned values inherit their default value from the make-linux-libre definition. When comparing the two snippets above, you may notice that the code comment in the first doesn't actually refer to the #:extra-version keyword; it is actually for #:configuration-file. Because of this, it is not actually easy to include a custom kernel configuration from the definition, but don't worry, there are other ways to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration. The first is to provide a standard .config file during the build process by including an actual .config file as a native input to our custom kernel. The following is a snippet from the custom 'configure phase of the make-linux-libre package definition:

(let ((build (assoc-ref %standard-phases 'build)) (config (assoc-ref (or native-inputs inputs) "kconfig"))) ;; Use a custom kernel configuration file or a default ;; configuration file. (if config (begin (copy-file config ".config") (chmod ".config" #o666)) (invoke "make" ,defconfig))

Below is a sample kernel package for one of my computers. Linux-Libre is just like other regular packages and can be inherited and overridden like any other:

(define-public linux-libre/E2140 (package (inherit linux-libre) (native-inputs `(("kconfig" ,(local-file "E2140.config")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre))))))

In the same directory as the file defining linux-libre-E2140 is a file named E2140.config, which is an actual kernel configuration file. I left the defconfig keyword of make-linux-libre blank, so the only kernel configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the extra-options keyword of the make-linux-libre procedure. The extra-options keyword works with another function defined right below it:

(define %default-extra-linux-options `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t) ;; Modules required for initrd: ("CONFIG_NET_9P" . m) ("CONFIG_NET_9P_VIRTIO" . m) ("CONFIG_VIRTIO_BLK" . m) ("CONFIG_VIRTIO_NET" . m) ("CONFIG_VIRTIO_PCI" . m) ("CONFIG_VIRTIO_BALLOON" . m) ("CONFIG_VIRTIO_MMIO" . m) ("CONFIG_FUSE_FS" . m) ("CONFIG_CIFS" . m) ("CONFIG_9P_FS" . m))) (define (config->string options) (string-join (map (match-lambda ((option . 'm) (string-append option "=m")) ((option . #t) (string-append option "=y")) ((option . #f) (string-append option "=n"))) options) "\n"))

And in the custom configure script from the make-linux-libre package:

;; Appending works even when the option wasn't in the ;; file. The last one prevails if duplicated. (let ((port (open-file ".config" "a")) (extra-configuration ,(config->string extra-options))) (display extra-configuration port) (close-port port)) (invoke "make" "oldconfig"))))

So by not providing a configuration-file the .config starts blank, and then we write into it the collection of flags that we want. Here's another custom kernel which I have:

(define %macbook41-full-config (append %macbook41-config-options %filesystems %efi-support %emulation (@@ (gnu packages linux) %default-extra-linux-options))) (define-public linux-libre-macbook41 ;; XXX: Access the internal 'make-linux-libre' procedure, which is ;; private and unexported, and is liable to change in the future. ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version) (@@ (gnu packages linux) %linux-libre-hash) '("x86_64-linux") #:extra-version "macbook41" #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches) #:extra-options %macbook41-config-options))

From the above example %filesystems is a collection of flags I compiled enabling different filesystem support, %efi-support enables EFI support and %emulation enables my x86_64-linux machine to act in 32-bit mode also. %default-extra-linux-options are the ones quoted above, which had to be added in since I replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know which modules are required for their system? The two places I found most helpful to try to answer this question were the Gentoo Handbook, and the documentation from the kernel itself. From the kernel documentation, it seems that make localmodconfig is the command we want.

In order to actually run make localmodconfig we first need to get and unpack the kernel source code:

tar xf $(guix build linux-libre --source)

Once inside the directory containing the source code run touch .config to create an initial, empty .config to start with. make localmodconfig works by seeing what you already have in .config and letting you know what you're missing. If the file is blank then you're missing everything. The next step is to run:

guix environment linux-libre -- make localmodconfig

and note the output. Do note that the .config file is still empty. The output generally contains two types of warnings. The first start with "WARNING" and can actually be ignored in our case. The second read:

module pcspkr did not have configs CONFIG_INPUT_PCSPKR

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the .config in the directory, and append =m, so in the end it looks like this:

CONFIG_INPUT_PCSPKR=m CONFIG_VIRTIO=m

After copying all the configuration options, run make localmodconfig again to make sure that you don't have any output starting with "module". After all of these machine specific modules there are a couple more left that are also needed. CONFIG_MODULES is necessary so that you can build and load modules separately and not have everything built into the kernel. CONFIG_BLK_DEV_SD is required for reading from hard drives. It is possible that there are other modules which you will need.

This post does not aim to be a guide to configuring your own kernel however, so if you do decide to build a custom kernel you'll have to seek out other guides to create a kernel which is just right for your needs.

The second way to setup the kernel configuration makes more use of Guix's features and allows you to share configuration segments between different kernels. For example, all machines using EFI to boot have a number of EFI configuration flags that they need. It is likely that all the kernels will share a list of filesystems to support. By using variables it is easier to see at a glance what features are enabled and to make sure you don't have features in one kernel but missing in another.

Left undiscussed however, is Guix's initrd and its customization. It is likely that you'll need to modify the initrd on a machine using a custom kernel, since certain modules which are expected to be built may not be available for inclusion into the initrd.

Suggestions and contributions toward working toward a satisfactory custom initrd and kernel are welcome!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

Categories: FLOSS Project Planets

FSF Events: Richard Stallman - "Copyright vs Community in the age of computer networks" (Nicosia, Cyprus)

GNU Planet! - Tue, 2019-05-21 05:53

Richard Stallman will be speaking at the Unconference (2019-05-30–06-01).

Copyright developed in the age of the printing press, and was designed to fit with the system of centralized copying imposed by the printing press. But the copyright system does not fit well with computer networks, and only draconian punishments can enforce it. The global corporations that profit from copyright are lobbying for draconian punishments, and to increase their copyright powers, while suppressing public access to technology. But if we seriously hope to serve the only legitimate purpose of copyright–to promote progress, for the benefit of the public–then we must make changes in the other direction.

This speech will be nontechnical, admission is gratis, and the public is encouraged to attend.

Location: University of Nicosia, Cyprus

Please fill out our contact form, so that we can contact you about future events in and around Nicosia.

Categories: FLOSS Project Planets

Agiledrop.com Blog: Optimizing Images with Drupal 8 Core Features

Planet Drupal - Tue, 2019-05-21 04:27

In this post, we’ll take a look at what you need to consider when preparing images for the web and how Drupal 8 can help you make this process automatic.

READ MORE
Categories: FLOSS Project Planets

Test and Code: 74: Technical Interviews: Preparing For, What to Expect, and Tips for Success - Derrick Mar

Planet Python - Tue, 2019-05-21 03:00

In this episode, I talk with Derrick Mar, CTO and co-founder of Pathrise.
This is the episode you need to listen to to get ready for software interviews.

  • We discuss four aspects of technical interviews that interviewers are looking for:

    • communication
    • problem solving
    • coding
    • verification
  • How to practice for the interview.

  • Techniques for synchronizing with interviewer and asking for hints.

  • Even how to ask the recruiter or hiring manager how to prepare for the interview.

If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up, and give you concrete tips on how to do better during the interview.

Special Guest: Derrick Mar.

Sponsored By:

Support Test & Code - Software Testing, Development, Python

Links:

<p>In this episode, I talk with Derrick Mar, CTO and co-founder of Pathrise.<br> This is the episode you need to listen to to get ready for software interviews.</p> <ul> <li><p>We discuss four aspects of technical interviews that interviewers are looking for:</p> <ul> <li>communication</li> <li>problem solving</li> <li>coding</li> <li>verification</li> </ul></li> <li><p>How to practice for the interview.</p></li> <li><p>Techniques for synchronizing with interviewer and asking for hints.</p></li> <li><p>Even how to ask the recruiter or hiring manager how to prepare for the interview.</p></li> </ul> <p>If you or anyone you know has a software interview coming up, this episode will help you both feel more comfortable about the interview before you show up, and give you concrete tips on how to do better during the interview.</p><p>Special Guest: Derrick Mar.</p><p>Sponsored By:</p><ul><li><a href="http://amzn.to/2E6cYZ9" rel="nofollow">Python Testing with pytest</a>: <a href="http://amzn.to/2E6cYZ9" rel="nofollow">Simple, Rapid, Effective, and Scalable The fastest way to learn pytest. From 0 to expert in under 200 pages.</a></li><li><a href="https://www.patreon.com/testpodcast" rel="nofollow">Patreon Supporters</a>: <a href="https://www.patreon.com/testpodcast" rel="nofollow">Help support the show with as little as $1 per month. Funds help pay for expenses associated with the show.</a></li></ul><p><a href="https://www.patreon.com/testpodcast" rel="payment">Support Test & Code - Software Testing, Development, Python</a></p><p>Links:</p><ul><li><a href="https://testandcode.com/72" title="72: Technical Interview Fixes - April Wensel" rel="nofollow">72: Technical Interview Fixes - April Wensel</a></li><li><a href="https://www.pathrise.com/" title="Pathrise" rel="nofollow">Pathrise</a></li></ul>
Categories: FLOSS Project Planets

codingdirectional: Growth of a Population

Planet Python - Mon, 2019-05-20 23:49

Hello and welcome back, in this episode we are going to solve a python related problem in Codewars. Before we start I just want to say that this post is related to python programming, you are welcome to leave your comments below this post if and only if they are related to the below solution, kindly do not leave any comment which has nothing to do with python programming under this article, thank you.

In a small town, the population isat p0 = 1000 at the beginning of a year. The population regularly increases by 2 percent per year and moreover, 50 new inhabitants per year come to live in the town. How many years does the town need to see its population greater or equal to p = 1200inhabitants? You need to round up the percentage part of the equation. Below is the entire solution to this question.

At the end of the first year there will be: 1000 + 1000 * 0.02 + 50 => 1070 inhabitants At the end of the 2nd year there will be: 1070 + 1070 * 0.02 + 50 => 1141 inhabitants (number of inhabitants is an integer) At the end of the 3rd year there will be: 1141 + 1141 * 0.02 + 50 => 1213 It will need 3 entire years.

So how are we going to turn the above population equation into a function?

def nb_year(p0, percent, aug, p): # p0 is the present total population, aug is the number of new inhabitants per year and p is the target population needs to be surpassed perc = round(p0 * percent/100) total_population = p0 + (perc) + aug year = 1 while(total_population < p): perc = round(total_population * percent/100) total_population = total_population + perc + aug year += 1 return year

Simple solution, hope you do enjoy this post. We will start a new project soon so stay tuned!

Categories: FLOSS Project Planets

[GSoC – 1] Achieving consistency between SDDM and Plasma

Planet KDE - Mon, 2019-05-20 20:43

I’m very excited to start off the Google Summer of Code blogging experience regarding the project I’m doing with my KDE mentors David Edmundson and Nate Graham. What we’ll be trying to achieve this summer is have SDDM be more in sync with the Plasma desktop. What does that mean? The essence of the problem...... Continue Reading →

Categories: FLOSS Project Planets

Andre Roberge: Test - please ignore

Planet Python - Mon, 2019-05-20 16:40
Simple test to embed a gist.


That's all.
Categories: FLOSS Project Planets

Drupal Association blog: Announcing the Drupal Community Working Group Review Panel

Planet Drupal - Mon, 2019-05-20 15:00

The Drupal Community Working Group (CWG) consists of volunteers who help promote the health of the Drupal community; maintain and uphold the Drupal Code of Conduct; and act as an escalation point to help mediate conflict between community members.

In December of 2018, following extensive input and feedback from the community, the CWG proposed a new charter to Dries and the board of the Drupal Association. This new charter changed the oversight of the group from the project lead (Dries) to a three-person Review Panel consisting of the two community-elected members of the Drupal Association Board along with an independent representative from a different open source project who is appointed by the full Association Board. The new charter also included an expanded mandate to focus on proactive measures for community health. Dries supported these changes as did the Association Board.

An important next step following these changes was to fully appoint the CWG Review Committee. The Drupal Association worked in the first part of 2019 to identify candidates for the third party seat of this panel.

At DrupalCon Seattle we were pleased to announce that the Review Panel is fully staffed. The current members are now:

Suzanne Dergacheva

Member of the Drupal Association Board. Elected by the community to a two-year term in 2018, Suzanne is a community leader and co-founder of Evolving Web.

Ryan Szrama

Member of the Drupal Association Board. Elected by the community to a two-year term in 2017, Ryan is a longtime community member and contributor to Drupal, as well as the founder and CEO of Centarro.

Jono Bacon

Jono Bacon is an experienced community strategist, speaker, author, and podcaster —and has consulted with a number of proprietary and open source organizations on community strategy and culture. The third seat of the panel has a term set by the board of the Drupal Association upon appointment, typically lasting 2 years.

What is the role of the Review Panel?

The Review Panel's mandate includes approving the appointment of new members of the CWG and acting as the escalation point for Community Working Group issues. The CWG Review Panel serves as the final escalation point for CWG matters, though in exceptional cases where an issue may represent a significant concern to the whole project, the panel may escalate an issue to the full Drupal Association Board.

The Review Panel’s mandate only extends to issues that are appealed to it if one of the involved parties feels a decision of the CWG is unreasonable. The Review Panel is not responsible for reviewing decisions that take place outside of the CWG process (such as Drupal.org terms of service violations, DrupalCon Code of Conduct violations resolved directly by Association staff, or other issues that have been escalated to the full board of the Drupal Association). Requests to review those decisions must be referred to the party that made the decision.

The Review Panel is not involved in the CWG’s day-to-day activities; only matters that are brought to it as part of the appeals process, or at the discretion of the CWG. The Review Panel may, however, consult with the members of the Community Working Group to help them develop programs for proactively supporting community health.

How do the Drupal Association and the CWG work together?

Under its new charter, the CWG is able to draw upon the resources of the Drupal Association, including legal advice and protection. It is also better equipped to proactively address the needs of the Drupal community.

For example, at DrupalCon Seattle the CWG presented a workshop on developing strategies for effective and inclusive group communication with the help of funding from the Drupal Association. The CWG is also currently soliciting feedback from the community as it prepares to review and update the Drupal Code of Conduct.

These are among the first of what we hope will be many initiatives to promote the health and well-being of the Drupal community, and to enhance volunteer leadership skills and sustainability as we continue to help make the Drupal community one of the most compassionate, inclusive, and intentional communities in open source.

Categories: FLOSS Project Planets

Codementor: Python's Counter - Part 2

Planet Python - Mon, 2019-05-20 11:03
This is the second part of the Counter tutorial sequel. It explores certain behaviour of Counter.
Categories: FLOSS Project Planets

Curtis Miller: What is the probability that in a box of a dozen donuts picked from 14 flavors there’s no more than 3 flavors in the box?

Planet Python - Mon, 2019-05-20 11:00
Dave's Donuts offers 14 flavors of donuts (consider the supply of each flavor as being unlimited). The “grab bag” box consists of flavors randomly selected to be in the box, each flavor equally likely for each one of the dozen donuts. What is the probability that at most three flavors are in the grab bag box of a dozen?
Categories: FLOSS Project Planets

Linux perf and KCachegrind

Planet KDE - Mon, 2019-05-20 10:18

If you occassionally do performance profiling as I do, you probably know Valgrind's Callgrind and the related UI KCachegrind. While Callgrind is a pretty powerful tool, running it takes quite a while (not exactly fun to do with something as big as e.g. LibreOffice).

Recently I finally gave Linux perf a try. Not quite sure why I didn't use it before, IIRC when I tried it somewhen long ago, it was probably difficult to set up or something. Using perf record has very little overhead, but I wasn't exactly thrilled by perf report. I mean, it's text UI, and it just gives a list of functions, so if I want to see anything close to a call graph, I have to manually expand one function, expand another function inside it, expand yet another function inside that, and so on. Not that it wouldn't work, but compared to just looking at what KCachegrind shows and seeing ...

When figuring out how to use perf, while watching a talk from Milian Wolff, on one slide I noticed a mention of a Callgrind script. Of course I had to try it. It was a bit slow, but hey, I could finally look at perf results without feeling like that's an effort. Well, and then I improved the part of the script that was slow, so I guess I've just put the effort elsewhere :).

And I thought this little script might be useful for others. After mailing Milian, it turns out he just created the script as a proof of concept and wasn't interested in it anymore, instead developing Hotspot as UI for perf. Fair enough, but I think I still prefer KCachegrind, I'm used to this, and I don't have to switch the UI when switching between perf and callgrind. So, with his agreement, I've submitted the script to KCachegrind. If you would find it useful, just download this do something like:

$ perf record -g ...
$ perf script -s perf2calltree.py > perf.out
$ kcachegrind perf.out



Categories: FLOSS Project Planets

Pages