8 meetings

1. October 11, 2007
   • let -project talk about coc, or dberkholz will write a proposal on how to implement
   • infra will decide what happens to packages.gentoo.org. They decide the old code will never be used again, dns will be redirected to a forums thread for alternatives, and someone will have to write a replacement.
   • Glep 39 will be amended for some reason, and a note added. Although it’s marked as amended this month, there’s nothing in the glep to indicate what changed.
   • Confirmed that their term will end on the same date the old council’s did, they started late because the elections started late.
   • My Interpretation: Did nothing about the COC, a GLEP got updated, someone can fix p.g.o if they want.
2. November 8, 2007
   • Jokey is the candidate to replace uberlord, unfortunately not all the council are at the meeting, so he can’t be confirmed.
   • UTC and daylight savings time has confused the council, so they won’t get slacker marks for not being on time or present.
   • EAPI=1 approved for use in the tree
   • dberkholz sent out a proposal for coc enforcement the same day as the meeting, it was discussed, and a decision deferred for a month
   • uberlord will be permitted to continue to maintain baselayout-2
   • My Interpretation: fail, fail, yay, fail, whut.
3. December 13, 2007
   • Someone (flameeyes and cardoe maybe) made some changes to use flag documentation without deigning to discuss the changes with the community first. The council will not revert these changes, but they should have been discussed first, and will punish anyone who tries this again.
   • The proposal on how to enforce the coc is again revised, a decision is postponed to the next meeting.
   • My Interpretation: pussies, three meetings; no real progress.
4. January 10, 2008
   • GLEP 54 – Insufficient discussion to make a decision, returned to -dev
   • GLEP 55 – Insufficient discussion to make a decision, returned to -dev
   • vapier will work in rich0’s suggestion on how to handler slacker arches
   • dberkholz will provide additional information to gentoo-council on the direction for coc enforcement.
   • dberkholz and araujo will look into providing a “Document of being an active developer”
   • My Interpretation: fail, fail, whatever, still not finished 4 months later,whut
5. February 14, 2008
   • coc: dberkholz posted a suggestion to -council on February 13, council supportive, dberkholz will get things going.
   • “Document of being an active developer” In worked on.
   • No update about the slacker arches document.
   • GLEP 54 – Not resubmitted
   • GLEP 55 – Not resubmitted
   • GLEP 46 – Returned for discussion on why urls are restricted, once discussed, approved.
   • long discussion on whether EAPI=1, approved November 07, can continue to be used without EAPI=0 being fully defined, halcy0n will work on finishing PMS.
   • My Interpretation: still done basically sweet fa, whut, one month and counting, dead glep, dead glep, yay; almost accepted a glep, is it that hard to update portage-utils?
6. March 13, 2008
   • Vapier will be working on the slacker arch doc this weekend.
   • “Document of being an active developer”: no update
   • GLEP 46: no updates, no authors present.
   • EAPI=0. Work continues but it is not ready yet.
   • Summer of Code: Gentoo SOC admins will decide if new blood should be preferred over developers, council will be extra SOC admins.
   • There aren’t enough package maintainers, try and promote proxy maintainership more.
   • amd64 team is no longer fucntioning any developer who has the hardware can keyword whatever they want.
   • My Interpretation: two months and counting, three months and counting, from >< close to acceptance to nothing, at least something has allegedly been done, like Gentoo has ever managed SOC successfully, proxy-maintainers: because we don’t have enough real developers, fucking ridiculous.
7. April 10, 2008
   • “Document of being an active developer”: no update
   • Vapier is finishing up the slacker arch doc and will post it “tonight”
   • GLEP 46: Approved. It’s not clear from the summary whether there was any further discussion.
   • discussion on minimum level of activity required to remain a developer.
   • kdebuild is not allowed in PMS if it’s not intended to be submitted to the council for approval.
   • My Interpretation: four months and counting, seeing is believing (three months now), yay, a 3 year old GLEP finally gets approved and it only took 3 months, blah blah blah decision deferred, actual question asked was “is this generally ok” it doesn’t seem to have been answered.
8. May 8, 2008
   • “Document of being an active developer”: demo certificate has been created, feedback provided, method of signing still unclear.
   • Vapier not present and no update given on on slacker arch doc.
   • When are changelogs required? Council confirms that there is no change to the rules on when changelogs are required.
   • Can the council help fewer bugs get ignored by arm/sh/s390 teams? Council understand that work is being done but bugs are not being updated, but doesn’t understand the situation well enough to advise.
   • Can versions contain more than 8 digits? Insufficient information to make a decision.
   • How will the council handle appeals against forced retirements? Meeting stopped.
   • My Interpretation: five months and counting – still not done, 4 months – still no progress, lol vapier, lol vapier, fail, fail.

Conclusion

Over 8 months this council has acheived little. Only Jokey has had the time to attend all meetings. Vapier appears to have had little time for his council duties (having the lowest attendance) and in the last meeting had two items that appeared to be directed at his behaviour.

On several occasions the council faced a topic a meeting that they felt required more discussion, or that they did not have enough information available to decide on a topic, but there is no evidence that any members of the council attempted to foster discussion or acquire extra information before or after the meeting, leading to the situation that they have meeting, talk in circles for a bit, then decide nothing.

One can’t be entirely sure from their summaries, but it seems that in eight months this council have failed to take a lead in any shape or fashion, managed to update 1 GLEP, approve EAPI=1 for use and then decided that they had no idea what EAPI=1 was, rejected 2 GLEPS, accepted a 3 year old GLEP, after failing to generate a discussion about it. Anything else that was brought before the council has been deferred, ignore, postponed or forgotten about.

Vote for anyone from this council again … vote for mediocrity at best.

As nightmorph has seen fit to re-nominate the outgoing gentoo council, I thought I’d do a quick analysis of their attendance at council meetings. For the purpose of this exercise, I’m just going to examine the 8 regularly scheduled meetings they had, and not include the second May meeting that only two members managed to attend.

jokey is the only council member to have a 100% personal attendance record, although as the replacement for uberlord, he had only 6 meeting to make it to. Of the other council members, amne, betelgeuse and flameeyes all managed to be present for 7/8 meetings (87.5%),flameeyes was proxied for the meeting he missed, betelgeuse was an hour late, and amne was AWOL.

dberkholz and lu_zero attended 6/8 meetings (75%), both were proxied for meeting, dberkholz was significantly late for another, and lu_zero was AWOL.

vapier personally attended 5/8 meetings (62.5%), was proxied for two others, and was AWOL for one.

I just scanned the council homepage for the attendance statistics. There’s also a second sheet, where I did calcule their attendance including their second May meeting, but I decided that the fact they can’t even agree among themselves as to whether there was a meeting probably says enough already, and I didn’t want to dent jokey’s 100% turnout rate.

If I have time later, I’ll probably trawl through the summaries to analyse how effective this council have been.

–
Edited because a) I can’t read, and b) forgot about lu_zero

Version 1.8.7 of ruby has been released, with magical vendor-dir support that I don’t recall being in the first few pre releases. It looks like someone decided to hack the autofoo as well, to obey –libdir, although it seems that while the default site_ruby uses it, the default vendor_ruby doesn’t yet. Here’s an ebuild for it, if you need one, and I’ve already added it to arbor.

At work we’ve got an old app we still haven’t upgraded from rails-1.2.6, 1.8.7 broke it. The first breakage has been fixed in 1.8.7 with this patch, and the second breakage we’ve found is that String now has a .chars method, returning an enumerable, this doesn’t get on with activesupport-1.4.4/lib/active_support/core_ext/string/unicode.rb, which defines chars to return ActiveSupport::Multibyte::Chars.new(self). We’ve noticed this where using attachment_fu is trying to use String.first, and I’m sure we’d have noticed it in more places if we’d ever written our tests properly. For now, we’ll just cheat and use String.class_eval { remove_method(:chars) } to drop the new method, but soon I suppose we’ll actually have to get around to upgrading.

I needed to check a pdf from work tonight, and didn’t have a pdf viewer installed on my exherbo install. I checked, and someone had written an exheres for epdfview already, but there was a problem when I tried to install it.

$ sudo paludis -i epdfview -p
Building target list...
Building dependency list...
DepList additional requirements not met error:
  * In program paludis -i epdfview:
  * When performing install action from command line:
  * When executing install task:
  * When building dependency list:
  * When adding PackageDepSpec 'app-text/epdfview':
  * When adding package 'app-text/epdfview-0.1.6:0::x11':
  * When adding build dependencies as pre dependencies:
  * When adding PackageDepSpec 'app-text/poppler[gtk]':
  * Error searching for 'app-text/poppler[gtk]': additional requirements are not met

Additional requirements are as follows:
    * Flag 'gtk' enabled

I checked poppler, and for some reason I’d only installed it with the jpeg option, so I edited my use.conf to add gtk to poppler’s options, and ran paludis -i epdfview -p again. To my pleasant surprise I saw this:

$ sudo paludis -i epdfview -p
Building target list...
Building dependency list...

These packages will be installed:

* app-text/poppler::x11 [R 0.8.1]
    Reasons: *app-text/epdfview-0.1.6:0::x11
    -cairo -cjk gtk* jpeg
* app-text/epdfview::x11 [N 0.1.6]
    "A lightweight PDF document viewer using Poppler and GTK+ libraries"
    -debug nls

Total: 2 packages (1 new, 1 rebuild)

I checked with TPB and it’s a currently a feature, not a bug, so I say yay for progress, yay.

When messing around with you ssh keys, trying to convince github to let you use the right ssh key with the right account, and you think it would be a good idea to temporarily move your sekrit key to a new filename, try not to overwrite you public key with it when you want to move it back.

This post is brought to you by the thank god I only deleted the public key, not the sekrit key department.

A script that I liked to use, when I was a gentoo dev, was compare_gems.rb.

This script runs through a repository using Paludis::NoConfigEnvironment, so that it’s not actually necessary to configure paludis¹. It grabs a list of all the packages that inherit the gems.eclass and then queries rubygems to find out which packages in the repository are lagging behind the published gems. It outputs all this infomation into a nice pretty html² file.

This helped me to keep the gem ebuilds that I used up to date, and also told me all the other gems we had that had fallen behind. It’s not 100% perfect on matching, sometimes the gentoo package names don’t match the gem name, and it won’t do anything clever, like checking the src_uri, to find out what gem it should really match

A few people, i.e. at least two, have come into #paludis to ask for help with fetching distfiles. Their specific problem is that the computer they want to update doesn’t have a fast connection to the internet, so they want to generate a list of files to download, take it to another machine that does have a relatively fast connection, download the files, and take them home again.

The usual answer these poor people receive is that they should upgrade their internets. Sometimes, they are told that the mysterious “dleverton” is thinking about possibly maybe one day writing a client that may achieve their goal for them. Today, I have made their dreams reality, with the world’s worst ruby script.

Run the script with just one target, and theoretically it will send to the files you need to download, in the format:

filename,download_location_1,download_location_2,…

The script is still in its first draft form, but it should work, and I may update it to be less stupid, to bind to more paludis source (rather than just copying it to ruby) and to have more polite variable names. To use it you will need paludis-scm installed, as I only commited the mirrors binding stuff today.

Good luck, you’ll need it.