Bug#576029: ITP: angband-audio -- Non-free sound files for the angband game
Package: wnpp Severity: wishlist Owner: Chris Carr * Package name: angband-audio Version : 3.1.0 Upstream Author : Dubtrain * URL : http://www.dubtrain.com/angband * License : CC BY-NC-SA Programming Lang: n/a Description : Non-free sound files for the angband game Dubtrain has produced free high quality audio files for use with the angband package. His choice of licence means that they must be provided in Debian's non-free section. Since great efforts have been made to ensure that the main angband game can be provided under the GPL, it seems sensible to package the non-free sounds separately. -- 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/20100331143027.17346.12476.report...@baba.sadnet
Re: lilo removal in squeeze (or, "please test grub2")
On 25/05/2010 10:00, Harald Braumann wrote: Hi, On Sat, May 22, 2010 at 10:39:52PM -0500, William Pitcock wrote: (4) Users need to test grub2 now. I've been using grub2 for quite some time now on several different systems with mixed success. [snip] Because of this, coupled with the many open bugs and the lack of documentation, I'm not sure if grub2 is ready to be released to the unsuspecting public. Just to add my 2p, I have had significant, foreseeable, nonunique problems with grub2 on several machines (#495433, #508405, #518835 are merely the ones I reported). I would agree with Harald's assessment that grub2 is not ready. It appears from this thread that the maintainer status of grub2 is little better than that of lilo. It is therefore difficult to understand an argument in favour of removing lilo on the basis of a lack of maintainer(s), as that would also apply to grub2. Given the importance of a reliable boot loader and the severity and urgency of any significant bugs in one, it is no surprise that volunteer maintainers are hard to find. Would it be sensible to consider creating a "boot loader" team to maintain one or more boot loaders, instead of waiting for individuals to step up? CC -- 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/4bfba195.4050...@gmail.com
RE: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries
Are we in danger of making the best the enemy of the good? Packaging winetricks as-is would be helpful: making it a part of the packaging system, keeping it up-to-date, maybe adding a man page. Massive integration of distributable libraries into wine, and/or the creation of a wine-nonfree package with more of same, are great ideas. But they're also a lot more work than just packaging winetricks. So maybe let the simple one be done first, and take the pressure off those who need more time to do the trickier work? If the new winetricks package were to be called wine-nonfree, that would lay the foundations for later efforts ... Chris Carr > -Original Message- > From: Andreas Barth [mailto:a...@not.so.argh.org] > Sent: 05 September 2010 14:05 > To: Adam Borowski > Cc: debian-devel@lists.debian.org; 595...@bugs.debian.org > Subject: Re: Bug#595427: ITP: winetricks -- Quick and dirty > script todownload and install variousredistributable runtime libraries > > * Adam Borowski (kilob...@angband.pl) [100905 11:04]: > > It's a massive script, so the file count of 1 doesn't > really matter. Also, > > it needs to update more often than wine proper, as it > refers to outside > > locations. > > > > I'd vote for having it as a separate package. > > It'd rather make sense to create a wine-nonfree which includes the > libraries that we are allowed to redistribute, and downloads the > others. > > Then it makes of course sense to have it as an seperate package (and > with e.g. cmake I'm even not sure if we couldn't take the free version > of it into wine proper). > > In other words, there will be some massive integration effort into > debian, so winetricks won't look like the current script. Which is > something that should be done. > > > > Andi > > > -- > 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/20100905130527.gl15...@mails.so.argh.org > > -- 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/b585aca71ccf4f16ae9aa789a202d...@lbcamden.net
RE: Debian Installer 6.0 Beta1 release (WPA support)
> -Original Message- > From: Christian PERRIER [mailto:bubu...@debian.org] > Sent: 07 November 2010 06:44 > To: debian-devel@lists.debian.org > Subject: Re: Debian Installer 6.0 Beta1 release (WPA support) > > Quoting Thomas Goirand (z...@debian.org): > > > I also expressed my regret to not have enough time to work > on it myself > > (I'm currently trying to get this patch to work though...). > > > That is definitely useful. I'd suggest however to coordinate this in > -boot as there seem to be other people working on it. > > But I hope this is clear that, whatever achievements are made, we > won't consider the feature for squeeze. Still, enabling it (even > broken) just after squeeze will definitely be the first action to > take. I think it is a great shame that the existing patch has not been sufficiently tested for inclusion into Squeeze. It is undeniably embarrassing for one of the premier Linux distributions to ship without WPA support in its installer in late 2010 - it will likely be 2012 before the next release. I am not pointing any fingers and I take some shared responsibility for this failure. The question is, how can we learn from this mistake and avoid such embarrassment in future? I am not familiar with the d-i team's procedures, but would it be possible to proactively "call for testers" of a patch far enough in advance that people like me - who lurk on this list while maintaining only a single low-scoring package - could come out of the woodwork and send you some test results? This may well have been done only on debian-boot: I don't subscribe to debian-boot because the volume is unmanageable and I don't install very often. I suspect this might be quite a common situation for potential testers - perhaps it would be helpful to mirror requests for testing on debian-devel and/or on http://www.debian.org/devel/debian-installer/? Was a pre-built installer provided for testers or were they expected to roll their own? In 2006 I had a long email debate with Geert Stappers and the late Frans Pop about these issues: the difficulty of building your own installer and the steepness of that learning curve (as well as suggestions for splitting debian-boot into a high-volume list for most reports and a lower-volume list for discussion of installer internals). I see from the Debian wiki that there is more information available now than there was four years ago, but there is still a yawning chasm between being able to download and test an installer ISO and being able to check out the source, apply a patch and build your own. Looking back, would it have been better to apply the patch earlier and get more test results that way? I'm unsure on the d-i team's criteria for adding a new patch, but perhaps these could be reviewed so that patches like WPA are mainstreamed earlier and tested more widely? Or perhaps the installer should have "testing" and "unstable" versions so that not-fully-tested patches can be pre-built for people to test in "unstable"? These are just some thoughts. I hope the d-i team will take them as constructive and not offensive. My continued thanks to the entire team for their ongoing efforts to keep Debian excellent. Regards, Chris -- 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/109decfa7a2e4aa388c57a4fb3cbd...@lbcamden.net
Re: Why is help so hard to find?
On Sat, 2011-01-15 at 01:09 -0800, Mike Bird wrote: > On Sat January 15 2011 00:51:42 Neil Williams wrote: > > Mike, you missed the sarcasm completely and just went on another > > rant about two (unrelated) bugs which affect you directly. Guess what > > - I don't give two flying figs about those two specific issues because > > they don't affect me. I care about the underlying problem. > > We ran into those bugs while testing Squeeze and have for the most > part worked around them. We now know never to enable insserv. We > may even add some hacks to our systems to prevent sysv-rc from nagging > us. And we know to remove KDE 4 and install Trinity. Sorry to de-lurk with a tangential question, but how can I as an interested observer subscribe to the conversations where these decisions get made, and contribute views *before* things get to this stage? I have had the same frustrations as Mike and Roger with insserv, and although I don't use KDE I have a third example of this problem, where a deeply flawed "upgrade" broke several of my systems and the maintainers' response was basically "too bad" (GRUB2). Is there some forum in which the choice of a default for a package or service gets made? I subscribe to debian-devel and debian-policy, but neither seems to contain discussions about the risks of replacing perfectly good defaults with significantly flawed ones. On a completely separate note, where is the correct place to advertise for a new sponsor? I have not heard from mine for nine months, and I have a new version of my package and a new related package to upload. Thanks, CC -- 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/1295086204.2740.20.camel@junior.sadnet
Re: Why is help so hard to find?
On Sat, 2011-01-15 at 13:07 +0200, Andrei Popescu wrote: > On Sb, 15 ian 11, 10:10:04, Chris Carr wrote: > > > > Is there some forum in which the choice of a default for a package or > > service gets made? I subscribe to debian-devel and debian-policy, but > > neither seems to contain discussions about the risks of replacing > > perfectly good defaults with significantly flawed ones. > > "replacing perfectly good defaults with significantly flawed ones" > implies the respective maintainers are evil and trying to break your > system on purpose. You surely don't mean that, do you? Certainly not. There was an exchange in this thread about the pros and cons of insserv during which it was acknowledged that there are some significant issues with insserv. The previous paradigm may have been a "pain in the rear", but from the perspective of some proportion of users it was perfectly good. My assumption is that the issues with insserv were known before the decision to roll it out in Testing was made - my curiosity is about where those discussions took place. > BTW, I was quite aware that the mentioned changes are about to happen. I > also subscribe to debian-devel-announce. I am more interested in the discussions which precede the announcement, but thank you for the advice. Thanks also to Lars and Jonathan for their helpful responses. CC -- 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/1295167907.3417.7.camel@junior.sadnet
Re: Skilled manpower vs. grunt work
On 15/01/2011 22:18, Neil Williams wrote: Ben Finney wrote: Neil Williams writes: Can the rest of us now actually ask if there is anything we can do to get more people involved in helping packaging teams which are openly asking for help? […] The problem is a lack of manpower in critical teams. That's not new. Is the requirement for manpower alone? I thought the problem was a lack of manpower with the appropriate specific skills. Bug triage doesn't need huge amounts of package-specific skills. It just needs the people doing triage to be able to cooperate with the maintainer(s). [snip] Is there an obvious way for people willing to do grunt work to help such teams (as opposed to the highly skilled work done by the core people in the maintenance team) to find that grunt work and begin contributing? Skills can be learnt, taught and developed - the missing component is the person who can work alongside the existing team without lecturing those in the team and without pestering the team with newbie questions. That's fun for the whole team. The more hard-pressed the team, the harder it is for new people to learn the ropes. There's no answer to that problem except that new people must want to learn, not lecture. No matter what your expertise, the packaging team has different expertise and everyone needs to get along to fix the actual problem. I have had two experiences in this area: wanting to help get dmraid support added to d-i (2003-7) and wanting to add a new package to debian (#576029, which is now ready for upload). I am a competent sysadmin, but a novice programmer. In both cases I ended up "pestering the team with newbie questions" because of the complexities of d-i and of packaging, respectively - not because I was unintelligent or unmotivated, nor because I had failed to read the available docs. I would welcome advice on how non-programmers should approach working with volunteer maintainers who have vastly more knowledge and skill than we do. To me it seems a bit like trying to play squash with a pro: it's no fun for them, but if you don't have anyone intermediate to practice with, you'll never get better. I would happily volunteer to do bug triaging on certain packages, as I am certain I possess the skills to do this. Is it as simple as emailing the maintainer(s) and offering? CC -- 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/4d32e81a.5050...@gmail.com
Re: Why is help so hard to find?
On 15/01/2011 23:50, Russ Allbery wrote: Chris Carr writes: Is there some forum in which the choice of a default for a package or service gets made? I subscribe to debian-devel and debian-policy, but neither seems to contain discussions about the risks of replacing perfectly good defaults with significantly flawed ones. debian-devel contained *extensive* discussions about dependency-based boot and about insserv. I'm not sure how you could have missed them. Having followed those discussions at the time, I'm pretty confident that the switch was supported by the consensus of the people who chose to participate in those discussions. In which case I am in the right place, but simply not paying enough attention. My apologies for the noise. CC -- 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/4d32e845.3030...@gmail.com
