I am submitting an ebuild for a newly released project, grubconf. Attached is grubconf-ebuild.tar.gz with the folowing contents: grubconf/ grubconf/files/ grubconf/files/digest-grubconf-0.1.1 grubconf/grubconf-0.1.1.ebuild Grub Conf is a Gnome2 based GRUB configuration editor. It provides an easy to use interface allowing effortless modification of OS's and the flexibility to configure the most obscure options. I suggest the ebuild be placed in the app-admin category under the portage tree. Its dependancies are grub and gtk2. - Joe Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 8041 [details] grubconf-0.1.1 ebuild The archives contents are: grubconf/ grubconf/files/ grubconf/files/digest-grubconf-0.1.1 grubconf/grubconf-0.1.1.ebuild
gnome app. fyi, the DEPEND and IUSE need to be fixed.
*** Bug 15803 has been marked as a duplicate of this bug. ***
wasnt there a 0.2 release by now ?
Created attachment 8346 [details] Ebuilds for grubconf 0.1.1 (modified to fix IUSE and DEPEND), and also for 0.2 I was going to submit a new bug for grubconf-0.2 ebuild, but I think that by fixing-up the original (added ChangeLog, fixed IUSE and DEPEND), and including the 0.2 ebuild we save some headaches for the developers :-)
Created attachment 8348 [details] Fixed ebuilds.tar.gz (ignore last one) I was using gtk+-2.0*, should be gtk+-2.2* to reflect latest stable. Updated .tar.gz to reflect
Thanks for fixing my ebuild and adding the newly released v0.2 ebuild :) I've never written one before so I really had no idea what I was doing.
Created attachment 8421 [details] Final ebuild set (We hope ;-)) After some discussion with Joe (The project manager for grubconf), we determined the proper DEPEND lines for the ebuild. Everything should be copistatic now :-)
Comment on attachment 8041 [details] grubconf-0.1.1 ebuild new ebuilds made this obsolete
Version 0.3 was released today, anyone want to update the ebuild?
Created attachment 10508 [details] updated 0.4 ebuild I just released a new version of grubconf and updated the ebuild. I also changed the DEPEND and RDEPEND a bit after looking through several ebuilds that used the same thing. If its wrong please let me know. Thanks!
joseph, you're the author of grubconf, right? before we put this into portage, there's a errno problem when compiling with glibc 2.3.2. partitioning.o(.text+0xdc): In function `_llseek': /home/acnt2/bin/partitioning.c:77: undefined reference to `errno' partitioning.o(.text+0x296): In function `get_sector': /home/acnt2/bin/partitioning.c:145: undefined reference to `errno' you need to add: #include <errno.h> to all the files that use the variable errno. do you want to fix that in the source rather than us hacking a patch for it?
Alastair, Yes, I'm the author. Thanks for pointing that out. I made the changes and updated the CVS and the 0.4 tarball on sourceforge with the fix.
one more small thing that's breaking sandbox. in omf.make, you've got scrollkeeper-update running twice. it doesn't seem to be necessary: install-data-hook-omf: $(mkinstalldirs) $(DESTDIR)$(omf_dest_dir) for file in $(omffile); do \ $(INSTALL_DATA) $$file.out $(DESTDIR)$(omf_dest_dir)/$$file; \ done -scrollkeeper-update -p $(scrollkeeper_localstate_dir) -o $(DESTDIR)$(omf_dest_dir) -scrollkeeper-update you should remove the last -scrollkeeper-update because it breaks our sandbox and possibly anybody who tries to package it.
Sorry about that. I'm kindof new at this. The 0.4 tarball on sourceforge is updated.
another small thing then, i think you should do minor version bumps when you fix things like that. It's very confusing when you fix things in already released packages. In our case it would give digest problems if it had already been in the tree.
I agree with you. I'll be sure to put updates in a new release in the future. Thanks for your help.
I'm wondering how the maintanance of this package would work in portage. Who would do this? or should/could it be me? I'm basically wondering how new releases will be added to the tree and things like that. Also, do you think the ~x86 keyword is appropriate? It will take a few releases for grubconf to be "stable" and I cant yet delcare the ebuild "stable", so I think for now it fits. Thanks!
we would maintain it, but if we don't update within reasonable time after a release is done you can just open an update request about it. The purpose of ~ is to test the ebuild and it should be possible to mark it stable after a while if no problems arise. But if you (the developer) don't consider the package stable, it shouldn't really be added to the tree.
Is there anyone I should contact when there is a new release? Or will the maintainer try to keep track of that? Concerning the stability of grubconf; from my testing and feedback (or lack of bug reports) from users I can't see any reason to consider this package unstable. What I meant by my comment "It will take a few releases for grubconf to be stable" is more that my personal goals for grubconf are not going to be complete until 1.0, but the current state of grubconf is still a solid package and I would consider it useful to users.
committed to portage. it works well for me. please keep in mind, that releases should not be "modified" after they're released. its a good idea to introduce fixes into another (bugfix) release rather than constantly modifying the same tarball. otherwise you might as well have just dail snapshots :) moreover, if you modify the tarball, it'll break our md5 digests.
Understood. Thanks for your help!
