You are here

Site në gjuhë të huaj

Steinar H. Gunderson: Not going to FOSDEM—but a year of Nageru

Planet Debian - Pre, 03/02/2017 - 12:29pd

It's that time of the year :-) And FOSDEM is fun. But this year I won't be going; there was a scheduling conflict, and I didn't really have anything new to present (although I probably could have shifted around priorities to get something).

But FOSDEM 2017 also means there's a year since FOSDEM 2016, where I presented Nageru, my live video mixer. And that's been a pretty busy year, so I thought I'd do a live cap from high up above.

First of all, Nageru has actually been used in production—we did Solskogen and Fyrrom, and both gave invaluable input. Then there have been some non-public events, which have also been useful.

The Nageru that's in git right now is evolved considerably from the 1.0.0 that was released last year. diffstat shows 19660 insertions and 3543 deletions; that's counting about 2500 lines of vendored headers, though. Even though I like deleting code much more than adding it, the doubling (from ~10k to ~20k lines) represents a significant amount of new features:

1.1.x added support for non-Intel GPUs. 1.2.x added support for DeckLink input cards (through Blackmagic's proprietary drivers), greatly increasing hardware support, and did a bunch of small UI changes. 1.3.x added x264 support that's strong enough that Nageru has really displaced VLC as my go-to tool for just video-signal-to-H.264-conversion (even though it feels overkill), and also added hotplug support. 1.4.x added multichannel audio support including support for MIDI controllers, and also a disk space indicator (because when you run out of disk during production without understanding that's what happens, it really sucks), and brought extensive end-user documentation. And 1.5.x, in development right now, will add HDMI/SDI output, which, like all the previous changes, requires various rearchitecting and fixing.

Of course, there are lots of things that haven't changed as well; the basic UI remains the same, including the way the theme (governing the look-and-feel of the finished video stream) works. The basic design has proved sound, and I don't think I would change a lot if I were to design something like 1.0.0 again. As a small free software project, you have to pick your battles, and I'm certainly glad I didn't start out doing something like network support (or a distributed architecture in general, really).

So what's for the next year of Nageru? It's hard to say, and it will definitely depend on the concrete needs of events. A hot candidate (since I might happen to need it) is chroma keying, although good keying is hard to get right and this needs some research. There's also been some discussion around other concrete features, but I won't name them until a firm commitment has been made; priorities can shift around, and it's important to stay flexible.

So, enjoy FOSDEM! Perhaps I'll return with a talk in 2018. In the meantime, I'll preparing the stream for the 2017 edition of Fyrrom, and I know for sure there will be more events, more features and more experiences to be had. And, inevitably, more bugs. :-)

Mario Sanchez Prada: Going to FOSDEM!

Planet GNOME - Enj, 02/02/2017 - 11:08md

It’s been two years since the last time I went to FOSDEM, but it seems that this year I’m going to be there again and, after having traveled to Brussels a few times already by plane and train, this year I’m going by car!: from Staines to the Euro tunnel and then all the way up to Brussels. Let’s see how it goes.

As for the conference, I don’t have any particular plan other than going to some keynotes and probably spending most of my time in the Distributions and the Desktops devrooms. Well, and of course joining other GNOME people at A La Bécasse, on Saturday night.

As you might expect, I will have my Endless laptop with me while in the conference, so feel free to come and say “hi” in case you’re curious or want to talk about that if you see me around.

At the moment, I’m mainly focused on developing and improving our flatpak story, how we deliver apps to our users via this wonderful piece of technology and how the overall user experience ends up being, so I’d be more than happy to chat/hack around this topic and/or about how we integrate flatpak in EndlessOS, the challenges we found, the solutions we implemented… and so forth.

That said, flatpak is one of my many development hats in Endless, so be sure I’m open to talk about many other things, including not work-related ones, of course.

Now, if you excuse me, I have a bag to prepare, an English car to “adapt” for the journey ahead and, more importantly, quite some hours to sleep. Tomorrow it will be a long day, but it will be worth it.

See you at FOSDEM!

Vincent Fourmond: Extended dataset generation possibilities of QSoas

Planet Debian - Enj, 02/02/2017 - 10:58md
While the main focus of QSoas is the processing of experimental data, it also features commands to generate (calculate) datasets. The command generate-buffer creates a dataset of equally spaced points (you can change their number using the option /samples) between to limiting values, as below:

QSoas> generate-buffer -2 2

By default, the values are taken equal to . However, generate-buffer also takes an optional formula to directly set the values:

QSoas> generate-buffer -10 10 sin(x)

From version 2.0, it is possible to generate several datasets in a row using the /number option, and to color them using the /style option (but only since version 2.1). Each dataset is generated according to the formula, and number is a special number that starts at 0 and increases by 1 for each dataset. Here's what I used to generate the picture on the right:

QSoas> generate-buffer -2 2 sin(PI*x)**(number+1) /number=30 /style=red-to-blue About QSoasQSoas is an open source data analysis program that focuses on flexibility and powerful fitting capacities. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050–5052.

Harald Sitter: How to Global Menu in Plasma 5.9

Planet UBUNTU - Enj, 02/02/2017 - 6:02md

Today Plasma 5.9.0 became available in KDE neon User Edition. With it comes the return of global menus along with other awesome sauce features.

To enable global menus open System Settings, go into the Application Style category, and in the Widget Style settings you will find a tab called Fine Tuning. On this tab you can find the new Menubar options. You can change to either a Title Bar Button, which will tuck the menu into a tiny button into the window decoration bar at the top, or the Application Menu widget, allowing the associated Plasma panel to supply the menu in a fixed location.

To apply the change, your applications need to be restarted, so ideally you’ll simply log out and back in again.

To add an Application Menu to Plasma, simply right click on the desktop and add the Panel called Application Menu Bar.

Enjoy your new Plasma 5.9 with global menu bars!

Guido Günther: Debian Fun in January 2017

Planet Debian - Enj, 02/02/2017 - 5:48md
Debian LTS

November marked the 21st month I contributed to Debian LTS under the Freexian umbrella. I had 8 hours allocated which I used for:

  • the first half of a LTS front desk week
  • updating icedove 45.6.0 resulting in DLA-782-1 fixing 8 CVEs
  • releasing DLA-783-1 for XEN, the actual update was provided by credativ
  • testing the bind9 update prepared by Thorsten Alteholz
  • fixing 8 CVEs in imagemagick resulting in DLA-807-1.
  • work on recent qemu CVEs
Other Debian stuff
  • Usual bunch of libvirt and related uploads
  • Uploaded git-buildpackage 0.8.10 to 0.8.12.1 to experimental and unstable fixing (among other things) a long standing bug when using multiple tarballs with filters and pristine-tar as well as making generated orig tarballs reproducible so one gets identical tarballs even without pristine-tar.
  • Ran a gbp import-dsc of unstable and filed bugs for cases where pristine-tar would not import the package. Started to look into git-apply errors.
Some other Free Software activites
  • libplanfahr: switched the example to python3 and made it parse arguments without date as "today":

    $ ./run python examples/trip-query.py --when=21:00 Essen Gelsenkirchen Loaded provider de_db Start: Essen Hbf End: Gelsenkirchen Hbf Trip #1 Start: Essen Hbf Departure: 2017-02-02 21:18 Delay: 0 End: Gelsenkirchen Hbf Arrival: 2017-02-02 21:26 Delay: 0 Switches: 0 Trip #2 Start: Essen Hbf Departure: 2017-02-02 21:22 Delay: 0 End: Gelsenkirchen Hbf Arrival: 2017-02-02 21:33 Delay: 0 Switches: 0 Trip #3 Start: Essen Hbf Departure: 2017-02-02 21:44 Delay: 0 End: Gelsenkirchen Hbf Arrival: 2017-02-02 21:52 Delay: 0 Switches: 0
  • Proposed a workaround to rbvmomi to massively speedup cloning under certain conditions when using CachedOVFDeployer

  • Proposed a fix to unbreak ansible's zypper module on first installations
  • Made ausroller use git-buildpackage from pypi on non Debian based distros
  • Made further progess on the Merkur board clones

Michael Meeks: 2017-02-02 Thursday.

Planet GNOME - Enj, 02/02/2017 - 2:34md
  • Up, interesting customer call; is it easier and cheaper for Collabora to reverse engineer a 3rd party's usage of COM for automating MS Office, than getting a large SI to react ? - probably. Loraine B. over to see J, nice to catch up with her.
  • Trains variously to the Eurostar for FOSDEM, TDF meetings on Friday, and HackFest afterwards.

Steve Kemp: I've built a product, not a project

Planet Debian - Enj, 02/02/2017 - 8:15pd

The past few days I've been doing more arduino-work. In between dying of sleep-exhaustion.

One thing that always annoyed me was that I had to hard-code my WiFi credentials in my projects, with code like this:

// // Connect to the SCOTLAND network // WiFi.mode(WIFI_STA); WiFi.hostname("tram-clock"); WiFi.begin("SCOTLAND", "highlander1"); // // Attempt to connect - TODO: Timeout on failure // while (WiFi.status() != WL_CONNECTED) delay(500); // // Now we're connected show the local IP address. // lcd.print("WiFi connected "); lcd.print(WiFi.localIP());

Whilst looking at another project I found a great solution though. There is a library called WiFiManager which behaves perfectly:

  • If you've stored connection details it will connect to the local WiFI network using those, automatically.
  • If you've not saved previous connection details it will instead configure the device to work as an Access Point
    • You can then connect to that access point and see a list of local WiFi networks.
    • Choose the appropriate one from the list, enter your password, and these details are saved for the future.
    • The device will then reset, join the network via your saved choices and acquire an IP via DHCP as you'd expect.

The code for this is beautifully simple:

// // Connect to WiFI with saved credentials, if any. // // Otherwise work as an access-point, named TRAM-TIMES, and // let the user fill out their details. // WiFiManager wifiManager; wifiManager.autoConnect("TRAM-TIMES");

This means my current project, which continues to revolve around tram-times, is so very much more user-friendly. It is a product you could package and take to a friends house, not a project you have to recompile to tweak.

For that reason, user-niceness, I reworked the on-board HTTP status-page to use bootstrap, be themed, and look nicer. Other than being housed in a horrid case the project actually looks like a product. Not one I'd buy, but neither one I'm ashamed of sharing.

Paul Wise: FLOSS Activities January 2017

Planet Debian - Enj, 02/02/2017 - 1:29pd
Changes Issues Review Administration
  • Debian: reboot 1 non-responsive VM, redirect 2 users to support channels, redirect 1 contributor to xkb upstream, redirect 1 potential contributor, redirect 1 bug reporter to mirror team, ping 7 folks about restarting processes with upgraded libs, manually restart the sectracker process due to upgraded libs, restart the package tracker process due to upgraded libs, investigate failures connecting to the XMPP service, investigate /dev/shm issue on abel.d.o, clean up after rename of the fedmsg group.
  • Debian mentors: lintian/security updates & reboot
  • Debian packages: deploy 2 contributions to the live server
  • Debian wiki: unblacklist 1 IP address, whitelist 10 email addresses, disable 18 accounts with bouncing email, update email for 2 accounts with bouncing email, reported 1 Debian member as MIA, redirect 1 user to support channels, add 4 domains to the whitelist.
  • Reproducible builds: rescheduled Debian pyxplot:amd64/unstable for themill.
  • Openmoko: security updates & reboots.
Debian derivatives
  • Send the annual activity ping mail.
  • Happy new year messages on IRC, forward to the list.
  • Note that SerbianLinux does not provide source packages.
  • Expand URL shortener on SerbianLinux page.
  • Invite PelicanHPC, Netrunner, DietPi, Hamara Linux (on IRC), BitKey to the census.
  • Add research publications link to the census template
  • Fix Symbiosis sources.list
  • Enquired about SalentOS downtime
  • Fixed and removed some 404 BlankOn links (blog, English homepage)
  • Fixed changes to AstraLinux sources.list
  • Welcome Netrunner to the census
Sponsors

I renewed my support of Software Freedom Conservancy.

The openchange 1:2.2-6+deb8u1 upload was sponsored by my employer. All other work was done on a volunteer basis.

Iustin Pop: The snow is gone

Planet Debian - Mër, 01/02/2017 - 11:25md

Almost all traces of the snow are gone.

After a very dry December, January was an awesome month. Lots of snow, even in the city, that held for (I think) three weeks—very rare for Zürich. This happened because the temperature never went above -5°C, even during the day—proper winter for the city!

It was awesome to bike in these conditions. At first fresh snow (best! but slow), then packed snow, it never actually became dangerous ice.

And then, at the end of last week, temperatures started climbing. First near zero, then 1-2°C above, then it finally started going warm (above freezing even during the night). And the snow started melting a bit, then more, and then it started raining.

And it rained for three days. The worst thing, seeing snow being rained upon. Dirty grey snow, slowly melting away… I don't like this picture.

At least now the snow is gone, and the streets are almost dry, and we can look to either some more snow (I wish…) or spring.

I'd rather take -2°C global average temperatures than +2°C. I'm not sure what -5° would mean, but compared to no winter…

Michael Meeks: LibreOffice under the hood: six months of progress to 5.3

Planet GNOME - Mër, 01/02/2017 - 10:00md

Today we release LibreOffice 5.3.0, the next step in our journey: rich in features indeed - but (understandably) the media like to focus on the things you can see. What about the things you cannot ? the increasingly awesome underpinnings on which we're building the next round of improvements. Again - to see the pretty things people made and (more importantly) who did the heavy lifting checkout the user visible features from many great hackers, translators, UX designers etc. Here I am going to focus on the under-sung heros of making everything else better. There is an official 5.3 wiki page, but I expand on this and dive in more deeply here.

First apologies if I missed your good work; (and this is a very incomplete view based on a few hours of analysis) - please do add yourself to the wiki page and potentially mail me a unified diff to this; thanks ! It is only really possible to skim 9750 commits and nearly one hundred thousand lines of git log message across core and online - with:
26,080 files changed, 1,698,565 insertions(+), 361,298 deletions(-)

The last stubborn German comments

One thing that perplexes me about LibreOffice 5.3 is how we can have managed to translate 50,000 lines of German comments to English, but the last 3700 lines continue to defy us. Is it that people don't like finishing things ? Is it that the interest in comment translation is proportional to the number of remaining comments ? Seems unlikely - many of the remaning comments are in writer and calc. Either way - there is some lingering low-hanging glory for the person who can rid us of the last comments here ! Many thanks to Johannes Berg, Maarten Bosmans, Tor Lillqvist (Collabora), Julian Mehne and Albert Thuswaldner for taking on a few comments and to Phillip Szelat for updating the bin/find-german-comments tool.

A short list of strings to whet your appetite; please do help finally dispatch this gasping dragon if you're a native German speaker (or competent context reading programmer).

Crash Reporting

Markus Mohrhard's great work integrating a Breakpad based crash reporter has been extraordinarily useful. You can browse the crash reports here by version, and we've had over thirty crashreporter related fixes in 5.3 targetting particular issues. It is great to see commits like this that can quantify the win (20% of daily crashes in 5.2.0.4). We managed to nail lots of the most frequently reported issues soon after deploying the reporter.

Unfortunately, as Tomaz fixed another very long standing issue that was deadlocking the Windows clipboard code we managed to create a big spike in crashes (when exiting with a live clipboard) - this immediately jumped out of the stats:

Which allowed us to somewhat accelerate the next release containing a fix (hence 5.2.5.1 vs. 5.2.5.2). Markus also nailed a whole clutch of evil badness around processing of events during very late shutdown of LibreOffice that we hope will improve things still further.

Another curious issue is that Windows, even Windows 64bit has a fairly hard (for an ISV) limit of 10,000 gdi objects (should be enough for anybody) handles per process. This was leading to lots of extremely diverse symptoms - with inexplicable failure cases above the window abstraction. Thanks to Markus Morhard for adding the ability to report the number of open GDI handles to crash reports, and Kohei Yoshida (Collabora) for fixing a gratuitous consumer of these handles for 5.3.1.

Ongoing Code quality work

As always lots of work from many people

  • Coverity scan - our Coverity numbers continue to be outstanding, thanks to the hard work of Caolan McNamara with a nice round 256 commits in this release. Happily (or not) we upgraded coverity version, and found a new check - throwing up another 400 warnings just before the release.
  • cppcheck - some great cleanup work chewing through the latest cppcheck report with over 40 fixes thanks to Jochen Nitschke, Caolán McNamara (RedHat), Zolnai Tamás (Collabora), Julien Nabet and Muhammet Kara (Pardus)
  • Enum scoping - Noel Grandin (Peralex) has had 180 commits cleaning up and making consistent our very many old, inconsistent & poorly scoped enumerations.
  • unique_ptr - lots of our code uses a pImpl pattern, thanks to Xisco Fauli, David Tardon, Arnold Dumas and others for cleaning this to use the safer unique_ptr template.
  • At many places, we were using own integer types instead of standard ones due to legacy. Many of them were cleaned up previously, but there are still various outstanding uses here and there. For 5.3, many of TCHARs / _tstring, sal_uIntPtr, or sal_Size uses were changed - thanks to Stuart Swales, Marian Scerbak, Michael Stahl and others.
  • Google Fuzz - the lovely ossfuzz project is providing some great value to us thanks to Google, and also Caolan McNamara (RedHat) for getting LibreOffice integrated into their tooling.
  • Clang Plugins - with 200 commits to the compilerplugins directory this series - we gained a number of Clang plugins checking corner cases, and enabling lots of cleanups. Overall this gave nearly 800 commits to the core fixing some auto-detected badness - from a who's who of Clang users - thanks to: Stephan Bergmann (RedHat), Noel Grandin (Collabora), Miklos Vajna (Collabora), Tor Lillqvist (Collabora), Caolán McNamara (RedHat), Michael Stahl (RedHat), Markus Mohrhard, Mike Kaganski (Collabora), Kohei Yoshida (Collabora), Jochen Nitschke and others The top plugins generating commits were: passstuffbyref, expandablemethods, singlevalfields, stringconstant, countusersofdefaultparams, staticmethods, redundantcast, cppunitassertequals, constantparam, unusedmethods.
  • a script to sanity check library dependencies: check-elf-dynamic-objects was implemented - to ensure that we don't get unexpected and unhelpful new library dependencies in# release and bibisect builds on GNU/Linux thanks to Michael Stahl (RedHat)
  • Address & Undefined Behavior Sanitizers - its great to see more than sixty patches referencing ASan and UBSan - finding nasty memory issues faster.
  • Crash testing - continues across a growing suite of around 100k documents; thanks to the RedHat team for keeping the numbers consistently at or near zero.

Unit testing

As always we continue to grow our unit test count, and number of assertions (and assert calls). The tests are run by the Jenkins CI infrastructure on commits before they are merged. Thanks to so many for adding tests and stopping things from regressing particuarly those who had more than 20 commits to the unit tests: Zdeněk Crhonek, Miklos Vajna (Collabora), Stephan Bergmann (RedHat), Caolán McNamara (RedHat), Justin Luth (SIL), Eike Rathke (RedHat), Noel Grandin (Collabora), Armin Le Grand (CIB), Michael Stahl (RedHat)

And also to those with more than 10 commits to the unit tests: Tamás Zolnai (Collabora), Laurent Balland-Poirier, Tor Lillqvist (Collabora), Katarina Behrens (CIB), Markus Mohrhard, Mike Kaganski (Collabora), Takeshi Abe, Mark Hung, Giuseppe Castagno. It always takes more time to write a test, there is always a temptation not to - thank goodness they helped.

Thanks too to Michael Stahl (RedHat) for tackling a number of horrible threading races and mis-designs causing intermittent failure in our unit tests.

One notable improvement in 5.3 has been the work from Zdeněk Crhonek adding 280 or so nicely organized unit test sheets for each Calc function and some of its corner-cases to the tree, and even more encouraging to see these extended when bugs are fixed.

Another area that got a number of nice unit tests was the old-style Parser and new XFastParser implementations thanks to Mohammed Abdul Azeem laying the ground for our incremental adoption of the XFastParser for LibreOffice 5.4 for ODF formats. Great to write tests before the code.

UI Testing

Thanks to Markus Mohrhard and our generous donors we have a shiny new UI testing framework in LibreOffice 5.3. We even have tutorials ( part 1 and part 2) to help people add new tests. Checkout the code in uitest/.

It is always good to see a whole new class of testing enabled, and provides a nice place for people comfortable with python to make a really important contribution.

Online

There were really a lot of changes in the LibreOfficeKit APIs and in the online code to interface with them; these two modules are tightly coupled. For details and credits I wrote most of this up for the CODE 2.0 release, around the time of the feature freeze.

Hardware Acceleration

A number of important fixes and performance improvements made their way into 5.3 (many of which are back-ported to 5.2 as well). We have used guards - which are created and destroyed in pairs around any OpenGL block - to catch buggy & crashing drivers inside those execution blocks, in order to disable OpenGL. In 5.3 these were adapted to OpenCL as well thanks to Tomaž Vajngerl (Collabora). In addition Michael Meeks (Collabora) added a test spreadsheet that is re-calculated using OpenCL whenever the driver changes - in order to catch badness in driver implementation - somewhat sad that these are necessary; it would be hoped that just asking a (software!) OpenCL driver for its version (to see if we can black-list it) would not hard-crash, but apparently that is too much to ask. Anyhow - now we cope well with lots of sub-optimal situations, and as such removed the legacy 'Test' button for manual CL driver selection.

The VCL / OpenGL backend got a large number of performance improvements from Tomaž Vajngerl (Collabora) including batch rendering of pixels, lines, rectangles and polylines and deferred texture rendering - these help to push more work to the GPU in one go improving performance.

Miscellaneous

  • Automatic screen-shotter - one of the problems of maintaining documentation in LibreOffice is that of taking UI screenshots and keeping them up-to-date for all languages. Thanks to Katarina "bubli" Behrens (CIB), Armin Le Grand (CIB), Thorsten Beherens (CIB) and our donors - we now have an automated tool for building screenshots. Checkout the documentation.
  • Threading wins - we deprecated the grim old windows-like osl::Condition API in 5.3 in favour of the much more sensible (Unix like) std::condition_variable - which makes it easier to write safe code. Thanks to Stephan Bergmann (RedHat) for fixing a related Thread Pool thread-safety issue. Also to Kohei Yoshida (Collabora) for unwinding an underlying threading issue in our ZIP file handling hurting threaded XLSX import.
  • gtk+3/Wayland - thanks to Caolan McNamara (RedHat) we have much improved gtk+3/wayland support in 5.3, one gem is OpenGL slide transitions.
  • Improved MathML support thanks to Takeshi Abe who continues to do excellent maintenance and bug fixing work on our math component.
  • MS Office URI schemes - were added to much improve LibreOffice's integration with Windows web browsers and particularly Sharepoint for launching and editing documents thanks to Mike Kaganski (Collabora).
  • Firebird - it has been good to watch Wastack fixing lots of blocker bugs for us to be able to use the upgraded Firebird 3.0 as our default database engine in 5.4 with lots of great commits.
  • Calc dynamic columns currently we have a fixed array of columns for each sheet; thanks to Dennis Francis we are creating a nice new encapsulations to eventually change this to a more powerful, and efficient sparse data structure.
  • Thanks to Maarten Bosmans for moving rapidly from translating German comments to improving Calc style and formatting performance as well as fixing bugs.
  • Much improved Calc functions with many bug fixes and new functions thanks to Eike Rathke (RedHat), Winfried Donkers, and others.
  • Significant interoperability wins thanks to Justin Luth who has tackled over eighty nasty bugs across DOC, DOCX and other formats.
  • Android cleanups - its great to see lots and lots of code cleanups this cycle and many ongoing improvements with some great work from Aleksandar Stefanovic, Mert Tumer, Christian Lohmaier (TDF), Mirek Mazel and Otto Kekäläinen slowly making the app more polished.

QA / bugzilla

The QA team do a noble job struggling against great odds; you can see those doing the hugely valuable triage and fixing work in the QA stats for 5.3.0 wiki page. During this release cycle in August we had the pleasure of having Xisco Fauli join TDF - funded by our generous donors - to support and contribute to the QA team; their hard work together has got our UNCONFIRMED bug count way down - accelerating a vital feedback loop between users and developers.

Pootle upgrades

Pootle was upgraded this cycle bringing a wealth of improvements for our translators. From little things like allowing special characters in usernames, to major performance improvements allowing us to extract translations into our builds much more quickly. Other great features such as improved notifications with feedback on changes, off-line translation memory are much appreciated. Thanks to Dwayne Bailey (TranslateHouse) and our sysadmin team.

Updated bundled libraries

LibreOffice depends on many 3rd party libraries. To stay up-to-date, they have to be updated from time to time, their patches re-evaluated (ideally up-stream merged them) and they need re-testing. For 5.3, the following were updated:

  • boost: Removed headers that are not used any more, and many more cleanups(Michael Stahl, Stephan Bergmann)
  • libxslt: Updated, and removed some LibreOffice-specific patches (Michael Stahl)
  • libzmf: Integrated, to support import of Zoner Callisto/Draw documents (Aleksas Pantechovskis)
  • libxmlsec: Upstreamed more LibreOffice patches and updated to new version (Miklos Vajna)
  • Added or updated fonts (Akshay Deep, Andras Timar)
  • libstaroffice: Integrated library to support the old StarOffice file formats.
  • firebird: Updated to Firebird 3.0 (Wastack, Lionel Elie Mamane, Caolán McNamara)
  • harfbuzz: Updated to new version, and enabled to be built with Graphite support (Khaled Hosny)
  • libmwaw, mdds, nss, curl, poppler, cairo, pixman, openldap, redland, orcus, liblangtag, libwps, icu, libmwaw: Updated to the latest versions (David Tardon, Kohei Yoshida, Caolán McNamara, Jochen Nitschke, Michael Stahl, Jaskaran Singh, Eike Rathke)

Getting involved

Lots of fun stuff going on at LibreOffice - quite apart from the visible feature development. Its a great place to find a home and contribute. If you want to get involved there are plenty of great people to meet and work alongside - come and see us at FOSDEM for example this weekend. As you can see individuals ('Assigned') make a huge impact to the diversity of LibreOffice.

In terms of diversity of code commits, we love to see the unaffiliated volunteers contribution by volume, though clearly the volume and balance changes with the season, release cycle, and volunteers vacation / business plans:

Naturally we maintain a list of small, bite-sized tasks which you can use to get involved at our Easy Hacks page, with simple build / setup instructions. It is extremely easy to build LibreOffice, each easy-hack should have code pointers and be a nicely self contained task that is easy to solve. In addition some of them are really nice-to-have features or performance improvements. Please do consider getting stuck in with something.

Another thing that really helps is running pre-release builds and reporting bugs just grab and install a pre-release and you're ready to contribute alongside the rest of the development team.

Conclusion

LibreOffice 5.3 is great; it is made by a set of developers having fun, working together, and building an increasingly attractive and beautiful Free Software Office suite, I hope you enjoy using it. Thanks for reading, don't forget to checkout the user visible feature page and thank you for supporting LibreOffice.

Raw data and commit stats built using our gitdm-config - are available for many of the above graphs.

Marcus Lundblad: Next stop: Brussels

Planet GNOME - Mër, 01/02/2017 - 10:00md
On Friday I'm leaving for Brussels and FOSDEM!

Looking forward to be back again after missing out on last year´s incarnation and meeting familiar faces in real life once again, listening to interesting talks, both those relevant to work-related activities and personal interests, as well as general techie stuff, as I usually tend to end up at some “unexpected“ talk. Especially in the afternoon when getting a bit of fatigue and just staying around after the previous talk (which I had planned to attend) :-)

When it comes to Maps, I also have some good news. Just in time for FOSDEM I have managed to set up a temporary OpenTripPlanner server instance for the event so that people can test things out with the transit-routing branch.

The server has the base URL http://tricholoma dot update dot uu dot se:8080/otp

(replace dot with a . obviously, as I wanted to at least make it somewhat less likely for automated bots to generate extra load)

Beware that this server is not behind an HTTPS proxy (which should be the case for a real server, so that the user´s activity isn´t leaked to a potential third party).

As before, use the OTP_BASE_URL environment variable (or use a modified service file as described in an earlier post).
The server is currently loaded with transit data for the whole of Belgium.


A little screenshot showing a plausible trip from ULB to Grand Place after on Saturday afternoon.

And last, but not least I would like to thank my employer PrimeKey Solutions AB for sponsoring my trip and http://www.update.uu.se for kindly letting me run the demo server on their hardware.

Lars Wirzenius: Hacker Noir, chapter 2: Development setup phase

Planet Debian - Mër, 01/02/2017 - 12:29md

It is a new month, and time to publish the next chapter in Hacker Noir. This is chapter 2, titled "Development setup phase". I hope you enjoy it. Feedback via email, irc, identi.ca, twitter are welcome. Or come talk to me at FOSDEM if you're there.

Wouter Verhelst: Resetting a Raspberry Pi to default using Ansible

Planet Debian - Mër, 01/02/2017 - 11:19pd

I got myself a bunch of Raspberry Pi 3s a short while ago:

...the idea being that I can use those to run a few experiments on. After the experiment, I would need to be able to somehow remove the stuff that I put on them again. The most obvious way to do that is to reimage them after every experiment; but the one downside of the multi-pi cases that I've put them in is that removing the micro-SD cards from the Pis without removing them from the case, while possible, is somewhat fiddly. That, plus the fact that I cared more about price than about speed when I got the micro-SD cards makes "image all the cards of these Raspberry Pis" something I don't want to do every day.

So I needed a different way to reset them to a clean state, and I decided to use ansible to get it done. It required a bit of experimentation, but eventually I came up with this:

--- - name: install package-list fact hosts: all remote_user: root tasks: - name: install libjson-perl apt: pkg: libjson-perl state: latest - name: create ansible directory file: path: /etc/ansible state: directory - name: create facts directory file: path: /etc/ansible/facts.d state: directory - name: copy fact into ansible facts directory copy: dest: /etc/ansible/facts.d/allowclean.fact src: allowclean.fact mode: 0755 - name: remove extra stuff hosts: pis remote_user: root tasks: - apt: pkg={{ item }} state=absent purge=yes with_items: "{{ ansible_local.allowclean.cleanable_packages }}" - name: remove package facts hosts: pis remote_user: root tasks: - file: path: /etc/ansible/facts.d state: absent - apt: pkg: libjson-perl state: absent autoremove: yes purge: yes

This ansible playbook has three plays. The first play installs a custom ansible fact (written in perl) that emits a json file which defines cleanable_packages as a list of packages to remove. The second uses that fact to actually remove those packages; and the third removes the fact (and the libjson-perl library we used to produce the JSON).

Which means, really, that all the hard work is done inside the allowclean.fact file. That looks like this:

#!/usr/bin/perl use strict; use warnings; use JSON; open PACKAGES, "dpkg -l|"; my @packages; my %whitelist = ( ... ); while(<PACKAGES>) { next unless /^ii\s+(\S+)/; my $pack = $1; next if(exists($whitelist{$pack})); if($pack =~ /(.*):armhf/) { $pack = $1; } push @packages, $1; } my %hash; $hash{cleanable_packages} = \@packages; print to_json(\%hash);

Basically, we create a whitelist, and compare the output of dpkg -l against that whitelist. If a certain package is in the whitelist, then we don't add it to our "packages" list; if it isn't, we do.

The whitelist is just a list of package => 1 tuples. We just need the hash keys and don't care about the data, really; I could equally well have made it package => undef, I suppose, but whatever.

Creating the whitelist is not that hard. I did it by setting up one raspberry pi to the minimum that I wanted, running

dpkg -l|awk '/^ii/{print "\t\""$2"\" => 1,"}' > packagelist

and then adding the contents of that packagelist file in place of the ... in the above perl script.

Now whenever we apply the ansible playbook above, all packages (except for those in the whitelist) are removed from the system.

Doing the same for things like users and files is left as an exercise to the reader.

Side note: ... is a valid perl construct. You can write it, and the compiler won't complain. You can't run it, though.

Daniel Pocock: Going to FOSDEM, Brussels this weekend

Planet UBUNTU - Mër, 01/02/2017 - 10:07pd

This weekend I'm going to FOSDEM, one of the largest gatherings of free software developers in the world. It is an extraordinary event, also preceded by the XSF / XMPP Summit

For those who haven't been to FOSDEM before and haven't yet made travel plans, it is not too late. FOSDEM is a free event and no registration is required. Many Brussels hotels don't get a lot of bookings on weekends during the winter so there are plenty of last minute offers available, often cheaper than what is available on AirBNB. I was speaking to somebody in London on Sunday who commutes through St Pancras (the Eurostar terminal) every day and didn't realize it goes to Brussels and only takes 2 hours to get there. One year I booked a mini-van at the last minute and made the drive from the UK with a stop in Lille for dinner on the way back, for 5 people that was a lot cheaper than the train. In other years I've taken trains from Switzerland through Paris or Luxembourg.

Real-time Communication (RTC) dev-room on Saturday, 4 February

On Saturday, we have a series of 23 talks about RTC topics in the RTC dev-room, including SIP, XMPP, WebRTC, peer-to-peer (with Ring) and presentations from previous GSoC students and developers coming from far and wide.

The possibilities of RTC with free software will also be demonstrated and discussed at the RTC lounge in the K building, near the dev-room, over both Saturday and Sunday. Please come and say hello.

Please come and subscribe to the Free-RTC-Announce mailing list for important announcements on the RTC theme and join the Free-RTC discussion list if you have any questions about the activities at FOSDEM, dinners for RTC developers on Saturday night or RTC in general.

Software Defined Radio (SDR) and the Debian Hams project

At 11:30 on Saturday I'll be over at the SDR dev-room to meet other developers of SDR projects such as GNU Radio and give a brief talk about the Debian Hams project and the relationship between our diverse communities. Debian Hams (also on the Debian Ham wiki) provides a ready-to-run solution for ham radio and SDR is just one of its many capabilities.

If you've ever wondered about trying the RTL-SDR dongle or similar projects Debian Hams provides a great way to get started quickly.

I've previously given talks on this topic at the Vienna and Cambridge mini-DebConfs (video).

Ham Radio (also known as amateur radio) offers the possibility to gain exposure to every aspect of technology from the physical antennas and power systems through to software for a range of analog and digital communications purposes. Ham Radio and the huge community around it is a great fit with the principles and philosophy of free software development. In a world where hardware vendors are constantly exploring ways to limit their users with closed and proprietary architectures, such as DRM, a broad-based awareness of the entire technology stack empowers society to remain in control of the technology we are increasingly coming to depend on in our every day lives.

Daniel Pocock: Going to FOSDEM, Brussels this weekend

Planet Debian - Mër, 01/02/2017 - 10:07pd

This weekend I'm going to FOSDEM, one of the largest gatherings of free software developers in the world. It is an extraordinary event, also preceded by the XSF / XMPP Summit

For those who haven't been to FOSDEM before and haven't yet made travel plans, it is not too late. FOSDEM is a free event and no registration is required. Many Brussels hotels don't get a lot of bookings on weekends during the winter so there are plenty of last minute offers available, often cheaper than what is available on AirBNB. I was speaking to somebody in London on Sunday who commutes through St Pancras (the Eurostar terminal) every day and didn't realize it goes to Brussels and only takes 2 hours to get there. One year I booked a mini-van at the last minute and made the drive from the UK with a stop in Lille for dinner on the way back, for 5 people that was a lot cheaper than the train. In other years I've taken trains from Switzerland through Paris or Luxembourg.

Real-time Communication (RTC) dev-room on Saturday, 4 February

On Saturday, we have a series of 23 talks about RTC topics in the RTC dev-room, including SIP, XMPP, WebRTC, peer-to-peer (with Ring) and presentations from previous GSoC students and developers coming from far and wide.

The possibilities of RTC with free software will also be demonstrated and discussed at the RTC lounge in the K building, near the dev-room, over both Saturday and Sunday. Please come and say hello.

Please come and subscribe to the Free-RTC-Announce mailing list for important announcements on the RTC theme and join the Free-RTC discussion list if you have any questions about the activities at FOSDEM, dinners for RTC developers on Saturday night or RTC in general.

Software Defined Radio (SDR) and the Debian Hams project

At 11:30 on Saturday I'll be over at the SDR dev-room to meet other developers of SDR projects such as GNU Radio and give a brief talk about the Debian Hams project and the relationship between our diverse communities. Debian Hams (also on the Debian Ham wiki) provides a ready-to-run solution for ham radio and SDR is just one of its many capabilities.

If you've ever wondered about trying the RTL-SDR dongle or similar projects Debian Hams provides a great way to get started quickly.

I've previously given talks on this topic at the Vienna and Cambridge mini-DebConfs (video).

Ham Radio (also known as amateur radio) offers the possibility to gain exposure to every aspect of technology from the physical antennas and power systems through to software for a range of analog and digital communications purposes. Ham Radio and the huge community around it is a great fit with the principles and philosophy of free software development. In a world where hardware vendors are constantly exploring ways to limit their users with closed and proprietary architectures, such as DRM, a broad-based awareness of the entire technology stack empowers society to remain in control of the technology we are increasingly coming to depend on in our every day lives.

Russ Allbery: Review: A Closed and Common Orbit

Planet Debian - Mër, 01/02/2017 - 6:24pd

Review: A Closed and Common Orbit, by Becky Chambers

Series: Wayfarers #2 Publisher: Harper Voyager Copyright: October 2016 ISBN: 0-06-256942-2 Format: Kindle Pages: 384

A Closed and Common Orbit has two threads, one that takes place twenty years in the past and one that happens simultaneously with the very end of The Long Way to a Small, Angry Planet. That second part is the motivating plot thread, but it's unfortunately impossible to talk about in any depth without seriously spoiling the previous book. You could otherwise read them out of order, but I think the previous book is too good to spoil, so you want to carefully avoid reading any descriptions of this book until after you've read The Long Way to a Small, Angry Planet.

Per my normal review policy, I'm going to try to avoid spoilers, but just about everything about half of this book would give away spoilers if you're paying attention. So you may want to just go read the other book before reading this review. (It's excellent!)

The part that I can safely say is that half this book is about Pepper, her partner Blue, Pepper's store and Blue's art, and her attempt to help a friend find a place and a sense of identity that she'd never asked for or expected, while keeping a very dangerous secret. That friend starts somewhat passive, but one of the things I liked the most about this story is that Pepper is neither always right in her advice nor always wrong. Sidra is wrong about some of the limitations that she thinks she has and some of the things she thinks she wants, but she's also right about other things where Pepper is wrong. She has a complicated, careful, and courageous journey.

The best part of this book for me, though, was the other half, told in alternating chapters with Sidra's story. This is Pepper's own backstory, which is rather awful (although Chambers does avoid being too graphic about the most horrible parts), but is also an amazing story of someone finding her own power, her own skills, and her own identity. And building a relationship that's something quite special. At first, this seems only vaguely related to Sidra's story and the other half of the book, but they both come together in a way that's both heartbreaking and wonderful.

I found this story particularly wonderful because one of my favorite SF tropes is sentient computers or sentient ships, which play a significant role in Pepper's backstory. And one of my favorite characters to read about is the technician who can cobble together fixes to things and who is always finding something to repair. Pepper is a delight, her story explains so much about how she became the person she is (and adds so much emotional heft to it), and she has a relentless, practical determination that I loved reading about.

A Closed and Common Orbit doesn't have the sprawling cast of The Long Way to a Small, Angry Planet. The story is tightly focused on five characters. I think I liked that even better than the previous book, even when I was finding Sidra a bit too passive and not as interesting. Chambers's characters have so much depth, thoughtfulness, and basic decency, while still being uniquely themselves, that I feel like I could read about them for months and keep uncovering new, interesting facets. I particularly loved the occasional excerpts from the chat system where Pepper hangs out (and would have loved about three times more of them). Speaking as someone who spends a lot of time in chat, Chambers got the tone just about perfect.

Just about the only complaint I have about this book is that I thought the ending was too abrupt. It's so important, the climax of Pepper's story and a hugely significant piece of character development, and I wanted more than the short scene and aftermath we got. I really wanted to spend some time feeling with the characters, savoring the emotional release. Another three or four pages would have been greatly appreciated.

The Long Way to a Small, Angry Planet was a happy surprise in 2015. A Closed and Common Orbit is fully as good, if not better. If you liked the previous book, you will definitely want to read this. I pre-ordered it and then read it within months after it was released, something that I almost never do. I can hardly wait to read whatever Chambers writes next.

Rating: 9 out of 10

Peter Hutterer: libinput and lid switch events

Planet GNOME - Mër, 01/02/2017 - 5:51pd

I merged a patchset from James Ye today to add support for switch events to libinput, specifically: lid switch events. This feature is scheduled for libinput 1.7.

First, what are switches and how are they different so keys? A key's state is transient with a neutral state of "key is up". The state itself is expected to change frequently. Switches don't always have a defined logical neutral state and the state changes only infrequently. This requires different handling in applications and thus libinput exposes a new interface (and capability) for switches.

The interface itself is trivial. A switch event has two properties, the switch type (e.g. "lid") and the switch state (on/off). See the libinput-debug-events source code for a simple code to print the state and type.

In libinput, we generally try to restrict ourselves to the cases we know how to handle. So in the first iteration, we'll support a single switch event: the lid switch. This is the toggle that changes when you close the lid on your laptop.

But libinput uses this internally too: touchpads are disabled automatically whenever the lid is closed. Indeed, this functionally was the main motivation for this patchset. On a number of devices, we get ghost touches when the lid is closed. Even though the touchpad is unreachable by the user interference with the screen still causes events, moving the pointer in unexpected ways and generally being a nuisance. Some trackpoints suffer from the same issue. But now that libinput knows about the lid switch it can transparently disable the touchpad whenever the lid is closed and thus discard the events.

Lid switches on some devices are unreliable. There are some devices where the lid is permanently closed and other devices where the lid can be closed, but we'll never see the open event. So we change behaviour based on a few factors. After all, no-one likes a dysfunctional touchpad because the lid switch is broken (if you do, seek help). For one, whenever we detect keyboard events while in logically closed state we'll assume that the lid is open after all and adjust state accordingly. Unless the lid switch is reliable, we don't sync the initial state. That's annoying for those who start libinput in closed mode, but it filters out all devices that set the lid switch to "on" and then never change again. On the Surface 3 devices we go even further: we know those devices needs a bit of hand-holding. So whenever we detect activity on the keyboard, we also write the EV_SW/SW_LID state to the device node, thus updating the kernel to be correct again (and thus help everyone else who may be listening).

The exact behaviours will likely change slightly over time as we have to deal with corner-cases one-by-one. But meanwhile, it's even easier for compositors to listen to switch events and users don't have to deal with ghost touches anymore. Many thanks to James Ye for implementing this.

Hideki Yamane: How to check your package for FTBFS with clang

Planet Debian - Mër, 01/02/2017 - 4:04pd
GCC 7 doesn't go into Debian9, but gcc maintainers now file FTBFS bugs for it.

Also you can check packages via building with clang easily. I've already prepared pbuilder (and cowbuilder) build hook script for it. So, if you want to check a package with clang 4.0,

$ mkdir ~/hookdir$ ln -s /usr/share/doc/pbuilder/examples/D65various-compiler-support ~/pbuilder-hookdir(modify your pbuilderrc as adding 1 line like below)
HOOKDIR=/home/henrich/pbuilder-hookdir$ sudo CHOOSE_COMPILER="clang-4.0" cowbuilder --build yourpackage_1.0-1.dsc
That's all - it's handy, isn't it? Please try it to make your package more healthy :)

Antoine Beaupré: Testing new hardware with Stressant

Planet Debian - Mër, 01/02/2017 - 1:36pd

I got a new computer and wondered... How can I test it? One of those innocent questions that brings hours and hours of work and questionning...

A new desktop: Intel NUC devices

After reading up on Jeff Atwood's blog and especially his article on the scooter computer, I have discovered a whole range of small computers that could answer my need for a faster machine in my office at a low price tag and without taking up too much of my precious desk space. After what now seems like a too short review I ended up buying a new Intel NUC device from NCIX.com, along with 16GB of RAM and an amazing 500GB M.2 hard drive for around 750$. I am very happy with the machine. It's very quiet and takes up zero space on my desk as I was able to screw it to the back of my screen. You can see my review of the hardware compatibility and installation report in the Debian wiki.

I wish I had taken more time to review the possible alternatives - for example I found out about the amazing Airtop PC recently and, although that specific brand is a bit too expensive, the space of small computers is far and wide and deserves a more thorough review than just finding the NUC by accident while shopping for laptops on System76.com...

Reviving the Stressant project

But this, and Atwood's Is Your Computer Stable? article, got me thinking about how to test new computers. It's one thing to build a machine and fire it up, but how do you know everything is actually really working? It is common practice to do a basic stress test or burn-in when you get a new machine in the industry - how do you proceed with such tests?

Back in the days when I was working at Koumbit, I wrote a tool exactly for that purpose called Stressant. Since I am the main author of the project and I didn't see much activity on it since I left, I felt it would be a good idea to bring it under my personal wing again, and I have therefore moved it to my Gitlab where I hope to bring it back to life. Parts of the project's rationale are explained in an "Intent To Package" the "breakin" tool (Debian bug #707178), which, after closer examination, ended up turning into a complete rewrite.

The homepage has a bit more information about how the tool works and its objectives, but generally, the idea is to have a live CD or USB stick that you can just plugin into a machine to run a battery of automated tests (memtest86, bonnie++, stress-ng and disk wiping, for example) or allow for interactive rescue missions on broken machines. At Koumbit, we had Debirf-based live images that we could boot off the network fairly easily that we would use for various purposes, although nothing was automated yet. The tool is based on Debian, but since it starts from boot, it should be runnable on any computer.

I was able to bring the project back to life, to a certain extent, by switching to vmdebootstrap instead of debirf for builds, but that removed netboot support. Also, I hope that Gitlab could provide with an autobuilder for the images, but unfortunately there's a bug in Docker that makes it impossible to mount loop images in Docker images (which makes it impossible to build Docker in Docker, apparently).

Should I start yet another project?

So there's still a lot of work to do in this project to get it off the ground. I am still a bit hesitant in getting into this, however, for a few reasons:

  1. It's yet another volunteer job - which I am trying to reduce for health and obvious economic reasons. That's a purely personal reason and there isn't much you can do about it.

  2. I am not sure the project is useful. It's one thing to build a tool that can do basic tests on a machine - I can probably just build an live image for myself that will do everything I need - it's another completely different thing to build something that will scale to multiple machines and be useful for more various use cases and users.

(A variation of #1 is how everything and everyone is moving to the cloud. It's become a common argument that you shouldn't run your own metal these days, and we seem to be fighting an uphill economic battle when we run our own datacenters, rack or even physical servers these days. I still think it's essential to have some connexion to metal to be autonomous in our communications, but I'm worried that focusing on such a project is another of my precious dead entreprises... )

Part #2 is obviously where you people come in. Here's a few questions I'd like to have feedback on:

  1. (How) do you perform stress-testing of your machines before putting them in production (or when you find issues you suspect to be hardware-related)?

  2. Would a tool like breakin or stressant be useful in your environment?

  3. Which tools do you use now for such purposes?

  4. Would you contribute to such a project? How?

  5. Do you think there is room for such a project in the existing ecology of projects) or should I contribute to an existing project?

Any feedback here would be, of course, greatly appreciated.

Faqet

Subscribe to AlbLinux agreguesi - Site në gjuhë të huaj