Re: Please make discover2 udebs available for testing
On Tue, 2003-06-17 at 03:43, Petter Reinholdtsen wrote:
> [Jeff Licquia]
> > Sure. Write all the code for me. :-)
>
> I'll see what I can do. But I suspect it will take me longer to find
> my way around the code then it will for you do to the work.
Given the passage of time, I'm not sure you were right. :-)
> > Seriously, I have been working on two things:
> >
> > - I have written a reduction script for discover 2 data, and have
> > begun testing it. As far as I can tell, it works. But I haven't
> > yet integrated the script into debian/rules so it's used to generate
> > the udeb.
>
> OK. This sounds good for the next iteration.
This integration work is now done.
> > - I have been working on removing the curl dependency. I have code
> > written that reads file: URIs directly instead of using curl, and
> > I've written it to use zlib if possible. But I haven't tested
> > compiling it yet.
>
> This too.
No change at this time.
> Right now I am just desperate after getting a package that works.
> This means a way to get the required information out of discover, and
> I suspect the best way is to get the needed functionality into the
> --format argument. I never got any replies on this problem. Is it
> possible to get the name of the card out of discover using the
> --format argument?
>
> Using short lists, or dropping a library dependency do not help if the
> program itself is useless. And at the moment, with a busybox missing
> the paste tool, it do not work at all.
>
> I want the equivalent for this command line for discover1:
>
> /sbin/discover --format="%m\t%V %M\n"
>
> This make it easy to handle the result using a shell script.
I've been spending the last week reading discover source code and
thinking of a solution for this.
The problem with the command line you describe is that the data format
has changed in a fundamental way, and there are now ways that a command
line as you describe won't give you the data you want. In a narrow
sense, that isn't going to be true now, but it could be. What we need
to decide is if this is a problem or not, or whether there's a better
solution.
There are a lot of issues that need thinking through now, but as you
have described it, we don't really have time right now for that. So,
I'm going to meet you half way, and leave the deep thinking for later.
I am in the middle of preparing new discover 2 packages (and
discover-data as well) and placing them in the same place they were
before. Again, these are very preliminary, so please don't distribute
them as "final" 2.0.2. These should be ready tonight sometime.
Inside the discover-udeb package, you will find a new utility,
"didiscover". (Think "Debian Installer discover". Sorry if it's a bad
name; as Branden will tell you, naming is not my strong suit.) This
utility is nearly exactly the same as discover, but with one additional
feature: you can now tell discover to output vendor and model
information as part of the format string.
So, to do the equivalent of this discover 1 command line:
/sbin/discover --format="%m:%V %M\n" ethernet
you'll do this with didiscover:
/usr/bin/didiscover --data-path=linux/module/name --data-vendor --data-model \
--format="%s:%s %s" network
Please give this a try and let me know if it works for you. (Backslash
handling, such as "\t", doesn't seem to be there in either discover or
didiscover, but it should be fairly straightforward to add if
necessary.) If the name is troubling to you, we can kill off the copy
of discover in the udeb and make "didiscover" the discover there.
> There is
> also the bug in discover printing empty entries with a newline.
No change here. If the above problem is sufficiently solved, this and
the zlib integration can be next.
> > If you have time and energy to assist with these two tasks, or any
> > others you can identify, I'd appreciate it.
>
> Where can I fetch the current CVS version of discover2?
This is another vexing problem; Progeny still does not have public
anonymous CVS. It's my hope that this will be a reality sometime in the
future.
--
Jeff Licquia <licquia@progeny.com>
Reply to: