Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Tue, 10 Jan 2023, Petr Štetiar wrote:
Date: Tue, 10 Jan 2023 10:08:51
From: Petr Štetiar
To: Brian Norris
Cc: Christian Marangi , Thibaut ,
Robert Marko , openwrt-devel@lists.openwrt.org,
Jo-Philipp Wich
Subject: Re: [PATCH v2 6/7] coreutils: Import from packages feed
Brian Norris [2023-01-09 11:51:53]:
For my use, it feels like a simplified form (which only needs to be a
stdin/stdout pipeline) would be pretty easy to inline into the
caldata/firmware-loader script:
ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
from my past experience, such oneliners usually endup in a hard to maintain
copy mess between targets/scripts, thus my initial idea was to simply
ship it for the start as target/linux/ipq806x/base-files/usr/bin/b64decode.uc,
thus allowing following usage:
- base64 -d "$source" > "$target_dir/data"
+ b64decode.uc "$source" > "$target_dir/data"
Once such decoding is needed in other parts/targets, we would simply just move
the script into target/linux/generic/base-files/usr/bin/b64decode.uc and call
it a day.
+1
Enrico
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Brian Norris [2023-01-09 11:51:53]:
> For my use, it feels like a simplified form (which only needs to be a
> stdin/stdout pipeline) would be pretty easy to inline into the
> caldata/firmware-loader script:
>
> ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
from my past experience, such oneliners usually endup in a hard to maintain
copy mess between targets/scripts, thus my initial idea was to simply
ship it for the start as target/linux/ipq806x/base-files/usr/bin/b64decode.uc,
thus allowing following usage:
- base64 -d "$source" > "$target_dir/data"
+ b64decode.uc "$source" > "$target_dir/data"
Once such decoding is needed in other parts/targets, we would simply just move
the script into target/linux/generic/base-files/usr/bin/b64decode.uc and call
it a day.
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 12:23:25PM -0800, Brian Norris wrote:
> On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi
> wrote:
> > On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > > For my use, it feels like a simplified form (which only needs to be a
> > > stdin/stdout pipeline) would be pretty easy to inline into the
> > > caldata/firmware-loader script:
> > >
> > > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> > >
> >
> > Ok a single line solution will be ideal and easy to include in the
> > hotplug script.
>
> Sounds good.
>
> > > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > > luci and fw4? In theory it should be always present or as a safe thing
> > > > we should add ucode in the required packages for this target?
> > >
> > > So far I don't find it as a strict core dependency, but just happens
> > > to be available by default due to dependencies. I guess similar
> > > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> > >
> >
> > If it's not a strict core dependency I would just put ucode as a
> > dependency for the needed devices and be done with it. It's not a low
> > space target and ucode is not that big and for sure smaller than lua,
> > openssl and easier to implement than moving coreutils from feeds to
> > core.
>
> Sounds good to me.
>
> Thanks all for the help.
>
> > Think with v3 and this implemented the series is ready.
>
> Great! Unfortunately, I'm still dependent on an outstanding patch for
> the fstools project:
> https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/
> See also patch 7's notes.
>
> I guess I could revert to the 2-partition layout (which does not
> depend on the fstools change) for the time being, so snapshots would
> work. I'm still trying to figure out what the best partitioning and
> syupgrade strategy is best for disk space flexibility and for
> reliability (e.g., not clobbering rootfs_data when it's appended to
> rootfs) on block devices...
>
We have way to make old image not compatible with partition change and
stuff so migrating to a new implementation in the future won't be that
problematic.
But it would be good if we can sort it out before... Need to check that
fstool patch better and see if something can be done.
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 9, 2023 at 11:56 AM Christian Marangi wrote:
> On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> > For my use, it feels like a simplified form (which only needs to be a
> > stdin/stdout pipeline) would be pretty easy to inline into the
> > caldata/firmware-loader script:
> >
> > ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> >
>
> Ok a single line solution will be ideal and easy to include in the
> hotplug script.
Sounds good.
> > > 2. Ucode is part of the core packages? Or an optional dependency for
> > > luci and fw4? In theory it should be always present or as a safe thing
> > > we should add ucode in the required packages for this target?
> >
> > So far I don't find it as a strict core dependency, but just happens
> > to be available by default due to dependencies. I guess similar
> > questions to the busybox, coreutils, etc., stuff -- whether we're OK
> > with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
> >
>
> If it's not a strict core dependency I would just put ucode as a
> dependency for the needed devices and be done with it. It's not a low
> space target and ucode is not that big and for sure smaller than lua,
> openssl and easier to implement than moving coreutils from feeds to
> core.
Sounds good to me.
Thanks all for the help.
> Think with v3 and this implemented the series is ready.
Great! Unfortunately, I'm still dependent on an outstanding patch for
the fstools project:
https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/
See also patch 7's notes.
I guess I could revert to the 2-partition layout (which does not
depend on the fstools change) for the time being, so snapshots would
work. I'm still trying to figure out what the best partitioning and
syupgrade strategy is best for disk space flexibility and for
reliability (e.g., not clobbering rootfs_data when it's appended to
rootfs) on block devices...
Brian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 11:51:53AM -0800, Brian Norris wrote:
> On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi
> wrote:
> >
> > On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> > > Petr Štetiar [2023-01-09 11:50:37]:
> > >
> > > Hi,
> > >
> > > > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> > > >
> > > > 1. https://github.com/jow-/ucode#663-b64decstr
> > >
> > > wanted to refresh my ucode brain cells, so I've explored feasibility of
> > > that
> > > suggestion and it seems to work just fine:
> > >
> > > #!/usr/bin/ucode
> > >
> > > import { stdin, open, error } from 'fs';
> > >
> > > if (length(ARGV) == 0 && stdin.isatty()) {
> > > warn("usage: b64decode [stdin|path]\n");
> > > exit(1);
> > > }
> > >
> > > let fp = stdin;
> > > let source = ARGV[0];
> > >
> > > if (source) {
> > > fp = open(source);
> > > if (!fp) {
> > > warn(`b64decode: unable to open ${source}:
> > > ${error()}\n`);
> > > exit(1);
> > > }
> > > }
> > >
> > > print(b64dec(fp.read("all")));
> > > fp.close();
> > > exit(0);
> > >
> > > BTW it needs recent ucode with fs.stdin.isatty() support[1].
> > >
> > > Thanks Jo for helping me making above script more idiomatic. IMO it looks
> > > more
> > > human readable, portable and maintanable then that awk based solution.
> > >
> > > 1.
> > > https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
>
> I sidestepped the isatty() stuff (below), and this works for me too.
>
> > Thanks for helping with this. I really like the ucode way. Just a few
> > question:
> > 1. How this should be handled? A script that the target will provide?
> > Part of a common function?
>
> For my use, it feels like a simplified form (which only needs to be a
> stdin/stdout pipeline) would be pretty easy to inline into the
> caldata/firmware-loader script:
>
> ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
>
Ok a single line solution will be ideal and easy to include in the
hotplug script.
> > 2. Ucode is part of the core packages? Or an optional dependency for
> > luci and fw4? In theory it should be always present or as a safe thing
> > we should add ucode in the required packages for this target?
>
> So far I don't find it as a strict core dependency, but just happens
> to be available by default due to dependencies. I guess similar
> questions to the busybox, coreutils, etc., stuff -- whether we're OK
> with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
>
If it's not a strict core dependency I would just put ucode as a
dependency for the needed devices and be done with it. It's not a low
space target and ucode is not that big and for sure smaller than lua,
openssl and easier to implement than moving coreutils from feeds to
core.
Think with v3 and this implemented the series is ready.
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 9, 2023 at 11:21 AM Christian Marangi wrote:
>
> On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> > Petr Štetiar [2023-01-09 11:50:37]:
> >
> > Hi,
> >
> > > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> > >
> > > 1. https://github.com/jow-/ucode#663-b64decstr
> >
> > wanted to refresh my ucode brain cells, so I've explored feasibility of that
> > suggestion and it seems to work just fine:
> >
> > #!/usr/bin/ucode
> >
> > import { stdin, open, error } from 'fs';
> >
> > if (length(ARGV) == 0 && stdin.isatty()) {
> > warn("usage: b64decode [stdin|path]\n");
> > exit(1);
> > }
> >
> > let fp = stdin;
> > let source = ARGV[0];
> >
> > if (source) {
> > fp = open(source);
> > if (!fp) {
> > warn(`b64decode: unable to open ${source}:
> > ${error()}\n`);
> > exit(1);
> > }
> > }
> >
> > print(b64dec(fp.read("all")));
> > fp.close();
> > exit(0);
> >
> > BTW it needs recent ucode with fs.stdin.isatty() support[1].
> >
> > Thanks Jo for helping me making above script more idiomatic. IMO it looks
> > more
> > human readable, portable and maintanable then that awk based solution.
> >
> > 1.
> > https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
I sidestepped the isatty() stuff (below), and this works for me too.
> Thanks for helping with this. I really like the ucode way. Just a few
> question:
> 1. How this should be handled? A script that the target will provide?
> Part of a common function?
For my use, it feels like a simplified form (which only needs to be a
stdin/stdout pipeline) would be pretty easy to inline into the
caldata/firmware-loader script:
ucode -e 'import { stdin } from "fs"; print(b64dec(stdin.read("all")));'
> 2. Ucode is part of the core packages? Or an optional dependency for
> luci and fw4? In theory it should be always present or as a safe thing
> we should add ucode in the required packages for this target?
So far I don't find it as a strict core dependency, but just happens
to be available by default due to dependencies. I guess similar
questions to the busybox, coreutils, etc., stuff -- whether we're OK
with forcing 'ucode' as a per-target dependency / DEVICE_PACKAGES.
Brian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Mon, Jan 09, 2023 at 03:35:56PM +0100, Petr Štetiar wrote:
> Petr Štetiar [2023-01-09 11:50:37]:
>
> Hi,
>
> > BTW ucode has `b64dec()`[1] so perhaps another viable option.
> >
> > 1. https://github.com/jow-/ucode#663-b64decstr
>
> wanted to refresh my ucode brain cells, so I've explored feasibility of that
> suggestion and it seems to work just fine:
>
> #!/usr/bin/ucode
>
> import { stdin, open, error } from 'fs';
>
> if (length(ARGV) == 0 && stdin.isatty()) {
> warn("usage: b64decode [stdin|path]\n");
> exit(1);
> }
>
> let fp = stdin;
> let source = ARGV[0];
>
> if (source) {
> fp = open(source);
> if (!fp) {
> warn(`b64decode: unable to open ${source}:
> ${error()}\n`);
> exit(1);
> }
> }
>
> print(b64dec(fp.read("all")));
> fp.close();
> exit(0);
>
> BTW it needs recent ucode with fs.stdin.isatty() support[1].
>
> Thanks Jo for helping me making above script more idiomatic. IMO it looks more
> human readable, portable and maintanable then that awk based solution.
>
> 1.
> https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
>
Thanks for helping with this. I really like the ucode way. Just a few
question:
1. How this should be handled? A script that the target will provide?
Part of a common function?
2. Ucode is part of the core packages? Or an optional dependency for
luci and fw4? In theory it should be always present or as a safe thing
we should add ucode in the required packages for this target?
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Petr Štetiar [2023-01-09 11:50:37]:
Hi,
> BTW ucode has `b64dec()`[1] so perhaps another viable option.
>
> 1. https://github.com/jow-/ucode#663-b64decstr
wanted to refresh my ucode brain cells, so I've explored feasibility of that
suggestion and it seems to work just fine:
#!/usr/bin/ucode
import { stdin, open, error } from 'fs';
if (length(ARGV) == 0 && stdin.isatty()) {
warn("usage: b64decode [stdin|path]\n");
exit(1);
}
let fp = stdin;
let source = ARGV[0];
if (source) {
fp = open(source);
if (!fp) {
warn(`b64decode: unable to open ${source}:
${error()}\n`);
exit(1);
}
}
print(b64dec(fp.read("all")));
fp.close();
exit(0);
BTW it needs recent ucode with fs.stdin.isatty() support[1].
Thanks Jo for helping me making above script more idiomatic. IMO it looks more
human readable, portable and maintanable then that awk based solution.
1. https://github.com/jow-/ucode/commit/be30472bfdbbb410e8934b48a56d26c5c630d0f1
Cheers,
Petr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Thibaut [2023-01-08 00:02:06]: > There might be an even easier/lighter way (short of enabling base64 in > busybox), AWK to the rescue: > https://github.com/shane-kerr/AWK-base64decode > > The code is clean and judging by the comment line 97, works with busybox awk. BTW ucode has `b64dec()`[1] so perhaps another viable option. 1. https://github.com/jow-/ucode#663-b64decstr Thibaut [2023-01-08 22:37:20]: > I wonder if it’s such a good idea to have discrepancies in busybox features > between targets? You're right, it's not a good idea. Brian Norris [2023-01-08 19:09:33]: > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. It works for me as well, but it's going to break some cases I've missed. Sorry for the noise. Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 9 janv. 2023 à 04:09, Brian Norris a écrit : > > On Sun, Jan 8, 2023 at 1:37 PM Thibaut wrote: >>> Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : >>> >>> On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: […] include $(INCLUDE_DIR)/target.mk + +DEPENDS:= \ + +@BUSYBOX_DEFAULT_BASE64 + > > Thanks! That does indeed work for me. And I might just throw it into > target/linux/ipq806x/chromium/target.mk instead, since the generic > target won't be using base64. I believe that won’t work, see below. >>> Is this already used for other target? Wonder if this special thing >>> would cause some problem for packages of this target? Like discrepancy >>> with stage2 and final image? > > stage2 as in sysupgrade? I don't immediately see how that would be a > problem, but maybe I'm not understanding well enough. Packages are built on architecture-basis by a separate set of builders (« phase2 »). For ipq806x, that’s arm_cortex-a15_neon-vfpv4. While adjusting this tunable will have an effect on phase1 builds (images) and local builds from source, my understanding is it won’t affect the global architecture setting, meaning that the busybox package that’s built by the « phase2 » builders will not have this knob enabled. Thus, anyone building from imagebuilder or updating busybox from the package repo will get a version without base64, and this will break. >> AFAICT this isn’t used anywhere so far (at least according to a quick git >> grep). > > Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in > the current tree or in the git history. > > And I can't even find anyone doing a bare 'DEPENDS:=' in their > Makefile under target/linux/ at all. All usages are as part of > packages (modules), not device/target specifications. Most likely because of the above, which is why I’m not convinced it’s such a good idea to « set this precedent ». >>> Anyway this looks to be the best solution for the problem. >> >> I wonder if it’s such a good idea to have discrepancies in busybox features >> between targets? > > I don't think I know enough about OpenWrt development yet to have a > good answer on this, so I'll let you all try to answer this. Regardless of the above, I think these types of features (core utils that are typically used in scripts) should be enabled/disabled tree wide: otherwise, a user building a script which uses any of these features will have the « surprise » that it doesn’t work consistently on all devices, and that IMHO is bad. My 2c. T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Sun, Jan 8, 2023 at 1:37 PM Thibaut wrote: > > Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : > > > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: > >> Brian Norris [2023-01-06 23:49:44]: > >> > >> Hi Brian, > >> > >>> I need to express a per-target dependency on the 'base64' utility, and > >>> that's seemingly impossible to do for busybox. > >> > >> --- a/target/linux/ipq806x/Makefile > >> +++ b/target/linux/ipq806x/Makefile > >> @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 > >> KERNELNAME:=zImage Image dtbs > >> > >> include $(INCLUDE_DIR)/target.mk > >> + > >> +DEPENDS:= \ > >> + +@BUSYBOX_DEFAULT_BASE64 > >> + Thanks! That does indeed work for me. And I might just throw it into target/linux/ipq806x/chromium/target.mk instead, since the generic target won't be using base64. > > Is this already used for other target? Wonder if this special thing > > would cause some problem for packages of this target? Like discrepancy > > with stage2 and final image? stage2 as in sysupgrade? I don't immediately see how that would be a problem, but maybe I'm not understanding well enough. > AFAICT this isn’t used anywhere so far (at least according to a quick git > grep). Right, I couldn't find any other target tweaking BUSYBOX_DEFAULT_* in the current tree or in the git history. And I can't even find anyone doing a bare 'DEPENDS:=' in their Makefile under target/linux/ at all. All usages are as part of packages (modules), not device/target specifications. > > Anyway this looks to be the best solution for the problem. > > I wonder if it’s such a good idea to have discrepancies in busybox features > between targets? I don't think I know enough about OpenWrt development yet to have a good answer on this, so I'll let you all try to answer this. But if I don't hear some specific negatives or some other consensus within a day or few, I'll try BUSYBOX_DEFAULT_BASE64 for a v3. Of course, I can also hold off sending if people were actively looking at the other parts of this series still. Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 8 janv. 2023 à 21:53, Christian Marangi a écrit : > > On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: >> Brian Norris [2023-01-06 23:49:44]: >> >> Hi Brian, >> >>> I need to express a per-target dependency on the 'base64' utility, and >>> that's seemingly impossible to do for busybox. >> >> --- a/target/linux/ipq806x/Makefile >> +++ b/target/linux/ipq806x/Makefile >> @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 >> KERNELNAME:=zImage Image dtbs >> >> include $(INCLUDE_DIR)/target.mk >> + >> +DEPENDS:= \ >> + +@BUSYBOX_DEFAULT_BASE64 >> + >> > > Is this already used for other target? Wonder if this special thing > would cause some problem for packages of this target? Like discrepancy > with stage2 and final image? AFAICT this isn’t used anywhere so far (at least according to a quick git grep). > Anyway this looks to be the best solution for the problem. I wonder if it’s such a good idea to have discrepancies in busybox features between targets? T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Sun, Jan 08, 2023 at 09:00:58PM +0100, Petr Štetiar wrote: > Brian Norris [2023-01-06 23:49:44]: > > Hi Brian, > > > I need to express a per-target dependency on the 'base64' utility, and > > that's seemingly impossible to do for busybox. > > --- a/target/linux/ipq806x/Makefile > +++ b/target/linux/ipq806x/Makefile > @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 >KERNELNAME:=zImage Image dtbs > >include $(INCLUDE_DIR)/target.mk > + > +DEPENDS:= \ > + +@BUSYBOX_DEFAULT_BASE64 > + > Is this already used for other target? Wonder if this special thing would cause some problem for packages of this target? Like discrepancy with stage2 and final image? Anyway this looks to be the best solution for the problem. -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
Brian Norris [2023-01-06 23:49:44]: Hi Brian, > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. --- a/target/linux/ipq806x/Makefile +++ b/target/linux/ipq806x/Makefile @@ -15,6 +15,11 @@ KERNEL_PATCHVER:=5.15 KERNELNAME:=zImage Image dtbs include $(INCLUDE_DIR)/target.mk + +DEPENDS:= \ + +@BUSYBOX_DEFAULT_BASE64 + Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On 08.01.2023 00:02, Thibaut wrote: Le 7 janv. 2023 à 22:41, Robert Marko a écrit : On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: I need to express a per-target dependency on the 'base64' utility, and that's seemingly impossible to do for busybox. Pull in coreutils to make that easier. Signed-off-by: Brian Norris We still need to think of a correct solution for this... coreutils is an option but wonder if a better one is openssl... Actually we have a small tool to handle specific decryption of some stuff... Wonder if that can be expanded for this task and just use wolfssl or openssl api to decode base64 stuff? Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils is a better option for sure. There might be an even easier/lighter way (short of enabling base64 in busybox), AWK to the rescue: https://github.com/shane-kerr/AWK-base64decode The code is clean and judging by the comment line 97, works with busybox awk. how is luci doing base64 en/decoding? that should be available in default images. if it's using lua, that should be available in every image even without web-interface or? ..ede ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 7 janv. 2023 à 22:41, Robert Marko a écrit : > > On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: >> >> >> >>> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : >>> >>> On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >>>> I need to express a per-target dependency on the 'base64' utility, and >>>> that's seemingly impossible to do for busybox. Pull in coreutils to make >>>> that easier. >>>> >>>> Signed-off-by: Brian Norris >>> >>> We still need to think of a correct solution for this... coreutils is an >>> option but wonder if a better one is openssl... Actually we have a small >>> tool to handle specific decryption of some stuff... Wonder if that can >>> be expanded for this task and just use wolfssl or openssl api to decode >>> base64 stuff? >> >> Using one or the other would impose (i.e. (en)force) that SSL library on >> this particular target. Do we want this, especially considering the ongoing >> conversation about mbedTLS? >> >> Also pulling an entire SSL implementation just to decode base64 seems a tad >> overkill too. > > I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils > is a better option for sure. There might be an even easier/lighter way (short of enabling base64 in busybox), AWK to the rescue: https://github.com/shane-kerr/AWK-base64decode The code is clean and judging by the comment line 97, works with busybox awk. HTH T ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Sat, 7 Jan 2023 at 16:26, Thibaut VARÈNE wrote: > > > > > Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > >> I need to express a per-target dependency on the 'base64' utility, and > >> that's seemingly impossible to do for busybox. Pull in coreutils to make > >> that easier. > >> > >> Signed-off-by: Brian Norris > > > > We still need to think of a correct solution for this... coreutils is an > > option but wonder if a better one is openssl... Actually we have a small > > tool to handle specific decryption of some stuff... Wonder if that can > > be expanded for this task and just use wolfssl or openssl api to decode > > base64 stuff? > > Using one or the other would impose (i.e. (en)force) that SSL library on this > particular target. Do we want this, especially considering the ongoing > conversation about mbedTLS? > > Also pulling an entire SSL implementation just to decode base64 seems a tad > overkill too. I agree on this one, forcing usage of OpenSSL isn't ideal, coreutils is a better option for sure. Regards, Robert > > HTH > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
> Le 7 janv. 2023 à 15:06, Christian Marangi a écrit : > > On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: >> I need to express a per-target dependency on the 'base64' utility, and >> that's seemingly impossible to do for busybox. Pull in coreutils to make >> that easier. >> >> Signed-off-by: Brian Norris > > We still need to think of a correct solution for this... coreutils is an > option but wonder if a better one is openssl... Actually we have a small > tool to handle specific decryption of some stuff... Wonder if that can > be expanded for this task and just use wolfssl or openssl api to decode > base64 stuff? Using one or the other would impose (i.e. (en)force) that SSL library on this particular target. Do we want this, especially considering the ongoing conversation about mbedTLS? Also pulling an entire SSL implementation just to decode base64 seems a tad overkill too. HTH ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 6/7] coreutils: Import from packages feed
On Fri, Jan 06, 2023 at 11:49:44PM -0800, Brian Norris wrote: > I need to express a per-target dependency on the 'base64' utility, and > that's seemingly impossible to do for busybox. Pull in coreutils to make > that easier. > > Signed-off-by: Brian Norris We still need to think of a correct solution for this... coreutils is an option but wonder if a better one is openssl... Actually we have a small tool to handle specific decryption of some stuff... Wonder if that can be expanded for this task and just use wolfssl or openssl api to decode base64 stuff? Would love some feedback about this from others since it's not so trivial. > --- > * New in v2 > > > (no changes since v1) > > package/utils/coreutils/Makefile | 153 ++ > .../patches/001-no_docs_man_tests.patch | 93 +++ > 2 files changed, 246 insertions(+) > create mode 100644 package/utils/coreutils/Makefile > create mode 100644 > package/utils/coreutils/patches/001-no_docs_man_tests.patch > > diff --git a/package/utils/coreutils/Makefile > b/package/utils/coreutils/Makefile > new file mode 100644 > index ..d1af3ce962f1 > --- /dev/null > +++ b/package/utils/coreutils/Makefile > @@ -0,0 +1,153 @@ > +# > +# Copyright (C) 2008-2014 OpenWrt.org > +# > +# This is free software, licensed under the GNU General Public License v2. > +# See /LICENSE for more information. > +# > + > +include $(TOPDIR)/rules.mk > + > +PKG_NAME:=coreutils > +PKG_VERSION:=9.1 > +PKG_RELEASE:=1 > + > +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > +PKG_SOURCE_URL:=@GNU/coreutils > +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 > + > +PKG_MAINTAINER:=Jo-Philipp Wich > +PKG_LICENSE:=GPL-3.0-or-later > +PKG_LICENSE_FILES:=COPYING > +PKG_CPE_ID:=cpe:/a:gnu:coreutils > + > +PKG_INSTALL:=1 > +PKG_BUILD_PARALLEL:=1 > + > +include $(INCLUDE_DIR)/package.mk > + > +COREUTILS_APPLETS := \ > + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot > \ > + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env > \ > + expand expr factor false fmt fold groups head hostid id install join > \ > + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl > \ > + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd > \ > + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum > \ > + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum > \ > + sync tac tail tee test timeout touch tr true truncate tsort tty uname > \ > + unexpand uniq unlink uptime users vdir wc who whoami yes > + > +DIR_BIN := \ > + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls > \ > + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync > \ > + touch true uname > + > +DIR_USR_BIN := \ > + basename chcon cksum comm cut dirname du env expand expr factor fold > \ > + groups head hostid id install logname md5sum mkfifo nl nohup nproc od > \ > + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum > \ > + shred shuf sort split sum tac tail tee test timeout tr truncate tty > \ > + unexpand uniq unlink uptime users wc who whoami yes > + > +DIR_USR_SBIN := \ > + chroot > + > +# BusyBox does not provide these yet > +DIR_OTHERS := \ > + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky > \ > + pr ptx sha224sum sha384sum stdbuf tsort vdir > + > +$(eval $(foreach > a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach > a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > +$(eval $(foreach > a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) > + > +DEPENDS_sort = +libpthread > +DEPENDS_timeout = +librt > +DEPENDS_expr = +libgmp > +DEPENDS_factor = +libgmp > +DEPENDS_cp = +libacl > +DEPENDS_dir = +libacl +libcap > +DEPENDS_install = +libacl > +DEPENDS_ls = +libacl +libcap > +DEPENDS_mv = +libacl > +DEPENDS_vdir = +libacl +libcap > + > +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so > + > +define Package/coreutils/Default > + SECTION:=utils > + CATEGORY:=Utilities > + TITLE:=The GNU core utilities > + URL:=http://www.gnu.org/software/coreutils/ > +endef > + > +define Package/coreutils > + $(call Package/coreutils/Default) > + TITLE:=The GNU core utilities > + MENU:=1 > +endef > + > +define Package/coreutils/description > + Full versio
[PATCH v2 6/7] coreutils: Import from packages feed
I need to express a per-target dependency on the 'base64' utility, and that's seemingly impossible to do for busybox. Pull in coreutils to make that easier. Signed-off-by: Brian Norris --- * New in v2 (no changes since v1) package/utils/coreutils/Makefile | 153 ++ .../patches/001-no_docs_man_tests.patch | 93 +++ 2 files changed, 246 insertions(+) create mode 100644 package/utils/coreutils/Makefile create mode 100644 package/utils/coreutils/patches/001-no_docs_man_tests.patch diff --git a/package/utils/coreutils/Makefile b/package/utils/coreutils/Makefile new file mode 100644 index ..d1af3ce962f1 --- /dev/null +++ b/package/utils/coreutils/Makefile @@ -0,0 +1,153 @@ +# +# Copyright (C) 2008-2014 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=coreutils +PKG_VERSION:=9.1 +PKG_RELEASE:=1 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=@GNU/coreutils +PKG_HASH:=61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423 + +PKG_MAINTAINER:=Jo-Philipp Wich +PKG_LICENSE:=GPL-3.0-or-later +PKG_LICENSE_FILES:=COPYING +PKG_CPE_ID:=cpe:/a:gnu:coreutils + +PKG_INSTALL:=1 +PKG_BUILD_PARALLEL:=1 + +include $(INCLUDE_DIR)/package.mk + +COREUTILS_APPLETS := \ + base32 base64 basename basenc b2sum cat chcon chgrp chmod chown chroot \ + cksum comm cp csplit cut date dd df dir dircolors dirname du echo env \ + expand expr factor false fmt fold groups head hostid id install join \ + kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl \ + nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd \ + readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum \ + sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum \ + sync tac tail tee test timeout touch tr true truncate tsort tty uname \ + unexpand uniq unlink uptime users vdir wc who whoami yes + +DIR_BIN := \ + base64 cat chgrp chmod chown cp date dd df echo false kill link ln ls \ + mkdir mknod mktemp mv nice printenv pwd rm rmdir sleep stat stty sync \ + touch true uname + +DIR_USR_BIN := \ + basename chcon cksum comm cut dirname du env expand expr factor fold \ + groups head hostid id install logname md5sum mkfifo nl nohup nproc od \ + paste printf readlink realpath runcon seq sha1sum sha256sum sha512sum \ + shred shuf sort split sum tac tail tee test timeout tr truncate tty \ + unexpand uniq unlink uptime users wc who whoami yes + +DIR_USR_SBIN := \ + chroot + +# BusyBox does not provide these yet +DIR_OTHERS := \ + base32 b2sum basenc csplit dir dircolors fmt join numfmt pathchk pinky \ + pr ptx sha224sum sha384sum stdbuf tsort vdir + +$(eval $(foreach a,$(DIR_BIN),ALTS_$(a):=300:/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_BIN),ALTS_$(a):=300:/usr/bin/$(a):/usr/libexec/$(a)-coreutils$(newline))) +$(eval $(foreach a,$(DIR_USR_SBIN),ALTS_$(a):=300:/usr/sbin/$(a):/usr/libexec/$(a)-coreutils$(newline))) + +DEPENDS_sort = +libpthread +DEPENDS_timeout = +librt +DEPENDS_expr = +libgmp +DEPENDS_factor = +libgmp +DEPENDS_cp = +libacl +DEPENDS_dir = +libacl +libcap +DEPENDS_install = +libacl +DEPENDS_ls = +libacl +libcap +DEPENDS_mv = +libacl +DEPENDS_vdir = +libacl +libcap + +FILES_stdbuf := usr/lib/coreutils/libstdbuf.so + +define Package/coreutils/Default + SECTION:=utils + CATEGORY:=Utilities + TITLE:=The GNU core utilities + URL:=http://www.gnu.org/software/coreutils/ +endef + +define Package/coreutils + $(call Package/coreutils/Default) + TITLE:=The GNU core utilities + MENU:=1 +endef + +define Package/coreutils/description + Full versions of standard GNU utilities. If an equivalent Busybox applet is + available, you should consider compiling that instead as Busybox applets are + usually smaller, at the expense of reduced functionality. +endef + +define GenPlugin + define Package/$(1) + $(call Package/coreutils/Default) + DEPENDS:=coreutils $(DEPENDS_$(2)) + TITLE:=Utility $(2) from the GNU core utilities + ALTERNATIVES:=$(ALTS_$(2)) + endef + + define Package/$(1)/description + Full version of standard GNU $(2) utility. + endef +endef + +$(foreach a,$(COREUTILS_APPLETS),$(eval $(call GenPlugin,coreutils-$(a),$(a + +CONFIGURE_VARS += \ + gl_cv_func_mbrtowc_incomplete_state=yes \ + gl_cv_func_mbrtowc_retval=yes \ + gl_cv_func_wcrtomb_retval=yes \ + ac_cv_header_selinux_context_h=no \ + ac_cv_header_selinux_flash_h=no \ + ac_cv_header_selinux_selinux_h=no \ + ac_cv_search_setfilecon=no + +CONFIGURE_ARGS += \ + --disable-xattr \ + --enable-install-program=su \ + --enable-threads=posix \ + --enable-acl
Re: Re: coreutils
If you are talking about the https://github.com/uutils/coreutils project then it's far from completion. Also the Rust compiler is not so good for MIPS targets which are used by most routers. OpenWrt is based on BusyBox utils which is a clone of coreutils but with many options stripped to keep space. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: coreutils
On 2021-12-06 14:33, Paul Spooren wrote: On 6. Dec 2021, at 13:37, Paul D wrote: Could coreutils in rust be interesting for this project? (memory safety, at least at a later date) I think long term rust routers would be of interest, did you already do some rather research? From a first looks it seem to miss a shell which is included in busybox (ash). Did you check the binary size? They use MIT license, however. It's still young and many components are not yet done. Just the idea seems interesting, however. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: coreutils
> On 6. Dec 2021, at 13:37, Paul D wrote: > > Could coreutils in rust be interesting for this project? (memory safety, at > least at a later date) I think long term rust routers would be of interest, did you already do some rather research? From a first looks it seem to miss a shell which is included in busybox (ash). Did you check the binary size? > > > They use MIT license, however. > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: coreutils
They use MIT license, however. https://github.com/uutils/coreutils ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
coreutils
Could coreutils in rust be interesting for this project? (memory safety, at least at a later date) They use MIT license, however. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/8] tools/coreutils: add cygwin compatibility
From: Alexey Loukianov Properly handle ".exe" suffix on CYGWIN hosts. Signed-off-by: Alexey Loukianov (rebased) Signed-off-by: Rosen Penev --- tools/coreutils/Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/coreutils/Makefile b/tools/coreutils/Makefile index e338796053..8de2cb9894 100644 --- a/tools/coreutils/Makefile +++ b/tools/coreutils/Makefile @@ -16,7 +16,13 @@ PKG_HASH:=8891d349ee87b9ff7870f52b6d9312a9db672d2439d289bc57084771ca21656b HOST_BUILD_PARALLEL := 1 -BUILD_PROGRAMS = date readlink touch +ifeq (CYGWIN,$(findstring CYGWIN,$(HOST_OS))) +EXEC_SUFFIX:=.exe +else +EXEC_SUFFIX:= +endif + +BUILD_PROGRAMS = date$(EXEC_SUFFIX) readlink$(EXEC_SUFFIX) touch$(EXEC_SUFFIX) include $(INCLUDE_DIR)/host-build.mk -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] upgrade coreutils
coreutils upgrade to version 8.15 and refresh COREUTILS_APPLETS list. I would also like to maintain this package. Signed-off-by: Luka Perkov open...@lukaperkov.net --- Index: utils/coreutils/patches/001-no_docs_man_tests.patch === --- utils/coreutils/patches/001-no_docs_man_tests.patch (revision 30641) +++ utils/coreutils/patches/001-no_docs_man_tests.patch (working copy) @@ -11,7 +11,7 @@ ChangeLog-2005 \ --- a/Makefile.in +++ b/Makefile.in -@@ -1238,7 +1238,7 @@ top_srcdir = @top_srcdir@ +@@ -1490,7 +1490,7 @@ top_srcdir = @top_srcdir@ # Some tests always need root privileges, others need them only sometimes. ALL_RECURSIVE_TARGETS = install-root check-root distcheck-hook Index: utils/coreutils/Makefile === --- utils/coreutils/Makefile(revision 30641) +++ utils/coreutils/Makefile(working copy) @@ -1,5 +1,5 @@ # -# Copyright (C) 2008-2010 OpenWrt.org +# Copyright (C) 2008-2012 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -8,26 +8,26 @@ include $(TOPDIR)/rules.mk PKG_NAME:=coreutils -PKG_VERSION:=8.8 +PKG_VERSION:=8.15 PKG_RELEASE:=1 -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@GNU/coreutils -PKG_MD5SUM:=bad596d9654e299eedea0eaf93f178fa -PKG_BUILD_DEPENDS:=libpthread +PKG_MD5SUM:=094909fafa86110140b32e4948941545 include $(INCLUDE_DIR)/package.mk COREUTILS_APPLETS:=\ base64 basename cat chcon chgrp chmod chown chroot cksum comm cp \ csplit cut date dd dir dircolors dirname du echo env expand expr \ - factor false fmt fold groups head hostid id install join kill link \ - ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc \ - od paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir \ - runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf \ - sleep sort split stat stdbuf stty su sum sync tac tail tee test timeout \ - touch tr true truncate tsort tty uname unexpand uniq unlink uptime users \ - vdir wc who whoami yes + factor false fmt fold getlimits ginstall groups head hostid id \ + join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv \ + nice nl nohup nproc od paste pathchk pinky pr printenv printf \ + ptx pwd readlink realpath rm rmdir runcon seq setuidgid sha1sum \ + sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort \ + split stat stdbuf stty su sum sync tac tail tee test timeout \ + touch tr true truncate tsort tty uname unexpand uniq unlink \ + uptime users vdir wc who whoami yes define Package/coreutils/Default SECTION:=utils @@ -43,7 +43,7 @@ endef define Package/coreutils/description - Full versions of standard GNU utilities. Normally, you would not + Full versions of standard GNU utilities. Normally, you would not use this package, since the functionality in BusyBox is more than sufficient and much smaller. endef @@ -56,7 +56,7 @@ endef define Package/$(1)/description - Full version of standard GNU $(2) utility. Normally, you would not + Full version of standard GNU $(2) utility. Normally, you would not use this package, since the functionality in BusyBox is more than sufficient. endef @@ -75,7 +75,11 @@ endif CONFIGURE_ARGS += \ - --enable-install-program=su + --disable-threads \ + --disable-rpath \ + --disable-nls \ + --without-selinux \ + --without-gmp define Build/Compile $(MAKE) -C $(PKG_BUILD_DIR) \ @@ -84,14 +88,10 @@ all install install-root endef -define Package/coreutils/install - true -endef - define BuildPlugin define Package/$(1)/install $(INSTALL_DIR) $$(1)/usr/bin - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/$(2) $$(1)/usr/bin/ + $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/$(2) $$(1)/usr/bin endef $$(eval $$(call BuildPackage,$(1))) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipkg-make-index: replace awk calls with stat and cut (from coreutils)
Le Thu, 27 Oct 2011 17:03:05 +0200,
Florian Fainelli flor...@openwrt.org a écrit :
On Thursday 27 October 2011 16:45:11 Raphaël HUCK wrote:
Hi all,
this patch replaces awk calls with stat and cut, which are both
included in coreutils.
Have you verified this works on BDS platforms, as well as MacOSX?
No, as I don't have a BSD or MacOS X system to test on.
And you're right to point this out, as stat -c %s doesn't work on
BSD, though cut -d' ' -f1 seems to be fine.
I've been looking intensively through Linux, BSD, and MacOS X man
pages, and I've come to the conclusion that the best portable way to
get the size of a file is:
$ wc -c $FILE
I've updated my patch, it now uses wc (which is also in coreutils) and
doesn't need cut anymore.
Thanks!
-Raphaël
--- scripts/ipkg-make-index.sh.orig 2011-10-27 16:08:33.149886769 +0200
+++ scripts/ipkg-make-index.sh 2011-10-28 11:13:42.483519744 +0200
@@ -1,24 +1,25 @@
#!/bin/sh
set -e
-pkg_dir=$1
+pkg_dir=$1
-if [ -z $pkg_dir ] || [ ! -d $pkg_dir ]; then
+if [ -z ${pkg_dir} ] || [ ! -d ${pkg_dir} ]; then
echo Usage: ipkg-make-index package_directory 2
exit 1
fi
-which md5sum /dev/null 21 || alias md5sum=md5
+which md5sum /dev/null 21 || alias md5sum=md5
-for pkg in `find $pkg_dir -name '*.ipk' | sort`; do
- echo Generating index for package $pkg 2
- file_size=$(ls -l $pkg | awk '{print $5}')
- md5sum=$(md5sum $pkg | awk '{print $1}')
+for pkg in $(find ${pkg_dir} -name '*.ipk' | sort); do
+ echo Generating index for package ${pkg} 2
+ file_size=$(wc -c ${pkg})
+ md5sum=$(md5sum ${pkg} 2 /dev/null)
+ md5sum=${sum%% *}
# Take pains to make variable value sed-safe
- sed_safe_pkg=`echo $pkg | sed -e 's/^\.\///g' -e 's/\\//\\//g'`
- tar -xzOf $pkg ./control.tar.gz | tar xzOf - ./control | sed -e s/^Description:/Filename: $sed_safe_pkg\\
-Size: $file_size\\
-MD5Sum: $md5sum\\
+ sed_safe_pkg=$(echo ${pkg} | sed -e 's/^\.\///g' -e 's/\\//\\//g')
+ tar -xzOf ${pkg} ./control.tar.gz | tar xzOf - ./control | sed -e s/^Description:/Filename: ${sed_safe_pkg}\\
+Size: ${file_size}\\
+MD5Sum: ${md5sum}\\
Description:/
echo
done
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ipkg-make-index: replace awk calls with stat and cut (from coreutils)
Hi all,
this patch replaces awk calls with stat and cut, which are both
included in coreutils.
Thanks,
-Raphaël
--- scripts/ipkg-make-index.sh.orig 2011-10-27 16:08:33.149886769 +0200
+++ scripts/ipkg-make-index.sh 2011-10-27 16:13:25.593893720 +0200
@@ -12,8 +12,8 @@ which md5sum /dev/null 21 || alias md
for pkg in `find $pkg_dir -name '*.ipk' | sort`; do
echo Generating index for package $pkg 2
- file_size=$(ls -l $pkg | awk '{print $5}')
- md5sum=$(md5sum $pkg | awk '{print $1}')
+ file_size=$(stat -c %s $pkg)
+ md5sum=$(md5sum $pkg | cut -d' ' -f1)
# Take pains to make variable value sed-safe
sed_safe_pkg=`echo $pkg | sed -e 's/^\.\///g' -e 's/\\//\\//g'`
tar -xzOf $pkg ./control.tar.gz | tar xzOf - ./control | sed -e s/^Description:/Filename: $sed_safe_pkg\\
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipkg-make-index: replace awk calls with stat and cut (from coreutils)
On Thursday 27 October 2011 16:45:11 Raphaël HUCK wrote: Hi all, this patch replaces awk calls with stat and cut, which are both included in coreutils. Have you verified this works on BDS platforms, as well as MacOSX? -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] coreutils-uptime not working?
Has coreutils-uptime ever worked? I recently tried turning it on: root@OpenWrt:~# uptime uptime: couldn't get boot time: No such file or directory root@OpenWrt:~# root@OpenWrt:~# who root@OpenWrt:~# users root@OpenWrt:~# And evidently who and users are also broken, since root on the console should be showing up. Just to make sure that it wasn't a problem with root on console not writing out a wtmp record, I also tried logging in via ssh and repeating the experiment... Same result. This is a build of Saturday's svn trunk. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] coreutils as default package is always built
Hello Everybody, with commit 26026 (https://dev.openwrt.org/changeset/26026) I see the coreutils package downloaded and build in my defconfig. With the following patch, this default selection really does no build, as long as no plugin is selected. Best regards, Thomas Signed-off-by: Thomas Langer thomas.lan...@gmx.net diff --git a/utils/coreutils/Makefile b/utils/coreutils/Makefile --- a/utils/coreutils/Makefile +++ b/utils/coreutils/Makefile @@ -84,10 +84,6 @@ define Build/Compile all install install-root endef -define Package/coreutils/install - true -endef - define BuildPlugin define Package/$(1)/install $(INSTALL_DIR) $$(1)/usr/bin -- http://thomas.hat-gar-keine-homepage.de/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] coreutils as default package is always built
On Mon, 14 Mar 2011 17:07:22 +0100 Thomas Langer thomas.lan...@gmx.net wrote: with commit 26026 (https://dev.openwrt.org/changeset/26026) I see the coreutils package downloaded and build in my defconfig. With the following patch, this default selection really does no build, as long as no plugin is selected. Commited r26169. Thanks for the good catch. -- erno hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] coreutils changes
Hello Philip, On Tuesday 22 February 2011 03:02:58 Philip Prindeville wrote: Did anything change in coreutils that would stop it from working with make defconfig? Because I have in my ~/.openwrt/defconfig file: ... CONFIG_PACKAGE_libpthread=y CONFIG_PACKAGE_coreutils=y CONFIG_PACKAGE_coreutils-users=y CONFIG_PACKAGE_coreutils-uptime=y CONFIG_PACKAGE_coreutils-who=y ... and yet make defconfig fails to select the individual packages... Yet CONFIG_PACKAGE_coreutils=y gets selected. What am I missing? I have removed the coreutils package which selected all the modules, feel free to submit a patch to add it back, I will look into adding it back later today. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] coreutils changes
Hi Philip, On 22/02/2011 19:01, Philip Prindeville wrote: On 2/22/11 1:05 AM, Florian Fainelli wrote: Hello Philip, On Tuesday 22 February 2011 03:02:58 Philip Prindeville wrote: Did anything change in coreutils that would stop it from working with make defconfig? Because I have in my ~/.openwrt/defconfig file: ... CONFIG_PACKAGE_libpthread=y CONFIG_PACKAGE_coreutils=y CONFIG_PACKAGE_coreutils-users=y CONFIG_PACKAGE_coreutils-uptime=y CONFIG_PACKAGE_coreutils-who=y ... and yet make defconfig fails to select the individual packages... Yet CONFIG_PACKAGE_coreutils=y gets selected. What am I missing? I have removed the coreutils package which selected all the modules, feel free to submit a patch to add it back, I will look into adding it back later today. -- Florian Sorry, I think we're talking crossed purposes... I'm trying to select those three packages, but can't do that. I think coreutils was changed so that when selected, coreutils now creates a submenu where you can select individual elements. Previously all of the coreutil packages were in the top level of Utilities. Florian changed it with this patch I believe. https://dev.openwrt.org/changeset/25434 Regards, Jon ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] coreutils version bump
Good day. coreutils version bump Index: feeds/packages/utils/coreutils/Makefile === --- feeds/packages/utils/coreutils/Makefile(revision 24752) +++ feeds/packages/utils/coreutils/Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=coreutils -PKG_VERSION:=8.7 -PKG_RELEASE:=2 +PKG_VERSION:=8.8 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=...@gnu/coreutils -PKG_MD5SUM:=3c1ae9531159447083ae8f25ae554b81 +PKG_MD5SUM:=bad596d9654e299eedea0eaf93f178fa PKG_BUILD_DEPENDS:=libpthread include $(INCLUDE_DIR)/package.mk Signed-off-by: Alexander Khryukin alexan...@mezon.ru ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
