Jekyll2020-11-08T13:28:26-05:00https://www.purinchu.net/wp/feed/feed.xmlMichael Pyne’s personal blogMichael Pyne's personal blogMichael Pynekdesrc-build updated for Gitlab Migration2020-05-17T00:00:00-04:002020-05-17T00:00:00-04:00https://www.purinchu.net/wp/kdesrc-build/kde/2020/05/17/kdesrc-build-for-gitlab<p>This weekend the KDE Sysadmins completed the migration of KDE git modules to
our Gitlab-based source code management stack as discussed for months now, and
recently <a href="https://mail.kde.org/pipermail/kde-cvs-announce/2020/000198.html">posted to
kde-cvs-announce</a>
as a final reminder.</p>
<p>While we did some work in kdesrc-build to set the stage for support for the migration,
there were a few changes still necessary to adapt to the new KDE project directory
scheme.</p>
<p>kdesrc-build has made those changes this weekend and should be able to handle
the Gitlab-based KDE git modules.</p>
<p>However you will likely need to manually update kdesrc-build and then kdesrc-build will
be able to handle the rest.</p>
<p>The easiest way to do this is to navigate to the kdesrc-build source directory (where
you initially cloned it from git) and ensure that the kdesrc-build <code class="language-plaintext highlighter-rouge">origin</code> is
properly configured.</p>
<p>If you use the default recommended paths from the <a href="https://community.kde.org/Get_Involved/development">Get Involved with
Development</a> page then you can make this
happen by following these commands:</p>
<div class="language-sh highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">cd</span> ~/kde/src/kdesrc-build
git remote set-url <span class="nt">--push</span> origin git@invent.kde.org:sdk/kdesrc-build.git
git remote set-url origin https://invent.kde.org/sdk/kdesrc-build.git
git pull
</code></pre></div></div>
<p><strong>IMPORTANT</strong> The <code class="language-plaintext highlighter-rouge">git remote set-url --push</code> command uses a <strong>:</strong> where the
other <code class="language-plaintext highlighter-rouge">set-url</code> command uses a <strong>/</strong> to separate “invent.kde.org” from the
“sdk/…” part. If you decide to type this in instead of copy-pasting then be
careful of that.</p>
<p>From there, kdesrc-build will be configured to read from the new Gitlab-based
git modules. When it next runs, it will update any existing <code class="language-plaintext highlighter-rouge">kde:</code> git config
prefixes to point to <code class="language-plaintext highlighter-rouge">invent.kde.org</code> as appropriate, and also update the
<code class="language-plaintext highlighter-rouge">git-remote</code> settings for KDE modules automatically since some modules are now
found in different locations (e.g. kdesrc-build itself moved from
‘extragear/utils/kdesrc-build.git’ to ‘sdk/kdesrc-build.git’)</p>
<p>If for whatever reason kdesrc-build ends up staying wedged, the easiest way to
resolve is probably just to delete the kdesrc-build install (<em>NOTE</em> do not
delete any existing kdesrc-buildrc configuration files you may have) and clone
it again using the instructions at the <a href="https://community.kde.org/Get_Involved/development">Get Involved with
Development</a> page.</p>
<p>I hope this helps you all to update your KDE git modules as seamlessly as
possible. This should free you of the need to manually run git kclone or git
kpull porting aids. As always if you run into bugs please let us know on IRC,
on the mailing list or at bugs.kde.org!</p>mpyneThis weekend the KDE Sysadmins completed the migration of KDE git modules to our Gitlab-based source code management stack as discussed for months now, and recently posted to kde-cvs-announce as a final reminder.Moved to Jekyll2018-12-15T00:00:00-05:002018-12-15T00:00:00-05:00https://www.purinchu.net/wp/jekyll/personal/2018/12/15/moved-to-jekyll<p>If you can see this, that means that the migration of my blog to
<a href="https://jekyllrb.com/">Jekyll</a> should be complete. Yay!</p>
<p>WordPress was actually quite good to me and quite easy to maintain and use. As
uncomplicated as the Jekyll approach is, aided by its usage of convention to
just do the smart thing, there’s still a fair bit of setup and playing around
you need to do to get Jekyll sorted out.</p>
<p>But I have to admit I feel better about being able to maintain a less dynamic
server footprint to be able to serve up my blog, especially since it’s so
completely low-traffic now.</p>
<p>The theme here is <a href="https://mmistakes.github.io/jekyll-theme-basically-basic/">Basically
Basic</a>, as installed
as a Ruby Gem. I’ve disabled the fancy fonts and analytics (all I could find at
least).</p>
<p>I’ve tried to ensure all the old URLs don’t break, and even fixed up some stray
conversion issues that had come from my last attempt to migrate to WordPress
years ago. The RSS feed is now an Atom feed though (hope that doesn’t break
your reader).</p>mpyneIf you can see this, that means that the migration of my blog to Jekyll should be complete. Yay!Akademy retrospective2018-08-19T09:08:25-04:002018-08-19T09:08:25-04:00https://www.purinchu.net/wp/2018/08/19/akademy-retrospective<p>I had an amazing time with the KDE community in Vienna this past week at <a href="https://akademy.kde.org/2018/">Akademy</a>. In fact it was my first Akademy despite contributing to KDE for so long, but Vienna was a great reason to make my first trip to Europe.</p>
<div id="attachment_860" style="width: 235px" class="wp-caption aligncenter">
<a href="https://www.purinchu.net/wp/wp-content/uploads/2018/08/yellow-submarine.jpg"><img class="size-medium wp-image-860" src="https://www.purinchu.net/wp/wp-content/uploads/2018/08/yellow-submarine-225x300.jpg" alt="selfie of mpyne in front of an ad for a yellow submarine" width="225" height="300" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/08/yellow-submarine-225x300.jpg 225w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/yellow-submarine-768x1024.jpg 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/yellow-submarine-624x832.jpg 624w" sizes="(max-width: 225px) 100vw, 225px" /></a>
<p class="wp-caption-text">
It's like Vienna knew I was coming over
</p>
</div>
<p>It was nice to experience in person many of the things I read about from previous Akademies. There were the talks, meeting up with friends, the late-night hacking, showing others the work I’ve done. I even got to participate in impromptu collaborations such as taking Helio’s Qt1 port to CMake and <a href="http://www.heliocastro.info/?p=328">building and running it on the Windows Subsystem for Linux</a> within minutes of his announcement of the release.</p>
<p>I also got a reminder again of the importance of open source and making the work we do available to the wider community at the <a href="https://conf.kde.org/en/Akademy2018/public/events/67">postmarketOS talk on day 2</a> of the talks, where the presenter noted how their effort to port a real Linux (as opposed to something like AOSP) to mobile form factors with a good GUI ran into some roadblocks related to their use of Alpine Linux (which uses musl libc), but <a href="https://postmarketos.org/blog/2017/09/03/100-days-of-postmarketos/#plasma-mobile-kdes-plasma-desktop-for-phones">managed to overcome those roadblocks more quickly</a> thanks in part to some patches I’d written a year ago for musl support. This helped get them closer to running Plasma Mobile on platforms like the original Nexus.</p>
<p>This talk was the first I’d heard of this, and this platform wasn’t the reason I’d pushed to get KF5 to compile on Alpine, but then that’s the beauty of open source — people will do amazing things with even the smallest contributions you make, if only you get those contributions out there.</p>
<h2 id="improving-the-onboarding-experience">Improving the onboarding experience</h2>
<p>A big theme of this Akademy was improving our ability to onboard new contributors, whether that’s testers, artists, bug triagers, designers, and developers, which is one of our <a href="https://dot.kde.org/2017/11/30/kdes-goals-2018-and-beyond">major goals as a community</a>. We need help everywhere, and this focus was reflected in many of the “Birds of a Feather” (BoF) sessions we conducted.</p>
<h3 id="improving-kdesrc-build">Improving kdesrc-build</h3>
<p>I led a BoF on this topic for kdesrc-build and participated in a few others as well. There’s a lot out there that we can do to improve our story here, in kdesrc-build and elsewhere, and I’m hopeful we can accomplish real improvement here over the next year. But it was also nice to see and hear a lot of the positive feedback our developers had about kdesrc-build.</p>
<div id="attachment_859" style="width: 310px" class="wp-caption alignleft">
<a href="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points.jpg"><img class="size-medium wp-image-859" src="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points-300x225.jpg" alt="A blackboard listing some user complaints about kdesrc-build" width="300" height="225" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points-300x225.jpg 300w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points-768x576.jpg 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points-1024x768.jpg 1024w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-pain-points-624x468.jpg 624w" sizes="(max-width: 300px) 100vw, 300px" /></a>
<p class="wp-caption-text">
Pain points from the kdesrc-build BoF
</p>
</div>
<div id="attachment_858" style="width: 310px" class="wp-caption alignright">
<a href="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements.jpg"><img class="wp-image-858 size-medium" src="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements-300x225.jpg" alt="A blackboard listing some suggested improvements for kdesrc-build" width="300" height="225" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements-300x225.jpg 300w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements-768x576.jpg 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements-1024x768.jpg 1024w, https://www.purinchu.net/wp/wp-content/uploads/2018/08/kdesrc-build-improvements-624x468.jpg 624w" sizes="(max-width: 300px) 100vw, 300px" /></a>
<p class="wp-caption-text">
Suggested improvements from the kdesrc-build BoF (some less serious than others…)
</p>
</div>
<p><br clear="all" />At that BoF, Dominik Haumann also demonstrated a mockup for GUI he’s been working on that, in association with the <a href="https://www.purinchu.net/wp/2018/04/14/fancy-status-updating-in-kdesrc-build/">work I’ve been doing to add support for APIs</a> in kdesrc-build to communicate to external processes, would make it easier to use kdesrc-build. More to follow on that, but I’m excited for it.</p>
<h3 id="other-options-for-onboarding">Other options for onboarding</h3>
<p>Also, there was acknowledgment during the week that kdesrc-build is not the best method to get access to bleeding-edge KDE software for all the types of new users.</p>
<p>That’s OK — I agree myself, and if anything it would be surprising for a command-line script to manage to be all things to all people.</p>
<p>So we talked during the week about other options for getting people access to more recent builds of KDE software (Plasma, the Frameworks, Applications, etc.). These options could include:</p>
<ul>
<li>Using virtual machines like KDE Neon’s <a href="https://neon.kde.org/develop">Developer Edition</a> (recommended by Nate Graham)</li>
<li><a href="https://flatpak.org/">Flatpaks</a> or <a href="https://snapcraft.io/">Snaps</a> for nightly builds</li>
<li><a href="https://conan.io/">Conan.io</a> C++ binary packages</li>
<li>Container-based solutions (e.g. being able to “docker pull” a kdesrc-build-based image based off a standard Linux-based docker image and which automatically gets you all the way to a working install without extra effort on your part)</li>
</ul>
<p>There’s pros and cons to all of these. I don’t expect kdesrc-build would go away — our developers need some way to build our software on their own, but many of these would be much easier for power users to test on, or for application developers to use to just get the latest Frameworks easily.</p>
<h2 id="closing-thoughts">Closing Thoughts</h2>
<p>All in all, Akademy was an amazing experience, it more than met up to the reputation it had built in my head from seeing things from the outside here. It’s never too late to attend either, so don’t let missing a few like I did keep you from going to your first!</p>
<p>The team that hosted Akademy did an <strong>amazing</strong> job in organizing. These types of events offer every opportunity for “Murphy’s Law” to strike, but you’d never have noticed from my perspective as a participant — everything simply happened smoothly. I was especially impressed with the extracurriculars like the day trip to the <a href="https://en.wikipedia.org/wiki/Kahlenberg">Kahlenburg</a>, and the sightseeing tour of Vienna hosted by the local team (the tour was so good you’d never have believed it was organized nearly at the last minute in response to the high interest we showed).</p>
<p>Now, it’s time to dive into all the “TODOs” I’d collected from just a week of in-person engagement with the Community, until the next time I can come back!</p>mpyneI had an amazing time with the KDE community in Vienna this past week at Akademy. In fact it was my first Akademy despite contributing to KDE for so long, but Vienna was a great reason to make my first trip to Europe.Going to Akademy2018-07-20T13:46:04-04:002018-07-20T13:46:04-04:00https://www.purinchu.net/wp/2018/07/20/going-to-akademy<p>Happy to participate in a tradition I’ve admired from afar but never been able to do myself… until this year. My tickets are bought, my passport is issued, and <a href="https://akademy.kde.org/2018">I’m going to Akademy</a>! Hope to see you all there!</p>
<div id="attachment_853" style="width: 850px" class="wp-caption aligncenter">
<a href="https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner.jpg"><img class="size-full wp-image-853" src="https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner.jpg" alt="" width="840" height="206" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner.jpg 840w, https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner-300x74.jpg 300w, https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner-768x188.jpg 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/07/Akademy2018_banner-624x153.jpg 624w" sizes="(max-width: 840px) 100vw, 840px" /></a>
<p class="wp-caption-text">
I'm going to Akademy!
</p>
</div>mpyneHappy to participate in a tradition I’ve admired from afar but never been able to do myself… until this year. My tickets are bought, my passport is issued, and I’m going to Akademy! Hope to see you all there!Fancy status updating in kdesrc-build2018-04-13T20:50:07-04:002018-04-13T20:50:07-04:00https://www.purinchu.net/wp/2018/04/14/fancy-status-updating-in-kdesrc-build<h1 id="new-interfaces-for-kdesrc-build">New Interfaces for kdesrc-build</h1>
<p>A few weeks back, a fellow KDE developer asked me in the IRC development channel whether I had thought about adding a GUI for kdesrc-build, to supplement (or even replace) the existing text-based interface.</p>
<p>In fact, I’ve been thinking about how to improve the interface for some time. I’ve long thought that the existing console interface is very wordy, and while that’s led to some very minor streamlining and internal code changes to prepare for a quieter future, the codebase would seemingly not make improvements here very easy.</p>
<p>We discussed in IRC whether it might be simpler to do something like <a href="https://blog.kitware.com/cmake-e-server-improves-visual-studio-and-qt-creator-ides/">CMake’s server feature</a> for kdesrc-build, where kdesrc-build would export a simple REST-style API while it was running. However it was difficult enough to permit kdesrc-build to run update and build processes at the same time, so expanding the existing codebase to also support being an HTTP server would probably have been quite difficult, especially since I actively try to avoid too many non-core Perl dependencies. Maintaining a custom environment for KDE-based software is hard enough without making our users also become proficient at maintaining a full-fat Perl distribution.</p>
<h1 id="kdesrc-build-its-web-scaletm">kdesrc-build: it’s Web Scale(TM)</h1>
<p>This would normally leave a dilemma of how to add the capability kdesrc-build would need without requiring a great deal of extra dependencies or invasive surgery. But I think I’ve found a solution, using (of all things) a web framework, called <a href="http://mojolicious.org/">Mojolicious</a>. It is Perl-based and can be installed without any additional non-core Perl dependencies, and perhaps more importantly, it is quite svelte for all the capability it delivers, which means we can use it without worrying about a large performance impact. In fact my perception has been that some things have sped up after being replaced with Mojolicious counterparts.</p>
<p>The result of a good deal of code refactoring can be seen below.</p>
<div id="attachment_844" style="width: 970px" class="wp-caption aligncenter">
<a href="https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm.png"><img class="size-full wp-image-844" src="https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm.png" alt="" width="960" height="540" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm.png 960w, https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm-300x169.png 300w, https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm-768x432.png 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/04/kdesrc-build-status-server-sm-624x351.png 624w" sizes="(max-width: 960px) 100vw, 960px" /></a>
<p class="wp-caption-text">
kdesrc-build status being published to a browser session
</p>
</div>
<p>The konsole session on the right is the normal kdesrc-build output you know and love, running from the kdesrc-build <code class="language-plaintext highlighter-rouge">make_it_mojo</code> git branch. On the left is a Chrome browser tab pointing to an HTTP port on localhost.</p>
<p>The web page shown in that tab was served up by kdesrc-build, handled by Mojolicious even as Mojolicious was helping to take care of the asynchronous updates and build processes.</p>
<p>Within the web page, the table shown is updated dynamically using a WebSocket connection back to kdesrc-build. It’s harder to see without animation, but as each build completed, the appropriate table cell was updated, and background changed to green (for success) or red (for error). The effect is even more impressive when performing source code updates like normal, as you can visually see how fast source code updates are completed even as the first builds are underway.</p>
<p>When the build finished, a “Build complete” entry was listed at the top. All of this is still quite ugly, of course, but it’s worked well in my testing.</p>
<p>Getting to this point has required quite a bit of work: I have 37 commits in <code class="language-plaintext highlighter-rouge">make_it_mojo</code> alone since it was branched off, encompassing:</p>
<ul>
<li>The introduction of Mojolicious,</li>
<li>Porting from my custom multiprocess IPC handling code to Mojolicious, using Mojolicious’s support for running blocking code in subprocesses to be able to slowly add new changes in,</li>
<li>Restructuring the update/build process to use promises (Mojolicious supports the same concept for promises as used in JavaScript, though without support for async/await keywords).</li>
<li>Adding the HTTP server,</li>
<li>Making it work with WebSockets,</li>
<li>Adding the web page</li>
<li>And of course all the little bugs on the way…</li>
</ul>
<h1 id="trying-it-yourself">Trying it Yourself</h1>
<p>To try it yourself (and I’m hoping to get some testing here!), you would first need to install Mojolicious. It seems to be <code class="language-plaintext highlighter-rouge">libmojolicious-perl</code> on Debian/Ubuntu, and <code class="language-plaintext highlighter-rouge">perl-Mojolicious</code> in Fedora or <a href="https://software.opensuse.org/download.html?project=devel%3Alanguages%3Aperl&package=perl-Mojolicious">openSUSE</a>. Or if you’re familiar with Perl’s CPAN, it’s just a matter of installing the “Mojolicious” distribution.</p>
<p>From there you’d run <code class="language-plaintext highlighter-rouge">git checkout origin/make_it_mojo</code> within the kdesrc-build source directory, and then run kdesrc-build as normal, from where you normally run it. Assuming everything turns on, you should be able to run <code class="language-plaintext highlighter-rouge">kdesrc-build --launch-browser</code> in a separate terminal window to open your preferred browser to whatever dynamic port the kdesrc-build web server ended up being pointed to, and hopefully watch a bunch of boxes start turning green.</p>
<h1 id="next-steps">Next Steps</h1>
<p>As I continue this I will be interested to hear feedback on how I should take this. I have a prototype Qt app that I was working on, though now that I’ve got WebSockets working I’ll probably shift to use QML once I pick it up again.</p>
<p>Clearly there’s still a lot of work left to do, such as sending important status messages across, hyperlinks to log files (for build failures), statistics on update/build time, perhaps even a dependency explorer. At least the framework is in place for this now, and I think this is the kind of thing that would benefit from hearing from the users before I go too far in one direction. How should this evolve? What would help you all the most?</p>mpyneNew Interfaces for kdesrc-buildDebugging issues booting a PC in 20182018-03-11T14:05:42-04:002018-03-11T14:05:42-04:00https://www.purinchu.net/wp/2018/03/11/debugging-issues-booting-a-pc-in-2018<p>I figured out a solution to a hardware troubleshooting problem I’ve had going off and on for at least a couple of years. I feel like others might run across it and, not knowing anywhere better to note it, suppose I might as well dump it on my blog and hope search engines can make it available to those who need it.</p>
<p>Anyways, the problem is that sometimes my computer wouldn’t boot. Particularly after power outages (in retrospect, clue 1). Sometimes resetting the CMOS would work. Sometimes resetting CMOS wouldn’t work but pulling various cards / memory modules around and reseating them would work.</p>
<p>Once when I encountered this issue, I discovered that plugging in my monitor using HDMI instead of DisplayPort worked (clue 2). This, however, lead to a separate problem which took me months to figure out (HDMI only supports 30 fps on my monitor’s native resolution, an issue fixed an a later rev of my monitor’s hardware).<!--more--></p>
<p>When the issue recently started to recur (after a weather-related power outage), I discovered that plugging in an alternate GPU (an incredibly cheap emergency backup discrete unit I have) also worked. This one only had HDMI but it couldn’t drive native resolution anyways, so at least I didn’t have to worry about 30fps.</p>
<p>The issue had gotten significantly worse when I upgraded my CPU and motherboard a year ago, so I spent weeks thinking that my GPU simply didn’t work well with the new CPU/motherboard and that it was time to find a different GPU.</p>
<p>The new GPU recently showed up and had the exact same problem as the previous one (oops). Everything finally dawned on me when I tried the HDMI output on the off chance that it wouldn’t be also affected by the 30fps issue (it was, but at least the computer booted!).</p>
<p>It turned out that the problem was my monitor this whole time. I went with a full power cycle to my computer probably dozens of time in the course of debugging this issue. But I didn’t power cycle my monitor once… doing so fixed my issue fully.</p>
<p>I guess I’ve been thinking that monitors are still “dumb”, that they just show pixels coming in over the wire. But that is no longer the case, hasn’t been for years, and so if you’re having issues that you think are GPU issues, don’t forget to do the “turn it off and then back on again” routine with your monitor as well!</p>
<p>In my case, what I think the issue was, is that the monitor had its display connection state corrupted slightly (whether due to power cycling or something else), and that the GPU was unable to complete a valid connection to the monitor during computer boot. Without a GPU in a valid state to drive a display, the motherboard would apparently abort the boot process (it had a GPU debug LED lit up, which I couldn’t figure out the cause of since the GPU always worked fine if I could get the computer to boot).</p>
<p>I could never find this problem described in any of my searches, but hopefully this will help someone else if they encounter something similar.</p>mpyneI figured out a solution to a hardware troubleshooting problem I’ve had going off and on for at least a couple of years. I feel like others might run across it and, not knowing anywhere better to note it, suppose I might as well dump it on my blog and hope search engines can make it available to those who need it.Animated Plasma Wallpaper: Asciiquarium2018-02-25T13:45:44-05:002018-02-25T13:45:44-05:00https://www.purinchu.net/wp/2018/02/25/animated-plasma-wallpaper-asciiquarium<p>Years ago, for KDE 3, I had ported a console “asciiquarium” to operate as a KDE screensaver, called “<a href="https://www.purinchu.net/software/asciiquarium.php">KDE asciiquarium</a>“. By KDE 4.2, it was included as part of the kdeartwork module by default.</p>
<p>Since the KDE 3 times when I started this screensaver, our desktop concept has changed around a bit. We’ve developed the Plasma desktop, and have effectively deprecated the idea of screensavers (which are increasingly less popular), though lock screens are still important.</p>
<p>But not everything that changes is a negative: Plasma also supports “live” (or animated) wallpapers, including for lock screens. After some pleas from users hoping for a Plasma 5 port of the screensaver, I started work about a year ago to see if I could port the screensaver to Plasma 5 as an animated wallpaper.</p>
<div id="attachment_829" style="width: 970px" class="wp-caption aligncenter">
<a href="https://purinchu.net/images/plasma_wallpaper_screenshot.png"><img class="wp-image-829 size-full" src="https://www.purinchu.net/wp/wp-content/uploads/2018/02/screenshot-x-sm.png" alt="" width="960" height="540" srcset="https://www.purinchu.net/wp/wp-content/uploads/2018/02/screenshot-x-sm.png 960w, https://www.purinchu.net/wp/wp-content/uploads/2018/02/screenshot-x-sm-300x169.png 300w, https://www.purinchu.net/wp/wp-content/uploads/2018/02/screenshot-x-sm-768x432.png 768w, https://www.purinchu.net/wp/wp-content/uploads/2018/02/screenshot-x-sm-624x351.png 624w" sizes="(max-width: 960px) 100vw, 960px" /></a>
<p class="wp-caption-text">
Screenshot of the running live wallpaper (set as the Plasma background)
</p>
</div>
<p>I think I’ve succeeded in at least getting something to start with. In fact I’ve been running this code for months, never quite finding time to work on it, and I figured maybe someone would be interested if I shared it out.</p>
<p>The code is available at my <a href="https://invent.kde.org/mpyne/plasma_wallpaper_asciiquarium">scratch KDE
repository</a>
(UPDATED 2020-11-08 to account for the move of KDE Git modules to
https://invent.kde.org/). A packaged tarball of the initial release can be
<a href="https://purinchu.net/dumping-ground/plasma_wallpaper_asciiquarium-0.1.tar.xz">downloaded from
here</a>.</p>
<p>This version uses QML, which was quite a bit harder than I thought it would be, due to the desire to keep this “low res”. For instance, instead of smoothly animating the fish with pixel precision, the code forces each fish to align to a text boundary (to simulate the effect of running the original TTY-based script).</p>
<p>To the Qt devs’ credit, I found that this was almost entirely doable in QML alone, thanks to its support for OpenGL shaders in its <a href="http://doc.qt.io/qt-5/qtquick-effects-particles.html">particle system</a>. In fact if you look at the <a href="https://cgit.kde.org/scratch/mpyne/plasma_wallpaper_asciiquarium.git/tree/src/pkg/contents/ui/main.qml#n123">QML code for the sharks</a> you can see that I managed to get the shark sprite to be de-rezzed using vertex shaders alone.</p>
<p>This didn’t work for the individual fish; unfortunately I hadn’t found a way to both use vertex shaders for the fish and allow a per-particle sprite for the fish. I’m sure this is just my inexperience with things; for now I create the fish in QML (in <code class="language-plaintext highlighter-rouge">Component.onCompleted</code>) but use a small C++ QML extension plugin to update their positions. The C++ plugin is also used to create the pixmaps. If it weren’t for these, the whole thing could notionally be in pure QML.</p>
<p>Unfortunately this isn’t anywhere near the greatness of the old version. The shark sometimes dies early, and can’t kill the fish. The air bubbles are missing (not that fish really produce bubbles anyways!), and we’re missing the other major ‘fun’ sprites like the sailing ship or, my favorite, the submarine.</p>
<p>But those nits aren’t getting fixed any faster hanging out on my hard disk, so I offer it up for wider consideration.</p>mpyneYears ago, for KDE 3, I had ported a console “asciiquarium” to operate as a KDE screensaver, called “KDE asciiquarium“. By KDE 4.2, it was included as part of the kdeartwork module by default.KDE in 20172017-12-28T17:11:27-05:002017-12-28T17:11:27-05:00https://www.purinchu.net/wp/2017/12/28/kde-in-2017<p>It’s time for the end of 2017 <a href="https://www.kde.org/fundraisers/yearend2017/">KDE fundraiser</a>, and so this is good a time as any during the year to take a step back and publish a retrospective on the work we’ve individually done in 2017.</p>
<p>For those maintaining a module or two this isn’t too hard to figure out what you’ve done with some git magic. But if you’ve made contributions to more than a few modules it can be a bit unwieldy trying to figure out what work you’ve actually done.</p>
<p>While it’s probably not too difficult to craft a <code class="language-plaintext highlighter-rouge">find(1)</code> command to search recursively under a common directory for git modules, and then run <code class="language-plaintext highlighter-rouge">git-log</code> to look for commits with a given author, it can take a significant amount of time to go through that list if you have a set of checkouts like mine.</p>
<p>Instead, I used kdesrc-build to help, using the <code class="language-plaintext highlighter-rouge">--query</code> flag I blogged about <a href="https://www.purinchu.net/wp/2017/12/24/kdesrc-build-updates-and-tips/">a few days ago</a>. Using kdesrc-build to query for a source directory isn’t very helpful here compared to raw use of <code class="language-plaintext highlighter-rouge">find(1)</code>. Rather, it allowed me to allow use kdesrc-build’s own facilities for filtering through modules to build so that I could eliminate git modules I know I’ve had nothing to do with in a way that isn’t as easily expressible using <code class="language-plaintext highlighter-rouge">find</code> flags.</p>
<p>In my case, I used a command like this:</p>
<div class="language-shell highlighter-rouge"><div class="highlight"><pre class="highlight"><code>kdesrc-build <span class="nt">--query</span> source-dir <span class="nt">--resume-from</span> extra-cmake-modules | <span class="se">\</span>
<span class="nb">cut</span> <span class="nt">-f</span> 2 <span class="nt">-d</span> <span class="s1">':'</span> | <span class="se">\</span>
<span class="k">while </span><span class="nb">read dir</span> <span class="p">;</span> <span class="k">do</span> <span class="se">\</span>
<span class="o">[</span> <span class="nt">-d</span> <span class="s2">"</span><span class="nv">$dir</span><span class="s2">"</span> <span class="o">]</span> <span class="o">&&</span> <span class="nb">cd</span> <span class="s2">"</span><span class="nv">$dir</span><span class="s2">"</span> <span class="o">&&</span> <span class="se">\</span>
git <span class="nt">--no-pager</span> log <span class="nt">--since</span><span class="o">=</span><span class="s1">'2017-01-01'</span> <span class="se">\</span>
<span class="nt">--pretty</span><span class="o">=</span><span class="s2">"tformat:</span><span class="si">$(</span><span class="nb">basename</span> <span class="nv">$dir</span><span class="si">)</span><span class="s2">: %s"</span> <span class="se">\</span>
<span class="nt">--author</span><span class="o">=</span><span class="s1">'mpyne@kde.org'</span> <span class="nt">--committer</span><span class="o">=</span><span class="s1">'mpyne@kde.org'</span> <span class="p">;</span> <span class="se">\</span>
<span class="k">done</span>
</code></pre></div></div>
<p>What this does is to run kdesrc-build and have it generate its module list as normal, using the <code class="language-plaintext highlighter-rouge">--resume-from</code> command to skip over a bunch of large modules I had nothing to do with, and output a line for each of those modules in the form “ki18n: /kdesrc/src/kf5/frameworks/ki18n”.</p>
<p>Each line is fed to <code class="language-plaintext highlighter-rouge">cut(1)</code>, which prints just the part after the colon (<code class="language-plaintext highlighter-rouge">sed(1)</code> would work as well). This path is fed into the <code class="language-plaintext highlighter-rouge">while</code> loop, which extracts each input line into the <code class="language-plaintext highlighter-rouge">$dir</code> variable, and uses that variable to make sure the directory is actually checked-out and if so, runs <code class="language-plaintext highlighter-rouge">git-log</code> in that directory.</p>
<p>Git then actually does the search for any commits since the date given (2017-01-01) by the author(s) or committer(s) you pass. I use the <code class="language-plaintext highlighter-rouge">--no-pager</code> flag before the git subcommand so that I don’t have to pipe to <code class="language-plaintext highlighter-rouge">cat(1)</code> to avoid the automatic interactive result display.</p>
<p>Finally, I use the <code class="language-plaintext highlighter-rouge">--pretty</code> flag to cause git to also include the basename of the directory when it is showing each commit. This helps organize where you did your work in a form that’s easy to slice-and-dice later.</p>
<p>So, what did I do this year? It was split up among these major categories:</p>
<ul>
<li>The <a href="https://www.purinchu.net/wp/2017/12/24/kdesrc-build-updates-and-tips/">kdesrc-build changes</a> I already mentioned.</li>
<li>KCoreAddons: Minor fixes, including to improve desktop entry specification parsing and legacy KDE service type handling. I then fixes a similar issue in KConfig.</li>
<li>KI18N: Mark .h files generated by <code class="language-plaintext highlighter-rouge">uic</code> as ineligible for CMake’s AUTOMOC (fixes a warning of a new CMake policy)</li>
<li>KF5: Make it compile with Alpine Linux (which uses musl). This work was actually to support kdesrc-build in a Docker container, but I never got around to publishing that… :(. This touched KIO, Solid, KInit, KSysGuard.</li>
<li>KWallet: Coverity fixes (on that note, we need someone to start running Coverity builds again…)</li>
<li>and finally… completed Kacper Kasper’s <a href="https://www.kde.org/announcements/announce-applications-17.12.0.php">port of JuK to KF5</a>! This work was released with KDE Applications 17.12. There are still things missing but in some important internal ways, the port is even more complete than the port of JuK from KDE3 to KDE4 was. Unlike the KDE4 version which always used kde3support, JuK now doesn’t use any compatibility libraries, not even Kdelibs4Support, and should compile without warnings (deprecated uses or otherwise).</li>
</ul>
<p>While it has been (and continues to be) difficult to find time to make a meaningful impact with a full-time job outside of software development and a growing family, I hope to be at least as productive in the year to come in 2018.</p>
<p>Happy New Year’s everyone and if you have some spare change lying around, please don’t hesitate to support the <a href="https://www.kde.org/fundraisers/yearend2017/">KDE fundraising drive</a>! Every bit goes to work on something important, and each contribution helps.</p>mpyneIt’s time for the end of 2017 KDE fundraiser, and so this is good a time as any during the year to take a step back and publish a retrospective on the work we’ve individually done in 2017.kdesrc-build updates and tips2017-12-24T06:40:51-05:002017-12-24T06:40:51-05:00https://www.purinchu.net/wp/2017/12/24/kdesrc-build-updates-and-tips<p>A few years back, I shifted <a href="https://kdesrc-build.kde.org/">kdesrc-build</a> to a release model where it was to be used essentially straight from the git-master version. This was both beneficial from a time management perspective, and also reflected the ongoing reality of how it was actually being used, since most developers were using kdesrc-build directly from git by then to take advantage of ongoing updates to the sample KF5 configurations.</p>
<p>While this was helpful to free up more time for development, it also meant that release announcements stopped being published. Since things that aren’t written down somewhere might as well have never happened, I figured I’d go ahead and collect some of the more notable changes over the past couple of years.</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">--include-dependencies</code> (a flag to automatically pull in KDE-based repository dependencies into a build) was adapted to find any KDE-based repository, instead of only ones that could already be located somewhere within your configuration file. The intent to this was to permit even simpler configuration files (set your source-dir, install dir, and go… at least in concept).</li>
<li>Update the code to refer consistently to the kdesrc-build docs <a href="https://docs.kde.org/trunk5/en/extragear-utils/kdesrc-build/index.html">available at docs.kde.org</a> rather than kdesrc-build.kde.org. The former are always built (from the same <code class="language-plaintext highlighter-rouge">doc/</code> sources in kdesrc-build.git) and were much better maintained.</li>
<li>Added a <code class="language-plaintext highlighter-rouge">--query</code> flag to the script. This flag permits <a href="https://docs.kde.org/trunk5/en/extragear-utils/kdesrc-build/supported-cmdline-params.html#cmdline-query">retrieving information about the various git repositories</a> without having to dust off scripts in kde-dev-scripts or kde-build-metadata, or go through a full kdesrc-build run. Note that you should probably include the <code class="language-plaintext highlighter-rouge">--pretend</code> flag to get output suitable for use by automated scripts, and kdesrc-build is not very fast on this.</li>
<li>Fixed the <code class="language-plaintext highlighter-rouge">${option-name}</code> syntax in the configuration file, which permits referring later in the configuration file to options previously set, including options not recognized by kdesrc-build.</li>
<li>Allowed <code class="language-plaintext highlighter-rouge">options</code> blocks in the configuration file to <a href="https://bugs.kde.org/show_bug.cgi?id=365813">apply to entire (named) module sets</a>, not just individual modules. Of course, you’ll want to be careful not to have ambiguous names between module sets and modules…</li>
<li>Removed support for installing KDE git repositories from tarball snapshots. This was far more useful back when we used Subversion; with git it actually seems to take more system resources to generate the tarballs than it saves on the whole, so the KDE sysadmins stopped generating them last year, and there are no other users supported by kdesrc-build. Much of the code has been removed already, the rest will be removed as I get to it.</li>
<li>Some work to move the included <code class="language-plaintext highlighter-rouge">kdesrc-build-setup</code> script to belated point to Qt5-based repositories and branches. The most ideal option is probably still to have kdesrc-build itself either work with a built-in good default configuration, or to generate a sample config directly… but that needs someone to do the work.</li>
<li>The normal set of code refactorings. Five years ago, when I started trying to modularize the core script with <a href="https://cgit.kde.org/kdesrc-build.git/commit/?id=88b065765bcac7066bf6ce001166549116dfb68c">commit 88b0657</a>, kdesrc-build was a 9,304 line single monolithic Perl script. I had started to get concerned at the time that if I ever left maintenance of the script, or if we needed to port it away from Perl, that it would be very difficult to make that transition. While the script is not exactly straightforward even today, it is in much better shape and I hope to keep that going.</li>
<li>Also, I have finally committed some work I’d been pursuing off and on over the past year, to remove the use of the <code class="language-plaintext highlighter-rouge">kde_projects.xml</code> file that kdesrc-build used to gather metadata about the various KDE source repositories. At one point it was looking like I’d be using a dedicated Web API that would expose this repository metadata, but then we realized that it would be easier for all involved to just go straight to the source: the sysadmin/repo-metadata.git repository. That code landed earlier this week, and although I’ve already received a couple of bug reports on it, it will significantly ease the burden on the KDE build infrastructure both in terms of compute power and of sysadmin time in maintaining the script which generates the required XML as they evolve their own backend.
<ul>
<li>You’ll want to install the <code class="language-plaintext highlighter-rouge">YAML::XS</code> Perl module. On Debian/Ubuntu based systems this seems to be libyaml-libyaml-perl. In particular the plain <code class="language-plaintext highlighter-rouge">YAML</code> Perl module seems to be buggy, at least for the YAML we are using in our repo-metadata.</li>
</ul>
</li>
<li>Finally, while this support still remains ‘unofficial’, I have managed to get enough of the Qt5 build system working in kdesrc-build that I have been able to start locally keeping Qt5 up to date with kdesrc-build and only a minimal amount of manual updates (usually revolving around git submodules).</li>
</ul>
<p>That’s quite a bit of work, but my personal effort represents less than 2/3<sup>rds</sup> of the git commits made in the last 2 years. The KDE community at large have been instrumental in keeping the default build configuration up to date and fixing bugs in the script itself.</p>
<p>Going forward my major goals are to resurrect a useful test suite (something broken in the modularization effort), and to use that to support making the script significantly less noisy (think one line of output per module, tops).</p>
<p>Both of these efforts have already started to some extent, and the test suite has its own branch (“testing-restructure”).</p>
<p>That’s what I want to do… what do you think I should do? How should kdesrc-build continue to evolve to support the KDE Community?</p>mpyneA few years back, I shifted kdesrc-build to a release model where it was to be used essentially straight from the git-master version. This was both beneficial from a time management perspective, and also reflected the ongoing reality of how it was actually being used, since most developers were using kdesrc-build directly from git by then to take advantage of ongoing updates to the sample KF5 configurations.The future of kdesrc-build packaging2015-03-20T18:59:24-04:002015-03-20T18:59:24-04:00https://www.purinchu.net/wp/2015/03/20/the-future-of-kdesrc-build-packaging<p>The last official release of the <a href="https://kdesrc-build.kde.org/">kdesrc-build</a> tool to build KDE was 1.15.1, <a href="https://kdesrc-build.kde.org/releases/kdesrc-build-1.15.1.php">nearly three years ago</a>. For some perspective, this is when we were in the process of preparing KDE Software Compilation 4.9 for release, and nearly 2 years before the first technological preview of KDE Frameworks 5.</p>
<p>One could rightly suspect that the project had died entirely, but that is not true (though in fairness there have been large lapses in my time to provide maintenance and development). My periods of inattention were somewhat made up for by a small ecosystem that has sprouted up around kdesrc-build, including <a href="http://jpwhiting.blogspot.co.uk/2014/12/kdesrc-build-is-very-useful-tool-heres.html">advice on how to use kdesrc-build</a>, <a href="http://martys.typepad.com/blog/2014/12/the-christmas-break-project-autocompletion-of-kde-projects-for-kdesrc-build.html" target="_blank">bash autocompletion scripts</a>, and even a project (<a href="http://ivan.fomentgroup.org/blog/2014/10/16/build-profiles-kdesrc-build/" target="_blank">kdesrc-build-extra</a>) that manages entire profiles for you to use with kdesrc-build, with a nice frontend to boot.</p>
<p>Either way, there have been nearly a half-thousand individual git commits to the kdesrc-build.git repository since the last release, including many bugfixes where I’ve faithfully recorded a “FIXED-IN: 1.16” in preparation for a release that seemed like it would never be tagged.</p>
<p>Well, 1.16 itself is official at least, “v1.16” being the official git tag for kdesrc-build.git commit <a href="http://commits.kde.org/kdesrc-build/a6f09a33a1dedf106bb025ab916d932536d32197" target="_blank">a6f09a33</a>. In fact this is where I would normally make a release announcement, but before I cover some of the things that have changed in 3 years, let me first explain how I intend to track kdesrc-build releases in the future.</p>
<h3 id="future-release-process">Future release process</h3>
<p>In short, starting with kdesrc-build 1.16, there will not be official “releases”. Instead, milestone versions will still be occasionally tagged, using the same version format that is becoming popular across open source, using the year and the month as the version. So kdesrc-build would jump from 1.16 to 15.04 (or perhaps 15.05).</p>
<p>Ever since the migration to git for KDE source repositories started really picking up steam, the recommended way to use kdesrc-build has been to run the git version of kdesrc-build directly. The sample KF5 configuration for kdesrc-build even pulls kdesrc-build itself from git (though you’d still need to remember to put it in your <tt>$PATH</tt>).</p>
<p>This was required at first due to the rapid changes required in kdesrc-build to support the rapid changes occurring in the KDE source repositories. Even as development later slowed on kdesrc-build itself, running kdesrc-build from git allowed KDE developers to push KF5 development by keeping the KF5 sample configurations up to date.</p>
<p>So the release process became redundant (indeed, I’ve had a bunch of feedback about kdesrc-build in the past few years, but not one single person has asked me to push an extra release). I will continue to periodically bump the version of the script itself using the time-based version format, but don’t expect formal releases any time soon.</p>
<h3 id="changes-since-1151">Changes since 1.15.1</h3>
<p>With all that said, if you’ve somehow managed to string 1.15.1 along up to this point, here’s some of the things you’d get when you upgrade to kdesrc-build.git (currently 1.16):</p>
<ul>
<li>kdesrc-build can automatically include KDE project dependencies of modules
into the build list. Gone are the days when you’d have to manually ask for
‘frameworks/*’ and then libkdemodule just so you could also build
kdemodule/bar. Well, assuming that kde-build-metadata is kept up to date. :) To
use, include the
<q><a href="https://kdesrc-build.kde.org/documentation/conf-options-table.html#conf-include-dependencies">include-dependencies</a>
true</q> option in a module-set that you wish to have dependencies included on,
like</li>
</ul>
<div class="language-console highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="go">module-set my-grouping
repository kde-projects
use-modules kate
include-dependencies true
end module-set
</span></code></pre></div></div>
<p>You could also use <code class="language-plaintext highlighter-rouge">--include-dependencies</code> on the command line, and pass any modules you wished to build. You can even use options like <code class="language-plaintext highlighter-rouge">--resume-from</code> and <code class="language-plaintext highlighter-rouge">--stop-after</code> to further constrain the module list after dependency extraction.</p>
<ul>
<li>Correctly use the bazaar source control tool to keep modules up to date (“kdesrc-build: We use bzr, so you don’t have to”).</li>
<li>Support for automatically selecting the right branch of a KDE module (assuming needed metadata is set in kde-build-metadata), based on a generic grouping of modules you wish to have (e.g. “stable KDE4”, “latest KF5-based applications”). This feature is essentially mandatory to using kdesrc-build today, but it didn’t exist in 1.15.1!</li>
<li>Better documentation, especially in –help. Note that I still need a lot of help here, despite all the words that are technically under the doc/ directory…</li>
<li>A lot of special-case handling code has been removed, since it’s been made redundant by better information in kde-build-metadata.</li>
<li>Tons more refactoring internally. This is intended to reduce the possibility of inadvertent lock-in to Perl, yet still no one else seems to want to port things… ;) In 1.15.1, kdesrc-build was effectively a giant single Perl file!</li>
<li>Support parsing a simplified dependency-data format, so that occasional logical moves of a git repository from one place to another don’t break all the dependencies. (e.g. if kcalc were to move to something like kf5/applications/base/kcalc.git, the dependencies wouldn’t have to change as kdesrc-build only cares about the ‘kcalc’ part at the end now).</li>
<li>Custom build commands are supported (this is essentially just to support the ‘ninja’ build tool).</li>
<li>Allow setting an HTTP proxy for downloads (and even to download Git modules over HTTP if needed).</li>
<li>Vim syntax highlighting (Kate’s syntax highlight is maintained in KTextEditor itself now).</li>
<li>Added support for building CMake itself, or autotools-based modules.</li>
<li>Added support for ‘catch-all’ dependencies to make it easy to say that e.g. all modules in ‘kde/*’ depend on ‘automoc’.</li>
<li>Allow including other configuration files from your kdesrc-buildrc, to let you create common sections to be shared with multiple kdesrc-buildrc files.</li>
<li>Vastly improved handling of options within kdesrc-buildrc, especially in module-sets, and especially in their interaction with command line flags.</li>
<li>Added a <code class="language-plaintext highlighter-rouge">--print-modules</code> command line option, which is effectively an even quicker “pretend mode” if all you need to know is what modules kdesrc-build thinks it would build. Very recently, <code class="language-plaintext highlighter-rouge">--print-modules</code> will indent modules in accordance with their dependencies (though only when kdesrc-build had to re-order the modules).</li>
<li>Likewise, added a <code class="language-plaintext highlighter-rouge">--metadata-only</code> command line option so that you can download the little bit of data needed to determine module lists without trying to build all of KDE repositories first (or having to Ctrl-C to exit).</li>
</ul>
<p>There are many many more minor things as well, accumulated across the contributions of 32 other developers over the past few years. I hope that will continue over the next few years as well.</p>mpyneThe last official release of the kdesrc-build tool to build KDE was 1.15.1, nearly three years ago. For some perspective, this is when we were in the process of preparing KDE Software Compilation 4.9 for release, and nearly 2 years before the first technological preview of KDE Frameworks 5.