As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc. We are working on this issue, and gtk-doc will be optional in the near future.

grey_dot ...

I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work. The attatched ebuild has the necessary changes required, I also had to change 'dodoc' to remove 'Changelog' and 'NEWS' as they are nolonger in the git repo.

case $? in
0) einfo "Your current kernel version (${KV_FULL}) is new enough to run ${P}."
;;
1) eerror "Your current kernel version (${KV_FULL}) is too old to run ${P}."
eerror "You need at least ${KV_MIN}."
;;
esac

If you can contribute to your favourite branch then you'd probably work at making that other side better and more attractive. Giving up before the unwanted is making it the only one rising. Maybe your contributions will greatly help, don't you think?

perhaps. But I am a little fish, and the desktop does not butter my bread. We've lost udev, and unless someone pulls rank on Poettering, with it we lose the desktop. Money, is what talks. If RH Inc begins to lose money over this, heads will roll, and the necessary walkbacks will happen. Their enterprise customers should raise holy hell over this. Along the lines of, "Hi, we're a Fortune 500 company, we rely on you to provide us a stable secure server platform for our critical business infrastructure. Why the fuck is Gnome development even involved, and why are you changing a critical component of our server platform for the sake of a fucking desktop environment?" That, is the best contribution anyone can make to this.

VinzC wrote:

What also pisses me off somehow is Gnome stuff ruling the rest of the system packages. *That* I really don't like. In the end, what will mostly distinguish distributions is only their package manager. One systemd to rule them all... just as if there were only one way to boot a machine, run services and manage hardware devices.

it's braindead. Completely and totally braindead. Device management is not simply a novelty item for desktop users. Linux makes its money as a server platform. Server platforms also need a dev manager. It's as though they've forgotten the world even exists outside of a home user's desktop, that people actually use linux for something other than running Gnome. How in the blue fuck someone thought it was a great idea to let THAT drive development is completely baffling to me.

And this is a perfect example:

grey_dot wrote:

As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc.

^^what in the blue fuck should gtk have to do with udev? why is gtk infesting a device management system?
(NB: grey_dot, that isn't directed at you, by the way. I'm just using the example of udev defaulting to relying on gtk-doc to hammer home the point of the amount of stupid that's made its way into udev. Pretty soon we'll see Frozen Bubble as a build dependency for udev)_________________Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

Very nice! I've been reading up on mdev and thinking about trying it out - I may just try this out soon instead

@sitquietly
If you are who I think you are, welcome, have you finally left the makeworld manipulation behind too?

Good to be here.

Uh, well, I'm known as sitquietly in the Arch forums too (the guy from Moscow Tennessee). I bought a SanDisk Extreme ssd for Gentoo and do maintain my Arch from-source install on my old Intel X-25E ssd. Maintaining the Arch system is not too demanding for me since I'm maintaining a database of all Archlinux packages (abs + aur) and use some custom scripts for maintenance, but customizing Arch pkgbuilds requires that I manually carry forward my local changes using meld: it's semi-automated and not remotely as nice as the portage system.

I'm still playing with both my custom Archlinux and with Funtoo to make sure I "know what I'm talking about." So far I can say that Funtoo/Gentoo has far superior engineering in its ebuilds than Arch's pkgbuilds, a proper o.s. development model, a more flexible and useful system maintenance technology, better kernels, more packages. It is probably the right basis for what I'm building, a purpose-built scientific linux suitable for autonomous systems, e.g. off-grid, off-the-radar applications or deep-space missions

There is much discussion over in the Archlinux forum about the speed of bootup with systemd. It seems, well, nuts to me. I got my Intel Sandybridge i5 bootup time (grub prompt to linux console prompt) down from 17.8 seconds with Archlinux to 8.5 seconds with Funtoo using a simple, reliable (no initrd) kernel (debian-sources 3.2.23 with the realtime patches) with Gentoo OpenRC/udev.

I assume you are Psykorgasm in the Archlinux forum, the guy from England...

As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc.

^^what in the blue f*** should gtk have to do with udev? why is gtk infesting a device management system?
(NB: grey_dot, that isn't directed at you, by the way. I'm just using the example of udev defaulting to relying on gtk-doc to hammer home the point of the amount of stupid that's made its way into udev. Pretty soon we'll see Frozen Bubble as a build dependency for udev)

cach0rr0 ... this isn't actually the case though, grey_dot was mistaken. Its just an automake issue that appears when running elibtoolize. Its easily fixed (see the ebuild above).

Otherwise, I agree, far too much user facing gumpf is being pushed deeper and deeper into the OS, and it shouldn't be there, no does it need to be. The problem, as I see it, is that the very concept of 'the desktop' is from an altogether different paradigm to 'unix', so its very much like mixing water and oil, they will seperate out unless you agitate constantly. So the dream of the 'Desktop OS' (and the desktop in general) with its 'unix underpinnings' is, I think, a failed one, but it none the less still has a strong following, and it is this as much as the developers that are driving this madness.

As for now, udev needs gtkdocize from gtk-doc to be run before autoconf/automake, so you have to install gtk-doc.

^^what in the blue fuck should gtk have to do with udev? why is gtk infesting a device management system?
(NB: grey_dot, that isn't directed at you, by the way. I'm just using the example of udev defaulting to relying on gtk-doc to hammer home the point of the amount of stupid that's made its way into udev. Pretty soon we'll see Frozen Bubble as a build dependency for udev)

gtk-doc is a documentation generator, it does not need gtk to work and it is not a runtime dependency. Besides, I've just made it optional. So, if you do not need api documentation, you have nothing to worry about.

khayyam wrote:

I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work.

It was still needed at that time. And we have not /docs directory, thus gtkdocize must be run without arguments. Check autogen.sh script in the repo.

The Unix philosophy is about modularity and clarity -- i.e, developer/power user friendly. A toolbox.

The aim of the "Desktop OS" is integration and opacity -- i.e., "grandma" friendly. An appliance.

That said, OSX and Android seem to accomplish the feat of layering a desktop on a Unix base. How do they manage? Do they require the same cruft in the Unix layer that GNOME is pushing for?_________________Personal overlay | Simple backup scheme

its very much like mixing water and oil, they will seperate out unless you agitate constantly.

I very much like this comparison. They've already started to separate judging from what we're talking about. And if we consider making much noise around this very topic, it would compare to agitation.

I'd add to what cach0rr0 said, what I have learnt from Linux (and possibily UNIX) is to minimize dependencies and functionalities for greater independence. Making a desktop system rely upon one given system manager is breaking that barrier. Not only does it taint all distributions but it also enforces unwanted and unneeded dependencies from the system management point of view. Unifying all platforms might be not a bad idea IMHO but only if you stay on the user's desktop side.

Gnome devs didn't listen to their user base. Now they're back doing the same with system admins, breaking independence. That's very sad._________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...1739!

I had sometime to look at the issue and it can be built without gtkdocize, so USE="-doc" does currently work.

It was still needed at that time. And we have not /docs directory, thus gtkdocize must be run without arguments. Check autogen.sh script in the repo.

grey_dot ... I did look at the autogen.sh and though no */docs exist the gtk-doc.make is looked for by automake in the directory where its run and so the above ebuild works. Of course, I may have did my 'ebuild udev-9999.ebuild compile' at a time after any commits were made, but from what I could gleen from udev-9999::gentoo this is also how they avoid the need for gtkdocize, and so I think your mistaken that it won't compile without it, but no biggy.

Hypnos wrote:

[...] OSX and Android seem to accomplish the feat of layering a desktop on a Unix base. How do they manage? Do they require the same cruft in the Unix layer that GNOME is pushing for?

Imagine your hand as a pointing device, you can point at an object, direct it, etc, and some invisible force does all the work necessary to follow your directions, but as the hand has now become a pointing device it can nolonger be used in all other capacities, you can nolonger 'gasp' as the pointing device is now a single-mode device, a pointer. Your hand, which you could use for myrid forms of manipulation (aquired from years of evolution, and use) has been subsituted for a prothesis. Some will say, well, look how much easier it is to use a pointing device, anybody can use it, it doesn't require years/millenia of training, practice, use ... plug & play.

This analogy (though admittedly stretched) is exactly the one used in all "ease of use", "usablitity", models, its so easy my 6 year old child could use it, etc, etc. But with this "use" comes, like the above pointing device, a 'single mode' clause, its nolonger a matter of actual use (skill aquisition, learning, etc) but a prosthesis for all possible use senarios. This is the 'fail' I was pointing to above, and I don't think OSX and Android have accomplished anything in this regard. The very idea of "layering" a pointing device on top of a device like the hand has already failed. This very idea has been central to computing since the '70's, and its mostly driven by the desire for market share than any kind of design principle, its the mantra for all kinds of dead end 'usability design', but of course in this model the user is a total abstraction.

VinzC wrote:

khayyam wrote:

[...] its very much like mixing water and oil, they will seperate out unless you agitate constantly.

I very much like this comparison. They've already started to separate judging from what we're talking about. And if we consider making much noise around this very topic, it would compare to agitation.

But everyone knows that oil and water don't mix (at least without an emusifier) ... my analogy was that the 'unix' and 'desktop' models are in stark contrast to each other, and that the attempt to mix them is only really an illusion born of someone adjitating the mixture enough to say "see, they do mix".

I'm going to watch this thread because I don't like that /usr, /var on different partitions needs initramfs.
also I don't like someone shoving his views into other's throat with no shred of consideration on how it will affect them.

I like current openrc and I intend to keep it although it seems that systemd is good for me as I use multiseat setup.
hope that I can enjoy both worlds in the end, if not, I'll be happy to give up on systemd.

great job! keep it up._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Last edited by DaggyStyle on Thu Aug 30, 2012 11:05 am; edited 1 time in total

Guys, I'm really glad this fork is appreciated and somebody is going to use it. You may direct your bugreports, feature requests, patches, and other related stuff to our bugtracker (https://bitbucket.org/braindamaged/udev/issues) or directly to me. Thanks for your support.

thank you guys for doing this. I hope this takes off like gangbusters. I am too time-constrained right now to do any "early adopter" stuff, but this is exactly what I'd been hoping someone would do, and hoping that distros will get behind to send a swift middle finger to upstream._________________Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash

grey_dot, is /run in the root directory integral to your fork as in upstream, or are you (ie all the devs) open to making the runtime directory location configurable either at build or run time (preferably both)?

grey_dot, is /run in the root directory integral to your fork as in upstream, or are you (ie all the devs) open to making the runtime directory location configurable either at build or run time (preferably both)?

Would making a feature request for such a change be worth while?

run directory location was configurable at run time before the merge with systemd. You may specify it with "udev_run" option in udev.conf. If nothing specified there, the path is set to '/run'. The same is for /dev and /sys. Other paths (e.g. configuration files) are configured at compile time.

haven't noticed any issues as yet ... the hdparm script from laptop-mode-tools (/usr/share/laptop-mode-tools/modules/hdparm) has a minor problem with the version returned by 'udevadm info -V', but other than that hunky-dorry.

So, outside of possible name change (which I think will need to be considered if this is to be a virtual stand-in for the currently named 'udev' package) it seems 'standalone' is a drop-in replacement.

haven't noticed any issues as yet ... the hdparm script from laptop-mode-tools (/usr/share/laptop-mode-tools/modules/hdparm) has a minor problem with the version returned by 'udevadm info -V', but other than that hunky-dorry.

So, outside of possible name change (which I think will need to be considered if this is to be a virtual stand-in for the currently named 'udev' package) it seems 'standalone' is a drop-in replacement.

best ... khay

There are still minor problems, but we'll handle those. For example, kmod is installed in /usr by default in gentoo, so either /usr should be mounted when udev starts, or you have to link udev statically against libkmod. Or rebuild kmod to be installed in /. Anyway, this is easily managable.

BTW, me and consus were having a talk regarding the versioning scheme, and we decided to switch to year-month release versioning. E.g. r1208, r1209, and so on.

BTW, me and consus were having a talk regarding the versioning scheme, and we decided to switch to year-month release versioning. E.g. r1208, r1209, and so on.

grey_dot ... but this will break things that expect 'udevadm info -V' to be consistant with udev-systemd, at least in terms of returning the same number of fields, etc. For example, laptop-mode-tools does the following:

Code:

UDEVVERSION=$(udevadm info -V | awk '{print $3}')

This string will be empty for 'udev-standalone' ... smilarly when it looks for the version integer ...