Beaker one liner using xmllint:
bkr job-results J:61 | xmllint --xpath /job/recipeSet/recipe/roles/role -
<role value="RECIPE_MEMBERS"/>
The dash at the end makes it read from stdin
Daniel Pocock Jérémy Bobbio (Lunar), Magna Carta & Debian Freedoms: RIP
Jérémy Bobbio (Lunar) passed away on 8 November 2024. It is uncanny but that is exactly 30 years after Oregon voted to legalize euthanasia and it is exactly ten years after Lunar disclosed his cancer diagnosis on a Debian mailing list, debian-private, the gossip network that is being used to spread rumors about developers. While Lunar advanced computer security in many technical initiatives, the gossip on debian-private enables social engineering attacks, therefore, gossip is like a cancer too.
Here is the message from 26 November 2014, it was sent some days after the diagnosis, hence the observation that he lived with the disease for almost exactly 10 years. He thought it would just be a couple of months. It turns out people make mistakes.
Subject: [semi-VAC] A couple of months?
Date: Wed, 26 Nov 2014 20:42:26 +0100
From: Lunar <lunar@debian.org>
To: debian-private@lists.debian.org
My fellow Debianites,
I have been diagnosed with kidney cancer, and it seems there's some
metastases in my lungs. A few doctors have decided it's worth doing many
things to make me live some more. (Another privilege to acknowledge.)
I'm going to follow them and see where it goes…
The first things are going to come up pretty quickly now, but I'm not
sure how long treatments will last or how much they will affect me. What
is clear is that getting better will take most of my life in the next
weeks and probably months.
Please take care of my packages if I'm not responsive; or if I'm
responsive but don't follow-up afterwards. Basically, consider me
unreliable.
I want to keep working on reproducible builds at least a little, as
it's a good source of pleasure. You are welcome to join the fun. :)
[ Never to be disclosed. ]
Be well,
--
Lunar .''`. lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'` `-
Moving on from that, we can see that Lunar made significant contributions to the harassment of Dr Jacob Appelbaum. It appears that Lunar was opposed to everything that has been achieved for the right to due process since the signing of the Magna Carta over eight hundred years ago.
It is really important to look at this email now because the cool kids on debian-private might be using similar tactics in the GNOME conspiracy against Sonny Piers.
Lunar did not allow the cancer to get in the way of his fight against due process. He even went beyond that, advocating for gaslighting. Look at the comments about creating a "support group" to brainwash Dr Appelbaum to believe he really might be a rapist:
Subject: Re: Jacob Appelbaum and harrassement
Date: Fri, 17 Jun 2016 02:12:01 +0200
From: Jérémy Bobbio <lunar@debian.org>
To: debian-private@lists.debian.org
CC: da-manager@debian.org
Hi!
Since these stories have been published, I kept myself referring to a
zine [1] jointly done by two organizations working on supporting
survivors of sexual assault and ending rape culture. I strongly
recommend you have a look, it's not that long.
The zine list nine principles on how to support survivors of sexual
assault. They've been very helpful to me, you might want to have a look.
[1]: http://www.phillyspissed.net/sites/default/files/survivor-support.pdf
Konstantinos Margaritis:
> I'm curious, is everyone else OK with expulsion, without having heard the side of
> the accused first? Disclaimer, I do not have any interest to the Tor project, and
> this is the first time I've actually heard of Jacob and his behaviour. I'm assuming
> that all the stories are true, but I'm not at all comfortable with expulsion,
> or any other "punishment" coming officially from Debian, without first hearing his
> side and at least having given him the right to respond to many of the emails here.
The process you describe is modeled on “coercive justice”. I think we
should instead be supporting survivors, and making sure that Debian can
be as safe and welcoming as possible.
The first principle given in the above zine is “Health & Safety First”,
and the second is “Restore Choice”.
So let's hear what people who have been abused has to say on what needs
to be done for their health and safety:
Alison Macrina who has been advocating Debian and its derivatives to
many libraries and activists has made the following demand in her
statement, amongst others [2]:
Jake must be excluded from all community activities as a
precondition for healing.
Isis Lovecruft who attended DebConf13 and is a longtime Debian user and
advocate has made the following demand to the communities, amongst
others [3]:
We need to entirely remove abusers from our communities, until such
a time as they have sufficiently demonstrated to their victims that
their abusive behaviours will no longer continue. Jake should be
removed from all places where his victims, their loved ones, and
friends might come into any form of contact with him. Given the
enormous amounts of pain myself and the other victims have gone
through, the draining emotional stress, and (please excuse my rather
dark humour) the development time wasted, I am not willing to
revisit this issue for at least four years. After that time has
passed, it may be possible to reassess whether there is any path
forward for Jake.
As such I support preventing Jacob Appelbaum from participating in
Debian until a process took place for him to work on his issues enough
to make those who have been abused and their friends confident that he
will not commit more abuses.
[2]: https://medium.com/@flexlibris/theres-really-no-such-thing-as-the-voiceless-92b3fa45134d
[3]: https://blog.patternsinthevoid.net/the-forest-for-the-trees.html
If people want to care about Jake, I suggest listening to Alison again:
People who love Jake and want him to heal should make a support
group for him. Those people should bear in mind that he has not
apologized nor admitted to any wrongdoing, and they should hold him
accountable for what he’s done.
For how this can be done, you can get some ideas from the work of Philly
Stands Up which they have documented [4].
[4]: https://communityaccountability.files.wordpress.com/2012/06/philly-stands-up.pdf
Given some of the emails I've read here, we do have work to do in order
to keep Debian as safe and welcoming as possible. We do have to educate
ourselves and newcomers on boundaries, consent, gender-based violence,
abuse prevention, accountability processes…
Others already wrote a few things about this, so I'm not going to
develop further, and discussing this on public channels might probably
more effective.
Oh, and principle 8 is “It's Not About You”.
Seriously, it's not. Your needs won't help the people who have been
abused or Jake.
--
Lunar .''`. lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'` `-
In my last couple of blog posts on my own site and the Software Freedom Institute site, I've discussed the invalid Swiss judgment based on lies and forgeries. One thing that people have failed to notice is the false judgment attacks the principle of free redistribution. It is this paragraph here:
Translated to English, it says:
Daniel Pocock has revoked the Debian Project Code of Conduct and stated that he has the right to authorize joint authors to use the name Debian in domains. On the site debiangnulinux.org, he has used the Debian open use logo and he has offered a copy of Debian for people to download.
The Debian Code of Conduct was never accepted or consented to by the vast majority of Debian co-authors. Less than 25% of co-authors consented to the Code of Conduct. Therefore, it was not even valid in the first place. You can't revoke a Code of Conduct that wasn't valid in the first place.
The use of the Debian open use logo is authorized very clearly.
If somebody was distributing a virus or some other random software under the name Debian it would be confusing and wrong. But what they accuse me of doing is distributing a genuine copy of Debian. Debian was the birthplace of the Debian Free Software Guidelines and the right to distribute genuine copies of Debian has always been there.
Moreoever, any co-author or joint author of intellectual property has the right to unilaterally redistribute copies of the joint work as they see fit, according to this legal guidance from UC Berkeley:
Joint authorship occurs when two or more people work together on a creative work. In this case, all creators have equal rights to distribute and alter the work, and they must split profits among each other.
That is always the case unless we have entered into a signed agreement with colleagues whereby we agree to only distribute the work through a specific agent or channel. Employment contracts for IT workers almost always include provisions to prevent such unilateral distribution but in Debian, we are not employees and we never signed anything giving up our rights under copyright law.
Pretending that some of us don't have the right to redistribute copies of Debian is a form of gaslighting, a lot like gaslighting Dr Appelbaum with a "support group" to brainwash him to believe the social media rumors that he could be a rapist.
Therefore, while the judgment is invalid, it appears to be contradicting the DFSG. What they have written is actually worse than IBM Red Hat's decision to restrict the RHEL source code.
Lunar, Magna Carta & Debian Social Contract. Rest In Peace.
Richard W.M. Jones Benchmarking RISC-V SpaceMIT X60 and others
I recently received 4 Milk-V Jupiter development boards, and one Banana Pi F3 through RISC-V International. All of these boards have the same (or very similar) SpaceMIT X60 SoC which is a fairly capable 8 core RISC-V processor.
model name : Spacemit(R) X60
isa : rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zca_zcd_zba_zbb_zbc_zbs_zkt_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmtSince we’ll be using all of these boards for Fedora package building I ran some simple benchmarks of how well they perform. The benchmark is to recompile this grub2 package to RPMs:
# dnf builddep grub2-2.12-11.0.riscv64.fc41.src.rpm
$ time rpmbuild --recompile grub2-2.12-11.0.riscv64.fc41.src.rpm(I did a few builds in a row until the times settled down, so these are all “hot cache” builds on an otherwise unloaded board.)
| Milk-V Jupiter | RISC-V SpaceMIT X60 8 cores 16GB RAM | 748s |
| Banana Pi | RISC-V SpaceMIT X60 8 cores 16GB RAM | 962s |
| VisionFive 2 | JH7110 4 cores 8GB RAM | 923s |
| Raspberry Pi 4 | ARM Cortex A72 4 cores 8 GB RAM | 753s |
| AMD gaming PC | AMD Ryzen 9 7950X 16 cores 64 GB RAM | 104s |
We should be getting a SiFive P550 development board soon which is the first widely available out-of-order RISC-V core.
(Thanks Andrea Bolognani for benchmarking the VF2)
Daniel Pocock Google-funded group distributed invalid Swiss judgment to deceive Midlands-North-West
A blog has appeared on the Software Freedom Institute web site proving that the defamatory Swiss judgment was invalid from the beginning. In fact, within a few weeks, it had been shot down in a response from the Swiss Intellectual Property Office.
The rogue Debianists clearly knew since December 2023 that their judgment document was invalid. Nonetheless, on the day before Ireland voted, they published the invalid judgment anyway along with a deceptive translation of what was in it.
By choosing to publish a document that they knew to be invalid and by doing so the day before voting, just hours before the news moratorium, it is clear that they intended to deceive the Irish media and the voters of Midlands-North-West.
On some metrics, like infrastructure, the region Midlands-North-West is one of the most disadvantaged in Europe. Therefore, the attempt by foreigners funded by Google to deceive this community is outrageous.
The blog by the Software Freedom Institute reveals that the publishers of the false document received Google funding. Looking at the DebConf web site, we can see that Google regularly sponsors the annual conference for Debianists.
The legal dispute started in early 2023. We can see that one of the leading sponsors of DebConf23 was Infomaniak, a competitor of the Software Freedom Institute in the Swiss market.
From the DebConf23 sponsors page, we can see Google and we can see Infomaniak, a competitor of the Institute, all had a hand in Debian's funding during the period of this dispute:
Adam Williamson AdamW's Debugging Adventures: Inadvertent Extreme Optimization
It's time for that rarest of events: a blog post! And it's another debugging adventure. Settle in, folks!
Recently I got interested in improving the time it takes to do a full compose of Fedora. This is when we start from just the packages and a few other inputs (basically image recipes and package groups), and produce a set of repositories and boot trees and images and all that stuff. For a long time this took somewhere between 5 and 10 hours. Recently we've managed to get it down to 3-4, then I figured out a change which has got it under 3 hours.
After that I re-analyzed the process and figured out that the biggest remaining point to attack is something called the 'pkgset' phase, which happens near the start of the process, not in parallel with anything else, and takes 35 minutes or so. So I started digging into that to see if it can be improved.
I fairly quickly found that it spends about 20 minutes in one relatively small codepath. It's created one giant package set (this is just a concept in memory at the time, it gets turned into an actual repo later) with every package in the compose in it. During this 20 minutes, it creates subsets of that package set per architecture, with only the packages relevant to that architecture in it (so packages for that arch, plus noarch packages, plus source packages, plus 'compatible' arches, like including i686 for x86_64).
I poked about at that code a bit and decided I could maybe make it a bit more efficient. The current version works by creating each arch subset one at a time by looping over the big global set. Because every arch includes noarch and src packages, it winds up looping over the noarch and src lists once per arch, which seemed inefficient. So I went ahead and rewrote it to create them all at once, to try and reduce the repeated looping.
Today I was testing that out, which unfortunately has to be done more or less 'in production', so if you like you can watch me here, where you'll see composes appearing and disappearing every fifteen minutes or so. At first of course my change didn't work at all because I'd made the usual few dumb mistakes with wrong variable names and stuff. After fixing all that up, I timed it, and it turned out about 7 minutes faster. Not earth shattering, but hey.
So I started checking it was accurate (i.e. created the same package sets as the old code). It turned out it wasn't quite (a subtle bug with noarch package exclusions). While fixing that, I ran across some lines in the code that had bugged me since the first time I started looking at it:
if i.file_path in self.file_cache:
# TODO: test if it really works
continue
These were extra suspicious to me because, not much later, they're followed by this:
self.file_cache.file_cache[i.file_path] = i
that is, we check if the thing is in self.file_cache and move on if it is, but if it's not, we add it to self.file_cache.file_cache? That didn't look right at all. But up till now I'd left it alone, because hey, it had been this way for years, right? Must be OK. Well, this afternoon, in passing, I thought "eh, let's try changing it".
Then things got weird.
I was having trouble getting the compose process to actually run exactly as it does in production, but once I did, I was getting what seemed like really bizarre results. The original code was taking 22 minutes in my tests. My earlier test of my branch had taken about 14 minutes. Now it was taking three seconds.
I thought, this can't possibly be right! So I spent a few hours running and re-running the tests, adding debug lines, trying to figure out how (surely) I had completely broken it and it was just bypassing the whole block, or something.
Then I thought...what if I go back to the original code, but change the cache thing?
So I went back to unmodified pungi code, commented out those three lines, ran a compose...and it took three seconds. Tried again with the check corrected to self.file_cache.file_cache instead of self.file_cache...three seconds.
I repeated this enough times that it must be true, but it still bugged me. So I just spent a while digging into it, and I think I know why. These file caches are kobo.pkgset.FileCache instances; see the source code here. So, what's the difference between foo in self.file_cache and foo in self.file_cache.file_cache? Well, a FileCache instance's own file_cache is a dict. FileCache instances also implement __iter__, returning iter(self.file_cache). I think this is why foo in self.file_cache works at all - it actually does do the right thing. But the key is, I think, that it does it inefficiently.
Python's preferred way to do foo in bar is to call bar.__contains__(foo). If that doesn't work, it falls back on iterating over bar until it either hits foo or runs out of iterations. If bar doesn't support iteration it just raises an exception.
Python dictionaries have a very efficient implementation of __contains__. So when we do foo in self.file_cache.file_cache, we hit that efficient algorithm. But FileCache does not implement __contains__, so when we do foo in self.file_cache, we fall back to iteration and wind up using that iterator over the dictionary's keys. This works, but is massively less efficient than the dictionary's __contains__ method would be. And because these package sets are absolutely fracking huge, that makes a very significant difference in the end (because we hit the cache check a huge number of times, and every time it has to iterate over a huge number of dict keys).
So...here's the pull request.
Turns out I could have saved the day and a half it took me to get my rewrite correct. And if anyone had ever got around to TODOing the TODO, we could've saved about 20 minutes out of every Fedora compose for the last nine years...
Peter Hutterer hidreport and hut: two crates for handling HID Report Descriptors and HID Reports
A while ago I was looking at Rust-based parsing of HID reports but, surprisingly, outside of C wrappers and the usual cratesquatting I couldn't find anything ready to use. So I figured, why not write my own, NIH style. Yay! Gave me a good excuse to learn API design for Rust and whatnot. Anyway, the result of this effort is the hidutils collection of repositories which includes commandline tools like hid-recorder and hid-replay but, more importantly, the hidreport (documentation) and hut (documentation) crates. Let's have a look at the latter two.
Both crates were intentionally written with minimal dependencies, they currently only depend on thiserror and arguably even that dependency can be removed.
HID Usage Tables (HUT)
As you know, HID Fields have a so-called "Usage" which is divided into a Usage Page (like a chapter) and a Usage ID. The HID Usage tells us what a sequence of bits in a HID Report represents, e.g. "this is the X axis" or "this is button number 5". These usages are specified in the HID Usage Tables (HUT) (currently at version 1.5 (PDF)). The hut crate is generated from the official HUT json file and contains all current HID Usages together with the various conversions you will need to get from a numeric value in a report descriptor to the named usage and vice versa. Which means you can do things like this:
let gd_x = GenericDesktop::X; let usage_page = gd_x.usage_page(); assert!(matches!(usage_page, UsagePage::GenericDesktop));Or the more likely need: convert from a numeric page/id tuple to a named usage.
let usage = Usage::new_from_page_and_id(0x1, 0x30); // GenericDesktop / X
println!("Usage is {}", usage.name());
90% of this crate are the various conversions from a named usage to the numeric value and vice versa. It's a huge crate in that there are lots of enum values but the actual functionality is relatively simple.
hidreport - Report Descriptor parsing
The hidreport crate is the one that can take a set of HID Report Descriptor bytes obtained from a device and parse the contents. Or extract the value of a HID Field from a HID Report, given the HID Report Descriptor. So let's assume we have a bunch of bytes that are HID report descriptor read from the device (or sysfs) we can do this:
let rdesc: ReportDescriptor = ReportDescriptor::try_from(bytes).unwrap();I'm not going to copy/paste the code to run through this report descriptor but suffice to day it will give us access to the input, output and feature reports on the device together with every field inside those reports. Now let's read from the device and parse the data for whatever the first field is in the report (this is obviously device-specific, could be a button, a coordinate, anything):
let input_report_bytes = read_from_device();
let report = rdesc.find_input_report(&input_report_bytes).unwrap();
let field = report.fields().first().unwrap();
match field {
Field::Variable(var) => {
let val: u32 = var.extract(&input_report_bytes).unwrap().into();
println!("Field {:?} is of value {}", field, val);
},
_ => {}
}
The full documentation is of course on docs.rs and I'd be happy to take suggestions on how to improve the API and/or add features not currently present.
hid-recorder
The hidreport and hut crates are still quite new but we have an existing test bed that we use regularly. The venerable hid-recorder tool has been rewritten twice already. Benjamin Tissoires' first version was in C, then a Python version of it became part of hid-tools and now we have the third version written in Rust. Which has a few nice features over the Python version and we're using it heavily for e.g. udev-hid-bpf debugging and development. An examle output of that is below and it shows that you can get all the information out of the device via the hidreport and hut crates.
$ sudo hid-recorder /dev/hidraw1 # Microsoft Microsoft® 2.4GHz Transceiver v9.0 # Report descriptor length: 223 bytes # 0x05, 0x01, // Usage Page (Generic Desktop) 0 # 0x09, 0x02, // Usage (Mouse) 2 # 0xa1, 0x01, // Collection (Application) 4 # 0x05, 0x01, // Usage Page (Generic Desktop) 6 # 0x09, 0x02, // Usage (Mouse) 8 # 0xa1, 0x02, // Collection (Logical) 10 # 0x85, 0x1a, // Report ID (26) 12 # 0x09, 0x01, // Usage (Pointer) 14 # 0xa1, 0x00, // Collection (Physical) 16 # 0x05, 0x09, // Usage Page (Button) 18 # 0x19, 0x01, // UsageMinimum (1) 20 # 0x29, 0x05, // UsageMaximum (5) 22 # 0x95, 0x05, // Report Count (5) 24 # 0x75, 0x01, // Report Size (1) 26 ... omitted for brevity # 0x75, 0x01, // Report Size (1) 213 # 0xb1, 0x02, // Feature (Data,Var,Abs) 215 # 0x75, 0x03, // Report Size (3) 217 # 0xb1, 0x01, // Feature (Cnst,Arr,Abs) 219 # 0xc0, // End Collection 221 # 0xc0, // End Collection 222 R: 223 05 01 09 02 a1 01 05 01 09 02 a1 02 85 1a 09 ... omitted for previty N: Microsoft Microsoft® 2.4GHz Transceiver v9.0 I: 3 45e 7a5 # Report descriptor: # ------- Input Report ------- # Report ID: 26 # Report size: 80 bits # | Bit: 8 | Usage: 0009/0001: Button / Button 1 | Logical Range: 0..=1 | # | Bit: 9 | Usage: 0009/0002: Button / Button 2 | Logical Range: 0..=1 | # | Bit: 10 | Usage: 0009/0003: Button / Button 3 | Logical Range: 0..=1 | # | Bit: 11 | Usage: 0009/0004: Button / Button 4 | Logical Range: 0..=1 | # | Bit: 12 | Usage: 0009/0005: Button / Button 5 | Logical Range: 0..=1 | # | Bits: 13..=15 | ######### Padding | # | Bits: 16..=31 | Usage: 0001/0030: Generic Desktop / X | Logical Range: -32767..=32767 | # | Bits: 32..=47 | Usage: 0001/0031: Generic Desktop / Y | Logical Range: -32767..=32767 | # | Bits: 48..=63 | Usage: 0001/0038: Generic Desktop / Wheel | Logical Range: -32767..=32767 | Physical Range: 0..=0 | # | Bits: 64..=79 | Usage: 000c/0238: Consumer / AC Pan | Logical Range: -32767..=32767 | Physical Range: 0..=0 | # ------- Input Report ------- # Report ID: 31 # Report size: 24 bits # | Bits: 8..=23 | Usage: 000c/0238: Consumer / AC Pan | Logical Range: -32767..=32767 | Physical Range: 0..=0 | # ------- Feature Report ------- # Report ID: 18 # Report size: 16 bits # | Bits: 8..=9 | Usage: 0001/0048: Generic Desktop / Resolution Multiplier | Logical Range: 0..=1 | Physical Range: 1..=12 | # | Bits: 10..=11 | Usage: 0001/0048: Generic Desktop / Resolution Multiplier | Logical Range: 0..=1 | Physical Range: 1..=12 | # | Bits: 12..=15 | ######### Padding | # ------- Feature Report ------- # Report ID: 23 # Report size: 16 bits # | Bits: 8..=9 | Usage: ff00/ff06: Vendor Defined Page 0xFF00 / Vendor Usage 0xff06 | Logical Range: 0..=1 | Physical Range: 1..=12 | # | Bits: 10..=11 | Usage: ff00/ff0f: Vendor Defined Page 0xFF00 / Vendor Usage 0xff0f | Logical Range: 0..=1 | Physical Range: 1..=12 | # | Bit: 12 | Usage: ff00/ff04: Vendor Defined Page 0xFF00 / Vendor Usage 0xff04 | Logical Range: 0..=1 | Physical Range: 0..=0 | # | Bits: 13..=15 | ######### Padding | ############################################################################## # Recorded events below in format: # E: . [bytes ...] # # Current time: 11:31:20 # Report ID: 26 / # Button 1: 0 | Button 2: 0 | Button 3: 0 | Button 4: 0 | Button 5: 0 | X: 5 | Y: 0 | # Wheel: 0 | # AC Pan: 0 | E: 000000.000124 10 1a 00 05 00 00 00 00 00 00 00
The packages are available for x86_64 and aarch64.
