[kdepim-runtime/Applications/16.12] resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which failed to create std.ics if it didn't exist.
Ben Cooksley
bcooksley at kde.org
Sat Dec 24 02:05:15 UTC 2016
On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid <aacid at 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.
>
> 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.
>
>
More information about the release-team
mailing list