Service 'Mailing Lists' now has status: minor: Mailing lists email sending crashed since late Sunday. Cause fixed, emails going out now.
admin)
on September 19, 2017 02:47 PM
jbwillia)
on September 19, 2017 01:30 PM
The Fedora Respins SIG is pleased to announce the latest release of Updated 26 Live ISOs, carrying the 4.12.13-300 kernel and include the following CVEs:
– Fix CVE-2017-12154 (rhbz 1491224 1491231)
– Fix CVE-2017-12153 (rhbz 1491046 1491057)
– Fix CVE-2017-1000251 (rhbz 1489716 1490906) (bluebourne)
These can be found at http://tinyurl.com/live-respins), seeders are welcome and encouraged, however addition of additional trackers is strictly prohibited. These isos save about 850M of updates on new installs. We would also like to thank the following irc nicks for helping test these isos: brain83,dowdle,linuxmodder,vwbusguy, short-bike, Southern_Gentlem
In quite a few blog posts I been referencing Pipewire our new Linux infrastructure piece to handle multimedia under Linux better. Well we are finally ready to formally launch pipewire as a project and have created a Pipewire website and logo.
To give you all some background, Pipewire is the latest creation of GStreamer co-creator Wim Taymans. The original reason it was created was that we realized that as desktop applications would be moving towards primarly being shipped as containerized Flatpaks we would need something for video similar to what PulseAudio was doing for Audio. As part of his job here at Red Hat Wim had already been contributing to PulseAudio for a while, including implementing a new security model for PulseAudio to ensure we could securely have containerized applications output sound through PulseAudio. So he set out to write Pipewire, although initially the name he used was PulseVideo. As he was working on figuring out the core design of PipeWire he came to the conclusion that designing Pipewire to just be able to do video would be a mistake as a major challenge he was familiar with working on GStreamer was how to ensure perfect audio and video syncronisation. If both audio and video could be routed through the same media daemon then ensuring audio and video worked well together would be a lot simpler and frameworks such as GStreamer would need to do a lot less heavy lifting to make it work. So just before we starting sharing the code publicaly we renamed the project to Pinos, named after Pinos de Alhaurín, a small town close to where Wim is living in southern Spain. In retrospect Pinos was probably not the worlds best name 
Anyway as work progressed Wim decided to also take a look at Jack, as supporting the pro-audio usecase was an area PulseAudio had never tried to do, yet we felt that if we could ensure Pipewire supported the pro-audio usecase in addition to consumer level audio and video it would improve our multimedia infrastructure significantly and ensure pro-audio became a first class citizen on the Linux desktop. Of course as the scope grew the development time got longer too.
Another major usecase for Pipewire for us was that we knew that with the migration to Wayland we would need a new mechanism to handle screen capture as the way it was done under X was very insecure. So Jonas Ådahl started working on creating an API we could support in the compositor and use Pipewire to output. This is meant to cover both single frame capture like screenshot, to local desktop recording and remoting protocols. It is important to note here that what we have done is not just implement support for a specific protocol like RDP or VNC, but we ensured there is an advaned infrastructure in place to support any protocol on top of. For instance we will be working with the Spice team here at Red Hat to ensure SPICE can take advantage of Pipewire and the new API for instance. We will also ensure Chrome and Firefox supports this so that you can share your Wayland desktop through systems such as Blue Jeans.
Where we are now
So after multiple years of development we are now landing Pipewire in Fedora Workstation 27. This initial version is video only as that is the most urgent thing we need supported for Flatpaks and Wayland. So audio is completely unaffected by this for now and rolling that out will require quite a bit of work as we do not want to risk breaking audio on your system as a result of this change. We know that for many the original rollout of PulseAudio was painful and we do not want a repeat of that history.
So I strongly recommend grabbing the Fedora Workstation 27 beta to test pipewire and check out the new website at Pipewire.org and the initial documentation at the Pipewire wiki. Especially interesting is probably the pages that will eventually outline our plans for handling PulseAudio and JACK usecases.
If you are interested in Pipewire please join us on IRC in #pipewire on freenode. Also if things goes as planned Wim will be on Linux Unplugged tonight talking to Chris Fisher and the Unplugged crew about Pipewire, so tune in!
admin)
on September 19, 2017 08:18 AM
You helped test i18n features in Fedora 27! Thanks!
renault)
on September 19, 2017 06:00 AM
Aujourd'hui, ce mardi 19 septembre, est une journée dédiée à un test précis : sur l'internationalisation de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.
Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.
Comme chaque version de Fedora, la mise à jour de ses outils impliquent souvent l’apparition de nouvelles chaînes de caractères à traduire et de nouveaux outils liés à la prise en charge de langues (en particulier asiatiques).
Pour favoriser l'usage de Fedora dans l'ensemble des pays du monde, il est préférable de s'assurer que tout ce qui touche à l'internationalisation de Fedora soit testée et fonctionne. Notamment parce qu'une partie doit être fonctionnelle dès le LiveCD d'installation (donc sans mise à jour).
Les tests du jour couvrent :
Bien entendu, étant donné les critères, à moins de savoir une langue chinoise, l'ensemble des tests n'est pas forcément réalisable. Mais en tant que francophones, de nombreuses problématiques nous concernent et remonter les problèmes est important. En effet, ce ne sont pas les autres communautés linguistiques qui identifieront les problèmes d'intégration de la langue française.
Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.
Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.
En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.
De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.
ankursinha)
on September 18, 2017 11:40 PM
Vim is a great text editor if one takes a bit of time to learn how to use it properly. There's quite enough documentation on how to use Vim correctly, and efficiently so I shan't cover that here. vimtutor is an excellent resource to begin at.
Similarly, LaTeX is a brilliant documentation system, especially for scientific writing if one takes the time to learn it. Unlike the usual Microsoft Word type systems, LaTeX is a set of commands/macros. Once the document is written using these, it must be compiled to produce a PDF document. It may appear daunting at first, but after one is familiar with it, it makes writing a breeze. Now, there are a editors especially designed for LaTeX, but given that I use Vim for about all my writing, I use it for LaTeX too.
On Fedora, you can install Vim using DNF: sudo dnf install vim-enhanced vim-X11. I install the X11 package too to use the system clipboard.
To begin with, there are a few command line commands that one can use other than the necessary latex, pdflatex, bibtex, biber, and so on commands:
latexmk is a great tool that figures out the compilation sequence required to generate the document, and it does it for you.lacheck and chktex are both linters for LaTeX that make writing a lot easier.detex strips a tex document of LaTeX commands to produce only the text bits.diction, and style give the author an idea of the readability of the text.One can use any text editor and then these utilities to improve their LaTeX writing experience.
On Fedora, install these with DNF: sudo dnf install latexmk /usr/bin/lacheck /usr/bin/chktex /usr/bin/detex diction. (Yes, you can tell DNF what file you want to install too!)
Vim already contains quite a few features that make writing quite easy;
There are a lot of Vim plug-ins that extend some functionality or the other. The simplest way to install plug-ins is to use Vundle. Here are some plug-ins that I use. They're not all specific to LaTeX.
I've also used vim-latex in the past and it's very very good. However, since I have other plug-ins that provide the various functionality that it brings together for many other languages too, I'm no longer using it. Worth a go, though.
The image below shows a LaTeX file open in Vim with different plug-ins in action:
S> bit is an indicator from the linter that Syntastic uses, showing a warning or an error.+ symbol in the left margin implies that it is folded.en_gb language.Neat, huh? There is a lot more there that isn't easy to show in a screen-shot. For example, \ll will compile the LaTeX file; \lv opens the generated PDF file in a PDF viewer, Evince in my case; \lc will clean the directory of any temporary files that were generated while compiling the document.
I keep all my vimfiles on Github. Feel free to take a look and derive your own. I tweak my configuration each time I find something new, though, so it may change rather frequently. Remember to read the documentation for whatever plug-ins in use. They provide a lot of options, lots of shortcuts, lots of other commands, and sometimes setting them up incorrectly can cause vim to behave in unexpected ways.
AnsibleFest was amazing, it always is. This has been my Third one and it's always one that I look forward to attending. The Ansible Events Team does an absolutely stellar job of putting things together and I'm extremely happy I was not only able to attend but that I was accepted as a speaker.
The event kicked off with some really great product announcements, some interesting bits about Ansible Tower and the newly announced Ansible Engine.
As an avid fan of Open Source Software, the announcement and immediate release of Ansible AWX was the headliner of the event for me. This is the open source upstream to Ansible Tower that Red Hat made the commitment to release once Ansible was acquired in accordance with their continued commitment to Open Source. If you live in Ansible user or contributor land, you know this is something that's been a hot topic for quite some time and I'm so glad it's been launched officially. I've been learning Django over the last week so I can start contributing. Looking forward to it.
Immediately following the Ansible AWX announcement was a fireside chat with Ansible Community Leader Robyn Bergeron (who is also previously the Fedora Project Leader) and Red Hat CEO Jim Whitehurst to discuss various market trends in the realm of infrastructure automation, the ability to deliver faster and more rapidly, and the challenges business are having with the concept of "Digital Transformation." This was a really cool thing to get the perspective of things from both an open source community perspective and that of a business minded individual, and to see where those two perspectives met in the middle and/or overlapped.
The day before and the day after the main headline of AnsibleFest was the Community Days, the day before AnsibleFest focused entirely on topics around Ansible Core and the greater Ansible Community. The day after AnsibleFest focused on Ansible AWX in the morning, explaining architecture and various technical implementation details to try and get some exposure to things for those of us in the room who weren't previously privy to that information. The afternoon of the second day involved the "Ansible Ambassadors" community (I'm not sure if this is an official term)
I gave a presentation that I like to call "Ansible All The Things" or "Ansible Everything" (depending on who my audience is and how acceptable they are of meme jokes). The basic idea though is to look at Ansible not as a configuration management tool, which I feel a lot of the "Tech Media" (for lack of a better term) has classified it as and therefore it is often known as to the more broad audience, but instead think of it like a Task Automation utility. This particular task automation utility also comes with a nice python API and a way to interact by anything that can "speak JSON." This has some advantages if you step back and thing about this abstract concept of a tool with a programming interface that is ultimately as generic as passing JSON around (with added convenience for python programmers). Effectively you have a method of running a task, or series of tasks, on one or many systems in your infrastructure. This is powerful enough to be used for all sorts of things like configuration management (yes, Ansible can perform configuration management tasks but it's also so much more than that), provisioning, deployment, orchestration, command line tooling, builds, event-based execution, workflow automation, continuous integration, and containers.
For those who would like to check you my slides, they are here.
I had the opportunity to attend a presentation about Molecule, which I was really excited about because this is a toolchain I've wanted to dig into for a while. This is effectively the goal: Infrastructure as Code, TDD/CI on your Code, and transitively your Infrastructure. What a time to be alive.
Anyways, the talk itself was absolutely fantastic. Elana Hashman is a spectacular speaker and the amount of research she put into the talk was apparent. The room was captivated and the questions and conversations were enthusiastic, this was clearly a topic space people were interested in. I also have to give a tip of the hat to the live Demo that went off flawlessly, I've never personally pulled off a live Demo without at least one goof that contained the amount of live editing of code that was contained in this one. Kudos.
For those who are interested in the presentation materials, check them out here. (Do it, it's really good.)
The event was wonderful and I hope to have the opportunity to go next year to the North America based AnsibleFest (they also do one in the EU/UK but it's not often I can pull together the funding to that trip).
bodhi-dequeue-stable CLI that is intended be added to cron that looks for batched updates andThe following developers contributed to Bodhi 2.11.0:
skamath)
on September 18, 2017 06:36 PM
Foo : Hey, I just installed Arch and I can't connect to the internet.
Bar : Hey, my DE won't boot in Arch. Help, please.
FooBar : Man, I installed Arch and I can't find sudo. Will I die?
I wanted to put this up on Devrant but thought I'd write a bit to enlighten the wannabe Arch-ers. I have been recently getting a lot of messages asking me to help debug issues on Arch. As a fellow Linux and Arch user, I've always responded to most of the messages. But hey, there's a limit to it.
If you choose to begin your Linux adventures with Arch Linux after trying Ubuntu for a month, you're probably doing it wrong. If there's a solid reason why you think Arch is for you; awesome! Do it. You will learn new things. A lot of new things. But hey, what's the point in learning what arch-chroot does if you can't figure out what sudo is or what wpa_supplicant does?
Remember, when you decided to install Arch - you signed up for it. If you really want to get the feel of using Arch and not do all the hard work, try Antergos or Monjaro Linux. They are built on top of Arch Linux and they're kickass distros. You'll love it. Antergos is arch hiding behind a nice GUI installer ;)
Or better yet, start with a distro that comes with out-of-the-box support and get the feel of Linux before attempting to move to Arch. I've seen a lot of people switch back to Windows after trying to install Arch because some online guide said "Arch was awesome", but never said it's not for beginners. I'd recommend Fedora any day because :
Also, please learn to use a search engine whenever you are stuck. It doesn't hurt to use it, does it? So stop asking, and start googling! duck-ing!. When you're confident that you've got your back, go ahead - fire up that live-USB and arch-chroot.
Every year, the Fedora User and Developer community puts on an conference entitled "Flock to Fedora" or "Flock" for short. This year was no different and the event was hosted in lovely Cape Cod, MA.
This year's Flock was a little different in focus than previous year's, the goal of the event organizers appeared to be that of "doing" as apposed to "watching presentations" which worked out great. As an user and contributor conference, almost everyone there was a current user or contributor so workshops to help enhance people's knowledge level, have them contribute to an aspect of the project, or to introduce them to a new area of the Fedora Project in a more hands-on way was met with enthusiastic participation. There were definitely still "speaking tracks" but there were more "participation tracks" than years past and it turned out to be a lot of fun.
Note
At the time of this writing, the videos had not yet been posted but it was reported that they will be found at the link below.
All the sessions were being recorded and I highly recommend anyone interested to check them out here.
I will recap my experience and take aways from the sessions I attended and participated in as well as post slides and/or talk materials that I know of.
The Fedora Project Leader, Matt Miller took the stage for the morning keynote following a brief instructional Logistics/Intro statement by event organizers. Matt discussed the current state of Fedora, where we are, where we're going, ongoing work and current notable Changes with work under way.
Big key take-aways here was that Fedora Modularity and Fedora CI are big initiatives aiming to bring more content to our users, in newly consumable ways, even faster than ever before without compromising quality (and hopefully improving it).
One of the big pain points from the Fedora contributor's standpoint is how long it takes to compose the entire distro into an usable thing. Right now, once contributors have pushed source code and built RPMs out of it, you have to take this giant pile of RPMs, create a repository, then start to build things out of it that are stand-alone useful for users. These kinds of things are install media, live images, cloud and virt images, container images, etc.
Factory 2.0 aims to streamline these processes, make them faster, more intelligent based on tracking metadata about release artifacts and taking action upon those artifacts only when necessary, and make everything "change driven" such that we won't re-spin things for the sake of re-spinning or because some time period has elapsed, but instead will take action conditionally on a change occurring to one of the sources feeding into an artifact.
For those who remember last Flock, there was discussion of this concept of the Eternal September and this was a progress report update of the work that's being done to handle that as well as clean up the piles of technical debt that have accrued over the last 10+ years.
Next time slot that I attended was my presentation on the new plans to provide a Multi-Architecture implementation of the Fedora Layered Image Build Service. The goal here is to provide a single entry point for Fedora Container Maintainers to contribute containerized content, submit it to the build system, and then have multiple architecture container builds as a result. This is similar to how the build system operates for RPMs today and we aim to provide a consistent experience for all contributors.
This is something that's still being actively implemented with various upstream components that make up the build service, but will land in the coming months. It was my original hope to be able to provide a live demo, but it unfortunately didn't work out.
A workshop put together by Josh Berkus that I helped with was to introduce people who'd never created a container within the Fedora Layered Image Build Service to our best practices and guidelines. Josh took everyone through an exercise of looking at a Dockerfile that was not in compliance with the guidelines and then interactively with the audience bringing it into compliance.
After the example was completed, Josh put up a list of packages or projects that would be good candidates for becoming containerized and shipped to the Fedora User base. Everyone split up into teams of two (we got lucky, there was an even number of people in the room), and they worked together to containerize something off the list. He and I spent a period of the time going around and helping workshop attendees and then with about 10 minutes left the teams traded their containerized app or service with someone else and performed a container review in order to give them an idea of what that side of the process is like.
Hopefully we've gained some new long term container maintainers!
This session is one that I think many were surprised would ever happen, most notably because I think for those who've been in the Linux landscape for long enough to remember Microsoft's top brass calling Linux a cancer, we never would have predicted Windows Subsystem for Linux existing. However, time goes on, management changes, and innovation wins. Now we have this magical thing called "Windows Subsystem for Linux" that doesn't actually run Linux at all, but instead runs programs meant to run on Linux without modification or recompilation.
The session goes through how this works, how the Windows kernel accomplishes the feats of magic that it does and the work that Seth Jennings (the session's presenter) put in to get Fedora working as a Linux distribution to run on top of Windows Subsystem for Linux. It's certainly very cool, a wild time to be alive, and something I think will ultimately be great for Fedora as an avenue to attract new users without having to shove them into the deep end right away.
Going along with the theme of continuing to try and deliver things faster to our users, this session discusses a new service that's being rolled out in Fedora Infrastructure that will address the needs of "keeping things fresh" in Fedora. Introducing Freshmaker
As it stands today, we don't have a good mechanism by which to track the "freshness" of various pieces of software, there's been some attempts at this in the past and they weren't necessarily incorrect or flawed but they never had the opportunity to come to fruition for one reason or another. Good news is that Freshmaker is a real thing, it's a component of Factory 2.0 and is tasked the job of making sure that software in build pipeline is fully up to date with latest input sources for easy of maintaining updated release artifacts for end users to download.
Greenwave is another component of Factory 2.0 with the goal of automatically blocking or releasing software based on automated testing such that the tests are authoritative. This session discussed the motivations and the design as well as discussed how to override Greenwave via WaiverDB.
This session was mostly about kubernetes, OpenShift, and how to deploy them on Fedora in different ways. There was a brief presentation and then discussions about preferred methods of deployment, what we as a community would like to and/or should pursue as the recommended method by which we direct new users to install these technologies.
Fedora's ARM champion, Peter Robinson, gave an update of where things are in ARM land, discussing the various development boards available and what Fedora contributors and community members can expect in the next couple Fedora releases.
This session was a working/discussion session that revolved around how the Fedora Infrastructure Team plans to utilize OpenShift in the future for Fedora services in order to achieve higher utilization of the hardware we currently have available and to allow for applications to be developed and deployed in a more flexible way. The current plans are still being discussed and reviewed, which is part of what this session was for, but stay tuned for more in the coming weeks.
Currently, fedmsg is Fedora's unified message bus. This is where all information about activities within the Fedora Infrastructure are sent and that's not slated to change anytime soon. However, there's new use cases for the messages that will go out on the message bus that have changed in scope and the reliability of message delivery is something that will become a more hard pressing requirement. This presentation was about a proposal to add new transports for messages in addition to the one that already exists, allowing various services needing to listen for fedmsgs to subscribe to the protocol endpoint that most makes sense for the purpose. This session opened a discussion with a proposal to satisfy the newer needs while leaving the current infrastructure in place by taking advantage of some of the features of ZeroMQ.
This was a very candid and honest presentation by our once long standing Fedora Infrastructure lead, Mike McGrath, who spoke on behalf of Red Hat as the primary corporate sponsor of Fedora as to what specifically Red Hat as an entity hopes to gain from the ongoing collaboration with the Fedora Community, and the innovations they hope to help foster moving forward. I unfortunately did not take good notes so don't have much in the way to provide as far as specifics so we'll have to wait for the videos to become available for those interested in this material.
The Fedora Infrastructure lead, Kevin Fenzi, stood infront of a whiteboard and kicked off a workshop where interested parties and contributors to the Fedora Infrastructure outlined and planned major initiatives for the Fedora Infrastructure for the next year. Headliners here from general consensus is that OpenShift will definitely be leveraged more heavily but it will require some well defined policy around development and deployment for the sake of sanitizing where code libraries come from for security, auditing, and compliance purposes. The other main topic of discussion was metrics reporting, various options will be evaluated with front runners being the Elastic Stack, Hawkular, and Prometheus.
This session was a great introduction to how things are going to fit together, we dove pretty far into the weeds with some of the tech behind how Fedora Modularity fits together and ultimately if anyone is interested in digging in there, the official docs really are quite good. I would recommend anyone interesting in learning about the technical details about modularity to give it a look.
In this workshop, put on my Tomas Tomecek, we learned how to create a module and feed it into the Fedora Module Build System (MBS). This was an interesting exercise to go through because it helped define the relationship between rpms, modules, non-rpm content, and the metadata that ties all of this together with disjoint modules to create variable lifecycles between different sets of software that come together as a module. I was unable to find the slides from the talk, but our presenter recently tweeted that a colleague of his wrote a blog post he thinks is even better than the workshop, so maybe give that a go. :)
The topic of Continuous Integration (CI) is one that's extremely common in software development teams and it is not a new concept. But what if we were going to take that concept and apply it to the entire Fedora distribution? Now that might be something special and could really pay off for the user and contributor base therein. This is exactly what the Fedora CI initiative aims to do.
What's most interesting to me about this presentation was that it went through an exercise of thought and then showed specifically how a small team was able to accomplish more work than almost anyone though they could because they treat the bot they've written to integrate their CI pipeline with various other services as a member of the team. They taught themselves to not think of it as a system but as a team member they could offload work to, the work that nobody else wanted to do.
I look forward to seeing a lot of this work come to fruition.
The last day of the conference we had a "Show and Tell" where various members from different aspects of the projects got together and worked on things. The rest of the day was a hackathon for those who were still in-town and not traveling back home mid-day.
As always, Flock was a blast and I can't wait for Flock 2018!
Until next time...
In the last bunch of weeks as FCAIC I1:
I’ll be traveling some and hope you’ll ping me for coffee if you’re nearby.
pravins)
on September 18, 2017 10:43 AM
admin)
on September 18, 2017 10:10 AM
When a new kernel is released, users often want to know if it’s usable. The kernel has a set of test cases that can be run to help validate it. These tests are run automatically on every successful build. They are designed to validate a basic set of functionality and some Fedora specific features, such as secure boot signing. Here’s how you can run them.
This wiki page provided by the Fedora QA team describes the process to run the regression tests on your local machine. To run these tests, you need the gcc, git, and python-fedora packages installed on your system. Use this sudo command if needed:
sudo dnf install gcc git python-fedora
First, clone the kernel-tests repository and move into the directory:
git clone https://pagure.io/kernel-tests.git cd kernel-tests
Next, set some configuration options. The easiest way to get started is to copy the config.example file:
cp config.example .config
The most important settings are the ones labeled to set submission. By default, tests do not submit results to the server. To submit results anonymously, use the setting submit=anonymous. To submit results linked to your FAS username, set submit=authenticated and username=<your FAS login> in .config. If you link your submission to your FAS username, you’ll also receive a Fedora badge.
To run the basic set of tests, use this command:
$ sudo ./runtests.sh
To run the performance test suites, use this command:
$ sudo ./runtests.sh -t performance
The expected result is that the tests pass. However, some tests may fail occasionally due to system load. If a test fails repeatedly, though, consider helping by reporting the failure on Bugzilla.
Running these regression tests helps validate the kernel. Look for more tests added in the near future to help make the kernel better.
Let me start with a wrong presumption that you have everything set up – you are a packager who knows what they want to achieve, you have a dist-git repository created, you have all the tooling installed. And of course, you know what Modularity is, and how and why do we use modulemd to define modular content. You know what Host, Platform, and Bootstrap modules are and how to use them.
Why would I make wrong presumptions like that? First of all, it might not be wrong at all. Especially, if you are a returning visitor, you don’t want to learn about the one-off things every time. I want to start with the stuff you will be doing on regular basis. And instead of explaining the basics over and over again, I will just point you to the right places that will help you solve a specific problem, like not having a dist-git repository.
Let’s go through the whole process of updating a module. I will introduce some build failures on purpose, so you know how to deal with them should they happen to you.
Start with cloning the module dist-git repository to get the modulemd file defining the installer module.
$ fedpkg clone modules/installer $ cd installer $ ls Makefile installer.yaml sources tests
I want to build an updated version of installer. I have generated a new, updated version of modulemd (I will be talking about generating modulemd files later in this post), and I am ready to build it.
$ git add installer.yaml $ git commit -m "building a new version" $ git push $ mbs-build submit ... asamalik's build #942 of installer-master has been submitted
Now I want to watch the build and see how it goes.
$ mbs-build watch 942 Failed: NetworkManager https://koji.fedoraproject.org/koji/taskinfo?taskID=21857852 realmd https://koji.fedoraproject.org/koji/taskinfo?taskID=21857947 python-urllib3 https://koji.fedoraproject.org/koji/taskinfo?taskID=21857955 Summary: 40 components in the COMPLETE state 3 components in the FAILED state asamalik's build #942 of installer-master is in the "failed" state
Oh no, it failed! I reviewed the Koji logs using the links above, and I see that:
After fixing realmd and updating the modulemd to reference the fix, I can submit a new build.
$ git add installer.yaml $ git commit -m "use the right version of automake with realmd" $ git push $ mbs-build submit ... asamalik's build #942 of installer-master has been submitted
To watch the build, I use the following command.
$ mbs-build watch 943 Failed: sssd https://koji.fedoraproject.org/koji/taskinfo?taskID=21859852 Summary: 42 components in the COMPLETE state 1 components in the FAILED state asamalik's build #943 of installer-master is in the "failed" state
Good news is that realmd worked this time. However, sssd failed. I know it built before, and by investigating the logs I found out it’s one of the random test failures again. Resubmitting the build will fix it. In this case, I don’t need to create a new version, just resubmit the current one.
$ mbs-build submit ... asamalik's build #943 of installer-master has been resubmitted
Watch the build:
$ mbs-build watch 943 Summary: 43 components in the COMPLETE state asamalik's build #943 of installer-master is in the "ready" state
The Platform module has been updated and there is a soname bump in rpmlib. I need to rebuild the module against the new platform. However, I’m not changing anything in the modulemd. I know that builds map 1:1 to git commits, so I need to create an empty commit and submit the build.
$ git commit --allow-empty -m "rebuild against new platform" $ git push $ mbs-build submit ... asamalik's build #952 of installer-master has been submitted
Now it’s the time to make sure you are not missing a step in your module building journey! Did I miss something? Ask for it in the comments or tweet at me and I will try to update the post.
To get a dist-git repository, you need to have your modulemd to go through a Fedora review process for modules. Please make sure your modulemd comply with the Fedora packaging guidelines for modules. Completing the review process wil result in having a dist-git repository.
Your module need to run on top of the Platform module which together with the Host and Shim modules form the base operating system. You can see the definition of Platform, Host, and Shim modules on github.
You should include all the dependencies needed for your module to run on the Platform module, with few exceptions:
To make it easier during the transition from a traditional release to a modular one, there is a set of useful scripts in the dependency-report-scripts repository, and the results are being pushed to the dependency-report repository. You are welcome to participate.
The module definitions are in the modularity-modules organizations, in a README.md format simlar to the Platform and Host definition. The scripts will take these repositories as an input together with the Fedora Everything repository to produce dependency reports and basic modulemd files.
The dependency-report-scripts can produce a basic modulemd, stored in the dependency-report repository. The modulemd files stored in the dependency-report repository reference their components using the f27 branch for now. To produce a more reproducible and predictable result, I recommend you to use the generate_modulemd_with_hashes.sh script inside the dependency-report-scripts repository:
$ generate_modulemd_with_hashes.sh MODULE_NAME
The result will be stored at the same place as the previous modulemd, that was using branches as references.
$ ls output/modules/MODULE_NAME/MODULE_NAME.yaml
Install the module-build-service package from Fedora repositories:
$ sudo dnf install module-build-service
See the F27 Content Tracking repository and help with the modules that are listed, or propose new ones. You can also ask on #fedora-modularity IRC channel.
Please see the Fedora Modularity documentation website.
jonatoni)
on September 18, 2017 01:54 AM
Flock is where you meet with other members of the Fedora community who share whatever your interest is, whether that’s the kernel or the cloud, hardware or UX design. Flock 2017 took place in Hyannis, Massachusetts, on 29 August – 1 September and was a more action-oriented event than previous years. Day #0 This was […]
The post Flock to Fedora: Fedora Contributor Conference appeared first on Jona Azizaj.
till)
on September 17, 2017 02:53 PM
From 29 August to 1 September 2017 Fedora contributors from all over the world flocked to Hyannis, Massachusetts to meet and work on improving Fedora. I was lucky to be part of it.
Our leader Matthew Miller opened the conference with his State of Fedora presentation that included a perfect quote for Fedora:
Let’s put things on fire in a good way and make friends with robots!
For me this is a great motto that also fits the conference. To stay in the innovators/early-adopters space, Fedora needs to constantly change. Unavoidable, this results in fires. But we need to make sure these are good fires that create space for good, new things. We changed a lot of things to allow modularity and now we can build great things with it. The other part is about increasing automation. This is what hopefully will result from the fire when adopting pagure for dist-git. Now we have the infrastructure ready for automating more tasks for packaging. This matches one of the last sessions by Stef Walter about Continuous Integration and Delivery. There he shared his experience with integrating robots into the creation of Cockpit and described best practices in making robots an integral part of a team.
There were many other interesting sessions and luckily there will be recordings of most of them. For the Atomic Host 101 workshop Dusty Mabe prepared an interesting lab session that he published in his blog so you can do it at home, too. It gave nice introduction into the special properties of Atomic Host. Being there in person I had the advantage that I could ask questions to find out more about the details which Dusty and Colin Walters happily answered. This is in my opinion the great extra value of live workshops on which Flock focussed: Getting introduced into new topics and giving/receiving immediate feedback. It is great to see, that there are already further use cases for the technology behind Atomic Host besides using them as a container host. Patrick Uiterwijk and Owen Taylor shared their experience running Atomic workstation. It seems to be doable but be prepared for a lot of extra work. In his visionary session about Fedora IoT Peter Robinson suggested to make use of the atomic upgrades for IoT devices to reduce the risk of bricking devices and allowing to easier recover to a previously known-good state. The ideas for Fedora IoT sound very promising but they still need a lot of work to be implemented.
In an evening session there was an the Fedorator building workshop. After reading about it on the Ambassador mailing list it was very interesting to learn to how to build one and understand it’s design. I volunteered to take one back to Germany, so hopefully we can present them at one of the next conferences. Anyone going to OpenRheinRuhr? The workshops fits great into another topic our project leader promoted – improving the Fedora Ambassador work. He focused on improving what Ambassadors do. For example targeting more events matching the Fedora objectives would be an idea. To me it would be great for Ambassadors to decide more consciously which events to visit and to properly show off Fedora’s unique selling points. However, at least for me personally the critical criterion is usually the proximity to my home town and whether I have time to be there at all. Therefore it might take a while to get enough people and presentations/workshops together. to actively pursue this. I like the vision nonetheless. Speaking of improving the Ambassador work, I see also potential in improving how to represent Fedora at events. But this could be a full blog post on its own and I want to get this one finished.
In the Bodhi hacking session Randy Barlow and Jeremy Cline helped me setting up a Bodhi 2 development instance. I lost track of Bodhi development after the switch from Bodhi 1. The new setup with vagrant is very nice and allows to test new code very easily. We tried to improve the speed for Fedora Easy Karma to get it’s update information. Initially we hoped adding indexes to the database would help but it seems there is also a lot of serialization going on that might make Bodhi send a whole database dump in the end instead of just the necessary data.
The other sessions, the hallway track and social events were awesome, too. Everyone was very friendly and it was great to meet more people in person that I only knew online. The organizers did a great job as well. The main possibility for improvement would be to make the scheduling more collision-free. There were some sessions that did not get many attendees because sessions for the same target audience were at the same time. My sessions suffered from this as well. Maybe there could be a poll in advance to figure out which sessions people want to go at the same time and then plan the schedule with this feedback. The Chaos Communication Congress uses halfnarp for this. Maybe this is an option for Flock, too.
All in all I am happy to have been part of Flock 2017 and hope to be there in 2018 when it is back in Europe.
dgoodwin)
on September 17, 2017 12:17 PM
Last weekend I decided to play around with my old workstation that’s just been sitting around powered off for years now, mostly replaced by a RaspBerry Pi3 which handles most of my home network and storage. The workstation is from around 2009, isn’t particularly fast but has 6GB of RAM and doesn’t consume much power if you yank the video card. I have a small Rails 4 app running as a backend for one of my Android pet projects, and thought it might be fun to repurpose this machine to host it on OpenShift.
I really don’t want to have to think about upgrades much, CentOS would then be a pretty good option but I thought it would be better to get a taste of what’s been going on with Project Atomic, a minimal OS just for running containers, which allows you to upgrade and rollback the whole OS filesystem as if you were using git.
For an Atomic OS I went with Fedora Atomic. Normally Fedora would be too much upgrade maintenance for what I want, but being able to upgrade everything and reboot so easily with Atomic seems like it should negate that, and I’d like access to be able to see the latest work being done in this area. Fedora installation has become incredibly refined over the years since I started using it, installing Atomic was no exception. (just had to dd an ISO to a USB drive and boot off it)
Post install you might want to do a one time root partition extension so you can do Atomic upgrades:
$ lvresize --resizefs --size=+10G /dev/mapper/fedora--atomic-root
For a headless server you might want Cockpit for remote management:
$ atomic install cockpit/ws
$ atomic run cockpit/ws
At this point you can see it running locally with a curl to https://yourip:9090, but accessing it remotely was quite difficult. Fedora Atomic does not appear to be using firewalld, but does appear to have a default deny iptables policy in play. There’s got to be a better way but I worked past this with:
$ systemctl iptables stop
$ vi /etc/sysconfig/iptables
Right after the ACCEPT for ssh (port 22) I added:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 9090 -j ACCEPT
Finally:
$ systemctl iptables start
To install OpenShift Origin I went with openshift-ansible. Using something like oc cluster would probably be a logical option here for a single system but I wanted to stick to a more production focused path.
To do this we need an Ansible inventory:
[OSEv3:children]
masters
nodes
etcd
[OSEv3:vars]
openshift_deployment_type=origin
openshift_release=v3.6
openshift_image_tag=v3.6.0
containerized=true
ansible_ssh_user=root
openshift_uninstall_images=False
# htpasswd auth
openshift_master_identity_providers=[{'name': 'htpasswd_auth', 'login': 'true', 'challenge': 'true', 'kind': 'HTPasswdPasswordIdentityProvider', 'filename': '/etc/origin/master/htpasswd'}]
openshift_master_htpasswd_users={'dgoodwin': 'HASHEDPW'}
ansible_python_interpreter=/usr/bin/python3
[masters]
192.168.1.2 schedulable=true
[nodes]
# Master would be unschedulable by default leaving us with nowhere for pods to run.
192.168.1.2 schedulable=true
[etcd]
192.168.1.2
To get the hashed password you can just create a temporary htpasswd file:
$ htpasswd -c deleteme-file username
Copy the whole hashed password out of the file (including trailing ‘/’) and then delete it.
We’ll also need something for persistent storage. With a setup like this I just went with NFS using the following small playbook:
---
- hosts:
- masters
become: yes
tasks:
- file: path=/var/nfsshare state=directory mode=0777
- lineinfile: dest=/etc/exports line="/var/nfsshare/ 192.168.1.2/24(rw,sync,no_root_squash)"
- service: name=rpcbind state=started enabled=yes
- service: name=nfs-server state=restarted enabled=yes
- service: name=rpc-statd state=started enabled=yes
- service: name=nfs-idmapd state=started enabled=yes
This should probably be modified to create a few PV’s just as sub-directories in /var/nfsshare.
At this point you should be ready to run openshift-ansible. A recent addition was the ability to run openshift-ansible playbooks via a container rather than having to git clone. You can read more about this here.
After installation I needed a couple tweaks because this is a single system “cluster”, by default the master is not schedulable and thus you’ve got nowhere to run pods.
$ oc label node master.local region=infra
$ oadm manage-node master.local --schedulable=trueoadm manage-node master.local --schedulable=true
We also need to define a single persistent volume:
$ cat nfspv.yml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
nfs:
path: /var/nfsshare
server: 192.168.1.2
persistentVolumeReclaimPolicy: Recycle
$ oc create -f /root/nfspv.yml
At this point I had OpenShift origin up and running containerized on Fedora Atomic Host. You can operate as the cluster admin by using root on the Atomic host, but you’ll naturally want to login as the regular user we created earlier for actually using it to run applications:
$ oc login -u dgoodwin https://yourip:8443
This of course isn’t the most logical thing to do, a single node Kubernetes or OpenShift cluster doesn’t make a lot of sense. It is however, kind of fun to play with and have running in your basement. I really like Atomic for servers, having that small footprint and not having to worry about upgrades is really satisfying. OpenShift, even at such a small scale, is handy for building from source and keeping an eye on your logs.
Not sure how long I’ll keep it running, my $5 Linode was doing this job previously and was able to run my app as a straight container (no OpenShift) just fine, so realistically it might end up back there soon, but regardless it is presently fun to tinker with and learn about.
admin)
on September 17, 2017 11:09 AM
All this week, we will be testing for i18n features in Fedora 27. Those are as follows:
Other than this, we also need to make sure all other languages works well specifically input, output, storage and printing.
Most of the information is available on the Test Day wiki page. In case of doubts, feel free to send an email to the testing team mailing list.
Though it is a test day, we normally keep it on for the whole week. If you don’t have time tomorrow, feel free to complete it in the coming few days and upload your test results.
Let’s test and make sure this works well for our users!
The post Test Days: Internationalization (i18n) features for Fedora 27 appeared first on Fedora Community Blog.
renault)
on September 17, 2017 06:00 AM
Pour rappel, vous pouvez consulter l'état du travail en cours sur la documentation.
À cause des vacances et d'autres histoires personnelles, j'ai loupé le bilan d'août et j'ai moins contribué que la période juin-juillet. En cette rentrée, faisons quand même un bilan du travail abattu depuis deux mois.
Les sujets traités ont changé quelque peu. C'est plus centré autours des thématiques :
Personnellement je me suis occupé plutôt des deux premiers thèmes. Par exemple le dépôt de RPMFusion et les paquets multimédia qu'il propose sont un incontournable auprès des utilisateurs de Fedora. Il était important de s'y atteler car de nombreux paquets ont évolué, que ce soit des nouveaux venus, des évolutions majeures comme plus de codecs accessibles via mplayer ou GStreamer.
Concernant le deuxième point, il était nécessaire de revoir les procédures pour exploiter kickstart qui a évolué (notamment depuis l'apparition des Spins et des produits Server, Workstation et Cloud). Les moyens de télécharger Fedora ont changé, le Live CD a peu à peu laissé place au Live USB qui a été particulièrement mis en avant avec l'outil Fedora Media Writer. D'ailleurs l'installation d'un dual Boot avec Windows a aussi beaucoup évolué, car GRUB a changé avec sa version 2 ce qui a simplifié la procédure et Windows est aussi plus conciliant sur ce genre de cohabitation.
J'ai également rafraîchi la page d'aide pour contribuer à Fedora, car depuis le temps les sujets ont évolué, de nouvelles ressources ou secteurs ce sont développés comme l'assurance qualité et l'ajout aussi de la documentation francophone jusqu'ici absente.
Le dernier point a été particulièrement étudié par Nicolas, car Fedora a bien entendu un usage serveur important dont le paysage a changé. Outre MySQL devenu MariaDB, de nombreuses commandes ont changé avec l’évolution des outils. Si l’environnement web LAMP est surtout concerné, cela touche également SELinux, le serveur de courriel Dovecot et Openldap. Un énorme travail a été accomplis, donc merci à lui !
Je remercie également les autres contributeurs, relecteurs ou toute autres personnes qui se sont impliquées dans ce processus comme Édouard, Nicolas Chauvet, et d'autres.
Aujourd'hui donc, nous sommes à 42 articles traités, contre 25 au précédent bilan. Je suis satisfait des progrès réalisés sur la documentation. Il y a beaucoup de travail à mener encore, mais il semble possible que la documentation soit dans un état très acceptable d'ici Fedora 27 ou la fin de l'année 2017. Ensuite il faudra veiller à maintenir la documentation à jour continuellement et ajouter des articles suivant les besoins du moment.
Je vous invite en tout cas à nous donner un coup de main, pour cela je vous conseille de suivre la procédure pour contribuer à la documentation et si possible de participer à nos ateliers hebdomadaires tous les lundi soir à partir de 21h (heure de Paris) sur le canal IRC #fedora-doc-fr du serveur Freenode. Rien ne vous empêche de contribuer en dehors du cadre des ateliers, toute l'aide est la bienvenue. Alors, n'hésitez pas !
rajeeshknambiar)
on September 17, 2017 05:40 AM
Official Raspbian images based on Debian Stretch by default has the Pixel desktop environment and will login new users to it. But if you have had a Raspbian installation with another DE (such as LXDE), here are the steps to install and login to the Pixel desktop.
apt-get install raspberrypi-ui-modssed -i 's/^autologin-user=pi/#autologin-user=pi/' /etc/lightdm/lightdm.confupdate-alternatives --set x-session-manager /usr/bin/startlxde-pised -i 's/^Session=.*/Session=lightdm-xsession/' ${USER}/.dmrcMake sure the user’s ‘.dmrc’ file is updated with the new startlxde-pi session as that is where lightdm login manager looks to decide which desktop should be launched.
pbrobinson)
on September 16, 2017 11:00 PM
I’ve been meaning to write about the state of accelerated open source graphics options for a while now to give an update on a blog post I wrote over 5 years ago in January 2012, before the Raspberry Pi even existed! Reading back through that post it was pretty dark times for any form of GUI on ARM devices but with the massive changes in ARM devices and the massive change in SBCs (Single Board Computers) heralded by things like the Raspberry Pi have things improved at all? The answer is generally yes!
Looking back at that post the MALI situation is still just as dire with ARM still steadfastly refusing to budge. The the LIMA reverse engineering effort started with promise, but went up in smoke with a fairly public community break down, I don’t envision that situation improving any time soon although just recently there appears to be some forward movement happening finally after a long silence. This only covers the MALI-400 series and any newer GPU is a completely different architecture/IP. Even with sessions recently at Linaro Connect titled What’s happening with ARM Mali drivers I don’t see fast change here.
The Imagination Technologies PowerVR is still just as dire as situation as it was five years ago. The company’s incompetent management recently managed to avoid being bought by Apple which in turn, because they’ve screwed the open source community while milking the Apple cash cow, essentially means they’re screwed. I suspect they’ll either open source to try and remain a relevant contender or die in a tire fire. Only time will tell there, in the mean time any ARM SoC that has this IP on board is useless for anything graphical so I’d tend to avoid it, thankfully there seems to be less of them these days.
Despite the two bad examples above there’s actually been a lot of good change in the last five years. We now have a number of options for fully accelerated 2D/3D graphics on ARM SoCs and I run GNOME Shell on Wayland, yes the full open source shiny, on a number of different devices regularly.
NVIDIA true to the rumours did open up all the graphics on the Tegra series of hardware. The new Tegra K/X series have GPUs similar to their x86 offerings with Kepler/Maxwell/Pascal GPU cores but NVIDIA supports these devices by contributing to the nouveau open driver rather than the closed x86 driver. The performance on 32 bit TK1 devices has been decent for a number of releases of Fedora and improves all the time, we’ll be supporting the X series (X1/X2) with their Maxwell/Pascal GPUs in Fedora 27.
In the old post I brushed past Vivante with a mere mention of Marvell and Freescale (now NXP). The Vivante GPUs ship in NXP i.MX6 and i.MX4, some Marvell chips and some TI chips. There was a reverse engineering effort called etnaviv that must have started not long after I wrote that post and after a number of years of development support landed upstream in the kernel late 2015, and in mesa in the 7.1 release allowing us to support fully accelerated Wayland in Fedora 26! Did anyone notice? I didn’t really yell about it as much as I should have! It supports fully accelerated 3D in mesa/wayland, is pretty stable and is improving all the time, well done to all the contributors to that effort!
Another I brushed past in the old post was the Qualcomm Snapdragon SoC. They ship with a Adreno GPU. This was previously closed source, with the SoC primarily used by phone/tablet manufacturers I suspect they didn’t care… until Rob Clark (and no doubt there were other contributors) decided to reverse engineer the driver with the open freedreno driver. This is now the default driver with even Qualcomm contributing to it. We’ll support this in Fedora 27, initially with the 96boards Dragonboard 410c using the freedreno driver, but I doubt it’ll be the last Qualcomm based device we support. The Snapdragon 835 SoC, the device in all the high end Android phones this year and the ARM Windows 10 laptops, is really nice with decent performance, I’d love to be able to support a device with that SoC!
Raspberry Pi, as I mentioned in the introduction, wasn’t even out in when I wrote the original post. When it fist launched there wasn’t an open driver but 5 years later there is, sponsored by Broadcom no less. We introduced initial support for the Raspberry Pi with the open vc4 driver by Eric Anholt in Fedora 25 and it’s improving regularly. It supports fully accelerated 3D in mesa/wayland, and 2D via glamor in mesa.
So in conclusion we have improved by A LOT! We now have numerous different GPUs with open drivers to choose from in all price ranges that support fully accelerated 2D/3D desktops from four different vendors on both ARMv7 and aarch64. The media acceleration offload is also looking quite good, but that’s one for another post. The biggest holdout is MALI, and that would need two open drivers or ARM to come to the table, LIMA might work out for the 400 series, but that won’t work on the newer midguard series. With support in a number of drivers for the shiny new Wayland there’s an increasing number of devices people can use to enjoy the latest desktops fully accelerated!
renault)
on September 16, 2017 09:30 PM
Je n'ai pas écrit de bilan de Rawhide en juin, juillet et août, l'approche de la version finale de Fedora 26 a amené trop peu de changements visibles pour que ce soit pertinent de les noter au départ puis j'ai manqué de temps pour traiter les avancées de Fedora 27.
Fedora 26 étant disponible depuis le 11 juillet, mon ordinateur personnel est repassé aussi tôt sur Fedora Rawhide qui est devenu il y a un mois Fedora 27 en devenir.
Fedora 27 Beta va d'ailleurs bientôt arriver, d'ici quelques semaines. Ce sera une première sans version Alpha préliminaire.
Dès le début GNOME 3.26 a des changements assez visibles. Je vous invite à lire les notes de versions pour plus de détails (et les illustrations). L'utilitaire gnome-tweak-tool a été remanié, les options sont plus nombreuses et le style de sélection ressemble à l'interface de GNOME Builder. Le centre de contrôle de GNOME a été également très modifié, avec une nouvelle organisation via cette barre latérale permanente et la refonte de nombreuses pages comme ce qui touche à l'affichage ou au réseau.
Je ne sais pas pourquoi mais la police par défaut de GNOME Terminal (police à chasse fixe) est Monospace Regular ce qui change bien entendu le rendu.
Quand les fenêtres dans GNOME sont rétrécies ou agrandies, il y a un nouvel effet visuel. Rien de sensationnel, mais c'est plutôt agréable sans pertes de performance dans la foulée j'ai l'impression. La barre de GNOME devient également transparente s'il n'y a pas de fenêtres maximisées.
Pendant quelques semaines, Empathy a également bénéficié de la refonte de son interface pour être plus homogène avec les autres applications GNOME en adoptant une interface proche de Polari. Mais cela était expérimental et l'interface habituelle a repli place. En espérant qu'il reviendra bientôt.
Et bien d'autres que je n'ai sans doute pas remarqué ou qui sont plus insignifiants.
Rawhide comporte bien évidemment de bogues. Même si des procédures doivent être mises en place durant ce cycle pour améliorer la qualité globale de cette branche de Fedora, des bogues importants resteront probablement présents.
En premier lieu, mon système de fichier /home chiffré avec LUKS n'était plus monté automatiquement. C'est plutôt gênant, on doit le faire à la main mais heureusement sans autres conséquences notamment en terme de cohérence des données. Heureusement corrigé depuis.
Un autre bogue, assez pénible, le sélecteur de fichier de GTK crashe. Donc dès qu'il faut choisir / ajouter un fichier dans un programme, l'application plante. Cela a été corrigé avant que je n'en fasse un rapport.
Firefox 55 a été oublié des mises à jour des paquets, à la base
suite à des soucis pour le compiler puis par oubli du mainteneur. 
Sinon GNOME est très instable. La session se ferme régulièrement (toutes les heures presque) voire à certains moment comme à l'ouverture d'une machine virtuelle. Beaucoup de rapports de bogues tournent autours de ce sujet. Il semble que le composant gjs soit le fautif et une correction semble en cours. C'est rare que GNOME soit autant en difficulté et étant donné l'importance du sujet Fedora bloque l'évolution du cycle de F27 le temps que cela se calme.
Let me start by annoying you with some pictures:
<3 Randa
The misty mountains below which the coders dwell.
We totally had snow in September. Well, not in Randa, but in the valley next to it, but still. SNOW!
And now for the serious part: in my last blog post, I talked about achieving our main goal for this year’s Randa meetings – we successfully ported the entire Kontact away from the obsoleted KDateTime class. Since we finished this on Thursday, there was still enough time left to start working on something new and exciting.
Volker and Frederik went on to work on a KWin plugin to simulate various kinds of color blindness which will help developers to see how visually impaired users see their software, I did a bit more code clean-up after the porting and a bit of code-review.
On Friday morning Volker and I discussed search in KDE PIM. Broken and unreliable search was one of the most often mentioned issues in the KMail User Survey, which we ran for the past month and a half, so I decided to tackle the problem and make our indexing and searching infrastructure fast and reliable.
The final plan consists of several phases – starting with reorganizing our current code to put related pieces of code (like email indexing and querying code) into a single place to make the code easier to maintain. This phase is already progressing and I hope to finish it within the next week. The second phase will involve moving the code that is responsible for indexing data into the backend Resources – whenever a backend retrieves an email from an IMAP server or an event from Google Calendar it will also index it and will send the index data alongside the raw data to Akonadi. Akonadi will then take care for just writing the data into the Xapian database. This will speed up indexing, reduce the IO load and will ensure that all data are reliably indexed and stored before they are presented in Kontact. The third phase will involve changing Kontact to query the index database directly, instead of asking Akonadi to do it for us. This will speed up the search and provide results faster. The final phase will focus on which data we are actually indexing. As they say – less is sometimes more – so having fewer, but better-defined data will allow us to provide better and more exact search results to the user.
Once this is settled, we can make applications to depend on the search index – for example KOrganizer will be able to query the index to only get events from e.g. December 2017 instead of fetching all events from the calendar and then figuring out if they should be displayed or not, making calendars of even the busiest people to load instantaneously.
All in all, it was an extremely productive hackfest for the PIM team and I’d again like to thank Mario, Christian and the rest of the Randa team for organizing the hackfest. You guys rock!
And remember, you can still donate to the Randa fundraiser to make future productive sprints possible!
I had the opportunity to spend some time in Montreal last week to meet with some lovely font designers and typophiles around the ATypI conference.
At the conference, variable fonts celebrated their first birthday. This is a new feature in OpenType 1.8 – but really, it is a very old feature, previously known under names like multiple master fonts.
The idea is simple: A single font file can provide not just the shapes for the glyphs of a single font family, but can also axes along which these shapes can be varied to generate multiple variations of the underlying design. An infinite number, really. Additionally, fonts may pick out certain variations and give them a name.
A lot has to happen to realize this simple idea. If you want to get a glimpse at what is going on behind the scenes, you can look at the OpenType spec.
A while ago, Behdad and I agreed that we want to have font variations available in the Linux text rendering stack. So we used the opportunity of meeting in Montreal to work on it. It is a little involved, since there are several layers of libraries that all need to know about these features before we can show anything: freetype, harfbuzz, cairo, fontconfig, pango, gtk.
freetype and harfbuzz are more or less ready with APIs like FT_Get_MM_Var or hb_font_set_variations that let us access and control the font variations. So we concentrated on the remaining pieces.
As the conference comes to a close today, it is time to present how far we got.
This video is showing a font with several axes in the Font Features example in gtk-demo. As you can see, the font changes in real time as the axes get modified in the UI. It is worth pointing out that the minimum, maximum and default values for the axes, as well as their names, are all provided by the font.
This video is showing the named variations (called Instances here) that are provided by the font. Selecting one of them makes the font change in real time and also updates the axis sliders below.
Eventually, it would be nice if this was available in the font chooser, so users can take advantage of it without having to wait for specific support in applications.
This video shows a quick prototype of how that could look. With all these new font features coming in, now may be a good time to have a hackfest around improving the font chooser.
One frustrating aspect of working on advanced font features is that it is just hard to know if the fonts you are using on your system have any of these fancy features, beyond just being a bag of glyphs. Therefore, I also spent a bit of time on making this information available in the font viewer.
And thats it!
Our patches for cairo, fontconfig, pango, gtk and gnome-font-viewer are currently under review on various mailing lists, bugs and branches, but they should make their way into releases in due course, so that you can have more fun with fonts too!
duffy)
on September 16, 2017 06:30 PM
I’ve been slowly moving my website from the official pelican-based version to an in-progress Wix-based version. I learned interesting things around current web development while using the Pelican version, but I found it difficult to implement the kinds of design choices I wanted to make. I also found it quite difficult to get a responsive design that _stayed_ responsive when I made changes to the CSS file.
Wix is very nice for many design decisions, in large part because one can take a particular design element and put it wherever you want on the page. There is no futzing with the HTML or CSS, and no need to learn Python or Javascript.
Given that I want my page to be welcoming and easy to follow, easily choosing specific design elements is vital.
One of the most important aspects of a UX portfolio is demonstrating one’s UX skills. This means walking folks through your process and making it easy to follow and understand.
One of my major challenges was (and is!) deciding how to structure my portfolio to offer the greatest ease of use without losing too many of the specific details. Upon the recommendation of one of the many recruiters I’ve spoken with, I’ve been adding an overview page to each piece of my projects:
<figure>
<figcaption>In this version, I offer an overview and links to more details of some of the pieces.</figcaption></figure>If you compare this to the currently official version of my page, it’s a clear and huge difference in usability:
<figure>
<figcaption>This doesn’t show the overall goal, what my role was, or offer much guidance. It’s also not physically structured for easy reading.</figcaption></figure>One of my major struggles is with offering too much information. Too many details, and too little structure.
I want people to know what I did! Unfortunately, if there’s not enough structure, they won’t read any of it. If there’s too much information, they won’ read any of it. So my major task is to take what I have and create overviews; not just for the main page of a project, but for sub pages.
This is unfortunately not quick or easy! As a result, I’m working on bringing the overviews back to my pelican site as I make them, with the eventual goal of fully transitioning. Sadly, I have been unable to convince my pelican site to let me stack things horizontally. My impression is that this is one of the major improvements to my Wix site, so even though I’ll bring some of the ideas back to Pelican, they are simply not as well-designed there.
I’ll be asking for feedback before I move over completely, of course. In the meantime, it’s pretty clear to me that my Wix site is just _better_. I’ll also be grabbing what I have at the Pelican site before ditching it, as I will worry that I’d lose information otherwise.
I’m also ditching the references to Cambio Buddies. It was a valuable and useful project, but I had very little guidance for what I was doing. I made a lot of mistakes, used techniques poorly, and am generally not happy with that project. Maybe it’s a mistake to remove my first project, but I just don’t like it.
Some folks have suggested incorporating the ‘current’ and ‘complete’ design projects into a single area. I’m reluctant to do this, since the current projects are still in process: I don’t want to be presenting them as if they were finished when they are not.
Similarly, folks have suggested getting rid of the design artifacts page. I’m not completely clear on why: they are in the Projects area, and it seems helpful to let folks get to a specific artifact quickly if they so desire.
One of my early bits of feedback for the Pelican portfolio was a lack of process. I’m still not entirely clear on what was meant by that, although I suspect that the lack of overview may have been part of it.
petersen)
on September 16, 2017 06:20 PM
duffy)
on September 16, 2017 06:03 PM
Hi folks!
I’ve been meeting, finding, and interviewing folks at various points in their UX careers. It’s been fascinating, and reminds me that I’m _much_ better at networking when I have a reason to talk to people.
I’ve not yet had a chance to analyze my interviews in depth thus far, but I have noticed some interesting trends.
This is a significant problem. Given that few places are hiring folks without a couple of years of experience, newbies and career changers need to find ways to get that experience.
For those who can afford it and have access, in-person UX programs like Bentley’s master’s in human factors program and Jarod Spool’s Center Centre are an excellent choice. These offer curated and guided information, connections, and practice at design. Unfortunately, these and other programs rely on proximity and available time and money, and are not inexpensive (although Center centre tries to mitigate that part).
There are also online courses which can be helpful, and bootcamps both on and offline, but these again cost money and may or may not offer built-in networking.
So how does one find work, even if unpaid? There’s a few options that I am aware of:
Options 2 and 6 may be more difficult for designers just starting out, as they are much easier to do if one has some guidance for how to approach design problems.
Mentorship is really important, especially if you cannot afford to attend school and get guidance that way. Unfortunately, it can be difficult to find a mentor, and precisely what a mentor can offer or do for you varies by the mentor.
Ideally, I think that mentors should offer:
Beyond this, it’d be lovely if mentors could offer networking help (eg: connections to open positions and folks who may eventually have open positions), and suggestions for projects to work on.
The XX UX community offers a mentorship matching program in some cities, although Boston is not yet one of them. This may be another opportunity for my project to help folks out, whether by working with XX UX (which would mean it’s only available to women), or by building on their example and making our own program.
Given how much information there is out there, a possible way to help folks out would be to offer resources that experienced UX folks agree would be useful to those who are starting out.
These resources could include basic guidance for portfolios for various design specialities, design interviews (including design exercises), and job applications, as well as structure within which to learn design processes.
Also relevant might be instruction on persuasion, on communicating and working within cross-functional teams, and on presentation skills (both creating a presentation and presenting it).
We might want to include specific information such as the use of short-cut keys within design programs (Ctrl d, alt Ctrl shift arrow keys for movement, etc), recommendations for tools to start out with and an introduction to their use, and suggestions for how to use those tools to more easily share and maintain one’s designs (since all good design involves many different folks in various different teams).
Finally, we could offer recommendations for good books for folks in various stages of learning.
One of the most important things for someone new to a field is to keep learning. Be visibly interested in and passionate about your field: it’ll communicate itself to those you are working with, and will help keep you informed and aware of what’s going on.
At the same time, don’t believe everything you read — some folks make things look more clear-cut and simple than actually happens. Reality is messy!
Don’t be afraid to try things out. No one in UX knows everything about it, and mistakes are how to learn.
Remember to mention others who had a role in any design you talk about: design isn’t typically an individual process (collaboration is important!), and hiring managers want to know that you understand and can talk about your role in the project.
If you’re interested in research, learn both qualitative and quantitative methods. Most of your work will probably be in qualitative spaces, but it’s useful to be able to measure success (are we accomplishing our goals?). It’s also helpful to understand basic data visualization techniques.
Remember to take pictures at all stages of your process! This will be hugely helpful when it comes time to make your portfolio.
This year I had the opportunity to attend Flock to Fedora for the first time. I had previously attended two FUDCons in the LATAM region, so this was a new experience for me as this conference only takes place in the North America and EMEA regions. Flock 2017 itself had a different focus, that is, do-sessions rather than just talks.
I will focus on three sessions that I attended, those what were of particular interest to me and from which I learnt the most.
This was a workshop on adding tests that are written as Ansible playbooks to Fedora packages. This is done by adding a tests directory in the dist-git repository for the package or module, and anyone will be able submit pull requests for any package to add tests via Pagure once the proper infrastructure is put in place, but for now, you need to create a repository in the https://upstreamfirst.fedorainfracloud.org repositories.
We were first shown a simple example for adding tests with the gzip package. All the steps are documented in the wiki at https://fedoraproject.org/wiki/CI/Tests#Testing_specific_RPMs. Since I had no previous experience with Ansible, I had to learn the very basics during the workshop itself, but that was good enough for this session’s purpose.
I started working on adding tests to one of the packages I am a maintainer for: nik4, a tool to export OpenStreetMap data to raster image formats. I expect to be able to push them very soon as I still have to figure out what input file would cover the most important corner cases and how to setup a database for the test pulling the minimum amount of packages. Since there are on tests at all in %check for this package, there is no need to migrate them to the CI infrastructure.
This was an open session with no actual slides or material to be presented as this was more discussion-oriented. Several issues were discussed, namely arbitrary branching (something that will not affect the kernel package), non-Red Hat participation in Fedora kernel maintenance, and alternative architectures (as of now cannot be shipped on Copr was builds take too long and timeout), but most of the time was spent on the workflow for fixing kernel bugs.
The Fedora kernel is not very different from upstream, as there are just about 80 out-of-tree patches applied to the kernel shipped by downstream. Users are welcome to request new modules to be enabled via Bugzilla, as long as they have a good reason for it.
Currently there are only two kernel maintainers who are full-time employees at Red Hat, and they have to deal with a whole bunch of very low quality bug reports, specially from ABRT, which are mostly ignored. Their main priority is to have CVS covered. A major problem is that the kernel team does not have a variety of hardware for testing, so having more users running the tests from the Kernel Testing Initiative will help to catch more hardware-specific bugs.
An idea that came out of this discussion was to organize a Kernel Test Day as part of the schedule for every Fedora release starting from F27, so we are expecting to see this happening on September after the Linux Plumbers conference.
I also attended very interesting sessions on modularity and Fedora Atomic. I found myself writing a Dockerfile for python-spyder for submission for review, that still needs some work. I also got a Fedorator that took back to Nicaragua and is ready for events, thanks to Neville Cross.
Better late than never, here’s my report from Flock 2017!
Thanks to my excellent foresight in the areas of ‘being white’ and ‘being Canadian’ I had no particular trouble getting through security / immigration, which was nice. The venue was kinda interesting – the whole town had this very specific flavor that seems to be shared among slightly second-class seaside towns the world over. Blackpool, White Rock or Hyannis, there’s something about them all…but the rooms were fairly clean, the hot water worked, the power worked, and the wifi worked fairly well for a conference, so all the important stuff was OK. Hyannis seriously needs to discover the crosswalk, though – I nearly got killed four times travelling about 100 yards from the hotel to a Subway right across the street and back. Unfortunately the ‘street’ was a large rotary with exactly zero accommodations for pedestrians…
Attendance seemed a bit thinner than usual, and quite heavily Red Hat-y; I’ve heard different reasons for this, from budget issues to Trump-related visa / immigration issues. It was a shame. There were definitely still enough people to make the event worthwhile, but it felt like some groups who would normally be there just weren’t.
From the QA team we had myself, Tim Flink, Sumantro Mukherjee and Lukas Brabec. We got some in-person planning / discussion done, of course, and had a team dinner. It was particularly nice to be in the same place as Sumantro for a while, as usually our time zones are awful, he gets to the office right when I’m going to bed – so we were able to talk over a lot of stuff and agree on quite a list of future projects.
The talks, as usual, were generally very practical, focused and useful – one of the nicest things about Flock is it’s a very low-BS conference. I managed to do some catch-up on modularity plans and status by following the track of modularity talks on Thursday. Aside from that, some of the talks I saw included the Hubs status update, Stef’s dist-git tests talk, the Greenwave session, the Bodhi hackfest, Sumantro’s kernel testing session, and a few others.
I gave a talk on how packagers can work with our automated test systems. As always seems to be the case I got scheduled very early in the conference, and again as always seems to be the case, I wound up writing my talk about an hour before giving it. Which was especially fun because while I still had about ten slides to write, my laptop starting suffering from a rather odd firmware bug which caused it to get stuck at the lowest possible CPU speed. Pro tip: LibreOffice does not like running at 400MHz. So I wasn’t entirely as prepared as I could have been, but I think it went OK. I had the usual thing where, once I reached the end of the talk, I realized how I should have started it, but never mind. If I ever get to give the talk again, I’ll tweak it. As a footnote, Peter Jones – being Peter Jones – naturally had all the tools and the know-how necessary to take my laptop apart and disconnect the battery, which turned out to be the only possible way to clear the CPU-throttling firmware state, so thanks very much to him for that!
As usual, though, the most productive thing about the conference was just being in the same place at the same time as lots of the folks who really make stuff happen in Fedora, and being able to work on things in real time, make plans, and pick brains. So I spent quite a lot of time bouncing around between Kevin Fenzi, Dennis Gilmore, and Peter Jones, trying to fix up Fedora 27 and Rawhide composes; we got an awful lot of bugs solved during the week. I got to talk to Ralph Bean, Pingou, Randy Barlow, Pengfei Jia, Dan Callaghan, Ryan Lerch, Jeremy Cline and various others about Bodhi, Pagure, Greenwave and various other key bits of current and future infrastructure; this was very useful in planning how we’re going to move forward with compose gating and a few other things. In the kernel testing session, Sumantro, Laura Abbott and myself came up with a plan to run regular Test Days around kernel rebases for stable releases, which should help reduce the amount of issues caused by those rebases.
We started working on a ‘rerun test’ button for automated tests in Bodhi during the Bodhi hackfest; this is still a work in progress but it’s going in interesting directions.
davidcarlos)
on September 15, 2017 03:10 PM
Because of my work on Google Summer of Code this year, I was invited to attend to the Fedora Contributor Conference (Flock) as volunteer, helping the organization staff to record some sessions and writing about what was discussed on then. This year, the FLock Conference was in Cape Cod, Massachusetts. Was a incredible experience, allowing me to keep up with great discussions made by the Fedora developers. On this post I will make a resume of what was discussed on the session Gating on automated tests in Fedora - Greenwave, proposed by Pengfei Jia.
Bodhi is the Fedora service that permits developers to propose a package update for a Fedora distribution. Beyond several functionalities of Bodhi, one that is important for us its that it queries ResultsDB for automated test results and displays them on updates. Greenwave, tool presented on the session, is a service that Bodhi will query to decide if an update is ready to be pushed, based on its test results.
The main purpose of Greenwave is to improve the use of automated tests on Bodhi, mainly because now a day, the automated tests (executed by taskotron) serves only for visualization, not having a useful integration with Bodhi. This is a problem because the developer can release a new update, without check if the tests are passing, and this can break other packages on Fedora. Greenwave, to avoid packages with broken tests, defines policies, to enforce checking the result of some tests.
The main purpose is to make available to developers, an API, that they can define polices that Greenwave will use to check the result of specific tests, telling Bodhi (with fedmsg) what was the result of the tests. Based on Greenwave response for some package tests, Bodhi can decides if a new update can be released. On this link, you can find a example of the use of Greenwave API, and how it policies works. Greenwave will use ResultsDB to access test results. On the session, one of the participants, asked if would not be better if packagers manually check the policies, during the package development. The answer was that these policies are running for four years, and the participant was the first that proposed that, so enforcing checking these policies is something necessary during Fedora updates.
This was my second Flock conference. The last Flock I attended was in 2014. This time it happened in CapeCod, MA, US from 29th August to 1st September. This Flock was also a nice experience.
This time there was no keynote session (as per schedule and also as told on flock-planning list) but the only first talk for day 1 was “Fedora State of the Union” from Fedora Project Leader Matthew Miller.
He talked about history of Fedora releases their usage, downloads per release in graphs. One of the graph showed number of IP connections to Fedora update servers is getting increased per release, another graph Geologic Eras of Fedora showed which Fedora release series was used most by users. He then given importance that Fedora Atomic CI and Fedora Modularity are the upcoming development in Fedora.
I attended some talks and Do-sessions from which I will write here for few of them.
I attended workshop on “Become a Container Maintainer“. This was a very useful workshop. I have been doing a package reviewing for many years now. Fedora project added namespaces in PkgDB which enabled containers, modules which made adding containers and modules easy in Fedora. For the last few months I found few Container specs that is Dockerfiles have been submitted for reviews. I was interested in trying reviewing few of Containers but did not get time but after attending this workshop, I got to know few concepts that Fedora has introduced while writing Dockerfiles for Fedora containers. During workshop we formed a group of 2 peoples and asked to write a Dockerfile for whichever software we want to containerize. Then our dockerfile has been given to another group for review. This was very helpful exercise. Hopefully I will look more into Container guidelines and try reviewing Dockerfiles getting submitted to Fedora. Thanks to Adam Miller and Josh Berkus for such a nice workshop.
Another workshop I attended was “Atomic Host 101“. For this workshop Dusty already provided needed lab files and images that I already downloaded day before. So it was easy start for me for this workshop. Dusty first gave introduction to Atomic concept. The workshop was divided into parts. Starting with preparing for this workshop as part0 to containerizing applications as part05. If someone want to follow this workshop stepwise then start with this blog post. This workshop provided how to use rpm-ostree commands, few things about container storage, how one can upgrade or rollback atomic host, some commands to try the experimental features Atomic is providing currently.
One of the talk I attended was “New Container Technologies” where Dan Walsh presented about new things coming for Containers. He discussed about Open Container Initiative (OCI) which is designing open standard for containers, Skopeo project which provides pulling container images from remote registries, images information. Then he discussed about image signing goals, System containers which can be installed by atomic command where skopeo is used to pull image and ostree to store image layers on disk. Then he discussed about standalone containers, container image development tools buildah. Then he gave some introduction to CRI-O project and shown some kpod tools which is management tools for CRI-O. This was one of the good session to know what development is happening for containers currently.
Another talk I attended was “Automate Building Custom Atomic Host with Ansible” where Trishna Guha talked about architecture of Atomic host, conventional way of 8 steps on how to compose own tree. Then she explained how this much 8 steps work can be simplified with the usage of Ansible. With the use of Ansible it become already easy to deploy things now.
This time Flock was organized differently that mean specific topic wise tracks. These tracks were having a mix of Do-Sessions and Talks (and 2 hrs lunch break daily). I like the concept of such schedule but then I saw some advantages and disadvantages. The advantage I saw that 2+ hours Do-Sessions proved to be very productive. As it was for longer duration and covered the given topics in detail, the attendees got that topic learned in detail. But for few such sessions there was another parallel good talks were going that I could not attend. The point I want to say here is that if there are only talks in parallel then one can choose one and skip others and can watch video later. But when you need to choose between one 2 hours workshop vs one or few talks then it becomes difficult. Also, one can say here that I can just attend workshops and watch videos of talks later but then you will loose chance to listen to the session presenter and if you got some queries then you can resolve it at the same time in the talk session.
Overall Flock was a nice experience. All we saw people were talking about these words only Atomic, Containers, Modularity. One of the good thing was the session “Advertise your session” on first day where I got a chance to see every session owner and also got to know about what they have planned for their session. Another good thing was on last day, last session where people talked about what they achieved and what they have planned for future. Also, first 3 days were having 2 hours of lunch break which really proved good to discuss some topics with other Flock attendees. Keep these things for next Flock also.
My suggestion for future Flock conference will be to keep only talks in parallel for say 2 or more days and rest of day workshops or daily morning session talks and post lunch workshops but not to mix them.
I want to thank to Flock organizing committee for such a nice selection of hotel and conference venue. I liked it much. Also thanks to Red Hat for sponsoring my air travel to this Flock.
davidcarlos)
on September 15, 2017 01:10 PM
Because of my work on Google Summer of Code this year, I was invited to attend to the Fedora Contributor Conference (Flock) as volunteer, helping the organization staff to record some sessions and writing about what was discussed on then. This year, the FLock Conference was in Cape Cod, Massachusetts. Was a incredible experience, allowing me to keep up with great discussions made by the Fedora developers. On this post I will make a resume of what was discussed on the session The Future of fedmsg?, proposed by Jeremy Cline.
The Fedora infrastructure have several different services that need to talk to each other. One simple example is the AutoQA service, that listen to some events triggered by the fedpkg library. If we have only two services interacting the problem is minimal, but when several applications request and response to other several applications, the problem becomes huge. FEDerated MeSsaGe bus (fedmsg), is a python package and API defining a brokerless messaging architecture to send and receive messages to and from applications.
fedmsg does not have a broker to manage the publish/subscribe process, done by the services that interacts with it. This leads to a problem of performance and reliability, because every service that consumes a message from fedmsg have to subscribe to every existent topic. Other issue with the absence of a broker, is that it is common to lose messages, that not always get to the destination. Jeremy proposed to use a broker (or several brokers) to fix these issues, and made a demo code showing the benefits of using a broker, instead of the current architecture of fedmsg.
A great discussion emerged from this demo code, including the reflection if Fedora really needs that fedmsg be reliable. Other problem pointed by Jeremy was the documentation of fedmsg, and the existent tools to consume and publish messages (fedmsg-hub have a setup that is quite confuse). This was my review of the session, and based on my work on Google Summer of Code (I had used fedmsg to consume the Anitya events), I agree with Jeremy. Adding a broker to manage the publish/subscribe process, could improve the consume of resources of fedmsg, would facilitate to add new services consuming messages from the API and would make fedmsg more reliable.
If you wasn’t aware, Fedora users can create their own user information page on a wiki. Mine for example is https://fedoraproject.org/wiki/User:Paulmellors [please note that’s it’s currently pretty sparse]
One of the more interesting things on the page is my list of badges. I’ll not explain what they are as you can read it here
To add a list of your badges to your wiki, all you need to add to the page is this
{{ #fedorabadges: paulmellors }} just make sure you replace my username with your own and you’ll have all your hard earned shiny badges on your wiki. #funtimes
Alternatively, you can add an infobox that displays all your information [including badges], this is the wiki code for mine
{{Infobox user
|REAL-NAME= Paul RJ Mellors
|location= Nottingham, UK
|birthday= April 15, 1972
|fas-name= paulmellors
|email=paulmellors@fedoraproject.org
|irc-nick= MooDoo
|irc-channels= #fedora-ambassadors #fedora-uk #fedora-diversity #fedora-mktg #fedora-join}}
Now you can populate your wiki page with information that people might like to read, one way of getting to know you, you never know someone might like to buy you a beer one day……[hint hint] 
COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.
Here’s a set of new and interesting projects in COPR.
Exa is an alternative for the ls command. By default it uses colors to distinguish between different file types and access permissions. It also can show status of source code managed by git, and show directories with a tree view. Exa is written in the Rust programming language.
The repo currently provides exa for Fedora 25, 26, and Rawhide. To install exa, use these commands:
sudo dnf copr enable eclipseo/exa sudo dnf install exa
Bazel is a tool that automatically builds and tests software. It can produce packages for deployment on Android and iOS. It uses the Bazel query language to declare dependencies. Bazel can also produce dependency graphs of the entire source code. Thanks to these graphs, it rebuilds only what is necessary. Bazel supports Python, Java, C++, C and Objective C natively. It also works with any other language using its extension language, Skylark.
The repo currently provides Bazel for EPEL 7 and Fedora 24, 25, 26, and Rawhide. To install bazel, use these commands:
sudo dnf copr enable vbatts/bazel sudo dnf install bazel
Riot is a client for the decentralized messaging and data-transfer protocol Matrix. It supports voice and video conferencing, and customizable and keyword specific notifications. It allows file-sharing as well, including file archiving. Riot also can connect to other communicating systems like IRC, Slack and Gitter.
The repo currently provides Riot for EPEL 7 and Fedora 25 and 26. To install the Riot package, use these commands:
sudo dnf copr enable ansiwen/Riot sudo dnf install riot
This package collects several simple one-player puzzle games. It includes favorites like minesweeper, sudoku, n15-puzzle, and many others. It uses its own framework to enable the games to run on multiple platforms. The games are written in C.
The repo currently supports Fedora 24, 25, 26, and Rawhide. To install the puzzles, use these commands:
sudo dnf copr enable ribenakid/puzzles
sudo dnf install puzzles
adamwill)
on September 15, 2017 02:34 AM
So the other day I noticed this rather unfortunate bug on one of my servers.
Fedora 26 included a jump from DNF 1.x to DNF 2.x. It seems that DNF 2.x came with a poorly-documented change to the implementation of dnf-automatic, the tool it provides for automatically notifying of, downloading and/or installing updates.
Simply put: if you had enabled dnf-automatic in Fedora 25 or earlier, using the standard mechanism it provided – edit /etc/dnf/automatic.conf to configure the behaviour you want, and run systemctl enable dnf-automatic.timer – then you upgraded to Fedora 26, then it probably just stopped working entirely. If you were relying on it to install updates for you…it probably hasn’t been. You can read the full details on why this is the case in the bug report.
We’ve now fixed this by sending out an update to dnf which should restore compatibility with the DNF 1.x implementation of dnf-automatic, by restoring dnf-automatic.service and dnf-automatic.timer (which function just as they did before) while preserving the new mechanisms introduced in DNF 2.x (the function-specific timers and services). But of course, you’ll have to install this update manually on any systems which need it. So if you do have any F26 systems where you’re expecting dnf-automatic to work…you probably want to log into them and run ‘dnf update’ manually to get the fixed dnf.
PSA ends!
Release Candidate versions are available in remi-test repository for Fedora and Enterprise Linux (RHEL / CentOS) to allow more people to test them. They are available as Software Collections, for a parallel installation, perfect solution for such tests (for x86_64 only), and also as base packages.
RPM of PHP version 7.1.10RC1 are available as SCL in remi-test repository and as base packages in the remi-test repository for Fedora 26-27 or remi-php71-test repository for Fedora 24-25 and Enterprise Linux.
RPM of PHP version 7.0.23RC1 are available as SCL in remi-test repository and as base packages in the remi-test repository for Fedora 25 or remi-php70-test repository for Fedora 24 and Enterprise Linux.
PHP version 5.6 is now in security mode only, so no more RC will be released.
PHP version 7.2 is in development phase, version 7.2.0RC2 is also available.
Installation : read the Repository configuration and choose your version.
Parallel installation of version 7.0 as Software Collection:
yum --enablerepo=remi-test install php70
Parallel installation of version 7.1 as Software Collection:
yum --enablerepo=remi-test install php71
Update of system version 7.0:
yum --enablerepo=remi-php70,remi-php70-test update php\*
Update of system version 7.1:
yum --enablerepo=remi-php71,remi-php71-test update php\*
Notice: version 7.1.10RC1 is also available in Fedora rawhide (for QA).
EL-7 packages are built using RHEL-7.4.
RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
Software Collections (php70, php71)
Base packages (php)
dvratil)
on September 14, 2017 03:29 PM
The main goal for me and Volker for this year Randa Meeting was to port KCalCore, our calendaring library, away from KDateTime. KDateTime/KTimeZone are classes for handling date, time and time zones which were used back in the KDE4 (and earlier) days when Qt’s QDateTime wasn’t good enough for us, mainly due to missing time zone support.
In Qt5 QDateTime finally gained all the necessary features we need which made it possible for us to leave KDateTime behind. But we couldn’t just go and replace “K” with “Q” everywhere – there are many subtle (and not-so-subtle) differences in API, behavior and some missing features of QDateTime that required us to carefully consider each step. The fact that we started working on this over 2 years ago shows how challenging task this was.
We did not expect to finish the port here, but once we dived into it, things went fairly well and I’m glad to say that after four days of intensive hacking, surrounded by Swiss Alps and mountains of chocolate, we succeeded. KCalCore is now free of KDateTime and KTimeZone and that in turn made (after some minor adjustments) the rest of KDE PIM free of KDELibs4Support. That’s a huge milestone for us.
Many thanks to John Layt for laying the initial ground for the porting and to Mario and Christian for the steady stream of chocolate and sweets to soothe our nerves :-)
If you want to help us to continue improving Kontact and other parts of KDE, please donate to the Randa fundraiser so that we can continue organizing similar productive sprints in the future. Thank you!
admin)
on September 14, 2017 12:37 PM
DNF Automatic is an optional Fedora component you can configure for automatic updates of packages. DNF Automatic is provided by the (aptly named) dnf-automatic package. This package has been available in previous releases of Fedora as well as in Fedora 26. As with all releases, though, Fedora 26 introduced numerous updates. These updates included DNF version 2, in which DNF Automatic configuration changed in an undocumented way.
As a result of the change, if you previously configured DNF Automatic and then upgraded to Fedora 26, your system may not be getting automatic updates. However, there’s now a DNF package that restores the previous configuration interface. But of course, you’ll need to install that update manually. After that, automatic updates will resume on your system.
If you don’t want to wait for a stable update through normal channels, you can use packages intended for advance testing. To update, temporarily enable the updates-testing repository with sudo and dnf:
sudo dnf --enablerepo=updates-testing update dnf\*
To restore automatic updates using a stable update (available later this week), do one of the following:
After you complete either of the above, run the following command:
rpm -q dnf
You should receive this version (or higher):
dnf-2.6.3-11.fc26.noarch
Using DNF Automatic alone isn’t enough to keep your system fully updated. Remember, DNF Automatic doesn’t reload or restart services, or reboot systems. These are often critical steps in applying security updates. Don’t forget to take these steps with the systems you care about.
Photo by mrigendra chauhan on Unsplash.d
A year and a half ago, frighteningly close to 1st April, Red Hat announced the availability of a gratis, self-supported, developer-only subscription for Red Hat Enterprise Linux and a series of other products. Simply put, if you went to developers.redhat.com, created an account and clicked a few buttons, you could download a RHEL ISO without paying anything to anybody. For the past few months, I have been investigating whether we can leverage this to do something exciting in Fedora Workstation. Particularly for those who might be building applications on Fedora that would eventually be deployed on RHEL.
While trying to figure out how the developers.redhat.com website and its associated infrastructure works, I discovered that its source code is actually available on GitHub. Sadly, my ineptitude with server-side applications and things like JBoss, Ruby, etc. meant that it wasn’t enough for me to write code that could interface with it. Luckily, the developers were kind enough to answer my questions, and now I know enough to write a C program that can download a free RHEL ISO.
The code is here: download-rhel.c.
I’ll leave it here in the hope that some unknown Internet traveller might find it useful. As for Fedora Workstation, I’ll let you know if we manage to come up with something concrete.
czanik)
on September 14, 2017 08:46 AM
You do not have to live without your favorite syslog implementation even in Amazon Web Services (AWS) Linux AMI. This Linux distribution is based on Red Hat Enterprise Linux version 6 and it is minimal extra work to install syslog-ng on it.
There are many different Linux distributions available on AWS, many of these include syslog-ng in an easy to install way as part of the distribution. The one I am writing about is the Amazon Linux AMI, the custom Linux distribution maintained by Amazon:
If your company policy suggests to use EPEL instead of the latest version, read my blog about the new core features of syslog-ng, which include advanced message parsing and disk based buffering to think again.
Enter the commands below to install syslog-ng 3.9 on AWS Linux AMI:
Installing applications from the command line is OK when you have a single machine. Using a private or public cloud automation is a must, if you do not want to waste a lot of time (and money). You can easily automate the above steps by adding it as a shell script while launching a new machine in AWS.
#!/bin/bash yum-config-manager --enable epel yum-config-manager --add-repo=https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng39epel6/repo/epel-6/czanik-syslog-ng39epel6-epel-6.repo rpm -e --nodeps rsyslog yum install -y syslog-ng chkconfig syslog-ng on /etc/init.d/syslog-ng start
If you use the web console to launch a new instance, you can paste the above script in step #3 (“configure instance”) in the text box under “Advanced Details”.
Of course it is even more elegant, if you turn the above commands into a cloud init script. I leave that exercise up to the reader.
By now syslog-ng is installed on your system with the default configuration. Before tailoring it to your environment make sure that everything works as expected.
You can check that syslog-ng is up and running using the /etc/init.d/syslog-ng status command, which prints the process ID of the syslog-ng application on screen.
You can check (very) basic functionality using the logger command. Enter:
logger this is a test message
And check if it is written to /var/log/messages using the tail command:
tail /var/log/messages
Unless your system is already busy serving users you should see a similar message as one of your last lines:
Sep 11 13:09:39 ip-172-x-y-z ec2-user[3395]: this is a test message
Here I list a few resources worth reading if you want to learn more about syslog-ng and AWS or if you get stuck along the way:
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or you can even chat with us. For a long list of possibilities, check our contact page at https://syslog-ng.org/contact-us/. On Twitter, I am available as @PCzanik.
The post Installing syslog-ng on AWS Linux AMI appeared first on Balabit Blog.
admin)
on September 14, 2017 08:28 AM
You attended the Fedora Women Day 2017.
jwrdegoede)
on September 14, 2017 07:23 AM
You're a proud member of the Community Operations (CommOps) team, helping tie Fedora together!
kushal)
on September 13, 2017 04:25 PM
In this post, I am going to talk about the isolation of network for different domains using VPN on Qubes. The following shows the default network configuration in Qubes.
The network hardware is attached to a special domain called sys-net. This is the only domain which directly talks to the outside network. Then a domain named sys-firewall connects to sys-net and all other VMs use sys-firewall to access the outside network. These kinds of special domains are also known as NetVM as they can provide network access to other VMs.
The easiest way is to clone the existing sys-net domain to a new domain. In my case, I have created two different domains, mynetwork and vpn2 as new NetVMs in dom0.
$ qvm-clone sys-net mynetwork
$ qvm-clone sys-net vpn2
As the next step, I have opened the settings for these VMs and marked sys-net as the NetVM for these. I have also install openvpn package in the templateVM so that both the new NetVM can find that package.
I am not running openvpn as proper service as I want to switch to different VPN services I have access to. That also means a bit of manual work to setup the right /etc/resolv.conf file in the NetVMs and any corresponding VMs which access the network through these.
$ sudo /usr/sbin/openvpn --config connection_service_name.ovpn
So, the final network right now looks like the following diagram. The domains (where I am doing actual work) are connected into different VPN services.
The Fedora Respins SIG is pleased to announce the latest release of Updated 26 Live ISOs, carrying the 4.12.11-300 kernel and 7 patched CVEs (https://bodhi.fedoraproject.org/upda…/FEDORA-2017-6764d16965). These can be found at https://dl.fedoraproject.org/pub/alt/live-respins/ (short link: http://tinyurl.com/live-respins), seeders are welcome and encouraged, however addition of additional trackers is strictly prohibited. These isos save about 800M of updates on new installs. We would also like to thank the following irc nicks for helping test these isos: ImBatman,brain83,dowdle,linuxmodder, Southern_Gentlem
ttomecek)
on September 13, 2017 02:27 PM
We were sitting at “Modularity UX feedback” session at Flock 2017. Sinny Kumari raised an interesting question: “Can I create a container image with modular OS locally myself?“. Sinny wanted to try the modular OS on different CPU architectures.
The container image can be created using Image Factory, which can be really tough to set up.
I’m so glad that platform team already solved this problem during development of Boltron in their GitHub repo fedora-modularity/baseruntime-docker-tests.
They created a neat way of creating a docker base image from scratch using mock.
In order to do this, you should follow the instructions from
README
of the repo. Before running avocado run setup.py, we need to change configuration
of mock because by default it uses Boltron (F26) repos and targets x86_64.
I did this on my Raspberry Pi. The configuration is present in resources/base-runtime-mock.cfg:
I targeted arm CPU architecture:
-config_opts['target_arch'] = 'x86_64'
-config_opts['legal_host_arches'] = ('x86_64',)
+config_opts['target_arch'] = 'armhfp'
+config_opts['legal_host_arches'] = ('armhfp', 'armv7l' )
I used Modular Rawhide compose repo:
-baseurl=https://kojipkgs.fedoraproject.org/compose/latest-Fedora-Modular-26/compose/Server/x86_64/os/
+baseurl=https://kojipkgs.fedoraproject.org/compose/latest-Fedora-Modular-Rawhide/compose/Server/armhfp/os/
Modular dnf is still not available in mainline. Martin is providing the RPM via
his COPR repo
mhatina/DNF-Modules.
The important note is that the modular DNF is only available for architectures
x86_64, i386 and ppc64le.
Let’s build the image!
$ sudo python2 ./setup.py
...
Successfully built dac3c6598bef
command 'docker rmi base-runtime-smoke-scratch' succeeded with output:
Untagged: base-runtime-smoke-scratch:latest
PASS 1-./setup.py:BaseRuntimeSetupDocker.testCreateDockerImage
Test results available in /tmp/avocado_avocado.core.jobwv6R1t
Once the build is done, we can try it out:
$ sudo docker run --rm -ti base-runtime-smoke-scratch:latest bash
bash-4.4# cat /etc/system-release
Fedora modular release 27 (Twenty Seven)
bash-4.4# uname -i
armv7l
Once the patches for modular DNF are in mainline, this will be a lot more interesting!
delouw)
on September 13, 2017 01:29 PM
Yesterday 2017-09-13 Redhat released infomation about the mitigation of the Blueborne vulnerability in RHEL: https://access.redhat.com/security/vulnerabilities/blueborne. For Fedora the new updates are probably still in the build queue and/or being QAed by the community. For a quick fix, you can disable … Continue reading
The post Blueborne – How to disable Bluetooth in Fedora appeared first on Luc de Louw's Blog.
Between 29 August and 1 September I attended, with other folks from Brno, the FLOCK conference, which took place in Cape Cod, Massachusetts. Flock 2017 is over, but a lot of talks will stay in our memories. The talks were exciting, fantastic, and simply awesome. Also, it was my first visit to the USA.
I attended several talks and I would like to mention some of them. Especially, I would like to write about the following talks and workshops: “Factory 2.0, future and Fedora”, “Fedora Legal”, “Gating on automated tests in Fedora - Greenwave”, and “Let’s create a test for modules/containers”.
Let me briefly introduce what the talks were about.
Flock 2017 - Keynote
The Flock began with a keynote presented by Matthew Miller. His presentation provided a brief summary across all Fedora versions. Matt showed several graphs about active community folks and the feedback, which was gathered from Fedora 25 and 26 releases. He highlighted Fedora Atomic CI and Modularity as one of the two current objectives for Fedora. After Matt’s presentation, the presenters had a two-minute introduction to their talks. This was useful to get a picture of presenters and helped me to plan attending talks and workshops that I wanted to focus on.
Factory 2.0, future and Fedora talk
Factory 2.0 team delivers several tools that automate things in the Fedora world. The tools provide a way to automate the distribution of modules, and they are used for testing, building, and updating.
Let’s have a brief look at them.
Waiver DB
WaiverDB is used together with ResultDB to record waivers against test results.
The service runs tests and the maintainer can waive it so that it does not block the other tests. The service is used together with Greenwave.
Greenwave is a service used to decide whether a software artifact can pass certain gating points in software delivery workflow. The policy defined by Greenwave defines which tests must pass in order to move to a new state.
Bodhi is a system that triggers and stores builds. The Factory 2.0 team enhanced Bodhi in order to display results from Greenwave and they also added the support for module updates, which are a part of modularity
ODCS is an abbreviation of “On Demand Compose Service”. This service can be used by other services and it updates docker images with the latest updates.
Factory 2.0 announced the support for chain rebuilds, which are important from the modularity point of view. The service responsible for chain rebuilds is called freshmaker.
Freshmaker, which waits for new fedmsg messages, is a new tool handled by Factory 2.0 team. Freshmaker is used mainly by module-build-service (MBS), which looks after modules delivered by the modularity team or Fedora module maintainers.
Fedora Legal - talk
Tom Callaway talked about legal aspects. The talk was fantastic, insightful, and full of information about software licensing. One of the important slides brought information about software patents that will expire soon, and thus the software can be used for Open Source. Tom also talked about why software should be safe and stressed that Fedora needs to remain free, which is awesome.
Gating on automated tests in Fedora - Greenwave - talk
Greenwave is a service for deciding whether the software with artifacts can pass some import points in the software delivery pipeline.
The results generated by Greenwave are stored in WaiverDB.
The checks that can be enforced in the pipeline are:
* dist.abicheck - it checks for ABI/API compatibilities
* dist.rpmdeplint - it checks for errors in RPM packages in the context of their dependency graph
* dist.updradepath - it checks whether the upgrade path was broken or not.
How to add tests to your packages - workshop
* https://fedoraproject.org/wiki/CI/Tests
* https://fedoraproject.org/wiki/Changes/InvokingTests#Terminology
The workshop tried to test several packages by Ansible. I tried to do it with MTF
and it worked as expected, but the artifacts were missing.
Let’s create a test for your module/container
This was a workshop presented by Jan Scotka and me. In 20 minutes we presented a brief overview of what MTF does, how it works, and some basic tests. Later on, the attendees had a chance to write tests for their containers. Some of them managed to make it. During the workshop we received a positive feedback about use cases for MTF, and of course what our plans in the future are, like testing containers in OpenShift. Good point, raised by Jan Kaluza, was to include some examples how to use MTF for several test multiple-host scenarios into our documentation.
What to tell at the end. Flock 2017 was great event, which I have ever visited. There were several talks and several session during 3 days, which was fine, and after getting back to home, I slept around 15 hours.
And Flock 2017 is over, but Flock 2018 will be there soon…...
