Exherbo

sydbox-0.1_alpha is released.This is the initial release of sydbox. What is sydbox? Sydbox is a ptrace based sandbox implementation which is based in part upon catbox and strace.Being ptrace based, it doesn’t suffer from the well known security ... [More] issues thatLD_PRELOAD based sandbox implementations suffer from.It has basic support to disallow network connections. OS/Arch Support At the moment only supported operating system is Linux and only supported architectures are x86 and x86_64but adding support for new architectures should be trivial.If you’re interested in porting please send a mail to me or leave a comment to this post. homepage: http://alip.github.com/sydbox/tarball: sydbox-0.1_alpha.tar.bz2sha1sum: e6d40372242951da90973490923c3fc14622c2a4 [Less]

envtag-0.3 has been released. Rewritten in C to make better use of taglib Lua is a hard dependency now, envtag uses it extensively Support for getting/setting Xiph Comments Optional libmagic based filetype detection support, enable with –enable-libmagic tarball: envtag-0.3.tar.gz sha1sum: 98159a8c53e9aadbeb36c7b83f24099e7ab4566c

Envtag-0.3 has been released. Rewritten in C++ to make better use of taglib. Lua is a hard dependency now, Envtag uses it extensively. Support for getting/setting Xiph Comments. Optional libmagic based filetype detection support, enable with –enable-libmagic tarball: envtag-0.3.tar.gzsha1sum: 98159a8c53e9aadbeb36c7b83f24099e7ab4566c

No, this is not an April fool's joke! Remember to check out the newest Irssi release! See http://www.irssi.org/ for more information and remember to read the NEWS file

I’ve been playing around with Ruby to create Summer, a simple web packages thing for Exherbo. Originally I was hand-creating HTML output simply because it’s easy, but that started getting very very messy. Mike convinced me to give ERB a shot. The ... [More] problem with template engines with inline code is that they look suspiciously like the braindead PHP model. Content and logic end up getting munged together in a horrid, unmaintainable mess, and the only people who’re prepared to work with it are the kind of people who think PHP isn’t more horrible than an aborted Jacqui Smith clone foetus boiled with rotten lutefisk and served over a bed of raw sewage with a garnish of Dan Brown and Patricia Cornwell novels. So does ERB let us combine easy page layouts with proper separation of code? Well, sort of. ERB lets you pass it a binding to use for evaluating any code it encounters. On the surface of it, this lets you select between the top level binding, which can only see global symbols, or the caller’s binding, which sees everything in scope at the time. Not ideal; what we want is to provide only a carefully controlled set of symbols. There are three ways of getting a binding in Ruby: a global TOPLEVEL_BINDING constant, which we clearly don’t want, the Kernel#binding method which returns a binding for the point of call, and the Proc#binding method which returns a binding for the context of a given Proc. At first glance, the third of these looks most promising. What if we define the names we want to pass through in a lambda, and give it that? require 'erb' puts ERB.new("foo <%= bar %>").result(lambda do bar = "bar" end) Mmm, no, that won’t work: (erb):1: undefined local variable or method `bar' for main:Object (NameError) Because the lambda’s symbols aren’t visible to the outside world. What we want is a lambda that has those symbols already defined in its binding: require 'erb' puts ERB.new("foo <%= bar %>").result(lambda do bar = "bar" lambda { } end.call) Which is all well and good, but it lets symbols leak through from the outside world, which we’d rather avoid. If we don’t explicitly say “make foo available to ERB”, we don’t want to use the foo that our calling class happens to have defined. We also can’t pass functions through in this way, except by abusing lambdas — and we don’t want to make the ERB code use make_pretty.call(item) rather than make_pretty(item). Back to the drawing board. There is something that lets us define a (mostly) closed set of names, including functions: a Module. It sounds like we want to pass through a binding saying “execute in the context of this Module” somehow, but there’s no Module#binding_for_stuff_in_us. Looks like we’re screwed. Except we’re not, because we can make one: module ThingsForERB def self.bar "bar" end end puts ERB.new("foo <%= bar %>").result(ThingsForERB.instance_eval { binding }) Now all that remains is to provide a way to dynamically construct a Module on the fly with methods that map onto (possibly differently-named) methods in the calling context, which is relatively straight-forward, then we can do this in our templates: <% if summary %> <p><%=h summary %>.</p> <% end %> <h2>Metadata</h2> <table class="metadata"> <% metadata_keys.each do | key | %> <tr> <th><%=h key.human_name %></th> <td><%=key_value key %></td> </tr> <% end %> </table> <h2>Packages</h2> <table class="packages"> <% package_names.each do | package_name | %> <tr> <th><a href="<%=h package_href(package_name) %>"><%=h package_name %></a></th> <td><%=h package_summary(package_name) %></td> </tr> <% end %> </table> Which gives us a good clean layout that’s easy to maintain, but lets us keep all the non-trivial code in the controlling class. Posted in summer Tagged: exherbo, ruby, summer [Less]

Gentoo is shuffling its way towards EAPI 3. The details haven’t been worked out yet, but there’s a provisional list of things likely to show up that’s mostly been agreed upon. This post will provide a summary; when EAPI 3’s finalised, I’ll do a ... [More] series of posts with full descriptions as I did for EAPI 2. PMS will remain the definitive definition; I’ve put together a a draft branch (I’ll be rebasing this, so don’t base work off it if you don’t know how to deal with that). Everything on this list is subject to removal, arbitrary change or nuking from orbit. We’re looking for a finalisation reasonably soon, so if it turns out Portage is unable to support any of these, they’ll be dropped rather than holding the EAPI up. EAPI 3 will be defined in terms of differences to EAPI 2. These differences may include: pkg_pretend support. This will let ebuilds signal a lot more errors at pretend-time, rather than midway through an install of a hundred packages that you’ve left running overnight. This feature is already in exheres-0. Slot operator dependencies. This will let ebuilds specify what to do when they depend upon a package that has multiple slots available — using :* deps will mean “I can use any slot, and it can change at runtime”, whilst := means “I need the best slot that was there at compile time”. This feature is already in exheres-0 and kdebuild-1. Use dependency defaults. With EAPI 2 use dependencies, it’s illegal to reference a flag in another package unless that package has that flag in IUSE. With use dependency defaults, you’ll be able to use foo/bar[flag( )] and foo/bar[flag(-)] to mean “pretend it’s enabled (disabled) if it’s not present”. This feature is already in exheres-0. DEFINED_PHASES and PROPERTIES will become mandatory (they’re currently optional). This won’t have any effect for users (although without the former, pkg_pretend would be slooooow). There’s going to be a default src_install of some kind. Details are yet to be entirely worked out. Ebuilds will be able to tell the package manager that it’s ok or not ok to compress certain documentation things using the new docompress function. dodoc will have a -r, for recursively installing directories. doins will support symlinks properly. || ( use? ( ... ) ) will be banned. dohard and dosed will be banned. (Maybe. This one’s still under discussion.) New doexample and doinclude functions. (Again, maybe. Quite a few people think these’re icky and unnecessary.) unpack will support a few new extensions, probably xz, tar.xz and maybe xpi. econf will pass --disable-dependency-tracking --enable-fast-install. This is already done for exheres-0. pkg_info will be usable on uninstalled packages too. This is already in exheres-0 and kdebuild-1. USE and friends will no longer contain arbitrary extra values. (Possibly. Not sure Portage will have this one done in time.) AA and KV will be removed. New REPLACED_BY_VERSION and REPLACING_VERSIONS variables, to let packages work out whether they’re upgrading / downgrading / reinstalling. exheres-0 has a more sophisticated version. The automatic S to WORKDIR fallback will no longer happen under certain conditions. exheres-0 already has this. unpack will consider unrecognised suffixes an error unless --if-compressed is specified, and the default src_unpack will pass this. exheres-0 already has this. (Maybe. Not everyone’s seen the light on this one yet.) The automagic RDEPEND=DEPEND ick will be gone. Utilities will die on failure unless prefixed by nonfatal. exheres-0 already has this. Unless, of course, something completely different happens. Posted in eapi 3 Tagged: eapi, eapi 3, gentoo [Less]

To avoid name clashes and silly names we're adding a new set of rules for naming repositories. The rules affect profiles/repo_name and not the actual sync url which can differ if neccessary. I'd recommend using the same name however.The new rules for ... [More] repo_name is as follows:- Official topic repositories uses the topic as name.- Personal repositories uses use the owners (nick)name- Personal topic repositories use owners (nick)name-topicSo the official KDE repository is named 'kde' and you can find all it's packages using for example 'paludis --list-packages --repository kde'. Ingmars personal repository is named 'ingmar' and if he had a personal topic repository for office type packages it would be named 'ingmar-office'.I hope the new rules will make the status of repositories easier to understand. [Less]

Please refrain from wasting developers’ time because you don’t want to read the error messages you get on your screen. Read them, act upon them or ask about the specific error message, rather than giving vague statements such as “I did X and now Y doesn’t work”. Oh, and read this. NOW! -- Thanks, The Management.

Onsdag d. 25/3 kl. 19 - til SSLUGs onsdagsmøde på CBS, vil Jesper Louis Andersen snakke om Graphviz. Graphviz er et værktøj som kan benyttes til visualisering af dine grafdata. Du specificerer grafen og programellet foretager dernæst automatisk ... [More] layout for dig. Dette kan benyttes til dynamisk visualisering af data i et computersystem. I dette foredrag introduceres Graphvizformatet og der gives eksempler på hvad man bruge det til. Det forventes at de fleste vil være i stand til at benytte værktøjet umiddelbart efter foredraget - eller efter et par timers leg med det. Om foredragsholderen Jesper Louis Andersen er Bachelor i Datalogi og er i skrivende stund igang med at tage sin kandidatgrad. Han interesserer sig for programmeringssprog af alle slags, samt hvad teknologien bag også kan anvendes til uden for sprog-feltet. For tiden køres der med Debian Linux. Tid og sted Mødet foregår på: CBS - Copenhagen Business School, Howitzvej 60, 2000 Frederiksberg og døren vil være åben fra kl. 18.00. Foredraget starter kl. 19.00. Se eventuelt http://wiki.sslug.dk/index.php/LokalGruppenKøbenhavn Det er ikke nødvendigt at tilmelde sig dette arrangement, arrangementet er gratis og alle medlemmer af SSLUG er velkomne. [Less]

I’ve just added Lua scripting support to envtag. This makes it possible to run Lua scripts on audio tags, enabling you to play with them through a simple Lua interface. Audio properties like bitrate, samplerate can also be retrieved through the same ... [More] interface. By interface i mean two Lua tables named tag and prop, which have get() and set() functions There are some examples under examples/lua directory of the source tree if you’re interested. This was a quick attempt to add Lua support and i don’t think it’s perfect yet but it works for me. If you want me to change it in a way that’s more useful, please comment and/or email me explaining how [Less]