Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/28/2018 02:06 AM, Manuel A. Fernandez Montecelo wrote: > The packages matching the search contain code matching *.qdoc for > example, not all necessarily invoke qdoc. Maybe one can restrict the > query to calls of qdoc from d/rules, but I think that there will be > indirect ways to use qdoc (like "make" in docs dir or something). >From what I understood, QDoc parses the source code and generates the documentation from the sources and additional comments placed into it. So, I guess the *.qdoc files you see there might be something else and it's just a naming clash. > Anyway, maybe I am misunderstanding the problem, but as I understand > it (don't know for sure) is that qdoc was there for a long time, it's > not a new thing, and what changed is that it now uses llvm/clang to > parse and generate doc instead of some internal code or other external > parsers. And the breakage for some ports is that not all of them have > support in llvm/clang, whereas presumably what they used before was > OK. Well, then we could hack something together using the old QDoc for Ports. But again, I don't think we need to build documentation in binary-arch targets. >>> Probably not all of these will actually use it for building (maybe >>> they will only test if available, and will generate an empty package >>> or something), others might do it only on -indep as Adrian says. >>> Almost certainly it will break some package. >> >> It shouldn't break any package. Again, building documentation in the >> binary-arch target should be considered a bug and get fixed. > > That's more or less what I said, in other words. I am convinced that > it will cause some breakage, because not all packages are perfect or > because of corner cases, only that uncovering the breakage is probably > a good thing in most or all cases, alerting about wrong practices. I agree. That's also one very good reason why having many different architectures in Debian are a good thing. It's tremendously useful to find obscure bugs which might not show on every target. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
2018-07-28 1:45 GMT+02:00 John Paul Adrian Glaubitz : > On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote: >> I was using codesearch.d.n and there are 83 that match "qdoc": >> https://codesearch.debian.net/search?q=%5CWqdoc%5CW > > Wait a minute. How can there be 83 packages already using qdoc when > Lisandro just uploaded the version of qttools to unstable which first > contained the qdoc utility. I am confused. The packages matching the search contain code matching *.qdoc for example, not all necessarily invoke qdoc. Maybe one can restrict the query to calls of qdoc from d/rules, but I think that there will be indirect ways to use qdoc (like "make" in docs dir or something). Anyway, maybe I am misunderstanding the problem, but as I understand it (don't know for sure) is that qdoc was there for a long time, it's not a new thing, and what changed is that it now uses llvm/clang to parse and generate doc instead of some internal code or other external parsers. And the breakage for some ports is that not all of them have support in llvm/clang, whereas presumably what they used before was OK. >> Probably not all of these will actually use it for building (maybe >> they will only test if available, and will generate an empty package >> or something), others might do it only on -indep as Adrian says. >> Almost certainly it will break some package. > > It shouldn't break any package. Again, building documentation in the > binary-arch target should be considered a bug and get fixed. That's more or less what I said, in other words. I am convinced that it will cause some breakage, because not all packages are perfect or because of corner cases, only that uncovering the breakage is probably a good thing in most or all cases, alerting about wrong practices. -- Manuel A. Fernandez Montecelo
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/28/2018 01:41 AM, Manuel A. Fernandez Montecelo wrote: > I was using codesearch.d.n and there are 83 that match "qdoc": > https://codesearch.debian.net/search?q=%5CWqdoc%5CW Wait a minute. How can there be 83 packages already using qdoc when Lisandro just uploaded the version of qttools to unstable which first contained the qdoc utility. I am confused. > Probably not all of these will actually use it for building (maybe > they will only test if available, and will generate an empty package > or something), others might do it only on -indep as Adrian says. > Almost certainly it will break some package. It shouldn't break any package. Again, building documentation in the binary-arch target should be considered a bug and get fixed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
2018-07-27 14:48 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer : > El viernes, 27 de julio de 2018 09:24:46 -03 Manuel A. Fernandez Montecelo > escribió: > > [snip] >> This page states that: >> >> http://doc.qt.io/qt-5/gettingstarted.html >> >> Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++ >> header and source files, and for parsing the function signatures in >> \fn commands. See Installing clang for QDoc for details. >> >> However, if it can be built without these doc tools, for example using >> Adrian's patch, it would be very nice to try. >> >> Not sure if it will break many packages (for these arches), packages >> might assume that qdoc tools are there, but the alternative is at least >> equally bad, and potentially worse. > > It will also mean that we Qt maintainers will start receiving valid bugs. > Considering the ratio of work and manpower we have now it's not something we > would like to deal with. Now if you can somehow chime in here, well, we can > make an arrangement of some type I guess. > > Maybe by opening a bug due to qdoc removal on some archs might help, you could > subscribe there if needed. OK, sounds fair, whatever the solution is implemented. I was using codesearch.d.n and there are 83 that match "qdoc": https://codesearch.debian.net/search?q=%5CWqdoc%5CW Probably not all of these will actually use it for building (maybe they will only test if available, and will generate an empty package or something), others might do it only on -indep as Adrian says. Almost certainly it will break some package. At that point we can intervene and explain to maintainers, or provide patches, for them to build it as -indep, so it's a win also for the wide Debian project (building -indep when possible, saving resources, etc). -- Manuel A. Fernandez Montecelo
Bug#904672: please package newer version - 4.7.0
Hi Roman! On Thu, 26 Jul 2018 at 10:12, Roman Lebedev wrote: [snip] > Dear maintainer, i'm sure that you are already aware that there is a new > released version of this amazing software - 4.7.0 yes, we are. > Please consider packaging it :) We do, as soon as manpower allows it. Thanks for waiting!
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
El viernes, 27 de julio de 2018 10:56:49 -03 John Paul Adrian Glaubitz escribió: > On 07/27/2018 03:51 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > >> I'm 99% sure it's not a hard dependency. It's a documentation utility. > > > > Which is then used by many packages, please check the other mail I have > > just sent. > > For building documentation in binary-arch packages? Again, we should not > allow that. It's a waste of disk space and buildd capacity, it's also > something that the QA tests will complain about. > > > [snip] > > > >>> If for some reason a package build it's doc on an arch-specific build it > >>> will FTBFS. > >> > >> Then this package is clearly buggy. Documentation is arch-independent and > >> should never be built per architecture. > > > > You have a point here. > > Ok, so you agree. Agreed on: packages should not be using qdoc while building arch:any packages. Yes, I agree. Let's wait for your build, but I think you will need to patch the build system too. By the way, qtcreator will start requiring clang too in the next upload. They ditched they internal parser in favor of clang, which is clearly better and more supported. As I understand this is a plugin, but I don't know how easy would be to turn it off, and if the previous parser will still be available. > > Mm, just noticed you sign as Adrian and not as John, will try to remember > > that. > > Yes, I go by Adrian despite the order. Don't ask why. My mother thought > it was funny :P. I have three names and two surnames, so believe me I have the feeling I understand you ;-) -- Never attribute to malice that which is adequately explained by stupidity. http://en.wikipedia.org/wiki/Hanlon's_razor Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
qtwebengine-opensource-src_5.11.1+dfsg-5_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 27 Jul 2018 10:28:56 -0300 Source: qtwebengine-opensource-src Binary: qtwebengine5-dev qtwebengine5-private-dev libqt5webengine5 libqt5webenginecore5 libqt5webenginewidgets5 libqt5webengine-data qml-module-qtwebengine qtwebengine5-dev-tools qtwebengine5-examples qtwebengine5-doc qtwebengine5-doc-html Architecture: source Version: 5.11.1+dfsg-5 Distribution: unstable Urgency: medium Maintainer: Debian Qt/KDE Maintainers Changed-By: Lisandro Damián Nicanor Pérez Meyer Description: libqt5webengine-data - Web content engine library for Qt - Data libqt5webengine5 - Web content engine library for Qt libqt5webenginecore5 - Web content engine library for Qt - Core libqt5webenginewidgets5 - Web content engine library for Qt - Widget qml-module-qtwebengine - Qt WebEngine QML module qtwebengine5-dev - Web content engine library for Qt - development files qtwebengine5-dev-tools - Qt WebEngine tools qtwebengine5-doc - Qt 5 webengine documentation qtwebengine5-doc-html - Qt 5 webengine HTML documentation qtwebengine5-examples - Qt WebEngine - Examples qtwebengine5-private-dev - Web content engine library for Qt - private development files Changes: qtwebengine-opensource-src (5.11.1+dfsg-5) unstable; urgency=medium . * Team upload. * Add fix-gcc-8-i386.patch to solve an alignment issue on i386. * Update symbols files with buildds' logs. Checksums-Sha1: db4ee34bbd9c4d0ac75d3165140fced3d8196638 4622 qtwebengine-opensource-src_5.11.1+dfsg-5.dsc 4c452c9a7d29903b0b3ab86915b4a9d6bac0ce97 463924 qtwebengine-opensource-src_5.11.1+dfsg-5.debian.tar.xz 5b55b118377a1e63334ee0df58dd856b91c00c2e 13662 qtwebengine-opensource-src_5.11.1+dfsg-5_source.buildinfo Checksums-Sha256: d48f47aaf126793820b0185c7dbb05f4341aabe7323c8a003e4e950fc40538d9 4622 qtwebengine-opensource-src_5.11.1+dfsg-5.dsc 272abefcafc4982af91af537b73bb3feff69eb952f8ea1a6786b15b79381c9c5 463924 qtwebengine-opensource-src_5.11.1+dfsg-5.debian.tar.xz 52b1a4023b005d4619c6cea23e5cdc8491fb4f3ccf81af77ea543fc087eed358 13662 qtwebengine-opensource-src_5.11.1+dfsg-5_source.buildinfo Files: 3fd11e38a8addd4e082123f0b63348ef 4622 libs optional qtwebengine-opensource-src_5.11.1+dfsg-5.dsc 89e0b9384925577334abd5164d3640fe 463924 libs optional qtwebengine-opensource-src_5.11.1+dfsg-5.debian.tar.xz b828d17d03e0b531c898650759c8 13662 libs optional qtwebengine-opensource-src_5.11.1+dfsg-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEEEt36hKwjsrvwSzE8q2RfQGKGp9AFAltbHzoUHGxpc2FuZHJv QGRlYmlhbi5vcmcACgkQq2RfQGKGp9D9whAAjA9dRwycgTv9YMeoFU9m6bXvADmD Aqw85Vkp2evssnPpn4Ng0IuSrYrwP2Ec/0KudwkRNSoeTku/+x4Aqln9Rlb7dzZZ fd3wEQVh5pEg0qJzF4f/0mYJj2urcUZvy1WlhIp4So5TvgFqlGdM5C0ZYMs1b1KC kG1Xxm0Z/9oXldGTuVxscFub5LRg/ZVUPzKjSAeskMg/4tfqFYXuX25kB3Jq5LJA Q6v/8OcYG5nowv7cSiJ+1CXysi+nNMrvah3cb9aHSp+XtHN6WUBp6QWc3STS5IeA Iu/A8bAV6xHOQN84xFh1WB3cKRRM1UiMGAhdcq6rjSiEnxPL5OoZcZfaYy2eeF61 htXEFcbnLZzvQBkV5Ci7gEFA593WgdJ6FyFKfZ5+MbykC51Ocgimu53r73Q9uOsD 3zNWQkEoDGL+0/0wXMFEDDY0kfIV+j7RPC0JvF8S7alkcVFGXA2ptSQFcNioy7n8 p2pFTXh2g8yFgTNpqzmXmZcAsEcyztcYKwsjzasMxcX8X7ImRmnL/CA2xiX85DzU urPqH8G1cqtNJs+szrE6NCJqOYy8EBWMnTqoScQpBx5/NI7QYV5ymvdyIVx+X6Lf QGtGx39Xn3O2NTM4Wc/qTmlukeoGiKmmTwVwxdAnnAYE/RuoBvLKIjL95izA+Op5 eZ5Cq1zmm2oGykg= =fIX8 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of qtwebengine-opensource-src_5.11.1+dfsg-5_source.changes
qtwebengine-opensource-src_5.11.1+dfsg-5_source.changes uploaded successfully to localhost along with the files: qtwebengine-opensource-src_5.11.1+dfsg-5.dsc qtwebengine-opensource-src_5.11.1+dfsg-5.debian.tar.xz qtwebengine-opensource-src_5.11.1+dfsg-5_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/27/2018 03:51 PM, Lisandro Damián Nicanor Pérez Meyer wrote: >> I'm 99% sure it's not a hard dependency. It's a documentation utility. > > Which is then used by many packages, please check the other mail I have just > sent. For building documentation in binary-arch packages? Again, we should not allow that. It's a waste of disk space and buildd capacity, it's also something that the QA tests will complain about. > [snip] >>> If for some reason a package build it's doc on an arch-specific build it >>> will FTBFS. >> >> Then this package is clearly buggy. Documentation is arch-independent and >> should never be built per architecture. > > You have a point here. Ok, so you agree. > Mm, just noticed you sign as Adrian and not as John, will try to remember > that. Yes, I go by Adrian despite the order. Don't ask why. My mother thought it was funny :P. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
El viernes, 27 de julio de 2018 10:33:48 -03 John Paul Adrian Glaubitz escribió: > On 07/27/2018 02:22 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > > Don't get me wrong: I also don't like build depending on LLVM [1], but it > > became a hard dependency. Again, I haven't looked at the code yet (I'm > > over > > the transition now), so I'm purely guiding myself from what one of my co > > maintainers did (and he happens to be in vac). > > > > But what can we do if it became a hard dependency? > > I'm 99% sure it's not a hard dependency. It's a documentation utility. Which is then used by many packages, please check the other mail I have just sent. [snip] > > If for some reason a package build it's doc on an arch-specific build it > > will FTBFS. > > Then this package is clearly buggy. Documentation is arch-independent and > should never be built per architecture. You have a point here. > > But on a second thought you might want to tackle those packages yourself. > > If you like that idea well, we need a patch to disable qdoc compilation > > probably. > You don't need to disable QDoc completely. Just use it in a reasonable > way. > > >>> The only way around I see is submitting patches upstream to avoid clanf > >>> usage. Remember they need to go directly to upstream, we can't forward > >>> then > >>> except for very small changes. > >> > >> Strange policy. Lots of people here take patches from the bugtracker and > >> forward them upstream. In fact, that's what the official Debian > >> documentation says. > > > > Yes, but upstream has a CLA in which you don't give copyright permissions > > *but* allow the Qt Company to use the submitted code in their proprietary > > version, your code remaining FLOSS for every other aspect. > > *sigh* CLAs suck Yes, they do. > > The way they enforce that is by making the real coders push their work to > > their gerrit instance, for which you previously have to agree to the CLA. > > Yes. I know the deal. > > >> Either way, there are plans to make LLVM available on more targets, there > >> are already branches working on alpha, m68k, riscv64 and more. Until > >> then, > >> it would be nice if Qt wouldn't have a hard dependency on it solely to > >> build documentation. > > > > Again: I would *love* to. But to the best of my knowledge now, we can't. > > Of > > course, I'll be delighted to learn I'm wrong :-) > > I will take care of that - like always :P. I like that :-) > Adrian Mm, just noticed you sign as Adrian and not as John, will try to remember that. -- Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer a la comunidad SL como una sarta de fanáticos que viven dentro de un tupperware. Pablo Di Noto - GrULiC Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
El viernes, 27 de julio de 2018 10:28:20 -03 John Paul Adrian Glaubitz escribió: > On 07/27/2018 02:48 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > > It will also mean that we Qt maintainers will start receiving valid bugs. > > Considering the ratio of work and manpower we have now it's not something > > we would like to deal with. Now if you can somehow chime in here, well, > > we can make an arrangement of some type I guess. > > I'm not sure what problem you are seeing here but I don't think that a > missing documentation generation tool will have any negative impact on > binary-only builds. > > qttools itself is only using qdoc in its binary-arch-indep target why should > that be any different for any of the other Qt packages? qdoc is generated two times: one during the binary build in order to ship it so other packages can create .qch documentation, and the other during the indep build in order to generate qttool's own .qch documentation. > > Maybe by opening a bug due to qdoc removal on some archs might help, you > > could subscribe there if needed. > > I'm not sure I understand this statement. If qdoc is not there in the first > place, how can it be removed? Does the explanation above solves this? Please do not hesitate in asking me again, I want this to be clear. > >> I think that this is similar to the case discussed in #897667, not being > >> able to build qt4-x11 makes big portions of the archive unbuildable, > >> many thousands of packages. Not being able to build > >> qttools-opensource-src will have a similar effect, I think. > > > > Yes, I'm afraid so. But first we would need patches. I doubt John's patch > > will work as I think Dmitry built the package first, FTBFS and then he > > added the llvm dependency. And if qdoc is not being built the .install > > files need also adjustment. > > The debian/rules file is already written such that it will not build any > documentation when DEB_HOST_ARCH != DEB_BUILD_ARCH, so unless Dmitry put > these statements there without any testing, I'm sure you can build qttools > without qdoc. Right, qttools but not the other docs. > > But again, I'll be happy to be shown otherwise. > > Working on it. Waiting for the build dependencies to get built. Excellent :-) -- perezmeyer: Gus no tiene inet :-( PabloOdorico: oh perezmeyer: te mando una copia de lo que hagamos esta noche PabloOdorico: de ultima mandame un loro del parque con una flash en la pata ;) Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/27/2018 02:22 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > Don't get me wrong: I also don't like build depending on LLVM [1], but it > became a hard dependency. Again, I haven't looked at the code yet (I'm over > the transition now), so I'm purely guiding myself from what one of my co > maintainers did (and he happens to be in vac). > > But what can we do if it became a hard dependency? I'm 99% sure it's not a hard dependency. It's a documentation utility. >>> I haven't looked at the code but it seems that this dependency is now >>> required in order to build qdoc, so reducing the severity to wishlist. >> >> Well, it's a documentation tool. It should just be possible to disable >> the documentation tool on the affected architectures. > > It's the tool to generate documentation. Exactly. And documentation is built in arch:all only anyway. >>> I don't know if it's possible at all to build everything but qdoc. And the >>> effect of this could be many packages starting to FTBFS. >> >> Unlikely. I don't know any project that has a hard dependency on >> documentation. > > No no, not the documentation itself, but the tool to create it! Yes, but you can (and should(!)) build documentation in the binary-arch-indep target. > If for some reason a package build it's doc on an arch-specific build it will > FTBFS. Then this package is clearly buggy. Documentation is arch-independent and should never be built per architecture. > But on a second thought you might want to tackle those packages yourself. If > you like that idea well, we need a patch to disable qdoc compilation probably. You don't need to disable QDoc completely. Just use it in a reasonable way. >>> The only way around I see is submitting patches upstream to avoid clanf >>> usage. Remember they need to go directly to upstream, we can't forward >>> then >>> except for very small changes. >> >> Strange policy. Lots of people here take patches from the bugtracker and >> forward them upstream. In fact, that's what the official Debian >> documentation says. > > Yes, but upstream has a CLA in which you don't give copyright permissions > *but* allow the Qt Company to use the submitted code in their proprietary > version, your code remaining FLOSS for every other aspect. *sigh* CLAs suck > The way they enforce that is by making the real coders push their work to > their gerrit instance, for which you previously have to agree to the CLA. Yes. I know the deal. >> Either way, there are plans to make LLVM available on more targets, there >> are already branches working on alpha, m68k, riscv64 and more. Until then, >> it would be nice if Qt wouldn't have a hard dependency on it solely to >> build documentation. > > Again: I would *love* to. But to the best of my knowledge now, we can't. Of > course, I'll be delighted to learn I'm wrong :-) I will take care of that - like always :P. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/27/2018 02:48 PM, Lisandro Damián Nicanor Pérez Meyer wrote: > It will also mean that we Qt maintainers will start receiving valid bugs. > Considering the ratio of work and manpower we have now it's not something we > would like to deal with. Now if you can somehow chime in here, well, we can > make an arrangement of some type I guess. I'm not sure what problem you are seeing here but I don't think that a missing documentation generation tool will have any negative impact on binary-only builds. qttools itself is only using qdoc in its binary-arch-indep target why should that be any different for any of the other Qt packages? > Maybe by opening a bug due to qdoc removal on some archs might help, you > could > subscribe there if needed. I'm not sure I understand this statement. If qdoc is not there in the first place, how can it be removed? >> I think that this is similar to the case discussed in #897667, not being >> able to build qt4-x11 makes big portions of the archive unbuildable, >> many thousands of packages. Not being able to build >> qttools-opensource-src will have a similar effect, I think. > > Yes, I'm afraid so. But first we would need patches. I doubt John's patch > will > work as I think Dmitry built the package first, FTBFS and then he added the > llvm dependency. And if qdoc is not being built the .install files need also > adjustment. The debian/rules file is already written such that it will not build any documentation when DEB_HOST_ARCH != DEB_BUILD_ARCH, so unless Dmitry put these statements there without any testing, I'm sure you can build qttools without qdoc. > But again, I'll be happy to be shown otherwise. Working on it. Waiting for the build dependencies to get built. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
El viernes, 27 de julio de 2018 09:24:46 -03 Manuel A. Fernandez Montecelo escribió: > Hi, Hi Manuel! [snip] > This page states that: > > http://doc.qt.io/qt-5/gettingstarted.html > > Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++ > header and source files, and for parsing the function signatures in > \fn commands. See Installing clang for QDoc for details. > > However, if it can be built without these doc tools, for example using > Adrian's patch, it would be very nice to try. > > Not sure if it will break many packages (for these arches), packages > might assume that qdoc tools are there, but the alternative is at least > equally bad, and potentially worse. It will also mean that we Qt maintainers will start receiving valid bugs. Considering the ratio of work and manpower we have now it's not something we would like to deal with. Now if you can somehow chime in here, well, we can make an arrangement of some type I guess. Maybe by opening a bug due to qdoc removal on some archs might help, you could subscribe there if needed. > I think that this is similar to the case discussed in #897667, not being > able to build qt4-x11 makes big portions of the archive unbuildable, > many thousands of packages. Not being able to build > qttools-opensource-src will have a similar effect, I think. Yes, I'm afraid so. But first we would need patches. I doubt John's patch will work as I think Dmitry built the package first, FTBFS and then he added the llvm dependency. And if qdoc is not being built the .install files need also adjustment. But again, I'll be happy to be shown otherwise. Cheers, Lisandro. -- I must confess, I was born at a very early age. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
Hi John! El viernes, 27 de julio de 2018 07:34:16 -03 John Paul Adrian Glaubitz escribió: > > Control: severity -1 wishlist > > Setting a bug which breaks multiple architectures is somewhat of an > understatement. Don't get me wrong: I also don't like build depending on LLVM [1], but it became a hard dependency. Again, I haven't looked at the code yet (I'm over the transition now), so I'm purely guiding myself from what one of my co maintainers did (and he happens to be in vac). But what can we do if it became a hard dependency? [1] Except some day they keep their API/ABI stable... > > I haven't looked at the code but it seems that this dependency is now > > required in order to build qdoc, so reducing the severity to wishlist. > > Well, it's a documentation tool. It should just be possible to disable > the documentation tool on the affected architectures. It's the tool to generate documentation. > > I don't know if it's possible at all to build everything but qdoc. And the > > effect of this could be many packages starting to FTBFS. > > Unlikely. I don't know any project that has a hard dependency on > documentation. No no, not the documentation itself, but the tool to create it! If for some reason a package build it's doc on an arch-specific build it will FTBFS. But on a second thought you might want to tackle those packages yourself. If you like that idea well, we need a patch to disable qdoc compilation probably. > > The only way around I see is submitting patches upstream to avoid clanf > > usage. Remember they need to go directly to upstream, we can't forward > > then > > except for very small changes. > > Strange policy. Lots of people here take patches from the bugtracker and > forward them upstream. In fact, that's what the official Debian > documentation says. Yes, but upstream has a CLA in which you don't give copyright permissions *but* allow the Qt Company to use the submitted code in their proprietary version, your code remaining FLOSS for every other aspect. The way they enforce that is by making the real coders push their work to their gerrit instance, for which you previously have to agree to the CLA. So, as we are not the real coders behind patches submitted to us, we can't forward them *except* when the patch is so small that it is not copyrighteable (a few lines of obvious code, for example). > Either way, there are plans to make LLVM available on more targets, there > are already branches working on alpha, m68k, riscv64 and more. Until then, > it would be nice if Qt wouldn't have a hard dependency on it solely to > build documentation. Again: I would *love* to. But to the best of my knowledge now, we can't. Of course, I'll be delighted to learn I'm wrong :-) Regards, Lisandro. -- The POP3 server service depends on the SMTP server service, which failed to start because of the following error: The operation completed successfully. -- Windows NT Server v3.51 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
Hi, 2018-07-26 21:48 Lisandro Damián Nicanor Pérez Meyer: Control: severity -1 wishlist Hi Thorsten! El jue., 26 de jul. de 2018 14:03, Thorsten Glaser escribió: Source: qttools-opensource-src Version: 5.11.1-3 Severity: important Justification: fails to build from source (but built successfully in the past), on d-ports arches https://buildd.debian.org/status/package.php?p=qttools-opensource-src LLVM/clang simply is not available for many Debian architectures as it’s not portable. Please drop the B-D for these architectures. I haven't looked at the code but it seems that this dependency is now required in order to build qdoc, so reducing the severity to wishlist. I don't know if it's possible at all to build everything but qdoc. And the effect of this could be many packages starting to FTBFS. This page states that: http://doc.qt.io/qt-5/gettingstarted.html Note: From Qt 5.11, QDoc requires clang from LLVM 3.9 for parsing C++ header and source files, and for parsing the function signatures in \fn commands. See Installing clang for QDoc for details. However, if it can be built without these doc tools, for example using Adrian's patch, it would be very nice to try. Not sure if it will break many packages (for these arches), packages might assume that qdoc tools are there, but the alternative is at least equally bad, and potentially worse. I think that this is similar to the case discussed in #897667, not being able to build qt4-x11 makes big portions of the archive unbuildable, many thousands of packages. Not being able to build qttools-opensource-src will have a similar effect, I think. Cheers. -- Manuel A. Fernandez Montecelo
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
El viernes, 27 de julio de 2018 07:55:19 -03 John Paul Adrian Glaubitz escribió: > On 07/27/2018 12:34 PM, John Paul Adrian Glaubitz wrote: > >> I don't know if it's possible at all to build everything but qdoc. And > >> the > >> effect of this could be many packages starting to FTBFS. > > > > Unlikely. I don't know any project that has a hard dependency on > > documentation. > This part of debian/rules is already written such qdoc is not build for > cross-builds, so why shouldn't it be possible to disable it for some > architectures either? This part is used to build qttools' documentation in a build-indep build. For this you need qdoc which is part of the same source package, so you need to build it. In the cross build case you can't because you need the build arch's qdoc. But then you also need to build qdoc to be shipped in the binary packages too. And that's where the problem begins. -- Programming is really just the mundane aspect of expressing a solution to a problem. There are talents that are specifically related to actually coding, but the real issue is being able to grasp problems and devise solutions that are detailed enough to actually be coded. John Carmack answers on Slashdot, http://slashdot.org/games/99/10/15/1012230.shtml Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/27/2018 12:55 PM, John Paul Adrian Glaubitz wrote: > This part of debian/rules is already written such qdoc is not build for > cross-builds, > so why shouldn't it be possible to disable it for some architectures either? I will test this patch later. Have to wait for the build dependencies for qttools to be built. Patch: diff -Nru old/qttools-opensource-src-5.11.1/debian/control new/qttools-opensource-src-5.11.1/debian/control --- old/qttools-opensource-src-5.11.1/debian/control2018-07-25 11:41:01.0 +0200 +++ new/qttools-opensource-src-5.11.1/debian/control2018-07-27 12:58:15.968968584 +0200 @@ -10,11 +10,11 @@ Dmitry Shachnev , Simon Quigley Build-Depends: debhelper (>= 11), - libclang-dev, + libclang-dev [!alpha !hppa !ia64 !m68k !powerpcspe !riscv64 !sh4 !x32], libqt5opengl5-dev (>= 5.11.1+dfsg~), libqt5sql5-sqlite (>= 5.11.1+dfsg~), libqt5webkit5-dev (>= 5.212.0~alpha2-11~) [!m68k !sparc64], - llvm-dev, + llvm-dev [!alpha !hppa !ia64 !m68k !powerpcspe !riscv64 !sh4 !x32], pkg-kde-tools, qtbase5-private-dev (>= 5.11.1+dfsg~), qtdeclarative5-private-dev (>= 5.11.1~), diff -Nru old/qttools-opensource-src-5.11.1/debian/rules new/qttools-opensource-src-5.11.1/debian/rules --- old/qttools-opensource-src-5.11.1/debian/rules 2018-07-25 11:41:01.0 +0200 +++ new/qttools-opensource-src-5.11.1/debian/rules 2018-07-27 13:00:34.712090723 +0200 @@ -32,6 +32,7 @@ dh_auto_build -- docs ifeq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) +ifeq (,$(filter alpha hppa ia64 m68k powerpcspe riscv64 sh4 x32, $(DEB_HOST_ARCH))) override_dh_auto_build-arch: build-doc-tools # Rebuild the internal assistant.qch which is used as a resource cd src/assistant/assistant/doc/internal; qmake @@ -39,6 +40,7 @@ mv doc/assistant.qch src/assistant/assistant/assistant.qch dh_auto_build endif +endif override_dh_auto_install-arch: dh_auto_install -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
On 07/27/2018 12:34 PM, John Paul Adrian Glaubitz wrote: >> I don't know if it's possible at all to build everything but qdoc. And the >> effect of this could be many packages starting to FTBFS. > > Unlikely. I don't know any project that has a hard dependency on > documentation. This part of debian/rules is already written such qdoc is not build for cross-builds, so why shouldn't it be possible to disable it for some architectures either? override_dh_auto_clean: dh_auto_clean rm -fv .qmake.cache rm -fv debian/qttools5-dev-tools.install build-doc-tools: # Build qdoc, qhelpgenerator and qtattributionsscanner tools cd src; qmake CONFIG+=disable_external_rpath dh_auto_build -- -Csrc sub-qdoc sub-qtattributionsscanner cd src/assistant; qmake dh_auto_build -- -Csrc/assistant sub-qhelpgenerator override_dh_auto_build-indep: build-doc-tools cd src/qdoc; qmake cd src/assistant/help; qmake dh_auto_build -- docs ifeq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) override_dh_auto_build-arch: build-doc-tools # Rebuild the internal assistant.qch which is used as a resource cd src/assistant/assistant/doc/internal; qmake dh_auto_build -- -Csrc/assistant/assistant/doc/internal docs mv doc/assistant.qch src/assistant/assistant/assistant.qch dh_auto_build endif The actual documentation is only generated in override_dh_auto_build-indep using the build tools generated in build-doc-tools. But if we're not building any documentation in a binary-arch build, why should we build the documentation tools either? For openjdk-X, the documentation is generated using pandoc which isn't available on every architecture either, yet the binary-arch target of openjdk-X builds on every architecture. So, I'm convinced the problem can be solved with better packaging. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures
> Control: severity -1 wishlist Setting a bug which breaks multiple architectures is somewhat of an understatement. > I haven't looked at the code but it seems that this dependency is now > required in order to build qdoc, so reducing the severity to wishlist. Well, it's a documentation tool. It should just be possible to disable the documentation tool on the affected architectures. > I don't know if it's possible at all to build everything but qdoc. And the > effect of this could be many packages starting to FTBFS. Unlikely. I don't know any project that has a hard dependency on documentation. > The only way around I see is submitting patches upstream to avoid clanf > usage. Remember they need to go directly to upstream, we can't forward then > except for very small changes. Strange policy. Lots of people here take patches from the bugtracker and forward them upstream. In fact, that's what the official Debian documentation says. Either way, there are plans to make LLVM available on more targets, there are already branches working on alpha, m68k, riscv64 and more. Until then, it would be nice if Qt wouldn't have a hard dependency on it solely to build documentation. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Processed: unblock 902557 with 887687
Processing commands for cont...@bugs.debian.org: > # debconf no longer needs qt4-perl > unblock 902557 with 887687 Bug #902557 [release.debian.org] transition: Perl 5.28 902557 was blocked by: 900832 899021 902771 629405 900232 887687 904727 902674 901085 862678 902556 901082 902557 was not blocking any bugs. Removed blocking bug(s) of 902557: 887687 > thanks Stopping processing here. Please contact me if you need assistance. -- 902557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#904698: sddm fails to login with user shell fish and bash completion installed
Control: tag -1 + pending ¡Hola Alf! El 2018-07-26 a las 22:16 +0200, Alf Gaida escribió: Package: sddm Version: 0.18.0-1 Severity: normal fish has some problems with the newly introduced sourcing of /etc/profile - esp an installed bash-completion and /etc/profile.d/bash_completion.sh Anyway, I've reverted the source of /etc/profile for fish after checking this: https://github.com/fish-shell/fish-shell/issues/3665 fish gives syntax errors on things like &&, so I don't think that applying https://github.com/sddm/sddm/commit/f749f1d65165de7ce7b9ae073b19f057b205ab35 was a good idea anymore. A patch to make sourcing of files more fault tolerant for all shells is attached. The "patch" is sourcing all the files in a different subshell, that means, no changes in the environment are in effect. This is not an acceptable "fix". I just commented the /etc/profile line for fish. Happy hacking, -- "If a pickpocket meets a saint, he sees only his pockets." -- Kegley's Law Saludos /\/\ /\ >< `/ signature.asc Description: PGP signature
Processed: Re: Bug#904698: sddm fails to login with user shell fish and bash completion installed
Processing control commands: > tag -1 + pending Bug #904698 [sddm] sddm fails to login with user shell fish and bash completion installed Added tag(s) pending. -- 904698: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904698 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
