Re: Coin3d and SoQt with Qt5 and CMake
Anton, you are right. I was confused with the original sources. It seems that the package in experimental fix the bug.At least use the system expat library. I'm so sorry for the noise. El 11/01/18 a les 19:37, Leopold Palomo-Avellaneda ha escrit: > The bug really exists in unstable and testing. The version in > experimental is > fixed and really depends on libexpat1. But as I told you, soqt and pivy > should be fixed to be built against cmaked-version of coin3. I suppose that soqt hs to be the cmaked version to be compiled against coin. I'll check. pivy ... I have no idea. > [1] https://packages.debian.org/experimental/libcoin80v5 > > Qt5+Coin3 is difficult because freecad does not support it yet. > I am not going to maintain coin3+soqt+pivy.. any more (very > limited time and no use of those packages). > > > I hope I could help on February for this packages. I use coin3+soqt > so no > problem here. > > > That would be fine! So we could then upload experimenatl->unstable and > finally fix #874727. yes, on February I',, will help with the migration. Leo signature.asc Description: OpenPGP digital signature
Re: Problems with my maintainer upload
On Thu, Jan 11, 2018 at 06:29:55PM +, James Clarke wrote: > > That makes sense. The best way of knowing when the update is done is > > probably looking into the keyring repository log, right? > > https://anonscm.debian.org/git/keyring/keyring.git/log/ > > Yes, I think that's updated at the same time as what's on ftp-master, and if > not it's certainly close (and the best you can do without SSH access). The authoritative way would be to check the content of the keyring that's available through rsync (that's also what is used to update ftp-master). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Coin3d and SoQt with Qt5 and CMake
Anton. Are you sure is fixed? I have looked the coin sources Cmake version and it uses the internal expat version always. I.ll check it . Leopold On 11 gener de 2018 18:40:57 CET, Anton Gladky wrote: >Hi Leo, > >2018-01-11 9:30 GMT+01:00 Leopold Palomo-Avellaneda : >>> I built coin3d+cmake in experimental trying to fix #874727. >>> But yes, one need to build also soqt and pivy. >> >> still has the bug. At least what the users said. Looking on the >CMakeLists, the >> CMake version uses the internal expat version. I would try to look on >it, but I >> cannot promise anything. > >The bug really exists in unstable and testing. The version in >experimental is >fixed and really depends on libexpat1. But as I told you, soqt and >pivy >should be fixed to be built against cmaked-version of coin3. > >[1] https://packages.debian.org/experimental/libcoin80v5 > >>> Qt5+Coin3 is difficult because freecad does not support it yet. >>> I am not going to maintain coin3+soqt+pivy.. any more (very >>> limited time and no use of those packages). >> >> I hope I could help on February for this packages. I use coin3+soqt >so no >> problem here. > >That would be fine! So we could then upload experimenatl->unstable and >finally fix #874727. > >Best regards > >Anton -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Problems with my maintainer upload
On 11 Jan 2018, at 18:22, Jose Luis Rivero wrote: > > On Thu, Jan 11, 2018 at 6:52 PM, James Clarke wrote: > > Yes, but you need ssh access to coccia, i.e. be a DD. Looking on there at > /srv/ftp-master.debian.org/log/current: > > > 2018071905|process-upload|dak|ignition-math2_2.9.0+dfsg1-1_source.changes|Error > > while loading changes: No valid signature found. (GPG exited with status > > code 0) > > gpg: Signature made Tue Jan 9 22:50:01 2018 UTC > > gpg:using RSA key A08161BBEC1CC063961459035E946C090AFF0427 > > gpg:issuer "jriv...@osrfoundation.org" > > gpg: Good signature from "Jose Luis Rivero " > > [expired] > > gpg: WARNING: Using untrusted key! > > Your key has expired, or at least the copy in the keyring. Note that the > keyring is uploaded manually around once a month, so even if you renew your > key > and upload it to the keyservers, you won't be able to upload anything for a > while and will need sponsorship. > > > That makes sense. The best way of knowing when the update is done is probably > looking into the keyring repository log, right? > https://anonscm.debian.org/git/keyring/keyring.git/log/ Yes, I think that's updated at the same time as what's on ftp-master, and if not it's certainly close (and the best you can do without SSH access). James
Re: Problems with my maintainer upload
On Thu, Jan 11, 2018 at 6:52 PM, James Clarke wrote: > > Yes, but you need ssh access to coccia, i.e. be a DD. Looking on there at > /srv/ftp-master.debian.org/log/current: > > > 2018071905|process-upload|dak|ignition-math2_2.9.0+dfsg1-1_source.changes|Error > while loading changes: No valid signature found. (GPG exited with status > code 0) > > gpg: Signature made Tue Jan 9 22:50:01 2018 UTC > > gpg:using RSA key A08161BBEC1CC063961459035E946C > 090AFF0427 > > gpg:issuer "jriv...@osrfoundation.org" > > gpg: Good signature from "Jose Luis Rivero " > [expired] > > gpg: WARNING: Using untrusted key! > > Your key has expired, or at least the copy in the keyring. Note that the > keyring is uploaded manually around once a month, so even if you renew > your key > and upload it to the keyservers, you won't be able to upload anything for a > while and will need sponsorship. > > That makes sense. The best way of knowing when the update is done is probably looking into the keyring repository log, right? https://anonscm.debian.org/git/keyring/keyring.git/log/ Thanks James.
Re: Problems with my maintainer upload
On 11 Jan 2018, at 15:29, Jose Luis Rivero wrote: > > Hello all: > > Excuse me if the question stupid but I have a problem with one of my > maintainer uploads. > > In this case ignition-math2 is the package and the upload is to update > to the 2.9.0 version. After I run dput I get a message of "Processing > ..." but never get "ACCEPTED or REJECTED". > > Here is the message that arrived to mailing list: > https://lists.alioth.debian.org/pipermail/debian-science-maintainers/2018-January/056854.html > > Is there any log or register where I can find what is the problem? Am I > missing something obvious? Yes, but you need ssh access to coccia, i.e. be a DD. Looking on there at /srv/ftp-master.debian.org/log/current: > 2018071905|process-upload|dak|ignition-math2_2.9.0+dfsg1-1_source.changes|Error > while loading changes: No valid signature found. (GPG exited with status > code 0) > gpg: Signature made Tue Jan 9 22:50:01 2018 UTC > gpg:using RSA key A08161BBEC1CC063961459035E946C090AFF0427 > gpg:issuer "jriv...@osrfoundation.org" > gpg: Good signature from "Jose Luis Rivero " > [expired] > gpg: WARNING: Using untrusted key! Your key has expired, or at least the copy in the keyring. Note that the keyring is uploaded manually around once a month, so even if you renew your key and upload it to the keyservers, you won't be able to upload anything for a while and will need sponsorship. Regards, James
Re: Coin3d and SoQt with Qt5 and CMake
Hi Leo, 2018-01-11 9:30 GMT+01:00 Leopold Palomo-Avellaneda : >> I built coin3d+cmake in experimental trying to fix #874727. >> But yes, one need to build also soqt and pivy. > > still has the bug. At least what the users said. Looking on the CMakeLists, > the > CMake version uses the internal expat version. I would try to look on it, but > I > cannot promise anything. The bug really exists in unstable and testing. The version in experimental is fixed and really depends on libexpat1. But as I told you, soqt and pivy should be fixed to be built against cmaked-version of coin3. [1] https://packages.debian.org/experimental/libcoin80v5 >> Qt5+Coin3 is difficult because freecad does not support it yet. >> I am not going to maintain coin3+soqt+pivy.. any more (very >> limited time and no use of those packages). > > I hope I could help on February for this packages. I use coin3+soqt so no > problem here. That would be fine! So we could then upload experimenatl->unstable and finally fix #874727. Best regards Anton
Re: Packaging shiny-server (Was: Bug#886815: ITP: r-cran-git2r -- GNU R access to Git repositories)
Hi,
On 10.01.2018 at 14:40, Andreas Tille wrote:
> Some local manual installation of shiny-server installs the following not yet
> packaged R packages:
>
>r-cran-broom
>r-cran-bubbles
>r-cran-dbplyr
>r-cran-ggvis
>r-cran-highcharter
>r-cran-leaflet
>r-cran-mclust
>r-cran-psych
>r-cran-rlist
>r-cran-shinysignals
>r-cran-shinythemes
>r-cran-wordcloud
>r-cran-rmarkdown
>
> This list possibly needs to be worked down.
are you sure? grep'ing the source code for those packages ('broom', ... of
course)
only shows 'rmarkdown' occurring in the source.
I only see shiny, ggplot2, reshape2, devtools and rmarkdown being used when
grep'ing for 'library(', 'require(' and 'install.package'
> I had an *old*, *non-working* packaging attempt on my local disk. I now
> imported the latest upstream of shiny-server into this Git repository, did
> **not** yet any test build yet (so expect that the build will fail!) and
> commited it to
>
> https://salsa.debian.org/science-team/shiny-server.git
>
> Feel free to commit any changes you consider an enhancement! I would work
> down the list or r-cran-* packages step by step and than see how complicated
> the actual shiny-server packaging is. I vaguely remember the nodejs stuff
> was
> quite complex - specifically for me since I have no idea about all this
> nodejs
> / JS stuff at all.
OK, I'll have a look (unfortunately I don't have much time until beginning of
February).
Best,
Philip
Re: r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)
I had some friendly emails with Stefan (git2r upstream) when he started the R package git2r (as I needed some features in my drat R package) and he expressed quite some frustration at working with libgit2 as it changed so much upstream. I know we collectively really hate embedding copies, but r-cran-git2r may be defensible case because libgot2 is too complex / volatile. Just my $0.02. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Problems with my maintainer upload
Hello all: Excuse me if the question stupid but I have a problem with one of my maintainer uploads. In this case ignition-math2 is the package and the upload is to update to the 2.9.0 version. After I run dput I get a message of "Processing ..." but never get "ACCEPTED or REJECTED". Here is the message that arrived to mailing list: https://lists.alioth.debian.org/pipermail/debian-science-maintainers/2018-January/056854.html Is there any log or register where I can find what is the problem? Am I missing something obvious? Thanks. -- Jose Luis Rivero
Re: r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)
Hello Andreas:
On 11/01/18 15:11, Andreas Tille wrote:
> Hi again,
>
> On Thu, Jan 11, 2018 at 08:34:09AM +0100, Andreas Tille wrote:
>>> # Add include paths for git2r
>>> -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
>>> ${CPPFLAGS}"
>>> -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
>>> ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
>>
>> ...
>> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter
>> /usr/include/git2 -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
>> -DGIT_OPENSSL -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH
>> -DGIT_CURL -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R
>> -fpic -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=.
>> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
>> -D_FORTIFY_SOURCE=2 -g -c git2r_branch.c -o git2r_branch.o
>> git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
>> git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this
>> function); did you mean 'GIT_REF_OID'?
>> git_buf buf = GIT_BUF_INIT;
>>^~~~
>>GIT_REF_OID
>> git2r_branch.c:407:19: note: each undeclared identifier is reported only
>> once for each function it appears in
>> git2r_branch.c:427:11: warning: implicit declaration of function
>> 'git_buf_join3'; did you mean 'git_buf_set'?
>> [-Wimplicit-function-declaration]
>> err = git_buf_join3(
>>^
>>git_buf_set
>> /usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed
>>
>>
>> This is in
>>
>>/usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char
>> *)(STR), 0, (size_t)(LEN) }
>>
>> but it seems a different buffer.h is used.
>
> I dived a bit deeper into this and found this other buffer.h: It is a
> private header from libgit2/src/ and other headers from there are needed
> as well like common.h, cc_compat.h, thread-utils.h and possibly other
> header files.
>
> That's ... uh, no idea how to call this. What would you suggest:
> Live with the nasty code copy and just add it to debian/copyright or
> hack around all those usage of private header files. I've pushed some
> changes to Git[1] which keeps some (not all needed - for instance
> thread-utils.h is missing) but if there is no better idea how to deal
> with this I think I have better things to spent my time on than getting
> rid of a code copy you can not really cleanly get rid of.
>
I agree with your analysis, the mess of headers that libgit2 is using
IMHO could make the solution (cherry pick only some parts of libgit2)
worse than maintaining the embedded copy.
--
Jose Luis Rivero
r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)
Hi again,
On Thu, Jan 11, 2018 at 08:34:09AM +0100, Andreas Tille wrote:
> > # Add include paths for git2r
> > -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
> > ${CPPFLAGS}"
> > -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
> > ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
>
> ...
> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter
> /usr/include/git2 -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -DGIT_OPENSSL -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH -DGIT_CURL
> -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R -fpic
> -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c
> git2r_branch.c -o git2r_branch.o
> git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
> git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this
> function); did you mean 'GIT_REF_OID'?
> git_buf buf = GIT_BUF_INIT;
>^~~~
>GIT_REF_OID
> git2r_branch.c:407:19: note: each undeclared identifier is reported only once
> for each function it appears in
> git2r_branch.c:427:11: warning: implicit declaration of function
> 'git_buf_join3'; did you mean 'git_buf_set'? [-Wimplicit-function-declaration]
> err = git_buf_join3(
>^
>git_buf_set
> /usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed
>
>
> This is in
>
>/usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char
> *)(STR), 0, (size_t)(LEN) }
>
> but it seems a different buffer.h is used.
I dived a bit deeper into this and found this other buffer.h: It is a
private header from libgit2/src/ and other headers from there are needed
as well like common.h, cc_compat.h, thread-utils.h and possibly other
header files.
That's ... uh, no idea how to call this. What would you suggest:
Live with the nasty code copy and just add it to debian/copyright or
hack around all those usage of private header files. I've pushed some
changes to Git[1] which keeps some (not all needed - for instance
thread-utils.h is missing) but if there is no better idea how to deal
with this I think I have better things to spent my time on than getting
rid of a code copy you can not really cleanly get rid of.
Kind regards
Andreas.
[1] https://salsa.debian.org/r-pkg-team/r-cran-git2r.git
--
http://fam-tille.de
Re: A common group on salsa.debian.org for R packages ?
Hi Frederic, On Thu, Jan 11, 2018 at 10:45:30AM +, PICCA Frederic-Emmanuel wrote: > > The people who > > contributed to the decision (including me) consider the advantage > > to maintain R packages in a technical team higher than to keep > > everything in Debian Science. > > I am just wondering if it is not always better to put packages in under the > language team umbrella. > For exemple to put all the python modules from Debian-science into the Debian > Python Team. You have a point definitely but the according language team needs to agree to take over those packages. For instance I'm currently working on pandas (#884294) and I clearly agree that somebody with more Python competence should work on this. But there is no volunteer obviously (not even a response to the bug report so far). There are just cases where a language team explicitly refused to take a package. Well, I admit the people who care in Debian Science / Debian Med could join the language team and use the repository there. But in some cases it is not really clear who cares - not always those who are listed as Uploader care in practice and I'm personally reading lists with different priorities. So if I as a team member notice some problem in a package which obviously needs help (for instance pandas repeatedly) I will notice way earlier if it is in a list I'm reading with higher priority. > It is not clear to me how to draw a line between Debian Science vs Language > Team, when it comes to choose the team for a new package. In short: There is no such rule to draw a line. Kind regards Andreas. -- http://fam-tille.de
RE:A common group on salsa.debian.org for R packages ?
Hello, > The people who > contributed to the decision (including me) consider the advantage > to maintain R packages in a technical team higher than to keep > everything in Debian Science. I am just wondering if it is not always better to put packages in under the language team umbrella. For exemple to put all the python modules from Debian-science into the Debian Python Team. It is not clear to me how to draw a line between Debian Science vs Language Team, when it comes to choose the team for a new package. Cheers Frederic
Re: A common group on salsa.debian.org for R packages ?
>> Sorry for a late reply to this thread. But I am wondering: why have you >> decided to make a separate Salsa group instead of making of special >> subgroup in Debian Science Team group? > > Some additional arguments in addition to what Charles said: > > * There were R packages from different teams (Debian Science and > Debian Med currently, DebiChem also has R packages which are > not yet merged). We want to have a common R team. > > * In Debian there are somehow topic based teams (some are organised > as Blends like Debian Science and Debian Med) and technique (mostly > programming language) based teams (Python, Perl, etc.) In many > cases you can argue whether a package belongs to a certain topic > (or in which of the several potential topics) or the technical team. > While R is clearly science oriented Debian Science might be the > natural place but R is also a programming language. The people who > contributed to the decision (including me) consider the advantage > to maintain R packages in a technical team higher than to keep > everything in Debian Science. I see. Thanks for an explanation. Best regards, Boris
Re: A common group on salsa.debian.org for R packages ?
Hi Boris, On Thu, Jan 11, 2018 at 12:34:05PM +0300, Boris Pek wrote: > > Sorry for a late reply to this thread. But I am wondering: why have you > decided to make a separate Salsa group instead of making of special > subgroup in Debian Science Team group? Some additional arguments in addition to what Charles said: * There were R packages from different teams (Debian Science and Debian Med currently, DebiChem also has R packages which are not yet merged). We want to have a common R team. * In Debian there are somehow topic based teams (some are organised as Blends like Debian Science and Debian Med) and technique (mostly programming language) based teams (Python, Perl, etc.) In many cases you can argue whether a package belongs to a certain topic (or in which of the several potential topics) or the technical team. While R is clearly science oriented Debian Science might be the natural place but R is also a programming language. The people who contributed to the decision (including me) consider the advantage to maintain R packages in a technical team higher than to keep everything in Debian Science. Kind regards Andreas. -- http://fam-tille.de
Re: A common group on salsa.debian.org for R packages ?
Le Thu, Jan 11, 2018 at 12:34:05PM +0300, Boris Pek a écrit : > > > > Thus, people would only need to ask for membership if they want to > > create a new project (needs Master level), or if they have a guest > > account and are not member of the Science or Med team (that would be > > Developer level). > > Sorry for a late reply to this thread. But I am wondering: why have you > decided to make a separate Salsa group instead of making of special > subgroup in Debian Science Team group? Hi Boris, at that time I did not know about subgroups. In any case, I think that it should not make a big differnece: since we want to not only share the repositories with the whole science-team group, but also with the Debian and the future Debian Med groups, we need anyway to manage the group sharing of the repositories. (In the long term we need to write a command that spots which repositories are not appropriately shared, and corrects that). Following the discussions on flat structures and stable URLs, I also started to wonder about just putting the repositories in the Debian group directly. This would not make a big difference, except that the risk of accident of a) our API calls to touch the wrong repository, and b) other DD's API calls to mess accidently with our repositories would be slightly higher. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: A common group on salsa.debian.org for R packages ?
Hi,
>>> I will create a team on GitLab. How about "r-packages-team" ?
>> I consider r-pkg-team a more typical name.
>
> Thanks for the suggestion. I have just created the `r-pkg-team` group
> ("Debian R Packages Maintainers") on Salsa.
>
> https://salsa.debian.org/groups/r-pkg-team/
>
> For each package in the `r-pkg-team`, I propose to give Developer access
> to all the members of the groups Debian, science-team and the future
> Debian med team (no name chosen yet).
>
> It can be done programatically as follows.
>
> curl -X POST --header "Private-Token: $(cat gitlabtoken.txt)"
> 'https://salsa.debian.org/api/v4/projects/$project_ID/share?group_id=$group_id&group_access=$access_level'
>
> (See https://docs.gitlab.com/ce/api/projects.html#share-project-with-group
> and https://salsa.debian.org/help/user/permissions )
>
> It is not possible to make a group member of a group.
>
> Thus, people would only need to ask for membership if they want to
> create a new project (needs Master level), or if they have a guest
> account and are not member of the Science or Med team (that would be
> Developer level).
Sorry for a late reply to this thread. But I am wondering: why have you
decided to make a separate Salsa group instead of making of special
subgroup in Debian Science Team group?
Best regards,
Boris
Re: Pushing commits to GitLab-Salsa not allowed
Dear Boris, On 01/11/2018 10:59 AM, Boris Pek wrote: > Just join to Debian Science Team group: > https://salsa.debian.org/science-team > as a member with Developer level of access: > https://docs.gitlab.com/ee/user/permissions.html many thanks for the explanation! I have requested to join the Team and now I am able to push my commits. Best regards, Andrius -- Andrius Merkys PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Re: Pushing commits to GitLab-Salsa not allowed
Hi Andrius, > I used to own a guest account on Alioth, and with this account I have > created a few packaging GIT repositories. However, since the transition > to GitLab-Salsa I am unable to push my commits: > > andrius@tasmanijos-velnias cod-tools $ git remote set-url origin > g...@salsa.debian.org:science-team/cod-tools.git > andrius@tasmanijos-velnias cod-tools $ git push > GitLab: You are not allowed to push code to this project. > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > > I have signed up on salsa.debian.org (@merkys-guest) and set up my SSH > key. Could this be because of me being absent from 'Project members' of > my package's project > (https://salsa.debian.org/science-team/cod-tools/project_members)? Yes. > If so, could I be added? Just join to Debian Science Team group: https://salsa.debian.org/science-team as a member with Developer level of access: https://docs.gitlab.com/ee/user/permissions.html Best wishes, Boris
Re: Coin3d and SoQt with Qt5 and CMake
Hi Anton, On 10/01/18 20:01, Anton Gladky wrote: > Hi Leo, > > I built coin3d+cmake in experimental trying to fix #874727. > But yes, one need to build also soqt and pivy. still has the bug. At least what the users said. Looking on the CMakeLists, the CMake version uses the internal expat version. I would try to look on it, but I cannot promise anything. > Qt5+Coin3 is difficult because freecad does not support it yet. > I am not going to maintain coin3+soqt+pivy.. any more (very > limited time and no use of those packages). I hope I could help on February for this packages. I use coin3+soqt so no problem here. Regards, Leo > Regards > > Anton > > > 2018-01-10 15:47 GMT+01:00 Leopold Palomo-Avellaneda : >> Hi, >> >> >> Coin3d is moving to CMake as build system ans SoQt is moving to Qt5 >> (finally). >> Anton, I have seen that you have pushed to experimental coin3 with CMake. >> >> It would be possible to have a version in Debian (at least in experimental) >> os >> SoQt build with Qt5 and begin a transition of all the packages involved? >> >> Best regards, >> >> Leopold >> >> -- >> -- >> Linux User 152692 GPG: 05F4A7A949A2D9AA >> Catalonia >> - >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> A: Top-posting. >> Q: What is the most annoying thing in e-mail? >> > -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
