- Off to a baptism at re:new and a shared lunch which was interesting, back in the afternoon slept on the sofa; pizza dinner, dancing competition on the trampoline, read stories; bed.
This is a feed aggregator that collects what openSUSE contributors are writing in their respective blogs.
To have your blog added to this aggregator, please read the instructions.
Note that you may use those keys with or without pressing the alt key.
Running in circles Another run without earphones was completed last night – I’ve reverted to using a Polar chest strap hear rate monitor whilst the Jabras are in their non-working state. Relatively faster and slow interval running last night – at over 30C and high humidity it’s not much fun. Jabra have offered to check […]
The openSUSE project has finally decided to split the deprecated net-tools binaries from the core net-tools package and moved them into net-tools-deprecated.
The following tools were removed from net-tools and moved into net-tools-deprecated in openSUSE Tumbleweed
You should only use the above deprecated tools if, and only if there’s an antiquated application or tool that you’re running requires them.
What should you be using in their place?
|Deprecated Tool||Alternative Tool|
ip route (netstat -r)
ip -s link (netstat -i)
If you haven’t made the switch I highly recommend you do as the the above (along with mil-tool and nameif) have been deprecated for many years now per the net-tools Linux Foundation page.
It’s that time of the year again, it seems: I’m working on KPluginMetaData improvements.
In this article, I am describing a new feature that allows developers to filter applications and plugins depending on the target device they are used on. The article targets developers and device integrators and is of a very technical nature.
This time around, I’m adding a mechanism that allows us to list plugins, applications (and the general “service”) specific for a given form factor. In normal-people-language, that means that I want to make it possible to specify whether an application or plugin should be shown in the user interface of a given device. Let’s look at an example: KMail. KMail has two user interfaces, the desktop version, a traditional fat client offering all the features that an email client could possibly have, and a touch-friendly version that works well on devices such as smart phones and tablets. If both are installed, which should be shown in the user interface, for example the launcher? The answer is, unfortunately: we can’t really tell as there currently is no scheme to derive this information from in a reliable way. With the current functionality that is offered by KDE Frameworks and Plasma, we’d simply list both applications, they’re both installed and there is no metadata that could possibly tell us the difference.
Now the same problem applies to not only applications, but also, for example to settings modules. A settings module (in Frameworks terms “KCM”) can be useful on the desktop, but ignored for a media center. There may also be modules which provide similar functionality, but for a different use case. We don’t want to create a mess of overlapping modules, however, so again, we need some kind of filtering.
Enter KPluginMetaData. KPluginMetaData gives information about an application, a plugin or something like this. It lists name, icon, author, license and a whole bunch of other things, and it lies at the base of things such as the Kickoff application launcher, KWin’s desktop effects listing, and basically everything that’s extensible or uses plugins.
I have just merged a change to KPluginMetaData that allows all these things to specify what form factor it’s relevant and useful for. This means that you can install for example KDevelop on a system that can be either a laptop or a mediacenter, and an application listing can be adapted to only show KDevelop when in desktop mode, and skipping it in media center mode. This is of great value when you want to unclutter the UI by filtering out irrelevant “stuff”. As this mechanism is implemented at the base level, KPluginMetaData, it’s available everywhere, using the exact same mechanism. When listing or loading “something”, you simply check if your current formfactor is among the suggested useful ones for an app or plugin, and based on that you make a decision whether to list it …
Juniper 8.0R5 includes support for 64-bit Linux systems. However, the process is a different on Tumbleweed and openSUSE 13.1 which I wrote about previously.
Juniper includes instructions via KB25230, however, their directions aren’t complete.
The following instructions will provide a functional Juniper VPN installation on openSUSE Tumbleweed:
sudo zypper in -y libXi.so.6 libXrender1-32bit libXtst6-32bit net-tools-deprecated
Extract Java to a location of your choosing:
tar xzvf jre-8u45-linux-i586.tar.gz -C /home/ben/apps/java32
Update /usr/bin/java alternatives to use 32-bit
sudo update-alternatives –install /usr/bin/java java /home/ben/apps/java32/jre-latest/bin/java 100
Note: you must use Firefox as Chrome/Chromium on Linux has already deprecated NPAPI plugin support.
The Web Open Font Format (short WOFF; here using Aladin font) is several years old. Still it took some time to get to a point, where WOFF is almost painless to use on the linux desktop. WOFF is based on OpenType style fonts and is in some way similar to the more known True Type Font (.ttf). TTF fonts are widely known and used on the Windows platform. Those feature rich kind of fonts are used for high quality font displaying for the system and local office-and design documents. WOFF aims at closing the gap towards making those features available on the web. With these fonts it becomes possible to show nice looking fonts on paper and web presentations in almost the same way. In order to make WOFF a success, several open source projects joined forces, among them Pango and Qt, and contributed to harfbuzz, a OpenType text shaping engine. Firefox and other web engines can handle WOFF inside SVG web graphics and HTML web documents using harfbuzz. Inkscape uses at least since version 0.91.1 harfbuzz too for text inside SVG web graphics. As Inkscape is able to produce PDF’s, designing for both the web and print world at the same time becomes easier on Linux.
How to install WOFF?
For using inside inkscape one needs to install the fonts locally. Just copy the fonts to your personal ~/.fonts/ path and run
fc-cache -f -v
After that procedure the fonts are visible inside a newly started Inkscape.
How to deploy SVG and WOFF on the Web?
Thankfully WOFF in SVG documents is similar to HTML documents. However simply uploading a Inkscape SVG to the web as is will not be enough to show WOFF fonts. While viewing the document locally is fine, Firefox and friends need to find those fonts independent of the localy installed fonts. Right now you need to manually edit your Inkscape SVG to point to the online location of your fonts . For that open the SVG file in a text editor and place a CSS font-face reference right after the <svg> element like:
src: url(“fonts/Aladin-Regular.woff”) format(“woff”);
How to print a Inkscape SVG document containing WOFF?
Just convert to PDF from Inkscape’s file menue. Inkscape takes care for embedding the needed fonts and creates a portable PDF.
In case your prefered software is not yet WOFF ready, try the woff2otf python script for converting to the old TTF format.
Hope this small post gets some of you on the font fun path.
Running Unfortunately, it’s more running without heart rate monitoring earphones, as the fifth pair have now failed. I make that just about 5 pairs failed inside 5 months. I am not going to warranty replace these ones – there is quite clearly a flaw and I don’t really see the point in continuing to trek […]
Deep thought and some additional core SUSE Linux Enterprise source code have given The openSUSE Project a path forward for future releases.
The change is so phenomenal that the project is building a whole new release.
Some people might be perplexed over the next regular release, but rather than bikeshedding the name over the next few months, for the moment, we will call it openSUSE: 42 after its project name in the Open Build Service. And we are going to explain the roadmap for this regular release.
openSUSE 42 is scheduled to be released around SUSECon, which is in Amsterdam this year from Nov. 2 – 6.
Unlike old releases, future releases of “42” are expected to align with the releases of SLE service packs and major releases.
There are about 2,000 packages in openSUSE 42 right now, said Stephan “Coolo” Kulow, release manager. Of course, many more are expected.
openSUSE 42 will be a long-term type release with enduring updates and maintenance commitments by the community and SUSE.
Kulow said a milestone will be released soon.
“We have to come up with solutions as problems arise,” Kulow said.
There is currently no plans for live CDs, but he said expect other media formats to be added later.
After more than two years of development, 15 pre-releases and more than 2000 commits we proudly present release 2.0 of the DocBook Authoring and Publishing Suite, in short DAPS 2.0.
DAPS lets you publish your DocBook 4 or Docbook 5 XML sources in various output formats such as HTML, PDF, ePUB, man pages or ASCII with a single command. It is perfectly suited for large documentation projects by providing profiling support and packaging tools. DAPS supports authors by providing linkchecker, validator, spellchecker, and editor macros. DAPS exclusively runs on Linux.
For download and installation instructions refer to https://github.com/openSUSE/daps/blob/master/INSTALL.adoc
Highlights of the DAPS 2.0 release include:
Please note that this DAPS release does not support webhelp. It is planned to re-add webhelp support with DAPS 2.1.
For a complete Changelog refer to https://github.com/openSUSE/daps/blob/master/ChangeLog
If you have got questions regarding DAPS, please use the discussion forum at https://sourceforge.net/p/daps/discussion/General/. We will do our best to help.
To report bugs or file enhancement issues, use the issue Tracker at https://github.com/openSUSE/daps/issues.
DAPS is developed by the SUSE Linux documentation team and used to generate the product documentation for all SUSE Linux products. However, it is not exclusively tailored for SUSE documentation, but supports every documentation written in DocBook.
DAPS has been tested on Debian Wheezy, Fedora 20/21 openSUSE 13.x, SLE 12, and Ubuntu 14.10.
The DAPS project moved from SourceForge to GitHub and is now available at https://opensuse.github.io/daps/.
Recently Thomas and me met in person and thought about an alternative approach to bring our big file chunking to the next level. “Big file chunking” is ownClouds algorithm to upload huge files to ownCloud with clients.
This is the first of three little blog posts in which we want to present the idea and get your feedback. This is for open discussion, nothing is set in stone so far.
What is the downside of the current approach? Well, the current algorithm needs a lot of distributed knowledge between server and client to work: The naming scheme of the part files, semi secret headers, implicit knowledge. In addition to that, due to the character of the algorithm the server code is too much spread over the whole code base which makes maintaining difficult.
This situation could be improved with the following approach.
To handle chunked uploads, there will be a new WebDAV route, called remote.php/uploads.
All uploads of files larger than the chunk size will go through this route.
In a nutshell, an upload of a big file will happen as parts to a directory under that new route. The client creates it through the new route. This initiates a new upload. If the directory could be created successfully, the client starts to upload chunks of the original file into that directory. The sequence of the chunks is set by the names of the chunk files created in the directory. Once all chunks are uploaded, the client submits a MOVE request the renames the chunk upload directory to the target file.
Here is a pseudo code description of the sequence:
1. Client creates an upload directory with a self choosen name (ideally a numeric upload id):
2. Client sends a chunk:
3. Client repeats 2. until all chunks have successfully been uploaded
4. Client finalizes the upload:
MOVE remote.php/uploads/upload-id /path/to/target-file
5. The MOVE sends the ETag that is supposed to be overwritten in the request header to server. Server returns new ETag and FileID as reply headers of the MOVE.
During the upload, client can retrieve the current state of the upload by a PROPFIND request on the upload directory. The result will be a listing of all chunks that are already available on the server with metadata such as mtime, checksum and size.
If the server decides to remove an upload, ie. because it hasn’t been active for a time, it is free to remove the entire upload directory and return status 404 if a client tries to upload to. Also, a client is allowed to remove the entire upload directory to cancel an upload.
An upload is finalized by the MOVE request. Note that it’s a MOVE of a directory on a single file. This operation is not supported in normal file systems, but we think in this case, it has a nice well descriptive meaning. A MOVE …
After fifty odd years my big toe toenails decided that deforming themselves would be a jolly wheeze. Like most men I figured leaving it was a brilliant idea and that self diagnoses “Tell you what, I won’t cut them and they’ll grow out!” was the answer. The nails were becoming pretty lethal, cutting their own escape routes from any pair of socks that dared to try and contain them. After getting through most of Marks and Spencer’s sock inventory I decided enough was enough and visited my doctors for the first time since 2011. After being told “You’re a little overweight.” which was a tad cheeky given he hadn’t even weighed me, I was given an appointment at the Podiatry clinic to have the offending nails removed.
The waiting area left a lot to be desired, effectively it was some seats against the wall outside the lift! My daughter and I sat there not without some trepidation I hasten to add when the air was pierced by what was evidently a girl screaming “Aaaaaaarrrrrrrrrrrgh” what little blood was sloshing around in my cheeks left my face and I assumed the pose of a scared rabbit caught in the headlights. The girl in question appeared a few minutes later sporting a large bandage on her big toe but clearly relieved it was all over. “Mr Cannon?” I tried to pretend that my name was in fact Yul Brynner but the Podiatrist wasn’t fooled because he’d met me before. A very nice nurse with cherry red hair and apparently formerly a Goth moved towards my toes with what looked like a whale harpoon! “Now Mr Cannon, I’m going to inject your toes in four places, here, here….” I held up my hand, “Any chance I can have gas?” I’m not going to lie, the first three smarted a bit, the nurse had said I could swear if I needed to but I’d promised myself I’d be a brave little soldier. “I’m just going to do under the toe, now it is a fairly big nerve.” said the nurse. “SHIIIIIIITING HELL!” sadly I let myself down.
The removal of the nails took no time at all and I felt nothing. The Podiatrist kept asking it I wanted to look, sadist. I politely refused although I did agree to look at the nails after he had used half of the cotton industries yearly output on my toes “Here you are then Mr Cannon, oh let me just remove that bit of flesh before I show you your nails.” while choking back the contents of my breakfast he proceeded to waft said gnarled up talons in front of me. “Now here’s is your paperwork, go and see your practice nurse tomorrow and she will change the dressing and give you some dressings so you can look after your wounds for about two to three weeks.” he said. Now this part is important …