Hi Kel, I haven't used ndiswrapper in ages. Feel free to do whatever you like w/ the package (including removing me as an Uploader)!
On Fri, 4 Apr 2008 08:50:21 +1000 Kel Modderman <[EMAIL PROTECTED]> wrote: > Hi jak and Andres, > > (CC'ing Andres, just to make sure he is comfortable with our proposal) > > Hi Andres, Do you mind if ndiswrapper debian package is maintained in > collab-maint with the help of Julian Andres Klode? > > He is a Debian Maintainer, and would eventually like to do unassisted uploads > of ndiswrapper to the archive, should either yourself, or i guess, Daniel > Baumann agree. > > Cheers. > > On Friday 04 April 2008 03:00:13 Julian Andres Klode wrote: > > > Any feedback on the described changes to tools? > > The module version detection works perfectly. > > Cheers for checking. > > > > > > > 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. > > I also very seldom actually use ndiswrapper. > > > > > > 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. > > Ok, I am a git virgin, but I'm fine to pop my cherry with it. I agree that > moving to collab-maint git would be cool, just let me know what needs to be > done on my end. > > > > > > 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. > > I have already submitted a patch to BTS for this, and it was NAK'd. However, I > am involved in project which has forked linux-2.6 and linux-modules-main-2.6 > and we have added ndiswrapper to the modules there, so I have working code > already for this, and you would just need ask me to resubmit it. I have spoken > with panthera about it, and he did not oppose the addition of ndiswrapper at > that time. > > http://svn.berlios.de/svnroot/repos/fullstory/linux-modules-sidux-main-2.6/trunk/ndiswrapper/ > > One showstopping problem, however, is that currently module binary packages > generated by linux-modules-main-2.6 have no way to define a dependency > or even a recommends on another package(s); this means that > ndiswrapper-modules-_KVERS_ built from linux-modules conglomerate package > will not automattically pull in ndiswrapper-utils-_VER_ at install time. > This is bad. > > > > > 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. > > Sounds like a good plan. > > Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
