You are here

Shtëpia › Agreguesi i feed › Burimet

Planet Debian

Subscribe to Feed Planet Debian
random musings and comments The experience of a free software community member Entries tagged english random musings and comments Indeed, there are many other ways to make the world a better place; but Free Software is the one I like the most. (y eso no es poca cosa) Random thoughts about everything tagged by Debian Just another WordPress.com weblog random musings and comments Random thoughts about everything tagged by Debian Thinking inside the box Joachim Breitners Denkblogade Thinking inside the box Debian and Free Software Random thoughts about everything tagged by Debian Free Software Indie Hacker Echoes Random thoughts about everything tagged by Debian Recent content in Planet Debian on Iain R. Learmonth Current Working Directory liw's English language blog feed Reproducible builds blog A blog from a scientist and Debian developer (and occasional book writer)... Tricks for data handling, programming, debian administration and development, command-line and many other joyful things in the same spirit. Oh, and sometimes completey unrelated things ! ganbatte kudasai! Ben Hutchings's diary of life and technology Random thoughts about everything tagged by Debian Conteúdo de Antonio Terceiro marcado com a tag "english" Entries tagged english Recent content in Planet Debian on Iain R. Learmonth Joachim Breitners Denkblogade Ricardo Mones - LiveJournal.com Recent content in Planet Debian on Iain R. Learmonth faiblog Payson, AZ Open Source Developer and enthusiast dedicated to KDE Insider infos, master your Debian/Ubuntu distribution WEBlog -- Wouter's Eclectic Blog Debian and Free Software Digital-Scurf Ramblings Recent content in Planet Debian on Iain R. Learmonth random musings and comments Thinking inside the box Reproducible builds blog a personal blog of Dimitri John Ledkov Recent content in Planet Debian on Iain R. Learmonth anarcat jmtd liw's English language blog feed showing latest 10 James McCoy As time goes by ... pabs
URL: http://planet.debian.org/
Përditësimi: 3 months 3 javë më parë

My Debian Activities in September 2017

Dje, 01/10/2017 - 6:07md

FTP assistant

This month almost the same numbers as last month appeared in the statistics. I accepted 213 packages and rejected 15 uploads. The overall number of packages that got accepted this month was 425.

Debian LTS

This was my thirty-ninth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian.

This month my all in all workload has been 15.75h. During that time I did LTS uploads of:

  • [DLA 1109-1] libraw security update for one CVE
  • [DLA 1117-1] opencv security update for 13 CVEs

I also took care of libstrusts1.2-java and marked all CVEs as not-affected and I marked all CVEs for jasper as no-dsa. I also started to work on sam2p.

Just as I wanted to upload a new version of libofx, a new CVE was discovered that was not closed in time. I tried to find a patch on my own but had difficulties in reproducing this issue.

Other stuff

This month I made myself familiar with glewlwyd and according to upstream, the Debian packages work out-of-the box. However upstream does not stop working on that software, so I uploaded new versions of hoel, ulfius and glewlwyd.

As libjwt needs libb64, which was orphanded, I used it as DOPOM and adopted it.

Does anybody still know the Mayhem-bugs? I could close one by uploading an updated version of siggen.

I also went through my packages and looked for patches that piled up in the BTS. As a result i uploaded updated versions of radlib, te923con, node-starttls, harminv and uucp.

New upstream versions of openoverlayrouter and fasttree also made it into the archive.

Last but not least I moved several packages to the debian-mobcom group.

alteholz http://blog.alteholz.eu blog.alteholz.eu » planetdebian

FLOSS Activities September 2017

Dje, 01/10/2017 - 3:39pd
Changes Issues Review Administration
  • icns: merged patches
  • Debian: help guest user with access, investigate/escalate broken network, restart broken stunnels, investigate static.d.o storage, investigate weird RAID mails, ask hoster to investigate power issue,
  • Debian mentors: lintian/security updates & reboot
  • Debian wiki: merged & deployed patch, redirect DDTSS translator, redirect user support requests, whitelist email addresses, update email for accounts with bouncing email,
  • Debian derivatives census: merged/deployed patches
  • Debian PTS: debugged cron mails, deployed changes, reran scripts, fixed configuration file
  • Openmoko: debug reboot issue, debug load issues
Communication Sponsors

The samba bug was sponsored by my employer. All other work was done on a volunteer basis.

Paul Wise http://bonedaddy.net/pabs3/log/ Log

Process Monitoring

Enj, 28/09/2017 - 3:46md

Since forking the Mon project to etbemon [1] I’ve been spending a lot of time working on the monitor scripts. Actually monitoring something is usually quite easy, deciding what to monitor tends to be the hard part. The process monitoring script ps.monitor is the one I’m about to redesign.

Here are some of my ideas for monitoring processes. Please comment if you have any suggestions for how do do things better.

For people who don’t use mon, the monitor scripts return 0 if everything is OK and 1 if there’s a problem along with using stdout to display an error message. While I’m not aware of anyone hooking mon scripts into a different monitoring system that’s going to be easy to do. One thing I plan to work on in the future is interoperability between mon and other systems such as Nagios.

Basic Monitoring ps.monitor tor:1-1 master:1-2 auditd:1-1 cron:1-5 rsyslogd:1-1 dbus-daemon:1- sshd:1- watchdog:1-2

I’m currently planning some sort of rewrite of the process monitoring script. The current functionality is to have a list of process names on the command line with minimum and maximum numbers for the instances of the process in question. The above is a sample of the configuration of the monitor. There are some limitations to this, the “master” process in this instance refers to the main process of Postfix, but other daemons use the same process name (it’s one of those names that’s wrong because it’s so obvious). One obvious solution to this is to give the option of specifying the full path so that /usr/lib/postfix/sbin/master can be differentiated from all the other programs named master.

The next issue is processes that may run on behalf of multiple users. With sshd there is a single process to accept new connections running as root and a process running under the UID of each logged in user. So the number of sshd processes running as root will be one greater than the number of root login sessions. This means that if a sysadmin logs in directly as root via ssh (which is controversial and not the topic of this post – merely something that people do which I have to support) and the master process then crashes (or the sysadmin stops it either accidentally or deliberately) there won’t be an alert about the missing process. Of course the correct thing to do is to have a monitor talk to port 22 and look for the string “SSH-2.0-OpenSSH_”. Sometimes there are multiple instances of a daemon running under different UIDs that need to be monitored separately. So obviously we need the ability to monitor processes by UID.

In many cases process monitoring can be replaced by monitoring of service ports. So if something is listening on port 25 then it probably means that the Postfix “master” process is running regardless of what other “master” processes there are. But for my use I find it handy to have multiple monitors, if I get a Jabber message about being unable to send mail to a server immediately followed by a Jabber message from that server saying that “master” isn’t running I don’t need to fully wake up to know where the problem is.

SE Linux

One feature that I want is monitoring SE Linux contexts of processes in the same way as monitoring UIDs. While I’m not interested in writing tests for other security systems I would be happy to include code that other people write. So whatever I do I want to make it flexible enough to work with multiple security systems.

Transient Processes

Most daemons have a second process of the same name running during the startup process. This means if you monitor for exactly 1 instance of a process you may get an alert about 2 processes running when “logrotate” or something similar restarts the daemon. Also you may get an alert about 0 instances if the check happens to run at exactly the wrong time during the restart. My current way of dealing with this on my servers is to not alert until the second failure event with the “alertafter 2” directive. The “failure_interval” directive allows specifying the time between checks when the monitor is in a failed state, setting that to a low value means that waiting for a second failure result doesn’t delay the notification much.

To deal with this I’ve been thinking of making the ps.monitor script automatically check again after a specified delay. I think that solving the problem with a single parameter to the monitor script is better than using 2 configuration directives to mon to work around it.

CPU Use

Mon currently has a loadavg.monitor script that to check the load average. But that won’t catch the case of a single process using too much CPU time but not enough to raise the system load average. Also it won’t catch the case of a CPU hungry process going quiet (EG when the SETI at Home server goes down) while another process goes into an infinite loop. One way of addressing this would be to have the ps.monitor script have yet another configuration option to monitor CPU use, but this might get confusing. Another option would be to have a separate script that alerts on any process that uses more than a specified percentage of CPU time over it’s lifetime or over the last few seconds unless it’s in a whitelist of processes and users who are exempt from such checks. Probably every regular user would be exempt from such checks because you never know when they will run a file compression program. Also there is a short list of daemons that are excluded (like BOINC) and system processes (like gzip which is run from several cron jobs).

Monitoring for Exclusion

A common programming mistake is to call setuid() before setgid() which means that the program doesn’t have permission to call setgid(). If return codes aren’t checked (and people who make such rookie mistakes tend not to check return codes) then the process keeps elevated permissions. Checking for processes running as GID 0 but not UID 0 would be handy. As an aside a quick examination of a Debian/Testing workstation didn’t show any obvious way that a process with GID 0 could gain elevated privileges, but that could change with one chmod 770 command.

On a SE Linux system there should be only one process running with the domain init_t. Currently that doesn’t happen in Stretch systems running daemons such as mysqld and tor due to policy not matching the recent functionality of systemd as requested by daemon service files. Such issues will keep occurring so we need automated tests for them.

Automated tests for configuration errors that might impact system security is a bigger issue, I’ll probably write a separate blog post about it.

Related posts:

  1. Monitoring of Monitoring I was recently asked to get data from a computer...
  2. When to Use SE Linux Recently someone asked on IRC whether they should use SE...
  3. Health and Status Monitoring via Smart Phone Health Monitoring Eric Topol gave an interesting TED talk about...
etbe https://etbe.coker.com.au etbe – Russell Coker

LibreOffice community celebrates 7th anniversary

Enj, 28/09/2017 - 2:52md

The Document foundation blog have a post about LibreOffice 7th anniversary:

Berlin, September 28, 2017 – Today, the LibreOffice community celebrates the 7th anniversary of the leading free office suite, adopted by millions of users in every continent. Since 2010, there have been 14 major releases and dozens of minor ones, fulfilling the personal productivity needs of both individuals and enterprises, on Linux, macOS and Windows.

I wanted to take a moment to remind people that 7 years ago the community decided to make the de facto fork of OpenOffice.org official after life under Sun (and then Oracle) were problematic. From the very first hours the project showed its effectiveness. See my post about LibreOffice first steps. Not to mention what it achieved in the past 7 years.

This is still one of my favourite open source contributions, not because it was sophisticated or hard, but because it as about using the freedom part of the free software:
Replace hardcoded “product by Oracle” with “product by %OOOVENDOR”.

On a personal note, for me, after years of trying to help with OOo l10n for Hebrew and RTL support, things started to go forward in a reasonable pace, getting patches in after years of trying, having upstream fix some of the issues, and actually able doing the translation. We made it to 100% with LibreOffice 3.5.0 in February 2012 (something we should redo soon…).


Filed under: i18n & l10n, Israeli Community, LibreOffice Kaplan https://liorkaplan.wordpress.com Free Software Universe

Review: The Seventh Bride

Enj, 28/09/2017 - 6:41pd

Review: The Seventh Bride, by T. Kingfisher

Publisher: 47North Copyright: 2015 ISBN: 1-5039-4975-3 Format: Kindle Pages: 225

There are two editions of this book, although only one currently for sale. This review is of the second edition, released in November of 2015. T. Kingfisher is a pen name for Ursula Vernon when she's writing for adults.

Rhea is a miller's daughter. She's fifteen, obedient, wary of swans, respectful to her parents, and engaged to Lord Crevan. The last was a recent and entirely unexpected development. It's not that she didn't expect to get married eventually, since of course that's what one does. And it's not that Lord Crevan was a stranger, since that's often how it went with marriage for people like her. But she wasn't expecting to get married now, and it was not at all clear why Lord Crevan would want to marry her in particular.

Also, something felt not right about the entire thing. And it didn't start feeling any better when she finally met Lord Crevan for the first time, some days after the proposal to her parents. The decidedly non-romantic hand kissing didn't help, nor did the smug smile. But it's not like she had any choice. The miller's daughter doesn't say no to a lord and a friend of the viscount. The miller's family certainly doesn't say no when they're having trouble paying the bills, the viscount owns the mill, and they could be turned out of their livelihood at a whim.

They still can't say no when Lord Crevan orders Rhea to come to his house in the middle of the night down a road that quite certainly doesn't exist during the day, even though that's very much not the sort of thing that is normally done. Particularly before the marriage. Friends of the viscount who are also sorcerers can get away with quite a lot. But Lord Crevan will discover that there's still a limit to how far he can order Rhea around, and practical-minded miller's daughters can make a lot of unexpected friends even in dire circumstances.

The Seventh Bride is another entry in T. Kingfisher's series of retold fairy tales, although the fairy tale in question is less clear than with The Raven and the Reindeer. Kirkus says it's a retelling of Bluebeard, but I still don't quite see that in the story. I think one could argue equally easily that it's an original story. Nonetheless, it is a fairy tale: it has that fairy tale mix of magical danger and practical morality, and it's about courage and friendships and their consequences.

It also has a hedgehog.

This is an T. Kingfisher story, so it's packed full of bits of marvelous phrasing that I want to read over and over again. It has wonderful characters, the hedgehog among them, and it has, at its heart, a sort of foundational decency and stubborn goodness that's deeply satisfying for the reader.

The Seventh Bride is a lot closer to horror than the other T. Kingfisher books I've read, but it never fell into my dislike of the horror genre, despite a few gruesome bits. I think that's because neither Rhea nor the narrator treat the horrific aspects as representative of the true shape of the world. Rhea instead confronts them with a stubborn determination and an attempt to make the best of each moment, and with a practical self-awareness that I loved reading about.

The problem with crying in the woods, by the side of a white road that leads somewhere terrible, is that the reason for crying isn't inside your head. You have a perfectly legitimate and pressing reason for crying, and it will still be there in five minutes, except that your throat will be raw and your eyes will itch and absolutely nothing else will have changed.

Lord Crevan, when Rhea finally reaches him, toys with her by giving her progressively more horrible puzzle tasks, threatening her with the promised marriage if she fails at any of them. The way this part of the book finally resolves is one of the best moments I've read in any book. Kingfisher captures an aspect of moral decisions, and a way in which evil doesn't work the way that evil people expect it to work, that I can't remember seeing an author capture this well.

There are a lot of things here for Rhea to untangle: the nature of Crevan's power, her unexpected allies in his manor, why he proposed marriage to her, and of course how to escape his power. The plot works, but I don't think it was the best part of the book, and it tends to happen to Rhea rather than being driven by her. But I have rarely read a book quite this confident of its moral center, or quite as justified in that confidence.

I am definitely reading everything Vernon has published under the T. Kingfisher name, and quite possibly most of her children's books as well. Recommended, particularly if you liked the excerpt above. There's an entire book full of paragraphs like that waiting for you.

Rating: 8 out of 10

Russ Allbery https://www.eyrie.org/~eagle/ Eagle's Path

RcppZiggurat 0.1.4

Enj, 28/09/2017 - 4:06pd

A maintenance release of RcppZiggurat is now on the CRAN network for R. It switched the vignette to the our new pinp package and its two-column pdf default.

The RcppZiggurat package updates the code for the Ziggurat generator which provides very fast draws from a Normal distribution. The package provides a simple C++ wrapper class for the generator improving on the very basic macros, and permits comparison among several existing Ziggurat implementations. This can be seen in the figure where Ziggurat from this package dominates accessing the implementations from the GSL, QuantLib and Gretl---all of which are still way faster than the default Normal generator in R (which is of course of higher code complexity).

The NEWS file entry below lists all changes.

Changes in version 0.1.4 (2017-07-27)

  • The vignette now uses the pinp package in two-column mode.

  • Dynamic symbol registration is now enabled.

Courtesy of CRANberries, there is also a diffstat report for the most recent release. More information is on the RcppZiggurat page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel http://dirk.eddelbuettel.com/blog Thinking inside the box

Systemd device units

Enj, 28/09/2017 - 12:00pd

These are the notes of a training course on systemd I gave as part of my work with Truelite.

.device units

Several devices are automatically represented inside systemd by .device units, which can be used to activate services when a given device exists in the file system.

See systemctl --all --full -t device to see a list of all decives for which systemd has a unit in your system.

For example, this .service unit plays a sound as long as a specific USB key is plugged in my system:

[Unit] Description=Beeps while a USB key is plugged DefaultDependencies=false StopWhenUnneeded=true [Install] WantedBy=dev-disk-by\x2dlabel-ERLUG.device [Service] Type=simple ExecStart=/bin/sh -ec 'while true; do /usr/bin/aplay -q /tmp/beep.wav; sleep 2; done'

If you need to work with a device not seen by default by systemd, you can add a udev rule that makes it available, by adding the systemd tag to the device with TAG+="systemd".

It is also possible to give the device an extra alias using ENV{SYSTEMD_ALIAS}="/dev/my-alias-name".

To figure out all you can use for matching a device:

  1. Run udevadm monitor --environment and plug the device
  2. Look at the DEVNAME= values and pick one that addresses your device the way you prefer
  3. udevadm info --attribute-walk --name=*the value of devname* will give you all you can use for matching in the udev rule.

See:

Enrico Zini http://www.enricozini.org/tags/pdo/ Enrico Zini: pdo

Qt cross-architecture development in Debian

Mër, 27/09/2017 - 3:25md

Use case: use Debian Stable as an environment to run amd64 development machines to develop Qt applications for Raspberry Pi or other smallish armhf devices.

Qt Creator is used as Integrated Development Environment, and it supports cross-compiling, running the built source on the target system, and remote debugging.

Debian Stable (vanilla or Raspbian) runs on both the host and the target systems, so libraries can be kept in sync, and both systems have access to a vast amount of libraries, with security support.

On top of that, armhf libraries can be installed with multiarch also in the host machine, so cross-builders have access to the exact same libraries as the target system.

This sounds like a dream system. But. We're not quite there yet.

cross-compile attempts

I tried cross compiling a few packages:

$ sudo debootstrap stretch cross $ echo "strech_cross" | sudo tee cross/etc/debian_chroot $ sudo systemd-nspawn -D cross # dpkg --add-architecture armhf # echo "deb-src http://deb.debian.org/debian stretch main" >> /etc/apt/sources.list # apt update # apt install --no-install-recommends build-essential crossbuild-essential-armhf

Some packages work:

# apt source bc # cd bc-1.06.95/ # apt-get build-dep -a armhf . # dpkg-buildpackage -aarmhf -j2 -b … dh_auto_configure -- --prefix=/usr --with-readline ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=\${prefix}/lib/arm-linux-gnueabihf --libexecdir=\${prefix}/lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --host=arm-linux-gnueabihf --prefix=/usr --with-readline … dpkg-deb: building package 'dc-dbgsym' in '../dc-dbgsym_1.06.95-9_armhf.deb'. dpkg-deb: building package 'bc-dbgsym' in '../bc-dbgsym_1.06.95-9_armhf.deb'. dpkg-deb: building package 'dc' in '../dc_1.06.95-9_armhf.deb'. dpkg-deb: building package 'bc' in '../bc_1.06.95-9_armhf.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../bc_1.06.95-9_armhf.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build bc-1.06.95 dpkg-buildpackage: info: binary-only upload (no source included)

With qmake based Qt packages, qmake is not configured for cross-building, probably because it is not currently supported:

# apt source pumpa # cd pumpa-0.9.3/ # apt-get build-dep -a armhf . # dpkg-buildpackage -aarmhf -j2 -b … qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/root/pumpa-0.9.3=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_LFLAGS_RELEASE=-Wl,-z,relro -Wl,-z,now" "QMAKE_LFLAGS_DEBUG=-Wl,-z,relro -Wl,-z,now" QMAKE_STRIP=: PREFIX=/usr qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qmake': No such file or directory … debian/rules:19: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2

With cmake based Qt packages it goes a little better in that it finds the cross compiler, pkg-config and some multiarch paths, but then it tries to run armhf moc, which fails:

# apt source caneda # cd caneda-0.3.0/ # apt-get build-dep -a armhf . # dpkg-buildpackage -aarmhf -j2 -b … cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=arm -DCMAKE_C_COMPILER=arm-linux-gnueabihf-gcc -DCMAKE_CXX_COMPILER=arm-linux-gnueabihf-g\+\+ -DPKG_CONFIG_EXECUTABLE=/usr/bin/arm-linux-gnueabihf-pkg-config -DCMAKE_INSTALL_LIBDIR=lib/arm-linux-gnueabihf … CMake Error at /usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfig.cmake:27 (message): The imported target "Qt5::Core" references the file "/usr/lib/arm-linux-gnueabihf/qt5/bin/moc" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/arm-linux-gnueabihf/cmake/Qt5Core/Qt5CoreConfigExtras.cmake" but not all the files it references.

Note: Although I improvised a chroot to be able to fool around with it, I would use pbuilder or sbuild to do the actual builds.

Helmut suggests pbuilder --host-arch or sbuild --host.

Doing it the non-Debian way

This guide in the meantime explains how to set up a cross-compiling Qt toolchain in a rather dirty way, by recompiling Qt pointing it at pieces of the Qt deployed on the Raspberry Pi.

Following that guide, replacing the CROSS_COMPILE value with /usr/bin/arm-linux-gnueabihf- gave me a working qtbase, for which it is easy to create a Kit for Qt Creator that works, and supports linking applications with Debian development packages that do not use Qt.

However, at that point I need to recompile all dependencies that use Qt myself, and I quickly got stuck at that monster of QtWebEngine, whose sources embed the whole of Chromium.

Having a Qt based development environment in which I need to become the maintainer for the whole Qt toolchain is not a product I can offer to a customer. Cross compiling qmake based packages on stretch is not currently supported, so at the moment I had to suggest to postpone all plans for total world domination for at least two years.

Cross-building Debian

In the meantime, Helmut Grohne has been putting a lot of effort into making Debian packages cross-buildable:

helmut> enrico: yes, cross building is painful. we have ~26000 source packages. of those, ~13000 build arch-dep packages. of those, ~6000 have cross-satisfiable build-depends. of those, I tried cross building ~2300. of those 1300 cross built. so we are at about 10% working.

helmut> enrico: plus there are some 607 source packages affected by some 326 bugs with patches.

helmut> enrico: gogo nmu them

helmut> enrico: I've filed some 1000 bugs (most of them with patches) now. around 600 are fixed :)

He is doing it mostly alone, and I would like people not to be alone when they do a lot of work in Debian, so…

Join Helmut in the effort of making Debian cross-buildable!

Build any Debian package for any device right from the comfort of your own work computer!

Have a single development environment seamlessly spanning architecture boundaries, with the power of all that there is in Debian!

Join Helmut in the effort of making Debian cross-buildable!

Apply here, or join #debian-bootstrap on OFTC!

Cross-building Qt in Debian

mitya57 summarised the situation on the KDE team side:

mitya57> we have cross-building stuff on our TODO list, but it will likely require a lot of time and neither Lisandro nor I have it currently.

mitya57> see https://gobby.debian.org/export/Teams/KDE/qt-cross for a summary of what needs to be done.

mitya57> Any help or patches are always welcome :))

qemu-user-static

Helmut also suggested to use qemu-user-static to make the host system able to run binaries compiled for the target system, so that even if a non-cross-compiling Qt build tries to run moc and friends in their target architecture version, they would transparently succeed.

At that point, it would just be a matter of replacing compiler paths to point to the native cross-compiling gcc, and the build would not be slowed down by much.

Fixing bug #781226 would help in making it possible to configure a multiarch version of qmake as the qmake used for cross compiling.

I have not had a chance of trying to cross-build in this way yet.

In the meantime...

Having qtcreator able to work on an amd64 devel machine and deploy/test/debug remotely on an arm target machine, where both machine run debian stable and have libraries in sync, would be a great thing to have even though packages do not cross-build yet.

Helmut summarised the situation on IRC:

svuorela and others repeat that Qt upstream is not compatible with Debian's multiarch thinking, in that Qt upstream insists on having one toolchain for each pair of architectures, whereas the Debian way tends to be to make packages generic and split stuff such that it can be mixed and matched.

An example being that you need to run qmake (thus you need qmake for the build architecture), but qmake also embeds the relevant paths and you need to query it for them (so you need qmake for the host architecture)

Either you run it through qemu, or you have a particular cross qmake for your build/host pair, or you fix qt upstream to stop this madness

Building qmake in Debian for each host-target pair, even just limited to released architectures, would mean building Qt 100 times, and that's not going to scale.

I wonder:

  • can I have a qmake-$ARCH binary that can build a source using locally installed multiarch Qt libraries, do I need to recompile and ship the whole of Qt, or just qmake?
  • is there a recipe for building a cross-building Qt environment that would be able use Debian development libraries installed the normal multiarch way?
  • we can't do perfect yet, but can we do better than this?
Enrico Zini http://www.enricozini.org/tags/pdo/ Enrico Zini: pdo

RcppAnnoy 0.0.10

Mër, 27/09/2017 - 4:05pd

A few short weeks after the more substantial 0.0.9 release of RcppAnnoy, we have a quick bug-fix update.

RcppAnnoy is our Rcpp-based R integration of the nifty Annoy library by Erik. Annoy is a small and lightweight C++ template header library for very fast approximate nearest neighbours.

Michaël Benesty noticed that our getItemsVector() function didn't, ahem, do much besides crashing. Simple bug, they happen--now fixed, and a unit test added.

Changes in this version are summarized here:

Changes in version 0.0.10 (2017-09-25)
  • The getItemsVector() function no longer crashes (#24)

Courtesy of CRANberries, there is also a diffstat report for this release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel http://dirk.eddelbuettel.com/blog Thinking inside the box

Systemd timer units

Mër, 27/09/2017 - 12:00pd

These are the notes of a training course on systemd I gave as part of my work with Truelite.

.timer units

Configure activation of other units (usually a .service unit) at some given time.

The functionality is similar to cron, with more features and a finer time granularity. For example, in Debian Stretch apt has a timer for running apt update which runs at a random time to distribute load on servers:

# /lib/systemd/system/apt-daily.timer [Unit] Description=Daily apt download activities After=network-online.target Wants=network-online.target [Timer] OnCalendar=*-*-* 6,18:00 RandomizedDelaySec=12h Persistent=true [Install] WantedBy=timers.target

The corresponding apt-daily.service file then only runs when the system is on mains power, to avoid unexpected batter drains for systems like laptops:

# /lib/systemd/system/apt-daily.service [Unit] Description=Daily apt download activities Documentation=man:apt(8) ConditionACPower=true [Service] Type=oneshot ExecStart=/usr/lib/apt/apt.systemd.daily update

Note that if you want to schedule tasks with an accuracy under a minute (for example to play a beep every 5 seconds when running on battery), you need to also configure AccuracySec= for the timer to a delay shorter than the default 1 minute.

This is how to make your computer beep when on battery:

# /etc/systemd/system/beep-on-battery.timer [Unit] Description=Beeps every 10 seconds [Install] WantedBy=timers.target [Timer] AccuracySec=1s OnUnitActiveSec=10s # /etc/systemd/system/beep-on-battery.service [Unit] Description=Beeps when on battery ConditionACPower=false [Service] Type=oneshot ExecStart=/usr/bin/aplay /tmp/beep.wav

See:

Enrico Zini http://www.enricozini.org/tags/pdo/ Enrico Zini: pdo

A mysterious bug with Twisted plugins

Mar, 26/09/2017 - 5:20md

I fixed a bug in Launchpad recently that led me deeper than I expected.

Launchpad uses Buildout as its build system for Python packages, and it’s served us well for many years. However, we’re using 1.7.1, which doesn’t support ensuring that packages required using setuptools’ setup_requires keyword only ever come from the local index URL when one is specified; that’s an essential constraint we need to be able to impose so that our build system isn’t immediately sensitive to downtime or changes in PyPI. There are various issues/PRs about this in Buildout (e.g. #238), but even if those are fixed it’ll almost certainly only be in Buildout v2, and upgrading to that is its own kettle of fish for other reasons. All this is a serious problem for us because newer versions of many of our vital dependencies (Twisted and testtools, to name but two) use setup_requires to pull in pbr, and so we’ve been stuck on old versions for some time; this is part of why Launchpad doesn’t yet support newer SSH key types, for instance. This situation obviously isn’t sustainable.

To deal with this, I’ve been working for some time on switching to virtualenv and pip. This is harder than you might think: Launchpad is a long-lived and complicated project, and it had quite a number of explicit and implicit dependencies on Buildout’s configuration and behaviour. Upgrading our infrastructure from Ubuntu 12.04 to 16.04 has helped a lot (12.04’s baseline virtualenv and pip have some deficiencies that would have required a more complicated bootstrapping procedure). I’ve dealt with most of these: for example, I had to reorganise a lot of our helper scripts (1, 2, 3), but there are still a few more things to go.

One remaining problem was that our Buildout configuration relied on building several different environments with different Python paths for various things. While this would technically be possible by way of building multiple virtualenvs, this would inflate our build time even further (we’re already going to have to cope with some slowdown as a result of using virtualenv, because the build system now has to do a lot more than constructing a glorified link farm to a bunch of cached eggs), and it seems like unnecessary complexity. The obvious thing to do seemed to be to collapse these into a single environment, since there was no obvious reason why it should actually matter if txpkgupload and txlongpoll were carefully kept off the path when running most of Launchpad: so I did that.

Then our build system got very sad.

Hmm, I thought. To keep our test times somewhat manageable, we run them in parallel across 20 containers, and we randomise the order in which they run to try to shake out test isolation bugs. It’s not completely unknown for there to be some oddities resulting from that. So I ran it again. Nope, but slightly differently sad this time. Furthermore, I couldn’t reproduce these failures locally no matter how hard I tried. Oh dear. This was obviously not going to be a good day.

In fact I spent a while on various different guesswork-based approaches. I found bug 571334 in Ampoule, an AMP-based process pool implementation that we use for some job runners, and proposed a fix for that, but cherry-picking that fix into Launchpad didn’t help matters. I tried backing out subsets of my changes and determined that if both txlongpoll and txpkgupload were absent from the Python module path in the context of the tests in question then everything was fine. I tried running strace locally and staring at the output for some time in the hope of enlightenment: that reminded me that the two packages in question install modules under twisted.plugins, which did at least establish a reason they might affect the environment that was more plausible than magic, but nothing much more specific than that.

On Friday I was fiddling about with this again and trying to insert some more debugging when I noticed some interesting behaviour around plugin caching. If I caused the txpkgupload plugin to raise an exception when loaded, the Twisted plugin system would remove its dropin.cache (because it was stale) and not create a new one (because there was now no content to put in it). After that, running the relevant tests would fail as I’d seen in our buildbot. Aha! This meant that I could also reproduce it by doing an even cleaner build than I’d previously tried to do, by removing the cached txpkgupload and txlongpoll eggs and allowing the build system to recreate them. When they were recreated, they didn’t contain dropin.cache, instead allowing that to be created on first use.

Based on this clue I was able to get to the answer relatively quickly. Ampoule has a specialised bootstrapping sequence for its worker processes that starts by doing this:

from twisted.application import reactors reactors.installReactor(reactor)

Now, twisted.application.reactors.installReactor calls twisted.plugin.getPlugins, so the very start of this bootstrapping sequence is going to involve loading all plugins found on the module path (I assume it’s possible to write a plugin that adds an alternative reactor implementation). If dropin.cache is up to date, then it will just get the information it needs from that; but if it isn’t, it will go ahead and import the plugin. If the plugin happens (as Twisted code often does) to run from twisted.internet import reactor at some point while being imported, then that will install the platform’s default reactor, and then twisted.application.reactors.installReactor will raise ReactorAlreadyInstalledError. Since Ampoule turns this into an info-level log message for some reason, and the tests in question only passed through error-level messages or higher, this meant that all we could see was that a worker process had exited non-zero but not why.

The Twisted documentation recommends generating the plugin cache at build time for other reasons, but we weren’t doing that. Fixing that makes everything work again.

There are still a few more things needed to get us onto pip, but we’re now pretty close. After that we can finally start bringing our dependencies up to date.

Colin Watson https://www.chiark.greenend.org.uk/~cjwatson/blog/ Colin Watson's blog

Debian/TeX Live 2017.20170926-1

Mar, 26/09/2017 - 5:01md

A full month or more has past since the last upload of TeX Live, so it was high time to prepare a new package. Nothing spectacular here I have to say, two small bugs fixed and the usual long list of updates and new packages.

From the new packages I found fontloader-luaotfload and interesting project. Loading fonts via lua code in luatex is by now standard, and this package allows for experiments with newer/alternative font loaders. Another very interesting new-comer is pdfreview which lets you set pages of another PDF on a lined background and add notes to it, good for reviewing.

Enjoy.

New packages

abnt, algobox, beilstein, bib2gls, cheatsheet, coelacanth, dijkstra, dynkin-diagrams, endofproofwd, fetchcls, fixjfm, fontloader-luaotfload, forms16be, hithesis, ifxptex, komacv-rg, ku-template, latex-refsheet, limecv, mensa-tex, multilang, na-box, notes-tex, octave, pdfreview, pst-poker, theatre, upzhkinsoku, witharrows.

Updated packages

2up, acmart, acro, amsmath, animate, babel, babel-french, babel-hungarian, bangorcsthesis, beamer, beebe, biblatex-gost, biblatex-philosophy, biblatex-source-division, bibletext, bidi, bpchem, bxjaprnind, bxjscls, bytefield, checkcites, chemmacros, chet, chickenize, complexity, curves, cweb, datetime2-german, e-french, epstopdf, eqparbox, esami, etoc, fbb, fithesis, fmtcount, fnspe, fontspec, genealogytree, glossaries, glossaries-extra, hvfloat, ifptex, invoice2, jfmutil, jlreq, jsclasses, koma-script, l3build, l3experimental, l3kernel, l3packages, latexindent, libertinust1math, luatexja, lwarp, markdown, mcf2graph, media9, nddiss, newpx, newtx, novel, numspell, ocgx2, philokalia, phfqit, placeat, platex, poemscol, powerdot, pst-barcode, pst-cie, pst-exa, pst-fit, pst-func, pst-geometrictools, pst-ode, pst-plot, pst-pulley, pst-solarsystem, pst-solides3d, pst-tools, pst-vehicle, pst2pdf, pstricks, pstricks-add, ptex-base, ptex-fonts, pxchfon, quran, randomlist, reledmac, robustindex, scratch, skrapport, spectralsequences, tcolorbox, tetex, tex4ht, texcount, texdef, texinfo, texlive-docindex, texlive-scripts, tikzducks, tikzsymbols, tocloft, translations, updmap-map, uplatex, widetable, xepersian, xetexref, xint, xsim, zhlipsum.

Norbert Preining https://www.preining.info/blog There and back again

Reproducible Builds: Weekly report #126

Mar, 26/09/2017 - 9:22pd

Here's what happened in the Reproducible Builds effort between Sunday September 17th and Saturday September 23rd 2017:

Media coverage
  • Christos Zoulas gave a talk entitled Reproducible builds on NetBSD at EuroBSDCon 2017
Reproducible work in other packages Packages reviewed and fixed, and bugs filed Reviews of unreproducible packages

1 package reviews was added, 49 have been updated and 54 have been removed in this week, adding to our knowledge about identified issues.

One issue type was updated:

Weekly QA work

During our reproducibility testing, FTBFS bugs have been detected and reported by:

  • Adrian Bunk (56)
  • Bas Couwenberg (1)
  • Helmut Grohne (1)
  • Nobuhiro Iwamatsu (2)
diffoscope development

Version 87 was uploaded to unstable by Mattia Rizzolo. It included contributions from:

strip-nondeterminism development reprotest development

Version 0.7 was uploaded to unstable by Ximin Luo:

tests.reproducible-builds.org

Vagrant Cascadian and Holger Levsen:

  • Re-add and armhf build node that had been disabled due to performance issues, but works linux 4.14-rc1 now! #876212

Holger Levsen:

Misc.

This week's edition was written by Bernhard M. Wiedemann, Chris Lamb, Vagrant Cascadian & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Reproducible builds folks https://reproducible.alioth.debian.org/blog/ Reproducible builds blog

Review: Artemis Fowl

Mar, 26/09/2017 - 6:36pd

Review: Artemis Fowl, by Eoin Colfer

Series: Artemis Fowl #1 Publisher: Disney-Hyperion Copyright: 2001 ISBN: 1-4231-2452-9 Format: Kindle Pages: 281

Artemis Fowl is the heir to the Fowl criminal empire and a child prodigy. He's also one of the few humans to know of the existence of fairies, who are still present in the world, hiding from humans and living by their own rules. As the book opens, he's in search of those rules: a copy of the book that governs the lives of fairies. With that knowledge, he should be able to pull off a heist worthy of his family's legacy.

Captain Holly Short is a leprechaun... or, more correctly, a LEPrecon. She's one of the fairy police officers that investigate threats to the fairies who are hiding in a vast underground civilization. The fairies have magic, but they also have advanced (and miniaturized) technology, maintained in large part by a grumpy and egotistical centaur (named Foaly, because it's that sort of book). She's also the fairy unlucky enough to be captured by Artemis's formidable personal bodyguard their first attempt to kidnap a hostage for their ransom demands.

This is the first book of a long series of young adult novels that has also spawned graphic novels and a movie currently in production. It has that lean and clear feeling of the younger side of young adult writing: larger-than-life characters who are distinctive and easy to remember, a short introductory setup that dives directly into the main plot, and a story that neatly pulls together every element raised in the story. The world-building is its strongest point, particularly the mix of tongue-in-cheek technology — ships that ride magma plumes, mechanical wings, and helmet-mounted lights to blind trolls — and science-tinged magic that the fairies build their police and army on. Fairies are far beyond humans in capability, and can be deadly and ruthless, but they have to follow a tightly constrained set of rules that are often not convenient.

Sadly, the characters don't live up to the world-building. I did enjoy a few of them, particularly Artemis's loyal bodyguards and the dwarf Mulch Diggums. But Holly, despite being likable, is a bit of a blank slate: the empathetic, overworked trooper who is mostly indistinguishable from other characters in similar stories. The gruff captain, the sarcastic technician Foaly, and the various other LEP agents all felt like they were taken straight from central casting. And then there's Artemis himself.

Artemis is the protagonist of the story, in that he's the one who initiates all of the action and the one who has the most interesting motivations. The story is about him, as the third-person narrator in the introduction makes clear. He's trying very hard to be a criminal genius with the deductive abilities of Sherlock Holmes and the speaking style of a Bond villain, but he's also twelve, his father has disappeared, and his mother is going slowly insane. I picked this book up on the recommendation of another reader who found that contrast compelling.

Unfortunately, I thought Artemis was just an abusive jerk. Yes, yes, family tragedy, yes, he's trapped in his conception of himself, but he's arrogant, utterly uncaring about how his actions affect other people, and dismissive and cruel even to his bodyguards (who are much better friends than he deserves). I think liking this book requires liking Artemis at least well enough to consider him an anti-hero, and I can squint and see that appeal if you have that reaction. But I just wanted him to lose. Not in the "you will be slowly redeemed over the course of a long series" way, but in the "you are a horrible person and I hope you get what's coming to you" way. The humor of the fairy parts of the book was undermined too much by the fact that many of them would like to kill Artemis for real, and I mostly wanted them to succeed.

This may or may not have to do with my low tolerance for egotistical smart-asses who order other people to do things that they refuse to explain.

Without some appreciation for Artemis, this is a story with some neat world-building, a fairly generic protagonist in Holly, and a plot in which the bad guys win. To make matters worse, I thought the supposedly bright note at the end of the story was just creepy, as was everything else involving Artemis's mother. The review I read was of the first three books, so it's entirely possible that this series gets better as it goes along, but there wasn't enough I enjoyed in the first book for me to keep reading.

Followed by Artemis Fowl: The Arctic Incident.

Rating: 5 out of 10

Russ Allbery https://www.eyrie.org/~eagle/ Eagle's Path

Started work on an internet-of-things Radio

Hën, 25/09/2017 - 11:00md

So recently I was in York at the Bytemark office, and I read a piece about building a radio in a Raspberry Pi magazine. It got me curious, so when I got home to sunny Helsinki I figured I'd have a stab at it.

I don't have fixed goal in mind, but what I do have is:

  • A WeMos Mini D1
    • Cost €3.00
    • ESP8266-powered board, which can be programmed easily in C++ and contains on-board WiFi as well as a bunch of I/O pins.
  • A RDA5807M FM Radio chip.
    • Cost 37 cents.
    • With a crystal for support.

The initial goal is simple wire the receiver/decoder to the board, and listen to the radio.

After that there are obvious extenstions, such as adding an LCD display to show the frequency (What's the frequency Kenneth), and later to show the station details, via RDS.

Finally I could add some buttons/switches/tweaks for selecting next/previous stations, and adjusting the volume. Initially that'll be handled by pointing a browser at the IP-address of the device.

The first attempt at using the RDA5807M chip was a failure, as the thing was too damn small and non-standardly sized. Adding header-pins to the chips was almost impossible, and when I did get them soldered on the thing just gave me static-hisses.

However I later read the details of the chip more carefully and realized that it isn't powerfull enough to drive (even) headphones. It requires an amp of some kind. With that extra knowledge I was able to send the output to the powered-speakers I have sat beside my PC.

My code is basic, it sets up the FM-receiver/decoder, and scans the spectrum. When it finds a station it outputs the name over the serial console, via RDS, and then just plays it.

I've got an PAM8403-based amplifier board on-order, when that arrives I'll get back to the project, and hookup WiFi and a simple web-page to store stations, tuning, etc.

My "token goal" at the moment is a radio that switches on at 7AM and switches off at 8AM. In addition to that it'll serve a web-page allowing interactive control, regardless of any buttons that are wired in.

I also have another project in the wings. I've ordered a software-defined radio (USB-toy) which I'm planning to use to plot aircraft in real-time, as they arrive/depart/fly over Helsinki. No doubt I'll write that up too.

Steve Kemp https://blog.steve.fi/ Steve Kemp's Blog

Lintian: We are all Perl developers now

Hën, 25/09/2017 - 6:26md

Lintian is a static analysis tool for Debian packages, reporting on various errors, omissions and general quality-assurance issues to maintainers.

I've previously written about my exploits with Lintian as well as authoring a short tutorial on how to write your own Lintian check.

Anyway, I recently uploaded version 2.5.53 about two months since previous release. The biggest changes you may notice are supporting the latest version of the Debian Policy as well the addition of checks to encourage the migration to Python 3.

Thanks to all who contributed patches, code review and bug reports to this release. The full changelog is as follows:

lintian (2.5.53) unstable; urgency=medium The "we are all Perl developers now" release. * Summary of tag changes: + Added: - alternatively-build-depends-on-python-sphinx-and-python3-sphinx - build-depends-on-python-sphinx-only - dependency-on-python-version-marked-for-end-of-life - maintainer-script-interpreter - missing-call-to-dpkg-maintscript-helper - node-package-install-in-nodejs-rootdir - override-file-in-wrong-package - package-installs-java-bytecode - python-foo-but-no-python3-foo - script-needs-depends-on-sensible-utils - script-uses-deprecated-nodejs-location - transitional-package-should-be-oldlibs-optional - unnecessary-testsuite-autopkgtest-header - vcs-browser-links-to-empty-view + Removed: - debug-package-should-be-priority-extra - missing-classpath - transitional-package-should-be-oldlibs-extra * checks/apache2.pm: + [CL] Fix an apache2-unparsable-dependency false positive by allowing periods (".") in dependency names. (Closes: #873701) * checks/binaries.pm: + [CL] Apply patches from Guillem Jover & Boud Roukema to improve the description of the binary-file-built-without-LFS-support tag. (Closes: #874078) * checks/changes.{pm,desc}: + [CL] Ignore DFSG-repacked packages when checking for upstream source tarball signatures as they will never match by definition. (Closes: #871957) + [CL] Downgrade severity of orig-tarball-missing-upstream-signature from "E:" to "W:" as many common tools do not make including the signatures easy enough right now. (Closes: #870722, #870069) + [CL] Expand the explanation of the orig-tarball-missing-upstream-signature tag to include the location of where dpkg-source will look. Thanks to Theodore Ts'o for the suggestion. * checks/copyright-file.pm: + [CL] Address a number of issues in copyright-year-in-future: - Prevent false positives in port numbers, email addresses, ISO standard numbers and matching specific and general street addresses. (Closes: #869788) - Match all violating years in a line, not just the first (eg. "2000-2107"). - Ignore meta copyright statements such as "Original Author". Thanks to Thorsten Alteholz for the bug report. (Closes: #873323) - Expand testsuite. * checks/cruft.{pm,desc}: + [CL] Downgrade severity of file-contains-fixme-placeholder tag from "important" (ie. "E:") to "wishlist" (ie. "I:"). Thanks to Gregor Herrmann for the suggestion. + [CL] Apply patch from Alex Muntada (alexm) to use "substr" instead of "substring" in mentions-deprecated-usr-lib-perl5-directory's description. (Closes: #871767) + [CL] Don't check copyright_hints file for FIXME placeholders. (Closes: #872843) + [CL] Don't match quoted "FIXME" variants as they are almost always deliberate. Thanks to Adrian Bunk for the report. (Closes: #870199) + [CL] Avoid false positives in missing source checks for "CSS Browser Selector". (Closes: #874381) * checks/debhelper.pm: + [CL] Prevent a false positive of missing-build-dependency-for-dh_-command that can be exposed by following the advice for the recently added useless-autoreconf-build-depends tag. (Closes: #869541) * checks/debian-readme.{pm,desc}: + [CL] Ensure readme-debian-contains-debmake-template also checks for templates "Automatically generated by debmake". * checks/description.{desc,pm}: + [CL] Clarify explanation of description-starts-with-leading-spaces tag. Thanks to Taylor Kline for the report and patch. (Closes: #849622) + [NT] Skip capitalization-error-in-description-synopsis for auto-generated packages (such as dbgsym packages). * checks/fields.{desc,pm}: + [CL] Ensure that python3-foo packages have "Section: python", not just python2-foo. (Closes: #870272) + [RG] Do no longer require debug packages to be priority extra. + [BR] Use Lintian::Data for name/section mapping + [CL] Check for packages including "?rev=0&sc=0" in Vcs-Browser. (Closes: #681713) + [NT] Transitional packages should now be "oldlibs/optional" rather than "oldlibs/extra". The related tag has been renamed accordingly. * checks/filename-length.pm: + [NT] Skip the check on auto-generated binary packages (such as dbgsym packages). * checks/files.{pm,desc}: + [BR] Avoid privacy-breach-generic false positives for legal.xml. + [BR] Detect install of node package under /usr/lib/nodejs/[^/]*$ + [CL] Check for packages shipping compiled Java class files. Thanks Carnë Draug . (Closes: #873211) + [BR] Privacy breach is no longer experimental. * checks/init.d.desc: + [RG] Do not recommend a versioned dependency on lsb-base in init.d-script-needs-depends-on-lsb-base. (Closes: #847144) * checks/java.pm: + [CL] Additionally consider .cljc files as code to avoid false- positive codeless-jar warnings. (Closes: #870649) + [CL] Drop problematic missing-classpath check. (Closes: #857123) * checks/menu-format.desc: + [CL] Prevent false positives in desktop-entry-lacks-keywords-entry for "Link" and "Directory" .desktop files. (Closes: #873702) * checks/python.{pm,desc}: + [CL] Split out Python checks from "scripts" check to a new, source check of type "source". + [CL] Check for python-foo without corresponding python3-foo packages to assist in Python 2.x deprecation. (Closes: #870681) + [CL] Check for packages that Build-Depend on python-sphinx only. (Closes: #870730) + [CL] Check for packages that alternatively Build-Depend on the Python 2 and Python 3 versions of Sphinx. (Closes: #870758) + [CL] Check for binary packages that depend on Python 2.x. (Closes: #870822) * checks/scripts.pm: + [CL] Correct false positives in unconditional-use-of-dpkg-statoverride by detecting "if !" as a valid shell prefix. (Closes: #869587) + [CL] Check for missing calls to dpkg-maintscript-helper(1) in maintainer scripts. (Closes: #872042) + [CL] Check for packages using sensible-utils without declaring a dependency after its split from debianutils. (Closes: #872611) + [CL] Warn about scripts using "nodejs" as an interpreter now that nodejs provides /usr/bin/node. (Closes: #873096) + [BR] Add a statistic tag giving interpreter. * checks/testsuite.{desc,pm}: + [CL] Remove recommendations to add a "Testsuite: autopkgtest" field to debian/control as it is added when needed by dpkg-source(1) since dpkg 1.17.1. (Closes: #865531) + [CL] Warn if we see an unnecessary "Testsuite: autopkgtest" header in debian/control. + [NT] Recognise "autopkgtest-pkg-go" as a valid test suite. + [CL] Recognise "autopkgtest-pkg-elpa" as a valid test suite. (Closes: #873458) + [CL] Recognise "autopkgtest-pkg-octave" as a valid test suite. (Closes: #875985) + [CL] Update the description of unknown-testsuite to reflect that "autopkgtest" is not the only valid value; the referenced URL is out-of-date (filed as #876008). (Closes: #876003) * data/binaries/embedded-libs: + [RG] Detect embedded copies of heimdal, libgxps, libquicktime, libsass, libytnef, and taglib. + [RG] Use an additional string to detect embedded copies of openjpeg2. (Closes: #762956) * data/fields/name_section_mappings: + [BR] node- package section is javascript. + [CL] Apply patch from Guillem Jover to add more section mappings. (Closes: #874121) * data/fields/obsolete-packages: + [MR] Add dh-systemd. (Closes: #872076) * data/fields/perl-provides: + [CL] Refresh perl provides. * data/fields/virtual-packages: + [CL] Update data file from archive. This fixes a false positive for "bacula-director". (Closes: #835120) * data/files/obsolete-paths: + [CL] Add note to /etc/bash_completion.d entry regarding stricter filename requirements. (Closes: #814599) * data/files/privacy-breaker-websites: + [BR] Detect custom donation logos like apache. + [BR] Detect generic counter website. * data/standards-version/release-dates: + [CL] Add 4.0.1 and 4.1.0 as known standards versions. (Closes: #875509) * debian/control: + [CL] Mention Debian Policy v4.1.0 in the description. + [CL] Add myself to Uploaders. + [CL] Drop unnecessary "Testsuite: autopkgtest"; this is implied from debian/tests/control existing. * commands/info.pm: + [CL] Add a --list-tags option to print all tags Lintian knows about. Thanks to Rajendra Gokhale for the suggestion. (Closes: #779675) * commands/lintian.pm: + [CL] Apply patch from Maia Everett to avoid British spelling when using en_US locale. (Closes: #868897) * lib/Lintian/Check.pm: + [CL] Stop emitting {maintainer,uploader}-address-causes-mail-loops for @packages.debian.org addresses. (Closes: #871575) * lib/Lintian/Collect/Binary.pm: + [NT] Introduce an "auto-generated" argument for "is_pkg_class". * lib/Lintian/Data.pm: + [CL] Modify Lintian::Data's "all" to always return keys in insertion order, dropping dependency on libtie-ixhash-perl. * helpers/coll/objdump-info-helper: + [CL] Apply patch from Steve Langasek to accommodate binutils 2.29 outputting symbols in a different format on ppc64el. (Closes: #869750) * t/tests/fields-perl-provides/tags: + [CL] Update expected output to match new Perl provides. * t/tests/files-privacybreach/*: + [CL] Add explicit test for packages including external fonts via the Google Font API. Thanks to Ian Jackson for the report. (Closes: #873434) + [CL] Add explicit test for packages including external fonts via the Typekit API via <script/> HTML tags. * t/tests/*/desc: + [CL] Add missing entries in "Test-For" fields to make development/testing workflow less error-prone. * private/generate-tag-summary: + [CL] git-describe(1) will usually emit 7 hexadecimal digits as the abbreviated object name, However, as this can be user-dependent, pass --abbrev=0 to ensure it does not vary between systems. This also means we do not need to strip it ourselves. * private/refresh-*: + [CL] Use deb.debian.org as the default mirror. + [CL] Update locations of Contents-<arch> files; they are now namespaced by distribution (eg. "main"). -- Chris Lamb <lamby@debian.org> Wed, 20 Sep 2017 09:25:06 +0100

Chris Lamb https://chris-lamb.co.uk/blog/category/planet-debian lamby: Items or syndication on Planet Debian.

Recruiting for Open Source jobs

Hën, 25/09/2017 - 3:34md

Part of services of Kaplan open source consulting is recruiting services to help companies find good open source people. In addition, we also try to help the community to find open source friendly businesses to work at.

Expect the “Usual Suspects” (e.g. RedHat), I encounter job descriptions which convince me these companies know the advantages of using open source projects and hiring open source people.

A few recent examples I found in Israel:

  • Advantages: People who like to build stuff (we really like people who maintain/contribute to open source projects) (Wizer Research)
  • You will: Incubate and contribute to open source projects (iguazio)
  • The X factor – significant contribution to an open-source community (unnamed startup)
  • An example open source project our team released is CoreML (Apple)
  • Job Responsibilities: Write open-source tools and contribute to open-source projects. (unnamed startup)
  • We’d like to talk to people who: Appreciate open-source culture and philosophy. (Seeking Alpha)

From the applicant side, the possibility to know which code base he or she is going to work on could help do a better and more educated choice about the offered position. While from the company side, getting “hard” evidence of what are the applicant capabilities and code looks like instead of just describing them or trying to demonstrate them on short tests. Not to mention the applicant’s ability to work as part of a team or community.

For the Israeli readers, you can see the full list at https://kaplanopensource.co.il/jobs/


Filed under: Israeli Community, Open source businesses Kaplan https://liorkaplan.wordpress.com Free Software Universe

APT 1.5 is out

Dje, 24/09/2017 - 9:32md

APT 1.5 is out, after almost 3 months the release of 1.5 alpha 1, and almost six months since the release of 1.4 on April 1st. This release cycle was unusually short, as 1.4 was the stretch release series and the zesty release series, and we waited for the latter of these releases before we started 1.5. In related news, 1.4.8 hit stretch-proposed-updates today, and is waiting in the unapproved queue for zesty.

This release series moves https support from apt-transport-https into apt proper, bringing with it support for https:// proxies, and support for autodetectproxy scripts that return http, https, and socks5h proxies for both http and https.

Unattended updates and upgrades now work better: The dependency on network-online was removed and we introduced a meta wait-online helper with support for NetworkManager, systemd-networkd, and connman that allows us to wait for network even if we want to run updates directly after a resume (which might or might not have worked before, depending on whether update ran before or after network was back up again). This also improves a boot performance regression for systems with rc.local files:

The rc.local.service unit specified After=network-online.target, and login stuff was After=rc.local.service, and apt-daily.timer was Wants=network-online.target, causing network-online.target to be pulled into the boot and the rc.local.service ordering dependency to take effect, significantly slowing down the boot.

An earlier less intrusive variant of that fix is in 1.4.8: It just moves the network-online.target Want/After from apt-daily.timer to apt-daily.service so most boots are uncoupled now. I hope we get the full solution into stretch in a later point release, but we should gather some experience first before discussing this with the release time.

Balint Reczey also provided a patch to increase the time out before killing the daily upgrade service to 15 minutes, to actually give unattended-upgrades some time to finish an in-progress update. Honestly, I’d have though the machine hung up and force rebooted it after 5 seconds already. (this patch is also in 1.4.8)

We also made sure that unreadable config files no longer cause an error, but only a warning, as that was sort of a regression from previous releases; and we added documentation for /etc/apt/auth.conf, so people actually know the preferred way to place sensitive data like passwords (and can make their sources.list files world-readable again).

We also fixed apt-cdrom to support discs without MD5 hashes for Sources (the Files field), and re-enabled support for udev-based detection of cdrom devices which was accidentally broken for 4 years, as it was trying to load libudev.so.0 at runtime, but that library had an SONAME change to libudev.so.1 – we now link against it normally.

Furthermore, if certain information in Release files change, like the codename, apt will now request confirmation from the user, avoiding a scenario where a user has stable in their sources.list and accidentally upgrades to the next release when it becomes stable.

Paul Wise contributed patches to allow configuring the apt-daily intervals more easily – apt-daily is invoked twice a day by systemd but has more fine-grained internal timestamp files. You can now specify the intervals in seconds, minutes, hours, and day units, or specify “always” to always run (that is, up to twice a day on systemd, once per day on non-systemd platforms).

Development for the 1.6 series has started, and I intent to upload a first alpha to unstable in about a week, removing the apt-transport-https package and enabling compressed index files by default (save space, a lot of space, at not much performance cost thanks to lz4). There will also be some small clean ups in there, but I don’t expect any life-changing changes for now.

I think our new approach of uploading development releases directly to unstable instead of parking them in experimental is working out well. Some people are confused why alpha releases appear in unstable, but let me just say one thing: These labels basically just indicate feature-completeness, and not stability. An alpha is just very likely to get a lot more features, a beta is less likely (all the big stuff is in), and the release candidates just fix bugs.

Also, we now have 3 active stable series: The 1.2 LTS series, 1.4 medium LTS, and 1.5. 1.2 receives updates as part of Ubuntu 16.04 (xenial), 1.4 as part of Debian 9.0 (stretch) and Ubuntu 17.04 (zesty); whereas 1.5 will only be supported for 9 months (as part of Ubuntu 17.10). I think the stable release series are working well, although 1.4 is a bit tricky being shared by stretch and zesty right now (but zesty is history soon, so …).


Filed under: Debian, Ubuntu Julian Andres Klode https://juliank.wordpress.com Blog of Julian Andres Klode

RcppGSL 0.3.3

Dje, 24/09/2017 - 5:41md

A maintenance update RcppGSL 0.3.3 is now on CRAN. It switched the vignette to the our new pinp package and its two-column pdf default.

The RcppGSL package provides an interface from R to the GNU GSL using the Rcpp package.

No user-facing new code or features were added. The NEWS file entries follow below:

Changes in version 0.3.3 (2017-09-24)

  • We also check for gsl-config at package load.

  • The vignette now uses the pinp package in two-column mode.

  • Minor other fixes to package and testing infrastructure.

Courtesy of CRANberries, a summary of changes to the most recent release is available.

More information is on the RcppGSL page. Questions, comments etc should go to the issue tickets at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel http://dirk.eddelbuettel.com/blog Thinking inside the box

Easier recipe to observe the cell phones around you

Dje, 24/09/2017 - 8:30pd

A little more than a month ago I wrote how to observe the SIM card ID (aka IMSI number) of mobile phones talking to nearby mobile phone base stations using Debian GNU/Linux and a cheap USB software defined radio, and thus being able to pinpoint the location of people and equipment (like cars and trains) with an accuracy of a few kilometer. Since then we have worked to make the procedure even simpler, and it is now possible to do this without any manual frequency tuning and without building your own packages.

The gr-gsm package is now included in Debian testing and unstable, and the IMSI-catcher code no longer require root access to fetch and decode the GSM data collected using gr-gsm.

Here is an updated recipe, using packages built by Debian and a git clone of two python scripts:

  1. Start with a Debian machine running the Buster version (aka testing).
  2. Run 'apt install gr-gsm python-numpy python-scipy python-scapy' as root to install required packages.
  3. Fetch the code decoding GSM packages using 'git clone github.com/Oros42/IMSI-catcher.git'.
  4. Insert USB software defined radio supported by GNU Radio.
  5. Enter the IMSI-catcher directory and run 'python scan-and-livemon' to locate the frequency of nearby base stations and start listening for GSM packages on one of them.
  6. Enter the IMSI-catcher directory and run 'python simple_IMSI-catcher.py' to display the collected information.

Note, due to a bug somewhere the scan-and-livemon program (actually its underlying program grgsm_scanner) do not work with the HackRF radio. It does work with RTL 8232 and other similar USB radio receivers you can get very cheaply (for example from ebay), so for now the solution is to scan using the RTL radio and only use HackRF for fetching GSM data.

As far as I can tell, a cell phone only show up on one of the frequencies at the time, so if you are going to track and count every cell phone around you, you need to listen to all the frequencies used. To listen to several frequencies, use the --numrecv argument to scan-and-livemon to use several receivers. Further, I am not sure if phones using 3G or 4G will show as talking GSM to base stations, so this approach might not see all phones around you. I typically see 0-400 IMSI numbers an hour when looking around where I live.

I've tried to run the scanner on a Raspberry Pi 2 and 3 running Debian Buster, but the grgsm_livemon_headless process seem to be too CPU intensive to keep up. When GNU Radio print 'O' to stdout, I am told there it is caused by a buffer overflow between the radio and GNU Radio, caused by the program being unable to read the GSM data fast enough. If you see a stream of 'O's from the terminal where you started scan-and-livemon, you need a give the process more CPU power. Perhaps someone are able to optimize the code to a point where it become possible to set up RPi3 based GSM sniffers? I tried using Raspbian instead of Debian, but there seem to be something wrong with GNU Radio on raspbian, causing glibc to abort().

Petter Reinholdtsen http://people.skolelinux.org/pere/blog/ Petter Reinholdtsen - Entries tagged english

Faqet

Alblinux.net mundësohet nga Drupal.