Posts
308
Following
90
Followers
3332
gregkh

Greg K-H

Reply to
@brauner @monsieuricon @dakkar Ah, makes sense.

Anyway, rewrote it in perl as that way I have a chance to maintain it over time: https://paste.sr.ht/~gregkh/d8cd98966d8e5ef61161c0341b250d018b16e8bd
3
0
1
gregkh

Greg K-H

Reply to @monsieuricon
@monsieuricon @brauner @dakkar Ah, so the python email library messed up again? Heck, if we are allowed to write full scripts here (and not just bash one-liners), let me try something on my own, worst case I write it in C...
1
0
3
gregkh

Greg K-H

Reply to

@brauner @monsieuricon @dakkar better, thanks!

But (you knew there was a but)…

message ids no longer have <> characters: `Message-Id: 2023040228-pastor-evidence-1269@gregkh Is that intentional and still a valid message id? As @monsieuricon said, email parsing is rough.

1
0
0
gregkh

Greg K-H

Reply to

@brauner @monsieuricon @dakkar Thanks!

In the never-ending series of things that really don’t matter but are fun, something is still not working. I just tried sending a patch out with this and the gmail server did not like it at all, and rewrote the message id with:

  Message-ID: <64293fdb.5d0a0220.58d3f.02e0SMTPIN_ADDED_BROKEN@mx.google.com>
X-Google-Original-Message-ID: <2023040245-stardust-obtain-0b4d@gregkh> usage.

Ah, in typing that out I see why, the original email header was:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
 usage.

So the perl script changed that to:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
Message-Id: <2023040245-stardust-obtain-0b4d@gregkh>
 usage.

And then vger promptly ate the message and never delivered it to the mailing list. I’ll hand-edit the subject line to be one line for now to get stuff done, but be aware of this if you use it as-is.

2
0
0
gregkh

Greg K-H

Reply to
@dakkar @monsieuricon @brauner yup, that worked, many thanks!
1
0
1
gregkh

Greg K-H

Reply to
@dakkar @monsieuricon @brauner Debugging a embedded perl script in a bash script for git run to use to send email for a Linux kernel patch over a social media message is yak shaving at it's finest.

Unfortunately, no, this change did not work, let me go dig up my old perl book from the upstairs library...
1
0
3
gregkh

Greg K-H

Reply to
@brauner @monsieuricon Much better. But not quite there, the script now strips out the "@" character and trailing text from the message id for some reason.

"2023040117-gem-unharmed-3194@gregkh" gets turned into "Message-Id: <2023040117-gem-unharmed-3194>"

But nice work with the inline perl, I have to use it for that reason alone!
1
0
0
gregkh

Greg K-H

Reply to @gregkh
@brauner @monsieuricon Ok, I lied, I couldn't resist doing it "by hand" to see if it would work, and it did: https://lore.kernel.org/lkml/2023040126-blandness-duckling-bd55@gregkh/
1
0
0
gregkh

Greg K-H

Reply to
@brauner @monsieuricon Ok, you are forcing me to switch to use b4 for my development workflow now, fair enough :)

In the meantime, let me just send this bugfix patch out and stop messing around with pretty message-ids as the bugfix is probably more important in the short-term...
1
0
0
gregkh

Greg K-H

Reply to @gregkh
@brauner @monsieuricon ah, maybe you are using --thread on 'git format-patch'? That might get messy as the message ids are now not correct (you rewrote them), and --thread doesn't work on single patches
2
0
0
gregkh

Greg K-H

Reply to @gregkh
@brauner @monsieuricon Your git-hook doesn't seem to work for me as 'git format-patch' does not generate the message-id, git send-email does (when it is sending the message). Are you generating a message-id before you run 'git send-email' somehow?
2
0
0
gregkh

Greg K-H

Reply to
@brauner @monsieuricon I was wondering about that...

Got the message id to work in mutt, will add it to git send-email tomorrow.
1
0
1
gregkh

Greg K-H

Reply to
@brauner @monsieuricon Nice! I'm stealing that right now...
0
0
2
gregkh

Greg K-H

Reply to
@brauner @monsieuricon I should at least try b4 out for new development. As @horms points out here:
https://lore.kernel.org/r/ZCU4BQ0C4K6HoBsf@corigine.com
I need all the luck I can get with my current "journey of a few hundred patches" that I'm on, and my current git branch / commit / rebase / rebase / rebase / rewrite / rebase / format-patch / send-email workflow leaves a lot to be desired at times.
1
1
1
gregkh

Greg K-H

Reply to @monsieuricon
@monsieuricon @brauner Cool! Now if only we could replace the hard-coded logic in `git send-email` with this...
2
0
0
gregkh

Greg K-H

Reply to
@bagder This is one reason why the Linux kernel security team does not interact with the linux-distros list anymore, their policies just are not conclusive to keeping systems secure for users.
0
0
1
gregkh

Greg K-H

Reply to
@agraf @kernellogger 1/2 year to rebase to a new version? You are doing something really really really wrong there.

The Android kernel team has been keeping the android kernel tree up to date with Linus's -rc releases within a few days at most, usually within a few hours (note, it is not up to date with 6.3-rc1 right now for "gpio reasons"). Keep your tree constantly up to date, that way it just does not matter when a new LTS comes out, AND you catch any rebase/conflict issues way way early when you can get upstream's help with it.

So if it takes you 6+ months to rebase, you really have the wrong development and maintenance model and need to fix it now And yes, Google prodkernel team, I'm looking at you...

If anyone wants me to come and yell at internal managers about all of this, please let me know, that's one of the funnest parts of my job.
0
11
23
gregkh

Greg K-H

Reply to
@kernellogger No one ever asked, that sounds like a good idea.

Maybe we can do that in the future as we wean people off of the 6 year model which has obviously failed to work well, thanks!
2
3
16
gregkh

Greg K-H

Reply to
@larsmb It also doesn't seem to handle well the "delete this sensor and rediscover it as new as I messed up the configuration for it so badly I want to start over" without having to dig around and hand-editing yaml files. Or maybe I'm just doing it wrong...
1
0
0
gregkh

Greg K-H

Reply to
@fenruspdx @Aissen @kernellogger We already do this today, but no one seems to notice: https://github.com/cloudsecurityalliance/gsd-database
0
0
2
Show older
About social.kernel.org

Terms of service

  1. Please do not use this service in violation of the Linux Kernel Code of Conduct. Doing so will result in your account suspension with the referral of the matter to the CoC committee.

  2. "Repeating"/"boosting" someone else's status on this platform will be treated as endorsement and will fall under rule #1.

  3. You are encouraged to use this platform to promote your work on the Linux Kernel, but there is no restriction on permitted topics (with the exception of anything covered by #1 above).

  4. There is no requirement to post in English, but it should be considered the primary language of communication on this platform.

Privacy notice

The admins of this service have access to all posted statuses. They aren't looking, but if it's something they shouldn't know about, then you should not post it on this platform.

Please see the Linux Foundation Privacy Policy, which applies to this platform as well.

Getting your own account

If you would like an account on this instance, please check that the following applies to you:

  • You are listed in MAINTAINERS or CREDITS

  • OR: You have a kernel.org account or email address

  • OR: You have a long and established history of involvement with the Linux Kernel

If the above is true and you agree with the Terms of Service and Privacy Notice listed above, please use these instructions to request an account: