Bug#662599: libmail-imapclient-perl: FTBFS: Test suite failure
Hello Moritz, Perl release? I think this code test is very old, the load fails. Perl changes. t/bodystructure.t .. 1/41 Can't call method at on unblessed reference at /usr/share/perl5/Parse/RecDescent.pm line 3109. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662599: libmail-imapclient-perl: FTBFS: Test suite failure
Hi, t/bodystructure.t .. 1/41 Can't call method at on unblessed reference at /usr/share/perl5/Parse/RecDescent.pm line 3109. More likely Parse::RecDescent changes. https://rt.cpan.org/Public/Bug/Display.html?id=74733 We have to discover what change in Parse::RecDescent breaks the Mail-IMAPClient code. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: situation of imapsync and Debian
Hello, - do you want Debian to continue distributing your program (http://packages.debian.org/unstable/mail/imapsync)? No. I thank you very much for all the time and skill you spent packaging imapsync in Debian. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: apologize
Hello, I've made a mistake, I quoted a private message from Michael publicly and I apologise for it, I was wrong. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: how to live editing dfsg software?
Hello, Afaics this clearly violates the DFSG (either section 2 or 7), I've read carefully the DFSG and The first sentence of the first section says The license of a Debian component may not restrict any party from selling the software. Since you think imapsync *must* be gratis for all from anywhere (unless shame) you opinion clearly violate the first sentence of the first section of the DFSG. Who should blush his eyes with shame? I still wait your proposals about a better solution on how to live by writing and maintaining free softwares. Show me I'm stupid too, where and why. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: huge memory leak when syncing large mailboxes
Hello Michael, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609845 Yeah, I just noticed that imapsync is no longer free, which is a shame. It is very funny to see such an opinion from a Debian guy. You seem to ignore what means free in free software. Imapsync is still free software, the licence let you do what you want, distributing free, selling, changing, making it non-free, making it free as what any mean you put in free. You can even make it a GPL software, this is far away more free than any GPL software. Really free, no? So I have no shame about imapsync and won't ever have any. I thus won't further debug this and switch to an alternative instead. No problem, all the other free alternatives are listed in the imapsync README file. And since the issue comes from a perl module http://search.cpan.org/~plobbes/Mail-IMAPClient-3.25/ which is free open and gratis then your thus won't further is stupid. You're free to stay stupid and I do know that even imapsync were gratis you wouldn't have proposed any line of patch to correct the memory issue. Good luck with alternatives, some are really good, fast, with no memory issue. Stopping distributing imapsync gratis from the homepage is the best decision I could do to continue to maintain imapsync and help users. How do you earn your living with free software? I do earn my living by selling my free work and I prefer that than doing an alternative job on non-free software. If you have a better solution on how to live by writing and maintaining free softwares I will carefully read it and even try it, I promise. I do wait your proposals. PS: Phil I've just added your right address, the one from http://search.cpan.org/~plobbes/ has error back. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: huge memory leak when syncing large mailboxes
Hello Michael, I've been trying to sync a larger IMAP mailbox (~6Gb including all folders) and imapsync constantly gets terminated by the kernel OOM-killer because it takes up all available memory (1024 mb). This maybe a well known problem coming directly from libmail-imapclient-perl. The problem doesn't come with large mailbox but with large messages. imapsync uses memory nearly 17 times the largest message size. There is also an old memory issue on freebsd systems. This makes imapsync basically useless for me, so I was tempted to file with severity grave. Ok. You can fix this with --maxsize 1000 --useheader Message-Id or by buying a better tool or RAM or by fixing this memory problem, it is not a leak issue, the code written in Mail::IMAPClient does allocate inefficiently objects. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609845: huge memory leak when syncing large mailboxes
Hello Michael, As the memory usage constantly grew before imapsync getting killed, I assumed it was a mem-leak. I'm sorry if this assumption was wrong. I said maybe. Your tries with --maxsize will tell us. Given your comments, this means I probably have an email which is bigger than 60Mb. Yes. An other thing is that --ssl* can bring issues too. Use --tls* instead or nothing if possible. Recent imapsync releases prints info about memory usage but do not solve the issue. I think I'll add a ligne about the biggest message in each folder. Imapsync is still free DWTF software but not gratis from the homepage. As you say this is an issue in Mail:IMAPClient, I guess this bug should be re-assigned to libmail-imapclient-perl? A ticket exists already. Or can imapsync workaround this limitation in Mail:IMAPClient somehow? I try but I partially succeeded. I went to decrease 17 to 4 times but I got errors and I gave up. I need to read carefully the IMAP RFC before going on again. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553412: [imapsync] Crashes upon prompting for password on Squeeze
Hello RISKO, I see that currently the newest version on the webpage is 1.315, but as you previously stated probably you do not want this to be packaged. Which version do you want to be packaged? 1.315 is not a bad horse. Do you have specific instructions for the packaging? imapsync is no longer GPL software. It is WTFPL software. Please also send me an email anytime you want your package to be updated, because I can't figure it out on my own, if you do not state on your webpage if something is stable or not. In fact, theoretically I can't really state stable when I've just published a new version. In practice since I don't publish imapsync unless all non-regression passed you can consider latest release is stable. If you state the version to package, I will go ahead now with the packaging and updating. You can. You always can now. It could be a big problem when debian goes to stable with software with no regression tests. May I also ask you to have a look on these bugs to determine if they are fixed in the version you will suggest? Ok. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496256 (probably this was never an issue, just the reporter's IMAP server didn't support specific characters in folder names) The user didn't reply to my questions. I could not reproduce the bug and had no --debug nor error message to better understand the issue. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541237 1.315 now reconnects to server by default when server closes the connection with Mail-IMAPClient 3.xx and old 2.2.9 One guy is asking for specific GMail support: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503159 Do you plan to support this or should I say won't fix? I've just written this folder to label wish in the TODO file, among many other wishes. It doesn't mean will support. Thanks for your feedback and your work! PS: You can contact me using directly the imapsync mailing-list (or CC at least). It can interest other users. -- Au revoir, 09 51 84 42 42 Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553412: imapsync: keep imapsync package to Debian.
Hello RISKO, Sorry to speak up so late. No problem. I am really behind schedule about uploading a new version of imapsync, and am sorry about that, nowadays I do not find the time. If there is anyone willing to take a better care of the package, I am happy to hand over. I can. Since I complain about Debian packagers, the best thing should be I complain to myself. I don't know if there is a rule like an upstream developer must not package his own software. I also need to learn a little about Debian packaging and be accepted as packager. I know it isn't so easy. If not, I will try to make good care enough to keep you happy, of course it is not my intention at all to have bad relationship with the original author and I do not want you to have bad feelings about YOUR software in Debian. Ok. You're doing packages on your free time too. Of course, I am always open to your suggestions regarding versions to include, remove or anything else. If I do not react quick enough in BTS, feel free to write personal email to me, I am not hard to find :-) I use Debian but I don't use the imapsync package so I complain only when I receive Debian bug reports or bugs relative to debian release. Please state if you are still interested in having imapsync in Debian and which version would you like me to upload. If you have specific opinions about the Debianization, I am also open to those one. imapsync now support both 2.2.9 and 3.x Mail-IMAPCLient. A good thing could be to automate the debian packaging to stay up to date easily (one of the first thing I'll do if I were a packager). If I upset you so much that you do not want imapsync to be included at all, never again, I really regret that and apologise. In this case I contact the ftp-master team about the removal. imapsync is free/open software, even if I ask to remove it you can keep it in Debian or anywhere else, otherwise it wouldn't be free/open. But I do appreciate you took care of my opinion. -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553412: imapsync: Please remove imapsync package from Debian.
Hello Michael, Now it seems you are contradicting yourself. No problem. Packagers not reading INSTALL files are bad Of course. but packagers finding the dependencies by hand are bad too? No, I never said that. Packagers finding the dependencies by hand are good. Packagers finding the dependencies by hand and by using tools and by reading are good good good. Packagers never doing mistakes anyway how they proceed are good good good good++. (this kind of packager simply doesn't exist) [...] The dependencies happen to match exactly what you specify in your INSTALL file (except Digest::MD5 is missing, as this is now packaged with base perl). Conclusion: you have time to spend to write useless email like I do. And now to something productive: Debian should just upgrade to a newer upstream version to fix the bug. It's not productive since Debian stable never upgrade to a newer upstream version to fix a bug, unless for a security bug. Did you consider checking which releases of debian 1.286 is in? Hint: stable contains 1.252 See: http://packages.debian.org/search?keywords=imapsync Ok. That's worst than I though. Stable is two years old late (will be three or four until switch) The on the edge yeah Unstable is one year old late. Please remove imapsync package from Debian. We can conclude that debian stable is unstable by all the no-security then no-fixed bugs. This has upsides and downsides. Consider the admin that made an ugly workaround for a bug in stable, Why does he make an ugly workaround for a bug in stable? Because of a bug? A bug? Fix the bug or ask for a fix! Contact the upstream developer! that would break if the bug were fixed (which is a common property of bugs needing an ugly workaround). No. You take the issue by reverse. No rule never fix any bug in stable = no ugly workaround (or few few fewer). A workaround is a bug fix, a wrong one since something is changed, a fix is done, but the software is still the two years old unstable one. The good way to keep bugs and to be two years late: the Debian way. If an update withing stable suddenly fixes the bug, the workaround breaks. The idea of stable is to get security updates without having to worry about this kind of issues on update. Ok. Debian prefer bugs on bugs than fixing actual bugs. A matter of taste? Maybe. I know why Debian prefer bugs on bugs. Ugly workaround is just bad laziness. Since packagers don't contact upstream developers, I'm not surprised they do ugly workaround instead of actual fixes. It seems that the upstream softwares are diamonds no packager could ever try to fix. Did one Debian packager ever try to? The surprising thing is that the upstream developers received bug reports from actual users about ugly workarounds from lazy-fake-stable distributions. I do. And yes: I have been annoyed by unfixed bugs in stable, too, even up to the point of recompiling patched packages. Silly. Packages are a long time packager work made for users to spend less of their time. Not the contrary. One person spend several hours to avoid thousand hours spent by users, even if they spend less hours each than the packager. I was happy with Debian until woody, I could upgrade by remote without crossing my fingers. It was the only Linux distribution permitting this. Since Woody/Sarge I know I have to be in front ofthe computer to upgrade: I always have to fix some services, sometimes, the boot level. I have to become an expert for a time on some services. Thanks to me, I am. Thousand of users are not. Not happy with old and unstable Stable Debian? No problem. I switch to other free Unix distributions, on the edge and stable. -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553412: imapsync: Fixable by uncommenting 'use Term::ReadKey;'
Hello Michael, The problem is easily fixed by removing the comment sign before use Term::ReadKey;. I don't see why this line was commented out. Because there is a require when needed. This statement is untrue. In http://www.linux-france.org/prj/imapsync/dist/imapsync-1.286.tgz, there is a require when needed, but this one is commented out, too. Ok. A mistake by me. Because I know only one user needing it. The module is listed in the INSTALL file. I won't uncomment this line since there is no problem when packagers read and apply the INSTALL file. I don't see at all how this rant against packagers is related to the obvious bug in Version 1.286. It's not related. Other rant: Debian packagers must contact the upstream developer before packaging a release (guidelines). I've never received any contact octet, even for the first debian package. Consequences? I saw bad imapsync release going to stable for several years and generating useless debian bug report (or direct bug report). Wrong packager assumption: Last software release is the most stable one. Sometimes it is, especially when the release is a bugfix-only release. Most of the time it is not the most stable one. Who knows what is the most stable release? the upstream developer. If the automatic tools are not smart enough, get them smart by changing the 'grep use' with 'grep use or require'. Did you even bother to check whether debian uses automatic tools to find the dependency? Debian doesn't use automatic tools to find the dependency? That's worst than I though. And now to something productive: Debian should just upgrade to a newer upstream version to fix the bug. It's not productive since Debian stable never upgrade to a newer upstream version to fix a bug, unless for a security bug. We can conclude that debian stable is unstable by all the no-security then no-fixed bugs. -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553412: imapsync: Fixable by uncommenting 'use Term::ReadKey;'
Hello, Jens Dreger wrote: Package: imapsync Version: 1.286+dfsg-3 Severity: normal The problem is easily fixed by removing the comment sign before use Term::ReadKey;. I don't see why this line was commented out. Because there is a require when needed. Because I know only one user needing it. The module is listed in the INSTALL file. I won't uncomment this line since there is no problem when packagers read and apply the INSTALL file. If the automatic tools are not smart enough, get them smart by changing the 'grep use' with 'grep use or require'. Or give me better argument. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686-bigmem (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages imapsync depends on: ii libdate-manip-perl6.05-1 module for manipulating dates ii libdigest-hmac-perl 1.01-7 create standard message integrity ii libio-socket-ssl-perl 1.31-1 Perl module implementing object or ii libmail-imapclient-perl 3.21-1 Perl library for manipulating IMAP ii libterm-readkey-perl 2.30-4 A perl module for simple terminal ii perl 5.10.1-8 Larry Wall's Practical Extraction imapsync recommends no packages. imapsync suggests no packages. -- debconf-show failed -- debsums errors found: debsums: changed file /usr/bin/imapsync (from imapsync package) -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496256: imapsync: Does not sync folders which reflect an email address
Hello Florian, When an IMAP server contains a folder named like an email address syncing fails (e.g. folder name is [EMAIL PROTECTED]). It seems imapsync treats that name as the account name on the target IMAP server. Can create this folder [EMAIL PROTECTED] on target --host2 with another client? I created [EMAIL PROTECTED] and everything went well. I can't create foo.bar because . is reserved on my imap server. imapsync can't do what the imap servers can't. -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469978: Should not contain IMAPClient code
Hello, This bug is just a reminder to resolve this issue. I'm working on it. Six hours later, bugs are still there with the new IMAPClient code 3.05 -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458501: New version packaged, Mail::IMAPClient 2.2.9
Hello Andreas, I've packaged it with the new package name libmail-imapclient-perl-229 . I thank you very much for this job ! -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459759: libmail-imapclient-perl: imapsync doesn't work with Mail::IMAPClient 3.xx
Package: libmail-imapclient-perl Version: 3.02-1 Severity: important imapsync doesn't work with Mail::IMAPClient 3.xx imapsync works fine with Mail::IMAPClient 2.2.9 See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458501 All applications depending on Mail::IMAPClient work fine with old Mail::IMAPClient 2.2.9. At least one (imapsync) doesn't work with Mail::IMAPClient 3.xx On etch there are only 4 applications depending on libmail-imapclient-perl. So at least 25% are broken by this upgrade. Maybe Mail::IMAPClient 3.xx can stay on Unstable but it is strange to see it on Testing. imapsync will work with Mail::IMAPClient 3.xx and 2.2.9 together but now it only works with 2.2.9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459759: libmail-imapclient-perl: imapsync doesn't work withMail::IMAPClient 3.xx
Hello, Stop CC: too much, I received last message 4 times. [EMAIL PROTECTED] is enough. imapsync doesn't work with Mail::IMAPClient 3.xx imapsync works fine with Mail::IMAPClient 2.2.9 I haven't taken a deeper look into the code, but what's wrong with adapting imapsync to work with Mail::IMAPClient 3.x? Since old Mail::IMAPClient maintainer ended maintaining it, imapsync added some code patching bugs and still calling old good routines. Those calls don't work with 3.xx There's even a patch in the bugreport you quote. Not enough. And I still fail to see what _exactly_ is wrong in the new version of Mail::IMAPClient. The upstream author is very responsive but I guess my application doesn't work anymore is not enough to make him change the code. Yes, I said my application doesn't work anymore but I didn't say change the code. Changing the code is a bad idea. I just say to debian maintainers wait before upgrading to 3.xx since it breaks imapsync, that is to say 25% of reverse dependencies of libmail-imapclient-perl. Just wait, or better, reverse to the old working 2.2.9 one, at least for lenny/testing. Keep 3.xx work in /tmp/, it will work when imapsync is ready. imapsync will support 3.xx, 2.2.9, and everyone will be happy :-) for the moment, it doesn't. It is my last message about this, I won't fight with this problem anymore. I'll spend my time fixing/coding imapsync, knowing 3.xx adaptation is not a priority. It was but I spent to much time on this subject with the Mail::IMAPClient new maintainer, debugging his new code that could not work, knowing he told me it worked and suggested my environment was the problem, I really believed it, I was wrong :-) 3.xx might be good now and near a good link with imapsync. I need to adapt imapsync and my test suite to check that. Before that test, 3.xx is still beta code for me. 3.xx new maintainer has no regression test, I have and I respect them. Unlike this message suggests it, I'm happy and proud there is a new maintainer for Mail::IMAPClient, really. imapsync has a foundation : Mail::IMAPClient -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458501: imapsync: does not work under lenny: perl libMail::IMAPClient release 2.2.9 needed
Hello, Torsten Flammiger wrote: Package: imapsync Version: 1.219-1 Severity: important imapsync does not work anymore under lenny after an dist-upgrade some time ago. Versions of packages imapsync depends on: ii libdigest-hmac-perl 1.01-6 create standard message integrity ii libio-socket-ssl-perl 1.02-1 Perl module implementing object or ii libmail-imapclient-perl 3.00-1 Perl library for manipulating IMAP ii libterm-readkey-perl 2.30-3 A perl module for simple terminal ii perl 5.8.8-12 Larry Wall's Practical Extraction imapsync recommends no packages. I (author of imapsync) recommend not to use libmail-imapclient-perl 3.xx because it doesn't work with imapsync. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458501: attached patch for lenny
Hello, maybe i/we have to wait for a version which support Mail::IMAPClient 3.x The question is why upgrading to Mail::IMAPClient 3.x since every application depending on Mail::IMAPClient 2.2.9 works nice for several years, even though some application (imapsync) doesn't work with Mail::IMAPClient 3.x? 4$ apt-cache rdepends libmail-imapclient-perl libmail-imapclient-perl Reverse Depends: libmail-box-perl libkolab-perl ldirectord imapsync At least adopting Mail::IMAPClient 3.x without any test broke 25% of its reverse dependencies. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197914: acknowledged by developer(Tagging NMU closed linuxdoc-tools with the right version)
Hello, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #197914: linuxdoc-tools language problem. Hard coded english. patch given., which was filed against the linuxdoc-tools package. It has been marked as closed by one of the developers, namely Agustin Martin [EMAIL PROTECTED]. Ok. Thanks. It's never too late to apply that patch, 4 years later :-) -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417997: imapsync: Out of memory
Hello Paolo, patch for Makefile in 1.182-1.diff doesn't apply; that's trivial though, so now I've installed 1.217. Yes, imapsync is just a single script. Last release is directly found at http://www.linux-france.org/prj/imapsync/imapsync 1st try didn't work: now it hangs taking up 99.8% cpu right after start, after printing imapd doesn't support MD5 auth. That's solved adding opt --noauthmd5. Ok. I added a FAQ entry with this problem. I think it should just check and if imapd doesn't know MD5 auth just don't use it, unless explicitly told to do so. This used to be the behavior. There was a time imapsync exited in than case but I received two many complains. We also found servers not claiming they support some AUTH mechanism but actually supporting it. imapsync tries with the AUTH mechanism, and if this authentification fails then imapsync retries with a normal LOGIN authentification. So the problem here is the 99.8% cpu not stopping. I wonder why, what says strace ? Anyway, on 2nd try 1.217 tops at 153MB and completes without errors. So the OoM problem seems ironed out, thanks :) Good. +150MB still looks quite a lot to me. Yes. memory and speed is not the first imapsync goal. There are several tricks to improve memory and speed. --useheader 'Message-ID' is one. Perhaps imapsync .deb maintainer should resync 'unstable' with upstream. It's up to RISKO. The freebsd maintener updates the main port 2 days after each imapsync release. May be he uses a good Makefile doing the work easily. It may be bad sometimes but in that case the fix comes as soon as the new bug. Constructing packet takes time and energy. I'm not complaining about imapsync .deb maintener, RISKO Gergely, I'm glad he takes care about imapsync .deb. He arrived at the moment I decided to learn how to construct a .deb. So learning .deb is still in my todo list :-) In fact, for the main .deb port, the difficulty seems not technical, but social, having the keys to do it without knowing anyone in the debian team may take some time and energy. In Debian every change seems a heavy work. I don't know why but I understand why Debian is often 2 years late from the official software releases. For imapsync it's just 8 months, a good point. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417997: imapsync: Out of memory
Hello Paolo, Package: imapsync Version: 1.182-1 Severity: normal Out of memory! Try 1.217 -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 09 52 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363969: Spelling mistake in package description
Hello Risko, I've fixed the typo on my disk and published a new release, 1.188. revision 1.188 fixes several small bugs since 1.182 I also removed the rfc from the tarball. I'm updating the Makefile from your changes http://ftp.debian.org/debian/pool/main/i/imapsync/imapsync_1.182-1.diff.gz (for the next release) I can change many things to save your time like a debian/ directory, a .deb goal in the Makefile etc. Give me your wishes. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 08 72 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363969: Spelling mistake in package description
Hello, RISKO Gergely said : We believe that the bug you reported is fixed in the latest version of imapsync, which is due to be installed in the Debian FTP archive: ... That's wrong for imapsync on my harddisk, so it may be wrong for every imapsync in the world. -- Au revoir,02 99 64 31 77 06 20 79 76 06 Gilles Lamiral. France, Chavagne (35310) 08 72 27 33 66 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
