[12:45] <rlameiro> hey scott-work
[12:45] <scott-work> good morning rlameiro
[12:48] <scott-work> rlameiro: sent an email to stochastic again about OSM interview, still waiting for response :(
[12:48] <rlameiro> :(
[12:48] <rlameiro> the interview was due tomorrow, wasnt it?
[12:49] <scott-work> yes, tomorrow morning at 8:00 CST
[12:49] <rlameiro> CST?
[12:49] <rlameiro> Central "S" Time?
[12:50] <scott-work> currently it is 6:50 CST
[12:51] <rlameiro> 6 hours sooner than me :D
[12:51] <rlameiro> scott-work: you work so early???
[12:53] <scott-work> yeah, about three days a week I like to get here at 6:30, i'm a E/D supervisor for two offices and getting in early allows me to actually be productive before everyone else gets here ;)
[12:53] <rlameiro> he he
[22:38] <stochastic> ScottL, you around?
[22:52] <ScottL> stochastic, yes
[22:52] <stochastic> ScottL, I'll have a lot of trouble making a 6am interview as I get off work tonight at 11am
[22:53] <stochastic> ScottL, it was suggested just now in #opensourcemusicians that we bump the interview back two hours 10am CST or 8am PST
[22:53] <ScottL> stochastic, lol, i told them i'm good for several hours +/-, what is a good time?
[22:53] <ScottL> stochastic, 10am CST is good
[22:54] <stochastic> ScottL, sweet.
[22:54] <ScottL> stochastic, i'm really glad you will be there also
[22:55] <stochastic> ScottL, provided my alarm clock gets me up, yes (I have been known for struggling with that, but I'll do my best
[22:56] <stochastic> sorry I've been living under a rock in seclusion for the past couple weeks or so
[22:56] <ScottL> hopefully your back now :)
[23:01] <stochastic> well my schedule should clear up significantly in the coming weeks
[23:03] <ScottL> stochastic, going out to eat with the family, i'll read back when we get back


[03:01] <debauchery1st> any around?
[06:02] <lordievader> Good morning
[06:56] <marty> Is someone here in the forum who knows some technical details about the panel? Are all plasmoids in the panel running in the same thread?
[11:58] <BluesKaj> Hiyas all
 This IRC<->Telegram integration works quite well. I'd love to use it in another Open Source Community. Where can I find more information about it?
 @bauchhaus, In Cinnamon the window border decoration is only one pixel, but the grab area to resize it is about 7 pixels wide. Makes it look good and at the same time usable. Can't believe this isn't possible in KDE..
[13:20] <BluesKaj> bauchhaus, for Ubuntu support join #ubuntu chat
[13:26] <lordievader> bauchhaus, you can set a modifier key for which you can do <modifier key> + <right click> anywhere in the window to resize it.
 BluesKaj: why do you suggest #ubuntu for a Kubuntu/KDE Question?
[15:48] <BluesKaj> you mentioned Cinnamon so assumed that's what DE you're using.
[15:48] <BluesKaj> bauchhaus ^
 I suggest to read complete sentences before jumping into conclusions.
 @bauchhaus, Think KDE uses this? https://github.com/FruitieX/teleirc
[16:32] <Asiff> is there a way i can get ubuntu theme for kubuntu
[16:32] <Asiff> the gnome like look
[16:41] <BluesKaj> Asiff, look in system settings>Desktop Theme>Get new Themes >type gnome in the search and you'll see Gotham
[16:42] <Asiff> oh gotham.. leme see
[16:43] <BluesKaj> look at details
[16:43] <Asiff> but its just the desktop theme right.. isnt there a workspace theme
[16:44] <Asiff> like the ambiance window decorator, adwaita cursor etc
[16:44] <BluesKaj> workspace theme is desktop theme
[16:45] <Asiff> oh wait.. found something.. named united
[16:45] <Asiff> thanks anyway
[19:28] <alashqa8> hf
[19:28] <alashqa8> hi
[19:29] <alashqa8> helo
[19:29] <alashqa8> abd alrhman
[19:47] <debauchery1st> I just installed kubuntu 18.04
[19:48] <debauchery1st> my only issue was bcmwl-kernel-source
[19:50] <debauchery1st> needs :  libdpkg-perl_<IP_ADDRESS>ubuntu2_all.deb     &     libfile-fcntllock-perl_0.22-3build2_amd64.deb
[19:52] <debauchery1st> please add those 2 packages to the next version of the ISO. I had to download and install via dpkg
[19:53] <debauchery1st> otherwise, it's perfect
[19:54] <debauchery1st> keep up the good work.
[20:03] <simonizor> What was someone smoking when they made the decision to make Cantata the default player?  I love Cantata, but mpd is not something that is at all easy for beginners.  You ***have*** to configure it manually to do a lot of things with it.
[20:03] <simonizor> audacious-qt would have been a ***much*** more sane choice
[20:10] <simonizor> Gotta love when someone is trying to setup mpd to work with Cantata and they get to a point where no sound is working *other than mpd*... pretty terrible choice here.
[20:11] <simonizor> It's decisions like these that will always make me recommend KDE neon over Kubuntu.  I'd like to think one day the offical Ubuntu KDE flavor would be able to produce a nice feeling flavor, but it... just doesn't happen...
 @acheronuk, Ah cool. Thanks @acheronuk
[20:49] <NerdTheThird> i just installed mpd and cantata worked
[20:49] <NerdTheThird> no extra configuration or setting up
[20:50] <NerdTheThird> then again, i'm not some super dooper advanced mpd user


[09:56] <Vibhav> If i translate any program using
[09:57] <Vibhav> .po files , ie not using rosetta , will i still get karma points
[09:58] <jokerdino> no you wont.
[09:58] <jokerdino> you might get some for uploading the po file
[09:59] <Vibhav> :(
[09:59] <Vibhav> Are you sure?
[09:59] <jokerdino> Karma is only attributed for work done in Launchpad and does not apply to items imported from other sources.
[09:59] <jokerdino> https://help.launchpad.net/YourAccount/Karma
[10:00] <Vibhav> Well i may report this as a bug
[10:00] <Vibhav> Thanks jokerdino
[10:01] <jokerdino> :)
[11:19] <trijntje> should ubuntu-default-image be working properly on precise? It runs without error but doesn't generate an iso image
[11:22] <trijntje> should ubuntu-default-image be working properly on precise? It runs without error but doesn't generate an iso image
[13:57] <sagaci> is there any way to delete a translation suggestion
[13:59] <trijntje> sagaci: not if its been automatically generated by launchpad, as far as I know
[14:00] <sagaci> no worries, just sick of seeing wrong suggestions


[07:03] <darkxst> Noskcaj, did you find out debian's plans for wayland?
[07:03] <darkxst> 1.7?
[07:04] <Noskcaj> no, i'll ask again but i don't think i got any info
[07:04] <Noskcaj> I'll be back in an hour
[07:04] <darkxst> Noskcaj, I suppose the main question is where they plan to install the new documentation
[09:15] <muppis> Do you have any problems with bumblebee / primus on non-Optimus systems and 15.04 ?
[09:16] <darkxst> muppis, bumblee shouldn't do anything on non-optimus systems!
[09:16] <darkxst> likewise with prime
[09:17] <muppis> darkxst, I assumed that, but login screen went all black after update. Purging both fixed it.
[09:20] <muppis> I can retest that when I get back to home. My desktop has nvidia gfx and uses proprietary drivers, laptop uses Intel and I got 15.04 in there as well.
[09:20] <darkxst> not seen any issues from prime
[09:21] <darkxst> never installed bumblebee since I don't have any hybrid hardware
[09:21] <muppis> I didn't know eithet that was installed.
[09:21] <muppis> *either
[09:22] <darkxst> nvidia-prime is likely pulled in automatically, bumblebee certainly wouldnt be
[09:22] <muppis> nvidia-prime wasn't installed at all.
[09:24] <darkxst> muppis, oh primus is part of bumblebee
[09:25] <darkxst> but you must have installed the latter?
[09:25] <darkxst> muppis, nvidia-prime is a rdep of all official nvidia blob packages, not sure how you can't have that
[09:25] <darkxst> since you are using them
[09:26] <darkxst> or did you manually install drivers from nvidia site?
[09:26] <muppis> I had manually installed, but then I changed to ones from repo.
[09:27] <darkxst> installing nvidia-3xx from repos will install nvidia prime
[09:28] <muppis> Then it's installed. I can remember incorrectly.
[09:30] <muppis> But I'm sure for that bumblebee and/or primus caused black screen.
[09:30] <muppis> Does it can affect that mb has integrated Intel based video chip?
[09:52] <darkxst> muppis, bumblebee will never be installed automatically
[09:52] <darkxst> its a hack
[09:53] <darkxst> nvidia-prime is the officially supported solution for hybrid nvidia graphics
[09:54] <muppis> Then I've no idea why that was installed.
[16:26] <spicie> @octoquad
[16:26] <meetingology> spicie: Error: "octoquad" is not a valid command.
[16:27] <octoquad> Hi spicie


[12:25] <fabbione> ok.. logs will be available from now on... they will start appearing on the server in not less than one hour
[12:25] <fabbione> enjoy :)
[05:30] <wasabi_> So, 3.1 really isn't that much better.
[05:30] <wasabi_> Basically they just moved stuff around and introduced a whole new set of packging problems.
[05:35] <wasabi_> Hey. Should .db files be put into share or lib by packages?
[05:36] <wasabi_> I'm about to actually start using this stuff for real packages.
[05:47] <jbailey> Lemme check FHS
[05:47] <jbailey> Hold on, the db files?
[05:48] <jbailey> Not the .so files?
[05:48] <jbailey> .so files should be in /usr/lib/...
[05:48] <jbailey> db files are generated at install time, right?
[05:55] <wasabi_> Nope.
[05:56] <wasabi_> The .db files will be distributed in each package and put into a central dir.
[05:56] <wasabi_> And the postinst will regenerage the main db file in /var/lib
[05:56] <wasabi_> regenerate
[05:56] <wasabi_> /usr/share/gcj-4.0/classmaps.d/packagename.db or something
[05:56] <wasabi_> I am uncertain if that should be in /usr/share or /usr/lib though, as it refers directly to .so files.
[06:00] <jbailey> The best thing is to generate one on two different arch's and see if they're exactly the same.
[06:06] <wasabi_> Check #gcj on OFTC.
[06:06] <wasabi_> Interesting point.
[06:06] <wasabi_> How do we deal with multiarch?
[09:42] <wasabi_> jbailey, converting Eclipse to cdbs. Need some assistance.
[09:43] <wasabi_> I have a fairly elaborate "configure" step.
[09:43] <wasabi_> configure:: prepare-stamp should make cdbs call my prepare-stamp target right?
[09:43] <wasabi_> Just using debhelper.mk....
[09:44] <wasabi_> Oh I guess that should be pre-build?
[09:50] <jbailey> pre-build is probably the best choice if you can.
[09:50] <jbailey> I need to know more about what you're doing to guess properly, though.
[09:50] <wasabi_> extracting the source, applying patches.
[09:52] <jbailey> There's a target apply-patches:: you can use. =)
[09:52] <wasabi_> Is that part of debhelper.mk?
[09:53] <wasabi_> I can't use a built in patch system.
[09:53] <jbailey> Nope, it's part of buildcore
[09:53] <wasabi_> Since I have a custom one that works per eclipse plugin
[09:53] <wasabi_> okay cooll
[09:53] <wasabi_> Does this thing manage stamp files?
[09:53] <jbailey> No. =(
[09:53] <wasabi_> Eclipse takes so freaking long.
[09:53] <jbailey> That's a major deficiancy in cdbs atm.
[09:54] <wasabi_> I have it split into a bunch of pieces just to make debugging easier
[09:54] <wasabi_> I think I'll just hang my current stuff off of it then.
[09:54] <jbailey> Probably best.
[10:06] <wasabi_> Heh this is odd.
[10:06] <wasabi_> I have these packages:
[10:07] <wasabi_> eclipse-sdk and eclipse-platform and a bunch more.
[10:07] <wasabi_> eclipse-sdk is Arch: all.
[10:07] <wasabi_> eclipse-platform is arch: any
[10:07] <wasabi_> Hmmm. I need the build process to happen before either are installed.
[10:07] <wasabi_> Right now it looks like it's trying to do arch indep stuff first, before it goes down my build process.
[10:08] <wasabi_> I would have expected build/eclipse:: to happen before any package, arch dep or indep.
[10:08] <wasabi_> Maybe I'm not using build/eclipse right.
[10:09] <wasabi_> How do I add a build target that is required for ALL packages?
[10:14] <jbailey> You're crawling into the cobweb ridden corners of cdbs here, and alot of the motivation for cdbs2. =(
[10:15] <wasabi_> hehe.
[10:15] <jbailey> (And stuff tha tI have to look up to get right, justasec)
[10:15] <jbailey> common-build-arch:: might be a good choice.
[10:16] <wasabi_> Ah.
[10:16] <jbailey> Honestly, I avoid the PASS/PACKAGE stuff as much as I can.
[10:16] <wasabi_> -indep stuff too?
[10:16] <jbailey> It was a neat idea implemented poorly.
[10:16] <jbailey> Yup, it's there.
[10:16] <jbailey> Although in practice -arch is fine.
[10:16] <wasabi_> I like it. If nothing else it lets you seperate code easier.
[10:16] <jbailey> It's always called.
[10:16] <jbailey> Right, except that people don't build their packages cleanly along the lines of their packages.
[10:17] <wasabi_> and provides a bit of self documentation
[10:17] <jbailey> cdbs2 introduces build passes that you can name explicitely.
[10:17] <jbailey> And packaging passes that are based on the package names.
[10:17] <wasabi_> Still didn't work.
[10:17] <wasabi_> common-build-arch:: build-eclipse-compile-stamp build-eclipse-install-stamp
[10:17] <wasabi_> common-build-arch-indep:: build-eclipse-compile-stamp build-eclipse-install-stamp
[10:17] <wasabi_> But neither of those were called before debhelper started running for eclipse-sdk
[10:17] <jbailey> common-build-indep
[10:18] <wasabi_> There we go.
[10:18] <wasabi_> This does help. It makes the code easier to follow.
[10:19] <wasabi_> How about a recommendation on how to "install" eclipse. Which steps go where? Right now I have the build targets building the eclipse.tar.gz file
[10:19] <wasabi_> That's how the eclipse upstream build system works. It ends up with a tar.gz
[10:19] <wasabi_> Then, in the install portion I "install" the .tar.gz to debian/tmp.
[10:19] <wasabi_> Basically just extracting it.
[10:20] <wasabi_> But then I have to move lots of pieces between different packages... and take debian/extras, shell scripts and stuff, and put them in the right place.
[10:20] <wasabi_> Should I be installing the extras into debian/tmp and then relying on dh_install to move them to the right package?
[10:20] <jbailey> Well, dh_install can reach into the debian/extras directory directly.
[10:20] <jbailey> So there's no need to move them to debian/tmp first.
[10:21] <wasabi_> But then I have some which require preprocessing
[10:21] <wasabi_> like debian/extras/eclipse.png.uu
[10:21] <jbailey> Right.  Can you do those in the build phase somewhere?
[10:21] <wasabi_> Is that what's proper?
[10:21] <jbailey> Move those into tmp.
[10:21] <jbailey> I like to do all munging and such in the build phase.
[10:22] <jbailey> It means that if I stamp that off, I'm done. I don't have to waste time doing any munging again.
[10:23] <wasabi_> sounds good
[10:24] <wasabi_> So build the .pong in build, but don't copy it to debian/tmp until install (where it's handled by dh_install)
[10:28] <jbailey> Right.  That means that you can always blow away debian/tmp and just redo the build from install.
[10:28] <jbailey> Probably nice in the case of eclipse.
[10:28] <wasabi_> oh yes.
[10:28] <wasabi_> heh.
[10:28] <wasabi_> it's a 30 minute compile.
[10:28] <jbailey> Ouch. =)
[10:28] <wasabi_> It uses about 900MB of space.
[10:29] <wasabi_> During build.
[10:29] <jbailey> We use tricks like that for the glibc build.
[10:29] <jbailey> When working on packaging, you *Really* don't want to have to rebuild it.
[10:29] <jbailey> How much of eclipse is C/C++ code?
[10:29] <wasabi_> Very little actually.
[10:30] <jbailey> Ah, too bad.
[10:30] <jbailey> Otherwise ccache might have sped the build up somewhat.
[10:31] <wasabi_> yeah. =(
[10:39] <wasabi_> can dh_install move files?
[10:39] <wasabi_> Like, I want usr/share/eclipse/eclipse to be moved to usr/lib/eclipse/eclipse
[10:39] <wasabi_> and then use dh_link to link it back
[10:40] <wasabi_> Dislike managing that stuff manually.
[10:45] <jbailey> Umm.
[10:45] <jbailey> I don't think it can.
[11:50] <wasabi_> make confuses me
[11:50] <wasabi_> common-install-arch:: install-eclipse-stamp
[11:51] <wasabi_> yet when I run debian/rules common-install-arch, it repeats it.
[11:51] <wasabi_> even though install-eclipse-stamp exists


[04:49] <wrtp> davecheney: hiya
[04:52] <wrtp> davecheney: FYI here's a sketch of the possible firewall-management code: http://paste.ubuntu.com/1089246/
[04:52] <wrtp> davecheney: (we discussed it when you weren't around)
[05:22]  * davecheney reads wrtp
[05:44] <wrtp> davecheney: actually, i realise that i didn't update it for the most recent version of the OpenPorts API: http://paste.ubuntu.com/1089282/
[05:47] <davecheney> wrtp: on da phone, hang on
[05:48] <wrtp> davecheney: np
[05:55] <davecheney> wrtp: that propsal looks good
[05:55] <wrtp> davecheney: cool
[05:56] <davecheney> open question, are you, i and frank all trying to eat the same elephant ?
[05:56] <davecheney> this is simlar to the branch be proposed on wednesday
[05:56] <wrtp> davecheney: i hope so
[05:57] <wrtp> davecheney: this was a response to frank's proposal
[05:57] <davecheney> he was approaching it from the state side, which sort of makes sense because in the py version there is a state.FirewallManager
[05:57] <wrtp> davecheney: i'm not quite sure why he did it actually, as it's really just part of the PA, but it was useful for focusing all the issues in one place
[05:57] <wrtp> davecheney: ah!
[05:58] <davecheney> but it does exactly that, although simpler
[05:58] <wrtp> davecheney: i hadn't quite got that it was in state
[05:58] <davecheney> for every machine or unit, it registers a callback (it == firewall manager)
[05:58] <davecheney> then does (stuff) when that callback fires
[05:58] <wrtp> davecheney: the main difference is that in the python version, it checks the "real" state every time.
[05:58] <davecheney> in some ways in twisted it's simpler
[05:58] <davecheney> in our version we need to start and manage a watcher goroutine
[05:59] <wrtp> davecheney: whereas this CL keeps track of the state and only issues OpenPort/ClosePort requests at well-defined times
[05:59] <davecheney> this is the <-serviceChange bit ?
[06:00] <wrtp> davecheney: yeah. there's only one central goroutine that manages the whole thing
[06:00] <davecheney> wrtp: here is the problem i see
[06:00] <wrtp> davecheney: i had difficulty keeping track of all the potential state interactions when there were multiple independent goroutines operating on it.
[06:00] <davecheney> if we have N port watchers, how do we funnel all those change messages into a single channel ?
[06:01] <wrtp> davecheney: easy
[06:01] <wrtp> davecheney: just start a goroutine for each watcher
[06:01] <davecheney> can we pass a channel to watchPort ?
[06:01] <davecheney> yup, goroutine that watches the watcher and forwardst he messages (means more tomb.Tombs ..)
[06:01] <wrtp> davecheney: which prepends some data and sends on a central channel
[06:01] <wrtp> davecheney: i think we can get away without any more tombs
[06:01] <davecheney> wrtp: i'd like to try
[06:02] <davecheney> nothing wrong with tomb
[06:02] <davecheney> but less of everything is better, when there are going to be a lot of these port watchers
[06:02] <wrtp> davecheney: the only thing wrong with tomb is that it's more heavyweight than necessary sometimes
[06:02] <davecheney> wrtp: i have to step out for a few hours, but will be online from ~8/9 my time this evening
[06:02] <wrtp> davecheney: ok
[06:02] <wrtp> davecheney: i think that all the mux goroutines can watch the same tomb
[06:03] <davecheney> wrtp: that would be excellent, because the most likely cause of them wanting to die is the firewaller goroutine exiting
[06:03] <davecheney> also, http://codereview.appspot.com/6333067/
[06:04] <davecheney> i imagine this would be a valid chassis for your proposal ?
[06:04] <wrtp> davecheney: absolutely
[06:04] <wrtp> davecheney: frank is now working on integrating my sketch with your chassis
[06:04] <davecheney> wrtp: could I ask for some of your time today to get a run through of that chassis
[06:05] <wrtp> davecheney: definitely
[06:05] <davecheney> it doesn't do anyhthing at the moment so the amount of review should be minimal
[06:05] <davecheney> especially at is a carbon copy of the provisioner
[06:05] <davecheney> which makes me wonder if some of the dulication can be factored out
[06:05] <wrtp> davecheney: it looks fine to me at first glance
[06:05] <davecheney> but that is not important right now
[06:06] <davecheney> wrtp: just got an email from minux, he sent me a photo out front of building 47 on the google campus with some of the go team
[06:06] <wrtp> davecheney: cool. link?
[06:07] <davecheney> i'll forward it
[06:10] <davecheney> wrtp: in ya gmail
[06:11] <wrtp> davecheney: rob looks very blues brothers
[06:11] <wrtp> davecheney: thanks, BTW
[06:19] <davecheney> wrtp: have a good one, be online later
[06:20] <wrtp> davecheney: how long?
[06:20]  * wrtp can't remember time zones!
[06:21] <wrtp> davecheney: np, just worked it out
[06:21] <wrtp> davecheney: i'll be around
[07:30] <wrtp> fwereade_, TheMue: mornin'
[07:30] <fwereade_> wrtp, TheMue: similarly :)
[07:31] <fwereade_> wrtp, so, what am I doing in ComposeConfig that I don't need to? :)
[07:31] <wrtp> fwereade_: i have an idea, but i haven't quite been able to make it work yet
[07:32] <fwereade_> wrtp, yeah, my experience has been that it's a bit harder than it sounds like it should be ;)
[07:32]  * fwereade_ looks sadly at this morning's conflicts
[07:32] <wrtp> fwereade_: here's what i what i'm trying: http://paste.ubuntu.com/1089407/
[07:33] <fwereade_> wrtp, hmm, interesting
[07:34] <wrtp> fwereade_: but there's a problem.
[07:34] <fwereade_> wrtp, I felt that we were doing so much with the maps that the internal types just complicated matters
[07:34] <wrtp> fwereade_: both the provider config and the config config require fields that have defaults provided by the other.
[07:35] <wrtp> fwereade_: so the initial config.Compose fails because it hasn't got a default-series
[07:35] <fwereade_> wrtp, yeah, indeed, it's fiddly
[07:37] <wrtp> fwereade_: i like the security that the internal type buys us
[07:38] <wrtp> fwereade_: it doesn't seem right that core after the initial configuration is still type coercing
[07:38] <wrtp> s/core/code/
[07:39] <fwereade_> wrtp, agreed, very much so; but converting back and forth between dicts and internal types *all the damn time*, because the composition api needs dicts (or at least divt-backed configs) seems even worse
[07:40] <wrtp> fwereade_: i'm not sure
[07:40] <fwereade_> wrtp, and niemeyer seems very convinced that an enviroment config "really is" a map
[07:41] <wrtp> fwereade_: outside of a provider, yes
[07:41] <fwereade_> wrtp, I consider that argument to be utterly invalid, it's as much a map as every single other type in the system
[07:41] <wrtp> fwereade_: inside a provider, it's a known thing
[07:41] <fwereade_> wrtp, that is a serialization format, surely? just like for every other type in the system that we serialize..?
[07:43] <wrtp> fwereade_: the difficulty is that it's not just a serialisation format - it's a serialisation that we want to process, rather than just unmarshal.
[07:43] <TheMue> wrtp, fwereade_ : Oh, sorry, morning from my side too. Just had received my malt #29, a Laphroaig Cask Strength Batch 004 *yummy*
[07:43] <wrtp> TheMue: don't drink it all this morning!
[07:44] <TheMue> wrtp: hehe, no, will open it this evening
[07:44] <fwereade_> wrtp, well, I see no good reason not to just marshal/unmarshal the type as a real type once we know what it is, and to handle *all* the funky processing at user input time
[07:44] <fwereade_> TheMue, nice
[07:45] <wrtp> fwereade_: what about secrets?
[07:46] <wrtp> fwereade_: i.e. how can we marshal the type without some info?
[07:46] <wrtp> fwereade_: also, SetAttr
[07:47] <wrtp> fwereade_: we need to be able to set environment attributes, but just marshalling and unmarshalling doesn't easily allow that
[07:47] <fwereade_> wrtp, I'm not sure I follow your concerns
[07:48] <fwereade_> wrtp, the secrets thing maybe needs a little bit of rearrangement
[07:48] <fwereade_> wrtp, but then I've been asked not to think about secrets for now anyway
[07:49] <fwereade_> wrtp, and the type could surely handle user-defined config files, and env-set command data, in the same way?
[07:50] <wrtp> fwereade_: part of the cause of the current issues, i think, is the way that concerns about the config are divided between the config package and the provider package
[07:51] <wrtp> fwereade_: if the provider did it all, i don't think there would be so much of a problem.
[07:51] <fwereade_> wrtp, wouldn't that just mean that we need to duplicate everything in config across every provider?
[07:51] <fwereade_> wrtp, I am maybe taking this whole situation a little personally
[07:52] <fwereade_> wrtp, because the very first thing I did when I joined the team was to unpick the ec2 provider so we could actually use the common bits in orchestra
[07:52] <fwereade_> wrtp, and it was not easy
[07:52] <wrtp> fwereade_: of course, you'd need to be careful about consistency across providers, but that's true in any case
[07:53] <wrtp> fwereade_: i don't think it would mean that we'd need to duplicate everything.
[07:53] <fwereade_> wrtp, and what I see in go is a wilful refusal to heed the lessons of the python port -- it feels like a deliberate decision was made to replicate a known mistake in the python :/
[07:53] <wrtp> fwereade_: there would be some duplication, yes, but anything substantial could be factored out and put in the environs package
[07:54] <wrtp> fwereade_: that's always been the intention
[07:54] <wrtp> fwereade_: if the providers are in charge, they can choose what shared bits to use from the environs package
[07:54] <wrtp> fwereade_: (readAuthorizedKeys being one example)
[07:55] <wrtp> s/the intention/my intention/
[07:56] <wrtp> s/the environs package/any package we choose to put shared bits in/
[07:56] <fwereade_> wrtp, I just don't see how it's a good idea from any perspective except the let's-just-hack-it-together-quickly one
[07:57] <fwereade_> wrtp, which I thought it was our avowed intention to avoid
[07:57] <wrtp> fwereade_: which code duplication are you particularly thinking of here?
[08:00] <fwereade_> wrtp, all the bootstrap/could-init stuff, default-series and authorized-keys, things like we discussed yesterday with ports handling on instance start
[08:00] <fwereade_> wrtp, the prts handling I agree was not well factored in the python
[08:00] <wrtp> fwereade_: prts?
[08:00] <fwereade_> wrtp, sorry, ports
[08:00] <wrtp> ah
[08:02] <wrtp> fwereade_: it has always been my intention to move environs/ec2/cloudinit.go to environs/cloudinit.go when it's needed
[08:02] <wrtp> fwereade_: it was designed to be used by any package (hence the "providerType" field)
[08:02] <wrtp> s/package/provider/
[08:02] <wrtp> fwereade_: same with readAuthorizedKeys
[08:02] <fwereade_> wrtp, and so what we end up with is bits of common code mixed in with provider-specific code, and a big nasty surprise waiting for us when we try to actually use them elsewhere
[08:03] <fwereade_> wrtp, I suspect you are going to say it's ok to duplicate all the structural code (ie doing the right things at the right time) across the providers
[08:03] <wrtp> fwereade_: i think we end up with providers having a coherent interface and using what is necessary to fulfil that interface
[08:03] <wrtp> fwereade_: the tests will test that we've got the structural stuff right
[08:04] <wrtp> fwereade_: and it will all end up nicely clear and understandable, i hope
[08:05] <fwereade_> wrtp, I hope you're right
[08:05] <fwereade_> wrtp, IMO you've severely underestimated the subtleties
[08:06] <wrtp> fwereade_: maybe i have. i put my faith in encapsulation :-)
[08:06] <fwereade_> wrtp, and duplication :/
[08:07] <TheMue> wrtp: Did you thought about this way http://paste.ubuntu.com/1089445/ to send all machnine unit changes to the firewaller?
[08:07] <wrtp> fwereade_: we're guessing about that. yes, there will be code similarities between providers, but i'm hoping there won't be significant duplication
[08:07] <TheMue> wrtp: So the main loop of the firewaller handles all like you porposed.
[08:08] <wrtp> TheMue: not quite
[08:08] <wrtp> TheMue: one mo
[08:08] <fwereade_> wrtp, sorry, I'm just feeling generally negative about things because, wtf, this whole config saga
[08:09] <wrtp> fwereade_: i totally understand
[08:09] <fwereade_> wrtp, honestly I'm thinking it's all sunk costs, fuck it, just use a map throughout
[08:10]  * wrtp resists, but is perhaps weakening. seems a pity but...
[08:12] <fwereade_> wrtp, the trouble is this is *another* week pissed up the wall
[08:12] <wrtp> fwereade_: agreed
[08:12] <wrtp> fwereade_: let's just do it
[08:13] <fwereade_> wrtp, "let's return actual configs from State.EnvironConfig"; "sounds good"; for {"ok, I'll give it a go"; "no, not like that"} :/
[08:14] <wrtp> fwereade_: :-(
[08:17] <fwereade_> wrtp, and all I wanted to do was to fix state.Initialize so I could fix the high-priority default-series bug that was assigned to me, pulling me away from the unit agent stuff
[08:18] <wrtp> TheMue: something like this perhaps? http://paste.ubuntu.com/1089457/
[08:18] <wrtp> fwereade_: yeah, it's gone a bit out of control
[08:19] <wrtp> TheMue: it's important that the changes on the channel include the information about what the change is about.
[08:23] <wrtp> TheMue: slightly more accurate: http://paste.ubuntu.com/1089462/
[08:23] <TheMue> wrtp: ah, thx
[08:24] <TheMue> wrtp: funnily it will drive the whole stuff into the same complexity direction as before, but with a cleaner interface
[08:24] <wrtp> TheMue: the important difference is that the state is only managed in one goroutine
[08:25] <wrtp> TheMue: stuff like that machine loop goroutine is just a conduit - it does nothing active
[08:25] <wrtp> TheMue: and that, i think, makes everything easier to reason about
[08:26] <TheMue> wrtp: yip
[08:27] <wrtp> TheMue: http://www.youtube.com/watch?v=SPPS8vExLmE :-)
[08:31] <TheMue> wrtp: ;) yip
[10:26] <Aram> hey.
[10:27] <wrtp> Aram: yo
[10:41] <wrtp> fwereade_: ping
[10:44] <TheMue> Aram: Hi
[10:47] <wrtp> fwereade_: i know it's way too late, but once i thought of this idea, i had to try it out. it feels much nicer to me, but it might be total crack. http://paste.ubuntu.com/1089617/
[10:50] <fwereade_> wrtp, thanks -- I'll try to look at it this pm, but cath's away and I'll be with laura :( (well, :) as well, but you know ;))
[10:50] <wrtp> fwereade_: if you want to declare your train wrecked and you like this idea, i'd be ok to take the flak from here if you like.
[10:50] <wrtp> fwereade_: ok
[10:51] <fwereade_> wrtp, it's appreciated, I'll think on it :)
[10:51] <fwereade_> wrtp, thanks :)
[10:52] <wrtp> fwereade_: that code passes the dummy tests BTW
[10:53] <wrtp> fwereade_: although i haven't added a test for default-series
[12:26] <TheMue> Hmm, starting with useful tests without blowing the whole stuff up isn't simple.
[14:04] <wrtp> fwereade_, davecheney, TheMue: here's an configuration alternative. it feels quite a bit cleaner to me than env-config-trainwreck. i wonder what you think: https://codereview.appspot.com/6343107/
[14:05] <wrtp> i *think* it provides as much flexibility as the other, but doesn't require nearly as much messing around with maps
[14:06] <wrtp> the heart of the proposal is in https://codereview.appspot.com/6343107/diff/1/environs/interface.go
[14:16] <TheMue> wrtp: Could you enlighten me, what is this "authorized-keys" stuff in config.go?
[14:17] <wrtp> TheMue: authorized-keys is a standard environment setting across all providers
[14:17] <wrtp> TheMue: it's also possible to use authorized-keys-path, which gives the name of a file containing the authorized keys
[14:18] <wrtp> TheMue: the authorized keys are ssh keys
[14:18] <TheMue> wrtp: per config entry?
[14:18] <wrtp> TheMue: yeah
[14:18] <TheMue> wrtp: ok, understand
[14:18] <wrtp> TheMue: that is, each config entry can have a different set of auth keys
[14:19] <TheMue> wrtp: How variable is the config scheme?
[14:19] <wrtp> TheMue: as variable as we want to make it
[14:20] <TheMue> wrtp: In the sense of "per software version", not in the sense of "how much possibilities this software has", sorry.
[14:20] <wrtp> TheMue: currently the fields i've put into config.go are a good guess at common functionality
[14:20] <wrtp> TheMue: i guess we'd want to keep things backwardly compatible
[14:21] <TheMue> wrtp: ok, otherwise I would use direct yaml or json marshalling of a strcut scheme representing the configuration
[14:21] <TheMue> wrtp: but if we need this generic approach it't ok
[14:22] <wrtp> TheMue: we can't do that, because each provider has a different set of attributes
[14:23] <wrtp> TheMue: config.go is an attempt to factor out some common functionality between providers.
[14:23] <TheMue> wrtp: so the config types have to be defined per provider. today he also as to know, which configuration variables he retrieves from the config, so it's kinda hard coded
[14:24] <wrtp> TheMue: only the common functionality is hard coded
[14:24] <TheMue> wrtp: and the names of variables a provider accesses
[14:24] <wrtp> TheMue: but each provider knows which attributes it supports, of course
[14:24] <TheMue> wrtp: that's what I mean, exactly
[14:25] <wrtp> TheMue: how could the provider get its configuration data otherwise?
[14:26] <TheMue> wrtp: Kind of ReadConfig(filename, &myTopStruct), internally simply using an unmarshalling of e.g. json
[14:27] <wrtp> TheMue: but myTopStruct has to hard code the fields names in just the same way
[14:27] <wrtp> s/fields/field/
[14:27] <wrtp> TheMue: but also, there are several sections in the file, each with a different provider and a different set of attributes. i don't know how the above could work with that
[14:28] <TheMue> wrtp: yes, indeed, only the generic part is simpler
[14:28] <TheMue> wrtp: in both ways we can have runtime errors, yes
[14:29] <wrtp> TheMue: what would the type of myTopStruct look like?
[14:29] <TheMue> wrtp: that depends on the provider
[14:29] <wrtp> TheMue: you don't know the provider before you read the file
[14:30] <wrtp> TheMue: we're using the schema package to do a similar kind of thing.
[14:30] <wrtp> TheMue: it doesn't marshal to a struct sadly
[14:30] <wrtp> s/marshal/unmarshal/
[14:42] <TheMue> wrtp: ok, I see
[14:48] <Aram> "<pnielsen> Aram: technically both can modify the struct, but one will be modifying copies, the other one will be modifying the "original""
[14:48] <Aram> I hate such redundant and pointless "corrections" on IRC.
[14:48] <Aram> read between the lines!
[14:54] <TheMue> Aram: *lol*
[16:05] <rogpeppe> TheMue, Aram, fwereade_: a code review if anyone cares for it: https://codereview.appspot.com/6344113
[16:05] <rogpeppe> TheMue: it's the implementation of OpenPorts etc that the firewaller code will use
[16:21] <fwereade_> rogpeppe, I'm very unlikely to get to that, but I really like the approach you took on the config stuff
[16:21] <rogpeppe> fwereade_: really? cool.
[16:22] <fwereade_> rogpeppe, I think it has unexamined fiddlinesses (in the review) but it's still going to be way way nicer
[16:22] <rogpeppe> fwereade_: i felt it was a bit of a last-ditch attempt, but after trying to work with it, i was tending to agree with you about the train wreck
[16:22] <rogpeppe> fwereade_: ah, a review! you're a lovely man.
[16:23] <rogpeppe> fwereade_: it definitely needs lots more tests - i didn't want to waste any more time on it if it was a dead end.
[16:23] <fwereade_> rogpeppe, IMO, s/last-ditch attempt/fantastic diving save/
[16:30] <rogpeppe> fwereade_: BTW should authorized-keys be optional in general?
[16:30] <fwereade_> rogpeppe, I think we always need it
[16:31] <fwereade_> rogpeppe, otherwise we can't connect to state
[16:31] <rogpeppe> fwereade_: but should the fields be optional?
[16:31] <rogpeppe> fwereade_: (assuming we can fetch something from $HOME)
[16:31] <fwereade_> rogpeppe, input-wise, yes, but a Config with empty authorizedKeys should be an error I think
[16:32] <rogpeppe> fwereade_: agreed
[16:32] <rogpeppe> fwereade_: ah, and that's why i put authorized-keys everywhere
[16:33] <rogpeppe> fwereade_: because we can't rely on any being in the testing user's home
[16:33] <fwereade_> rogpeppe, yeah
[16:34] <fwereade_> rogpeppe, that has tripped up a fair number of users I know about
[16:34] <fwereade_> rogpeppe, so, probably, a whole bunch more that never said anything ;)
[16:35] <rogpeppe> fwereade_: it's awkward to make the dummy provider add a authorized-keys default
[16:37] <rogpeppe> fwereade_: i wonder if we should set $HOME=/tmp/something in every test suite
[16:37] <fwereade_> rogpeppe, +1
[16:38] <fwereade_> rogpeppe, c.MkDir() anyway
[16:38] <rogpeppe> fwereade_: yeah
[16:39] <rogpeppe> func init() {os.Setenv("HOME", "/dsvfkdsalewnfcldsakj") } :-)
[16:39] <fwereade_> haha
[16:40] <rogpeppe> fwereade_: should default-series be optional?
[16:40] <rogpeppe> fwereade_: (defaulting to environs.CurrentSeries, if so, presumably)
[16:40] <fwereade_> rogpeppe, I think that's OK to get from there, yeah
[16:51] <rogpeppe> fwereade_: "
[16:51] <rogpeppe> it shouldn't
[16:51] <rogpeppe> even be possible to look at a Conn's Environ's config, because it is likely to
[16:51] <rogpeppe> be wrong.
[16:51] <rogpeppe> "
[16:51] <rogpeppe> what do you mean by that?
[17:01] <rogpeppe> i'm off for the weekend.
[17:01] <rogpeppe> have a great weekend everyone!


[00:02] <greg-g> brousch: so, what was broken for you?
[00:02] <greg-g> when I resume form suspend I have to ctrl+alt+F1 then c+a+F7 to get a non-black screen
[00:02] <brousch> in xubuntu or in ubuntu one music?
[00:05] <greg-g> I guess xubuntu (figured you wree refering to Ubuntu)
[00:05] <snap-l> greg-g: Jesus, how do you keep up with the cc mailing lists?
[00:05] <snap-l> high traffic, high strawman
[00:05] <brousch> it locks up on suspend
[00:06] <brousch> so i have to hibernate, which takes like 5 minutes to reccover from
[00:07] <greg-g> brousch: ah
[00:07] <greg-g> snap-l: well, right now, I'm terribly behind
[00:07] <greg-g> ML is doing a great job, from the little I read
[00:07] <brousch> also the volume indddicators are worthless. they always show it at 0
[00:07] <snap-l> Yeah, he is, but man...
[00:07] <greg-g> yeah, I know, the craziness come out of the woodwork during this process
[00:08] <greg-g> s/craziness/crazies/
[00:08] <snap-l> Have tocommend you folks on handling the hypotheticals
[00:08] <snap-l> "What if I package my music inside the anus of a panda bear, but the panda bear is really, really crotchety"
[00:09] <snap-l> "is that the same as distribution if I send the panda bear to my brother's place, and upon arrival, it plays Brad Sucks?"
 "No, brousch, you're not here."
[13:20] <Wolfger> That would have been creepy if I looked around and he was standing there behind me.
[13:23] <snap-l> rick_h__: Did you see today's Woot?
[13:23] <rick_h_droid> yes...
[13:23] <jrwren> i wonder what ubuntu's cash situation is. could they afford to buy the IP from nv/ati and hire devs to write good drivers?
[13:24] <brousch> seems expensive. i can get a nook color for that price
[13:24] <snap-l> brousch: Yeah, but you get the largest screen of all of them
[13:24] <rick_h__> eink > *
[13:24] <brousch> black and white
[13:24] <brousch> i need color damnit
[13:25] <snap-l> brousch: Right, so no Angry Birds for you.
[13:25] <rick_h__> i think we've hashed this over before
[13:25] <jrwren> why do you need color in a book reader?
[13:25] <rick_h__> sorry, saw the nook tablet last night and those jaggy's would kill me in reading
[13:25] <brousch> magazines. kids books.
[13:25] <snap-l> rick_h__: They're not that bad
[13:25] <jrwren> true. distro is beautiful in color, so is flipbook.
[13:26] <jrwren> but if you are reading like an adult... eink is excellent replacement for paperbacks
[13:26] <rick_h__> snap-l: yea, maybe over time I'd get used to it, but just in skimming there last night it was distracting
[13:27] <jrwren> i had a similar reaction to a non antialiased line recently.
[13:27] <jrwren> i thought, "why the fuck can I see the pixels jagged?"
[13:29] <snap-l> The only time I really notice it is in italicized text.
[13:29] <brousch> also having the kindle reader+nook reader+fb reader + the whole google  and amazon android markets is just nice
[13:32] <rick_h__> snap-l: it's done...
[13:32] <snap-l> rick_h__: The deed?
[13:32] <rick_h__> yea
[13:32] <snap-l> Uh oh
[13:32] <snap-l> Erica know? :)
[13:32] <rick_h__> not yet
[13:32] <snap-l> We have a couch and wifi if you need it. :)
[13:32] <rick_h__> lol
[13:33] <rick_h__> well hopefully she'll use it as well so it's part experiment for her demands
[13:33] <rick_h__> but we'll see
[13:33] <rick_h__> it's the lowest price I've seen for one even used so wtf
[13:33] <snap-l> Blame me as an accomplice. :)
[13:33] <brousch> like living before lightbulbs
[13:34] <snap-l> rick_h__: You know what this means?
[13:35] <rick_h__> snap-l: yes...a new one will be out Jan 5th
[13:35] <snap-l> Amazon will blow out of their refurbs at $199, and then do a complete refresh on the line and make it $250.
[13:35] <snap-l> It'll be the Kindle Touch DX
[13:35] <brousch> kindle DY announced for April 1. color e-ink for $249
[13:36] <snap-l> brousch: Mean
[13:36] <snap-l> Somehow I don't think the eInk will get color in that form-factor
[13:36] <snap-l> because it'll make a $500 e-ink device.
[13:38] <jjesse> brousch, sad news last year for the train at breton village mall: http://www.mlive.com/business/west-michigan/index.ssf/2011/12/man_behind_breton_village_chri.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+grpress+%28The+Grand+Rapids+Press+Latest+News+%7C+MLive.com%29&utm_content=Google+Reader
[13:39] <Wolfger> color would be nice for magazine subscriptions, but I can't think what other purpose color serves in e-book readers. I'm certainly not willing to pay a $100 (or more) premium for color.
[13:39] <snap-l> jjesse: Aw, that's sad, but very cool
[13:39] <jjesse> yeah its an awesome train setup
[13:39] <snap-l> I hope someone takes his enthusiasm
[13:40] <snap-l> DeVries said he plans to sell his pieces at auction or on eBay.
[13:40] <snap-l> Oh, that's a bummer.
[13:40] <jjesse> did i post pictures to google+?
[13:41] <jjesse> i know i did to facebook
[13:43] <snap-l> I didn't.
[13:48] <brousch> jjesse: at least we got to meet him. i made sure george thanked him for doing it
[13:48] <jjesse> we wrote a note in the book each year thanking him
[13:48] <jjesse> would be nice if someone bought the entire set and set things up
[13:48] <jjesse> but i bets its a lot of work
[13:53] <brousch> just moving it in and out is huge
[13:57] <brousch> imagine the space he has at home to store it
[14:20] <snap-l> That's why God invented Garages.
[14:20] <brousch> this would fill a 3 stall garage
[14:23] <snap-l> Is it sad that the most useful plugins I have for Firefox / Chrome are reloading plugins?
[14:23] <brousch> not bookie?
[14:24] <snap-l> Should have clarified: for work
[14:25] <brousch> my thumbnail database for digikam is 800MB
[14:25] <brousch> this does not make dropbox happy
[14:27] <Wolfger> lol
[14:27] <snap-l> 800mb of small files?
[14:27] <brousch> sqlite
[14:27] <Wolfger> what... dropbox and not Ubuntu One?
[14:28] <brousch> i suspect ubuntuone would choke and die on something like that
[14:30] <brousch> i moved it out of a synced folder. that should be better
[14:31] <brousch> it's cool that digikam gives me that level of control
[14:31] <brousch> it looks like it can also use a mysql DB
[14:31] <snap-l> so does a little thing called "UNIX"
[14:32] <snap-l> they're called "links"
[14:35] <Wolfger> snap-l: how does a link allow you to move something out of a folder?
[14:35] <snap-l> move something out of the folder
[14:36] <snap-l> do ln -s new_location old_location
[14:36] <Wolfger> but wouldn't the sync also follow that link?
[14:37] <brousch> i don't think so with dropbox
[15:36] <Wolfger> Why have I never heard of this before? http://freedesktop.org/software/pulseaudio/pavucontrol/
[15:37] <Wolfger> (and why do the standard sound controls in Ubuntu suck so badly?)
[15:37] <snap-l> Wolfger: Heh
[15:46] <brousch> ahahah, i like that someone suggested Python to jrwren after his Ruby complaint, and it wasn't even one of us
[15:47] <rick_h__> lol
[16:04] <brousch> heyhey! i have an ubuntuone indicator in my system tray again. life is good! https://launchpad.net/one-indicator
[16:05] <brousch> i can right-click it and see wtf it is doing
[16:06] <jrwren> haha, nice.
[16:06] <jrwren> i didn't see that.
[16:09] <snap-l> rick_h__: thanks for the link to the U1DB stuff
[16:10] <snap-l> Looks interesting
[16:10] <jrwren> ok, i read twitter, and I still didn't see anyone suggest python.
[16:14] <snap-l> http://www.reddit.com/r/politics/comments/nmnie/godaddy_supports_sopa_im_transferring_51_domains/
[16:15] <jrwren> oh, mulka
[16:16] <jrwren> i xfer from godaddy for lots of other reasons.
[16:16] <jrwren> this is just another.
[16:16] <brousch> jrwren: https://twitter.com/#!/JayRWren/status/149872281617838080
[16:17] <snap-l> Also, Pearson Education supports sopa
[16:24] <rick_h__> snap-l: see twitter RT from dmarsh if you have a second. Wonder what you and the wife used perhaps?
[16:25] <snap-l> JoDee's been using GNU Fortran
[16:26] <snap-l> _stink_: Got any insight?
[16:30] <brousch> Ah, a banner year. I moved all of my domains off of Register.com and GoDaddy
[16:30] <jrwren> yeah, maybe I'm naive, but I'd think GNU Fortran is the definitive modern compiler.
[16:30] <jrwren> but I always think gnu compilers are the definitive modern, and sometimes that just isn't true.
[16:31] <snap-l> WEll, I think the performant Fortran compilers are Intel's compilers
[16:31] <snap-l> but my info is about 10 years old.
[16:32] <jrwren> i think anyone doing fortran for perf reasons needs to take their head out of the sand
[16:33] <snap-l> heh
[16:36] <snap-l> Man, now I feel dirty reading Doug Hellmann's book.
[16:37] <brousch> you're not dirty for reading it, just for buying it
[16:38] <rick_h__> snap-l: huh?
[16:38] <snap-l> Addison Wesley is part of Pearson Education, which supports SOPA.
[16:39] <brousch> BURN IT
[16:39] <snap-l> It's an eBook
[16:39] <jrwren> yeah, i just saw tim orielly's tweet.
[16:40] <rick_h__> snap-l: ah, gotcha
[16:40] <snap-l> I retweeted.
[16:40] <jrwren> that is how I saw it.
[16:40] <snap-l> It was two weeks ago that he mentioned it.
[16:40] <brousch> rm isn't nearly as spectacular as burning, so i recommend you open it on a kindle and burn the kindle
[16:44] <snap-l> brousch: You're too kind. :)
[17:05] <Scott_firebeta> any reason GoDaddy is supporting SOPA?
[17:06] <snap-l> other than terminal idiocy, not sure.
[17:09] <Wolfger> because if your domain gets banned, you'll buy a new one
[17:23] <snap-l> Making room on my shelves for non-SOPA supporters. :)
[17:25] <snap-l> Although justifying keeping the Art of Computer Programming / Stevens books because Pearson hadn't purchased them yet. ;)
[17:30] <greg-g> :)
[17:31] <snap-l> Argh, Chris Crawford's book is on New Riders, a Pearson imprint. :(
[17:31] <snap-l> principles, or idolizing a game developer that I tried to go out as for Halloween.
[17:31] <snap-l> when I was in Fifth Grade.
[17:32] <greg-g> :( this is why Free Software is always seen as extreme. Sticking by your principles gets hard and looks weird
[17:34] <snap-l> Yeah, no kidding.
[17:36] <brousch> and then you look like an asshat because you make people realise the things they love are evil
[17:38] <snap-l> Well, Chris Crawford wins out
[17:38] <snap-l> though I shall read it with disdain. :)
[17:42] <snap-l> I'm putting "Publisher Supports SOPA" in the comments field of my listing.
[17:42] <snap-l> Man, I really hope O'Reilly never becomes evil.
[17:45] <Scott_firebeta> is Apress evil?
[17:46] <snap-l> Not to my knowledge.
[17:48] <snap-l> http://www.thedominoproject.com/2011/12/who-wants-to-break-the-internet.html
[17:49] <brousch> that would be more useful with links
[17:49] <brousch> wtf is ABC?
[17:49] <snap-l> Disney
[17:50] <Scott_firebeta> ESPN is on the list as well
[17:50] <Scott_firebeta> another Disney company
[17:50] <Scott_firebeta> NFL (I can see why they support SOPA)
[17:53] <brousch> now i can boycott football on principle instead of just because i find it uninteresting?
[17:54] <snap-l> But of course
[17:55] <Wolfger> I think that if you want to boycott people who support SOPA you will never see another movie again, nor watch any TV
[17:55] <Wolfger> listen to very little music
[17:55] <Wolfger> and reduce your availability of reading material
[17:55] <snap-l> I'm doing it with books
[17:56] <snap-l> unfotunately, if I did it with DVD / CDs, I'd have to sell everything. :)
[17:56] <Wolfger> yep
[17:56] <snap-l> And I'm already making compromises.
[17:56] <Wolfger> Just go to Wall Street and get pepper-sprayed. It's less painful, and slightly more effective.
[17:56] <snap-l> Penguin group has about a billion imprints.
[17:57] <brousch> it makes sense to target companies that you think can be swayed
[17:57] <brousch> like tech book publishers
[18:01] <snap-l> That's my intent
[18:01] <snap-l> Also, quite frankly, it gets me some shelf space, and gets rid of books that I'm not really reading. ;)
[18:02] <snap-l> *cough* opportunistic asshole *cough*
[18:02] <brousch> i'm quoting that on twitter now
[18:02] <snap-l> ;)
[18:02] <Wolfger> Oooh, nice and cheap: www.amazon.com/Out-Later-Years-Philosopher-ebook/dp/B004Q9U0L0/ref=br_lf_m_1000706171_1_4_ttl
[18:03] <Wolfger> snap-l: getting rid of what you've already bought has no effect, really. They got your money.
[18:03] <snap-l> I know, but they also hate the used market with a passion. :)
[18:04] <brousch> what would you do if amazon supported sopa?
[18:05] <snap-l> Die a lot inside.
[18:08] <snap-l> And then take everything over to John King Books
[18:11] <Wolfger> I would have to imagine Amazon is violently opposed to SOPA. I mean, if they are found to be selling a book that infringes on a copyright, they could be shut down, right?
[18:11] <snap-l> Oh yeah
[18:21] <snap-l> http://www.reddit.com/r/circlejerk/comments/nlieb/why_is_sopa_being_passed_while_im_upvoting_all_of/
[18:23] <greg-g> wait a second, what the hell is the image at the bottom of that page?
[18:23] <greg-g> of the circle of aliens
[18:24] <snap-l> Um....
[18:24] <snap-l> http://www.reddit.com/r/circlejerk
[18:24] <snap-l> I guess it's a little too late to say NSFW?
[18:24] <greg-g> lol
[18:24] <Wolfger> Didn't see any image.
[18:25] <Wolfger> Could be that it was blocked from loading.
[18:25] <snap-l> scroll all the way down
[18:25] <Wolfger> and now somebody in IT is asking why I'm trying to look at such a thing
[18:26] <brousch> look at the name
[18:26] <brousch> it's your own fault
[18:26] <greg-g> who reads URLs anymore?
[18:27] <brousch> :P
[18:39] <Wolfger> I read the URL. It said Reddit. :-p
[18:39] <Wolfger> I know Reddit is allowed at work (don't ask me why), so I clicked.
[18:40] <snap-l> Apress information: http://en.wikipedia.org/wiki/Springer_Science%2BBusiness_Media#Selected_imprints
[18:48] <Wolfger> http://askubuntu.com/questions/89673/busybox-v1-18-4-ubuntu-11-18-4-2ubuntu2-built-in-shell-ash-enter-help-for-a
[18:49] <snap-l> That first paragraph makes no sense.
[18:51] <brousch> they never do, until jcastro comes along and deciphers them
[18:56] <Wolfger> I love the part where he switches to caps-lock and starts swearing, like that will get people to help him faster...
[18:57] <snap-l> WHAT, DOESN'T THAT WORK?
[18:57] <Wolfger> was tempted to edit it to put everything in proper case and remove all swear words, but I just flagged it instead.
[18:58] <Wolfger> I feel for the guy, but there's really no excuse for that.
[19:05] <Wolfger> I think I am in love with Louis C.K. http://money.cnn.com/2011/12/22/technology/louis_ck_million/index.htm?source=cnn_bin
[19:18] <greg-g> snap-l: ah, apress is an imprint of springer? Spring is a mostly-OK (not great, maybe not good, depending on the day/journal) scholarly publisher
[19:18] <greg-g> s/Spring/Springer/
[19:21] <snap-l> greg-g: Yeah, most of these publishers have a lot of evil streaks to them
[19:21] <snap-l> btw: just made $90+ trading in a book back to Amazon.
[19:22] <rick_h__> snap-l: sweet
[19:22] <rick_h__> next round at CHC is on snap-l everyone :)
[19:22] <snap-l> That'll pay for the Morgan Kauffman replacement. :)
[19:22] <snap-l> Pffffft.
[19:31] <_stink_> snap-l: not really - i do recall having trouble making cernlibs work with gfortran.  that was maybe 3 years ago
[19:42] <jcastro> Wolfger: I just edit out the bad stuff
[19:42] <jcastro> but I was at lunch
[19:46] <Wolfger> slacker
[19:55] <greg-g> yay, last conf call for the year starting in 5 minutes!
[19:55] <greg-g> (watch, I just jinxed it)
[19:56] <snap-l> (yeah, that would do it. :) )
[20:28]  * ColonelPanic001 extends welcome to The_Machine
[20:32] <rick_h__> jcastro: hey, sorry to bug you but my new ultrasharp arrived an my time spent last night didn't get me anywhere.
[20:32] <rick_h__> any idea where I can take this? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/906441
[20:33] <rick_h__> seems to have a few people out there with the same issue, not sure where to head for irc/docs to debug getting vesa vs intel
[21:05] <snap-l> http://rpg.drivethrustuff.com/product_info.php?products_id=97688
[21:05] <snap-l> Merry Krampus. :)
[21:05] <snap-l> (and CC licensed)
[21:55] <The_Machine> It's alright, i know what you mean


[04:37] <Oooohboy> hello all, can anyone point me to a doc that has instructions for a backtrace when wayland is crashing completely? What do I need to gather for an effective bug report here?
[06:34] <oSoMoN> good morning desktoppers
[06:41] <tsimonq2> Heya oSoMoN, how goes it?
[06:42] <duflu> Morning oSoMoN, tsimonq2
[06:42] <tsimonq2> Heya duflu
[06:46] <oSoMoN> hey tsimonq2, I'm good, how are you?
[06:46] <oSoMoN> good afternoon duflu
[06:46] <tsimonq2> oSoMoN: Pretty good.
[07:17] <didrocks> good morning
[07:21] <duflu> Morning didrocks
[07:22] <didrocks> hey duflu
[07:23] <oSoMoN> salut didrocks, ça va?
[07:24] <didrocks> hey oSoMoN, les acouphènes ont pourri mes vacances, mais bon, c'est la vie… et toi ?
[07:31] <oSoMoN> zut :/ moi ça va, j’ai pris des semi-vacances avec deux semaines consécutives de trois jours, ça fait du bien
[07:39] <jibel> Bonjour didrocks !
[07:39] <didrocks> salut jibel
[07:40] <jibel> didrocks, bien reposé malgré les acouphènes ?
[07:41] <didrocks> jibel: à part ça, les vacances étaient bien, oui :)
[07:41] <didrocks> et ici, tout s'est bien passé ?
[07:44] <jibel> ras
[07:54] <duflu> Also hi jibel
[07:54] <jibel> Hi duflu
[07:59] <seb128> good morning desktopers
[08:03] <oSoMoN> good morning seb128
[08:03] <seb128> lut oSoMoN! en forme ? bon w.e ?
[08:04] <seb128> t'es tjs en France ?
[08:05] <oSoMoN> seb128, la forme! je suis rentré vendredi soir
[08:05] <oSoMoN> et toi, bon week-end?
[08:08] <seb128> ah, je pensais que tu passais le w.e encore là bas, tu me diras faut bien rentrer à un moment
[08:08] <seb128> ouais, on était invité à un mariage samedi et j'avais un match de tennis vendredi soir que j'ai dû finir hier parce qu'il a commencé à tomber des cordes et qu'on a dû arrêter
[08:18] <oSoMoN> I'm seeing PDF documents being opened by default with libreoffice-draw instead of evince in a cosmic VM, known issue?
[08:19] <seb128> no
[08:19] <seb128> is that from nautilus ?
[08:19] <seb128> or from a webbrowser ?
[08:19] <seb128> also new user ?
[08:22] <seb128> oSoMoN, gio info <...> | grep content-type and "gio mime <typecopied>"
[08:23] <oSoMoN> gotta change diapers, back in a moment with more info
[08:29] <seb128> lol, I had forgotten the context when I first read that, I was like "why does he want to give us more info about the diaper!" :)
[08:29] <duflu> There was a bug about totem opening PDFs by default recently, but it wasn't high quality enough for me to recommend reusing that bug
[08:30] <duflu> So I guess the problem is just when evince isn't #1
[08:33] <duflu> oSoMoN, is evince installed?
[08:33]  * duflu wonders if priority is affected by package installation order
[08:33] <oSoMoN> yes
[08:34] <oSoMoN> libreoffice-draw.desktop is first, org.gnome.Evince.desktop is second
[08:34] <oSoMoN> it's a rather stock cosmic VM, installed fairly recently and upgraded daily
[08:35] <jamesh> oSoMoN: iirc, the application chosen is effectively random if two apps claim the same mime type and there is no defaults file to break the tie
[08:37] <duflu> oSoMoN, workaround: Right click, Open with other application, Select
[08:37] <duflu> and it will remember
[08:38] <oSoMoN> sure, but it doesn't feel right that evince is not the default
[08:38] <duflu> Yeah
[08:38] <jibel> oSoMoN, I had the same issue but pdf were opened by gimp
[08:38] <jibel> I thought I did something wrong
[08:38] <duflu> Is there even a priority algorithm at all?
[08:38] <duflu> Sounds like there isn't
[08:38] <oSoMoN> jamesh, where should the defaults file go? and which package would be responsible for writing it?
[08:39] <jamesh> hmm.  /usr/share/applications/defaults.list should be forcing it to evince
[08:39] <seb128> I can fix that
[08:39]  * seb128 does
[08:39] <seb128> https://bazaar.launchpad.net/~ubuntu-desktop/desktop-file-utils/ubuntu/view/head:/debian/defaults.list
[08:39] <seb128> still use the old .desktop name
[08:39] <seb128> or we dropped the compat names in cosmic
[08:39] <seb128> let me update that file
[08:40] <jamesh> yep.  It says "application/pdf=evince.desktop" rather than org.gnome.Evince.desktop
[08:41] <duflu> Hmm. Maybe I already applied the workaround on cosmic and forgot
[08:41] <seb128> the default is not deterministic if there isn't a valid one in that config
[08:41] <seb128> so maybe you just are lucky and get evince
[08:42] <jibel> it used to work reliably, my system is a pretty old installation and this behaviour changed recently, like a week or so
[08:42] <seb128> right, we only dropped the compat .desktop recently I think
[08:43] <duflu> jibel, evince upgraded to 3.29.x a week or two ago :)
[08:45] <jamesh> duflu: you should see any manual associations in ~/.config/mimeapps.list
[08:45] <jamesh> or ~/.local/share/applications/mimeapps.list
[08:45] <duflu> jamesh, Thanks. Unfortunately I can't tell manual additions a few minutes ago from those added earlier
[08:46] <duflu> but certainly they are there
[09:00] <seb128> k, fix uploaded in http://launchpadlibrarian.net/385549885/desktop-file-utils_0.23-1ubuntu4_0.23-3ubuntu1.diff.gz
[09:00] <seb128> oSoMoN, ^
[09:03] <duflu> Sounds like no one except early adopters of cosmic will encounter that bug though
[09:05] <seb128> well, before that fix anyone using cosmic would be hit by a wrong/random default for opening pdf & text files
[09:06] <seb128> but it doesn't impact user configs
[09:07] <jamesh> some people might have accidentally got the correct association though
[09:34] <oSoMoN> seb128, thanks
[10:05] <seb128> oSoMoN, so what was the status of the libreoffice update? still having autopkgtest issues?
[10:06] <oSoMoN> seb128, I resolved the autopkgtests issues, I'm now performing some thorough manual testing, and when I'm confident it's good to go I'll file a FFe
[10:07] <seb128> oSoMoN, great, thx :)
[10:08] <oSoMoN> mmm, exporting a doc to PDF works but printing to file (postscript) results in garbled rendering, wondering if this is a LO issue or an evince regression
[10:10] <oSoMoN> ghostscript fails to render too
[10:10] <seb128> could be a ghostscript issue
[10:28] <seb128> RAOF, hey, colord update reminder a week later :)
[10:33] <oSoMoN> ah, that's a LO bug indeed: https://bugs.documentfoundation.org/show_bug.cgi?id=119357
[10:33] <oSoMoN> patch already in 6.1.1, so should be fine
[11:25] <Trevinho> hi didrocks, welcome back :)
[12:19] <oSoMoN> ricotz, does bug #1789202 ring a bell?
[12:49] <ricotz> oSoMoN, can't reproduce it here (using -prereleases ppa build)
[12:50] <oSoMoN> ricotz, I installed libreoffice-base and the crash went away, looks like java is needed?
[12:52] <ricotz> oSoMoN, hmm, maybe some database libraries which are shared
[12:54] <oSoMoN> aha, indeed when I want to insert a field the dialog opens on a "databases" tab
[12:54] <oSoMoN> that's new in 6.1 I think, it used to open on the first tab ("Document")
[13:14] <didrocks> thanks Trevinho!
[13:24] <seb128> hey Trevinho :)
[13:24] <Trevinho> hi seb128
[13:27] <seb128> Trevinho, how are you?
[13:27] <Trevinho> good thanks, you?
[13:41] <seb128> I'm good thanks
[15:56] <oSoMoN> seb128, FYI, the LO FFe bug is bug #1789240


[03:24] <Rinchen> Nixternal - are you going to the summit in SJ? So far I'm the only one on the list...still :-)
[03:25] <nixternal> don't know just yet
[03:25] <Rinchen> I was going to get tickets soonish, like this week, to keep the cost low
[03:25] <nixternal> that is midterm time for me, so i could only be there for 1 day
[03:26] <Rinchen> I was hoping to work on Marketing/Bugs/LoCo specs and such but so far nobody from any of my projects, besides Canonical folks like Corey, are going.
[03:27] <Rinchen> So I'm debating attending now since I wouldn't have a workgroup.
[03:27] <nixternal> im going to try hard to make it for at least one day
[03:27] <Rinchen> expensive to fly in and out for a day or so you know.  :-)
[03:28] <Rinchen> I suspect worst case I could be Jono's community slave
[03:28] <nixternal> $300 give or take
[03:33] <Rinchen> $300 for the flight but the hotel is a killer
[03:40] <Rinchen> I fired off a note to Jono to see if he needs help. :-)
[03:55] <Burgundavia> hmm, I don't work for Canonical
[03:55] <lophyte> hey Burgundavia
[03:56] <Burgundavia> hey lophyte
[03:56] <lophyte> how's it going?
[03:56] <Burgundavia> not bad
[05:05] <johnlittle> http://johnlittle.org/working_late
[05:06] <johnlittle> im setup for making vids now..muhahaha
[05:06] <Flannel> johnlittle: then what are you doing here?  go make videos!  slacker. sheesh.
[05:07] <johnlittle> I would if it wasnt bedtime :)
[05:07] <johnlittle> getting up before dawn for the CC meeting wiped me out
[05:36] <johnlittle> ++6
[11:16] <digitalmouse> greetings programs! :)
[05:23] <elkbuntu> hi nixternal
[05:23] <nixternal> well howdy there ;)
[05:24] <elkbuntu> well.. yesterday morning
[05:24] <Kamping_Kaiser> well... this morning
[05:25] <elkbuntu> no... its aproximately 24 hours ago now
[05:25] <Kamping_Kaiser> 24 hours and 8 minutes
[05:25] <elkbuntu> 24 hours 20 mins
[05:25] <elkbuntu> o.O
[05:25] <Kamping_Kaiser> ooh, conflict ;)
[05:26] <elkbuntu> fabbione logs say 5.09 elmo's ack came through
[05:26] <elkbuntu> s/5.09/5:09/
[05:27] <lophyte> congrats again, elkbuntu ;)
[05:27] <elkbuntu> soryr you missed out lophyte :(
[05:27] <lophyte> yeah, well.. now I get an extra 2 weeks to contribute more
[05:27] <elkbuntu> :)
[05:27] <elkbuntu> you were feeling rushed i believe
[05:28] <elkbuntu> from what you were saying
[05:28] <lophyte> indeed.. Corey only suggested it to me on Sunday
[05:29] <lophyte> but, I think I had/have a better chance at it than some of the guys that were there
[05:29] <elkbuntu> lophyte, no doubt
[05:30] <elkbuntu> advantage one.. your english is fluent
[05:30] <lophyte> good point
[05:32] <lophyte> I'm starting work with the MOTU now.. so maybe in 2 weeks, daniel holbach will have some good words to say about me to add to my credibility
[05:32] <lophyte> hopefully :)
[05:34] <elkbuntu> bwahahaha.. <Kamion> beta2 is crashier than a very crashy thing
[06:14] <MitchM> =P
[08:26] <Bassetts> anyone around?
[08:26] <Bassetts> heh
[08:26] <Bassetts> what the hell is happening with spread ubuntu?
[08:26] <MenZa> Iunno.
[08:27] <Bassetts> brb
[08:30] <MenZa> wb
[08:31] <Bassetts> ty
[08:39] <Burgwork> Bassetts, spread ubuntu has not got off the ground
[08:39] <Bassetts> i guessed
[08:39] <Burgwork> if you want to thelp with other projects, there is the fridge and the UWN
[08:40] <Burgwork> plus there is a need for somebody todo the beta releae page
[08:40] <Bassetts> is spread ubuntu still in planning/ dev though or has it been ditched?
[08:40] <Burgwork> I have heard nothing either way
[08:41] <Bassetts> ok
[08:41] <Bassetts> beta release page for what?
[08:42] <Burgwork> the Edgy Beta release is coming out next week
[08:42] <Burgwork> we need a page for it, like ubuntu.com/testing/knot3
[08:42] <Bassetts> there is one
[08:42] <Bassetts> oh you mean somewhere else?
[08:43] <Burgwork> create the page on the wiki
[08:43] <Burgwork> that knot3 page was written as wiki.ubuntu.com/Edgy/Knot3
[08:43] <Bassetts> ok
[08:43] <Bassetts> so what needs doing
[08:43] <Burgwork> take a look at the style of those pages
[08:44] <Bassetts> yeh
[08:44] <Burgwork> create a page with style, but it needs to cover all the changes in edgy
[08:44] <Burgwork> basically, look at all the knot pages and combine them into one page and then throw out the boring and duplicative bits
[08:44] <Bassetts> so /testing/knot3 needs to be a proper page not a wiki page
[08:45] <Bassetts> the edgy wallpaper looks wayyyy too much like the win logo
[08:45] <Burgwork> no
[08:45] <Burgwork> the page is written on the wiki and then moved to the Ubuntu website
[08:45] <Bassetts> ok...
[08:45] <Burgwork> see the wiki URL I added earlier
[08:46] <Bassetts> yeh
[08:46] <Burgwork> look through the history of that page
[08:47] <Bassetts> it doesnt exist
[08:49] <Burgwork> just a sec
[08:50] <Burgwork> https://wiki.ubuntu.com/EdgyEft/Knot3
[08:50] <Burgwork> look at the history of that page
[08:51] <Bassetts> ok
[08:53] <Bassetts> and?
[08:55] <Bassetts> so basically there needs to be a /testing/beta page for Edgy?
[08:56] <Burgwork> yes, but create it at /EdgyEft/Beta on the wiki
[08:56] <Burgwork> I can do the moving once it is written
[08:56] <Bassetts> right
[08:56] <Burgwork> to be clear, the beta page should cover every major change, especially the user visible ones, since dapper was released
[08:56] <Bassetts> so use the knot pages to find the changes then
[08:57] <Burgwork> yep, and your brain
[08:57] <Burgwork> ask around
[08:57] <Burgwork> think like a reporter
[08:57] <Bassetts> ill see what i can do =)
[08:58] <Burgwork> anything you can do is great
[08:59] <Bassetts> ok
[09:07] <Burgwork> Bassetts, your real name is Jason Licquorish ?
[09:08] <Bassetts> Liquorish
[09:08] <Bassetts> yes
[09:09] <Bassetts> i get called allsorts.... ;-)
[09:09] <Burgwork> right
[09:09] <Bassetts> heh
[09:27] <Bassetts> Burgwork, what template do I need to use for the page?
[09:32] <Burgwork> Bassetts, don't worry about that
[09:32] <Burgwork> copy the knot3 page and start from there
[09:33] <Bassetts> im not too up-to-date with wiki formatting =S
[09:33] <Burgwork> that is why copying it good
[09:33] <Burgwork> play! you have a few days to do so
[09:33] <Bassetts> so copy the code from: https://wiki.ubuntu.com/EdgyEft/Knot3?action=diff
[09:34] <Burgwork> you can look at the raw code any one point
[09:34] <Burgwork> johnlittle, http://news.com.com/Something+different+than+Windows+or+Mac+OS/1606-2_3-6114944.html?tag=fd_carsl
[09:36] <MenZa> ROFL
[09:36] <MenZa> I'm looking at an ad
[09:36] <MenZa> "Sponsored by Microsoft"
[09:36] <MenZa> On Cnet of course
[09:37] <Burgwork> https://wiki.ubuntu.com/EdgyEft/Knot3?action=raw&rev=13
[09:37] <Bassetts> got it
[09:37] <Bassetts> ok research time! =D
[09:38] <Burgwork> excellent
[09:41] <KenSentMe> I found an error on the DIYMarketing page at https://wiki.ubuntu.com/DIYMarketing. Who can i report it to?
[09:41] <Burgwork> KenSentMe, it is a wiki, you can edit it yourself
[09:41] <Burgwork> what is the fix?
[09:42] <KenSentMe> Burgwork: i know. The problem is a link to a quicktour on help.ubuntu.com, but the page doesn't exist and i can see where it should link to
[09:43] <Burgwork> quicktour is dead
[09:43] <Burgwork> kill the link
[09:43] <Burgwork> given I wrote the quicktour, I can comfortably say that
[09:43] <KenSentMe> that means removing the complete line
[09:43] <Burgwork> yep, that is fine
[09:43] <KenSentMe> ok
[09:44] <Bassetts> Corey can you give me some pointers where to find changes
[09:45] <Burgwork> edgy-changes mailing list
[09:45] <Burgwork> reviews of edgy
[09:45] <Burgwork> blog posts of developers
[09:45] <Burgwork> previous Knot pages
[09:45] <Burgwork> specs that are implemented
[09:46] <Bassetts> ok
[10:06] <adamant1988> hello
[10:09] <Burgwork> johnlittle, did you mean to send that email just to me?


[15:38] <ma10> @now
[16:10] <persia> Erm.  That's just not right.
[16:10] <persia> Anybody from the news team around?  Could you populate the calendar a bit?  I *know* there's lots of meetings during the next 30 hours or so.
[17:57] <heno_> Hey everyone
[17:57]  * pedro_ waves
[17:57] <intellectronica> 'alo
[17:57] <LaserJock> hi heno_
[17:57] <heno_> I may have to run in a few minutes
[17:57] <heno_> hey LaserJock
[17:58] <bdmurray> greetings
[17:58] <heno_> pedro_: could you chair the meeting? - in case I need to dash off
[17:58] <pedro_> heno_: yes no problem
[17:58] <LaserJock> pedro_: I think we need to send the meeting emails earlier
[17:59] <LaserJock> it'd be nice if we had the agenda set by Monday and the email sent out Tuesday I think
[17:59] <LaserJock> to allow people who don't normally come but may be interested in specific agenda items
[17:59] <heno_> should we schedule meetings when there are no suggested agenda items?
[17:59] <pedro_> LaserJock: indeed, but we didn't have an agenda till today morning, that's why i didn't send it yesterday
[18:00] <LaserJock> heno_: well, I would propose that unless we have a full agenda a "spec status" roll call would be good to do each meeting
[18:00] <heno_> we may have some standing items of course like, indeed
[18:00] <LaserJock> it's often good if we don't have big agenda items :-)
[18:00] <sbeattie> hey
[18:00] <bdmurray> Or a round table
[18:00] <heno_> also looking toward testing of the next milestone and SRU status
[18:01] <LaserJock> but it's also good to get everybody together, talk about the week
[18:01] <ara> hello
[18:01] <heno_> yay, let's do a round table!
[18:01] <pedro_> yeah
[18:01] <pedro_> ok everybody is here, let's start
[18:01] <pedro_> #startmeeting
[18:01] <LaserJock> I think it's especially nice to find out about blockers :-)
[18:01]  * pedro_ kicks the bot
[18:02] <heno_> I'll go first since I may have to run
[18:02] <davmor2> hello
[18:02] <pedro_> Welcome to the Ubuntu QA Meeting the Agenda for today is at https://wiki.ubuntu.com/QATeam/Meetings
[18:02] <heno_> I was at a Canonical distro team leads sprint all last week
[18:03] <heno_> we discussed the usual admin stuff but also some Ubuntu QA stuff
[18:03] <stgraber> hey
[18:03] <heno_> There is broad agreement that we will ramp up the focus on quality in the releases to come
[18:03] <heno_> I can write more when I get the notes
[18:04] <LaserJock> that's always a good thing? :-)
[18:04] <LaserJock> s/?/!/
[18:04] <heno_> of course!
[18:04] <heno_> oh, not '?'
[18:04] <heno_> heh
[18:04]  * LaserJock plays "punctuation jumble" today
[18:04] <heno_> on monday I was at an LP team sprint as well
[18:05] <heno_> the numbers that we discussed for the LP bugs priorities were presented
[18:05] <heno_> it looks like they have a good process for taking that forward
[18:05] <davmor2> cool :)
[18:06] <heno_> they will decide on actual priorities this week
[18:06] <LaserJock> excellent
[18:06] <pedro_> yay
[18:06] <heno_> ok, that's it from me!
[18:06] <pedro_> thanks
[18:06] <pedro_> ok the next point i see is
[18:06] <pedro_> Ubuntu Developer Week preparations
[18:07] <pedro_> the Ubuntu Developer Week starts next week
[18:07] <heno_> That's just pointing out https://wiki.ubuntu.com/UbuntuDeveloperWeek
[18:07] <pedro_> and there's a few talks from the members of the team
[18:08] <pedro_> anyone wants to give a brief overview about their talk?
[18:08] <LaserJock> I was pleasantly surprised to see Ara scheduled
[18:08] <heno_> and it looks like there are no more open slots
[18:08] <pedro_> bdmurray, ara ?
[18:08] <LaserJock> go ara go! ;-)
[18:08] <ara> pedro_: ok, I'll go
[18:09] <pedro_> rock
[18:09] <ara> I will be presenting the automated testing library that we've been working on
[18:09] <ara> what is exactly, how to use it, etc.
[18:10] <ara> i will be completing the docuementation at https://wiki.ubuntu.com/Testing/Automation/LDTP/HowToUseTestingLibrary
[18:10] <ara> before the session, so people will be able to have some reading after it
[18:11] <ara> what I would like to achieve from the session is making people more involved in testing and more specifically in automated testing
[18:11] <ara> only some very basic python knowledge is required
[18:11] <LaserJock> ara: very nice
[18:12] <pedro_> nice! looking forward to it
[18:12] <pedro_> bdmurray: may you tell us a bit about the launchpad hacks session?
[18:12] <LaserJock> ara: so are you going to be able to go through how people can contribute test scripts?
[18:13] <ara> LaserJock: yes, how to contribute with new scripts that use the library; but not how to extend the library
[18:13] <ara> LaserJock: if I get people willing to contribute also to extend the library, it will be great
[18:14] <bdmurray> pedro_: I plan on talking about recent features added to bughelper / python-launchpad-bugs.  Additionally, I want to talk about all the scripts in the launchpad-gm-scripts project and how they might help you use launchpad.
[18:15] <LaserJock> next time we should get a QA Team overview session
[18:15] <pedro_> cool!
[18:15] <heno_> should we continue the round table?
[18:16] <bdmurray> If so there's one thing I wanted to mention...
[18:18] <bdmurray> I've written a script that checks needs-packaging bugs to see if they are already packged in debian or ubuntu and checks to see if there is a request to have them packaged in debian
[18:18] <bdmurray> I plan on running this on qa.ubuntu.com soon and announcing it
[18:19] <bdmurray> However, one way we can help is ensuring the needs-packaging bugs follow a specific format for the title
[18:19] <bdmurray> for example: [needs-packaging] softwarename ....
[18:19] <heno_> how does it find the package in the archive?
[18:19] <bdmurray> So if you happen to see any that don't follow that convention please modify the title.
[18:19] <intellectronica> bdmurray: why do you want to use the title?
[18:20] <bdmurray> heno_: rmadison
[18:20] <ara> bdmurray: one thing that is unclear from the documentation is that instead of "naming [needs-packaging]" the document reads "tagging [needs-packaging]"
[18:20] <intellectronica> bdmurray: rather than a tag, that is
[18:20] <bdmurray> intellectronica: so it is distinguishable in a list of bugs - both are done
[18:20] <bdmurray> ara: okay, I'll update the documentation
[18:21] <bdmurray> Ideally they'll be tagged needs-packaging and have that prepended to the title
[18:21] <LaserJock> hmm, but how reliable would the title be?
[18:22] <bdmurray> LaserJock: I've modified ~134 needs-packaging bugs which is >10%
[18:22] <bdmurray> So I think it has been pretty successful
[18:22] <LaserJock> bdmurray: you've modified the title of 134?
[18:23] <LaserJock> what I meant was that by definition we don't have a package name for needs-packaging bugs
[18:23] <bdmurray> LaserJock: no, I've linked to upstream bug watches, marked as duplicate or Fix Released 134 bugs
[18:23] <LaserJock> so how do you go from a bug title to finding if it's in the archive?
[18:23]  * heno_ is afk
[18:24] <bdmurray> I assume the 2nd word in the title is the name of the software needing packaging
[18:25] <bdmurray> And that's where help would be useful - ensuring the bug titles follow that convention
[18:25] <LaserJock> bdmurray: right but quite often that's not a great mapping to package name
[18:25] <LaserJock> but consistency is usually a good thing :-)
[18:26] <LaserJock> I'm just worried that if we take a scripted list we'll could have a significant amount of false positives
[18:26] <LaserJock> so then we'd be triaging anyway
[18:27] <davmor2> bdmurray: so bug title Intrepid: xapian doesn't work  and intrepid: bunnys have big ears is cool for you?
[18:28] <davmor2> where bunnys needs packaging sorry
[18:29] <bdmurray> davmor2: heh
[18:29] <hggdh> LaserJock, this is one reason why we would still need the tag -- titles may not work always
[18:30] <LaserJock> hggdh: that's the whole reason why I made the tag in the first place ;-)
[18:30] <hggdh> and this is another reason why we need more tags ;-)
[18:30] <bdmurray> and if a particular ubuntu bug has too many results just skip it or modify the title and it'll get processed in the next run of the script
[18:30] <davmor2> bdmurray: sorry talking at cross purposes missed the first bit just played catch up
[18:31] <LaserJock> bdmurray: ok, so what does your script output?
[18:31] <LaserJock> the bugs where the software exists in Debian/Ubuntu?
[18:31] <bdmurray> The output of rmadison or links and titles of debian bugs
[18:32] <LaserJock> hmm, that just seems so error prone
[18:34] <pedro_> Any other issues?
[18:35] <LaserJock> well, the Testing Day thing is still up in the air
[18:35] <LaserJock> it'd be nice to get something nailed down for that
[18:37] <pedro_> Yes, LaserJock can you send a reminder about it to the ubuntu-qa list ?
[18:37] <LaserJock> k
[18:37] <davmor2> also before I need to dash off the bugs I've come across whilst smoke testing I've collated here https://wiki.ubuntu.com/Testing/DailySmoke/bugs I won't be around next week so if someone can quickly blitz through them and see if there fixed early next week that would be great
[18:37] <pedro_> thanks you
[18:40] <pedro_> alright, thanks davmor2
[18:40] <pedro_> ok it seems we don't have anything else
[18:40] <intellectronica> just a quick one
[18:40] <pedro_> intellectronica: go ahead
[18:41] <intellectronica> has there been any progress on preparation for that bug status migration?
[18:41] <pedro_> intellectronica: i haven't had the time yet to prepare the wiki page, but ill need to do it soon
[18:42] <intellectronica> cool. let me know if you need any help
[18:42] <pedro_> yup , thanks
[18:42] <pedro_> ok , let's wrap then
[18:42] <pedro_> thanks everybody
[18:43] <intellectronica> thanks, pedro_
[18:43] <ara> thanks
[18:43] <bdmurray> thanks
[18:44] <sbeattie> thanks everyone
[19:42] <jjesse> @schedule detroit
[22:56]  * asac first
[22:56] <asac> hi
[22:56] <evand> hi
[22:56] <liw> hi
[22:56] <james_w> hi all
[22:57] <ArneGoetje> morning
[22:57] <calc> hi
[22:57] <cjwatson> evening
[22:58]  * ogra waves
[22:59]  * slangasek waves
[23:01] <cjwatson> bryce: ping?
[23:03] <cjwatson> guess not; let's move on without him for now
[23:03] <bryce> hi
[23:03] <cjwatson> aha
[23:03] <cjwatson> ok, so feature freeze is at some time I'm not entirely certain of, but at any rate within the next day
[23:04] <cjwatson> so now's a good time to look over our team's progress and see what needs to be deferred and what might want exceptions from the release team
[23:04]  * ogra hopes late
[23:04] <james_w> 5 minutes ago I thought
[23:04] <slangasek> 0000 UTC
[23:04] <slangasek> which by my clock leaves us all with 2h :)
[23:04] <cjwatson> I heard COB Wednesday, though personally I'd been shooting for COB Thursday; but I shouldn't imagine a few hours will make a whole lot of difference either way
[23:05] <ogra> slangasek, eeek
[23:05] <james_w> ah, I fail at timezones yet again
[23:05] <cjwatson> so, I asked for a one-line summary of each of your feature goals (something of the form "name of goal: where it's at" would be fine)
[23:06] <cjwatson> how about we go in reverse order, since ogra was expressing concern
[23:06] <cjwatson> ogra:
[23:06] <slangasek> (cjwatson: there was apparently a precedent in the wiki that freezes start at 0000UTC on the given day; we diverged from this for hardy, reinstated now for intrepid, sorry to catch people flat-footed)
[23:06] <ogra> well, still busy getting the latest ltsp upstream changes in
[23:06] <persia> According to my clock, FF is in 114 minutes
[23:07] <cjwatson> slangasek: there were older precedents yet that were different again, of course ;-)
[23:07] <slangasek> heh
[23:07] <cjwatson> we've gone through various interpretations
[23:07] <ogra> my only left goal for intrepid was compcache: implemented and running fine
[23:07] <ogra> (just getting it into ltsp)
[23:07] <cjwatson> that was certainly the only major item
[23:08] <cjwatson> I'm very pleased with how memory use has come out so far on the desktop CD, and I gather there's more room for tweakage
[23:08] <ogra> yeh, definately
[23:08]  * ogra is hoping for 24M ltsp client support
[23:08] <cjwatson> ogra: edubuntu-menus-completion and local-content-filter deferred, I take it?
[23:08] <ogra> yeah
[23:08] <cjwatson> I thought that was likely
[23:09] <ogra> and though i'm likely moving teams now, i'D still like to go after the content filter stuff
[23:09] <ogra> (trying to get to that since the sydney UDS where i had to take edubuntu to actually get the spec :P )
[23:10] <slangasek> heh :)
[23:10] <cjwatson> ogra: on that note, remind me to give you a ring tomorrow
[23:10] <ogra> oki
[23:10] <cjwatson> doko is on holiday
[23:11] <cjwatson> of his feature goals, OpenJDK seems pretty happy at this point barring a few glitches the server team would like to be cleared up
[23:11] <cjwatson> Python 3 was only ever preparation for the future
[23:11] <cjwatson> TheMuso:
[23:11] <TheMuso> dmraid: Complete bar no event monitoring due to broken code and incomplete upstream tarballs.
[23:11] <TheMuso> desktop a11y review: Deferred, dmraid took more time than expected.
[23:11] <doko> Hola
[23:12] <cjwatson> doko: oh, hiya
[23:12] <TheMuso> audio: due to the kernel fuss nothing has been uploaded yet, although things are almost ready on my end, just need to test check and upload alsa pieces.
[23:12] <TheMuso> pulseaudio I'd rather PPA test, and if people really want it, we FF for it.
[23:12] <cjwatson> TheMuso: though dmraid not yet promoted to main - I'll get to that before the deadline
[23:12] <TheMuso> cjwatson: Ok no problem.
[23:13] <cjwatson> right, for those who haven't noticed, the kernel team is pretty set on trying out 2.6.27, but acknowledges the regression risk so we're going to be pretty careful about it
[23:13] <TheMuso> I doubt I can get all of alsa done before FF, but I'll see...
[23:13] <cjwatson> https://wiki.ubuntu.com/KernelTeam/2.6.27-kernel-plan is the plan and timeline
[23:13] <asac> TheMuso: can we at least get a fix for the also through pulseaudio by default thing?
[23:13] <cjwatson> we're going to have to switch up to .27 in intrepid in order to get certification testing done, but that's not necessarily final
[23:13] <asac> TheMuso: otherwise we will end up with flash blocking sound device
[23:14] <asac> TheMuso: i know that the current fix isnt kde compatible.
[23:14] <TheMuso> asac: Yes, I need to reread up on everything to work out what exactly has to be done but yes, that is regardless of pulse version
[23:14] <asac> but maybe that should be solved on a package base somehow (if we cannot find a real solution)
[23:14] <asac> TheMuso: ok. as long as you keep in line tha tthis is really a big show stopper and we need a solution i am happy ;)
[23:15] <asac> s/in line/in mind/
[23:15] <cjwatson> TheMuso: do you have some skeleton disk images that people could use in a vm to do basic dmraid testing?
[23:15] <TheMuso> cjwatson: Yes, but thats not really useful.
[23:15] <cjwatson> something of the form "create zero-filled images, and run this dd command"
[23:15] <TheMuso> Other than testing whether everything fits together.
[23:15] <cjwatson> I would find it very useful to be able to try out the installer and suggest possible improvements
[23:15] <TheMuso> but yes, I do have images.
[23:16] <cjwatson> 23:10 <cjwatson> doko is on holiday
[23:16] <cjwatson> 23:11 <cjwatson> of his feature goals, OpenJDK seems pretty happy at this point barring a few glitches the server team would like to be cleared up
[23:16] <cjwatson> 23:11 <cjwatson> Python 3 was only ever preparation for the future
[23:16] <cjwatson> TheMuso: thanks
[23:16] <cjwatson> doko: anything you want to add? just a very quick run-down
[23:16] <TheMuso> cjwatson: I'm going to blog/post to devel about dmraid anyway, so I will put the images up somewhere for people to download.
[23:16] <cjwatson> TheMuso: great, thanks
[23:17] <doko> cjwatson: I will upload python3 next week, including with a few modules how python3 modules sould be packaged.
[23:17] <doko> I didn't see any critical reports about OpenJDK
[23:18] <cjwatson> the server team wanted to get bugs 261847 and 249178 cleared up
[23:18] <doko> python3 should go to main however, because we want to build modules from one source package
[23:18] <slangasek> that's going to bloat the size of all the python module packages again?
[23:18] <doko> 261847 seems to be controversial
[23:19] <slangasek> I don't see how that can be justified as a post-FF change
[23:19] <doko> slangasek: no, not the binary ones, we'll have python3-XXX binaries
[23:19] <slangasek> hmm, breaking the python policy instead, ok... :)
[23:19] <cjwatson> you can't have the same source used by both python 2 and 3, to a good first approximation
[23:20] <doko> 249178 should be uploaded
[23:20] <cjwatson> so this is really something the python policy failed to predict :)
[23:20] <slangasek> well, ouch
[23:20] <doko> not breaking, but changing.
[23:21] <cjwatson> doko: 249178 is a two-parter, I understand: one using -headless, and one being a recommends change that I understand is disputed
[23:21] <cjwatson> they seem quite upset about all the X libraries being pulled in
[23:22] <cjwatson> I didn't want to overrule you in your absence; in any case this all seems to be under the bug-fix heading
[23:22] <doko> well, yes, maybe we could drop this recommend, now that we have java-gcj-compat and java-gcj-compat-hl. I'll do this next week
[23:22] <doko> I mean: dropping the recomend of libgcj9-0-awt in libgcj9-0
[23:23] <cjwatson> doko: thanks for the update; we'd best move on, as time is pressing
[23:23] <cjwatson> liw:
[23:23] <liw> CleanupCruft: package almost ready, gui sucks but works, need to find how to do root from gui
[23:23] <liw> DebianPolicyInDocbook: ignored
[23:23] <liw> FastLsbRelease: ignored
[23:23] <liw> GetRidOfPythonCentralAndSupport: not ready, lots of work needed
[23:23] <liw> GobbyServerPersistentState: my patch works, upstream now maintains package and has corresponding patch (which I should review)
[23:23] <liw> LintianHarness. ignored
[23:23] <liw> NoFsckAtBoot: deemed semi-impossible, but ubuntu-devel(-discuss) has had similar discussions
[23:23] <liw> PythonProfilingTool: playing with Heapy (it does work!), but no concrete results
[23:23] <liw> SuperPiuparts: deferred
[23:24] <cjwatson> perhaps somebody could help liw out with the last bits needed for cleanup-cruft
[23:24] <asac> what is needed?
[23:24] <james_w> policykit?
[23:25] <liw> should I run gksu (what update-manager seems to do currently) or go straight for policykit?
[23:25] <asac> ah ... root from gui ;)
[23:25] <slangasek> AIUI we're well on the path for transitioning to policykit, so better if new stuff uses that?
[23:25] <james_w> liw: policykit, though it may require architecture changes
[23:26] <james_w> and may require frustration
[23:26] <liw> ok, policykit it is (unless it looks too difficult, in which case I'll go for gksu, call it a bug, and fix it to use policykit later...)
[23:26] <TheMuso> Policykit please, for accessibility reasons.
[23:26] <TheMuso> gksu is not an option. :p
[23:27] <james_w> I know pitti recently converted to policykit, so he may be able to help, and I have a basic knowledge, so I'll help if I can
[23:27] <cjwatson> pitti is on holiday at the moment
[23:27] <liw> james_w, thanks, that'll be helpful
[23:27] <cjwatson> as is, I gather, most of the desktop team :P
[23:28] <cjwatson> liw: thanks, better to get system-cleaner into the archive while a bit suboptimal than to leave it until it's too late; we still have time for bug-fixing and polishing provided the basic functionality works
[23:28] <liw> cjwatson, ack
[23:28] <cjwatson> james_w: it's been a while since we talked about UDD. What's the good word?
[23:29] <james_w> I've got bzr-builddeb 2.0 in bzr since about an hour, that has the features I think we need for Intrepid.
[23:29] <james_w> I'd love a sponsor (perhaps for Debian as well, but that's less important)
[23:30] <james_w> if not I can get an FFe and have my usual sponsor upload
[23:30] <cjwatson> I don't see it on https://code.edge.launchpad.net/bzr-builddeb ?
[23:30] <james_w> the rest is not bound by feature freeze, and hasn't moved in the last couple of weeks
[23:30] <asac> bzr http mirror syncs are broken i think
[23:31] <cjwatson> hmm, worked for me earlier today
[23:31] <asac> strange. then thats just affecting the mozillateam branches ;)
[23:31] <james_w> cjwatson: I also tried to upgrade the alioth branch that it mirrors from at the same time, so there may be a delay
[23:31] <asac> (but havent checked today)
[23:31] <james_w> http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk if anyone is interested
[23:32] <slangasek> interested, but otherwise occupied at the moment
[23:32] <cjwatson> james_w: I'll be up for a little while after the meeting, and can sponsor
[23:32] <james_w> cjwatson: great, thanks
[23:32] <cjwatson> bzr: ERROR: No repository present: "http://bzr.debian.org/pkg-bazaar/bzr-builddeb/trunk/"
[23:32] <cjwatson> EHOSEDBRANCH
[23:32] <james_w> cjwatson: just fixed that, there's a bug in bzr I'll report
[23:33] <slangasek> not EHOSEDHOSTING?
[23:33] <slangasek> (I can't seem to get http transport to work for bzr.debian.org for my stuff, maybe I'm doing it wrong)
[23:33] <cjwatson> slangasek: I shall withhold my comments on the delays involved in getting new branches created on bzr.d.o
[23:33] <james_w> slangasek: try nosmart+http://
[23:33] <james_w> slangasek: *another* bzr bug, fixed in 1.6
[23:34] <james_w> which leads me to
[23:34] <slangasek> james_w: hum, ok :/
[23:34] <james_w> bzr* updates: all lined up as sponsored sync requests, thanks to LaserJock and jelmer. Probably bugs to fix in 1.6, but we definitely want its features. We shou
[23:34] <james_w> ld evaluate 1.7 in 3 weeks.
[23:34] <james_w> slangasek: assuming it's the bug I think it is.
[23:34] <slangasek> james_w: I don't suppose we'll get 1.6 into lenny...?
[23:34] <slangasek> (I imagine not)
[23:34] <cjwatson> just about every problem I've run into in the last couple of weeks has been "fixed in 1.6"
[23:34] <james_w> slangasek: it's in experimental, but no-ones pushing for it
[23:34] <cjwatson> (including the ones that had nothing to do with bzr)
[23:35] <slangasek> cjwatson: fwiw, I haven't had problems with getting bzr setups done for bzr.d.o
[23:35] <james_w> slangasek: I should investigate backporting the fix.
[23:35] <james_w> 1.6 was a real pain of a release, I think it may have reached 4 months.
[23:35] <james_w> pretty bad for a monthly release project
[23:37] <james_w> the rest of my list:
[23:37] <james_w> font-selector: nowhere, sorry.
[23:37] <james_w> lvm .39: done, thanks to TheMuso.
[23:37] <james_w> mono-tools: still needs MIR for webkit-sharp, though could be sponsored as-is I
[23:37] <james_w> believe.
[23:39] <cjwatson> james_w: ok, thanks
[23:39] <cjwatson> evand:
[23:39] <evand>  * usb-installer-images: Mostly finished.  I just need to figure out
[23:39] <evand> why an io_watch isn't promptly firing, polish the code and UI, and
[23:39] <evand> pick a name (suggestions welcome).  This will be done in time for the
[23:39] <evand> feature freeze cutoff Thursday.
[23:39] <evand> (written before the above conversation)
[23:39] <evand>  * dvd-performance-hacks: Mostly done.  Just need to merge in my
[23:40] <evand> ubiquity changes and triggerize packages.
[23:40] <evand>  * ubiquity-visual-refresh:  The partition bar work has been committed
[23:40] <evand> to ubiquity trunk.  I did not manage to coordinate the slideshow work
[23:40] <evand> in time and will have to defer that (though I'll continue working with
[23:40] <evand> the art and documentation team to obtain the required media for it
[23:40] <evand> during the remainder of the 8.10 cycle).  I am going to apply for a
[23:40] <evand> feature freeze for the timezone map changes for over the weekend as
[23:40] <evand> I'm having some difficulty with rsvg and locating the mouse within a
[23:40] <evand> particular time zone.  If the work fails to produce effective results,
[23:40] <cjwatson> slangasek: the usb installer stuff is largely (afaik) a new package, so I think the regression risk is pretty low; can we manage the one-day slip there?
[23:40] <evand> I will work to fix the remaining usability bugs in the previous
[23:40] <evand> timezone map.
[23:41] <slangasek> cjwatson: yes
[23:41] <evand> thanks
[23:41] <cjwatson> evand: if you could push the ubiquity branch for dvd-performance-hacks somewhere, I can have a look at it for you
[23:41] <TheMuso> Speaking of slips, I can get alsa uploaded today, but it won't all be before FF. Is this ok?
[23:42] <liw> /msg evand name suggestion for the usb thing: gloffod (glorious freedom from optical disks)
[23:42] <evand> cjwatson: will do
[23:42] <doko> james_w: pitti and I will clean up MIRs next week
[23:42] <slangasek> TheMuso: what part is going to be past FF?
[23:42] <james_w> doko: great, I'll try and get it written before then
[23:42] <evand> thanks liw, any other suggestions?
[23:42] <TheMuso> slangasek: Getting lib/utils/plugins in.
[23:43] <cjwatson> evand: I'm looking forward to having a look at the partition bar work; you should blog about it :)
[23:43] <evand> (can be mailed so we don't eat up time here)
[23:43] <slangasek> TheMuso: hmm, you said it won't /all/ be before FF... will /any/ of it be before FF? :)
[23:43] <evand> cjwatson: blog?  I don't think I've done that since Summer of Code ;)
[23:43] <cjwatson> yes, I know ;-)
[23:43] <asac> slangasek: i think he ment that this upload will take a few more hours
[23:43] <asac> (but thats just what i read from it)
[23:43] <TheMuso> slangasek: lib likely will be yes.
[23:43] <asac> oh ok ;)
[23:44] <slangasek> TheMuso: ok.  yes, that'll be alright.
[23:47] <cjwatson> on my own bits:
[23:47] <cjwatson> recommends-by-default: germinate updated and all seems to be working, although some people have requested the ability to exempt certain recommendations from CD building. We may be able to do something about tha
[23:48] <cjwatson> t.
[23:48] <cjwatson> splitting server and mobile into separate branches and metapackages: not done, will probably wait for archive-reorganisation.
[23:48] <cjwatson> archive-reorganisation: call tomorrow morning with Mark to iron out some details. I think we have high-level agreement though and it's on the LP 3.0 plan.
[23:48] <cjwatson> policy-and-standards: initial version of Ubuntu policy uploaded; need to reinstate pristine debian-policy and repackage but that's no big deal.
[23:48] <ogra> recommends-by-default, any idea what to do with the lilo dep of linux-image-* ?
[23:48] <cjwatson> also been helping out the server team with some installer bits, but I think my end is done and any FFEs they need are their business :)
[23:49] <slangasek> ogra: I think that's wrong under the definition of Recommends and should be dropped?
[23:49] <TheMuso> 5~/c
[23:49] <ogra> slangasek, well, lilo seems to be still wanted ...
[23:49] <cjwatson> you can also use --no-install-recommends as a stopgap measure
[23:49] <cjwatson> it's not appropriate as the first alternative
[23:49] <ogra> yeah, thats what i switched ltsp to now
[23:49] <slangasek> oh, it's linux-image-* that was Recommending lilo?
[23:49] <cjwatson> yes
[23:49] <ogra> since my chroots just explode with recommends ...
[23:49] <slangasek> yeah, shouldn't be the first one, anyway
[23:50] <ogra> right and lilo in a chroot isnt really fun :)
[23:50] <cjwatson> for minimal chroots I think --no-install-recommends is entirely appropriate
[23:50] <cjwatson> they aren't the usual case
[23:50] <ogra> i was fearing i miss anyhing ..
[23:50] <ogra> but it seems to stil work fine
[23:51] <ogra> wont be the caes if we start to rely on recommends
[23:51] <ogra> *case
[23:51] <cjwatson> if we follow the definitions properly, it should be fine
[23:51] <slangasek> right; for a minimal chroot, --no-install-recommends is precisely how one finds out if a recommends should've been a depends instead :)
[23:52] <ogra> heh
[23:52] <cjwatson> calc:
[23:52] <calc> ok
[23:52] <calc> OOo 3.0 rc1 is delayed again until sept 1
[23:53] <calc> i am working on OOo 3.0 packaging split and hope to have some debs in PPA by the end of the week (maybe not all packages though)
[23:53] <calc> potentially having OOo 3.0 split packages parallel installable
[23:53] <slangasek> parallel alongside what?
[23:53] <calc> slangasek: the regular debs, if the 3.0 release slips much more we may have 3.0 split debs for test and 2.4.1 debs for the main install
[23:53] <doko> calc: is this the mmeks split?
[23:54] <cjwatson> my suggestion was, by way of having some concrete progress on OOo this cycle, to produce openoffice.org3-* modularised packages
[23:54] <calc> doko: yes
[23:54] <slangasek> ah :/
[23:54] <slangasek> right, that's better than getting stuck with prerelease 3.0 packages at release time
[23:54] <calc> slangasek: yea
[23:54] <cjwatson> and to use those as a guideline for the observable quality of 3.0
[23:55] <calc> slangasek: they still have sept 16 listed as release date, but that looks awfully optimistic
[23:55] <cjwatson> realistically we aren't going to get much feedback until there's something in the archive, but it seems like they're slipping too much for us to commit to 3.0
[23:55] <cjwatson> that's my take on it, anyway ...
[23:56] <calc> yes
[23:56]  * slangasek nods
[23:56] <calc> if they slip between rc1 and final as much as usual it will be around a week before ubuntu rc when its released
[23:56] <slangasek> yeah, not an ok time to be uploading it :-)
[23:56] <cjwatson> calc: did anything ever come of talking to Till about applications-printing?
[23:56] <calc> and final upstream releases generally are still a bit buggy
[23:57] <cjwatson> I remember you said you'd missed him at the sprint
[23:57] <calc> cjwatson: not much no
[23:57] <cjwatson> did you discuss it with Till?
[23:57] <calc> i talked to him again a few weeks ago, but i don't remember the outcome now
[23:57] <cjwatson> notes, IRC logs, ...?
[23:57] <calc> it looks like there aren't patches for the OOo bit so i would need to track down how to convert OOo to output as PDF
[23:58] <calc> i found the email
[23:58] <cjwatson> (I know I'm putting you on the spot, I just want to check it wasn't lost)
[23:58] <calc> OOo's PDF output is not that great to begin with so i am not sure what would be needed there
[23:59] <calc> there are some pdf changes for 3.0 but i haven't looked into what exactly has changed
[23:59] <calc> eg pdf import via poppler


[00:36] <bigjools> qhartman_too: check that maas-celery-cluster is running; check its log at /var/log/maas/celery.log
[16:51] <jtv> rvba: https://bugs.launchpad.net/maas/+bug/1314409