Re: 1 year src-patch anniversary!

2023-02-15 Thread Tomoaki AOKI 
On Mon, 30 Jan 2023 03:54:48 +0100
"Julian H. Stacey"  wrote:

> Jamie Landeg-Jones wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> > to an admittedly trivial issue, but it's soon going to hit one year old,
> > and has not had any feedback. Not even "this is rubbish. close ticket"
> >
> > | jamie@catwalk:~ % stat 'so good they named it twice'
> > | stat: so good they named it twice: stat: No such file or directory
> >
> > As such, it's the oldest of my patches to be completely ignored, but then,
> > most of my fixes I haven't even submitted, because, what's the point?
> > I've instead spent time writing something so the patches are automatically
> > aplied to my src tree, and distributed to all my servers.
> 
> I wrote a tool in 1993 I still use
>   http://www.berklix.com/~jhs/bin/.csh/customise
> to apply trees of generic & personal diffs to src & ports, for multi releases
>   http://www.berklix.com/~jhs/src/
> to apply diffs, where some are submitted, some committed
> for some versions, some diffs still needed for older versions, &
> some not submitted or committed.
> 
> I guess many, especially non-commiters, maintain trees of uncommited
> diffs & there's probably other applicator scripts, numerous
> re-inventing of wheels for decades, 'cos send-pr /
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
> commiters can't keep up with submissions.
> 
> & non committers can't afford to wait months or years, remembering
> what's been seen commited to Release X.Y & what still needs to be
> kept to apply to other inc. older releases.  Probably lots of
> re-invented wheels: trees of diffs & applicator scripts, but to
> different standards, not uniformly exportable, not immediately
> familiar to & usable by others.
> 
> While retaining the model of "This generic src/ ports/ doc/ tree
> has been built from patches blessed by commiters as fit for all"
> 
> FreeBSD hackers(especially non commiters who must wait for commits
> to reduce their heap of candidate diffs) would benefit from a unified
> set of tools & directory formats to allow individuals to maintain
> & export trees of candidate diffs etc to some common standards.
> 
> It wouldnt obviate / replace send-pr &
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
> be an optional normalied convenience, especially beneficial to those
> who are Not commiters but who have growing heaps of uncommited patches.
> 
> Maybe a summer of code or other person might look at Jamie's & my
> applicator scripts, & diff tree shapes, not for our actual current diffs,
> but to design common unified standards to export trees of candidate diffs
> that can be applied by one common applicator tool ?
> 
> Hacker who are not committers presumably accumulate an an ever
> growing heap of diffs, a burden best normalised & automated.
> 
> > I know it's a volunteer effort, but I've been here 25 years, and whilst
> > I could (and should) take on more port-maintainership, any other offers
> > of help have fallen on deaf ears.
> >
> > *shrug* I miss Mark Linimon.
> 
> Cheers,
> -- 
> Julian Stacey  http://StolenVotes.UK/jhs/  Arm Ukraine,  Zap Putin.

Just FYI:
Attached is the sh script I've been using for years to apply/revert
multiple patches at once, basically for patches uploaded on bugzilla.

I know it's far from perfect, but maybe handy for casual users who have
any problem with genuine base or ports and needs multiple patches
uploaded on bugzilla, phabricator or anywhere else.

The attachement itself should have been stripped by the ML server,
but maybe you can see it via "Original text of this message" link
at the bottom of the mail archive of this message.

-- 
Tomoaki AOKI
#!/bin/sh
# multipatch: Apply / revert multiple patches at once.
# Copyright (C) Mar. 16, 2017 by Tomoaki AOKI all rights reserved.

IGNORE_OPT="-p"
DRY_OPT="-C"
REV_OPT="-R -E"
DFL_OPT="-i"

OPTION=""

TMPFILE=/tmp/multipatch00

__usage() {
	cat << EOF
Usage: multipatch (-fc | -f | -rc | -r | -h) filename

multipatch: Apply / revert multiple patches listed in filename.
The list file shall list one patchfile per line, lead by ignored depth.

Parameters:
  -r : Revert listed patches.
  -rc: Revert listed patches (dry run).
  -f : Apply listed patches.
  -fc: Apply listed patches (dry run).
  -h: show this help

File format example:
1 ~/LocalPatches/patch1.diff
0 ~/LocalPatches/patch2.patch

where src filenames in patch1.diff is like a/sys/kernel/init_sysent.c
and src filenames in patch2.patch is like sys/amd64/conf/GENERIC

EOF

	exit 0
}

if [ 0 -eq $# ]
then
	__usage
fi

case "$1" in
	"-rc")
		MODE="REVDRY"
		OPTION="${REV_OPT} ${DRY_OPT}"
		;;
	"-r")
		MODE="REV"
		OPTION="${REV_OPT}"
		;;
	"-fc")
		MODE="FWDDRY"
		OPTION="${DRY_OPT}"
		;;
	"-f")
		MODE="FWD"
		OPTION=""
		;;
	"-c")
		MODE="DRY"
		OPTION="${DRY_OPT}"
		;;
	"-h"|"--help")
		__usage
		;;
*)
		__usage
		;;
esac
shift
LSTFILE=$1
echo ${LSTFILE}

if [ -e

Re: 1 year src-patch anniversary!

2023-02-15 Thread Jamie Landeg-Jones 
Warner Losh  wrote:

> Bugzilla is inefficient for small patches.

Yes, I can see that bugzilla is unsuitable for things like that.

> I'm trying an experiment on github: any smallish, almost ready patches will
> be landed, redirected or rejected quickly

Thanks Warner! That sounds great! - I'll be taking you up on that!

Another thing - my last port maintainer update was converted to a phabricator
post, as was the recent patch that delphij committed.

Should I have posted them there instead to save the committers time?
I always thought new phabricator posts were for committers
only, as it seems to me to be a way for committers to get their code
reviewed and passed prior to committing.

Cheers, Jamie

Re: 1 year src-patch anniversary!

2023-02-15 Thread Jamie Landeg-Jones 
"Julian H. Stacey"  wrote:

Firstly, apolgies for the delay in replying.

> I wrote a tool in 1993 I still use
>   http://www.berklix.com/~jhs/bin/.csh/customise
> to apply trees of generic & personal diffs to src & ports, for multi releases
>   http://www.berklix.com/~jhs/src/
> to apply diffs, where some are submitted, some committed
> for some versions, some diffs still needed for older versions, &
> some not submitted or committed.

Thanks, I'll look at that.

> I guess many, especially non-commiters, maintain trees of uncommited
> diffs & there's probably other applicator scripts, numerous
> re-inventing of wheels for decades, 'cos send-pr /
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
> commiters can't keep up with submissions.

Yep :-( And to the committers: I'm not meaning to complain - I know
it's a volunteer effort, but sometimes it can be frustrating.

This particular bug I've highlighted is laughably trivial and inconsequential,
but as Julian says, there must be many people who end up doing
the same thing, and that all adds up to lots of wasted work that
could be better channeled.

What can we do to help?

> FreeBSD hackers(especially non commiters who must wait for commits
> to reduce their heap of candidate diffs) would benefit from a unified
> set of tools & directory formats to allow individuals to maintain
> & export trees of candidate diffs etc to some common standards.
>
> It wouldnt obviate / replace send-pr &
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
> be an optional normalied convenience, especially beneficial to those
> who are Not commiters but who have growing heaps of uncommited patches.
>
> Maybe a summer of code or other person might look at Jamie's & my
> applicator scripts, & diff tree shapes, not for our actual current diffs,
> but to design common unified standards to export trees of candidate diffs
> that can be applied by one common applicator tool ?
>
> Hacker who are not committers presumably accumulate an an ever
> growing heap of diffs, a burden best normalised & automated.

That's a good idea. I'm happy to describe/publish my mechanisms - I've been
meaning to publish all my tools in case they help anyone, but time keeps
getting in the way! As for the patches, it's
quite basic: for src, all patch-files in a common directory-tree (synced to
my machines along with other common directories/tools) are applied
after each git sync. The tree contains directories for "all versions"
patches, and then directories for differing FreeBSD versions.

For ports, I have 3 sets of common patch directories:

1) Patches to the port-templates (i.e. the build files under /usr/ports)
2) Patches to the ports source itself.
3) "Overrides" - directories containing the port-templates for a port
   that are installed after a port-sync. These are usually "deleted"
   ports that I actually still use, local-port hacks that no-one else
   would care about, and less-often complete overrides of ports for
   various reasons.

There is glue code to ensure these are all automatically actioned.

I'd love to get involved with anything that can help streamline this,
whether src or ports.

Cheers, Jamie

Re: 1 year src-patch anniversary!

2023-02-15 Thread Warner Losh 
On Wed, Feb 15, 2023, 7:11 AM Jamie Landeg-Jones  wrote:

> Mateusz Guzik  wrote:
>
> > Well I was not aware of it.
>
> Apologies for the delay in replying. Fair enough you weren't aware, but the
> thing is, how do we make people aware?
>
> If bugs.freebsd.org is no longer the way to go, what's the alternative?
>

Bugzilla is inefficient for small patches.

I'm trying an experiment on github: any smallish, almost ready patches will
be landed, redirected or rejected quickly

Warner

> mail me with git format-patch result and I'll commit.
>
> Thanks! However, in this case, "delphij" has already done it.
>
> Cheers, Jamie
>
>

Re: 1 year src-patch anniversary!

2023-02-15 Thread Jamie Landeg-Jones 
Mateusz Guzik  wrote:

> Well I was not aware of it.

Apologies for the delay in replying. Fair enough you weren't aware, but the
thing is, how do we make people aware?

If bugs.freebsd.org is no longer the way to go, what's the alternative?

> mail me with git format-patch result and I'll commit.

Thanks! However, in this case, "delphij" has already done it.

Cheers, Jamie

Re: 1 year src-patch anniversary!

2023-02-02 Thread Fabian Keil 
Mateusz Guzik  wrote on 2023-01-29 at 23:29:48:

> On 1/29/23, Jamie Landeg-Jones  wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> > to an admittedly trivial issue, but it's soon going to hit one year old,
> > and has not had any feedback. Not even "this is rubbish. close ticket"
> >
> > | jamie@catwalk:~ % stat 'so good they named it twice'
> > | stat: so good they named it twice: stat: No such file or directory
> >
> > As such, it's the oldest of my patches to be completely ignored, but then,
> > most of my fixes I haven't even submitted, because, what's the point?
> > I've instead spent time writing something so the patches are automatically
> > aplied to my src tree, and distributed to all my servers.
> >
> > I know it's a volunteer effort, but I've been here 25 years, and whilst
> > I could (and should) take on more port-maintainership, any other offers
> > of help have fallen on deaf ears.
> >
> 
> Well I was not aware of it.
> 
> mail me with git format-patch result and I'll commit.

Is this an open invitation?

I can easily beat the 1 year anniversary with a couple of
ggate-related patches:


Teaser:
fk@t520 /usr/src $grep "^Reported" 
~/web/www.fabiankeil.de/sourcecode/electrobsd/ElectroBSD-13-f5631983b23-2023.02.02-ggate.diff
 
Reported to security-offi...@freebsd.org on 2014-12-09.
Reported to security-offi...@freebsd.org on 2014-12-09.
Reported to security-offi...@freebsd.org on 2014-12-09.
Reported to security-offi...@freebsd.org on 2014-12-09.
Reported to security-offi...@freebsd.org on 2014-12-09.
Reported to security-offi...@freebsd.org on 2015-04-05.
Reported to security-offi...@freebsd.org on 2015-04-05.
Reported to security-offi...@freebsd.org on 2015-04-05.

The patch set is against stable/13 but I could rebase
on HEAD if there's interest and actual merge conflicts.

Fabian


pgpt_qYb_IBR8.pgp
Description: OpenPGP digital signature

Re: 1 year src-patch anniversary!

2023-01-29 Thread Julian H. Stacey 
Jamie Landeg-Jones wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> to an admittedly trivial issue, but it's soon going to hit one year old,
> and has not had any feedback. Not even "this is rubbish. close ticket"
>
> | jamie@catwalk:~ % stat 'so good they named it twice'
> | stat: so good they named it twice: stat: No such file or directory
>
> As such, it's the oldest of my patches to be completely ignored, but then,
> most of my fixes I haven't even submitted, because, what's the point?
> I've instead spent time writing something so the patches are automatically
> aplied to my src tree, and distributed to all my servers.

I wrote a tool in 1993 I still use
http://www.berklix.com/~jhs/bin/.csh/customise
to apply trees of generic & personal diffs to src & ports, for multi releases
http://www.berklix.com/~jhs/src/
to apply diffs, where some are submitted, some committed
for some versions, some diffs still needed for older versions, &
some not submitted or committed.

I guess many, especially non-commiters, maintain trees of uncommited
diffs & there's probably other applicator scripts, numerous
re-inventing of wheels for decades, 'cos send-pr /
https://bugs.freebsd.org/bugzilla/enter_bug.cgi & volunteer unpaid
commiters can't keep up with submissions.

& non committers can't afford to wait months or years, remembering
what's been seen commited to Release X.Y & what still needs to be
kept to apply to other inc. older releases.  Probably lots of
re-invented wheels: trees of diffs & applicator scripts, but to
different standards, not uniformly exportable, not immediately
familiar to & usable by others.

While retaining the model of "This generic src/ ports/ doc/ tree
has been built from patches blessed by commiters as fit for all"

FreeBSD hackers(especially non commiters who must wait for commits
to reduce their heap of candidate diffs) would benefit from a unified
set of tools & directory formats to allow individuals to maintain
& export trees of candidate diffs etc to some common standards.

It wouldnt obviate / replace send-pr &
https://bugs.freebsd.org/bugzilla/enter_bug.cgi & git etc, but would
be an optional normalied convenience, especially beneficial to those
who are Not commiters but who have growing heaps of uncommited patches.

Maybe a summer of code or other person might look at Jamie's & my
applicator scripts, & diff tree shapes, not for our actual current diffs,
but to design common unified standards to export trees of candidate diffs
that can be applied by one common applicator tool ?

Hacker who are not committers presumably accumulate an an ever
growing heap of diffs, a burden best normalised & automated.

> I know it's a volunteer effort, but I've been here 25 years, and whilst
> I could (and should) take on more port-maintainership, any other offers
> of help have fallen on deaf ears.
>
> *shrug* I miss Mark Linimon.

Cheers,
-- 
Julian Stacey  http://StolenVotes.UK/jhs/  Arm Ukraine,  Zap Putin.

Re: 1 year src-patch anniversary!

2023-01-29 Thread Mateusz Guzik 
On 1/29/23, Mateusz Guzik  wrote:
> On 1/29/23, Jamie Landeg-Jones  wrote:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
>> to an admittedly trivial issue, but it's soon going to hit one year old,
>> and has not had any feedback. Not even "this is rubbish. close ticket"
>>
>> | jamie@catwalk:~ % stat 'so good they named it twice'
>> | stat: so good they named it twice: stat: No such file or directory
>>
>> As such, it's the oldest of my patches to be completely ignored, but
>> then,
>> most of my fixes I haven't even submitted, because, what's the point?
>> I've instead spent time writing something so the patches are
>> automatically
>> aplied to my src tree, and distributed to all my servers.
>>
>> I know it's a volunteer effort, but I've been here 25 years, and whilst
>> I could (and should) take on more port-maintainership, any other offers
>> of help have fallen on deaf ears.
>>
>
> Well I was not aware of it.
>
> mail me with git format-patch result and I'll commit.
>

also make sure the commit message starts with: stat:

-- 
Mateusz Guzik

Re: 1 year src-patch anniversary!

2023-01-29 Thread Mateusz Guzik 
On 1/29/23, Jamie Landeg-Jones  wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
> to an admittedly trivial issue, but it's soon going to hit one year old,
> and has not had any feedback. Not even "this is rubbish. close ticket"
>
> | jamie@catwalk:~ % stat 'so good they named it twice'
> | stat: so good they named it twice: stat: No such file or directory
>
> As such, it's the oldest of my patches to be completely ignored, but then,
> most of my fixes I haven't even submitted, because, what's the point?
> I've instead spent time writing something so the patches are automatically
> aplied to my src tree, and distributed to all my servers.
>
> I know it's a volunteer effort, but I've been here 25 years, and whilst
> I could (and should) take on more port-maintainership, any other offers
> of help have fallen on deaf ears.
>

Well I was not aware of it.

mail me with git format-patch result and I'll commit.

-- 
Mateusz Guzik

1 year src-patch anniversary!

2023-01-29 Thread Jamie Landeg-Jones 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261657 is a trivial fix
to an admittedly trivial issue, but it's soon going to hit one year old,
and has not had any feedback. Not even "this is rubbish. close ticket"

| jamie@catwalk:~ % stat 'so good they named it twice'
| stat: so good they named it twice: stat: No such file or directory

As such, it's the oldest of my patches to be completely ignored, but then,
most of my fixes I haven't even submitted, because, what's the point?
I've instead spent time writing something so the patches are automatically
aplied to my src tree, and distributed to all my servers.

I know it's a volunteer effort, but I've been here 25 years, and whilst
I could (and should) take on more port-maintainership, any other offers
of help have fallen on deaf ears.

*shrug* I miss Mark Linimon.