Fedora Magazine: Firefox 57 coming soon: a Quantum leap

Share Button

A few packages in Fedora get major updates outside the regular release cycle. The kernel is one of these, and Firefox is another. The maintainers do their best to handle these situations. Of course they always try to avoid any breaking changes to the user experience. However, there are times an upstream provides a path that makes this unavoidable. One of those rare situations is happening at present.

Upstream work on Firefox 57

Over the past year, Mozilla has been working on a series of major changes to the Firefox browser, mainly for performance and security. These changes are referred to as Project Quantum. Some improvements arrived already with no major differences for its users.

Last month the major changes landed in the developer channel. These changes mark a major deadline for how extensions work. This deadline gave third party developers a chance to look at their extensions and make changes to remain compatible. It was an important milestone date for the various Firefox add-ons. Firefox 57 marks an end to the legacy XUL based extensions. Starting with version 57, Firefox supports only a new type of extension, named WebExtension.

This shouldn’t be a surprise to Firefox extension developers, though. The compatibility roadmap has been known for the past year. Those who maintain their own extensions should read through the general upstream documentation on the change and the specific porting guide, as well.

User visible changes

Of course, developers following the Mozilla blogs have been aware of this change for a while. But the question remains: what does this mean for users?

The WebExtensions API is a cross-platform initiative. Therefore, this change means more extensions shared between Chrome, Opera and Firefox and the larger community. That should lead to better quality extensions overall. For the past several months, extension developers have been porting and giving feedback to Mozilla with APIs they require. Over 5000 extensions from addons.mozilla.org have been converted to remain compatible with version 57 and onward.

Users probably shouldn’t “hold back at FF56 as my favorite extensions don’t work.” Recall that security fixes only come from new versions, and they’ll all be WebExtension only. The Extended Support Release version will also switch to WebExtensions only at the next release. This date, June 2018, marks the deadline for ESR users to migrate their extensions.

Check which extensions you use that aren’t supported, and investigate if there’s a replacement or a beta test build by the developer. An upstream effort tracks whether many popular extensions have been ported yet, and related Mozilla bugs.

In addition to the extension changes, there are UI changes (codename Photon) as well as HTML, CSS and JavaScript rendering additions and fixes. Although the present beta release notes are brief, they link to further articles on the changes. Users and system administrators should read them to be prepared.

How Fedora is handling Firefox 57

Firefox 57 release is scheduled for November 14; Fedora 27 releases a week or so before that. The current Fedora 27 beta has the Firefox 57 beta. Fedora intends to have the Firefox 57 final release in a Fedora 27 update. This will be a significant part of the Fedora 27 Workstation release. If you use extensions, you’ll want to be aware of this plan.

Once Mozilla releases version 57, it will be submitted to the Fedora 26 updates-testing repository for an extended period. This provides adequate time for users to check their extensions before the update is promoted. However, this update will come to the stable repos for Fedora 26.

Between now and that point, a COPR provides builds for early testing of the builds, updated with any changes from the Fedora 27 release. Note that you cannot return to the older release on the same profile, due to changes in the update. Bear that in mind before installing this early release. You may want to make a backup of the existing profile before you update. This COPR will be removed when Firefox 57 reaches the Fedora 26 updates-testing repository.

To test these early package builds and provide early feedback of any issues, follow the usual COPR instructions to enable the repository and install the software:

dnf copr enable jhogarth/firefox57
dnf update firefox

When version 57 reaches the testing repository of Fedora 26 and the COPR is no longer required, remove it. This gets you the official Firefox maintainer’s builds and a clean future upgrade to Fedora 27:

dnf clean all
dnf copr remove jhogarth/firefox57

Providing feedback on the upcoming packages

Is the thought of testing the upcoming Firefox tempting? Then please follow these guidelines so maintainers can more easily handle your reported issues.

  • The Fedora 25 builds are entirely unsupported and provided only as a convenience for testing. Only Fedora 26 will receive the Firefox 57 update in the official Fedora repositories.
  • The COPR is provided by the author, a Fedora Packager, not the Mozilla maintenance team, though it is a coordinated effort. The author will try to get updates into place as soon as possible after updates in Fedora 27. These RPMs are not identical to those that will appear in Fedora, although built from the same spec files and sources as in Fedora’s git repositories.
  • Please only report Firefox issues and not any extension issues to Bugzilla. If in doubt, please try to reproduce the issue with extensions disabled.
  • Please use Bugzilla. Do not mail anyone directly.

To report any issues with Firefox 57 on Fedora, use the standard bugzilla report, and please note in the report that you’re using these packages.

Powered by WPeMatico

Share Button

Firefox 57 coming soon: a Quantum leap

Share Button

A few packages in Fedora get major updates outside the regular release cycle. The kernel is one of these, and Firefox is another. The maintainers do their best to handle these situations. Of course they always try to avoid any breaking changes to the user experience. However, there are times an upstream provides a path that makes this unavoidable. One of those rare situations is happening at present.

Upstream work on Firefox 57

Over the past year, Mozilla has been working on a series of major changes to the Firefox browser, mainly for performance and security. These changes are referred to as Project Quantum. Some improvements arrived already with no major differences for its users.

Last month the major changes landed in the developer channel. These changes mark a major deadline for how extensions work. This deadline gave third party developers a chance to look at their extensions and make changes to remain compatible. It was an important milestone date for the various Firefox add-ons. Firefox 57 marks an end to the legacy XUL based extensions. Starting with version 57, Firefox supports only a new type of extension, named WebExtension.

This shouldn’t be a surprise to Firefox extension developers, though. The compatibility roadmap has been known for the past year. Those who maintain their own extensions should read through the general upstream documentation on the change and the specific porting guide, as well.

User visible changes

Of course, developers following the Mozilla blogs have been aware of this change for a while. But the question remains: what does this mean for users?

The WebExtensions API is a cross-platform initiative. Therefore, this change means more extensions shared between Chrome, Opera and Firefox and the larger community. That should lead to better quality extensions overall. For the past several months, extension developers have been porting and giving feedback to Mozilla with APIs they require. Over 5000 extensions from addons.mozilla.org have been converted to remain compatible with version 57 and onward.

Users probably shouldn’t “hold back at FF56 as my favorite extensions don’t work.” Recall that security fixes only come from new versions, and they’ll all be WebExtension only. The Extended Support Release version will also switch to WebExtensions only at the next release. This date, June 2018, marks the deadline for ESR users to migrate their extensions.

Check which extensions you use that aren’t supported, and investigate if there’s a replacement or a beta test build by the developer. An upstream effort tracks whether many popular extensions have been ported yet, and related Mozilla bugs.

In addition to the extension changes, there are UI changes (codename Photon) as well as HTML, CSS and JavaScript rendering additions and fixes. Although the present beta release notes are brief, they link to further articles on the changes. Users and system administrators should read them to be prepared.

How Fedora is handling Firefox 57

Firefox 57 release is scheduled for November 14; Fedora 27 releases a week or so before that. The current Fedora 27 beta has the Firefox 57 beta. Fedora intends to have the Firefox 57 final release in a Fedora 27 update. This will be a significant part of the Fedora 27 Workstation release. If you use extensions, you’ll want to be aware of this plan.

Once Mozilla releases version 57, it will be submitted to the Fedora 26 updates-testing repository for an extended period. This provides adequate time for users to check their extensions before the update is promoted. However, this update will come to the stable repos for Fedora 26.

Between now and that point, a COPR provides builds for early testing of the builds, updated with any changes from the Fedora 27 release. Note that you cannot return to the older release on the same profile, due to changes in the update. Bear that in mind before installing this early release. You may want to make a backup of the existing profile before you update. This COPR will be removed when Firefox 57 reaches the Fedora 26 updates-testing repository.

To test these early package builds and provide early feedback of any issues, follow the usual COPR instructions to enable the repository and install the software:

dnf copr enable jhogarth/firefox57
dnf update firefox

When version 57 reaches the testing repository of Fedora 26 and the COPR is no longer required, remove it. This gets you the official Firefox maintainer’s builds and a clean future upgrade to Fedora 27:

dnf clean all
dnf copr remove jhogarth/firefox57

Providing feedback on the upcoming packages

Is the thought of testing the upcoming Firefox tempting? Then please follow these guidelines so maintainers can more easily handle your reported issues.

  • The Fedora 25 builds are entirely unsupported and provided only as a convenience for testing. Only Fedora 26 will receive the Firefox 57 update in the official Fedora repositories.
  • The COPR is provided by the author, a Fedora Packager, not the Mozilla maintenance team, though it is a coordinated effort. The author will try to get updates into place as soon as possible after updates in Fedora 27. These RPMs are not identical to those that will appear in Fedora, although built from the same spec files and sources as in Fedora’s git repositories.
  • Please only report Firefox issues and not any extension issues to Bugzilla. If in doubt, please try to reproduce the issue with extensions disabled.
  • Please use Bugzilla. Do not mail anyone directly.

To report any issues with Firefox 57 on Fedora, use the standard bugzilla report, and please note in the report that you’re using these packages.

Powered by WPeMatico

Share Button

Wolnei Tomazelli Junior: Thursday 19 oct, was the second day of LatinoWare and temperature go low to 25ºC after a heavy storm…

Share Button


Thursday 19 oct, was the second day of LatinoWare and temperature go low to 25ºC after a heavy storm. Unfortunately was damaged part of event infrastructure, but happily after a hard work everything back to normal at 1 pm of today.
We have our first FudMeeting at room Venezuela, from 10am to 5pm, with many great talks about Ansible, oVirt, ARM, How start contribute, Packaging and Translation. In result of this day will be one more traducer and website contributor do Fedora Project.
Closest to our room, many children was playing with educational robotics and using Fedora Robotics to upload their code to their ARM board.
Closing the day, employers of ITAIPU offer us a nice pizza dinner and a amazing surprise of live show of rock band. The band play very well many Brazilian rock classics and made all people get up to dance and sing together.

http://latinoware.org/1o-fudmeeting/ #fedora #latinoware #linux

20/10/2017

Powered by WPeMatico

Share Button

Justin W. Flory: Resigning from Fedora Council for Fedora 27

Share Button

FAmSCo August 2017 elections: Thoughts on a global community

Since I became a Fedora contributor in August 2015, I’ve spent a lot of time in the community. One of the great things about a big community like Fedora is that there are several different things to try out. I’ve always tried to do the most help in Fedora with my contributions. I prefer to make long-term, in-depth contributions than short-term, “quick fix”-style work. However, like many others, Fedora is a project I contribute to in my free time. Over the last month, I’ve come to a difficult realization.

After deep consideration, I am resigning from the Fedora Council effective at the end of the Fedora 26 release cycle.

Why I’m stepping back

When I decided to run for Fedora Council in July, I had not yet moved back to Rochester, New York. From my past experiences, I didn’t predict an issue to fulfill my commitments to the Fedora community. However, since moving back to Rochester, it is difficult to fulfill my expectations, Council and otherwise, to Fedora.

I’m entering the last years of my degree and the rigor of my coursework demands more time and focus. Additionally, I’m working more hours this year than I have in the past, which takes away more time Fedora. Because student loans are too real.

If I expected these changes, I would not have run for the Council. However, from my short time on the Council, I understand the energy and dedication needed to represent the community effectively. During my campaign and term, this was my driving motivation – to do my best to represent an international community of thousands in the highest body of leadership in Fedora. Now, I do not feel I am meeting my standard of participation and engagement. Already, I’ve stepped back from the Fedora Magazine and Marketing teams to focus more time in other areas of Fedora. Now, it is right to do the same for the Council.

I will spend the most time in the CommOps and Diversity teams, since I believe that is where I can make the largest impact as a contributor.

Fedora 27 Council elections

I privately shared my resignation with the Fedora Council before writing this post. After discussing with other Council members, the plan is

  1. Elect a new, full-term Council member for Fedora 27 and 28
  2. Elect a new, half-term Council member for only Fedora 27

In past elections with half-term seats, the candidate with the most votes receives the full-term seat and the runner-up receives the half-term seat. I expect this to happen again, although final details will come once the election phase begins.

Thank you for your trust

This is one of the most difficult decisions I’ve made in Fedora. Serving on the Fedora Council is the greatest privilege. My election to the Council by hundreds of people was humbling and inspired me to not only lead by example, but represent the perspective of the greater Fedora community to the Council. This was the greatest honor for me and it disappoints me to finish my term early.

However, based on current circumstances, I believe this is the best path forward to make sure the community is well-represented in Fedora leadership. Thank you for your trust and I hope I can return to serve the community in this capacity someday in the future.

The post Resigning from Fedora Council for Fedora 27 appeared first on Justin W. Flory’s Blog.

Powered by WPeMatico

Share Button

Fernando Espinoza: Cómo configurar sus dispositivos para la protección de la privacidad.

Share Button

Las computadoras, los teléfonos inteligentes y los aparatos conectados a Internet han hecho nuestras vidas más fáciles hasta el punto en que estaríamos atrapados sin ellos. Por otro lado, cuanto más confiamos en ellos, más datos pasan a través de ellos y potencialmente fuera de nuestro control. Lamentablemente, estos dispositivos a menudo están mal protegidos por la… Seguir leyendo →

Powered by WPeMatico

Share Button

Christian F.K. Schaller: Looking back at Fedora Workstation so far

Share Button

So I have over the last few years blogged regularly about upcoming features in Fedora Workstation. Well I thought as we putting the finishing touches on Fedora Workstation 27 I should try to look back at everything we have achieved since Fedora Workstation was launched with Fedora 21. The efforts I highlight here are efforts where we have done significant or most development. There are of course a lot of other big changes that has happened over the last few years by the wider community that we leveraged and offer in Fedora Workstation, examples here include things like Meson and Rust. This post is not about those, but that said I do want to write a post just talking about the achievements of the wider community at some point, because they are very important and crucial too. And along the same line this post will not be speaking about the large number of improvements and bugfixes that we contributed to a long list of projects, like to GNOME itself. This blog is about taking stock and taking some pride in what we achieved so far and major hurdles we past on our way to improving the Linux desktop experience.
This blog is also slightly different from my normal format as I will not call out individual developers by name as I usually do, instead I will focus on this being a totality and thus just say ‘we’.

  • Wayland – We been the biggest contributor since we joined the effort and have taken the lead on putting in place all the pieces needed for actually using it on a desktop, including starting to ship it as our primary offering in Fedora Workstation 25. This includes putting a lot of effort into ensuring that XWayland works smoothly to ensure full legacy application support.
  • Libinput – A new library we created for handling all input under both X and Wayland. This came about due to needing input handling that was not tied to X due to Wayland, but it has even improved input handling for X itself. Libinput is being rapidly developed and improved, with 1.9 coming out just a few days ago.
  • glvnd – Dealing with multiple OpenGL implementations have been a pain under Linux for years. We worked with NVidia on this effort to ensure that you can install multiple OpenGL implementations on the system and have your system be able to use the correct one depending on which GPU and driver you are using. We keep expanding on this solution to cover more usecases, so for Fedora Workstation 27 we expect to bring glvnd support to XWayland for instance.
  • Porting Firefox to GTK3 – We ported Firefox to GTK3, including making sure it works under Wayland. This work also provided the foundation for HiDPI support in Firefox. We are the single biggest contributor to Firefox Linux support.
  • Porting LibreOffice to GTK3 – We ported LibreOffice to GTK3, which included Wayland support, touch support and HiDPI support. Our team is one of the major contributors to LibreOffice and help the project forward on a lot of fronts.
  • Google Drive integration – We extended the general Google integration in GNOME 3 to include support for Google Drive as we found that a lot of our users where relying on Google Apps at their work.
  • Flatpak – We created Flatpak to lead the way in moving desktop applications into their own namespaces and containers, resolving a lot of long term challenges for desktop applications on Linux. We expect to have new infrastructure in place in Fedora soon to allow Fedora packagers to quickly and easily turn their applications into Flatpaks.
  • Linux Firmware Service – We created the Linux Firmware service to provide a way for Linux users to get easy access to UEFI firmware on their linux system and worked with great vendors such as Dell and Logitech to get them to support it for their devices. Many bugs experienced by Linux users over the years could have been resolved by firmware updates, but with tooling being spotty many Linux users where not even aware that there was fixes available.
  • GNOME Software – We created GNOME Software to give us a proper Software Store on Fedora and extended it over time to include features such as fonts, GStreamer plugins, GNOME Shell extensions and UEFI firmware updates. Today it is the main Store type application used not just by us, but our work has been adopted by other major distributions too.
  • mp3, ac3 and aac support – We have spent a lot of time to be able to bring support for some of the major audio codecs to Fedora like MP3, AC3 and AAC. In the age of streaming supporting codecs is maybe of less importance than it used to be, but there is still a lot of media on peoples computers they need and want access to.
  • Fedora Media Creator – Cross platform media creator making it very easy to create Fedora Workstation install media regardless of if you are on Windows, Mac or Linux. As we move away from optical media offering ISO downloads started feeling more and more outdated, with the media creator we have given a uniform user experience to quickly create your USB install media, especially important for new users coming in from Windows and Mac environments.
  • Captive portal – We added support for captive portals in Network Manager and GNOME 3, ensuring easy access to the internet over public wifi networks. This feature has been with us for a few years now, but it is still a much appreciated addition.
  • HiDPI support – We worked to add support for HiDPI across X, Wayland, GTK3 and GNOME3. We lead the way on HiDPI support under Linux and keep working on various applications to this date to polish up the support.
  • Touch support – We worked to add support for touchscreens across X, Wayland, GTK3 and GNOME3. We spent significant resources enabling this, both on laptop touchscreens, but also to support modern wacom devices.
  • QGNOME Platform – We created the QGNOME Platform to ensure that Qt applications work well under GNOME3 and gives a nice native and integrated feel. So while we ship GNOME as our desktop offering we want Qt applications to work well and feel native. This is an ongoing effort, but for many important applications it already is a great improvement.
  • Nautilus improvements. Nautilus had been undermaintained for quite a while so we had Carlos Soriano spend significant time on reworking major parts of it and adding new features like renaming multiple files at ones, updating the views and in general bring it up to date.
  • Night light support in GNOME – We added support for automatic adjusting the color and light settings on your system based on light sensors found in modern laptops. This integrated functionality that you before had to install extra software like Red Shift to enable.
  • libratbag – We created a library that enable easy configuration of high end mice and other kind of input devices. This has led to increased collaboration with a lot of gaming mice manufacturers to ensure full support for their devices under Linux.
  • RADV – We created a full open source Vulkan implementation for ADM GPUs which recently got certified as Vulkan compliant. We wanted to give open source Vulkan a boost, so we created the RADV project, which now has an active community around it and is being tested with major games.
  • GNOME Shell performance improvements – We been working on various performance improvements to GNOME Shell over the last few years, with significant improvements having happened. We want to push the envelope on this further though and are planning a major performance hackfest around Shell performance and resource usage early next year.
  • GNOME terminal developer improvements – We worked to improve the features of GNOME Terminal to make it an even better tool for developers with items such as easier naming of terminals and notifications for long running jobs.
  • GNOME Builder – Improving the developer story is crucial for us and we been doing a lot of work to make GNOME Builder a great tool for developer to use to both improve the desktop itself, but also development in general.
  • Pipewire – We created a new media server to unify audio, pro-audio and video. First version which we are shipping in Fedora 27 to handle our video capture.
  • Fleet Commander – We launched Fleet Commander our new tool for managing large Linux desktop deployments. This answer a long standing call from many of Red Hats major desktop customers and many admins of large scale linux deployments at Universities and similar for a powerful yet easy to use administration tool for large desktop deployments.

I am sure I missed something, but this is at least a decent list of Fedora Workstation highlights for the last few years. Next onto working on my Fedora Workstation 27 blogpost :)

Powered by WPeMatico

Share Button

Laura Abbott: Splitting the Ion heaps

Share Button

One of the requests before Ion moves out of staging is to split the /dev
interface into multiple nodes. The way Ion allocation currently works is
by calling ioctls on /dev/ion. This certainly works but requires that Ion
have a fairly permissive set of privileges. There’s not an easy1 way to
restrict access to certain heaps. Splitting access out into /dev/ion0,
/dev/ion1 etc. makes it possible to set Unix and selinux permissions per
heap. Benjamin Gaignard has been working on some proposals
to make this work.

I decided to give this a boot and run a few tests. Everything came up okay in
my buildroot based environment but I didn’t see /dev/ion0, /dev/ion1 on
my Android system. Creation of the device nodes is the responsibility of
userspace so it wasn’t too surprising to see at least some problems. On
most systems, this is handled by some subset of udev,
which might be part of systemd or some other init subsystem. Android being
Android uses its own setup for device initialization.

My preferred Android board these days is a HiKey
development board. Linaro has done a fantastic job of getting support for this
board in AOSP so I can work off of AOSP master or one of the branches to do
development. By default, AOSP ships a binary kernel module based on whatever
branch they are shipping but John Stultz keeps a git tree
with a branch that tracks mainline pretty closely. With this setup, I can
recompile and test almost any part of the system I want (except for the Mali
blobs of course).

The Android init system provides an option to log
uevents. This was useful for seeing exactly what was going on. The logs showed
the init system probing some typical set of the /sys hierarchy. The Ion
nodes weren’t on that list though, so the Android init system wasn’t finding
it in /sys. This is what I found in /sys/devices/ on my qemu setup:

# ls /sys/devices/
LNXSYSTM:00  ion0         msr          platform     software     tracepoint
breakpoint   ion1         pci0000:00   pnp0         system       virtual

ion0 and ion1 are present in the /sys hierarchy but not where one might
have expected. This was a side-effect of how the underlying devices were set
up in the kernel. I’m not very familiar with the device model so I’m hoping
to see more feedback on a proper solution. Progress always takes time…


  1. You can do some filtering with seccomp but that’s not the focus here. 

Powered by WPeMatico

Share Button

Karel Zak: util-linux v2.31 — what's new?

Share Button

uuidparse — this is a new small command to get more information about UUIDs “hash”. The command provides info about UUID type, variant and time. For example:

$ (uuidgen; uuidgen -t) | uuidparse
UUID VARIANT TYPE TIME
8f251893-d33a-40f7-9bb3-36988ec77527 DCE random
66509634-b404-11e7-aa8e-7824af891670 DCE time-based 2017-10-18 15:01:04,751570+0200

The command su has been refactored and extended to create pseudo terminal for the session (new option –pty). The reason is CVE-2016-2779, but the issue addressed by this CVE is pretty old and all the problem is silently ignored for for years on many places (on only su(1)). The core of the problem is that unprivileged user (within su(1) session) shares terminal file descriptor with original root’s session. The new option –pty forces su(1) to create independent pseudo terminal for the session and than su(1) works as proxy between the terminals. The feature is experimental and not enabled by default (you have to use su –pty).

standard su session (all on pts/0):

               
24909 pts/0 S 0:02 _ -bash
13607 pts/0 S 0:00 _ su - kzak
13608 pts/0 S 0:00 _ -bash
13679 pts/0 R+ 0:00 _ ps af

su –pty session (root pts/0; user pts/5):

               
24909 pts/0 S 0:02 _ -bash
13857 pts/0 S+ 0:00 _ su --pty - kzak
13858 pts/5 Ss 0:00 _ -bash
13921 pts/5 R+ 0:00 _ ps af

rfkill — this is a new command in util-linux. The command was originally written by Johannes Berg and Marcel Holtmann and maintained for years as standalone package. We believe that it’s better to maintain and distribute it with another commands on one place. The util-linux version is backwardly compatible with the original implementations. The command has been also improved (libsmartcols ouotput, etc.), the new default output:
# rfkill       
ID TYPE DEVICE SOFT HARD
0 bluetooth tpacpi_bluetooth_sw unblocked unblocked
1 wlan phy0 unblocked unblocked
4 bluetooth hci0 blocked unblocked

The library libuuid and command uuidgen support hash-based UUIDs v3 (md5) and v5 (sha1) as specified by RFC-4122 now. The library also provides UUID templates for dns, url, oid, or x500. For example:
 
$ uuidgen --sha1 --namespace @dns --name foobar.com
e361e3ab-32c6-58c4-8f00-01bee1ad27ec

and it’s expected to use v3 and v5 UUIDs as hierarchy, so you can use this UUID (or arbitrary other UUID) as a namespace:

 
$ uuidgen --sha1 --namespace e361e3ab-32c6-58c4-8f00-01bee1ad27ec --name mystuff
513f905c-7df2-5afa-9470-4e82382dbf00

I can imagine system where for example per-user or per-architecture partition UUIDs are based on this system. For example use UUID specific for the system root as –namespace and username as –name, or so. 
wipefs and libblkid have been improved to provide all possible string permutations for a device. It means that wipefs does not return the first detected signature, but it continues and tries another offsets for the signature. This is important for filesystems and partitions tables where the superblock is backuped on multiple places (e.g. GPT) or detectable by multiple independent ways (FATs). This all is possible without a device modification (the old version provides the same, but only in “wipe” mode). 

The libfdisk has been extended to use BLKPG ioctls to inform the kernel about changes. This means that cfdisk and fdisk will not force your kernel to reread all of the partition table, but untouched partitions may remain mounted and used by the system. The typical use-case is resizing the last partition on the system disk. 

You can use cfdisk to resize a partition. Yep, cool.

The hwclock command now significantly reduces system shutdown times by not reading the RTC before setting it (except when the –update-drift option is used). This also mitigates other potential shutdown and RTC setting problems caused by requiring an RTC read.

Powered by WPeMatico

Share Button

Daniel Pocock: FOSDEM 2018 Real-Time Communications Call for Participation

Share Button

FOSDEM is one of the world’s premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2018 takes place 3-4 February 2018 in Brussels, Belgium.

This email contains information about:

  • Real-Time communications dev-room and lounge,
  • speaking opportunities,
  • volunteering in the dev-room and lounge,
  • related events around FOSDEM, including the XMPP summit,
  • social events (the legendary FOSDEM Beer Night and Saturday night dinners provide endless networking opportunities),
  • the Planet aggregation sites for RTC blogs

Call for participation – Real Time Communications (RTC)

The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge.

The dev-room is only on Sunday, 4 February 2018. The lounge will be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list.

To be kept aware of major developments in Free RTC, without being on the discussion list, please join the Free-RTC Announce list.

Speaking opportunities

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 30 November. Please use the Pentabarf system to submit a talk proposal for the dev-room. On the “General” tab, please look for the “Track” option and choose “Real Time Communications devroom”. Link to talk submission.

Other dev-rooms and lightning talks: some speakers may find their topic is in the scope of more than one dev-room. It is encouraged to apply to more than one dev-room and also consider proposing a lightning talk, but please be kind enough to tell us if you do this by filling out the notes in the form.

You can find the full list of dev-rooms on this page and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC 3 November. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track.

First-time speaking?

FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it.

Submission guidelines

The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one.

In the “Submission notes”, please tell us about:

  • the purpose of your talk
  • any other talk applications (dev-rooms, lightning talks, main track)
  • availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators based on the received proposals. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used.

Volunteers needed

To make the dev-room and lounge run successfully, we are looking for volunteers:

  • FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this
  • organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 4 February
  • participation in the Real-Time lounge
  • helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses
  • circulating this Call for Participation (text version) to other mailing lists

Related events – XMPP and RTC summits

The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on 2 February 2018. XMPP Summit web site – please join the mailing list for details.

Social events and dinners

The traditional FOSDEM beer night occurs on Friday, 2 February.

On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints and reservations are essential. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat.

Spread the word and discuss

If you know of any mailing lists where this CfP would be relevant, please forward this email (text version). If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your blog to the planet site administrators:

Planet site Admin contact
All projects Free-RTC Planet (http://planet.freertc.org) contact planet@freertc.org
XMPP Planet Jabber (http://planet.jabber.org) contact ralphm@ik.nu
SIP Planet SIP (http://planet.sip5060.net) contact planet@sip5060.net
SIP (Español) Planet SIP-es (http://planet.sip5060.net/es/) contact planet@sip5060.net

Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community.

Contact

For any private queries, contact us directly using the address fosdem-rtc-admin@freertc.org and for any other queries please ask on the Free-RTC mailing list.

The dev-room administration team:

Powered by WPeMatico

Share Button

Fedora Community Blog: Teaching metrics and contributor docs at Flock 2017

Share Button

The Fedora Community Operations (CommOps) team held an interactive workshop during the annual Fedora contributor conference, Flock. Flock took place from August 29th to September 1st in Cape Cod, Massachusetts. Justin W. Flory and Sachin Kamath represented the team in the workshop. CommOps spends a lot of time working with metrics and data tools available in Fedora, like fedmsg and datagrepper. Our workshop introduced some of the tools to work with metrics in Fedora and how to use them. With our leftover time, we discussed the role of contributor-focused documentation in the wiki and moving it to a more static place in Fedora documentation.

What does CommOps do?

The beginning of the session introduced the CommOps team and explained our function in the Fedora community. There’s two different skill areas in the CommOps team: one focuses on data analysis and the other focuses on non-technical community work. The motivation for CommOps was explained too. The team’s mission is to bring more heat and light into the project, where light is exposure and awareness, and heat is more activity and contributions. Our work usually follows this mission for either technical or non-technical tasks.

At the beginning of the workshop, metrics were the main discussion point. CommOps helps generate metrics and statistical reports about activity in Fedora. We wanted to talk more about the technical tools we use and how others in the workshop could use them for their own projects in Fedora.

What are Fedora metrics?

fedmsg is the foundation for all metrics in Fedora. fedmsg is a message bus that connects the different applications in Fedora together. All applications and tools used by Fedora contributors emit messages into fedmsg. This includes git commits, Koji build status, Ansible playbook runs, adding a member to a FAS group, new translations, and more. Together, the data is meaningless and is difficult to understand. In the #fedora-fedmsg channel on Freenode, you can see all the fedmsg activities in the project (you can see the project “living”!). The valuable part is when you take the data and filter it down into something meaningful.

One of the examples from the workshop was the analysis of FOSDEM and community engagement by CommOps contributor Bee Padalkar. In her report, she determined our approximate impact in the community at FOSDEM. Using Fedora Badges, it revealed how many people we interacted with at FOSDEM and how they engaged with the Fedora community before and after the conference.

The metrics tools in Fedora help make this research possible. One of the primary goals of our workshop was to introduce the metrics tools and how to use them for the audience. We hoped to empower people to build and generate metrics of their own. We also talked about some of the plans by the team to advance use of metrics further.

Introducing the CommOps toolbox

The CommOps toolbox is a valuable resource for the data side of CommOps. Our virtual toolbox is a list of all the metrics and data tools available for use and a short description of how they’re used. You can see the toolbox on the wiki.

Sachin led this part of the workshop and explained some of the most common tools. He introduced what a fedmsg publication looked like and helped explain the structure of the data. Next, he introduced Datagrepper. Datagrepper helps you pull fedmsg data based on a set of filters. With your own filters, you can customize the data you see to make comparisons easier. Complex queries with Datagrepper are powerful and help bring insights into various parts of the project. When used effectively, it provides insight into potential weak spots in a Fedora-related project.

Finally, Sachin also introduced his Google Summer of Code (GSoC) 2016 project, gsoc-stats. gsoc-stats is a special set of pre-defined filters to create contribution profiles for individual contributors. It breaks down where a contributor spends most of their time in the project and what type of work they do. Part of its use was for GSoC student activity measurements, but it has other uses as well.

What is Grimoire Lab?

Sachin is leading progress on a new tool for CommOps called Grimoire Lab. Grimoire Labs is a visual dashboard tool that lets a user create charts, graphs, and visual measurements from a common data source. The vision for Grimoire Lab in Fedora is to build an interactive dashboard based off of fedmsg data. Using the data, anyone could create different gauges and measurements in an easy-to-understand chart or graph. This helps make the fedmsg data more accessible for others in the project to use, without making them write their own code to create graphic measurements.

Most of the time for Grimoire Lab in the workshop was explaining its purpose and expected use. Sachin explained some of the progress made so far to make the tool available in Fedora. This goal is to get it hosted inside of Fedora’s infrastructure next. We hope to deliver on an early preview of this over the next year.

Changing the way we write contributor documentation

The end of our workshop focused on non-technical tasks. We had a few tickets highlighted but left it open to the audience interest to direct the discussion. One of the attendees, Brian Exelbierd, started a discussion about the Fedora Documentation team and some of the changes they’ve made over the last year. Brian introduced AsciiDoc and broke down the workflow that the Docs team uses with the new tooling. After explaining it, the idea came up of hosting contributor-focused information in a Fedora Docs-style project, instead of the wiki.

The two strong benefits of this approach is to keep valuable information updated and to make it easily accessible. Some common wiki pages for the CommOps team came up, like the pages explaining how to join the team and how to get “bootstrapped” in Fedora. After Brian’s explanation of the tools, the new Docs tool chain felt easy to keep up and effective promoting high-value content for contributors out of the wiki. Later during Flock, on Thursday evening, Brian organized a mini workshop to extend this idea further and teach attendees how to port content over.

CommOps hopes to be an early example of a team to use this style of documentation for our contributor-focused content. Once we are comfortable with the set-up and have something to show to others, we want to document how we did and explain how other teams can do it too. We hope to carry this out over the Fedora 27 release cycle.

See you next year!

Flock 2017 was a conference full of energy and excitement. The three-hour workshop was useful and effective for CommOps team members to meet and work out plans for the next few release cycles in the same room. In addition to our own workshop, spending time in other workshops was also valuable for our team members to see what others in Fedora are doing and where they need help.

A special thanks goes out to all the organizing staff, for both the bid process and during the conference. Your hard work helps drive our community forward every year by feeling more like a community of people, in an open source world where we mostly interact and work together over text messaging clients and emails.

We hope to see you next year to show you what we accomplished since last Flock!

The post Teaching metrics and contributor docs at Flock 2017 appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button