Fedora Community Blog: News from Fedora Infrastructure

Share Button

IndiaHacks 2016

Most of the Community Platform Engineering (CPE) team met in person last month in Brno during a week. CPE team is the team at Red Hat that works on Fedora and CentOS infrastructure. As a distributed team, we usually use DevConf.cz as an opportunity to meet face to face.

This is an update on what we have been up to during this week.

Continuous Integration

One of the first tasks we have achieved is to move as many application we maintain to use CentOS CI for our Continuous Integration pipeline. CentOS CI provides us with a Jenkins instance that is running in an OpenShift cluster, you can have a look at the this instance here.

Since a good majority of our application are developed in Python, we agreed on using tox to execute our CI tests. Adopting tox on our application allows us  to use a really convenient way to configure the CI pipeline in Jenkins. In fact we only needed to create .cico.pipeline file in the application repository with the following.

fedoraInfraTox { }

At the end of the day out of the 27 application which we are directly involved in we have migrated 22 to CentOS CI and tox.

OpenShift

A second task we have focused on was to migrate some of our application to OpenShift. After identifying which applications were good candidate we worked on deploying the following :

Currently these are running on OpenShift in the staging environment.

This was a good opportunity to get the team up to speed with deploying application on OpenShift and using the source-to-image tool. You can have a look at the Ansible playbooks we are using here.

Migration to fedora-messaging

While working on moving application to OpenShift we worked on the migration from fedmsg to fedora-messaging. First we replaced the fedmsg producer by fedora-messaging since it is quite trivial. You can see an example in this Pull-Request.

Planning and prioritization

The rest of the week was spent on planning and prioritizing work for this year. Generally we are looking to increase our transparency and make it easier for us and other teams to see which tasks are currently in progress. Some progress on this effort should happen soon once we have a supported Taiga instance available in Fedora.

If you are interested in helping out with any of these efforts, you can join #fedora-apps channel on the freenode IRC network, or send an email to the infrastructre mailing list

The post News from Fedora Infrastructure appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

Peter Hutterer: Adding entries to the udev hwdb

Share Button

In this blog post, I’ll explain how to update systemd’s hwdb for a new device-specific entry. I’ll focus on input devices, as usual.

What is the hwdb and why do I need to update it?

The hwdb is a binary database sitting at /etc/udev/hwdb.bin and /usr/lib/udev/hwdb.d. It is usually used to apply udev properties to specific devices, those properties are then picked up by other processes (udev builtins, libinput, …) to apply device-specific behaviours. So you’ll need to update the hwdb if you need a specific behaviour from the device.

One of the use-cases I commonly deal with is that some touchpad announces wrong axis ranges or resolutions. With the correct hwdb entry (see the example later) udev can correct these at device initialisation time and every process sees the right axis ranges.

The database is compiled from the various .hwdb files you have sitting on your system, usually in /etc/udev/hwdb.d and /usr/lib/hwdb.d. The terser format of the hwdb files makes them easier to update than, say, writing a udev rule to set those properties.

The full process goes something like this:

  • The various .hwdb files are installed or modified
  • The hwdb.bin file is generated from the .hwdb files
  • A udev rule triggers the udev hwdb builtin. If a match occurs, the builtin prints the to-be properties, and udev captures the output and applies it as udev properties to the device
  • Some other process (often a different udev builtin) reads the udev property value and does something.

On its own, the hwdb is merely a lookup tool though, it does not modify devices. Think of it as a virtual filing cabinet, something will need to look at it, otherwise it’s just dead weight.

An example for such a udev rule from 60-evdev.rules contains:


IMPORT{builtin}="hwdb --subsystem=input --lookup-prefix=evdev:",
RUN{builtin}+="keyboard", GOTO="evdev_end"

The IMPORT statement translates as “look up the hwdb, import the properties”. The RUN statement runs the “keyboard” builtin which may change the device based on the various udev properties now set. The GOTO statement goes to skip the rest of the file.

So again, on its own the hwdb doesn’t do anything, it merely prints to-be udev properties to stdout, udev captures those and applies them to the device. And then those properties need to be processed by some other process to actually apply changes.

hwdb file format

The basic format of each hwdb file contains two types of entries, match lines and property assignments (indented by one space). The match line defines which device it is applied to.

For example, take this entry from 60-evdev.hwdb:


# Lenovo X230 series
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*ThinkPad*X230*
EVDEV_ABS_01=::100
EVDEV_ABS_36=::100

The match line is the one starting with “evdev”, the other two lines are property assignments. Property values are strings, any interpretation to numeric values or others is to be done in the process that requires those properties. Noteworthy here: the hwdb can overwrite previously set properties, but it cannot unset them.

The match line is not specified by the hwdb beyond “it’s a glob”. The format to use is defined by the udev rule that invokes the hwdb builtin. Usually the format is:


someprefix:search criteria:

For example, the udev rule that applies for the match above is this one in 60-evdev.rules:


KERNELS=="input*",
IMPORT{builtin}="hwdb 'evdev:name:$attr{name}:$attr{[dmi/id]modalias}'",
RUN{builtin}+="keyboard", GOTO="evdev_end"

What does this rule do? $attr entries get filled in by udev with the sysfs attributes. So on your local device, the actual lookup key will end up looking roughly like this:


evdev:name:Some Device Name:dmi:bvnWhatever:bvR112355:bd02/01/2018:...

If that string matches the glob from the hwdb, you have a match.

Attentive readers will have noticed that the two entries from 60-evdev.rules I posted here differ. You can have multiple match formats in the same hwdb file. The hwdb doesn’t care, it’s just a matching system.

We keep the hwdb files matching the udev rules names for ease of maintenance so 60-evdev.rules keeps the hwdb files in 60-evdev.hwdb and so on. But this is just for us puny humans, the hwdb will parse all files it finds into one database. If you have a hwdb entry in my-local-overrides.hwdb it will be matched. The file-specific prefixes are just there to not accidentally match against an unrelated entry.

Applying hwdb updates

The hwdb is a compiled format, so the first thing to do after any changes is to run


$ systemd-hwdb update

This command compiles the files down to the binary hwdb that is actually used by udev. Without that update, none of your changes will take effect.

The second thing is: you need to trigger the udev rules for the device you want to modify. Either you do this by physically unplugging and re-plugging the device or by running


$ udevadm trigger

or, better, trigger only the device you care about to avoid accidental side-effects:


$ udevadm trigger /sys/class/input/eventXYZ

In case you also modified the udev rules you should re-load those too. So the full quartet of commands after a hwdb update is:


$ systemd-hwdb update
$ udevadm control --reload-rules
$ udevadm trigger
$ udevadm info /sys/class/input/eventXYZ

That udevadm info command lists all assigned properties, these should now include the modified entries.

Adding new entries

Now let’s get down to what you actually want to do, adding a new entry to the hwdb. And this is where it also get’s tricky to have a generic guide because every hwdb file has its own custom match rules.

The best approach is to open the .hwdb files and the matching .rules file and figure out what the match formats are and which one is best. For USB devices there’s usually a match format that uses the vendor and product ID. For built-in devices like touchpads and keyboards there’s usually a dmi-based match format (see /sys/class/dmi/id/modalias). In most cases, you can just take an existing entry and copy and modify it.

My recommendation is: add an extra property that makes it easy to verify the new entry is applied. For example do this:


# Lenovo X230 series
evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO*:pn*ThinkPad*X230*
EVDEV_ABS_01=::100
EVDEV_ABS_36=::100
FOO=1

Now run the update commands from above. If FOO=1 doesn’t show up, then you know it’s the hwdb entry that’s not yet correct. If FOO=1 does show up in the udevadm info output, then you know the hwdb matches correctly and any issues will be in the next layer.

Increase the value with every change so you can tell whether the most recent change is applied. And before your submit a pull request, remove the FOOentry.

Oh, and once it applies correctly, I recommend restarting the system to make sure everything is in order on a freshly booted system.

Troubleshooting

The reason for adding hwdb entries is always because we want the system to handle a device in a custom way. But it’s hard to figure out what’s wrong when something doesn’t work (though 90% of the time it’s a typo in the hwdb match).

In almost all cases, the debugging sequence is the following:

  • does the FOO property show up?
  • did you run systemd-hwdb update?
  • did you run udevadm trigger?
  • did you restart the process that requires the new udev property?
  • is that process new enough to have support for that property?

If the answer to all these is “yes” and it still doesn’t work, you may have found a bug. But 99% of the time, at least one of those is a sound “no. oops.”.

Your hwdb match may run into issues with some ‘special’ characters. If your device has e.g. an ® in its device name (some Microsoft devices have this), a bug in systemd caused the match to fail. That bug is fixed now but until it’s available in your distribution, replace with an asterisk (‘*’) in your match line.

Greybeards who have been around since before 2014 (systemd v219) may remember a different tool to update the hwdb: udevadm hwdb –update. This tool still exists, but it does not have the exact same behaviour as systemd-hwdb update. I won’t go into details but the hwdb generated by the udevadm tool can provide unexpected matches if you have multiple matches with globs for the same device. A more generic glob can take precedence over a specific glob and so on. It’s a rare and niche case and fixed since systemd v233 but the udevadm behaviour remained the same for backwards-compatibility.

Happy updating and don’t forget to add Database Administrator to your CV when your PR gets merged.

Powered by WPeMatico

Share Button

Miro Hrončok: Python 3.8 alpha in Fedora

Share Button

The Python developers have released the first alpha of Python 3.8.0 and you can already try it out in Fedora! Test your Python code with 3.8 early to avoid surprises once the final 3.8.0 is out in October.

Install Python 3.8 on Fedora

If you have Fedora 29 or newer, you can install Python 3.8 from the official software repository. Either with GNOME Software or with dnf:

$ sudo dnf install python38

As more alphas, betas and release candidates of Python 3.8 will be released, the Fedora package will receive updates. No need to compile your own development version of Python, just install it and have it up to date. New features will be added until the first beta.

Test your projects with Python 3.8

Run the python3.8 command to use Python 3.8 or create virtual environments with the builtin venv module, tox or with pipenv. For example:

$ git clone https://github.com/benjaminp/six.git
Cloning into 'six'...
$ cd six/
$ tox -e py38
py38 runtests: commands[0] | python -m pytest -rfsxX
================== test session starts ===================
platform linux -- Python 3.8.0a1, pytest-4.2.1, py-1.7.0, pluggy-0.8.1
collected 195 items

test_six.py ...................................... [ 19%]
.................................................. [ 45%]
.................................................. [ 70%]
..............................................s... [ 96%]
....... [100%]
========= 194 passed, 1 skipped in 0.25 seconds ==========
________________________ summary _________________________
py38: commands succeeded
congratulations 🙂

What’s new in Python 3.8

So far, only the first alpha was released, so more features will come. You can however already try out the new walrus operator:

$ python3.8
Python 3.8.0a1 (default, Feb 7 2019, 08:07:33)
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> while not (answer := input('Say something: ')):
... print("I don't like empty answers, try again...")
...
Say something:
I don't like empty answers, try again...
Say something: Fedora
>>>

And stay tuned for Python 3.8 as python3 in Fedora 31!

Powered by WPeMatico

Share Button

alciregi: Using systemd timer instead of cron

Share Button

Cron is not part of Fedora Silverblue (as well as Atomic Host).
You can install (overlay) it with rpm-ostree. But it is better to avoid as much as possible to overlay packages in such systems.
So, how to take advantage of systemd instead of cron?

Powered by WPeMatico

Share Button

Fedora Magazine: Convert your Fedora Silverblue to HTPC with Kodi

Share Button

Ever wanted to create a HTPC from old computer laying around. Or just have some spare time and want to try something new. This article could be just for you. It will show you the step by step process to convert a Fedora Silverblue to a fully fledged HTPC.

What is Fedora Silverblue, Kodi and HTPC?

Fedora Silverblue is a system similar to Fedora Workstation. It offers an immutable filesystem (only /var and /etc are writable) and atomic updates using an ostree image, which offers reliable updates with ability to rollback to previous version easily. If you want to find out more about Fedora Silverblue visit https://silverblue.fedoraproject.org/ or if you want to try it by yourself you can get it here.

Kodi is one of the best multimedia player available. It provides plenty of features (like automatic downloads of metadata for movies, support for UPnP etc.) and it’s open source. It also has many addons. So if you are missing any functionality you could probably find an addon for it.

HTPC is just an acronym for Home Theater PC in simple words a PC that is mainly used as an entertainment station. You can connect it to TV or any monitor and just use it to watch your favorite movies, TV shows or listen to your favorite music.

Why choosing Silverblue to create an HTPC?

So why choosing Fedora Silverblue for HTPC? The main reasons are:

  • Reliability – you don’t need to fear that after update everything stop working and if it does, I can rollback easily
  • New technology – it is a good opportunity to play with a new technology.

And why to choose Kodi ? As stayted before it’s one of the best multimedia player and it’s packaged as a flatpak, which make it easy to install on Silverblue.

Conversion of Fedora Silverblue to HTPC

Let’s go step by step through this process and see how to create a fully usable HTPC from Fedora Silverblue.

1. Installation of Fedora Silverblue

First thing you need to do is to install Fedora Silverblue, this guide will not cover the installation process, but you can expect similar process as with standard Fedora Workstation installation. You can get the Fedora Silverblue ISO here

Create only the root user during the installation with some password. We will create a user for Kodi later without password.

2. Booting to terminal

This part will be a little tricky. You need to bypass GNOME and end the boot sequence in terminal. Otherwise you will end up in GNOME initial setup process, which will not allow you to create user without password.

To bypass the GNOME you need to press the ‘e’ key in GRUB menu to edit the GRUB entry. When editing the GRUB entry just look for the line starting with linux16 and add 3 to end of this line. Then continue the boot sequence with CTRL + x. Don’t worry about the changes, they are used only for this session.

GRUB menu
GRUB entry edited

You will end up in terminal where you need to login as root.

3. Creation of user for Kodi

When you are in the terminal logged as root, you need to create a user that will be used by Kodi. This can be done using the useradd command.

useradd kodi

4. Installation of Kodi from Flathub

To install the Kodi in flatpak you first need to add a Flathub remote repository.

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

With the Flathub repository added the installation of Kodi is simple.

flatpak install flathub tv.kodi.Kodi

5. Set Kodi as autostart application

First we need to create the autostart directory for the kodi user, this is easier if you switch to kodi user directly.

su kodi
mkdir -p /home/kodi/.config/autostart

Then you need to create a symlink for the Kodi desktop file.

ln -s /var/lib/flatpak/exports/share/applications/tv.kodi.Kodi.desktop /home/kodi/.config/autostart/tv.kodi.Kodi.desktop

The last thing that will prevent for autostart to work correctly is the GNOME initial setup. To disable it just create a gnome-initial-setup-done file in .config directory of kodi user.

echo "yes" > /home/kodi/.config/gnome-initial-setup-done

You can now switch back to root for the next steps.

exit

6. Set autologin for kodi user

This step is very useful together with autostart of Kodi. Every time you restart your HTPC you will end up directly in Kodi and not in the GDM or GNOME shell. To set the auto login you need to add the following lines to /etc/gdm/custom.conf to the [daemon] section

AutomaticLoginEnable=True       
AutomaticLogin=kodi

7. Enable automatic updates

For HTPC automatic updates you will need a cron job. But because cron is not part of the standard Fedora Silverblue installation you need to install it first. In this step I also recommend to do upgrade of the Fedora Silverblue first before layering the cron package.

rpm-ostree upgrade

rpm-ostree install cronie

After this you need to reboot your computer, to apply the new updates.

reboot

To be able to setup cron in this phase you need to do the second step again and log in as root. After this you need to edit the crontab.

crontab -e

And add the following line to it.

0 4 * * 3 flatpak update -y; rpm-ostree upgrade; reboot

This will create a new cron job, which will update any flatpaks (Kodi in this case), update Silverblue and does a restart to apply the changes.

This job will run at 4 AM on Wednesday. It is recommended to set this to a time when nobody will use the HTPC.

Restart the computer now.

reboot

8. Disable GNOME features

There are few GNOME features that could be annoying when using Fedora Silverblue as HTPC. Most of these features could be setup directly in Kodi anyway, so if you want them later it’s easy to set them directly in Kodi.

To do this exit Kodi and open the terminal. Press Super key (this is the key between ALT and CTRL) and type terminal. Once the terminal will be open and you need to type the following commands.

# Display dim
dconf write "/org/gnome/settings-daemon/plugins/power/idle-dim" false

# Sleep over time/
dconf write "/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type" 0

# Screensaver
dconf write "/org/gnome/desktop/screensaver/lock-enabled" false

# Automatic updates through gnome-software
dconf write "/org/gnome/software/download-updates" false

And that’s it, you just need to do one last restart to apply the dconf changes. After the restart you will end up directly in Kodi.

Kodi

What now?

Now I will recommend you to play with the Kodi settings a little bit and set it up to your liking. You can find plenty of guides on the internet.

If you want to automate the process you can use my ansible script that was written just for this occasion.


Photo by Sven Scheuermeier on Unsplash

Powered by WPeMatico

Share Button

Kushal Das: Tracking my phone's silent connections

Share Button

My phone has more friends than me. It talks to more peers (computers) than the
number of human beings I talk on an average. In this age of smartphones and
mobile apps for A-Z things, we are dependent on these technologies. However, at
the same time, we don’t know much of what is going on in the computers equipped
with powerful cameras, GPS device, microphone we are carrying all the time. All
these apps are talking to their respective servers (or can we call them
masters?), but, there is no easy way to track them.

These questions bothered me for a long time: I wanted to see the servers my
phone is connecting to, and I want to block those connections as I wish.
However, I never managed to work on this. A few weeks ago, I finally sat down to
start working to build up a system by reusing already available open source
projects and tools to create the system, which will allow me to track what my
phone is doing. Maybe not in full details, but, at least shed some light on the
network traffic from the phone.

Initial trial

I tried to create a wifi hotspot at home using a Raspberry Pi and then started
capturing all the packets from the device using standard tools (dumpcap) and
later reading through the logs using Wireshark. This procedure meant that I
could only capture when I am connected to the network at home. What about when I
am not at home?

Next round

This time I took a bit different approach. I chose
algo to create a VPN server. Using
WireGuard, it became straightforward to connect my
iPhone to the VPN. This process also allows capturing all the traffic from the
phone very easily on the VPN server. A few days in the experiment,
Kashmir started posting her experiment named
Life Without the Tech
Giants
, where she
started blocking all the services from 5 big technology companies. With her
help, I contacted Dhruv Mehrotra, who is a
technologist behind the story. After talking to him, I felt that I am going in
the right direction. He already posted
details
on how they did the blocking, and you can try that at home 🙂

Looking at the data after 1 week

After capturing the data for the first week, I moved the captured pcap files
into my computer. Wrote some Python code to put the data into a SQLite database,
enabling me to query the data much faster.

Domain Name System (DNS) data

The Domain Name System (DNS)
is a decentralized system which helps to translate the human memory safe domain
names (like kushaldas.in) into Internet Protocol (IP) addresses (like
192.168.1.1 ). Computers talk to each other using these IP addresses, we, don’t
have to worry to remember so many names. When the developers develop their
applications for the phone, they generally use those domain names to specify
where the app should connect.

If I plot all the different domains (including any subdomain) which got queried
at least 10 times in a week, we see the following graph.

The first thing to notice is how the phone is trying to find servers from Apple,
which makes sense as this is an iPhone. I use the mobile Twitter app a lot, so
we also see many queries related to Twitter. Lookout is a special mention there,
it was suggested to me by my friends who understand these technologies and
security better than me. The 3rd position is taken by Google, though sometimes I
watch Youtube videos, but, the phone queried for many other Google domains.

There are also many queries to Akamai CDN service, and I could not find any easy
way to identify those hosts, the same with Amazon AWS related hosts. If you know
any better way, please drop me a note.

You can see a lot of data analytics related companies were also queried.
dev.appboy.com is a major one, and thankfully algo already blocked that domain
in the DNS level. I don’t know which app is trying to connect to which all
servers, I found about a few of the apps in my phone by searching about the
client list of the above-mentioned analytics companies. Next, in coming months,
I will start blocking those hosts/domains one by one and see which all apps stop
working.

Looking at data flow

The number of DNS queries is an easy start, but, next I wanted to learn more
about the actual servers my phone is talking to. The paranoid part inside of me
was pushing for discovering these servers.

If we put all of the major companies the phone is talking to, we get the
following graph.

Apple is leading the chart by taking 44% of all the connections, and the number
is 495225 times. Twitter is in the second place, and Edgecastcdn is in the
third. My phone talked to Google servers 67344 number of times, which is like 7
times less than the number of times Apple itself.

In the next graph, I removed the big players (including Google and Amazon).
Then, I can see that analytics companies like nflxso.net and mparticle.com
have 31% of the connections, which is a lot. Most probably I will start with
blocking these two first. The 3 other CDN companies, Akamai, Cloudfront, and
Cloudflare has 8%, 7%, and 6% respectively. Do I know what all things are these
companies tracking? Nope, and that is scary enough that one of my friend
commented “It makes me think about throwing my phone in the garbage.”

What about encrypted vs unencrypted traffic? What all protocols are being used?
I tried to find the answer for the first question, and the answer looks like the
following graph. Maybe the number will come down if I try to refine the query
and add other parameters, that is a future task.

What next?

As I said earlier, I am working on creating a set of tools, which then can be
deployed on the VPN server, that will provide a user-friendly way to monitor,
and block/unblock traffic from their phone. The major part of the work is to
make sure that the whole thing is easy to deploy, and can be used by someone
with less technical knowledge.

How can you help?

The biggest thing we need is the knowledge of “How to analyze the data we are
capturing?”. It is one thing to make reports for personal user, but, trying to
help others is an entirely different game altogether. We will, of course, need
all sorts of contributions to the project. Before anything else, we will have
to join the random code we have, into a proper project structure. Keep following
this blog for more updates and details about the project.

Note to self

Do not try to read data after midnight, or else I will again think a local
address as some random dynamic address in Bangkok and freak out (thank you
reverse-dns).

Powered by WPeMatico

Share Button

Fedora Community Blog: Draft Fedora 31 schedule available

Share Button

Image by Wikipedia user used under CC BY-SA 3.0 https://en.wikipedia.org/wiki/File:Pert_example_gantt_chart.gif

It’s almost time for me to submit the Fedora 31 schedule to FESCo for approval. Before I do that, I’m sharing it with the community for comment. After some discussion before the end of the year, we decided not to go with an extended development cycle for Fedora 31. After getting input from teams within Fedora, I have a draft schedule available.

The basic structure of the Fedora 31 schedule is pretty similar to the Fedora 30 schedule. You may notice some minor formatting changes due to a change in the tooling, but the milestones are similar. I did incorporate changes from different teams. Some tasks that are no longer relevant were removed. I added tasks for the Mindshare teams. And I included several upstream milestones.

Take a look at the full schedule. If you have any questions or comments, join me in the FPgM office hours on Wednesday or file an issue in the schedule Pagure. I’ll be submitting the schedule to FESCo next week for approval.

The post Draft Fedora 31 schedule available appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

Kiwi TCMS: Kiwi TCMS 6.5.3

Share Button

We’re happy to announce Kiwi TCMS version 6.5.3! This is a
security, improvement and bug-fix update that includes new
versions of Django, includes several database migrations and fixes several bugs.
You can explore everything at
https://demo.kiwitcms.org!

Supported upgrade paths:

5.3   (or older) -> 5.3.1
5.3.1 (or newer) -> 6.0.1
6.0.1            -> 6.1
6.1              -> 6.1.1
6.1.1            -> 6.2 (or newer)

Docker images:

kiwitcms/kiwi       latest  b9355cf85833    1.039 GB
kiwitcms/kiwi       6.2     7870085ad415    957.6 MB
kiwitcms/kiwi       6.1.1   49fa42ddfe4d    955.7 MB
kiwitcms/kiwi       6.1     b559123d25b0    970.2 MB
kiwitcms/kiwi       6.0.1   87b24d94197d    970.1 MB
kiwitcms/kiwi       5.3.1   a420465852be    976.8 MB

Changes since Kiwi TCMS 6.5

Security

  • Update Django from 2.1.5 to 2.1.7. Fixes CVE-2019-6975:
    Memory exhaustion in django.utils.numberformat.format()

Improvements

  • Update mysqlclient from 1.4.1 to 1.4.2
  • Multiple template strings marked as translatable (Christophe CHAUVET)

Database migrations

  • Email notifications for TestPlan and TestCase now default to True
  • Remove TestPlanEmailSettings.is_active field

API

  • New method Bug.report(), References
    Issue #18
  • Method Bug.create() now accepts parameter auto_report=False

Translations

Bug fixes

  • Show the user who actually tested a TestCase instead of hard-coded value. Fixes
    Issue #765
  • Properly handle pagination button states and page numbers. Fixes
    Issue #767
  • Add TestCase to TestPlan if creating from inside a TestPlan. Fixes
    Issue #777
  • Made TestCase text more readable. Fixes
    Issue #764
  • Include missing templates and static files from PyPI tarball

Refactoring

  • Use find_packages() when building PyPI tarball
  • Install Kiwi TCMS as tarball package inside Docker image instead of copying
    from the source directory
  • Pylint fixes
  • Remove testcases.views.ReturnActions() which is now unused
  • Refactor New TestCase to class-based view and add tests

How to upgrade

If you are using Kiwi TCMS as a Docker container then:

cd Kiwi/
git pull
docker-compose down
docker pull kiwitcms/kiwi
docker pull centos/mariadb
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate

Don’t forget to backup
before upgrade!

WARNING: kiwitcms/kiwi:latest and docker-compose.yml will
always point to the latest available version! If you have to upgrade in steps,
e.g. between several intermediate releases, you have to modify the above workflow:

# starting from an older Kiwi TCMS version
docker-compose down
docker pull kiwitcms/kiwi:
edit docker-compose.yml to use kiwitcms/kiwi:
docker-compose up -d
docker exec -it kiwi_web /Kiwi/manage.py migrate
# repeat until you have reached latest

Happy testing!

Powered by WPeMatico

Share Button

Jiri Eischmann: Better Bluetooth sound quality on Linux

Share Button

Over a year ago I got my first serious Bluetooth headphones. They worked with Fedora well, they paired, connected, sound was directed to them. Just the sound quality was not overwhelming. I learnt that because of limited bandwidth of Bluetooth a codec with audio compression has to be used. There are quite a few of them to pick from: AAC (very widely supported because it’s the only one iPhone supports, partly freely available), AptX (also very widely supported, but proprietary), AptX-HD (enhanced AptX with a higher bitrate, also proprietary), LDAC (probably the best codec available, highest bitrate, available in Android, supported mostly by Sony devices), MP3 (also possible, but supported by virtually no devices). And also SBC which is a native Bluetooth, first generation compression codec with rather bad sound quality.

My headphones supported SBC, AAC, AptX, AptX-HD, LDAC, so all the advanced codecs. Sadly on Linux it fallbacked to the basic SBC because no other was available for Bluetooth, and headphones for €200 produced rather underwhelming sound. I mostly listen to music on Spotify. Listening to it on my headphones meant transcoding OGG 320 kbps to SBC and losing a lot of sound quality.

Then I recalled that Sony released LDAC as open source in the Android Open Source Project. And they really did because you can find libldac released under Apache 2.0 License there. So it could possibly be made available on Linux, too. Bluez was also able to negotiate LDAC with the end device. What was missing was a plugin for PulseAudio that would utilize the codec and encode the stream into LDAC before sending it over Bluetooth to the headphones.

Today I learnt that such a plugin had been finally created.  And besides LDAC it also supports AAC, AptX, and AptX-HD. Those are patent-protected codecs and the plugin relies on ffmpeg to support them, so it’s not likely they will be available in Fedora any time soon. But libldac is already in Fedora package review and is waiting for the final legal approval. The plugin currently depends on ffmpeg, but if it were made optional, we could at least ship LDAC support by default in Fedora Workstation.

I thought we could also support AAC because its decoder/encoder is already available in Fedora, but I learnt that it only supported the original AAC format while what devices support these days is HE-AAC which is still protected by patents.

Anyway, someone already built packages of both the plugin and libldac and I installed them to test it. And it worked on Fedora 29 Workstation, LDAC was used for Bluetooth stream encoding:

ldac

I don’t have bat ears, but I could recognize a difference in sound quality immediately.

If I’m not mistaken it makes Linux the first desktop system to support LDAC. And with support for other codecs it will make it the OS with the best Bluetooth sound quality support because all other systems support only a subset of the list, hence fewer headphones/speakers at their best sound quality.

Powered by WPeMatico

Share Button

Guillaume Kulakowski: Plugin ZiGate pour Jeedom v1.2.0

Share Button

Après pas mal d’efforts et surtout de tests, la version 1.2.0 du plugin ZiGate pour Jeedom vient de sortir. Parmi les nombreuses nouveautés, on remarquera : Des corrections de bugs en tout genre. Le support de nouveaux périphériques. L’identifiant unique d’un équipement Jeedom (LogicalId) passe de l’adresse (ADDR) à l’IEEE. L’idée et d’assurer un identifiant […]

Cet article Plugin ZiGate pour Jeedom v1.2.0 est apparu en premier sur Guillaume Kulakowski’s blog.

Powered by WPeMatico

Share Button