dmedia-gfx/dispcalGUI — Open Source Display Calibration and Characterization by Argyll CMS Well, I started at least, but struggel on some snadbox violations using distutils_src_install. installing icon resources... ACCESS DENIED open_wr: /usr/share/icons/hicolor/.xdg-icon-resource-dummy ACCESS DENIED utimensat: /usr/share/icons/hicolor/.xdg-icon-resource-dummy touch: cannot touch `/usr/share/icons/hicolor/.xdg-icon-resource-dummy': Permission denied ACCESS DENIED unlinkat: /usr/share/icons/hicolor/.xdg-icon-resource-dummy rm: cannot remove `/usr/share/icons/hicolor/.xdg-icon-resource-dummy': Permission denied installing desktop menu entry... * Generating '/usr/bin/dispcalGUI' wrapper script * Generating '/usr/bin/dispcalGUI_postinstall.py' wrapper script >>> Completed installing dispcalGUI-0.4.9.2 into /var/tmp/portage/media-gfx/dispcalGUI-0.4.9.2/image/ The line which is the cause is in dispcalGUI/postinstall.py (Line 241 ff) python setup.py install --prefix="${D}" does not throw sandbox violations but installs nothing... Here it is above 30°C and this is to hot for my brain to work. Maybe someone with a cooler environment finds the problem. Kind regards Bjoern Reproducible: Always
Created attachment 239051 [details] media-gfx/dispcalGUI-0.4.9.2.ebuild - not yet working Preliminary, not working ebuild for dispcalGUI. Cheers Bjoern
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, Markos. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 240099 [details] media-gfx/dispcal-gui-0.4.9.2 - working ebuild I modified the ebuild provided here and produced a working ebuild. I changed the ebuild name to adhere to Gentoo's naming conventions. I had to trick dispcalGUI's build system into bypassing a sanity check that it does of the prefix directory. As a consequence, the ebuild will build the source as ebuilds normally do, but when it goes to the compilation stage, discalGUI's build system will produce a binary tarball that is then extracted to ${D} for integration into the system by portage. I am inexperienced at writing ebuilds, so while I do not know if that is a proper way for an ebuild to work, that was the best I could do.
Created attachment 240101 [details] media-gfx/dispcal-gui-0.4.9.2 - working ebuild I made a small last minute modification to the ebuild that broke it before I uploaded it. "x86_64" was inside the filename of the tarball, so I modified the ebuild to use "*" instead. Unfortunately, this was the wrong thing to do. I modified the ebuild to use "$(uname -m)" in its place, which works.
Sweet workaround! I am sure there is a more gentoonic way for this, but I couldn't come up with one. Your workaround even prevents patching around in the source (what I was working on...) Cheers Bjoern
Created attachment 240203 [details] media-gfx/dispcal-gui-0.5.8.0 - new ebuild; fixes download issue I found two issues with the existing ebuild. One is that the download url was broken by the name change I made, but I did not catch that. The other is that the correct download url no longer works. It seems that the author of dispcalGUI has produced a new version, pulling the existing version from his site. Instead of returning a 404 Not Found Response, his site returns a 300 Multiple Choices HTTP Response, which messes things up. I have uploaded a new ebuild which fixes both of those issues. Unfortunately, this implies that unless portage mirrors the tarball, the new ebuild will break the next time a new version of dispcalGUI is published.
I forgot to mention that I have tested the ebuild on both x86 and x86_64. As far as I can tell, all of the functionality works. It should be ready for inclusion into sunrise if anyone with commit privileges would like to commit it.
Confirmed. Working on both x86 and x86_64 Thanks for completing the the ebuild! Cheers Bjoer
Just renamed the ebuild to the 0.5.8.1 version (current version) and so far it's installed and working great. Thanks for the ebuild!
Created attachment 241445 [details] media-gfx/dispcal-gui-0.5.8.1 - adds support for media-gfx/argyllcms-1.2.0 (In reply to comment #9) > Just renamed the ebuild to the 0.5.8.1 version (current version) and so far > it's installed and working great. Thanks for the ebuild! > Thanks for the report. I have attached a version bumped ebuild with the hope that it will be committed to sunrise.
* How about you commit it to sunrise yourself? :) * Please have a look at the python eclass; all the *PYTHON* variables that you define at the beginning are completely ignored at the moment!
Created attachment 244115 [details] media-gfx/dispcal-gui-0.5.8.1-r1 - minor dependency corrections; use flag added (In reply to comment #11) > * How about you commit it to sunrise yourself? :) > > * Please have a look at the python eclass; all the *PYTHON* variables that you > define at the beginning are completely ignored at the moment! > To answer your question, I lack commit privileges. Otherwise, I would likely do it. As for the PYTHON variables, my ebuild inherited that from Bjoern Olausson's earlier attempt at one because I used his ebuild as the basis for mine. The variable names correct according to the official documentation: http://www.gentoo.org/proj/en/Python/developersguide.xml At the same time, there appear to be a few minor issues with the ebuild's prerequisites according to upstream's documentation, so I am uploading a modified ebuild to fix them. http://dispcalgui.hoech.net/#prerequisites
Created attachment 244117 [details] metadata.xml file that is required for inclusion into sunrise I am also uploading a metadata.xml file that I believe is required for inclusion into the sunrise overlay.
(In reply to comment #6) > I found two issues with the existing ebuild. [...] The other is that > the correct download url no longer works. It seems that the author of > dispcalGUI has produced a new version, pulling the existing version from his > site. Instead of returning a 404 Not Found Response, his site returns a 300 > Multiple Choices HTTP Response, which messes things up. > > I have uploaded a new ebuild which fixes both of those issues. Unfortunately, > this implies that unless portage mirrors the tarball, the new ebuild will break > the next time a new version of dispcalGUI is published. Don't know if it helps, but the current version number is available via http://dispcalgui.hoech.net/VERSION as a simple text file.
Created attachment 248198 [details] media-gfx/dispcal-gui-0.6.2.2 - version bump (In reply to comment #14) > (In reply to comment #6) > > I found two issues with the existing ebuild. [...] The other is that > > the correct download url no longer works. It seems that the author of > > dispcalGUI has produced a new version, pulling the existing version from his > > site. Instead of returning a 404 Not Found Response, his site returns a 300 > > Multiple Choices HTTP Response, which messes things up. > > > > I have uploaded a new ebuild which fixes both of those issues. Unfortunately, > > this implies that unless portage mirrors the tarball, the new ebuild will break > > the next time a new version of dispcalGUI is published. > > Don't know if it helps, but the current version number is available via > http://dispcalgui.hoech.net/VERSION as a simple text file. > That enables us to obtain the current latest version with the following command: echo $(wget --output-document=- http://dispcalgui.hoech.net/VERSION 2> /dev/null) Unfortunately, this is not directly useful in ebuilds, since the only mechanism by which the package manager can identify new versions is through changes to the portage tree. I imagine that I could use this to setup a cron job to check the server for an updated ebuild on a fixed schedule and notify me by email whenever the version changes, although since this ebuild is not in Sunrise, that would not mean that updates would come any sooner than they do now. I also do not have commit privileges to Sunrise, so even if the ebuild was in Sunrise, I could not commit version bumps or other improvements. If I had commit privileges, I would have committed this two months ago. By the way, although I have many offline responsibilities, this ebuild is fairly problem free and if the lack of a maintainer is keeping it from inclusion into Sunrise, I could become the maintainer.
Thanks again for you affords! As long as there is no maintainer willing to adopt this ebuild, you/we could just write a little shell script, which grabs the version number, patches the ebuild and tries to compile it. If it compiles successful, publish the automated ebuild on a website if not, dispatch a mail. Since my lack of time currently does not allow a lot of involvement I could write the shell/python script if this would help you to maintain the ebuild. I could also provide the webspace and server the script is running on. But since it is headless I guess this is not appropriate for testing the ebuild. Cheers Bjoern
(In reply to comment #16) > Thanks again for you affords! > > As long as there is no maintainer willing to adopt this ebuild, you/we could > just write a little shell script, which grabs the version number, patches the > ebuild and tries to compile it. If it compiles successful, publish the > automated ebuild on a website if not, dispatch a mail. > > Since my lack of time currently does not allow a lot of involvement I could > write the shell/python script if this would help you to maintain the ebuild. > I could also provide the webspace and server the script is running on. But > since it is headless I guess this is not appropriate for testing the ebuild. > > Cheers > Bjoern > I've re-configured my server so that old versions of dispcalGUI can still be downloaded if they are in the archive at http://dispcalgui.hoech.net/archive/ (but I don't guarantee that they will be available forever). The preferred way to get the latest released source tgz is now via http://dispcalgui.hoech.net/download.php?version=latest&suffix=.tar.gz Regards, Florian
Created attachment 255773 [details] Fixes download location and does version bump (In reply to comment #16) > Thanks again for you affords! > > As long as there is no maintainer willing to adopt this ebuild, you/we could > just write a little shell script, which grabs the version number, patches the > ebuild and tries to compile it. If it compiles successful, publish the > automated ebuild on a website if not, dispatch a mail. > > Since my lack of time currently does not allow a lot of involvement I could > write the shell/python script if this would help you to maintain the ebuild. > I could also provide the webspace and server the script is running on. But > since it is headless I guess this is not appropriate for testing the ebuild. > > Cheers > Bjoern > Sadly, I am suffering from a lack of time too. I will be swamped with work and few breaks until the middle of May 2011. I am hesitant to commit to having an automated script notify me of updates as I do not know whether I will have time to respond. There have been two new dispcalGUI releases since my last post. Florian moved the location for downloads as he said he would, which broke the download urls we were using. I have uploaded a new ebuild, which both fixes that and does a revision bump.
Created attachment 266317 [details] Version Bump; Reintroduce curves USE flag It seems that I accidentally used an older version of the ebuild when I did the last revision bump. I just corrected that. I have also done a revision bump.
Created attachment 273679 [details] dispcalGUI 0.7.0.0 ebuild Hello, I hope I don't offend anyone with this attachment, feel free to remove it if that's the case. This is an updated ebuild for dispcalGUI and it is tested with version 0.7.0.0. The older ebuilds which serviced as my starting point, had some problems with the current testing Gentoo branch: - The testing branch has wxPython 2.8.12.0. With this version neither the profile installation dialog, neither the curves dialog of dispcalGUI show up. The log window shows some problems with wxPython. So I restricted it to <wxPython-2.8.12.0 - For some reason, errors happen when someone emerges or unmerges the ebuild at postinstall/postrm phases. These errors aren't fatal but can be alarming for users. Also I changed the ebuild in order to make it use the available portage functions. For me (~amd64 branch) it works fine now.
Created attachment 275685 [details] ebuild for dispcalGUI 0.7.0.7 New version 0.7.0.7 of dispcalGUI supports wxpython 2.8.12.0 (testing version for Gentoo). I changed the ebuild so it does not require you to stay with a stable version of wxpython. I am going to check this ebuild from time to time and post updates when needed. My only problem is that I only have a ~amd64 system to test if it works well. If a developer is willing to act as a proxy and submit it to the sunrise overlay, please do.
I will take it. Marios, I will be your proxy
Created attachment 275965 [details] ebuild for dispcalGUI 0.7.0.7 I corrected the latest ebuild's filename.
This package is now on portage. Thank you
Thank you Markos! I'll try my best to keep this package updated. I noticed that you tweaked the ebuild. So if anyone else wants to post updates, please remember to use the portage version as your starting point instead of the ebuilds attached in this bug.
