Re: dpkg --version

[Tito]

On 10/20/2015 03:43 PM, linuxcbon linuxcbon wrote:

On Tue, Oct 20, 2015 at 12:04 PM, Denys Vlasenko 
wrote:


On Mon, Oct 19, 2015 at 2:33 AM, linuxcbon linuxcbon
 wrote:

Hello,

can someone please add the option "--version" to dpkg in busybox ?
(for example, to avoid error messages in the steam client).


Do you want someone to install steam (what is it?),
do whatever it is necessary to generate the error message,
then experiment with adding a correct --version message
of dpkg to fix it?



I would like that busybox dpkg has option "--version",  like in the
"normal" dpkg.




Hi,
you can try to run a wrapper script.
1) remove the symlink dpkg -> busybox if it exists
2) create a shell script named dpkg with this text:

#!/bin/sh
if [ "$1" == "--version ] ; then
  echo "`dpkg' package management program version x.y.z"
else
  busybox dpkg $@
fi


3) make it executable: chmod 755 dpkg

This is untested so I could have forgotten some detail
but you will find out.
Hope it helps.

Ciao,
Tito
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: dpkg --version

[Joshua Judson Rosen]

On 2015-10-20 09:43, linuxcbon linuxcbon wrote:
> 
> On Tue, Oct 20, 2015 at 12:04 PM, Denys Vlasenko  > wrote:
> 
> On Mon, Oct 19, 2015 at 2:33 AM, linuxcbon linuxcbon
> mailto:linuxc...@gmail.com>> wrote:
> > Hello,
> >
> > can someone please add the option "--version" to dpkg in busybox ?
> > (for example, to avoid error messages in the steam client).
> 
> Do you want someone to install steam (what is it?),
> do whatever it is necessary to generate the error message,
> then experiment with adding a correct --version message
> of dpkg to fix it?
> 
> 
> I would like that busybox dpkg has option "--version",  like in the "normal" 
> dpkg.

I think what Denys means is: what do you need the output to be?

If what you're asking for is that "busybox dpkg --version" should
output something that can be parsed by Steam or another program,
we'd need to know what assumptions those program are making about
the format of the "dpkg --version" output.

Many of us are not familiar with Steam, or not familiar enough
to know what it expects to be able to do with the output from
"dpkg --version". Would it be sufficient to say something like:

BusyBox v1.20.2 (Debian 1:1.20.0-7) multi-call binary.

?

Would it be sufficient to simply output nothing and exit
with `success' status?

You didn't give any indication what kind of output busybox
would need to produce to actually resolve your problem
with Steam (and whatever other programs you might be using
that try to use the output of "dpkg --version" in some way),
so how are we to know? :)

For all we know, the programs you're using expect "dpkg --version"
to output exactly this text:

Debian `dpkg' package management program version 1.16.1.2 (amd64).
This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.

Or they might expect exactly some other text.

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: dpkg --version

[linuxcbon linuxcbon]

On Tue, Oct 20, 2015 at 12:04 PM, Denys Vlasenko 
wrote:

> On Mon, Oct 19, 2015 at 2:33 AM, linuxcbon linuxcbon
>  wrote:
> > Hello,
> >
> > can someone please add the option "--version" to dpkg in busybox ?
> > (for example, to avoid error messages in the steam client).
>
> Do you want someone to install steam (what is it?),
> do whatever it is necessary to generate the error message,
> then experiment with adding a correct --version message
> of dpkg to fix it?
>

I would like that busybox dpkg has option "--version",  like in the
"normal" dpkg.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v2] inotifyd: -x: new option

[Laurent Bercot]

On 20/10/2015 13:17, Denys Vlasenko wrote:

inotifyd syntax is "inotifyd PROG FILE1[:MASK]...",
and PROG is run with

 PROG ACTUAL_EVENTS FILEn [SUBFILE]

This severely limits the number of unmodified PROGs you can run
to achieve some useful result. (...)
IOW: in practice, you always need a shim.


 Ah, indeed. It's a shame PROG is a single argument, though:
I very much prefer executing whole command lines. If you have
to tailor PROG to inotifyd's needs anyway, the "it's less code"
argument falls.



Sorry, but I don't agree to this view even after you repeat it.
Here is an example where this idiom of "killing the parent"
is used already:


 Well, giving me another example of this idiom doesn't convince
me that it's a good one either. :P
 ntpd, just like inotifyd, can be killed by one of its children?
I still don't like it. I'm a Unix traditionalist and reactionary:
parents should have control over their children, not the other way
round.



Can you point me to the software you are working on so that
I can look on a wider picture of the problem you are trying to solve?


 That would be Bartosz. I'm not working on any software using inotifyd,
I was just adding my support to his proposal from a pure "Unix software
design" point of view. But for me it's theoretical, and borderline
bikeshedding, and I can work with your design even if it's not my
preferred one - so if you won't be convinced, that's ok too, and I'll
just drop it. :)

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH v2] inotifyd: -x: new option

[Denys Vlasenko]

On Sat, Oct 17, 2015 at 12:38 PM, Laurent Bercot
 wrote:
> On 17/10/2015 09:47, Denys Vlasenko wrote:
>>
>> If you have a program which does not know that it is being run by
>> inotifyd,
>> you can create a shim which does know that:
>>
>> #!/bin/sh
>> PROG "$@"
>> test "$?" = 111 && kill $PPID
>
>
>  Yes. You still have to know which program needs it and which one does
> not, and you have to run that shim for every program that does. This
> is code - a longer code path than Bartosz's patch, and that has to be
> maintained separately.

inotifyd syntax is "inotifyd PROG FILE1[:MASK]...",
and PROG is run with

PROG ACTUAL_EVENTS FILEn [SUBFILE]

This severely limits the number of unmodified PROGs you can run
to achieve some useful result. For example, even cat'ting newly
created files to stdout can't be done by PROG=cat, you need
to massage argv's

IOW: in practice, you always need a shim.

>> You propose to add complexity to inotifyd because it's looks "cleaner".
>> I don't see it as "cleaner", I see both ways as legitimate.
>> But your way requires additional code.
>
>  It requires additional code in inotifyd, yes. But it factorizes code
> that you would have had to run anyway, in scripting the child. It also
> allows you to make the natural assumption that a child cannot impact
> its parent (except by returning a certain exit code), which I find
> makes scripts easier to understand, so more maintainable.

Sorry, but I don't agree to this view even after you repeat it.
Here is an example where this idiom of "killing the parent"
is used already:

busybox/examples/var_service/ntpd/ntp.script
...
if test x"$1" = x"unsync"; then
# No replies for our NTP requests were seen for some time.
#
# Among more mundate cases like network outages, this happens
# if we ran for a LONG time (days) and ntp server's IP has changed.
# ntpd has no code to re-resolve peers' addresses to IPs,
# we need to help it:
#
echo "$dt: $1"\
"syncronization lost, restarting ntpd"\
>>"$0.log.$$"
mv -- "$0.log.$$" "$0.log"
kill $PPID
exit
fi
...

Can you point me to the software you are working on so that
I can look on a wider picture of the problem you are trying to solve?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: dpkg --version

[Denys Vlasenko]

On Mon, Oct 19, 2015 at 2:33 AM, linuxcbon linuxcbon
 wrote:
> Hello,
>
> can someone please add the option "--version" to dpkg in busybox ?
> (for example, to avoid error messages in the steam client).

Do you want someone to install steam (what is it?),
do whatever it is necessary to generate the error message,
then experiment with adding a correct --version message
of dpkg to fix it?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH 1/2] udhcpd: sanitize invalid hostnames to match rfcs

[Bernhard Reutner-Fischer]

On October 20, 2015 6:20:17 AM GMT+02:00, Isaac Dunham  
wrote:
>On Mon, Oct 19, 2015 at 10:52:27AM +0200, walter harms wrote:
>> 
>> 
>> Am 18.10.2015 23:26, schrieb Isaac Dunham:
>> > On Sun, Oct 18, 2015 at 07:55:38PM +0200, walter harms wrote:
>> >>
>> >>
>> >> Am 18.10.2015 07:54, schrieb Isaac Dunham:
>> >>> RFC952/RFC1123 limit the characters in a hostname for a node to
>> >>> [-a-zA-Z0-9], with '-' being legal only in the middle; we were
>> >>> accepting everything from ' ' to '~'.
>> >>> (As a byproduct of this, the hostname in dumpleases can now be
>safely
>> >>> used from scripts without sanitization.)
>> >>
>> >> since several tools check for hostnames,
>> >> maybe it is useful to make this a function ?
>> > 
>> > What this does is not  simply 'check for validity'; it *makes* a
>hostname
>> > valid, which is not what most tools need.
>> > It also is exclusively for leaf node names, rather than an FQDN
>(ie,
>> > '.' is not valid here).
>> > 
>> > It would be possible to design a function that can check or fix the
>> > hostname depending how it's called, though I wonder if that's
>> > doing too much in a single call.
>> > 
>> > It would probably have to be something like this:
>> > 
>> > #define HOSTCHECK_LEAF 0x1 //leaf hostname-no '.' allowed
>> > #define HOSTCHECK_FIX  0x2 //fix-replace invalid chars with '-'/'X'
>> > 
>> > //return NULL if valid, pointer to first invalid char otherwise
>> > char * validate_hostname(char *p, int flags);
>> > 
>> > This does not handle transforming a URL via punycode, of course.
>> > 
>> > Would such an interface be desireable?
>> 
>> note: i did not make an inventory if this is needed by other
>>   programms but i can imagine that with 'hostname' it would be
>useful.
>
>RFCs only apply to networking; a local hostname need not conform.
>udhcpc and dnsd might be able to use it.
>Other networking tools (that do DNS lookups) could use it, or could
>simply trust that if the user inputs an invalid name, either the DNS
>system will catch it or it will resolve despite the standards.
>
>> for a bit more flexibility:
>> int status=valid_hostname(char *in, char **out, int flags);
>> 
>I'd assume 'status' is bytes invalid, 'out' is somewhere to store a
>sanitized hostname, and flags is as above.
>Or is 'status' the offset of the first invalid byte?
>Is 'out' to store a pointer to an invalid char?
>
>The reason I proposed the above:
>-the return value works as both a logical test:
>   if((status = validate_hostname(host, 0))) /* error handler */;
> and as a usable error:
>   printf("error: '%c' is not valid in a hostname\n", *status);
>-in the context of the code I modified, it *must* be sanitized in
>place:
> the hostname is a char[20] buffer that is part of a struct, and
> dumpleases relies on that fact.
>
>> In a first step it would be sufficient to move this code into a
>function
>> and then look for more uses.
>
>Due to the subtle variations in what we need to cover, a function
>*will*
>be larger than the inline code, and will also require thought as to
>what
>it should cover.
>I don't think it's sensible to move it into a function before
>determining
>what it should do, and that it really is useful.

bugs.busybox.net/3979#c2

I wouldn't support broken names, it doesn't make real sense.

HTH,
>
>Thanks,
>Isaac Dunham
>___
>busybox mailing list
>busybox@busybox.net
>http://lists.busybox.net/mailman/listinfo/busybox


___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox