Re: Change the expectation that emails should wrap at 80 characters
On Thu, 06 Mar 2025 14:53:07 +0100, Giuseppe Sacco wrote: I think that even for emails, the line length should be kept at a reasonable value in order to maximize the readability. Such value is usually lower than 80, as shown, for example, in https://baymard.com/blog/line-length-readability . I do have a large screen, but I keep my email/text editors quite narrow in order to allow less than 100 characters per line. Of course YMMV. Thank you for this link. I've been thinking about describing my personal experiences for some days but this web page explains it much better than I could have written it myself: Following long lines and than backtracking to the next line is tedious for me; and if I have to turn my head right and left I'm much more prone to just delete a mail than to follow through and complete reading the whole text. -- There's a reason why texts in newspapers are typically in columns and not across the whole page. I acknowledge that there are people in Debian whose neck and eyes are better than mine, and who have less knowledge about email customs, and who use broken MUAs, and who want me to adjust my terminal size but I'd like to note anyway that I'm not supporting any change in the recommendations for Debian mailing lists, and I'll keep ignoring unreadable emails in the future. And I'd also like to thank people who pushed me into exploring format=flowed in MUAs and editors further. I enjoy(ed) experimenting with these things :) Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Improvement of headless server upgrades
On 2025-03-06 17:56, Helmut K. C. Tessarek wrote: It was a Debian Buster on armv7l that I had forgotten, because it was running perfectly until now, but apps complained that the OS is no longer supported. To clarify my previous statement: The upgrade to bullseye changed the ifname. Buster used eth0. After the rebooot, bulsseye used a different ifname. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On 06.03.25 23:01, Chris Hofstaedtler wrote: This doesn't give a huge list of packages using diversions, but very high profile packages are in there. Keep in mind that many of those are there to support usrmerge; these probably should be filtered out. On the other hand, on my system lots of diversions are tagged "glx-diversions"; the packages that installed these don't show up in https://binarycontrol.debian.net/?q=dpkg-divert&path=unstable. Apparently "dpkg-maintscript-helper symlink_to_dir" does (did?) some interesting behind-the-scenes magic there. Bottom line: It's not *that* easy. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Change the expectation that emails should wrap at 80 characters
Quoting gregor herrmann (2025-03-07 00:14:19) > On Thu, 06 Mar 2025 14:53:07 +0100, Giuseppe Sacco wrote: > > >I think that even for emails, the line length should be kept at a reasonable > >value in order to maximize the readability. Such value is usually lower than > >80, as shown, for example, in > >https://baymard.com/blog/line-length-readability . I do have a large screen, > >but I keep my email/text editors quite narrow in order to allow less than > >100 characters per line. Of course YMMV. > > Thank you for this link. For completeness sake, I recommend to take newer research into account, which a) questions if longer lines generally harms reading due to flaws in especially one major research project from 2029, and b) points at printed and digital texts affecting readability differently: https://designregression.com/article/line-length-revisited-following-the-research Despite long lines possibly not really *generally* hampering readability, some of us *are* helped by following the typographic conventions of 50-70 chars per line, be it due to e.g. dyslexia or simply years of training our reading skills with print style texts. Yes, some of us are younger, which quite likely means that reading skills have been trained to a larger degree on online media than on printed books, i.e. less commonly following typographic conventions and therefore potentially more fluent in processing long lines. Søren proposes to simply not wrap when composing. That helps reading on narrow width devices, but harms reading on conventional MUAs expecting less than 80 chars per line, and harms reading on wide width devices for some of us. Sure we can then tell folks to change MUA and to resize their windows, but that is not nice to impose of human beings, being creatures of habit. I favor the proposal of continuing to follow the convention of wrapping below 80 chars per line, and ecourage the use of f=f. That helps those stock in the 90s, either mentally or through their choice of arcane MUA, but harms those with large width MUAs and skilled reading long lines, and those reading emails on narrow width devices. But only the (allegedly large) subset of those users who use MUAs not supporting f=f. > Following long lines and than backtracking to the next line is > tedious for me; and if I have to turn my head right and left I'm much > more prone to just delete a mail than to follow through and complete > reading the whole text. -- There's a reason why texts in newspapers > are typically in columns and not across the whole page. > I acknowledge that there are people in Debian whose neck and eyes > are better than mine, and who have less knowledge about email > customs, and who use broken MUAs, and who want me to adjust my > terminal size but I'd like to note anyway that I'm not supporting any > change in the recommendations for Debian mailing lists, and I'll keep > ignoring unreadable emails in the future. Yes, arguably the issue of non-wrapped text causing too long lines is a luxury problem that can be addressed by simply changing window size. But that is asking creatures of habit to change habits, which is a lot. Interestingly, I see this as a combined social and technical issue, and since we are hackers, I favor that we try explore the option of hacking our tools, before giving up and instead impose pressure on the habits of our peers (because obviously *my* habits are a priority, it must be the habits of others that need to change, right?). Let us please continue to respect the ancient rules of email style, and try explore format=flowed, which might be old too but evidently not widely known prior to this thread! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
On 7/3/25 12:29 AM, Otto Kekäläinen wrote: Hi! Around 12 years ago, I proposed a peer-review system to increase the quality of the packages in the NEW queue. https://wiki.debian.org/CopyrightReview For packages that I sponsor, I already do reviews of the debian/copyright and all other files. These are recorded as Merge Requests in Salsa. Perhaps the easiest way to achieve the workflow you envision would be to have a field in the upload metadata that links to the Merge Request on Salsa, so FTP masters can see who reviewed the contents and if their feedback was properly addressed in addition to reviewing the uploaded artifacts from scratch? May be this can go to changelog? As adding new filed may need tools and people to adjust and can take a long time.
STFU please (Re: Bits from DPL)
On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote: > Marc. I'll take my Popcorn with salt please. yeah, it's pretty funny to see a team burn out and have the same silly & salty discussion about this again and again. or maybe not. also talking about how NEW is a bottleneck will be really motivating to the person how has been doing most of NEW processing in the last months. or maybe not. I'm not sure about you, but just last week I got a package through NEW in a few hours. my rust upload folder also told me we (mostly sequoia, but also rebuilderd) go 86 packages through NEW in the last 15 months, which means more than one package per week. and that's just our little corner here. I do have some complaints about the ftp team, as I have about many things, *but* I also have tremendous respect for their work. and I know, you might have forgotten but it was discussed on d-d-a iirc, that several improvements are being worked on right, and that's not only tag2upload. so if the/a team says they cannot handle new members right now and thus there should be no big announcement asking for new members, I very much think this should be respected and not be ignored and spread on our most visible mailing list, where there pain will be consumed with popcorn. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ war is peace. freedom is slavery. ignorance is strength. infection is health. signature.asc Description: PGP signature
Re: Improvement of headless server upgrades
On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote: > Both network "outages" could have been prevented by adding a note at the end > of the dist-upgrade output. they could also have been prevented by reading the release notes and following their advice. that would also have prevented this wonderful bikeshedding thread. sorry to state the obvious. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It blows my mind that the people who rage about the spike proteins don't rage about governments encouraging the spread of self-replicating auto-mutating aerosolised spike proteins. (@1goodtern) signature.asc Description: PGP signature
Re: Change the expectation that emails should wrap at 80 characters
On Wed, Mar 05, 2025 at 09:32:05PM -0800, James Lu wrote: If I were to write, say, a Thunderbird extension that forcibly unwraps text I receive, regardless of whether format=flowed was specified, what would be the implication? This (as a mild but easy to get example of pre-formatted text): For sake of argument:- If this re-wrapping is purely client side and happens after PGP verification, incoming mail could still show as verified (but it may look slightly different)- I could toggle this on/off per message, so that I can still write inline replies based on the original message's formatting -- WBR, wRAR signature.asc Description: PGP signature
Re: STFU please (Re: Bits from DPL)
On 06.03.25 09:53, Marc Haber wrote: I apologize for trying to bring a smile into a heated discussion Thank you. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bits from DPL
On 06.03.25 08:58, Marc Haber wrote: I thank the DPL for putting this to public attention. Well OK but mayybe he should have handled this a bit more diplomatically. Or maybe he tried to, and failed to get traction. I assume he'll tell us presently, if only to reduce the popcorn-to-serious-discussion ratio. Greetings Marc. I'll take my Popcorn with salt please. Please don't. We'll get enough of this sort of remark from LWN soon enough; treating peoples' honest concerns (not to mention their actual work for the project) as entertainment on-list is disingenious. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: TC decision on ownership of top-level filesystem aliases - #1091995
Hello ctte, On Tue 04 Mar 2025 at 11:46am GMT, Matthew Vernon wrote: > In Bug #1091995, the Technical Committe was asked to rule on an issue > that could, under certain circumstances, result in failure of the > base-files package to install or upgrade correctly. Under these > circumstances, systemd will create a symlink from /lib64 to /usr/lib, > which does not match the symlink contained within base-files. base-files > will detect this case in preinst and generate an error, but if it did > not do this then dpkg would instead fail with a less verbose message. > > Policy does not currently define ownership of the usrmerge filesystem > aliases, but since trixie base-files has effectively been responsible > for ensuring that these aliases are configured appropriately. This is > therefore a technical disagreement rather than a policy violation. Just to note that the most recent release of Policy sort-of defines ownership of this, though it is not as explicit as the TC decision: Packages must not install files to paths whose first component is a name directly under the file system root and which is a symbolic link to a directory of the same name under "/usr". ... The base-files package is an exception, for it installs aliasing symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et cetera. -- Sean Whitton signature.asc Description: PGP signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hello, On Thu 06 Mar 2025 at 01:21pm +09, Charles Plessy wrote: > Hi Sean and everybody, > > Around 12 years ago, I proposed a peer-review system to increase the quality > of > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview > > Maybe we could revisit the idea along these lines: If someone wants to set this up in a way that doesn't increase ftp team workload but means packages have to be reject'd less often -- by all means. -- Sean Whitton signature.asc Description: PGP signature
Processing times for the NEW queue (was Re: Bits from DPL)
Hi, * Matthias Urlichs [2025-03-05 23:00]: The NEW queue currently contains ~135 packages. The median wait time on the list(*) is three weeks, and the oldest packages have been, well, languishing, for nine months or so. (*) Yes I know that this may well be an inflated median: after all, the packages which ftpmaster *did* process lately are not on the list by definition. However, that's still 50 people who've been waiting for at least a month to get their package into Debian. I'm not an FTP Team member, but I happen to have analyzed exactly this question in detail [1]. The FTP team is very transparent in this regard and provides all processing logs, so any DD can verify this for themselves. In summary, the median wait time in NEW is currently less than 48 hours, and in the last 10 years it was seldomly longer than a week. 90 percent of all packages going through NEW are processed within a few weeks. Only 2 percent of all packages going through NEW are held up for several months or longer. A typical months sees about 400 packages going through NEW, and up to twice that many in the month or two directly after a release, when maintainers rush to catch up with upstream releases or introduce new stuff for the next release cycle. That means that in an average month, more than 200 packages pass through NEW within two days, and only about 20 packages get stuck for more than three or four weeks. So why do people feel NEW processing is generally slow? I have a few ideas: 1. People looking at the current state of the NEW queue easily fall prey to survivorship bias; they see mostly the problematic cases and almost none of the simple ones. 2. Source packages going through NEW merely because they introduce new binary packages are typically processed faster than completely new ones. Maintainers for C/C++ libraries, which need to go through NEW on a semi regular basis, tend to have a much smoother overall experience than, say, Python maintainers, who only interact with NEW when they introduce new packages. 3. Source packages have varying degrees of complexity for debian/copyright, which is not necessarily the maintainers fault (some upstreams seem to treat code with various licenses as some sort of Pokemon-style collection challenge), but the maintainer has to deal with it in a way that the FTP team can sign off on it. And that may take some time (on both ends). 4. There is a certain variability in processing times which naturally comes from the fact that everything we do is volunteer work, which is totally out of the maintainer's control. I've seen packages pass through NEW within hours, one time even in less than 60 minutes(!), and I've waited on a similar one for weeks. The difficulty to know how long the trip through NEW will take has a significant psychological impact. Close to my home, there is a railway crossing on a relatively busy track. If the barriers come down, it can mean a wait time from a minute (a single train) up to 20(!) minutes (with several and/or long trains in close sucession). This does not happen very often, but you have no way of knowing in advance. Thus, people take significant detours to avoid that level crossing, as they'd rather add five minutes for certain to their trip than roll the dice for an unlucky quarter hour. Cheers Timo [1] https://people.debian.org/~roehling/new_queue/ -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Growing new FTP-masters (Re: Bits from DPL)
Hello, On Thu 06 Mar 2025 at 08:41am +01, Matthias Urlichs wrote: > Apparently the problem isn't that no help is needed but that nobody has time > to train the new help, citing possible burn-out trying to get answers from the > existing members and leaving in disappointment, if not disgust. (My > interpretation …) > > While that's a valid concern, it's a problem every manager of an overworked > team in the world has faced, volunteer or not. > > There are (of course) multiple ways to approach this issue. The point (and I > assume the reason Andreas basically ignored the team's rejection of new > members) is that "do nothing until somebody has time to train new people" is > among the worst possible approaches: experience tells us that the most likely > outcome is "another team members quits". You can't just throw people at a team of volunteers who are busy doing other things and say "train them". Nobody wins, there, and the candidates won't come back at a time when those volunteers *do* have the time to do the training. -- Sean Whitton signature.asc Description: PGP signature
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hi, Le 2025-03-06 10:41, Sean Whitton a écrit : If someone wants to set this up in a way that doesn't increase ftp team workload but means packages have to be reject'd less often -- by all means. Do you have some stats or even just an estimate telling how often this happens, or is there an archive or a log somewhere that could be used to estimate the rejection frequency and most common causes? Cheers, -- Julien Plissonneau Duquène
Re: STFU please (Re: Bits from DPL)
On 3/6/25 2:09 PM, Holger Levsen wrote: so if the/a team says they cannot handle new members right now and thus there should be no big announcement asking for new members, I very much think this should be respected and not be ignored and spread on our most visible mailing list, where there pain will be consumed with popcorn. This has been an long term recurring complaint without any tangible solution or a plan from the concerned team, so I think it is important for the whole project to address it, and not just leave it to the ftp team to resolve it (they ave not been able to address it by themselves for a long time).
Re: Improvement of headless server upgrades
Il 06/03/2025 09:43, Holger Levsen ha scritto: On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote: Both network "outages" could have been prevented by adding a note at the end of the dist-upgrade output. they could also have been prevented by reading the release notes and following their advice. that would also have prevented this wonderful bikeshedding thread. sorry to state the obvious. I think the things to do can be summed up as follows: read release note of new major version and NEWS entries If you are upgrading important or critical systems try also: - test before in a testing system, or vm. or even just start from a less critical one - try to have additional access in case of unforeseen events (there are not only the network ones mentioned in this discussion that can prevent the boot but also other undocumented and/or specific ones to the system or to a part of it). I mean for example an access from the host in case of vm or an ipmi system in case of physical server. - if you don't have much time to read the whole release note read at least the "Upgrade specific items" part, for example for buster there is "5.1.6. Migrating from legacy network interface names". - if you don't have time to read NEWS every update do it at least for the first time so you can see all the common ones on the basic packages, for example however it can be useful to have a quick look at each update and read those of specific programs to be aware of important or essential changes and save time rather than having problems later, perhaps not noticing the problems immediately or not being able to find the cause immediately Regarding possible improvements I think the only thing that can be added is a check to the upgrade operations and if it is detected that you are upgrading to packages of the next major version add a simple initial warning (but not a big "image" as suggested in topic start) in which it is recommended to read the release notes, especially the "Upgrade specific items" part, and the NEWS of the packages. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1099652: ITP: bacon -- background code checker
Package: wnpp
Severity: wishlist
Owner: Blair Noctis
X-Debbugs-Cc: debian-devel@lists.debian.org, n...@debian.org
* Package name: bacon
Version : 3.11.0
Upstream Contact: dystroy
* URL : https://dystroy.org/bacon/
* License : AGPL-3.0
Programming Lang: Rust
Description : background code checker
bacon is a code checker designed to run in the background, alongside your editor, with
minimal interaction, notifying you of warnings, errors or test failures. It was
originally developed for Rust/cargo, but recently gained support ("analyzers")
for other languages/runtimes, like Python/pytest, Python/ruff, JavaScript/eslint, etc.
--
Sdrager,
Blair Noctis
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On 06/03/25 14:25, Lorenzo wrote:
Hello Otto,
[please keep me in CC, I'm not subscribed]
Salsa CI has had for many years the job 'missing-breaks' that
complements piuparts by checking that the files a package introduce
don't clash with files shipped by any other package in the
distribution without having proper Breaks/Replaces in the
`debian/control` file. This job works well, being quick to run and has
had zero false positives in our experience.
In salsa CI now I see:
$ check_for_missing_breaks_replaces.py -o ${WORKING_DIR}/missing_breaks.xml
--changes-file ${WORKING_DIR}/*.changes
[ERROR] Missing Breaks/Replaces found
[ERROR] runit-init conflicts with init-system-helpers files:
{'/usr/share/man/man8/invoke-rc.d.8.gz', '/usr/sbin/service',
'/usr/sbin/invoke-rc.d', '/usr/share/man/man8/service.8.gz'}
Uploading artifacts for failed job
this looks like false positive, file are in fact diverted. Does the test
check for for diversions?
## Schedule
1. March 1st: Enable this job by default, but in allow_failure mode,
making Salsa CI yellow on packages that fail on this job
2. March 31st: Remove the allow_failure mode, potentially making the
Salsa CI red for packages that fail on this job
Could you please consider delaying 2. until diversion are properly
detected?
Another instance of diversions not being detected is in linux's pipeline
[1,2]: linux-libc-dev and oss4-dev both install
/usr/include/linux/soundcard.h, oss4-dev diverts it, missing-break
fails. If my understanding is correct, this will make all unstable/exp
(oss4-dev is in unstable only) src:linux pipelines break starting March
31st.
I agree that diversions should be detected.
[1] https://salsa.debian.org/kernel-team/linux/-/jobs/7205419
[2] https://salsa.debian.org/kernel-team/linux/-/jobs/7182906
> Best Regards,
> Lorenzo
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Charles Plessy writes: > Hi Sean and everybody, > > Around 12 years ago, I proposed a peer-review system to increase the quality > of > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview > > Maybe we could revisit the idea along these lines: I like this idea, as an opt-in service to prepare for ftp-master review. I've been doing at least 25 NEW uploads for the past months, and debian/copyright is certainly the biggest manual time consumer for me. I've learned some tricks to get it right, but I also rely on ftp-masters to catch me when I miss something. There are corner-cases where I would like to have a discussion about some minor aspect, and I've been trying (although not always succeeding) to not pester ftp-masters with these minor questions. Having an opt-in service of people who want to perform ftp-master-like debian/copyright review of a package would be helpful for me. I don't find posting to debian-legal serving this function, where the advice received is often neither helpful or actionable. Using debian-legal for this discussion would be fine, maybe that makes it more contributory. It would also be good to write down some of the finer rules on some aspects of debian/copyright, such as how to deal with public domain contributions, vendored stuff where there is a known copyright holder but not mentioned in any file, how to deal with non-free DCO-like statements, etc. /Simon > > - a Salsa group into which people fork repos and run CI screens for > copyright, >license and missing source issues. > > - a peer-review system based on issues or MRs (for instance to a master >repository with a text file tracing the outcome of the reviews). > > - as of today people would use it to ensure their submissions to NEW are to >the highest standards and therefore the least likely to waste time of the >FTP team members. > > - the outcome of the NEW processing of the peer review is also recorded by >volunteers, allowing to better measure the achievements and usefulness of >the system. > > - The FTP team, if they wish, can provide feedback. > > - when the FTP team calls for new trainees, applicants who have a track > record >of peer reviews in that system can show it to the FTP team, who are free to >do what they want with this information. > > - If the FTP team recruits someobody who was peer reviewer and liked that >system, a positive loop is made. > > Have a nice day, > > Charles > signature.asc Description: PGP signature
Re: Improvement of headless server upgrades
On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek" wrote: Both network "outages" could have been prevented by adding a note at the end of the dist-upgrade output. e.g. something like the following (monospace font required for the "Attention" text): _ _ _ _ _ _ _ ___ ___ _ _ / \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | / _ \ | | | | | _| | \| | | | | | | | | \| | / ___ \| | | | | |___| |\ | | | | | |_| | |\ | /_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| Network interface name changed: please update config files before reboot. Why would people who do not read the NEWS.Debian or the Release Notes read that? And how would you solve the issue of people wanting more and more of those attention banners? While I agree that an *experienced* sysadmin would have caught that mistake purely by previous experience with Debian, imagine for a second an end user or fresh sysadmin. Do me a favour and go to https://www.debian.org/, and tell me how many clicks you needed to find the release notes. Now imagine you didn't know of their existence. Would you still have stumbled upon them? Do you still believe that level of sass in your response is warranted? From my experience with giving support on the Debian IRC support channel most new users are not aware the release notes exist. Greetings Marc Greets, Lee P.S.: This failure mode isn't even documented in the release notes.
Re: Improvement of headless server upgrades
On 2025-03-06 08:43 +, Holger Levsen wrote: > On Tue, Mar 04, 2025 at 08:39:43PM -0500, Helmut K. C. Tessarek wrote: > > Both network "outages" could have been prevented by adding a note at the end > > of the dist-upgrade output. > > they could also have been prevented by reading the release notes and following > their advice. Would it? Do we know why these things happened? K.C. does not say what he was upgrading from/to (so it wasn't a very useful report in that regard), but there has certainly been a long-term expectation that headless upgrades will work (and in my experience of 25 years now they always do (well done everyone - I am regularly impressed at how this usually doesn't break). Which entry in which release notes will warn that this time (presumably - was this an upgrade to unstable K.C. or to bookworm, or something else?) the (pretty old now) eth0 -> 'annoying, unmemorable, but ordered and unique', renaming will/might actually break your config? Or that dhcpd will be replaced by network manager in such a way that things break? (Is the mechanism here that the server was running dhcpd to dish out addresses so now in fact the server is working but other machines are not getting addresses? I do read the release notes before the first upgrade to a new release, but I wouldn't be expecting either of the mentioned things to break so I'm not (yet) convinced that 'RTFM' is a fair response here. I do vaguely recall that one version of DHCP (isc-dhcp?) was being retired (did that happen for bookworm?). But normally debian upgrades do not replace your existing packages, precisely because they might be doing something important. I've just looked over the release notes for upgrading to bookworm and whilst here is loads of good advice about checking for obsolete packages, noting removals, making backups etc, it is largely generic and relies on the user knowing what removed packages do. I didn't see anything specific which warned about the 2 issues noted, and the guide is pretty long these days, so some skimming the 3rd time you upgrade is inevitable. So yeah, would RTFM really have avoided these problems? Maybe, maybe not. In general I would echo Helmut's response: it is better to work out why this happenned and try to prevent it, than to add more notices, as we do have some notice mechanisms already. But they are old, and expectations change so it's not crazy to ask if they are still sufficient. But equally, starting with 'it's your fault' seems unhelpful and possibly unfair. I look forward to some answers in response to Helmut, and we'll find out if there are real issues to address or not. Wookey -- Principal hats: Debian, Wookware http://wookware.org/ signature.asc Description: PGP signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
Hello Otto,
[please keep me in CC, I'm not subscribed]
> Salsa CI has had for many years the job 'missing-breaks' that
> complements piuparts by checking that the files a package introduce
> don't clash with files shipped by any other package in the
> distribution without having proper Breaks/Replaces in the
> `debian/control` file. This job works well, being quick to run and has
> had zero false positives in our experience.
In salsa CI now I see:
$ check_for_missing_breaks_replaces.py -o ${WORKING_DIR}/missing_breaks.xml
--changes-file ${WORKING_DIR}/*.changes
[ERROR] Missing Breaks/Replaces found
[ERROR] runit-init conflicts with init-system-helpers files:
{'/usr/share/man/man8/invoke-rc.d.8.gz', '/usr/sbin/service',
'/usr/sbin/invoke-rc.d', '/usr/share/man/man8/service.8.gz'}
Uploading artifacts for failed job
this looks like false positive, file are in fact diverted. Does the test
check for for diversions?
> ## Schedule
>
> 1. March 1st: Enable this job by default, but in allow_failure mode,
> making Salsa CI yellow on packages that fail on this job
> 2. March 31st: Remove the allow_failure mode, potentially making the
> Salsa CI red for packages that fail on this job
Could you please consider delaying 2. until diversion are properly
detected?
Best Regards,
Lorenzo
Re: Growing new FTP-masters (Re: Bits from DPL)
On 06.03.25 10:51, Sean Whitton wrote: You can't just throw people at a team of volunteers who are busy doing other things and say "train them". That's true in general. However. * this episode demonstrates that there are obviously a few crossed wires between ftpmaster and DPL; I think it's fair to assume that this is not a recent development. Andreas' ignoring your NACK may not have been particularly nice (he can apologize himself :-P ) but at least it threw the problem into the spotlight. * there seem to be some reasonable(IMHO) ideas out there to reduce and/or spread the workload of NEW processing. These obviously need some fleshed-out proposal, discussion, and people who then implement the result. This requires volunteers , but not necessarily any up-front training. * I have learned (thanks @roehling) that the *actual* median time packages spend in NEW is less than two days. In other words, *somebody* must have *some* time available. * Speaking from personal experience: Fighting an ongoing uphill battle is much less rewarding than bulldozing some of that hill away. The effect on actual time available for the task in question should be obvious. My personal suggestion would be to work with one or two volunteers to write a somewhat-comprehensive how-to-ftpmaster-the-NEW-queue manual, so that the *next* time you have a bottleneck you can throw that document at the volunteer and say "here's ten example packages, find their problems if any, then come back". Finally, a question -- as you don't seem to document the issues you have with long term packages in their ITP bug, where *do* you document them? -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Change the expectation that emails should wrap at 80 characters
On 2025-03-06 at 00:32, James Lu wrote: > Hi all, > > On 2025-02-26 10:21, Soren Stoutner wrote: >> However, from a technical perspective, having the *sending* program >> decide where line breaks should be in an email doesn’t seem like >> the correct approach to me because, 1) the sending program does not >> know the screen width of the receiving program, and 2) there is >> large variability in the screen width of receiving devices, >> including cell phones who are often less than 80 characters wide. > > There's plenty of discussion about format=flowed elsewhere in this > thread, but unfortunately it never caught on. This got me thinking > though: why do email clients *have* to show hard-wrapped text as-is? > If I were to write, say, a Thunderbird extension that forcibly > unwraps text I receive, regardless of whether format=flowed was > specified, what would be the implication? At my workplace, I am obliged to use Outlook. By default, Outlook seems to do exactly that, on the recipient and viewing side: it leaves the actual representation on-disk etc. alone, but if it sees consecutive non-blank lines (I'm guessing the criterion is actually "has something other than whitespace at the start of the line"), it will fold those lines together into a single line (with the division point represented by, as far as I can see, a single space) at rendering time. There seems to be nothing you can do, as the sender, to affect this behavior for the recipient - not short of using *double* newlines, turning each "line" into its own paragraph. There seem to be some special rules relating to punctuation (if the previous line ends with a period, the next one won't be folded into the same line; if the new line begins with a '>', the two lines won't be folded together; I've also seen cases where the new line begins with a single word followed by a period and a close-paren get the new line not folded in to the previous), but I don't have a full handle on those, and the 100-foot view of the behavior remains the same. This sometimes makes no difference, and sometimes drives me *batty*, especially given how much effort I put in to manually adding those hard-line-breaks in all the mails I have to compose in Outlook (since it won't add them itself). There *is* a setting which can disable this behavior; I don't remember what it is, except that it might be (or be a subset of) the "read E-mail as plain text" setting which they designate as being a security option. That setting is per-client, however. ...which has the effect that the same person can see the same mail rendered differently when reading it on different devices. I personally find that to be a negative, but others may well find it to be a positive. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Change the expectation that emails should wrap at 80 characters
Hello James, Il giorno mer, 05/03/2025 alle 21.32 -0800, James Lu ha scritto: > Hi all, > On 2025-02-26 10:21, Soren Stoutner wrote: > > > > I started thinking about this a few weeks ago when I received an email > > from a Debian Developer complaining that replies from my email client > > (KMail) looked odd because they truncated quoted lines in a way that did > > not lay out pleasingly. This was because I had set KMail to wrap lines > > at 80 characters. > > > > I see this too with a lot of ML posts - mails are wrapped in a way such > that the text only takes up a third of my monitor. This is one of those > things where the more I notice it, the more it annoys me :/ [...] I think that even for emails, the line length should be kept at a reasonable value in order to maximize the readability. Such value is usually lower than 80, as shown, for example, in https://baymard.com/blog/line-length-readability . I do have a large screen, but I keep my email/text editors quite narrow in order to allow less than 100 characters per line. Of course YMMV. Bye, Giuseppe
Re: Bits from DPL
On Thu, Mar 06, 2025 at 09:01:13AM +0800, Sean Whitton wrote: On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote: Do you mind clarifying why that's the case, unless the reason is truly personal or undisclosable? It's pretty simple -- there is no-one with the free time to train them right now, in which case trainees will simply burn out, because they won't get enough feedback on their NEW reviews. This sounds like a self-amplifying situation. The project should do something against that, especially in such a core position. I thank the DPL for putting this to public attention. Greetings Marc. I'll take my Popcorn with salt please. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: STFU please (Re: Bits from DPL)
On Thu, Mar 06, 2025 at 08:39:13AM +, Holger Levsen wrote: On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote: Marc. I'll take my Popcorn with salt please. yeah, it's pretty funny to see a team burn out and have the same silly & salty discussion about this again and again. I apologize for trying to bring a smile into a heated discussion and will now return to shutting up to non-technical issues. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
* Otto Kekäläinen [250306 19:57]:
> Salsa CI has had for many years the job 'missing-breaks' that
> complements piuparts by checking that the files a package introduce
> don't clash with files shipped by any other package in the
> distribution without having proper Breaks/Replaces in the
> `debian/control` file. This job works well, being quick to run and has
> had zero false positives in our experience.
https://binarycontrol.debian.net/?q=dpkg-divert&path=unstable%2F
This doesn't give a huge list of packages using diversions, but very
high profile packages are in there. I wonder what your testing
strategy was :-)
In salsa CI now I see:
$ check_for_missing_breaks_replaces.py -o ${WORKING_DIR}/missing_breaks.xml
--changes-file ${WORKING_DIR}/*.changes
[ERROR] Missing Breaks/Replaces found
[ERROR] runit-init conflicts with init-system-helpers files:
{'/usr/share/man/man8/invoke-rc.d.8.gz', '/usr/sbin/service',
'/usr/sbin/invoke-rc.d', '/usr/share/man/man8/service.8.gz'}
Uploading artifacts for failed job
this looks like false positive, file are in fact diverted. Does the test
check for for diversions?
No, it does not. This is now tracked at
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/418
The challenge is that most of the debian/ contents is declarative,
such as the file lists in debian-*.install files, while the diversions
are procedural code inside maintainer scripts and challenging to
automatically analyze.
Yup. dumat has a lot of code to deal with diversions. But overall it
seems totally doable/reusable.
live-tools also seems to divert files from initramfs-tools, which is
how I found out about this mail thread.
Best,
Chris
Re: Improvement of headless server upgrades
On 2025-03-06 09:13, Wookey wrote: Would it? Do we know why these things happened? K.C. does not say what he was upgrading from/to (so it wasn't a very useful report in that regard), but there has certainly been a long-term expectation that headless upgrades will work (and in my experience of 25 years now they always do (well done everyone - I am regularly impressed at how this usually doesn't break). It was a Debian Buster on armv7l that I had forgotten, because it was running perfectly until now, but apps complained that the OS is no longer supported. That upgrade changed the ifname. (The other issue happened either from bullseye to bookworm or after.) I have done upgrades from buster to bullseye before (on amd64) and I never lost network connectivity even though the network interface name changed. Maybe because those machines already used a different network setup. I don't really know. (It's been a while.) This was the reason I was so startled that I couldn't connect anymore. Yes, I had done updates where the ifname changed, but sorry that I forgot that fact, since it was rather a long time ago (epecially since I still had network access in my previous upgradres where that happened). But I can only agree and I am equally impressed as Wookey how well dist-upgrades work. I maybe should have mentioned that I have done countless updates before and never ran into any issues. Or at least I knew beforehand that I had to make changes that something like that might not happen. Please note that I was not trying to blame Debian or package managers or anyone really. This was clearly my fault. I started this thread to begin a discussion whether there is an option to prevent something like that. An option that doesn't require me to read through 3000 lines of text. If not, it's fine. If yes, it might be awesome to do so. That's all. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
On 2025-03-05 07:38, Helmut Grohne wrote: I am surprised to see this happen. Back in older times, interfaces used to be named like eth0, but that should not be happening since quite a number of stable releases. Those old systems that still use eth0 today tend to do it due to a file /etc/udev/rules.d/70-persistent-net.rules. Does that exist and list your interface on the affected system? If not, can you try figuring out why it was still named eth0 before upgrading? It was buster to bullseye. A machine I had forgotten since it was running perfectly. It was my fault that I didn't read the 3000 lines of NEWS for the upgrade, but I have done buster upgrades before and I didn't lose network connectivity then. I forgot that the ifname would change. Can you try figuring out what dependency caused Network Manager to be installed? Your apt or dpkg logs may be helpful here. I am looking into it. Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
Hi!
> > Salsa CI has had for many years the job 'missing-breaks' that
> > complements piuparts by checking that the files a package introduce
> > don't clash with files shipped by any other package in the
> > distribution without having proper Breaks/Replaces in the
> > `debian/control` file. This job works well, being quick to run and has
> > had zero false positives in our experience.
>
> In salsa CI now I see:
>
> $ check_for_missing_breaks_replaces.py -o ${WORKING_DIR}/missing_breaks.xml
> --changes-file ${WORKING_DIR}/*.changes
> [ERROR] Missing Breaks/Replaces found
> [ERROR] runit-init conflicts with init-system-helpers files:
> {'/usr/share/man/man8/invoke-rc.d.8.gz', '/usr/sbin/service',
> '/usr/sbin/invoke-rc.d', '/usr/share/man/man8/service.8.gz'}
> Uploading artifacts for failed job
>
> this looks like false positive, file are in fact diverted. Does the test
> check for for diversions?
No, it does not. This is now tracked at
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/418
The challenge is that most of the debian/ contents is declarative,
such as the file lists in debian-*.install files, while the diversions
are procedural code inside maintainer scripts and challenging to
automatically analyze.
If I get more people interested in collaborating on getting the script
first included in devscripts
(https://salsa.debian.org/debian/devscripts/-/merge_requests/478), we
could later take a stab at adding somekind of diversion detection.
> > ## Schedule
> >
> > 1. March 1st: Enable this job by default, but in allow_failure mode,
> > making Salsa CI yellow on packages that fail on this job
> > 2. March 31st: Remove the allow_failure mode, potentially making the
> > Salsa CI red for packages that fail on this job
>
> Could you please consider delaying 2. until diversion are properly
> detected?
If this CI job is too incorrect for your package, you can also opt out
but having this in your salsa-ci.yml file:
variables:
SALSA_CI_DISABLE_MISSING_BREAKS: 1
The point with having this job enabled for a month in allow_failure
mode is precisely to collect this feedback. If there is enough
packages that use diversions or have other issues, we might indeed
postpone this change, or roll it back completely. Thanks for sharing
your feedback!
Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)
Hi! > Around 12 years ago, I proposed a peer-review system to increase the quality > of > the packages in the NEW queue. https://wiki.debian.org/CopyrightReview For packages that I sponsor, I already do reviews of the debian/copyright and all other files. These are recorded as Merge Requests in Salsa. Perhaps the easiest way to achieve the workflow you envision would be to have a field in the upload metadata that links to the Merge Request on Salsa, so FTP masters can see who reviewed the contents and if their feedback was properly addressed in addition to reviewing the uploaded artifacts from scratch?
Re: Growing new FTP-masters (Re: Bits from DPL)
Hi, > > Apparently the problem isn't that no help is needed but that nobody has time > > to train the new help, citing possible burn-out trying to get answers from > > the > > existing members and leaving in disappointment, if not disgust. (My > > interpretation …) > > > > While that's a valid concern, it's a problem every manager of an overworked > > team in the world has faced, volunteer or not. > > > > There are (of course) multiple ways to approach this issue. The point (and I > > assume the reason Andreas basically ignored the team's rejection of new > > members) is that "do nothing until somebody has time to train new people" is > > among the worst possible approaches: experience tells us that the most > > likely > > outcome is "another team members quits". > > You can't just throw people at a team of volunteers who are busy doing > other things and say "train them". Nobody wins, there, and the > candidates won't come back at a time when those volunteers *do* have the > time to do the training. I don't think you are quoting the DPL above correctly. I think he had good judgement, and raising awareness of FTP Masters team being spread thin and needing more help in a Bits from DPL announcement is the correct thing to do. New people standing up and stating they want to help is a good thing, even with the risk that some of those people would go away while waiting. I did also read the queue processing time reports by Matthias and Timo. On a quick look I wasn't able to find stats on which FTP Master team member has done how many reviews, but in my experience it seems to rely on the heroic efforts of a very few people (thanks Thorsten for all your work!), and having more people in the team would be of great benefit for Debian, and rightly something the DPL should help with.
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On Thu, Mar 06, 2025 at 03:52:54PM +0100, NoisyCoil wrote: > Another instance of diversions not being detected is in linux's pipeline > [1,2]: linux-libc-dev and oss4-dev both install > /usr/include/linux/soundcard.h, oss4-dev diverts it, missing-break fails. If > my understanding is correct, this will make all unstable/exp (oss4-dev is in > unstable only) src:linux pipelines break starting March 31st. Open an serious bug report against oss4-dev. No need to wait, it needs to go. Bastian -- Beam me up, Scotty! It ate my phaser!
Re: Improvement of headless server upgrades
On 3/6/25 4:00 PM, Lee Garrett wrote: On Tue, 4 Mar 2025 20:39:43 -0500, "Helmut K. C. Tessarek" wrote: Both network "outages" could have been prevented by adding a note at the end of the dist-upgrade output. e.g. something like the following (monospace font required for the "Attention" text): _ _ _ _ _ _ _ ___ ___ _ _ / \|_ _|_ _| | \ | |_ _|_ _/ _ \| \ | | / _ \ | | | | | _| | \| | | | | | | | | \| | / ___ \| | | | | |___| |\ | | | | | |_| | |\ | /_/ \_\_| |_| |_|_| \_| |_| |___\___/|_| \_| Network interface name changed: please update config files before reboot. Why would people who do not read the NEWS.Debian or the Release Notes read that? And how would you solve the issue of people wanting more and more of those attention banners? While I agree that an *experienced* sysadmin would have caught that mistake purely by previous experience with Debian, imagine for a second an end user or fresh sysadmin. Do me a favour and go to https://www.debian.org/, and tell me how many clicks you needed to find the release notes. Now imagine you didn't know of their existence. Would you still have stumbled upon them? Do you still believe that level of sass in your response is warranted? From my experience with giving support on the Debian IRC support channel most new users are not aware the release notes exist. It's four clicks, in 90 seconds. I'm using Debian for more than 20 years, but finding them still took considerable effort on my part. All clicks were educated guesses. I generally get my news from apt's NEWS displays, but even though I can't be sure that my installation will be accessible after a release upgrade (I'm very sure that it'll boot, at least though). I'm following the thread since its beginning and thinking a solution which might be useful, but I came up with basically nothing. This is one of the hard problems where computers and humans collide. Funnily, what I found useful is using Testing as a desktop system and gain the knowledge of what will gonna happen in the next release upgrade. This creates an innate knowledge of what to do on your servers which run stable since you went through all of the changes (and then some) during the testing phase. Greetings Marc Greets, Lee P.S.: This failure mode isn't even documented in the release notes. Regards, H. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Improvement of headless server upgrades
Wookey writes: > Which entry in which release notes will warn that this time > (presumably - was this an upgrade to unstable K.C. or to bookworm, or > something else?) the (pretty old now) eth0 -> 'annoying, unmemorable, > but ordered and unique', renaming will/might actually break your > config? There probably hasn't been a warning since buster, when the release notes [1] warned: 4.1.6. Verify network interface name support Systems upgraded from older releases that still use network interfaces with names like eth0 or wlan0 are at risk of losing networking once they switch to buster; see Section 5.1.6, “Migrating from legacy network interface names” for migration instructions. Maybe all release notes after this should have warned about using systemd unpredictable interface names on headless systems? Particularily on systems with a single network interface, where such breakage is completely unnecessary and "eth0" is guaranteed to be stable from kernel to kernel. We should probably also advise users of headless systems with multiple interfaces that they need to manually configure names for their interfaces. Personally I prefer more descriptive names like "uplink", "backend" etc. Avoids the systemd breakage and makes network config easier to read/debug. Bjørn [1] - https://www.debian.org/releases/buster/amd64/release-notes.en.txt
Re: Improvement of headless server upgrades
On Thu, Mar 06, 2025 at 02:13:49PM +, Wookey wrote: Which entry in which release notes will warn that this time (presumably - was this an upgrade to unstable K.C. or to bookworm, or something else?) the (pretty old now) eth0 -> 'annoying, unmemorable, but ordered and unique', renaming will/might actually break your config? 4.1.6 in https://www.debian.org/releases/buster/amd64/release-notes.en.txt (I cannot link to a HTML version because it doesn't look like it exists anymore, or I cannot Google it, which is the same thing in our case). -- WBR, wRAR signature.asc Description: PGP signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On 06/03/25 17:09, Bastian Blank wrote: Open an serious bug report against oss4-dev. No need to wait, it needs to go. oss4-dev is fine (unless diversions of files in linux-libc-dev are forbidden): oss4-dev is correctly diverting the header, as a consequence it needs not Break or Conflict with linux-libc-dev. The issue here is that the new missing-breaks pipeline job has no clue that packages are correctly diverting files, and it flags as missing Breaks packages which, in fact, do not miss Breaks because they aren't supposed to have any.
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On 06.03.25 17:51, Bastian Blank wrote: Because diverts are kind of sledgehammers. Without coordination they break stuff. OK, so in *this* case the diversion is in error (in your opinion anyway; not having looked at the contents of these headers, I have no opinion here). However, I'm reasonably certain that there are other cases where diversions are intentional and perfectly valid. Unless 'missing-breaks' learns to handle them it will report CI failures for *all* of them, at which point we might as well change Policy to state that diversions are a legacy feature that cannot be used in new uploads. I kindof doubt that we'd get a majority to sign off on that. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Salsa CI job 'missing-breaks' to be enabled by default starting March 1st
On 06.03.25 19:42, Bastian Blank wrote: On Thu, Mar 06, 2025 at 06:21:10PM +0100, Matthias Urlichs wrote: However, I'm reasonably certain that there are other cases where diversions are intentional and perfectly valid. Do you have an example? Does perldoc diverting the stub perldoc so that it can install the real one count? (That's the only one on my desktop that's not glx-diversions or usrmerge.) I kindof doubt that we'd get a majority to sign off on that. You don't need to use it, so don't? All of that is opt-in. Fair enough. -- -- regards -- -- Matthias Urlichs OpenPGP_signature.asc Description: OpenPGP digital signature
