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]
