Re: Please create the email alias do-not-apply-to-sta...@kernel.org -> /dev/null

On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote: > @Greg, BTW: should this be stable+noauto...@kernel.org or have a > 'vger.' No vger, just stable+whate...@kernel.org. > in it, e.g. stable+noauto...@vger.kernel.org? I assume without 'vger.' > is fine, just wanted to be sure,

Re: Please create the email alias do-not-apply-to-sta...@kernel.org -> /dev/null

On Wed, Apr 17, 2024 at 03:38:28PM +0200, Greg KH wrote: > > That afaics makes them useless for the stable team (Greg may correct > > me > > if I'm wrong here), as they deal with the commits and have no easy, > > fast, and reliable way to look up the patch posting to query this. Or is > > the

Re: Please create the email alias do-not-apply-to-sta...@kernel.org -> /dev/null

On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote: > > In general, I feel this information belongs in the patch basement > > (the place where change-id, base-commit, etc goes). E.g.: > > > > stable-autosel: ignore > > [This fix requires a feature that is only present in

Re: Please create the email alias do-not-apply-to-sta...@kernel.org -> /dev/null

On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote: > Hi kernel.org helpdesk! > > Could you please create the email alias > do-not-apply-to-sta...@kernel.org which redirects all mail to /dev/null, > just like sta...@kernel.org does? > > That's an idea GregKH brought up a few days

Re: [PATCH v2 1/2] get_maintainer: add patch-only keyword-matching

On Wed, Sep 27, 2023 at 10:08:33PM -0700, Joe Perches wrote: > > This could all be a moot point, though, as I believe Konstantin > > is trying to separate out the whole idea of a patch-sender needing > > to specify the recipients of a patch. > > As I understand it, by using get_maintainer.

Re: This list is being migrated to new infrastructure

On Wed, Sep 20, 2023 at 03:52:05PM -0400, Konstantin Ryabitsev wrote: > Hello, all: > > This list is being migrated to the new vger infrastructure. This should be a > fully transparent process and you don't need to change anything about how you > participate with the list or how y

Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Tue, Mar 23, 2021 at 09:30:33AM -0700, James Bottomley wrote: > > I think the bulk of user issues are going to be regressions. Although > > you may be in a better position to know for sure, but at least for > > me, wearing my "user" hat, the thing that gets me the most is > > upgrading to a new

Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Tue, 23 Mar 2021 at 04:58, Thorsten Leemhuis wrote: > > If we can > > actually get users to *read* it, I think it's going to save kernel > > developers a huge amount of time and frustration. > > And users hopefully as well. But yes, making them read it is the > problem. :-/ I've added a very

Re: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Mon, Mar 22, 2021 at 07:55:29PM +0100, Thorsten Leemhuis wrote: > Out of curiosity: will that work for other bug trackers as well? Like > the gitlab instance used by the drm developers? It's not really > important and I guess the answer will be "no", but the question came up > while at it...

Re: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions

On Mon, Mar 22, 2021 at 04:18:14PM +0100, Thorsten Leemhuis wrote: > Note, there is a second reason why ksummit-discuss is CCed: another > reason why I want to create this new list is making it easier to find > and track regressions reported to our various mailing lists (often > without LKML in

Re: [GIT] SPARC

On Wed, Mar 10, 2021 at 11:40:47AM +0100, Geert Uytterhoeven wrote: > > > (And yes, I prefer lore.kernel.org over marc, although for single > > > patches it doesn't make much of a difference. For patch series, I find > > > 'b4' so convenient that I definitely want the patch to show up on > > >

Re: stable kernel checksumming fails

On Sun, Mar 07, 2021 at 03:45:15PM +0100, Greg KH wrote: > > checksumming the downloaded kernel manually gives an "Okay" though. > > > > > > is this just me (on Fedora 33) ? > > Fails for me on Arch: > > Verifying checksum on linux-5.11.4.tar.xz > /usr/bin/sha256sum: >

Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org

On Wed, Jan 13, 2021 at 01:17:10PM +0200, Jani Nikula wrote: > >> Well, that said, a lot of stuff sent to the _proper_ mailing lists also > >> never > >> receives a response > > > > Good point. > > There's a school of thought that this is actually a feature. If there's > no attention, the

Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org

On Sun, Jan 10, 2021 at 01:10:33PM +0100, Thorsten Leemhuis wrote: > The front page doesn't make this aspect obvious and not even point to > Documentation/admin-guide/reporting-bugs.rst to help those that want to > properly report a bug. Only the FAQ mentions it, albeit only indirectly: > 'The

Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe

On Thu, Dec 24, 2020 at 01:57:40PM -0800, Florian Fainelli wrote: > >> Konstantin, would you be willing to mod the kernel.org instance of > >> patchwork to populate Fixes tags in the generated mboxes? > > > > I'd really rather not -- we try not to diverge from project upstream if at > > all > >

Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe

On Mon, Dec 28, 2020 at 01:05:26PM -0800, Florian Fainelli wrote: > On 12/28/2020 12:23 PM, Konstantin Ryabitsev wrote: > > On Thu, Dec 24, 2020 at 01:57:40PM -0800, Florian Fainelli wrote: > >>>> Konstantin, would you be willing to mod the kernel.org instance of > >&

Re: [PATCH] net: ethernet: Fix memleak in ethoc_probe

On Wed, Dec 23, 2020 at 05:41:46PM -0800, Jakub Kicinski wrote: > > >> Does patchwork not automagically add Fixes: lines from full up emails? > > >> That seems like a reasonable automation. > > > > > > Looks like it's been a TODO for 3 years now: > > > > > >

Re: PGP pathfinder service is no longer maintained

On Wed, Dec 16, 2020 at 10:20:18PM +, Matthew Wilcox wrote: > > Unfortunately the site https://pgp.cs.uu.nl/ is not maintained > > anymore > > and the "Finding paths to Linus" link in the Kernel Maintainer PGP guide > > is dead. Is there any alternative sites to find a way through the web of

Re: [PATCH AUTOSEL 5.9 15/23] scsi: storvsc: Validate length of incoming packet in storvsc_on_channel_callback()

On Mon, Dec 14, 2020 at 02:07:11PM +0300, Dan Carpenter wrote: > On Sat, Dec 12, 2020 at 07:09:01PM +0100, Andrea Parri wrote: > > Hi Sasha, > > > > On Sat, Dec 12, 2020 at 11:07:56AM -0500, Sasha Levin wrote: > > > From: "Andrea Parri (Microsoft)" > > > > > > [ Upstream commit

Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch

On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote: > Perhaps automate a mechanism to capture that information as > git notes for the patches when applied. Git notes have a limited usefulness for this -- they are indeed part of the repository, but they aren't replicated unless someone

Re: [PATCH] pstore: Move kmsg_bytes default into Kconfig

On Wed, Dec 02, 2020 at 02:30:08PM -0800, Kees Cook wrote: > > Did you use the sendemail-validate hook for this? > > In my scripts right now, I'm doing this before "git send-email": > > # Construct header-based attestations > b4 attest outgoing/* > > I haven't yet converted to using the git

Re: [PATCH] pstore: Move kmsg_bytes default into Kconfig

On Tue, Dec 01, 2020 at 12:12:34PM -0800, Kees Cook wrote: > --- > This was sent off-list, so I'm resending it to lkml (with the commit log > cleaned up sligthly) before I push it into for-next/pstore. Also, nice: Writing /tmp/20201201_keescook_pstore_move_kmsg_bytes_default_into_kconfig.mbx ✔

Re: [GIT PULL] USB/PHY driver fixes for 5.10-rc6

On Sat, Nov 28, 2020 at 03:50:28PM -0800, Linus Torvalds wrote: > On Sat, Nov 28, 2020 at 2:07 PM Randy Dunlap wrote: > > > > Could it just be a vger issue? vger has been acting ill today... > > Possible. pr-tracker-bot obviously is back, it just had a very long delay. Correct, there was

Re: [PATCH AUTOSEL 5.9 054/111] USB: cdc-acm: handle broken union descriptors

On Mon, Oct 19, 2020 at 09:10:34AM +0200, Johan Hovold wrote: > Hmm. Apparently the Link-tag that I had added to keep a record of the > descriptors provided in the original report also fell out. Another b4 > bug? > > Adding Konstantin just in case. Correct, looks like this was broken in the

Re: Backing up the PGP master key

On Thu, Oct 15, 2020 at 12:34:06AM +0300, Jarkko Sakkinen wrote: > Konstantin, writing to you based on 'git blame' :-) > > The maintainer guide recommends using paperkey for the PGP master key, > which is a prefectly sane method. > > I was just wondering that isn't a backup to a USB stick a

Re: [PATCH 00/18] use semicolons rather than commas to separate statements

On Sat, Oct 03, 2020 at 09:18:51PM +0200, Julia Lawall wrote: > > > There seems to be some mismatch between b4's use of the > > > cover letter to a patch series and what maintainers that > > > apply a subset of the patches in the patch series. > > > > > > The merge description shows the entire

Re: [PATCH 00/18] use semicolons rather than commas to separate statements

On Sat, Oct 03, 2020 at 11:40:48AM -0700, Joe Perches wrote: > (Adding tools and Konstantin Ryabitsev) > > There seems to be some mismatch between b4's use of the > cover letter to a patch series and what maintainers that > apply a subset of the patches in the patch series.

Re: [PATCH v2 1/2] perf vendor events: Update CascadelakeX events to v1.08

On Fri, Sep 25, 2020 at 03:05:27PM -0300, Arnaldo Carvalho de Melo wrote: > Things like b4 help with this and probably have to take into account > attachments as well, that is why I'm adding Konstantin to the Cc: list > of this message. > > Konstantin, is this case covered? I.e. patches that get

Re: [GIT PULL] io_uring changes for 5.9-rc1

On Mon, Aug 03, 2020 at 01:53:12PM -0700, Linus Torvalds wrote: > On Mon, Aug 3, 2020 at 1:48 PM Linus Torvalds > wrote: > > > > I've pushed out my merge of this thing [..] > > It seems I'm not the only one unhappy with the pull request. > > For some reason I also don't see pr-tracker-bot being

Re: linux-next: Fixes tag needs some work in the block tree

On Fri, Jun 26, 2020 at 07:32:15PM -0600, Jens Axboe wrote: > On 6/26/20 5:07 PM, Stephen Rothwell wrote: > > Hi all, > > > > In commit > > > > cd664b0e35cb ("io_uring: fix hanging iopoll in case of -EAGAIN") > > > > Fixes tag > > > > Fixes: bbde017a32b3 ("io_uring: add memory barrier to

Re: fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/': SSL certificate problem: certificate has expired

On Sat, 30 May 2020 at 12:16, Konstantin Ryabitsev wrote: > > > $ curl https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ > > > curl: (60) SSL certificate problem: certificate has expired > > > More details here: https://curl.haxx.se/docs/sslcerts.h

Re: fatal: unable to access 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/': SSL certificate problem: certificate has expired

On Sat, May 30, 2020 at 03:47:19PM +0200, Toralf Förster wrote: > > $ git pull > > 15:07:08.488836 git.c:439 trace: built-in: git pull > > 15:07:08.504295 run-command.c:663 trace: run_command: git fetch > > --update-head-ok > > 15:07:08.506481 git.c:439 trace:

Re: [sysadmin] New Wiki URLs?

On Tue, Apr 28, 2020 at 06:44:40AM +0200, Alexander Dahl wrote: > Could the webmasters of kernel.org please configure some kind of > redirects so people don't get 404 errors when looking for docs? If someone goes through the trouble of compiling a list of such redirects, then perhaps. The

Re: email as a bona fide git transport

On Fri, Oct 18, 2019 at 11:54:09AM -0400, Santiago Torres Arias wrote: Seeing how large this signature is, I have to admit that I am partial to Konstantin's suggestion of using minisign. This seems like something that could be added to git as an alternative to gpg without too much trouble, I

Re: problem of posting patch to lkml

On Sat, Oct 12, 2019 at 12:45:28PM +0800, Hillf Danton wrote: Hey Konstantin The patches I sent out could not reach x...@vger.kernel.org because I am not able to find any of them at lore.kernel.org/lkml unless it was replied by the readers. xyz can be pci, netdev and linux-kernel for instance.

Re: Kernel.org SSL certification expired

renewal process failed to restart the daemon. It should be good now for everyone. Regards, -- Konstantin Ryabitsev Kernel.org Systems Administrator Montéal, Québec

Distributing kernel developer PGP keys via pgpkeys.git

Hi, all: As you may be aware, the SKS keyserver network has been very unreliable lately due to two general factors: - a large number of SKS servers were shut down in the past year or so due to GDPR compliance concerns (as designed, SKS is not compliant and cannot be made compliant) - the

Re: Latest kernel version no NOT reflecting on kernel.org

On Wed, Aug 28, 2019 at 07:05:47PM +0200, Greg KH wrote: > I think there's a way to see which cdn mirror you are hitting when > you > ask for "www.kernel.org". Konstantin, any hints as to see if maybe one > of the mirrors is out of sync? Looks like the Singapore mirror was feeling

Re: Latest kernel version no NOT reflecting on kernel.org

On Wed, Aug 28, 2019 at 05:13:53PM +0200, Greg KH wrote: On Wed, Aug 28, 2019 at 07:27:53PM +0530, Bhaskar Chowdhury wrote: Am I the only one, who is not seeing it getting reflected on kernel.org??? Well, I have tried it 2 different browsers.cleared caches several times(heck) .3

Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3

On Mon, Aug 05, 2019 at 12:17:49PM -0700, Linus Torvalds wrote: However, I suspect that getting message-ids for all your pull requests would significantly complicate your workflow. Yeah, that would be a noticeable annoyance. If I were to process pull requests the way I used to process emailed

Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3

On Mon, Aug 05, 2019 at 11:20:59AM -0700, Linus Torvalds wrote: I don't know if it's worth changing the pr-tracker-bot rules. I *do* think that the whole unquoted for you to fetch changes up to [hex string] is by far the strongest single signal for a pull request, but it's not clear that

Re: [GIT PULL] SafeSetID MAINTAINERS file update for v5.3

On Sun, Aug 04, 2019 at 10:47:54AM -0700, Linus Torvalds wrote: - maybe pr-tracker-bot ignores follow-up emails with "Re:" in the subject? Yes, this is the culprit. Here are the matching regexes:

Re: PSA: Do not use "Reported-By" without reporter's approval

On Fri, May 24, 2019 at 12:57:08AM -0400, Theodore Ts'o wrote: I'm perfectly fine with Link:, however Reported-By: usually has the person's name and email address (i.e. PII data per GDPR definition). If that pehrson submitted the bug report via bugzilla.kernel.org or a similar resource, their

Re: PSA: Do not use "Reported-By" without reporter's approval

On Wed, May 22, 2019 at 12:45:06PM -0700, Joe Perches wrote: It is common courtesy to include this tagline when submitting patches: Reported-By: J. Doe Please ask the reporter's permission before doing so (even if they'd submitted a public bugzilla report or sent a report to the mailing

PSA: Do not use "Reported-By" without reporter's approval

Hello, all: It is common courtesy to include this tagline when submitting patches: Reported-By: J. Doe Please ask the reporter's permission before doing so (even if they'd submitted a public bugzilla report or sent a report to the mailing list). They need to understand and agree that: -

Re: [PATCH 11/10] arm64: unbreak DYNAMIC_DEBUG=y build with clang

On Fri, Apr 26, 2019 at 09:27:46PM +0200, Rasmus Villemoes wrote: On 26/04/2019 21.06, Rasmus Villemoes wrote: Andrew, please apply and/or fold into 9/10. Hm, I'm getting bounces for Andrew's email address: The mail system : host 172.17.192.39[172.17.192.39] said: 550

Re: [PATCH 11/10] arm64: unbreak DYNAMIC_DEBUG=y build with clang

On Fri, Apr 26, 2019 at 09:27:46PM +0200, Rasmus Villemoes wrote: On 26/04/2019 21.06, Rasmus Villemoes wrote: Andrew, please apply and/or fold into 9/10. Hm, I'm getting bounces for Andrew's email address: The mail system : host 172.17.192.39[172.17.192.39] said: 550

Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6

On Mon, Feb 11, 2019 at 02:04:08PM -0800, Linus Torvalds wrote: Okay, so I need guidance on the proper behaviour here. As this request didn't use the magic wording for the commit-id (as generated by git-request-pull), we ended up trying to look up the remote. The remote specified was:

Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6

On Mon, Feb 11, 2019 at 10:34:09AM -0800, Linus Torvalds wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > fixes > > has been merged into torvalds/linux.git: > https://git.kernel.org/torvalds/c/7ad915f5ebf5b9e7ca98a7048d8f84a631fe388b I think the bot is

Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6

On Mon, 11 Feb 2019 at 13:40, Konstantin Ryabitsev wrote: > >> On Sun, Feb 10, 2019 at 04:25:16AM +, pr-tracker-...@kernel.org wrote: > >> > The pull request you sent on Sat, 9 Feb 2019 20:17:23 -0800: > >> > > >> > > git://git.kernel.org/pub

Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6

On Mon, Feb 11, 2019 at 10:34:09AM -0800, Linus Torvalds wrote: On Sun, Feb 10, 2019 at 7:19 PM Eduardo Valentin wrote: On Sun, Feb 10, 2019 at 04:25:16AM +, pr-tracker-...@kernel.org wrote: > The pull request you sent on Sat, 9 Feb 2019 20:17:23 -0800: > > >

Re: [GIT PULL] csky fixup for linux-5.0-rc1

On Thu, Jan 10, 2019 at 04:02:03PM +0800, Guo Ren wrote: > Can I take back this pull request and send a new pull request with > https:// URLs ? It's not necessary at this point, as the pull request has already been processed. However, your future emails should have the public URL of the git

Re: [GIT PULL] csky fixup for linux-5.0-rc1

On Wed, Jan 09, 2019 at 10:40:20AM -0800, Linus Torvalds wrote: > Side note: I do wish people would use the proper _public_ access. I'm wondering if this largely happens due to people's insteadOf rules. We've established that git-request-pull will quietly substitute URLs in the emails it

Re: [GIT PULL] csky fixup for linux-5.0-rc1

On Wed, Jan 09, 2019 at 06:05:01PM +, pr-tracker-...@kernel.org wrote: > The pull request you sent on Wed, 9 Jan 2019 22:49:57 +0800: > > > (unable to parse the git remote) I just committed a fix for this. We weren't expecting URLs without :// in them. -K

Re: [GIT PULL] libnvdimm for 4.21

On Fri, Dec 28, 2018 at 09:57:28PM -0800, Linus Torvalds wrote: > Hmm. > > This pull request doesn't seem to have gotten an automatic pr-tracker > reply, even though I pulled it, and even though it was cc'd to lkml. > > Konstantin, any idea why the automation didn't trigger? I'm not seeing >

Re: [RFC] LKML Archive in Maildir Format

On Sun, Dec 16, 2018 at 09:21:35AM -1000, Joey Pabalinas wrote: > That was my first attempt, but the ducumentation for the public-inbox > format is sort of terrible, I'm surprised you think so, because it's basically a simple file called "m" that is updated on each commit and contains the body

Re: [RFC] LKML Archive in Maildir Format

On Sun, Dec 16, 2018 at 09:06:39AM -1000, Joey Pabalinas wrote: > I spent a lot of time trying to find an LKML archive in Maildir format > that I could use for local searches with nutmuch or something, but all > the links I was able to find were all dead. > > I ended up just compiling one myself

Get notified when your patches are applied to linux-next or mainline

Hello: We are trialing out a new feature that can send you a notification when the patches you send to the LKML are applied to linux-next or to the mainline git trees. If you are interested in trying it out, here are the details: - The patches must be sent to the LKML

Re: linux-next: Signed-off-by missing for commit in the gfs2 tree

On Tue, Dec 11, 2018 at 09:47:43PM +0100, Andreas Grünbacher wrote: > > Now, after the rebase: > > > > Commits > > > > 187e4dad3f55 ("gfs2: Remove vestigial bd_ops") > > > > is missing a Signed-off-by from its committer. > > Yep, I've not asked for a way to get the server to reject or warn >

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 11:27:06AM -0600, Bjorn Helgaas wrote: > > > OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should > > > https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or > > > expand that recommendation? The only reason I added insteadOf in the > >

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 11:27:06AM -0600, Bjorn Helgaas wrote: > > > OK, I think I'll remove the insteadOf chunk from my .gitconfig. Should > > > https://korg.wiki.kernel.org/userdoc/gitolite be updated to remove or > > > expand that recommendation? The only reason I added insteadOf in the > >

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 09:03:21AM -0600, Bjorn Helgaas wrote: > > You didn't really do anything wrong. In *general* I prefer to see > > public URLs if they are sent to public lists, so if you're cc'ing > > something to LKML, I would generally expect the pull request to have a > > public URL like

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 09:03:21AM -0600, Bjorn Helgaas wrote: > > You didn't really do anything wrong. In *general* I prefer to see > > public URLs if they are sent to public lists, so if you're cc'ing > > something to LKML, I would generally expect the pull request to have a > > public URL like

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 01:12:53AM -0600, Bjorn Helgaas wrote: > > and I kinda see the point of maybe not having your ssh username in the > > URL. Not that it is a big deal for us, k.org users though. > > Sorry, I don't understand the problem. I have this in my .gitconfig: > > [url

Re: [GIT PULL] PCI fixes for v4.20

On Thu, Nov 15, 2018 at 01:12:53AM -0600, Bjorn Helgaas wrote: > > and I kinda see the point of maybe not having your ssh username in the > > URL. Not that it is a big deal for us, k.org users though. > > Sorry, I don't understand the problem. I have this in my .gitconfig: > > [url

Re: [GIT PULL] PCI fixes for v4.20

On Wed, Nov 14, 2018 at 10:46:01PM +0100, Borislav Petkov wrote: > > > that bot needs some parsing improvs: "None None". > > > > Correct, this is because the original pull request was for an ssh:// > > You'd think Bjorn would know better... :-))) For the record, there's nothing wrong with that,

Re: [GIT PULL] PCI fixes for v4.20

On Wed, Nov 14, 2018 at 10:46:01PM +0100, Borislav Petkov wrote: > > > that bot needs some parsing improvs: "None None". > > > > Correct, this is because the original pull request was for an ssh:// > > You'd think Bjorn would know better... :-))) For the record, there's nothing wrong with that,

Re: [GIT PULL] PCI fixes for v4.20

On Wed, Nov 14, 2018 at 09:12:14PM +0100, Borislav Petkov wrote: > Hey Konstantin, > > that bot needs some parsing improvs: "None None". Correct, this is because the original pull request was for an ssh:// URL, which I'm not properly handling for the purposes of generating responses. I will add

Re: [GIT PULL] PCI fixes for v4.20

On Wed, Nov 14, 2018 at 09:12:14PM +0100, Borislav Petkov wrote: > Hey Konstantin, > > that bot needs some parsing improvs: "None None". Correct, this is because the original pull request was for an ssh:// URL, which I'm not properly handling for the purposes of generating responses. I will add

Re: [GIT PULL] namespace fixes for v4.20-rc2

On Wed, Nov 14, 2018 at 12:55:45AM +, pr-tracker-...@kernel.org wrote: > The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600: > > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > > for-linus > > has been merged into torvalds/linux.git: >

Re: [GIT PULL] namespace fixes for v4.20-rc2

On Wed, Nov 14, 2018 at 12:55:45AM +, pr-tracker-...@kernel.org wrote: > The pull request you sent on Sat, 10 Nov 2018 12:12:12 -0600: > > > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > > for-linus > > has been merged into torvalds/linux.git: >

Re: Git pull ack emails..

On Thu, Oct 25, 2018 at 07:13:59AM -0700, Linus Torvalds wrote: > It would be much nicer if the "notification" really did the right > thing, and created an actual email follow-up, with the correct To/Cc > and subject lines, but also the proper "References" line so that it > actually gets threaded

Re: Git pull ack emails..

On Thu, Oct 25, 2018 at 07:13:59AM -0700, Linus Torvalds wrote: > It would be much nicer if the "notification" really did the right > thing, and created an actual email follow-up, with the correct To/Cc > and subject lines, but also the proper "References" line so that it > actually gets threaded

Re: [sysadmin] Re: linux-next: Tree for Oct 29

On Mon, Oct 29, 2018 at 01:16:59PM +0100, Geert Uytterhoeven wrote: > I can confirm syd.git.kernel.org and ord.git.kernel.org have it, but > fra.git.kernel.org (my default) hasn't. The Frankfurt frontend lost the VPN connection to our main infra. I'm checking why the alerts for that didn't fire

Re: [sysadmin] Re: linux-next: Tree for Oct 29

On Mon, Oct 29, 2018 at 01:16:59PM +0100, Geert Uytterhoeven wrote: > I can confirm syd.git.kernel.org and ord.git.kernel.org have it, but > fra.git.kernel.org (my default) hasn't. The Frankfurt frontend lost the VPN connection to our main infra. I'm checking why the alerts for that didn't fire

Re: Git pull ack emails..

On Tue, Oct 23, 2018 at 10:46:06AM +0100, Linus Torvalds wrote: If it's a "proper" pull request (ie done by git request-pull), then the magic marker would be that it as that for you to fetch changes up to %H: line where %H is the hash of the tip of the tree that is requested to be pulled.

Re: Git pull ack emails..

On Tue, Oct 23, 2018 at 10:46:06AM +0100, Linus Torvalds wrote: If it's a "proper" pull request (ie done by git request-pull), then the magic marker would be that it as that for you to fetch changes up to %H: line where %H is the hash of the tip of the tree that is requested to be pulled.

Re: linux-mm@ archive on lore.kernel.org (Was: [PATCH 0/2] thp nodereclaim fixes)

On Thu, Sep 27, 2018 at 12:08:38AM +0100, Mel Gorman wrote: > > fwiw, I have everything going back to 2001. For some reason. > > This is far better than mine and the only person I think could potentially > improve upon the archives is Rik. 2001 would cover the most interesting > periods when

Re: linux-mm@ archive on lore.kernel.org (Was: [PATCH 0/2] thp nodereclaim fixes)

On Thu, Sep 27, 2018 at 12:08:38AM +0100, Mel Gorman wrote: > > fwiw, I have everything going back to 2001. For some reason. > > This is far better than mine and the only person I think could potentially > improve upon the archives is Rik. 2001 would cover the most interesting > periods when

Re: linux-mm@ archive on lore.kernel.org (Was: [PATCH 0/2] thp nodereclaim fixes)

On Wed, Sep 26, 2018 at 04:08:50PM +0300, Kirill A. Shutemov wrote: On Tue, Sep 25, 2018 at 02:03:24PM +0200, Michal Hocko wrote: Thoughts, alternative patches? [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarca...@redhat.com [2]

Re: linux-mm@ archive on lore.kernel.org (Was: [PATCH 0/2] thp nodereclaim fixes)

On Wed, Sep 26, 2018 at 04:08:50PM +0300, Kirill A. Shutemov wrote: On Tue, Sep 25, 2018 at 02:03:24PM +0200, Michal Hocko wrote: Thoughts, alternative patches? [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarca...@redhat.com [2]

[PATCH] Documentation/process: updates to the PGP guide

(specifically, Nitrokeys) - Link to the GnuPG wiki page about gpg-agent forwarding over ssh - Tell git to use gpgv2 instead of legacy gpgv when verifying signed tags or commits Signed-off-by: Konstantin Ryabitsev <konstan...@linuxfoundation.org> --- Documentation/process/maintainer-pgp-guide.rs

[PATCH] Documentation/process: updates to the PGP guide

(specifically, Nitrokeys) - Link to the GnuPG wiki page about gpg-agent forwarding over ssh - Tell git to use gpgv2 instead of legacy gpgv when verifying signed tags or commits Signed-off-by: Konstantin Ryabitsev --- Documentation/process/maintainer-pgp-guide.rst | 39 -- 1 file

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

t config --global gpgv.program gpgv2 Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

of your master key. For the recipients, it's sufficient to just refresh your key: gpg2 --refresh-key rost...@goodmis.org To validate ECC tags, you will need to tell git to always use gpg2, since gpg1 doesn't know what ECC is: git config --global gpg.program gpg2 git config --global gpgv.program g

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

enefit to having a signing subkey stronger than 2048 bits, especially for the purposes of signing git objects -- which are only as strong as SHA1. Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH 0/5] [GIT PULL] tracing: A few last minute clean up and fixes

enefit to having a signing subkey stronger than 2048 bits, especially for the purposes of signing git objects -- which are only as strong as SHA1. Regards, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Are you in MAINTAINERS? Get your free Nitrokey Start.

, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Are you in MAINTAINERS? Get your free Nitrokey Start.

, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

is will create refs/notes/crosstree that has less of a chance to be clobbered by someone else's use of notes. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH v3 19/20] firmware: add request_firmware_cache() to help with cache on reboot

is will create refs/notes/crosstree that has less of a chance to be clobbered by someone else's use of notes. Best, -- Konstantin Ryabitsev Director, IT Infrastructure Security The Linux Foundation signature.asc Description: OpenPGP digital signature

Re: [PATCH v2] Documentation/process: kernel maintainer PGP guide

On Thu, Feb 01, 2018 at 11:14:50AM -0700, Jonathan Corbet wrote: - Capitalizing "Kernel" bugs me. Obviously not a big deal. Noted. - The "master keys vs. subkeys" section is nice, but it's missing one thing, IMO: a sentence saying what a subkey *is* in the first place. I'll work that in

Re: [PATCH v2] Documentation/process: kernel maintainer PGP guide

On Thu, Feb 01, 2018 at 11:14:50AM -0700, Jonathan Corbet wrote: - Capitalizing "Kernel" bugs me. Obviously not a big deal. Noted. - The "master keys vs. subkeys" section is nice, but it's missing one thing, IMO: a sentence saying what a subkey *is* in the first place. I'll work that in

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

On Wed, Jan 31, 2018 at 09:18:11AM +0200, Jani Nikula wrote: Just one nit, I think it would be better to move the Maintainer: bit from the end near the top as a reStructuredText field list. See 'git grep :Author:' under Documentation for examples. Could even add a MAINTAINERS entry to improve

Re: [PATCH] Documentation/process: kernel maintainer PGP guide

On Wed, Jan 31, 2018 at 09:18:11AM +0200, Jani Nikula wrote: Just one nit, I think it would be better to move the Maintainer: bit from the end near the top as a reStructuredText field list. See 'git grep :Author:' under Documentation for examples. Could even add a MAINTAINERS entry to improve

[PATCH v2] Documentation/process: kernel maintainer PGP guide

those who do rarely remember that such wiki exists. Keeping it with the rest of in-kernel docs should hopefully give it more visibility, but also help keep it up-to-date as tools and processes evolve. Signed-off-by: Konstantin Ryabitsev <konstan...@linuxfoundation.org> --- Documentation/p

[PATCH v2] Documentation/process: kernel maintainer PGP guide

those who do rarely remember that such wiki exists. Keeping it with the rest of in-kernel docs should hopefully give it more visibility, but also help keep it up-to-date as tools and processes evolve. Signed-off-by: Konstantin Ryabitsev --- Documentation/process/index.rst

[PATCH] Documentation/process: kernel maintainer PGP guide

those who do rarely remember that such wiki exists. Keeping it with the rest of in-kernel docs should hopefully give it more visibility, but also help keep it up-to-date as tools and processes evolve. Signed-off-by: Konstantin Ryabitsev <konstan...@linuxfoundation.org> --- Documentation/p

[PATCH] Documentation/process: kernel maintainer PGP guide

those who do rarely remember that such wiki exists. Keeping it with the rest of in-kernel docs should hopefully give it more visibility, but also help keep it up-to-date as tools and processes evolve. Signed-off-by: Konstantin Ryabitsev --- Documentation/process/index.rst

Re: leaking_addresses script..

On Thu, Nov 16, 2017 at 08:11:24AM +1100, Tobin C. Harding wrote: On Tue, Nov 14, 2017 at 02:45:59PM -0800, Linus Torvalds wrote: On Tue, Nov 14, 2017 at 1:03 PM, Tobin C. Harding wrote: > > I did not sign the tag, it looks like you have not processed this yet. > Do you want me

  1   2   >