I Use This!
Activity Not Available

News

Analyzed 2 months ago. based on code collected about 1 year ago.
Posted 2 days ago
Lately a recurrent contributor to the GIMP project (Massimo Valentini) contributed a patch to support HGT files. From this initial commit, since I found this data quite cool, I improved the support a bit (auto-detection of the variants and ... [More] special-casing in particular, as well as making an API for scripts). So what is HGT? That’s topography data basically just containing elevation in meters of various landscape (HGT stands for “height“), gathered by the Shuttle Radar Topography Mission (SRTM) run by various space agencies (NASA, National Geospatial-Intelligence Agency, German and Italian space agencies…). To know more, you can read here and there. HGT download source: https://dds.cr.usgs.gov/srtm/version2_1/ (go inside SRTM1/ and SRTM3/ directories for respectively 1 arc-second and 3 arc-seconds sampled data) You probably won’t find other links of interest since not everyone can do such data (not everyone has satellites!). Here is what it can look like after processing: left is an image obtained from NASA PDF, and right is the same data imported in GIMP followed by a gradient mapping. So the support is not perfect yet because to get a nice looking result, you need to do it in several steps and that involves likely a bunch of tweaking. My output above is not that good (colors look a bit radioactive compared to the NASA one!) but that’s mostly because I didn’t take the time to tweak more. And so that’s why I am writing this blog post. Someone trying to import HGT files in GIMP may be a bit disconcerted at first (so I’m hoping you’ll find this blog post to go further). At first you’d likely get a nearly uniform-looking grey image and may think that HGT import is broken. It is not. What’s happening? Why is the imported HGT all uniform grey? GIMP by default will convert the HGT data into greyscale. That is not a problem by itself since we can have very well contrasted greys. But that doesn’t happen for HGT import. Why? HGT contains elevation data as signed 16-bit integers representing meters. In other words, it represents elevation from -32767 m to 32767 m (with an exception for -32768 which means “void”, i.e. invalid data; since that’s raw data with minimum processing, it can indeed contain errors). Therefore once mapped to [0; 1] range, color 0 (pure black) is invalid, ]0; 0.5] is anything under water level and [0.5; 1] is above water elevation. Considering that on earth, the highest point is Mount Everest at 8848m, when mapped to our [0; 1] range, we see it has value 0.635. So you can see the problem: most things on earth will be represented with greys really close to 0.5 and that’s why there is no contrast. How to get nice colors and contrast? There are several solutions, but the one proposed by the contributor was to use the “Gradient Map” plug-in. That’s a good idea. Basically you remap your greys from 0 to 1 into color gradients. Now you can try to create a gradient by setting random stops through the GUI, but that will most likely be quite a challenge. A better idea is to do it a bit more “scientifically” (i.e. to use numbers, which you can also do through the GUI by using the new blend tool, though not as accurately as I’d like with only 2 decimal places). This is what did Massimo here by creating a gradient file which would map “magenta for invalid data, blue below zero, green to 1000 m, yellow to 2000m, and gray to white above“. From this base, I added a bit of random tweaking because I was trying to get an output similar to the NASA document (just for the sake of it), so you can get a look at how my own gradient file looks like. But if you are looking to, say, create a relief map with accurate elevation/color mapping, you’d prefer to stick by the number-only approach. Then once you get your gradient “code”, copy it in a file with the extension .ggr inside the gradients/ folder of your GIMP config, and just use it when running “Gradient Map” filter. Just to explain a bit the format: for each line, you get the startpoint, midpoint and endpoint coordinates (in the [0; 1] range), followed by 4 values for RGBA (also in [0; 1] range) for the startpoint then again 4 values for RGBA endpoint color. Then you get an integer for the blending mode (you likely want to keep it linear, i.e. 0, for a relief map), then the coloring value (leave it to 0 as well, which is RGB). Finally the last 2 integers are whether the startpoint and endpoint must be fixed colors, or correspond to foreground, background, etc. You will likely want to keep them as fixed colors (0). So basically a line like this: 0.500000 0.507633 0.515267 0.000000 1.000000 0.000000 1.000000 0.000000 0.500000 0.000000 1.000000 0 0 0 0 means: gradient from 0 meter (0.5) to 1000 m ((0.515267 – 0.5) × 216 ≈ 1000) is a linear gradient from RGBA 0-1-0-1 (green) to RGBA 0-0.5-0-1. That is: start mid end Rs Gs Bs As Re Ge Be Ae 0 0 0 0 where start is the start elevation and end the end elevation in [0; 1] range; and RsGsBsAs and ReGeBeAe are respectively the start and end gradient colors. That’s how you can easily map the elevation into colors! I hope that’s clear! Can’t we have nicer support with a GUI? Yes of course. This was fun and cool to review then improve this feature, and we should not let quality patches rot in our bugtracker, but that’s not my priority (as you know) so I stopped improving the feature (if I don’t stop myself from all these funny stuff out there, when would I work on ZeMarmot?!). I gladfully accept new patches to improve the support and have left myself 2 bug reports to leave ideas about how to improve the current tools: Improve “Gradient Map” filter to provide on-canvas preview and editing, similarly to the blend tool, because I realize this filter is powerful but that is a bit of a pain to use right now (iterations of edit gradient, run the filter for test, cancel, again and again). Map gradients directly from HGT import with preview and [0; 1] range remapped to elevation in meters in the dialog so that we don’t have to constantly recompute values back and forth and edit .ggr files by hand. In the meantime, I leave this blog post so that the format is at least understandable and HGT import usable to moderately technical people. That’s it! Hopefully this post will be useful to someone needing to process HGT files with GIMP and willing to understand how this works, until we get more intuitive support. Reminder: my Free Software coding can be funded on Liberapay, Patreon or Tipeee through ZeMarmot project. [Less]
Posted 2 days ago
We celebrated yesterday another session of the local challenge 2017-2 “PeruRumboGSoC2018”. It was held at the Centro Cultural Pedro Paulet of FIEE UNI.  GTK on C was explained during the fisrt two hours of the morning based on the window* exercises ... [More] from my repo to handle some widgets such as windows, label and buttons.Before he scheduled lunch, we were able to program a Language Selector using grid with GTK on C. These are some of the students git: Fiorella, Cris, Alex, Johan Diego & GiohannyWe’ve shared a deliciuos Pollo a la Brasa, and a tasty Inca Cola to drink during our lunch. Martin Vuelta helped us to make our miniapplication works by clicking a single or multiple languages in our language selector to open a useful links to learn those programming languages. We needed to install webkit4 packages on Fedora 27.Thank you so much Martin for supporting the group with your expertise and good sense of humor! We are going to have three more sessions this week to finish the program. Filed under: Education, Events, FEDORA, GNOME, τεχνολογια :: Technology, Programming Tagged: #PeruRumboGSoC2018, apply GSoC, fedora, Fedora + GNOME community, Fedora Lima, gnome 3, GSoC 2018, GSoC Peru Preparation, Julita Inca, Julita Inca Chiroque, Lima, Peru Rumbo al GSoC 2018 [Less]
Posted 2 days ago
We were asked a few times about trying out Liberapay. It is different from other recurring funding platforms (such as Patreon and Tipeee) that it is managed by a non-profit and have lesser fees (from what I understand, there are payment processing ... [More] fees, but they don’t add their own fees) since they fund themselves on their own platform (also the website itself is Free Software). Though we liked the concept, until now we were a bit reluctant for a single reason: ZeMarmot is already on 2 platforms (we started before even knowing Liberapay), and more platforms mean more time spent to manage them all, time we prefer using to hack Free Software and draw/animate Libre Animation. Nevertheless recently Patreon made fee policy changes which seem to anger the web (just search for it on your favorite web search engine, there are dozens of articles on the topic) and as most Patreon projects, we lost many patrons (at time of writing, 20 patrons for $80.63 of pledge left in 4 days, more than 10% the patronage received from this platform!). So we decided to give Liberapay a try. If you like ZeMarmot project, and our contributions to GIMP, then feel free to fund us at: » ZeMarmot Liberapay page « https://liberapay.com/ZeMarmot/ Main difference with other platforms: both EUR (€) and USD ($) donations are accepted, which is cool; there are no news system so one has to get them oneself (for instance reading the project blog or twitter); all patrons are fully anonymous (which means they won’t appear in credits of the movie); localization is supported (right now our page is only in English, but we will make a French version soon!). Now this is just another platform, we are not abandoning Patreon and Tipeee. Don’t feel like you have to move your patronage to Liberapay if you don’t want to. From now on, this will just be one more option. Finally we remind that ZeMarmot project is fully managed by a non-profit registered in France, LILA. This means there are also other means to support the project, for instance with direct bank transfers (most European banks allow monthly bank transfers without any fees, so if you are in the EU, this may be the best solution), or Paypal (though for very small amounts, fees are quite expensive, they are quite ok for most donations), etc. To see the full list of ways to fund LILA, hence ZeMarmot and GIMP: https://libreart.info/en/donate [Less]
Posted 2 days ago
On Friday I added support for yet another variant of DFU. This variant is called “driverless DFU” and is used only by BlueCore chips from Cambridge Silicon Radio (now owned by Qualcomm). The driverless just means that it’s DFU like, and routed over ... [More] HID, but it’s otherwise an unremarkable protocol. CSR is a huge ODM that makes most of the Bluetooth audio chips in vendor hardware. The hardware vendor can enable or disable features on the CSR microcontroller depending on licensing options (for instance echo cancellation), and there’s even a little virtual machine to do simple vendor-specific things. All the CSR chips are updatable in-field, and most vendors issue updates to fix sound quality issues or to add support for new protocols or devices. The BlueCore CSR chips are used everywhere. If you have a “wireless” speaker or headphones that uses Bluetooth there is a high probability that it’s using a CSR chip inside. This makes the addition of CSR support into fwupd a big deal to access a lot of vendors. It’s a lot easier to say “just upload firmware” rather than “you have to write code” so I think it’s useful to have done this work. The vendor working with me on this feature has been the awesome AIAIAI who make some very nice modular headphones. A few minutes ago we uploaded the H05 v1.5 firmware to the LVFS testing stream and v1.6 will be coming soon with even more bug fixes. To update the AIAIAI H05 firmware you just need to connect the USB cable and press and hold the top and bottom buttons on the headband until the LED goes out. You can then update the firmware using fwupdmgr update or just using GNOME Software. The big caveat is that you have to be running fwupd >= 1.0.3 which isn’t scheduled to be released until after Christmas. I’ve contacted some more vendors I suspect are using the CSR chips. These include: Jarre Technologies RIVA Audio Avantree Zebra Fugoo Bowers&Wilkins Plantronics BeoPlay JBL If you know of any other “wireless speaker” companies that have issued at least one firmware update to users, please let me know in a comment here or in an email. I will follow up all suggestions and put the status on the Naughty&Nice vendorlist so please check that before suggesting a company. It would also be really useful to know the contact details (e.g. the web-form URL, or the email address) and also the model name of the device that might be updatable, although I’m happy to google myself if required. Thanks as always to Red Hat for allowing me to work on this stuff. [Less]
Posted 3 days ago
Another year of GNOME development is coming to a close so it’s time to look back as we forge into 2018. This is going to be more verbose than I generally write. I hope you’ll have a warm drink and take the time to read through because I think this is ... [More] important. Twenty years of GNOME is a monumental achievement. We know so much more about software development than we did when we started. We regularly identify major shortcomings and try to address them. That is a part of our shared culture I enjoy greatly. GNOME contributors have a wide variety of interests and direction when it comes to a computer’s role in our lives. That naturally creates an ever-expanding set of goals. As our goals expand we must become more organized if our quality is to maintain or improve. Traditionally, we have a very loosely organized project. People spend their time on things that interest them, which does not put the focus on the end product. I intend to convince you that is now holding us back. We’re successful not because of our engineering focus but despite it. This results in overworking our contributors and we can do better. Those that have not worked in larger engineering companies may be less familiar with some of the types of roles there are in software development. So let’s take a moment to describe these roles so everyone is on the same page. Programmers are responsible for the maintenance of the code-base and implementing new features. All of us familiar with this role in GNOME because it’s what a large number of our contributors do. Designers are responsible for thinking through the current and planned features to find improved ways for users to solve their problems. Graphic Designers can often overlap with Design, but not necessarily. They’re responsible for creating the artwork used in the given project. Quality Assurance ensures that you don’t ship a product that is broken. You don’t wait until the freezes to do this, but do it as features are developed so that the code is fresh in the programmers minds while addressing the issues. The sooner you catch issues, the less likely a code or design failure reaches users. User Support is your front-line defense to triage incoming issues by your users. Without users your project is meaningless. Finding good people for this role can have a huge impact on keeping your users happy and your developers less stressed. If your bug tracker is also your user support, you might want to ask yourself if you really have user support. When you have a separate support system and bug-tracker, user support is responsible for converting user issues into detailed bug reports. Security Engineers look for trust, privacy, and other safety issues in products and infrastructure. They take responsibility to ensure issues are fixed in a timely manner and work with others when planning features to help prevent issues in the first place. User and Developer Advocates are liaisons between your team and the people using (or developing third-party tools with) your product. They amplify the voices of those speaking important truths. User Testing is responsible for putting your product in-front of users and seeing how well they can perform the given tasks. Designers use this information to refine and alter designs. Tech writers are responsible for writing technical documentation and help guides. They also help refine programmer authored API documentation. This role often fulfills the editor role to ensure a unified voice to your project’s written word. Build engineers ensure that your product can be packaged, built reliably, and distributed to users. Operations and “DevOps” ensure that your product is working day-to-day. They provide and facilitate the tooling that these roles need to do their jobs well. Internationalization and localization ensure that your software is available to a group of users who might otherwise not be able to use your software. It enables your software to have global impact. Release management is your final check-point for determining when and what you release based on the goals of the project. They don’t necessarily determine road-maps, but they do keep you honest. Product managers are responsible for taking information and feedback from all these roles and converting that into a coherent project direction and forward looking vision. They analyze common issues, bug velocity, and features to ensure reasonable milestones that keeps the product functional as it transforms into it’s more ideal state. Most importantly, this role is leadership. There are other roles involved in the GNOME project. If I didn’t include your role here, it is by no means of any lesser value. For the past 3 years I’ve been working very hard because I fulfill a number of these roles for Builder. It’s exhausting and unsustainable. It contributes to burnout and hostile communication by putting too much responsibility on too few people’s shoulders. I believe that communication breakdown is a symptom of a greater problem, not the problem itself. To improve the situation, we need to encourage more people to join us in non-programming roles. That doesn’t mean that you can’t program, but simply a recognition that these other roles are critical to a functioning and comprehensive software project. There are a few strategies used by companies with how to structure teams. But they can be generalized into three forms, as follows. Teams based on product contain the aforementioned roles, but are assembled in a tight-knit group where people are focused on a single product. This model can accel at ensuring all of the members are focused on a single vision. Teams based on role contain the aforementioned roles, but are assembled by the role. Members of the team work on different projects. This model can accel in cross-training newer team members. A hybrid approach tries to balance the strengths of both team-based and role-based so that your team members get long-term mentorship but stick around in a project long enough to benefit from contextual knowledge. To some degree we have teams based on role even though it’s very informal. I think we could really gain from increasing our contributors in these roles and taking a hybrid approach. For the hybrid approach to work, there needs to be strong mentor-ship for each role. My current opinion is that with a strong focus on individual products, we can improve our depth of quality and address many outstanding user issues. Due to how loosely assembled our teams are I think it is very difficult for someone to join GNOME and provide one of these non-programming roles in an existing project. That is because they not only need to fulfill the role but also define what that role should be and how it would contribute to the project. Then they need to convince the existing team members it’s needed. With stronger inclusion of these roles into our software process we can begin to think about the long-term skill development of our contributors. A good manager shepherds their team by ensuring they refine existing skills while expanding to new areas of interest. I want people to know that by joining GNOME they can feel assured that they will be part of something greater than themselves. They will both refine and develop new skills. In many ways, we provide an accelerator for career development. We can provide an opportunity that might otherwise be unapproachable. If contributing to GNOME in one or more of these roles sounds interesting to you, then please come join us. We need to learn to rely on each other in new ways. For that to happen, self-organization to fulfill these roles must become a priority. https://www.gnome.org/get-involved/ [Less]
Posted 3 days ago
Another year of GNOME development is coming to a close so it’s time to look back as we forge into 2018. This is going to be more verbose than I generally write. I hope you’ll have a warm drink and take the time to read through because I think this is ... [More] important. Twenty years of GNOME is a monumental achievement. We know so much more about software development than we did when we started. We regularly identify major shortcomings and try to address them. That is a part of our shared culture I enjoy greatly. GNOME contributors have a wide variety of interests and direction when it comes to a computer’s role in our lives. That naturally creates an ever-expanding set of goals. As our goals expand we must become more organized if our quality is to maintain or improve. Traditionally, we have a very loosely organized project. People spend their time on things that interest them, which does not put the focus on the end product. I intend to convince you that is now holding us back. We’re successful not because of our engineering focus but despite it. This results in overworking our contributors and we can do better. Those that have not worked in larger engineering companies may be less familiar with some of the types of roles there are in software development. So let’s take a moment to describe these roles so everyone is on the same page. Programmers are responsible for the maintenance of the code-base and implementing new features. All of us familiar with this role in GNOME because it’s what a large number of our contributors do. Designers are responsible for thinking through the current and planned features to find improved ways for users to solve their problems. Graphic Designers can often overlap with Design, but not necessarily. They’re responsible for creating the artwork used in the given project. Quality Assurance ensures that you don’t ship a product that is broken. You don’t wait until the freezes to do this, but do it as features are developed so that the code is fresh in the programmers minds while addressing the issues. The sooner you catch issues, the less likely a code or design failure reaches users. User Support is your front-line defense to triage incoming issues by your users. Without users your project is meaningless. Finding good people for this role can have a huge impact on keeping your users happy and your developers less stressed. If your bug tracker is also your user support, you might want to ask yourself if you really have user support. When you have a separate support system and bug-tracker, user support is responsible for converting user issues into detailed bug reports. Security Engineers look for trust, privacy, and other safety issues in products and infrastructure. They take responsibility to ensure issues are fixed in a timely manner and work with others when planning features to help prevent issues in the first place. User and Developer Advocates are liaisons between your team and the people using (or developing third-party tools with) your product. They amplify the voices of those speaking important truths. User Testing is responsible for putting your product in-front of users and seeing how well they can perform the given tasks. Designers use this information to refine and alter designs. Tech writers are responsible for writing technical documentation and help guides. They also help refine programmer authored API documentation. This role often fulfills the editor role to ensure a unified voice to your project’s written word. Build engineers ensure that your product can be packaged, built reliably, and distributed to users. Operations and “DevOps” ensure that your product is working day-to-day. They provide and facilitate the tooling that these roles need to do their jobs well. Internationalization and localization ensure that your software is available to a group of users who might otherwise not be able to use your software. It enables your software to have global impact. Release management is your final check-point for determining when and what you release based on the goals of the project. They don’t necessarily determine road-maps, but they do keep you honest. Product managers are responsible for taking information and feedback from all these roles and converting that into a coherent project direction and forward looking vision. They analyze common issues, bug velocity, and features to ensure reasonable milestones that keeps the product functional as it transforms into it’s more ideal state. Most importantly, this role is leadership. There are other roles involved in the GNOME project. If I didn’t include your role here, it is by no means of any lesser value. For the past 3 years I’ve been working very hard because I fulfill a number of these roles for Builder. It’s exhausting and unsustainable. It contributes to burnout and hostile communication by putting too much responsibility on too few people’s shoulders. I believe that communication breakdown is a symptom of a greater problem, not the problem itself. To improve the situation, we need to encourage more people to join us in non-programming roles. That doesn’t mean that you can’t program, but simply a recognition that these other roles are critical to a functioning and comprehensive software project. There are a few strategies used by companies with how to structure teams. But they can be generalized into three forms, as follows. Teams based on product contain the aforementioned roles, but are assembled in a tight-knit group where people are focused on a single product. This model can excel at ensuring all of the members are focused on a single vision. Teams based on role contain the aforementioned roles, but are assembled by the role. Members of the team work on different projects. This model can accel in cross-training newer team members. A hybrid approach tries to balance the strengths of both team-based and role-based so that your team members get long-term mentorship but stick around in a project long enough to benefit from contextual knowledge. To some degree we have teams based on role even though it’s very informal. I think we could really gain from increasing our contributors in these roles and taking a hybrid approach. For the hybrid approach to work, there needs to be strong mentor-ship for each role. My current opinion is that with a strong focus on individual products, we can improve our depth of quality and address many outstanding user issues. Due to how loosely assembled our teams are I think it is very difficult for someone to join GNOME and provide one of these non-programming roles in an existing project. That is because they not only need to fulfill the role but also define what that role should be and how it would contribute to the project. Then they need to convince the existing team members it’s needed. With stronger inclusion of these roles into our software process we can begin to think about the long-term skill development of our contributors. A good manager shepherds their team by ensuring they refine existing skills while expanding to new areas of interest. I want people to know that by joining GNOME they can feel assured that they will be part of something greater than themselves. They will both refine and develop new skills. In many ways, we provide an accelerator for career development. We can provide an opportunity that might otherwise be unapproachable. If contributing to GNOME in one or more of these roles sounds interesting to you, then please come join us. We need to learn to rely on each other in new ways. For that to happen, self-organization to fulfill these roles must become a priority. https://www.gnome.org/get-involved/ [Less]
Posted 3 days ago by nore...@blogger.com (Jim Hall)
During a usability test, it's important to understand what the tester is thinking. What were they looking for when they couldn't find a button or menu item? During the usability test, I recommend that you try to observe, take notes, capture as much ... [More] data as you can about what the tester is doing. Only after the tester is finished with a scenario or set of scenarios should you ask questions.But how do you ask questions in a way to gain the most insight? Asking the right questions can sometimes be an art form; it certainly requires practice. A colleague shared with me a few questions she uses in her usability interviews, and I am sharing them here for your usability interviews:Before starting a scenario or set of scenarios: What are three things you might do in this application? What menu options do you see here and what do you think they do? What might you do on this panel? What is your first impression of the application? What do these icons do? What do they represent? After finishing a set of scenarios: Who do you think the application was created for? How easy did you think it was to get around the application? If you could make one change to the application, what would it be? Is there a feature you think is missing? Do you remember any phrases or icons that you didn't understand? The goal is to avoid leading questions, or any questions that suggests a "right" and "wrong" answer. [Less]
Posted 4 days ago
Today, I released a new version of scikit-survival. This release adds support for the latest version of scikit-learn (0.19) and pandas (0.21). In turn, support for Python 3.4, scikit-learn 0.18 and pandas 0.18 has been dropped. Many people are ... [More] confused about the meaning of predictions. Often, they assume that predictions of a survival model should always be non-negative since the input is the time to an event. However, this not always the case. In general, predictions are risk scores of arbitrary scale. In particular, survival models usually do not predict the exact time of an event, but the relative order of events. If samples are ordered according to their predicted risk score (in ascending order), one obtains the sequence of events, as predicted by the model. A more detailed explanation is available in the Understanding Predictions in Survival Analysis section of the documentation. Download You can install the latest version via Anaconda (Linux, OSX and Windows): conda install -c sebp scikit-survival or via pip: pip install -U scikit-survival [Less]
Posted 5 days ago by nore...@blogger.com (zeenix)
I have been meaning to document my experience of moving to Berlin, mainly to help people who are considering to move or are about to move. However I'm lazy and unless I'm paid to do so, I just won't get around to doing that so instead of ending up ... [More] posting nothing, I'll just quickly list all the advice I have here: Don't actually order any services through check24 website. Only use them to compare prices etc. Avoid Vodafone for broadband connection. Follow this thread for why. Consider using an online bank, like N26. For your Anmeldung, go to Bürgeramt in Neukölln or Kreuzberg (unless you speak German). book appointment around noon or be prepared to wait a month. Make sure you have local friends who speak German and are willing to help you out. Many locals will tell you that you don't need German in Berlin but that is simply not true. Either consider hiring an estate agent or make sure your temporary residence allows you to register on their address. Related to above, you don't have to pay deposit upfront if you use EuroKaution service. Consider the after 10am monthly travel pass if you don't commute to work before that time. [Less]
Posted 6 days ago by nore...@blogger.com (Robert Ancell)
Simple Scan recently migrated to the new gitlab.gnome.org infrastructure. With modern infrastructure I now have the opportunity to enable Continuous Integration (CI), which is a fancy name for automatically building and testing your software when ... [More] you make changes (and it can do more than that too).I've used CI in many projects in the past, and it's a really handy tool. However, I've never had to set it up myself and when I've looked it's been non-trivial to do so. The great news is this is really easy to do in GitLab!There's lots of good documentation on how to set it up, but to save you some time I'll show how I set it up for Simple Scan, which is a fairly typical GNOME application.To configure CI you need to create a file called .gitlab-ci.yml in your git repository. I started with the following:build-ubuntu:  image: ubuntu:rolling  before_script:    - apt-get update    - apt-get install -q -y --no-install-recommends meson valac gcc gettext itstool libgtk-3-dev libgusb-dev libcolord-dev libpackagekit-glib2-dev libwebp-dev libsane-dev  script:    - meson _build    - ninja -C _build installThe first line is the name of the job - "build_ubuntu". This is going to define how we build Simple Scan on Ubuntu.The "image" is the name of a Docker image to build with. You can see all the available images on Docker Hub. In my case I chose an official Ubuntu image and used the "rolling" link which uses the most recently released Ubuntu version.The "before_script" defines how to set up the system before building. Here I just install the packages I need to build simple-scan.Finally the "script" is what is run to build Simple Scan. This is just what you'd do from the command line.And with that, every time a change is made to the git repository Simple Scan is built on Ubuntu and tells me if that succeeded or not! To make things more visible I added the following to the top of the README.md:[![Build Status](https://gitlab.gnome.org/GNOME/simple-scan/badges/master/build.svg)](https://gitlab.gnome.org/GNOME/simple-scan/pipelines)This gives the following image that shows the status of the build: And because there's many more consumers of Simple Scan that just Ubuntu, I added the following to.gitlab-ci.yml:build-fedora:  image: fedora:latest  before_script:    - dnf install -y meson vala gettext itstool gtk3-devel libgusb-devel colord-devel PackageKit-glib-devel libwebp-devel sane-backends-devel  script:    - meson _build    - ninja -C _build installNow it builds on both Ubuntu and Fedora with every commit!I hope this helps you getting started with CI and gitlab.gnome.org. Happy hacking. [Less]