public inbox for tools@linux.kernel.org
 help / color / mirror / Atom feed
* korgalore v0.4 now available
@ 2026-01-20 15:29 Konstantin Ryabitsev
  2026-01-23 11:59 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 7+ messages in thread
From: Konstantin Ryabitsev @ 2026-01-20 15:29 UTC (permalink / raw)
  To: users, tools

Hi, all:

Korgalore v0.4 is now available with IMAP OAuth2 support for Microsoft 365 and
several GUI improvements.

New features
------------

IMAP OAuth2 Authentication for Microsoft 365:

This release adds support for OAuth2 authentication (XOAUTH2) with Microsoft
365 accounts. The app includes a built-in Azure AD application ID for
zero-configuration setup, though it is going to show up as "unverified"
(it's too much work!).

Your corporate IT may block third-party or unverified apps by default, so in
this case you will need to either get them to approve the korgalore app or
give you their own client_id. 

Example configuration:

    [targets.office365]
    type = 'imap'
    auth_type = 'oauth2'
    server = 'outlook.office365.com'
    username = 'user@company.com'

Improvements
------------
- Close network connections after sync runs to avoid keeping idle connections
  open between periodic syncs (IMAP, HTTP sessions)
- JMAP target now uses shared requests session for consistent User-Agent
  header and proper connection cleanup
- Add GUI optional dependencies to pyproject.toml (pip install korgalore[gui])
- Support AyatanaAppIndicator3 as fallback for AppIndicator3 (needed on
  Debian and derivatives)
- GUI now monitors network availability via Gio.NetworkMonitor and skips
  sync attempts when network is unavailable (airplane mode, resume from
  suspend, etc.). Sync is automatically scheduled when network is restored.
- GUI error messages now display actual error text instead of unhelpful
  "see logs" messages, since logs are not collected by default

Full changelog and documentation:

    https://korgalore.docs.kernel.org/

Source repository:

    https://git.kernel.org/pub/scm/utils/korgalore/korgalore.git

Install via pipx:

    pipx install korgalore

-K

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
  2026-01-20 15:29 korgalore v0.4 now available Konstantin Ryabitsev
@ 2026-01-23 11:59 ` Mauro Carvalho Chehab
  2026-01-23 16:14   ` Konstantin Ryabitsev
  0 siblings, 1 reply; 7+ messages in thread
From: Mauro Carvalho Chehab @ 2026-01-23 11:59 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: users, tools

Hi Konstantin,

On Tue, 20 Jan 2026 10:29:28 -0500
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:

> Hi, all:
> 
> Korgalore v0.4 is now available with IMAP OAuth2 support for Microsoft 365 and
> several GUI improvements.

I started trying it this week to have a copy of my public e-mails
on a separate machine at my office, and indeed it is an interesting
tool. I tested only maildir, as having accounts on oauth2 providers
for kernel stuff is always a lot more complex than it should be.

I used there both lei and non-lei feeds.

One thing that I missed is that "kgl pull" doesn't really pull
e-mails inside the mailbox, even when used with lei to pick the last
week/month of stuff: it just sets it to pick newest e-mails from
now on.

IMO, the default should be to populate maildir with the contents
from the lore git trees, when "kgl pull" is called, as, if one
wants to pick stuff there is because they usually want to look
at the most recent messages - eventually replying to them.
As such, IMHO, the mailbox to be sync altogether with the
already-existing messages from the specified period.

On the exceptional case where one doesn't want that, you could
provide a "--only-new" argument to pull - to skip the mailbox
filling with existing e-mails.

Just my 2 cents.

Regards,
Mauro



> 
> New features
> ------------
> 
> IMAP OAuth2 Authentication for Microsoft 365:
> 
> This release adds support for OAuth2 authentication (XOAUTH2) with Microsoft
> 365 accounts. The app includes a built-in Azure AD application ID for
> zero-configuration setup, though it is going to show up as "unverified"
> (it's too much work!).
> 
> Your corporate IT may block third-party or unverified apps by default, so in
> this case you will need to either get them to approve the korgalore app or
> give you their own client_id. 
> 
> Example configuration:
> 
>     [targets.office365]
>     type = 'imap'
>     auth_type = 'oauth2'
>     server = 'outlook.office365.com'
>     username = 'user@company.com'
> 
> Improvements
> ------------
> - Close network connections after sync runs to avoid keeping idle connections
>   open between periodic syncs (IMAP, HTTP sessions)
> - JMAP target now uses shared requests session for consistent User-Agent
>   header and proper connection cleanup
> - Add GUI optional dependencies to pyproject.toml (pip install korgalore[gui])
> - Support AyatanaAppIndicator3 as fallback for AppIndicator3 (needed on
>   Debian and derivatives)
> - GUI now monitors network availability via Gio.NetworkMonitor and skips
>   sync attempts when network is unavailable (airplane mode, resume from
>   suspend, etc.). Sync is automatically scheduled when network is restored.
> - GUI error messages now display actual error text instead of unhelpful
>   "see logs" messages, since logs are not collected by default
> 
> Full changelog and documentation:
> 
>     https://korgalore.docs.kernel.org/
> 
> Source repository:
> 
>     https://git.kernel.org/pub/scm/utils/korgalore/korgalore.git
> 
> Install via pipx:
> 
>     pipx install korgalore
> 
> -K
> 



Thanks,
Mauro

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
  2026-01-23 11:59 ` Mauro Carvalho Chehab
@ 2026-01-23 16:14   ` Konstantin Ryabitsev
  0 siblings, 0 replies; 7+ messages in thread
From: Konstantin Ryabitsev @ 2026-01-23 16:14 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: users, tools

On Fri, Jan 23, 2026 at 12:59:49PM +0100, Mauro Carvalho Chehab wrote:
> One thing that I missed is that "kgl pull" doesn't really pull
> e-mails inside the mailbox, even when used with lei to pick the last
> week/month of stuff: it just sets it to pick newest e-mails from
> now on.

Yes, for now it acts just like joining a mailing list -- you start receiving
any new mail after you've subscribed. This is mostly to avoid starting off
with delivering a potentially large number of messages to gmail on the very
first run. It takes about 3-5 seconds per message (verily!), so if you are
just setting up and your initial delivery is 1000 messages, you're sitting
there for an hour looking at the progress bar crawling forward.

> IMO, the default should be to populate maildir with the contents
> from the lore git trees, when "kgl pull" is called, as, if one
> wants to pick stuff there is because they usually want to look
> at the most recent messages - eventually replying to them.
> As such, IMHO, the mailbox to be sync altogether with the
> already-existing messages from the specified period.

This is the behaviour we have with "track-subsystem" -- it will deliver the
last 7 days of messages right away. At the moment, I'm loath to do this with
arbitrary lei searches. I'd rather people manually yanked the threads they
actually want.

Thanks for the feedback, though -- I appreciate it.

Regards,
-K

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
@ 2026-01-23 16:43 Mark Brown
  2026-01-23 16:47 ` Konstantin Ryabitsev
  2026-01-23 19:07 ` Konstantin Ryabitsev
  0 siblings, 2 replies; 7+ messages in thread
From: Mark Brown @ 2026-01-23 16:43 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Hi,

If I run

   kgl track-subsystem -m MAINTAINERS 'REGISTER MAP'

then kgl medidtates for a long time then outputs:

| Found subsystem: REGISTER MAP ABSTRACTION
| Creating mailinglist query: l:linux-kernel.vger.kernel.org AND d:7.days.ago..
| Creating patches query: (dfn:Documentation/devicetree/bindings/regmap/ OR dfn:drivers/base/regmap/ OR dfn:include/linux/regmap.h) AND d:7.days.ago..
| Created 2 lei queries for subsystem "REGISTER MAP ABSTRACTION"
| Configuration written to: /home/broonie/.config/korgalore/conf.d/register_map_abstraction.toml
| Target: local, Labels: 

Given how long it took I'd expected it to have done something to the
output, and the above is not going to DTRT given that it's pulling in
linux-kernel.  Probably the program should understand that linux-kernel
is special here.

I'd also have expected MAINTAINERS to be read from the current
directory if it's available and not otherwise specified.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
  2026-01-23 16:43 Mark Brown
@ 2026-01-23 16:47 ` Konstantin Ryabitsev
  2026-01-23 19:07 ` Konstantin Ryabitsev
  1 sibling, 0 replies; 7+ messages in thread
From: Konstantin Ryabitsev @ 2026-01-23 16:47 UTC (permalink / raw)
  To: Mark Brown; +Cc: tools

On Fri, Jan 23, 2026 at 04:43:46PM +0000, Mark Brown wrote:
> Hi,
> 
> If I run
> 
>    kgl track-subsystem -m MAINTAINERS 'REGISTER MAP'
> 
> then kgl medidtates for a long time then outputs:
> 
> | Found subsystem: REGISTER MAP ABSTRACTION
> | Creating mailinglist query: l:linux-kernel.vger.kernel.org AND d:7.days.ago..

Oh, ouch. Yeah, this is 10,000 messages right there (lei's maximum).

> | Creating patches query: (dfn:Documentation/devicetree/bindings/regmap/ OR dfn:drivers/base/regmap/ OR dfn:include/linux/regmap.h) AND d:7.days.ago..
> | Created 2 lei queries for subsystem "REGISTER MAP ABSTRACTION"
> | Configuration written to: /home/broonie/.config/korgalore/conf.d/register_map_abstraction.toml
> | Target: local, Labels: 
> 
> Given how long it took I'd expected it to have done something to the
> output, and the above is not going to DTRT given that it's pulling in
> linux-kernel.  Probably the program should understand that linux-kernel
> is special here.

Agreed, let me figure something out.

> I'd also have expected MAINTAINERS to be read from the current
> directory if it's available and not otherwise specified.

Yes, plus we can also try to grab it from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS
if all else fails.

Thanks for the feedback.

-K

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
  2026-01-23 16:43 Mark Brown
  2026-01-23 16:47 ` Konstantin Ryabitsev
@ 2026-01-23 19:07 ` Konstantin Ryabitsev
  2026-01-23 19:19   ` Mark Brown
  1 sibling, 1 reply; 7+ messages in thread
From: Konstantin Ryabitsev @ 2026-01-23 19:07 UTC (permalink / raw)
  To: Mark Brown; +Cc: tools

On Fri, Jan 23, 2026 at 04:43:46PM +0000, Mark Brown wrote:
> Given how long it took I'd expected it to have done something to the
> output, and the above is not going to DTRT given that it's pulling in
> linux-kernel.  Probably the program should understand that linux-kernel
> is special here.

Done. kgl now filters out the following catch-all mailing lists from subsystem
queries by default:

- linux-kernel@vger.kernel.org
- patches@lists.linux.dev

If a subsystem only has these lists and no others, the mailinglist query
is skipped entirely (only patches query is created). The list can be
customized via main.catchall_lists in the config file, or set to [] to
disable filtering (though I don't see why anyone would want that).

> I'd also have expected MAINTAINERS to be read from the current
> directory if it's available and not otherwise specified.

Also done. The -m/--maintainers flag is now optional. kgl looks for
MAINTAINERS in this order:

1. Explicit path via -m
2. ./MAINTAINERS in current directory
3. Fetch from kernel.org (cached for 24 hours)

So you can now just run "kgl track-subsystem 'REGMAP'" from your kernel
tree without any extra flags.

Cheers,
-K

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: korgalore v0.4 now available
  2026-01-23 19:07 ` Konstantin Ryabitsev
@ 2026-01-23 19:19   ` Mark Brown
  0 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2026-01-23 19:19 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: tools

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Fri, Jan 23, 2026 at 02:07:18PM -0500, Konstantin Ryabitsev wrote:
> On Fri, Jan 23, 2026 at 04:43:46PM +0000, Mark Brown wrote:
> > Given how long it took I'd expected it to have done something to the
> > output, and the above is not going to DTRT given that it's pulling in
> > linux-kernel.  Probably the program should understand that linux-kernel
> > is special here.

> Done. kgl now filters out the following catch-all mailing lists from subsystem
> queries by default:

> - linux-kernel@vger.kernel.org
> - patches@lists.linux.dev

Great, thanks!

> So you can now just run "kgl track-subsystem 'REGMAP'" from your kernel
> tree without any extra flags.

Also great, thanks.  Sadly the above doesn't work but that's because
MAINTAINERS doesn't actually say regmap which is a MAINTAINERS issue.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-01-23 19:19 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-01-20 15:29 korgalore v0.4 now available Konstantin Ryabitsev
2026-01-23 11:59 ` Mauro Carvalho Chehab
2026-01-23 16:14   ` Konstantin Ryabitsev
  -- strict thread matches above, loose matches on Subject: below --
2026-01-23 16:43 Mark Brown
2026-01-23 16:47 ` Konstantin Ryabitsev
2026-01-23 19:07 ` Konstantin Ryabitsev
2026-01-23 19:19   ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox