A full month has passed since Claws Mail 4.0.0 was uploaded to Debian experimental, and, somewhat surprisingly, I've received no bug report about it. This of course can be either because nobody has been brave enough to install it or because well, it works really nice. For those who don't know what I'm talking about, just note that this version is the first Debian upload for the GTK+3 version of Claws Mail. There was an initial upstream release, namely 3.99, but it was less polished and also I was very busy, so I decided not to upload it. Since then I've been using git's 'gtk3' branch daily without problems, so, for me, it's as stable as its GTK+2 counterpart. There's still some rough edges, of course. Note also that, if everything goes well, Claws Mail 4.x will be the version to be shipped with Debian 12 (bookworm).

One of the reasons which made me switch my old 17" BenQ monitor for a Dell U2413 three years ago was it had an integrated SD card reader. I find very convenient to take camera's card out, plug the card into the monitor and click on KDE device monitor's option Open with digiKam to download the photos or videos.

But last week, when trying to reconnect the USB cable to the new board just didn't work and the kernel log messages were not very hopeful:

[190231.770349] usb 2-2.3.3: new SuperSpeed USB device number 15 using xhci_hcd
[190231.890439] usb 2-2.3.3: New USB device found, idVendor=0bda, idProduct=0307
[190231.890444] usb 2-2.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[190231.890446] usb 2-2.3.3: Product: USB3.0 Card Reader
[190231.890449] usb 2-2.3.3: Manufacturer: Realtek
[190231.890451] usb 2-2.3.3: SerialNumber: F141000037E1
[190231.896592] usb-storage 2-2.3.3:1.0: USB Mass Storage device detected
[190231.896764] scsi host8: usb-storage 2-2.3.3:1.0
[190232.931861] scsi 8:0:0:0: Direct-Access     Generic- SD/MMC/MS/MSPRO  1.00 PQ: 0 ANSI: 6
[190232.933902] sd 8:0:0:0: Attached scsi generic sg5 type 0
[190232.937989] sd 8:0:0:0: [sde] Attached SCSI removable disk
[190243.069680] hub 2-2.3:1.0: hub_ext_port_status failed (err = -71)
[190243.070037] usb 2-2.3-port3: cannot reset (err = -71)
[190243.070410] usb 2-2.3-port3: cannot reset (err = -71)
[190243.070660] usb 2-2.3-port3: cannot reset (err = -71)
[190243.071035] usb 2-2.3-port3: cannot reset (err = -71)
[190243.071409] usb 2-2.3-port3: cannot reset (err = -71)
[190243.071413] usb 2-2.3-port3: Cannot enable. Maybe the USB cable is bad?
...

I was sure USB 3.0 ports were working, because I've already used them with a USB 3.0 drive, so first thought was the monitor USB hub had failed. It seemed unlikely that a cable which has not been moved in 3 years was suddenly failing, is that even possible?

But a few moments later the same cable plugged into a USB 2.0 worked flawlessly and all photos could be downloaded, just noticeably slower.

A bit confused, and thinking that, since everything else was working maybe the cable had to be replaced, it happened I upgraded the system in the meantime. And luck came into rescue, because now it works again in 4.9.30-2+deb9u5 kernel. Looking at the package changelog it seems the fix was this usb:xhci:Fix regression when ATI chipsets detected . So, not a bad cable but a little kernel bug ;-)

Thanks to all involved, specially Ben for the package update!

Seems the breakage of my desktop computer more than 3 months ago did also caused also a hiatus on my online publishing activities... it was not really intended, it happened I was just busy with other things _ .

With a broken computer being able to build software on the laptop became a priority. Around September 2016 or so the good'n'old black MacBook decided to stop working. I didn't really need a replacement by that time, but never liked to have just a single working system, and in October just found an offer which I could not resist and bought a ThinkPad X260. It helped to build my final project (it was faster than the desktop), but lacking time for FOSS hadn't used it for much more.

Setting up the laptop for software (Debian packages and Claws Mail, mainly) was somewhat easy. Finding a replacement for the broken desktop was a bit more difficult. I considered a lot of configurations and prices, from those new Ryzen to just buying the same components (pretty difficult now because they're discontinued). In the end, I decided to spend the minimum and make good use of everything else still working (memory, discs and wireless card), so I finally got an AMD A10-7860K on top of an Asus A88M-PLUS. This board has more SATA ports, so I added an unused SSD, remains of a broken laptop, to install the new system Debian Stretch, of course while keeping the existing software RAID partitions of the spinning drives.


The last thing distracting from the usual routine was replacing the car. Our child is growing as expected and the Fiesta was starting to appear small and uncomfortable, specially for long distance travel. We went for an hybrid model, with a high capacity boot. Given our budget, we only found 3 models below the limit: Kia Niro, Hyundai Ioniq and Toyota Auris TS. The color was decided by the kid (after forbidding black), and this was the winner...

In the middle of all of this we also took some vacation to travel to the south of Galicia, mostly around Vigo area, but also visiting Oporto and other nice places.

What happened in the Reproducible Builds effort between May 15th and May 21st 2016: Media coverage Blog posts from our GSoC and Outreachy contributors:

• Val's first post describing her plans for improving tests.reproducible-builds.org.
• ceridwen's first post describing her plans for reprotest, the universal reproducibility testing tool.
• Scarlett's and Satyam's first posts were linked in previous week's report already.

Documentation update Ximin Luo clarified instructions on how to set SOURCE_DATE_EPOCH. Toolchain fixes

• Joao Eriberto Mota Filho uploaded txt2man/1.5.6-4, which honours SOURCE_DATE_EPOCH to generate reproducible manpages (original patch by Reiner Herrmann).
• Dmitry Shachnev uploaded sphinx/1.4.1-1 to experimental with improved support for SOURCE_DATE_EPOCH (original patch by Alexis Bienven e).
• Emmanuel Bourg submitted a patch against debhelper to use a fixed username while building ant packages.

Other upstream fixes

• Doxygen merged a patch by Ximin Luo, which uses UTC as timezone for embedded timestamps.
• CMake applied a patch by Reiner Herrmann in their next branch, which sorts file lists obtained with file(GLOB).
• GNU tar 1.29 with support for --clamp-mtime has been released upstream, closing #816072, which was the blocker for #759886 "dpkg-dev: please make mtimes of packaged files deterministic" which we now hope will be closed soon.

Packages fixed The following 18 packages have become reproducible due to changes in their build dependencies: abiword angband apt-listbugs asn1c bacula-doc bittornado cdbackup fenix gap-autpgrp gerbv jboss-logging-tools invokebinder modplugtools objenesis pmw r-cran-rniftilib x-loader zsnes The following packages have become reproducible after being fixed:

• ball/1.4.3~beta1-1 by Andreas Tille.
• chrony/2.3-1 by Vincent Blut, original patch by Alexis Bienven e.
• corosync/2.3.5-7 by Ferenc W gner.
• gap-ctbllib/1r2p2.dfsg.0-3 by Bill Allombert, original patch by Alexis Bienven e.
• kdiff3/0.9.98-3 by Eike Sauer.
• netcdf-cxx/4.3.0+ds-3 by Bas Couwenberg.
• netcdf-fortran/4.4.4+ds-2 by Bas Couwenberg.
• primesieve/5.6.0+ds-2 by Jerome Benoit.
• ray/2.3.1-4 by Sascha Steinbiss.
• rocksdb/4.5.1-1 by Laszlo Boszormenyi, original patch by Chris Lamb.
• shapelib/1.3.0-8 by Bas Couwenberg.
• swift/2.7.0-3 by Ond ej Nov .
• t-coffee/11.00.8cbe486-3 by Sascha Steinbiss.
• webkit2pdf/0.3-2 by Ricardo Mones, original patch by Reiner Herrmann.
• wise/2.4.1-18 by Sascha Steinbiss.

Some uploads have fixed some reproducibility issues, but not all of them:

• bzr/2.7.0-6 by Jelmer Vernoo .
• libsdl2/2.0.4+dfsg2-1 by Manuel A. Fernandez Montecelo.
• pvm/3.4.5-13 by James Clarke.
• refpolicy/2:2.20140421-11 by Laurent Bigonville.
• subvertpy/0.9.3-4 by Jelmer Vernoo .

Patches submitted that have not made their way to the archive yet:

• #824413 against binutils by Chris Lamb: filter build user and date from test log case-insensitively
• #824452 against python-certbot by Chris Lamb: prevent PID from being embedded into documentation (forwarded upstream)
• #824453 against gtk-gnutella by Chris Lamb: use SOURCE_DATE_EPOCH for deterministic timestamp (merged upstream)
• #824454 against python-latexcodec by Chris Lamb: fix for parsing the changelog date
• #824472 against torch3 by Alexis Bienven e: sort object files while linking
• #824501 against cclive by Alexis Bienven e: use SOURCE_DATE_EPOCH as embedded build date
• #824567 against tkdesk by Alexis Bienven e: sort order of files which are parsed by mkindex script
• #824592 against twitter-bootstrap by Alexis Bienven e: use shell-independent printing
• #824639 against openblas by Alexis Bienven e: sort object files while linking
• #824653 against elkcode by Alexis Bienven e: sort list of files locale-independently
• #824668 against gmt by Alexis Bienven e: use SOURCE_DATE_EPOCH for embedded timestamp (similar patch by Bas Couwenberg already applied and forwarded upstream)
• #824808 against gdal by Alexis Bienven e: sort object files while linking
• #824951 against libtomcrypt by Reiner Herrmann: use SOURCE_DATE_EPOCH for timestamp embedded into metadata

Reproducibility-related bugs filed:

• #824420 against python-phply by ceridwen: parsetab.py file is not included when building with DEB_BUILD_OPTIONS="nocheck"
• #824572 against dpkg-dev by XImin Luo: request to export SOURCE_DATE_EPOCH in /usr/share/dpkg/*.mk.

Package reviews 51 reviews have been added, 19 have been updated and 15 have been removed in this week.

• Two new issues have been found:
  • random_order_in_static_library_by_icmake
  • timestamps_in_manpages_generated_by_latex2man

22 FTBFS bugs have been reported by Chris Lamb, Santiago Vila, Niko Tyni and Daniel Schepler. tests.reproducible-builds.org

• Icons have been added to the package test history pages (h01ger).
• Test performance and variation pages have been splitted out of the dashboard view (h01ger).
• A new pkg set has been added: packages maintained by debian-med-packaging@l.a.d.o (h01ger).
• The preliminary results for testing have improved further:
  • testing/amd64 has 20944 / 90.2% reproducible packages now,
  • testing/i386 has reached 20013 / 86.3% reproducible packages,
  • testing/armhf has come close with 19951 / 86.0%.

Misc.

• During the discussion on debian-devel about PIE, an archive rebuild was suggested by B lint R czey, and Holger Levsen suggested to coordinate this with a required archive rebuild for reproducible builds.
• Ximin Luo improved misc.git/reports (=the tools to help writing the weekly statistics for this blog) quite a bit, h01ger contributed a little too.

This week's edition was written by Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

Today it happened again: you try to open some program and nothing happens. Go to an open terminal, try again and it answers with the above message. Other days I used to reboot the session, but that's something I don't really think should be necessary.

First thought about X gone mad, but this one seems pretty well behaved:

$ lsof -p  pidof Xorg    wc -l
5

Then noticed I had a long running chromium process (a jQuery page monitoring a remote service) so tried this one as well:

$ for a in  pidof chromium ; do echo "$a " lsof -p $a   wc -l ; done
27914 5
26462 5
25350 5
24693 5
23378 5
22723 5
22165 5
21476 222
21474 1176
21443 5
21441 204
21435 546
11644 5
11626 5
11587 5
11461 5
11361 5
9833 5
9726 5

Wow, I'd bet you can guess next command ;-)

$ kill -9 21435 21441 21474 21476

This of course wiped out all chromium processes, but also fixed the problem. Suggestions for selective chromium killing welcome! But I'd better like to know why those files are not properly closed. Just relaunching chromium to write this post yields:

$ for a in  pidof chromium ; do echo "$a " lsof -p $a   wc -l ; done
11919 5
11848 222
11841 432
11815 5
11813 204
11807 398

Which looks a bit exaggerated to me :-(

This weekend I had to downgrade my home desktop to stable thanks to a strange Xorg bug which I've been unable to identify among the current ones. Both testing and sid versions seem affected and all you can see after booting is this:


The system works fine otherwise and can be accessed via ssh, but restarting kdm doesn't help to fix it, it just changes the pattern. Anyway, as explaining a toddler he cannot watch his favourite youtube cartoons because suddenly the computer screen has become an abstract art work is not easy I quickly decided to downgrade.

Downgrading went fine, using APT pinning to fix stable and apt-get update/upgrade/dist-upgrade after that, but today I noticed libreoffice stopped working with this message:

Warning: failed to launch javaldx - java may not function correctly
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libreglo.so: cannot open shared object file: No such file or directory

All I found related to that is a post on forums, which didn't help much (neither the original poster nor me). But just found the library was not missing, it was installed:

# locate libreglo.so
/usr/lib/ure/lib/libreglo.so

But that was not part of any ldconfig conf file, hence the fix was easy:

# echo '/usr/lib/ure/lib' > /etc/ld.so.conf.d/libreoffice-ure.conf
# ldconfig

And presto! libreoffice is working again :-)

Yep, I had planned to go, but given the last mail from registration seems there's a overwhelming number of sponsorship requests, so I've dediced to withdraw my request. There's lots of people doing much more important things for Debian than me which deserve that help. Having to complete my MSc project does also help to take this decision, of course.

I guess the Debian MIA meeting will have to wait for next planetary alignment ;-) well, not really, any other member of the team can set up it, hint! hint!

See you in DebConf17 or a nearby local event!

Finally I find the mood to do this, a process which started 5 years ago in DebConf 9 at C ceres by following Ana's post, of course with my preferred options and my name, not like some other ;-).

Said that, dear reader, if you have signed my old key:

1024D/C9B55DAC 2005-01-19 [expires: 2015-10-01]
Key fingerprint = CFB7 C779 6BAE E81C 3E05  7172 2C04 5542 C9B5 5DAC

And want to sign my "new" and stronger key:

4096R/DE5BCCA6 2009-07-29
Key fingerprint = 43BC 364B 16DF 0C20 5EBD  7592 1F0F 0A88 DE5B CCA6

You're welcome to do so :-)

The new key is signed with the old, and the old key is still valid, and will probably be until expiration date next year. Don't forget to gpg --recv-keys DE5BCCA6 to get the new key and gpg --refresh-keys C9B55DAC to refresh the old (otherwise it may look expired).

Debian's Keyring Team has already processed my request to add the new key, so all should keep working smoothly. Kudos to them!

Human nature is hard to change. Very hard. We can talk about it for ages, but mistakes repeat again and again. In the end it's mostly by mistakes how we learn, so I doubt this could ever be changed without losing our own nature. One of these is trying to fix some social issue with a technical measure. Unfortunately, given the technical orientation of most of the developers, this appears from time to time in our Debian private mailing list, and yesterday I realized it's our own version of Godwin's law:

As a social problem discussion grows longer in debian-private the probability of some developer proposing a technical solution aproaches one.

Not discussing about this problems in debian-private would be a good start, but of course that would only change the name of the list in the above sentence ;-).

The output of some commands explains it all.

These are the default values in a Wheezy system:

$ ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (kbytes) = 8388608
min seg size (bytes) = 1

That's not enough for all the data I want to load in a single segment, so let's start with 1Gb of shared memory:

# sysctl kernel.shmmax=1073741824 kernel.shmall=1073741824
kernel.shmmax = 1073741824
kernel.shmall = 1073741824

So now, both should be equal, isn't it?

$ ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1048576
max total shared memory (kbytes) = 4294967296
min seg size (bytes) = 1

Uh!?

A free $BEVERAGE when we met for the one which tells me what's happening here ;-)

...is reading my mind!

I didn't tell anybody, but a couple of months ago, when I finally had time at work to upgrade my work computer desktop from Squeeze to Wheezy I also switched from GNOME to XFCE. Now I read via LWN that Debian is doing the same, at least for a while :)

BTW, I knew newer GNOME was different (had seen it in Fedora 18 for example), anyway I installed it (because I was lazy enough just to apt-get dist-upgrade the box) and tried it.

Maybe it's me, becoming an old dog which doesn't want to learn new tricks, but in order to get my work done as fast as usually I had to install something usable, hence went back to XFCE. I had to manually convert GNOME panel launchers to XFCE launchers but, besides that and some missing applet I'm pretty happy with the switch.

No, not to this 3.11, but to Linux kernel 3.11.

I was aware of the #718533 bug, which happens when you have a software RAID with anything higher than 3.2.0 (mine is RAID 1 with 2 disks). At least that has been my case since I tried to upgrade, hence I was delaying upgrades again and again.

Unfortunately today things went worse when I tried to plug my USB 3.0 device on the system:

Oct 20 17:52:51 busgosu kernel: [20799.672127] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command
Oct 20 17:52:51 busgosu kernel: [20799.876136] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20799.876148] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080148] usb 2-2: device not accepting address 2, error -12
Oct 20 17:52:51 busgosu kernel: [20800.080202] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20800.080209] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080221] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20800.080227] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080235] hub 2-0:1.0: couldn't allocate port 2 usb_device
Oct 20 17:52:53 busgosu kernel: [20801.568169] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:53 busgosu kernel: [20801.568181] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:53 busgosu kernel: [20801.568190] hub 2-0:1.0: couldn't allocate port 2 usb_device

And of course the device didn't show up. As there's not much relevant stuff about this issue on the googlesphere, thought it may have been solved. And turned out that I was right: upgrading fixes this, and now the device works again.

But, hit by the above bug now I have to add a rootdelay=1 to my kernel boot parameters (started testing with 5 but finally seems one second is enough). Fortunately the Ubuntu folks have detailed how to do it ;-)