Exherbo

I’ve just created a repository to publish my Paludis hooks.Right now there are two simple hooks in the repository.The first one is to generate locales after glibc updates.You can think this as a locale-gen equivalent for Exherbo.The second one updates /etc/localtime when timezone-data is updated.

This is part of a series on EAPI 3. In EAPI 3, econf will pass --disable-dependency-tracking. This might marginally speed up a few packages’ builds, and breaks a few others that have funky half-hand-written makefiles. What it won’t do, despite what ... [More] you may of heard from certain less well informed Council members, is break packages that are using custom configure scripts. Those packages, if they have configure scripts that die on unrecognised options, aren’t using econf anyway since econf already passes all kinds of weird nonsense through. In summary, pretty much no-one has any reason to care about this particular feature, and it’s only being discussed here for completeness. Posted in eapi 3 Tagged: eapi 3 [Less]

This is part of a series on EAPI 3. In another disappointing defeat for the shadowy cabal controlling Gentoo’s every move (no, not that cabal, the other one), EAPI 3 will see unpack support xz format archives. This is icky. Support for unpacking lzma ... [More] files was retroactively shoved into existing EAPIs because Mike Frysinger decided to just commit support to Portage without an EAPI change and start relying upon it for coreutils, making it impossible for everyone else to do anything except copy the change. This, it turns out, was a waste of time, since the lzma format is effectively deprecated in favour of xz. Now, despite it not having any unmasked extractor on Gentoo, unpack in EAPI 3 is required to know how to unpack xz files. Whilst this is a step better than doing the change without an EAPI bump (no thanks to Mike, who tried to put it in without one), it’s still silly. Of course, soon we’ll have to add in support for whatever the cool kids are using next week into EAPI 4. Posted in eapi 3 Tagged: eapi 3 [Less]

Yesterday around 12 am, the #irssi channel on IRCnet experienced a channel takeover, so we had to move our channel to #irssi.org instead. Please update your configuration file and remember to read the full announcement at irssi.org.

This is somehow surprising the first time you see it and it is interesting to remind it to people from time to time. The question is easy, does this program always return 0? That is, are those summations the same? If there’s a case when it doesn’t ... [More] , provide a sample input and explain why it happens. #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { float f[argc - 1]; for (int i = 1; i < argc; i ) f[i - 1] = atof(argv[i]); float r1 = 0; for (int i = 0; i < argc - 1; i ) r1 = f[i]; float r2 = 0; for (int i = argc - 2; i >= 0; i--) r2 = f[i]; return r1 != r2; } As usual, I’ll post the solution in a couple of days or when someone gets it right (which is always the case :)) — fpereda Update: correct typo spotted by Snaury. Tagged: C, CS, programming, trivia [Less]

This is part of a series on EAPI 3. The dohard utility is used to create a hard link between two files. Except it can’t necessarily do that, and even when it does it probably won’t end up being merged as a hard link; up until recently, Portage only ... [More] supported merging hard links by fluke if it happened to take a particular fast-path in the code, and few people even noticed. Even in ideal circumstances, dealing with hard links is fraught with mess, so we’ve decided to ban dohard in EAPI 3 as a way of discouraging their use. As for dosed… It doesn’t really do what you think, it’s been considered deprecated for ages and there are better alternatives. EAPI 3 bans it too. Both of these were originally banned in kdebuild-1. Unfortunately, kdebuild-1’s banning of the abomination that is dohtml hasn’t made it into EAPI 3. Posted in eapi 3 Tagged: eapi 3 [Less]

This is part of a series on EAPI 3. Currently, to install a directory full of documentation, you have to either copy the directory yourself (after making the parent directory), or play around with into and doins -r. EAPI 3 adds a -r switch to dodoc ... [More] for recursively installing a directory. On the subject of doins, currently doins -r’s behaviour is undefined for anything except files or directories. With EAPI 3, doins -r will also be guaranteed to install symlinks correctly. Incidentally, there’re probably a whole bunch more small improvements like these that we could make to the utilities. Suggestions (along with demonstrations of use cases) for EAPI 4 will be being taken in the not too distant future; something like the above is easy to get in. Posted in eapi 3 Tagged: eapi 3 [Less]

This is part of a series on EAPI 3. Gentoo is, as everyone knows, about choice. This means it is considered vitally important that users get to choose such earth-shatteringly important matters as which program is used to compress their documentation ... [More] files. It doesn’t matter that blockers repeatedly confuse people, that the tree is an unmanageable mess or that there’s no way of handling USE flag requirements — ensuring that the user’s choice of compression is applied to a small number of documentation files in every case is critical to Gentoo’s future. As such, EAPI 3 introduces controllable compression. It works like this: The package manager maintains a list of things that may be compressed in some arbitrary way. By default, this list includes /usr/share/doc/, /usr/share/info and /usr/share/man. The package manager also maintains a list of things to be excluded from the above compression. By default, this list includes /usr/share/doc/${PF}/html. Inside src_install, packages can add things to the inclusion list using docompress blah, and to the exclusion list using docompress -x blah. After src_install has finished, the package manager may apply some kind of compression to anything in the inclusion list that is not also in the exclusion list. PMS is carefully worded to allow all of this nonsense to be a no-op. Controllable compression is a Gentoo-original feature, and clear proof that there is no magic external cabal dictating Gentoo’s future, since they’d never let people get away with this if there were. Posted in eapi 3 Tagged: eapi 3 [Less]

This is part of a series on EAPI 3. EAPI 3 will feature a default src_install that isn’t just a no-op. While it won’t eliminate the need for some packages to write their own implementation, it will help in a good number of cases. The exact default is ... [More] still subject to bikeshedding and could be changed at any point right up until PMS is tagged for EAPI 3. Right now we’re going with the following, and it’s very likely the final choice will look more or less like this: src_install() { if [[ -f Makefile ]] || [[ -f GNUmakefile ]] || [[ -f makefile ]]; then emake DESTDIR="${D}" install fi if ! declare -p DOCS >/dev/null 2>&1 ; then local d for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \ THANKS BUGS FAQ CREDITS CHANGELOG ; do [[ -s "${d}" ]] && dodoc "${d}" done elif declare -p DOCS | grep -q '^declare -a ' ; then dodoc "${DOCS[@]}" else dodoc ${DOCS} fi } Note the following: There will be a DOCS variable. This was decided by a Council vote, since not everyone sees the obvious sense of the idea. If something is explicitly listed in DOCS, it will be an error for it not to exist. But if we’re using the default values, things are only installed as documentation if they’re there and not empty. We don’t use -j1 for the install. This will break some packages built using older autotools. This is in line with Gentoo policy. The first practical non-empty src_install was in exheres-0. The exheres-0 version remains considerably more flexible and parametrisable than the above. Posted in eapi 3 Tagged: eapi 3 [Less]

This is part of a series on EAPI 3. DEFINED_PHASES and PROPERTIES were retroactively introduced into earlier EAPIs. We could get away with this because it’s legal for a package manager to do absolutely nothing with them and pretend they don’t exist. ... [More] PROPERTIES isn’t very interesting; it’s only mandatory in EAPI 3 because we like to tidy things up as we go along. DEFINED_PHASES, however, is now mandatory for a very good reason: it’s necessary to make pkg_pretend usable. Invoking an ebuild process to run pkg_pretend, even if it does nothing, takes something like a tenth of a second. If you’re doing a world update, that could mean thirty seconds of sitting around waiting, and if you’re doing a full reinstall, several minutes. In the grand scheme of things, it’s not a huge penalty, but it’s one that occurs when the user is sitting waiting rather than something added to build time — and if we add too much to pretend time, users will just stop waiting for it, which defeats the whole point of it. By requiring DEFINED_PHASES support, a package manager only has to pay the penalty for packages where it will be useful. This one’s more something that would be annoying if it were not there than a revolutionary new feature; users and developers shouldn’t have to care about it, except if they’re interested in the thought and planning that the shadowy cabal directing Gentoo’s future from their secret moon base put into all of this. DEFINED_PHASES first appeared in exheres-0, where it was always mandatory. Posted in eapi 3 Tagged: eapi 3 [Less]