Re: [Evolution-hackers] Maintenance fork for Evolution / EDS 2.32
On lun., 2011-04-04 at 08:53 +0200, Milan Crha wrote: > I objected against this many times, directly to you, on IRC, with no > effect, obviously. If I recall correctly, the reason why release-team > decreased releases is that distributions were *not* using .2 release. > Which is just the opposite you are trying to convince us. If they are > not using official releases, why should they use unofficial branch? In my (Debian) case, I usually upload .2 releases (and even .3). See http://packages.qa.debian.org/e/evolution.html Regards, -- Yves-Alexis ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.28 obsolete?
On jeu., 2011-01-27 at 12:11 -0500, Paul Smith wrote: > I don't think this answer will solve your problem in any way, but it is > nevertheless the correct answer: if you have a problem with a version of > Evolution provided by your distribution, then you should file a bug > against that package in your distribution's bug tracking system. For > Ubuntu, that would be Launchpad. For Red Hat/Fedora, I guess it would > be their bugzilla. Etc. I do ask Debian users to report upstream bugs into Evolution bugzilla because I don't have any way to fix them myself (except by cherry-picking upstream fixes anyway) and sadly don't have enough time for real good maintainership (I'm more or less the only maintainer in Debian). But you're right that those bugs may not be fixed if they are in an unsupported version (though supporting a version 6 months looks to me quite short). They still exist and shouldn't be closed (or at least with version information so it's easier for downstream to find a patch, even though it might not be backportable). For other downstream maintainers, I guess looking at Red Hat bugzilla might help too, since they are shipping evolution in RHEL and they do support it for quite a while. So backported patch might appear there. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution 2.28 obsolete?
On ven., 2011-01-28 at 02:06 +0100, Thomas Mittelstaedt wrote: > I'd suggest to you to build version 2.32 from git source on your ubuntu > LTS. See > http://mail.gnome.org/archives/evolution-list/2010-November/msg4.html and > http://mail.gnome.org/archives/evolution-list/2010-November/msg5.html. > If you are not familiar with building software from source, I or maybe a > few others on this list could assist you. Note that it's not really a solution for people usually concerned by an LTS distro. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] "Use secure connection" confusion
On lun., 2010-11-22 at 15:30 -0500, Matthew Barnes wrote: > On Mon, 2010-11-22 at 19:48 +0100, Yves-Alexis Perez wrote: > > As I understood it, SSL meant a tunneled connection over SSL/TLS, using > > the relevant port (995/pops, 993/imaps, 465/smtps, 636/ldaps). TLS means > > STARTTLS over a normal connection, so usually using the standard port > > (110/143/25/389). > > Thanks, that at least explains some of the original intent. It may well > be that mail accounts still work this way (I haven't looked closely yet) > but I've seen several address book and calendar backends whose behavior > appears to be basically "try a secure connection first, or else fall > back to a normal connection". I'll take a second look with this new > information in mind to make sure I haven't misunderstood something. Yeah, in my opinion there are two settings there * how secure should the connection be (always/if possible/never) * in the former cases: what kind of secure connection to use > > It's still quite confusing, especially since SSL is called TLS now since > > quite some time. > > Yeah, the labels need to be clarified regardless. But from a usability > perspective, I see no reason why the user interface needs to be any more > complex than a "use secure connection" checkbox. If that means we first > try a tunneled connection and then fall back to STARTTLS (or vice versa) > then that's fine, but we should do it *silently*. > > Plus we can easily record which method worked for a given mail account > or data source and try that method first next time. If picky users want > to control which method is tried first then, well, key files are easy to > edit. Im my opinion, the connection should be secure by default, with a fallback (and a warning asking for confirmation) if the secure connection can't be established (it might be sensible in some cases). For IMAP at least, STARTTLS can be detected in the capabilities returned by the server, so it might help too. Simplifying the settings is a good idea, but pretty please, no wizard à la thunderbird, it's *horrible*, everytime I need to use it I want to die. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] "Use secure connection" confusion
On lun., 2010-11-22 at 11:47 -0500, Matthew Barnes wrote: > >Use secure connection: SSL encryption > TLS encryption > No encryption > > But the backends that offer those choices all have a very different > interpretation of them: > >Use secure connection: Always > When Possible > Never > > First of all, why the disparity between the combo box label (first set) > and the actual meaning (second set)? I've never understood why I need > to choose between SSL and TLS encryption in the first place. Changing > these combo box labels to match their actual meaning strikes me as an > obvious improvement to help clarify things, or am I missing something > that's supposed to be implied by choosing between SSL and TLS? As I understood it, SSL meant a tunneled connection over SSL/TLS, using the relevant port (995/pops, 993/imaps, 465/smtps, 636/ldaps). TLS means STARTTLS over a normal connection, so usually using the standard port (110/143/25/389). It's still quite confusing, especially since SSL is called TLS now since quite some time. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Gnome 3.0 delay & Evo?
On 29/07/2010 13:32, Matthew Barnes wrote: > The question of what distros should ship would be better posed to the > GNOME release team, although from what they've said publicly so far I > don't think even they have a clear picture. Fedora 14 is moving full > steam ahead with a GTK+ 3.0 based desktop. Ubuntu had already stated > their fear and uncertainty over GTK+ 3.0 even before yesterday, so I > imagine they'll stay with GTK+ 2.x. I don't know what other distros > have planned. But Evolution 2.32 should be usable for everyone. > Speaking for Debian, the Squeeze plan is unchanged (we ship GNOME 2.30 anyway) so the GTK+ 3.0 transition will happen later. I guess we won't --enable-gtk3 for 2.32 anyway. Cheers, -- Yves-Alexis ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] XDG Base Directories -- Wrapping Up
On ven., 2010-07-23 at 18:08 -0400, Matthew Barnes wrote: > * Don't downgrade! Once you cross this threshold, it's going to > be > fairly painful to revert data files back to a state that > earlier > Evolution versions can understand. > > Each of the three binaries -- evolution, e-addressbook-factory, and > e-calendar-factory -- migrates its own data and then tries to remove > ~/.evolution, which only works if the directory is empty. The idea is > whichever program starts last should succeed. > An an evolution user and a packager, is this really a good idea? Shouldn't it be safer to keep it “as a backup” but mark it as already migrated. This way, another attempt can be tried should the first one fail, and we don't touch user valuable data. We already saw weird bugs with data loss during the sqlite migration, so I have to admit I'm a bit scared at this point :) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] LFS in evolution-data-server
On sam., 2010-07-10 at 07:00 -0400, Matthew Barnes wrote: > On Thu, 2010-07-08 at 14:19 +0200, Yves-Alexis Perez wrote: > > I recently enabled large file support in evolution-data-server in > > Debian. It seems that it leaded to the discover of some bugs on i386 > > installs (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580419 / > > https://bugzilla.gnome.org/show_bug.cgi?id=612082 and > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585921 / > > https://bugzilla.gnome.org/show_bug.cgi?id=619098) which leaded to crashes. > > After applying the patches in #612082 and the one-line fix in #619098, > are you still seeing reports of problems? It seemed to me the issue had > at least quieted down if not been fixed entirely. > It was a more generic questions. Those bugs are fixed, and it's better they are fixed than hidden. But if enabling LFS means codepaths not well tested are used and bugs are discovered, it's bad and good at the same time. Bad because we see nasty bugs which make evolution crash, good because rarely used codepaths are now used more often and those bugs can be identified and fixed. Now, would you recommend enabling LFS in Debian stable? I'm wondering, especially since it's not enabled by default. Cheers, and thanks for your time. -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] LFS in evolution-data-server
On jeu., 2010-07-08 at 14:19 +0200, Yves-Alexis Perez wrote: > Hey there, > > I'm the current evolution/eds/gtkhtml maintainer in Debian, and I'd like > to ask a question. Ping? Any idea on that? -- Yves-Alexis signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] LFS in evolution-data-server
Hey there, I'm the current evolution/eds/gtkhtml maintainer in Debian, and I'd like to ask a question. I recently enabled large file support in evolution-data-server in Debian. It seems that it leaded to the discover of some bugs on i386 installs (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580419 / https://bugzilla.gnome.org/show_bug.cgi?id=612082 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585921 / https://bugzilla.gnome.org/show_bug.cgi?id=619098) which leaded to crashes. Not all bugs are caused by LFS, but it seems that enabling it leads to use infrequent/less tested code paths, which lead to bug discovery. It seems like a good idea to fix bugs and not hide them, so I'm fine with that, but I have someone asking to disable LFS support for Squeeze (we're trying to freeze at the moment) so the bugs revealed by LFS support stay hidden. The bug asking for that is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588316 basically saying it's safer to disable it for now and re-enable it later in unstable. I'm not completely against disabling it (it wasn't enabled before, like in Lenny) but it's a release goal for us, and all in all it seems like a good idea to be able to support large files. I don't know if a lot of people have 2/4G+ files on their evolution install, and only 32 bit users are concerned (but that still means quite a lot of people), so I'd like to ask upstream advice on this. What do you think of the LFS support, should it be considered stable and enabled (and eventual bugs fixed asap) or should I still keep it disable for now? Thanks for your help, -- Yves-Alexis ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
