Search Results: "Ricardo Mones"

22 November 2021

Ricardo Mones: Claws Mail 4 in experimental

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).

8 October 2017

Ricardo Mones: Cannot enable. Maybe the USB cable is bad?

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!

28 September 2017

Ricardo Mones: Long time no post

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.

22 May 2016

Reproducible builds folks: Reproducible builds: week 56 in Stretch cycle

What happened in the Reproducible Builds effort between May 15th and May 21st 2016: Media coverage Blog posts from our GSoC and Outreachy contributors: Documentation update Ximin Luo clarified instructions on how to set SOURCE_DATE_EPOCH. Toolchain fixes Other upstream fixes 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: Some uploads have fixed some reproducibility issues, but not all of them: Patches submitted that have not made their way to the archive yet: Reproducibility-related bugs filed: Package reviews 51 reviews have been added, 19 have been updated and 15 have been removed in this week. 22 FTBFS bugs have been reported by Chris Lamb, Santiago Vila, Niko Tyni and Daniel Schepler. tests.reproducible-builds.org Misc. This week's edition was written by Reiner Herrmann and Holger Levsen and reviewed by a bunch of Reproducible builds folks on IRC.

25 April 2016

Ricardo Mones: Maximum number of clients reached Error: Can't open display: :0

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 :-(

26 May 2015

Ricardo Mones: Downgrading to stable

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 :-)

4 May 2015

Ricardo Mones: Bye bye DebConf15

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!

29 July 2014

Ricardo Mones: Switching PGP keys

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!

5 February 2014

Ricardo Mones: Fixing partridge eggs with industrial duct tape

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 ;-).

26 November 2013

Ricardo Mones: Shared memory crazyness

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 ;-)

9 November 2013

Ricardo Mones: The Debian Project...

...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.

20 October 2013

Ricardo Mones: Forced to 3.11

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 ;-)