[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: [kdepim-runtime/Applications/16.12] resources/shared/singlefileresource:
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2016-12-30 5:36:51
Message-ID: CA+XidOGArZ_tGimp41geZohRscqvffLKiU9XJnZuSXohjVAq-A () mail ! gmail ! com
[Download RAW message or body]

On Thu, Dec 29, 2016 at 12:14 AM, Albert Astals Cid <aacid@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 <aacid@kde.org> wrote=
:
>> > So i guess we're in agreement that we need a new tarball? Or can we ju=
st
>> > 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 th=
en
>> > distros are going to complain since it has one extra version, and sinc=
e
>> > it's not a whole new release we again basically depend on distros pick=
ing
>> > 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.

>
> 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=C3=A9cembre 2016 10:29:03 CET Sandro Knau=C3=9F 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 en=
ter
>> >> > 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 use=
r?
>> >>
>> >> 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 impo=
rt
>> >> > to
>> >> > trigger this bug.
>> >>
>> >> Parse error at "default local is import". Can you rephrase?
>> >>
>> >> > Btw. if the default location for korganzier has changed, than pleas=
e
>> >> > 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.
>
>
[prev in list] [next in list] [prev in thread] [next in thread]