Re: [gentoo-dev] RFC: new global USE flag: jit
On Mon, 2012-05-14 at 14:05 -0400, Alexandre Rostovtsev wrote: > I propose adding the following global USE flag: > > jit - Enable just-in-time compilation for improved performance. May > prevent use of some PaX memory protection features in Gentoo Hardened. > > > Current local flags that could probably be unified: > > app-arch/libzpaq:jit - Enable just-in-time compilation for faster > compression (requires SSE2) > > dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp > bytecode to machine code, through the SLJIT compiler. This feature might > conflict wtih security mitigation strategies such as NX/PaX as enabled > by Gentoo Hardened. > > dev-python/pypy:jit - Enable the JIT compiler > > dev-scheme/racket:jit - Enable just-in-time compiler > > media-sound/csound:luajit - Use the lua just-in-time compiler > dev-lang/luajit instead of dev-lang/lua > > net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it > will cause performance penalty) > > www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the > JIT javascript compiler enabled > > www-client/luakit:luajit - Use the lua just-in-time compiler > dev-lang/luajit instead of dev-lang/lua, which should make luakit > faster. > > www-client/seamonkey:methodjit - Enable JIT for JavaScript using > MethodJIT for faster JS performance. Hardened users can disable this > USE-flag to use MPROTECT on grsecurity kernels. > > www-servers/nginx:pcre-jit - Enable JIT for pcre > > x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt > > x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt > > x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for > faster JavaScript execution > > -Alexandre. Update: since the response to the proposal was favorable, jit has now been added to use.desc. Two packages, webkit-gtk and epiphany, have switched to the global flag already; bugs (#416601, #416603, #416605, #416607, #416609, #416611) have been filed with maintainers of the other packages most likely to benefit from the new flag. -Alexandre.
[gentoo-dev] Lastrite: app-arch/hardlink++
# Samuli Suominen (19 May 2012) # Dead project wrt http://bugs.gentoo.org/416613 # Use app-arch/hardlink instead # Removal in 30 days app-arch/hardlink++
[gentoo-dev] unmasking of jabberd, and now feeling uncertain about it...
net-im/jabberd was masked for removal but I've fixed the bugs that it was masked for in fact, there should now be 0 bugs in bugzilla for it (or can anyone find some?) so i've unmasked it again was that right, wrong, what? i really don't know anything about the application itself does jabberd2 replace all of it's functionality? - Samuli
Re: [gentoo-dev] RFC: git-2.eclass & fetching from multiple repos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/05/12 01:40, Michał Górny wrote: > > > 1/ Mike suggested something like: > > EGIT_REPO_URI=( "repo1 fallback1" "repo2 fallback2" ) > > but IMO it hurts readability and makes the behavior a little surprising > (not that the fallback syntax isn't surprising already). Does not look that bad, do you have an actual example so we can see how bad could get? lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+39EIACgkQ6Ex4woTpDjQ7WgCdHXC8qOKxKGTkZg0UdlXr2BA0 VoEAoLmcUx/0TfsrtKf7eiOxrLQMcpBj =MUjk -END PGP SIGNATURE-
[gentoo-dev] Implementing udev without an initramfs (Was: Stability of /sys api)
Hey, William William Hubbs wrote: > Steven J Long wrote: >> Thing is it runs before the real init[1] so if we are using a separate >> /usr partition on LVM, will it still work? I'd have thought not, since we >> need the device-mapper service and there's /etc/lvm.conf to consider, but >> I'll gladly be told different. > > No, you are correct about this. This does not work if you have /usr on > lvm, mdadm, or encrypted. The same applies to /. That is the situation > where you would need an initramfs. > Let's not conflate the two: we never needed an initramfs before now*, unless / were on lvm or mdadm (not sure about dmcrypt, but always thought it pointless without encrypting root.) So the touted solution to Chainsaw's problem, as raised to Council, doesn't actually work for that use-case, and there is still no official support for both setups. -- * If anyone wants to chip in with something along the lines of "you did but you didn't know it" or "this isn't safe" etc, please don't: I've heard it all before, and acknowledged technical points, and you'll just be adding noise and distracting from the topic. The users we're talking about have already set this up manually, if that's your concern. -- > I'm curious, have you seen our initramfs guide yet [1]? Making and using > an initramfs seems to be pretty well documented these days. > No, that is useful information to have, though all the detail is in links I've seen before. Also useful are: NeddySeagoon's Rough Guide to udev-182+: http://forums.gentoo.org/viewtopic-t-920644.html udeved's port of Arch's mkinitcpio: http://forums.gentoo.org/viewtopic-t-923168.html ..which seems like a really nice tool to build an initramfs. But let's be frank: you're never going to persuade me, or many others[2], that merging udev and systemd, as well as / and /usr, and running an initramfs is the One True Way(TM). And the argument is boring, for all of us I'm sure, as the title of [2] should make clear. So, let's agree that no-one needs to fork udev at this stage. There /are/ methods that work flawlessly[3] with lvm and separate /usr with no initramfs, at least for now, should people care to explore them[4], and give feedback to improve them. What could spoil that and force a fork (or a switch to a patched mdev) instead of initscript-ordering? 1) Random linkage into /usr/lib It's simple enough to check linkage, and while it would be nice if there were a portage feature to check any binaries installed to /bin /sbin or /lib* and ewarn if they link outside /lib* (QA otherwise), we can happily implement a portage bashrc hook to do it for us. Since every package manager uses a staged build and install, it doesn't matter what the end-user's filesystem layout is; even if they've munged all binaries into /usr, the image won't use symlinks, but contain directories. I accept that this is something we're going to have to handle on our own, since initramfs-people aren't interested in the data, as their scripts already automate pulling in dependent libs. But atm this is a non-issue. Running this one-liner: for f in /bin/* /sbin/*; do ldd "$f"|grep -q /usr || continue; echo "** $f"; ldd "$f"; done ..shows only /sbin/umount.udisks, an optional desktop dep, linking to /usr here. Ultimately, we may need a tiny overlay for the few packages that are both A) required in early boot before localmount, in the opinion of someone who wants to submit an ebuild or patches to it, and: b) whose root-installed binaries link outside, or: c) it uses: econf --prefix=/usrand we'd like: econf --prefix=/ --exec-prefix=/usr and: D) where upstream is unresponsive, and: E) the ebuild maintainer doesn't want to accept a patch In most cases, we should be able to deal with (b) with portage hooks which move libs in "$D". I wouldn't like to do that automatically when a warning is flagged, though, as it should be specifically edited-in. 2) Hard dependency on systemd This is the killer, and would force a fork, or we'd have to start work on extensions to mdev. Outside our control, and pointless to speculate on, though given recent feedback, the old kernel.org udev repo[5] is a reference point for anyone who wants to check it out. I'd personally be wary of any changes to udev in systemd's repo[6] going forward, although it would only be an issue if and when unstable udev stopped working for openrc users. Regards, Steve. > [1] http://www.gentoo.org/doc/en/initramfs-guide.xml [2] http://forums.gentoo.org/viewtopic-t-921140.html [3] http://forums.gentoo.org/viewtopic-t-901206.html [4] http://forums.gentoo.org/viewtopic-t-918466.html [5] http://git.kernel.org/?p=linux/hotplug/udev.git;a=summary -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] RFC: git-2.eclass & fetching from multiple repos
On Sat, 19 May 2012 12:28:02 -0700 Luca Barbato wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 17/05/12 01:40, Michał Górny wrote: > > > > > > 1/ Mike suggested something like: > > > > EGIT_REPO_URI=( "repo1 fallback1" "repo2 fallback2" ) > > > > but IMO it hurts readability and makes the behavior a little > > surprising (not that the fallback syntax isn't surprising already). > > Does not look that bad, do you have an actual example so we can see > how bad could get? Well, for example if the project was hosted on github, it would look like: EGIT_REPO_URI=( "git://github.com/foo/foo.git http://github.com/foo/foo.git"; "git://github.com/foo/bar.git http://github.com/foo/bar.git"; ) Or something like that. What I am afraid of is that we use nested list with tricky syntax, and one could miss the specifics of "" use. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Implementing udev without an initramfs (Was: Stability of /sys api)
On 05/19/2012 10:36 PM, Steven J Long wrote: 1) Random linkage into /usr/lib ..shows only /sbin/umount.udisks, an optional desktop dep, linking to /usr here. I know you propably meant this as an example, but I've fixed it months ago by moving it to /usr: http://bugs.gentoo.org/398081 Then vapier kindly fixed util-linux's umount to look for umount.* wrappers also from /usr: http://bugs.gentoo.org/403073 I'm only waiting for new util-linux to stabilize, to stabilize new udisks, to get it out of / (And rest of your post was boring repeat of the old. If you don't have anything new and constructive to add, I recommend staying quiet or at least moving this to some other ML, like gentoo-user.) - Samuli
Re: [gentoo-dev] Implementing udev without an initramfs (Was: Stability of /sys api)
On Sat, 19 May 2012 20:36:57 +0100 Steven J Long wrote: > * If anyone wants to chip in with something along the lines of "you > did but you didn't know it" or "this isn't safe" etc, please don't: > I've heard it all before, and acknowledged technical points, and > you'll just be adding noise and distracting from the topic. * If anyone wants to chip in with something along the lines 'I never needed an initramfs and nothing can change', please don't: we've heard that a thousand times, and it gets boring. In fact, if you just set up an initramfs instead of writing that post, you'd probably save some time. Our time, especially. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: git-2.eclass & fetching from multiple repos
On 19/05/12 13:18, Michał Górny wrote: > EGIT_REPO_URI=( > "git://github.com/foo/foo.git > http://github.com/foo/foo.git"; > > "git://github.com/foo/bar.git > http://github.com/foo/bar.git"; > ) > > Or something like that. What I am afraid of is that we use nested list > with tricky syntax, and one could miss the specifics of "" use. it doesn't look that bad, the result would be getting foo and bar in workdir I guess. for github, sourceforge, bitbucket, gnome, etc, we might use something like gitmirror://github/foo/bar lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] unmasking of jabberd, and now feeling uncertain about it...
On 2012-05-19 Sat 08:03, Samuli Suominen wrote: > net-im/jabberd was masked for removal but I've fixed the bugs that it > was masked for > in fact, there should now be 0 bugs in bugzilla for it (or can anyone > find some?) > so i've unmasked it again > was that right, wrong, what? i really don't know anything about the > application itself > does jabberd2 replace all of it's functionality? I don't know how many people are using jabberd rather than jabberd2 (or other options such as ejabberd) nowadays since jabberd2 is well maintained and is generally a suitable replacement for jabberd, Also, jabberd hasn't had much development in years from what I've seen. Unfortunately, no one has bumped jabberd2 in the tree for a while so there are a few bugs open for it. Tim pgp6jL6vtESwL.pgp Description: PGP signature
