Re: I've been caught out

[gene heskett]

On Tuesday, January 25, 2022 7:43:10 AM EST Greg Wooledge wrote:
> On Tue, Jan 25, 2022 at 09:12:52AM +0100, Urs Thuermann wrote:
> > Greg Wooledge  writes:
> > > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > > 
> > > That's not how you do it.  patch(1) can only accept one patch at a
> > > time, and it expects to see it on standard input.
> > > 
> > > for p in ../patches/*.patch; do patch -p1 < "$p"; done
> > 
> > You can even do the somewhat easier
> > 
> > cat ../patches/*.patch | patch -p1
> > 
> > which will do the same.
> > 
> > However, often the order of patches is important when some patch
> > depends on another being applied before.  Then *.patch will probably
> > not work since it applies patches in alphabetical order.
> 
> It will work if whoever distributed the patches has half a clue.  Any
> such individual will name the patches with a sortable prefix, like
> 00- 01- 02- .  Or *something* similar, so that the glob returns the
> patches in the correct order.
> 
> If this hasn't been done, then the end user would somehow have to
> deduce the correct order in which to apply the patches.  How an end
> user would guess this is beyond me.
> 
> .
Now, now, all we have to do it learn how to use quilt. So
sudo apt install quilt.

The man page isn't very explicit, other than giving you an ascii graphic 
of the directory tree it expects to run in. But does point you at the 
.pdf site, and after re-reading it several times and putting the 
directory full of unpacked patches where it wants it to be, it got 
simple. The secret is that the patches.xz file when unpacked, contains a 
"series" file as the whole archive was created by quilt in the first 
place. This file gives the order to apply them in.

quilt push

up arrow, hit return, does it one at a time in the correct order until 
its out of patches and complains, or from further reading

quilt push -a

would have done them all in the same order. But I wasn't that brave.

So now the newest, bleeding edge kernel has been built, on the pi running 
uptodate buster, and I've written 2 cards with the raspios release image, 
edited both of those images to add a fallback net config to /etc/
dhcpdp.conf so I stand a small chance of having a working network on the 
first boot, and will hand carry those cards to my rpi4b and test them in 
the next hour or so.

Theoretically, all _I_ should have to do once its booted is open a shell, 
and 

sudo mkdir /mnt/sdb1
sudu mount -text4 /dev/sdb1 /mnt/sdb1
cd to /mnt/sdb1/arm.src/apt-rt.stf/linux
sudo make modules_install dtbs_install install

look to see if it did. and then reboot the pi. In my case, and a reboot 
works, a uname -a should show a v5.16.3-rt kernel is running.

Theoretically... But have a 12 gauge loaded with 00 buck handy in case 
that guy Murphy has snuck around and drunk your last beer. :-(

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: I've been caught out

[tomas]

On Tue, Jan 25, 2022 at 01:33:45PM +0100, Vincent Lefevre wrote:
> On 2022-01-25 09:12:52 +0100, Urs Thuermann wrote:
> > Greg Wooledge  writes:

[...]

> > You can even do the somewhat easier
> > 
> > cat ../patches/*.patch | patch -p1
> > 
> > which will do the same.  
> 
> Even easier (works with zsh, multios enabled, which is the default):
> 
>   patch -p1 < ../patches/*.patch

But exactly that was the original poster's problem. With his shell (most
probably bash) this leads to an "ambiguous redirect". Your zsh does an
implicit cat when it sees multiple files.

> > However, often the order of patches is important when some patch
> > depends on another being applied before.  Then *.patch will probably
> > not work since it applies patches in alphabetical order.
> 
> Sometimes patch names are prepended with a number with a fixed number
> of digits (e.g., 3) to make sure that this works.

Yes, this is an independent issue. The OP's patches (at least one of
them, but we do induction :) are prepended by leading-zero four-digit
numbers, so assuming they are intended to be ordered by that seems low
risk ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: I've been caught out

[Greg Wooledge]

On Tue, Jan 25, 2022 at 09:12:52AM +0100, Urs Thuermann wrote:
> Greg Wooledge  writes:
> 
> > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > 
> > That's not how you do it.  patch(1) can only accept one patch at a time,
> > and it expects to see it on standard input.
> > 
> > for p in ../patches/*.patch; do patch -p1 < "$p"; done
> 
> You can even do the somewhat easier
> 
> cat ../patches/*.patch | patch -p1
> 
> which will do the same.  
> 
> However, often the order of patches is important when some patch
> depends on another being applied before.  Then *.patch will probably
> not work since it applies patches in alphabetical order.

It will work if whoever distributed the patches has half a clue.  Any
such individual will name the patches with a sortable prefix, like
00- 01- 02- .  Or *something* similar, so that the glob returns the
patches in the correct order.

If this hasn't been done, then the end user would somehow have to deduce
the correct order in which to apply the patches.  How an end user would
guess this is beyond me.

Re: I've been caught out

[Vincent Lefevre]

On 2022-01-25 09:12:52 +0100, Urs Thuermann wrote:
> Greg Wooledge  writes:
> > On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > 
> > That's not how you do it.  patch(1) can only accept one patch at a time,
> > and it expects to see it on standard input.
> > 
> > for p in ../patches/*.patch; do patch -p1 < "$p"; done
> 
> You can even do the somewhat easier
> 
> cat ../patches/*.patch | patch -p1
> 
> which will do the same.  

Even easier (works with zsh, multios enabled, which is the default):

  patch -p1 < ../patches/*.patch

> However, often the order of patches is important when some patch
> depends on another being applied before.  Then *.patch will probably
> not work since it applies patches in alphabetical order.

Sometimes patch names are prepended with a number with a fixed number
of digits (e.g., 3) to make sure that this works.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: I've been caught out

[Urs Thuermann]

Greg Wooledge  writes:

> On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> 
> That's not how you do it.  patch(1) can only accept one patch at a time,
> and it expects to see it on standard input.
> 
> for p in ../patches/*.patch; do patch -p1 < "$p"; done

You can even do the somewhat easier

cat ../patches/*.patch | patch -p1

which will do the same.  

However, often the order of patches is important when some patch
depends on another being applied before.  Then *.patch will probably
not work since it applies patches in alphabetical order.  That's, why
I also like to work with quilt a lot.  With quilt, the patches/series
file describes the patch series, i.e. the order in which patches have
to be applied.  With "quilt push" and "quilt pop" you can apply and
remove single patches, or go to a specific patch with "quilt push
" (or "quilt pop "), or apply/remove all patches with
"quilt push -a" and "quilt pop -a".  Always in the correct order.

urs

Re: I've been caught out

[gene heskett]

On Monday, January 24, 2022 6:19:24 AM EST to...@tuxteam.de wrote:
> On Mon, Jan 24, 2022 at 06:08:57AM -0500, gene heskett wrote:
> > On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:
> > > Hi,
> > > 
> > > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > > > patch:
> > > > ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > > > PREEMPT.patch: extra operand
> > > 
> > > man patch says
> > > 
> > >patch [options] [originalfile [patchfile]]
> > > 
> > > With "patchfile" being singular i'd expect that it refuses if you
> > > give
> > > more than one.
> > > Further it does not look as if you give an "originalfile", which is
> > > demanded by the common []-bracket around "originalfile
> > > [patchfile]".
> > > 
> > > So what file do you want to change by the patch ?
> > > Does ../patches/*.patch evaluate to a single file ?
> > 
> > No, its a directory with many patches. IMO patch should take them, in
> > their sorted order, until its out of patches.
> 
> The man page disagrees with you on that, as Thomas notes :)
> 
> >Or do we have a gui to
> > 
> > oversee that, something like kompare maybe? I'll take a look.
> 
> See my other answer for a quick-and-dirty proposal. There are several
> patch managers around which help you on that -- quilt is one of them.
> 

And once I had wrapped my brain around quilt, it just worked, the result 
is building right now. Thanks a bunch.

> Cheers
Take care Thomas.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: I've been caught out

[tomas]

On Mon, Jan 24, 2022 at 03:15:17PM -0500, gene heskett wrote:

[...]

> And that might be the magic twanger, thank you Thomas. I'm finding it 
> harder and harder to think 'outside the box'.

very glad if some of my wall of text helps :)

take care
-- 
tomás


signature.asc
Description: PGP signature

Re: I've been caught out

[gene heskett]

On Monday, January 24, 2022 5:27:45 AM EST to...@tuxteam.de wrote:
> On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> > Greetings all;
> > 
> > I must admit its been quite a few years since the last time I used
> > patch. Basck in the early 90's when the amiga was king in the
> > graphic arts. And it then had a syntax of 'patch -p1 <
> > path/to/patchfile'
> > But now I have a ../patch directory with 50 or so files in it, and
> > patch is spanking me, starting with an ambiguous redirect if the <
> > is used,
> This ain't patch. This is the shell. If you do
> 
>   foo < file
> 
> ... then it's the shell's job to present file's content to foo on
> stdin. Foo doesn't even get to see file "as a file on your file
> system", just its content. Doing
> 
>   foo < file1 file2 file3...
> 
> will lead the shell to present the complaint above.
> 
> This might seem like superfluous nitpicking, but you won't understand
> what's going on unless you know that.
> 
> > And while it finds the patch file without it, its reporting an extra
> > operand. So whats todays syntax for a ../dir full of patches?
> 
> Now if you go to the patch man page (I know, I know :) you'll see that
> patch can take /the/ patch file either on stdin or as an optional
> second argument, instead of taking stdin. I emphasised /the/, because,
> according to the man page, it doesn't expect more than one. So that
> might be the extra operand complaint you are seeing...
> 
> > Example:
> > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > PREEMPT.patch: extra operand
> 
> Yes, that's it: the expression "../patches/*.patch" gets expanded by
> the shell to "../patches/foo.patch ../patches/bar.patch ..." and so
> on, so your little /usr/bin/patch gets so see this long list of args.
> No good.
> > And the man page doesn't address the 'extra operand' error.
> 
> Indirectly, yes:
> 
>   SYNOPSIS
>patch [options] [originalfile [patchfile]]
>but usually just
>patch -pnum  
> ...means it takes options, optionally an orig file name, and only then,
> optionally a patch file name (so if you want to provide the patch file
> name, you /have/ to provide the original file name, it seems).
> 
> Conclusion: you have to arrange for all those patches to be applied one
> after the other, in some order. Guessing from your first one, they are
> prefixed by a number, so that is most probably the one encoding that
> order.
> 
> You could try doing something along the lines of
> 
>   for f in ../patches/*.patch ; do
> patch -p1 < "$f"
>   done
> 
> Or you could have a look into quilt, which is supposed to automate such
> things.
> 
And that might be the magic twanger, thank you Thomas. I'm finding it 
harder and harder to think 'outside the box'.
> Cheers


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: I've been caught out

[Greg Wooledge]

On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch

That's not how you do it.  patch(1) can only accept one patch at a time,
and it expects to see it on standard input.

for p in ../patches/*.patch; do patch -p1 < "$p"; done

Re: I've been caught out

[Mark Allums]

On 1/24/22 05:08, gene heskett wrote:

On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:

Hi,


gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
PREEMPT.patch: extra operand


man patch says

patch [options] [originalfile [patchfile]]

With "patchfile" being singular i'd expect that it refuses if you give
more than one.
Further it does not look as if you give an "originalfile", which is
demanded by the common []-bracket around "originalfile [patchfile]".

So what file do you want to change by the patch ?
Does ../patches/*.patch evaluate to a single file ?


No, its a directory with many patches. IMO patch should take them, in
their sorted order, until its out of patches. Or do we have a gui to
oversee that, something like kompare maybe? I'll take a look.


(I get that error if i give three dummy file arguments.
  If i give two i get a lot of "Hunk ... FAILED at .." because my second
file is no properly formatted patch.
  If i give one, the program waits for standard input.)


Have a nice day :)

Thomas


Thanks Thomas, stay well now.

.



Cheers, Gene Heskett.



There exist tools for this.  What about quilt?

Mark A.

Re: I've been caught out

[Thomas Schmitt]

Hi,

gene heskett wrote:
> > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch

I wrote:
> > Does ../patches/*.patch evaluate to a single file ?

gene heskett wrote:
> No, its a directory with many patches.

So you effectively ran something like

  patch -p1  ../patches/abc.patch ../patches/bla.patch [maybe more] 
../patches/.patch

This does not match any of the use cases in the man page.

At most two file paths are expected with:

   patch [options] [originalfile [patchfile]]

No file path at all is expected by

   patch -pnum  IMO patch should take them, in
> their sorted order, until its out of patches.

That would be possible with the first use case. But there the developers
obviously decided to accept only a single patch file.
Well, you don't want this use case anyways. (Because you have no single
originalfile to give as argument before the .patch files.)


The shell offers means to create a workaround. Try:

  for i in ../patches/*.patch ; do patch <"$i" ; done

The for-do-done loop will run patch separately for each of your .patch
files.


Have a nice day :)

Thomas

Re: I've been caught out

[tomas]

On Mon, Jan 24, 2022 at 06:08:57AM -0500, gene heskett wrote:
> On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:
> > Hi,
> > 
> > > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > > PREEMPT.patch: extra operand
> > 
> > man patch says
> > 
> >patch [options] [originalfile [patchfile]]
> > 
> > With "patchfile" being singular i'd expect that it refuses if you give
> > more than one.
> > Further it does not look as if you give an "originalfile", which is
> > demanded by the common []-bracket around "originalfile [patchfile]".
> > 
> > So what file do you want to change by the patch ?
> > Does ../patches/*.patch evaluate to a single file ?
> > 
> No, its a directory with many patches. IMO patch should take them, in 
> their sorted order, until its out of patches.

The man page disagrees with you on that, as Thomas notes :)

>Or do we have a gui to 
> oversee that, something like kompare maybe? I'll take a look.

See my other answer for a quick-and-dirty proposal. There are several
patch managers around which help you on that -- quilt is one of them.

Cheers
-- 
tomás


signature.asc
Description: PGP signature

Re: I've been caught out

[gene heskett]

On Monday, January 24, 2022 5:19:13 AM EST Thomas Schmitt wrote:
> Hi,
> 
> > gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> > patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> > PREEMPT.patch: extra operand
> 
> man patch says
> 
>patch [options] [originalfile [patchfile]]
> 
> With "patchfile" being singular i'd expect that it refuses if you give
> more than one.
> Further it does not look as if you give an "originalfile", which is
> demanded by the common []-bracket around "originalfile [patchfile]".
> 
> So what file do you want to change by the patch ?
> Does ../patches/*.patch evaluate to a single file ?
> 
No, its a directory with many patches. IMO patch should take them, in 
their sorted order, until its out of patches. Or do we have a gui to 
oversee that, something like kompare maybe? I'll take a look.

> (I get that error if i give three dummy file arguments.
>  If i give two i get a lot of "Hunk ... FAILED at .." because my second
> file is no properly formatted patch.
>  If i give one, the program waits for standard input.)
> 
> 
> Have a nice day :)
> 
> Thomas
> 
Thanks Thomas, stay well now.
> .


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: I've been caught out

[tomas]

On Mon, Jan 24, 2022 at 05:01:21AM -0500, gene heskett wrote:
> Greetings all;
> 
> I must admit its been quite a few years since the last time I used patch.
> Basck in the early 90's when the amiga was king in the graphic arts.
> And it then had a syntax of 'patch -p1 < path/to/patchfile'
> But now I have a ../patch directory with 50 or so files in it, and patch 
> is spanking me, starting with an ambiguous redirect if the < is used,  

This ain't patch. This is the shell. If you do

  foo < file

... then it's the shell's job to present file's content to foo on stdin.
Foo doesn't even get to see file "as a file on your file system", just
its content. Doing

  foo < file1 file2 file3...

will lead the shell to present the complaint above.

This might seem like superfluous nitpicking, but you won't understand
what's going on unless you know that.

> And while it finds the patch file without it, its reporting an extra 
> operand. So whats todays syntax for a ../dir full of patches?

Now if you go to the patch man page (I know, I know :) you'll see that
patch can take /the/ patch file either on stdin or as an optional second
argument, instead of taking stdin. I emphasised /the/, because, according
to the man page, it doesn't expect more than one. So that might be the
extra operand complaint you are seeing...

> Example:
> gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> PREEMPT.patch: extra operand

Yes, that's it: the expression "../patches/*.patch" gets expanded by the
shell to "../patches/foo.patch ../patches/bar.patch ..." and so on, so
your little /usr/bin/patch gets so see this long list of args. No good.

> And the man page doesn't address the 'extra operand' error.

Indirectly, yes:

  SYNOPSIS
   patch [options] [originalfile [patchfile]]
   but usually just
   patch -pnum 

signature.asc
Description: PGP signature

Re: I've been caught out

[Thomas Schmitt]

Hi,

> gene@coyote:~/Debian-arm/linux$ patch -p1  ../patches/*.patch
> patch: ../patches/0001-mm-memcg-Disable-threshold-event-handlers-on-
> PREEMPT.patch: extra operand

man patch says

   patch [options] [originalfile [patchfile]]

With "patchfile" being singular i'd expect that it refuses if you give
more than one.
Further it does not look as if you give an "originalfile", which is demanded
by the common []-bracket around "originalfile [patchfile]".

So what file do you want to change by the patch ?
Does ../patches/*.patch evaluate to a single file ?

(I get that error if i give three dummy file arguments.
 If i give two i get a lot of "Hunk ... FAILED at .." because my second
 file is no properly formatted patch.
 If i give one, the program waits for standard input.)


Have a nice day :)

Thomas