The available version still depends on dbus. The develeopment comes without DBus. http://forums.gentoo.org/viewtopic-p-7617702.html#7617702
It also needs to sport a gtk USE flag and a qt or qt4 USE flag.
Created attachment 384926 [details] dhcpcd-ui-0.7.1.ebuild Gentoo incorrectly complains about dhcpcd-gtk.desktop because Cinnamon is not a valid desktop entry, but freedesktop lists it as a standard. http://standards.freedesktop.org/menu-spec/latest/apb.html Gentoo correctly complains abiut dhcpcd-qt.desktop because LXQT is not a valid desktop entry. However, it does exist in Gentoo itself. The systemd USE flag just installs a service file for it for dhcpcd-online so applications like say Apache can wait till dhcpcd actually completes with a working network connection. Comments welcome.
Created attachment 384982 [details] net-misc/dhcpcd-ui-0.7.2.ebuild I cleaned up that old ebuild and removed gtk+ deps. USE flags are alos cleaned with a debug addition. gettext is a compilation requirement, so virtual/libintl was added. virtual/notification-daemon is used instead of plain libnotify because everyone who want notifications has a minimal DE if not those oversized DE. I prefer to use lightweight dunst and it is already in the virtual dependency. Thanks Roy for your contribution. I may give a help here and there if I have the time too. I highly follow dhcpcd related discussion and I am using it as a nm. I killed NM already. I may not contribute to maintain the ebuild here as I may keep it in my overlay (https://github.com/tokiclover/bar) for the time being. It is not a burden at all for now. Although I have to take a look and had a hard time realizing that I was trying to build 0.6.0 instead 7.1 (yeah I looked at the header and named the file accordingly...) Anyway, here is a cleaner version.
I could add a live ebuild... but hey that fossil svn is... too fossil. I may look at it tomorrow.
Wait, how I do retrieve the svn url with that js interface?!
(In reply to tokiclover from comment #4) > I could add a live ebuild... but hey that fossil svn is... too fossil. I may > look at it tomorrow. Look at the dhcpcd-9999 ebuild for the fossil interface.
(In reply to tokiclover from comment #3) > Created attachment 384982 [details] > net-misc/dhcpcd-ui-0.7.2.ebuild > > I cleaned up that old ebuild and removed gtk+ deps. USE flags are alos > cleaned with a debug addition. gettext is a compilation requirement, so > virtual/libintl was added. virtual/notification-daemon is used instead of > plain libnotify because everyone who want notifications has a minimal DE if > not those oversized DE. I prefer to use lightweight dunst and it is already > in the virtual dependency. Looks good! One comment though - I would drop the icons USE flag as dhcpcd-qt just won't work without icons. (Oddly enough dhcpcd-gtk might). Depend on the hicolor theme if qt, gtk or gtk3 are set I guess. > Thanks Roy for your contribution. I may give a help here and there if I have > the time too. > > I highly follow dhcpcd related discussion and I am using it as a nm. I > killed NM already. Awwww, thanks!
Created attachment 384994 [details] net-misc/dhcpcd-ui-9999.ebuild Well then, here the live version ebuild.
Created attachment 384996 [details, diff] dhcpcd-0.7.2.ebuild.patch And here a dhcpcd-0.7.2.ebuild.patch to update the versioned version.
(In reply to Roy Marples from comment #7) > Looks good! > One comment though - I would drop the icons USE flag as dhcpcd-qt just won't > work without icons. (Oddly enough dhcpcd-gtk might). > > Depend on the hicolor theme if qt, gtk or gtk3 are set I guess. > Well then, I added a qt4 USE requirement. icons USE flag is not sctrictly necessary, but as many good icons theme has a good network icons (e.g. faenza), it's not necessary to install those icons. However, I'd rather add +icons as a sane default. I leave it for discussion. And I removed the unecessary multilib eclass. By the way, I'd rather keep the system USE flag as too many maintainers are just too lazy for those unit sh*t and keep installing those files without a conditionnal requirement. I understand why so many people out there keep fighting unit sh*t files out of their system. I'm not going to use that crazy pid 1 binary any time soon in the future. And if ever I have, I might just drop gnu/linux altogether and go for bsd os. So please, keep the crap out! > Awwww, thanks! The pleasure is mine.
I forgot to mention that I left that lengthy KEYWORDS string from net-misc/dhcpcd... well, discussion is welcomed.
Oh well, launched dhcpcd-gtk as user and it says dhcpcd is offline?! I don't know how the ui talks to the daemon since there is no *kit crap. I don't remember what RM said about this. And I cannot get the preferences as it is grayed... How do normal user (in the wheel group) got a grip of network admin? I tried `sudo -g wheel dhcpcd-gtk' to no avail. NOTE: I volunteer for proxy maintaining this package for the time being.
(In reply to tokiclover from comment #12) > Oh well, launched dhcpcd-gtk as user and it says dhcpcd is offline?! I don't > know how the ui talks to the daemon since there is no *kit crap. I don't > remember what RM said about this. And I cannot get the preferences as it is > grayed... > > How do normal user (in the wheel group) got a grip of network admin? I tried > `sudo -g wheel dhcpcd-gtk' to no avail. dhcpcd needs to be running in master mode and not per interface. So don't use net.*, or if you really want to ensure that dhcpcd is passed the -M flag which *might* allow it to work. Also, you need either dhcpcd-6.4.4 with the unprivileged socket OR you need to be able to write to dhcpcd's socket. In newer versions you can say which group has RW access to it in dhcpcd.conf. The default config has a commented out section which allows wheel group access. You should enable this and ensure your user is in the wheel group. If not, you'll need to add it and log all the back out to pickup the change. Then it should be working fine. This is documented in dhcpcd-gtk(8) :)
If you don't want to be in the wheel group, but do want privileged access to dhcpcd, just set which group to use instead in dhcpcd.conf. Sorry if that's not clear.
(In reply to tokiclover from comment #12) [...] > NOTE: I volunteer for proxy maintaining this package for the time being. CCing proxy-maint team then :)
(In reply to Roy Marples from comment #14) > If you don't want to be in the wheel group, but do want privileged access to > dhcpcd, just set which group to use instead in dhcpcd.conf. > > Sorry if that's not clear. Thanks for your reply. It works perfectly well, without icons on a gtk+:2 based system without any dev-qt crufts, in a nice/neat ui. Thanks for this! I may help for E17 ui if you have the time for that. I have just forgot to update dhcpcd from 6.4.3 to 6.4.4 (writting those ebuilds very late in the night does not help.) dhcpcd-gtk-0.7.2(8) man page is less rich than what you said in the previous comment. I'm using dhcpcd-ui-0.7.2 for now because I don't have fossil vcs... at the moment.
(In reply to tokiclover from comment #16) > It works perfectly well, without icons on a gtk+:2 based system without any > dev-qt crufts, in a nice/neat ui. Thanks for this! I may help for E17 ui if > you have the time for that. Nice! Currently I don't have much time for a new port, the qt port took 5 years to write since the gtk inception! But I think dhcpcd itself is now pretty much feature complete from where I want it to be (which it wasn't 5 years ago) so maybe I will have more time for the UI stuff. But I'd like to write an OpenVPN configuration screen before any EFL work. > dhcpcd-gtk-0.7.2(8) man page is less rich than what you said in the previous > comment. I'm using dhcpcd-ui-0.7.2 for now because I don't have fossil > vcs... at the moment. The man pages for them have not changed since. They refer you read dhcpcd.conf(5) which has the socket setup details in full. Patches to improve the man pages are always welcome :)
(In reply to Roy Marples from comment #13) > (In reply to tokiclover from comment #12) > Also, you need either dhcpcd-6.4.4 [...] > Then it should be working fine. This is documented in dhcpcd-gtk(8) :) Indeed. Yes, I added dhcpcd-6.4.4 dependency to the ebuilds (https://github.com/tokiclover/bar-overlay sorry for repeating this long address but the previous was broken for a missing *-overlay*). Waiting to update the attached ebuilds...
we'd tend to not add live ebuild, also I'd suggest you strip the the live-ebuilds-logic from 0.7.2 (since it's not trivial..) can you double check the R/DEPEND? either via the config.mk file in the source or tools[1].. it might miss something. Ebuilds must not introduce USE=systemd in order to control unit file installation[2] [1] tools check RDEPEND (it's not for DEPEND) https://github.com/gentoo/kde/blob/master/Documentation/maintainers/dynlink-scanner [2] https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy
(In reply to Yixun Lan from comment #19) > we'd tend to not add live ebuild, also I'd suggest you strip the the > live-ebuilds-logic from 0.7.2 (since it's not trivial..) Why? Gentoo is the only platform I know that provides this and as an upstream maintainer I can say "can you try the live ebuild" vs "can you try my patch which may or may not apply to your current version?" It's easier both for myself and the end users, but if you insist on making life hard then that's you're choice. Gentoo was once the developers platform for users you know. > can you double check the R/DEPEND? either via the config.mk file in the > source or tools[1].. it might miss something. The depends are correct for each top level dependency. dhcpcd-ui does need qmake from qtcore to build, but that's brought in via qtgui. I forget how build time depends are handled here. No source directly uses any other libs. > Ebuilds must not introduce USE=systemd in order to control unit file > installation[2] Fine, I'm sure we can split off the systemd part into a separate ebuild which would have the same net effect of being user controllable.
(In reply to Roy Marples from comment #20) > Why? > Gentoo is the only platform I know that provides this and as an upstream > maintainer I can say "can you try the live ebuild" vs "can you try my patch > which may or may not apply to your current version?" > > It's easier both for myself and the end users, but if you insist on making > life hard then that's you're choice. Gentoo was once the developers platform > for users you know. > you can put the live ebuild into your overlay, and suggest user to pull that. generally speaking, the reason why we don't recommend live ebuild has been listed here[1]. > The depends are correct for each top level dependency. > dhcpcd-ui does need qmake from qtcore to build, but that's brought in via > qtgui. I forget how build time depends are handled here. > No source directly uses any other libs. > from my first glance, it also pull in x11-libs/gdk-pixbuf.. also it seems USE=gtk3 doesn't take effect. with my system gtk2, gtk3 installed it always link to gtk2, and USE="-gtk2 gtk3" result in no gtk application installed. there could be more problems here, so I said "please double check"... > Fine, I'm sure we can split off the systemd part into a separate ebuild > which would have the same net effect of being user controllable. No. don't split-off, just install the systemd unit file (we intend to install small files directly, it's a policy here, see the reference link)
sorry, forget the url link http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html Disadvantages of CVS Sources
(In reply to Yixun Lan from comment #21) > > The depends are correct for each top level dependency. > > dhcpcd-ui does need qmake from qtcore to build, but that's brought in via > > qtgui. I forget how build time depends are handled here. > > No source directly uses any other libs. > > > from my first glance, it also pull in x11-libs/gdk-pixbuf.. Neither dhcpcd-gtk nor dhcpcd-qt make any direct calls to gdk-pixbuf. If gtk itself does, that's gtk's problem isn't it? > also it seems USE=gtk3 doesn't take effect. with my system gtk2, gtk3 > installed > it always link to gtk2, and USE="-gtk2 gtk3" result in no gtk application > installed. That's currently correct, I need to fix my configure program to allow the user to specifiy which one - currently it prefers GTK2, but will work with GTK3 I cba to argue with the other points which is why I don't play much in this ground.
(In reply to Yixun Lan from comment #22) > sorry, forget the url link > > http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/ > index.html > > Disadvantages of CVS Sources Not even going to read it. I know the disadvantages, but then that's why there are no ACCEPT_KEYWORDS in a live ebuild. For a system that encourages to be different via USE flags, it seems to go out of the way to make it harder to allow users to participate in active development for the sake of QA. Poof, gone again.
(In reply to Yixun Lan from comment #19) > we'd tend to not add live ebuild, also I'd suggest you strip the the > live-ebuilds-logic from 0.7.2 (since it's not trivial..) Are kidding me or something? There live ebuilds all over the place, it's just versioned are prefered to live etc. Well, I'm not going to waste my time on that. > can you double check the R/DEPEND? either via the config.mk file in the > source or tools[1].. it might miss something. Dependencies where checked... if you have read the previous posts. > Ebuilds must not introduce USE=systemd in order to control unit file > installation[2] Again, see we have to make war for other people stupidity? Comme on, give a break. This is one of the reason I could rm -f `/usr/lib/systemd' shit. I'm leaving it there for more constructive criticisms. I repeat, I volunteer to proxy maintain this ebuild, however if I have to undergo that kind of bossing... I will leave the hot potato. > [1] tools check RDEPEND (it's not for DEPEND) > https://github.com/gentoo/kde/blob/master/Documentation/maintainers/dynlink- > scanner > [2] https://wiki.gentoo.org/wiki/Project:Systemd/Ebuild_policy
(In reply to Roy Marples from comment #23) > > also it seems USE=gtk3 doesn't take effect. with my system gtk2, gtk3 > > installed > > it always link to gtk2, and USE="-gtk2 gtk3" result in no gtk application > > installed. > > That's currently correct, I need to fix my configure program to allow the > user to specifiy which one - currently it prefers GTK2, but will work with > GTK3 Actually I don't ./configure --with-gtk=gtk+-2.0 or ./configure --with-gtk=gtk+-3.0 works fine
(In reply to Roy Marples from comment #26) > Actually I don't > > ./configure --with-gtk=gtk+-2.0 > or > ./configure --with-gtk=gtk+-3.0 > > works fine Of course, I have read the configure script (well, part of it to write the builds) and I did notice the WITH_GTK=${var:-yes}... I am updating the ebuilds then... not here. Still waitting for a batch update.
I have forgot the gtk3 USE flag in src_configure(), queued for update as well.
Well then if Gentoo systemd policy is pill up unit shit, I will remove the systemd USE flag when attaching an updated ebuild here. Updates are available in y overlay for the time being. I will keep rm-f-ing systemd files manually. Fight other stupid wars then! Right on!
(In reply to tokiclover from comment #29) > Well then if Gentoo systemd policy is pill up unit shit, I will remove the > systemd USE flag when attaching an updated ebuild here. Updates are > available in y overlay for the time being. > > I will keep rm-f-ing systemd files manually. Fight other stupid wars then! > Right on! man make.conf grep for INSTALL_MASK
Created attachment 385640 [details] net-misc/dhcpcd-ui-0.7.2.ebuild Lets add an updated ebuild and obsolete the previous ones.
----- if [[ ${PV} == "9999" ]]; then DEPEND+=" dev-vcs/fossil" src_unpack() { local distdir=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}} local repo=${distdir}/fossil/${PN}.fossil addwrite "${distdir}" if [[ -e "${repo}" ]]; then fossil pull "${FOSSIL_URI}" -R "${repo}" || die else mkdir -p "${distdir}/fossil" || die fossil clone "${FOSSIL_URI}" "${repo}" || die fi mkdir -p "${S}" || die cd "${S}" || die fossil open "${repo}" || die } fi ------ No no no no. This is very ugly. If you *really* want to support 9999 please provide an src_unpack() {} and do all the PV=9999 conditions inside that function. Not in global scope. However, I see no reason to support -9999 for now, so please drop all the -9999 sections from the ebuild and keep only those needed for 0.7.2
(In reply to Markos Chandras from comment #32) > No no no no. This is very ugly. If you *really* want to support 9999 please > provide an src_unpack() {} and do all the PV=9999 conditions inside that > function. Not in global scope. However, I see no reason to support -9999 for > now, so please drop all the -9999 sections from the ebuild and keep only > those needed for 0.7.2 Sure it looks intersting to not *ugly*, no I did not say ugly. Well truth to be said, I did not know anything about fossile VCS a few days ago. So, I've just copied that part over net-misc/dhcpcd 'as is'. I can look at that later... sure a proper src_unpack() will be better. A part for the dependency, everything should/could be in a src_unpack(). Well, I will attach another ebuild later. However, as net-misc/dhcpcd has the same bits, it could be postponed or queued for wanted/futur improvements.
Created attachment 385874 [details] net-misc/dhcpcd-ui-0.7.2.ebuild The "no no no no" of Markos was revealing, so let's clean up a little and add a proper `src_unpack()'. I've just slightly modified the repository directory to follow Gentoo way (git goes DISTDIR/egit-src, svn goes to DISTDIR/svn-src) so fossil goes to DISTDIR/fossil-src. fossil seems to be a KISS VCS tools under BSD-2 rather than a overwhelming, well THE VCS SWISS ARMY KNIFE, git. And dhcpcd-ui is under *active* developement (Roy M. get busier and busier with it lately!), so a live ebuild won't hurt.
So, let's review this ebuild. If the live bits do not fit in, it will be removed. Let's keep it simple! and not waste too much time on it.
Darn, there is a missing `-ui' in `FOSSIL_URI' value. It is fixed in my overlay. And it will be added in the submission ebuild if the live bits pass the review (or the trash hole wait for that.)
Comment on attachment 385874 [details] net-misc/dhcpcd-ui-0.7.2.ebuild ># Copyright 1999-2014 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># $Header: net-misc/dhcpcd-ui/dhcpcd-ui-0.7.2.ebuild,v 1.1 2014/09/18 18:29:24 -tclover Exp $ > >EAPI=5 > >if [[ ${PV} == "9999" ]]; then > FOSSIL_URI="http://roy.marples.name/projects/dhcpcd" > DEPEND="dev-vcs/fossil" Again, Do you really need to support 9999 and regular version in a single ebuild? If so, why? Would it be cleaner to move the 9999 to a separate ebuild? The addwrite parts below look a bit ugly. Perhaps you can keep the 9999 in your overlay? >else > SRC_URI="http://roy.marples.name/downloads/${PN}/${P}.tar.bz2" > KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~amd64-linux ~arm-linux ~x86-linux" Have you really tested this package in all the architectures listed above^^^? if not, only add those that you have tested it on >fi > >inherit eutils systemd > >DESCRIPTION="Desktop notification and configuration for dhcpcd" >HOMEPAGE="http://roy.marples.name/projects/dhcpcd-ui/" > >LICENSE="BSD-2" >SLOT="0" >IUSE="debug gtk gtk3 icons qt4 libnotify" >REQUIRED_USE="qt4? ( icons )" > >DEPEND="${DEPEND} > virtual/libintl > libnotify? ( virtual/notification-daemon ) > gtk? ( x11-libs/gtk+:2 ) > gtk3? ( x11-libs/gtk+:3 ) Can gtk and gtk3 used together? If not, see if you can use the REQUIRED_USE > qt4? ( dev-qt/qtgui )" Add :4 as well so Qt5 won't be pulled. > >RDEPEND="${DEPEND} In case of the 9999 ebuild, fossil will be a RDEPEND which is wrong. > >=net-misc/dhcpcd-6.4.4 > !icons? ( x11-themes/hicolor-icon-theme )" > >src_unpack() >{ > if [[ "${PV}" == 9999* ]]; then > local distdir="${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}"/fossil-src > local repo="${distdir}"/${PN}.fossil > > addwrite "${distdir}" > > if [[ -e "${repo}" ]]; then > fossil pull "${FOSSIL_URI}" -R "${repo}" || die > else > mkdir -p "${distdir}/fossil" || die > fossil clone "${FOSSIL_URI}" "${repo}" || die > fi > > mkdir -p "${S}" || die > cd "${S}" || die > fossil open "${repo}" || die > else > default > fi Again please consider moving the 9999 bits into a separate ebuild. I don't feel comfortable having all this code into the portage tree. >} > >src_prepare() >{ > epatch_user >} > >src_configure() >{ > local myeconfargs=( > $(use_enable debug) > $(use_with icons) > $(use gtk && echo '--with-gtk=gtk+-2.0') > $(use gtk3 && echo '--with-gtk=gtk+-3.0') > $(use_with qt4 qt) > $(use_enable libnotify notification) Indentation. > ) > econf "${myeconfargs[@]}" >} > >src_install() >{ > emake DESTDIR="${D}" INSTALL_ROOT="${D}" install > > systemd_dounit src/dhcpcd-online/dhcpcd-wait-online.service Any documents to install? (dodoc etc)
(In reply to Markos Chandras from comment #37) > >DEPEND="${DEPEND} > > virtual/libintl > > libnotify? ( virtual/notification-daemon ) > > gtk? ( x11-libs/gtk+:2 ) > > gtk3? ( x11-libs/gtk+:3 ) > > Can gtk and gtk3 used together? If not, see if you can use the REQUIRED_USE gtk and gtk3 cannot be used together. libnotify is for gtk2/gtk3 only. the qt build also supports KDE notifications, so optionally depend on kde-base/kdelibs From a configure POV, --enable-notifications pully in libnotify for gtk2/3 and kdelibs for qt. > Any documents to install? (dodoc etc) Nothing other than man pages, which should be handled correctly. BTW, I released dhcpcd-ui-0.7.3 which is already in pkgsrc, so catchup :)
Created attachment 386256 [details] net-misc/dhcpcd-ui-0.7.3.ebuild Lets get the versioned ebuild into the main tree then. Only the gtk/gtk3 merge was rejected because of the way the package configure script, it is not possible to merge that. Just take a look of src_configure(). The previous SRC_URI fix was also broken! ... it is now fixed in this ebuild. Lastly, I am not going to open a new bug for the live version inclusion. So, if the updated live ebuild does not make it to the review, I will keep it in my overlay anyway. I did not remove the versioned bits from it, just updated following the previous comment of Markos. Lets get it in!
libnotify? ( virtual/notification-daemon ) Not sure about that I would go with something like this (not tested, just to show the intent) notify? ( gtk? || gtk3? ( virtual/notification-daemon ) qt4? ( kde-base/kdelibs ) ) Even then, the gtk build links directly to libnotify and I don't know if the virtual satisfies that or not.
(In reply to Roy Marples from comment #40) > libnotify? ( virtual/notification-daemon ) > > Not sure about that I would go with something like this (not tested, just to > show the intent) > > notify? ( > gtk? || gtk3? ( virtual/notification-daemon ) > qt4? ( kde-base/kdelibs ) > ) > > Even then, the gtk build links directly to libnotify and I don't know if the > virtual satisfies that or not. Right. I was trying to not deal directly with x11-libs/libnotify as users who want notifacation have a daemon or something that deal with notifaction. Well, it's not that simple. gtk apps/daemon or x11-misc/notification-daemon will pull in libnotify. I guess the virtual dependency is satisfactory. Does it make sense to keep it? I don't know for qt based deps. Only kde-base/knotify will pull in kdelibs (which has a big qt dep list, so this is for those who have an almost full KDE set). It's unclear for the light weight qt based apps. I am not familiar with qt apps, it looks like lxqt-notificationd and razorqt-notifications will not. The later does not really matter because the former should replace it. So I've update the ebuilds in my overlay with: --- libnotify? ( gtk? ( x11-libs/libnotify ) gtk3? ( x11-libs/libnotify ) qt4? ( kde-base/kdelibs ) ) --- I can attach a new ebuild here it that satisfy Markos or other reviewers. Note: enlightenment and awesome (present in virtual/libnotification-daemon) are out of this discussion.
(In reply to tokiclover from comment #39) > Created attachment 386256 [details] > net-misc/dhcpcd-ui-0.7.3.ebuild Could you please move 0.7.3 to portage
The latest ebuild looks good to me. I will move it to the tree right now
I am seeing that IUSE.invalid 2 net-misc/dhcpcd-ui/dhcpcd-ui-0.7.3.ebuild: gtk3 net-misc/dhcpcd-ui/dhcpcd-ui-0.7.3.ebuild: icons Could you provide some good descriptions for these two local use flags so I can add them to metadata.xml? thanks
(In reply to Roy Marples from comment #38) > (In reply to Markos Chandras from comment #37) > > >DEPEND="${DEPEND} > > > virtual/libintl > > > libnotify? ( virtual/notification-daemon ) > > > gtk? ( x11-libs/gtk+:2 ) > > > gtk3? ( x11-libs/gtk+:3 ) > > > > Can gtk and gtk3 used together? If not, see if you can use the REQUIRED_USE > > gtk and gtk3 cannot be used together. Then the ebuild is wrong because right now one can enable gtk and gtk3 and get something else from what he expects. Can we please fix this using REQUIRED_USE?
(In reply to Markos Chandras from comment #45) > Then the ebuild is wrong because right now one can enable gtk and gtk3 and > get something else from what he expects. Can we please fix this using > REQUIRED_USE? Fixed in a commit (and added a metadata file) with: --- REQUIRED_USE="|| ( gtk gtk3 qt4 ) gtk3? ( !gtk ) gtk? ( !gtk3 ) qt4? ( icons )" --- Please sync to latest ebuilds.
(In reply to tokiclover from comment #46) > (In reply to Markos Chandras from comment #45) > > Then the ebuild is wrong because right now one can enable gtk and gtk3 and > > get something else from what he expects. Can we please fix this using > > REQUIRED_USE? > > Fixed in a commit (and added a metadata file) with: Thanks, but where is the metadata.xml file? What commit are you referring to?
(In reply to Markos Chandras from comment #47) > Thanks, but where is the metadata.xml file? What commit are you referring to? There is a commit a day ago... I've just slightly edited the description (in the latest commit 27071c9).
(In reply to tokiclover from comment #48) > (In reply to Markos Chandras from comment #47) > > Thanks, but where is the metadata.xml file? What commit are you referring to? > > There is a commit a day ago... I've just slightly edited the description (in > the latest commit 27071c9). i don't understand. What repository are you referring to? could you point me to a link? alternatively could you attach the metadata and ebuild here?
(In reply to Markos Chandras from comment #49) > i don't understand. What repository are you referring to? could you point me > to a link? alternatively could you attach the metadata and ebuild here? Sorry to confuse you... I'm refering to my overlay: https://github.com/tokiclover/bar-overlay. I could attach new files and updates here later to avoid confusions. I just avoided unecessary bandwith waste.
Created attachment 388922 [details] net-misc/dhcpcd-ui-0.7.4.ebuild
Created attachment 388926 [details] net-misc/metadata.xml The ditfile hash are available in Manifest in my overlay.
+*dhcpcd-ui-0.7.4 (09 Nov 2014) + + 09 Nov 2014; Markos Chandras <hwoarang@gentoo.org> +dhcpcd-ui-0.7.4.ebuild, + metadata.xml: + Version bump. Thanks to tokiclover <tokiclover@gmail.com>. Bug #522854 +
There is no live ebuild in the main tree.
OK, so this bug report turned out to be about a version bump. It's not about a live ebuild after all.
