This is just a request so someone may add an ebuild for this package. I'll try to make an ebuild for conkeror in the coming days, but I cannot promise anything as I'm extremelly newbie at the matter and had lots of unsuccessful efforts with (probably) more simple packages. Here is a description borrowed from wikikedia about what is Conkeror: "Conkeror is a free, keyboard-driven, Mozilla-based web browser. It borrows as many key bindings as it can from GNU Emacs." (from http://en.wikipedia.org/wiki/Conkeror) Reproducible: Always
Created attachment 162220 [details] Ebuild for Conkeror (git snapshot) I've made an ebuild for this. It's not the most elegant of ebuilds, but it merges correctly on my rig. Please note that this ebuild uses a snapshot from Conkeror's git repository. Upstream doesn't seem to provide actual releases. This means that if the code were to radically change in the future, this ebuild might stop working.
I've added www-client/conkeror to the Emacs overlay today: <http://overlays.gentoo.org/proj/emacs/browser/emacs-overlay/www-client/conkeror> (In reply to comment #1) > I've made an ebuild for this. Sorry that I didn't check bugzilla first. After I committed the package to the overlay, someone has pointed out to me that this bug is already open... So thank you for the contribution, even if the ebuild in the Emacs overlay was now created independently. > Upstream doesn't seem to provide actual releases. I hope that they will at some point. Live ebuilds are problematic for several reasons and therefore we are reluctant to add them to the Portage tree.
Created attachment 168954 [details] Ebuild for Conkeror (no git) Thanks, Ulm! For my personal use, I've made a modification of your ebuild. It downloads the snapshot tarball instead of cloning the git repository (to avoid any git dependencies). I've attached it above if someone should find it useful.
(In reply to comment #3) > Created an attachment (id=168954) [edit] > Ebuild for Conkeror (no git) > > For my personal use, I've made a modification of your ebuild. It downloads > the snapshot tarball [...] SRC_URI="http://repo.or.cz/w/conkeror.git?a=snapshot;h=master;sf=tgz -> ${PF}.tar.gz" Does this actually work? I would expect to get a different distfile for different downloads, therefore digest verification would fail. Or what am I missing?
(In reply to comment #4) > (In reply to comment #3) > > Created an attachment (id=168954) [edit] > > Ebuild for Conkeror (no git) > > > > For my personal use, I've made a modification of your ebuild. It downloads > > the snapshot tarball [...] > > SRC_URI="http://repo.or.cz/w/conkeror.git?a=snapshot;h=master;sf=tgz -> > ${PF}.tar.gz" > > Does this actually work? I would expect to get a different distfile for > different downloads, therefore digest verification would fail. Or what am I > missing? If you set a fixed revision (which is possible), the snapshot should be the same...
(In reply to comment #5) > > SRC_URI="http://repo.or.cz/w/conkeror.git?a=snapshot;h=master;sf=tgz -> > > ${PF}.tar.gz" > If you set a fixed revision (which is possible), the snapshot should be > the same... Where do you see a fixed revision in above URI?
(In reply to comment #6) > (In reply to comment #5) > > > SRC_URI="http://repo.or.cz/w/conkeror.git?a=snapshot;h=master;sf=tgz -> > > > ${PF}.tar.gz" > > > If you set a fixed revision (which is possible), the snapshot should be > > the same... > > Where do you see a fixed revision in above URI? I only said it is possible, not that it happened.
www-client/conkeror-0.9_pre20090401 committed to Portage tree. (In reply to comment #5) > If you set a fixed revision (which is possible), the snapshot should be the > same... I've experimented with this: The snapshot is the same, but it is compressed on-the-fly, and gzip inserts a different timestamp (leading to a different digest/checksum of the file) for each fetch. Therefore, I've put the tarball on the Gentoo mirrors.
Created attachment 237129 [details] Ebuild for Conkeror (from git) updated ebuild for conkeror(from git)
Reassign the bug.
Thank you for your contribution, but I am not really inclined to add a live ebuild. What about you, Ulrich?
(In reply to comment #11) > Thank you for your contribution, but I am not really inclined to add a live > ebuild. What about you, Ulrich? The reasons from two years ago for _not_ adding a live ebuild still apply. We can prepare a new snapshot from git if you convince us that there are good reasons for that. (But then, you should first try to convince upstream to tag a new release. ;-)
