Shirish Agarwal: Ayisha, Manju Warrier, Debutsav, Books
But I m drifting from the topic/movie. 
The counter of the FAI.me build service has reached 20.000. This
counter was added shortly after the service was started in
November 2017. Since then, this service has built more than 21.000
installation images and more than 1300 cloud disk images.
In the last few month we had averaged 100 requests per week.
Some statistics which settings are popular:
| 12000 | us |
| 4000 | de |
| 2500 | fr |
| 800 | gb |
| 500 | es |
| 300 | ru |
| 300 | cn |
| 200 | pt |
| 12000 | NONE (without any desktop) |
| 5000 | GNOME |
| 1800 | XFCE |
| 800 | KDE |
| 700 | CINNAMON |
| 700 | MATE |
| 500 | LXDE |
I've moved to having containers be first-class citizens on my home network, so
any local machine (laptop, phone,tablet) can communicate directly with them all,
but they're not (by default) exposed to the wider Internet. Here's why, and how.
After I moved containers from docker to Podman and
systemd, it became much more convenient to run web apps on
my home server, but the default approach to networking
(each container gets an address on a private network between the host server
and containers) meant tedious work (maintaining and reconfiguring a HTTP
reverse proxy) to make them reachable by other devices. A more attractive
arrangement would be if each container received an IP from the range used by
my home LAN, and were automatically addressable from any device on it.
To make the containers first-class citizens on my home LAN, first I needed to
configure a Linux network bridge and attach the host machine's interface to it
(I've done that many times before);
then define a new Podman network, of type "bridge". podman-network-create
(1)
serves as reference, but the blog post Exposing Podman containers fully on the
network
is an easier read (skip past the macvlan bit).
I've opted to choose IP addresses for each container by hand. The Podman
network is narrowly defined to a range of IPs that are within the subnet that
my ISP-provided router uses, but outside the range of IPs that it allocates.
When I start up a container by hand for the first time, I choose a free IP from
the sub-range by hand and add a line to /etc/avahi/hosts on the parent
machine, e.g.
192.168.1.33 octoprint.local
podman run --rm -d --name octoprint \
...
--network bridge_local --ip 192.168.1.33 \
octoprint/octoprint
octoprint.local.
What's next
Although it's not a huge burden, it would be nice to not need to statically
define the addresses in /etc/avahi/hosts (perhaps via "IPAM"). I've also been
looking at
WireGuard
(which should be the subject of a future blog post) and combining this with
that would be worthwhile.
[Note: the original version of this post named the author of the referenced blog post, and the tone of my writing could be construed to be mocking or otherwise belittling them.
While that was not my intention, I recognise that was a possible interpretation, and I have revised this post to remove identifying information and try to neutralise the tone.
On the other hand, I have kept the identifying details of the domain involved, as there are entirely legitimate security concerns that result from the issues discussed in this post.]
I have spoken before about why it is tricky to redact private keys.
Although that post demonstrated a real-world, presumably-used-in-the-wild private key, I ve been made aware of commentary along the lines of this representative sample:
I find it hard to believe that anyone would take their actual production key and redact it for documentation. Does the author have evidence of this in practice, or did they see example keys and assume they were redacted production keys?Well, buckle up, because today s post is another real-world case study, with rather higher stakes than the previous example.
xs.
Based on the steps I explained previously, it is relatively straightforward to retrieve the entire, intact private key.
72bef096997ec59a671d540d75bd1926363b2097eb9fe10220b2654b1f665b54
Searching for certificates which use that key fingerprint, we find one result: a certificate for hiltonhotels.jp (and a bunch of other, related, domains, as subjectAltNames).
As of the time of writing, that certificate is not marked as revoked, and appears to be the same certificate that is currently presented to visitors of that site.
This is, shall we say, not great.
Anyone in possession of this private key which, I should emphasise, has presumably been public information since the post s publication date of February 2023 has the ability to completely transparently impersonate the sites listed in that certificate.
That would provide an attacker with the ability to capture any data a user entered, such as personal information, passwords, or payment details, and also modify what the user s browser received, including injecting malware or other unpleasantness.
In short, no good deed goes unpunished, and this attempt to educate the world at large about the benefits of secure key storage has instead published private key material.
Remember, kids: friends don t let friends post redacted private keys to the Internet.
Debian v12 with codename bookworm was released as new stable release on 10th of June 2023. Similar to what we had with #newinbullseye and previous releases, now it s time for #newinbookworm!
I was the driving force at several of my customers to be well prepared for bookworm. As usual with major upgrades, there are some things to be aware of, and hereby I m starting my public notes on bookworm that might be worth also for other folks. My focus is primarily on server systems and looking at things from a sysadmin perspective.
Further readings
As usual start at the official Debian release notes, make sure to especially go through What s new in Debian 12 + Issues to be aware of for bookworm.
Package versions
As a starting point, let s look at some selected packages and their versions in bullseye vs. bookworm as of 2023-02-10 (mainly having amd64 in mind):
| Package | bullseye/v11 | bookworm/v12 |
|---|---|---|
| ansible | 2.10.7 | 2.14.3 |
| apache | 2.4.56 | 2.4.57 |
| apt | 2.2.4 | 2.6.1 |
| bash | 5.1 | 5.2.15 |
| ceph | 14.2.21 | 16.2.11 |
| docker | 20.10.5 | 20.10.24 |
| dovecot | 2.3.13 | 2.3.19 |
| dpkg | 1.20.12 | 1.21.22 |
| emacs | 27.1 | 28.2 |
| gcc | 10.2.1 | 12.2.0 |
| git | 2.30.2 | 2.39.2 |
| golang | 1.15 | 1.19 |
| libc | 2.31 | 2.36 |
| linux kernel | 5.10 | 6.1 |
| llvm | 11.0 | 14.0 |
| lxc | 4.0.6 | 5.0.2 |
| mariadb | 10.5 | 10.11 |
| nginx | 1.18.0 | 1.22.1 |
| nodejs | 12.22 | 18.13 |
| openjdk | 11.0.18 + 17.0.6 | 17.0.6 |
| openssh | 8.4p1 | 9.2p1 |
| openssl | 1.1.1n | 3.0.8-1 |
| perl | 5.32.1 | 5.36.0 |
| php | 7.4+76 | 8.2+93 |
| podman | 3.0.1 | 4.3.1 |
| postfix | 3.5.18 | 3.7.5 |
| postgres | 13 | 15 |
| puppet | 5.5.22 | 7.23.0 |
| python2 | 2.7.18 | (gone!) |
| python3 | 3.9.2 | 3.11.2 |
| qemu/kvm | 5.2 | 7.2 |
| ruby | 2.7+2 | 3.1 |
| rust | 1.48.0 | 1.63.0 |
| samba | 4.13.13 | 4.17.8 |
| systemd | 247.3 | 252.6 |
| unattended-upgrades | 2.8 | 2.9.1 |
| util-linux | 2.36.1 | 2.38.1 |
| vagrant | 2.2.14 | 2.3.4 |
| vim | 8.2.2434 | 9.0.1378 |
| zsh | 5.8 | 5.9 |
--fsync: fsync every written file--old-dirs: works like dirs when talking to old rsync--old-args: disable the modern arg-protection idiom--secluded-args, -s: use the protocol to safely send the args (replaces protect-args option)--trust-sender: trust the remote sender s file list
Now that Debian 12 has been released with proprietary firmwares on the official media, non-optional merged-/usr and systemd adopted by everybody, I want to take a moment to list, not without some pride, a few things that I was right about over the last 20 years:
Accepting the obvious solution about firmwares took 18 years. My work on the merged-/usr transition started in 2014, and the first discussions about replacing sysvinit are from 2011. The general adoption of udev (and dynamic device names, and persistent network interface names...) took less time in comparison and no large-scale flame wars, since people could enable it at their own pace. But it required countless little debates in the Debian Bug Tracking System: I still remember the people insisting that they would never use this newfangled dynamic /dev/, or complaining about their beloved /dev/cdrom symbolic link and persistent network interface names.
So follow me for more rants about inevitable technologies.
Contributing to Debian
is part of Freexian s mission. This article
covers the latest achievements of Freexian and their collaborators. All of this
is made possible by organizations subscribing to our
Long Term Support contracts and
consulting services.
Debian (I might as well say "we", this is the beauty of it) is about to release Debian 12 aka Bookworm. Let's take a quick look at what is new in Debian Qt land.
Qt 5
Bookworm has Qt 5.15.8, which is nothing but great news. KDE will be switching to Qt 6 sooner than later and Qt 5 has been a fun ride, but Dmitry Shachnev and I needed a break, or at very least not handling two Qt versions. But in the end I need to be fair: you REALLY need to thank Dmitry for Qt 5. He has been the man power behind it in 99.5% of the cases.
Qt 6
This will be the first Debian release to have official Qt 6 packages. NOTHING would have happened if it weren't for Patrick "Delta-One" Franz standing up to maintain it. BIG kudos to him!
Well, there is a "little lie" in the paragraph above. Thanks to The Qt Company and ICS the current Qt 6 version, 6.4.2, is also available as Bullseye's backports. The Qt Company really also helped us here by providing us almost-to-be-released tarballs of Qt 6.4.2 so we were able to push them to unstable and do a transition in time for freeze, thanks a lot for that!
So, what is the Qt 6 state?
At the binary side all but OpenGL ES support should be there. Sadly this was discovered too late in the release process and we still might need help maintaining it (read the link to know why!).
We are still not building the documentation. Properly building the whole documentation, as with Qt 5, would require all the Qt submodules' source code in one place, which we can't (easily?) do in Debian. So building the doc means hacking the build system and getting semi-linked documentation, much like with Qt 5. Now if you think you have an idea to solve this... we are happy to hear from you!
Another great thing to know about Qt 6 is that, thanks to Helmut Grohne, pure Qt 6 applications should be able to cross compile. Applications using multi-arch enabled libraries ought to work too. Even more, many Qt submodules themselves should also cross compile! Not all of them, as we missed some patches in time, but hey, if you need to cross compile Qt, you surely can apply them yourselves!
And finally tests, unit tests. In Qt 5 we had some of those, but none yet in Qt 6. This is one of the areas I would love to be able to put time... but time is scarce.
The future?
In my point of view the Debian 13 "Trixie" development cycle will see Qt 5 diminishing it's usage and Qt 6 becoming the major Qt version used, but from the Qt 4 experience I do not expect Qt 5 being dropped during this release cycle... let's see what the future brings us.
Thanks!
While I mentioned Dmitry and Patrick many more people helped us reach this place. I personally want to thank the people behind the KDE software, both upstream and, of course, the Debian maintainers. You should be thankful with them too, many hours of effort go into this.
And thanks to you our dear users. We are normally overflowed with what we have in our hands and might not be up to the task sometimes, but hey, you are part of the reason we are doing this!
Just a few days back we came to know about the horrific Train Crash that happened in Odisha (Orissa). There are some things that are known and somethings that can be inferred by observance. Sadly, it seems the incident is going to be covered up . Some of the facts that have not been contested in the public domain are that there were three lines. One loop line on which the Goods Train was standing and there was an up and a down line. So three lines were there. Apparently, the signalling system and the inter-locking system had issues as highlighted by an official about a month back. That letter, thankfully is in the public domain and I have downloaded it as well. It s a letter that goes to 4 pages. The RW is incensed that the letter got leaked and is in public domain. They are blaming everyone and espousing conspiracy theories rather than taking the minister to task. Incidentally, the Minister has three ministries that he currently holds. Ministry of Communication, Ministry of Electronics and Information Technology (MEIT), and Railways Ministry. Each Ministry in itself is important and has revenues of more than 6 lakh crore rupees. How he is able to do justice to all the three ministries is beyond me
The other thing is funds both for safety and relaying of tracks has been either not sanctioned or unutilized. In fact, CAG and the Railway Brass had shared how derailments have increased and unfulfilled vacancies but they were given no importance In fact, not talking about safety in the recently held Chintan Shivir (brainstorming session) tells you how much the Govt. is serious about safety. In fact, most of the programme was on high speed rail which is a white elephant. I have shared a whitepaper done by RW in the U.S. that tells how high-speed rail doesn t make economic sense. And that is an economy that is 20 times + the Indian Economy. Even the Chinese are stopping with HSR as it doesn t make economic sense.
Incidentally, Air Fares again went up 200% yesterday. Somebody shared in the region of 20k + for an Air ticket from their place to Bangalore
Coming back to the story itself. the Goods Train was on the loopline. Some say it was a little bit on the outer, some say otherwise, but it is established that it was on the loopline. This is standard behavior on and around Railway Stations around the world. Whether it was in the Inner or Outer doesn t make much of a difference with what happened next. The first train that collided with the goods train was the 12864 (SMVB-HWH) Yashwantpur Howrah Express and got derailed on to the next track where from the opposite direction 12841 (Shalimar- Bangalore) Coramandel Express was coming. Now they have said that around 300 people have died and that seems to be part of the cover-up. Both the trains are long trains, having between 23 odd coaches each. Even if you have reserved tickets you have 80 odd people in a coach and usually in most of these trains, it is at least double of that. Lot of money goes to TC and then above (Corruption). The Railway fares have gone up enormously but that s a question for perhaps another time . So at the very least, we could be looking at more than 1000 people having died. The numbers are being under-reported so that nobody has to take responsibility. The Railways itself has told that it is unable to identify 80% of the people who have died. This means that 80% were unreserved ticket holders or a majority of them. There have been disturbing images as how bodies have been flung over on tractors and whatnot to be either buried or cremated without a thought. We are in peak summer season so bodies will start to rot within 24-48 hours No arrangements made to cool the bodies and take some information and identifying marks or whatever. The whole thing being done in a very callous manner, not giving dignity to even those who have died for no fault of their own. The dissent note also tells that a cover-up is also in the picture. Apparently, India doesn t have nor does it feel to have a need for something like the NTSB that the U.S. used when it hauled both the plane manufacturer (Boeing) and the FAA when the 737 Max went down due to improper data collection and sharing of data with pilots. And with no accountability being fixed to Minister or any of the senior staff, a small junior staff person may be fired. Perhaps the same official that actually told them about the signal failures almost 3 months back
There were and are also some reports that some jugaadu /temporary fixes were applied to signalling and inter-locking just before this incident happened. I do not know nor confirm one way or the other if the above happened. I can however point out that if such a thing happened, then usually a traffic block is announced and all traffic on those lines are stopped. This has been the thing I know for decades. Traveling between Mumbai and Pune multiple times over the years am aware about traffic block. If some repair work was going on and it wasn t able to complete the work within the time-frame then that may well have contributed to the accident. There is also a bit muddying of the waters where it is being said that one of the trains was 4 hours late, which one is conflicting stories.
On top of the whole thing, they have put the case to be investigated by CBI and hinting at sabotage. They also tried to paint a religious structure as mosque, later turned out to be a temple. The RW says done by Muslims as it was Friday not taking into account as shared before that most Railway maintenance works are usually done between Friday Monday. This is a practice followed not just in India but world over.
There has been also move over a decade to remove wooden sleepers and have concrete sleepers. Unlike the wooden ones they do not expand and contract as much and their life is much more longer than the wooden ones. Funds had been marked (although lower than last few years) but not yet spent. As we know in case of any accident, it is when all the holes in cheese line up it happens. Fukushima is a great example of that, no sea wall even though Japan is no stranger to Tsunamis. External power at the same level as the plant. (10 meters above sea-level), no training for cascading failures scenarios which is what happened. The Days mini-series shares some but not all the faults that happened at Fukushima and the Govt. response to it. There is a difference though, the Japanese Prime Minister resigned on moral grounds. Here, nor the PM, nor the Minister would be resigning on moral grounds or otherwise :(. Zero accountability and that was partly a natural disaster, here it s man-made. In fact, both the Minister and the Prime Minister arrived with their entourages, did a PR blitzkrieg showing how concerned they are. Within 50 hours, the lines were cleared. The part-time Railway Minister shared that he knows the root cause and then few hours later has given the case to CBI. All are saying, wait for the inquiry report. To date, none of the accidents even in this Govt. has produced an investigation report. And even if it did, I am sure it will whitewash as it did in case of Adani as I had shared before in the previous blog post. Incidentally, it is reported that Adani paid off some of its debt, but when questioned as to where they got the money, complete silence on that part :(. As can be seen cover-up after cover-up
FWIW, the Coramandel Express is known as the Migrant train so has a huge number of passengers, the other one which was collided with is known as sick train as huge number of cancer patients use it to travel to Chennai and come back
The main takeaway is if you do not have their voice, you won t make policies for them. They won t go away but you will make life hell for them. One thing to keep in mind that most people assume that most people are disabled from birth. This may or may not be true. For e.g. in the above triple Railways accidents, there are bound to be disabled people or newly disabled people who were healthy before the accident. The most common accident is road accidents, some involving pedestrians and vehicles or both, the easiest is Ministry of Road Transport data that says 4,00,000 people sustained injuries in 2021 alone in road mishaps. And this is in a country where even accidents are highly under-reported, for more than one reason. The biggest reason especially in 2 and 4 wheeler is the increased premium they would have to pay if in an accident, so they usually compromise with the other and pay off the Traffic Inspector.
Sadly, I haven t read a new book, although there are a few books I m looking forward to have. People living in India and neighbors please be careful as more heat waves are expected. Till later.
Welcome to the May 2023 report from the Reproducible Builds project
In our reports, we outline the most important things that we have been up to over the past month. As always, if you are interested in contributing to the project, please visit our Contribute page on our website.
Holger Levsen gave a talk at the 2023 edition of the Debian Reunion Hamburg, a semi-informal meetup of Debian-related people in northern Germany. The slides are available online.
In April, Holger Levsen gave a talk at foss-north 2023 titled Reproducible Builds, the first ten years. Last month, however, Holger s talk was covered in a round-up of the conference on the Free Software Foundation Europe (FSFE) blog.
Pronnoy Goswami, Saksham Gupta, Zhiyuan Li, Na Meng and Daphne Yao from Virginia Tech published a paper investigating the Reproducibility of NPM Packages. The abstract includes:
When using open-source NPM packages, most developers download prebuilt packages on npmjs.com instead of building those packages from available source, and implicitly trust the downloaded packages. However, it is unknown whether the blindly trusted prebuilt NPM packages are reproducible (i.e., whether there is always a verifiable path from source code to any published NPM package). [ ] We downloaded versions/releases of 226 most popularly used NPM packages and then built each version with the available source on GitHub. Next, we applied a differencing tool to compare the versions we built against versions downloaded from NPM, and further inspected any reported difference.The paper reports that among the 3,390 versions of the 226 packages, only 2,087 versions are reproducible, and furthermore that multiple factors contribute to the non-reproducibility including flexible versioning information in package.json file and the divergent behaviors between distinct versions of tools used in the build process. The paper concludes with insights for future verifiable build procedures. Unfortunately, a PDF is not available publically yet, but a Digital Object Identifier (DOI) is available on the paper s IEEE page.
Elsewhere in academia, Betul Gokkaya, Leonardo Aniello and Basel Halak of the School of Electronics and Computer Science at the University of Southampton published a new paper containing a broad overview of attacks and comprehensive risk assessment for software supply chain security.
Their paper, titled Software supply chain: review of attacks, risk assessment strategies and security controls, analyses the most common software supply-chain attacks by providing the latest trend of analyzed attack, and identifies the security risks for open-source and third-party software supply chains. Furthermore, their study introduces unique security controls to mitigate analyzed cyber-attacks and risks by linking them with real-life security incidence and attacks . (arXiv.org, PDF)
NixOS is now tracking two new reports at reproducible.nixos.org. Aside from the collection of build-time dependencies of the minimal and Gnome installation ISOs, this page now also contains reports that are restricted to the artifacts that make it into the image. The minimal ISO is currently reproducible except for Python 3.10, which hopefully will be resolved with the coming update to Python version 3.11.
David A. Wheeler started a thread noting that the OSSGadget project s oss-reproducible tool was measuring something related to but not the same as reproducible builds. Initially they had adopted the term semantically reproducible build term for what it measured, which they defined as being if its build results can be either recreated exactly (a bit for bit reproducible build), or if the differences between the release package and a rebuilt package are not expected to produce functional differences in normal cases. This generated a significant number of replies, and several were concerned that people might confuse what they were measuring with reproducible builds . After discussion, the OSSGadget developers decided to switch to the term semantically equivalent for what they measured in order to reduce the risk of confusion.
Vagrant Cascadian (vagrantc) posted an update about GCC, binutils, and Debian s build-essential set with some progress, some hope, and I daresay, some fears .
Lastly, kpcyrd asked a question about building a reproducible Linux kernel package for Arch Linux (answered by Arnout Engelen). In the same, thread David A. Wheeler pointed out that the Linux Kernel documentation has a chapter about Reproducible kernel builds now as well.
In Debian this month, nine reviews of Debian packages were added, 20 were updated and 6 were removed this month, all adding to our knowledge about identified issues. In addition, Vagrant Cascadian added a link to the source code causing various 
ecbuild issues. [ ]
The F-Droid project updated its Inclusion How-To with a new section explaining why it considers reproducible builds to be best practice and hopes developers will support the team s efforts to make as many (new) apps reproducible as it reasonably can.
In diffoscope development this month, version 242 was uploaded to Debian unstable by Chris Lamb who also made the following changes:
binwalk is not available, ensure the user knows they may be missing more info. [ ]0.7.24 and 0.7.25 to Debian unstable which added support for Tox versions 3 and 4 with help from Vagrant Cascadian [ ][ ][ ]
mtools (forwarded upstream).lombok.lcov.lucene8.bnd.clc-intercal.proj.gcc-13.pygopherd.pytorch-audio.vcmi.proj.generateLocaleConfig in Android Gradle Plugin version 8.1.0 generates XML files using non-deterministic ordering, breaking reproducible builds. [ ]
The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In May, a number of changes were made by Holger Levsen:
arm64 nodes only put required modules in the initrd to save space in the /boot partition. [ ]--fetch, --help, --no-future and --verbose options [ ][ ][ ][ ] as well as adding a suite of new actions, such as apt-upgrade, command, deploy-git, rmstamp, etc. [ ][ ][ ][ ] in addition a significant amount of refactoring [ ][ ][ ][ ].apt has updates to install. [ ]bind9-dnsutils on some Ubuntu 18.04 nodes. [ ][ ]apt upgrades are available. [ ]nocheck, nopgo and nolto when building gcc-* and binutils packages [ ] as well as performed some node maintenance [ ][ ]. In addition, Roland Clobus updated the openQA configuration to specify longer timeouts and access to the developer mode [ ] and updated the URL used for reproducible Debian Live images [ ].
#reproducible-builds on irc.oftc.net.
rb-general@lists.reproducible-builds.org
A
equipe de tradu o do Debian para o portugu s do Brasil
realizar , no dia 13 de junho a partir das 20h, uma oficina de tradu o do
Manual do(a) Administrador(a) Debian (The Debian Administrator's Handbook).
O objetivo mostrar aos( s) iniciantes como colaborar na tradu o deste
importante material, que existe desde 2004 e vem sendo traduzido para o
portugu s ao longo dos anos. Agora a tradu o precisa ser atualizada para a
vers o 12 do Debian (bookworm), que ser
lan ada este m s.
A ferramenta usada para traduzir o Manual o site weblate, ent o voc j pode
criar sua conta e acessar o
Projeto Debian Handbook
para se ambientar.
A oficina acontecer no formato online, e o link para participar da sala no
jitsi ser divulgado no grupo
debl10nptBR no telegram e no canal
#debian-l10n-br do IRC.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | def parse_plain_text_body(text): lines = text.splitlines() for i, line in enumerate(lines): if line == 'Reply to this email directly or view it on GitHub:': return lines[i + 1].split('#')[0] if (line == 'For more details, see:' and lines[i + 1].startswith('https://code.launchpad.net/')): return lines[i + 1] try: (field, value) = line.split(':', 1) except ValueError: continue if field.lower() == 'merge request url': return value.strip() return None |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | pub fn parse_plain_text_body(text: &str) -> Option<String> let lines: Vec<&str> = text.lines().collect(); for (i, line) in lines.iter().enumerate() if line == &"Reply to this email directly or view it on GitHub:" return Some(lines[i + 1].split('#').next().unwrap().to_string()); if line == &"For more details, see:" && lines[i + 1].starts_with("https://code.launchpad.net/") return Some(lines[i + 1].to_string()); if let Some((field, value)) = line.split_once(':') if field.to_lowercase() == "merge request url" return Some(value.trim().to_string()); None |
1 2 3 4 5 6 7 8 9 10 11 12 13 | use pyo3::prelude::*; #[pyfunction] fn parse_plain_text_body(text: &str) -> Option<String> janitor_mail_filter::parse_plain_text_body(text) #[pymodule] pub fn _mail_filter(py: Python, m: &PyModule) -> PyResult<()> m.add_function(wrap_pyfunction!(parse_plain_text_body, m)?)?; Ok(()) |
1 2 3 4 5 6 7 8 9 10 11 12 | [package] name = "mailfilter-py" version = "0.0.0" authors = ["Jelmer Vernoo <jelmer@jelmer.uk>"] edition = "2018" [lib] crate-type = ["cdylib"] [dependencies] janitor-mail-filter = path = "../mailfilter" pyo3 = version = ">=0.14", features = ["extension-module"] |
1 2 3 4 5 6 7 8 9 | #!/usr/bin/python3 from setuptools import setup from setuptools_rust import RustExtension, Binding setup( rust_extensions=[RustExtension( "janitor._mailfilter", "crates/mailfilter-py/Cargo.toml", binding=Binding.PyO3)], ) |
1 | from ._mailfilter import parse_plain_text_body |
During the weekend of 19-23 May 2023 I attended the Wikimedia hackathon 2023 in Athens,
Greece. The event physically reunited folks interested in the more technological aspects of the Wikimedia movement in person for the
first time since 2019. The scope of the hacking projects include (but was not limited to)
tools, wikipedia bots, gadgets, server and network infrastructure, data and other technical systems.
My role in the event was two-fold: on one hand I was in the event because of my role as SRE in the Wikimedia Cloud Services team, where we provided
very valuable services to the community, and I was expected to support the technical contributors of the movement that were around. Additionally, and
because of that same role, I did some hacking myself too, which was specially augmented given I generally collaborate on a daily basis with some
community members that were present in the hacking room.
The hackathon had some conference-style track and I ran a session with my coworker Bryan, called
Past, Present and Future of Wikimedia Cloud Services (Toolforge and friends)
(slides) which was very satisfying to deliver given the friendly space
that it was. I attended a bunch of other sessions, and all of them were interesting and well presented. The number of ML themes that were present in
the program schedule was exciting. I definitely learned a lot from attending those sessions, from how LLMs work, some
fascinating applications for them in the wikimedia space, to what were some industry trends for training and hosting ML models.
Despite the sessions, the main purpose of the hackathon was, well, hacking. While I was in the hacking space for more than 12 hours each day, my
ability to get things done was greatly reduced by the constant conversations, help requests, and other social interactions with the folks. Don t get
me wrong, I embraced that reality with joy, because the social bonding aspect of it is perhaps the main reason why we gathered in person instead of
virtually.
That being said, this is a rough list of what I did:
It wasn t the first Wikimedia Hackathon for me, and I felt the same as in previous iterations: it was a welcoming space, and I was surrounded by
friends and nice human beings. I ended the event with a profound feeling of being privileged, because I was part of the Wikimedia movement, and
because I was invited to participate in it.
Next.