Samba

The Debian Janitor is an automated system that commits fixes for (minor) issues in Debian packages that can be fixed by software. It gradually started proposing merges in early December. The first set of changes sent out ran lintian-brush on sid ... [More] packages maintained in Git. This post is part of a series about the progress of the Janitor. Since the original post, merge proposals created by the janitor now include the debdiff between a build with and without the changes (showing the impact to the binary packages), in addition to the merge proposal diff (which shows the impact to the source package). New merge proposals also include a link to the diffoscope diff between a vanilla build and the build with changes. Unfortunately these can be a bit noisy for packages that are not reproducible yet, due to the difference in build environment between the two builds. This is part of the effort to keep the changes from the janitor high-quality. The rollout surfaced some bugs in lintian-brush; these have been either fixed or mitigated (e.g. by disabling specified fixers). For more information about the Janitor's lintian-fixes efforts, see the landing page. [Less]

I’ve recently bought a Garmin Fenix Multisport Smartwatch. The watch offers support for navigation and maps. By default it came with some topo maps for Europe. However I wanted to use more detailed maps from OpenStreetMap. Freizeitkarte for ... [More] Garmin Fenix loaded into QMapShack After some search I’ve discovered the wonderful Freizeitkarte project, which is a project to offer maps for Garmin devices. The default maps work OKish on the device. However as the smart watch doesn’t have a high end processor zooming and fast scrolling on the map is very slow. Also the display of the Fenix isn’t very saturated, so you need to work with different contrasts to display the map nicely. So I’ve downloaded the Freizeitkarte Map Development Environment (MDE) and tried to find out how the map is generated and how you could improve it. It is really simple to use and well documented! First I removed power lines from the map, you really don’t need them on a fitness tracker and they often confused me because the display was similar to roads and it looks like the is a junction of a road but there wasn’t a road. Then I reduced the Points of Interest (POI) to remove what we really don’t need. Things like car, beauty or fashion shops, power and communication towers, bowling and horse stuff and many more. The next step as to improve the look of the map. The MDE comes already with different files which define how a map looks, those are called TYP files. It has an outdoorc.TYP file which has a more contrasty look for a map but not enough for the Fenix. So I created a new TYP file especially for the Fenix and improved some icons I find important like restaurants, supermarkets, pharmacies and hospitals, parking lots and (bus) stops. Also there had been problems with the map on fenix. The draw order really matters and I needed to draw forests earlier as they didn’t show up on smartwatch, but worked fine when loaded in QMapShack. My current version of the Fenix style for Freizeitkarte can be found in a Merge Request (MR) for FZK MDE. If you want to play with an already rendered map, I’ve uploaded a map of Bavaria and the Alps here: fzk_fenix_bavaria_de.img.xz (262 MB)fzk_fenix_alps_de.img.xz (1.4 GB) Download the file, unzip it and copy the fenix_fzk_bayern_de.img to the GARMIN folder on the device using MTP. Make sure to use None as the Map theme to get the one from the map! In case you want a map for your region you can build it yourself using the MDE. Here are my build steps: # Build Freizeitkarte for Fenix 1. Bootstrap (needed only once) ./mt.pl bootstrap urls http://osm.thkukuk.de/data/bounds-latest.zip http://osm.thkukuk.de/data/sea-latest.zip ./mt.pl create 2. Fetch OSM and Elevation and join them ./mt.pl --downloadbar fetch_osm Freizeitkarte_BAYERN ./mt.pl --downloadbar fetch_ele Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 join Freizeitkarte_BAYERN 3. Split and build the map ./mt.pl --ram=22528 --cores=11 --language=de split Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 --typfile=fenix.TYP --style=fzk-fenix --language=de build Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 --typfile=fenix.TYP --style=fzk-fenix --language=de gmapsupp Freizeitkarte_BAYERN Note: For using 1 CPU core you need 2GB of RAM. I have 12 cores (24 threads) and 32GB of RAM in my machine. The above values I use are a good compromise between speed and a still usable system :-) Feedback is welcome as well as code/style contributions. [Less]

I’ve recently bought a Garmin Fenix Multisport Smartwatch. The watch offers support for navigation and maps. By default it came with some topo maps for Europe. However I wanted to use more detailed maps from OpenStreetMap. Freizeitkarte for ... [More] Garmin Fenix loaded into QMapShack After some search I’ve discovered the wonderful Freizeitkarte project, which is a project to offer maps for Garmin devices. The default maps work OKish on the device. However as the smart watch doesn’t have a high end processor zooming and fast scrolling on the map is very slow. Also the display of the Fenix isn’t very saturated, so you need to work with different contrasts to display the map nicely. So I’ve downloaded the Freizeitkarte Map Development Environment (MDE) and tried to find out how the map is generated and how you could improve it. It is really simple to use and well documented! First I removed power lines from the map, you really don’t need them on a fitness tracker and they often confused me because the display was similar to roads and it looks like the is a junction of a road but there wasn’t a road. Then I reduced the Points of Interest (POI) to remove what we really don’t need. Things like car, beauty or fashion shops, power and communication towers, bowling and horse stuff and many more. The next step as to improve the look of the map. The MDE comes already with different files which define how a map looks, those are called TYP files. It has an outdoorc.TYP file which has a more contrasty look for a map but not enough for the Fenix. So I created a new TYP file especially for the Fenix and improved some icons I find important like restaurants, supermarkets, pharmacies and hospitals, parking lots and (bus) stops. Also there had been problems with the map on fenix. The draw order really matters and I needed to draw forests earlier as they didn’t show up on smartwatch, but worked fine when loaded in QMapShack. My current version of the Fenix style for Freizeitkarte can be found in a Merge Request (MR) for FZK MDE. If you want to play with an already rendered map, I’ve uploaded a map of Bavaria and the Alps here: fzk_fenix_bavaria_de.img.xz (262 MB)fzk_fenix_alps_de.img.xz (1.4 GB) Download the file, unzip it and copy the fenix_fzk_bayern_de.img to the GARMIN folder on the device using MTP. Make sure to use None as the Map theme to get the one from the map! In case you want a map for your region you can build it yourself using the MDE. Here are my build steps: # Build Freizeitkarte for Fenix 1. Bootstrap (needed only once) ./mt.pl bootstrap urls http://osm.thkukuk.de/data/bounds-latest.zip http://osm.thkukuk.de/data/sea-latest.zip ./mt.pl create 2. Fetch OSM and Elevation and join them ./mt.pl --downloadbar fetch_osm Freizeitkarte_BAYERN ./mt.pl --downloadbar fetch_ele Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 join Freizeitkarte_BAYERN 3. Split and build the map ./mt.pl --ram=22528 --cores=11 --language=de split Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 --typfile=fenix.TYP --style=fzk-fenix --language=de build Freizeitkarte_BAYERN ./mt.pl --ram=22528 --cores=11 --typfile=fenix.TYP --style=fzk-fenix --language=de gmapsupp Freizeitkarte_BAYERN Note: For using 1 CPU core you need 2GB of RAM. I have 12 cores (24 threads) and 32GB of RAM in my machine. The above values I use are a good compromise between speed and a still usable system :-) Feedback is welcome as well as code/style contributions. [Less]

TL;DR: exchanges are casinos and don’t want to onboard anyone into bitcoin. Avoid. There’s a classic scam in the “crypto” space: advertize Bitcoin to get people in, then sell suckers something else entirely. Over the last few years, this ... [More] bait-and-switch has become the core competency of “bitcoin” exchanges. I recently visited the homepage of Australian exchange btcmarkets.net: what a mess. There was a list of dozens of identical-looking “cryptos”, with bitcoin second after something called “XRP”; seems like it was sorted by volume? Incentives have driven exchanges to become casinos, and they’re doing exactly what you’d expect unregulated casinos to do. This is no place you ever want to send anyone. Incentives For Exchanges Exchanges make money on trading, not on buying and holding. Despite the fact that bitcoin is the only real attempt to create an open source money, scams with no future are given false equivalence, because more assets means more trading. Worse than that, they are paid directly to list new scams (the crappier, the more money they can charge!) and have recently taken the logical step of introducing and promoting their own crapcoins directly. It’s like a gold dealer who also sells 57 varieties of pyrite, which give more margin than selling actual gold. For a long time, I thought exchanges were merely incompetent. Most can’t even give out fresh addresses for deposits, batch their outgoing transactions, pay competent fee rates, perform RBF or use segwit. But I misunderstood: they don’t want to sell bitcoin. They use bitcoin to get you in the door, but they want you to gamble. This matters: you’ll find subtle and not-so-subtle blockers to simply buying bitcoin on an exchange. If you send a friend off to buy their first bitcoin, they’re likely to come back with something else. That’s no accident. Looking Deeper, It Gets Worse. Regrettably, looking harder at specific exchanges makes the picture even bleaker. Consider Binance: this mainland China backed exchange pretending to be a Hong Kong exchange appeared out of nowhere with fake volume and demonstrated the gullibility of the entire industry by being treated as if it were a respected member. They lost at least 40,000 bitcoin in a known hack, and they also lost all the personal information people sent them to KYC. They aggressively market their own coin. But basically, they’re just MtGox without Mark Karpales’ PHP skills or moral scruples and much better marketing. Coinbase is more interesting: an MBA-run “bitcoin” company which really dislikes bitcoin. They got where they are by spending big on regulations compliance in the US so they could operate in (almost?) every US state. (They don’t do much to dispel the wide belief that this regulation protects their users, when in practice it seems only USD deposits have any guarantee). Their natural interest is in increasing regulation to maintain that moat, and their biggest problem is Bitcoin. They have much more affinity for the centralized coins (Ethereum) where they can have influence and control. The anarchic nature of a genuine open source community (not to mention the developers’ oft-stated aim to improve privacy over time) is not culturally compatible with a top-down company run by the Big Dog. It’s a running joke that their CEO can’t say the word “Bitcoin”, but their recent “what will happen to cryptocurrencies in the 2020s” article is breathtaking in its boldness: innovation is mainly happening on altcoins, and they’re going to overtake bitcoin any day now. Those scaling problems which the Bitcoin developers say they don’t know how to solve? This non-technical CEO knows better. So, don’t send anyone to an exchange, especially not a “market leading” one. Find some service that actually wants to sell them bitcoin, like CashApp or Swan Bitcoin. [Less]

There are a lot of small changes that can be made to the Debian archive to increase the overall quality. Many of these changes are small and have just minor benefits if they are applied to just a single package. Lintian encourages maintainers to ... [More] fix these problems by pointing out the common ones. Most of these issues are often trivially fixable; they are in general an inefficient use of human time, and it takes a lot of effort to keep up with. This is something that can clearly be automated. Several tools (e.g. onovy’s mass tool, and the lintian-brush tool that I’ve been working on) go a step further and (for a subset of the issues reported by lintian) fix the problems for you, where they can. Lintian-brush can currently fix most instances of close to 100 lintian tags. Thanks to the Vcs-* fields set by many packages and the APIs provided by hosting platforms like Salsa, it is now possible to proactively attempt to fix these issues. The Debian Janitor is a tool that will run lintian-brush across the entire archive, and propose fixes to lintian issues via pull request. Objectives The aim of Debian Janitor is to take some drudge work away from Debian maintainers where possible, so they can spend their time on more important packaging work. Its purpose is to make automated changes quick and easy to apply, with minimal overhead for package maintainers. It is essentially a bit of infrastructure to run lintian-brush across all of the archive. The actions of the bot are restricted to a limited set of problems for which obviously correct actions can be taken. It is not meant to automate all packaging, or even to cover automating all instances of the issues it knows about. The bot is designed to be conservative and delight with consistently correct fixes instead of proposing possibly incorrect fixes and hoping for the best. Considerable effort has been made to avoid the janitor creating pull requests with incorrect changes, as these take valuable time away from maintainers, the package doesn’t actually improve (since the merge request is rejected) and it makes it likelier that future pull requests from the Debian Janitor bot are ignored or rejected. In short: The janitor is meant to propose correct changes if it can, and back off otherwise. Design The Janitor finds package sources in version control systems from the Vcs*- control field in Debian source packages. If the packaging branch is hosted on a hosting platform that the Janitor has a presence on, it will attempt to run lintian-brush on the packaging branch and (if there are any changes made) build the package and propose a merge. It is based on silver-platter and currently has support for: Salsa GitHub Launchpad GitLab The Janitor is driven from the lintian and vcswatch tables in UDD. It queries for packages that are affected by any of the lintian tags that lintian-brush has a fixer script for. This way it can limit the number of repositories it has to process. Ensuring quality There are a couple of things I am doing to make sure that the Debian Janitor delights rather than annoys. High quality changes Lintian-brush has end-to-end tests for its fixers. In order to make sure that merge requests are useful and high-value, the bot will only propose changes from lintian-brush that: successfully build in a chroot and pass autopkgtest and piuparts; are not completely trivial - e.g. only stripping whitespace Changes for a package will also be reviewed by a human before they make it into a pull request. One open pull request per package If the bot created a pull request previously, it will attempt to update the current request by adding new commits (and updating the pull request description). It will remove and fix the branch when the pull request conflicts because of new upstream changes. In other words, it will only create a single pull request per package and will attempt to keep that pull request up to date. Gradual rollout I’m slowly adding interested maintainers to receiving pull requests, before opening it up to the entire archive. This should help catch any widespread issues early. Providing control The bot will be upfront about its pull requests and try to avoid overwhelming maintainers with pull requests by: Clearly identifying any merge requests it creates as being made by a bot. This should allow maintainers to prioritize contributions from humans. Limiting the number of open proposals per maintainer. It starts by opening a single merge request and won’t open additional merge requests until the first proposal has a response Providing a way to opt out of future merge requests; just a reply on the merge request is sufficient. Any comments on merge requests will also still be reviewed by a human. Current state Debian janitor is running, generating changes and already creating merge requests (albeit under close review). Some examples of merge requests it has created: i3 (on Salsa) nbd (on Salsa) friendly recovery (on Launchpad) dh-exec (on GitHub) Using the janitor The janitor can process any package that’s maintained in Git and has its Vcs-Git header set correctly (you can use vcswatch to check this). If you’re interested in receiving pull requests early, leave a comment below. Eventually, the janitor should get to all packages, though it may take a while with the current number of source packages in the archive. By default, salsa does not send notifications when a new merge request for one of the repositories you’re a maintainer for is created. Make sure you have notifications enabled in your Salsa profile, by ticking “New Merge Requests” for the packages you care about. You can also see the number of open merge requests for a package repository on QA - it’s the ! followed by a number in the pull request column. It is also possible to download the diff for a particular package (if it’s been generated) ahead of the janitor publishing it: $ curl https://janitor.debian.net/api/lintian-fixes/pkg/PACKAGE/diff E.g. for i3-wm, look at https://janitor.debian.net/api/lintian-fixes/pkg/i3-wm/diff. Future Plans The current set of supported hosting platforms covers the bulk of packages in Debian that is maintained in a VCS. The only other 100+ package platform that’s unsupported is dgit. If you have suggestions on how best to submit git changes to dgit repositories (BTS bugs with patches? or would that be too much overhead?), let me know. The next platform that is currently missing is bitbucket, but there are only about 15 packages in unstable hosted there. At the moment, lintian-brush can fix close to 100 lintian tags. It would be great to add fixers for more common issues. The janitor should probably be more tightly integrated with other pieces of Debian infrastructure, e.g. Jenkins for running jobs or linked to from the tracker or lintian.debian.org. More information See the FAQ on the homepage. If you have any concerns about these roll-out plans, have other ideas or questions, please let me know in the comments. [Less]

There are a lot of small changes that can be made to the Debian archive to increase the overall quality. Many of these changes are small and have just minor benefits if they are applied to just a single package. Lintian encourages maintainers to ... [More] fix these problems by pointing out the common ones. Most of these issues are often trivially fixable; they are in general an inefficient use of human time, and it takes a lot of effort to keep up with. This is something that can clearly be automated. Several tools (e.g. onovy's mass tool, and the lintian-brush tool that I've been working on) go a step further and (for a subset of the issues reported by lintian) fix the problems for you, where they can. Lintian-brush can currently fix most instances of close to 100 lintian tags. Thanks to the Vcs-* fields set by many packages and the APIs provided by hosting platforms like Salsa, it is now possible to proactively attempt to fix these issues. The Debian Janitor is a tool that will run lintian-brush across the entire archive, and propose fixes to lintian issues via pull request. Objectives The aim of Debian Janitor is to take some drudge work away from Debian maintainers where possible, so they can spend their time on more important packaging work. Its purpose is to make automated changes quick and easy to apply, with minimal overhead for package maintainers. It is essentially a bit of infrastructure to run lintian-brush across all of the archive. The actions of the bot are restricted to a limited set of problems for which obviously correct actions can be taken. It is not meant to automate all packaging, or even to cover automating all instances of the issues it knows about. The bot is designed to be conservative and delight with consistently correct fixes instead of proposing possibly incorrect fixes and hoping for the best. Considerable effort has been made to avoid the janitor creating pull requests with incorrect changes, as these take valuable time away from maintainers, the package doesn't actually improve (since the merge request is rejected) and it makes it likelier that future pull requests from the Debian Janitor bot are ignored or rejected. In short: The janitor is meant to propose correct changes if it can, and back off otherwise. Design The Janitor finds package sources in version control systems from the Vcs*- control field in Debian source packages. If the packaging branch is hosted on a hosting platform that the Janitor has a presence on, it will attempt to run lintian-brush on the packaging branch and (if there are any changes made) build the package and propose a merge. It is based on silver-platter and currently has support for: Salsa GitHub Launchpad GitLab The Janitor is driven from the lintian and vcswatch tables in UDD. It queries for packages that are affected by any of the lintian tags that lintian-brush has a fixer script for. This way it can limit the number of repositories it has to process. Ensuring quality There are a couple of things I am doing to make sure that the Debian Janitor delights rather than annoys. High quality changes Lintian-brush has end-to-end tests for its fixers. In order to make sure that merge requests are useful and high-value, the bot will only propose changes from lintian-brush that: successfully build in a chroot and pass autopkgtest and piuparts; are not completely trivial - e.g. only stripping whitespace Changes for a package will also be reviewed by a human before they make it into a pull request. One open pull request per package If the bot created a pull request previously, it will attempt to update the current request by adding new commits (and updating the pull request description). It will remove and fix the branch when the pull request conflicts because of new upstream changes. In other words, it will only create a single pull request per package and will attempt to keep that pull request up to date. Gradual rollout I'm slowly adding interested maintainers to receiving pull requests, before opening it up to the entire archive. This should help catch any widespread issues early. Providing control The bot will be upfront about its pull requests and try to avoid overwhelming maintainers with pull requests by: Clearly identifying any merge requests it creates as being made by a bot. This should allow maintainers to prioritize contributions from humans. Limiting the number of open proposals per maintainer. It starts by opening a single merge request and won't open additional merge requests until the first proposal has a response Providing a way to opt out of future merge requests; just a reply on the merge request is sufficient. Any comments on merge requests will also still be reviewed by a human. Current state Debian janitor is running, generating changes and already creating merge requests (albeit under close review). Some examples of merge requests it has created: i3 (on Salsa) nbd (on Salsa) friendly recovery (on Launchpad) dh-exec (on GitHub) Using the janitor The janitor can process any package that’s maintained in Git and has its Vcs-Git header set correctly (you can use vcswatch to check this). If you're interested in receiving pull requests early, leave a comment below. Eventually, the janitor should get to all packages, though it may take a while with the current number of source packages in the archive. By default, salsa does not send notifications when a new merge request for one of the repositories you're a maintainer for is created. Make sure you have notifications enabled in your Salsa profile, by ticking "New Merge Requests" for the packages you care about. You can also see the number of open merge requests for a package repository on QA - it's the ! followed by a number in the pull request column. It is also possible to download the diff for a particular package (if it's been generated) ahead of the janitor publishing it: $ curl https://janitor.debian.net/api/lintian-fixes/pkg/PACKAGE/diff E.g. for i3-wm, look at https://janitor.debian.net/api/lintian-fixes/pkg/i3-wm/diff. Future Plans The current set of supported hosting platforms covers the bulk of packages in Debian that is maintained in a VCS. The only other 100+ package platform that's unsupported is dgit. If you have suggestions on how best to submit git changes to dgit repositories (BTS bugs with patches? or would that be too much overhead?), let me know. The next platform that is currently missing is bitbucket, but there are only about 15 packages in unstable hosted there. At the moment, lintian-brush can fix close to 100 lintian tags. It would be great to add fixers for more common issues. The janitor should probably be more tightly integrated with other pieces of Debian infrastructure, e.g. Jenkins for running jobs or linked to from the tracker or lintian.debian.org. More information See the FAQ on the homepage. If you have any concerns about these roll-out plans, have other ideas or questions, please let me know in the comments. [Less]

There are a lot of small changes that can be made to the Debian archive to increase the overall quality. Many of these changes are small and have just minor benefits if they are applied to just a single package. Lintian encourages maintainers to ... [More] fix these problems by pointing out the common ones. Most of these issues are often trivially fixable; they are in general an inefficient use of human time, and it takes a lot of effort to keep up with. This is something that can clearly be automated. Several tools (e.g. onovy's mass tool, and the lintian-brush tool that I've been working on) go a step further and (for a subset of the issues reported by lintian) fix the problems for you, where they can. Lintian-brush can currently fix most instances of close to 100 lintian tags. Thanks to the Vcs-* fields set by many packages and the APIs provided by hosting platforms like Salsa, it is now possible to proactively attempt to fix these issues. The Debian Janitor is a tool that will run lintian-brush across the entire archive, and propose fixes to lintian issues via pull request. Objectives The aim of Debian Janitor is to take some drudge work away from Debian maintainers where possible, so they can spend their time on more important packaging work. Its purpose is to make automated changes quick and easy to apply, with minimal overhead for package maintainers. It is essentially a bit of infrastructure to run lintian-brush across all of the archive. The actions of the bot are restricted to a limited set of problems for which obviously correct actions can be taken. It is not meant to automate all packaging, or even to cover automating all instances of the issues it knows about. The bot is designed to be conservative and delight with consistently correct fixes instead of proposing possibly incorrect fixes and hoping for the best. Considerable effort has been made to avoid the janitor creating pull requests with incorrect changes, as these take valuable time away from maintainers, the package doesn't actually improve (since the merge request is rejected) and it makes it likelier that future pull requests from the Debian Janitor bot are ignored or rejected. In short: The janitor is meant to propose correct changes if it can, and back off otherwise. Design The Janitor finds package sources in version control systems from the Vcs*- control field in Debian source packages. If the packaging branch is hosted on a hosting platform that the Janitor has a presence on, it will attempt to run lintian-brush on the packaging branch and (if there are any changes made) build the package and propose a merge. It is based on silver-platter and currently has support for: Salsa GitHub Launchpad GitLab The Janitor is driven from the lintian and vcswatch tables in UDD. It queries for packages that are affected by any of the lintian tags that lintian-brush has a fixer script for. This way it can limit the number of repositories it has to process. Ensuring quality There are a couple of things I am doing to make sure that the Debian Janitor delights rather than annoys. High quality changes Lintian-brush has end-to-end tests for its fixers. In order to make sure that merge requests are useful and high-value, the bot will only propose changes from lintian-brush that: successfully build in a chroot and pass autopkgtest and piuparts; are not completely trivial - e.g. only stripping whitespace Changes for a package will also be reviewed by a human before they make it into a pull request. One open pull request per package If the bot created a pull request previously, it will attempt to update the current request by adding new commits (and updating the pull request description). It will remove and fix the branch when the pull request conflicts because of new upstream changes. In other words, it will only create a single pull request per package and will attempt to keep that pull request up to date. Gradual rollout I'm slowly adding interested maintainers to receiving pull requests, before opening it up to the entire archive. This should help catch any widespread issues early. Providing control The bot will be upfront about its pull requests and try to avoid overwhelming maintainers with pull requests by: Clearly identifying any merge requests it creates as being made by a bot. This should allow maintainers to prioritize contributions from humans. Limiting the number of open proposals per maintainer. It starts by opening a single merge request and won't open additional merge requests until the first proposal has a response Providing a way to opt out of future merge requests; just a reply on the merge request is sufficient. Any comments on merge requests will also still be reviewed by a human. Current state Debian janitor is running, generating changes and already creating merge requests (albeit under close review). Some examples of merge requests it has created: i3 (on Salsa) nbd (on Salsa) friendly recovery (on Launchpad) dh-exec (on GitHub) Using the janitor The janitor can process any package that’s maintained in Git and has its Vcs-Git header set correctly (you can use vcswatch to check this). If you're interested in receiving pull requests early, leave a comment below. Eventually, the janitor should get to all packages, though it may take a while with the current number of source packages in the archive. By default, salsa does not send notifications when a new merge request for one of the repositories you're a maintainer for is created. Make sure you have notifications enabled in your Salsa profile, by ticking "New Merge Requests" for the packages you care about. You can also see the number of open merge requests for a package repository on QA - it's the ! followed by a number in the pull request column. It is also possible to download the diff for a particular package (if it's been generated) ahead of the janitor publishing it: $ curl https://janitor.debian.net/api/lintian-fixes/pkg/PACKAGE/diff E.g. for i3-wm, look at https://janitor.debian.net/api/lintian-fixes/pkg/i3-wm/diff. Future Plans The current set of supported hosting platforms covers the bulk of packages in Debian that is maintained in a VCS. The only other 100+ package platform that's unsupported is dgit. If you have suggestions on how best to submit git changes to dgit repositories (BTS bugs with patches? or would that be too much overhead?), let me know. The next platform that is currently missing is bitbucket, but there are only about 15 packages in unstable hosted there. At the moment, lintian-brush can fix close to 100 lintian tags. It would be great to add fixers for more common issues. The janitor should probably be more tightly integrated with other pieces of Debian infrastructure, e.g. Jenkins for running jobs or linked to from the tracker or lintian.debian.org. More information See the FAQ on the homepage. If you have any concerns about these roll-out plans, have other ideas or questions, please let me know in the comments. [Less]

As I’m an amateur photographer, I’m using Open Source tools for developing my images. The software I use is called darktable. I think it is the best tool out there for editing RAW images. From time to time I contributed small code changes to ... [More] darktable, mostly bug fixes. Now I nearly finished my first feature for darktable, support for the AVIF image format. From RAW exported and reimported AVIF images in darktable. For implementing AVIF support I used libavif. Joe Drago the author of libavif was very helpful explaining all the details and helping me in debugging issues. Thank you Joe! The code need to be polished a bit more and I need to decide what to expose in the export UI or better simplify for the user. However there are some outstanding things that this will be a great experience for everyone: Multi threaded encoding of AVIF images using rav1e in libavif Still image support in rav1e Lossless support in rav1e AVIF image support in exiv2 AVIF image support in Firefox (FYI: Firefox already uses dav1d playing for AV1 videos) [Less]

As I’m an amateur photographer, I’m using Open Source tools for developing my images. The software I use is called darktable. I think it is the best tool out there for editing RAW images. From time to time I contributed small code changes to ... [More] darktable, mostly bug fixes. Now I nearly finished my first feature for darktable, support for the AVIF image format. From RAW exported and reimported AVIF images in darktable. For implementing AVIF support I used libavif. Joe Drago the author of libavif was very helpful explaining all the details and helping me in debugging issues. Thank you Joe! The code need to be polished a bit more and I need to decide what to expose in the export UI or better simplify for the user. However there are some outstanding things that this will be a great experience for everyone: Multi threaded encoding of AVIF images using rav1e in libavif Still image support in rav1e Lossless support in rav1e AVIF image support in exiv2 AVIF image support in Firefox [Less]

As I’m an amateur photographer, I’m using Open Source tools for developing my images. The software I use is called darktable. I think it is the best tool out there for editing RAW images. From time to time I contributed small code changes to ... [More] darktable, mostly bug fixes. Now I nearly finished my first feature for darktable, support for the AVIF image format. From RAW exported and reimported AVIF images in darktable. For implementing AVIF support I used libavif. Joe Drago the author of libavif was very helpful explaining all the details and helping me in debugging issues. Thank you Joe! The code need to be polished a bit more and I need to decide what to expose in the export UI or better simplify for the user. However there are some outstanding things that this will be a great experience for everyone: Multi threaded encoding of AVIF images using rav1e in libavif Still image support in rav1e Lossless support in rav1e AVIF image support in exiv2 AVIF image support in Firefox (FYI: Firefox already uses dav1d playing for AV1 videos) [Less]