Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 522854 - net-misc/dhcpcd-ui-0.7.4 version bump
Summary: net-misc/dhcpcd-ui-0.7.4 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: tokiclover
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-15 10:38 UTC by charles17
Modified: 2014-12-03 12:17 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dhcpcd-ui-0.7.1.ebuild (dhcpcd-ui-0.7.1.ebuild,1.05 KB, text/plain)
2014-09-17 08:44 UTC, Roy Marples
Details
net-misc/dhcpcd-ui-0.7.2.ebuild (dhcpcd-ui-0.7.2.ebuild,1.05 KB, text/plain)
2014-09-18 01:33 UTC, tokiclover
Details
net-misc/dhcpcd-ui-9999.ebuild (dhcpcd-ui-9999.ebuild,1.78 KB, text/plain)
2014-09-18 09:32 UTC, tokiclover
Details
dhcpcd-0.7.2.ebuild.patch (dhcpcd-ui-0.7.2.ebuild.patch,2.13 KB, patch)
2014-09-18 09:34 UTC, tokiclover
Details | Diff
net-misc/dhcpcd-ui-0.7.2.ebuild (dhcpcd-ui-0.7.2.ebuild,1.85 KB, text/plain)
2014-09-28 07:40 UTC, tokiclover
Details
net-misc/dhcpcd-ui-0.7.2.ebuild (dhcpcd-ui-0.7.2.ebuild,1.88 KB, text/plain)
2014-10-01 08:59 UTC, tokiclover
Details
net-misc/dhcpcd-ui-0.7.3.ebuild (dhcpcd-ui-0.7.3.ebuild,1.18 KB, text/plain)
2014-10-08 19:26 UTC, tokiclover
Details
net-misc/dhcpcd-ui-0.7.4.ebuild (dhcpcd-ui-0.7.4.ebuild,1.28 KB, text/plain)
2014-11-09 11:05 UTC, tokiclover
Details
net-misc/metadata.xml (metadata.xml,410 bytes, text/xml)
2014-11-09 11:06 UTC, tokiclover
Details

Note You need to log in before you can comment on or make changes to this bug.
Description charles17 2014-09-15 10:38:25 UTC
The available version still depends on dbus. The develeopment comes without DBus.

http://forums.gentoo.org/viewtopic-p-7617702.html#7617702
Comment 1 Roy Marples 2014-09-15 10:46:59 UTC
It also needs to sport a gtk USE flag and a qt or qt4 USE flag.
Comment 2 Roy Marples 2014-09-17 08:44:50 UTC
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.
Comment 3 tokiclover 2014-09-18 01:33:53 UTC
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.
Comment 4 tokiclover 2014-09-18 01:35:04 UTC
I could add a live ebuild... but hey that fossil svn is... too fossil. I may look at it tomorrow.
Comment 5 tokiclover 2014-09-18 01:45:34 UTC
Wait, how I do retrieve the svn url with that js interface?!
Comment 6 Roy Marples 2014-09-18 07:21:10 UTC
(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.
Comment 7 Roy Marples 2014-09-18 08:31:19 UTC
(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!
Comment 8 tokiclover 2014-09-18 09:32:55 UTC
Created attachment 384994 [details]
net-misc/dhcpcd-ui-9999.ebuild

Well then, here the live version ebuild.
Comment 9 tokiclover 2014-09-18 09:34:31 UTC
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.
Comment 10 tokiclover 2014-09-18 09:45:06 UTC
(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.
Comment 11 tokiclover 2014-09-18 09:47:46 UTC
I forgot to mention that I left that lengthy KEYWORDS string from net-misc/dhcpcd... well, discussion is welcomed.
Comment 12 tokiclover 2014-09-18 10:09:21 UTC
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.
Comment 13 Roy Marples 2014-09-18 10:15:33 UTC
(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) :)
Comment 14 Roy Marples 2014-09-18 10:17:06 UTC
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.
Comment 15 Pacho Ramos gentoo-dev 2014-09-18 11:13:34 UTC
(In reply to tokiclover from comment #12)
[...] 
> NOTE: I volunteer for proxy maintaining this package for the time being.

CCing proxy-maint team then :)
Comment 16 tokiclover 2014-09-18 13:19:49 UTC
(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.
Comment 17 Roy Marples 2014-09-18 14:27:00 UTC
(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 :)
Comment 18 tokiclover 2014-09-18 15:55:31 UTC
(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...
Comment 19 Yixun Lan archtester gentoo-dev 2014-09-19 06:13:31 UTC
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
Comment 20 Roy Marples 2014-09-19 08:11:33 UTC
(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.
Comment 21 Yixun Lan archtester gentoo-dev 2014-09-19 09:19:30 UTC
(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)
Comment 22 Yixun Lan archtester gentoo-dev 2014-09-19 09:35:32 UTC
sorry, forget the url link

http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html

Disadvantages of CVS Sources
Comment 23 Roy Marples 2014-09-19 09:37:37 UTC
(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.
Comment 24 Roy Marples 2014-09-19 09:41:19 UTC
(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.
Comment 25 tokiclover 2014-09-19 10:22:28 UTC
(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
Comment 26 Roy Marples 2014-09-19 10:32:21 UTC
(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
Comment 27 tokiclover 2014-09-19 10:46:29 UTC
(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.
Comment 28 tokiclover 2014-09-19 10:52:54 UTC
I have forgot the gtk3 USE flag in src_configure(), queued for update as well.
Comment 29 tokiclover 2014-09-19 11:04:12 UTC
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!
Comment 30 Manuel Rüger (RETIRED) gentoo-dev 2014-09-19 11:07:10 UTC
(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
Comment 31 tokiclover 2014-09-28 07:40:50 UTC
Created attachment 385640 [details]
net-misc/dhcpcd-ui-0.7.2.ebuild

Lets add an updated ebuild and obsolete the previous ones.
Comment 32 Markos Chandras (RETIRED) gentoo-dev 2014-09-30 20:56:01 UTC
-----
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
Comment 33 tokiclover 2014-09-30 21:33:22 UTC
(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.
Comment 34 tokiclover 2014-10-01 08:59:47 UTC
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.
Comment 35 tokiclover 2014-10-01 11:47:55 UTC
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.
Comment 36 tokiclover 2014-10-01 14:01:57 UTC
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 37 Markos Chandras (RETIRED) gentoo-dev 2014-10-04 10:52:52 UTC
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)
Comment 38 Roy Marples 2014-10-07 01:20:51 UTC
(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 :)
Comment 39 tokiclover 2014-10-08 19:26:55 UTC
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!
Comment 40 Roy Marples 2014-10-09 20:39:48 UTC
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.
Comment 41 tokiclover 2014-10-10 08:11:03 UTC
(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.
Comment 42 charles17 2014-10-22 06:23:45 UTC
(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
Comment 43 Markos Chandras (RETIRED) gentoo-dev 2014-11-07 21:57:04 UTC
The latest ebuild looks good to me. I will move it to the tree right now
Comment 44 Markos Chandras (RETIRED) gentoo-dev 2014-11-07 22:00:40 UTC
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
Comment 45 Markos Chandras (RETIRED) gentoo-dev 2014-11-08 13:27:51 UTC
(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?
Comment 46 tokiclover 2014-11-08 20:46:58 UTC
(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.
Comment 47 Markos Chandras (RETIRED) gentoo-dev 2014-11-08 22:55:58 UTC
(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?
Comment 48 tokiclover 2014-11-09 09:03:16 UTC
(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).
Comment 49 Markos Chandras (RETIRED) gentoo-dev 2014-11-09 09:25:40 UTC
(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?
Comment 50 tokiclover 2014-11-09 11:03:32 UTC
(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.
Comment 51 tokiclover 2014-11-09 11:05:12 UTC
Created attachment 388922 [details]
net-misc/dhcpcd-ui-0.7.4.ebuild
Comment 52 tokiclover 2014-11-09 11:06:36 UTC
Created attachment 388926 [details]
net-misc/metadata.xml

The ditfile hash are available in Manifest in my overlay.
Comment 53 Markos Chandras (RETIRED) gentoo-dev 2014-11-09 11:20:56 UTC
+*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
+
Comment 54 Jeroen Roovers (RETIRED) gentoo-dev 2014-12-03 12:11:58 UTC
There is no live ebuild in the main tree.
Comment 55 Jeroen Roovers (RETIRED) gentoo-dev 2014-12-03 12:17:04 UTC
OK, so this bug report turned out to be about a version bump. It's not about a live ebuild after all.