Re: eric and jquery.js to a symbolic link
Thanks Julian That was helpful. It is fixed now in upstream. Regards Gudjon
eric and jquery.js to a symbolic link
Hi list I am working on eric and I do have a problem with the lintian requirement to replace the jquery.js file with the debian provided jquery.js file. The upstream author pointed out that it doesn't work as well and I have verified the behavior. If you run eric7_browser and press ==->Bookmarks->Speed Dial it doesn't show the links when using the debian jquery.js file. Is it ok to keep the original jquery files and add a lintian-override in this case? Regards Gudjon
Re: Eric-22.12 and trove-classifiers
Hi Dmitry Thanks a lot for all help. I did implement your patches and trove-classifiers is now on salsa: https://salsa.debian.org/python-team/packages/trove-classifiers If you or anyone is willing to upload, I would be very happy. Regards Gudjon
Re: Eric-22.12 and trove-classifiers
Hi again list The trove-classfiers library is only three minor files and the calver library is a single small file, I don't find it worth it to make Debian packages out of them plus I can only build them using setuptools. Eric contains a ThirdParty directory and I can add the trove-classifiers there and it works perfectly. Is there any drawback from adding trove-classifiers as a patch in the Eric package? /Gudjon
Eric-22.12 and trove-classifiers
Hi list
I am working on eric and I do have an issue before release.
It depends on trove-classifiers which isn't packaged in Debian. I have
tried to make a package out of it but not luck.
First it depends on calver that is not packaged in Debian.
Secondly. After having installed calver, the build stops with the following
error:
E: pybuild pybuild:386: configure: plugin distutils failed with: exit
code=1: python3.11 setup.py config
dh_auto_configure: error: pybuild --configure -i python{version} -p "3.11
3.10" returned exit code 13
make: *** [debian/rules:10: binary] Error 13
Does anyone have a solution to this?
If anyone is willing to package these or even adopt eric, you are more than
welcome.
Regards
Gudjon
Re: Fixing upstream branch after tagging
Thanks Andrius and Julian Forgot to mention that I had already pushed my changes. I will try to adapt to the new git standard but that will be my Christmas project. Julian, your solution with a new tag worked perfectly but I won't push my changes until it is lintian clean. Regards Gudjon On Mon, Dec 5, 2022 at 1:04 PM Julian Gilbey wrote: > On Mon, Dec 05, 2022 at 06:24:48AM +0000, Guðjón Guðjónsson wrote: > > Hi list > > I am working on eric and I made a mistake while updating the git > repository. > > Some paths have changed so files were not excluded correctly and now > upstream > > and pristine-tar contain jquery*.js files. > > How can I remove the files after having tagged? > > I read that the pristine-tar branch should be removed [1]. Is that > correct? > > Regards > > Gudjon > > Hi Gudjon, > > It depends on whether you have pushed to a remote repository yet, or > whether it's still only on your local machine. If you've already > pushed, then you'll have to update your local versions and give it a > different version number (for example, +ds2 rather than +ds1), doing a > fresh gbp import-orig on the repacked source package. > > If you're still only on your local machine, this is an error I have > made a number of times, only noticing after doing gpb import-orig. To > fix it, you can roll back the gbp import-orig. With care, do the > following (where git co is shorthand for git checkout): > > git co debian/unstable [or whatever your branch is] > git log > git reset --hard > > git co upstream > git log > git reset --hard > > git co pristine-tar > git log > git reset --hard > > git tag -d upstream/ > > > There is probably a better way to do it, but this has worked for me. > > Good luck! > >Julian >
Fixing upstream branch after tagging
Hi list I am working on eric and I made a mistake while updating the git repository. Some paths have changed so files were not excluded correctly and now upstream and pristine-tar contain jquery*.js files. How can I remove the files after having tagged? I read that the pristine-tar branch should be removed [1]. Is that correct? Regards Gudjon 1) https://go-team.pages.debian.net/workflow-changes.html
Re: Git, gbp blues
Hi again One more question. If I have updated the sources with uscan and when running lintian I find out that there is an unwanted file in the upstream sources. How can I remove the file from the upstream tarball after it has been imported into upstream and pristine-tar? Regards Gudjon
Re: Git, gbp blues
Hi Thanks for the suggestions. I will try my best. I am now working on my gspiceui package (which is in fact not a python package) But the master branch is just master, not debian/master Here debian/master is preferred https://wiki.debian.org/Python/GitPackaging But in this page the branch name is master. https://wiki.debian.org/PackagingWithGit What is the standard? Shall I change? git checkout -b debian/master git branch -D master ? Regards Gudjon
Re: Git, gbp blues
Hi Dmitry and Anrdrey On Sun, Aug 25, 2019 at 10:19 PM Dmitry Shachnev wrote: > The correct procedure is running “gbp pq import” *before* importing a new > tarball. Then after importing you do “gbp pq rebase”. In fact I did do that. > > Sometimes I myself forget to run “gbp pq import”. In this case I do the > following: > > - Remember the current commit SHA1; > - git reset --hard origin/debian/master; # or to previous tag > - gbp pq import; # this is the needed step > - git checkout debian/master; # back to debian/master branch > - git merge COMMIT_ID; # that you remembered before Thanks, this is useful for me. > > > But fixing the patches with quilt before importing them the second > > time seems to fix all my problems. > If it does not break the patches metadata then it also works. But what other way is possible? The patch queue must apply cleanly in gbp pq import and in general you can assume it doesn't with new upstream and old patch queue. I still don't understand how to edit the patches the correct way after a new upstream release. Regards Gudjon Ps. The package qscintilla2 is pushed, still a few lintian warnings to fix.
Re: Git, gbp blues
Hi Andrey Thanks for the answer. On Sun, Aug 25, 2019 at 9:50 PM Andrey Rahmatullin wrote: > > Isn't this an error. Shouldn't it be git checkout? > > $ gbp checkout debian/master > Yes. You mean it should be git checkout? > > If you ran gbp pq import after importing the new tarball and it didn't say > "Patch queue branch 'patch-queue/master'. already exists. Try 'rebase' or > 'switch' instead." this means you didn't follow the procedure you copied > above, which includes running gbp pq import before gbp import-orig. I did follow the procedure but I don't know what to do if a patch doesn't apply cleanly. I did try gbp pq import gbp:info: Trying to apply patches at 'c72f39a3a32b5e5c1eb7f9aaf7176e942e85d804' gbp:warning: Patch 0004-remove-logo-privacy-issue.diff.patch failed to apply, retrying with whitespace fixup gbp:error: Failed to apply '/home/gudjon/debian/python-modules/qscintilla2/debian/patches/0004-remove-logo-privacy-issue.diff.patch': Error running git apply: error: patch failed: doc/Scintilla/index.html:64 error: doc/Scintilla/index.html: patch does not apply gbp:error: Couldn't apply patches But fixing the patches with quilt before importing them the second time seems to fix all my problems. I can push my changes if you want to take a look? Regards Gudjon
Git, gbp blues
Hi list I'm sorry to say but I am no friend of git for Debian packaging but I am a big wannabe. This page has been very helpful: https://wiki.debian.org/Python/GitPackaging It says $ gbp pq import which has more or less solved my problems when trying to upgrade a package. Isn't this an error. Shouldn't it be git checkout? $ gbp checkout debian/master $ gbp import-orig --pristine-tar --uscan rebase and export. But I still find working with patch queues difficult especially with new upstream where the old patches don't apply correctly. I tried to do $ gbp pq import but it fails because one of the patches doesn't apply. So I fixed the patches in the old way using quilt push -f quilt edit quilt refresh And after having fixed all the patches I could do $gbp pq import $gbp pq export and the diff seems ok. Is this the correct procedure? Regards Gudjon
Re: Python2/Qt4 removal
Hi Scott Great, thanks. I will make one upgrade with python2/Qt4 and then start preparing for its removal. Regards Gudjon
Re: Watch file for riverbankcomputing (QScintilla)
Hi Dmitry Thanks a lot, this works perfectly > version=3 > opts=dversionmangle=s/\+dfsg// \ > https://www.riverbankcomputing.com/software/qscintilla/download \ > /static/Downloads/QScintilla/[\d.]+/QScintilla_gpl-([\d.]+)\.tar\.gz I first made the mistake of removing the space after "download" wihch doesn't work but with the space it works perfectly. Regards Gudjon
Python2/Qt4 removal
Hi list QScintilla Qt4/python2 version has one reverse dependency and it is the tora package that is marked for autoremoval on the 5th of September. Shall I keep support for Qt4/python2 in my upgrade or is it ok to remove it? Regards Gudjon
Watch file for riverbankcomputing (QScintilla)
Hi list I am working on the QScintilla package and starting on the watch file but I cannot figure out how to fix the URL. I tried to use the pyqt5 package as a template but without luck. The URL is https://www.riverbankcomputing.com/static/Downloads/QScintilla/2.11.2/QScintilla_gpl-2.11.2.tar.gz and the pyqt5 watch file contains: https://www.riverbankcomputing.com/software/pyqt/download5 \ /static/Downloads/PyQt5/[\d.]+/PyQt5_gpl-([\d.]+)\.tar\.gz but it doesn't help me :( Can anyone help? Regards Gudjon
Re: uscan, get-orig-source and multiple source packages
Hi Thomas On Sun, Aug 18, 2019 at 1:50 AM Thomas Goirand wrote: > In debian/watch, you can point to a script that does the download work. > Just do that... Thanks a lot. That will fix my problem. /Gudjon
uscan, get-orig-source and multiple source packages
Hi list I am upgrading my packages after the release of Buster and starting with eric. The get-orig-source target has been removed from the rules file and I know that is according to the current standard but I miss it :( In eric version 18.08 I could add the whole multiple source to the pristine-tar target: eric_18.08.orig.tar.gz.delta eric_18.08.orig.tar.gz.id eric_18.08.orig-transl-de.tar.gz.delta eric_18.08.orig-transl-de.tar.gz.id eric_18.08.orig-transl-en.tar.gz.delta eric_18.08.orig-transl-en.tar.gz.id eric_18.08.orig-transl-es.tar.gz.delta eric_18.08.orig-transl-es.tar.gz.id eric_18.08.orig-transl-ru.tar.gz.delta eric_18.08.orig-transl-ru.tar.gz.id But I have no clue how to do that without the get-orig-source target. Can someone please point me to a well maintained multiple source package to take a look at. Regards Gudjon
Removing a binary package (python-qwt3d-qt4)
Hi list I have a problem with my package pyqwt3d. It did contain the binary package python-qwt3d-qt4 but I removed it and replaced it with python3-qwt3d-qt5. The old binary package seems to exist somewhere and stops the package from entering testing. See: https://tracker.debian.org/pkg/pyqwt3d I did add Package: python3-qwt3d-qt5 Conflicts: python-qwt3d-qt4 Replaces: python-qwt3d-qt4 but it did not help. I don't find the solution in the Policy manual. Can anyone help me? Regards Gudjon
Questions about salsa and Git
Hi list I have to admit that I have never become comfortable with the Debian Git workflow but I know I have to learn to use it. Following the advice on https://wiki.debian.org/Python/GitPackaging Does the following advice hold true after the move to salsa? $ git clone git+ssh://git.debian.org/git/python-modules/tools/python-modules.git I have cloned the eric repository. git branch -a * debian/master remotes/origin/HEAD -> origin/debian/master remotes/origin/debian/master remotes/origin/lenny remotes/origin/pristine-tar remotes/origin/svn remotes/origin/upstream Is debian/master == master? Shall I checkout and pull the pristine-tar and upstream git checkout remotes/origin/upstream -b upstream git pull git checkout remotes/origin/pristine-tar -b upstream git pull To update the package, shall I copy the new upstream over the upstream branch, commit and then do $ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream ? Regarding the now deprecated get-orig-source target. Do you have any example on how to put the mechanism into the watch file? Regards Gudjon
New package, pyqt-qwt
Hi list I have made a new package that I want to get into Debian. dget http://gudjon.org/debian/source/pyqt-qwt_1.00.00-1.dsc It builds on Qt5, python3 and Qwt6 and I hope it will replace pyqwt5 which only supports Qt4, Qwt5. Any comments on upstream/packaging are welcome but I would like to upload it to DPMT asap. Regards Gudjon
PyQwt3D packaging strategy
Hi list I am updating my package pyqwt3d. It is tested for Qt5, python2 and python3. The changes were so huge that I made GitHub fork of it: https://github.com/GauiStori/PyQwt3D Now I have two questions: 1. Shall I skip the python2 version since it is already end of life? 2. Shall I make my changes into a huge patch (changes from upstream in the DPMT git repository) or make my own GitHub repository as an upstream source? Regards Gudjon
Re: Removal of pyqwt5
Hi Andrey and Scott Thanks a lot. Reportbug was very helpful. Regards Gudjon
Removal of pyqwt5
Hi list I would like to close bug: #787300 <787...@bugs.debian.org> and ask for removal of pyqwt5 plus some more Qt4 only packages. But I cannot find info on how to ask for removal of package from the Debian distribution. Can anyone help me Regards Gudjon
Re: dpkg-buildpackage -B fails
Thanks Andrey and Ghislain > dpkg-genbuildinfo --build=any > > dpkg-genbuildinfo: error: binary build with no binary artifacts found; > > .buildinfo is meaningless > Why are you trying to build arch:any subpackages of a package that doesn't > have arch:any subpackages? > > The packages are Architecture: all This is quite tricky for silly me :) Yesterday I changed the order of binary-indep and binary-arch but that didn't fix the problem. What I missed is that dpgk-buildpackage -B is no longer the problem but that sbuild doesn't download python. I will have to find out why sbuild doesn't download the build dependencies and preferably how to make it cache the downloads. Regards Gudjon
Re: Qtiplot, python support and bug #560852
Hi again Perhaps may earlier mail was a bit cryptic, excuse me. So I will make another attempt to explain my problem in the hope of an answer. Qtiplot[1] is a fairly large program, written in C++ that contains support for python scripting. The python scripting part is written in sip and it is compiled into the program. The python version is hard coded in the configuration files (of the Debian package). It was by mistake hard coded to 2.5 after the switch to 2.6 but that has been fixed. However I would very much like not to hard code the python version at all. If I do ldd on qtiplot, the output is: $ ldd /usr/bin/qtiplot ... libpython2.6.so.1.0 = /usr/lib/libpython2.6.so.1.0 (0xb725d000) ... so the binary is linked to version 2.6. Is there any possibility of providing support for more python versions other that moving the python-sip code into a shared library and compile each library for the corresponding python version? Regards Gudjon [1] http://packages.qa.debian.org/q/qtiplot.html
Qtiplot, python support and bug #560852
Hi Here is a question that I should know (and I think I know) the answer to but I want to be sure :) I am working on a new version of qtiplot and currently I hardcode python version 2.6 for the python support. $ ldd /usr/bin/qtiplot ... libpython2.6.so.1.0 = /usr/lib/libpython2.6.so.1.0 (0xb725d000) ... I would very much like not to hardcode the python version but I think the python scripting part of the program needs to be rewritten as a shared library in order to allow for many python versions. Is that correct? Regards Gudjon
