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, as
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 "pat
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 ma
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 a
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.
Correc
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
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
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...
If
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 CC,
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
> > > lore
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:
> /home/gregkh/Downloads/l
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 reports
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 subs
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
> > p
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
> >&
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:
> > >
> > > https://github.com/getpatchwork/patc
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
>
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 3b8c72d076c42bf27
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 do
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 hook
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
✔
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 anothe
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 devel
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 reaso
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 patc
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 se
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 b
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
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 sy
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.html
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: bui
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 previou
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 thin
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.
cert 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
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 r
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 out-of-sorts
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 differe
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
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 it's
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:
https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/pr-tracker-bot.py#n41
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 ex
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
list)
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:
-
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
5
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
5
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:
git://g
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 off
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
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:
>
> > git://git.kernel.org/pub/scm/l
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 reposi
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 generates
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
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
> anyt
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 of
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 a
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 (linux-kernel@vger.kernel.or
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
> abo
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
> > >
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 h
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 "ssh://g.
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,
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 s
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:
> https://git.kern
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 p
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 pr
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.
T
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 thi
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] http://lkml.kernel.org/r/20180830064732.ga2...@dhcp22.suse.
card (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
trust/validity 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 confi
benefit 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
st regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation
signature.asc
Description: OpenPGP digital signature
stree [...]
This 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
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
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 you
even 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
even 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
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 to re-do the pul
ice that the [pgp] signing is not there. Is that normal?
Yes, see
https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
Linux Foundation Projects
Montréal, Québec
ches,
> but
> still: can those be changed to say ".gz" or something, so that
> $browser
> won't _display_ it by default but _download_ it instead?
We'll enable that the moment cgit supports that -- but it currently doesn't. I
have an RFE open with cgit
s and patches as part of the
cryptographically verifiable /pub tree:
https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html
Regards,
--
Konstantin Ryabitsev
Director, IT Infrastructure Security
Linux Foundation Projects
Montréal, Québec
Not unless there is a convincing reason to do so (and please feel free to
provide it, as this is not a final change and can always be undone should the
counter-arguments be convincing).
Regards,
--
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec
are the people who still need to download patches
as opposed to using git directly, and what their use-case scenario is.
Regards,
--
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec
On Mon, Mar 13, 2017 at 09:15:21AM -0700, Linus Torvalds wrote:
On Mon, Mar 13, 2017 at 9:05 AM, Josh Boyer wrote:
Yes. A git pull just grabbed it for me. The 'view diff' link on
kernel.org still fails with bad object, but I'm guessing that will
catch up at some point too.
Hmm. I pushed th
On Mon, Mar 13, 2017 at 11:44:18AM -0400, Ilia Mirkin wrote:
>> rcnee@debian:~/linux$ host git.kernel.org
>> git.kernel.org is an alias for pub.kernel.org.
>> pub.kernel.org is an alias for pub.ewr.kernel.org.
>> pub.ewr.kernel.org has address 147.75.196.57
>> pub.ewr.kernel.org has IPv6 address 26
On Mon, Mar 13, 2017 at 11:44:18AM -0400, Ilia Mirkin wrote:
rcnee@debian:~/linux$ host git.kernel.org
git.kernel.org is an alias for pub.kernel.org.
pub.kernel.org is an alias for pub.ewr.kernel.org.
pub.ewr.kernel.org has address 147.75.196.57
pub.ewr.kernel.org has IPv6 address 2604:1380:1:360
On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote:
>rcnee@debian:~$ git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>Cloning into 'linux'...
>remote: Counting objects: 5266818, done.
>remote: Compressing objects: 100% (803214/803214), done.
>remote: Total 526
On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote:
rcnee@debian:~$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Cloning into 'linux'...
remote: Counting objects: 5266818, done.
remote: Compressing objects: 100% (803214/803214), done.
remote: Total 5266818
On Thu, Jan 19, 2017 at 02:48:38PM +0100, Greg KH wrote:
From: Greg Kroah-Hartman
Might as well just mark it as such now, to head off the constant
questions. Yes, 4.9 is the next longterm supported kernel version.
Signed-off-by: Greg Kroah-Hartman
diff --git a/content/releases.rst b/content
investigating what we can do to
improve the situation and will follow up shortly.
Regards,
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
signature.asc
Description: PGP signature
d of 2015
> 3.4 Li Zefan 2012-05-20 Sep, 2016
> 3.2 Ben Hutchings 2012-01-04 May, 2018
Merged and deployed.
Best,
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
signature.asc
Description: PGP signature
x27;s insanity is now publicly documented on
https://kernel.org/releases.html
Best regards,
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
signature.asc
Description: PGP signature
On 28/10/15 04:41 PM, Greg KH wrote:
> From: Greg Kroah-Hartman
>
> As a result of the discussion at the 2015 Linux Kernel summit, the 4.4
> kernel will be the next longterm kernel release, so notify everyone
> about this on the web site.
Applied and live. Sorry about the delay.
https://kernel.
On 23/09/15 07:14 PM, Greg Kroah-Hartman wrote:
> I'll be maintaining 4.1 for the next two years, proving that after a
> decade of doing stable kernels, I still do not know any better.
>
> Signed-off-by: Greg Kroah-Hartman
v3 applied and live. Good luck!
Best,
--
Konstanti
On 11/03/15 09:24 AM, Greg KH wrote:
> Oops, sorry for missing the change to pelicanconf.py, I'll try to
> remember that in 6 months or so when a new longterm kernel is named.
No worries, I can live with doing it manually once every 6 months. ;)
Best,
--
Konstantin Ryabitsev
Linux
30 Aug, 2016
> 3.12 Jiri Slaby 2013-11-03 2016
> 3.10 Greg Kroah-Hartman 2013-06-30 Sep, 2015
>
Applied, thanks.
https://git.kernel.org/cgit/docs/kernel/website.git/commit/?id=b8b597193b10159204ff09cb9375db2059146233
Best,
--
Konstantin Ryabitsev
Linux
ine or a web-link on the mainpage?
https://www.kernel.org/releases.html
--
Konstantin Ryabitsev
Linux Foundation Collab Projects
Montréal, Québec
pgpis1WTCwFsF.pgp
Description: PGP signature
On Tue, 26 Aug 2014 16:08:58 -0700, Greg KH wrote:
> Li has agreed to continue to support the 3.4 stable kernel tree until
> September 2016. Update the releases.html page on kernel.org to
> reflect this.
Applied and live, thanks.
Best,
--
Konstantin Ryabitsev
Linux Foundation Collab
On 03/07/14 03:19 PM, Greg KH wrote:
> I'm going to be maintaining the 3.14 kernel as a "longterm" kernel for
> the next two years, so mention that on the kernel.org site.
3.14 marked as longterm on the frontpage and in releases.
Thanks, Greg!
Best,
--
Konstantin Rya
1 - 100 of 119 matches
Mail list logo