Clint Adams: Measure once, devein twice
package require TclCurl
# download to a variable
curl::transfer -url https://sven.stormbind.net -bodyvar page
# or store it in a file
curl::transfer -url https://sven.stormbind.net -file page.html
Now the remaining problem is that the code is unmaintained upstream and there is one
codebase on bitbucket and one on github. While I fed patches to the bitbucket repo and
thus based the Debian package on that repo, the github repo diverted in a different direction.
[domain/hostacl]
autofs_provider = none
ldap_schema = rfc2307bis
# to work properly we've to keep the search_base at the highest level
ldap_search_base = ou=foo,ou=people,o=myorg
ldap_default_bind_dn = cn=ro,ou=ldapaccounts,ou=foo,ou=people,o=myorg
ldap_default_authtok = foobar
id_provider = ldap
auth_provider = ldap
chpass_provider = none
ldap_uri = ldaps://ldapserver:636
ldap_id_use_start_tls = false
cache_credentials = false
ldap_tls_cacertdir = /etc/pki/tls/certs
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
ldap_tls_reqcert = allow
ldap_group_object_class = groupOfUniqueNames
ldap_group_member = uniqueMember
access_provider = simple
simple_allow_groups = fraappmgmtt
[sssd]
domains = hostacl
services = nss, pam
config_file_version = 2
Important side note: With current sssd versions you're more or less forced to
use ldaps with a validating CA chain, though hostnames are not required to
match the CN/SAN so far.
Relevant are:
chromium --enable-remote-extensions
See also #851927.
- unpacked the tarball
- installed the rpm from the "packages" folder
zypper install cnijfilter-common-3.70-1.x86_64.rpm cnijfilter-ip100series-3.70-1.x86_64.rpm
... and choose to ignore the missing file dependency on libtiff.so.5.
ln -s /usr/lib64/libtiff.so /usr/lib64/libtiff.so.5
- re-ran the ./install.sh which registered the printer with cups and does whatever else
magic is included in 1906 lines of shell.
To my surprise this driver still works and provides the expected quality. Though it's just
a question of time until this setup will break. Be it an incompatible ABI change in libtiff
or another lib in use by those Canon provided tools.
QGIS and gdal with ECW support
While the printer stuff is a rather common use case, having a map viewer for map files in the
ECW format is the eccentric
part. I found some hints on stackoverflow and subsequently
https://trac.osgeo.org/gdal/wiki/ECW
that a non-free library is required and a specific build of gdal.
Then QGIS should be able to work with ECW files. Lucky us there
is at least a OpenSuSE repository for gdal and QGIS. So I did the following:
zypper addrepo http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.2/Application:Geo.repo
zypper install qgis
Then I had to download the non-free ECW SDK from http://download.hexagongeospatial.com/downloads/erdas-ecw-jp2-sdk-v5.3-%28linux%29 - you'll and up with a '.bin' installer file. The installation process
left me with "ERDAS-ECW_JPEG_2000_SDK-5.3.0" folder in my $HOME. I moved that one to /opt. Next
step is adding the library to the ldconfig search path.
echo "/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only/lib/x64/release/" > /etc/ld.so.conf.d/ecw.conf; ldconfig
Now it was "just" about rebuild gdal with ECW support. So I downloaded the required source packages
with "zypper source-install gdal", edited the spec somewhere in "/usr/src/" to make the following
modifications
--with-ecw=/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only
added to the "./configure" invocation. And somewhere at the top we had to relax the
requirement that all installed files have to be referenced inside the package.
%define _unpackaged_files_terminate_build 0
As a last step I had to "rpmbuild -ba" the package and force the installation via zypper
once more, because this time we have a file depedency on the libecw stuff and it's obviously
not listed in the rpm database. Last but not least I tried to put the gdal build on hold with
zypper addlock gdal libgdal20
to ensure it's not removed on the next update.
Other non-free tools
Beside of those two issues I had to install a range of other non-free tools, but currently
they work without further issues or modifications. One is Teamviewer (i686 multiarch rpm) and
the other one is XnViewMP. XnView is also able to show ECW files, but only the smaller ones.
It crashes on bigger ones but that's also the case on Windows. Then there is also (required
by some Italian map related websites) the ugly Adobe Flash Plugin for Firefox, but that one
is sadly still a widespread issue. We also tried to try out the nvidia graphic drivers but
at the moment we could only get the build in Intel card to work. Usually the preferred solution
from my point of view but sometimes we see rendering glitches and I'm not sure if it's the
driver or something else.
my personal take away
I hate to admit it but it's nothing extraordinary that was requested here. But still
it took me the better part of two evenings to figure everything out. And even now it's
not properly integrated and doomed to fail any day due to various updates and changes
in the surounding ecosystem. I've full sympathy for every average user that would give
up after two hours of research and try&error on this journey.
For the printer drivers I'm happy to blame Canon. The printer situation as a whole
improved from my point of view during the last decade, but it's still a pain in the
ass with the very short shelf life you usually see with consumer models.
For the ECW case one could discuss if it would be legally possible and helpful to do
ugly dlopen() stuff to dynamcially load the shared libs. But then again someone has
to make his hands dirty during the build and discussions about the legal use of header
files will be the next chapter (hello Oracle). It's just ugly. Actually I know too little
about the world of image formats to judge if someone has a good reason to keep this
format commercial or not. From my personal point of view it's not useful and maybe
even morally wrong.
Technically one could argue if it would make sense to keep a local copy of the
gdal build in "/opt" and start QGIS with a modified library path to prefer the
private gdal build. Not sure if that is any better.
On the other hand there are evolving mechanism like flatpack that would ease the handling of
such situations. Buth then again we would be catering non-free software. It feels a lot
like giving up.
While my private working environment is except for firmware blobs free, I now created
for someone a real "FrankenSuSE" to satisfy his everyday needs. On the one hand we
now have another mostly satisfied user of a mostly free operating system. On the other
hand that was only possible by adding a vast amount of non-free software. For sure
we did not win the war, I'm not even sure if we've won a single battle here. It's
just frustrating to see what is required to get someone up and running. With my personal
attitude towards open source software it even feels wrong to invest so much time into
fiddling with non-free components.
What is still missing
We currently lack an image viewer that allows us to print only a selection of
an image, which is useful to print parts of a map. That usually works with XnView
on Windows but does not work with the Linux version at the moment. I also tried gwenview
and geeqie and had the same issue. Not sure if it's maybe a bug in XnView or one of the
Qt parts (gwenview is also Qt based). I did not research that yet.
Update: I spent quite some time looking into open bug reports for geeqie and gwenview.
Seems the feature to print only a section of an image is something new. I've created
#374299 (gwenview) and
#457 (geeqie).
For XnView I expect it's a difference between XnViewMP (the portable version) and
the Windows only XnView Classic. Needs to be clarified and it might be worth to try
XnView Classic with wine. Maybe printing with wine via cups works, I found at least
some results for it on the internet.
% appstreamcli what-provides modalias \ usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 Identifier: pymissile [generic] Name: pymissile Summary: Control original Striker USB Missile Launcher Package: pymissile % appstreamcli what-provides modalias usb:v0694p0002d0000 Identifier: libnxt [generic] Name: libnxt Summary: utility library for talking to the LEGO Mindstorms NXT brick Package: libnxt --- Identifier: t2n [generic] Name: t2n Summary: Simple command-line tool for Lego NXT Package: t2n --- Identifier: python-nxt [generic] Name: python-nxt Summary: Python driver/interface/wrapper for the Lego Mindstorms NXT robot Package: python-nxt --- Identifier: nbc [generic] Name: nbc Summary: C compiler for LEGO Mindstorms NXT bricks Package: nbc %A similar query can be done using the combined AppStream and Isenkram databases using the isenkram-lookup tool:
% isenkram-lookup usb:v1130p0202d0100dc00dsc00dp00ic03isc00ip00in00 pymissile % isenkram-lookup usb:v0694p0002d0000 libnxt nbc python-nxt t2n %You can find modalias values relevant for your machine using cat $(find /sys/devices/ -name modalias). If you want to make this system a success and help Debian users make the most of the hardware they have, please helpadd AppStream metadata for your package following the guidelines documented in the wiki. So far only 11 packages provide such information, among the several hundred hardware specific packages in Debian. The Isenkram database on the other hand contain 101 packages, mostly related to USB dongles. Most of the packages with hardware mapping in AppStream are LEGO Mindstorms related, because I have, as part of my involvement in the Debian LEGO team given priority to making sure LEGO users get proposed the complete set of packages in Debian for that particular hardware. The team also got a nice Christmas present today. The nxt-firmware package made it into Debian. With this package in place, it is now possible to use the LEGO Mindstorms NXT unit with only free software, as the nxt-firmware package contain the source and firmware binaries for the NXT brick. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
The owncloud package was removed from
Debian unstable and testing. I am thus now looking for an alternative.
Unfortunately, finding such replacement seems to be harder than I initially
thought, even though I only use a very small subset of what owncloud provides.
What I require is some software which allows me to:
| Software | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| owncloud | ||||||
| sparkleshare | ||||||
| dvcs-autosync | ||||||
| git annex assistant | ||||||
| syncthing | ||||||
| pydio | ||||||
| seafile | ||||||
| sandstorm.io | ||||||
| ipfs | ||||||
| bozon | ||||||
| droppy |
Drought here since August. The small cistern ran dry a month ago, which has
never happened before. The large cistern was down to some 900 gallons. I
don't use anywhere near the national average of 400 gallons per day. More
like 10 gallons. So could have managed for a few more months.
Still, this was worrying, especially as the area moved from severe to
extreme drought according to the
US Drought Monitor.
Two days of solid rain fixed it, yay! The small cistern has already
refilled, and the large will probably be full by tomorrow.
The winds preceeding that same rain storm fanned the flames that
destroyed Gatlinburg. Earlier, fire got within 10 miles of here,
although that may have been some kind of controlled burn.
Climate change is leading to longer duration weather events in this area.
What tended to be a couple of dry weeks in the fall, has become multiple
months of drought and weeks of fire. What might have been a few days of
winter weather and a few inches of snow before the front moved through has
turned into multiple weeks of arctic air, with multiple 1 ft snowfalls.
What might have been a few scorching summer days has become a week of
100-110 degree temperatures. I've seen all that over the past several
years.
After this, I'm adding "additional, larger cistern" to my todo list.
Also "larger fire break around house".
Took me a hell of a long time to get my head out of my arse and dive again
into some Debian related work. Thanks to Nik for pushing me from time
to time.
So I've taken the time to upload LyX 2.2.2 to unstable and it's now
build with Qt5. Afterall the package is still missing a lot of love,
but I hope we've once again something for the upcoming stable release,
that is close to the latest upstream stable release. If you use LyX please
give it a try.
For myself it's now the 6th year that I stopped using LyX after maintaining
it for five years. And still I'm sponsoring the uploads and try to keep it
at least functional. Strange how we sometimes take care of stuff even if we
no longer have an active use for them.
DebConf16
Firstly, thanks to everyone who came out and added their own uniqueness and expertise to the pool. The feedback received so far has been very positive and I feel that the few problems we did experience was dealt with very efficiently. Having a DebConf in your hometown is a great experience, consider a bid for hosting a DebConf in your city!
DebConf16 Open Festival (5 August)
The Open Festival (usually Debian Open Day) turned out pretty good. It was a collection of talks, a job fair, and some demos of what can be done with Debian. I particularly liked Hetzner s stand. I got to show off some 20 year old+ Super Mario skills and they had some fun brain teasers as well. It s really great to see a job stand that s so interactive and I think many companies can learn from them.
The demo that probably drew the most attention was from my friend Georg who demoed some LulzBot Mini 3D Printers. They really seem to love Debian which is great!At #Debconf? Join the #HetznerSA #Supermariobros challenge and stand a chance to win a case of #Leagueofbeers pic.twitter.com/DpkOj6wmZb HetznerSA Careers (@HetznerCareers) July 2, 2016
LulzBot Mini #3Dprinters were on the scene at @DebConf Open Festival in South Africa. We re powered by @debian! pic.twitter.com/AOBS64ZtiJ LulzBot (@lulzbot3D) July 13, 2016DebConf (6 August to 12 August) If I try to write up all my thoughts and feeling about DC16, I ll never get this post finished. Instead, here as some tweets from DebConf that other have written:
@o0karen0o delivering today s #DebConf16 keynote pic.twitter.com/hG1wD5MBhH Michael Banck (@mbanck) July 3, 2016
Great to see Sicelo Mhlongo speaking about issues using @debian in Swaziland #debconf16 pic.twitter.com/U6z7HA8zd5 Neil McGovern (@nmcgovern) July 7, 2016
What happened at #DebConf16 yesterday? Sandstorm Principles talking about the freedom to choose #software #sandbox pic.twitter.com/ltYaw3dAmP Obsidian Systems (@obsidianza) July 5, 2016
All @DebConf end with similar feelings: we re an incredible crowd working together for a incredibly important cause. https://t.co/DYuUWT5eKt Didier Raboud (@OdyX_) July 9, 2016
My congratulations to the #DebConf video team. As usual, they are doing an amazing work at #DebConf16Day Trip We had 3 day trips:
Marcelo Santana (@mgsantana) July 8, 2016
.buildinfo file server:
Because I lack the infrared sensor used to control the robot in the
design from HiTechnic, I had to comment out the last task
(taskControl). I simply placed /* and */ around it get the program
working without that sensor present. Now it balances just fine until
the battery status run low:
Now we would like to teach it how to follow a line and take remote control instructions using the included Bluetooth receiver in the NXT. If you, like me, love LEGO and want to make sure we find the tools they need to work with LEGO in Debian and all our derivative distributions like Ubuntu, check out the LEGO designers project page and join the Debian LEGO team. Personally I own a RCX and NXT controller (no EV3), and would like to make sure the Debian tools needed to program the systems I own work as they should.
Here is my monthly update covering what I have been doing in the free software world (previously):
Whilst anyone can inspect the source code of free software for malicious flaws, most GNU/Linux distributions provide binary (or "compiled") packages to end users. The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced either maliciously and accidentally during this compilation process by promising identical binary packages are always generated from a given source.
Presented a talk entitled "Reproducible Builds" talk at Software Freedom Kosova, in Prishtina, Republic of Kosovo.
I filed my 2,500th bug in the Debian BTS: #840972: golang-google-appengine: accesses the internet during build.
In order to build packages reproducibly, one not only needs identical sources but also some external and sharable definition of the environment used for a particular build, stipulating such things such as the version numbers of the required build-dependencies. It is not currently clear how to handle these .buildinfo files after the archive software has processed them and how to make them available to the world so I started development on a proof-of-concept server to see what issues arise in practice. It is available at buildinfo.debian.net.
Chaired an IRC meeting and ran a poll to determine a regular time .
Submitted two design proposals to our wiki page.
Improvements to our tests.reproducible-builds.org testing framework:
Next.