Kel Modderman wrote: > On Wednesday 19 March 2008 17:53:37 Kel Modderman wrote: >> On Monday 17 March 2008 22:04:57 Julian Andres Klode wrote: >>> Therefore, you need to get the supported version from the module, using >>> something like >>> modinfo -p ndiswrapper | sed -n 's/^utils_version:.*(read only: >>> \([0-9\.]*\)).*/\1/p' >> Can you please take a look at the wrappers in current SVN that implement >> your suggestion as primary method of utils version selection? > > Any feedback on the described changes to tools? The module version detection works perfectly. > > Also, after some thought, I would be open to allow you to look after future > maintenance of ndiswrapper package; the other packages you maintain that I use Well, thank you for asking.
Actually, I haven't used ndiswrapper since last year (except
for creating directories in /etc/ndiswrapper to have some invalid drivers for
ndisgtk
testing). [I don't need it anymore, as I'm using Intel Wireless on 64bit
systems]
But it's always a good idea to have a package co-maintained. With my DM
status, I would also be able to upload new versions on my own (after one
upload which adds Dm-Upload-Allowed: yes), without the need for a sponsor.
You can add me to Uploaders and add a "Dm-Upload-Allowed: yes" to the source
part
of the control file.
> seem to be well taken care of (eg. aufs), plus you also do ndisgtk (of which I
> would love to port to QT one day...).
Well, ndisgtk's core functionality will be integrated into jockey, a driver
management
tool with QT4 and GTK frontend. It will detect network cards without drivers
(incl. USB)
and you can click on them, it asks you where you want to search the driver
(CD/Harddisk)
and finds all drivers on a cdrom automatically. But first I need to write
python-ndiswrapper,
as some kind of bindings for ndiswrapper. (or I integrate it directly in jockey)
(BTW, i never used ndisgtk for real driver installation, I simply copied my
/etc/ndiswrapper.)
>
> Even if you wanted just to move maintenance to a shared area where we both
> have
> possibility to commit, if that is reasonable. In this case I would not object
I would prefer a distributed system like git or Mercurial or GNU Bazaar. Using
git
makes it very easy, as you can easily use pristine-tar to keep small delta
files to
regenerate identical upstream tarballs.
I would create such a repository in collab-maint, so every DD has commit access.
This is the easiest way currently. We would need some commit policies and I
won't
create soon, as I'll first complete my work on debimg, python-libisofs and
gimmie, as well
as an update for app-install-data. But it will happen sometime this month.
> changes such as that suggested here on #470774, and mainly make sure a module
> is available for latest stable linux.
I can see the advantage of the current packaging, but I do not know of any other
distribution doing this. But switching to another packaging style is also
useless
and would make ndiswrapper NEW. Therefore, I think the current packaging should
be
kept.
BTW, I think ndiswrapper should be autobuilt in linux-modules-extra-2.6, and I
would do the steps needed for this.
Summary:
1. I agree to co-maintain this package.
2. I agree to use a repository in collab-maint on git.debian.org,
which I would setup this month.
3. I agree with the current packaging style.
>
> Please consider.
>
> Thanks, Kel.
--
Julian Andres Klode, Fellow of the Free Software Foundation Europe
Debian Maintainer | Developer | Ubuntu Member
try Debian: http://www.debian.org/ | my site: http://jak-linux.org/
jabber: [EMAIL PROTECTED] | IRC: juliank (FreeNode, OFTC)
languages: German | English
signature.asc
Description: OpenPGP digital signature
