[08:51] <flaccid> erichammond: i have that image going RightScale managed in a deploy atm
[10:11] <erichammond> flaccid: I'm having trouble parsing that sentence.  Is it possible to rephrase?
[10:11] <flaccid> i have your latest ubuntu image running under rightscale and its script management
[10:12] <erichammond> Are you using the lightweight bootstrap init script or a full RightScale software install?
[10:13] <flaccid> im using basically what i ported from http://support.rightscale.com/06-FAQs/FAQ_0103_-_How_do_I_make_any_Amazon_Machine_Image_(AMI)_capable_of_running_RightScripts%3f which essentially a colleage in services here did a while ago
[10:15] <erichammond> I can't use that approach on the images I build because it significantly increases the image size (and startup time) just to support a service which most of the users aren't going to be using.
[10:16] <erichammond> If RightScale support can be added as a lightweight, optional feature which is only triggered when run inside the RightScale environment, then I'm happy to add it.  This seems to be the intent of the init script Martin provided.
[10:16] <flaccid> that was part of the reason why i was taking them upstream. i was unaware of this lightweight thing
[10:17] <erichammond> In both cases, I'd also be interested to know if there are any limitations in the RightScale support.  For example, I know that they enable RightScripts, but do the images also work with the monitoring, rebundling, and other integration features?
[10:18] <erichammond> Plus, I've heard that some of the more advanced RightScripts may have needed some polishing to work smoothly with Ubuntu, so it would be nice to hear if this has been done.
[10:19] <erichammond> At this point, it's all rumor and hearsay as I'm not actively testing RightScale beyond seeing that a simple RightScale startup script is run.
[10:19] <flaccid> as for the monitoring, the sys monitoring install script would need to be run and that would need to be compatible
[10:19] <flaccid> in terms of RightScripts in general, a lot are being updated, but there is still some that are not independent of distro etc.
[10:21] <flaccid> well eric, i am new, but i am there. personally i use debian in the cloude, not ubuntu or centos, so you can be assured i'll be following all this up. i had not rcvd any word on any new script that conditionally tested for debian lsb ..
[10:22] <erichammond> If you ever run into Uri, tell him I said hi.
[10:22] <flaccid> ah i'll ping him, i saw him last week; we were in the same motel
[10:23] <flaccid> he is very transient in terms of travel
[10:28] <erichammond> Also, if you are aware of a super-responsible, super-technical person/organization who cares deeply about Debian on EC2 and who might be interested in the thankless job of building, maintenance, and support of public Debian AMIs, I'd be interested in phasing out of this in the coming year.
[10:28] <flaccid> erichammond: oh and your note on start up time, i didn't do that as a boot script. i bundled it.
[10:28] <flaccid> erichammond: isn't that where I come in ?
[10:31] <erichammond> Time will tell :)
[10:31] <flaccid> sure..
[10:32] <flaccid> id like ec2 to upgrade xen so i can run freebsd
[10:32] <flaccid> so i settle for debian
[10:32] <erichammond> I'm not doing anything official, so anybody can really put forth a better (or as good) product and folks can migrate over.
[10:32] <erichammond> I'm willing to provide mentoring and guidance to anybody who is interested in tackling the project.
[10:33] <flaccid> i just see it as an ec2 ami and rs enabled branch
[10:33] <erichammond> My first point of guidance is: You have no idea what you're getting into.  You really don't want to do this.
[10:33] <flaccid> why is that
[10:33] <erichammond> If they're misguided enough to continue, then they've passed the first test.
[10:34] <flaccid> i'm sure i've tackled greater obstacles
[10:38] <erichammond> Building the first public AMI is the easy part.  It's the months and months of upgrading, testing, support, feedback, etc. where the initial glamor starts to wear off.
[10:38] <erichammond> There is also a lot of pressure to make sure that the AMIs are kept available as companies are depending on them for their business to stay afloat and for their individual livelihoods.
[10:39] <erichammond> Once you create a public AMI that folks are depending on, you can pretty much never delete it.
[10:39]  * Debolaz saves "Building the first public AMI.." line in his quote file for later lols.
[10:50] <erichammond> I'm going on two years in December and, though it's been personally rewarding in a number of ways, I am hoping my contributions to the community in another year will be taking on a different form.
[10:54] <flaccid> thanks for the info. i like to make the build process as automated as possible. i respect your AMIs and use them so its just a matter of where you want to go
[21:00] <smoser> erichammond, just fyi, i talked with martin earlier regarding bug 434181 and he is thinking they'd like to go that way
[21:00] <smoser> it means they dont ever have to block on us as long as we keep a compatible run-user-data
[21:02] <erichammond> smoser: Good to know.  Seems like they'll have to solve a couple tough problems: How to determine if an AMI supports user-data scripts (not possible to do in the general sense); How to make user-data look the same to users who are passing in user-data within RightScale (though I suppose if users are using the RightScale API to access user-data it could be done).
[21:04] <smoser> well the first problem is easier than getting some arbitrary script included in everyone's images, and maintaining them there.
[21:04] <smoser> the second, yeah, i dont know whow they let users get at user data, this would result in them putting more there then they are currently.
[21:05] <smoser> they currently *do* put some stuff in user data though. something like:
[21:05] <smoser> RS_rn_id=427443<EMAIL_ADDRESS>RS_api_url=https://my.rightscale.com/api/inst/ec2_instances/3c5b532b9b035589cf6b3414c4be2f8817ab14d6,
[21:07] <erichammond> smoser: Right, I was aware of the first line which triggers the startup hooks, but their web interface also lets the user specify "user-data" which I thought was sent as the contents of user-data after that line.
[21:07] <smoser> i dont know. martinr mentioned to me "cross cloud"ness
[21:07] <erichammond> smoser: I haven't looked at this part in a couple years and they might implement the "user-data" outside of user-data.
[21:08] <smoser> and the inability to rely on user-data outside of ec2
[21:08] <erichammond> smoser: In any case, as long as they are willing to do the work, I'm thrilled.
[21:08] <smoser> so if they want to be at all cross-cloud for their users, giving raw access to user data meta service isn't probably good anyway
[21:09] <erichammond> smoser: Yep, it makes sense with all the expansion they've done beyond just EC2.
[21:10] <smoser> since your here...
[21:10] <smoser> if you want to try to put together suggested changes for "run at S99" bug, go ahead.
[21:11] <smoser> the thing i am dreading is that i'm going to get questioned on 2 init scripts being installed by that package .. as in bug 434693
[21:12] <erichammond> smoser: I didn't notice an objection to multiple init scripts in that bug.
[21:13] <erichammond> Is this really the first package which had to do things at different rc priorities?
[21:13] <smoser> no. but objections to lots of things. and them not being proper init scripts anyway... i dont know. your'e right though nothing explicit against it.  but the lsb headers and such is a pita.
[21:16] <erichammond> smoser: So do you think the existing ec2-init script is going to have a lot of changes soon?  Should I wait for those before splitting it?
[21:17] <smoser> i dont think so.
[21:17] <smoser> oh. well, other than using echo versus lsb_functions
[21:17] <erichammond> smoser: ok, simple 'nuff
[21:18] <Debolaz> Hmm... I'm going to set up a secondary nameserver on EC2. I'm pondering how to push out the configuration file (named.conf) for it. Is this something I should be storing on S3, or is it better to just download it from our (non-ec2-)website?
[21:18] <erichammond> smoser: bzr+ssh://bazaar.launchpad.net/~ubuntu-on-ec2/ec2-init/trunk/ seems to have disappeared.
[21:18] <erichammond> What branch should I use as the base for the proposed changes?
[21:19] <erichammond> I have a note about bzr+ssh://bazaar.launchpad.net/~soren/ec2-init/0.5/ at some point in the recent past
[21:21] <smoser> yeah, thats what i have as trunk
[21:21] <smoser> soren is sick today, but i'd ask him what he wants. i'm not even really privy to publish a build
[21:21] <smoser> but i doubt its significantly different
[21:22] <smoser> erichammond, dont bother. ill try to do this tonight.
[21:22] <smoser> err.. wait. can't tonight.
[21:22] <smoser> but i'll get to it.
[21:57] <erichammond> smoser: ok, thanks


[03:46] <r00tintheb0x> I've been experimenting with different desktop enviroments on a Gnome Ubuntu install, I've settled on LUbuntu. Is there a way to remove the others without borquing the install?
[03:47] <nannes> r00tintheb0x: I think it would be much better to directly reinstall Lubuntu, now that you've settled with lxde
[03:47] <r00tintheb0x> Okay nannes , I thought the same. I've got like, six desktop enviroments on it. Hehe.
[03:47] <r00tintheb0x> Thanks nannes . :)
[03:47] <nannes> The reason is: experimenting means installing many things, creating many config files etc.
[03:48] <nannes> it messes things up too much
[03:48] <nannes> Yeah, I'm happy you think the same :)
[03:48] <r00tintheb0x> nannes, not lookin forward to reinstalling wine, etc... for the 23905973th thousand time.
[03:48] <nannes> uhh
[03:48] <nannes> well, there's an anthidot for that
[03:48] <r00tintheb0x> :) Yeah, I've noticed that it isn't quite rite when you rip it down and build it up.
[03:48] <nannes> you can take the config files for all the most important programs
[03:49] <r00tintheb0x> On nannes ?
[03:49] <r00tintheb0x> Oh man, I can reinstall it.. doesn't take that long. I seemed to have lost 4 USB drives anyway.. I'm down to 1 1G.
[03:50] <nannes> I mean, pidgin for example. thunderbird. firefox
[03:50] <nannes> I mean, the most boring-to-config programs have specific locations where to save configs
[03:50] <r00tintheb0x> I use chrome and it syncs. I know what you mean though.
[03:51] <nannes> ok :))
[03:51] <r00tintheb0x> Ty though, :)
[03:51] <nannes> yw... happy that mor eand more people is appreciating lubuntu as much as me
[03:51] <r00tintheb0x> It's amazing how much quicker lubuntu is than the other alt's.
[03:51] <nannes> s/is/are
[03:51] <nannes> yeah :D XD
[03:51] <r00tintheb0x> Right.
[03:51] <r00tintheb0x> :)
[03:51] <r00tintheb0x> I started on Slackware 7.
[03:51] <r00tintheb0x> Linux Desktop's have come a long way.
[03:52] <nannes> y, and there's much more to come I hope :))
[03:52] <r00tintheb0x> Most definitely, I may get into developing soon.
[03:53] <r00tintheb0x> I've been a UNIX Sysadmin for about 10 years.
[03:53] <r00tintheb0x> Time to flip to development.
[03:53] <ianorlin> http://www.psychocats.net/ubuntu/purelubuntu
[03:53] <nannes> great! Yeah, Good luck with it! :D
[03:53]  * r00tintheb0x looks @ ianorlin 's link.
[03:53] <ianorlin> is how to switch back to only lubuntu
[03:54] <r00tintheb0x> Exxxxcellent... let me check that out before I nuke.
[03:54] <ianorlin> although after you paste if you want to keep a package you can use backspace to not remove it
[03:55] <r00tintheb0x> Okay ianorlin , I think i'll get it to default then build back up.
[03:56] <r00tintheb0x> ianorlin, I have gnome, mate, xfce, xubuntu and cinnamon installed though.
[03:57] <r00tintheb0x> brb, I'm just going to nuke it. thanks gents.
[04:24] <r00tintheb0x> Schweet, nice and clean now.
[04:25] <r00tintheb0x> NOW, to quit distro/desktop hopping. I've had a bad habbit about that, I get bored quickly.


[00:20] <RAOF> smoser: To show verification-done on multiple releases (or anywhere where the SRU isn't a simple one-package, one-release affair) you can just comment like you did there.
[00:21] <RAOF> smoser: Indeed, in general it's nicer for us if you make some sort of comment when setting verification-done. It makes it easier to trust :)
[00:24] <smoser> RAOF, well, i had put comments on them on the first upload to -proposed. better comments. then i  just re-played the.
[00:28] <smoser> !regression-alert
[00:28] <smoser> bug 1100491
[00:28] <smoser> cloud-init update in precise caused a regression.
[00:29] <smoser> regressions suck.  the good news here is that the presense in -updates isn't as bad as it is for other packages.  this is because we have not (will not) release a new cloud-image with cloud-init inside it until this fix is applied.
[00:30] <smoser> i've uploaded the fix to -proposed.
[00:32] <smoser> RAOF, if you're around, i'd appreciate https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init as mentioned above.
[00:40] <RAOF> smoser: Processing.
[00:44] <RAOF> smoser: Done.
[00:45] <smoser> RAOF, thank you.
[00:45] <RAOF> smoser: Is this something which should have been caught while testing the proposed update?
[00:45] <smoser> well, clearly yes.
[00:45] <smoser> but it was collateral damage
[00:45] <smoser> ie, not somethign that was directly trying to be fixed.
[00:50] <RAOF> Was it something that should have been identified as a regression risk?
[00:51] <smoser> its something that ideally would have been found in automated testing of -proposed.
[01:08] <smoser> RAOF, does the regression fix in -proposed still bake for 7 days ?
[01:10] <RAOF> smoser: Not necessarily; but we do want some testing.
[01:12] <RAOF> If you can provide some thorough testing then we can let it through much earlier. What we don't want to do is let it through but find it breaks something else ☺
[01:13] <smoser> well, this particiular change is clear to not make anything worse than the previous one.
[01:15] <smoser> anyone have thoughts on how to choose the size 'read' ?
[01:16] <smoser> i'm not terribly concerned about the memory used by the buffer. i'm looking for insite on how to choose one , or a reasonable default.
[01:16] <smoser> (when reading possibly large MB of data but not wanting to just do 'read()')
[01:23]  * RAOF would also be intellectually interested in the answer.
[01:24] <RAOF> I guess the context needed would be: how much data do you need before you can start processing? That's clearly the minimum buffer size.
[01:31] <smoser> RAOF, yeah, i'm basically copying
[01:31] <smoser> so 1 byte :)
[01:31] <smoser> i stuck it at 1MB
[01:31] <RAOF> Some multiple of the CPU page size would seem a reasonable default.
[01:35] <sarnold> smoser: just a little birdie from the sidelines, but cloud-image update could probably also wait on this bug: 1060404
[01:36] <sarnold> smoser: juju in lxc containers on precise has been useless for a few weeks due to that one...
[01:36] <sarnold> or, rather, juju in lxc containers with precise ...
[01:37] <smoser> sarnold, i'd love to have that fixed also, but is there actually a fix for it?
[01:37] <sarnold> smoser: as I understand, cjwatson re-pushed the package again today
[01:37] <smoser> precise is just "triaged"
[01:38] <smoser> oh. wait. no
[01:38] <smoser> oh. its still just "triaged" in lxc
[01:38] <sarnold> .. and the lxc fix was a bad idea anyhow, soo..
[01:40] <sarnold> since reproducing this specific problem is so easy, I'd happily do the verification for the juju folks :) but I haven't got a clue how to shove the fixed package into the image that it puts together. getting a fixed cloud-image seems to me like the far easier way to test it, but that's also way outside of my experience.
[01:40] <sarnold> (afterall, if there were an easy way to shove commands into early juju instance creation, one could just throw in a pin package command..)
[01:41] <sarnold> anyway, I feel better knowing it's also on your radar :)
[01:49] <smoser> sarnold, well, actually your problem magically goes away if you get a new released build
[01:49] <smoser> because lxc pulls the newer build
[01:50] <smoser> which wont have the grub or linux image inside when 'apt-get update' is applied.
[01:51] <sarnold> smoser: hrm, we're running into my lack of experience with juju :)
[01:51] <sarnold> or lack of experience with lxc :)
[01:51] <smoser> which is understandable. this stuff shoudl "just work"
[01:51] <smoser> :)
[01:51] <sarnold> hehe
[01:52] <sarnold> smoser: is there an easy way to get the -proposed repository added before the .. charms? juju? cloud-init? .. runs apt-get upgrade?
[01:53] <smoser> hm..
[01:53] <smoser> you might be able to just hold grub and linux-image
[06:11] <pitti> Good morning
[06:23] <infinity> pitti: Hey, are you still involved in langpack-o-madness?
[06:23] <pitti> infinity: yeah, together with dpm
[06:24] <infinity> pitti: langpacks are the biggest offender for https://bugs.launchpad.net/launchpad/+bug/1078697
[06:24] <infinity> pitti: Are they still being generated on a hardy host/chroot?
[06:24] <infinity> pitti: And is there any way that could be moved to >= lucid?
[06:27]  * pitti checks
[06:28] <pitti> infinity: urgh, indeed, hardy
[06:28] <infinity> pitti: Kay.  And, since we're not doing point releases for << precise, there's no reason that couldn't be precise, right?
[06:28] <pitti> infinity: sure, I can file an RT to upgrade it to precise, or just install a new one
[06:28] <infinity> pitti: But at least lucid.
[06:28] <pitti> I don't see why we couldn't build a hoary langpack on raring
[06:28] <infinity> pitti: Getting it fixed before we land the final langpacks for precise.2 would be nice.
[06:29] <pitti> the source.changes will have the extra checksums, but that doesn't appear anywhere
[06:29] <pitti> infinity: well, I'm not root in that dchroot, so I can only RT; doing that now
[06:30] <infinity> pitti: Ahh, if it's a chroot, at least it's probably simple to upgrade (or, indeed, just rebuild it as precise).
[06:37] <pitti> infinity: RT sent
[06:37] <pitti> with you CCed
[06:51] <infinity> pitti: Danke.
[07:26] <dholbach> good morning
[07:35] <pitti> hey dholbach
[07:35] <dholbach> hey pitti
[07:42] <geser> cjwatson: Hi, could you check what the migration script did to your copy of libimobiledevice from a few days ago? LP says that it got removed from from -proposed as it moved to release but there is no publishing entry for raring for it (raring has still the old version).
[08:43] <tsdgeos> tkamppeter: is cups forward-port-cups-1-5-x-cups-browsing.patch planned to get upstream?
[08:53] <pitti> tsdgeos: I think that already has been dropped, and replaced by cups-browsed
[08:54] <tsdgeos> pitti: in raring you mean?
[08:54] <pitti> yes
[08:54] <tsdgeos> ah, tx
[08:54] <tjaalton> cups-browsed is crashing constantly here
[08:54] <tjaalton> every 25s
[08:55] <tjaalton> bug 1098756
[08:56] <pitti> tsdgeos: http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=tree;f=debian/patches -> gone
[09:00] <Daviey> cjwatson: Super, you did the grub2 .d support! Thank you!
[09:07] <xnox> stgraber: infinity: so with su, it's not a bug it's a feature?!
[09:11] <tkamppeter> tsdgeos, no, the patch is not intended to get forwarded upstream, as upstream has dropped the old CUPS-specific broadcasting/browsing protocol in favor the standardized Bonjour protocol, standardized by the Printing Working Group (www.pwg.org) for printing and standard for many other network services, like wireless screen forwarding from a mobile phone to a TV. The forward-port is also already removed from Raring. Raring does the comple
[09:11] <tkamppeter> te broadcasting and browsing via Bonjour. For the browsing part I have written cups-browsed (part of the cups-filters upstream package), but print dialogs will also Bonjour-browse by themselves soon.
[09:12] <tsdgeos> ok, people seems to wrongly be using the CUPS_SERVER_REMOTE_PRINTER in adminutil.h to create new code
[09:13] <tsdgeos> devels that run ubuntu most probably :D
[09:17] <pitti> tkamppeter: ah, so cups-browsed will also disappear eventually?
[09:18] <infinity> xnox: It's potentially both a bug and a feature.
[09:25] <tkamppeter> pitti, cups-browsed will probably not disappear so quickly. One must see how well print dialogs will do the job by themselves and when, and how many legacy apps will be around which are not able to broadcast by themselves.
[09:25] <tkamppeter> pitti s/broadcast/browse/
[09:26] <pitti> tkamppeter: I thought that mainly affects broadcasting printers to clients from cups servers to cups clients?
[09:26] <pitti> tkamppeter: if that changes to bonjour, clients shouldn't even notice?
[09:26] <pitti> tkamppeter: or is that for spooler-less operation, i. e. just with cups-client?
[09:27] <tkamppeter> pitti, yes. Now CUPS servers broadcast printers via Bonjour, but CUPS daemons on clients do not browse for remote Bonjour printers.
[09:27] <tkamppeter> pitti, cups-browsed does the browsing job for CUPS currently.
[09:28] <pitti> tkamppeter: right, but why woudl applications be concerned about which protocol cups uses for discovery?
[09:28] <tkamppeter> pitti, if print dialogs are able to browse by themselves, they would send these jobs directly to the remote CUPS daemon eliminating the need of a local CUPS daemon.
[09:28] <pitti> tkamppeter: ah, so this is for spooler-less operation then
[09:29] <tkamppeter> pitti, yes.
[09:29] <pitti> but cups-browsed depends on cups
[09:29] <pitti> which wouldn't be spooler-less any more then
[09:29] <tkamppeter> pitti, cups-browsed needs cupsd as it creates local raw queues pointing to the discovered remote printers.
[09:30] <pitti> tkamppeter: but if you are going to have cupsd installed anyway, that could just as well use bonjour for discovery?
[09:30] <tkamppeter> pitti, this I do as current print dialogs only ask the local cupsd for available printers.
[09:30] <pitti> right; and as long as the local cupsd says "that printer over --> there", it shouldn't matter much whether it was discovered through the old browsing protocol or DNSSD?
[09:32] <tkamppeter> pitti, I do not patch the cupsd itself to do the Bonjour browsing as upstream would not accept it. Upstream expects print dialogs to browse, requiring us to wait for the inertia of big desktop projects and leaving us with a lot of legacy apps using old libs or individual dialogs and also not seeing the printers when using the command line.
[09:34] <pitti> tkamppeter: ah, ok; I understand
[09:34] <pitti> tkamppeter: FWIW, having print _dialogs_ do the browsing is absolutely the wrong thing
[09:34] <OdyX> yes (I'm following the interesting discussion :p )
[09:35] <infinity> tkamppeter: Are there plans to fix the constant crash/respawn cycles people are seeing?
[09:35] <pitti> tkamppeter: oh, wait, I guess for "browse themselves" you just mean "ask avahi"
[09:35] <infinity> tkamppeter: "upstart will restart it" is not a fix. :P
[09:35] <pitti> not actually "send out a request to the network"
[09:36] <cjwatson> Daviey: it was about time :)
[09:36] <tkamppeter> pitti, yes for the end user it does not matter whether the printer info is conveyed via Bonjour or the old protocol. The Bonjour is even better as printers appear and disappear immediately and not only within 30 sec.
[09:36] <cjwatson> geser: looks like it failed with
[09:36] <cjwatson> 2013-01-14 11:25:15 INFO    Job:
[09:36] <cjwatson> <PlainPackageCopyJob to copy package libimobiledevice from ubuntu/primary, PROPOSED pocket, in ubuntu raring to ubuntu/primary, RELEASE pocket, in ubuntu raring, including binaries>
[09:36] <cjwatson> raised CannotCopy:
[09:36] <cjwatson> libimobiledevice 1.1.4-1ubuntu3 in raring (binaries conflicting with the existing ones)
[09:36] <cjwatson> geser: this is a known bug when copying from series with more architectures than raring - I should've known better than to copy that
[09:36] <pitti> tkamppeter: right, so a new printer woudl send out a DNSSD message, avahi picks it up, and dialogs only ask avahi
[09:36] <pitti> tkamppeter: that makes sense indeed
[09:37] <cjwatson> geser: I'm going to do a no-change rebuild as the simplest fix for the time being
[09:37] <tkamppeter> infinity, which crash/respawn cycles do you mean?
[09:37] <cjwatson> geser: thanks for th report
[09:37] <infinity> cjwatson: We're long past the point where we shouldn't be copying from previous releases anyway, aren't we?  In the name of building with current toolchains, etc.
[09:37] <infinity> tkamppeter: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1098756 for example.
[09:39] <infinity> tkamppeter: Also, possibly unrelated, but the upload to quantal-proposed that adds an apport blacklist for cupsd crashing instead of fixing the crash?
[09:39] <infinity> tkamppeter: That's just wrong on so many levels.
[09:39] <infinity> tkamppeter: The claim that daemons crashing is "harmless" because upstart respawns them is... Wrong.
[09:41] <cjwatson> infinity: arguably, I suppos
[09:41] <cjwatson> e
[09:41] <cjwatson> Though that's never scared me because it generally isn't a regression from the previous binaries also copied from the previous release ...
[09:41] <infinity> cjwatson: (I realise the irony here, as I'm violating that on every single armadaxp and ti-omap4 kernel release right now)
[09:42] <infinity> And even worse, I suspect the ones I'm copying absolutely would FTBFS in raring.
[09:42] <infinity> But I'm told there's a 3.8 omap4 kernel coming soon.
[09:44] <infinity> cjwatson: Anyhow, it's less about regression (though that sucks too), and more about new toolchain shiny.  Like, for instance, the binutils in raring has better ABI tagging for armhf that, once the whole world is rebuilt with it (you know, by 2016 or so), we can drop our awful ld.so hacks.
[09:45] <cjwatson> Yeah
[09:51] <tkamppeter> infinity, OdyX, pitti, the upstart script for cups-browsed needs to be modified that cups-browsed starts after avahi-daemon. Did someone of you already do this?
[09:51] <pitti> start on (filesystem
[09:51] <pitti>           and started avahi-daemon
[09:51] <pitti>           and (started cups or runlevel [2345]))
[09:51] <pitti> looks fine tome
[09:52] <pitti> (space saving Thursday!)
[09:52] <OdyX> tkamppeter: not me.
[09:56] <tkamppeter> pitti, OdyX, I will do it today.
[09:56] <tkamppeter> infinity, ^^
[09:56] <pitti> tkamppeter: do what?
[09:56] <pitti> tkamppeter: it already depends on avahi
[09:59] <tkamppeter> infinity, about the cups package in quantal-proposed. I know that it is not the best solution to simply suppress the crash messages of cupsd, but the crashes are caused by the temporary forward-port patch for CUPS browsing. This patch is already removed in Raring.
[10:00] <tkamppeter> pitti, add "and started avahi-daemon" to the cups-browsed startup script.
[10:00] <infinity> tkamppeter: Yes, I read the changelog.  But if you know the cause, surely you can also fix it, rather than ignoring it.
[10:01] <tkamppeter> infinity, unfortunately, I do not know the cause within the patch. The crash goes away when turning off browsing.
[10:01] <tkamppeter> infinity, one thing I already observed is that the crash does not happen when printing but it happens during logrotate.
[10:02] <tkamppeter> infinity, I could stabilize the logrotate by actually shutting down CUPS before, doing the logrotate, and afterwards starting it again. Currently, the logs get rotated under the running CUPS and after that CUPS gets HUPed.
[10:03] <OdyX> tkamppeter: the depends on avahi-daemon is there already, in -1ubuntu2, I commented on the bug.
[10:04] <tkamppeter> OdyX, OK, now I see, this one is not in Debian's BZR repo, so I did not see it.
[10:04] <pitti> tkamppeter: I thought we moved to the git repo now?
[10:05] <OdyX> pitti: cups, not cups-filters
[10:05] <tkamppeter> pitti, got cups-filters also moved? I know that cups got moved.
[10:05] <pitti> oh, sorry
[10:05] <OdyX> I'd be more than happy to move cups-filters too. :)
[10:06] <OdyX> every time I try to use bzr, I have to relearn it from scratch.
[10:06] <pitti> I really miss bzr bd-do from git-buildpackage, otherwise it's working fairly nicely
[10:06] <OdyX> what does that do ?
[10:07] <OdyX> nah, found it.
[10:07] <pitti> OdyX: it fetches the orig.tar.gz (from pristine-tar, the archive, uscan, or get-orig-source), and puts you into a temporary build tree with the orig unpacked, the debian/ bits copied, and patches applied
[10:07] <pitti> you can hack in it, then exit, and the debian/ changes get copied back
[10:07] <pitti> I also use it to build Debian packages
[10:07] <pitti> bzr bd-do, dchroot, dpkg-buildpackge, exit 1
[10:07] <OdyX> well, with git, quilt push -a gives you that. :)
[10:08] <pitti> with git I do git-buildpackage -S -us -uc, cd ../build-area, dpkg-source -x, dchroot, build
[10:08] <pitti> so that's not so bad; I miss it more for doing experimental changes, and testing them in the temp dir without cluttering my checkout; but again, no biggie
[10:11] <pitti> oh, we are again down to two ppc builders?
[10:11] <pitti> poor yellow
[10:14] <tkamppeter> pitti, are PPC processors still produced? Can you buy any device new with a PPC processor in it?
[10:15] <cjwatson> tkamppeter: yes, and we just did - infinity is working on getting it up and running as a builder at the moment
[10:15] <pitti> nice!
[10:15] <tkamppeter> cjwatson, which device?
[10:15] <cjwatson> I don't know, some big beast :)
[10:15] <cjwatson> pitti: yellow was amd64, iirc ...
[10:16] <cjwatson> itym sulfur?
[10:16] <pitti> oh right, which one am I thinking of -- the old live image builder
[10:16] <pitti> right, that was it
[10:16] <pitti> cjwatson: well, it's also kind of yellow :)
[10:18]  * pitti wonders where in the periodic table of elements we are, and what we do after nobelium
[10:18] <pitti> oh, it already exists
[10:18] <infinity> cjwatson: For the record, linux-ppc built on sagari in 51m.
[10:18] <infinity> cjwatson: (That takes 13.5h on ross)
[10:18] <pitti> even ununoctium.canonical.com exists already
[10:19] <cjwatson> infinity: nice
[10:19] <cjwatson> pitti: we stopped using elements some time ago
[10:19] <pitti> oh, even duranium and trilithium exist :)
[10:19] <infinity> pitti: I'm working on hunting a tg3 bug with the adapter in this machine (not PPC-specific, just specific to this silicon revision of tg3, I suspect), but otherwise it''ll be good to go soon.
[10:20] <infinity> pitti: If I can't sort the tg3 bug $soon, I may just toss an e1000e in there and let 'er rip.
[10:20] <pitti> cjwatson: yeah, seems we clearly need more Star Trek episodes that introduce new elements
[10:21] <cjwatson> pitti: Since elements, we've done Arabic star names and we're now on legendary creatures
[10:21] <cjwatson> pitti: https://wiki.canonical.com/InformationInfrastructure/SA/MachineNames
[10:21] <infinity> (I do wonder why every single tg3 silicon revision seems to quirk the crap out of he driver and require two years of bugfixing to work correctly)
[10:22] <infinity> cjwatson: Didn't you miss fruit in there somewhere?
[10:33] <cjwatson> infinity: oh yes
[11:07] <cousteau> ok, so the nvidia-96 package is finally installable in Precise?
[11:09] <cousteau> tjaalton, you were the one uploading it to precise-updates, right?
[11:20] <tjaalton> cousteau: yes+
[11:20] <tjaalton> ?
[11:20] <tkamppeter> OdyX, infinity, pitti, seems that upstart does not do what it is asked for, see bug 1098756, last comment.
[11:20] <cousteau> just wanted to thank you  :)  ok, now nothing stops me from definitely upgrading to precise
[11:21] <cousteau> by the way, can that driver be ported to quantal?  I don't think the nvidia-173 supports some legacy cards
[11:21] <tjaalton> cousteau: no
[11:21] <pitti> tkamppeter: perhaps avahi-daemon is crashing?
[11:22] <tjaalton> avahi-daemon starts and runs fine if I start it manually
[11:24] <tjaalton> but yeah, boot.log shows that it's started during boot too, but isn't running by the time I'm logged in to check
[11:25] <cousteau> tjaalton, does that mean I won't be able to use my card on ubuntu versions quantal and newer with the drivers on repos?
[11:25] <cousteau> (...well, maybe with nouveau)
[11:25] <tjaalton> cousteau: only with nouveau
[11:27] <cousteau> I'm seriously considering switching to nouveau...  wonder if there's a big performance difference
[11:28] <tjaalton> I'd suggest you seriously consider a hw upgrade ;)
[11:28] <cousteau> (I noticed some Firefox 3D things being faster with Nouveau than the Nvidia drivers)
[11:28] <cousteau> tjaalton, no PCIe, only AGP.  The range of available cards is small.
[11:30] <tjaalton> can'ẗ find any cards for agp that you can buy as new..
[11:30] <tjaalton> the second hand market should have plenty
[11:33] <cousteau> well, I found an Nvidia AGP for about 50€
[11:34] <cjwatson> Anyone know Cython and fancy fixing the libimobiledevice build?  I have http://paste.ubuntu.com/1541130/ to deal with the multiarch Python failure, but then I run into a huge pile of Cython garbage.
[11:35] <cjwatson> Seems not to be fixed upstream.
[11:36] <geser> cjwatson: I just saw that libimobiledevice FTBFS due to multi-arched Python :( I will try to fix it over the weekend.
[11:36] <cousteau> actually, both NVidia and Radeon for about the same price, 47€
[11:37] <cjwatson> geser: Lovely, thanks
[11:37] <cjwatson> The Cython failure seems to be unrelated to multiarching
[11:38] <geser> I hope I have more success than you
[11:39] <bdrung> infinity: re bug #633109, it can be seen as regression when going from a ftp to a sftp upload.
[11:53] <cjwatson> geser: Looks rather like http://libiphone.lighthouseapp.com/projects/27916/tickets/285-cant-compile-cython-bindings FWIW
[12:38] <ogra_> cjwatson, ogra@anubis:~/Desktop$ apt-file search types.h|grep /types.h|grep manpages
[12:38] <ogra_> manpages-posix-dev: /usr/share/man/man7/types.h.7posix.gz
[12:38] <cjwatson> hah :)
[12:38] <cjwatson> follow up then
[12:38] <ogra_> ;)
[12:38] <cjwatson> looks like I don't have manpages-posix-dev installed here
[12:39] <cjwatson> mostly if I want posix I use the website
[12:39] <ogra_> i didnt either, but it seeems to be what he wants now that i looked at it
[12:39] <cjwatson> well, it will document what POSIX guarantees you get from <sys/types.h>, rather than what Ubuntu gives you
[12:39] <cjwatson> Which is not quite the same - sometimes people want the extensions
[12:40] <cjwatson> For example it won't document the LFS/file-offset-bits=64 mess
[12:40] <ogra_> oh, right
[12:44] <tkamppeter> pitti, so I should perhaps move the bug on to avahi-damon, as it seems to not stay stably running?
[12:44] <pitti> tkamppeter: that shoudl be verified first, though
[12:45] <OdyX> also, cups-browsed must not crash if avahi disappears, but handle the situation gracefully IMHO.
[12:51] <tkamppeter> OdyX, AFAIR it does not crash, it does "exit 1". Perhaps I should add a wait loop, so that it stays running but starts working when avahi-daemon appears.
[13:14] <mlankhorst> @pilot in
[13:39] <ev> pitti: shall I give you a ring?
[13:46] <ev> :
[13:46] <ev> whoops
[13:46] <pitti> ev: hangout?
[13:46] <ev> sure
[13:46] <pitti> or mumble, etc.
[13:46] <pitti> ev: first time I try hangout with didrocks' sound fix, let's see whether it works
[13:50] <ev> pitti: you should have an invite
[13:50] <pitti> ev: I do, just firefox says the connection has been interrupted
[13:50] <pitti> argh
[13:51] <pitti> ev: *hrmpf*
[13:52] <ev> I've got a desk phone right here, POTS is pretty stable tech
[13:52] <ev> shall I just give you a ring?
[13:52] <pitti> ev: it has an abysmally low audio quality, but I guess everything is better than total silence :)
[13:55] <davmor2> pitti, ev: you should try the canonical sip service it tends to work pretty well in sofiasip from quantal on in empathy
[13:57] <smb> slangasek, After I had a masochistic moment I tried my luck a bit on some multi-arch conversion, I am now at a point where I think I could be ok with one of the created binary sub-packages. But some others seem hard since I struggle with multiple layers of autoconfig'ish things. Would it be acceptable to go with that stage and do the rest later?
[14:00] <mpt> pitti, ev: So far in the "worth showing" box we had evolution-data-server and compiz-gnome, and in the "not worth showing" box we had lsb-release and update-notifier.
[14:01] <pitti> mpt: lsb-release on its own is not really meaningful indeed, but it seemed to have caused a problem in firefox
[14:01] <pitti> (by not working as intended)
[14:01] <pitti> mpt: but still, in terms of reporting I agree to "batch mode" for it
[14:02] <mpt> pitti, the question is, can we expect Firefox to explain the error itself (or to crash and produce an application crash error).
[14:02] <mpt> If so, there's no point showing it separately.
[14:04] <pitti> mpt: even if not, I doubt telling the user about lsb_release will be useful to explain what happend in firefox
[14:04] <mpt> fair enough
[14:23] <mitya57> barry, ScottK, doko_: I've just filed a python3-defaults MP (just letting you know so that you don't duplicate my work, but I'll be happy if someone reviewed it)
[14:23] <mitya57> https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/resync/+merge/143697
[14:30] <ScottK> mitya57: You could use sbuild or pbuilder to run the tests in a chroot.   A full VM is not needed.
[14:31] <mitya57> ScottK: I've no idea how to do that, is there a script somewhere?
[14:31] <ScottK> mitya57: pbuilder-dist in ubuntu-dev tools is probably the easiest.  pbuilder-dist raring create then pbuilder-dist raring login
[14:33] <mitya57> ScottK: I'll try, thanks
[14:51] <achiang> mlankhorst: hi, this merge of mine has been sitting since before xmas break, can you please take a look at it? (pinging you since you're marked as pilot, not because i think you know about remmina ;) https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/1093511
[14:52] <mlankhorst> sure, I'll take a look :)
[14:53] <mlankhorst> the revu page in that bug report seems to be dead, 403 forbidden
[14:56] <barry> mitya57, ScottK i'll take a look in a little while
[14:58] <achiang> mlankhorst: damn, let me check
[14:58] <achiang> mlankhorst: all of revu is down
[14:58] <mlankhorst> achiang: are those diffs available from version control somewhere, or just those diffs?
[15:00] <bluefoxxx> Gentlemen
[15:00] <bluefoxxx> The installer is capable of utilizing LVM.
[15:01] <bluefoxxx> Would it be outrageous to modify the installer such that it automatically partitions 0.25% of the LVM physical volume free, and recommends such if a user manually partitions with LVM?
[15:01] <achiang> mlankhorst: just have the diffs, sorry
[15:01] <bluefoxxx> sorry
[15:02] <bluefoxxx> somethnig I am doing wrong.  10TB should give 250GB... 1TB should give 25GB or 0.025TB ... .1TB is 10%... .01TB ... so 2.5%
[15:02] <mlankhorst> ah no worries, it's usually easier with version control, debian maintains it in git afaict, not sure about ubuntu
[15:02] <bluefoxxx> I do not think that is unreasonable.
[15:03] <bluefoxxx> in any case
[15:03] <bluefoxxx> All partitions formatted in the LVM would be configured to be fscked once per 180 days
[15:03] <achiang> mlankhorst: i can upload the *.dsc, etc. somewhere else
[15:03] <bluefoxxx> once per week, each drive would be snapshotted onto the free space in the LVM PV
[15:03] <bluefoxxx> the snapshot would be fscked
[15:04] <bluefoxxx> if clean, then the volume would be marked as recently fscked
[15:04] <bluefoxxx> i.e. tune2fs -T 0
[15:04] <mlankhorst> achiang: no those are available, I'm just looking into the source repository atm :)
[15:04] <bluefoxxx> otherwise an alert would be set and the drive scheduled for fsck.  The administrator could request read-only remount, online fsck.
[15:04] <bluefoxxx> in this way, periodic fsck of clean file system could be accomplished without associated down time
[15:05] <bluefoxxx> tune2fs -T now rather
[15:11] <mlankhorst> achiang: overall looks ok to me, but I don't have any familiarity with remmina
[15:16] <mlankhorst> achiang: also I don't have upload rights, so I can't actually sponsor the upload for you :(
[15:17] <Laney> I'll take a look at remmina
[15:17] <Laney> the two diffs are fine (infact, preferred) to sponsor it
[15:18] <mlankhorst> thanks Laney
[15:22] <achiang> Laney: mlankhorst thanks!
[15:28] <dobey> can someone take a poke at my patch in bug #859600 ? i think it's better than the previously attached patches, but would be nice to get it reviewed/included
[15:29] <dobey> (and pushed into debian if anyone could do so)
[15:54] <hallyn> is it ever 'done' to have a 'README.Ubuntu' under debian/ ?  Or do we, if no README.Debian exists, create that?
[15:57] <Laney> achiang: I think you need a Breaks/Replaces for remmina-common that used to contain the desktop file
[15:57] <hallyn> i'll make README.Debian.  will need to suggest they ship it too, anyway
[15:58] <slangasek> smb: if the binary package you have converted to multiarch is usefully installable by itself, then sure
[15:59] <achiang> Laney: ah, interesting. ok, thanks
[16:00] <Laney> perhaps just Breaks (to help the upgrade order)
[16:02] <Laney> achiang: No need for you to update it - I'll do that before uploading
[16:06] <achiang> Laney: great, thanks!
[16:08] <highvoltage> where could I get an ubuntu phone image?
[16:10] <Laney> http://www.ubuntu.com/static/u/img/devices/phone-home-industry-269x192.jpg
 - they aren't available yet but I heard late Feb (also #ubuntu-phone)
[16:11] <highvoltage> Laney: ah ok
[16:14] <xnox> highvoltage: pick your fancy from all of them http://www.ubuntu.com/static/u/img/devices/
[16:14]  * xnox likes
[16:14] <xnox> http://www.ubuntu.com/static/u/img/devices/phone-app-hero-420x338.jpg
[16:15] <arges> : )
[16:18] <highvoltage> on a slightly related note. I reflashed my Atrix with Cyanogenmod and lost the default Ubuntu 9.04 installation that it came with. Where could I get Ubuntu for Android?
[16:20] <xnox> highvoltage: there is no download yet.
[16:20] <highvoltage> xnox: but it's been existing for so long!
[16:21] <highvoltage> xnox: who's actually working on it? could I ask someone for an image?
[16:21]  * xnox didn't know highvoltage is a phone manufacturer =)
[16:22]  * highvoltage didn't know that you had to be in order to get ubuntu
[16:23] <dobey> xnox: i've actually been pondering just making my own phone actually. :)
[16:29] <stgraber> highvoltage: I can give you a tarball of the osh partition (the default 0.94 system) on my Atrix, mine didn't get wiped with the reflash
[16:30] <highvoltage> stgraber: I'm going to try to follow http://fooprotected.wordpress.com/2012/04/02/debian-on-androidatrix-with-debootstrap/ to get a more recent version than 9.04 running. then at least I can share it for others who'd like to do the same
[16:33] <stgraber> highvoltage: you won't be able to get a terribly recent userspace on the atrix because of the kernel version
[16:34] <stgraber> highvoltage: 10.04 chroot/containers work pretty well here, but anything more recent was met with a lot of crashes because of missing/broken syscalls in the android kernel
[16:45] <highvoltage> stgraber: ah right :-/
[16:47] <smoser> slangasek, around ?
[16:48] <smoser> who do i need to talk to to get bug 1100491 into -updates
[16:48] <smoser> its not sat for 7 days in -proposed, but we have a broken update in -updates and this fixes that.
[16:50]  * cjwatson double-reviews
[16:51] <cjwatson> smoser: I've waived the waiting period; it's on its way into -updates now.
[16:52] <jamespage> \o/
[16:52] <smoser> thank you.
[16:52] <smoser> sorry for suck.
[16:55] <smoser> utlemming, can you spin a precise-daily build once cloud-init 0.6.3-0ubuntu1.4 is in -updates ? the latest daily has the broken version and want to stop people from getting that even if they're using dailies.
[17:18] <roaksoax> cjwatson: howdy!! I was wondering if you could take a look to: bug #1092265
[17:18] <roaksoax> thihs is really an issue with syslinux
[17:20] <cjwatson> roaksoax: sorry, pretty overloaded
[17:20] <cjwatson> roaksoax: as you can see we've got back in sync with Debian so I haven't actually touched syslinux in some time anyway
[17:21] <roaksoax> cjwatson: ack! thanks though :)
[17:21] <cjwatson> I'd probably suggest starting by looking through changes to chain.c32's source in upstream git
[17:22] <roaksoax> cjwatson: will do! thanks! :)
[17:22] <cjwatson> though chain has hardly changed in quite a whwile
[17:23] <smb> slangasek, I guess, though I would need to throw it over the fence to someone else who has an environment for using that. Though basically it is only one subpackage that only provides libraries (and has done before). Its less clear with some language interface package which then have a perl/ruby/python binding plus an .so part. So following thatis it enough to not have any multi-arch keywords on the other packages in the control file to say tho
[17:23] <smb> se aren't ready (yet)
[17:24] <roaksoax> yeah /win 13
[17:24] <roaksoax> err
[17:32] <mlankhorst> @pilot out
[17:39] <infinity> @pilot in
[17:44] <mcclurmc> hi infinity. i submitted a but report and a patch this morning for indicator-weather: https://bugs.launchpad.net/indicator-weather/+bug/1100680
[17:44] <mcclurmc> any chance this could get looked at?
[17:46] <slangasek> smb: can you point me at specifics?
[17:49] <smb> slangasek, I can. Though I think it also makes sense to take this into email where I can add a bit more info. But I think I won't get to that till tomorrow.
[17:51] <slangasek> smb: ok :)
[18:06] <bjf> slangasek, i had the following line in my /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT=initcall_debug quiet printk.time=1
[18:06] <bjf> slangasek, because of that, i was getting failures in /usr/sbin/grub-mkconfig:  /etc/default/grub: quiet: not found
[18:07] <bjf> slangasek, this was preventing an update of the kernel package. i changed it to just "GRUB_CMDLINE_LINUX_DEFAULT= quiet"
[18:08] <bjf> slangasek, that fixed my issue
[18:08] <cjwatson> bjf: You need to quote that
[18:08] <cjwatson> GRUB_CMDLINE_LINUX_DEFAULT="initcall_debug quiet printk.time=1"
[18:08] <bjf> cjwatson, ah!
[18:08] <bjf> cjwatson, thanks
[18:08] <cjwatson> de nada
[18:09] <infinity> mcclurmc: I can have a poke.
[18:10] <mcclurmc> thanks infinity. it's nothing critical, but it'd be good to get it merged
[18:31] <bdmurray> tkamppeter_: the cups upload in the quantal -proposed queue will prevent all apport crash reports regarding cups which seems rather heavy handed
[18:34] <BenC> cjwatson: I'm not sure where it needs to go, but msdos is the default filesystem for the e500* systems (right now, it claims ignorance)
[18:34] <BenC> s/filesystem/partition-map/
[18:35] <infinity> BenC: That's true for IBM machines too.  Is there some broken assumption somewhere?
[18:35] <BenC> infinity: the installer just says "we don't know what to do, so you guess and if it's wrong, well then, it's not my fault"
[18:36] <BenC> It's not that I can't select it on my own, just wondering where to stick in a default for reasons
[18:36] <BenC> e500* doesn't match powermac/pseries, which I believe are the only two sub-archs it knows about partition-wise
[18:37] <BenC> and of course ps3, but that's not really in existence anymore
[18:39] <infinity> BenC: Does archdetect already know about your machine?
[18:39] <BenC> Yeah, it selects the correct kernel
[18:39] <infinity> BenC: So, it's just a question of partman-$whatever getting smarter?
[18:39] <BenC> Right, whatever udeb devices on the default partition map
[18:39] <BenC> *decides
[18:40] <infinity> BenC: Any idea what the exact string is? :P
[18:40] <infinity> (The error string)
[18:41] <BenC> One moment while I look that up for you sir...
[18:41] <BenC> My fiancé's customer service job is rubbing off on my online etiquette
[18:42] <infinity> Oh, think I may have found it.
[18:42] <infinity> BenC: What does archdetect return on your two platforms?
[18:43] <BenC> One other bug I have is that the cdrom-detect isn't detecting things too well in qemu with a media=cdrom virtio-blk device
[18:43] <BenC> infinity: e500mc and e500 as subarch
[18:43] <infinity> Did you really need two, you greedy, greedy man? :P
[18:43] <BenC> infinity: Actually, nm, it's not
[18:44] <BenC> Showing powerpc/unknown
[18:44] <infinity> Oh.  Right, then fix archdetect first.
[18:44] <infinity> Since everything else keys off that.
[18:45] <BenC> infinity: I might just make it powerpc/sgy
[18:45] <BenC> Since a lot of stuff is specific to our system (grub, partition map)
[18:46] <infinity> BenC: Once archdetect does something sane (FSVO sane), your partition map type fix would be in lib/disk-label.sh in partman-partitioning
[18:46] <BenC> infinity: Thanks
[18:46] <infinity> BenC: Feel free to fix yourself, but ping someone (like me, Colin, or xnox) perhaps for a quickie review, and see about getting it committed upstream too (which at least two of us can do, maybe all three of us)
[18:47] <xnox> all three =)
[18:50] <infinity> BenC: On a side note, MSDOS, really?  On a brand new platform, why not go GPT from the start and future-proof for larger disks?
[18:50] <infinity> (Or would that have required adding GPT support to u-boot?)
[18:50] <BenC> infinity: It will work with GPT…doesn't bother me any at all
[18:51] <BenC> No, just enabling it in our firmware linux-kernel
[18:51] <infinity> BenC: Just a suggestion, since sticking some future developer (or yourself) with remembering all the places where msdos is hardcoded the day you decide to ship systems with >2TB drives could be irksome. :)
[18:51] <BenC> infinity: I don't see GPT in linux's partition map selection
[18:52] <BenC> LDM, OSF, KARMA?
[18:52] <infinity> BenC: Given that it's default on ia64 and EFI systems, I can only assume the kernel supports it a little bit...
[18:53] <infinity> Though, no idea what CONFIG_ twiddle makes it happen.
[18:55] <infinity> Oh, actually, partman just silently forces gpt over msdos on large disks anyway.
[18:55] <infinity> I guess we assume all OUR kernels and bootloaders can deal with that.
[18:55] <infinity> (Which I'm betting not all of them can... I know the openfirmware on one of my machines sure can't)
[18:56] <BenC> infinity: it's EFI, supports GUID GPT partitions
[18:56] <BenC> I already have that enabled in our firmware kernel, so I'll use that as default on installer
[19:01] <infinity> BenC: You may want to double-check that all works with a manual install/reboot cycle on GPT before committing, but it just makes sense to me to future-proof the platform now rather than panic later when someone ships a big disk/array/whatever.
[19:01] <BenC> Makes more sense to me too
[19:16] <BenC> infinity: I just added two lines to the map_platform[] array to produce powerpc/fsl which will work on bare metal and qemu on this platform
[19:16] <BenC> Ok to upload that?
[19:17] <infinity> BenC: debdiff *dsc | pastebinit -f diff
[19:18] <infinity> BenC: Just to have a quick look for myself.  Also, "fsl" makes it sound freescale-generic, which is probably a lie, no?
[19:18] <BenC> http://paste.ubuntu.com/1542331/
[19:19] <infinity> (Given that PegasOS and others are also freescale)
[19:19] <BenC> infinity: They won't match at this point though
[19:19] <BenC> I just can't make it servergy specific, because it works in qemu, and that has a generic /proc/cpuinfo
[19:20] <infinity> Yeah, fair enough.  Go nuts.
[19:20] <BenC> I'm going on making it generic and if some freescale based platform needs something more specific, they will need to add the extra bits
[19:24] <infinity> BenC: Well, I assume that first one is your hardware specifically, and the second is generic, right?
[19:24] <BenC> Right
[19:24] <BenC> Actually, no
[19:25] <infinity> BenC: You could follow the chrp/chrp_ibm example and have fsl/fsl_sgy and just make them both do the same thing for now.
[19:25] <BenC> P4080 DS is generic fsl platform
[19:25] <infinity> Oh, they're both generic?  Kay.
[19:25] <BenC> I'd have to detect also the model to get down to something servergy specific
[19:25] <infinity> I guess if you're the only ones that match this for now, that works.
[19:25] <BenC> platform	: P4080 DS
[19:25] <BenC> model		: servergy,jade-rev3
[19:25] <infinity> Just might need some re-engineering if someone else bases a wildly different platform on the same chip later, I guess.
[19:26] <BenC> Which at this point is an unknown, so I'll hope that we set the standard for anyone else coming along :)
[19:27] <BenC> infinity: http://paste.ubuntu.com/1542349/
[19:28] <BenC> Now to figure out why cdrom-detect chokes on virtio-blk cdroms
[19:31] <infinity> BenC: Both those diffs look fine, then.  Assuming you've done a manual test and your platform actually boots. ;)
[19:32] <BenC> infinity: It does…even if I broke it to high-hell, no one would notice but me at this point :)
[19:33] <infinity> Heh.
[19:47] <jbicha_> cjwatson: can we drop the pcsc-lite diff now? http://bugs.debian.org/531592 has been marked fixed for a while
[19:48] <cjwatson> jbicha_: I disagree with their solution
[19:49] <cjwatson> jbicha_: It means that if you have /usr as a separate partition then you get random behaviour depending on whether wpa_supplicant happens to try to start before or after /usr
[19:49] <Logan_> Laney: Gah, so sorry. I'm running a test build of the ghc from Experimental right now, as, after attempting a merge, I found that the only delta (an Ubuntu patch) was applied upstream. If it builds successfully (and installs successfully, of course!), I'll file a sync request and link to it in the haskell-devscripts merge.
[19:50] <cjwatson> jbicha_: Once https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-usr-merge is implemented then it can be dropped; I don't think it should be dropped before then
[19:50] <Logan_> micahg: and my apologies to you as well
[19:53] <jbicha_> I didn't think we supported /usr on a separate partition, thanks for looking at it though
[19:53] <cjwatson> We always hav
[19:53] <cjwatson> e
[19:53] <cjwatson> Or at least have tried to
[19:54] <cjwatson> usr-merge will certainly make life simpler but I don't think we should knowingly break stuff in advance of it landing
[19:58] <infinity> cjwatson: I suppose that whole spec doesn't need implementing for people to stop caring, just the initramfs early-usr-mounting bit.  I should review a bunch of the competing bits in the BTS for that and commit something sane to Debian git and raring.
[19:58] <cjwatson> Indeed
[19:59] <cjwatson> The symlink farm stuff is rather riskier
[19:59] <cjwatson> (And I think a bit scary, actually)
[19:59] <micahg> Logan_: well, we try to do the ghc merge/world rebuild just once per cycle if we can get away with, so, you probably want to coordinate with Laney on that
[20:01] <cjwatson> infinity: doesn't bug 1065827 need a precise task?
[20:02] <cjwatson> infinity: (just for bcmwl, not for casper)
[20:08] <infinity> cjwatson: Oh, indeed.
[20:11] <infinity> cjwatson: I was so excited that the package otherwise passed my review on this round, I forgot to check all the bug tasks.  Fixed now.
[20:35] <tion> will new xorg and nvidia-current updates break opengl on my box? i have nvidia FX5200 card. Currently I'm using the 173 driver and opengl is working fine
[20:40] <xnox> mlankhorst: tjaalton: see tion ^
[20:40] <xnox> not sure who does nvidia though.
[20:41] <tion> i installed the current driver before. opengl was broken so i reinstalled the 173 driver should i skip the updates?
[20:44] <mlankhorst> not that I'm aware of?
[21:01] <tjaalton> tion: on what? the update adds support for xserver 1.13, so unless you're on precise you haven't actually used the driver AIUI
[21:18] <dkessel> hey guys. i'm having graphics flickering in the dash since today on raring. i have this card: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML
[21:23] <dkessel> can i do anything to help debug?
[21:26] <tjaalton> dkessel:
[21:26] <tjaalton> http://wiki.ubuntu.com/X/Testing/IntelSNA
[21:27] <tjaalton> check if you see it with sna
[21:29] <dkessel> tjaalton: ok, will do :) thanks
[21:32] <tjaalton> dkessel: actually, check your xorg logfile
[21:33] <tjaalton> nevermind
[21:33] <dkessel> tjaalton, shall i try the xorg.conf from the wiki or not?
[21:34] <tjaalton> yes
[21:37] <infinity> Ooo, new xserver-xorg-video-intel?  I wonder how this can break my laptop today. :)
[21:37] <tjaalton> probably does nothing much :)
[21:38] <bdmurray> hallyn: I think the testcase in bug 1096771 is not for that bug
[21:38] <infinity> tjaalton: So, won't fix my hang?  Sadface.
[21:38] <infinity> BenC: Oh, BTW.    You're missing a build-dep on openssl in linux-ppc.
[21:39] <infinity> BenC: This'll become painfully obvious when I remove openssl from the buildd chroots, since it's not meant to be there. :P
[21:39] <infinity> BenC: (You might want to compare your build-dep line with master, didn't bother to see if you're otherwise in sync)
[21:40] <hallyn> bdmurray: why?
[21:40] <dkessel> tjaalton, still flickering. xorg.log says: (II) intel(0): SNA initialized with gen3 backend
[21:40] <tjaalton> infinity: I doubt it, but it has ~90 sna related commits
[21:41] <tjaalton> dkessel: and you're on raring?
[21:41] <hallyn> bdmurray: the bug is that when libcgroup gets updated, its initscripts are not properly removed.
[21:41] <dkessel> yup, raring
[21:41] <hallyn> so the test is to reinstall the version with initscripts, upgrade to the testing version, and check whether they were removed
[21:41] <tjaalton> dkessel: ok, so please file a bug with 'ubuntu-bug xorg'
[21:41] <tjaalton> dkessel: first verify you have xdiagnose installed
[21:41] <dkessel> tjaalton: ok thanks
[21:41] <hallyn> though i'd believe that i was saying or doing something stupid...
[21:44] <tjaalton> dkessel: you ran raring before today too?
[21:45] <tjaalton> dkessel: if you happen to have the old version of xserver-xorg-video-intel in /var/cache/apt/archives, mind giving it a go?
[21:45] <dkessel> well, ony this machine only a few days. could be that i missed the flickering due to using terminal to install stuff and so..
[21:45] <dkessel> tjaalton, sure, i can do... finishing the initial bug report first
[21:46] <tjaalton> thanks
[21:49] <dkessel> bug 1100970
[21:50] <dkessel> tjaalton, no old version there... bad luck
[21:51] <tjaalton> dkessel: ok, and running i386 so none here either
[21:52] <infinity> https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.20.16-0ubuntu1
[21:52] <infinity> https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/2:2.20.17-0ubuntu1
[21:52] <tjaalton> heh, thanks
[21:52] <infinity> Poke one of those for a previous version to try.
[21:54]  * xnox is puzzeled at https://launchpad.net/ubuntu/+source/openvswitch/1.9.0~git20130115.ca71f5b-0ubuntu2 FTBFS on powerpc, when it's no-code change upload.
[21:56] <dkessel> hm, do i just dpkg -i one of those?
[21:57] <dkessel> nevermind, i did :)
[22:04] <dkessel> tjaalton, i tried .17, .16 and .9. nothing changes
[22:06] <tjaalton> dkessel: ok, thanks
[22:07] <infinity> xnox: Random bogons, or a build-dep broke?
[22:08] <xnox> infinity: 1 test suite failure, and very cryptic. I could retry... to see what happens, but maybe when the build queue is smaller.
[22:08] <infinity> xnox: The queue is only an hour.  Just give it a whack.
[22:11] <dkessel> tjaalton, i'll leave it for today and turn off the machine. if there will be any more instructions added in the bug report, i will try it if i can. thanks so far
[22:11] <tjaalton> dkessel: one more thing, did you have the xorg.conf there when testing the older versions?
[22:12] <dkessel> oh... yes i still have it
[22:13] <tjaalton> might try without it and post the results
[22:13] <xnox> infinity: can you let me in on a secret of app-install-data-partner package?
[22:13] <bdmurray> cyphermox: is bug 1055497 fixed in raring?
[22:14] <infinity> xnox: Which secret would that be?
[22:16] <xnox> infinity: how to regenerate it. There is currently a UDD merge proposal for it.
[22:16] <xnox> https://code.launchpad.net/~baltix/ubuntu/precise/app-install-data-partner/fix-for-missing-applications-flashplugin-skype/+merge/134402
[22:16] <xnox> yet it removed ~ubuntu-core-dev/app-install-data-commercial/trunk from the vcs-bzr field.
[22:19] <infinity> xnox: Ahh, hrm.  To be fair, I'm not hugely familiar with the inner workings.  mvo might be a better person to review that.
[22:21] <BenC> infinity: Ok
[22:22] <BenC> infinity: What is it that detects the kernel flavor to use in the installer? I need to make sure it wasn't expecting powerpc/unknown
[22:22] <xnox> well pitti did some work on it as well.
[22:23] <xnox> pitti: how does one work with app-install-data-partner?
[22:23] <infinity> BenC: base-installer.
[22:23] <BenC> Thanks
[22:23] <infinity> BenC: But it does it based on cpuinfo.
[22:23] <BenC> I seem to remember it calling archdetect
[22:23] <BenC> But I could be misremembering
[22:24] <infinity> Err.  Not cpuinfo as in /proc/cpuinfo, though...
[22:24] <BenC> You're correct though, it uses /proc/cpuinfo
[22:25] <BenC> SUBARCH="$(archdetect)"
[22:25] <BenC> SUBARCH="${SUBARCH#*/}"
[22:25] <infinity> Oh, yeah, it's /proc/cpuinfo.
[22:25] <BenC> Well, sort of
[22:25] <infinity> archdetect for subarch, yeah.
[22:25] <infinity> But you're ignoring that right now.
[22:25] <BenC> For kernel selection, it needs to use /proc/cpuinfo regardless
[22:25] <BenC> Right
[22:30] <jackyalcine> Where do I go to diagonise problems with Launchpad and PPAs?
[22:30]  * jackyalcine checks #launchpad in the meanwhile
[22:30] <Laney> #launchpad
[22:35] <cyphermox> bdmurray: yeah, bug 1055497 is fixed in raring
[22:37] <jackyalcine> Thanks Laney, but you know of a mailing list I can use?
[22:38] <cjwatson> BenC: kernel selection should at least *involve* the output of archdetect, even if sometimes refined by cpuinfo
[22:38] <BenC> cjwatson: it uses the powerpc part, but not the /* part
[22:39] <BenC> It's completely irrelevant…if the CPU is e500 or e500mc, it has to use those kernels
[22:39] <cjwatson> oh, e500/e500mc is irregular there
[22:39] <cjwatson> anyway, I should've noticed the lack of support in libdebian-installer
[22:40] <cjwatson> it would've been clearer to do things in terms of subarch and have *that* detected from cpuinfo, but no matter


[08:57] <kim0> Morning everyone o/
[14:34] <niemeyer> Hello all!
[14:35] <niemeyer> We're headed to a good week
[14:40] <kim0> Hey there
[14:42] <niemeyer> kim0: Hi
[14:46] <kim0> niemeyer: Hi
[14:47] <kim0> any particular reason this week will rock :)
[14:48] <niemeyer> kim0: Many!  We're all back from UDS now, have relevant stuff in review, have to plan our next sprint, and a lot more.
[14:54] <kim0> woohoo :) yeah
[15:02] <niemeyer> ah, we also got properly updating info on ensemble.ubuntu.com
[15:55]  * hazmat yawns
[15:55] <niemeyer> hazmat!
[15:55] <niemeyer> hazmat: Rested/relaxed/ready to rock?
[15:55]  * niemeyer gives an early morning shock on hazmat
[15:56] <hazmat> niemeyer! indeed. relaxed and rested.. budapest was awesome.. time to rock
[15:56]  * hazmat caffienates anyways
[15:56] <niemeyer> hazmat: Did you spend all the time there?
[15:57] <niemeyer> hazmat: Or went around to other close-by attractions?
[15:57] <niemeyer> hazmat: I still owe you a review, but not for long
[15:58] <hazmat> niemeyer, no we did some day trips.. one to this artist commune/town that jim mentioned.. some slow days ( i ended up getting an eye infection so we relaxed for a day or two).. but walked about 6-7 hrs each day around the town, and hit some local spots
[15:58] <niemeyer> hazmat: Ouch/nice :)
[15:59] <hazmat> all the bridges, synagogues, basicalla, island, and the hot public baths of course. its a nice town, very pictureseque... picked up lots of gifts for family etc.
[15:59] <niemeyer> hazmat: Neat
[15:59] <niemeyer> hazmat: I wish I had gone to the public baths
[15:59] <hazmat> its strange to consider how short of a time ago it was a police state
[15:59] <niemeyer> hazmat: Sounds awesome
[16:00] <niemeyer> hazmat: When did it change?
[16:00] <hazmat> niemeyer, roughly 89-91
[16:00] <hazmat> we checked out the house of terror which cover wwII and soviet occupation, pretty disturbing stuff
[16:00] <hazmat> i hope we end up doing UDS there next year.
[16:03] <hazmat> niemeyer, anything interesting from the last week?
[16:04] <niemeyer> hazmat: Well, Brazil only had direct elections after 83/84
[16:05] <niemeyer> hazmat: A lot has been happening
[16:05] <niemeyer> hazmat: But it was kind of a slow week in terms of development
[16:06] <niemeyer> hazmat: Jim was off pretty much all of it
[16:06] <niemeyer> hazmat: Ben was sick for a good while
[16:06] <niemeyer> hazmat:  I've managed to do some reviewing, and pushed the lpad package to a reasonable state
[16:07] <niemeyer> hazmat: Some good conversations around Launchpad =
[16:07] <niemeyer> s/=//
[16:07] <niemeyer> hazmat: a few interviews
[16:07] <hazmat> niemeyer, nice.. anything promising on the candidates?
[16:08] <niemeyer> hazmat: This week I plan to start with reviews, and then will start implementing formula/parsing/building for the repo
[16:08] <niemeyer> hazmat: Some great candidates, yeah
[16:09] <hazmat> niemeyer, cool, i'm gonna catch up on emails and pickup some of the branches from review
[16:10] <niemeyer> hazmat: The most important one from you is still there.. I'll start with this one after lunch
[16:11] <hazmat> niemeyer, sounds good
[17:09] <_mup_> Bug #787069 was filed: Expose needs to track the service hierarchy  <Ensemble:In Progress by jimbaker> < https://launchpad.net/bugs/787069 >
[17:49] <_mup_> ensemble/expose-provision-service-hierarchy r233 committed by<EMAIL_ADDRESS>[17:49] <_mup_> Observe service units watching
[17:52] <_mup_> ensemble/expose-provision-service-hierarchy r234 committed by<EMAIL_ADDRESS>[17:52] <_mup_> Merged upstream expose-service-watch
[17:53] <_mup_> ensemble/expose-service-watch r233 committed by<EMAIL_ADDRESS>[17:53] <_mup_> Merged trunk
[17:53] <_mup_> ensemble/expose-provision-service-hierarchy r235 committed by<EMAIL_ADDRESS>[17:53] <_mup_> Merged upstream expose-service-watch trunk changes
[18:45] <negronjl> hi all.  I am in the process of porting the hadoop orchestra module to ensembe but have some questions.  Anyone able to help me ?  The question that I have is how to have ensemble remember some values that are needed for future use ( analogous to puppet exported resources ).
[18:46] <negronjl> In hadoop.  The namenode, jobtracker and hdfsdatadir are values ( all strings ) that need to be saved. so, when we deploy a hadoop-slave node, we can preconfigure those values and have the node automagically connect to the master
[18:46] <negronjl> If this is the wrong forum for this, by all means let me know.
[18:54] <niemeyer> negronjl: Hey!
[18:54] <negronjl> hi niemeyer
[18:54] <niemeyer> negronjl: This is the right forum
[18:54] <niemeyer> negronjl: The mailing list is also good, but less interactive :)
[18:54] <negronjl> I thought so.
[18:55] <niemeyer> negronjl: The model of Ensemble is slightly different
[18:55] <niemeyer> negronjl: Rather than configuring arbitrary variables with the address of the job tracker, for instance, you actually put the job tracker in a formula, and deploy it as a service
[18:56] <niemeyer> negronjl: Then, the slaves can declare a relation with a given interface (e.g. "hadoop-jobtracker" sounds like a good name for this case)
[18:56] <niemeyer> negronjl: With that in place, users can simply ask the node to be connected to this job tracker..
[18:56] <niemeyer> negronjl: E.g.
[18:56] <niemeyer> ensemble deploy hadoop-jobtracker
[18:57] <niemeyer> ensemble deploy hadoop-slave
[18:57] <niemeyer> ensemble add-relation hadoop-jobtracker hadoop-slave
[18:57] <negronjl> I se
[18:57] <niemeyer> negronjl: Of course, you can have several trackers, slaves, etc
[18:57] <negronjl> I see
[18:57] <niemeyer> negronjl: and can also name them differently
[18:57] <niemeyer> negronjl: E.g.
[18:57] <niemeyer> ensemble add-relation hadoop-jobtracker production-jobtracker
[18:57] <niemeyer> Erm
[18:57] <niemeyer> ensemble deploy hadoop-jobtracker production-jobtracker
[18:58] <niemeyer> negronjl: So you can have multiple "instances" of the same formula deployed
[18:58] <niemeyer> negronjl: If you code the formula the proper way, you can also have multiple service units of the same formula.
[18:58] <niemeyer> negronjl: Which means you might do something like this:
[18:58] <niemeyer> ensemble add-unit hadoop-slave
[18:59] <niemeyer> negronjl: and this would spawn a new machine, and connect to the proper job tracker, etc, automatically
[18:59] <negronjl> how does the slave know to which master to connect to?   is it all based on the relationships?
[19:00] <niemeyer> negronjl: Precisely
[19:00] <niemeyer> negronjl: Because you said earlier that you wanted hadoop-slave to be connected to hadoop-jobtracker, for instance
[19:00] <negronjl> got it.  I have the basic hadoop-master configured already.  I'll play with this for the day and see if I can get the slave to work.
[19:00] <niemeyer> negronjl: Then, *all* units of that service will know what other services they are supposed to be talking to
[19:01] <niemeyer> negronjl: That's awesome.. we'll be around if you need any help
[19:01] <niemeyer> negronjl: The examples formulas next to the source code and the principia project in Launchpad may provide some hints about how that stuff may be put together
[19:01] <niemeyer> negronjl: The documentation may also be helpful (link in the channel topic)
[19:01] <niemeyer> negronjl: But again, just ping us in case you have questoins
[19:02] <negronjl> I will document the process and what I am trying to do.  I will then send the formula and all of it's documentation to you guys.  This way you will not only see the formula but will be ble to see what I am "trying" to do.
[19:02] <negronjl> perfect!
[19:02] <negronjl> thanks for the help.
[19:02] <negronjl> I'll keep you up to date on the progress
[19:05] <niemeyer> negronjl: Sweet, thank you
[19:05] <negronjl> niemeyer:  np
[19:09] <niemeyer> I'm going to take a walk outside for half an hour or so to try to switch myself into review mode.
[19:10] <niemeyer> brb
[19:11]  * hazmat catches up
[19:12] <jimbaker> sounds like a good idea, a good application of neuroscience
[19:12] <jimbaker> ;)
[19:22] <_mup_> ensemble/expose-provision-service-hierarchy r236 committed by<EMAIL_ADDRESS>[19:22] <_mup_> Observer on _watched_services makes much more sense
[19:33]  * niemeyer is back
[19:57] <jimbaker> back in 10 min
[20:08] <koolhead17> hi al
[20:08] <koolhead17> l
[20:11] <jimbaker> koolhead17, HI
[20:12] <jimbaker> cap locks on and all :)
[20:12] <koolhead17> hehe jimbaker :)
[20:12] <koolhead17> niemeyer: kim0 hello :)
[20:12] <koolhead17> obino: hi :)
[20:35] <robbiew> bcsaller: any interest in http://www.cloudcamp.org/sf/2011-05-26  ?
[20:35] <robbiew> preaching the gospel??
[20:35] <robbiew> of ensemble :P
[20:36] <bcsaller> robbiew: sounds like a good idea
[20:40] <bcsaller> robbiew: I'll register and go promote
[20:40] <robbiew> bcsaller: sweet
[21:33]  * niemeyer => coffee
[21:33] <niemeyer> Btw, i don't understand why Launchpad sometimes decides to show conflicts in the merge proposal.. e.g.:
[21:33] <niemeyer> https://code.launchpad.net/~bcsaller/ensemble/config-set/+merge/60235
[21:33] <niemeyer> Checking out the branch and asking for the diff doesn't show any conflicts
[21:34] <niemeyer> Anyway.. coffee
[21:34] <bcsaller> yeah, I see strangeness sometimes too
[22:55] <negronjl> where are you guys getting python-txzookeeper from?  any ppa available?
[22:59] <niemeyer> negronjl: Hmmm
[22:59] <niemeyer> negronjl: Yeah, I think it should be in the Ensemble PPA
[22:59]  * niemeyer checks
[23:00] <niemeyer> It is indeed
[23:00] <negronjl> niemeyer:  I saw something there for lucid but nothing for natty
[23:00] <niemeyer> negronjl: https://launchpad.net/~ensemble/+archive/ppa
[23:00] <niemeyer> Oh
[23:01] <niemeyer> negronjl: Sorry about that.. I have some due work to do on our PPA
[23:01] <niemeyer> negronjl: I hope to work it this week or on the next one the latest
[23:01] <negronjl> no worries.  I'll work with a lucid VM for now
[23:01] <niemeyer> negronjl: Meanwhile, you can easily grab the code with bzr branch lp:txzookeeper
[23:01] <negronjl> even better :)
[23:01] <niemeyer> negronjl: Might be easier to just grab the code there
[23:02] <negronjl> perfect!  Thanks.
[23:02] <niemeyer> negronjl: My goal is that by the end of next week you can do "apt-get install ensemble" and move on
[23:02] <niemeyer> negronjl: I hope I get to it before then, though
[23:02] <negronjl> cool.
[23:48] <niemeyer> I'm stepping out.. may be back later


[05:12] <hallyn> bah - so i can use /etc/default/keymap to set capslock as control in *console*, but unity8 still resets it to capslock :(
[05:36] <RAOF> hallyn: Urgh. Yeah, we don't read that properly at the moment. U8 isn't friendly to keyboards that aren't qwerty en_US.
[05:43] <hallyn> RAOF: drat, that's a bit of a blocker to getting serious work done in unity8
[05:44] <RAOF> Yes; particularly for me, as I use a dvorak keymap.
[05:44] <RAOF> So it's just plain wrong.
[05:44] <RAOF> https://bugs.launchpad.net/mir/+bug/1570340
[05:44] <ubot5`> Launchpad bug 1570340 in Canonical System Image "Mir should read default keymap from udev properties." [Medium,Confirmed]
[05:44] <hallyn> oh that reminds me i need to add a comment to the webbrowser-app crashing bug
[05:44] <hallyn> RAOF: ouch :)
[05:44] <RAOF> If you'd like to fix it yourself, it probably wouldn't be *that* hard. I could mentor you!
[12:48] <Mirv> kdub: kgunn: related to https://code.launchpad.net/~kdub/mir/avert-1563287/+merge/292298 Turbo also has Mali, or have you tested there's such a difference between T720 and T760?
[12:49] <Mirv> all our shipping or soon to be shipping devices have Mali.
[12:51] <kgunn> Mirv: we only have like 3 turbos among us, i do think kdub has one?
[12:51] <kdub> no
[12:51] <kdub> we can add the turbo name to that list, if that's what's being asked
[12:52] <kgunn> kdub: really?!?
[12:52] <kdub> I'll probably just change to a whitelist for adreno instead of a blacklist
[12:52]  * kgunn knows he asked
[12:53] <kdub> oh, I don't want one :)
[12:53] <kgunn> kdub: pvr ?
[12:53] <kgunn> ;)
[12:53] <kgunn> kdub: can you blacklist mali midgard
[12:53] <kgunn> ?
[12:53] <kgunn> rather than device
[12:53] <kgunn> just gpu
[12:53] <kdub> not yet
[12:53] <kdub> there's a card about it
[12:54] <kgunn> ? i feel like i've done this
[12:54] <kgunn> with a pvr quirk
[12:54] <kdub> we have a quirk system, but its config file + device name
[12:57] <Mirv> ok, thanks :)
[12:57] <kdub> Mirv, do you have a turbo?
[12:58] <Mirv> kdub: no :(
[12:59] <Mirv> they are hard to get so far, but that should of course change once they start to be sold
[12:59] <kdub> great, we developers can fix it then
[12:59] <kdub> ;)
[13:05] <kgunn> kdub: mzanetti and Saviq have one
[13:06] <Saviq> what up?
[13:06] <kdub> Saviq, if you do getprop ro.product.device is the string "turbo" ?
[13:06] <kdub> we're trying to anticipate further 'quirks' for that device
[13:09] <Saviq> kdub, yes
[13:09] <Saviq> $ getprop ro.product.device
[13:09] <Saviq> turbo
[13:09] <kdub> thanks Saviq
[19:34] <Saviq> hi all, can anyone point me to where is the virtual output for WiFi display created? We've been (temporarily, possibly wrongly) assuming that LVDS is our internal screen (that's the case on all hour hardware devices), but now WiFi Display says it's LVDS also, and that's breaking some scaling logic
[19:46] <AlbertA> Saviq: it is in
[19:46] <AlbertA> Saviq:  <mir>/src/platforms/android/server/display_configuration.cpp:45
[19:47] <AlbertA> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/android/server/display_configuration.cpp#L45
[19:56] <Saviq> AlbertA, think it would make sense to make that unknown at least? at least as long as we don't have "virtual" or able to get the actual thing from the other side (but why would we - as far as we're concerned it's virtual)
[19:57] <AlbertA> Saviq: I could add a virtual type
[19:57] <AlbertA> Saviq: is that all you would need?
[19:58] <Saviq> AlbertA, yeah, as far as I know right now
[20:03] <AlbertA> Saviq: ok I'll roll that in to mir 0.22
[20:15] <Saviq> AlbertA, when you have a diff I could apply against lp:mir/ubuntu I'd be obliged, we'd put it in the aethercast silo
[20:15] <Saviq> temporarily at least
[22:14] <n1md4> hi.   tried using mir and unity8 recently.  after entering my details it just locks up.  im running a gtx980m with nvidia-361 driver.  any clues to get this working?
[22:35] <bregma> n1md4, we're only just enabling the nVidia binary blob driver...  it's,  uh, special
[22:35] <bregma> you could try nouveau instead
[22:42] <n1md4> bregma: thanks for the update.  I'd prefer something open, but to miss all the 980 goodness ... would almost be criminal.
[22:44] <bregma> fortunately nVidia is very interested in providing a better experience on Linux and we've been working with them to make sure that includes Mir support
[22:44] <bregma> they do go at their own pace, though
[22:45] <n1md4> it's always nice to hear though


[15:32] <zequence> XFCE looks have evolved, it seems
[16:04] <zequence> elfy: I'm done testing the images, so no need for you to. I'm assuming you have little time as is.
[17:08] <elfy> zequence: thank you :)


[04:57] <webwulf> anyone here?
[04:57] <webwulf> I could use some help setting up some systems for a school
[04:58] <webwulf> hello?
[14:36] <fsgaston> Does anybody know of patch to the 64bit ltsp so it won't lock up?
[14:37] <ogra> ?? can you elaborate ?
[14:37] <ogra> you have 64bit clients that done work ?
[14:37] <ogra> *dont
[14:38] <fsgaston> ogra - once we get a about 10 clients going with some multimedia the server just locks up
[14:38] <ogra> define "some multimedia"
[14:38] <fsgaston> ogra - the box has 8GB or ram and is doing fine and then just stops, I have read some other
[14:38] <fsgaston> people having the same issue
[14:38] <ogra> like everyone using rhythmbox at the same time ?
[14:39] <fsgaston> ogra - realplayer and a few and Writer on a few, variety of apps, I even had it happen on a two client test setup
[14:39] <ogra> anything in the logs ?
[14:40] <fsgaston> Sadly we have already wiped the machine and are testing other options, so I don't know
[14:40] <fsgaston> I heard 32bit was solid.
[14:40] <ogra> it should be, yes
[14:41] <ogra> (as should amd64 though, i'D really like to know what that was)
[14:41] <fsgaston> ogra - have you heard of this happening before, or do most people use 32 bit.
[14:41] <fsgaston> What logs would help you the most
[14:42] <ogra> well, i had a lot good feedback for hardy amd64 vs gutsy, but that was merely because flash finally works there
[14:42] <stgraber> ogra: did you see that bug about http proxy and ltsp-build-client ? (reading /etc/apt/apt.conf)
[14:42] <ogra> i havent heard of random lockups though
[14:42] <stgraber> ogra: it's easy to fix but I don't know if debootstrap uses /etc/apt/apt.conf, if it doesn't there is no point in fixing it
[14:42] <ogra> stgraber, yeah, its a duplicate
[14:43] <ogra> i was discussing it with vagrant a while ago but we didnt come to a proper solution yet ... since there are at least two places to define the proxy
[14:43] <stgraber> yes and IIRC the Ubuntu way is to create a file in apt.conf.d no ?
[14:43] <ogra> either /etc/apt/apt.conf or as http_proxy env variable. the fix needs to handle both
[14:44] <ogra> i dotn want a ubuntu alone solution ... the advantage of having something deban can use too is that they do the maintenance :)
[14:44] <stgraber> http_proxy currently works fine for both debootstrap and apt-get, apt.conf doesn't for any, can be solved for apt-get but that's useless if debootstrap doesn't use it
[15:01] <fsgaston> Does anybody have a good link for setting up autologin with LTSP?
[15:01] <fsgaston> ogra - we are setting up a new 64bit box for testing?
[15:01] <ogra> you need to set LDM_AUTOLOGIN=True, LDM_USERNAME and LDM_PASSWORD in lts.conf
[15:02] <fsgaston> ogra - if the usernames are the same, does this cause problems on the server with 100 clients
[15:02] <ogra> yes
[15:03] <fsgaston> ogra - what do you recommend
[15:03] <ogra> not with the server but with the apps
[15:03] <fsgaston> can you do login based on hostname
[15:03] <ogra> create one user per client u
[15:06] <fsgaston> ogra - How do point each host machine to a differnet username?
[15:07] <ogra> i think Gadin in #ltsp had a script for that, try to catch him there
[15:07] <ogra> *Gadi
[15:08] <fsgaston> ogra - If you were starting with 100 hosts and were planning on going up to 300 very soon, what approach would you take (network authentication etc)
[15:09] <ogra> i dont care about hosts, the question is how many users do you have ? :)
[15:09] <ogra> (often thats more than the number of hosts)
[15:10] <fsgaston> about 2000 users
[15:10] <fsgaston> We were looking at network filestorege for file access at school and home
[15:10] <ogra> yeah, well, a separation of appservers vs bootservers would be the first step i guess
[15:11] <ogra> sorry, got a meeting now ... look at the mille-xterm scripts (i think stgraber can poit you to something) they do things like automatic appserver detection in ldm etc
[15:11] <fsgaston> Thanks ogra, you have been a great help
[15:12] <ogra> i'll be back soon
[15:13] <fsgaston> join #ltsp
[16:41] <dukeofgp> how to get involved in edubuntu
[17:48] <lulemurfan> is it possible to install edubuntu on QEMU?
[20:24] <fsgaston> I need some feedback, would you do Edubuntu 7.1 or 8.04 for LTSP?
[20:27] <stgraber> 8.04, it's LTS


[04:55] <rjian> hello somerville32
[04:55] <somerville32> Ugh oh
[04:55] <somerville32> :)
[04:55] <somerville32> Hi Rjian
[04:56] <rjian> hehe
[04:56] <rjian> did anybody sign up here for LINUX ASIA 2007?
[04:59] <rjian> how bout u somerville32 did u sign up??
[04:59] <somerville32> No, lol
[04:59] <rjian> lols
[05:00] <rjian> hehe
[05:00] <rjian> it is open to everyone  :)
[05:00] <rjian> hehe
[05:00] <somerville32> I live in Canada
[05:00] <somerville32> Pay for me to go and I'll go
[05:02] <rjian> hahah
[05:02] <rjian> they offer subsidy hehehe
[05:02] <rjian> dont know yet if the application is still open.. hehe
[06:00] <somerville32> rjian, Wanna do me a favour?
[06:00] <rjian> sure somerville32 wat favour?
[06:01] <somerville32> Will you recap the Community Council Meeting for me in UWN 26?
[06:03] <rjian> hmm
[06:03] <rjian> wat exactly do u mean?
[06:04] <somerville32> Summarize what happened
[06:04] <somerville32> There is a section in UWN 26 about the last CC
[06:04] <somerville32> The meeting needs to be sumarized
[06:05] <somerville32> IT is already done on the Agenda page (in bullet form)
[06:05] <somerville32> You just need to turn it into flowing paragraphs of poetic beauty
[06:06] <rjian> ah ok get it.
[06:07] <somerville32> :)
[06:07] <somerville32> So, you'll do it? :)
[06:08] <rjian> ok ill take a look...
[06:08] <rjian> hmm seems like my news become a spanish ..
[06:08] <beuno> ;D
[06:08] <beuno> I try
[06:09] <beuno> hello all
[06:09] <somerville32> beuno: Will you do a section too?
[06:09] <beuno> yeap
[06:09] <somerville32> Awesome.
[06:09] <somerville32> Which one will you do?
[06:09] <somerville32> Maybe the community spotlight?
[06:09] <beuno> are you working on gobby or wiki?
[06:10] <rjian> yo somerville32 y is my article become a french or spanish??
[06:10] <somerville32> wiki
[06:10] <somerville32> rjian: Pardon?
[06:11] <rjian> somerville32: i mean my article on UWN 26 who edit it?
[06:11] <somerville32> I dunno
[06:11] <somerville32> It is still English, right?
[06:11] <beuno> somerville32: what do you need for the Community Spotlight?
[06:12] <somerville32> rjian: OR do you mean the article you plan to write?
[06:12] <rjian> somerville32: it is not anymore in English...
[06:12] <somerville32> beuno: Look at UWN 25 and do the same thing except look at the Marketing Team
[06:12] <somerville32> rjian: Can you give the link of the page you are viewing?
[06:12] <beuno> rjian: make sure you're looking at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue26 and not: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue26/ES
[06:13] <somerville32> IF you guys want to work on both right now, lets move to Gobby
[06:13] <somerville32> and I'll help
[06:13] <beuno> ok
[06:13] <beuno> that would be better
[06:13] <rjian> hmmm strange its back to normal..
[06:14] <rjian> wait ill try to check it again
[06:15] <beuno> somerville32: gobby info?
[06:16] <somerville32> yarusso.no-ip.org 523
[06:16] <somerville32> *6523
[06:16] <somerville32> Note the non-standard port
[06:17] <beuno> psw?  (I always forget  ;D, I know it's on the wiki somewhere)
[06:17] <somerville32> ufl@ftw
[06:19] <rjian> somerville32: {{ Currently editing in Backup Gobby Server (yarusso.no-ip.org 6523) }}}
[06:20] <somerville32> Right.
[06:20] <rjian> how can i write it? :)
[06:21] <somerville32> Do you have gobby installed?
[06:21] <rjian> i dont have..
[06:21] <rjian> wait ill download it..
[06:25] <rjian> somerville32: is there any way.. gobby dont work properly here..
[06:26] <somerville32> : (
[06:27] <rjian> wait ill try to reinstall it
[06:29] <beuno> rjian: did you make sure you changed the default port?
[06:29] <beuno> also, it's normal to have a startup error about ZeroConf
[06:29] <beuno> and last, but not least, are you on Edgy?
[06:30] <beuno> the Dapper version is old
[06:32] <rjian> beuno: actually im on Windows ryt now..
[06:32] <beuno> oh, sorry
[06:32] <beuno> I just assumed...
[06:32] <beuno> my bad
[06:32] <beuno> that's probably you're problem
[06:33] <rjian> yup.. wait ill try to download something.. give me a second...
[06:38] <rjian> somerville32: is the previous meeting is Dec. 12?
[06:39] <somerville32> Yup
[06:42] <somerville32> rjian: I'll just do it since you can't get connected. :(
[06:43] <rjian> dont
[06:43] <rjian> i mean done
[06:43] <rjian> but the problem is that i dont know how to use this gobby
[06:43] <rjian> can u teach me??
[06:44] <rjian> how to connect this thing to UWN26
[06:44] <beuno> did you get tot he point you're asked for a password?
[06:46] <rjian> nope..it says the hOSt Port and Name..
[06:46] <beuno> ok
[06:46] <rjian> how will i set it beuno ?
[06:46] <beuno> host name is: yarusso.no-ip.org
[06:46] <beuno> port: 6523
[06:47] <beuno> then, when you're asked for a password, put in:      ufl@ftw
[06:48] <rjian> tenx beuno
[06:48] <beuno> np  ;D
[07:38] <jenda> Mornin' folks
[07:38] <beuno> howdy jenda!
[07:39] <beuno> mornin'
[07:40] <beuno> how's it going?
[07:42] <crimsun> is the gobby server public (i.e., is the passwd restricted to a subset of people currently)?
[07:44] <beuno> crimsun, no
[07:44] <beuno> just protected from random bypasers
[07:44] <beuno> password is:  ufl@ftw
[07:46] <jenda> beuno: Isn't a bypasser a guy with a bypass on his aorta?
[07:46] <jenda> I'm doing OK, but extremely busy.
[07:47] <beuno> lol
[07:47] <beuno> yes, probably
[07:47] <beuno> it seems we all are pretty busy lately  ;D
[07:56] <beuno> jenda, it's "Feisty Changes" time on UWn
[07:57] <beuno> I've heard it's your favorite
[07:57] <jenda> uhh...
[07:57] <jenda> why? :)
[07:57] <jenda> I've never even touched that section ;)
[07:57] <beuno> exactly my point   ;D
[07:58] <jenda> ah I see :)
[07:58] <beuno> oh, another thing, maybe somerville32 can participate too
[07:58] <beuno> I got the itch to write up an article on "Upstart" for the next UWN
[07:58] <beuno> possibly an interview too, if I can get it
[07:58] <beuno> what's the best place/way to do it?
[07:59] <somerville32> In the Community Spotlight
[08:00] <rjian> after writing what will i do?
[08:00] <rjian> save it?
[08:00] <beuno> ok, good, I'm a bit concerned it will be too long
[08:00] <beuno> rjian: no, it's safe
[08:01] <rjian> ah ok
[08:02] <somerville32> There is 1236 commits to Feisty for December
[08:02] <somerville32> *are
[08:02] <rjian> somerville32: any needs to summarize?
[08:02] <somerville32> We usually summarize a majority of them
[08:03] <somerville32> For UWN 25, we commented on all commits except for 50
[08:03] <beuno> jenda: wouldn't the Community Spotlight be of a specific team/member rather then a package?
[08:04] <somerville32> No
[08:04] <jenda> makes sense to me, beuno, but I'm not the UWN guy around here...
[08:04] <somerville32> Community Spotlight is Team/Member, Process, or Specification/Feature
[08:04] <beuno> great
[08:04] <beuno> then unless something more important comes up
[08:04] <beuno> I'd like to do that
[08:06] <somerville32> Well, Mark wants us to a do a process soon
[08:06] <somerville32> Like how to do an MIR or SRU
[08:09] <Madpilot> 'how to decipher our TLAs'
[08:09] <Madpilot> ;)
[08:09] <beuno> ok
[08:32] <somerville32> Alrighty
[08:32] <somerville32> Last call for review before release
[08:33] <Rinchen> lol... ok this is funny.  http://blogs.gnome.org/view/uraeus/2006/12/31/0
[08:34] <Rinchen> The thinking being that having a full featured office suite for instance is more important to potential users than having a panel that can be themed to have the shape of a sextant.
[08:34] <Rinchen> sorry, it's just getting late
[08:35] <somerville32> Alrighty, I'm going to release UWN 26 now.
[08:36] <Rinchen> bring out the party hats and pop the bubbly, it's press time
[08:37] <somerville32> UWN #26 approved for release
[08:39] <beuno> well, if it's out there then I'm going to sleep for a few hours
[08:39] <beuno> when's 27 due?
[08:40] <rjian> today is the release of UWN 26?
[08:41] <beuno> rjian: it's out there: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue26
[08:42] <beuno> "UWN 27 in progress for Dec 30th"   :rolleyes:
[08:43] <beuno> I'm getting annoying, sorry
[08:43] <beuno> going to sleep
[08:43] <beuno> somerville32: I can help out with 27 tomorrow and delegate the translation of 26 to see if we can release on date
[08:44] <Rinchen> doh, I found a typo
[08:44] <somerville32> Good Work Everyone! :)
[08:44] <Rinchen> in my work no less
[08:44] <somerville32> Rinchen: haha
[08:44] <Rinchen> Changes in Rosetta from Sept 3rd to December 31st in Rosetta:
[08:44] <Rinchen> can you edit that out right quick?
[08:44] <somerville32> What is it suppose to be?
[08:44] <Rinchen> to "Changes in Rosetta from Sept 3rd to December 31st:"
[08:45] <somerville32> oh, too minor to recall the e-mail
[08:45] <somerville32> You can fix it in the wiki
[08:45] <tonyyarusso> You can recall e-mail?
[08:45] <somerville32> tonyyarusso, It is still in queue.
[08:46] <Rinchen> done
[08:46] <tonyyarusso> It would be pretty sweet if you could "unsend" anything that hadn't been read yet
[08:47] <somerville32> In some environments, you can
[08:47] <beuno> ok, I'm off
[08:47] <beuno> cya with 27 tomorrow!
[08:47] <beuno> g'night
[08:47] <Rinchen> cheers
[08:47] <beuno> been fun  ;D
[08:49] <rjian> weeeee
[08:50] <somerville32> I'm also thinking sleep is starting to sound good :]
[08:51] <rjian> i have to go home and prepare for school..
[08:54] <rjian> see ya somerville32
[08:56] <somerville32> Thanks for helping out rjian :]
[08:56] <rjian> no problem.. :)
[09:04] <crimsun> hah, too many hats?
[09:09] <somerville32> crimsun: Aspiring MOTU, Chief-Editor for UWN, Xubuntu Website Administrator, IRC Op, Xubuntu IRC namespace contact, Ubuntu-ca member, Xubuntu team member, etc. etc.
[09:09] <somerville32> Then I got little mini projects going on like the feisty changes script and welcome-centre
[09:10] <somerville32> I feel like different things are getting neglected
[09:10] <somerville32> Like, I have one approved SRU that I need to get sponsored and one that just needs a quick tweak to be approved - haven't had a  chance to deal with it yet.
[09:13] <somerville32> The goal for me was to get involved with Ubuntu but not let it consume my life like I've let other projects... I'm not doing so well. <g>
[09:14] <crimsun> heh.
[09:14] <crimsun> that's me for the past two years.
[09:14] <crimsun> I lost track of everything I've touched in Ubuntu.
[09:15] <somerville32> : ]
[09:15] <somerville32> Well, my vision is starting to go fuzzy - time for sleep :)
[09:16] <crimsun> 'night
[10:20] <beuno> damn insomnia...
[11:11] <beuno> damn insomnia...
[11:11] <beuno> sorry
[11:11] <beuno> ;D
[11:28] <juliux> jenda, ping
[11:29] <juliux> hi mindspin
[11:31] <mindspin> hi juliux
[01:53] <jenda> juliux: pong
[01:55] <juliux> jenda, which size for the shirt you need?
[01:58] <jenda> ah, right :)
[01:58] <jenda> juliux: I think we went for M for me last time, and that's good enough - not sure abotu MenZa
[01:59] <jenda> MenZa^
[02:01] <juliux> MenZa,
[09:52] <MenZa> large
[09:52] <MenZa> jenda
[09:52] <jenda> tiny
[09:52] <somerville32> moo
[09:52] <MenZa> orly?
[09:53] <jenda> ah, of course, the shirt... :)
[09:53] <MenZa> [07:01:13]  ( jenda) juliux: I think we went for M for me last time, and that's good enough - not sure abotu MenZa
[09:53] <jenda> I'll remember.
[09:53] <MenZa> :D
[09:53] <MenZa> ok
[09:53] <MenZa> I'll have those stickers sent the moment my stupid boss decides to transfer my pay
[09:53] <MenZa> Been away?
[09:53] <jenda> yep
[09:53] <jenda> And totally forgot about the stickers, BTW :)
[09:54] <somerville32> jenda: Why happened to my stickers?
[09:54] <somerville32> *what
[09:54] <MenZa> Are those mine?
[09:54] <MenZa> In that case, I apologise somerville32
[09:54] <MenZa> jenda: They've been packed in a box for over a week
[09:54] <MenZa> two even
[09:55] <jenda> somerville32: you didn't get any?
[09:55] <somerville32> nope
[09:55] <jenda> somerville32: I was supposed to send you some?
[09:55] <somerville32> Yes.
[09:56] <jenda> OK, Lemme check the docs...
[09:56] <beuno> hey somerville32, I've been getting a head start with UWN 27, maybe you can add the Feisty Changes to it so I can start doing some writeups on those
[09:56] <jenda> somerville32: but you did get posters, right?
[09:56] <somerville32> jenda: Yes and I was very pleased with them too :)
[09:56] <jenda> Good :)
[09:56] <somerville32> beuno: I can post the so-far ones, sure
[09:57] <beuno> somerville32: that would be great, thanks
[09:57] <beuno> I've also gotten some articles on it
[09:57] <jenda> somerville32: you didn't order them by email, did you?
[09:57] <jenda> or - no, you didn't ;)
[09:57] <beuno> and contacted scott about the Upstart piece  ;D
[09:58] <somerville32> jenda: What?
[09:58] <jenda> ahhh, somerville32 found it in IRC logs
[09:58] <jenda> how many did I promise? I'll just send them again.
[09:59] <somerville32> jenda: Up to you
[10:01] <jenda> ok, can you PM me your address again?
[10:03] <somerville32> Ok
[10:03] <somerville32> beuno: uploaded
[10:03] <somerville32> gotta run
[10:17] <rikai> Well, this place has grown some...
[10:18] <jenda> hmm... been 20-30 for several months now, I think :)