El divendres, 30 de desembre de 2016, a les 18:36:51 CET, Ben Cooksley va escriure: > On Thu, Dec 29, 2016 at 12:14 AM, Albert Astals Cid <aa...@kde.org> wrote: > > El dissabte, 24 de desembre de 2016, a les 15:05:15 CET, Ben Cooksley va > > > > escriure: > >> On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid <aa...@kde.org> wrote: > >> > So i guess we're in agreement that we need a new tarball? Or can we > >> > just > >> > tell distro packagers to patch it? > >> > > >> > My issue with a new tarball is that i will need to call it 16.12.0.1 > >> > (since i don't want to do 16.12.1 with just kderuntime-changes) and > >> > then > >> > distros are going to complain since it has one extra version, and since > >> > it's not a whole new release we again basically depend on distros > >> > picking > >> > up the new tarball. > >> > >> Whichever one works easiest for the packagers I guess. > >> > >> Considering the severity of this issue though (silent data loss) we > >> should probably make an advisory in about a month's time of which > >> distributions have failed to patch/upgrade their packages so users are > >> aware of the risk they are taking. > > > > We only have security advisories AFAIK > > https://www.kde.org/info/security/ > > > > What kind of advisory/way to make the world now were you thinking about? > > A press release of some description would do the job I think. > I'll admit i'm not sure of the form it should take though.
For now i'll just put it in the KDE Applications 16.12.1 in a relatively "prominent" place. Cheers, Albert > > > Cheers, > > > > Albert > > Cheers, > Ben > > >> > So may as well just ask them to patch it in? > >> > > >> > Cheers, > >> > > >> > Albert > >> > >> Cheers, > >> Ben > >> > >> > El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va > >> > > >> > escriure: > >> >> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote: > >> >> > Hey, > >> >> > > >> >> > mmh the description of your problem does not match with the commit > >> >> > you > >> >> > have > >> >> > pushed, or do i miss anything. > >> >> > >> >> The latter, I think ;) > >> >> > >> >> > Your patch is "only doing: > >> >> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path()); > >> >> > right? > >> >> > >> >> Right. > >> >> > >> >> > that means that we still have the problem with schema prefix in the > >> >> > url? > >> >> > >> >> No, fromUserInput supports both absolute paths and URLs, see API docs. > >> >> > >> >> > And than mCurrentUrl.isLocalFile() is not true and you'll do not > >> >> > enter > >> >> > that > >> >> > codepath? > >> >> > >> >> isLocalFile() will be true for local files and false for remote URLs, > >> >> I > >> >> don't see a problem here. > >> >> > >> >> > Just a little bit curious, why this is only a problem for a new > >> >> > user? > >> >> > >> >> Well, anyone without a ~/.local/share/apps/korganizer/ subdir, > >> >> which certainly includes new users. > >> >> > >> >> > On the other side I do not understand why the default local is > >> >> > import > >> >> > to > >> >> > trigger this bug. > >> >> > >> >> Parse error at "default local is import". Can you rephrase? > >> >> > >> >> > Btw. if the default location for korganzier has changed, than please > >> >> > update > >> >> > the defaultcalendar.desktop path. > >> >> > >> >> And break "Personal Calendar" for all users who copy their home dir > >> >> (but > >> >> not their akonadi setup) to another computer? Seems too dangerous to > >> >> me, > >> >> for zero gain. The korganizer in the path is historical anyhow, > >> >> korganizer no longer accesses std.ics directly, ever since akonadi 1 > >> >> came into play.