Am Mon, den 19.01.2004 schrieb Goswin von Brederlow um 19:56:
Hi,
I installed kernel-headers on m68k manually and build discover2.
The UDeb is at
rsync://mrvn.homeip.net/m68k-sid/new/discover2/
If someone could sponsor an upload it would help.
The current version of discover2 does no
Gaudenz Steinlin [EMAIL PROTECTED] writes:
Am Mon, den 19.01.2004 schrieb Goswin von Brederlow um 19:56:
Hi,
I installed kernel-headers on m68k manually and build discover2.
The UDeb is at
rsync://mrvn.homeip.net/m68k-sid/new/discover2/
If someone could sponsor an upload it
Am Die, den 20.01.2004 schrieb Goswin von Brederlow um 11:39:
Gaudenz Steinlin [EMAIL PROTECTED] writes:
Ok, the autobuilders should handle them then. Did you put a Closes
into the changelog?
Yes, of course. They are listed as resolved on b.d.o
Does m68k have one of these buses: ata, pci,
Gaudenz Steinlin [EMAIL PROTECTED] writes:
Am Die, den 20.01.2004 schrieb Goswin von Brederlow um 11:39:
Gaudenz Steinlin [EMAIL PROTECTED] writes:
Ok, the autobuilders should handle them then. Did you put a Closes
into the changelog?
Yes, of course. They are listed as resolved on b.d.o
Hi,
I installed kernel-headers on m68k manually and build discover2.
The UDeb is at
rsync://mrvn.homeip.net/m68k-sid/new/discover2/
If someone could sponsor an upload it would help.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
tis 2003-06-24 klockan 08.49 skrev Jeff Licquia:
- 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.
This integration work is
[Jeff Licquia]
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
This shounds like it
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
On Tue, 2003-06-24 at 01:49, Jeff Licquia wrote:
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
On Mon, 2003-06-16 at 10:22, Petter Reinholdtsen wrote:
[Jeff Licquia, 2003-06-02]
Thanks for all the feedback, patches, and patience. I'm still learning
my way around discover, and this is my first udeb.
Today, I have an important project to deliver something for. Once
that's done,
On Sun, 2003-06-01 at 02:41, Petter Reinholdtsen wrote:
[Jeff Licquia]
I've stashed discover 2.0.2-0.0.0.2 and discover-data 2.2003.02.05-2
packages in http://hackers.progeny.com/~licquia/discover/. Again,
please don't upload these or otherwise give them official status.
I'm trying to
Hi Jeff...
In addition to the three patches I sent earlier for discover to build from
source, I suggest the attached patch to debian/rules, which simply adds a '.'
in an opportune place, so the libdiscover.so symlink is not added to the udeb
(it's not needed, and it causes the installer's
Hi..
I imagine the correct fix is simply not to tag discover.conf as a conffile, so
dpkg doesn't play fast and loose with renaming it. Hence add a:
rm -f debian/discover-udeb/DEBIAN/conffiles
right after the call to dh_installdeb when building discover-udeb.
This seems to work fine.
=)
Peter
Hi...
On Sun, 1 Jun 2003 07:27 pm, Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
developer:~# discover --data-path=linux/module/name \
--data-version=2.4 -t -d all -e ata -e pci -e pcmcia -e scsi display
--data-version has no meaning without --data-path.
I found the problem.
On Sun, Jun 01, 2003 at 10:35:11AM +0200, Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
670k is way to much. It is one of the biggest udebs. We need to
reduce it.
Is there a true requirement for reduction here? It seems like whenever
we exclude this or that hardware, we also exclude
[Chris Tillman]
Is there a true requirement for reduction here? It seems like
whenever we exclude this or that hardware, we also exclude this or
that user. Someone has worked diligently to make discover
inclusive?
Reducing the size of discover-data-udeb and redusing the list of
supported
sön 2003-06-01 klockan 15.53 skrev Chris Tillman:
On Sun, Jun 01, 2003 at 10:35:11AM +0200, Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
670k is way to much. It is one of the biggest udebs. We need to
reduce it.
Is there a true requirement for reduction here? It seems like
[Peter Hawkins]
Isn't that because what that line actually scans for is things of
type 'display'?
Right. I thought it was an instruction, not a type. I changed it to
'all', and it worked much better. :)
I tried to list several types on the command line, but that gave a
segfault. Not every
[Jeff Licquia]
I've stashed discover 2.0.2-0.0.0.2 and discover-data 2.2003.02.05-2
packages in http://hackers.progeny.com/~licquia/discover/. Again,
please don't upload these or otherwise give them official status.
Is this how it is supposed to work?
developer:/# discover
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
[Herbert Xu]
FWIW, I posted a script ages ago to produce the data file containing
network devices for discover v1 directly from a kernel-image
package. This can be easily extended to cover other PCI devices.
I got a script to update v1
[Jeff Licquia]
I've stashed discover 2.0.2-0.0.0.2 and discover-data 2.2003.02.05-2
packages in http://hackers.progeny.com/~licquia/discover/. Again,
please don't upload these or otherwise give them official status.
I'm trying to test these now. I'll let you know about my progress.
-
[Petter Reinholdtsen]
I'm trying to test these now. I'll let you know about my progress.
OK. This new version is better, but there are still some problems.
I'm testing in the d-i chroot.
First of all, discover still segfaults when /etc/discover.conf is
missing. And it is still missing
sön 2003-06-01 klockan 10.35 skrev Petter Reinholdtsen:
[Petter Reinholdtsen]
I'm trying to test these now. I'll let you know about my progress.
OK. This new version is better, but there are still some problems.
I'm testing in the d-i chroot.
First of all, discover still segfaults when
[Petter Reinholdtsen]
developer:~# discover --data-path=linux/module/name \
--data-version=2.4 -t -d all -e ata -e pci -e pcmcia -e scsi display
--data-version has no meaning without --data-path.
I found the problem. Removing '-t' got rid of this error. But I get
two empty lines
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
I want the code to handle v2 to be as short and easy to handle as the
v1 code.
FWIW, I posted a script ages ago to produce the data file containing
network devices for discover v1 directly from a kernel-image package.
This can be easily extended to
[Herbert Xu]
FWIW, I posted a script ages ago to produce the data file containing
network devices for discover v1 directly from a kernel-image
package. This can be easily extended to cover other PCI devices.
I got a script to update v1 discover-data files with the module names
listed in
On Sat, 2003-05-24 at 02:43, Petter Reinholdtsen wrote:
You went silent, so I guess I should make the task a bit easier. As a
first try on discover-data-udeb, just include the whole data set
without reduction (if it is hard to recuse the list, lets spend that
time later). It will probably be
27 matches
Mail list logo
