Several people have been asking me to explain and/or write about my solution for chatting nowadays. I realize that the current scenario is much more complex than, say, 10 or 20 years ago. Back then, this post would probably be more about the IRC client I used than about different chatting technologies. I have also spent a non trivial amount of time setting things up the way I want, so I understand that it’s about time to write about my setup not only because I think it can be helpful to others, but also because I would like to document things for myself.

As promised in the last post, I have now orphaned the Pagure Debian package. Here’s the full text I posted on the BTS: After several years, I finally decided to orphan pagure :-(. I haven’t been using it as my personal forge anymore, and unfortunately upstream development slowed down quite a bit after the main author and maintainer stopped contributing regularly to the project. But that is not to say that upstream is dead; they are still working towards preparing the next release.

I have been thinking more and more about orphaning the Pagure Debian package. I don’t have the time to maintain it properly anymore, and I have also lost interest in doing so. What’s Pagure Pagure is a git forge written entirely in Python using pygit2. It was almost entirely developed by one person, Pierre-Yves Chibon. He is (was?) a Red Hat employee and started working on this new git forge almost 10 years ago because the company wanted to develop something in-house for Fedora.

It’s been a while since I had this idea to leverage the power of WireGuard to self-host stuff at home. Even though I pay for a proper server somewhere in the world, there are some services that I don’t consider critical to put there, or that I consider too critical to host outside my home. It’s only NATural With today’s ISP packages for end users, I find it very annoying the amount of trouble they create when you try to host anything at home.

You might remember that in my last post about the Ubuntu debuginfod service I talked about wanting to extend it and make it index and serve source code from packages. I’m excited to announce that this is now a reality since the Ubuntu Lunar (23.04) release. The feature should work for a lot of packages from the archive, but not all of them. Keep reading to better understand why. The problem While debugging a package in Ubuntu, one of the first steps you need to take is to install its source code.

These past couple of months I have been working to bring debuginfod to Ubuntu. I thought it would be a good idea to make this post and explain a little bit about what the service is and how I’m planning to deploy it. A quick recap: what’s debuginfod? Here’s a good summary of what debuginfod is: debuginfod is a new-ish project whose purpose is to serve ELF/DWARF/source-code information over HTTP. It is developed under the elfutils umbrella.

This is a quick public announcement to say that I am not on the Freenode IRC network anymore. My nickname (sergiodj), which was more than a decade old, has just been deleted (along with every other nickname and channel in that network) from their database today, 2021-06-14. For your safety, you should assume that everybody you knew at Freenode is not there either, even if you see their nicknames online. Do not trust without verifying.

Hi there. Long time no write! This last Tuesday, February 23, 2021, I made an announcement at debian-devel-announce about a new service that I configured for Debian: a debuginfod server. This post serves two purposed: pay the promise I made to Jonathan Carter that I would write a blog post about the service, and go into a bit more detail about it. What’s debuginfod? From the announcement above: debuginfod is a new-ish project whose purpose is to serve ELF/DWARF/source-code information over HTTP.

Back in September, we had the GNU Tools Cauldron in the gorgeous city of Montréal (perhaps I should write a post specifically about it…). One of the sessions we had was the GDB BoF, where we discussed, among other things, how to improve our patch review system. I have my own personal opinions about the current review system we use (mailing list-based, in a nutshell), and I haven’t felt very confident to express it during the discussion.

Back in 2016, when life was simpler, a Fedora GDB user reported a bug (or a feature request, depending on how you interpret it) saying that GDB’s gcore command did not respect the COREFILTER_ELF_HEADERS flag, which instructs it to dump memory pages containing ELF headers. As you may or may not remember, I have already written about the broader topic of revamping GDB’s internal corefile dump algorithm; it’s an interesting read and I recommend it if you don’t know how Linux (or GDB) decides which mappings to dump to a corefile.

Heya! This past Saturday, April 27th, 2019, Samuel Vale, Alex Volkov and I organized the Toronto Bug Squashing Party here in the city. I was very happy with the outcome, especially the fact that we had more than 10 people attending, including a bunch of folks that came from Montréal! The start It was a cold day in Toronto, and we met at the Mozilla Toronto office at 9 in the morning.

Hey, there. This is long overdue: my entry in Planet Debian! I’m creating this post because, until now, I didn’t have a debian tag in my blog! Well, not anymore. Stay tunned!