Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems
Package: wnpp Severity: wishlist Owner: Nick Leverton This is really an ITA for the existing unicorn and unicorn-source packages which were somewhat precipitately removed from Debian two weeks ago. * Package name: unicorn Version : 0.9.3 Upstream Author : Frode Isaksen * URL : http://www.bewan.com * License : GPL and Proprietary Programming Lang: C Description : Kernel drivers and applications for the Bewan ADSL PCI ST and USB modems Unicorn package provides the source code for the unicorn kernel modules and applications that can be useful to monitor the state of the Bewan ADSL modems. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems
On Mon, Apr 20, 2009 at 01:10:26AM +0200, Cyril Brulebois wrote: > Nick Leverton (19/04/2009): > > This is really an ITA for the existing unicorn and unicorn-source > > packages which were somewhat precipitately removed from Debian two > > weeks ago. > > Well, I don't call that precipitately: Hi Cyril, Thanks for your interest in my IT(re)P and your comments. > RoQA was end of january, fixed 2 months later. I don't call that > precipitated. And those reasons look quite good to me Of the stated reasons for removal: > | Please remove unicorn: > | - mostly unused (2 in popcon for the binary package unicorn) The unicorn binary package contains ancillary utils which are frankly of little use. A better metric for the use of driver packages such as unicorn would be the module source. Unicorn-source scores a not completely moribund 50 users. A better decision on the package's user base could have been gathered by considering all the packages built from unicorn, not just one of them. > | - unmaintained (last upload from a year ago) As mentioned in the removal proposal it was very hasty on those grounds alone. There are packages which haven't been uploaded since Etch, are they unmaintained as a result ? > | - doesn't build with Lenny kernel I had done considerable work on this following the discussion in #394465 and was preparing an NMU even as the removal was being considered. Just a ping on the bug would have got my attention rather than assuming the package was not being worked on. My NMU was already on Mentors seeking an upload when the package was actually removed. > | - not in Lenny Again, not of itself a reason for removal IMO, only if there were no action on it and it was hence unlikely to be in squeeze. Myself and others were working on updating it as seen in #394465 but didn't have time before the freeze. > | - depends on legacy libs (GTK 1.2), which will be removed soon Trivial to fix, took me about 2 hours once pointed out. No bug was raised on this issue beforehand; it's a reason for raising a fresh bug with a warning of removal, perhaps, but still not a reason for removal IMO. > | - lacks support for important archs like amd64 (#306322) This one is problematical to fix but not a reason for removal IMO as long as there are i386 users who need it (50 according to popcon, placing it almost 10,000 packages from the bottom ranking) My biggest beef with this removal is that no bug was filed against unicorn itself. I have been monitoring the package to see what bugs I could fix in my NMU. Had there been any hint that the above causes for removal were being considered I could have responded and dealt with them. But I think this removal was not even justified according to the stated grounds, and only allowing the last uploader 3 weeks to reply after a ping is perhaps a bit precipitate before deciding they are MIA. I can't speak for him but I certainly had email to him bounce at around that time, apparently due to to Sourceforge mail servers. I think that perhaps I should open a bug on the removal process, so that at least removal notices are filed against the actual package, and due time is given for other interested parties to respond. It is not as if the removal of unicorn was necessary to get a new release out or to enable some blocked transition involving hundreds of other packages. > > > * Package name: unicorn > > Version : 0.9.3 > > Upstream Author : Frode Isaksen > > * URL : http://www.bewan.com > > * License : GPL and Proprietary > ^^^ > > What the hell? Oh, that's for non-free, apparently, OK Yep. It's GPL interface code to a closed-source but redistributable binary, like many other bits of non-free. I intend to have another push at the distributor to get the closed-source bit opened, and if they won't then I hope I have sufficient experience to reverse engineer it if the Unicorn driver is still widely used by then. Others may disagree but I think it's more environmentally friendly to re-use old second hand hardware as I am doing, even if non-free when originally sold, rather than to create still more electronic waste. Anyway as I say, thanks for your interest and your time in responding. I hope I've addressed your comments fairly. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#524787: ITP: unicorn -- Drivers and applications for the Bewan ADSL PCI ST and USB modems
On Wed, Apr 22, 2009 at 03:49:46PM +0200, Cyril Brulebois wrote: > Nick Leverton (22/04/2009): > > Thanks for your interest in my IT(re)P and your comments. > > No problem. > > > Of the stated reasons for removal: > > > > > | Please remove unicorn: > > > | - mostly unused (2 in popcon for the binary package unicorn) > > > > The unicorn binary package contains ancillary utils which are frankly > > of little use. A better metric for the use of driver packages such > > as unicorn would be the module source. Unicorn-source scores a not > > completely moribund 50 users. > > Alright. I guess the person proposing the removal thought that the tools > were some kind of needed to get it working. I'm thinking of renaming the binary package as unicorn-utils for the next upload to make this clearer. It's going to go into NEW anyway. Though with only two popcon users I guess most people have figured it out :) It contains the natty GTK control/status app for the board though which I've done some work on. > > A better decision on the package's user base could have been gathered > > by considering all the packages built from unicorn, not just one of > > them. > > Sounds fair. Well I've discovered this may not be QA's oversight. For some reason the last upload didn't seem to link unicorn-source .deb to the unicorn source package. Don't know why not as they are both in the .dsc. > Yes, it's bad luck that your activity wasn't noticed. No worries. People running unstable should be prepared for packages popping in and out of installability. It's probably quantum ... > I guess this package might not have got a serious bug filed against > it/wasn't noticed when the first round of gtk1 MBF because it's in > non-free? > > Also, not all packages are trivially portable, quite the opposite from > what I've seen. Good luck it only took 2 hours. :) My hubris was too quick, I found some bugs due to the Glade1 templates generating some code which didn't work the same in GTK2. Getting rid of autoconf cruft from the .diff after running autoreconf took a while too :( > I think it might be worth adding an X-Debbugs-CC to the $package@ QA > address when filing removal with reportbug, and add that step to the > process. As you said, since you were monitoring this package, you would > have then been notified and had more chance to reply. Good idea. > > I think that perhaps I should open a bug on the removal process, so > > that at least removal notices are filed against the actual package, > > I'll take that topic to debian...@. I wouldn't want to mandate times because circumstances differ and the core teams do a great job anyway without adding constraints. I think a policy of filing a bug on the package would be sufficient "notice to interested parties". Doing so with some suitable bug-tag might also help to automate the remainder of the process, thus hopefully not adding to QA's work once the decision had been taken to remove a package as unused/unmaintained. By someone taking ownership of the bug they could declare an interest and forestall the process. However I wouldn't currently have time to learn debbugs and code this myself :) so I would understand if other stuff were more important. Hope I don't sound too legalistic. I think Debian's Developer and QA processes are two of its great strengths and the chief source of its consistently high quality. The prospect of Debian quality control helping us meet engineering standards is the reason I'm pushing Debian at work instead of our existing RH/Fedora lash ups. > > Anyway as I say, thanks for your interest and your time in responding. > > I hope I've addressed your comments fairly. > > No problem. I might nevertheless remove unicorn from m-a's > compliant.list (I plan to do some cruft removal in the next upload). > You're welcome to open a bug against module-assistant to have it > included back once your package reaches the archive (although I'm trying > to follow *-source package additions by myself). That'd be fine by me. I've re-packaged it to work with and indeed to build using module-assistant, but I want to make sure the package is great before re-introducing it. The motherboard with the card in seems to be buggy and causing IRQ problems. I need to try it in a different machine to be sure the drivers are OK, before uploading unicorn again. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: even root cannot read my symlinks!
On Sun, Sep 09, 2012 at 01:54:20AM +0100, Ben Hutchings wrote: > On Sun, 2012-09-09 at 06:06 +0800, jida...@jidanni.org wrote: > > I see. > > Who knows what they'll break next. > > Do you use any particular obscure features that I could suggest? Networking, keyboards, rotating media ... Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120909031700.ga26...@leverton.org
Re: directory under /usr/bin -- Ok or not?
On Mon, Nov 07, 2011 at 04:33:33PM +0100, Stig Sandbeck Mathisen wrote: > Josselin Mouette writes: > > > We already have $pkglibdir and $pkgdatadir for those. There is no > > technical need for a new directory in /usr, and it doesnt improve > > anything for users. > > Possibly not for the users, but it _certainly_ improves the environment > for system and application administrators. > > Some applications (for instance: inn and mailman) have a lot of > executables which only makes sense when you're in the context of that > application user, so having a /usr/libexec/ in the path for > that user makes life as an application administrator easier. That seems no different from having, say, /usr/lib/news/bin in the path, as at present. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2007180152.ga15...@leverton.org
Re: info please (on transitions and dependency levels)
On Wed, Nov 16, 2011 at 12:19:40PM +, Colin Watson wrote: > > Packages in level 2 build-depend on packages in level 1 (and so on up > the stack), so in general level 1 needs to be built before level 2. > > (This is mostly only of practical interest to people managing these > transitions, though.) Is there a usual way to generate the dependency level lists ? I ask because I have a transition coming up for one of my packages, which I am currently attempting to plan. Debtree can do it in nice graph format of course, but converting that to a written list might be error prone. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016135402.ga30...@leverton.org
Re: info please (on transitions and dependency levels)
On Wed, Nov 16, 2011 at 02:21:37PM +, Colin Watson wrote: > On Wed, Nov 16, 2011 at 01:54:02PM +0000, Nick Leverton wrote: > > > > Is there a usual way to generate the dependency level lists ? I ask > > because I have a transition coming up for one of my packages, > > Ask the release team; they use > http://anonscm.debian.org/gitweb/?p=collab-maint/ben.git;a=summary for > the purpose and should be able to add transition pages for you. Thanks Colin, I'll involve them at an early stage then. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016142957.ga3...@leverton.org
Re: Two groups of users, one distro in the middle
On Wed, Nov 16, 2011 at 06:48:02PM +0800, Paul Wise wrote: > > There is no one way to deal with this, we should only deal with this > on a case-by-case basis and use a number of strategies. ... > encourage our upstreams to rename and or work it out between them. If > they are willing, great, if not, add Conflicts to the Debian packages > and be done with it. Forcing the creation of a pair of > incompatibilities between Debian and upstreams doesn't help anyone. +1 Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016162308.ga1...@leverton.org
Re: from / to /usr/: a summary
On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote: > On 01/01/2012 03:11 PM, Russ Allbery wrote: > > Thomas Goirand writes: > >> The other sane way is to mark files not in /etc as conffiles. It > >> semantically sux a bit, but if we have no choice because of upstream > >> decisions (which we don't have enough time to fix), then that might be a > >> way... > >> > > That doesn't help unless you expect sysadmins to change them (unchanged > > conffiles are quietly updated just like any other package file), at which > > point it becomes an FHS violation. > > > I'd like to know: is it a normal thing to edit these files in > /usr/lib/udev/rules.d > (or, any other file that udev will use and which will be stored in /usr)? > Or should we expect that *never* anyone will touch them (eg: there's never > a real valid reason to edit them)? The latter. If you wish to override them, place the new file in /etc/udev/rules.d and the one in /usr/lib/udev won't be used. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101144201.ga5...@leverton.org
Re: from / to /usr/: a summary
On Fri, Jan 27, 2012 at 10:46:07AM +0100, Wouter Verhelst wrote: > > While I agree that forking upstream is not necessarily the right thing > to do, allow me to ask some things just so I understand things > better... > > Do I understand you correctly that an empty configuration file in /etc > will override its 'full' equivalent in /usr? I.e., just an empty file > full of comments saying "this is what you can do with this file" will > break some things? > If so, are there some things in udev which intrinsically depend on that > behaviour? I can give an example of this one. Placing an empty 75-persistent-net-generator.rules in /etc/udev/rules.d is the recommended way to prevent udev from allocating your network devices to fixed static MAC addresses (something it otherwise does which is the bane of a virtual machine admin's life, and which makes things generally harder when you want to help non-Linux people in swapping network cards over). Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127124040.ga32...@leverton.org
Re: Bug#666715: ITP: dedupdedup -- find duplicate programs for finding duplicate files
On Sun, Apr 01, 2012 at 04:40:22PM +0100, Lars Wirzenius wrote: > On Sun, Apr 01, 2012 at 05:08:06PM +0200, Tollef Fog Heen wrote: > > ]] Ben Hutchings > > > init systems? > > > > aekeech6 can, at least. > > Given that yours is written in C and is therefore inflexible, and mine's > in Python and therefore easy to hack, isn't it obvious that mine's going > to be better in the long run? > > Though I guess we could support both, and define an interchange format > for exchanging data between our two systems. Is there not a risk that they would dedupe each other ? Incidentally I note that dedupdedup has deduped this bug Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120401180733.ga19...@leverton.org
Bug#696690: ITP: mp3cat -- reads, writes, splits and combines MP3 files
Package: wnpp Severity: wishlist Owner: Nick Leverton * Package name: mp3cat Version : 0.5 Upstream Author : Tom Clegg * URL : http://tomclegg.net/mp3cat * License : GPL-2+ Programming Lang: C Description : reads, writes, splits and combines MP3 files mp3cat can read a stream from standard input and write to standard output. Instead of standard output, mp3cat can store MP3 data across multiple timestamped files in a directory (an "mp3dir") and another instance can follow the stream from there. . Also, mp3cat only outputs MP3 frames with valid headers, even if there is extra garbage in its input stream. This fixes up time/frame estimates in a stream created by simply concatenating mp3 files or by other utilities that add app-specific frames. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121225231950.ga30...@leverton.org
Re: Who is (co-)maintaining lcdproc package ?
On Mon, Mar 21, 2011 at 08:48:48PM +0100, Dominique Dumont wrote: > Depending on your answers, I'll upload a new version with an updated > maintainer/uploader list. (and with a correction in the bug list which is > missing commas) Hi Dominique and all, My situation is uncertain at the moment and I don't know if I'll be using LCDproc in future :-( Please go ahead and upload but I don't need to be an uploader at the moment. If I come up with another worthwhile contribution we can see about it perhaps :-) Thanks to everyone for the past and future maintainership of lcdproc, which was a major cross-distro contribution to the project. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110323204730.ga25...@leverton.org
