Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 03:14:05 CEST, Kevin Kofler wrote: not surprised that they are now using C99 comments (which ARE compliant to the current C standard, and have been for 16 years (!)). Sure, but since it seems it's the only C99 feature used(?, stdint is more a library thing, at least gcc more or less tagged it as such¹), this looks like an intended break. At least I completely fail to see the advantage of c++ style comments for a machine (rather the opposite, since "dumb" appending to lines can now produce undesired results) Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either we - raise the bar in kdelibs/KF5 to require a C99 compliant compiler (as a build dep requires it, "we just need //" isn't true - the requirements are controlled outside - ship only pre-produced and hand-fixed code from flex/yacc - pipe flex/yacc results through c++ rather than the C compiler Cheers, Thomas [1] https://gcc.gnu.org/c99status.html
Re: Generated files in version control (was: Re: Why is C90 enforced in KDE?)
On Montag, 7. Dezember 2015 01:08:31 CEST, Nicolás Alvarez wrote: It will look better to stick my app logo into the real-artist-designed piece-of-paper-with-shadow than to draw an icon from scratch... Afaiu, one should have asked the oxygen team to avoid this kind of patched icons. I don't think that's the case. Surely the preferred way to modify an icon is to edit the SVG and rasterize it again. Again: that's processing. The required file was the png (since svg icons were initially not even supported and even now the Qt svg renderer is completely not up to inkscape features extending vanilla svg) If you used gimp, you should put your multilayer .xcf **mt** - it's not simply "multilayer", that's just an intermediate result. The (hypothetical) icon was forged using several destructive processes to get the pixels colorful in the desired way - which are not documented anywhere. It could even haven been done in the very same layer or layer merging was one of the required process steps. A rastered image really completely rests in itself - no matter what tools were used to forge it. A vector editor is just a process detail; the same result could have been achieved in MS paint (with a lot of time ;-) Cheers, Thomas
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Kevin Kofler wrote: +1, of course we should not. Generated files have no business being in a source control or in source tarballs. "BuildRequires: flex" is one line in a distro specfile. Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced
On Friday, December 04, 2015 11:28:03 AM Jan Kundrát wrote: > On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote: > > Note that in the long run with DMARC looming you will need to switch > > to #2 anyway, and keeping your current behaviour will likely lead to > > mail from people who use Yahoo / AOL / etc ending up in the spam > > folder with many mailing list members. I'll be starting a discussion > > regarding taking this step on KDE systems at some point in the near > > future (switching to DMARC compatible policies). > > > > For more information, please see http://wiki.list.org/DEV/DMARC > > Do I understand your plan correctly? The following projects appear to not > re-sign their ML traffic, and they mangle headers at the same time. If I > understand your plan correctly, this means that I won't be able to use my > @kde.org addresses on mailing lists of these projects, for example: > > - Qt, > - Debian, > - Gentoo, > - OpenStack, > - anything hosted at SourceForge, > - and many, many more, essentially anybody who were ignoring DKIM. > > Please, change your plans, this is obviously a huge no-go. I cannot see how this would not hurt development. IMO, we can only enforce DMARC once all of our stakeholders support it or for those that do. We're not living in an isolated environment. We can be very strict and religious about standards and enforcing them, but in the end it's going to hurt us, and I don't think that's worth it at all. We'd simply be wasting energy we're putting into KDE, and that's not reasonable dealing with our resources. I think the lack of objections to this plan stems from almost nobody understanding what these plans actually mean for our development processes. The discussion happening around it is therefore not representative, and I think many who would have objected, haven't, for that reason. I can't say that I fully understand it myself. Please reconsider. Cheers, -- sebas http://www.kde.org | http://vizZzion.org
Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced
On Friday, December 4, 2015 11:28:03 AM CET Jan Kundrát wrote: > On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote: > > Note that in the long run with DMARC looming you will need to switch > > to #2 anyway, and keeping your current behaviour will likely lead to > > mail from people who use Yahoo / AOL / etc ending up in the spam > > folder with many mailing list members. I'll be starting a discussion > > regarding taking this step on KDE systems at some point in the near > > future (switching to DMARC compatible policies). > > > > For more information, please see http://wiki.list.org/DEV/DMARC > > Do I understand your plan correctly? The following projects appear to not > re-sign their ML traffic, and they mangle headers at the same time. If I > understand your plan correctly, this means that I won't be able to use my > @kde.org addresses on mailing lists of these projects, for example: > > - Qt, > - Debian, > - Gentoo, > - OpenStack, > - anything hosted at SourceForge, > - and many, many more, essentially anybody who were ignoring DKIM. > > Please, change your plans, this is obviously a huge no-go. this looks like a huge problem. Could this be rolled out in two phases: one where a big fat warning is added in some way, so that we can inform our mailing list masters about the breakage and then a slow enforcement? Kicking out kde.org from important stakeholders doesn't look right to me. And it's not like we would notice. It might take quite some time till we notice no longer incoming mails in mailing list folders. And not everybody read this thread and understood the implications. I do not know how to verify that a mailing list sends correctly and there are important mailing lists I'm subscribed to with low traffic. So: can we do something to notify non compliant mailing lists? And what if they don't act on it? If for example freedesktop.org is slow on it the solution cannot be to effectively kick out kde from freedesktop.org. I'm not going to subscribe there with my private mail address, because it's important to be there with an @kde.org address. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Why is C90 enforced in KDE?
Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: > Unfortunately, Linux distros aren't the main platform anymore for the > KDE software _I_ maintain. Given you've said this multiple times, with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. You may not care for Linux distros, but there are people who *do*. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: A29D259B
Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: Given you've said this multiple times, with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. I actually don't think this related at all. Compiling C99 (beyond some minor additions like the comments, but that's not guaranteed to be the only usage) on MSVC is a general problem to begin with (if you care about elder versions of what MS calls a "compiler"), so Boudewijn's primary problem is the usage of flex/yacc to begin with and he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc being translated to *.cpp (where "i build every shit and just guess what the developer meant" MSVC still sucks, but not that much) Distros and notably self-builders would probably prefer such as well (less build time dependency, yeah!), so there's no conflict. Otoh, developers will prefer to have flex/yacc in the CI and will require a cmake rule to include *.l & *.y in the source list (so it's regenerated on local changes) but otherwise there's (afaik) no strong reason to not simply ship the pre-translated sources (along the lex sources which are usually not invoked on build) The situation is (afaik) slightly different w/ *.moc since you might run into "the moc that generated this header is too old" issues (latter happens, so we can/should not ship pre-built mocs; but I'm not sure whether such problems can show up with lex as well) Cheers, Thomas, Baseball cap - I've not hats.
Re: Why is C90 enforced in KDE?
On Monday, December 07, 2015 04:33:37 PM Thomas Lübking wrote: > On Montag, 7. Dezember 2015 15:54:40 CEST, Luca Beltrame wrote: > > Given you've said this multiple times, with my packager hat on I'll just > > mention this: just don't make it harder *for us* to work just because > > you're targeting another platform. > > I actually don't think this related at all. > > Compiling C99 (beyond some minor additions like the comments, but that's not > guaranteed to be the only usage) on MSVC is a general problem to begin with > (if you care about elder versions of what MS calls a "compiler"), so > Boudewijn's primary problem is the usage of flex/yacc to begin with and > he'll prefer pre-translated C-fixed-to-90 (hello sed ;-) OR flex/yacc being > translated to *.cpp (where "i build every shit and just guess what the > developer meant" MSVC still sucks, but not that much) > > Distros and notably self-builders would probably prefer such as well (less > build time dependency, yeah!), so there's no conflict. > > Otoh, developers will prefer to have flex/yacc in the CI and will require a > cmake rule to include *.l & *.y in the source list (so it's regenerated on > local changes) but otherwise there's (afaik) no strong reason to not simply > ship the pre-translated sources (along the lex sources which are usually > not invoked on build) > > The situation is (afaik) slightly different w/ *.moc since you might run > into "the moc that generated this header is too old" issues (latter > happens, so we can/should not ship pre-built mocs; but I'm not sure whether > such problems can show up with lex as well) As long as you also ship the source, as a Debian packager, I'm happy. We have to have preferred form of modification and the ability to rebuild from that source. It's not 100% required that we rebuild, but how do you know you can, unless you do. I don't mind the additional dependency at all. My preference would be that on Linux, at least, if flex/yacc are detected, the rebuilding is automatic. Scott K
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Luca Beltrame wrote: Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. Given you've said this multiple times, Yes, and I'll go on saying it until I feel people are listening... Which I feel hasn't happened yet. with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. You may not care for Linux distros, but there are people who *do*. I care about Linux, I care for Linux distributions and I've always done. I hate having to work on OSX (especially OSX) or Windows, but I don't have a choice here. And if the KDE frameworks are supposed to be cross-platform, development needs to reflect that, and anything that's making life easy for a distribution should be weighed and considered and maybe rejected if it's making life harder for users of the KDE frameworks on other platforms. The alternative is doing what Gnome did: declare the KDE Frameworks Linux-only. That would be a clear, honest step to take, and I wouldn't actually oppose it. But it would put an end to the story that KDE Frameworks are just additions to Qt that everyone can use. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. Back on topic: do you actually have trouble with invoking flex/yacc* to generate code or do you have a problem with the generated (C99) code (what seems to be a pretty new problem - and is on Linux/any distro because KF5 does --std=c90)? Or was this just a general "Hey, there's a world beyond Linux" remark? You also may have some (personal, at least) data on relevant MSVC 2013 is in practice? Because every gcc in the wild as well as clang should be able to handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). Afaics, MSVC 2013 is the deal breaker here; but no warranty on that statement... Cheers, Thomas * other than "install it" - Windows doesn't come with a compiler by default either.
Re: Why is C90 enforced in KDE?
Am 07.12.2015 um 21:36 schrieb Thomas Lübking: > On Montag, 7. Dezember 2015 17:22:47 CEST, Boudewijn Rempt wrote: > >> There are two sides, of course: if making it easier for a distribution >> to package KDE software makes it harder for an application to be packaged >> for another distribution, where do we go? What's most important? Just >> adding a dependency because all linux distributions have it so it's no >> sweat can cause huge problems. > > Back on topic: do you actually have trouble with invoking flex/yacc* to > generate code or do you have a problem with the generated (C99) code > (what seems to be a pretty new problem - and is on Linux/any distro > because KF5 does --std=c90)? > > Or was this just a general "Hey, there's a world beyond Linux" remark? > > You also may have some (personal, at least) data on relevant MSVC 2013 > is in practice? > Because every gcc in the wild as well as clang should be able to handle > C99 - and so should MSVC 2015 and the intel compiler(s of the past). > Afaics, MSVC 2013 is the deal breaker here; but no warranty on that > statement... IIRC the problem here is(was) the version of flex/bison used. There was only a very outdated version of flex/bison available for a long time, and this one produced different results from a more modern version. When I looked last, there was a newer build available for both, which was recent enough and which also produced valid results (in at least some cases). I would recommend thus to test those two first, to see if there is a problem at that point at all (and if needed, then it is possible to decide that on a case by case basis - there shouldn't be to many flex/bison uses in total KDE code). About C99: I am not sure which compiler is currently required with MSVC, but if it is 2013 or below, then only some C99 features are supported. I tried to create a C99-to-C90 compiler with the help of clang, but this failed pretty early. So my advice would be to not make C90 default, but to allow some C99 features, but with improved CI instead. regards, Patrick
Re: Move ktp-call-ui to kdenetwork
El Wednesday 02 December 2015, a les 20:30:11, Diane Trout va escriure: > Hello, > > Thanks to contributions from several people we have a build of ktp-call-ui > that works with KF5 libraries. I've done some testing calling a few test > call services using SIP. > > ktp-call-ui commit 1e1ff29f5586861ff8454c504c6ab2cd3a7b82a7 should work for > others. > > Martin Klapetek suggested I email this list and ask "to move ktp-call-ui > from extragear to kde/network with the target release of kde apps 16.04" Urs what's your opinion as kdenetwork maintainer? Cheers, Albert > > Diane Trout
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 09:29:59 Thomas Lübking wrote: > Either way, Qt5 supports down to MSVC 2010, Qt4 down to MSVC 2008, so either > we Qt 5.6 supports MSVC 2008. Qt 5.7 raises the minimum to MSVC 2012. Neither compiler supports stdint.h or some other nice C99 functions, like isnanf. You need MSVC 2013 for that. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Why is C90 enforced in KDE?
On Monday 07 December 2015 21:36:13 Thomas Lübking wrote: > You also may have some (personal, at least) data on relevant MSVC 2013 is in > practice? Because every gcc in the wild as well as clang should be able to > handle C99 - and so should MSVC 2015 and the intel compiler(s of the past). > Afaics, MSVC 2013 is the deal breaker here; but no warranty on that > statement... MSVC 2013 has good support for C99. MSVC 2012 does not. I should point all that MSVC has supported // comments in C sources since before it was known as Visual. But that's not the problem. The problem is the C99 Library, which MSVC did not support until 2013 and it only did so because C++11 imported it by reference. Microsoft does not care for C. They didn't implement C99 because they didn't want to, not because their compiler team was unable to. So my recommendation: write C++ code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Change to Mail Infrastructure - SPF and DKIM verification will now be enforced
On Tue, Dec 8, 2015 at 2:19 AM, Martin Graesslin wrote: > On Friday, December 4, 2015 11:28:03 AM CET Jan Kundrát wrote: >> On Friday, 4 December 2015 10:56:42 CET, Ben Cooksley wrote: >> > Note that in the long run with DMARC looming you will need to switch >> > to #2 anyway, and keeping your current behaviour will likely lead to >> > mail from people who use Yahoo / AOL / etc ending up in the spam >> > folder with many mailing list members. I'll be starting a discussion >> > regarding taking this step on KDE systems at some point in the near >> > future (switching to DMARC compatible policies). >> > >> > For more information, please see http://wiki.list.org/DEV/DMARC >> >> Do I understand your plan correctly? The following projects appear to not >> re-sign their ML traffic, and they mangle headers at the same time. If I >> understand your plan correctly, this means that I won't be able to use my >> @kde.org addresses on mailing lists of these projects, for example: >> >> - Qt, >> - Debian, >> - Gentoo, >> - OpenStack, >> - anything hosted at SourceForge, >> - and many, many more, essentially anybody who were ignoring DKIM. >> >> Please, change your plans, this is obviously a huge no-go. > > this looks like a huge problem. Could this be rolled out in two phases: one > where a big fat warning is added in some way, so that we can inform our > mailing list masters about the breakage and then a slow enforcement? You can examine the "Authentication-Results" header from any mail that passes through kde.org mail infrastructure to determine if it is valid. These headers should be added by any system which is performing DKIM validation (even if it takes no action based on it) - Google at least also adds these headers. > > Kicking out kde.org from important stakeholders doesn't look right to me. And > it's not like we would notice. It might take quite some time till we notice no > longer incoming mails in mailing list folders. And not everybody read this > thread and understood the implications. I do not know how to verify that a > mailing list sends correctly and there are important mailing lists I'm > subscribed to with low traffic. You would still get the list subscription suspended message from the list, as these are generated by Mailman itself. They would only fail if they had tried to setup DKIM and made a mistake. > > So: can we do something to notify non compliant mailing lists? And what if > they don't act on it? If for example freedesktop.org is slow on it the > solution cannot be to effectively kick out kde from freedesktop.org. I'm not > going to subscribe there with my private mail address, because it's important > to be there with an @kde.org address. I would suggest mailing the list administrator or server administrator's of the mailing lists in question. Nobody else really has the power to fix it. The actual server administrators aren't required to take any action as long as you have the assistance of someone who can administrate the mailing list, at least with Mailman. You will only need the assistance of the server administrator if they've done something stupid - like enabling sitewide stripping of DKIM headers. In terms of what we should do - that will depend on their response > > Cheers > Martin Cheers, Ben
