Introduction
DebConf23, the 24th annual Debian Conference, was held in India in the city of Kochi, Kerala from the 3rd to the 17th of September, 2023. Ever since I got to know about it (which was more than an year ago), I was excited to attend DebConf in my home country. This was my second DebConf, as I attended one last year in Kosovo. I was very happy that I didn t need to apply for a visa to attend. This time I submitted two talks - one on Debian packaging for beginners and the other on ideas on sustainable solutions for self-hosting. I got full bursary to attend the event (thanks a lot to Debian for that!) which is always helpful in covering the expenses, especially if the venue is a five star hotel :)
My friend Suresh - who is enthusiastic about Debian and free software - wanted to attend it too. When the registration started, I reminded him about applying. We landed in Kochi on the 28th of August 2023 during the festival of Onam. We celebrated Onam in Kochi, had a trip to Wayanad, and returned to Kochi. On the evening of the 3rd of September, we reached the venue - Four Points Hotel by Sheraton, at Infopark Kochi, Ernakulam, Kerala, India.
Suresh and me celebrating Onam in Kochi.
Hotel overview
The hotel had 14 floors, and featured a swimming pool and gym (these were included in our package). The hotel gave us elevator access for only our floor, along with public spaces like the reception, gym, swimming pool, and dining areas. The temperature inside the hotel was pretty cold and I had to buy a jacket to survive. Perhaps the hotel was in cahoots with winterwear companies? :)
Four Points Hotel by Sheraton was the venue of DebConf23. Credits: Bilal
Photo of the pool. Credits: Andreas Tille.
Meals
On the first day, Suresh and I had dinner at the eatery on the third floor. At the entrance, a member of the hotel staff asked us about how many people we wanted a table for. I told her that it s just the two of us at the moment, but (as we are attending a conference) we might be joined by others. Regardless, they gave us a table for just two. Within a few minutes, we were joined by Alper from Turkey and urbec from Germany. So we shifted to a larger table but then we were joined by even more people, so we were busy adding more chairs to our table. urbec had already been in Kerala for the past 5-6 days and was, on one hand, very happy already with the quality and taste of bananas in Kerala and on the other, rather afraid of the spicy food :)
Two days later, the lunch and dinner were shifted to the All Spice Restaurant on the 14th floor, but the breakfast was still served at the eatery. Since the eatery (on the 3rd floor) had greater variety of food than the other venue, this move made breakfast the best meal for me and many others. Many attendees from outside India were not accustomed to the spicy food. It is difficult for locals to help them, because what we consider mild can be spicy for others. It is not easy to satisfy everyone at the dining table, but I think the organizing team did a very good job in the food department. (That said, it didn t matter for me after a point, and you will know why.) The pappadam were really good, and I liked the rice labelled Kerala rice . I actually brought that exact rice and pappadam home during my last trip to Kochi and everyone at my home liked it too (thanks to Abhijit PA). I also wished to eat all types of payasams from Kerala and this really happened (thanks to Sruthi who designed the menu). Every meal had a different variety of payasam and it was awesome, although I didn t like some of them, mostly because they were very sweet. Meals were later shifted to the ground floor (taking away the best breakfast option which was the eatery).
This place served as lunch and dinner place and later as hacklab during debconf. Credits: Bilal
The excellent Swag Bag
The DebConf registration desk was at the second floor. We were given a very nice swag bag. They were available in multiple colors - grey, green, blue, red - and included an umbrella, a steel mug, a multiboot USB drive by Mostly Harmless, a thermal flask, a mug by Canonical, a paper coaster, and stickers. It rained almost every day in Kochi during our stay, so handing out an umbrella to every attendee was a good idea.
Picture of the awesome swag bag given at DebConf23.
A gift for Nattie
During breakfast one day, Nattie expressed the desire to buy a coffee filter. The next time I went to the market, I bought a coffee filter for her as a gift. She seemed happy with the gift and was flattered to receive a gift from a young man :)
Being a mentor
There were many newbies who were eager to learn and contribute to Debian. So, I mentored whoever came to me and was interested in learning. I conducted a packaging workshop in the bootcamp, but could only cover how to set up the Debian Unstable environment, and had to leave out how to package (but I covered that in my talk). Carlos (Brazil) gave a keysigning session in the bootcamp. Praveen was also mentoring in the bootcamp. I helped people understand why we sign GPG keys and how to sign them. I planned to take a workshop on it but cancelled it later.
My talk
My Debian packaging talk was on the 10th of September, 2023. I had not prepared slides for my Debian packaging talk in advance - I thought that I could do it during the trip, but I didn t get the time so I prepared them on the day before the talk. Since it was mostly a tutorial, the slides did not need much preparation. My thanks to Suresh, who helped me with the slides and made it possible to complete them in such a short time frame.
My talk was well-received by the audience, going by their comments. I am glad that I could give an interesting presentation.
My presentation photo. Credits: Valessio
Visiting a saree shop
After my talk, Suresh, Alper, and I went with Anisa and Kristi - who are both from Albania, and have a never-ending fascination for Indian culture :) - to buy them sarees. We took autos to Kakkanad market and found a shop with a great variety of sarees. I was slightly familiar with the area around the hotel, as I had been there for a week. Indian women usually don t try on sarees while buying - they just select the design. But Anisa wanted to put one on and take a few photos as well. The shop staff did not have a trial saree for this purpose, so they took a saree from a mannequin. It took about an hour for the lady at the shop to help Anisa put on that saree but you could tell that she was in heaven wearing that saree, and she bought it immediately :) Alper also bought a saree to take back to Turkey for his mother. Me and Suresh wanted to buy a kurta which would go well with the mundu we already had, but we could not find anything to our liking.
Selfie with Anisa and Kristi.
Cheese and Wine Party
On the 11th of September we had the Cheese and Wine Party, a tradition of every DebConf. I brought Kaju Samosa and Nankhatai from home. Many attendees expressed their appreciation for the samosas. During the party, I was with Abhas and had a lot of fun. Abhas brought packets of paan and served them at the Cheese and Wine Party. We discussed interesting things and ate burgers. But due to the restrictive alcohol laws in the state, it was less fun compared to the previous DebConfs - you could only drink alcohol served by the hotel in public places. If you bought your own alcohol, you could only drink in private places (such as in your room, or a friend s room), but not in public places.
Me helping with the Cheese and Wine Party
Party at my room
Last year, Joenio (Brazilian) brought pastis from France which I liked. He brought the same alocholic drink this year too. So I invited him to my room after the Cheese and Wine party to have pastis. My idea was to have them with my roommate Suresh and Joenio. But then we permitted Joenio to bring as many people as he wanted and he ended up bringing some ten people. Suddenly, the room was crowded. I was having good time at the party, serving them the snacks given to me by Abhas. The news of an alcohol party at my room spread like wildfire. Soon there were so many people that the AC became ineffective and I found myself sweating.
I left the room and roamed around in the hotel for some fresh air. I came back after about 1.5 hours - for most part, I was sitting at the ground floor with TK Saurabh. And then I met Abraham near the gym (which was my last meeting with him). I came back to my room at around 2:30 AM. Nobody seemed to have realized that I was gone. They were thanking me for hosting such a good party. A lot of people left at that point and the remaining people were playing songs and dancing (everyone was dancing all along!). I had no energy left to dance and to join them. They left around 03:00 AM. But I am glad that people enjoyed partying in my room.
This picture was taken when there were few people in my room for the party.
Sadhya Thali
On the 12th of September, we had a sadhya thali for lunch. It is a vegetarian thali served on a banana leaf on the eve of Thiruvonam. It wasn t Thiruvonam on this day, but we got a special and filling lunch. The rasam and payasam were especially yummy.
Sadhya Thali: A vegetarian meal served on banana leaf. Payasam and rasam were especially yummy!
Sadhya thali being served at debconf23. Credits: Bilal
Day trip
On the 13th of September, we had a daytrip. I chose the daytrip houseboat in Allepey. Suresh chose the same, and we registered for it as soon as it was open. This was the most sought-after daytrip by the DebConf attendees - around 80 people registered for it.
Our bus was set to leave at 9 AM on the 13th of September. Me and Suresh woke up at 8:40 and hurried to get to the bus in time. It took two hours to reach the venue where we get the houseboat.
The houseboat experience was good. The trip featured some good scenery. I got to experience the renowned Kerala backwaters. We were served food on the boat. We also stopped at a place and had coconut water. By evening, we came back to the place where we had boarded the boat.
Group photo of our daytrip. Credits: Radhika Jhalani
A good friend lost
When we came back from the daytrip, we received news that Abhraham Raji was involved in a fatal accident during a kayaking trip.
Abraham Raji was a very good friend of mine. In my Albania-Kosovo-Dubai trip last year, he was my roommate at our Tirana apartment. I roamed around in Dubai with him, and we had many discussions during DebConf22 Kosovo. He was the one who took the photo of me on my homepage. I also met him in MiniDebConf22 Palakkad and MiniDebConf23 Tamil Nadu, and went to his flat in Kochi this year in June.
We had many projects in common. He was a Free Software activist and was the designer of the DebConf23 logo, in addition to those for other Debian events in India.
A selfie in memory of Abraham.
We were all fairly shocked by the news. I was devastated. Food lost its taste, and it became difficult to sleep. That night, Anisa and Kristi cheered me up and gave me company. Thanks a lot to them.
The next day, Joenio also tried to console me. I thank him for doing a great job. I thank everyone who helped me in coping with the difficult situation.
On the next day (the 14th of September), the Debian project leader Jonathan Carter addressed and announced the news officially. THe Debian project also mentioned it on their website.
Abraham was supposed to give a talk, but following the incident, all talks were cancelled for the day. The conference dinner was also cancelled.
As I write, 9 days have passed since his death, but even now I cannot come to terms with it.
Visiting Abraham s house
On the 15th of September, the conference ran two buses from the hotel to Abraham s house in Kottayam (2 hours ride). I hopped in the first bus and my mood was not very good. Evangelos (Germany) was sitting opposite me, and he began conversing with me. The distraction helped and I was back to normal for a while. Thanks to Evangelos as he supported me a lot on that trip. He was also very impressed by my use of the StreetComplete app which I was using to edit OpenStreetMap.
In two hours, we reached Abraham s house. I couldn t control myself and burst into tears. I went to see the body. I met his family (mother, father and sister), but I had nothing to say and I felt helpless. Owing to the loss of sleep and appetite over the past few days, I had no energy, and didn t think it was good idea for me to stay there. I went back by taking the bus after one hour and had lunch at the hotel. I withdrew my talk scheduled for the 16th of September.
A Japanese gift
I got a nice Japanese gift from Niibe Yutaka (Japan) - a folder to keep papers which had ancient Japanese manga characters. He said he felt guilty as he swapped his talk with me and so it got rescheduled from 12th September to 16 September which I withdrew later.
Thanks to Niibe Yutaka (the person towards your right hand) from Japan (FSIJ) gave me a wonderful Japanese gift during debconf23: A folder to keep pages with ancient Japanese manga characters printed on it. I realized I immediately needed that :)
This is the Japanese gift I recieved.
Group photo
On the 16th of September, we had a group photo. I am glad that this year I was more clear in this picture than in DebConf22.
Click to enlarge
Volunteer work and talks attended
I attended the training session for the video team and worked as a camera operator. The Bits from DPL was nice. I enjoyed Abhas presentation on home automation. He basically demonstrated how he liberated Internet-enabled home devices. I also liked Kristi s presentation on ways to engage with the GNOME community.
Bits from the DPL. Credits: Bilal
Kristi on GNOME community.
Abhas' talk on home automation
I also attended lightning talks on the last day. Badri, Wouter, and I gave a demo on how to register on the Prav app. Prav got a fair share of advertising during the last few days.
I was roaming around with a QR code on my T-shirt for downloading Prav.
The night of the 17th of September
Suresh left the hotel and Badri joined me in my room. Thanks to the efforts of Abhijit PA, Kiran, and Ananthu, I wore a mundu.
Me in mundu. Picture credits: Abhijith PA
I then joined Kalyani, Mangesh, Ruchika, Anisa, Ananthu and Kiran. We took pictures and this marked the last night of DebConf23.
Departure day
The 18th of September was the day of departure. Badri slept in my room and left early morning (06:30 AM). I dropped him off at the hotel gate. The breakfast was at the eatery (3rd floor) again, and it was good.
Sahil, Saswata, Nilesh, and I hung out on the ground floor.
From left: Nilesh, Saswata, me, Sahil
I had an 8 PM flight from Kochi to Delhi, for which I took a cab with Rhonda (Austria), Michael (Nigeria) and Yash (India). We were joined by other DebConf23 attendees at the Kochi airport, where we took another selfie.
Ruchika (taking the selfie) and from left to right: Yash, Joost (Netherlands), me, Rhonda
Joost and I were on the same flight, and we sat next to each other. He then took a connecting flight from Delhi to Netherlands, while I went with Yash to the New Delhi Railway Station, where we took our respective trains. I reached home on the morning of the 19th of September, 2023.
Joost and me going to Delhi
Big thanks to the organizers
DebConf23 was hard to organize - strict alcohol laws, weird hotel rules, death of a close friend (almost a family member), and a scary notice by the immigration bureau. The people from the team are my close friends and I am proud of them for organizing such a good event.
None of this would have been possible without the organizers who put more than a year-long voluntary effort to produce this. In the meanwhile, many of them had organized local events in the time leading up to DebConf. Kudos to them.
The organizers also tried their best to get clearance for countries not approved by the ministry. I am also sad that people from China, Kosovo, and Iran could not join. In particular, I feel bad for people from Kosovo who wanted to attend but could not (as India does not consider their passport to be a valid travel document), considering how we Indians were so well-received in their country last year.
Note about myself
I am writing this on the 22nd of September, 2023. It took me three days to put up this post - this was one of the tragic and hard posts for me to write. I have literally forced myself to write this. I have still not recovered from the loss of my friend. Thanks a lot to all those who helped me.
PS: Credits to contrapunctus for making grammar, phrasing, and capitalization changes.
/usr-merge, by Helmut Grohne, et al
Towards the end of April, the discussion on DEP 17 on
debian-devel@l.d.o initiated by Helmut
Grohne took off, trying to deal with the fact that while Debian bookworm has a
merged /usr, files are still being distributed to / and /usr in Debian binary
packages, and moving them currently has some risk of breakage. Most
participants of the discussion agreed that files should be moved, and there
are several competing design ideas for doing it safely.
Most of the time was spent understanding the practical implications of lifting
the moratorium and moving all the files from / to /usr in a coordinated effort.
With help from Emilio Pozuelo Monfort, Enrico Zini, and Raphael Hertzog,
Helmut Grohne performed extensive analysis of the various aspects, including
quantitative analysis of the original file move problem, analysis of effects on
dpkg-divert,
dpkg-statoverride,
and update-alternatives,
analysis of effects on
filesystem bootstrapping tools.
Most of the problematic cases spawned plausible workarounds, such as turning
Breaks into Conflicts in selected cases or adding protective diversions for the
symbolic links that enable aliasing.
Towards the end of May, Andreas Beckmann reported a
new failure scenario which may cause
shared resources to inadvertently disappear,
such as directories and even regular files in case of Multi-Arch packages, and
our work on analyzing these problems and proposing mitigations is on-going.
While the quantitative analysis is funded by Freexian, we wouldn t be here
without the extensive feedback and ideas of many voluntary contributors from
multiple areas of Debian, which are too many to name here. Thank you.
Preparing for the tox 4 transition, by Stefano Rivera
While Debian was in freeze for the bookworm release, tox 4 has landed in Debian
experimental, and some packages are starting to require it, upstream. It
has some backwards-incompatible behavior
that breaks many packages using tox through pybuild. So Stefano had to make
some changes to pybuild and to many packages that run build-time tests with tox.
The easy bits of this transition are now completed in git / experimental, but a
few packages that integrate deeply into tox need upstream work.
Debian Printing, by Thorsten Alteholz
Just before the release of Bookworm, lots of QA tools were used to inspect
packages. One of these tools found a systemd service file in a wrong directory.
So, Thorsten did another upload of package lprint to correct this.
Thanks a lot to all the hardworking people who run such tools and file bugs.
Thorsten also participated in discussions about the new Common Printing Dialog
Backends (CPDB) that will be introduced in Trixie and hopefully can replace
the current printing architecture in Forky.
Miscellaneous contributions
DebConf 23 preparations by Stefano Rivera. Some work on the website, video
team planning, accounting, and
team documentation.
Utkarsh Gupta started to prep the work on the bursary team s side for DC23.
Stefano spun up a website for the
Hamburg mini-DebConf so that the video team could have a machine-readable
schedule and a place to stream video from the event.
Santiago Ruano Rinc n reviewed and sponsored four python packages of a prospective
Debian member.
Helmut Grohne supported Timo Roehling and Jochen Sprickerhof to improve cross
building in 15 ROS packages.
Helmut Grohne supported Jochen Sprickerhof with diagnosing an
e2fsprogs RC bug.
Helmut Grohne continued to maintain rebootstrap and located an issue with
lto in gcc-13.
Anton Gladky fixed some RC-Bugs and uploaded a new stravalib python library.
I watched a 2015
video from Andreas Schiffler the other day, where he set up
LinuxCNC to send status
information to the MQTT broker IBM Bluemix. As I also use MQTT for
graphing, it occured to me that a generic MQTT LinuxCNC component
would be useful and I set out to implement it. Today I got the first
draft limping along and submitted as
a patch to the
LinuxCNC project.
The simple part was setting up the MQTT publishing code in Python.
I already have set up other parts submitting data to my Mosquito MQTT
broker, so I could reuse that code. Writing a LinuxCNC component in
Python as new to me, but using existing examples in the code
repository and the extensive documentation, this was fairly straight
forward. The hardest part was creating a automated test for the
component to ensure it was working. Testing it in a simulated
LinuxCNC machine proved very useful, as I discovered features I needed
that I had not thought of yet, and adjusted the code quite a bit to
make it easier to test without a operational MQTT broker
available.
The draft is ready and working, but I am unsure which LinuxCNC HAL
pins I should collect and publish by default (in other words, the
default set of information pieces published), and how to get the
machine name from the LinuxCNC INI file. The latter is a minor
detail, but I expect it would be useful in a setup with several
machines available. I am hoping for feedback from the experienced
LinuxCNC developers and users, to make the component even better
before it can go into the mainland LinuxCNC code base.
Since I started on the MQTT component, I came across
another video from Kent
VanderVelden where he combine LinuxCNC with a set of screen glasses
controlled by a Raspberry Pi, and it occured to me that it would
be useful for such use cases if LinuxCNC also provided a REST API for
querying its status. I hope to start on such component once the MQTT
component is working well.
As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.
The Guile bindings for GnuTLS has been part of GnuTLS since spring 2007 when Ludovic Court s contributed it after some initial discussion. I have been looking into getting back to do GnuTLS coding, and during a recent GnuTLS meeting one topic was Guile bindings. It seemed like a fairly self-contained project to pick up on. It is interesting to re-read the old thread when this work was included: some of the concerns brought up there now have track record to be evaluated on. My opinion that the cost of introducing a new project per language binding today is smaller than the cost of maintaining language bindings as part of the core project. I believe the cost/benefit ratio has changed during the past 15 years: introducing a new project used to come with a significant cost but this is no longer the case, as tooling and processes for packaging have improved. I have had similar experience with Java, C# and Emacs Lisp bindings for GNU Libidn as well, where maintaining them centralized slow down the pace of updates. Andreas Metzler pointed to a similar conclusion reached by Russ Allbery.
There are many ways to separate a project into two projects; just copying the files into a new git repository would have been the simplest and was my original plan. However Ludo mentioned git-filter-branch in an email, and the idea of keeping all git history for some of the relevant files seemed worth pursuing to me. I quickly found git-filter-repo which appears to be the recommend approach, and experimenting with it I found a way to filter out the GnuTLS repo into a small git repository that Guile-GnuTLS could be based on. The commands I used were the following, if you want to reproduce things.
I debated with myself back and forth whether to include some files that would be named the same in the new repository but would share little to no similar lines, for example configure.ac, Makefile.am not to mention README and NEWS. Initially I thought it would be nice to preserve the history for all lines that went into the new project, but this is a subjective judgement call. What brought me over to a more minimal approach was that the contributor history and attribution would be quite strange for the new repository: Should Guile-GnuTLS attribute the work of the thousands of commits to configure.ac which had nothing to do with Guile? Should the people who wrote that be mentioned as contributor of Guile-GnuTLS? I think not.
The next step was to get a reasonable GitLab CI/CD pipeline up, to make sure the project builds on some free GNU/Linux distributions like Trisquel and PureOS as well as the usual non-free distributions like Debian and Fedora to have coverage of dpkg and rpm based distributions. I included builds on Alpine and ArchLinux as well, because they tend to trigger other portability issues. I wish there were GNU Guix docker images available for easy testing on that platform as well. The GitLab CI/CD rules for a project like this are fairly simple.
To get things out of the door, I tagged the result as v3.7.9 and published a GitLab release page for Guile-GnuTLS that includes OpenPGP-signed source tarballs manually uploaded built on my laptop. The URLs for these tarballs are not very pleasant to work with, and discovering new releases automatically appears unreliable, but I don t know of a better approach.
To finish this project, I have proposed a GnuTLS merge request to remove all Guile-related parts from the GnuTLS core.
Doing some GnuTLS-related work again felt nice, it was quite some time ago so thank you for giving me this opportunity. Thoughts or comments? Happy hacking!
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
Debian project funding
No any major updates on running projects. Two 1, 2 projects are in the pipeline now. Tryton project is in a review phase. Gradle projects is still fighting in work.
In July, we put aside 2389 EUR to fund Debian projects.
We re looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article.
Debian LTS contributors
In July, 14 contributors have been paid to work on Debian LTS, their reports are available:
Abhijith PA did 0.00h (out of 14.00h assigned, thus carrying over 14.00h to the next month).
Andreas R nnquist did 0.00h (out of 0.00h assigned and 10.50h from previous period, thus carrying over 10.50h to the next month).
Anton Gladky did 23.00h (out of 25.00h assigned, thus carrying over 2.00h to the next month).
Ben Hutchings did 3.00h (out of 24.00h assigned, thus carrying over 21.00h to the next month).
Dominik George did 0.00h (out of 0.00h assigned and 22.17h from previous period, thus carrying over 22.17h to the next month).
Utkarsh Gupta did not report back about their work so we assume they did nothing (out of 35.75 available hours, thus carrying them over to the next month).
Evolution of the situation
In July, we have released 3 DLAs. July was the period, when the Debian Stretch had already ELTS status, but Debian Buster was still in the hands of security team. Many member of LTS used this time to update internal infrastructure, documentation and some internal tickets. Now we are ready to take the next release in our hands: Buster!
Thanks to our sponsors
Sponsors that joined recently are in bold.
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
Debian project funding
No any major updates on running projects. Two 1, 2 projects are in the pipeline now. Tryton project is in a review phase. Gradle projects is still fighting in work.
In June, we put aside 2254 EUR to fund Debian projects.
We re looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article.
Debian LTS contributors
In June, 15 contributors have been paid to work on Debian LTS, their reports are available:
Utkarsh Gupta did not report back about their work so we assume they did nothing (out of 30.25 available hours, thus carrying them over to the next month).
Evolution of the situation
In June we released 27 DLAs.
This is a special month, where we have two releases (stretch and jessie) as ELTS and NO release as LTS. Buster is still handled by the security team and will probably be given in LTS hands at the beginning of the August. During this month we are updating the infrastructure, documentation and improve our internal processes to switch to a new release. Many developers have just returned back from Debconf22, hold in Prizren, Kosovo! Many (E)LTS members could meet face-to-face and discuss some technical and social topics! Also LTS BoF took place, where the project was introduced (link to video).
Thanks to our sponsors
Sponsors that joined recently are in bold. We are pleased to welcome Alter Way where their support of Debian is publicly acknowledged at the higher level, see this French quote of Alterway s CEO.
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
Debian project funding
Two [1, 2] projects are in the pipeline now. Tryton project is in a final phase. Gradle projects is fighting with technical difficulties.
In May, we put aside 2233 EUR to fund Debian projects.
We re looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article.
Debian LTS contributors
In May, 14 contributors have been paid to work on Debian LTS, their reports are available:
Utkarsh Gupta did 35h (out of 19h assigned and 30h from April), thus carrying over 14h to June.
Evolution of the situation
In May we released 49 DLAs. The security tracker currently lists 71 packages with a known CVE and the dla-needed.txt file has 65 packages needing an update.
The number of paid contributors increased significantly, we are pleased to welcome our latest team members: Andreas R nnquist, Dominik George, Enrico Zini and Stefano Rivera.
It is worth pointing out that we are getting close to the end of the LTS period for Debian 9. After June 30th, no new security updates will be made available on security.debian.org. We are preparing to overtake Debian 10 Buster for the next two years and to make this process as smooth as possible.
But Freexian and its team of paid Debian contributors will continue to maintain Debian 9 going forward for the customers of the Extended LTS offer. If you have Debian 9 servers to keep secure, it s time to subscribe!
You might not have noticed, but Freexian formalized a mission statement where we explain that our purpose is to help improve Debian. For this, we want to fund work time for the Debian developers that recently joined Freexian as collaborators. The Extended LTS and the PHP LTS offers are built following a model that will help us to achieve this if we manage to have enough customers for those offers. So consider subscribing: you help your organization but you also help Debian!
Thanks to our sponsors
Sponsors that joined recently are in bold.
About a month later than I probably should have posted it, here s a recap of my Free Software activities in 2021. For previous years see 2019 + 2020. Again, this year had fewer contributions than I d like thanks to continuing fatigue about the state of the world, and trying to work on separation between work and leisure while working from home. I ve made some effort to improve that balance but it s still a work in progress.
Conferences
No surprise, I didn t attend any in-person conferences in 2021. I find virtual conferences don t do a lot for me (a combination of my not carving time out for them in the same way, because not being at the conference means other things will inevitably intrude, and the lack of the social side) but I did get to attend a few of the DebConf21 talks, which was nice. I m hoping to make it to DebConf22 this year in person.
Debian
Most of my contributions to Free software continue to happen within Debian.
As part of the Data Protection Team I responded to various inbound queries to that team. Some of this involved chasing up other project teams who had been slow to respond - folks, if you re running a service that stores personal data about people then you need to be responsive to requests about it. Some of this was dealing with what look like automated scraping tools which send no information about the person making the request, and in all the cases we ve seen so far there s been no indication of any data about that person on any systems we have access to. Further team time was wasted dealing with the Princeton-Radboud Study on Privacy Law Implementation (though Matthew did the majority of the work on this).
The Debian Keyring was possibly my largest single point of contribution. We re in a roughly 3 month rotation of who handles the keyring updates, and I handled 2021.03.24, 2021.04.09, 2021.06.25, 2021.09.25 + 2021.12.24
For Debian New Members I m mostly inactive as an application manager - we generally seem to have enough available recently. If that changes I ll look at stepping in to help, but I don t see that happening. I continue to be involved in Front Desk, having various conversations throughout the year with the rest of the team, but there s no doubt Mattia and Pierre-Elliott are the real doers at present. I did take part in an NM Committee appeals process.
In terms of package uploads I continued to work on gcc-xtensa-lx106, largely doing uploads to deal with updates to the GCC version or packaging (8 + 9). sigrok had a few minor updates, libsigkrok 0.5.2-3, pulseview 0.4.2-3 as well as a new upstream release of sigrok CLI 0.7.2-1. There was a last minute pre-release upload of libserialport 0.1.1-4 thanks to a kernel change in v5.10.37 which removed termiox support.
Despite still not writing any VHDL these days I continue to keep an eye on ghdl, because I found it a useful tool in the past. Last year that was just a build fix for LLVM 11.1.0 - 1.0.0+dfsg+5. Andreas Bombe has largely taken over more proactive maintenance, which is nice to see.
I uploaded OpenOCD0.11.0~rc1-2, cleaning up some packaging / dependency issues. This was followed by 0.11.0~rc2-1 as a newer release candidate. Sadly 0.11.0 did not make it in time for bullseye, but rc2 was fairly close and I uploaded 0.11.0-1 once bullseye was released.
Finally I did a drive-by upload for garmin-forerunner-tools 0.10repacked-12, cleaning up some packaging issues and uploading it to salsa. My Forerunner 305 has died (after 11 years of sterling service) and the Forerunner 45 I ve replaced it with uses a different set of tools, so I decided it didn t make sense to pick up longer term ownership of the package.
Linux
My Linux contributions continued to revolve around pushing MikroTik RB3011 support upstream. There was a minor code change to Set FIFO sizes for ipq806x (which fixed up the allowed MTU for the internal switch + VLANs). The rest was DTS related - adding ADM DMA + NAND definitions now that the ADM driver was merged, adding tsens details, adding USB port info and adding the L2CC and RPM details for IPQ8064. Finally I was able to update the RB3011 DTS to enable NAND + USB.
With all those in I m down to 4 local patches against a mainline kernel, all of which are hacks that aren t suitable for submission upstream. 2 are for patching in details of the root device and ethernet MAC addresses, one is dealing with the fact the IPQ8064 has some reserved memory that doesn t play well with AUTO_ZRELADDR (there keeps being efforts to add some support for this via devicetree, but unfortunately it gets shot down every time), and the final one is a hack to turn off the LCD backlight by treating it as an LED (actually supporting the LCD properly is on my TODO list).
Personal projects
2021 didn t see any releases of onak. It s not dead, just resting, but Sequoia PGP is probably where you should be looking for a modern OpenPGP implementation.
I continued work on my Desk Viking project, which is an STM32F103 based debug tool inspired by the Bus Pirate. The main addtion was some CCLib support (forking it in the process to move to Python 3 and add some speed ups) to allow me to program my Zigbee dongles, but I also added some 1-Wire search logic and some support for Linux emulation mode with VCD output to allow for a faster development cycle. I really want to try and get OpenOCD JTAG mode supported at some point, and have vague plans for an STM32F4 based version that have suffered from a combination of a silicon shortage and a lack of time.
That wraps up 2021. I d like to say I m hoping to make more Free Software contributions this year, but I don t have a concrete plan yet for how that might happen, so I ll have to wait and see.
Getting the latest version of a package into Debian involves checking when there are new versions available fortunately (and not surprisingly) Debian has tools to make this simpler.
I have recently ran into the problem when an upstream beta version sorts higher than a newer non-beta version. Which is problematic, of course. This is due to Debian sorting something like 1.0b as later than a pure 1.0 version.
But there s a solution name the beta versions something like 1.0~beta. And you don t need to force upstream to make any changes either. You can use uscan and the watch file to make it interpret an upstream 1.0b version as 1.0~beta in Debian.
This is done by using a line like
uversionmangle=s/(\d)[\_\.\-\+]?((RC rc pre dev beta alpha b a)\d*)$/$1~$2/;s/\~b/\~beta/;,\
in uversionmangle in your debian/watch file. In this case i have added on the end something to make the ending ~b into ~beta instead. Full version of the watch file available here.
The Motoko programming language has a built-in data type for optional values, named ?t with values null and ?v (for v : t); this is the equivalent of Haskell s Maybe, Ocaml s option or Rust s Option. In this post, I explain how Motoko represents such optional values (almost) without allocation.
I neither claim nor expect that any of this is novel; I just hope it s interesting.
Uniform representation
The Motoko programming language, designed by Andreas Rossberg and implemented by a pretty cool team at DFINITY is a high-level language with strict semantics and a strong, structural, equi-recursive type system that compiles down to WebAssembly.
Because the type system supports polymorphism, it represents all values uniformly. Simplified for the purpose of this blog post, they are always pointers into a heap object where the first word of the heap object, the heap tag, contains information about the value:
tag
The tag is something like array, int64, blob, variant, record, , and it has two purposes:
The garbage collector uses it to understand what kind of object it is looking at, so that it can move it around and follow pointers therein. Variable size objects such as arrays include the object size in a subsequent word of the heap object.
Some types have values that may have different shapes on the heap. For example, the ropes used in our text representation can either be a plain blob, or a concatenation node of two blobs. For these types, the tag of the heap object is inspected.
The optional type, naively
The optional type (?t) is another example of such a type: Its values can either be null, or ?v for some value v of type t, and the primitive operations on this type are the two introduction forms, an analysis function, and a projection for non-null values:
null : () -> ?t
some : t -> ?t
is_some : ?t -> bool
project : ?t -> t // must only be used if is_some holds
It is natural to use the heap tag to distinguish the two kind of values:
The null value is a simple one-word heap object with just a tag that says that this is null:
null
The other values are represented by a two-word object: The tag some, indicating that it is a ?v, and then the payload, which is the pointer that represents the value v:
some payload
With this, the four operations can be implemented as follows:
The problem with this implementation is that null() and some(v) both allocate memory. This is bad if they are used very often, and very liberally, and this is the case in Motoko: For example the iterators used for the for (x in e) construct have type
type Iter<T> = next : () -> ?T
and would unavoidably allocate a few words on each iteration. Can we avoid this?
Static values
It is quite simple to avoid this for for null: Just statically create a single null value and use it every time:
This way, at least null() doesn t allocate. But we gain more: Now everynull value is represented by the same pointer, and since the pointer points to static memory, it does not change even with a moving garbage collector, so we can speed up is_some:
def is_some(p):
return p != static_null
This is not a very surprising change so far, and most compilers out there can and will do at least the static allocation of such singleton constructors.
For example, in Haskell, there is only a single empty list ([]) and a single Nothing value in your program, as you can see in my videos exploring the Haskell heap.
But can we get rid of the allocation in some(v) too?
Unwrapped optional values
If we don t want to allocate in some(v), what can we do? How about simply
def some(v):
return v
That does not allocate! But it is also broken. At type ??Int, the values null, ?null and ??null are distinct values, but here this breaks.
Or, more formally, the following laws should hold for our four primitive operations:
is_some(null()) = false
v. is_some(some(v)) = true
p. project(some(p)) = p
But with the new definition of some, we d get is_some(some(null())) = false. Not good!
But note that we only have a problem if we are wrapping a value that is null or some(v). So maybe take the shortcut only then, and write the following:
def some(v):
if v == static_null v[0] == SOME_TAG:
ptr <- alloc(2)
ptr[0] = SOME_TAG
ptr[1] = v
return ptr
else:
return v
The definition of is_some can stay as it is: It is still the case that all null values are represented by static_null. But the some values are now no longer all of the same shape, so we have to change project():
def project(p):
if p[0] == SOME_TAG:
return p[1]
else:
return p
Now things fall into place: A value ?v can, in many cases, be represented the same way as v, and no allocation is needed. Only when v is null or ?null or ??null or ???null etc. we need to use the some heap object, and thus have to allocate.
In fact, it doesn t cost much to avoid allocation even for ?null:
static_some_null = [SOME_TAG, static_null]
def some(v):
if v == static_null:
return static_some_null
else if v[0] == SOME_TAG:
ptr <- alloc(2)
ptr[0] = SOME_TAG
ptr[1] = v
return ptr
else:
return v
So unless one nests the ? type two levels deep, there is no allocation whatsoever, and the only cost is a bit more branching in some and project.
That wasn t hard, but quite rewarding, as one can now use idioms like the iterator shown above with greater ease.
Examples
The following tables shows the representation of various values before and after. Here [ ] is a pointed-to dynamically allocated heap object, a statically allocated heap object, N = NULL_TAG and S = SOME_TAG.
type
value
before
after
Null
null
N
N
?Int
null
N
N
?Int
?23
[S,23]
23
??Int
null
N
N
??Int
?null
[S, N ]
S, N
??Int
??23
[S,[S,23]]
23
???Int
null
N
N
???Int
?null
[S, N ]
S, N
???Int
??null
[S,[S, N ]]
[S, S, N ]
???Int
???23
[S,[S,[S,23]]]
23
Concluding remarks
If you know what parametric polymorphism is, and wonder how this encoding can work in a language that has that, note that this representation is on the low-level of the untyped run-time value representation: We don t need to know the type of v in some(v), merely its heap representation.
The uniform representation in Motoko is a bit more involved: The pointers are tagged (by subtracting 1) and some scalar values are represented directly in place (shifted left by 1 bit). But this is luckily orthogonal to what I showed here.
Could Haskell do this for its Maybe type? Not so easily:
The Maybe type is not built-in, but rather a standard library-defined algebraic data type. But the compiler could feasible detect that this is option-like?
Haskell is lazy, so at runtime, the type Maybe could be Nothing, or Just v, or, and this is crucial, a yet to be evaluated expression, also called a thunk. And one definitely needs to distinguish between a thunk t :: Maybe a that may evaluate to Nothing, and a value Just t :: Maybe a that definitely isJust, but contains a value, which may be a thunk.
As I said above, I don t expect this to be novel, and I am happy to add references to prior art here.
Given that a heap object with tag SOME_TAG now always encodes a tower ? null for n>0, one could try to optimize that even more by just storing the n:
some n
But that seems unadvisable: It is only a win if you have deep towers, which is probably rare. Worse, now the project function would have to return such a heap object with n decremented, so now projection might have to allocate, which goes against the cost model expected by the programmer.
If you rather want to see code than blog posts, feel free to check out Motoko PR #2115.
Does this kind of stuff excite you? Motoko is open source, so your contributions may be welcome!
Today marks the 90th day of me joining Canonical to work on Ubuntu full-time! So since
it s been a while already, this blog post is long due. :)
The News
I joined Canonical, this February, to work on Ubuntu full-time! \o/
Those who know, they know that this is really very exciting for me because Canonical has
been a dream company for me, for real (more about this below!). And hey, this is my first
job, ever, so all the more reason to be psyched about, isn t it? ^_^
P.S. Keep reading and we ll meet my squad really sooon!
The Story
Being an undergrad student (batch 2017-2021), I ve been slightly worried during my last
two semesters, naturally, thinking about how s it all gonna pan out and what will I be doing,
et al, because I ve been seeing all my friends and batchmates getting placed in companies
or going for masters or at least having some sort of plans for their future and I, on the
other hand, was hopelessly clueless. :D
Well, to be fair, I did Google Summer of Code twice,
in 2019 and
2020, became a
Debian Developer in 2019, been a part of
GCI and Outreachy, contributed
to over dozens of open-source projects, et al, et al. So I wasn t all completely hopeless
but for sure was completely clueless , heh.
And for full disclosure, I was only slightly panicking because firstly, I did get placed
in several companies and secondly, I didn t really need a job immediately since I was already
getting paid to work on Debian stuff by Freexian, which was good enough. :)
(and honestly, Freexian has my whole heart! - more on that later sometime.)
But that s not the point. I was still confused and worried and my mom & dad, more so than
anyone. Ugh. We were all figuring out and she asked me places that I was interested to work
in. And whilst I wasn t clear about things I wanted to do (and still am!) but I was (very)
clear about this and so I told her about Canonical and also did tell her that it s a bit too
ambitious for me to think about it now so I ll probably apply after some experience or something.
and as they say, the world works in mysterious ways and well, it did for me! So back during
the Ruby sprints (Feb 20), Kanashiro, the guy ( ), mentioned that his team was hiring and
has a vacant position but I won t be eligible since I was still in my junior year. It was
since then I ve been actively praying for Cronus, the god of time, to wave his magic wand and
align it in such a way that the next opening should be somewhere near my graduation. And guess
what? IT HAPPENED!
9 months later, in November 20, Kanashiro told me his team is hiring yet again and that I
could apply this time! Without much (since there was some ) delay, I applied and started
asking all sorts of questions to Kanashiro. No words are enough for him, he literally helped
me throughout the process; from referring me to answering all sorts of doubts I had!
And roughly after 2 months of interviewing, et al, my ambitious dream did come true and I
finalyyyy signed my contract! \o/
(the interview process and what went on during those 10 weeks is a story for later ;))
The Server Team! \o
This position, which I didn t mention earlier, was for the Server Team which is a team of
15 people, working to make Ubuntu server the best! And as I
tweeted sometime back, the team
is absolutely lovely, super kind, and consists of the best of teammates one could possibly
ask for!
Here s a quick sneak peek into our weekly team meeting. Thanks to
Rafael for taking such a lovely picture. And yes,
the cat Luna is a part of our squad!
And oh, did I mention that we re completely remote and distributed?
FUN FACT: Our team covers all the TZs, that is, at any point of time (during weekdays),
you ll find someone or the other from the team around! \o/
Anyway, our squad, managed by Rick is divided into two halves: Squeaky Wheels and
Table Flip. Cool names, right?
Squeaky Wheels does the distro side of stuff and consists of Christian, Andreas, Rafael, Robie,
Bryce, Sergio, Kanashiro, Athos, and now myself as well! And OTOH, Table Flip consists of Dan,
Chad, Paride, Lucas, James, and Grant.
Even though I interact w/ Squeaky Wheels more (basically daily), each of my teammates is
absolutely lovely and equally awesome!
Whilst I ll talk more about things here in the upcoming months, this is it for now! If there s
anything, in particular, you d like to know more about, let me know!
And lastly, here s us vibing our way through, making Ubuntu server better, cause that s how
we roll!
Until next time. :wq for today.
FTP master
This month I only accepted 8 packages and like last month rejected 0. Despite the holidays 293 packages got accepted.
Debian LTS
This was my seventy-eighth 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 26h. During that time I did LTS uploads of:
[DLA 2489-1] minidlna security update for two CVEs
[DLA 2490-1] x11vnc security update for one CVE
[DLA 2501-1] influxdb security update for one CVE
[DLA 2511-1] highlight.js security update for one CVE
Unfortunately package slirp has the same version in Stretch and Buster. So I first had to upload slirp/1:1.0.17-11 to unstable, in order to be allowed to fix the CVE in Buster and to finally upload a new version to Stretch. Meanwhile the fix for Buster has been approved by the Release Team and I am waiting for the next point release now.
I also prepared a debdiff for influxdb, which will result in DSA-4823-1 in January.
As there appeared new CVEs for openjpeg2, I did not do an upload yet. This is planned for January now.
Last but not least I did some days of frontdesk duties.
Debian ELTS
This month was the thirtieth ELTS month.
During my allocated time I uploaded:
ELA-341-1 for highlight.js
As well as for LTS, I did not finish work on all CVEs of openjpeg2, so the upload is postponed to January.
Last but not least I did some days of frontdesk duties.
Unfortunately I also had to give back some hours.
Other stuff
This month I uploaded new upstream versions of:
With these uploads I finished the libosmocom- and libctl-transitions.
The Debian Med Advent Calendar was again really successful this year. There was no new record, but with 109, the second most number of bugs has been closed.
year
number of bugs closed
2011
63
2012
28
2013
73
2014
5
2015
150
2016
95
2017
105
2018
81
2019
104
2020
109
Well done everybody who participated. It is really nice to see that Andreas is no longer a lone wolf.
Over the course of the last year and a half, I ve been doing some self-directed
learning on how radios work. I ve gone from a very basic understanding of
wireless communications (there s usually some sort of antenna, I guess?) all
the way through the process of learning about and implementing a set of
libraries to modulate and demodulate data using my now formidable stash of SDRs.
I ve been implementing all of the RF processing code from first principals and
purely based on other primitives I ve written myself to prove to myself that I
understand each concept before moving on.
I figured that there was a fun capstone to be done here - the blind reverse
engineering and implementation of the protocol my cheep Amazon power switch
uses to turn on and off my Christmas Tree. All the work described in this post
was done over the course of a few hours thanks to help during the demodulation
from Tom Bereknyei and
hlieberman.
Going in blind
When I first got my switch, I checked it for any FCC markings in order to look
up the FCC filings to determine the operational frequency of the device, and
maybe some other information such as declared modulation or maybe even part
numbers and/or diagrams. However, beyond a few regulatory stickers, there were
no FCC ids or other distinguishing IDs on the device. Worse yet, it appeared to
be a whitelabeled version of another product, so searching Google for the
product name was very unhelpful.
Since operation of this device is unlicensed, I figured I d start looking in
the ISM band. The most common band used that I ve seen is the band starting
at 433.05MHz up to 434.79MHz. I fired up my trusty waterfall tuned to a
center frequency of 433.92MHz (since it s right in the middle of the band, and
it let me see far enough up and down the band to spot the remote) and pressed
a few buttons. Imagine my surprise when I realize the operational frequency of
this device is 433.920MHz, exactly dead center. Weird, but lucky!
After taking a capture, I started to look at understanding what the modulation
type of the signal was, and how I may go about demodulating it.
Using inspectrum, I was able to clearly
see the signal in the capture, and it immediately stuck out to my eye to be
encoded using OOK / ASK.
Next, I started to measure the smallest pulse, and see if I could infer the
symbols per second, and try to decode it by hand. These types of signals are
generally pretty easy to decode by eye.
This wound up giving me symbol rate of 2.2 Ksym/s, which is a lot faster than I
expected. While I was working by hand, Tom
demodulated a few messages in Python, and noticed that if you grouped the bits
into groups of 4, you either had a 1000 or a 1110 which caused me to
realize this was encoded using something I saw documented elsewhere, where the
0 is a short pulse, and a 1 is a long pulse, not unlike morse code, but
where each symbol takes up a fixed length of time (monospace morse code?).
Working on that assumption, I changed my inspectrum symbol width, and
demodulated a few more by hand. This wound up demodulating nicely (and the
preamble / clock sync could be represented as repeating 0s, which is handy!)
and gave us a symbol rate of 612(ish) symbols per second a lot closer to
what I was expecting.
If we take the code for on in the inspectrum capture above and demodulate
it by hand, we get 0000000000110101100100010 (treat a short pulse as a 0, and
a long pulse as a 1). If you re interested in following along at home, click on
the inspectrum image, and write down the bits you see, and compare it to what
I have!
Right, so it looks like from what we can tell so far that the packet looks
something like this:
preamble / sync
stuff
Next, I took a capture of all the button presses and demodulated them by hand,
and put them into a table to try and understand the format of the messages:
Button
Demod'd Bits
On
0000000000110101100100010
Off
00000000001101011001010000
Dim Up
0000000000110101100110100
Dim Down
0000000000110101100100100
Timer 1h
0000000000110101100110010
Timer 2h
0000000000110101100100110
Timer 4h
0000000000110101100100000
Dim 100%
0000000000110101000101010
Dim 75%
00000000001101010001001100
Dim 50%
00000000001101010001001000
Dim 25%
0000000000110101000100000
Great! So, this is enough to attempt to control the tree with, I think so I
wrote a simple modulator. My approach was to use the fact that I can break down
a single symbol into 4 sub-symbol components which is to say, go back to
representing a 1 as 1110, and a 0 as 1000. This let me allocate IQ
space for the symbol, break the bit into 4 symbols, and if that symbol is 1,
write out values from a carrier wave (cos in the real values, and sin in
the imaginary values) to the buffer. Now that I can go from bits to IQ data,
I can transmit that IQ data using my PlutoSDR or HackRF and try and control my
tree. I gave it a try, and the tree blinked off!
Success!
But wait that s not enough for me I know I can t just demodulate bits and
try and replay the bits forever there s stuff like addresses and keys and
stuff, and I want to get a second one of these working. Let s take a look at
the bits to see if we spot anything fun & interesting.
At first glance, a few things jumped out at me as being weird? First is
that the preamble is 10 bits long (fine, let s move along - maybe it
just needs 8 in a row and there s two to ensure clocks sync?). Next is that
the messages are not all the same length. I double (and triple!) checked
the messages, and it s true, the messages are not all the same length. Adding
an extra bit at the end didn t break anything, but I wonder if that s just due
to the implementation rather than the protocol.
But, good news, it looks like we have a stable prefix to the messages from the
remote must be my device s address! The stable 6 bits that jump out right
away are 110101. Something seems weird, though, 6 bits is a bit awkward, even
for a bit limited embedded device. Why 6? But hey, wait, we had 10 bits in the
preamble, what if we have an 8 bit address meaning my device is 00110101,
and the preamble is 8 0 symbols! Those are numbers that someone working on
an 8 bit aligned platform would pick! To test this, I added a 0 to the
preamble to see if the message starts at the first 1, or if it requires all
the bits to be fully decoded, and lo and behold, the tree did not turn on or
off. This would seem to me to confirm that the 0s are part of the address,
and I can assume we have two 8 bit aligned bytes in the prefix of the message.
preamble / sync
address
stuff
Now, when we go through the 9-10 bits of stuff , we see all sorts of weird
bits floating all over the place. The first 4 bits look like it s either
1001 or 0001, but other than that, there s a lot of chaos. This is where
things get really squishy. I needed more information to try and figure this out,
but no matter how many times I sent a command it was always the same bits (so,
no counters), and things feel very opaque still.
The only way I was going to make any progress is to get another switch and see
how the messages from the remote change. Off to Amazon I went, and ordered
another switch from the same page, and eagerly waited its arrival.
Switch #2
The second switch showed up, and I hurriedly unboxed the kit, put batteries
into the remote, and fired up my SDR to take a capture. After I captured the
first button ( Off ), my heart sunk as I saw my lights connected to
Switch #1 flicker off. Apparently the new switch and the old switch have the
same exact address. To be sure, I demodulated the messages as before, and
came out with the exact same bit pattern. This is a setback and letdown I
was hoping to independently control my switches, but it also means I got no
additional information about the address or button format.
The upside to all of this, though, is that because the switches are controlled
by either remote, I only needed one remote, so why not pull it apart and see if
I can figure out what components it s using to transmit, and find any
datasheets I can. The PCB was super simple, and I wound up finding a WL116SC
IC on the PCB.
After some googling, I found a single lone
datasheet,
entirely in Chinese. Thankfully, Google Translate seems to have worked well
enough on technical words, and I was able to put together at least a little bit
of understanding based on the documentation that was made available. I took a
few screenshots below - I put the google translated text above the hanzi. From
that sheet, we can see we got the basics of the 1 and 0 symbol encoding
right (I was halfway expecting the bits to be flipped), and a huge find by way
of a description of the bits in the message!
It s a bummer that we missed the clock sync / preamble pulse before the data
message, but that s OK somehow. It also turns out that 8 or 10 bit series of of
0"s wasn t clock sync at all - it was part of the address! Since it also turns
out that all devices made by this manufacturer have the hardcoded address of
[]byte 0x00, 0x35 , that means that the vast majority of bits sent are always
going to be the same for any button press on any remote made by this vendor.
Seems like a waste of bits to me, but hey, what do I know.
Additionally, this also tells us the trailing zeros are not part of the data
encoding scheme, which is progress!
address
keycode
Now, working on the assumptions validated by the datasheet, here s the updated
list of scancodes we ve found:
Button
Scancode Bits
Integer
On
10010001
145 / 0x91
Off
10010100
148 / 0x94
Dim Up
10011010
154 / 0x9A
Dim Down
10010010
146 / 0x92
Timer 1h
10011001
154 / 0x99
Timer 2h
10010011
147 / 0x93
Timer 4h
10010000
144 / 0x90
Dim 100%
00010101
21 / 0x15
Dim 75%
00010011
19 / 0x13
Dim 50%
00010010
18 / 0x12
Dim 25%
00010000
16 / 0x10
Interestingly, I think the Dim keys may have a confirmation that we have
a good demod the codes on the bottom are missing the most significant
bit, and when I look back at the scancode table in the datasheet, they make an
interesting pattern the bottom two rows, right and left side values match
up! If you take a look, Dim 100% is S1 , Dim 75% is S19 , Dim 50% is S8 ,
and Dim 25% is S20 . Cool!
Since none of the other codes line up, I am willing to bet the most significant
bit is a Combo indicator, and not part of the button (leaving 7 bits for the
keycode).
And even more interestingly, one of our scancodes ( Off , which is 0x94) shows up just
below this table, in the examples.
Over all, I think this tells us we have the right bits to look at for
determining the scan code! Great news there!
Back to the modulation!
So, armed with this knowledge, I was able to refactor my code to match the
timings and understanding outlined by the datasheet and ensure things still work.
The switch itself has a high degree of tolerance, so being wildly off frequency
or a wildly wrong symbol rate may actually still work. It s hard to know if
this is more or less correct, but matching documentation seems like a more stable
foundation if nothing else.
This code has been really reliable, and tends to work just as well as the
remote from what I ve been able to determine. I ve been using incredibly low
power to avoid any interference, and it s been very robust - a testament to the
engineering that went into the outlet hardware, even though it cost less than
of a lot of other switches! I have a lot of respect for the folks who built
this device - it s incredibly simple, reliable and my guess is this thing will
keep working even in some fairly harsh RF environments.
The only downside is the fact the manufacturer used the same address for all
their devices, rather than programming a unique address for each outlet and
remote when the underlying WL116SC chip supports it. I m sure this was done to
avoid complexity in assembly (e.g. pairing the remote and outlet, and having to
keep those two items together during assembly), but it s still a bummer. I took
apart the switch to see if I could dump an EEPROM and change the address in
ROM, but the entire thing was potted in waterproof epoxy, which is a very nice
feature if this was ever used outdoors. Not good news for tinkering, though!
Unsolved Mysteries
At this point, even though I understand the protocol enough to control the
device, it still feels like I hit a dead end in my understanding. I m not able
to figure out how exactly the scancodes are implemented, and break them down
into more specific parts. They are stable and based on the physical wiring of
the remote, so I think I m going to leave it a magic number. I have what I was
looking for, and these magic constants appear to be the right one to use, even
if I did understand how to create the codes itself.
This does leave us with a few bits we never resolved, which I ll memorialize
below just to be sure I don t forget about them.
Question #1: According to the datasheet there should be a preamble. Why do
I not see one leading the first message?
My hunch is that the trailing 0 at the end of the payload is actually just
the preamble for the next message (always rendering the first message
invalid?). This would let us claim there s an engineering reason why we are
ignoring the weird bit, and also explain away something from the documentation.
It s just weird that it wouldn t be present on the first message.
This theory is mostly confirmed by measuring the timing and comparing it to the
datasheet, but it s not exactly in line with the datasheet timings either
(specifically, it s off by 200 s, which is kinda a lot for a system using 400 s
timings). I think I could go either way on the last 0 being the preamble for
the next message. It could be that the first message is technically invalid, or
it could also be that this was not implemented or actively disabled by the
vendor for this specific application / device. It s really hard to know
without getting the source code for the WL116SC chip in this specific remote
or the source in the outlet itself.
Question #2: Why are some keycodes 8 bits and others 9 bits?
I still have no idea why there sometimes 8 bits (for instance, On ) and
other times there are 9 bits (for instance, Off ) in the 8 bit keycode
field.
I spent some time playing with the trailing zeros, when I try and send an
Off with the most significant 8 bits (without the least significant / last
9th bit, which is a 0 ), it does not turn the tree off. If I send an On with
9 bits (an additional 0 after the least significant bit), it does work,
but both On and Off work when I send 10, 11 or 12 bits padded with trailing
zeros. I suspect my outlet will ignore data after the switch is done reading
bits regardless of trailing zeros. The docs tell me there should only be 8 bits,
but it won t work unless I send 9 bits for some commands. There s something
fishy going on here, and the datasheet isn t exactly right either way.
Question #3: How in the heck do those scancodes work?
This one drove me nuts. I ve spent countless hours on trying to figure this
out, including emailing the company that makes the WL116SC (they re really
nice!), and even though they were super kind and generous with documentation
and example source, I m still having a hard time lining up their documentation
and examples with what I see from my remote. I think the manufacturer of my
remote and switch has modified the protocol enough to where there s actually
something different going on here. Bummer.
I wound up in my place of last resort asking friends over Signal to try and
see if they could find a pattern, as well as making
multiple pleas to the twittersphere, to no avail (but thank you to
Ben Hilburn,
devnulling,
Andreas Bombe and Larme
for your repiles, help and advice!)
I still don t understand how they assemble the scan code for instance,
if you merely add, you won t know if a key press of 0x05 is 0x03 + 0x02
or if it s 0x01 + 0x04. On the other hand, treating it as two 4-bit
integers won t work for 0x10 to 0x15 (since they need 5 bits to
represent). It s also likely the most significant bit is a combo indicator,
which only leaves 7 bits for the actual keypress data. Stuffing 10 bits of data
into 7 bits is likely resulting in some really intricate bit work.
On a last ditch whim, I tried to XOR the math into working, but some initial
brute forcing to make the math work given the provided examples did not result
in anything. It could be a bitpacked field that I don t understand, but I don t
think I can make progress on that without inside knowledge and much more work.
Here s the table containing the numbers I was working off of:
Keys
Key Codes
Scancode
S3 + S9
0x01 + 0x03
0x96
S6 + S12
0x07 + 0x09
0x94
S22 + S10
0x0D + 0x0F
0x3F
If anyone has thoughts on how these codes work, I d love to hear about it! Send
me an email or a tweet or something - I m a bit stumped.
There s some trick here that is being used to encode the combo key in a way
that is decodeable. If it s actually not decodeable (which is a real
possibility!), this may act as a unique button combo hash which allows the
receiver to not actually determine which keys are pressed, but have a unique
button that gets sent when a combo is used. I m not sure I know enough to
have a theory as to which it may be.
It has been almost a year since I got a different implementation of my
PDP-8/e replica project for my birthday.
Yes, it was a cake, and I have neglected to share it with the world so far. To
be fair, there was a time this year where everything was a cake, at least on
Twitter, and adding another one would have just been pouring gasoline on the
fire.
But here it is, first a side by side comparison of the implementations:
Some detail to admire:
Afterwards I got to see some of the planning that went into it:
I can t say that the other implementation was as functional as mine, but it was
definitely tastier.
One of the most awesome helpers I carry around in my ~/bin since
the early '00s is the
sanity.pl
script written by Andreas Gohr. It just recently came back to use
when I started to archive some awesome Corona enforced live
session music with youtube-dl.
Update:
Francois Marier pointed out that Debian contains the
detox
package, which has a similar functionality.
DebConf8
This tshirt is 12 years old and from DebConf8.
DebConf8 was my 6th DebConf and took place in Mar de la Plata, Argentina.
Also this is my 6th post in this series of posts about DebConfs and for the
last two days for the first time I failed my plan to do one post per day.
And while two days ago I still planned to catch up on this by doing more than one
post in a day, I have now decided to give in to realities, which mostly
translates to sudden fantastic weather in Hamburg and other summer
related changes in life. So yeah, I still plan to do short posts about all the
DebConfs I was lucky to attend, but there might be days without a blog post.
Anyhow, Mar de la Plata.
When we held DebConf in Argentina it was winter there, meaning locals and other folks
would wear jackets, scarfs, probably gloves, while many Debian folks not so much.
Andreas Tille freaked out and/or amazed local people by going swimming in the sea
every morning. And when I told Stephen Gran that even I would find it a bit cold with
just a tshirt he replied "na, the weather is fine, just like british summer", while
it was 14 celcius and mildly raining.
DebConf8 was the first time I've met Valessio Brito, who I had worked together
since at least DebConf6. That meeting was really super nice, Valessio is such a lovely person.
Back in 2008 however, there was just one problem: his spoken English was worse than
his written one, and that was already hard to parse sometimes. Fast forward
eleven years to Curitiba last year and boom, Valessio speaks really nice English now.
And, you might wonder why I'm telling this, especially if you were exposed to my Spanish
back then and also now. So my point in telling this story about Valessio is to illustrate two things:
a.) one can contribute to Debian without speaking/writing much English, Valessio did
lots of great artwork since DebConf6 and b.) one can learn English by doing Debian stuff. It worked
for me too!
During set up of the conference there was one very memorable moment, some time after the
openssl maintainer, Kurt Roeckx arrived at the venue: Shortly
before DebConf8 Luciano Bello, from Argentina no less, had found
CVE-2008-0166 which
basically compromised the security of sshd of all Debian and Ubuntu installations done in the last
4 years (IIRC two Debian releases were affected) and which was
commented heavily and noticed everywhere.
So poor Kurt arrived and
wondered whether we would all hate him, how many toilets he would have to clean and what not...
And then, someone rather quickly noticed this, approached some people and suddenly
a bunch of people at DebConf were group-hugging Kurt
and then we were all smiling and continuing doing set up of the conference.
That moment is one of my most joyful memories of all DebConfs and partly explains
why I remember little about the conference itself, everything else pales in comparison and
most things pale over the years anyway. As I remember it, the conference ran
very smoothly in the end, despite quite some organisational problems right before the start.
But as usual, once the geeks arrive and are happily geeking, things start to run smooth,
also because Debian people are kind and smart and give hands and brain were needed.
And like other DebConfs, Mar de la Plata also had moments which I want to share but I will only hint
about, so it's up to you to imagine the special leaves which were brought to that cheese and wine party! Update: added another xkcd link, spelled out Kurt's name after talking to him and added a link to a video of the group hug.
Long story short, a fast solution for the issue with EGLSetBlobFuncANDROID is
to remove libraspberrypi-dev from your sysroot and do a full rebuild. There
will be some changes to the configure results, so please review them - if
they are relevant for you - before proceeding with your work.
That got me unstuck! dpkg --purge libraspberrypi-dev in the sysroot, and
we're back in the game.
While Qt5's build has proven extremely fragile, I was surprised that some
customization from Raspberry Pi hadn't yet broken something.
In the end, they didn't disappoint.
More i386 issues
The run now stops with a new 32bit issue related to v8 snapshots:
qt-everywhere-src-5.15.0/qtwebengine/src/core/release$/usr/bin/g++-pie-Wl,--fatal-warnings-Wl,--build-id=sha1-fPIC-Wl,-z,noexecstack-Wl,-z,relro-Wl,-z,now-Wl,-z,defs-Wl,--as-needed-m32-pie-Wl,--disable-new-dtags-Wl,-O2-Wl,--gc-sections-o"v8_snapshot/mksnapshot"-Wl,--start-group@"v8_snapshot/mksnapshot.rsp"-Wl,--end-group-ldl-lpthread-lrt-lz/usr/bin/ld:skippingincompatible//usr/lib/x86_64-linux-gnu/libz.so when searching for -lz/usr/bin/ld:skippingincompatible//usr/lib/x86_64-linux-gnu/libz.a when searching for -lz/usr/bin/ld:cannotfind-lzcollect2:error:ldreturned1exitstatus
Attempted solution: apt install zlib1g-dev:i386.
Alternative solution (untried): configure Qt5 with -no-webengine-v8-snapshot.
It builds!
Installation paths
Now it tries to install files into debian/tmp/home/build/sysroot/opt/qt5custom-armhf/.
I realise that I now need to package the sysroot itself, both as a build-dependency
of the Qt5 cross-compiler, and as a runtime dependency of the built cross-builder.
Conclusion
The current work in progress, patches, and all, is at
https://github.com/Truelite/qt5custom/tree/master/debian-cross-qtwebengine
It blows my mind how ridiculously broken is the Qt5 cross-compiler build, for a
use case that, looking at how many people are trying, seems to be one of the
main ones for the cross-builder.
This is part of a series of posts on compiling a custom version of Qt5 in order
to develop for both amd64 and a Raspberry Pi.
Now that I have a sysroot,
I try to use it to build Qt5 with QtWebEngine.
Nothing seems to work straightforwardly with Qt5's build system, and hit an
endless series of significant blockers to try and work around.
Problem in wayland code
QtWayland's source currently does not compile:
../../../hardwareintegration/client/brcm-egl/qwaylandbrcmeglwindow.cpp: In constructor QtWaylandClient::QWaylandBrcmEglWindow::QWaylandBrcmEglWindow(QWindow*) :../../../hardwareintegration/client/brcm-egl/qwaylandbrcmeglwindow.cpp:131:67: error: no matching function for call to QtWaylandClient::QWaylandWindow::QWaylandWindow(QWindow*&) , m_eventQueue(wl_display_create_queue(mDisplay->wl_display())) ^
In file included from ../../../../include/QtWaylandClient/5.15.0/QtWaylandClient/private/qwaylandwindow_p.h:1,
from ../../../hardwareintegration/client/brcm-egl/qwaylandbrcmeglwindow.h:43,
from ../../../hardwareintegration/client/brcm-egl/qwaylandbrcmeglwindow.cpp:40:
../../../../include/QtWaylandClient/5.15.0/QtWaylandClient/private/../../../../../src/client/qwaylandwindow_p.h:97:5: note: candidate: QtWaylandClient::QWaylandWindow::QWaylandWindow(QWindow*, QtWayland
Client::QWaylandDisplay*)
QWaylandWindow(QWindow *window, QWaylandDisplay *display);
^~~~~~~~~~~~~~
../../../../include/QtWaylandClient/5.15.0/QtWaylandClient/private/../../../../../src/client/qwaylandwindow_p.h:97:5: note: candidate expects 2 arguments, 1 provided
make[5]: Leaving directory '/home/build/armhf/qt-everywhere-src-5.15.0/qttools/src/qdoc'
I am not trying to debug here. I understand that Wayland support is not a
requirement, and I'm adding -skip wayland to Qt5's configure options.
Next round.
nss not found
Qt5 embeds Chrome's sources. Chrome's sources require libnss3-dev to be
available for both host and target architectures. Although I now have it
installed both on the build system and in the sysroot, the pkg-config wrapper
that Qt5 hooks into its Chrome's sources, failes to find it:
Command: /usr/bin/python2 /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/3rdparty/chromium/build/config/linux/pkg-config.py -s /home/build/sysroot/ -a arm -p /usr/bin/arm-linux-gnueabihf-pkg-config --system_libdir lib nss -v -lssl3
Returned 1.
stderr:
Package nss was not found in the pkg-config search path.
Perhaps you should add the directory containing nss.pc'
to the PKG_CONFIG_PATH environment variable
No package 'nss' found
Traceback (most recent call last):
File "/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/3rdparty/chromium/build/config/linux/pkg-config.py", line 248, in <module>
sys.exit(main())
File "/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/3rdparty/chromium/build/config/linux/pkg-config.py", line 143, in main
prefix = GetPkgConfigPrefixToStrip(options, args)
File "/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/3rdparty/chromium/build/config/linux/pkg-config.py", line 82, in GetPkgConfigPrefixToStrip
"--variable=prefix"] + args, env=os.environ).decode('utf-8')
File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['/usr/bin/arm-linux-gnueabihf-pkg-config', '--variable=prefix', 'nss']' returned non-zero exit status 1
See //build/config/linux/nss/BUILD.gn:15:3: whence it was called.
pkg_config("system_nss_no_ssl_config")
^---------------------------------------
See //crypto/BUILD.gn:218:25: which caused the file to be included.
public_configs += [ "//build/config/linux/nss:system_nss_no_ssl_config" ]
^--------------------------------------------------
Project ERROR: GN run error!
It's trying to look into $SYSROOT/usr/lib/pkgconfig, while it should be
$SYSROOT//usr/lib/arm-linux-gnueabihf/pkgconfig.
I worked around this this patch to qtwebengine/src/3rdparty/chromium/build/config/linux/pkg-config.py:
Next round.
g++ 8.3.0 Internal Compiler Error
Qt5's sources embed Chrome's sources that embed the skia library sources.
One of the skia library sources, when cross-compiled to ARM with -O1 or -O2
with g++ 8.3.0, produces an Internal Compiler Error:
/usr/bin/arm-linux-gnueabihf-g++ -MMD -MF obj/skia/skcms/skcms.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCR_SYSROOT_HASH=76e6068f9f6954e2ab1ff98ce5fa236d3d85bcbd -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../3rdparty/chromium/third_party/skia/include/third_party/skcms -Igen -I../../3rdparty/chromium -w -std=c11 -mfp16-format=ieee -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-psabi -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti --sysroot=../../../../../../sysroot/ -fvisibility-inlines-hidden -c ../../3rdparty/chromium/third_party/skia/third_party/skcms/skcms.cc -o obj/skia/skcms/skcms.o
during RTL pass: expand
In file included from ../../3rdparty/chromium/third_party/skia/third_party/skcms/skcms.cc:2053:
../../3rdparty/chromium/third_party/skia/third_party/skcms/src/Transform_inl.h: In function void baseline::exec_ops(const Op*, const void**, const char*, char*, int) :
../../3rdparty/chromium/third_party/skia/third_party/skcms/src/Transform_inl.h:766:13: internal compiler error: in convert_move, at expr.c:218
static void exec_ops(const Op* ops, const void** args,
^~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-8/README.Bugs> for instructions.
I reported the bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96206
Since this source compiles with -O0, I attempted to fix this by editing
qtwebkit/src/3rdparty/chromium/build/config/compiler/BUILD.gn and replacing
instances of -O1 and -O2 with -O0.
Spoiler: wrong attempt. We'll see it in the next round.
Impossible constraint in asm
Qt5's sources embed Chrome's sources that embed the
ffmpeg library sources. Even if ffmpeg's development
libraries are present both in the host and in the target system, the build
system insists in compiling and using the bundled version.
Unfortunately, using -O0 breaks the build of ffmpeg:
/usr/bin/arm-linux-gnueabihf-gcc -MMD -MF obj/third_party/ffmpeg/ffmpeg_internal/opus.o.d -DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE -D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DCR_SYSROOT_HASH=76e6068f9f6954e2ab1ff98ce5fa236d3d85bcbd -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DOPUS_FIXED_POINT -I../../3rdparty/chromium/third_party/ffmpeg/chromium/config/Chromium/linux/arm -I../../3rdparty/chromium/third_party/ffmpeg -I../../3rdparty/chromium/third_party/ffmpeg/compat/atomics/gcc -Igen -I../../3rdparty/chromium -I../../3rdparty/chromium/third_party/opus/src/include -fPIC -Wno-deprecated-declarations -fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb -g0 -fvisibility=hidden -Wno-psabi -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O0 -fno-ident -fdata-sections -ffunction-sections -std=gnu11 --sysroot=../../../../../../sysroot/ -c ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/opus.c -o obj/third_party/ffmpeg/ffmpeg_internal/opus.o
In file included from ../../3rdparty/chromium/third_party/ffmpeg/libavutil/intmath.h:30,
from ../../3rdparty/chromium/third_party/ffmpeg/libavutil/common.h:106,
from ../../3rdparty/chromium/third_party/ffmpeg/libavutil/avutil.h:296,
from ../../3rdparty/chromium/third_party/ffmpeg/libavutil/audio_fifo.h:30,
from ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/opus.h:28,
from ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/opus_celt.h:29,
from ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/opus.c:32:
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/opus.c: In function ff_celt_quant_bands :
../../3rdparty/chromium/third_party/ffmpeg/libavutil/arm/intmath.h:77:5: error: impossible constraint in asm
__asm__ ("usat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p));
^~~~~~~
The same source compiles with using -O2 instead of -O0.
I worked around this by undoing the previous change, and
limiting -O0
to just the source that causes the Internal Compiler Error.
I edited qtwebengine/src/3rdparty/chromium/third_party/skia/third_party/skcms/skcms.cc to prepend:
Next round.
Missing build-deps for i386 code
Qt5's sources embed Chrome's sources that embed the V8 library sources.
For some reason, torque, that is part of V8, wants to build some of its sources
into 32 bit code with -m32, and I did not have i386 cross-compilation
libraries installed:
/usr/bin/arm-linux-gnueabihf-g++ -MMD -MF obj/QtWebEngineCore/display_gl_output_surface.o.d -DCHROMIUM_VERSION=\"80.0.3987.163\" -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DCR_SYSROOT_HASH=76e6068f9f6954e2ab1ff98ce5fa236d3d85bcbd -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DQT_NO_LINKED_LIST -DQT_NO_KEYWORDS -DQT_USE_QSTRINGBUILDER -DQ_FORWARD_DECLARE_OBJC_CLASS=QT_FORWARD_DECLARE_CLASS -DQTWEBENGINECORE_VERSION_STR=\"5.15.0\" -DQTWEBENGINEPROCESS_NAME=\"QtWebEngineProcess\" -DBUILDING_CHROMIUM -DQTWEBENGINE_EMBEDDED_SWITCHES -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QMLMODELS_LIB -DQT_WEBCHANNEL_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_POSITIONING_LIB -DQT_CORE_LIB -DQT_WEBENGINECOREHEADERS_LIB -DVK_NO_PROTOTYPES -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DU_USING_ICU_NAMESPACE=0 -DU_ENABLE_DYLOAD=0 -DUSE_CHROMIUM_ICU=1 -DU_STATIC_IMPLEMENTATION -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_FILE -DUCHAR_TYPE=uint16_t -DWEBRTC_NON_STATIC_TRACE_EVENT_HANDLERS=0 -DWEBRTC_CHROMIUM_BUILD -DWEBRTC_POSIX -DWEBRTC_LINUX -DABSL_ALLOCATOR_NOTHROW=1 -DWEBRTC_USE_BUILTIN_ISAC_FIX=1 -DWEBRTC_USE_BUILTIN_ISAC_FLOAT=0 -DHAVE_SCTP -DNO_MAIN_THREAD_WRAPPING -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\" -DSK_GL -DSK_HAS_JPEG_LIBRARY -DSK_USE_LIBGIFCODEC -DSK_VULKAN_HEADER=\"../../skia/config/SkVulkanConfig.h\" -DSK_VULKAN=1 -DSK_SUPPORT_GPU=1 -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DVK_NO_PROTOTYPES -DLEVELDB_PLATFORM_CHROMIUM=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DV8_31BIT_SMIS_ON_64BIT_ARCH -DV8_DEPRECATION_WARNINGS -I../../3rdparty/chromium/skia/config -I../../3rdparty/chromium/third_party -I../../3rdparty/chromium/third_party/boringssl/src/include -I../../3rdparty/chromium/third_party/skia/include/core -Igen -I../../3rdparty/chromium -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/api -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQuick/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQuick/5.15.0/QtQuick -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtGui/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtGui/5.15.0/QtGui -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQuick -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtGui -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQmlModels/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQmlModels/5.15.0/QtQmlModels -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQml/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQml/5.15.0/QtQml -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtCore/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtCore/5.15.0/QtCore -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQmlModels -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebchannel/include -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebchannel/include/QtWebChannel -I/home/build/armhf/qt-everywhere-src-5.15.0/qtdeclarative/include/QtQml -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtNetwork -I/home/build/armhf/qt-everywhere-src-5.15.0/qtlocation/include -I/home/build/armhf/qt-everywhere-src-5.15.0/qtlocation/include/QtPositioning -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/include/QtCore -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/include -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/include/QtWebEngineCore -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/include/QtWebEngineCore/5.15.0 -I/home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/include/QtWebEngineCore/5.15.0/QtWebEngineCore -I.moc -I/home/build/sysroot/opt/vc/include -I/home/build/sysroot/opt/vc/include/interface/vcos/pthreads -I/home/build/sysroot/opt/vc/include/interface/vmcs_host/linux -Igen/.moc -I/home/build/armhf/qt-everywhere-src-5.15.0/qtbase/mkspecs/devices/linux-rasp-pi2-g++ -Igen -Igen -I../../3rdparty/chromium/third_party/libyuv/include -Igen -I../../3rdparty/chromium/third_party/jsoncpp/source/include -I../../3rdparty/chromium/third_party/jsoncpp/generated -Igen -Igen -I../../3rdparty/chromium/third_party/khronos -I../../3rdparty/chromium/gpu -I../../3rdparty/chromium/third_party/vulkan/include -I../../3rdparty/chromium/third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen -Igen -Igen/third_party/dawn/src/include -I../../3rdparty/chromium/third_party/dawn/src/include -Igen -I../../3rdparty/chromium/third_party/boringssl/src/include -I../../3rdparty/chromium/third_party/protobuf/src -Igen/protoc_out -I../../3rdparty/chromium/third_party/protobuf/src -I../../3rdparty/chromium/third_party/ced/src -I../../3rdparty/chromium/third_party/icu/source/common -I../../3rdparty/chromium/third_party/icu/source/i18n -I../../3rdparty/chromium/third_party/webrtc_overrides -I../../3rdparty/chromium/third_party/webrtc -Igen/third_party/webrtc -I../../3rdparty/chromium/third_party/abseil-cpp -I../../3rdparty/chromium/third_party/skia -I../../3rdparty/chromium/third_party/libgifcodec -I../../3rdparty/chromium/third_party/vulkan/include -I../../3rdparty/chromium/third_party/skia/third_party/vulkanmemoryallocator -I../../3rdparty/chromium/third_party/vulkan/include -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -Igen/third_party/perfetto -I../../3rdparty/chromium/third_party/crashpad/crashpad -I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/non_mac -I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/linux -I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/non_win -I../../3rdparty/chromium/third_party/libwebm/source -I../../3rdparty/chromium/third_party/leveldatabase -I../../3rdparty/chromium/third_party/leveldatabase/src -I../../3rdparty/chromium/third_party/leveldatabase/src/include -I../../3rdparty/chromium/v8/include -Igen/v8/include -I../../3rdparty/chromium/third_party/mesa_headers -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pipe -pthread -march=armv7-a -mfloat-abi=hard -mtune=generic-armv7-a -mfpu=vfpv3-d16 -mthumb -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-psabi -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fvisibility=hidden -g -O2 -fdebug-prefix-map=/home/build/armhf/qt-everywhere-src-5.15.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -fno-exceptions -Wall -Wextra -D_REENTRANT -I/home/build/sysroot/usr/include/nss -I/home/build/sysroot/usr/include/nspr -std=gnu++14 -Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess -Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno-deprecated-copy -fno-exceptions -fno-rtti --sysroot=../../../../../../sysroot/ -fvisibility-inlines-hidden -g -O2 -fdebug-prefix-map=/home/build/armhf/qt-everywhere-src-5.15.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -std=gnu++1y -fno-exceptions -Wall -Wextra -D_REENTRANT -Wno-unused-parameter -Wno-unused-variable -Wno-deprecated-declarations -c /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp -o obj/QtWebEngineCore/display_gl_output_surface.o
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_interface.h:8,
from ../../3rdparty/chromium/gpu/command_buffer/client/client_transfer_cache.h:15,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:28,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
/home/build/sysroot/opt/vc/include/GLES2/gl2.h:78: warning: "GL_FALSE" redefined
#define GL_FALSE (GLboolean)0
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/client_context_state.h:10,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:27,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
../../3rdparty/chromium/third_party/khronos/GLES3/gl3.h:85: note: this is the location of the previous definition
#define GL_FALSE 0
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_interface.h:8,
from ../../3rdparty/chromium/gpu/command_buffer/client/client_transfer_cache.h:15,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:28,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
/home/build/sysroot/opt/vc/include/GLES2/gl2.h:79: warning: "GL_TRUE" redefined
#define GL_TRUE (GLboolean)1
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/client_context_state.h:10,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:27,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
../../3rdparty/chromium/third_party/khronos/GLES3/gl3.h:86: note: this is the location of the previous definition
#define GL_TRUE 1
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_interface.h:8,
from ../../3rdparty/chromium/gpu/command_buffer/client/client_transfer_cache.h:15,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:28,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
/home/build/sysroot/opt/vc/include/GLES2/gl2.h:600:37: error: conflicting declaration of C function void glShaderSource(GLuint, GLsizei, const GLchar**, const GLint*)
GL_APICALL void GL_APIENTRY glShaderSource (GLuint shader, GLsizei count, const GLchar** string, const GLint* length);
^~~~~~~~~~~~~~
In file included from ../../3rdparty/chromium/gpu/command_buffer/client/client_context_state.h:10,
from ../../3rdparty/chromium/gpu/command_buffer/client/gles2_implementation.h:27,
from /home/build/armhf/qt-everywhere-src-5.15.0/qtwebengine/src/core/compositor/display_gl_output_surface.cpp:47:
../../3rdparty/chromium/third_party/khronos/GLES3/gl3.h:624:29: note: previous declaration void glShaderSource(GLuint, GLsizei, const GLchar* const*, const GLint*)
GL_APICALL void GL_APIENTRY glShaderSource (GLuint shader, GLsizei count, const GLchar *const*string, const GLint *length);
^~~~~~~~~~~~~~
cc1plus: warning: unrecognized command line option -Wno-deprecated-copy
I'm out of the allocated hour budget, and I'll stop here for now.
Building Qt5 has been providing some of the most nightmarish work time in my
entire professional life. If my daily job became being required to deal with
this kind of insanity, I would strongly invest in a change of career.
Update
Andreas Gruber wrote:
Long story short, a fast solution for the issue with EGLSetBlobFuncANDROID is
to remove libraspberrypi-dev from your sysroot and do a full rebuild. There
will be some changes to the configure results, so please review them - if
they are relevant for you - before proceeding with your work.
Welcome to the June 2020 report from the Reproducible Builds project. In these reports we outline the most important things that we and the rest of the community have been up to over the past month.
What are reproducible builds?
One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security.
But whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into seemingly secure software during the various compilation and distribution processes.
News
The GitHub Security Lab published a long article on the discovery of a piece of malware designed to backdoor open source projects that used the build process and its resulting artifacts to spread itself. In the course of their analysis and investigation, the GitHub team uncovered 26 open source projects that were backdoored by this malware and were actively serving malicious code. (Full article)
Carl Dong from Chaincode Labs uploaded a presentation on Bitcoin Build System Security and reproducible builds to YouTube:
The app intended to trace infection chains of Covid-19 in Switzerland published information on how to perform a reproducible build.
The Reproducible Builds project has received funding in the past from the Open Technology Fund (OTF) to reach specific technical goals, as well as to enable the project to meet in-person at our summits. The OTF has actually also assisted countless other organisations that promote transparent, civil society as well as those that provide tools to circumvent censorship and repressive surveillance. However, the OTF has now been threatened with closure. (More info)
It was noticed that Reproducible Builds was mentioned in the book End-user Computer Security by Mark Fernandes (published by WikiBooks) in the section titled Detection of malware in software.
Lastly, reproducible builds and other ideas around software supply chain were mentioned in a recent episode of the Ubuntu Podcast in a wider discussion about the Snap and application stores (at approx 16:00).
Distribution work
In the ArchLinux distribution, a goal to remove .doctrees from installed files was created via Arch s TODO list mechanism. These .doctree files are caches generated by the Sphinx documentation generator when developing documentation so that Sphinx does not have to reparse all input files across runs. They should not be packaged, especially as they lead to the package being unreproducible as their pickled format contains unreproducible data. Jelle van der Waa and Eli Schwartz submitted various upstream patches to fix projects that install these by default.
Dimitry Andric was able to determine why the reproducibility status of FreeBSD s base.txz depended on the number of CPU cores, attributing it to an optimisation made to the Clang C compiler []. After further detailed discussion on the FreeBSD bug it was possible to get the binaries reproducible again [].
For the GNU Guix operating system, Vagrant Cascadian started a thread about collecting reproducibility metrics and Jan janneke Nieuwenhuizen posted that they had further reduced their bootstrap seed to 25% which is intended to reduce the amount of code to be audited to avoid potential compiler backdoors.
In openSUSE, Bernhard M. Wiedemann published his monthly Reproducible Builds status update as well as made the following changes within the distribution itself:
Debian
Holger Levsen filed three bugs (#961857, #961858 & #961859) against the reproducible-check tool that reports on the reproducible status of installed packages on a running Debian system. They were subsequently all fixed by Chris Lamb [][][].
Timo R hling filed a wishlist bug against the debhelper build tool impacting the reproducibility status of 100s of packages that use the CMake build system which led to a number of tests and next steps. []
Chris Lamb contributed to a conversation regarding the nondeterministic execution of order of Debian maintainer scripts that results in the arbitrary allocation of UNIX group IDs, referencing the Tails operating system s approach this []. Vagrant Cascadian also added to a discussion regarding verification formats for reproducible builds.
47 reviews of Debian packages were added, 37 were updated and 69 were removed this month adding to our knowledge about identified issues. Chris Lamb identified and classified a new uids_gids_in_tarballs_generated_by_cmake_kde_package_app_templates issue [] and updated the paths_vary_due_to_usrmerge as deterministic issue, and Vagrant Cascadian updated the cmake_rpath_contains_build_path and gcc_captures_build_path issues. [][][].
Lastly, Debian Developer Bill Allombert started a mailing list thread regarding setting the -fdebug-prefix-map command-line argument via an environment variable and Holger Levsen also filed three bugs against the debrebuild Debian package rebuilder tool (#961861, #961862 & #961864).
Development
On our website this month, Arnout Engelen added a link to our Mastodon account [] and moved the SOURCE_DATE_EPOCHgit log example to another section []. Chris Lamb also limited the number of news posts to avoid showing items from (for example) 2017 [].
strip-nondeterminism is our tool to remove specific non-deterministic results from a completed build. It is used automatically in most Debian package builds. This month, Mattia Rizzolo bumped the debhelper compatibility level to 13 [] and adjusted a related dependency to avoid potential circular dependency [].
Upstream work
The Reproducible Builds project attempts to fix unreproducible packages and we try to to send all of our patches upstream. This month, we wrote a large number of such patches including:
Bernhard M. Wiedemann also filed reports for frr (build fails on single-processor machines), ghc-yesod-static/git-annex (a filesystem ordering issue) and ooRexx (ASLR-related issue).
diffoscope
diffoscope is our in-depth diff-on-steroids utility which helps us diagnose reproducibility issues in packages. It does not define reproducibility, but rather provides a helpful and human-readable guidance for packages that are not reproducible, rather than relying essentially-useless binary diffs.
This month, Chris Lamb uploaded versions 147, 148 and 149 to Debian and made the following changes:
New features:
Add output from strings(1) to ELF binaries. (#148)
Dump PE32+ executables (such as EFI applications) using objdump(1). (#181)
Drop accidentally-duplicated copy of the --diff-mask tests. []
Don t mask an existing test. []
Codebase improvements:
Replace obscure references to WF with Wagner-Fischer for clarity. []
Use a semantic AbstractMissingType type instead of remembering to check for both types of missing files. []
Add a comment regarding potential security issue in the .changes, .dsc and .buildinfo comparators. []
Drop a large number of unused imports. [][][][][]
Make many code sections more Pythonic. [][][][]
Prevent some variable aliasing issues. [][][]
Use some tactical f-strings to tidy up code [][] and remove explicit u"unicode" strings [].
Refactor a large number of routines for clarity. [][][][]
trydiffoscope is the web-based version of diffoscope. This month, Chris Lamb also corrected the location for the celerybeat scheduler to ensure that the clean/tidy tasks are actually called which had caused an accidental resource exhaustion. (#12)
In addition Jean-Romain Garnier made the following changes:
Fix the --new-file option when comparing directories by merging DirectoryContainer.compare and Container.compare. (#180)
Allow user to mask/filter diff output via --diff-mask=REGEX. (!51)
Make child pages open in new window in the --html-dir presenter format. []
Improve the diffs in the --html-dir format. [][]
Lastly, Daniel Fullmer fixed the Coreboot filesystem comparator [] and Mattia Rizzolo prevented warnings from the tlsh fuzzy-matching library during tests [] and tweaked the build system to remove an unwanted .build directory []. For the GNU Guix distribution Vagrant Cascadian updated the version of diffoscope to version 147 [] and later 148 [].
Testing framework
We operate a large and many-featured Jenkins-based testing framework that powers tests.reproducible-builds.org. Amongst many other tasks, this tracks the status of our reproducibility efforts across many distributions as well as identifies any regressions that have been introduced. This month, Holger Levsen made the following changes:
Don t try to build a disorderfs Debian source package. [][][]
Stop building diffoscope as we are moving this to Salsa. [][]
Merge several is diffoscope up-to-date on every platform? test jobs into one [] and fail less noisily if the version in Debian cannot be determined [].
In addition: Marcus Hoffmann was added as a maintainer of the F-Droid reproducible checking components [], Jelle van der Waa updated the is diffoscope up-to-date in every platform check for Arch Linux and diffoscope [], Mattia Rizzolo backed up a copy of a remove script run on the Codethink-hosted jump server [] and Vagrant Cascadian temporarily disabled the fixfilepath on bullseye, to get better data about the ftbfs_due_to_f-file-prefix-map categorised issue.
Lastly, the usual build node maintenance was performed by Holger Levsen [][], Mattia Rizzolo [] and Vagrant Cascadian [][][][][].
If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. However, you can get in touch with us via:
This month s report was written by Bernhard M. Wiedemann, Chris Lamb, Eli Schwartz, Holger Levsen, Jelle van der Waa and Vagrant Cascadian. It was subsequently reviewed by a bunch of Reproducible Builds folks on IRC and the mailing list.
I know most Debian people know about this already But in case you
don t follow the usual Debian communications channels, this might
interest you!
Given most of the world is still under COVID-19 restrictions, and that
we want to work on Debian, given there is no certainty as to what the
future holds in store for us Our DPL fearless as they always are
had the bold initiative to make this weekend into the first-ever
miniDebConf
Online
(MDCO)!
So, we are already halfway through DebCamp (which means, you can come
and hang out with us in the debian.social DebCamp Jitsi
lounge, where some
impromptu presentations might happen (or not).
Starting tomorrow morning (11AM UTC),
we will have a quite interesting set of talks. I am reproducing the
schedule here:
Saturday 2020.05.30
Time (UTC)
Speaker
Talk
11:00 - 11:10
MDCO team members
Hello + Welcome
11:30 - 11:50
Wouter Verhelst
Extrepo
12:00 - 12:45
JP Mengual
Debian France, trust european organization
13:00 - 13:20
Arnaud Ferraris
Bringing Debian to mobile phones, one package at a time
13:30 - 15:00
Lunch Break
A chance for the teams to catch some air
15:00 - 15:45
JP Mengual
The community team, United Nations Organizations of Debian?
16:00 - 16:45
Christoph Biedl
Clevis and tang - overcoming the disk unlocking problem
17:00 - 17:45
Antonio Terceiro
I m a programmer, how can I help Debian
Sunday 2020.05.31
Time (UTC)
Speaker
Talk
11:00 - 11:45
Andreas Tille
The effect of Covid-19 on the Debian Med project
12:00 - 12:45
Paul Gevers
BoF: running autopkgtest for your package
13:00 - 13:20
Ben Hutchings
debplate: Build many binary packages with templates
13:30 - 15:00
Lunch break
A chance for the teams to catch some air
15:00 - 15:45
Holger Levsen
Reproducing bullseye in practice
16:00 - 16:45
Jonathan Carter
Striving towards excellence
17:00 - 17:45
Delib*
Organizing Peer-to-Peer Debian Facilitation Training
18:00 - 18:15
MDCO team members
Closing
subject to confirmation
Timezone
Remember this is an online event, meant for all of the world! Yes, the
chosen times seem quite Europe-centric (but they are mostly a function
of the times the talk submitters requested).
Talks are 11:00 18:00UTC, which means, 06:00 13:00 Mexico (GMT-5),
20:00 03:00 Japan (GMT+9), 04:00 11:00 Western
Canada/USA/Mexico (GMT-7) and the rest of the world, somewhere in
between.
(No, this was clearly not optimized for our dear usual beer
team. Sorry! I
guess we need you to be fully awake at beertime!)
[update] Connecting!
Of course, I didn t make it clear at first how to connect to the
Online miniDebConf, silly me!
The video streams are available at: https://video.debconf.org/
Suggested: tune in to the #minidebconf-online IRC channel in OFTC.
That should be it. Hope to see you there!
(Stay home, stay safe )