Posts
2041
Following
230
Followers
2519
Director of Linux Foundation IT. Currently in charge of kernel.org infra.

This account is for Linux/Kernel/FOSS topics in general: #linux, #kernel, #foss, #git, #sysadmin, #infrastructure.

For my personal account, please follow @monsieuricon@castoranxieux.ca.

MontrΓ©al, QuΓ©bec, Canada πŸ‡¨πŸ‡¦πŸ‡ΊπŸ‡¦
@palmer @lina No, the ">#" bit is something I just came up with today. :)
0
0
0
@palmer @lina Yes, git has always stripped lines starting with # -- which is why it's the behaviour in b4 as well.
1
0
0
@lina Ok, I added this into current dev and will probably backport to 0.12.2.

https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=041d10b7f628fa082babdfa14def50b25b28f701
1
0
0
@lina I am considering using ">#" that is converted to just "#" when put into the cover letter body, but that's a partial fix. You'd still hit this same problem if you didn't know to use "># header" syntax. However maybe if I add this into the default cover letter template, it will be more obvious.
1
0
0
@lina my goal is to avoid unexpected behaviour, so I'll try to think of a way that would both allow someone to add comments that won't go into the final cover letter (such as commenting out a Cc trailer) and do markup.
1
0
1
@lina It's not "accidentally" if they literally asked to be cc'd on that regex. :)
0
0
3
@lina I'm happy to receive any b4 feedback you have. The "#" treatment bit is really because the cover letter is a git commit and if you edit it directly with git, it will remove any lines starting with "#". I'm worried that if we treat these any differently, we'll potentially run into unexpected behaviour. :/
1
0
4

K. Ryabitsev 🍁

When you see someone using an old version of your tool that you know has a bad bug that they somehow keep avoiding.
0
1
11

K. Ryabitsev 🍁

"The code stack is extremely brittle for no good reason" literally describes 98% of the world's entire IT infrastructure.
2
2
7

K. Ryabitsev 🍁

Edited 2 years ago
Me, entering room: Mornin'.
My wife: Wait a minute, that accent. Have you been playing RDR2 again?
Me: I ain't got no idea whatcha mean.
My wife: you're not even from this part of the world!
0
0
5
@jwildeboer it's a bit drastic with header rewriting, but otherwise it should work for non-technical lists. You can keep your lists DMARC compliant *and* preserve original headers, which has a bonus of preserving sender domain authentication.
0
0
1
@llvm @LWN Sorry, I read "Gnudi hackers" as "nudie hackers" and couldn't get past that point because my whole brain seized up.
1
0
2

K. Ryabitsev 🍁

This was a productive Friday, even if I didn't get to all outstanding b4 patches. B4 0.13-dev gained a `b4 prep --cleanup` feature that will be handy for people sending many series and it allows archiving and cleaning up git objects used for series tracking.
0
0
5

K. Ryabitsev 🍁

We had our heat pump replaced and a new central thermostat put in. We were supposed to get a wifi enabled one, but looks like they installed a cheaper version that isn't wifi-capable.

I ain't even mad.
0
0
3

K. Ryabitsev 🍁

Pretty sure I'm on LWN entirely due to my skillful use of dadjoke titles.
2
0
11
@jwildeboer well, list-label is "dot-atom-text" as well, so it can contain periods. In the context of "nyt.1.0.sparkpostmail.com" the namespace would be "sparkpostmail.com", so the list-label is "nyt.1.0".

Goes to show that you can write all the standards you like, but you can't make people use them sanely. :)
0
0
1
@jwildeboer I'm not saying their naming convention isn't stupid, just that using "@" isn't actually allowed per RFC.
0
0
3
@jwildeboer not trying to out-greybeard you or anything, but RFC2919 mandates the format of that header, and it can't use a "@". :)
0
0
1
@ljs @monsieuricon Ah, yes, this is indeed the problem I'm complaining about in that post. :)
1
0
1
@ljs @monsieuricon I don't think gmail has this problem, does it? I thought it was just mutt.
2
0
0
Show older