Re: switching from exim to postfix
On Mon, Apr 30, 2012 at 01:55:24PM BST, Adam Borowski wrote: > Not on a laptop or any machine that has to conserve power and avoid > unnecessary wakeups / disk spin-ups. Or any device with an SSD or SD card (more and more popular net-tops nowadays). > A cronjob every 5 minutes means you need to start up the process, which adds > quite a bit of churn. Worse, it will spam the logs, and since at least > auth.log is fsync()ed after every write, it needs to spin up the disk. This is the reason why I got rid of DMA on my systems, the defaults - cron job and unnecessary entries in the logs. Other than that I don't really have anything else against it. If those two get fixed it could be a sane default MTA (IMHO). Cheers, -- Raf -- 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/20120430171517.ga3...@linuxstuff.pl
New package doesn't fix the problem in the old version
Hi all, Recently I filed a bug report against git-stuff[0] which itself been closed with the explanation that it's a duplicate of an earlier bug[1] which itself has been closed by the maintainer claiming it had been fixed in version 5-1. While the new package indeed does not contain the bug itself when installed as a new package on a system which hadn't had it before, it does not fix the bug if installed on a system with the older version. As you can read in the first link, maintainer's not interested in including the fix for older versions. Widely available link[2] reads: Debian bug reports should be closed when the problem is fixed. Problems in packages can only be considered fixed once a package that includes the bug fix enters the Debian archive. The way I read it is: "the new version has to introduce the fix for older ones". You shouldn't need to remove older version and installing the new one after or even editing any files yourself if the new version allegedly fixes the issue. Since the new version doesn't override the file in question it cannot possibly treated as a fix. Unless I'm missing something? [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644017 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640016 [2] http://www.debian.org/Bugs/Developer#closing Regards, -- Raf -- 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/20111007151708.GA28182@thor.local
Re: New package doesn't fix the problem in the old version
On Fri, Oct 07, 2011 at 05:26:03PM BST, Bernhard R. Link wrote: > As I had problems of understanding this first let me recap the > situation: > > git-stuff before 5-1 created a buggy file when getting installed that > is still causing problems when git-stuff 7-1 is installed. > > So it's not so much a bug in 7-1 but 7-1 not tidy up the mess left by > earlier versions. That's correct. > As git-stuff was never released, those earlier buggy versions were > not released either, so only people installing unstable or testing > are effected. > > For not too serious stuff in unstable it is usually widely accepted > that people sometimes might have to clean things up themselves. > (Any cleaning code means the package is bigger for everyone and > any fix could go wrong and introduce new bugs). I've been using unstable exclusively for nearly 10 years. Most if not all packages I reported bugs for DO fix the issues caused by earlier versions, otherwise no one would use unstable if expected to fix everything by hand. I don't mind packages being broken, that's the reason why I use sid - to help develop Debian, find and report bugs, etc. > I'm not sure what the consensus for packages that were in testing > is (or if there was a consensus at all). I guess it mostly depends > on the time it was in testing and how complicated the fix is. > > The bug was only in testing for either for 50 days or for 25 days, > so it might depend how complex the fix is. It shouldn't matter that it's been in testing for so long, the bug's in unstable, and should be fixed there, even if doesn't reach testing in a long time. Both the bug and a fix are trivial - it's simply an entry in a cron job file - the links I've attached have all the relevant information. Regards, -- Raf -- 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/20111007172312.GA28774@thor.local
Re: New package doesn't fix the problem in the old version
On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote: > my opinion.. [cut] > * unstable and *testing* users are supposed to be able to cope with > the one or other glitch, if they don't, they use stable. I know that, thank you. I've been doing that for nearly a decade. > * this is a colossal waste of time. That might be true. All I was trying to do was to establish was whether you're being lazy/unhelpful or is there a policy which I've missed as, per my earlier email, I can't remember last time I filed a bug which later version hadn't corrected, no matter how trivial it was. Cheers, -- Raf -- 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/20111007174009.GA2944@thor.local
Re: New package doesn't fix the problem in the old version
Hi Ian, Thanks for taking the time to reply. > > > All I was trying to do was to establish was whether you're being > > > lazy/unhelpful or is there a policy which I've missed as, [...] I admit that I should have allowed a third possibility here. > There is a third possibility which is that the maintainer has made a > judgement that this bug is not worth going to special effort to fix in > the package. Policy does not need to be involved. My point is exactly that: "who makes the call?". It's not just about that package and that particular bug. Maybe there should be a clear policy, which should apply to all releases which are fully fledged (stable, testing, unstable[0]), on what is deemed to be called a bug fix - IMHO uninstall (purge rather) a package and install it again is not. Where should individual judgement end and a clear policy/good practice/standard way of doing things, start? If we scale it (might be a bit far-fetched, but it really isn't IMHO) we get to the point where personal judgement and opinion takes precedence over everything else and is quite harmful[1]. > The suggestion that someone is or might be "lazy/unhelpful" is not > appropriate. It should have read: "lazy or unhelpful or ..." but because of there being two "ORs" I shortened it. As mentioned above I think I should have included a possibility of a third one. This however doesn't change the fact that "lazy" or "unhelpful" are some of many human states of mind, and therefore I don't see it as inappropriate to enumerate them as one is perfectly entitled to them. Besides, I gave it only as an option and yes, should have included more to choose from. I didn't mean any harm by it. [0] experimental excluded for obvious reasons [1] http://blog.aurel32.net/?p=47 - while the blog post itself is valuable, the links included in there show exactly what I have in mind Ta, -- Raf -- 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/20111008060729.GA7757@thor.local
Re: New package doesn't fix the problem in the old version
On Sat, Oct 08, 2011 at 04:50:35PM BST, Stefano Zacchiroli wrote: > To nitpick a bit, your third possibility mentioned that the fix is "not > worth", but there are at least two sub-cases there: (1) maintainer does > not want to spend *their own time* preparing the fix, but would gladly > accept patches from others and (2) the maintainer does not want the fix > to reach user machines (e.g. because they consider the fix might make > things worse). The fix is trivial and it won't make things worse. Now probably not worth it but what could have been done in version 5-1: if [ -f /etc/cron.d/git-repack-repositories ] then sed -i 's/bin\/git-repack-repositories/bin\/git-repack-repositories-cron/g' \ /etc/cron.d/git-repack-repositories fi > Given Raf's interest in getting this particular issue fixed, I wonder > whether he has tried proposing a patch to the maintainer (there is no > trace of it in the buglog mentioned in this thread). Going that way can > be way more useful in actually improving the life of users affected by > the issue than this intriguing discussion about who *in theory* is > responsible of cleaning up old debris. No I hadn't as I've mentioned before, the fix is trivial and would have taken me longer to do that than the maintainer, who already knows his package and is dealing with debian packages on a daily basis, I on the other hand hadn't created any packages in years. > Share the code, we'll all be happier. :^) -- Raf -- 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/20111011191058.GA20160@thor.local
Re: daily build 24/11/11
On Fri, Nov 25, 2011 at 05:35:35AM GMT, Richard wrote: > I was always under the impression it was worth checking with others before > raising a bug, and keeping > the volume of bug request down. It is, not on debian-devel though. debian-devel - Development of Debian, Discussion about technical development topics. > I joined the list as I wanted to contribute something albeit regarded as a > waste. You meant right but in the wrong place. debian-boot is better suited for that. I recommend reading [0][1]. > Maybe best to unsubscribe Debian-devel might indeed not be what you were after. [0] http://www.debian.org/devel/debian-installer/ [1] http://wiki.debian.org/DebianInstaller/Today P.S. I know that debian-boot is not necessarily intuitive name. Regards, -- Raf -- 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/2025101417.ga14...@linuxstuff.pl
Re: ITP: ipmiutil -- Easy-to-use IPMI server management utilities
On Mon, Nov 28, 2011 at 08:58:42PM GMT, Andy Cress wrote: > It supports Windows servers, the others do not. So users who have mixed OS > environments would prefer ipmiutil. If that's true it's enough of a reason for me for it to be packaged. Regards, -- Raf -- 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/2028223355.ga2...@linuxstuff.pl
