From ciaran.mccreesh at googlemail.com Wed Feb 1 15:10:43 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Wed, 1 Feb 2012 15:10:43 +0000 Subject: [Exherbo-dev] Paludis 0.72.0 Released Message-ID: <20120201151043.2ea87cd7@googlemail.com> Paludis 0.72.0 has been released: * Changed documentation and Git URLs from paludis.pioto.org to paludis.exherbo.org. * Gentoo's new boost.python library names are now recognised. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philantrop at exherbo.org Mon Feb 6 19:50:18 2012 From: philantrop at exherbo.org (Wulf C. Krueger) Date: Mon, 06 Feb 2012 20:50:18 +0100 Subject: [Exherbo-dev] dev-lang/python:2.7 unmasked Message-ID: <4F302EFA.4070704@exherbo.org> I've just unmasked dev-lang/python:2.7. As with all Python updates, packages which depend on Python will need to be rebuilt. Until we have a better method for updating these packages, I recommend you just go ahead rebuild all packages which depend on Python: 1. Update to python:2.7: cave resolve python:2.7 2. Switch to python:2.7: eclectic python2 set 2.7 3. Re-install everything depending on Python: cave resolve --reinstall-dependents-of dev-lang/python nothing -- Best regards, Wulf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From woutershep at gmail.com Thu Feb 9 15:06:56 2012 From: woutershep at gmail.com (Wouter van Kesteren) Date: Thu, 9 Feb 2012 16:06:56 +0100 Subject: [Exherbo-dev] Merging XULRunner and Firefox Message-ID: I would like to merge xulrunner and firefox into one. REASONS TO MERGE: 1. Mozilla seems to actively discourage separating xulrunner. The documentation says it's a bad idea because upgrades to xulrunner might break stuff and the install documentation says you need to copy xulrunner to the ./xulrunner/ directory[0]. With the rapid release cycle this has become a bigger issue. Even in firefox itself it is not fully supported. After firefox's `make install` symlinks and wrappers are required to actually make it work. Not to mention g++:4.6 causing segfaults when xulrunner is separated. 2. Firefox is very tightly coupled to xulrunner. So tight that only a specific version of xulrunner is usable by firefox at any one time. So if we where to say hold xulrunner 10 back because it was incompatible with vlc we would also be missing out on firefox 10 automatically. The same is true for the opposite, if we want xulrunner 10 for security fixes we can no longer use firefox 9. 3. Another problem is the way its distributed. The configure is the same for both xulrunner and firefox. This means that even though firefox doesn't require something, the configure still checks for it and thus we have to depend on it for it to build. This means firefox currently has the majority of xulrunner dependencies and configure switches. And all patches to the configure (libvpx-1.0.0 support for example) will have to be doubled. Effectively doubling all maintenance work. [0] https://developer.mozilla.org/en/XULRunner/Deploying_XULRunner_1.8#Linux PACKAGES THAT NEED TO CHANGE FOR A MERGE: Packages that depend on xulrunner can fit into the following three categories. -- Packages that need it for a javascript library: * net-libs/libproxy webkit? ( net-libs/webkit:3.0 ) xulrunner? ( dev-libs/xulrunner[>=2.0] ) * gnome-bindings/gjs spidermonkey? ( dev-libs/spidermonkey ) !spidermonkey? ( dev-libs/xulrunner:=[>=7.0] ) libproxy's scm has a commit[1] that says: > Only support mozjs185 as valid mozilla pacrunner backend. Xulrunner is no > longer trackable from upstream due to the lightning fast movement of the > Firefox source base. Also, Mozilla does not support usage of xulrunner from > other apps. The libproxy exheres should apply the patch and depend on spidermonkey instead of xulrunner. gjs has done the same[2] which makes it hard-depend on mozjs185 and no longer on the xulrunner/firefox versions. The gjs exheres just needs to hard-enable the spidermonkey part and drop xulrunner support. (The masked gjs-1.31.10 already does this) [1] https://code.google.com/p/libproxy/source/detail?r=815 [2] http://git.gnome.org/browse/gjs/commit/?id=aeb75aa3d869195e3d8e77f2facd258cd575ba1d -- Packages that need it to build a plugin: * dev-lang/gcj-jdk nsplugin? ( dev-libs/xulrunner ) * dev-lang/icedtea-web nsplugin? ( dev-libs/xulrunner[~8.0] ) * media/vlc mozilla-plugin? ( dev-libs/xulrunner[>=1.9.1] ) These packages could in theory simply be changed to depend on net-www/firefox. Building firefox in addition to xulrunner would only add like 5 minutes on a compile time of 1+ hours so the overhead is negligible. HOWEVER icedtea-web and vlc also support npapi-sdk.pc[3][4][5] (currently two versions, one from gentoo and one from openSUSE) which is a lightweight replacement for building plugins. This would make it easyer for say chromium users to build nsplugins without pulling in xulrunner. gcc does not support npapi-sdk but does support firefox-plugin[6] [3] http://icedtea.classpath.org/hg/release/icedtea-web-1.1/file/360bd0a75304/acinclude.m4#l375 [4] http://git.videolan.org/?p=npapi-vlc.git;a=blob;f=configure.ac#l177 [5] https://code.google.com/p/npapi-sdk/issues/detail?id=7 [6] http://gcc.gnu.org/viewcvs/trunk/libjava/classpath/configure.ac?view=markup#l764 -- Packages that require a XUL-runtime: * net-www/firefox If upstreams followed the mozilla install guide it will be bundled with a copy of xulrunner for which the app is written. Currently there are no exheres that depend on xulrunner for a XUL runtime other than firefox so this category isn't that important at the moment to begin with. -- STEPS TO REALIZE THE MERGE: 1. switch libproxy/gjs over to spidermonkey 2a. merge xulrunner into firefox 2b. make gcj-jdk, icedtea-web and vlc depend on firefox 3. package npapi-sdk 4. make vlc and icedtea-web depend on npapi-sdk Maybe with step 2a there should also be a news item for people who have xulrunner installed so that they are aware that they need to move the options to the firefox package. But I'm not really familiar with news items. Some advice on this option would be welcome. So are there any objections or additions to all of this? Things i missed? -Wouter van Kesteren From philantrop at exherbo.org Sat Feb 11 23:59:45 2012 From: philantrop at exherbo.org (Wulf C. Krueger) Date: Sun, 12 Feb 2012 00:59:45 +0100 Subject: [Exherbo-dev] split kde 4.7 was unmasked. it's a mess. work it out. (Or read on) Message-ID: <4F3700F1.9010905@exherbo.org> (I'd like to mention first that zlin wanted this to say "split kde 4.7 was unmasked. it's a mess. work it out." So be happy you're getting a bit more! ;-) ) KDE 4.7 was unmasked and it's (partly) split and somewhat messy: kdebase-runtime -> kde-runtime kdebase-workspace -> kde-workspace kdebase -> kde-baseapps, kate and konsole There are sets for the split packages and "cave show kde-split\*" will give a complete list of packages to pick from. I did this (if you don't have the same packages installed, leave those out, of course): cave resolve -z \ kde/kdepim \ kde/kdepim-runtime \ kde/kdeplasma-addons \ kde/kdesdk \ kde/kdetoys \ kde/kdeutils \ kde/konq-plugins \ kde/ktorrent \ kde/kate \ kde/konsole \ virtual/notification-daemon \ kde/kdenetwork \ kde/kdemultimedia \ kde/kdeartwork \ graphics/kipi-plugins \ kde/kde-runtime \ kde/kde-workspace \ kde/kde-baseapps \ kde/libkexiv2 \ kde/marble \ \!kde/kdebase \ \!kde/kdebase-workspace \ \!kde/kdebase-runtime \ \!kde/kdegraphics \ \!kde/kdeedu I wrote down the packages that still triggered errors, e. g. for ! kde/kdebase Reasons: !kde/kdebase from kde/kde-baseapps: "kde/kde-baseapps was part of kde/kdebase in previous releases", target, kde/konq-plugins -> kde/konq-plugins and excluded them: --without kde/konq-plugins Of course, that made things break, e. g. X graphics/digikam 1.9.0:0::installed Will be broken by uninstalls: Reasons: dependent upon kde/kdegraphics-4.6.5:4::installed (build, run) Cannot proceed without: --uninstalls-may-break or --remove-if-dependent So, nothing critical, thus, I threw in --uninstalls-may-break for good measure. Last I updated world (cave resolve world -c) to pull the --without'ed stuff back in (it's in world after all) and checked it really worked. :-) This is probably all very horrible and I'll get stabbed but, hey, it worked for me and might work for you. -- Best regards, Wulf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From eternaleye at gmail.com Sat Feb 18 05:11:06 2012 From: eternaleye at gmail.com (Alex Elsayed) Date: Sat, 18 Feb 2012 05:11:06 +0000 (UTC) Subject: [Exherbo-dev] =?utf-8?q?=5BRFC=5D_A_new_approach_to_CONFIG=5FPROT?= =?utf-8?q?ECT?= Message-ID: Could I get people's opinions on how sensible this is? The current layout of a directory under CONFIG_PROTECT is somewhat less than ideal. An update to a protected directory results in ._cfg0000_.* files strewn throughout, with no information as to their origin. Also, this layout does not interact well with configuration management tools such as etckeeper. Here I will propose an alternate method for achieving the goals of CONFIG_PROTECT. First, a different layout could bring many benefits both in terms of functionality and performance. In all examples, we will be treating /etc as the directory under CONFIG_PROTECT. For a new layout, we should avoid splattering dotfiles all over the directory tree. It would also be beneficial to record the package that tried to merge the file, as well as a timestamp. Conveniently, exndbam already stores a timestamp. This is how I imagine the new layout might look: /etc/ .config-protect/ new/ old/ resolved/ When the package manager comes across a file with a destination that is under CONFIG_PROTECT, it should create a directory of the form ${TIMESTAMP}---${CATEGORY}---${PN}:${SLOT}:${PVR} under 'new'. It will then merge the file that has a CONFIG_PROTECT destination to the newly-created directory as if it were the destination. Note that the package manager will *never* merge directly to a CONFIG_PROTECT directory, even if there is no preexisting file. When the user next runs 'eclectic config', it will scan /etc/.config-protect/new/ to see what action needs to be taken. This should be a considerable performance improvement over the old system - while still O(n), now n is 'the files that need updates' rather than 'all files in /etc.' I see no need to change the user interface of 'eclectic config' at all. It will behave exactly like before from the user's perspective. However, in order to support configuration management properly, we cannot have the user altering the original files in the course of managing these updates. Therefore, when the user would perform an action that could modify the original file, the original file is instead copied to the 'old' directory and the action is performed on the copy. To give an example, if we have a config file /etc/foo/bar.conf which has an update pending in /etc/.config-protect/new/00000.00---foo---bar:0:0/foo/bar.conf, and the user chooses to merge them, the original will be copied to /etc/.config-protect/old/00000.00---foo---bar:0:0/foo/bar.conf and the merge tool will be called on that copy. As a resolution is decided upon, the final resolution is placed at /etc/.config-protect/resolved/00000.00---foo---bar:0:0/foo/bar.conf If there are multiple pending updates for a single file, then the updates are applied serially in chronological order. The copying of the old version uses the 'resolved' entry from the previous update to that file. After all updates have been addressed (which can be checked for by testing whether for every file in 'new' there is a corresponding file in 'resolved') eclectic config iterates over /etc/.config-protect/resolved/ in order of timestamp from oldest to newest. For each, it overwrites the original with the resolved version. At this point, if etckeeper or some other configuration management system supported by eclectic is enabled (support is provided via plugins), the files changed by that specific update are treated to the equivalent of git add /etc/foo/baz.conf git commit The default message would be something like Conf update for ${CATEGORY}/${PNVR} from `date --rfc-3339=ns -d "@${TIMESTAMP}"` but would be open to editing. It should be noted that /etc/.config-protect/ would be in the equivalent of .gitignore for whatever system is being used. From eternaleye at gmail.com Sat Feb 18 05:28:07 2012 From: eternaleye at gmail.com (Alex Elsayed) Date: Sat, 18 Feb 2012 05:28:07 +0000 (UTC) Subject: [Exherbo-dev] =?utf-8?q?=5BRFC=5D_A_new_approach_to_CONFIG=5FPROT?= =?utf-8?q?ECT?= References: Message-ID: Forgot to mention that immediately after the changes for a package are committed, the new, old, and resolved entries for that package are deleted. From wk at mailstation.de Sat Feb 18 20:40:59 2012 From: wk at mailstation.de (Wulf C. Krueger) Date: Sat, 18 Feb 2012 21:40:59 +0100 Subject: [Exherbo-dev] HEADS UP: Version bump to systemd-43 / Move to /usr Message-ID: <4F400CDB.9010100@mailstation.de> (This is the same as the news item but I want this to get maximum exposure.) Read ALL of this, it's important to *everyone* using systemd. Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr. systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr. This won't matter much to you if you don't have /usr split from / (it should *not* be split; cf. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken ). Even if you don't have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I've rev-bumped all packages, that install their own custom systemd units but even after you've updated those, you'll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them. Should you forget to do so, you might end up in systemd's emergency mode. If that happens, don't panic. Get your network connection up and continue updating/re-installing. You'll live, I promise. There might be orphaned systemd units left behind. Check those on your own and decide if you need to move them to /etc/systemd/system. If you do, don't forget to systemctl disable and then enable them. You'll also have some broken symlinks in /etc/systemd/system pointing to /${LIBDIR}/systemd/system. To fix those, all you have to do is disable and re-enable the respective unit. Here's how to do it quickly and easily: for link in $(find -L /etc/systemd/system -type l); do systemctl disable $(basename ${link}); systemctl enable $(basename ${link}); done Final sanity checks: 1. Is /${LIBDIR/systemd gone? If so, carry on; if not, you missed a step. Go back and find out which one. 2. No broken symlinks in /etc/systemd/system anymore? ("find -L /etc/systemd/system -type l" doesn't output anything) If so, carry on. Otherwise, you missed a step. Go back and find out which one. If you do *NOT* have /usr separated from /, you're done now and it should be safe to reboot if you so desire. If you *do* have /usr separated from /, you'll *have* to use an initramfs (preferrably created by dracut) for booting from systemd[=43] onwards. The first step to using an initramfs is enabling CONFIG_BLK_DEV_INITRD in your kernel, recompiling and installing it. If you want to switch from a custom initramfs to dracut, don't forget to empty CONFIG_INITRAMFS_SOURCE in your kernel configuration either if you have been using it before. If you want to use dracut (sys-boot/dracut[>=14]), install it and add add_dracutmodules+="98usrmount" to /etc/dracut.conf. If you have some weird configuration, you might need to add further dracut or kernel modules. In general, though, dracut is going to pick up everything you'll need to boot. Now run dracut to create your shiny new initramfs: dracut -H e. g. dracut -H /boot/init-3.2.5.gz 3.2.5-00001-gf74dd96 -H (or --hostonly) tells dracut to build an initramfs for the machine it's running on. Leaving it out *should* create a *HUGE* generic init- ramfs that should bascially be able to boot *everything*. In reality, leaving -H out usually builds something that doesn't boot *anything*. Next, update grub's config so that it includes a root= parameter for the kernel command line and your new initramfs, e. g.: (for grub-0.9x's menu.lst) title Exherbo Linux root (hd0,1) kernel /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv initrd /init-3.2.5.gz or (for grub-1.9x's grub.cfg) menuentry "Exherbo Linux" { set root=(hd0,1) linux /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv initrd /init-3.2.5.gz } Do *NOT* forget the root= parameter. It's essential. (Of course, you need to adjust paths and filenames to your setup but if I need to tell you that, you shouldn't be using Exherbo in the first place.) If you're using a custom initramfs, you must make sure that you mount /usr as early as possible but definitely before systemd (/sbin/init) starts. If you're rolling your own initramfs, you should know how to accomplish that. After you've updated your grub configuration, systemd is updated and your kernel is ready, too, say a little prayer ;-) and reboot. Best regards, Wulf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From ciaran.mccreesh at googlemail.com Sat Feb 18 21:00:11 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Sat, 18 Feb 2012 21:00:11 +0000 Subject: [Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT In-Reply-To: References: Message-ID: <20120218210011.55603da7@googlemail.com> On Sat, 18 Feb 2012 05:11:06 +0000 (UTC) Alex Elsayed wrote: > The current layout of a directory under CONFIG_PROTECT is somewhat > less than ideal. An update to a protected directory results in > ._cfg0000_.* files strewn throughout, with no information as to their > origin. Well... Their origin should just be "cave owner" on the unprotected file, shouldn't it? > This is how I imagine the new layout might look: > > /etc/ > .config-protect/ > new/ > old/ > resolved/ I'm slightly confused by your directory layout here. Let's say that /var/foo is also protected. Would that live in /var/foo/.c-p or /etc/.c-p/var/foo? I'm in favour of the latter, incidentally. It's an utter pain in the ass having to know that one package added /lib/blah to C_P, since we have to scan through exndbam for every package to see where C_P things might live. > Note that the package manager will *never* merge directly to a > CONFIG_PROTECT directory, even if there is no preexisting file. That's unworkable. Say foo deps upon bar, and bar needs /etc stuff present to work. You'd not be able to install foo and bar as part of the same resolution then. > When the user next runs 'eclectic config', it will scan > /etc/.config-protect/new/ to see what action needs to be taken. This > should be a considerable performance improvement over the old system - > while still O(n), now n is 'the files that need updates' rather than > 'all files in /etc.' Don't think performance is an issue. Let's focus on functionality first. > However, in order to support configuration management properly, we > cannot have the user altering the original files in the course of > managing these updates. Therefore, when the user would perform an > action that could modify the original file, the original file is > instead copied to the 'old' directory and the action is performed on > the copy. That sounds like it's getting in the way of the user. Supporting complex things is good, but we shouldn't force it upon people who don't want to screw around with configuration management. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ciaran.mccreesh at googlemail.com Sat Feb 18 21:01:19 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Sat, 18 Feb 2012 21:01:19 +0000 Subject: [Exherbo-dev] HEADS UP: Version bump to systemd-43 / Move to /usr In-Reply-To: <4F400CDB.9010100@mailstation.de> References: <4F400CDB.9010100@mailstation.de> Message-ID: <20120218210119.69791dbe@googlemail.com> On Sat, 18 Feb 2012 21:40:59 +0100 "Wulf C. Krueger" wrote: > This won't matter much to you if you don't have /usr split from / (it > should *not* be split; > cf. > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken ). I'm a little unhappy with us pushing propaganda like that. It's one thing to say that "we've decided that it's too difficult to get split /usr to work", which might be the case if enough upstreams are forcing us to go that way, but it's quite another to claim that split /usr is wrong. We might have to accept what they've done, but we don't have to like it, and we certainly don't have to advocate it or encourage them to carry on unilaterally doing that kind of thing. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eternaleye at gmail.com Sun Feb 19 20:31:50 2012 From: eternaleye at gmail.com (Alex Elsayed) Date: Sun, 19 Feb 2012 20:31:50 +0000 (UTC) Subject: [Exherbo-dev] =?utf-8?q?=5BRFC=5D_A_new_approach_to_CONFIG=5FPROT?= =?utf-8?q?ECT?= References: <20120218210011.55603da7@googlemail.com> Message-ID: Ciaran McCreesh writes: > On Sat, 18 Feb 2012 05:11:06 +0000 (UTC) > Alex Elsayed wrote: > > > This is how I imagine the new layout might look: > > I'm slightly confused by your directory layout here. Let's say > that /var/foo is also protected. Would that live in /var/foo/.c-p > or /etc/.c-p/var/foo? /var/foo/.c-p > > Note that the package manager will *never* merge directly to a > > CONFIG_PROTECT directory, even if there is no preexisting file. > > That's unworkable. Say foo deps upon bar, and bar needs /etc stuff > present to work. You'd not be able to install foo and bar as part of > the same resolution then. Mm, perhaps a tweak that it merges to both /etc/.c-p *and* the actual destination in that case? That way it still interoperates properly with configuration management. > Don't think performance is an issue. Let's focus on functionality first. It was more something I realized after I had the idea. Also, on my laptop using eclectic config has about a 10-15 second startup lag from scanning /etc and the rest. For the non-interactive stuff, that adds up fast. > > However, in order to support configuration management properly, we > > cannot have the user altering the original files in the course of > > managing these updates. Therefore, when the user would perform an > > action that could modify the original file, the original file is > > instead copied to the 'old' directory and the action is performed on > > the copy. > > That sounds like it's getting in the way of the user. Supporting > complex things is good, but we shouldn't force it upon people who don't > want to screw around with configuration management. Maybe an option then? The current method of running the action on all updates involved in the conflict at once would lose information in the case of the user wanting configuration management, but I see your point. Perhaps eclectic could call into the configuration management plugins to ask whether they are active, and only change its behavior if one answers "yes"? From ciaran.mccreesh at googlemail.com Sun Feb 19 21:01:14 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Sun, 19 Feb 2012 21:01:14 +0000 Subject: [Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT In-Reply-To: References: <20120218210011.55603da7@googlemail.com> Message-ID: <20120219210114.6dfee781@googlemail.com> On Sun, 19 Feb 2012 20:31:50 +0000 (UTC) Alex Elsayed wrote: > > I'm slightly confused by your directory layout here. Let's say > > that /var/foo is also protected. Would that live in /var/foo/.c-p > > or /etc/.c-p/var/foo? > > /var/foo/.c-p Wrong answer! > > > However, in order to support configuration management properly, we > > > cannot have the user altering the original files in the course of > > > managing these updates. Therefore, when the user would perform an > > > action that could modify the original file, the original file is > > > instead copied to the 'old' directory and the action is performed > > > on the copy. > > > > That sounds like it's getting in the way of the user. Supporting > > complex things is good, but we shouldn't force it upon people who > > don't want to screw around with configuration management. > > Maybe an option then? The current method of running the action on all > updates involved in the conflict at once would lose information in the > case of the user wanting configuration management, but I see your > point. Perhaps eclectic could call into the configuration management > plugins to ask whether they are active, and only change its behavior > if one answers "yes"? I think we need to be careful here. Replacing some of the silliness we inherited with config-protect is a good idea. What we don't want to do is tie config-protect into any particular user policy, particularly if that system is complicated and involves configuration management. The default should be something simple; being able to support fancy stuff on top of that is something a good design should allow, not something it should enforce. Perhaps a better question to ask is something like "how would we design config protection if it didn't already exist?". From the package mangler side there's probably not much difference here between having a choice of two mechanisms, or having one mechanism that's heavily parameterised. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From djc at djc.id.au Sun Feb 19 21:55:54 2012 From: djc at djc.id.au (Dan Callaghan) Date: Mon, 20 Feb 2012 07:55:54 +1000 Subject: [Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT In-Reply-To: <20120219210114.6dfee781@googlemail.com> References: <20120218210011.55603da7@googlemail.com> <20120219210114.6dfee781@googlemail.com> Message-ID: <1329686948-sup-664@sage.djc.id.au> Excerpts from Ciaran McCreesh's message of Mon Feb 20 07:01:14 +1000 2012: > Perhaps a better question to ask is something like "how would we > design config protection if it didn't already exist?". From the > package mangler side there's probably not much difference here between > having a choice of two mechanisms, or having one mechanism that's > heavily parameterised. I had an idea a while back for replacing CONFIG_PROTECT. (I was inspired by etckeeper, and the mess that CONFIG_PROTECT makes of it.) Instead of merging a package's files under /etc to the filesystem, you commit them to their own branch of a git repo (so one branch per package, which gets updated when the package is updated). Your master branch is made up by merging in all of these "pristine" package branches, and the real /etc is a checkout of that. A whole bunch of useful operations then become easy with git. You can see what changed in an upgrade using git log. You can make git do all (or most) of the hard work when merging in upgraded config files. `eclectic config list` just becomes an operation on the git repo to find all pristine package branches which are not fully merged into master. I hacked up a Paludis merger hook to do this, which mostly worked -- the biggest problem I ran into was CONFIG_PROTECT_MASK. It seems there's a lot of packages which don't work if they can't overwrite certain config files during their upgrade. /etc/env.d seemed to be the main culprit. (I would argue that the env.d stuff belongs outside of /etc since it's apparently not real configuration. Maybe with just an option to override it in /etc, the way systemd lets you do?) There's also a lot of packages which just don't work if their config files are completely absent. The way around this would probably be to have the package manager try to merge the pristine package branch into master after an upgrade. It would abort if the merge isn't clean, but presumably the first merge for a new package would always go through cleanly. It would also be tied to git, which some might say is a downside (I don't). -- Dan Callaghan From ciaran.mccreesh at googlemail.com Sun Feb 19 22:50:25 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Sun, 19 Feb 2012 22:50:25 +0000 Subject: [Exherbo-dev] [RFC] A new approach to CONFIG_PROTECT In-Reply-To: <1329686948-sup-664@sage.djc.id.au> References: <20120218210011.55603da7@googlemail.com> <20120219210114.6dfee781@googlemail.com> <1329686948-sup-664@sage.djc.id.au> Message-ID: <20120219225025.3c9410c0@googlemail.com> On Mon, 20 Feb 2012 07:55:54 +1000 Dan Callaghan wrote: > It would also be tied to git, which some might say is a downside (I > don't). You need to be careful with things like that. Right now, the list of things that have the property that if they break then Paludis breaks is fairly short (and can be made even shorter if your GCC is new enough to do static-libstdc++ properly). Being able to use git is all well and good, but not being able to fix your system if you don't have git is going to hurt. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eternaleye at gmail.com Mon Feb 20 02:46:10 2012 From: eternaleye at gmail.com (Alex Elsayed) Date: Mon, 20 Feb 2012 02:46:10 +0000 (UTC) Subject: [Exherbo-dev] =?utf-8?q?=5BRFC=5D_A_new_approach_to_CONFIG=5FPROT?= =?utf-8?q?ECT?= References: <20120218210011.55603da7@googlemail.com> <20120219210114.6dfee781@googlemail.com> Message-ID: Ciaran McCreesh writes: > > On Sun, 19 Feb 2012 20:31:50 +0000 (UTC) > Alex Elsayed wrote: > > > I'm slightly confused by your directory layout here. Let's say > > > that /var/foo is also protected. Would that live in /var/foo/.c-p > > > or /etc/.c-p/var/foo? > > > > /var/foo/.c-p > > Wrong answer! Well, I'm not wedded to that statement. If you think it would be better to have *all* stuff that is config_protect share that same directory, I'm perfectly fine with that. > I think we need to be careful here. Replacing some of the silliness we > inherited with config-protect is a good idea. What we don't want to do > is tie config-protect into any particular user policy, particularly if > that system is complicated and involves configuration management. The > default should be something simple; being able to support fancy stuff > on top of that is something a good design should allow, not something > it should enforce. > > Perhaps a better question to ask is something like "how would we design > config protection if it didn't already exist?". From the package > mangler side there's probably not much difference here between having a > choice of two mechanisms, or having one mechanism that's heavily > parameterised. If it didn't exist, I *would* impose that chronological serialization unequivocally. I think it just makes more sense to deal with any updates that come from updating a package to version 2 on Wednesday before dealing with an update to version 3 on Friday. From philantrop at exherbo.org Sat Feb 25 21:57:56 2012 From: philantrop at exherbo.org (Wulf C. Krueger) Date: Sat, 25 Feb 2012 22:57:56 +0100 Subject: [Exherbo-dev] Google Summer of Code 2012: Ideas Message-ID: <4F495964.5010004@exherbo.org> The same procedure as every year... We, Exherbo, are going to apply for Google's Summer of Code again. This year, I have the honour to be our GSoC administrator so... If you have some great project ideas for Google's Summer of Code, *now* would be a good time to present them here. We have a list of ideas at http://exherbo.org/docs/project-ideas.html to which I'm going to add all your excellent ideas if they can be agreed upon here. I've already updated the projects page with some information requested by Google last year, btw. Best regards, Wulf -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Attached Message Part URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From masterkorp at masterkorp.net Sun Feb 26 00:08:13 2012 From: masterkorp at masterkorp.net (Alfredo Palhares) Date: Sun, 26 Feb 2012 01:08:13 +0100 Subject: [Exherbo-dev] Google Summer of Code 2012: Ideas In-Reply-To: <4F495964.5010004@exherbo.org> References: <4F495964.5010004@exherbo.org> Message-ID: <1330214820-sup-6683@masterkorp.net> Hello, > We have a list of ideas at http://exherbo.org/docs/project-ideas.html to That rubygems integrations is something i am really interested in! I really may submit myself to that. From ciaran.mccreesh at googlemail.com Sun Feb 26 13:02:57 2012 From: ciaran.mccreesh at googlemail.com (Ciaran McCreesh) Date: Sun, 26 Feb 2012 13:02:57 +0000 Subject: [Exherbo-dev] Paludis 0.72.1 Released Message-ID: <20120226130257.6fd824c8@googlemail.com> Paludis 0.72.1 has been released: * Hardlinks are now handled cleanly by pbins. * Ruby 1.9 is now supported. * Minor bug fixes. -- Ciaran McCreesh -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eternaleye at gmail.com Mon Feb 27 01:48:55 2012 From: eternaleye at gmail.com (Alex Elsayed) Date: Mon, 27 Feb 2012 01:48:55 +0000 (UTC) Subject: [Exherbo-dev] =?utf-8?q?=5BRFC=5D_A_new_approach_to_CONFIG=5FPROT?= =?utf-8?q?ECT?= References: <20120218210011.55603da7@googlemail.com> <20120219210114.6dfee781@googlemail.com> Message-ID: Having had some time to think, I have a few refinements to my proposal. Firstly, a small change to the directory structure I proposed. All config-protect goes ubnder one directory, /etc/.config-protect. Within that are the following directories: new/ old/ resolved/ protected/ historic/ new, old, and resolved are as in my previous proposal. However, 'protected' and 'historic' are new. 'protected' exists to act as a registry of what is currently config-protected. If /etc and /var/cfg are protected, but /etc/.config-protect is config-protect-masked, then it will contain: etc.protect etc/.config-protect.mask var/ cfg.protect A .protect or .mask entry will contain a newline separated list of (timestamp, packageid) tuples with the two elements separated by a space, corresponding to the packages that added those paths to config-protect or config-protect-mask. 'historic' exists to provide for three-way-merges. When in the previous version of my proposal the 'new' entry would be deleted when the changes are committed, now that entry is moved to 'historic'. On creating a resolution, a three-way merge can be done between the user's file (the one in the config-protected path), the previous upstream (historic) and the new one. Also, since Ciaran pointed out that never merging directly even if there is no previous file is unworkable, I'd like to suggest that the package manager merges to /etc/.config-protect/new and creates a symlink to *that* file in the protected directory in such a case, so that it is trivial for eclectic config to detect such files and automerge them. Thoughts? From ahf at 0x90.dk Mon Feb 27 14:30:29 2012 From: ahf at 0x90.dk (=?ISO-8859-1?Q?Alexander_F=E6r=F8y?=) Date: Mon, 27 Feb 2012 15:30:29 +0100 Subject: [Exherbo-dev] Hetzner server will shutdown around April 12th Message-ID: Hey, It looks like Hetzner is going to move our server which hosted our old virtualized setup around the 12th of April, so please move all your stuff away from those machines, since I am going to request them to shutdown the physical machine at that time and I am not going to do full backup of our VM's. Cheers, Alex. -- Alexander F?r?y From v.tolstov at selfip.ru Tue Feb 28 06:09:06 2012 From: v.tolstov at selfip.ru (Vasiliy Tolstov) Date: Tue, 28 Feb 2012 10:09:06 +0400 Subject: [Exherbo-dev] creating pbins for all packages in the system to easy uprade low speed server Message-ID: Hello. I have some low speed servers running exherbo and want to compile all packages via pbins on build server. How can i avoid accounts packages? cave resolve --make binaries -x1 system for example, tries to install accounts packages.... Or i need to use cave show with specific conditions? -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov at selfip.ru jabber: vase at selfip.ru From ivan.miljenovic at gmail.com Tue Feb 28 06:52:17 2012 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 28 Feb 2012 17:52:17 +1100 Subject: [Exherbo-dev] creating pbins for all packages in the system to easy uprade low speed server In-Reply-To: References: Message-ID: On 28 February 2012 17:09, Vasiliy Tolstov wrote: > Hello. I have some low speed servers running exherbo and want to > compile all packages via pbins on build server. > How can i avoid accounts packages? cave resolve --make binaries -x1 > system for example, tries to install accounts packages.... > Or i need to use cave show with specific conditions? Isn't that just the package that records which accounts are automatically created by cave? As such, IIUC there's no real "building" required and it should be OK to do on your low-speed servers. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From v.tolstov at selfip.ru Tue Feb 28 14:40:57 2012 From: v.tolstov at selfip.ru (Vasiliy Tolstov) Date: Tue, 28 Feb 2012 18:40:57 +0400 Subject: [Exherbo-dev] creating pbins for all packages in the system to easy uprade low speed server In-Reply-To: References: Message-ID: 2012/2/28 Ivan Lazar Miljenovic : > On 28 February 2012 17:09, Vasiliy Tolstov wrote: >> Hello. I have some low speed servers running exherbo and want to >> compile all packages via pbins on build server. >> How can i avoid accounts packages? cave resolve --make binaries -x1 >> system for example, tries to install accounts packages.... >> Or i need to use cave show with specific conditions? > > Isn't that just the package that records which accounts are > automatically created by cave? ?As such, IIUC there's no real > "building" required and it should be OK to do on your low-speed > servers. > I'm understand, but when i try to create pbins for system paludis says, that accounts already installed on / and stops... -- Vasiliy Tolstov, Clodo.ru e-mail: v.tolstov at selfip.ru jabber: vase at selfip.ru From lmi at ift.uni.wroc.pl Tue Feb 28 15:08:43 2012 From: lmi at ift.uni.wroc.pl (=?utf-8?Q?=C5=81ukasz?= Michalik) Date: Tue, 28 Feb 2012 16:08:43 +0100 Subject: [Exherbo-dev] creating pbins for all packages in the system to easy uprade low speed server In-Reply-To: References: Message-ID: <20120228150843.GA2923@havoc.ift.uni.wroc.pl> On 10:09 2012-02-28 +0400, Vasiliy Tolstov wrote: > Hello. I have some low speed servers running exherbo and want to > compile all packages via pbins on build server. > How can i avoid accounts packages? cave resolve --make binaries -x1 > system for example, tries to install accounts packages.... > Or i need to use cave show with specific conditions? Add "--without 'user/*' --without 'group/*'" to your cave resolve invocation. -- Pozdrawiam, ?ukasz P. Michalik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: